IT Village

AI 시대에 Java 개발자로 입문하기 위한 경쟁력에 대한 이야기

Kevin's IT Village — Fri, 7 Nov 2025 14:32:29 +0900

안녕하세요. Kevin입니다.

정말 오랜만에 포스팅을 하는 것 같은데요.

오늘은 프로그래밍이나 어떤 기술에 대한 구체적인 이야기를 하려고 하는 건 아니에요.

어쩌면 그것보다 더 중요한 이야기일 수 있는데 저의 생각이 담긴 이 글이 Java 개발자로 입문하고자 하는 분들에게 작은 동기부여 그리고 포기하지 마시라는 작은 응원이 될 수 있으면 하는 바램입니다.

그럼 지금부터 글을 적어볼게요. 처음에는 `부정적인` 분위기에서 곧 `긍정적인` 분위기로 바뀝니다. ^^;

1. Java 개발자로 입문하는 길은 더 좁아졌다?

현실적으로 보면 신입 개발자 채용이 줄어드는 건 사실이라고 생각해요. AI가 코드 레벨에서 많은 일을 대신하고 있다는 사실을 부정할 수는 없으니까요. 이건 숨기기 어려운 `팩트`라고 생각합니다.

2. 개발자는 더 적게 필요해진다?

단순히 개발자의 숫자로만 따진다면 과거보다 더 적게 필요해진다고 생각합니다.

기술이 발달할수록 인간의 손이 직접적으로 닿는 곳 중에 기술로 대체하기 쉬운 부분부터 순차적으로 대체하는 사례는 흔히들 찾아볼 수 있는 일이니까요.

공장 자동화로 인해서 제품을 생산하는 생산 인력이 로봇과 기계로 대체되는게 좋은 사례 같습니다.

그리고 최근에 많이 볼 수 있는 사례는 패스트푸드 점에서 주문할 때 사용할 수 있는 키오스크를 들 수 있구요. 키오스크가 설치되는 만큼 매장에서 일하는 직원 수는 줄어들 테니까요.

소프트웨어 개발자도 이런 기술 발달의 영향을 피해 갈 수는 없다고 생각합니다. 더군다나 AI가 인간에게 미치는 영향은 이때까지 나왔던 그 어떤 기술보다 영향력이 더 크다는 생각이 들기 때문이에요.

그렇기 때문에 표면적으로 `AI로 인해 개발자의 숫자는 줄어들 것이다`라는 의견에 저도 대표적으로 공감하고 있습니다.

다만..(지금까지는 좀 부정적인 이야기이고 이제부터 긍정적인 이야기를 시작해 볼게요. ^^)

3. 어떻게 보면 좋은 개발자가 되기 더 쉬워졌을 수 있다.

AI를 본격적으로 실무에서 사용하기 이전에 과연 개발자가 되기 쉬워졌을까를 생각해 보면 사실 그렇지도 않습니다.

개발자로 입문하고 취업하는 게 지금보다는 쉬웠겠지만 제대로 된 개발자로 성장해서 좋은 기업에 취업하기 어려운 건 그때나 지금이나 마찬가지라는 생각이 들거든요.

그러면 왜 그때보다 지금이 더 좋은 개발자가 되기 쉬워졌을까를 `문제 해결`이라는 관점에서 생각해 보면 이해하기가 좀 쉬워집니다.

AI를 자유롭게 활용할 수 있는 지금은 소프트웨어적으로 어떤 문제가 발생했을 때, 나를 도와줄 수 있는 강력한 서포터가 항상 내 옆에 있기 때문에 오히려 문제 해결하기가 훨씬 더 쉬워졌다는 생각이 듭니다.

저 포함해서 과거의 개발자들은 애플리케이션에 어떤 문제가 발생했을 때, 가장 의지할 수 있는 최고의 서포터가 바로 `구글링`이었는데요.

자체 디버깅으로 해결할 수 없는 문제들을 구글링으로 문제를 해결하기까지의 과정이 지금과는 말도 안 되게 험난했던 기억이 아직도 뚜렷하니까요.

결론적으로 AI라는 강력한 도구가 항상 곁에 있을 수 있기 때문에 AI와 호흡만 잘 맞출 수 있다면 좋은 개발자가 될 가능성은 예전보다 더 높아졌다고 생각합니다.

4. AI 시대에 맞는 경쟁력 있는 좋은 개발자란?

`다른 사람보다 경쟁력이 있는 개발자는 예전이나 지금이나 반드시 개발자의 길을 가게 된다`라고 저는 그렇게 생각하고 있습니다. ^^

예전에도 현장에서 늘 있던 웃픈 말 중에 하나가 `개발자는 많은데 뽑을 개발자가 없다`였습니다. 이 말의 의미가 이해되시죠?
경쟁력 있는 개발자는 그때도 많지 않았고, 지금도 많지 않다고 생각해요.

그런데 그때와 다르게 지금은 경쟁력 있는 개발자가 될 수 있는 가능성이 더 높아졌다고 생각합니다.
바로 AI가 항상 여러분들 옆에서 도와줄 수 있기 때문이죠.

AI로부터 최적의 도움을 받으려면 발생한 문제에 대해서 논리적이면서 구체적인 상황을 AI에게 잘 설명해야 되겠죠.
무언가를 만들어 달라고 할 경우에도 내가 만들고 싶은 그 무언가에 대해서 설명을 잘할 수 있어야 되는건 말할 것도 없구요.

자 그러면 AI에게 설명을 잘할 수 있는 가장 확실한 방법을 생각해 봅시다.

AI를 잘 활용할 수 있는 것이 앞으로 개발자의 가장 훌륭한 경쟁력이 될 거라고 생각하지만 AI를 활용하든 그렇지 않든 어떤 문제를 체계적으로 해결하려는 연습이 되어 있지 않으면 AI를 활용한 경쟁력 있는 개발자가 되는 건 불가능하지 않을까 조심스럽게 생각해 봅니다.

5. 아는만큼 활용할 수 있는 AI

소프트웨어적인 문제를 잘 해결하기 위해 AI의 도움을 정확하게 잘 받으려면 AI에게 문제에 걸맞은 정확한 질문을 해야 하고 AI가 답변을 제시하면 그 답변이 적절한 답이 맞는지를 검증할 수 있어야 합니다. 왜냐하면 AI는 거짓말도 밥 먹듯이 잘 하니까요.

`아는 만큼 보인다`라는 명언 들어보셨죠?

내가 소프트웨어적인 지식을 정확하게 알고 있다면 AI에게 질문도 더 정확하게 할 수 있고, AI의 답변도 더 정확하게 검증할 수 있다고 생각합니다.

`아는 만큼 보인다면 5년 10년 동안 개발 지식을 많이 쌓아야 하는 건가?` 이렇게 생각하실 수도 있지만 앞에서 얘기드렸다시피 저희에게는 AI라는 최고의 서포터가 있기 때문에 아는 만큼 보이기 위한 시간은 획기적으로 단축할 수 있을 거라고 생각해요.

6. 프로그래밍 기본기를 습득하는 방식의 변화

아무리 AI 시대라고 해도 아는 만큼 AI를 잘 활용하기 위한 시작은 프로그래밍의 기본기를 잘 습득하는 것이라고 생각합니다.

결국 프로그래밍의 기본기는 예나 지금이나 변함없이 중요하다는거죠.

그런데 과거와는 다른 방식이어야 한다고 생각해요.

과거에는..
`프로그래밍 문법 → 자료구조/알고리즘 → 많은 연습 → 몇 달 후 작동하는 애플리케이션 겨우 하나 만들기` 였다면,

현재는..
`프로그래밍 문법 → 바로 미니 프로젝트 → AI 도움으로 즉시 결과 확인 → 더 나은 코드로의 진화`

즉, 기본기는 여전히 필요하지만, 기본기를 배우는 방식이 아래와 같이 바뀌어야 된다고 생각합니다.

내가 먼저 작은 프로젝트라도 직접 수행하고 AI에게 피드백을 받은 후에 내 것으로 만든다.
그리고 더 나은 방식을 AI와 고민하면서 거기에서 더 나은 경험을 배우는 과정을 반복한다.

이렇게 해야 나 스스로가 해박해지면서 AI도 잘 활용할 수 있는 경쟁력 있는 개발자가 될 수 있을 것 같습니다.

7. 미니 프로젝트를 스스로 해보는 것의 중요성

로우 코드, 노코드, 바이브 코딩 등등 코드 하나 몰라도 AI한테 다 맡기면 모든 걸 다 제대로 만들 수 있을 것 같지만 결국 AI한테 제대로 일을 맡기려면 인간이 제대로 사고할 수 있어야 합니다.

개발자로써 제대로 사고하기 위한 가장 확실한 방법은 프로젝트를 스스로 많이 수행해 보는 것입니다.

내가 가지고 있는 능력만큼의 작은 프로젝트를 스스로 수행해 보세요.

그리고 나서 1차적으로 다 만든 프로젝트를 개선하기 위해 AI의 도움을 받아서 더 나은 방식의 애플리케이션을 만들어 보세요.
이렇게 하면 여러분들의 개발 스킬과 AI를 잘 활용할 수 있는 힘을 모두 축적할 수 있을거라는 생각이 드네요.

`일거 양득, 일타 쌍피`라는 말은 이럴 때 가장 어울리는 것 같습니다. ^^

다만, 지켜야 할 규칙은 `내가 먼저 만들어본다. 그다음에 AI의 도움을 받는다` 입니다.

개발자로 입문을 하게 되면 만들면서 AI의 도움을 그때그때 받겠지만 입문 전까지는 `선 사고, 후 도움` 이 규칙을 지켜야 되지 않을까 하고 생각해 봅니다.

7. 결론

부트 캠프에서 학생들을 가르칠 때도 직접 생각하고 코드를 타이핑하는 연습을 하지 않는 학생들이 굉장히 많았습니다.

눈으로만 보고, 귀로만 듣는 방법으로 좋은 개발자가 될 수 없듯이 내가 지식이 없이 AI에게 무조건 적으로 요청만 하면서 경쟁력 있는 개발자가 될 수는 없다고 생각해요.

신입으로 취업하는게 과거보다 더 어려워졌다는 뉴스 기사를 자주 접하는 요즘,

각자의 의견이 다르겠지만 저는 `사고하는 개발자 + AI의 활용`이라면 충분히 승산이 있다고 생각합니다.

마지막 한줄 결론은,

AI 시대에도 프로그래밍 기본기가 필요하다. 아니, AI 시대라서 더 필요하다.

입니다.

제가 포스팅한 이 글이 개발자로 입문하고자 하는 분들한테 조금이나마 힘이 되고, 동기 부여가 될 수 있으면 좋겠네요.

`나는 할 수 있다!!`고 여러분 스스로를 믿으세요. 그리고 포기하지 마세요.

저도 처음 개발자로 입문하기 전에는 고졸에 비전공에 프로그래밍 지식도 전무했었지만 결국 여기까지 왔으니 여러분도 분명 개발자가 될 수 있을 거에요.

개발자라는 직업은 꽤나 매력이 있는 직종입니다.

마지막까지 포기하지 마시고 여러분 앞을 가로막고 있는 벽을 반드시 넘을 수 있길 바래 볼게요.

끝까지 읽어주셨다면 감사합니다.

[Java 실무 프로젝트 입문편] 객체지향 사고력 훈련 (미니 프로젝트 3종 실습)

[Java 실무 프로젝트 입문편] 객체지향 사고력 훈련 - 미니 프로젝트 3종 실습| Kevin - 인프런 강의

현재 평점 5.0점인 강의를 만나보세요. 작은 프로젝트부터 구조 잡는 연습까지! Java 객체지향 설계와 실습 경험이 부족한 분들을 위한 직접 만들어보며 성장하는 미니 프로젝트 실전 입문 강의.

www.inflearn.com

[Java 실무 프로젝트 심화편] Spring Core + H2 기반 푸드 트럭 키오스크 시스템 제작

[Java 실무 프로젝트 심화편] Spring Core + H2 기반 푸드 트럭 키오스크 시스템 제작| Kevin - 인프런 강

실무 감각을 키우고 싶은 입문 개발자를 위한 Java 심화 프로젝트 강의! Spring Core, JdbcClient, H2 DB로 구성된 콘솔 기반 키오스크 주문 시스템을 함께 만들어갑니다. 요구사항을 분석하고 기능 단위

www.inflearn.com

Spring Boot 콘솔 애플리케이션에서 H2 인메모리 데이터베이스를 TCP 서버 모드로 설정하는 방법

Kevin's IT Village — Fri, 4 Apr 2025 15:49:35 +0900

✅ Spring Boot 콘솔 프로젝트에서 H2 DB를 TCP 서버 모드로 설정하는 이유

Spring 웹 애플리케이션에서 H2 인메모리 DB를 사용하는것과 마찬가지로 Spring Boot로 콘솔 기반 프로젝트에서도 H2 DB를 이용할 수 있는데요.

그런데 Spring 웹 애플리케이션에서 H2를 사용할 때처럼 콘솔 프로젝트에도 동일한 방식으로 사용할 수 있다라고 생각하기 쉬운데 웹 애플리케이션과 콘솔 애플리케이션은 구조적으로 동작 방식이 다릅니다.

웹 애플리케이션 vs 콘솔 애플리케이션의 차이점

구분	Spring 웹 애플리케이션	Spring 콘솔 애플리케이션
실행 방식	서버로 실행됨 (8080 등에서 계속 대기)	메인 메서드 실행 후 바로 종료
H2 DB 유지	실행 중엔 메모리 DB 유지 가능	애플리케이션 종료 시 H2 DB도 즉시 종료
외부 도구 접근	결과 확인을 위해 브라우저나 툴에서 접근하기 쉬움	브라우저나 툴에서 접근하기 어려움

그래서 저는 콘솔 애플리케이션에서 H2 DB를 TCP 서버 모드로 띄워서 외부 툴(IntelliJ 등)에서도 접근 가능하도록 구성하는 방식을 적용했고, 잘 동작하는걸 확인을 했는데 지금부터 그 구성 방식을 설명 드리도록 하겠습니다.

H2 TCP 서버 모드 설정 방법

1. Spring Boot 기본 H2 설정

spring:
  datasource:
    url: jdbc:h2:mem:testdb
    driver-class-name: org.h2.Driver
    username: sa
    password:

이 설정은 Spring Boot의 프로퍼티 설정 파일인 application.yml의 설정 내용인데 H2를 메모리 DB로 사용하기 위한 설정이기 때문에 애플리케이션이 종료되면 DB도 함께 종료되어서 메모리에 저장된 데이터가 사라집니다.

⚠️주의: Spring Boot는 Embedded 방식으로 DB를 연결해야 하며, TCP URL 사용 시 Spring Boot 애플리케이션에서 Embedded 방식의 DB에 연결하는 것이 아니라 Spring Boot 애플리케이션 외부의 H2 DB에 연결하려하기 때문에 tcp:// 형식으로 설정하면 Database not found 오류가 발생할 수 있으므로 주의해야합니다.

2. H2 TCP 서버를 코드로 실행하기

@Slf4j
@Configuration
public class H2ServerConfig {

    @Bean
    public CommandLineRunner startH2Server() {
        log.info("# h2 server started");
        return args -> {
            Server.createTcpServer("-tcp", "-tcpAllowOthers", "-tcpPort", "9092").start();
        };
    }
}

콘솔 애플리케이션 종료 시, H2 DB가 함께 종료되지 않도록 Spring Boot에서는 @Bean 애너테이션으로 H2를 TCP 서버 모드로 띄울 수 있도록합니다.

IntelliJ에서 연결하기

이제 IntelliJ에서 H2에 접속할 수 있도록 아래와 같은 순서로 설정하도록 합니다.

Database 탭 → Data Source → H2 선택
JDBC URL: jdbc:h2:tcp://localhost:9092/mem:testdb
User: sa, Password: 비워도 OK
이렇게 설정하면 콘솔 애플리케이션이 즉시 종료되지 않고 애플리케이션이 실행 중일 때 H2에 접속할 수 있게 됩니다.

흔히 발생하는 오류와 해결 방법

잘못된 설정 예시

예를 들어서 application.yml에서의 H2 설정을 클래스 레벨에서도 구성할 수 있는데 아래와 같이 tcp://로 시작하는 URL과 같이 설정하면 어떻게 될까요?

System.setProperty("spring.datasource.url", "jdbc:h2:tcp://localhost:9092/mem:testdb"); // ❌ 오류 발생

위에서 설명했던 것 처럼 마찬가지로 Spring 애플리케이션이 외부 TCP 서버로 접속을 시도하게 되어, Database not found 또는 Connection refused와 같은 오류가 발생할 수 있습니다.

정상 설정 예시

System.setProperty("spring.datasource.url", "jdbc:h2:mem:testdb"); // ✅ 올바른 방식

application.yml이 아닌 클래스 레벨에서 H2를 설정할 경우에는 꼭 tcp://localhost:9092를 제외하고 지정해야 한다는 사실을 기억하세요.

H2 관련 포트 정리

모드	기본 포트	설명
H2 TCP 서버	9092	외부 툴(JDBC 클라이언트) 접속용
H2 Web Console	8082	브라우저에서 사용하는 Web UI
Spring Boot	8080	Spring 애플리케이션 기본 포트

마무리 요약

콘솔 기반 Spring Boot 앱에서는 H2를 TCP 서버 모드로 띄워야 실시간 DB 확인이 가능하다는 사실을 기억해 주세요.
Spring 내부는 mem:testdb로 접근, 외부 툴은 tcp://localhost:9092로 연결해야 한다는 사실을 잊지 마세요.

이 포스트가 Spring Boot 기반의 콘솔 애플리케이션에서 H2를 효율적으로 사용하는 데 도움이 되었길 바랍니다.

감사합니다!

[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

Kevin's IT Village — Wed, 26 Mar 2025 11:43:38 +0900

“작은 프로젝트 세 개를 해보니,
이제 조금은 애플리케이션 구현에 자신감이 생겼습니다.
그런데 그다음엔 뭘 해야 하죠?”

1부 강의를 끝낸 분들이 종종 묻는 질문입니다.
그리고 이 질문이 나오는 순간, “이제부터가 진짜구나”라는 답을 드리고 싶어요.

1부는 입문, 2부는 확장입니다

1부에서 우리는

콘솔 기반의 작은 프로젝트를 통해
설계 → 구현 → 검증이라는 사이클을
직접 여러 번 반복해 봤습니다.

그 과정에서 “어떻게 나눌까?”, “이건 어떤 책임이지?”
이런 객체지향적 질문들을 훈련했죠.

하지만 현실에서의 프로젝트는
이보다 조금 더 복잡하고, 더 유연한 구조를 요구합니다.
그걸 경험해 보는 게 바로 2부의 목표입니다.

2부에서 바뀌는 것들

✅ 프로젝트의 성격이 달라집니다

1부: 기능 중심 / 단순한 구조
2부: 실제 실무에서처럼 역할이 명확한 시스템 구성

예: 고객과 직원이 각기 다른 화면(콘솔 인터페이스)을 사용하고,
내부에서는 주문, 메뉴, 영수증, 매출 등 다양한 역할이 분리되어 존재합니다.

✅ 설계가 더 중요해집니다

1부에선 “일단 만들어보자”였다면,
2부에선 만들기 전에 먼저 설계를 고민하게 됩니다

클래스 다이어그램을 그려보거나,
요구사항을 기능 단위로 분리해 보는 훈련을 하게 됩니다.

✅ 테스트와 리팩터링의 감각을 배웁니다

코드를 먼저 만들고 나서
“이걸 테스트하려면 구조가 이래야겠네”
“이건 너무 많은 역할을 하고 있구나”
같은 생각이 자연스럽게 생기게 됩니다.

즉, 구현 → 회고 → 개선의 흐름을
작은 규모에서부터 확장된 구조로 연결시켜보게 되는 거죠.

조금 더 실무에 가까워지는 여정

2부 강의는
이제 막 객체지향을 ‘감’으로 이해한 입문자가
조금 더 실무스러운 사고방식을 익히는 데에 초점을 둡니다.

레이어드 아키텍처
도메인 중심의 클래스 분리
간단한 저장소 구현
H2 인메모리 데이터베이스
JUnit을 통한 단위 테스트

이런 기술들도 간단히 등장하지만,
기술 자체보다 구조와 사고 흐름에 집중합니다.

이런 분께 2부를 추천합니다

1부를 들으며 "이제 구현이 좀 재밌다" 느끼신 분
뭔가 만들 수는 있는데 “내가 맞게 하고 있나?” 의문이 생기는 분
코드가 길어지면 점점 흐름을 통제하지 못하는 느낌을 겪는 분
“실무에서 이런 건 어떻게 하지?”라는 궁금증이 드 분

강의 둘러보기

Java 실무 프로젝트 입문편 - 객체지향 사고력 훈련 (미니 프로젝트 3종 실습)

Java 실무 프로젝트 심화편 - 오픈 예정

2부에서는
Spring 프레임워크를 이용해 콘솔 기반 키오스크 주문 시스템을 함께 만들어봅니다.

1부보다 조금 더 복잡한 구조로,

손님용 콘솔
직원용 콘솔
주문, 메뉴, 매출 관리 등
여러 역할이 명확하게 나뉘는 시스템을 설계합니다.

또한 Spring의 JdbcClient를 활용해 H2 DB와 연동하는 실습도 포함되어 있어 간단한 영속성 처리까지 경험할 수 있습니다.

Java 개발 입문자들을 위해 1부보다 한 단계 더 깊이 있는 객체지향 설계와 구조적 사고를 경험할 수 있다는 사실을 기억해 주세요!

시리즈 목차

이 글은 `Java 구현이 막막한 당신에게` 시리즈의 마지막 편입니다.
그래도 끝이 아니라, 이제 다음 단계가 시작되는 순간일지도 모르죠

시리즈 전체 글

[0편] Java 문법은 아는데 구현이 막막해요 – 그럴 땐 이렇게 해봤습니다
[1편] 왜 구현이 막막한가? – Java 초심자의 고민
[2편] 작은 프로젝트에서 배우는 객체지향
[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기
[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?(현재 글)

[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기

Kevin's IT Village — Wed, 26 Mar 2025 11:43:15 +0900

“이거 정답(레퍼런스) 코드 주시는 건가요?”

학생들을 가르치다 보면 강의 초반에 많이 듣는 질문 중 하나입니다.
당연히 정답(레퍼런스) 코드가 있겠지만 이 강의의 목표는 ‘정답 코드’를 주는 것이 아니라,
자신이 작성한 코드와 강사가 작성한 코드 중에서 더 나은 코드를 도출해 ‘자신만의 코드’를 만들 수 있는 사고력을 기르는 것에 있습니다.

직접 해보는 것만큼 강력한 학습은 없다

Java에 대한 문법은 책이나 온라인 강의로도 배울 수 있고,
좋은 코드는 인터넷에도 많습니다.
하지만 그걸 스스로 처음부터 구현해 보는 경험은
완전히 다른 차원의 학습입니다.

어떤 클래스를 만들지
어떤 책임을 나눌지
어떤 흐름으로 동작시킬지

이걸 직접 고민하면서 만들어보는 경험은
그 사람만의 사고 구조를 만듭니다.

그다음, 비교가 시작됩니다

강의는 이런 구조로 구성되어 있습니다:

먼저 혼자서 만들어본다
- 요구사항 분석 → 직접 구현 (실패해도 괜찮음)
강사(Kevin)의 구현과 비교해 본다
- 클래스 분리, 책임 분산, 테스트 방식 등을 비교
왜 그렇게 만들었는지 설명을 듣는다
- 좋은 코드의 작성 패턴뿐만이 아니라 ‘생각의 흐름’을 공유

이 과정은 단순한 코드 암기가 아니라
설계적 사고의 틀을 만드는 훈련입니다.

혼자 구현할 때 얻는 것

내가 뭘 모르는지 알게 됩니다
내가 자주 실수하는 패턴을 알게 됩니다
내가 코드를 짤 때 어떤 순서로 생각하는지 점검할 수 있습니다

즉, 나를 객관화할 수 있는 절호의 기회가 생깁니다.

그리고 강의의 비교 파트를 통해
“아, 이렇게 구조를 바꿨더니 테스트가 쉬워졌네”
“이건 책임을 나눈 게 훨씬 유연하구나”
이런 인사이트를 얻는 순간,
진짜 성장이 시작됩니다.

코드가 아니라, '사고방식'을 배우는 강의

이 강의는
단순히 코드 예제를 따라 치는 강의가 아닙니다.

내가 구현 → 비교 → 리팩터링 → 이해 → 내 것으로 만들기

이런 자기 주도형 구조로 되어 있기 때문에,
코드를 ‘이해’하는 것이 아니라
‘생각하는 법’을 배우는 과정에 가깝습니다.

참고 강의

Java 실무 프로젝트 입문편 - 객체지향 사고력 훈련 (미니 프로젝트 3종 실습)

정답 코드를 외우는 것이 아니라,
‘왜 이렇게 만들었는가’를 함께 고민하고 성장하는 강의입니다.
직접 구현해보고 비교해보는 방식은
입문자에게도, 다시 기본을 다지고 싶은 분에게도
가장 강력한 학습법이 될 수 있습니다.

시리즈 목차 & 다음 글 안내

이 글은 Java 구현이 막막한 당신에게 시리즈의 일부입니다.
스스로 구현하고 비교하는 과정을 통해, 사고력과 설계력을 함께 키워보세요!

시리즈 목차

[0편] Java 문법은 아는데 구현이 막막해요 – 그럴 땐 이렇게 해봤습니다
[1편] 왜 구현이 막막한가? – Java 초심자의 고민
[2편] 작은 프로젝트에서 배우는 객체지향
[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기(현재 글)
[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

다음 글: [4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

[2편] 작은 프로젝트에서 배우는 객체지향

Kevin's IT Village — Wed, 26 Mar 2025 11:42:27 +0900

“객체지향이 중요하대서 이론은 공부했는데...
막상 어떻게 적용해야 할지 모르겠어요.”

Java를 공부한 입문자들에게 가장 많이 듣는 이야기입니다.
책을 보고 개념은 어느 정도 이해했는데,
직접 객체지향으로 무언가를 만들어본 경험은 거의 없다는 거죠.

객체지향은 '이해'보다 '적용'이 어렵다

추상화, 캡슐화, 상속, 다형성…
책으로 보면 뭔가 멋져 보이는데
막상 프로젝트에 쓰려고 하면 어디에 써야 할지 막막하죠.
특히 작은 프로젝트를 만들다 보면
“굳이 클래스를 나눠야 해?”, “이걸 인터페이스로 만드는 게 맞아?”
같은 고민에 빠지게 됩니다.

그런데 바로 이런 혼란과 시행착오 과정이
진짜 객체지향을 습득하게 해주는 가장 좋은 기회입니다.

작은 프로젝트 = 객체지향 훈련장

작은 콘솔 프로젝트라도
역할 분리 → 책임 분리 → 메시지 전달 흐름을 따라가다 보면
자연스럽게 객체지향적인 사고가 시작됩니다.

예를 들어 이런 흐름을 겪어보게 되죠:

기능 목록을 쪼개다가, 반복되는 책임을 발견하고
해당 역할을 담당할 클래스를 하나 만들고
그 클래스가 너무 커지면 다시 분리하거나 상속이나 인터페이스 구조를 고민하게 되고
테스트를 해보면서 유연한 구조를 고민하게 되는…

이런 반복이 쌓이면서
자연스럽게 설계 감각이 생기고,
“객체지향이 뭔지 이제 조금은 알겠어”라는 순간이 찾아옵니다.

중요한 건 '정답'이 아니라 '시도'

입문자분들이 흔히 하는 실수 중 하나는
“객체지향 설계의 정답이 있겠지” 하고
인터넷에서 구조를 그대로 베끼는 겁니다.

하지만 진짜 실력은

내가 먼저 만들어보고
불편함을 느끼고
더 좋은 구조를 찾고
다른 사람이 만든 코드의 구조와 비교하면서 배우는 과정에서 나옵니다.

그렇기 때문에,
처음부터 정답이라 생각되는 코드를 보지 않고
내가 먼저 직접 만들어보는 경험이 정말 중요합니다.

이 강의에서는 이런 훈련을 합니다

강의에서는
총 3가지 미니 프로젝트를 직접 만들어보게 됩니다.

요구사항을 먼저 분석해 보고
스스로 설계/구현한 뒤
강사(Kevin)가 구현한 버전과 비교하며 객체지향적 사고를 훈련합니다

강의의 목적은
“정답 코드”를 주는 것이 아니라,
“사고 방식”을 훈련하는 것입니다.

참고 강의

Java 실무 프로젝트 입문편 - 객체지향 사고력 훈련 (미니 프로젝트 3종 실습)

3가지 미니 프로젝트를 통해
입문자도 부담 없이 객체지향 감각을 키울 수 있도록 구성했습니다.

시리즈 목차 & 다음 글 안내

이 글은 Java 구현이 막막한 당신에게 시리즈의 일부입니다.
작고 반복 가능한 훈련으로, 객체지향에 한 걸음 더 다가가보세요

시리즈 목차

[0편] Java 문법은 아는데 구현이 막막해요 – 그럴 땐 이렇게 해봤습니다
[1편] 왜 구현이 막막한가? – Java 초심자의 고민
[2편] 작은 프로젝트에서 배우는 객체지향(현재 글)
[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기
[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

다음 글: [3편] 강의 방식: 스스로 만들고, 비교하며 성장하기

[1편] 왜 구현이 막막할까? – Java 입문자의 고민

Kevin's IT Village — Wed, 26 Mar 2025 11:27:15 +0900

“Java 문법은 이제 대충 알겠는데 구현이 너무 어렵습니다.”

Java 입문자를 대상으로 강의를 하다 보면, 정말 자주 듣는 말입니다.
심지어 객체지향이나 상속, 캡슐화 같은 개념도 알고 있어요.
그런데 막상 “작은 애플리케이션 하나 구현해 보세요” 하면, 손이 멈춰버립니다.

익숙하지만 낯선 그 순간

Java는 분명히 익숙해졌는데,
“뭐부터 해야하지?” , “어떤 클래스부터 만들지?”, “이걸 어떻게 나눠야 하지?”
이런 질문 앞에서 멈칫하게 됩니다.

이런 상황이 오는 이유는 단순히 ‘공부가 부족해서’가 아닙니다.
오히려 문법 위주로만 학습해 왔기 때문이죠.

클래스는 만들 수 있지만,
“왜” 만드는지, “어떻게 역할을 나누는지”,
이런 설계적 사고가 없으면 구현은 늘 막막합니다.

제자들의 사례

제가 부트캠프나 인프런 강의에서 만난 많은 학생들이 그랬어요.

CRUD는 할 줄 아는데, 어떤 기능부터 만들어야 할지 모르겠어요
Spring MVC 구조를 배우긴 했는데, Controller가 모든 역할을 다 해버려요
객체지향이 중요하다는 건 알지만, 어떻게 적용해야 할지 감이 오질 않아요

이런 분들이 공통적으로 말하던 건 하나입니다.
“애플리케이션을 구현 하라고 하면, 막막해져요.”

이유는 명확합니다

“문제 해결을 위한 사고력”을 훈련할 기회가 없었기 때문입니다.
우리 사회는 ‘정답’을 배우는 데 익숙해져 있죠.

하지만 구현은 정답이 아니라 선택과 책임의 연속입니다.

이 클래스는 어떤 역할을 맡아야 할까?
어떤 책임을 다른 객체에게 위임할 수 있을까?
변경이 생기면 어느 부분이 영향을 받을까?

이런 고민은 코드를 많이 외운다고 생기는 게 아니라,
직접 부딪히고, 설계하고, 고치면서 생깁니다.

그래서 이 시리즈를 시작합니다

이 글은 `Java 구현이 막막한 당신에게`라는 시리즈의 첫 번째 이야기입니다.
저 역시 개발자로 입문했을 때 학생들과 같은 고민을 수없이 했기 때문에
이제는 그 과정을 정리하고 함께 나누고 싶었습니다.

다음 편에서는,
작은 프로젝트 하나가 어떻게 객체지향 사고력을 키워주는지에 대해
이야기해 보려 합니다.

참고 강의

이 시리즈는 아래 강의 내용을 기반으로 하고 있습니다:
Java 실무 프로젝트 입문편 - 객체지향 사고력 훈련 (미니 프로젝트 3종 실습)

강의에서는 먼저 스스로 만들어보고,
이후 저의 설계와 구현을 비교해 보는 방식으로 학습이 진행됩니다.
정답이 아니라 사고력을 함께 키워가는 과정,
그게 제가 이 강의를 만든 이유입니다.

시리즈 목차 & 다음 글 안내

이 글은 `Java 구현이 막막한 당신에게` 시리즈의 일부입니다.
차근차근 읽어나가며, 함께 성장해봐요

시리즈 목차

[0편] Java 문법은 아는데 구현이 막막해요 – 그럴 땐 이렇게 해봤습니다
[1편] 왜 구현이 막막한가? – Java 초심자의 고민(현재 글)
[2편] 작은 프로젝트에서 배우는 객체지향
[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기
[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

다음 글: [2편] 작은 프로젝트에서 배우는 객체지향

[0편] “Java 문법은 아는데 구현이 막막해요” – 그럴 땐 이렇게 했습니다

Kevin's IT Village — Sun, 23 Mar 2025 07:46:58 +0900

[Java 실무 프로젝트 입문편] 객체지향 사고력 훈련 - 미니 프로젝트 3종 실습 강의 썸네일

Java 프로젝트가 막막할 때, 작게 시작해 보세요

“Java 문법은 배웠는데, 직접 무언가를 구현하려니까 너무 막막했어요.” 이런 고민, 한 번쯤 해보셨나요? Java는 분명 문법도 많고, 클래스나 인터페이스 같은 개념도 어렵죠. 그래서 학원이나 부트캠프를 수료하고도 “이제 뭘 만들어야 하지?” 라며 길을 잃기 쉬운데요.

Spring 전에, 작고 단단한 구현 경험이 필요합니다

많은 입문자들이 Java를 배운 뒤 곧바로 Spring으로 넘어가지만, 막상 프로젝트 구현을 시작하려면 손이 안 움직이는 경우가 많습니다. 그 이유는 간단합니다. “코드를 직접 구조화해서 만들면서 익힌 적이 없기 때문”입니다.

이 강의는 그런 분들을 위해 만들어졌습니다.

✔️ 설계 ✔️ 구현 ✔️ 테스트 ✔️ 리팩토링 이 모든 단계를 직접 해보는 미니 프로젝트 실습 과정입니다.

이 강의는 어떤 강의인가요?

작지만 핵심이 있는 3가지 Java 미니 프로젝트를 구현합니다. 좋은 코드 구조, 객체지향 설계, 테스트, 책임 분리 등 실무에 필요한 감각을 처음부터 끝까지 경험할 수 있어요.

구구단 앱 (Stream API로 구현)
할 일 관리 앱 - 설계와 테스트 중심 구현
할 일 관리 앱 - Google Tasks API 연동

직접 만들어보며, “내가 생각한 설계를 코드로 옮기는 훈련”을 할 수 있습니다.

이런 분들에게 꼭 추천합니다

- Java 문법은 아는데, 뭘 만들어야 할지 모르는 분
- “구현해 보라”는 말에 두려움을 느끼는 분
- Spring 전에 Java의 기초를 실전처럼 다지고 싶은 분
- 코드 품질, 구조, 설계에 대한 감각을 키우고 싶은 분

수강 전 vs 수강 후, 이렇게 달라집니다

- “요구사항을 코드로 옮기기 막막했어요” → 클래스와 기능 단위로 구조화하는 능력이 생깁니다
- “객체지향 설계를 해본 적이 없어요” → OOP 사고방식으로 실제 설계를 해봅니다
- “그냥 코드만 외우고 있었어요” → 구조를 이해하고 직접 만들어보는 습관이 생깁니다
- “강의는 보는데, 코드가 머리에 안 남아요” → 먼저 구현하고, 강사 코드와 비교하는 방식으로 배웁니다

수강생의 실전 감각을 키우는 방식

이 강의는 단순히 강사의 코드를 따라치는 방식이 아닙니다. “요구사항 문서”를 바탕으로 먼저 스스로 구현한 후, 강사 코드와 비교해보며 더 나은 구조를 고민하게 됩니다.
✅ 내가 먼저 만들고 ✅ 내가 비교하고 ✅ 내가 개선해보는 흐름 이게 바로 이 강의의 핵심 방식입니다.

지금 수강하면 할인된 가격에 수강할 수 있어요

2025년 4월 4일까지 30% 할인 강의 바로 가기 (인프런)

이 강의로 기대할 수 있는 것

✔ Java 객체지향 설계 감각
✔ 프로젝트 구조 설계 경험
✔ 코드 테스트 및 리팩토링 역량
✔ 강의 따라하기가 아닌 진짜 실전 감각

마무리

“구현은 어렵지만, 시작하면 생각보다 멀지 않습니다.” 작게, 단단하게, 확실하게 시작해보세요. 이 강의가 여러분의 첫 구조화된 프로젝트가 되길 바랍니다.

‍♂️ 글쓴이: Kevin (Java 백엔드 강사 / 미니 프로젝트 실전 시리즈 제작자)

이 글은 [Java 구현이 막막한 당신에게] 시리즈의 시작입니다.
아래 시리즈 글들을 통해, 작은 프로젝트로 객체지향 설계와 Java 애플리케이션 구현을 연습하는 여정을 함께 할 수 있었으면 좋겠네요.

관련 강의:
[Java 실무 프로젝트 입문편 - 객체지향 사고력 훈련 (미니 프로젝트 3종 실습)]

[Java 실무 프로젝트 입문편] 객체지향 사고력 훈련 - 미니 프로젝트 3종 실습 강의 | Kevin - 인프런

Kevin | , [임베딩 영상]이런 분들께 추천해요Java 문법은 배웠지만, 실제로 어디서부터 어떻게 구현해야 할지 모르는 분Java 프로젝트 실습 경험이 부족한 분Spring을 배우긴 했지만, Java 기본기가 약

www.inflearn.com

시리즈 목차 & 다음 글 안내

이 글은 Java 구현이 막막한 당신에게 시리즈의 일부입니다.
스스로 구현하고 비교하는 과정을 통해, 사고력과 설계력을 함께 키워보세요!

시리즈 목차

[0편] Java 문법은 아는데 구현이 막막해요 – 그럴 땐 이렇게 해봤습니다(현재 글)
[1편] 왜 구현이 막막한가? – Java 초심자의 고민
[2편] 작은 프로젝트에서 배우는 객체지향
[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기
[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

다음 글: [1편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

Java Stream API 한방에 이해하기

Kevin's IT Village — Thu, 13 Mar 2025 22:23:03 +0900

Java의 Stream은 위에서 아래로 흐르는 시냇물이다

프로그래밍에서 데이터를 처리할 때, 우리는 보통 for 문을 이용한 반복문을 먼저 떠올립니다.
하지만 Java 8부터 등장한 Stream API는 완전히 다른 방식으로 데이터를 다루게 해줍니다.

Stream은 마치 위에서 아래로 흐르는 시냇물처럼
컬렉션(List, Set 등)의 데이터를 흘려보내며
필터링하고, 가공하고, 집계하는 도구입니다.

예를 들어 볼까요?

코드 스니핏 (Java):

List<String> names = List.of("kevin", "tom", "emma");

names.stream()
    .filter(name -> name.length() >= 5)
    .map(String::toUpperCase)
    .forEach(System.out::println);

이 코드는 names 리스트에 담긴 데이터를

길이가 5 이상인지 판단해서 필터링해주고 (filter)
대문자로 변환한 후에 (map)
한 줄씩 출력 (forEach) 하는 구조입니다.

즉, Stream이 제공하는 선언형 스타일을 통해
하나의 흐름 속에서 데이터를 가공하고 처리하는 전체 과정을 명확하게 표현할 수 있습니다.

Stream은 각자 자기 할 일만 한다

Stream의 구성은 체이닝 구조로 이루어져 있으며, 각 연산은 자신이 맡은 역할만 수행합니다.

filter(): 조건을 걸어 원하는 요소만 통과시킵니다.
map(): 데이터를 다른 형식으로 변환합니다.
sorted(): 데이터를 정렬합니다.
collect(): 최종 결과를 컬렉션 형태로 반환합니다.
forEach(): 하나씩 꺼내서 소비(처리)합니다.

예를 들어 다음 코드처럼 각 연산은 파이프라인처럼 연결되어 실행됩니다.

코드 스니핏 (Java):

List<String> cities = List.of("Seoul", "Busan", "Incheon");

cities.stream()
    .filter(city -> city.length() > 5)
    .map(String::toLowerCase)
    .forEach(System.out::println);

여기서 filter()는 길이가 5보다 큰 도시만 남기고,
map()은 해당 도시명을 소문자로 바꾸며,
forEach()는 최종 출력 처리를 담당합니다.

각 단계는 자기 할 일만 수행하고,
다른 연산과는 독립적으로 설계되어 있어 유지보수가 쉬워집니다.

Stream은 ‘대용량 데이터’를 흘려 보내기 위해 태어났다

많은 사람들이 처음엔 “for문 대신 쓰면 깔끔하네?”라고 Stream을 이해하지만,
사실 Java가 Stream을 만든 진짜 이유는 따로 있습니다.

그 이유는 바로 대용량 데이터를 효율적으로 다루기 위해서입니다.

기존 방식은 데이터를 전부 메모리에 올려놓고 처리했지만 Stream은 데이터를 하나씩 읽는 순간 바로 처리할 수 있습니다.
즉, 메모리를 덜 사용하고, 처리 효율도 훨씬 높다는 말이죠.

이 말이 이해되지 않는 다면 다음 예를 통해 Stream의 중요한 특징을 이해해 보세요.

공장에서 하루에 라면을 1만 개 생산한다고 가정해봅시다.

만약 면 1만 개를 모두 만든 다음에 포장 작업을 시작하려면,
완성된 면을 담아둘 엄청나게 큰 그릇이 필요하겠죠.

반면에 면이 하나 만들어질 때마다 바로 포장 단계로 넘어간다면,
그릇 같은 중간 저장 공간은 필요 없습니다.

이렇게 각 공정이 바로바로 이어지는 방식이 바로 Stream의 처리 방식과 유사합니다.

공정이 바로바로 이어진다는 의미는 1만 개의 면이 모두 만들어질 때까지 기다릴 필요가 없다는 뜻이기 때문에 공정 시간 또한 단축될 수 있다는 의미입니다.

아래 그림은 방금 설명한 Stream의 처리 흐름을 시각적으로 표현한 것입니다.
Java Stream이 데이터를 처리하는 과정을 공장에서 제품을 생산할 때 사용하는 컨베이어 벨트에서의 흐름으로 그려봤습니다.

그림: 데이터소스에서 데이터가 하나씩 흐르며 filter → map → collect 단계를 거치는 구조

데이터 소스에서 데이터가 하나씩 흐르며 filter → map → collect 단계를 거치는 구조

이 그림을 보면, Stream이 어떤 구조로 데이터를 처리하는지 한눈에 이해할 수 있습니다.

조금 더 여러분의 이해를 돕기 위해 코드 예시로 설명하겠습니다.

예를 들어 파일에서 한 줄씩 데이터를 읽고 싶다고 해봅시다.

기존 방식:

코드 스니핏 (Java):

List<String> lines = Files.readAllLines(Path.of("data.txt"));
for (String line : lines) {
    if (line.contains("ERROR")) {
        System.out.println(line.toUpperCase());
    }
}

이 방식은 data.txt의 모든 라인을 List<String>에 한꺼번에 읽어들인 뒤,
해당 리스트를 반복문으로 순회하며 원하는 라인을 찾아 처리합니다.

처음엔 직관적이고 익숙하게 느껴질 수 있지만,
문제가 되는 건 파일 크기입니다.

파일에 수천만 줄이 있다면, 그 모든 데이터를 한꺼번에 메모리에 올리게 되며
→ 메모리 사용량이 급증하고 OutOfMemoryError가 발생할 위험도 있습니다.
모든 데이터를 메모리에 읽어놓고 그 후에야 처리하므로
→ 처리 지연이 발생하며, 반응성도 낮습니다.
실시간으로 라인이 계속 추가되는 로그 파일이라면
→ 매번 파일을 다시 읽어야 하므로 비효율적입니다.

Stream 방식:

코드 스니핏 (Java):

try (Stream<String> lines = Files.lines(Path.of("data.txt"))) {
    lines.filter(line -> line.contains("ERROR"))
         .map(String::toUpperCase)
         .forEach(System.out::println);
}

이 방식은 모든 데이터를 한꺼번에 메모리에 올릴때 까지 기다리는게 아니라 파일에서 한 줄씩 읽어오면서
조건에 맞는 줄만 필터링하고, 대문자로 변환 후 출력까지 이어집니다.

한 줄씩 읽고 처리하므로 메모리 사용량이 매우 적습니다.
Stream의 lazy evaluation(지연 처리) 덕분에 필요한 작업만 최소로 수행합니다.
처리 속도도 빨라지고, 대용량 로그 처리나 실시간 분석에도 적합합니다.

Java의 Stream과 Lambda는 베스트 프렌드이다. 그래서 게으르다

Java의 Stream은 선언형 API입니다.
즉, “어떻게 처리할지”를 구체적으로 지시하기보다는
“이렇게 처리하겠다”는 의도를 선언하는 방식으로 코드를 작성하게 해줍니다.

그런데 재미있는 점은, 이렇게 처리 흐름을 선언해도
최종 연산(forEach, collect 등)이 실행되기 전까지는 아무런 동작도 하지 않는다는 점입니다.

이런 동작 방식을 우리는 lazy evaluation(지연 처리)라고 부르죠.

그리고 이 Stream은 Lambda(람다)와 함께 사용할 때 그 진가가 드러납니다.
바로 반복적인 처리를 훨씬 더 간결하고 직관적으로 표현할 수 있기 때문이에요.

코드 스니핏 (Java):

List<String> list = List.of("apple", "banana", "grape");

list.stream()
    .filter(s -> s.startsWith("b"))
    .map(String::toUpperCase)
    .forEach(System.out::println);

이 코드는 먼저 "b"로 시작하는 문자열만 골라낸 다음,
그 문자열을 대문자로 변환해서 출력합니다.여기서 중요한 건, 리스트에 있는 모든 데이터를 한꺼번에 처리하는 것이 아니라
필요한 데이터만 골라서, 그때그때 필요한 작업만 수행한다는 점이에요.
이런 방식이 바로 Stream의 지연 처리(lazy evaluation) 특성을 잘 보여줍니다.
따라서 실행 결과는 "BANANA" 하나만 출력되죠.

Stream을 어떨 때 사용하면 좋을까?

Java Stream은 단순히 코드를 깔끔하게 만드는 것뿐 아니라, 데이터를 다루는 다양한 상황에서 효율적인 해결책이 되어줍니다.
다음과 같은 경우에 특히 효과적이에요:

반복 작업이 많고, 데이터를 필터링하거나 가공하는 로직이 자주 등장할 때
(예: 조건에 맞는 값만 골라내고, 형식을 바꾸는 작업 등)
기존 코드가 너무 복잡해서 가독성이나 유지보수에 부담을 느낄 때
→ Stream은 처리 흐름을 명확하게 보여주기 때문에, 읽기 쉽고 수정도 편해집니다.
파일, DB, API 등에서 연속적으로 들어오는 데이터를 실시간으로 처리해야 할 때
→ 한꺼번에 데이터를 모두 모으지 않고, 한 줄씩 흘려보내며 처리할 수 있어요.
다루는 데이터의 양이 크고, 메모리 사용량을 최소화하면서 처리하고 싶을 때
→ 필요한 데이터만 읽고, 처리하고, 버리기 때문에 훨씬 효율적입니다.
성능이 중요한 상황에서 병렬 처리(parallel stream)를 통해
데이터를 동시에 나눠서 처리하고 싶을 때도 유용합니다.

실제로 어떻게 써보면 좋을까?

Stream의 개념을 이해했더라도, 실제로 써보지 않으면 감이 잘 안 올 수 있습니다.

그래서 저는 Stream의 개념만 이해하는 예제가 아니라 Stream을 애플리케이션 구현에 실제로 적용해 볼 수 있는 실사용 예를 강의에 담았습니다:

구구단 애플리케이션 실습: Stream 기본 처리 흐름을 익히기 좋은 입문 실습
사전지식 실습 문제: 조금 더 복잡한 데이터 가공 흐름을 직접 경험
할일 관리 애플리케이션 프로젝트: 리스트 필터링, 상태 변경, 정렬 등
실제 서비스에서 발생할 수 있는 상황을 Stream으로 구현해볼 수 있습니다.

단순히 문법만 배우는 게 아니라, Stream을 “실제로 사용할 수 있는 수준까지” 도달할 수 있게 도와주는 강의입니다.

Java 백엔드 미니 프로젝트 실습 강의 보기
https://www.inflearn.com/course/java-백엔드-미니프로젝트-실습

[Java 실무 프로젝트 입문편] 객체지향 사고력 훈련 - 미니 프로젝트 3종 실습 강의 | Kevin - 인프런

www.inflearn.com

JwtAuthorizationFilter에 try ~ catch 문이 있고, 없고의 차이

Kevin's IT Village — Mon, 18 Dec 2023 18:45:43 +0900

Spring Security 기반의 애플리케이션에 아이디/패스워드 로그인 인증 후, 전달 받은 JWT를 이용해 서버 측 리소스에 접근한다고 가정해 봅시다.

이 경우, 매 요청마다 JWT를 request header에 포함해서 요청 전송을 할텐데요.

이 JWT를 JwtAuthorizationFilter가 검증할 경우, 두 가지 케이스를 테스트 해 보았습니다.

JwtAuthorizationFilter에서 인증이나 접근 권한 등의 예외를 try ~ catch로 잡는 경우

public class JwtVerificationFilter extends OncePerRequestFilter {
    private final JwtTokenizer jwtTokenizer;
    private final CustomAuthorityUtils authorityUtils;

    public JwtVerificationFilter(JwtTokenizer jwtTokenizer,
                                 CustomAuthorityUtils authorityUtils) {
        this.jwtTokenizer = jwtTokenizer;
        this.authorityUtils = authorityUtils;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
       // JWT 검증 시, 발생하는 예외를 try ~ catch 문으로 catch 하는 경우
       try {
            Map<String, Object> claims = verifyJws(request);
            setAuthenticationToContext(claims);
        } catch (Exception e) {
            request.setAttribute("exception", e);
        }

        filterChain.doFilter(request, response);
    }
    
    ...
    ...
}

SecurityFilterChain 동작이 ExceptionTranslationFilter 까지 넘어 간다.
ExceptionTranslationFilter에서 다시 AuthorizationFilter로 동작이 넘어간다.
AuthorizationDecision.isGranted()이기 때문에 AccessDeniedException이 throw된다.
ExceptionTranslationFilter에서 예외를 catch 한다.
ExceptionTranslationFilter 내부에서 AccessDeniedException을 처리하는 로직을 수행한다.
- handleAccessDeniedException()
  - 인증 여부를 체크해서 인증이 되지 않았으면 AuthenticationEntryPoint를 이용해 예외를 처리한다.
  - 인증은 된 상태이고 권한이 적절하지 않다면 AccessDeniedHandler를 이용해 예외를 처리한다.

JwtAuthorizationFilter에서 인증이나 접근 권한 등의 예외를 try ~ catch로 잡지 않는 경우

public class JwtVerificationFilter extends OncePerRequestFilter {
    private final JwtTokenizer jwtTokenizer;
    private final CustomAuthorityUtils authorityUtils;

    public JwtVerificationFilter(JwtTokenizer jwtTokenizer,
                                 CustomAuthorityUtils authorityUtils) {
        this.jwtTokenizer = jwtTokenizer;
        this.authorityUtils = authorityUtils;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        // JWT 검증 시, try ~ catch 문으로 catch 하지 않는 경우
        Map<String, Object> claims = verifyJws(request);

        filterChain.doFilter(request, response);
    }

    ...
    ...
}

예외가 throw 되어서 톰캣 같은 서블릿 컨테이너 레벨까지 전파된다.
`/error` URL로 리다이렉트 된다.
Spring Framework의 BasicErrorController의 error() 핸들러 메서드가 `/error` 요청을 수신한다.
디폴트 에러 메시지를 JSON 형태로 리턴한다.

ObjectMapper를 이용한 JSON 역직렬화(Deserialization) 이야기

Kevin's IT Village — Thu, 9 Feb 2023 17:23:40 +0900

Spring MVC에서 ObjectMapper로 json 포맷의 request body를 DTO 객체로 역직렬화 하는 방법은 크게 두 가지이다.

디폴트 생성자가 있을 경우,

이 경우는 다음과 같은 순서를 따라 역직렬화를 수행한다. 역직렬화의 시작점은 BeanDeserializer이다.

BeanDeserializer.deserializeFromObject()에서 디폴트 생성자를 이용한 리플렉션 기법(Constructor.newInstance(Object[] args)으로 DTO 객체를 생성한다.
FieldProperty.deserializeAndSet(...)에서 리플렉션으로 얻어온 Field에 JSON 포맷에서 얻은 값을 set한다. 여기서의 Field는 DTO 객체의 멤버 필드의 메타 정보를 포함한 객체이다.

디폴트 생성자가 있을 경우의 결론은 디폴트 생성자를 이용해서 Java의 리플렉션을 이용해 Field에 값을 세팅한다.

디폴트 생성자가 없을 경우,

문제는 디폴트 생성자가 없을 경우이다.

이 경우는 IntelliJ에서 Gradle 빌드 옵션(IntelliJ > Settings > Build, Execution, Deployment > Build Tools > Gradle)을 Gradle(default)로 설정하느냐 IntelliJ로 설정하느냐에 따라 다르다.

여기서의 핵심은 PropertyBasedCreator 객체가 null이냐 그렇지 않느냐이다.

Gradle 빌드 옵션을 Gradle(default)로 설정할 경우,

디폴트 생성자가 없어도 argument가 있는 Constructor 정보를 이용한 리플렉션 기법을 통해 JSON에서 DTO 객체로 역직렬화가 된다.

PropertyBasedCreator 객체가 null이 아니다.

PropertyBasedCreator가 null이 아니므로, BeanDeserializer.deserializeFromObjectUsingNonDefault() 에서 시작해 내부적으로 더 들어 가면,

PropertyBasedCreator가 StdValueInstantiator를 이용해 역시 리플렉션 기법으로 argument가 있는 Constructor로 객체를 생성한다.

argument가 있다라는 것은 DTO 클래스의 필드에 생성자 주입을 통해 바로 값이 세팅된다라는 의미와 같다.

Gradle 빌드 옵션을 IntelliJ로 설정할 경우,

디폴트 생성자가 없으면 JSON에서 DTO 객체로 역직렬화가 되지 않는다.

PropertyBasedCreator 객체가 null이다.

PropertyBasedCreator가 null 이므로, 디폴트 생성자나 argument가 있는 생성자를 이용해 리플렉션으로 DTO 클래스의 객체를 생성할 수 없다.

PropertyBasedCreator에 대해서는 아래와 같이 설명하고 있다.

Object that is used to collect arguments for non-default creator (non-default-constructor, or argument-taking factory method) before creator can be called. Since ordering of JSON properties is not guaranteed, this may require buffering of values other than ones being passed to creator.

즉, 디폴트 생성자가 아닌 생성자의 argument를 수집하는데 사용한다고 설명이 나와 있음.

결론

Gradle 빌드 옵션이 Gradle(default)일 경우, 디폴트 생성자가 없어도 리플렉션을 통해 argument가 있는 Constructor 정보로 DTO 객체를 생성할 수 있다. 즉, 어떤 경우도 역직렬화가 가능하다.
Gradle 빌드 옵션을, IntelliJ로 설정하면 PropertyBasedCreator 객체가 생성되지 않으므로, 디폴트 생성자가 반드시 있어야지만 역직렬화가 가능하다.
Gradle 빌드 옵션을 바꾸지 말자.

Reactor Sequence에서 발생하는 signal의 전파 흐름

Kevin's IT Village — Sat, 28 Jan 2023 23:10:44 +0900

이번 시간에는 Reactor Sequence 상에서 발생하는 signal의 전파 흐름을 알아보도록 하겠습니다.

일반적인 Signal의 전파 흐름

1
2
3
4
5
6
7
8
9
10
11
12
13

import lombok.extern.slf4j.Slf4j;
import reactor.core.publisher.Flux;
 
@Slf4j
public class ReactorSignalEventPropagationExample01 {
    public static void main(String[] args) {
        Flux
            .range(1, 1)
            .filter(n -> n > 0)
            .map(n -> n * 2)
            .subscribe(data -> log.info("# onNext: {}", data));
    }
}
코드 1-1 일반적인 signal 이벤트 흐름

 

코드 1-1은 Reactor Sequence 상에서 발생하는 signal의 전파 흐름을 확인하기 위한 예제 코드입니다.

예제 코드 상에는 log() Operator가 빠져있지만 range(), filter(), map() Operator 하단에 각각 log() Operator를 추가해서 실행하면 아래와 같은 로그를 출력합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

18:51:02.355 [main] DEBUG reactor.util.Loggers - Using Slf4j logging framework
18:51:02.369 [main] INFO log.range - | onSubscribe([Synchronous Fuseable] Operators.ScalarSubscription)
18:51:02.371 [main] INFO log.filter - | onSubscribe([Fuseable] FluxFilterFuseable.FilterFuseableSubscriber)
18:51:02.371 [main] INFO log.map - | onSubscribe([Fuseable] FluxMapFuseable.MapFuseableSubscriber)
18:51:02.372 [main] INFO log.map - | request(unbounded)
18:51:02.372 [main] INFO log.filter - | request(unbounded)
18:51:02.372 [main] INFO log.range - | request(unbounded)
18:51:02.372 [main] INFO log.range - | onNext(1)
18:51:02.372 [main] INFO log.filter - | onNext(1)
18:51:02.372 [main] INFO log.map - | onNext(2)
18:51:02.372 [main] INFO com.codestates.example.schedulers.SchedulersExample04 - # onNext: 2
18:51:02.373 [main] INFO log.range - | onComplete()
18:51:02.373 [main] INFO log.filter - | onComplete()
18:51:02.373 [main] INFO log.map - | onComplete()
 

 

로그를 보면, 코드 1-1에서 발생하는 signal은 아래와 같은 순서로 전파됩니다.

range | onSubscribe() --> filter | onSubscribe() --> map | onSubscribe()
--> map | request() --> filter | request() --> range | request()
--> range | onNext() --> filter | onNext() --> map | onNext()
--> range | onComplete() --> filter | onComplete() --> map | onComplete()

이를 통해 알 수 있는 사실 두 가지를 살펴보면,

먼저 대부분의 Operator들은 각각 자신만의 Subscriber를 포함하고 있고, 이 Subscriber와 서로 signal을 주고 받으면서 데이터를 전송하고 데이터를 전달 받는다는 것을 알 수 있습니다.

다름으로 onSubscribe, onNext, onComplete signal은 Downstream 쪽으로 전파되고, request signal은 Upstream 쪽으로 전파되는 것을 알 수 있습니다.

subscribeOn()이 추가되었을 때 Signal의 전파 흐름

그렇다면 subscribeOn() Operator가 Operator 체인에 추가되면 signal의 전파 흐름은 어떻게 변할까요?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import lombok.extern.slf4j.Slf4j;
import reactor.core.publisher.Flux;
import reactor.core.scheduler.Schedulers;
 
@Slf4j
public class ReactorSignalEventPropagationExample02 {
    public static void main(String[] args) throws InterruptedException {
        Flux
            .range(1, 1)
            .doOnSubscribe(subscription -> log.info("# doOnSubscribe"))
          .subscribeOn(Schedulers.boundedElastic()) // (1)
            .map(n -> n * 2)
            .subscribe(data -> log.info("# onNext: {}", data));
 
        Thread.sleep(100L);
    }
}
코드 1-2 subscribeOn()이 추가되었을 때 signal 이벤트 흐름

 

코드 1-2는 subscribeOne() Operator가 Operator체인에 추가되었을 때 signal의 전파 흐름을 살펴보기 위한 예제 코드입니다. ( 로그 출력 결과가 복잡해 보일 것 같아 filter() Operator는 제외했습니다.)

코드 1-1과 마찬가지로 log() Operator를 각각의 Operator 다음에 추가해서 코드를 실행하면 로그 출력 결과는 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

21:48:27.992 [main] INFO log.subscribeOn - onSubscribe(FluxSubscribeOn.SubscribeOnSubscriber)
21:48:27.993 [main] INFO log.map - onSubscribe(FluxMap.MapSubscriber)
21:48:27.994 [main] INFO log.map - request(unbounded)
21:48:27.994 [main] INFO log.subscribeOn - request(unbounded)
21:48:28.003 [boundedElastic-1] INFO log.range - | onSubscribe([Synchronous Fuseable] Operators.ScalarSubscription)
21:48:28.004 [boundedElastic-1] INFO com.codestates.example.schedulers.SchedulersExample05 - # doOnSubscribe
21:48:28.005 [boundedElastic-1] INFO log.doOnSubscribe - | onSubscribe([Fuseable] FluxPeekFuseable.PeekFuseableSubscriber)
21:48:28.006 [boundedElastic-1] INFO log.doOnSubscribe - | request(unbounded)
21:48:28.006 [boundedElastic-1] INFO log.range - | request(unbounded)
21:48:28.006 [boundedElastic-1] INFO log.range - | onNext(1)
21:48:28.006 [boundedElastic-1] INFO log.doOnSubscribe - | onNext(1)
21:48:28.006 [boundedElastic-1] INFO log.subscribeOn - onNext(1)
21:48:28.006 [boundedElastic-1] INFO log.map - onNext(2)
21:48:28.006 [boundedElastic-1] INFO com.codestates.example.schedulers.SchedulersExample05 - # onNext: 2
21:48:28.006 [boundedElastic-1] INFO log.range - | onComplete()
21:48:28.006 [boundedElastic-1] INFO log.doOnSubscribe - | onComplete()
21:48:28.006 [boundedElastic-1] INFO log.subscribeOn - onComplete()
21:48:28.006 [boundedElastic-1] INFO log.map - onComplete()
 

 

로그가 좀 복잡해보이는데 어쨌든 코드 1-2의 signal 전파 흐름을 보면 코드 1-1과 조금 다르다른 것을 알 수 있습니다.

subscribeOn()이 추가되지 않았던 코드 1-1에서는 range()부터 차례대로 onSubscribe signal이 전파되었는데 코드 1-2의 경우에는 subscribeOn()부터 onSubscribe signal이 Downstream쪽으로 전파되고, request signal이 다시 Upstream 쪽으로 전파되지만 range()까지 전파되는 것이 아니라 subscribeOn()까지만 전파되고 이 후 부터는 range()부터 onSubscribe signal이 subscribeOn()까지만 전파된 후에 request signal이 다시 range()까지 전파되고 이 후부터는 onNext signal이 Downstream 끝까지 전파되고, 다음에 onComplete signal 역시 Downstream 끝까지 전파되는 것을 알 수 있습니다.

signal의 전파 흐름이 굉장히 복잡한데 이 복잡함을 덜 복잡하게 이해하기 위해서는 signal의 전파 흐름을 subscribeOn() Operator를 기준으로 생각하면 됩니다.

subscribeOn() Operator를 기준으로 signal 흐름을 요약하면,

먼저 onSubscribe signal이 Downstream 쪽으로 전파
-> request signal이 Upstream 쪽으로 전파되지만 subscribeOn() Operator까지만 전파
-> range() 부터 onSubscribe signal이 전파되지만 subscribeOn() 까지만 전파
-> request signal이 Upstream 쪽으로 전파
-> onNext signal이 Downstream 끝까지 전파
-> onComplete signal이 Downstream 끝까지 전파

위에서 설명한 signal 전파 흐름을 코드 상의 흐름으로 간략하게 표현하면 아래의 [그림 1-1]과 같습니다.

[그림 1-1] subscribeOn()이 추가될 경우의 signal 전파 흐름

그리고, subscribeOn() Operator가 추가 되었을 때 signal 전파 흐름이 어떻게 되는지 Reactor 코드 내부에서 사용되는 코드를 통해 조금 더 구체적으로 표현하면 아래의 [그림 1-2]와 같습니다.

[그림 1-2] subscribeOn()이 추가될 경우의 signal 전파 흐름(detail description)

[그림 1-2]의 signal 전파 흐름이 꽤 복잡해 보이지만 Reactor에서 실제 사용되는 컴포넌트들을 이용해 [그림 1-1]을 조금 더 구체적으로 표현한 것 뿐입니다.

만일 [그림 1-2]를 이해하는것이 어렵게 느껴진다면 [그림 1-1]만 이해해도 충분하다고 생각합니다.

Operator 체인상에서 doOnSubscribe()의 위치에 따른 실행 쓰레드의 변경

[그림 1-2]를 보면 doOnSubscribe() Operator는 subscribeOn() 위 쪽에 추가되어있습니다.

이 경우, doOnSubscribe()의 실행 쓰레드는 코드 1-2의 로그 출력 결과에서도 확인할 수 있다시피 boundedElastic-1 쓰레드에서 실행되는 이유가 뭘까요?

doOnSubscribe() Operator는 onSubscribe()가 호출되었을 때 이어서 호출되는 일종의 콜백입니다.
따라서 onSubscribe()가 호출될 때의 실행 쓰레드와 동일한 쓰레드에서 실행이 됩니다.

doOnSubscribe()를 호출되게 하는 onSubscribe()는 어디서 호출될까요?

[그림 1-2]의 signal 전파 흐름에서도 알 수 있듯이 range()에서 onSubscribe()가 호출되면 뒤이어 doOnSubscribe()가 호출됩니다.

range()의 실행 쓰레드는?

바로 boundedElastic-1 쓰레드입니다.

따라서 range()에서 호출하는 onSubscribe()도 boundedElastic-1 쓰레드이고, doOnSubscribe()의 실행 쓰레드 역시 boundedElastic-1 쓰레드입니다.

만약 doOnSubscribe()를 subscribeOn() 바로 아래에 추가한다면 doOnSubscribe()의 실행 쓰레드는 무엇일까요?

이 경우, doOnSubscribe()의 실행 쓰레드는 subscribeOn()에서 호출되는 onSubscribe()의 영향을 받습니다.

[그림 1-2]에서 subscribeOn()의 실행 쓰레드는 무엇인가요?

바로 main 쓰레드입니다.

따라서 subscribeOn()에서 호출하는 onSubscribe()도 main 쓰레드이고, doOnSubscribe()의 실행 쓰레드 역시 main 쓰레드입니다.

헷갈리겠지만 이것 하나만 기억하면 됩니다.

doOnSubscribe()의 실행 쓰레드는 doOnSubscribe() 바로 위 쪽에 있는 Operator가 호출하는 onSubscribe()의 실행 쓰레드와 같다.

이 글이 Reactor Sequence 상에서 발생하는 signal의 전파 흐름과 subscribeOn()과 doOnSubscribe()의 실행 쓰레드의 관계를 이해하는데 조금이라도 도움이 될 수 있길 바래봅니다.

Spring Security OAuth 2 컴포넌트 요약

Kevin's IT Village — Thu, 26 Jan 2023 18:57:35 +0900

1️⃣ OAuth2LoginAuthenticationFilter

OAuth 2 인증을 처리하기 위한 Filter

2️⃣ CommonOAuth2Provider

신뢰할 만한 OAuth 2 Provider 목록 제공
실질적으로 각 Provider에게 넘겨줘야 되는 Client 정보를 포함한 ClientRegistration 객체를 생성한다.

3️⃣ ClientRegistration

각 OAuth 2 Provider 사용을 위해 Client에게 필요한 등록 정보

public enum CommonOAuth2Provider {

	GOOGLE {

		@Override
		public Builder getBuilder(String registrationId) {
			ClientRegistration.Builder builder = getBuilder(registrationId,
					ClientAuthenticationMethod.CLIENT_SECRET_BASIC, DEFAULT_REDIRECT_URL);
      // Provider가 제공할 Resource 범위
			builder.scope("openid", "profile", "email");

      // Client가 OAuth 2 인증을 위해 Redirect하는 URI(구글의 로그인 인증 화면)
			builder.authorizationUri("<https://accounts.google.com/o/oauth2/v2/auth>");

      // Client가 Access Token과 Refresh Token을 얻기 위해 호출하는 URI
			builder.tokenUri("<https://www.googleapis.com/oauth2/v4/token>");

      // JWT 검증용 Key Set을 조회할 수 있는 URI
			builder.jwkSetUri("<https://www.googleapis.com/oauth2/v3/certs>");

      // Access Token 발행자 정보 조회 URI
			builder.issuerUri("<https://accounts.google.com>");

      // Resource Owner의 User Info를 조회하기 위한 URI
			builder.userInfoUri("<https://www.googleapis.com/oauth2/v3/userinfo>");

      // Resource Owner의 이름에 접근하기 위한 Attribute Name
			builder.userNameAttributeName(IdTokenClaimNames.SUB);

      // Client Name. Provider를 구분하는 용도로 사용
			builder.clientName("Google");
			return builder;
		}

	},
  
  ...
  ...

}

4️⃣ OAuth2AuthorizedClientService

OAuth 2로 인증된 Client(OAuth2AuthorizedClient)를 관리하는 서비스 클래스
OAuth2AuthorizedClientService 인터페이스의 구현 클래스
- InMemoryOAuth2AuthorizedClientService
- JdbcOAuth2AuthorizedClientService

5️⃣ ClientRegistrationRepository

OAuth 2로 인증된 Client(OAuth2AuthorizedClient)를 저장하는 역할을 한다.
- ClientRegistrationRepository 인터페이스의 구현 클래스
  - InMemoryClientRegistrationRepository
OAuth2AuthorizedClientService가 ClientRegistrationRepository를 사용해 OAuth2AuthorizedClient 를 저장한다.

6️⃣ OAuth2AuthorizedClientManager

OAuth2AuthorizedClient 를 관리하는 관리자 역할을 한다.

7️⃣ OAuth2AuthorizedClientProvider

Authorization Grant 유형을 설정할 수 있는 인터페이스
- Authorization Code
- Implicit Grant Type
- Client Credentials
- Resource Owner Password Credentials

ContentCachingRequestWrapper 사용 예

Kevin's IT Village — Tue, 24 Jan 2023 23:57:18 +0900

Spring MVC 기반의 웹 애플리케이션을 개발하다보면 Interceptor나 AOP Advice 등에서 request body를 사용해야하는 경우가 종종 있을 수 있습니다.

reqeust 전송 시, header에 추가되 전송되는 JWT의 claims에 포함된 memberId와 request body에 포함된 memberId가 동일한지를 검증하는 예를 들어보겠습니다.

@Slf4j
@Component
@Aspect
public class MemberVerifyAdvice extends VerifyAdvice {
    private final ObjectMapper objectMapper;
    public MemberVerifyAdvice(JwtTokenizer jwtTokenizer, ObjectMapper objectMapper) {
        super(jwtTokenizer);
        this.objectMapper = objectMapper;
    }

    @Pointcut(
            "execution(* com.itvillage.member.controller.MemberController.postQnaQuestionOfMember(..)) || " +
                    "execution(* com.itvillage.qna.controller.QnaQuestionController.postAnswerOfQuestion(..))"
    )
    public void verifyMySelfWithPointcut(){}

    @Before(value = "verifyMySelfWithPointcut()")
    public void verifyMySelf(JoinPoint joinPoint) throws IOException {
        String jws = getHeader("Authorization").substring(7);
        long memberIdFromJws = getMemberIdFromJws(jws);

        long memberIdFromRequest = extractMemberId();

        checkSameMember(memberIdFromJws, memberIdFromRequest);

    }

    private long extractMemberId() throws IOException {
        // (1)
        HttpServletRequest request = 
                  ((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest();
        
        
        String body = IOUtils.toString(request.getReader());  // (2-1)
        or
        String body = 
        	StreamUtils.copyToString(request.getInputStream(), StandardCharsets.UTF_8); // (2-2)

        ...
        ...
        
    }
}

코드 1-1 MemberVerifyAdvice

먼저 코드 1-1에서 처럼 request body를 파싱하기 위해 AOP Advice에서 (1)과 같이 RequestContextHolder를 이용해 HttpServletRequest를 얻습니다.

그리고 (2-1)과 같이 apache commons io 라이브러리를 이용하거나 (2-2)와 같이 Spring에서 제공하는 StreamUtils를 이용해 request body를 얻기 위한 시도를 할 수 있습니다.

그런데 (2-1) 또는 (2-2)와 같은 코드가 실행되면 request body가 비어있거나 getInputStream() has already been called for this request 같은 에러가 발생해 정상적으로 request body를 얻을 수 없습니다.

⭐ 이유는 Spring Boot에 내장된 Tomcat의 경우 HttpServletRequest의 InputStream을 한번 read 하게되면 다시 읽을 수 없도록 구현되어 있기 때문입니다.

즉, 이 말은 AOP Advice에서 얻은 HttpServletRequest는 Advice에 도달하기 전에 이미 어딘가에서 InputStream을 read 했다는 의미와도 같습니다.

Advice에서 request body를 정상적으로 사용하려면 어떻게 해야할까요?

이런 경우에는 InputStream을 애플리케이션 어딘가에서 read 하기 전에 ContentCachingRequestWrapper를 이용해 원본 HttpServletRequest를 캐싱해 두면 됩니다.

즉, 캐싱해서 저장해 두었다가 나중에 필요할 때 꺼내서 사용할 수 있도록 하는 것입니다.

ContentCachingRequestWrapper로 원본 HttpServletRequest를 캐싱하기 좋은 지점은 바로 필터입니다.

필터를 하나 추가해서 해당 필터에서 ContentCachingRequestWrapper로 원본 HttpServletRequest를 캐싱하면 됩니다.

ContentCachingRequestWrapper로 원본 HttpServletRequest를 캐싱하기

Filter 생성

import org.springframework.web.filter.OncePerRequestFilter;
import org.springframework.web.util.ContentCachingRequestWrapper;
import org.springframework.web.util.ContentCachingResponseWrapper;

import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class HttpServletWrappingFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws ServletException, IOException {
        // ContentCachingRequestWrapper로 HttpServletRequest 캐싱
        ContentCachingRequestWrapper wrappingRequest = new ContentCachingRequestWrapper(request);
        ContentCachingResponseWrapper wrappingResponse = new ContentCachingResponseWrapper(response);
        filterChain.doFilter(wrappingRequest, wrappingResponse);
        wrappingResponse.copyBodyToResponse();
    }
}

코드 1-2 HttpServletWrappingFilter

코드 1-2와 같이 ContentCachingRequestWrapper를 이용해 HttpServletRequest와 HttpServletResponse를 캐싱하는 필터를 생성합니다.

이렇게하면 나중에 원본 HttpServletRequest를 사용하고자 하는 곳에서 ContentCachingResponseWrapper를 이용해 request body를 사용하면 됩니다.

Filter 추가

@Configuration
public class WebConfiguration {
    @Bean
    public FilterRegistrationBean<HttpServletWrappingFilter> firstFilterRegister()  {
    	// HttpServletWrappingFilter 추가
        FilterRegistrationBean<HttpServletWrappingFilter> registrationBean =
                new FilterRegistrationBean<>(new HttpServletWrappingFilter());
        registrationBean.setOrder(Integer.MIN_VALUE);

        return registrationBean;
    }
}

코드 1-3 FilterRegistrationBean

코드 1-3과 같이 FilterRegistrationBean을 이용해 앞에서 생성한 HttpServletWrappingFilter를 FilterChain에 추가합니다.

ContentCachingRequestWrapper로 원본 HttpServletRequest 사용

@Slf4j
@Component
@Aspect
public class MemberVerifyAdvice extends VerifyAdvice {
    private final ObjectMapper objectMapper;
    public MemberVerifyAdvice(JwtTokenizer jwtTokenizer, ObjectMapper objectMapper) {
        super(jwtTokenizer);
        this.objectMapper = objectMapper;
    }

    @Pointcut(
            "execution(* com.itvillage.member.controller.MemberController.postQnaQuestionOfMember(..)) || " +
                    "execution(* com.itvillage.qna.controller.QnaQuestionController.postAnswerOfQuestion(..))"
    )
    public void verifyMySelfWithPointcut(){}

    @Before(value = "verifyMySelfWithPointcut()")
    public void verifyMySelf(JoinPoint joinPoint) throws IOException {
        String jws = getHeader("Authorization").substring(7);
        long memberIdFromJws = getMemberIdFromJws(jws);

        long memberIdFromRequest = extractMemberId();

        checkSameMember(memberIdFromJws, memberIdFromRequest);

    }

    private long extractMemberId() throws IOException {
        HttpServletRequest request = 
                  ((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest();
        
		// (1)
		ContentCachingRequestWrapper requestWrapper = WebUtils.getNativeRequest(request, ContentCachingRequestWrapper.class);
        byte[] body = requestWrapper.getContentAsByteArray();  // (2)
        
        ...
        ...
        
    }
}

코드 1-3 개선된 MemberVerifyAdvice

코드 1-3과 같이 (1)에서 WebUtils를 이용해 ContentCachingRequestWrapper 얻은 후에 (2)에서 ContentCachingRequestWrapper의 getContentAsByteArray()로 request body를 얻고 있습니다.

이 글에서 처럼 request body를 read하려는데 정상적으로 read하지 못하는 경우가 있다면 이 글이 도움이 되길 바래봅니다.

JWT를 이용한 인증(Authentication) 및 자격 검증(Authorization) 프로세스

Kevin's IT Village — Thu, 19 Jan 2023 21:51:11 +0900

Spring Security에서 JWT를 발급 받는 방법은 크게 두 가지로 볼 수 있습니다.

첫째는 구글 검색을 통해서도 흔히 볼 수 있는 Controller를 이용해서 아이디/패스워드 로그인 후, JWT를 발급 받는 방식이고, 두 번째는 Spring Security에서 지원하는 Security Filter를 확장하는 방법입니다.

Controller를 이용하는 것이 안좋은 방법이라고 보기는 힘들지만 그래도 Spring Security라는 보안 프레임워크를 사용하는 개발자 입장에서는 Controller까지 request가 전달되기 전에 Security Filter 레벨에서 인증을 처리하는 것이 조금 더 자연스럽지 않을까하는 생각을 해보게 됩니다.

이번 글에는 구체적인 코드는 없지만 JWT를 이용해 어떤식으로 인증이 처리 되는지 그리고 JWT를 이용해서 클라이언트의 자격을 검증하는 프로세스가 어떻게 진행 되는지를 그림으로만 표현하도록 하겠습니다.

이 글에 있는 그림을 보고 CSR(Client Side Rendering) 방식의 애플리케이션에서 JWT를 이용해 인증 및 클라이언트의 자격 검증 로세스를 어떻게 코드로 구현할 수 있는지에 대한 인사이트를 얻어갈 수 있기를 바래봅니다.

JWT 인증 프로세스

[그림 1-1] JWT 인증 프로세스

[그림 1-1]의 JWT 인증 프로세스는 다음과 같습니다.

클라이언트가 최초 로그인 인증을 위해 username(이메일 등의 로그인 아이디)과 password를 request body에 실어서 전송합니다.
- 백엔드 애플리케이션 쪽으로 전송된 username과 password는 JwtAuthenticationFilter에 전달되어 JwtAuthenticationFilter에서부터 클라이언트에 대한 인증 프로세스가 시작됩니다.
- JwtAuthenticationFilter는 UsernamePasswordAuthenticationFilter를 확장해서 구현하면 됩니다.
JwtAuthenticationFilter에서 AuthenticationManager의 구현 클래스인 ProdiverManager를 거쳐 인증되지 않은(unauthenticated) Authentication 객체가 AuthenticationProvider에게 전달됩니다.
AuthenticationProvider는 인증되지 않은(unauthenticated) Authentication 객체에 포함된 username을 UserDetailsService의 구현 클래스인 MemberDetailsService에게 전달합니다.
- loadUserByUsername(String username)을 이용.
UserDetailsService의 구현 클래스인 MemberDetailsService는 데이터베이스에서 사용자의 Credential(암호화 된 패스워드)을 조회한 뒤 조회한 Credential을 포함한 UserDetails를 AuthenticationProvider에게 리턴합니다.
AuthenticationProvider는 전달 받은 UserDetails에 포함된 Credential(암호화 된 패스워드)과 인증되지 않은(unauthenticated) Authentication 객체에 포함된 password를 암호화 해서 둘을 비교합니다.
- 두 패스워드를 비교해서 검증에 성공하면 인증된(authenticated) Authentication 객체를 JwtAuthenticationFilter에게 전달합니다.
- 두 패스워드를 비교해서 검증에 실패하면 AuthenticationException을 throw합니다.
JwtAuthenticationFilter는 전달 받은 인증된(authenticated) Authentication을 이용해 Access Token과 Refresh Token을 생성해 response header에 추가합니다.

JWT를 이용한 클라이언트 자격 검증 프로세스

[그림 1-2] JWT를 이용한 클라이언트 자격 검증 프로세스

클라이언트 측에서 JWT를 성공적으로 전달 받았다면 이제 전달 받은 Access Token을 이용해서 백엔드 애플리케이션의 API 엔드포인트에 접근할 수 있습니다.

[그림 1-2]의 JWT를 이용한 클라이언트 자격 검증 프로세스는 다음과 같습니다.

클라이언트는 백엔드 애플리케이션의 API 엔드포인트를 이용하기 위해 request를 전송할 때 마다 request header에 Access Token을 실어보냅니다.
JwtVerificationFilter는 전달 받은 Access Token이 유효한 JWT인지를 검증하기 위해 JwtTokenizer에게 JWT 검증을 요청합니다.
JwtTokenizer는 Access Token의 Signature를 검증합니다.
- Access Token이 유효한 JWT이면 Claims를 리턴합니다.
- Access Token이 유효하지 않으면 Exception을 throw합니다.
JwtVerificationFilter는 전달 받은 Claims를 이용해 username과 role 정보를 포함한 Authentication 객체를 SecurityContext에 저장합니다.
- 이제 인증된(authenticated) Authentication 객체가 SecurityContext에 저장되어 있으므로 DispatcherServlet에 도달하기 전의 마지막 Security Filter까지 문제 없이 통과할 수 있습니다.
DispatcherServlet부터는 Spring MVC의 기본적인 요청 처리 흐름에서 알 수 있듯이 Controller까지 요청이 전달됩니다.

JWT 자격 검증 시, SecurityContext는 언제 비워(clear)질까?

Kevin's IT Village — Thu, 19 Jan 2023 21:19:07 +0900

클라이언트 쪽에서 전송한 username과 password에 대한 인증을 처리하는 JwtAuthenticationFilter(UsernamePassworAuthenticationFilter를 확장)에서 로그인 인증에 성공한 뒤, JWT를 클라이언트 쪽에 응답으로 전달했다고 가정해 봅시다.

이제 클라이언트는 백엔드 애플리케이션의 API 엔드포인트를 이용할 때 마다 백엔드 애플리케이션으로부터 전달 받은 JWT를 header에 포함시켜 request를 전송합니다.

만약 JWT를 검증하는 필터인 JwtVerificationFilter가 구현되어 있는 상태라면 백엔드 애플리케이션에서는 이 JwtVerificationFilter를 이용해 클라이언트의 request header 등에 포함된 JWT를 검증하는 처리를 할 것입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class JwtVerificationFilter extends OncePerRequestFilter {
    ...
    ...
 
    @Override
    protected void doFilterInternal(HttpServletRequest request, 
                                    HttpServletResponse response, 
                                    FilterChain filterChain) throws ServletException, IOException {
        // System.out.println("# JwtVerificationFilter");
 
        try {
            Map<String, Object> claims = verifyJws(request);    // (1)
            setAuthenticationToContext(claims);           // (2)
        } catch (SignatureException se) {
            request.setAttribute("exception", se);
        } catch (ExpiredJwtException ee) {
            request.setAttribute("exception", ee);
        } catch (Exception e) {
            request.setAttribute("exception", e);
        }
 
        filterChain.doFilter(request, response);
    }
    ...
    ...
}
코드 1-1 JwtVerificationFilter 코드 일부

cs

코드 1-1은 JwtVerificationFilter의 코드 일부입니다.

먼저 (1)에서 클라언트로부터 전달 받은 JWT를 검증합니다.

검증에 성공하면 (2)에서 처럼 인증된(authenticated) Authentication 객체를 SecurityContext에 저장합니다.

그런데 만약에 (2)와 같이 Authentication 객체를 SecurityContext에 저장하지 않으면 어떻게 될까요?

SecurityFilterChain에서 아직 처리가 진행되지 않은 즉, 뒤에 남아있는 Filter 어딘가에서 SecurityContext에 저장된 Authentication 객체가 있는지 확인했는데 Authentication 객체가 존재하지 않아서 결국엔 정상적인 요청 프로세스가 진행되지 못하고 클라이언트 쪽에 에러 메시지를 전송하게 됩니다.

⭐ 따라서 JWT 검증 이후에 SecurityContext에 Authentication 객체를 반드시 저장해 주어야 한다는 사실을 기억해야 합니다.

그런데 이런 생각을 해볼 수 있습니다.

코드 1-1과 같은 로직에서는 클라이언트 쪽에서 request를 전송할 때 마다 JWT를 검증하고, SecurityContext에 Authentication 객체를 매 번 저장할 텐데 SecurityContext에 Authentication 객체가 매번 저장되어서 쌓여있거나(물론 그런일은 없겠지만), Authentication 객체가 SecurityContext에 남아 있는건 아닐까?

다행히 Spring Security에서는 적절한 시점에 SecurityContext를 사용할 수 없도록 Authentication 객체가 저장되어 있는 SecurityContext 자체를 삭제합니다.

그 적절한 시점은 언제일까요?

클라이언트의 요청을 모두 처리하고 응답을 리턴하는 어느 시점에 더이상 Authentication 객체가 필요 없어질텐데요.

더이상 필요없어진 SecurityContext를 삭제하는 역할을 하는 것이 바로 SecurityContextPersistenceFilter입니다.

SecurityContextPersistenceFilter는 SecurityContext를 저장, 로드, 삭제하는 등의 역할을 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

public class SecurityContextPersistenceFilter extends GenericFilterBean {
    ...
    ...
 
    public SecurityContextPersistenceFilter() {
        this(new HttpSessionSecurityContextRepository());
    }
 
    public SecurityContextPersistenceFilter(SecurityContextRepository repo) {
        this.repo = repo;
    }
 
    ...
    ...
 
    private void doFilter(HttpServletRequest request, 
                          HttpServletResponse response, 
                          FilterChain chain)
            throws IOException, ServletException {
        ...
        ...
        
        HttpRequestResponseHolder holder = new HttpRequestResponseHolder(request, response);
        
        // (1)
        SecurityContext contextBeforeChainExecution = this.repo.loadContext(holder);
        try {
            SecurityContextHolder.setContext(contextBeforeChainExecution);
            if (contextBeforeChainExecution.getAuthentication() == null) {
                logger.debug("Set SecurityContextHolder to empty SecurityContext");
            }
            else {
                if (this.logger.isDebugEnabled()) {
                    this.logger
                            .debug(LogMessage.format("Set SecurityContextHolder to %s", contextBeforeChainExecution));
                }
            }
            chain.doFilter(holder.getRequest(), holder.getResponse());
        }
        finally {
            SecurityContext contextAfterChainExecution = SecurityContextHolder.getContext();
            
            // (2)
            SecurityContextHolder.clearContext();
            
            // (3)
            this.repo.saveContext(contextAfterChainExecution, holder.getRequest(), holder.getResponse());
            request.removeAttribute(FILTER_APPLIED);
            this.logger.debug("Cleared SecurityContextHolder to complete request");
        }
    }
 
    public void setForceEagerSessionCreation(boolean forceEagerSessionCreation) {
        this.forceEagerSessionCreation = forceEagerSessionCreation;
    }
 
}

코드 1-2 SecurityContextPersistenceFilter 코드 일부 

cs

코드 1-2는 SecurityContextPersistenceFilter의 코드 일부입니다.

먼저 JWT가 request header 등에 포함되어 전송되었다고 가정하면 SecurityFilterChain의 Filter 중 하나인 SecurityContextPersistenceFilter에 request가 전달 되었을 때,

(1)과 같이 SecurityContextRepository에서 기존에 저장되어 있는 SecurityContext를 로드하는데 JWT를 이용하는 방식에서는 이 SecurityContext 객체 안에 Authenticaion 객체가 저장되어 있지 않습니다.

이유는 JWT 인증 방식은 Stateless 즉, HttpSession에서 인증된 Authentication을 포함한 SecurityContext를 관리하지 않기 때문인데요.

HttpSession을 사용하지 않는 이유는 아래에서 다시 설명하겠습니다.

어쨌든 SecurityFiterChain의 실행이 끝난 시점 즉, 클라이언트의 요청이 Controller를 거쳐서 처리를 다 끝낸 후에 메서드 실행 흐름이 SecurityContextPersistenceFilter로 넘어오게 되면 (2)와 같이 SecurityContext를 비우게 됩니다.

물론 (3)에서 SecurityFilterChain 실행 후에 생성된 contextAfterChainExecution(clear하기 직 전에 인증된 Authentication 객체가 저장되어 있는 SecurityContext)이 SecurityContextRepository에 저장되긴 하는데, 여기서 저장되는 contextAfterChainExecution는 Spring Security가 Session 인증 방식으로 동작할 경우에는 HttpSession에 contextAfterChainExecution을 저장하고, JWT 인증 방식으로 동작할 경우에는 HttpSession에 저장하는 것이 아니라 단순히 this.repo.saveContext(...)와 같이 메서드 호출만 할 뿐이지 내부적으로는 아무 동작도 하지 않습니다.

이렇게 SecurityContextRepository가 saveContext(...)를 호출하지만 아무런 동작도 하지 않는 이유는 JWT 인증 방식을 사용하기 위해 SecurityConfiguration에서 아래와 같은 설정을 추가하기 때문입니다.

.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)

SessionCreationPolicy.STATELESS는 HttpSession을 사용하지 않겠다는 의미인데, 이 경우 코드 1-2의 (3)에서 사용하는 SecurityContextRepository의 구현 클래스는 HttpSessionSecurityContextRepository가 아니라 NullSecurityContextRepository가 됩니다. NullSecurityContextRepository의 saveContext(...)는 아래와 같습니다.

public final class NullSecurityContextRepository implements SecurityContextRepository {
	...
    ...
    
	@Override
	public void saveContext(SecurityContext context, 
    						HttpServletRequest request, 
                            HttpServletResponse response) {
	}

}

코드를 보면, NullSecurityContextRepository의 saveContext(...)에는 아무런 로직이 없이 그냥 비어있습니다.

SecurityContext를 clear 한다는 의미는 무엇일까?

마지막으로 한 가지만 더 이야기 하고 이번 글을 마치도록 하겠습니다.

우리가 코드 1-2의 (2)에서 SecurityContextHolder.clearContext();를 통해 SecurityContext를 비운다(clear)라고 했습니다.

여기서 clear의 의미는 정확하게 무엇일까요?

SecurityContext를 관리하는 관리 주체는 SecurityContextHolder인데, SecurityContextHolder는 SecurityContext를 어떻게 관리할지에 대한 몇 가지 전략(SecurityContextHolderStrategy)을 취할 수 있습니다.

시스템 프로퍼티에 별도의 전략을 설정하지 않을 경우, 디폴트 전략은 ThreadLocalSecurityContextHolderStrategy입니다.

즉, SecurityContext를 ThreadLocal 변수에 저장해서 관리하겠다라는 전략입니다.

이 말은 clearContext()를 호출하면 현재 실행 중인 Thread에서 사용하는 ThreadLocal 변수에 저장된 데이터 즉, SecurityContext 객체를 지우겠다라는 의미입니다.

실제로 ThreadLocalSecurityContextHolderStrategy의 코드를 보면 아래와 같이 구성되어 있습니다.

final class ThreadLocalSecurityContextHolderStrategy implements SecurityContextHolderStrategy {

   // (1) SecurityContext를 ThreadLocal 변수에서 관리한다.
   private static final ThreadLocal<SecurityContext> contextHolder = new ThreadLocal<>();

   @Override
   public void clearContext() {
      contextHolder.remove();
   }

   @Override
   public SecurityContext getContext() {
      SecurityContext ctx = contextHolder.get();
      if (ctx == null) {
         ctx = createEmptyContext();
         contextHolder.set(ctx);
      }
      return ctx;
   }

   @Override
   public void setContext(SecurityContext context) {
      Assert.notNull(context, "Only non-null SecurityContext instances are permitted");
      contextHolder.set(context);
   }

   @Override
   public SecurityContext createEmptyContext() {
      return new SecurityContextImpl();
   }

}

코드를 보면 (1)과 같이 ThreadLocal<SecurityContext> 필드 변수를 포함하고 있으며, setContext(SecurityContext context)로 SecurityContext를 ThreadLocal 변수에 저장하고, getContext()로 ThreadLocal 변수에 저장된 SecurityContext를 가지고 옵니다.

그리고 clearContext()로 ThreadLocal 변수에 저장되어 있는 SecurityContext를 제거하고 있습니다.

SecurityContextPersistenceFilter의 역할

추가로 SecurityContextPersistenceFilter의 역할에 대해서 아래와 같이 간단하게 정리하고 글을 마무리 하도록 하겠습니다.

✔️ SecurityFilterChain이 시작하는 시점에.

세션 기반 자격 증명일 경우,

HTTP Session에서 SecurityContext를 로드(load)한다.
로드한 SecurityContext를 SecurityContextHolder에 저장한다(hold)

토큰 기반(JWT 등) 자격 증명일 경우,

비어있는 SecurityContext를 로드(load)한다. 즉, 아무일도 하지 않음.
로드한 비어 있는 SecurityContext를 SecurityContextHolder에 저장한다(hold)
⭐⭐ 비어 있으므로 누군가가 채워줘야 한다. ⭐⭐

✔️ SecurityFilterChain이 끝나는 시점에.

세션 기반 자격 증명일 경우

SecurityContextHolder에 저장된 SecurityContext를 제거(clear)한다.
SecurityContext를 HTTP Session에 저장한다.

토큰 기반(JWT 등) 자격 증명일 경우,

SecurityContextHolder에 저장된 SecurityContext를 제거(clear)한다.

참고로 SecurityContextPersistenceFilter는 Spring Security 5.7 이후로 Deprecated 되었으며, 5.7 버전 이후로는 SecurityContextPersistenceFilter 대신에 SecurityContextHolderFilter를 사용하기를 권장하고 있습니다.

이 글이 SecurityContext를 이해하는데 도움이 되셨길 바랍니다.

Spring Security에서의 권한 부여 (Authorization) 처리 흐름

Kevin's IT Village — Tue, 17 Jan 2023 22:59:26 +0900

Spring Security의 권한 부여 처리 흐름

Spring Security Filter Chain에서 URL을 통해 사용자의 액세스를 제한하는 권한 부여 Filter는 바로 AuthorizationFilter 이다.
- SecurityContextHolder로 부터 Authentication을 획득
SecurityContextHolder로 부터 획득한Authentication과 HttpServletRequest를 AuthorizationManager에게 전달
AuthorizationManager는 권한 부여 처리를 총괄하는 매니저 역할을 한다.
RequestMatcherDelegatingAuthorizationManager는 AuthorizationManager를 구현하는 구현체 중 하나이다.
- RequestMatcherDelegatingAuthorizationManager는 RequestMatcher 평가식을 기반으로 해당 평가식에 매치되는 AuthorizationManager에게 권한 부여 처리를 위임하는 역할
- ⭐ RequestMatcherDelegatingAuthorizationManager가 직접 권한 부여 처리를 하는 것이 아니라 RequestMatcher를 통해 매치되는 AuthorizationManager 구현 클래스에게 위임
- RequestMatcherDelegatingAuthorizationManager 내부에서 매치되는 AuthorizationManager 구현 클래스가 있다면 해당 AuthorizationManager 구현 클래스가 사용자의 권한을 체크
적절한 권한이 아니라면 (5)와 같이 AccessDeniedException이 throw되고 ExceptionTranslationFilter가 AccessDeniedException을 처리

Spring Security에서의 인증(Authentication) 처리 흐름

Kevin's IT Village — Tue, 17 Jan 2023 22:54:15 +0900

Spring Security 인증 컴포넌트의 인터랙션 과정

UsernamePasswordAuthenticationFilter 는 Username/Password 기반의 인증 요청을 처리한다.
- UsernamePasswordAuthenticationToken 생성
  - 아직 인증되지 않은 Authentication 객체
AuthenticationManager는 인증 처리를 총괄하는 매니저 역할을 하는 인터페이스.
ProviderManager는 AuthenticationManager를 구현한 구현 클래스
UserDetails는 사용자의 자격을 증명해주는 크리덴셜(Credentials) 과 권한 정보를 가지고 있는 객체.
UserDetailsService가 사용자의 Credential과 권한 정보를 조회해서 UserDetails 를 생성.
UserDetailsService가 AuthenticationProvider에게 UserDetails 를 전달.
AuthenticationProvider는 전달 받은 UserDetails에서 패스워드가 일치하는지 검증.
AuthenticationProvider가 패스워드 검증에 성공하면 인증에 성공한 사용자의 정보(Principal, Credential, GrantedAuthorities)를 포함한 Authentication을 생성.
인증된 Authentication을 전달 받은 UsernamePasswordAuthenticationFilter는 SecurityContextHolder를 이용해 SecurityContext에 인증된 Authentication을 저장.
SecurityContext는 다시 HttpSession에 저장되어 사용자의 인증 상태를 유지.

Spring Security의 인증 컴포넌트

1️⃣ UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter

Username/Password 방식의 인증 처리의 시작점

2️⃣ UsernamePasswordAuthenticationToken

사용자의 인증 처리가 되기 전에는 인증되지 않은 Authentication.
- Username과 Password 정보를 포함하고 있다.
사용자의 인증 처리가 된 이후에는 인증된 Authentication
- Principal, Authorities를 포함하고 있다.
- Credentials 정보는 민감한 정보이므로 인증 이 후에는 제거된다.

3️⃣ AuthenticationManager

인증 처리를 지시하는 매니저 역할을 한다.
인증 매니저 계의 총 지배인

4️⃣ ProviderManager

AuthenticationManager의 구현 클래스
인증 매니저 계의 지배인
인증이 성공적으로 이루어진 후, Crendentials를 제거한다.
- 인증 끝났으니까 민감한 정보는 가지고 있을 필요가 없음.

5️⃣ AuthenticationProvider

인증된 사용자인지를 판단하는 역할
인증 매니저의 지시를 받는 현장 담당자 역할

6️⃣ UserDetails

크리덴셜 저장소에 저장된 크리덴셜 정보를 가지고 있는 객체
AuthenticationProvider는 UserDetailsService로부터 UserDetails를 전달 받는다.

7️⃣ UserDetailsService

UserDetails 객체를 생성해서 AuthenticationProvider에게 제공하는 역할을 한다.

8️⃣ SecurityContext와 SecurityContextHolder

인증된 Authentication 정보를 저장하는 저장 객체
SecurityContext는 인증 성공 이 후, HTTP Session에 저장된다.
HTTP Session은 최종적으로 StandardManager의 상위 클래스인 ManagerBase에서 관리된다.
⭐ HTTP Session에 누가 저장 할까?
- 최초 인증에 성공할 경우에는 UsernamePasswordAuthenticationFilter에서 HttpSessionSecurityContextRepository를 이용해 HTTP Session에 저장한다.
- 인증 이 후에 재요청 시에는 SecurityContextPersistenceFilter가 저장한다.
  - 인증 이 후 재요청 시의 프로세스는 대략 아래와 같다.
    - HTTP 요청
    - --> SecurityContextPersistenceFilter가 HTTP Session에서 SecurityContext를 꺼낸 후, SecurityContextHolder에 저장
    - -> 이 후, 요청이 끝나는 시점에 SecurityContextPersistenceFilter의 finally 블럭에서
      - SecurityContextHolder에 저장된 SecurityContext를 지운 뒤,
      - --> HttpSessionSecurityContextRepository를 이용해 HTTP Session에 SecurityContext를 다시 저장한다.

SecurityContext의 구조

그림과 코드로 알아보는 Spring MVC 요청 처리 흐름

Kevin's IT Village — Mon, 16 Jan 2023 23:07:04 +0900

우리가 흔히 알고 있는 Spring MVC의 요청 처리 흐름 한 가운데에는 DispatcherServlet이 자리잡고 있습니다.

클라이언트로부터 들어오는 HTTP request는 Servlet Filter를 거쳐 DispatcherServlet에 전달되고, DispatcherServlet은 해당 request를 처리할 Controller를 검색하고 대상 Controller에게 request를 전달하기 위해 HandlerMapping과 HandlerAdapter 등의 컴포넌트를 이용합니다.

대부분 다 알고 있는 내용이기 때문에 자세한 설명은 필요없을 것 같습니다.

다만, 구글링을 통해 그림으로 표현한 Spring MVC의 요청 처리 흐름에 대한 자료는 많이 볼 수 있지만 코드 베이스의 자료는 생각보다 찾기 힘든 것 같아서 이 참에 코드 베이스의 흐름을 정리해 볼까 합니다.

SSR(Server Side Rendering) 방식의 코드 흐름

SSR(Server Side Rendering) 방식은 CSR(Client Side Rendering) 방식의 애플리케이션이 본격적으로 사용되기 이 전부터 사용되던 전통적인 방식으로 아파치 톰캣(Apache Tomcat) 같은 서블릿 컨테이너가 Thymeleaf 등의 템플릿 기술을 이용해 HTML 템플릿을 렌더링 한 후에 클라이언트 쪽으로 내려주는 방식입니다.

[그림 1-1] SSR 방식의 Spring MVC 요청 처리 흐름

[그림 1-1]은 우리가 흔히들 알고 있는 Spring MVC의 요청 처리 흐름 중에서 SSR(Server Side Rendering) 방식의 요청 처리 흐름입니다.

SSR 방식의 요청 처리 흐름의 특징은 ViewResolver가 적절한 뷰 정보를 해석한 후에 대상 View 객체에게 응답 데이터를 전달하고 View를 통해 이 응답 데이터를 HTML 같은 템플릿에 채워 넣어서 최종적으로 클라이언트에게 전송한다는 것입니다.

따라서 [그림 1-1]에 있는 Spring MVC 컴포넌트들을 모두 사용합니다.

SSR 방식의 요청 처리 흐름을 코드로 표현하면 다음과 같은 순서로 호출이 됩니다.

DispatcherServlet
1. doDispatch(HttpServletRequest request, HttpServletResponse response)
2. getHandler(HttpServletRequest request) // HandlerMapping을 통해 HandlerChain을 얻는다.
3. HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
4. mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
5. processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
6. render(mv, request, response);
7. View view = resolveViewName(viewName, mv.getModelInternal(), locale, request); // ViewResolver가 View를 해석해 적절한 View 객체를 얻는다.
8. view.render(mv.getModelInternal(), request, response); // View를 렌더링한다.
ThymeleafView (Thymeleaf 템플릿 기술을 사용할 경우)
1. render(final Map<String, ?> model, final HttpServletRequest request, final HttpServletResponse response)
2. renderFragment(this.markupSelectors, model, request, response);
3. String viewTemplateName = getTemplateName();
4. ISpringTemplateEngine viewTemplateEngine = getTemplateEngine();
5. viewTemplateEngine.process(templateName, processMarkupSelectors, context, templateWriter);
TemplateEngine
1. process(new TemplateSpec(template, templateSelectors, null, null,null), context, writer);
2. TemplateManager templateManager = this.configuration.getTemplateManager();
3. templateManager.parseAndProcess(templateSpec, context, writer);
TemplateManager
1. TemplateModel cached = this.templateCache.get(cacheKey);
2. cached.process(processingHandlerChain);
TemplateEngine
1. writer.flush();

코드의 흐름을 보면 꽤 복잡한 흐름을 거치고 실제 내부 코드들은 더 복잡하지만 어쨌든 각각의 컴포넌트들이 각자 맡은바 역할에만 집중하고 있는 것을 볼 수 있습니다.

View를 렌더링하는 과정은 일반적으로 Thymeleaf 기술을 사용하고 있다고 가정했을 때, View 인터페이스의 구현 클래스인 ThymeleafView가 TemplateEngine과 TemplateManager를 이용해 클라이언트에게 전송할 HTML에 응답 데이터를 채워 넣은 후, 최종 템플릿을 만듭니다.

그리고 마지막은 Writer가 write한 템플릿 데이터를 flush 해서 클라이언트에게 전달합니다.

템플릿 데이터는 TemplateEngine과 TemplateManager 어딘가에서 write 된다라고 생각하면 될 것 같습니다. ^^;

CSR(Client Side Rendering) 방식의 코드 흐름

CSR(Client Side Rendering) 방식은 SSR 방식처럼 HTML 템플릿을 렌더링 해서 클라이언트 쪽으로 내려주는것이 아니라 Controller가 리턴한 데이터를 주로 JSON 형태로 HTTP response body에 실어서 응답 데이터만 클라이언트 쪽에 전달해주는 방식입니다.

여기서 말하는 클라이언트는 Apache나 Nginx 같은 웹서버에서 실행되는 Frontend 측 웹 앱이 될 수도 있고, 스마트 폰에서 실행되는 네이티브 앱이 될 수도 있으며, 데스크탑에서 실행되는 데스크탑 애플리케이션이 될 수도 있습니다.

[그림 1-2] CSR 방식의 Spring MVC 요청 처리 흐름

[그림 1-2]은 Spring MVC의 요청 처리 흐름 중에서 CSR(Client Side Rendering) 방식의 요청 처리 흐름입니다.

그림에서 보다시피 View 자체가 필요 없기 때문에 ViewResolver와 View의 로직을 타지 않습니다.

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
			@Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
			@Nullable Exception exception) throws Exception {

		...
		...

		// HandlerAdapter가 리턴한 ModelAndView가 null이면 뷰를 렌더링하지 않는다.
		if (mv != null && !mv.wasCleared()) {
			render(mv, request, response); 
			if (errorView) {
				WebUtils.clearErrorRequestAttributes(request);
			}
		}
		else {
			if (logger.isTraceEnabled()) {
				logger.trace("No view rendering, null ModelAndView returned.");
			}
		}
		...
		...
}

위 코드는 DispatcherServlet의 processDispatchResult() 코드의 일부입니다.
코드를 보면 HandlerAdapter가 리턴 받은 ModelAndView 객체가 null이면 뷰를 렌더링하지 않는 것을 볼 수 있습니다.

즉, 이 말은 Controller에서 리턴한 객체가 ResponseEntity 같은 타입의 객체인 경우 내부적으로 ModelAndView 객체를 생성하지 않는다는 의미와도 같습니다.

CSR 방식의 요청 처리 흐름의 코드는 앞에서 살펴보았던 SSR 방식의 코드 흐름 중, DispatcherServlet의 processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException) 내부에서 render(mv, request, response)의 호출부터 이 후 나머지 과정의 처리를 생략하면 됩니다.

이 글을 통해 Spring MVC의 요청 처리 흐름을 조금 더 깊게 이해하는데 조금이라도 도움이 될 수 있길 바랍니다.

메시지 암호화에 대한 짧은 이야기

Kevin's IT Village — Mon, 16 Jan 2023 14:30:24 +0900

우리가 일반적으로 생각하는 대표적인 암호화의 대상은 크리덴셜(Credential)의 한 종류인 패스워드입니다. 패스워드는 암호화의 대상인 메시지를 조금 더 구체적으로 표현한 것이라고 볼 수 있을테구요.

이번 시간에는 암호화에 대한 아주 쉬운 이야기를 짧게 해보려고 합니다.

암호화란 무엇인지 암호화 유형에는 기본적으로 어떤것이 있는지 등을 아주 쉽게 이해할 수 있도록 짧게 정리해 보겠습니다.

암호화란?

사용자의 민감한 정보를 보호하기 위한 기술
Crypto 또는 Cipher라는 비슷한 용어가 있음
Ciphertext: 암호화 된 텍스트
Cryptography
- 암호학적 관점에서의 암호화 전체를 아우르는 말
Crypto Currency
- 암호 화폐
Encryption / Decryption
- 암호학 관점에서의 데이터 변환 과정
- Encryption
  - 암호화
- Decryption
  - 복호화
Encoding / Decoding
- 암호학 관점은 아님
- 데이터의 형식이나 패턴을 목적에 맞게 변환하는 과정
- 예)
  - Encoding
    - encode(원본 데이터) → Base64 형식의 문자열로 인코딩
  - Decoding
    - decode(Base64 형식으로 인코딩된 문자열) → 원본 데이터

암호화 대상의 기준

웹 애플리케이션의 아이디/패스워드 로그인을 생각해보면 암호화의 대상 기준은 무엇이 되어야하는가를 잘 알 수 있습니다.

패스워드는 민감한(Sensitive) 정보이므로 타인에게 평문(Plain Text) 형태로 유출이 되면 안될테니까요.

따라서 애플리케이션 구현시 외부에 유출되면 문제가 발생할 수 있는 정보들은 암호화의 대상이 될 수 있으며, 아래에서 나열한 항목들은 암호화를 진지하게 고려해 보아야 하는 대상이라고 볼 수 있습니다.

로그인 인증을 위한 패스워드
구글, AWS 등의 외부 서비스를 이용하기 위한 계정 정보 또는 Secret 정보
JWT를 생성하고 검증하는데 필요한 Secret 정보
데이터베이스 접속 정보
- 데이터베이스 접속 정보에서 root 계정을 사용하는 분들이 많은데 root 계정이 아닌 별도의 사용자 계정을 만들어서 사용하길 권장합니다.
- root는 말 그대로 최고 권한을 가진 계정이기 때문에 직접적으로 사용하지 않는 것이 좋습니다.

암/복호화 가능 여부에 따른 암호화 방식

양방향 암호화
- 암호화도 되고 복호화도 되는 암호화 방식
- 암호화 된 메시지를 상대방이 볼 수 있어야 하는 암호화 방식이며, 복호화가 되어야 정상적인 메시지를 확인할 수 있습니다.
단방향 암호화
- 암호화는 되지만 복호화는 되지 않는 암호화 방식
- 암호화된 메시지를 굳이 복호화 해서 확인할 필요가 없을 때 사용할 수 있는 암호화 방식입니다.
- 단방향 암호화를 적용하는 대표적인 항목이 로그인 패스워드입니다. 로그인 패스워드의 경우 사용자가 입력한 패스워드를 암호화 한 데이터와 이미 암호화 되어 저장되어 있는 데이터가 일치한지 여부만 판단하면 되기 때문에 복호화가 필요없습니다.
- 단방향 암호화는 일반적으로 해시 알고리즘을 사용하는데 엄밀하게 말하자면 해시 알고리즘 자체가 암호화라고 보기는 어렵지만 어쨌든 원본 메시지를 보호할 수 있다는 관점에서의 암호화라고 생각하면 좋을 것 같습니다.

키 유형에 따른 암호화 방식

대칭키 암호화 방식
- 하나의 키를 서로 공유해서 해당 키로 암호화/복호화를 수행
- 대칭키 암호화 방식은 하나의 키를 서로 공유해야 하기 때문에 공유된 키가 유출되면 심각한 문제가 발생할 수 있습니다.
비대칭키 암호화 방식
- 암호화를 수행하는 키와 복호화를 수행하는 키가 다릅니다.
- Public Key와 Private Key
- ⭐ Public Key로 암호화 하는 것은 민감한 데이터 또는 메시지 보호를 위해서.
- ⭐ Private Key로 암호화 하는 것은 디지털 서명(Digital Signature)을 위해서.
  - 블록체인에서 이 방식을 사용합니다.

Spring WebFlux + R2DBC 환경에서 H2 web console 사용하기

Kevin's IT Village — Mon, 16 Jan 2023 09:34:25 +0900

※ 이 글은 아끼는 저의 학생이 공유한 글을 기반으로 재편집한 글입니다.

기존의 Spring MVC 환경에서는 인메모리 DB인 h2의 web console을 이용하기 수월했었는데, Spring WebFlux + R2DBC 환경에서는 Spring MVC 환경에서 사용하던 방법 그대로 h2의 web console을 이용할 수 없기 때문에 별도의 설정을 해주어야 합니다.

Spring WebFlux + R2DBC 환경에서 h2 web console을 사용하기 위한 설정 방법은 다음과 같습니다.

Gradle 설정

== build.gradle ==

dependencies {
	...
	implementation 'io.r2dbc:r2dbc-h2'
}

build.gradle의 dependencies에 implementation 'io.r2dbc:r2dbc-h2'를 추가합니다.

application.yml 설정

spring:
  sql:
    init:
      schema-locations: classpath*:db/h2/schema.sql
      data-locations: classpath*:db/h2/data.sql
  r2dbc:         # (1)                                   
    url: r2dbc:h2:mem:///test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
    username: sa
    password:
h2:       # (2)
  console:
    port: 8090
logging:
  level:
    org:
      springframework:

(1)과 같이 R2DBC용 H2 Connection 정보를 설정합니다.
(2)와 같이 h2 콘솔 포트를 8090으로 설정합니다. 포트 번호는 편한 번호로 설정하면 됩니다.

h2 console 서버 설정

==== H2ServerConfig.java ====

@Slf4j
@Component
public class H2ServerConfig {
    @Value("${h2.console.port}")
    private Integer port;
    private Server webServer;

    @EventListener(ContextRefreshedEvent.class)
    public void start() throws java.sql.SQLException {
        log.info("started h2 console at port {}.", port);
        this.webServer = Server.createWebServer("-webPort", port.toString()).start();
    }

    @EventListener(ContextClosedEvent.class)
    public void stop() {
        log.info("stopped h2 console at port {}.", port); this.webServer.stop();
    }
}

application.yml에서 추가한 포트 번호를 H2 Server를 start 하기 전에 지정해 줍니다.

애플리케이션 실행

애플리케이션을 실행한 후, http://localhost:8090으로 접속해서 h2 web console로 접속이 잘 되는지 확인합니다.

HTTPS의 동작 원리와 CA의 역할을 그림으로..

Kevin's IT Village — Fri, 13 Jan 2023 22:34:33 +0900

HTTPS의 동작 원리와 CA를 그림으로 표현한다면 한마디로 아래와 같습니다.

HTTPS의 동작 원리

CA의 역할

No default constructor for entity 에러

Kevin's IT Village — Tue, 3 Jan 2023 00:14:47 +0900

Spring Data JPA에서 findById() 같은 API를 사용해 데이터를 조회할 때, No default constructor for entity 라는 에러가 발생하는 이유가 무엇인지 조금 더 디테일하게 분석해보았습니다.

Spring Data JPA에서는 개발자가 JpaRepository 등의 인터페이스를 상속하는 Repository 인터페이스를 구현하는 구현 클래스의 인스턴스를 생성하기 위해 내부적으로 Dynamic Proxy라는 기술과 Reflection을 이용하는데 RepositoryFactorySupport에서 해당 인스턴스(Repository의 Proxy)를 생성합니다.

그런데, 여기까지는 Spring에서 지원하는 Repository 인터페이스(개발자가 JpaRepository 같은 인터페이스를 상속한 Custom Repository)의 Proxy를 생성하는 역할을 할 뿐이고, 이 Proxy에서 타겟 클래스인 SimpleJpaRepository의 쿼리 메서드를 이용한 과정까지입니다.

제가 원한건 No default constructor for entity라는 에러가 발생하는 이유를 조금 더 디테일하게 알고 싶은것이었기 때문에 조금 더 분석을 해보았습니다.

분석 결과 Spring Data에서 제공하는 RepositoryComposition이 RepositoryMethodInvoker를 이용해 앞에서 얻은 Proxy의 타겟 클래스인 SimpleJpaRepository에 구현된 쿼리 메서드(findById() 같은)를 호출합니다.

그 다음부터는 Hibernate ORM의 영역입니다. Hibernate ORM에서 EntityManager의 역할을 하는 Session 인터페이스의 구현 클래스인 SessionImpl에서 데이터베이스에 접속해 데이터를 조회합니다.

SessionImpl로부터 데이터베이스에 데이터를 조회하는 복잡한 로직이 시작되고 결국 조회한 데이터를 개발자가 정의 Entity 클래스의 object로 변환하기 위해 아래와 같이 PojoInstantiator의 instantiate()에서 Reflection을 통해 얻은 Constructor 인스턴스로 newInstance()를 호출해 Entity 클래스의 object를 생성합니다.

/*
 * Hibernate, Relational Persistence for Idiomatic Java
 *
 * License: GNU Lesser General Public License (LGPL), version 2.1 or later.
 * See the lgpl.txt file in the root directory or <http://www.gnu.org/licenses/lgpl-2.1.html>.
 */
package org.hibernate.tuple;

import java.io.IOException;
import java.io.Serializable;
import java.lang.reflect.Constructor;

import org.hibernate.InstantiationException;
import org.hibernate.PropertyNotFoundException;
import org.hibernate.bytecode.spi.ReflectionOptimizer;
import org.hibernate.internal.CoreLogging;
import org.hibernate.internal.CoreMessageLogger;
import org.hibernate.internal.util.ReflectHelper;
import org.hibernate.mapping.Component;

/**
 * Defines a POJO-based instantiator for use from the tuplizers.
 */
public class PojoInstantiator implements Instantiator, Serializable {
	private static final CoreMessageLogger LOG = CoreLogging.messageLogger( PojoInstantiator.class.getName() );

	private transient Constructor constructor;

	private final Class mappedClass;
	private final transient ReflectionOptimizer.InstantiationOptimizer optimizer;
	private final boolean embeddedIdentifier;
	private final boolean isAbstract;
    ...
    ...
    
	public Object instantiate() {
		if ( isAbstract ) {
			throw new InstantiationException( "Cannot instantiate abstract class or interface: ", mappedClass );
		}
		else if ( optimizer != null ) {
			return optimizer.newInstance();
		}
		else if ( constructor == null ) {
			throw new InstantiationException( "No default constructor for entity: ", mappedClass );
		}
		else {
			try {
				return applyInterception( constructor.newInstance( (Object[]) null ) );
			}
			catch ( Exception e ) {
				throw new InstantiationException( "Could not instantiate entity: ", mappedClass, e );
			}
		}
	}
    
    ...
    ...
}

그런데, 코드를 보면 constructor가 null이라면 InstantiationException을 throw하도록 구현된 것을 볼 수 있습니다.
이유는 Java의 Reflection에서 object를 생성하기 위해서는 파라미터가 없는 디폴트 생성자(default constructor)가 필요하기 때문입니다.

이러한 이유때문에 Spring Data JPA에서 사용되는 Entity 클래스에는 디폴트 생성자가 반드시 있어야한다는 사실을 기억하면 좋을 것 같습니다.

Java의 클래스에 파라미터를 가지는 별도의 생성자를 추가하지 않으면 내부적으로 디폴트 생성자가 있다고 가정하지만 오버로딩된 생성자가 추가되는 순간 디폴트 생성자는 개발자가 직접 지정을 해야한다는 사실은 잘 알고 있을거라 생각합니다.

그리고 lombok에서 지원하는 @Builder 패턴 등을 사용할 경우에는 항상 디폴트 생성자를 기본으로 가질 수 있도록 해야한다는 사실을 기억하면 좋을 것 같습니다.

NIO의 구성요소와 동작 방식

Kevin's IT Village — Tue, 6 Dec 2022 23:11:21 +0900

NIO의 구성 요소

Channel

네트워크 소켓에 대한 채널을 의미하며 NetworkChannel 인터페이스로 정의된다. NetworkChannel 인터페이스의 구현 클래스로는 ServerSocketChannel, SocketChannel, DatagramChannel 등이 있다.

※ 소켓이란?

서버 프로그램과 클라이언트 프로그램의 양방향 통신을 위한 양방향 소프트웨어 엔드포인트이다. 엔드포인트는 IP 주소와 포트 번호로 구성된다.

Java의 스트림은 read/write 둘 중 하나만 수행할 수 있는 단방향이지만 Channel은 read/write 모두 수행할 수 있는 양방향 입출력 클래스이다.

ServerSocketChannel
- ServerSocketChannel은 클라이언트의 연결 요청이 들어오면 [open] - [bind] - [accept] 단계를 거친 후, SocketChannel을 생성한다.
SocketChannel
- 클라이언트가 전달한 데이터를 read하고, 클라이언트에게 데이터를 write하기 위한 채널이다.
- ServerSocketChannel이 클라이언트의 연결을 accept하면 SocketChannel이 생성된다.

Selector

Selector는 채널에 I/O 이벤트가 있는지 없는지를 알려주는 일종의 이벤트 리스너(Event Listener)의 역할을 한다.
ServerSocketChannel과 SocketChannel은 register() 메서드를 통해 Selector로 등록된다.
Selector에 등록된 채널은 I/O 이벤트 발생 시, 이벤트 리스닝의 대상이 된다.
즉, Selector.select()를 호출하면 I/O 이벤트가 있는 채널 set을 리턴한다.

SelectionKey

SelectionKey는 Selector에 등록된 채널이 어떤 I/O 이벤트를 처리할지를 지정하는 객체이다.
SelectionKey 유형
- SelectionKey.OP_ACCEPT
- SelectionKey.OP_CONNECT
- SelectionKey.OP_READ
- SelectionKey.OP_WRITE
SelectionKey는 채널의 register()를 호출하면 리턴된다.
SelectionKey.attach()를 통해 SelectionKey 유형의 이벤트를 처리할 이벤트 핸들러를 등록할 수 있다.
SelectionKey의 유형은 SelectionKey.interestOps()로 지정할 수 있다.

ByteBuffer

데이터를 read/write 할 수 있는 버퍼로 Java의 NIO에서 사용된다.
byte buffer가 사용하는 메모리의 위치에 따라서 non-direct buffer와 direct buffer로 나눌 수 있다.
non-direct buffer는 우리가 흔히 알고 있는 JVM의 heap memory를 사용하지만 direct buffer는 OS(Operatoion System)의 memory를 사용한다.

Charset

character(문자)를 byte로 인코딩하거나 byte를 charter(문자)로 디코딩할 때 사용하는 클래스이다.

NIO의 동작 방식

ServerSocketChannel의 바인딩 흐름

ServerSocketChannel과 Selector의 생성
- 애플리케이션이 실행되면 ServerSocketChannel.open()을 통해 ServerSocketChannel을 생성한다.
- 애플리케이션이 실행되면 Selector.open()을 통해 Selector를 생성한다. 생성된 Selector는 ServerSocketChannel 또는 SocketChannel 등을 Selector에 등록하는데 사용된다.
ServerSocketChannel.bind()를 통해 ServerSocketChannel을 바인딩한다.
- 여기서의 바인딩은 IP 주소와 로컬 포트 번호를 서버 소켓과 연결함을 의미한다.
ServerSocketChannel.register()를 통해서 Selector에 ServerSocketChannel을 등록한다.
- SelectionKey.OP_ACCEPT를 지정함으로써 클라이언트의 connect 요청 이벤트가 발생하면 클라이언트의 connect 요청을 수락하기 위한 로직을 처리할 수 있다.

ServerSocketChannel과 Selector를 통한 SocketChannel 연결 흐름

Client와 SocketChannel 연결 흐름

애플리케이션이 실행되고, ServerSocketChannel이 바인딩 된 이후에 Selector는 무한 루프 상태에서 SelectionKey 유형에 해당하는 I/O 이벤트를 처리하기 위해 대기 모드를 유지한다.
Selector.select()를 통해 발생하는 이벤트를 기다린다.
- 이벤트가 발생하는지에 대한 일종의 이벤트 리스닝이라고 볼 수 있다.
Selector.selectedKeys()를 통해 이벤트가 발생된 key를 의미하는 SelectionKey set을 얻는다.
- 여기서는 클라이언트의 connect 요청 흐름에 대해서만 설명하므로 SelectionKey.OP_ACCEPT에 해당하는 이벤트만 처리한다.
SelectionKey.channel()을 통해 ServerSocketChannel을 얻는다.
ServerSocketChannel.accept()을 통해 클라이언트의 connect 요청을 기다리고, 클라이언트의 connect 요청이 들어오면 SocketChannel을 생성한다.
- ServerSocketChannel에서 사용하는 포트 번호는 클라이언트의 연결 요청을 수락하기 위해서 계속해서 사용되어야 하므로 SocketChannel은 별도의 새 로컬 포트 번호를 할당 받아서 바인딩된다.

Client와 SocketChannel의 데이터 read/write 흐름

Client와 SocketChannel이 바인딩 되면 Selector.select()를 통해 I/O 이벤트가 발생할 때까지 대기한다.
I/O 이벤트가 발생하면 Selector.selectedKeys()를 이벤트가 발생한 SelectioinKey set을 얻는다.
SelectionKey.channel()을 통해 이벤트가 발생한 SocketChannel을 얻을 수 있으며, 이 SocketChannel은 해당 이벤트를 처리할 이벤트 핸들러에게 전달된다.
SelectionKey.attachment()를 통해 이벤트를 처리할 이벤트 핸들러를 얻을 수 있으며, 이벤트 핸들러가 SocketChannel을 이용해 이벤트를 처리한다.

Mac OS에서 시스템 환경 변수 등록하는 방법

Kevin's IT Village — Thu, 24 Nov 2022 17:47:05 +0900

Mac OS의 기본 셸 확인하기

Mac OS Catalina 이 전 버전까지는 기본 셸이 Bash shell(bash)이었으나, Catalina부터 Z shell(zsh)이 기본 셸로 변경되었습니다.
따라서 Mac OS에서 시스템 환경 변수를 등록하기 위해서는 현재 사용하고 있는 Mac OS의 기본 셸이 무엇인지부터 확인을 해야 합니다.

Mac OS에서 기본 셸은 아래의 터미널 명령으로 손쉽게 확인할 수 있습니다.

kevin@hwang ~ % echo $SHELL
/bin/zsh
or
/bin/bash

Z shell에서 시스템 환경 변수 등록 방법

Z shell의 경우 다음과 같은 절차를 따릅니다.

아래와 같이 vi 편집기로 .zshrc 파일을 생성 또는 오픈합니다.

kevin@hwang ~ % vi ~/.zshrc

.zshrc 파일에 아래와 같이 등록하고자 하는 환경 변수명과 값을 입력합니다.

export JWT_SECRET_KEY=kevin111111111111111111111111111111111111111111

아래와 같이 source 명령어를 이용해 환경 변수를 등록합니다.

kevin@hwang ~ % source ~/.zshrc

Bash shell에서 시스템 환경 변수 등록 방법

Bash shell의 경우 다음과 같은 절차를 따릅니다.

아래와 같이 vi 편집기로 .bashrc 파일을 생성 또는 오픈합니다.

kevin@hwang ~ % vi ~/.bashrc

.bashrc 파일에 아래와 같이 등록하고자 하는 환경 변수명과 값을 입력합니다.

export JWT_SECRET_KEY=kevin111111111111111111111111111111111111111111

아래와 같이 source 명령어를 이용해 환경 변수를 등록합니다.

kevin@hwang ~ % source ~/.bashrc

터미널 사용이 익숙하지 않을 경우 방법

만약 터미널을 사용해서 Shell을 편집하는 것이 익숙하지 않다면 아래와 같은 방법으로 시스템 환경 변수를 등록할 수 있습니다.

⌘⇧. (Command + Shfit + . )을 눌러 숨김 파일을 표시합니다.
아래와 같이 사용자 계정의 디렉토리에서 .zprofile을 찾아 더블 클릭한 후 파일을 엽니다.

아래와 같이 등록하고자 하는 환경 변수명과 값을 입력한 후, 창을 닫습니다.

열려진 터미널과 IntelliJ IDE가 있다면 창을 닫고 다시 시작합니다.

아래와 같이 터미널과 IntelliJ IDE를 다시 오픈해서 환경 변수가 잘 등록 되었는지 확인합니다.

★ 시스템 환경 변수를 Spring Boot 애플리케이션에서 정상적으로 로드하기 위해서는 IntelliJ 같은 IDE를 반드시 Restart 하도록합니다.

HttpMessageConverter에 대한 이야기

Kevin's IT Village — Fri, 6 May 2022 19:02:29 +0900

HttpMessageConverter란?

웹 브라우저 같은 클라이언트에서 보여지는 HTML 컨텐츠가 렌더링(Rendering)되는 방식은 크게 두 가지입니다.

하나는 웹 애플리케이션 서버에서 동적으로 변하는 데이터를 포함하는 HTML을 만들어서 HTML 자체를 한번에 클라이언트 쪽으로 내려주는 방식입니다.
이 방식은 JSP나 타임리프(Thymeleaf) 같은 기술을 사용해서 HTML을 템플릿화 한 다음에 Controller의 핸들러 메서드에서 리턴하는 모델 데이터를 템플릿에 동적으로 채워 넣은 후, 최종적으로 완성된 HTML을 클라이언트 쪽으로 내려주는 방식입니다. 이 방식을 바로 서버 사이드 렌더링(Server Side Rendering)이라고 합니다.

또 하나는 클라이언트 쪽을 담당하는 Apache나 NginX 같은 웹 서버에 HTML을 올려 놓은 후, 자바스크립트의 Ajax 기술을 이용해서 웹 애플리케이션 서버에 데이터를 요청 합니다.
그리고 응답으로 전달받은 데이터를 웹 서버에 올려둔 HTML에 동적으로 채워 넣은 후, 최종적으로 완성된 HTML을 클라이언트 쪽으로 내려주는 방식입니다. 이 방식을 바로 클라이언트 사이드 렌더링(Client Side Rendering)이라고 합니다.

위 두가지 방식 중에서 HttpMessageConverter는 두 번째 방식인 클라이언트 사이드 렌더링과 관련이 있습니다.
즉, 클라이언트 사이드 렌더링을 위해 필요한 데이터를 특정 형식으로 변환해 주는 것이 바로 HttpMessageConverter입니다.

HttpMessageConverter의 사용 목적

HttpMessageConverter는 크게 두 가지 목적으로 사용됩니다.

하나는 웹 서버에서 전송된 Reqeust Body를 DTO 같은 클래스의 객체로 변환해서 웹 애플리케이션 서버 쪽에서 사용할 수 있도록 해주는 것이고,

다른 하나는 웹 서버 쪽으로 전달할 응답 데이터를 Response Body로 변환해주는 것입니다.

HttpMessageConverter의 동작 과정

[그림 1-1] Spring MVC 요청/응답 동작 과정

[그림 1-1]은 클라이언트의 요청을 처리하는 Spring MVC의 기본 동작 과정입니다.
이 Spring MVC의 동작 과정에서 HandlerAdapter의 동작 과정을 조금 더 구체적으로 설명하겠습니다.

요청 처리 시 HandlerAdapter의 동작 과정

HandlerMapping을 통해 적절한 HandlerAdapter를 찾으면 HandlerAdapter는 Controller로 넘겨줄 파라미터를 결정하기 위해 이 작업을 HandlerMethodArgumentResolver에게 위임합니다.
HandlerMethodArgumentResolver는 HttpMessageConverter에게 HTTP Request Body를 특정 타입의 객체로 변환해주기를 요청합니다.
HttpMessageConverter는 HTTP Request Body를 특정 타입의 객체로 변환합니다.
HandlerMethodArgumentResolver는 변환된 데이터를 전달 받아서 이 데이터를 다시 HandlerAdapter에게 전달합니다.
HandlerAdapter는 HandlerMethodArgumentResolver로부터 전달 받은 데이터를 핸들러 메서드의 파라미터로 포함 시킨 후, 핸들러 메서드를 호출합니다.

응답 처리 시 HandlerAdapter의 동작 과정

핸들러 메서드가 응답으로 전달할 데이터를 리턴합니다.
HandlerMethodReturnValueHandler는 핸들러 메서드로부터 전달 받은 응답 데이터를 HttpMessageConverter에게 전달합니다.
HttpMessageConverter는 HandlerMethodReturnValueHandler로부터 전달 받은 데이터를 HTTP Response Body에 포함되는 형식의 데이터로 변환합니다.
HandlerMethodReturnValueHandler는 HttpMessageConverter로부터 전달 받은 데이터를 HandlerAdapter에게 전달합니다.

REST API에서의 HttpMessageConverter

Spring MVC에서는 기본적으로 아래의 HttpMessageConverter 구현체가 활성화 되어 있습니다.

ByteArrayHttpMessageConverter
StringHttpMessageConverter
ResourceHttpMessageConverter
SourceHttpMessageConverter
FormHttpMessageConverter
Jaxb2RootElementHttpMessageConverter
MappingJackson2HttpMessageConverter
MappingJacksonHttpMessageConverter
AtomFeedHttpMessageConverter
RssChannelHttpMessageConverter

만약 우리가 HTTP Request 또는 Response를 위한 통신 프로토콜로 JSON을 사용하는 REST API Controller를 구현했다고 가정해 봅시다.

특정 Controller의 핸들러 메서드 파라미터에 @RequestBody 애너테이션이 추가되거나 파라미터의 타입이 HttpEntity라면 위에서 나열한 HttpMessageConverter가 순서대로 HTTP Request Body를 체크해서 핸들러 파라미터에 지정한 클래스로 변환이 되는지, HTTP Message의 Content Type을 지원하는지 여부를 확인하게 됩니다.

이 두가지 조건을 모두 만족한다면 아마도 MappingJackson2HttpMessageConverter가 Request Body를 해당 클래스의 객체로 변환할 것이고, 조건에 부합하는 HttpMessageConverter가 존재하지 않는다면 예외가 발생할 것입니다.

이제 응답 데이터를 JSON 형식으로 전달하는 상황을 생각해 봅시다.
핸들러 메서드에 @ResponseBody 애너테이션을 추가하거나 핸들러 메서드의 리턴 타입이 HttpEntity라면 역시 위에서 나열한 HttpMessageConverter가 순서대로 핸들러 메서드의 리턴 값을 체크해서 해당 클래스 타입을 지원하는지, Accept Header에 명시된 MediaType으로 변환이 되는지 여부를 확인하게 됩니다.

HttpMessageConverter가 동작하는 시점

HttpMessageConverter가 동작하는 시점은 JSON을 DTO로 deserialization 할 때와 DTO를 JSON으로 serialization 할 때가 다릅니다. 아래는 HttpMessageConverter의 대략적인 동작 흐름입니다. 참고하세요.

JSON -> DTO로 deserialization

HandlerMethodArgumentResolverComposite.resolveArgument()

→ RequestResponseBodyMethodProcessor.resolveArgument()

→ RequestResponseBodyMethodProcessor.readWithMessageConverters() > converter.read()

→ objectReader.readValue()

DTO -> JSON serialization

HandlerMethodReturnValueHandlerComposite.handleReturnValue()
→ HttpEntityMethodProcessor.handleReturnValue()
→ AbstractMessageConverterMethodProcessor.writeWithMessageConverters() > genericConverter.write()
→ AbstractGenericHttpMessageConverter.write()
→ AbstractJackson2HttpMessageConverter.writeInternal() > objectWriter.writeValue(generator, value)→ write() and flush() 과정을 거친다.
→ ...
→ ...
→ CoyoteAdapter.service() > response.finishResponse() // response가 close되면서 클라이언트 쪽에 출력

HttpMessageConverter 참고 자료

https://docs.spring.io/spring-framework/docs/current/javadoc-api/

Spring Framework 5.3.19 API

docs.spring.io

ResponseEntity 알아보기

Kevin's IT Village — Thu, 21 Apr 2022 14:01:43 +0900

ResponseEntity란?

ResponseEntity는 HttpEntity의 확장 클래스로써 HttpStatus 상태 코드를 추가한 전체 HTTP 응답(상태 코드, 헤더 및 본문)을 표현하는 클래스입니다.

ResponseEntity를 어디에 사용할 수 있나요?

ResponseEntity 클래스는 주로 @Controller 또는 @RestController 애너테이션이 붙은 Controller 클래스의 핸들러 메서드(Handler Method)에서 요청 처리에 대한 응답을 구성하는데 사용됩니다. Used in RestTemplate as well as in @Controller methods.
그리고 RestTemplate으로 외부의 API 통신에 대한 응답을 전달 받아서 처리할 경우, 역시 ResponseEntity를 사용합니다.

ResponseEntity를 어떻게 사용해야 할까요?

가장 일반적인 방식

가장 일반적인 방식은 [코드 1-1]과 같이 new로 ResponseEntity 객체를 생성하는 방식입니다.

1
2
3
4
5
6
7
8
9
10
11

@RestController
@RequestMapping("/v1/coffees")
public class ResponseEntityExample01 {
    @PostMapping
    public ResponseEntity postCoffee(Coffee coffee) {
 
        // coffee 정보 저장
        
        return new ResponseEntity<>(coffee, HttpStatus.CREATED);
    }
}
[코드 1-1]


 

[코드 1-1]은 ResponseEntity 객체를 생성하면서 응답의 body 데이터와 HttpStatus의 상태를 전달하고 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@RestController
@RequestMapping("/v1/coffees")
public class ResponseEntityExample01 {
    @GetMapping("/{coffee-id}")
    public ResponseEntity getCoffee(@PathVariable("coffee-id") long coffeeId) {
 
        if (coffeeId < 0) {
            return new ResponseEntity<>(
                    "coffeeId should be greater than 0",
                    HttpStatus.BAD_REQUEST);
        }
 
        return new ResponseEntity<>(new Coffee(), HttpStatus.OK);
    }
}
[코드 1-2]

코드 1-2는 coffeeId에 따라서 HttpStatus 상태를 동적으로 지정하는 예입니다.

코드 1-2는 요청 데이터에 대한 유효성 검사가 API 계층에 포함에 직접 포함이 되어 있는데, 이는 좋은 개발 방식은 아닙니다.

Handler Method는 단순히 클라이언트의 요청을 전달 받고, 처리된 응답을 다시 클라이언트에게 전달하는 역할만 하도록 로직을 단순화 하는 것이 좋으며, 유효성 검사나 비즈니스 처리 등의 로직은 별도의 메서드 또는 클래스로 분리를 하는 것이 좋습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@RestController
@RequestMapping("/v1/coffees")
public class ResponseEntityExample01 {
    @GetMapping("/{coffee-id}")
    public ResponseEntity getCoffee(@PathVariable("coffee-id") long coffeeId) {
 
        if (coffeeId < 0) {
            return new ResponseEntity<>(
                    "coffeeId should be greater than 0",
                    HttpStatus.BAD_REQUEST);
        }
 
        HttpHeaders headers = new HttpHeaders();
        headers.add("Custom-Header", "bar");
        return new ResponseEntity<>(new Coffee(), headers, HttpStatus.OK);
    }
}
[코드 1-3]

만일 ResponseEntity에 Custom header를 포함하고 싶다면 코드 1-3과 같이 HttpHeaders에 원하는 header를 추가하고 ResponseEntity의 생성자로 headers 객체를 전달하면 됩니다.

BodyBuilder를 이용한 메서드 체인 방식

ResponseEntity 클래스의 생성자로 body, header, HttpStatus 등을 추가하는 방식과 달리 BodyBuilder 클래스를 이용하면 각각의 항목들을 메서드 체인 방식으로 전달할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11

@RestController
@RequestMapping("/v1/coffees")
public class ResponseEntityExample02 {
    @PostMapping
    public ResponseEntity<Coffee> postCoffee(Coffee coffee) {
 
        // coffee 정보 저장
        long savedCoffeeId = 1L;
        return ResponseEntity.created(URI.create("/members/" + savedCoffeeId)).body(coffee);
    }
}
[코드 1-4]

코드 1-4는 코드 1-1을 ResponseEntity.BodyBuilder를 이용해서 메서드 체인 방식으로 ResponseEntity 객체를 리턴해주고 있습니다.

created() 메서드의 경우 URI를 지정할 수 있는데, 이는 새롭게 생성된 리소스에 대한 접근 URI를 Location 헤더 값으로 포함시킴으로써 클라이언트 쪽에서 이 정보를 이용해 해당 리소스에 접근할 수 있도록 해줍니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@RestController
@RequestMapping("/v1/coffees")
public class ResponseEntityExample02 {
    @GetMapping("/{coffee-id}")
    public ResponseEntity getCoffee(@PathVariable("coffee-id") long coffeeId) {
 
        if (coffeeId < 0) {
            return ResponseEntity.badRequest().body("coffeeId should be greater than 0");
        }
 
        HttpHeaders headers = new HttpHeaders();
        headers.add("Custom-Header", "bar");
        return ResponseEntity.ok().headers(headers).body(new Coffee());
    }
}
[코드 1-5]

코드 1-5는 코드 1-3을 BodyBuilder를 이용해서 메서드 체인 방식으로 변경한 코드입니다.

ResponseEntity 관련 자료

Spring Framework API docs: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/http/ResponseEntity.html

Controller 핸들러 메서드의 Argument 알아보기

Kevin's IT Village — Tue, 19 Apr 2022 14:36:42 +0900

Controller의 핸들러 메서드는 다양한 유형의 Argument(인수)를 지원합니다.

그 중에서 REST API 애플리케이션에서 자주 사용되는 유형의 Argument를 간단히 살펴보도록 하겠습니다.

Method Argument	설명
@RequestParam	쿼리 파라미터, form-data 등의 Servlet request Parameter를 바인딩 해야 할 경우 사용합니다.
@RequestHeader	request header를 바인딩해서 header의 key/value에 접근할 수 있습니다.
@RequestBody	request body를 읽어서 지정한 Java 객체로 deserialization 해줍니다.
@RequestPart	'multipart/form-data' 형식의 request 데이터를 part 별로 바인딩할 수 있도록 해줍니다.
@PathVariable	@RequestMapping 에 패턴 형식으로 정의된 URL의 변수에 바인딩할 수 있도록 해줍니다.
@MatrixVariable	URL 경로 세그먼트 부분에 key/value 쌍으로 된 데이터에 바인딩할 수 있도록 해줍니다.
HttpEntity	request header와 body에 접근할 수 있는 컨테이너 객체를 사용할 수 있습니다.
javax.servlet.ServletRequest, javax.servlet.ServletResponse	로우 레벨의 ServeletRequest와 ServletResponse의 정보가 필요할 때 사용할 수 있습니다.

@RequestParam

@RequestParam은 클라이언트 쪽에서 쿼리 파라미터, form data, x-www-form-urlencoded 등의 형식으로 전달되는 요청 데이터를 바인딩해서 사용할 수 있도록 해줍니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Controller
@RequestMapping("/coffees")
public class CoffeeController {
 
    // ...
 
    @GetMapping
    public Coffee getCoffee(@RequestParam("coffeeId") int coffeeId) {
       Coffee coffee = coffeeService.getCoffee(coffeeId);
        return coffee;
    }
 
    // ...
 
}
[코드 1-1]

cs

@RequestHeader

@RequestHeader는 HTTP request header의 key/value 쌍의 데이터에 접근할 수 있도록 해줍니다.

1
2
3
4
5
6

@GetMapping("/coffee")
public void getCoffee(
        @RequestHeader("Content-Type") String contentType, 
        @RequestHeader("Content-Length") long contentLength) { 
    //...
}
[코드 1-2]

cs

@RequestBody

@RequestBody는 HTTP request body를 읽어서 지정한 Java 객체로 변환(deserialization) 해줍니다.

1
2
3
4
5

@PostMapping("/coffees")
public void handle(@RequestBody Coffee coffee) {
    // ...
    coffeeService.save(coffee)
}
[코드 1-3]

cs

@RequestBody는 특히 리소스를 등록하는 @PostMapping에서 주로 사용됩니다.

@RequestPart

'multipart/form-data' 형식의 request 데이터를 part 별로 바인딩할 수 있도록 해줍니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Controller
public class CoffeeController {
    @PostMapping("/coffees")
    public String postCoffee(@RequestPart("coffee") Coffee coffee,
           @RequestPart("file") MultipartFile photoFile) {
 
        if (!photoFile.isEmpty()) {
            byte[] bytes = file.getBytes();
            // TODO 파일 저장
            return "success";
        }
        return "failed";
    }
}
[코드 1-4]

cs

예를 들어, 클라이언트 쪽에서 커피 사진이 포함된 multpart/form-data 타입의 커피 정보를 전송한다면, [코드 1-4]와 같이 form data를 part별로 나누어서 전달 받을 수 있습니다.

@PathVariable

@PathVariable은 @RequestMapping 에 패턴 형식으로 정의된 URL의 변수에 바인딩할 수 있도록 해줍니다.

1
2
3
4

@GetMapping("/members/{member-id}/coffees/{coffee-id}")
public Pet getCoffee(@PathVariable("member-id") Long memberId, 
@PathVariable("coffee-id") Long coffeeId) {
    // ...
}
[코드 1-5]

cs

[코드 1-5]와 같이 '{variable name}'과 같은 형태의 URL 변수가 여러개 있을 경우, @PathVariable을 핸들러 메서드에 순차적으로 추가해서 URL 변수의 값을 받을 수 있습니다.

@MatrixVariable

@MatrixVariable은 URL 경로 세그먼트 부분에 key/value 쌍으로 된 데이터에 바인딩할 수 있도록 해줍니다.

@MatrixVariable의 사용은 예제 코드를 보는게 가장 이해가 빠릅니다.

1
2
3
4
5
6
7
8
9
10
11
12

// 클라이언트 요청 URL
// GET /coffees/42;q=11;r=22
 
@GetMapping("/coffees/{coffeeId}")
public void getCoffee(@PathVariable("coffee-id") coffeeId, 
                      @MatrixVariable int q,
                      @MatrixVariable int r) {
 
    // coffeeId == 42
    // q == 11
    // r == 22
}
[코드 1-6]

cs

만약에 클라이언트 쪽 요청 URL이 '/coffees/42;q=11;r=22'와 같다면 세미콜론(;) 뒤에 오는 q, r을 변수로 보고 각 변수의 값을 [코드 1-6]과 같이 핸들러 메서드에서 전달 받을 수 있습니다.

HttpEntity

클라이언트 요청 body와 header 정보를 HttpEntity 객체를 통해 한번에 전달 받을 수 있습니다. 물론 HttpServletRequest 객체를 통해서도 요청 body와 header에 접근할 수 있지만 HttpEntity 객체를 통해 조금 더 간단하게 두 정보에 접근할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12

@RestController
@RequestMapping("/v1/coffees")
public class HttpEntityExample {
    @PostMapping
    public Coffee postCoffee(HttpEntity<Coffee> entity) {
        Coffee coffee = entity.getBody();
        HttpHeaders headers = entity.getHeaders();
        
        // coffee 정보 저장
        return coffee;
    }
}
[코드 1-7]

cs

 

@RequestMapping 애너테이션

Kevin's IT Village — Tue, 19 Apr 2022 09:34:32 +0900

@RequestMapping 애너테이션은 어디에 사용할 수 있나요?

@RequestMapping 애너테이션은 클라이언트의 요청과 Controller의 핸들러 메서드를 매핑하기 위해서 사용하는 애너테이션입니다. 즉, @RequestMapping 애너테이션에 정의된 URI에 매치되는 요청을 처리할 수 있도록 해줍니다.

@RequestMapping 애너테이션은 클래스 레벨에 사용할 수 있고, 메서드 레벨에 사용할 수 있습니다.
일반적으로 공통 URI는 클래스 레벨에 정의하고, 핸들러 메서드별로 달라지는 URI는 각각의 핸들러 메서드에 정의합니다.

@RequestMapping 애너테이션 단축 표현

@RequestMapping 애너테이션은 HTTP Method 에 해당하는 단축 표현들을 주로 사용합니다.

@GetMapping: HTTP Get Method에 해당하는 단축 표현으로 서버의 리소스를 조회할 때 사용
@PostMapping: HTTP Post Method에 해당하는 단축 표현으로 서버에 리소스를 등록(저장)할 때 사용
@PutMapping: HTTP Put Method에 해당하는 단축 표현으로 서버의 리소스를 수정할 때 사용. 리소스의 모든 정보를 수정할 때 사용한다.
@PatchMapping: HTTP Put Method에 해당하는 단축 표현으로 서버의 리소스를 수정할 때 사용. 리소스의 일부 정보만 수정할 때 사용한다.
@DeleteMapping: HTTP Delete Method에 해당하는 단축 표현으로 서버의 리소스를 삭제할 때 사용.

일반적으로 클래스 레벨에는 @RequestMapping 애너테이션을 사용하고, 메서드 레벨에서는 단축 표현을 사용하는 것을 권장하고 있습니다.

@RequestMapping 애너테이션에 사용되는 Attribute

@RequestMapping 애너테이션에 사용되는 Attribute는 생각보다 많이 사용되지 않습니다. 하지만 필요할 경우 그때 그때 설정해서 사용할 수 있으므로 아래 링크를 확인하시고 어떤 Attribute가 있는 살펴보기 바랍니다.

Postman 기본 사용법

Kevin's IT Village — Mon, 18 Apr 2022 17:48:27 +0900

이번 시간에는 REST API 요청을 테스트하기 위한 API 테스트 툴인 Postman의 기본 사용법을 알아보도록 하겠습니다.

API 요청을 보내는 최소한의 사용법만 살펴볼 예정이므로 Postman의 세부 기능이 궁금하신 분들은 공식 사이트의 매뉴얼을 참고해주세요.

Postman은 웹에서도 사용 가능하지만 여기서는 편의를 위해 실행 파일을 다운로드한 후, 설치하는 것을 기준으로 설명합니다.
이 글의 Postman 실행 파일은 Windows 기준이지만 다른 OS의 경우도 사용법은 크게 다르지 않을 것이라 생각합니다.

실행 파일 다운로드

Postman 사이트에서 Postman 실행 파일을 다운로드 받습니다.

실행 파일 설치

다운로드 받은 실행 파일을 실행한 후, 안내에 따라서 설치합니다.

설치된 파일 실행

[그림 1-1] Postman 파일 실행 시 첫 화면

설치된 Postman 파일을 실행하면 [그림 1-1]과 같은 화면이 오픈됩니다. 여기서 처음 사용을 하는 분은 [Create Account] 버튼을 눌러서 계정을 생성한 후, [Sign In] 버튼을 눌러 로그인을 진행하면 됩니다.

※ Postman은 특이하게 컴퓨터에 설치된 파일을 실행해도 계정 생성이나 로그인은 웹 브라우저로 자동 이동해서 진행이 되니 이점 참고하시기 바랍니다.

[그림 1-2] 로그인 후, 애플리케이션 리다이렉션 메시지

로그인 후, [그림 1-2]와 같이 데스크탑 애플리케이션으로 리다이섹션 할지 묻는 창이 열립니다. [Postman 열기] 버튼을 클릭합니다.

워크스페이스(Workspace) 생성

[그림 1-3] 워크 스페이스 생성

[그림 1-3]과 같이 [Workspaces] 탭을 선택한 후, [Create Workspace] 버튼을 클릭한 후, 워크스페이스 이름을 입력해서 워크스페이스를 생성합니다.

컬렉션(Collections) 생성

[그림 1-4] 컬렉션 생성

[그림 1-4]와 같이 [+](Create new Collection) 버튼을 눌러서 컬렉션을 생성합니다.

※ 컬렉션은 원하는 API 요청들을 컬렉션 별로 구분하기 위한 일종의 그룹화라고 보면 됩니다. 프로젝트별로 컬렉션을 생성해서 API 요청 목록들을 관리하면 좋을 것 같습니다.

API 요청 정보 추가

[그림 1-5] API 요청 정보 추가

생성된 컬렉션의 [...] 메뉴를 클릭한 후, [Add request] 메뉴를 클릭합니다.

[그림 1-6] 요청 정보 입력 화면

[그림 1-6]과 같이 요청에 필요한 HTTP Method를 선택한 후, 요청에 필요한 URI를 입력합니다.

[그림 1-6]에서는 HTTP Method로 POST를 선택했기 때문에 [Body] 탭에서 데이터 타입을 선택할 수 있습니다.

요청에 필요한 정보를 모두 입력했다면 [Send] 버튼을 눌러서 서버로부터 응답 메시지를 전달 받을 수 있습니다.

Spring Boot 애플리케이션의 부트스트랩(Bootstrap) 과정 알아보기

Kevin's IT Village — Tue, 12 Apr 2022 18:35:36 +0900

Spring Boot에서의 부트스트랩이란?

일반적으로 부트스트랩(Bootstrap)이란 어떠한 과정이 시작되어 알아서 진행되는 일련의 과정을 의미합니다.

컴퓨터의 부팅 과정을 생각해보면 이해가 쉬울것입니다.

우리가 컴퓨터 전원을 켜게 되면 일반적으로 다음과 같은 작업이 내부적으로 진행이 됩니다

전원을 켜면 컴퓨터 전원이 잘 공급되는지를 확인한다.
중앙 처리 장치의 상태를 점검한다.
ROM에서 컴퓨터의 입출력 장치 및 램과 같은 주요 기본 장치들에 대한 정보를 읽어들여서 정상 동작 유무를 확인한다.
운영체제를 램으로 읽어 들여서 실행한다.

Spring Boot에서의 부트스트랩도 컴퓨터 부팅 과정과 유사합니다.

Spring Boot 애플리케이션이 실행이 되면, 클라이언트가 사용 가능한 애플리케이션으로 동작하기 위한 사전 작업을 거치게 됩니다.

Spring Boot 애플리케이션을 어떻게 부트스트랩 시킬 수 있을까요?

[코드 1-1]

1
2
3
4
5
6
7

@Configuration
@EnableAutoConfiguration
public class CoffeeApplication  {
    public static void main(String[] args) {
     SpringApplication.run(CoffeeApplication.class, args);
    }
}
 

cs

대부분의 Spring Boot 애플리케이션은 [코드 1-1]과 같이 run() 메서드를 호출해서 부트스트랩을 진행할 수 있습니다.

[코드 1-2]

1
2
3
4
5
6
7
8
9

@Configuration
@EnableAutoConfiguration
public class CoffeeApplication  {
    public static void main(String[] args) {
         SpringApplication application = new SpringApplication(CoffeeApplication.class);
        // 애플리케이션 설정 커스터마이징..
        application.run(args)
    }
}
 

cs

[코드 1-2]와 같이 애플리케이션 부트스트랩 전에 애플리케이션 설정을 커스터마이징 할 수도 있습니다.

Spring Boot에서는 부트스트랩 과정에서 어떤 일이 일어날까요?

클래스 패스 내에서 ApplicationContext 인스턴스를 생성한다.
커맨드라인 매개 변수들을 Spring의 프로퍼티로 구성하기 위해 CommandLinePropertySource를 등록한다.
모든 싱글톤 bean들을 로드한 후, 애플리케이션 컨텍스트를 갱신한다.
CommandLineRunner bean들이 존재한다면 트리거(Trigger) 시킨다.

@SpringBootApplication 의 역할

Kevin's IT Village — Tue, 12 Apr 2022 17:59:24 +0900

[코드 1-1]

@SpringBootApplication
public class CoffeeApplication {

    public static void main(String[] args) {
        SpringApplication.run(CoffeeApplication.class, args);
    }

}

[코드 1-1]과 같이 Spring Boot Application 클래스에 @SpringBootApplication 애너테이션을 추가하면 기본적으로 해당 애플리케이션이 Spring Boot 기반의 애플리케이션으로 동작하도록 해줍니다.

그렇다면 @SpringBootApplication 은 내부적으로 어떤 기능을 하는 걸까요?

@SpringBootApplication 은 다음과 같은 세 가지 기능을 활성화 하는데 사용됩니다.

@EnableAutoConfiguration
- Spring Boot의 자동 구성 메카니즘을 활성화합니다.
@ComponentScan
- 애플리케이션 내의 패키지에서 @Component 애너테이션이 붙은 클래스들에 대한 스캐닝을 활성화합니다.
@SpringBootConfiguration
- Spring Context에 Bean을 추가적으로 등록하거나 Configuration 클래스를 추가적으로 임포트 하는 기능을 활성화합니다.
- Spring Boot의 @*Test 애너테이션을 사용해서 테스트를 진행할 경우, 자동으로 @SpringBootConfiguration을 검색합니다.

@SpringBootApplication 을 무조건 붙여야 하는것은 아니며, [코드 1-2]와 @SpringBootApplication 이 지원하는 세 가지 기능을 개별적으로 적용할 수 있습니다.

[코드 1-2]

@SpringBootConfiguration(proxyBeanMethods = false)
@EnableAutoConfiguration
@Import({ CoffeeConfiguration.class, MemberConfiguration.class })
public class CoffeeApplication {

    public static void main(String[] args) {
        SpringApplication.run(CoffeeApplication.class, args);
    }

}

RESTful API의 URL 작성 규칙

Kevin's IT Village — Tue, 12 Apr 2022 17:02:02 +0900

REST API란?

REST(Representational State Transfer)는 HTTP 네트워크 상의 리소스(Resource, 자원)를 정의하고 해당 리소스를 URI라는 고유한 주소로 접근하는 접근 방식을 의미하며, REST API란 REST 방식을 통해서 리소스에 접근하기 위한 서비스 API를 지칭합니다.

REST에서 의미하는 리소스란?

REST에서 의미하는 자원은 데이터베이스에 저장된 데이터, 문서, 이미지, 동영상 등 HTTP 통신을 통해 주고 받을 수 있는 모든 것을 의미합니다.

URI(Uniform Resource Identifier)와 URL(Uniform Resource Locator)

URI는 네트워크 상에 있는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미합니다.

URL은 인터넷에 있는 리소스를 나타내는 통합 리소스 식별자를 의미하며, 우리가 흔히들 이야기하는 웹 상의 주소를 의미합니다.

URI는 URL의 상위 개념으로 볼 수 있습니다.

URI는 리소스를 식별하는 식별자 역할을 하고, URL은 리소스의 위치를 가리킵니다.

예) http://www.itivllage.tistory.com/manage? id = 1

위 예에서 'http://www.itivllage.tistory.com/manage'까지는 리소스의 위치를 가리키는 URL이라고 할 수 있고, 'http://www.itivllage.tistory.com/manage? id = 1'는 리소스를 식별하기 위한 'id = 1'이라는 고유 식별자 붙었으므로 URI라고 할 수 있습니다.

REST API URI 작성 규칙

그러면 이번에는 HTTP 상에서 REST API 서비스를 만드는 입장에서 REST API URI를 작성하는 규칙들을 살펴보도록 하겠습니다.

URI 작성 기본 규칙

URI의 마지막이 '/'로 끝나지 않아야 합니다.
- better
  - http://www.itivllage.tistory.com/coffees (ㅇ)
- worse
  - http://www.itivllage.tistory.com/coffees/ (x)
동사 보다는 명사를 사용합니다.
- better
  - http://www.itivllage.tistory.com/coffees (ㅇ)
- worse
  - http://www.itivllage.tistory.com/coffees/update (x)
단수형 보다는 복수형 명사를 사용합니다.
- better
  - http://www.itivllage.tistory.com/coffees (ㅇ)
- worse
  - http://www.itivllage.tistory.com/coffee (x)
URI는 기본 소문자로 사용합니다.
언더스코어( _ ) 대신에 하이픈(-)을 사용합니다.
파일 확장자는 URI에 포함하지 않습니다.

URI에서 리소스 간의 관계를 표현하는 방법

REST API를 작성하다보면 특정 리소스 간의 관계를 URI로 표현해야 할 경우가 굉장히 많습니다.

이해를 위해 예시를 살펴보도록 하겠습니다.

'http://www.itivllage.tistory.com/members'는 전체 회원에 대한 리소스를 의미합니다.
'http://www.itivllage.tistory.com/members/1'는 1이라는 ID를 가지는 회원에 대한 리소스를 의미합니다..
'http://www.itivllage.tistory.com/members/1/orders'는 1이라는 ID를 가지는 회원의 주문에 대한 리소스를 의미합니다.

더 읽을 거리

REST - 위키백과, 우리 모두의 백과사전

대한민국의 힙합 음악가에 대해서는 R-EST 문서를 참고하십시오. REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이

ko.wikipedia.org

7 Rules for REST API URI Design - DZone Integration

URIs, or Uniform Resource Identifiers, should be designed to be readable and clearly communicate the API resource model. These rules will help you succeed.

dzone.com

웹 API 디자인 모범 사례 - Azure Architecture Center

플랫폼 독립성과 서비스 진화를 지원하는 웹 API 설계를 위한 모범 사례를 알아봅니다.

docs.microsoft.com

Spring MVC의 동작 방식 추가 설명

Kevin's IT Village — Fri, 8 Apr 2022 14:35:18 +0900

Handler 용어의 의미

핸들(Handle) 이라고 하면 일반적으로 자동차의 핸들을 제일 먼저 떠올릴 수 있는데, 자동차의 핸들은 운전자가 직접 핸들을 움직이면서 직접적으로 자동차의 주행을 처리하는 역할을 합니다.

Spring MVC에서는 자동차의 핸들과 마찬가지로 클라이언트의 요청을 처리하는 처리자를 Handler라고 합니다.

그렇다면 Spring MVC에서 Handler는 누구일까요?
Spring MVC에서의 요청 Handler는 바로 여러분들이 작성하는 Controller 클래스를 의미합니다. 그리고 Controller 클래스에 있는 ‘@GetMapping, @PostMapping’ 같은 애너테이션이 붙어 있는 메서드들을 핸들러 메서드라고 합니다.

HandlerMapping이란 의미는 결국 사용자의 요청과 이 요청을 처리하는 Handler를 매핑해주는 역할을 하는 것입니다.

그렇다면, 사용자의 요청과 Handler 메서드의 매핑은 어떤 기준으로 이루어질까요?
@GetMapping(”/coffee”) 처럼 HTTP Request Method(GET, POST 등)와 Mapping URL을 기준으로 해당 Handler와 매핑이 되는데 Spring 에서는 여러가지 유형의 HandlerMapping 클래스를 제공하고 있습니다.

실무에서는 Spring에서 디폴트로 지정한 ‘RequestMappingHandlerMapping’을 대부분 사용하는데 원한다면 얼마든지 HandlerMapping 전략을 바꿀 수 있습니다.

Adapter의 의미

Java에서 사용하는 클래스나 인터페이스의 이름을 살펴보다 보면 흥미로운 용어들이 많이 나옵니다.
Adapter라는 용어도 그 중에 하나라고 볼 수 있습니다.

우리말로 아답터, 어댑터(Adapter, Adaptor)하면 220V 전압을 110V 전압으로 또는 그 반대로 바꿔주는 어댑터(일명, 돼지코)나 USB 충전기를 떠올릴 수 있습니다.

220V를 5V 전압으로 바꿔주는 USB 충전기 예

이처럼 Adapter는 무언가를 다른 형식이나 형태로 바꿔주는 역할을 합니다.

그렇다면 HandlerAdater는 무엇을 바꿔줄까요?

Spring은 객체지향의 설계 원칙을 잘 따르는 아주 유연한 구조를 가지는 프레임워크입니다.
따라서 Spring이 제공하는 Spring MVC에서 지원하는 Handler를 사용해도 되지만 다른 프레임워크의 Handler를 Spring MVC에 통합할 수 있습니다.

이처럼 다른 프레임워크의 핸들러를 Spring MVC에 통합하기 위해서 HandlerAdapter를 사용할 수 있습니다.

ViewResolver의 의미

’Resolve’는 무언가를 해석하고, 해결해주다라는 뜻이 있습니다.

ViewResolver는 DispatcherServlet에서 ‘이런 이름을 가진 View를 줘’ 라고 요청하면 DispatcherServlet에서 전달한 View 이름을 해석한 뒤 적절한 View 객체를 리턴해주는 역할을 합니다.

객체지향 설계 원칙

Kevin's IT Village — Mon, 28 Mar 2022 11:27:04 +0900

객체 지향 설계 원칙이란?

수많은 사람들이 고민하고 시행착오를 겪으면서 만든 원칙입니다.
좀 더 유지보수하기 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 만들 수 있습니다.
코드 베이스뿐만 아니라 아키텍쳐 설계에 이르기까지 다양하게 적용할 수 있습니다.

높은 응집력이란?

비슷한 일을 하는 기능 즉, 하나의 책임에 포함되는 기능들이 잘 뭉쳐있다면 높은 응집력을 가진다고 볼 수 있습니다.
하나의 기능을 변경하는데 여기저기 변경해야 될 곳이 많다면 응집력이 낮다고 볼 수 있습니다.

낮은 결합도란?

클래스 간에 의존성이 낮다면 낮은 결합도를 가진다고 볼 수 있습니다.
하나의 클래스를 수정하는데 의존하는 다른 클래스를 모두 수정해야 한다면 결합도가 높다고 할 수 있습니다.

SOLID 원칙

SRP, OCP, LSP, ISP, DIP의 첫 글자를 딴것이 SOLID 입니다.

SRP(Single Responsibility Principle, 단일 책임의 원칙)

클래스가 제공하는 기능들은 하나의 책임을 수행하는데 집중해야 한다는 원칙입니다.
SRP를 지키지 않는다면?
- 응집력이 낮아지고, 결합도는 높아집니다.
- 서로 다른 애플리케이션에 배포될 때 사용하지 않는 기능도 포함됩니다. 즉, 왕따가 발생합니다.
- 변수 레벨
  - 하나의 속성이 여러 의미를 가지는 경우
- 메서드 레벨
  - if 문이 많을 경우
SRP를 잘 지킨다면?
- 응집력이 높아지고, 결합도는 낮아집니다.
- 코드 가독성도 좋아집니다.
- 테스트 범위도 작아집니다. 즉 유지보수도 편해집니다.
AOP는 별도의 부가 기능을 핵심 로직에서 분리했기 때문에 SRP의 원칙을 지킨 방식이라고도 할 수 있습니다.

SRP를 지키는 역할 분리의 예) Kevin이라는 클래스가 있다면?

남편의 역할
- 자주 전화해주기
- 기념일 챙기기
아빠의 역할
- 놀아주기
- 씻겨주기
- 재워주기
- 먹여주기
- 책 읽어주기
아들의 역할
- 건강 체크하기
- 용돈 주기
- 안부 전화하기
- 자주 방문하기
사위의 역할
- 건강 체크하기
- 용돈 주기
- 안부 전화하기
- 자주 방문하기
친구의 역할
- 안부 전화하기
- 술 마시기
- 고민 들어주기
직원의 역할
- 출근하기
- 열심히 일하기
- 회의하기
- 퇴근하기

OCP(Open Close Principle, 개방폐쇄의 원칙)

확장에는 열려있고(Open), 변경에는 닫혀 있어야 한다(Close)는 원칙입니다.
변하는것과 변하지 않는것을 잘 구분하면 OCP를 지키기 용이합니다. 변하는것은 Open, 변하지 않는 것은 Close에 해당됩니다.
변하지 않는것은 변하는 것의 구현에 의존하지 않고, 인터페이스를 통해 느슨하게 의존하게 만듭니다.
디자인 패턴 중에서 전략패턴의 전략 인터페이스는 OCP의 Open에 해당되고 Context는 OCP의 Close에 해당됩니다.
예)
- 자동차라는 객체에서 변하지 않는 동작
  - 움직이는 것
- 자동차 객체에서 변하는 동작
  - 수동 모드, 오토메이션 모드, 크루즈컨트롤 모드

LSP(The Liskov Substitution Principle, 리스코브 치환의 원칙)

subclass의 객체는 superclass의 참조 변수에 대입해서 superclass의 역할을 수행하는데 문제가 없어야 한다는 원칙입니다.
OCP 원칙의 기반이 된다고 생각됩니다.

ISP(Interface Segregation Principle, 인터페이스 분리의 원칙)

인터페이스의 단일 책임을 위한 원칙입니다.
즉, 일반적인 하나의 인터페이스를 조금 더 구체적인 인터페이스로 쪼개는것이 낫다는 것입니다.
예)
- 새의 행동(일반적인 하나의 인터페이스)
- 날수 있는 행동(구체적인 인터페이스)
- 울수 있는 행동(구체적인 인터페이스)

DIP(Dependency Inversion Principle, 의존성 역전의 원칙)

자주 변경되는 구체 클래스에 의존하지 않고, 추상화(일반화) 된 클래스에 의존하는 것을 의미합니다.
구체 클래스가 추상 클래스에 의존하므로 의존 관계가 역전된 형태입니다.
예)
- Spring framework의 IOC 컨테이너
  - 직접 객체를 생성하는것이 아니라 프레임워크에서 객체를 제공해줍니다.
- 느슨한 연결 측면에서의 DIP
  - 추상 클래스에서 구체 클래스의 hook 메서드를 호출하는 것
    - hook 메서드 호출 시, 구체 클래스가 무엇인지 알 필요가 없습니다.
- 이벤트 드리븐 방식
  - 이벤트 리스너를 등록하고 hook 메서드를 통해 해당 이벤트를 처리합니다.
    - hook 메서드 호훌 시, 구체적인 이벤트 리스너가 무엇인지 알 필요가 없습니다.

OpenID Connect 방식의 로그인 연동

Kevin's IT Village — Fri, 9 Jul 2021 16:44:46 +0900

: NiFi 서버의 로그인 방식은 LDAP, Kerberos, OpenID Connect, Apache Knox에서 하나를 선택하여 구성할 수 있다(다음 링크 참조: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication). 이 네가지 방식중에서 OpenID Connect(다음 링크 참조: https://openid.net/connect/) 로그인 방식을 택한것은 별도의 추가적인 인증 서버 설치 및 관리가 필요없어서 관리의 부담이 적고, 설정 자체가 네가지 방식 중에 가장 단순하기때문이다.

(1) Google API 프로젝트 생성 : OpenID Connect 방식의 로그인을 사용하기위해서 Google API를 사용할 것이므로 Google API용 프로젝트를 먼저 생성해야 한다.

a. 아래 링크를 통해 Google API로 접속을 한다.

https://console.developers.google.com/apis

b. (그림 1. Google API Dashboard)와 같이 새 프로젝트를 생성하기 위해 1)의 빨간색 박스 영역을 클릭한다.

(그림 1. Google API Dashboard)

c. (그림 2. 새프로젝트 생성)과 같이 1)의 "새 프로젝트"를 클릭한다.

※ NiFi 서버용 프로젝트(nifi-fitogether)가 이미 생성이 되어 있는 상태이지만 새 프로젝트를 생성하는 방법을 보여주기 위함이다.

(그림 2. 새프로젝트 생성)

d. (그림 3. 새 프로젝트 설정)에서 1) 프로젝트명을 입력 2) "만들기" 버튼을 클릭한다.

(2) OAuth 동의 화면 설정

(그림 4.1. OAuth 동의 화면 설정)

1) 좌측 메인 메뉴에서 "OAuth" 동의 화면을 클릭한다.

2) "UserType"에서 "내부"를 선택한 후, "만들기" 버튼을 클릭한다. "만들기" 버튼을 클릭하면 OAuth 동의 화면의 상세 항목 페이지로 이동한다.

(그림 4.1. OAuth 동의 화면 상세)

1) 애플리케이션 이름을 적절하게 입력한다.

2) OAuth 인증을 사용하기 위한 승인된 도메인을 입력하고 엔터키를 누른 후, 맨 하단의 저장 버튼을 클릭한다.

(3) 클라이언트 ID 생성

(그림 5.1. 사용자 인증 정보 생성)

1) 좌측의 메인 메뉴에서 "사용자 인증 정보"를 클릭한다.

2) 사용자 인증 정보를 생성하기 위해서 상단의 "사용자 인증 정보 만들기"를 클릭한다.

3) "OAuth 클라이언트 ID"를 클릭한다.

(그림 5.2. 애플리케이션 유형 선택)

1) 애플리케이션 유형 항목에서 "웹 애플리케이션"을 선택한다.

2) 이름 항목에 적절한 이름을 입력한 후, "생성" 버튼을 클릭한다.

(그림 5.3. OAuth 클라이언트 생성 후 팝업)

: OAuth 클라이언트 생성 직 후, 위와 같은 팝업이 뜨는데 "클라이언트 ID"와 "클라이언트 보안 비밀번호"를 copy해서 보관해둔다.

(그림 5.4. OAuth 클라이언트 ID 목록)

1) 생성된 OAuth 클라이언트 ID를 설정하기 위해 클라이언트 ID 목록에서 이름 항목을 클릭한다.

(그림 5.5. OAuth 클라이언트 ID 설정)

1) 이름 항목에 이름을 적절하게 입력한다.

2) URI 버튼을 클릭해서 아래 URI 주소를 입력한 후, "저장" 버튼을 클릭한다.

https://xxx.xxxx.com/nifi-api/access/oidc/callback

(4) nifi.properties 설정 : Google 클라이언트 ID를 이용한 OpenID Connect 방식의 로그인을 위해 nifi.properties(파일 위치: /home/ubuntu/app/nifi-1.11.4/conf)에 아래와 같이 설정을 추가한다.

(그림 6. nifi.properties에 OpenID Connect 설정)

1) OpenID Connect Provider 검색 URL을 "nifi.security.user.oidc.discovery.url" 프로퍼티의 값으로 입력한다.

2) (그림 5.3. OAuth 클라이언트 생성 후 팝업)에서 copy하여 보관한 클라이언트 ID를 "nifi.security.user.oidc.client.id" 프로퍼티의 값으로 입력한다.

3) (그림 5.3. OAuth 클라이언트 생성 후 팝업)에서 copy하여 보관한 클라이언트 보안 비밀번호를 "nifi.security.user.oidc.client.secret" 프로퍼티의 값으로 입력한다.

(5) authorizers.xml 파일 설정 : OpenID Connect 로그인을 위한 접근 권한을 부여하기 위해 authorizers.xml(/home/ubuntu/app/nifi-1.11.4/conf) 파일을 아래와 같이 수정한다.

(그림 7. authorizers.xml에 접근 권한 설정)

: 1), 2)에 Google OAuth 클라이언트 ID를 생성할 때 로그인한 Google 이메일 계정을 입력한 후, 파일을 저장한다.

(6) 로그인 테스트

a. NiFi 서버를 stop and start 시킨다.(/home/ubuntu/app/nifi-1.11.4/bin/nifi.sh stop, /home/ubuntu/app/nifi-1.11.4/bin/nifi.sh start)

b. NiFi 서버(https://xxx.xxxxx.com/nifi)로 다시 접속을 한다.

c. 아래와 같이 로그인을 위해 구글 계정을 선택 또는 입력하는 화면에서 authorizers.xml에 등록한 구글 계정을 선택 또는 입력한다.

(그림 8. 구글 계정 선택 또는 입력)

d. 아래와 같이 입력한 구글 계정의 비밀번호를 입력한다.

(그림 9. 구글 계정의 비밀번호)

e. 아래와 같이 NiFi 캔버스가 오픈되고, 좌측 상단에 구글 이메일 계정이 보이면 정상적으로 로그인이 된것이다.

(그림 10. OpenID Connect 방식으로 로그인 한 화면)

: 로그인에 성공하면 1)과 같이 구글 계정이 표시된다. 로그 아웃을 하기 위해서는 1)에서 "LOG OUT" 링크를 클릭하면 정상적으로 로그 아웃된다. "LOG OUT" 링크를 클릭했을때 자동으로 다시 로그인이 된다면 구글 사이트로 이동해서 구글 계정 자체를 로그아웃한 다음에 다시 한번 시도한다.

Apache NiFi에 SSL 적용

Kevin's IT Village — Fri, 9 Jul 2021 15:33:27 +0900

: NiFi 서버에 로그인 화면을 적용하기 위해서는 SSL 연동이 필수이다. 현재(2020년 5월 12일 기준) EC2에 생성된 NiFi 서버의 SSL 인증서는 Self Signed Certificate을 사용하였으며, OpenSSL 툴을 사용하지 않고 좀 더 빠르게 Self Signed Certificate을 생성하기 위해 TinyCert(https://www.tinycert.org/)를 이용하였다.

(1) 인증서 생성 : NiFi 서버에 SSL 설정을 하기 위해서는 먼저 TinyCert 에서 CA 인증서와 서버 인증서를 생성 및 다운로드해야하는데 절차는 다음과 같다.

a. TinyCert에 접속하여 먼저 Sing Up을 한다. Email Address와 Password, Passphrase를 입력 해야 하는데 Passphrase는 서버 인증서를 NiFi 서버에 구성할때 필요하므로 기억을 해야한다.

b. TinyCert에 로그인이 된 상태에서 아래 (그림 1. CA 생성)에서와 같이 메인 화면에서 CA 인증서를 생성한다.

(그림 1. CA 생성)

1) "Create" 버튼을 클릭하여 CA 인증서를 생성한다. CA 인증서 항목은 적절하게 입력해주면 된다.

c. 서버 인증서 생성

(그림2. 서버 인증서 생성)

1) "Create" 버튼을 클릭해서 서버 인증서를 생성한다. 서버 인증서 항목은 적절하게 입력해주면 된다.

d. CA 다운로드

(그림3. CA 다운로드)

1) "다운로드" 버튼을 클릭해서 CA 인증서를 다운로드한다.

e. 서버 인증서 다운로드

(그림 4.1. 생성된 서버 인증서 목록)

1) 생성된 서버 인증서 목록을 클릭한다.

(그림 4.2. 생성된 서버 인증서 상세)

1) "다운로드" 버튼을 클릭해서 서버 인증서를 다운로드 버튼을 클릭한다.

2) 서버 인증서 타입을 "PKCS#12 Archive" 타입으로 선택하면 서버 인증서가 다운로드 된다.

(2) NiFi 서버에 인증서 업로드 : 로컬 PC에 다운로드 받은 CA 인증서와 서버 인증서를 AWS EC2에 설치된 NiFi 서버쪽으로 업로드를 해야하는데 이를 위해서는 EC2 인스턴스에 해당하는 Private Key가 필요하다. Private Key는 개발 담당자(2020년 5월 12일 기준: 황정식)에게 문의한다. 아래 링크의 문서를 참조해서 다운로드 받은 CA 인증서와 서버 인증서를 NiFi 서버쪽으로 업로드한다.

a. SCP 파일 전송 관련 문서 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

b. 현재(2020년 5월 12일 기준) 업로드된 CA 인증서와 서버 인증서의 디렉토리 경로는 (그림 5. CA 인증서와 서버 인증서의 디렉토리 경로)와 같다.

(그림 5. CA 인증서와 서버 인증서의 디렉토리 경로)

1) CA 인증서와 서버 인증서가 위치한 디렉토리 경로이다.

2) 로컬 PC에서 업로드 된 CA 인증서이다.

3) 로컬 PC에서 업로드 된 서버 인증서이다.

(3) Truststore 생성 : NiFi 서버는 SSL 설정을 위해서 서버 인증서와 추가적으로 Truststore를 생성해야하는데 Truststore는 로컬 PC에서 업로드한 CA 인증서를 이용해서 (그림 6. Truststore 생성)과 같이 생성할 수 있다.

(그림 6. Truststore 생성)

1) <ca_file> 부분은 로컬 PC에서 업로드한 CA 인증서 파일명이며, <password>에는 패스워드를 입력하면 된다. 설정된 패스워드에 대해서는 개발 담당자(2020년 5월 12일 기준: 황정식)에게 문의한다.

(4) nifi.properties 설정 : nifi.properties 파일을 열어서 SSL 포트, KeyStore, Truststore 설정을 해준다.

a. HTTPS 설정 : NiFi 서버는 http와 https를 동시에 운용할 수 없기때문에 (그림7.1. HTTPS 설정)과 같이 프로퍼티 값을 수정한다.

(그림 7.1. HTTPS 설정)

1) "nifi.remote.input.secure" 프로퍼티의 값을 "true"로 수정한다.

2) "nifi.remote.input.http.enabled" 프로퍼티의 값을 "false"로 수정한다.

3) "nifi.web.https.port" 프로퍼티의 값을 "9443"으로 수정한다. NiFi의 https 디폴트 포트는 9443이다.

4) 그림 7.1에는 빨간 박스로 표시 되어 있지만 "nifi.web.https.host" 프로퍼티의 값으로 NiFi 서버와 매핑된 도메인을 입력해야지만 다음 글에서 설명하는 OpenID Connect 방식의 로그인을 사용할 수 있다.

b. KeyStore 및 Truststore 설정: CA 인증서를 이용해서 생성한 Truststore와 서버 인증서 설정을 (그림 7.2. KeyStore 및 Truststore 설정)과 같이 추가한다.

(그림 7.2. KeyStore 및 Truststore 설정)

1) "nifi.security.keystore" 프로퍼티의 값으로 서버 인증서의 경로를 입력한다.

2) "nifi.security.keystoreType" 프로퍼티의 값으로 "PKCS12"를 입력한다.

3) "nifi.security.keystorePasswd" 프로퍼티의 값으로 TinyCert에서 Sign up 시, 등록한 passphrase 값을 입력한다.

4) "nifi.security.truststore" 프로퍼티의 값으로 CA 인증서를 이용해서 생성한 Truststore의 경로를 입력한다.

5) "nifi.security.truststoreType" 프로퍼티의 값으로 "JKS"를 입력한다.

6) "nifi.security.truststorePasswd" 프로퍼티의 값으로 Truststore를 생성할 때 설정한 패스워드를 입력한다.

(5) hosts 파일 설정 : NiFi 서버에 접속하는 사용자는 (6)에서 설명할 도메인을 통해서 NiFi 서버에 접속을 할 수 있는데, 이 도메인은 EC2에서 추가한 외부 IP인 탄력적 IP와 매핑이 되어 있다. 하지만 NiFi 서버 입장에서는 EC2 인스턴스 내부 IP와 매핑이 되어야하므로 hosts 파일에 매핑 정보를 추가해주어야 한다.

a. hosts 파일의 경로 : /etc/hosts

b. 내부 IP는 "hostname -I" 명령어로 확인 가능하며, NiFi 서버가 설치된 EC2 인스턴스의 내부 IP는 "172.31.34.156" 이다.

b. (그림 8. 도메인과 내부 IP 매핑 정보)와 같이 매핑 정보를 추가해준다.

1) EC2 인스턴스의 내부 IP와 도메인 매핑 정보를 hosts 파일에 추가한다.

(6) 접속 테스트

a. nifi.sh 명령을 사용해 NiFi 서버를 가동 시킨다. nifi.sh 전체 명령어는 아래와 같다.

ubuntu@ip:~/app/nifi-1.11.4$ pwd
/home/ubuntu/app/nifi-1.11.4
ubuntu@ip:~/app/nifi-1.11.4$ bin/nifi.sh start

b. 아래 주소로 접속을 해본다.

https://도메인:9443/nifi

1) NiFi 서버쪽에 정상적으로 접속이 되지 않는 이유는 NiFi 서버는 SSL 설정이 완료되면 추가적으로 로그인 설정을 해주어야 한다. 접속 시, 발생하는 에러는 SSL 설정은 되어 있으나 로그인 설정이 되어 있지 않았기때문에 발생하는 에러이다.

다음 글에서는 NiFi 로그인 인증 방식중에 하나인 OpenID Connect 설정을 해보겠습니다.

Hello Reactor 들여다 보기

Kevin's IT Village — Wed, 6 Jan 2021 10:30:56 +0900

안녕하세요? [Kevin의 알기 쉬운 RxJava] 강의를 진행하고 있는 Kevin입니다.

이번 시간에는 'Hello, Reactor' 코드를 가지고 Reactor의 기본 구조를 들여다보는 시간을 가져보겠습니다.

개발에 처음 입문하실때 대부분 'Hello World!' 코드를 실행해보셨을텐데요. Reactor 역시 마찬가지로 'Hello, Reactor' 메시지를 출력해보면서 Reactor의 기본 구조를 간단하게 살펴보도록 하겠습니다.

어렵지 않으니 가벼운 마음으로 글을 읽어주시면 감사드리겠습니다.^^

먼저 아래의 코드를 보시죠.

[Hello Reactor 코드]

여러분들이 아시다 시피 Reactor는 RxJava와 마찬가지로 Reactive Streams라는 표준 사양을 구현한 구현체입니다. 따라서 Reactive Streams에서 정의하고 있는 생산자 즉, Publisher와 소비자 즉, Subscriber를 구현하고 있는데요.

위의 코드에서 보시는것처럼 Reactor에서는 Flux가 대표적인 생산자 중에 하나입니다.
위의 코드에서 소비자라고 되어 있는 부분은 람다 베이스 Subscriber가 되겠습니다.

생산자 쪽에서는 just라는 Operator(연산자)를 사용해서 두 개의 데이터를 소비자 쪽으로 통지를 하는데요. Reactor에서는 생산자 쪽에서 통지할 데이터를 정의하는 과정 자체를 묶어서 'Sequence(시퀀스)'라고 합니다. 이 Sequence라는 용어는 Reactor를 접하다보면 자주 나오는 용어이니 기억을 해두시길 바래볼게요.

생산자 쪽에서 소비자 쪽으로 데이터를 통지하는것이 맞긴하지만 최종 소비자까지 데이터가 전달 되기까지는 중간에 여러 Operator를 만날 수 있기때문에 엄밀히 말하자면 생산자가 소비자에게 데이터를 통지한다라고 말하기보다는 생산자가 Downstream으로 데이터를 내보낸다라는 표현이 더 정확할 것 같네요.

용어에 대한 부분은 아래쪽에서 다시 정의를 해보도록 하구요.

아무튼 생산자 쪽에서 데이터를 통지하게 되면 최종 소비자 쪽에 바로 데이터가 전달되는 것이 아니라 map( )이라는 Operator에서 원본 데이터가 가공 처리 된 후에 최종 소비자 쪽으로 전달이 되는것을 볼 수 있는데요.

여기서는 통지된 String 데이터를 소문자로 변환을 한 후에 최종 소비자쪽으로 전달하고 있네요.

자, RxJava 강의 시간에도 말씀을 드렸지만 리액티브 프로그래밍은 크게 세가지의 step으로 이루어져있습니다.

1 step : 생산자가 데이터를 통지한다.
2 step : 통지된 데이터를 Operator로 가공한다.
3 step : 가공 처리된 데이터를 최종 소비자에게 전달한다.

이 세가지 큰 흐름은 기본적으로 꼭 기억을 해두시고, 나머지는 데이터를 통지하는 다양한 방법, 데이터를 가공하는 다양한 방법, 비동기 프로그래밍을 위한 쓰레드를 할당하는 방법, 에러 처리 방법 등을 단계적으로 적용 하는 식으로 학습을 진행해 나가면 리액티브 프로그래밍을 조금 더 수월하게 이해하실 수 있을거라는 생각이 드네요. ^^;

자, 그럼 마지막으로 Reactor에 대한 에피소드를 계속 진행가기 전에 Reactor에서 사용되는 여러가지 용어를 정의하고 에피소드를 마무리 하도록 하겠습니다.

먼저 아래 용어들을 보시죠.

Publisher : 발행자, 게시자, 생산자, 방출자(Emitter)
Subscriber : 구독자, 소비자
Emit : Publisher가 데이터를 내보내는 것(방출하다. 내보내다. 통지하다.)
Sequence : Publisher가 emit하는 데이터의 연속적인 흐름. 스트림과 같은 의미라고 보면 됨
Subscribe : Subscriber가 Sequence를 구독하는 것
Dispose : Suscriber가 Sequence 구독을 해지 하는 것
Downstream : 현재 Operator 체인의 위치에서 봤을때 데이터가 전달 되는 하위 Operator 및 method 체인
Upstream : 현재 Operator 체인의 위치에서 봤을때 상위 Operator 및 method 체인

여태껏 제가 데이터를 통지하는 쪽은 생산자로 지칭했는데요. 보시는대로 생산자 이외에 발행자, 게시자, 방출자 등 다양하게 사용이 되고 있습니다. 모두 같은 의미라고 보시면 되겠지만 앞으로 에피소드를 진행할 때는 그냥 영어로 Publisher라고 지칭하도록 하겠습니다. ^^;

따라서 소비자 역시 영어로 Subscriber라고 지칭하면 되겠구요.

데이터를 통지하는 행위 역시 영어 그대로 Emit 한다라고 하겠습니다.

Sequence는 위에서 잠깐 말씀 드렸죠? Publisher쪽에서 데이터를 emit하는 흐름 자체를 통칭하는 것을 의미하는데, 예를 들어서 Flux라는 Publisher가 데이터의 Emit을 정의하는 부분을 설명할때 Sequence를 생성한다 라고 표현할 수 있겠습니다.

Subscribe와 Dispose는 구독하다, 구독을 해지하다라고 표현하도록 하겠습니다.

마지막으로 Downstream과 Upstream이라는 용어인데요. Reactor를 학습하다보면 종종 나오는 용어인데 개념적으로 이해하기 모호한 면이 있는 용어중에 하나이기도 합니다.

이럴때는 그냥 단순하게 이해를 하는게 제일 좋을거라고 생각을 해보게되네요. ^^;
예를 들어 위의 코드에서 just( )의 위치에서 Downstream은 map( )부터 subscribe( )까지 하위 체인이 되겠습니다. 그리고 subscribe( ) 입장에서는 map( )과 just( )가 Upstream이 되겠구요.

just( )의 내부를 들여다보면 return 값으로 Flux를 반환하는데요. just( )에서 반환하는 Flux를 원본 Flux가 되겠습니다. 그리고 map( )에서 반환하는 return 값 역시 Flux인데요. 여기서의 Flux는 원본 Flux가 아닌 가공 처리된 데이터를 가지고 있는 새로운 Flux입니다.

Flux(또는 Mono)의 이러한 처리 흐름때문에 Downstream이나 Upstream이라는 용어가 생겨난것 같은데 위에서 언급드린것처럼 단순하게 생각해주시면 될것 같아요.

자, 오늘은 'Hello, Reactor' 코드를 통해서 Reactor 의 기본 구조를 살펴보았는데요.
다음 시간에 다른 에피소드를 가지고 다시 찾아뵙도록 하겠습니다. ^^

감사합니다!

[Kevin의 알기 쉬운 RxJava 1부] 강의 바로가기

Kevin의 알기 쉬운 RxJava 1부 - 인프런

리액티브 프로그래밍이라는 진입 장벽을 넘고 싶으신가요? Kevin의 알기 쉬운 RxJava가 그 벽을 넘을 수 있는 힘을 키워드리겠습니다. 초급 프레임워크 및 라이브러리 함수형 프로그래밍 RxJava Reacti

www.inflearn.com

[Kevin의 알기 쉬운 RxJava 2부] 강의 바로가기

Kevin의 알기 쉬운 RxJava 2부 - 인프런

www.inflearn.com

이벤트 루프란?

Kevin's IT Village — Wed, 6 Jan 2021 09:29:55 +0900

수강생 여러분 안녕하세요. RxJava 강의를 진행하고있는 Kevin입니다. 오늘은 리액티브 프로그래밍과 밀접한 관련이 있는 이벤트 루프에대해서 잠시 알아보도록하겠습니다.

이벤트 루프에 대해서 먼저 이야기 하기 전에 저희는 서블릿에 대한 언급을 먼저 하고 넘어가야되는데, 그 이유는 이벤트 루프라는 개념이 나오게 된 배경에는 서블릿이 있기때문이에요.

그럼 서블릿에 대한 이야기를 먼저 해볼까요?

서블릿의 기본 개념

서블릿은 뭘까요? 자바를 사용하는 개발자이거나 자바를 배우고 계신 분들이 웹 애플리케이션을 만들어 보셨다면 이미 서블릿을 사용해보셨을겁니다. 여러분들이 JSP를 사용해보셨거나 아니면 Spring framework을 사용해보셨다면 여러분들은 알게 모르게 서블릿이란 놈을 사용해보셨다는 말씀. ^^

서블릿은 웹에서 클라이언트의 요청을 동적으로 처리하기 위해 서블릿 규약이라는 일정한 규칙에 맞춰서 작성되는 클래스인데요. 이 클래스들이 클라이언트로 부터 들어오는 요청을 받아서 응답으로 되돌려주는 역할을 하죠.

개발자가 작성한 서블릿 클래스가 HttpServlet을 상속 받고, doGet( ), doPost()를 구현하는 것이 서블릿 클래스의 기본이라는 사실은 서블릿 클래스를 사용해보신분들은 너무나 잘 알고들 계실겁니다.

Spring에서의 서블릿

어쨌든 저희가 HttpServlet 같은 상위 클래스를 상속 받아서 개발을 진행할건 아니기때문에 서블릿에 대해서 더 자세한 이야기를 할 필요는 없을 것을 같네요. 다만, 이것 하나만은 기억을 하셔야 될 것 같습니다. Spring MVC 역시 내부적으로는 Servlet 기술을 사용을 한다는것을요. DispatcherServlet 이라는 녀석을 기억하시죠? Spring MVC에서는 이 DispatchServlet이라는 녀석이 최앞단에서 클라이언트의 요청을 전달 받아서 해당 요청에 매핑되는 Controller 에게 요청을 전달한다는 사실은 Spring MVC로 개발을 해보신분들은 잘 알고 계실겁니다.

서블릿 방식의 문제점

그런데 이러한 서블릿을 사용하여 클라이언트의 요청을 처리하는 방식에는 큰 문제점이 하나 있는데요. 서블릿 방식은 클라이언트에서 요청이 들어오면 해당 요청을 처리하기 위해서 요청 당 쓰레드 하나씩을 생성해서 처리합니다. 하나의 쓰레드에서 클라이언트의 요청을 다 처리하면 이 쓰레드는 쓰레드풀이라는 쓰레드의 저장소에 다시 반납이 되는데, 참고로 이 쓰레드 풀은 톰캣 같은 서블릿 컨테이너가 관리를 해줍니다. 사실 클라이언트의 요청이 폭주만 하지 않으면 지금과 같은 서블릿 방식이 큰 문제가 되지는 않겠지만 클라이언트의 요청이 쓰레드의 갯수에 비해 기하급수적으로 늘어나는 순간 문제가 시작됩니다. 요청을 처리하기 위한 쓰레드가 쓰레드 풀에 남아있지 않을 경우 기존에 사용되던 쓰레드가 쓰레드 풀에 다시 반납이 되어 다른 요청을 처리하기 위해서 재사용할 수 있 때까지 클라이언트로 부터 들어온 요청들은 대기를 해야되니까요. 이런 성능상의 문제점을 상당 부분 해소할 수 있는 방식이 바로 이벤트 루프 방식인데요. 그럼 이벤트 루프 방식이 무엇인지, 어떻게 클라이언트의 요청을 효과적으로 처리하는지 간단하게 살펴볼까요?

이벤트 루프란

아래 그림을 보면서 이벤트 루프에 대해서 설명 드리겠습니다.

클라이언트가 서버로 요청을 보내면 요청 핸들러가 클라이언트의 요청이 들어왔다는 이벤트를 이벤트 루프에 푸시합니다.

이벤트 루프는 그림과 같이 계속해서 루프를 돌면서(한마디로 무한루프) 요청 핸들러로부터 푸시된 이벤트를 감지합니다. 그리고 나서 해당 이벤트에 대한 콜백을 등록한 후, 클라이언트가 요청한 작업을 처리합니다. 작업이 끝나면 작업이 끝났다는 이벤트를 이벤트 루프에 푸시하고 등록된 콜백을 호출한 후, 요청 핸들러를 다시 거쳐서 클라이언트에게 최종적으로 응답을 되돌려줍니다. 어떠신가요? 이벤트 루프가 무엇인지 대충 감이 오시는지 모르겠네요.

이벤트 루프 방식의 장점은 쓰레드 하나로 굉장히 많은 요청을 병렬로 처리하기때문에 기존의 서블릿 방식의 성능상의 문제를 해결한다는것입니다.

WebFlux와 이벤트 루프

Spring WebFlux가 바로 이벤트 루프 방식을 사용하기때문에 대량의 클라이언트 요청을 효과적으로 처리할 수 가 있게되었는데요. Spring WebFlux를 사용해서 대량의 클라이언트 요청을 효과적으로 처리하는 애플리케이션을 한번 만들어보고 싶어지지 않으셨나요? ^^;

Spring MVC냐 Spring WebFlux냐

자, 그러면 무조건적으로 Spring MVC 대신에 Spring WebFlux를 사용하면 좋은것이냐하면 사실 그건 아닌것같습니다. Spring MVC로 개발을 진행해보셨다면 아시겠지만 생산성이 대단하다는것을 느끼실 수가 있을겁니다. 그리고 RxJava 2부 강의에서 비동기 방식의 디버깅에 대한 이야기를 드리겠지만 비동기 방식보다는 동기 방식이 디버깅도 용이하고 여태껏 사용해온 익숙한 명령형 프로그래밍 방식으로 코드를 짜면 되니 코드를 짜는 부담 역시 줄어드는게 사실일테구요. 하지만 분명한것은 사물 인터넷, 자동차, 인공 지능 등등 우리가 생각하는 전통적인 클라이언트 이외에 다양한 클라이언트들이 계속해서 생겨날텐데 이런 종류의 클라이언트들이 계속해서 생겨나면 생겨날수록 서버가 감당해야 되는 요청의 수는 점점 늘어나겠죠. 마이크로 서비스로 인해서 또한 서비스들 간의 요청도 점점 늘어나고 있기도 하구요.

결론은 지금 당장은 아니더라도 개발자로서 미래를 준비하고 싶으신 분은 리액티브 프로그래밍 기법을 꼭 익혀두셨으면 하는 바램입니다. ^^ 이야기는 길었는데 결론은 꽤 간단하다는.. ^^;;

오늘은 이벤트 루프에 대한 이야기를 간단하게 해보았는데요. Spring WebFlux에 대한 이야기로 또 찾아뵙도록 할게요.

감사합니다~

[Kevin의 알기 쉬운 RxJava 1부 강의] 바로 가기

Kevin의 알기 쉬운 RxJava 1부 - 인프런

www.inflearn.com

[Kevin의 알기 쉬운 RxJava 2부 강의] 바로 가기

Kevin의 알기 쉬운 RxJava 2부 - 인프런

www.inflearn.com

리액터와 WebFlux

Kevin's IT Village — Wed, 6 Jan 2021 09:02:41 +0900

여러분 안녕하세요? [Kevin의 알기 쉬운 RxJava 강의]를 진행하고 있는 Kevin이라고 합니다. 지난번 공지에서 잠깐 말씀을 드렸다시피 매주 한두번 정도 시간을 내서 강의에서 제대로 얘기하지 못했던 리액티브 프로그래밍에 대한 뒷 얘기들을 조금씩 해볼까 합니다. 리액티브 프로그래밍을 배우고자 하시는 분들께 조금이나마 더 도움이 되길 바래보겠습니다.

리액터(Reactor)란 무엇일까요?

리액티브 프로그래밍에 대해서 처음 들으시는 분들은 리액터에 대해서 당연히 모르실거 같은데 아마도 스프링을 학습하면서 들어 보신분도 있지 않을까하는 생각도 들긴하네요. ^^예상하신분도 계시겠지만 리액터는 Java로 구현 된 리액티브 프로그래밍의 한 종류입니다. 더 정확히 얘길 하자면 Reactive Streams를 구현한 구현체라고 볼 수 있는데요.강의를 수강하신 분들은 이미 알고 계시지만 RxJava 역시 Reactive Streams를 구현한 구현체의 하나라고 볼 수 있습니다. 일반적으로 Reactive Streams를 구현한 구현체들은 대부분 Rx~로 시작을 하는데 Reactor는 그것보다 더 확실하게 "나는 리액티브 프로그래밍을 사랑하는 Reactor야" 라고 얘길 하는것 같군요.^^Reactor라는 이름에서 리액티브 프로그래밍의 느낌이 팍팍 오지 않으신가요?ㅎ

리액터(Reactor)를 배워야 할까 말아야 할까

결론부터 말씀드리자면 리액티브 프로그래밍을 배우기로 하셨다면 리액터는 배우는것이 맞다고 생각합니다. 두가지 이유만 얘길 드리자면 먼저 리액터를 통해서 저희는 명령형 프로그래밍의 한계를 넘어설 수 있는 그리고 시대에 맞는 개발 패러다임을 이해하고 실무에 점차적으로 사용을 하게 될 것입니다. 끊임없이 생산되는 데이터를 효과적인 비동기 상태로 처리할 수 있어야 한다는 사실은 필연적이라는 생각이 드니까요. 그렇기 때문에 Reactor는 꼭 학습을 하시는게 좋을 것이라는 생각이 드네요.

굳이 왜 리액터일까?

근데 왜 굳이 리액터를 배워야 되는가.. 라고 생각을 하실수도 있겠네요.^^; 저희는 지금 RxJava를 배우고 있는데 말이죠. 음.. Java 애플리케이션을 개발해보신 분들은 아시겠지만 Java 애플리케이션을 개발하면서 Spring Framework을 빼놓고 얘기하는게 어려워진 것은 오래되었습니다.물론 Spring을 사용하지 않고, 애플리케이션을 만들 수는 있지만 Spring을 일단 한 번 사용하게되면 Spring 없이 개발하겠다고 얘기하는 분들은 많지 않을거 같아요.Spring 얘기를 왜 하느냐하면 Reactor가 바로 Spring5에서 지원하는 Reactive 프로그래밍의 기본이 되기 때문인데요. Spring을 사용하시는 분들, 그리고 앞으로 Spring을 접하실 분들이라면 Spring과 궁합이 딱 맞는 Reactor를 배우지 않을 이유가 있을까 싶습니다. Spring과 Reactor를 사용해서 Spring MVC 기반의 애플리케이션 대신에 리액티브 애플리케이션을 만들어보는것. 재미있을 것 같지 않나요? ^^

그럼 RxJava는 배우지 말라는거?

그건 당연히 아닙니다. 제가 RxJava 강의를 오픈한 가장 큰 이유 중에 한 가지는 RxJava라는 기술 자체 보다는 리액티브 프로그래밍에 대해서 알려드리고 싶어서이기 때문인데요. 리액티브 프로그래밍은 처음 접하게 되면 이해하기가 쉽지 않기때문에 리액티브 프로그래밍에 대한 기본 개념을 잡을 수 있도록 하는것이 제 강의의 가장 큰 목표라고 볼 수 있습니다. 그런 의미에서 제 강의는 다른 의미로 여러분들한테 충분히 의미있는 강의가 될거라고 믿어보겠습니다.^^제 강의를 듣고 Reactor를 접하게 된 후에 생각했던 것보다 Reactor가 어렵지 않구나라는 얘기를 꼭 들었으면 좋겠네요. ^^

Reactor는 이제 알겠는데 WebFlux는 뭐지?

저희 강의를 조금이라도 수강을 하신 분들은 알고 계실텐데요. RxJava에서 데이터를 통지(또는 발행, 방출)하는 생산자의 역할을 하는 놈이 Observable, Flowable, Single, Maybe 등인데, Reactor에서 이러한 역할을 하는 놈이 바로 Flux와 Mono라는 놈입니다.RxJava에서는 데이터를 한 건만 통지할 때에는 Single을 사용하고, 데이터를 한 건도 통지하지 않거나 한 건만 통지할 때는 Maybe를 사용 하죠. 그리고 데이터를 한 건 이상 통지할 때에는 Observable 또는 Flowable을 사용을 합니다. 뭔가 좀 복잡하죠? Reactor에서는 이걸 조금 단순화해서 Mono라는 놈은 딱 한 건의 데이터만 처리하고, Flux는 한건도 통지하지않거나 한건 이상 통지하는데 사용을 하도록했습니다.Flux에 대해서 말씀을 드렸으니 WebFlux는 무얼하는 놈인지 대충 감이 오시죠?
'혹시 Web에서 사용하는 Flux?' 맞습니다.^^ Spring MVC가 웹 계층에 특화된 웹프레임워크인 것과 마찬가지로 WebFlux는 웹 계층에서 비동기 처리를 하는데 특화된 리액티브 프로그래밍 기반의 웹 프레임워크라고 할 수 있습니다. 그러니까 우리는 WebFlux라는 저놈을 Spring MVC 처럼 효과적으로 잘 사용 하기 위해서 Reactor를 먼저 배우게 되는 것입니다. 구체적으로 어떻게 사용하는지는 아직 자세히 모르더라도 WebFlux가 대충 뭐하는 놈인지는 대충 이해가 되시죠?그러면 Reactor의 Flux를 사용하는 코드 예시를 조금 살펴보고 오늘 이야기를 마무리 하도록할게요. 먼저 RxJava에서 사용하는 코드부터 간단하게 살펴보겠습니다.

@Test
public void ObservableFilterTest() {
	Observable<Integer> observable = Observable.just(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
		.filter(n -> n % 2 == 0);

    observable.test()
    		.assertValues(2, 4, 6, 8, 10)
    		.assertComplete();
}

RxJava 2부 강의에서 만나보시겠지만 Observable에서 통지하는 데이터들에 대한 Unit Test 코드입니다. Observable의 just() 함수를 사용해서 1부터 10까지 10개의 데이터를 통지하면 filter() 함수에서 통지된 데이터를 2로 나눈 나머지가 0인 숫자 즉, 짝수인 숫자만 필터링을 해서 최종적으로 소비자 쪽에 통지를 하는 간단한 코드인데요.이렇게 통지된 데이터가 정상적으로 소비자 쪽에 전달이 되는지 검증하기 위해서 Observable의 test() 함수를 이용해서 검증을 합니다.자, 그러면 이번에는 Reactor에서 사용하는 코드를 한번 보실까요?

@Test
public void fluxFilterTest() {
  Flux<Integer> flux = Flux.just(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
  		.filter(n -> n % 2 == 0);

  StepVerifier.create(flux)
  		.expectNext(2, 4, 6, 8, 10)
 	 	.verifyComplete();
}

Flux의 just()함수를 사용해서 1부터 10까지 10개의 데이터를 통지하면 filter()함수에서 역시 짝수인 숫자만 필터링을 해서 소비자 쪽에 통지를 합니다. 그러면 StepVerifier 클래스를 이용해서 소비자 쪽에 전달되는 데이터를 검증을 하고 있습니다.RxJava와 거의 똑같다는거 느껴지시죠? 그렇기때문에 여러분들은 저희 강의를 통해서 리액티브 프로그래밍의 기본 개념을 확실하게 자기 것으로 만든 후에 Reactor의 코드를 보면 '아.. 어렵지 않네?'라고 말씀하실수 있을거라고 생각합니다. ^^그럼 저는 다음 시간에 리액티브 프로그래밍의 또 다른 에피소드를 가지고 다시 뵙도록 할게요. 감사합니다!

Kevin의 알기 쉬운 RxJava 1부 강의 바로가기

Kevin의 알기 쉬운 RxJava 1부 - 인프런

www.inflearn.com

Kevin의 알기 쉬운 RxJava 2부 강의 바로가기

Kevin의 알기 쉬운 RxJava 2부 - 인프런

www.inflearn.com

현실적인 개발자 로드맵(8) - Angular 그리고 최종 로드맵

Kevin's IT Village — Tue, 29 Jan 2019 21:31:36 +0900

현실적인 개발자 로드맵(8) - Angular 그리고 최종 로드맵

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-angular 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, Kevin입니다. 계속되는 육아로 인해서 포스팅을 짧은 주기로 할수는 없는 상황이 반복이 되고 있네요. ㅡ,.ㅡ 그래도 여전히 짬을 내어 최선을 다해보도록하겠습니다.

자, 이번 시간은 개발자 로드맵 시리즈의 마지막 시간입니다. 사실 로드맵 시리즈를 진행을 하고자한다면 얼마든지 더 시리즈를 만들어낼 수 있는데요. 8회에서 마무리 하려는 이유는.. 로드맵은 단지 로드맵일 뿐이기때문에 어떤 언어나 기술, 방법론 등에 대해서 구체적인 지식을 전하기가 힘이 들죠. 구체적인 지식을 전하는것이 주목적이 아니기때문에 로드맵인것이기도 하구요. 결론은 전하고 싶은 지식들이 많이 있는데 언제까지 로드맵 시리즈만 이야기하고싶지 않기때문입니다.^^;

그렇기때문에 이번 시간에는 Front-end쪽 이야기를 살짝하고 이때까지 마인드맵으로 그려온 자바 개발자 로드맵을 최종적으로 정리하는 시간을 가져보겠습니다.

자, 그럼 먼저 Front-end쪽 기술을 로드맵에 추가하기 위한 이야기를 먼저 해보도록 하겠습니다.

SPA란?

Front-end 쪽 개발을 하시는 분이라면 SPA라는 용어를 들어보셨을겁니다. 아직 들어보지 못하신분은 당연히 SPA 방식으로 개발을 해본적이 없으신 개발자분들이실테구요. SPA란 Single Page Application의 약자인데요. 우리말로 하면 단일 페이지 방식의 애플리케이션 정도로 해석을 할 수 있을텐데요. 초보 분들에게는 단일 페이지 방식이라는게 선뜻 와닿지 않을수도 있습니다.

더 이해하기 쉽게 얘기하자면 한마디로 웹브라우저에서 보여지는 화면들이 바뀔때 웹브라우저 자체가 refresh가 되지 않는 애플리케이션이라고 말할 수 있겠습니다.

refresh 되지 않는다.. 즉, 화면이 새로고침하지 않는다라는 것인데 개발자 로드맵 시리즈에서 Ajax에 대한 이야기를 한적이 있는데 Ajax 기술이 바로 화면이 새로고침 되지 않는 방식이라고 말씀을 드렸더랬습니다. 그렇기때문에 SPA 방식의 애플리케이션에 필수적인 통신 기술이 바로 Ajax라고 할 수 있겠습니다.

JSP, ASP, PHP 같은 웹 애플리케이션은 기본적으로 서버와 통신하면서 화면이 바뀔때 화면이 새로고침되는 방식입니다. 웹브라우저에 보이는 화면 전체에 대한 HTML 코드들을 서버로부터 한번에 내려받기때문인데요.

물론 이전 로드맵 포스팅에서도 말씀드린적 있지만 JSP 같은 서버사이드 언어에서도 jQuery의 Ajax 통신을 사용해서 화면의 일부분만 갱신되도록 할 수 있습니다. 개발자 로드맵 jQuery 편에서 실제로 TODO 애플리케이션 전체 화면에서 할일을 등록하면 화면의 새로고침 없이 할일 목록만 바뀌도록 했으니까요.

하지만 jQuery만 사용을 해서 SPA를 구현한다는것은 사실 무리가 있습니다. SPA를 구현하는것에 무리가 있다는것이지 jQuery에 문제점이 아주 많아서 사용하지 말아야한다는것은 아닙니다. 현재까지 Front-end 기술의 트렌드는 SPA로 바뀌고 있는 추세이긴하지만 여전히 심플하고 작은 애플리케이션을 만드는데는 jQuery가 많이 사용되고 있고 성능상으로도 큰 무리가 없는게 사실이니까요.

그렇긴하지만 기술 트렌드를 따라가다보면 필연적으로 SPA라는 용어를 만나게될것이고 꼭 익혀야되는 개발 방식이기도합니다. 기술 트렌드를 쫓아서 끊임없이 시도하고 시행착오를 거치는 기업은 그렇지 않은 기업보다 개발자가 일하기 더 좋은 기업일 가능성이 높다는 사실 꼭 염두에 두시면 좋으실것 같네요.

SPA 구현을 위한 프레임워크 또는 라이브러리 선택

자, 그럼 SPA를 구현하기 위한 자바스크립트 프레임워크나 라이브러리를 선택하여 TODO 애플리케이션을 SPA로 바꿔보도록 하겠는데요. 현재 가장 많이 사용하고 있는 기술은 Angular, Vue.js, React 라고 볼 수 있겠습니다. 이 중에서 Angular와 Vue.js는 프레임워크이고, React는 라이브러리입니다. 세가지 기술 모두다 각각의 장점과 단점을 가지고 있는데요. 이 세가지 기술에 대한 비교 설명이 다음 링크에 잘 나와있습니다.

Angular vs Vue.js vs React 비교 : https://kr.vuejs.org/v2/guide/comparison.html#Angular-Formerly-known-as-Angular-2

그중에서 저는 Angular를 사용하여 TODO 애플리케이션을 구현하였습니다. Angular를 선택한 이유는 많은 개발자들이 Angular는 Vue.js나 React보다 유연성이 떨어진다고들 얘기들하시는데요. 그 떨어지는 유연성이 오히려 생산성 측면에서는 도움이 될 수도 있다는 사실. ^^ (사실 Angular 말고 Vue.js와 React는 사용을 해본적이 없다는것도 큰 이유중에 하나입니다. ^^;) 여기서 말하는 유연성은 애플리케이션의 구조와도 관계가 있는데요. Angular의 경우 애플리케이션의 구조가 자바스크립트 class를 통해서 구조화가 잘되어 있습니다. 그렇기때문에 생산성이나 유지보수 측면에서 더 나은 결과를 가져다 준다는게 개인적인 생각이기도 합니다.

그리고 Angular의 단점 중에 하나가 가파른 학습곡선이다라고 말씀을 하시기도 하는데요. 학습에 대한 시간을 일정 부분 투자를 해야하는건 사실이긴하지만 이건 개개인마다 약간씩 틀리지 않을까 싶네요. 설령 학습 곡선이 가파르다고 하더라도 학습 자체가 상당히 재미있다는게 제 개인적인 생각이며 또한 Google에서 주도하는 오픈 소스이기때문에 학습을 위한 컨텐츠도 상당히 많이 제공되고 있는편입니다.

혹시 시간이 되시는 분들은 Vue.js나 React까지 공부하셔서 이 세가지 기술을 비교해보는것 역시 개인적인 성장에 도움이 되지 않을까 싶네요.

자, 그럼 Angular를 사용하여 이전 시간에 jQuery로 만든 TODO 애플리케이션을 SPA 방식으로 바꾸어 볼까요?

jQuery vs Angular 구현 방식 비교

jQuery와 Angular는 구현방식이 근본적으로 다릅니다. 어떻게 다른지 소스코드를 통해서 간단히 살펴보도록 하겠습니다.

먼저 아래는 jQuery로 구현한 TODO 애플리케이션의 소스 코드인데 Angular 구현 코드와 어떻게 다른지 보시겠습니다.

==== front_jquery.js ====

jQuery 구현 코드에서는 하나의 화면에 할일 등록 폼과 할일 목록이 같이 표시되기때문에 할일을 등록하는 기능과 할일을 서버로부터 조회해서 목록으로 표시하는 기능을 하나의 자바스크립트 파일에서 함수화 하여 구현하였는데 할일을 등록하고, 조회하기 위해서 서버와 통신을 하기도 하고 가져온 할일 데이터를 화면에 렌더링하기도 합니다.

이 말은 달리 표현하면 하나의 자바스크립트 파일 안에서 너무 많은 일을 한다라고 말씀 드릴 수 있겠습니다.

또한 서버로부터 가져온 할 일 데이터를 목록으로 화면에 표시하기 위해서 HTML DOM을 조작하기때문에 jQuery 코드에 HTML 코드가 뒤섞여 있는것을 보실 수 있습니다.

자, 그럼 Angular에서는 할일을 등록하고 등록한 할일을 조회하여 표시하는 기능을 어떻게 구현했을까요? 아래는 Angular로 구현한 TODO 애플리케이션의 디렉토리 구조인데요.

Angular 애플리케이션에서 하나의 화면은 기본적으로 여러개의 컴포넌트의 조합으로 구성이 되어있습니다. 이말의 의미는 구현해야할 코드가 기능 단위로 각각 분리가 되어있다고도 말할 수 있습니다.

TODO 애플리케이션의 디렉토리 구조에서 todo 디렉토리 하위에 todo-list 디렉토리와 todo-register 디렉토리로 분리되어 있는 것을 보실 수가 있습니다. 할일을 등록하는 기능과 할일을 조회하는 기능을 각각 컴포넌트화하여 분리한것이죠.

그렇기때문에 Angular에서는 하나의 컴포넌트에서는 대부분 하나의 기능에 대해서만 구현하므로 소스코드도 매우 간결하게구성할 수 있고, 컴포넌트라는 정해진 구조내에서 코드를 구현하기 때문에 유지 보수측면에서도 매우 뛰어나다고 볼수있습니다.

자, 그럼 Angular로 구현된 TODO 애플리케이션의 컴포넌트의 소스코드는 어떻게 구성되어있는지 간단하게 살펴보도록 하겠습니다.

==== todo.component.html ====

TODO 컴포넌트는 위와 같이 크게 할일을 등록하는 컴포넌트와 할일을 조회하여 목록으로 표시하는 컴포넌트로 나누어져있습니다. 이 각각의 하위 컴포넌트들이 HTML로 렌더링되어 화면에 보여지게 되는것입니다. 이렇게 해놓으니까 코드가 무척 단순해 보이지 않나요? 실제로 복잡한 코드들 즉, 해당 컴포넌트들의 기능들에 대한 코드는 각각의 컴포넌트안에서 독립적으로 구현이 됩니다. 다시 말하면 컴포넌트들간의 관계가 느슨해진다라고도 할 수 있습니다.

그럼 하위 컴포넌트들은 어떻게 구현되어있는지 한번 볼까요?

==== todo-register.component.ts ====

할일을 등록하는 컴포넌트인데요. Angular의 컴포넌트들은 위와 같이 @Component 애노테이션을 가지는 클래스로 구성이 되어 있으며, 특정 이벤트가 발생했을때 클래스내의 함수(또는 메서드)를 호출 하도록 구성이 되어있습니다.

위의 TodoRegisterComponent 클래스에서는 할일을 등록하는 버튼 이벤트가 발생했을 때 registerTodo() 함수가 호출이 되어 서버측에 할일 데이터를 전송하게됩니다.

TodoRegisterComponent는 할일 등록에 대한 부분에 대해서만 처리하는데 해당 클래스내에서 서버쪽에 할일 데이터를 전송하는 로직은 포함하고 있지 않으며 서버측으로의 전송 자체는 자신의 일이 아니기때문에 TodoService 에 서버쪽으로의 전송을 위임을 합니다.

Angular를 사용하면 각각의 기능들을 Component 단위로 쪼개서 각자의 할일만 처리하도록 구현을 할 수 있습니다. 이와 더불어 컴포넌트간의 관계는 느슨하기때문에 컴포넌트들은 서로가 무슨 일을 하는지 알지 못하며 알필요가 없습니다.

할일을 등록하고난 후, 등록된 할일 데이터를 할일 목록에 갱신을 하게 되는데요. 이 경우 등록된 할일 데이터를 할일 목록을 표시하는 컴포넌트에 넘겨주는데 그 부분이 바로 코드 24번 라인에 나와 있습니다.

TodoRegisterComponent는 TodoListComponent라는 존재를 알지 못한채 그저 등록된 할일 데이터를 이벤트에 담아TodoService에게 전달하기만 하고, 누가 그 데이터를 전달받아서 사용하는지에 대해서는 관심이 없습니다.

TodoListComponent는 등록된 할일 데이터를 담고 있는 이벤트가 발생하는지 귀 기울이고 있다가 이벤트가 발생하면 할일 데이터를 전달받아서 할일 목록을 갱신하게 됩니다.

어떠신가요? 제가 Angular 문법 자체를 강의하는게 아니라서 어렵게 느껴지실수 있겠지만 Angular가 각각의 컴포넌트들을 클래스화 하여 객체지향적인 코드를 쉽게 구현할 수 있도록 해주고 있다는 사실을 조금만 더 학습해보시면 충분히 느끼실 수 있을것입니다.

자, 다음으로 앞서 말씀드린것처럼 TodoRegisterComponent에서 등록된 할일 데이터를 이벤트에 담아 내보냈을 때, 이를 받아서 할일 목록을 갱신하는 기능을 하는 TodoListComponent의 코드를 간단히 살펴보도록 하겠습니다.

==== todo-list.component.ts ====

TodoListComponent 의 코드는 복잡하지 않습니다. 단순히 할일 데이터를 전달 받아서 화면에 표시하는 기능만 담당하기때문에 코드가 복잡할래야 복잡할수가 없는것이죠.

Angular의 컴포넌트들은 대부분 한가지 기능에 대해서만 독립적으로 구현을 하기때문에 코드 자체가 단순해질 수 밖에 없으며, 만약 하나의 컴포넌트내에서 코드가 복잡해진다면 무언가 잘못 구현을 하고 있으며 이럴 경우 컴포넌트를 세분화 하는 등의 리팩토링이 필요할 것입니다.

19 - 23 라인의 ngOnInit() 함수에서는 Angular 애플리케이션의 구성이 완료되었을 때 초기화 작업을 진행할 수 있는데 여기서는 서버측으로부터 할일 데이터를 가져와서 할일 목록을 표시하는 작업을 처리합니다.

11 - 16라인의 생성자에서는 TodoRegisterComponent 에서 할일을 등록하고 이벤트를 내보내면 이 이벤트가 발생했는지에 대해서 귀 기울이고 있다가 이벤트가 발생하면 등록된 할일 데이터를 받아서 할일 목록을 갱신하는 작업을 처리합니다.

제가 이벤트 발생 여부에 대해서 귀 기울인다고 쉽게 표현을 했지만 더 정확하게는 해당 이벤트를 구독한다라고 할 수 있습니다. 이벤트 발행/구독에 대한 부분은 Reactive프로그래밍과 관련이 있으므로 더 자세한 내용은 관련 자료를 확인하시기 바랍니다.

그런데 신기한건 jQuery 처럼 DOM을 조작하여 등록된 할일 데이터를 화면에 추가하는것이 아닌 단순히 todoData라는 배열에 등록된 할일 데이터를 추가하는것 뿐인데 화면에서는 할일 목록이 자동으로 갱신이 됩니다. 이는 Angular의 컴포넌트 내에서 모델 데이터와 Template간에 데이터가 동기화 되는것인데 이를 바인딩이라고 합니다.

Angular로 구현한 Todo 애플리케이션에 대해서 대략적으로나마 설명을 드렸는데 어떠신가요? 물론 Angular에 대한 학습 곡선이 조금 있는 편이기때문에 처음에는 어렵게 느껴지실수도 있습니다. 하지만 그만큼 학습 자체가 상당히 재미있기때문에 코딩하는 재미도 그만큼 크다는것이 제 개인적인 생각입니다. ^^;

자.. 이제 웹 개발자(Java 개발자) 로드맵 시리즈를 슬슬 마무리 할 시간인데요. 이때까지 로드맵 시리즈를 진행하면서 그려왔던 로드맵을 마지막으로 한번 정리해보는 시간을 가지고 이번 포스팅을 마무리 하도록 하겠습니다.

최종 로드맵

웹 개발자(Java 개발자) 로드맵 시리즈를 시작한지 5개월만에 이제야 마무리를 할 시간이 다가왔네요. ^^; 5개월이면 매일 하나씩 포스팅을 할 수 있다고 쳐도 100개가 넘는 포스팅을 할 수 있었을텐데 겨우 7개밖에 할 수 없었던 이유는 직장 + 유부남 + 아기 탄생 + 육아때문이라고 볼 수 있겠습니다. ^^ 아무튼 늦게나마 최종 로드맵을 올릴 수 있어서 개인적으로는 보람이 있습니다.

첫번째 시간에서도 말씀을 드린바 있지만 웹 개발자(Java 개발자)가 되기 위해서, 그리고 되고난 후에 배워야할 것들은 상당히 많습니다. 하지만 대한민국에서 웹 개발자(Java 개발자)로써 현실적으로 필요한 것들만 제가 경험한 기술들을 바탕으로 말씀을 드리고 싶었더랬습니다.

여기서 현실적이라는 말은 이 글을 읽으시는 분들이 한국에서 생활하기 괜찮은 직장(연봉, 복지, 기업문화)에서 좋은 개발자로써 일을할 수 있었으면 하는 제 바램이 담겨있다고 보시면 되겠는데요. 개발자 입문자들에게 부디 조금이라도 도움이 될 수 있길 바래보면서 그럼 최종 로드맵을 소개하도록 하겠습니다.

짜잔!

[Angular + 추가 기술 포함 최종 로드맵]

색깔이 채워져 있지 않은 놈들은 이미 이전시간까지 소개를 해드렸던 기술들이며, 노란색으로 채워져 있는 기술은 오늘 말씀드린 Angular가 추가 되었습니다. Angular 이외에 Vue.js나 React는 Angular 대신에 학습하면 되는 기술들이기에 같이 적어놓았는데요. 시간이 되신다면 Angular나 Vue.js 둘중에 하나를 학습하시고, React를 추가적으로 학습하시면 좋을듯 하네요. Angular와 Vue.js는 상대적으로 학습할 내용이 비슷한 부분이 있다고 생각되지만 React는 개발 방식이 많이 다른걸로 알고 있습니다.(저도 안써봐서 어떻게 다른지에 대해서는 말씀을 못드리겠네요. ^^;)

자, 그리고 녹색으로 채워져 있는 부분은 개발자 로드맵에서 추가적으로 설명을 하고 싶지만 시간 관계상 모두 설명하기 힘든 녀석들을 모아봤습니다. 하지만 언젠가 꼭 학습을 하게된다면 개발자로써 한단계 더 성장할 수 있는 기술들만 추려보았으므로 가급적이면 시간과 계획을 세워서 꼭 학습해보길 바래봅니다.

이로써 5개월 동안의 웹 개발자(Java 개발자) 로드맵 시리즈는 이렇게 마무리를 짓도록하겠습니다. 다음 시간부터는 조금 구체적인 특정 내용들로 육아 후, 짬나는대로 찾아뵙도록 할게요.

그럼 전 이만.. 새해 복 많이 받으세요~

★ [Kevin의 알기 쉬운 Java 로드맵 이야기] 인프런 강의 바로가기

현실적인 개발자 로드맵(7) - Spring Boot으로 Spring을 더욱 편리하게..

Kevin's IT Village — Mon, 31 Dec 2018 23:11:05 +0900

현실적인 개발자 로드맵(7) - Spring Boot으로 Spring을 더욱 편리하게..

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-springboot 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, 오랜만에 찾아뵙게 되었네요. Kevin이라고 합니다. ^^

거의 석 달만에 올리는 글이 되겠습니다. 저희 아기가 탄생하시는 바램에 석 달 동안 참 바빴고 여러가지 많은 일이 있었더랬습니다. 새 생명이 탄생하는 경이로움을 경험했다고나 할까요. 아무튼 직장 다니랴 아기 돌보느라 이래 저래 바빠서 포스팅 한다는것은 꿈에도 생각하지 못했네요. 다만 짬짬이 유튜브 강의 영상만 녹화 하면서 간간히 소식을 전해드렸는데요. 포스팅 한 내용만큼 유튜브 영상 업로드가 끝나서 다시 포스팅을 진행하게 되었네요. Term이 조금 길긴했지만 그래도 이 다음 이야기를 궁금해 하실 초보 개발자분들이 있을거라고 생각하기에 다시 이야기를 진행해보도록 하겠습니다.

지난 시간에는 Spring 프레임워크에 대한 얘기를 나누어보았는데요. 앞서 보셨듯이 Spring은 그야말로 자바 개발자들에게는 없어서는 안될 그런 대세가 되어버렸습니다. 하지만 그 대단한 Spring 프레임워크에도 개발자들이 아주 난색을 표하는 단점이 하나 있었는데요. 그것은 바로 Spring 프레임워크를 사용하기 위한 설정의 어려움이었습니다. 프레임워크라는 편리한 도구를 사용해서 비즈니스 로직의 개발에 집중을 해야될 판에 정작 Spring Framework를 사용하기 위한 설정에 개발자들이 꽤나 상당한 시간을 투자해야하는 아이러니한 상황이 발생하게 되었던 것입니다.

물론 Spring이 버전업되면서 이런 문제들이 개선이 되긴했지만 여전히 설정의 복잡함은 남아 있었는데요.

이러한 문제를 해결하기 위해서 등장한것이 바로 Spring Boot 이라는 놈입니다. 이 Spring Boot이 등장함으로 인해서 개발자들은 더이상 Spring의 설정을 위해 머리 싸매면서 고민하던 시간을 접고 비즈니스 로직을 구현하는데 집중할 수 있게 해주었습니다.

그럼, Spring Boot 이라는 놈은 어떤 놈인지 지금부터 한번 살펴 볼까요?

우리가 Spring을 사용하여 웹 애플리케이션을 만들기위해서는 어떤 것들이 필요할까요?

우선 메이븐이나 그레이들을 사용하는 프로젝트 구조를 사용하기 위해서 Spring에 필요한 의존 관계 라이브러리들을 지정해야합니다.

그리고 DispatcherServlet 설정을 위한 web.xml 설정도 해야하구요.

또한 Spring MVC를 사용하기 위해서는 핸들러 매핑이나 핸들러 어댑터, 뷰 리졸버 등의 설정을 최소한 해주어야합니다.

마지막으로 웹 애플리케이션을 배포하기 위한 Tomcat 등의 웹 애플리케이션 서버가 필요하겠죠.

이러한 준비 작업들이 끝나고나면 자 드디어 컨트롤러 클래스를 작성하면서 개발을 시작하면 되겠습니다.

자, 어떻게 된게 개발을 시작하기도 전에 해야할 일이 너무 많다는 생각이 들지 않으신가요? ^^; 개발자가 개발에 집중해야함에도 불구하고 개발을 하기 위한 사전 작업을 너무나 많이 하게되는 셈이 되는데요.

Spring Boot의 자동 구성과 스타터 의존성이라는 방법으로 이러한 문제들을 해결 해주게되었습니다. 짝!짝!짝! 자 그럼 Spring Boot의 자동 구성과 스타터 의존성이 무엇인지 잠깐 알아볼까요?

자동 구성

우선 Spring Boot은 Tomcat을 내장하고 있기때문에 별도의 웹 애플리케이션 서버를 설치할 필요가 없습니다. 내장된 Tomcat에 빠르게 웹 애플리케이션을 배포할 수 있습니다.

그리고 자동 구성 덕택에 DispatcherServlet이나 핸들러 매핑, 핸들러 어댑터 등의 Spring MVC 설정도 따로 필요가 없습니다. Spring Boot이 애플리케이션의 클래스 패스에서 관련 클래스들을 발견하고는 알아서 척척 구성을 해주는 것이죠. 또한 H2 같은 특정 데이터베이스 라이브러리를 발견한다면 해당 라이브러리를 사용하기위한 데이터베이스 설정을 자동으로 구성합니다. JPA를 사용하고 싶다면? 네, 맞습니다. Spring Boot이 JPA를 사용하기 위한 설정을 역시 자동으로 구성해줍니다. 웹 애플리케이션의 보안 설정을 하고 싶다면? 네, 역시 Spring Boot이 Spring Security를 사용하기 위한 설정을 자동으로 구성해줍니다.

Spring Boot을 통해 Spring이 더 똑똑해졌다는 생각이 드시죠?

스타터 의존성

하나의 애플리케이션을 만들기 위해서 의존 관계에 있는 라이브러리들을 정확하게 추가하는일은 쉽지가 않습니다. JSON 형식의 응답 데이터를 반환하는 Spring MVC 애플리케이션을 만들어서 내장된 Tomcat으로 애플리케이션을 실행해야 한다면 대략 다음과 같은 라이브러리들을 직접 메이븐이나 그레이들 설정에 추가해주어야 합니다.

spring-core, spring-web, spring-webmvc, jackson-databind, tomcat-embed-core, tomcat-embed-el

하지만 스타터 의존성을 이용하면 개발자가 이런 의존관계에 있는 라이브러리들을 일일이 추가할 필요가 없습니다. 단순히 spring-boot-starter-web 스타터를 추가해주면 알아서 의존 위에 열거한 라이브러리들을 자동으로 추가해줍니다. 개발자들이 어떤 스타터를 추가해야 되는지도 직관적으로 알 수 있습니다.

웹 애플리케이션을 개발하기 위해서는 spring-boot-starter-web 스타터를 추가하면 되고, JPA 영속성을 사용하려면 spring-boot-starter-jpa를, 애플리케이션 보안이 필요하다면 spring-boot-starter-security를 추가하면 됩니다.

말로 설명하면 Spring Boot의 장점이 직접적으로 와닿지 않을수도 있으니 코드를 한번 살펴보도록 하겠습니다.

지난 시간의 Spring MVC 프로젝트의 구조에서는 설정해야되는 부분이 엄청 많았습니다. 아래 이미지를 보시죠.

[전통적인 Spring MVC 설정]

스프링 MVC 프로젝트에 필요한 라이브러리들을 설정해놓은 pom.xml, 웹 애플리케이션 개발을 위한 dispatcher-servlet.xml과 web.xml 설정을 개발자가 직접 해주어야 했습니다.

물론 Spring Boot에서도 설정을 하긴합니다. 아래와 같이 말이죠.

[Spring Boot의 설정]

build.gradle 파일에서 Spring MVC 웹 애플리케이션 설정을 위해서 dependencies 항목에 필요한 라이브러리들을 설정하는데 단 5줄밖에 되지 않습니다. web.xml이나 dispatcher-servlet.xml 같은 설정은 아예 사라져버린것이죠.

이게 끝입니다. 더 이상 설정할게 없으며, 이 5줄만으로 기존의 Spring MVC 웹 애플리케이션에 JPA와 H2 데이터베이스 기능까지 포함한 설정이 자동으로 구성이 되는것입니다. 엄청나지 않나요? 저만 그렇게 느끼는건 아닌지.ㅎ ^^;

그리고 추가적으로 기존의 Spring MVC 기반의 Todo 애플리케이션을 Spring Boot 기반으로 변경하면서 구현 코드는 어떻게 변경이 되었는지 잠깐 살펴보도록 하겠습니다.

이번 Spring Boot 기반 Todo 애플리케이션에는 할일 목록을 DB에 저장하기 위한 기술로 JPA(Java Persistence API)를 사용하였습니다. JPA는 데이터베이스의 테이블과 자바의 Entity 객체를 매핑하여 데이터를 손쉽게 DB에 저장하는 ORM(Object Relational Mapping) 기술중에 하나로써 Spring을 사용하여 JPA를 손쉽게 사용할 수 있습니다.

아래 코드를 잠깐 보시겠습니다.

==== Todo.java ====

DB의 todo 테이블과 매핑되는 Todo 엔티티 클래스인데요. @Entity 애노테이션을 붙여서 엔티티 클래스라는것을 명시했고, @Id 애노테이션을 붙여서 기본키를 설정했습니다. 그리고 10번 라인에 @Data 애노테이션을 추가해서 Todo 클래스의 멤버 변수들에 대한 getter/setter 메서드를 간편하게 추가하였습니다.

참고로 Lombok이라는 라이브러리를 사용하여 클래스의 생성자, toString(), getter/setter 등의 다양한 설정을 간편하게 할 수 있기때문에 Lombok은 개발자들이 많이 사용하는 라이브러리중의 하나입니다.

==== TodoRepository.java ====

이 클래스는 Todo 클래스의 객체를 DB에 저장해주는 기능을 하는 Repository 클래스입니다. JpaRepository를 상속받고 있는 인터페이스인데요. 구현된게 아무것도 없음에도 불구하고 할일을 저장해주고 조회해주는 CRUD 기능을 모두 다 할 수 있습니다.

마지막으로 할일에 대한 요청을 받아들이는 TodoController 클래스를 한번 보실까요?

==== TodoController.java ====

이전 포스팅에서는 @RequestParam 애노테이션을 사용하여 할일 데이터를 register()의 파라미터로 받았는데 이번에는 todoName과 todoDate 파라미터의 값이 Todo 객체에 바로 매핑이 되도록 한 후, TodoRepository 클래스의 save()를 사용하여 DB에 저장하는 로직으로 변경되었습니다.

28번 라인에서는 TodoRepository 클래스의 findAll()을 사용하여 저장된 모든 할일 데이터를 조회하도록 변경되었습니다.

실제 DB에 저장을 하는 로직으로 변경되었지만 여전히 소스코드가 필요한 비즈니스 로직만 포함하는 깔끔함을 유지하는것을 보실 수 있습니다.

자, 간단하게나마 Spring Boot의 편리함에 대해서 살펴보았는데요. Spring Boot이 개발자가 비즈니스 로직 개발에 집중하도록 얼마나 많은 노력을 하였는지 여전히 현실적으로 와닿지 않는 분들께서는 저처럼 Spring Boot을 사용하지 않고 Spring MVC 애플리케이션 구성을 해보신다음 Spring Boot으로 개선해보는 작업을 한번쯤 해보셨으면 하는 바램을 가져보겠습니다.

자, 그럼 이번 시간에 새롭게 추출해야 될 기술들에는 무엇이 있는지 살펴보겠습니다.

[Spring Boot이 추가된 로드맵]

개발자 로드맵에 새롭게 추가된 기술입니다. ^^ Spring Boot은 당연히 추가가 되었구요. 그 외에 JPA와 H2를 추가하였는데요.

JPA는 데이터베이스에 데이터를 추가하는 대표적인 ORM 기술로써 괜찮은 회사(여기서 괜찮은 회사라함은 기술 트렌드를 적극적으로 받아들이는 회사로 칭하겠습니다.^^;)에서 일을 하고 싶다면 꼭 알아두셨으면 하는 기술중에 하나입니다.

H2는 그 자체로는 단순히 데이터베이스의 한 종류입니다. 일반적인 데이터베이스와의 차이점이라면 In memory DB 즉, 애플리케이션 실행을 종료하면 저장된 데이터는 사라지는 내장 DB라는것입니다. 제가 말씀드리고 싶은것은 H2 자체를 배우라기보다는 In memory DB를 활용할 줄 알아야한다는 것입니다. 나중에 Spring으로 개발을 진행하다보면 단위 테스트 코드를 짜야 되는 경우가 많은데 이 경우에 H2 같은 In memory DB를 활용하면 편리하게 단위 테스트 코드를 DB와 연계할 수 있습니다.

자, 이번 시간에는 Java 개발자(웹 개발자) 로드맵에 Spring Boot을 추가를 해보았는데요. 다음 시간에는 '현실적인 개발자 로드맵 시리즈'의 마지막 편을 포스팅 해보도록 하겠습니다. 시리즈로 계속해서 포스팅을 할 수 있지만 다른 기술들에 대해서 구체적인 얘기들을 많이 해야되겠기에 어쨌든 다음 시간에 '현실적인 개발자 로드맵 시리즈'를 마무리 하겠습니다. ^^;

오늘이 2019년의 첫날인데 다들 새해에 목표하신바를 잘 이룰 수 있도록 좋은 출발하시기를 바래보겠습니다. 저도 올 한해 열심히 열심히 살아보도록 하겠습니다.

그럼 다음 시간에 다시 뵐게요~ 새해 복 많이 받으세요!(Happy New Year!)

★ [Kevin의 알기 쉬운 Java 로드맵 이야기] 인프런 강의 바로 가기

현실적인 개발자 로드맵(6) - Spring의 탄생

Kevin's IT Village — Wed, 3 Oct 2018 10:54:13 +0900

현실적인 개발자 로드맵(6) - Spring의 탄생

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-spring-mvc 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, Kevin입니다.

지난 시간까지 Ajax와 jQuery가 등장함으로 인해서 웹 애플리케이션 개발이 Front-end와 Back-end로 나누어 지기 시작했다고 말씀을 드렸는데요. 지난 시간에 Front-end쪽을 잠깐 살펴보았으니 이번 시간에는 Servlet에서 멈춰 있는 Back-end 쪽의 기술의 변화를 다시 살펴 보도록 하겠습니다.

Servlet을 사용하여 Back-end쪽을 불편하고 복잡하게 개발을 하던 시절의 무렵, 혜성 같이 등장한 구원투수가 있었으니 그것은 바로 Spring이라는 놈이었습니다. 마치 야근을 밥 먹듯이 하는 개발자들에게 봄날이 오길 바라는 마음에서 였을까 아무튼 자바 개발자들에게 Spring은 봄(spring)이 오듯이 찾아왔습니다. ^^;

Java 웹 개발의 이전과 이후는 Spring을 기준으로 나뉘어 진다고해도 과언이 아니라고 볼 수 있습니다. 마치 예능 프로그램이 무한도전 이전과 이후로 나뉜다고 볼 수 있는것 처럼 말이죠. ^^

아무튼 Spring이라는 프레임워크가 등장한 이후로 웹 애플리케이션을 개발에 있어서 커다란 변화가 생겼음은 Java 개발자라면 누구나 부정할 수 없을것이라고 봅니다.

Spring 1.0 버전이 2004년에 나온것으로 알고 있는데 저는 개인적으로 2009년에 Spring 2.5를 처음 접하게 되었습니다.

2018년 10월 현재 Spring 5 버전이 나오면서 Spring 프레임워크의 기술에도 많은 변화가 있었으나 IOC, DI, AOP 같은 Spring의 근본 기술들은 Spring의 핵심 기술로 변함없이 자리를 지키고 있습니다.

이 포스팅은 Spring에 대한 구체적인 사용방법 등에 대해서 이야기를 하는것이 아니기때문에 Spring에 대한 이야기들은 추후에 다시 포스팅할 수 있는 기회가 있었으면 좋겠습니다.

Java 개발자 로드맵에 이미 Spring이 추가가 될 것이라는 결론은 난 셈이 되지만 그래도 이대로 글을 마치게되면 너무 싱거우니 여태까지 해온대로 이전 포스팅에서 Servlet 기반으로 구현했던 TODO 애플리케이션을 Spring 프레임워크를 사용하여 개선을 해보도록 하겠습니다. Servlet 기반의 TODO 애플리케이션 구현에 대한 상세한 내용은 아래 포스팅을 참고해주세요.

2018/09/07 - [현실적인 개발자 로드맵] - 현실적인 개발자 로드맵(3) - JSP 모델2

자, 그럼 결론적으로 Servlet으로 구현한 TODO 애플리케이션의 Servlet 코드와 Spring으로 구현한 Spring Controller의 코드를 비교해서 잠깐 살펴보겠습니다. 아래는 TodoAjaxServlet의 코드입니다.

==== ToDoAjaxServlet.java ====

package com.itvillage.servlet;

import com.google.gson.Gson;
import com.itvillage.vo.ToDo;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

@WebServlet(name = "ToDoAjaxServlet", value = "/todoAjax")
public class ToDoAjaxServlet extends HttpServlet {
    // Database를 대신한다.
    private List<ToDo> todoList;

    @Override
    public void init() throws ServletException {
        super.init();
        this.todoList = new ArrayList<>();
    }

    protected void doPost(HttpServletRequest request, HttpServletResponse response) 
            throws ServletException, IOException {
        request.setCharacterEncoding("UTF-8");
        response.setContentType("text/html;charset=UTF-8");

        String todoName = request.getParameter("todoName");
        String todoDate = request.getParameter("todoDate");

        todoList.add(new ToDo(todoName, todoDate));

        Gson gson = new Gson();
        String json = gson.toJson(todoList);

        response.setContentType("application/json");
        response.setCharacterEncoding("UTF-8");
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.getWriter().write(json);

    }
}

다음은 Spring으로 구현한 ToDoController입니다.

==== ToDoController.java ====

package com.itvillage;

import com.itvillage.vo.ToDo;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.List;

@Controller
public class ToDoController {
    @RequestMapping(value = "/todoAjax", method = RequestMethod.POST)
    @ResponseBody
    public List<ToDo> todoAjax(@RequestParam("todoName")String todoName,
                               @RequestParam("todoDate")String todoDate) {
        ToDo.todoList.add(new ToDo(todoName, todoDate));
        return ToDo.todoList;
    }
}

ToDoAjaxServlet 클래스의 doPost() 메서드와 ToDoController 클래스의 todoAjax() 메서드는 클라이언트측으로부터 Ajax 요청을 처리하는 메서드인데요. 일단 눈으로 보이는 소스 코드의 길이만 봐도 ToDoController의 todoAjax() 메서드가 확연히 짧고 간결한것이 보이시죠?

ToDoAjaxSevlet의 doPost()에서는 캐릭터 셋 설정이나 JSON으로의 포맷팅 설정, response의 설정까지 직접 해주어야 했으나 ToDoController의 todoAjax() 메서드에는 그런 설정들이 전혀 없습니다.

Spring 설정파일에 별도의 설정을 하긴 하지만 구현 코드상에서는 모두 제거되어 Servlet 보다 실제로 깔끔한 소스 코드를 유지하는것이 가능해졌습니다.

사실 왜 Spring을 사용하여야 되는지에 대해서 구체적으로 설명하려면 저는 내일 출근을 못합니다.^^;

Spring에 대해서는 다음에 더 많은 얘기를 나눌 수 있는 기회가 있을것이라고 생각을 하고, 우선 지금은 이것 하나만 기억하시면 되겠습니다.

Spring은 Java 개발자가 되기 위해서 반드시 알아야되는 핵심 기술중에 하나이다 라는것을 말이죠.

자, 이미 앞에서 이미 다 결론이 난 상태이지만 그래도 로드맵을 정리하는 차원에서 다시 한번 로드맵을 그려보면 다음과 같습니다.

[Spring 프레임워크가 추가된 개발자 로드맵]

짠~ 예상했던대로 Spring 프레임워크가 개발자 로드맵에 추가가 되었습니다.^^;

Spring에 대해서는 몇십번을 강조해도 지나치지 않을만큼 Java 개발자가 되기위해서 필수적으로 알아야 되는 기술입니다.

더 정확하게 말하자면 Spring을 몰라도 당연히 Java 개발자가 될 수 있지만 조금 더 스마트하고 미래지향적인 Java 개발자가 되기위해서는 배워야 될 기술입니다.

이렇게 Spring에 대한 칭찬만 하다가 끝나도 사실 상관은 없지만 그래도 Spring에 대한 단점에 대해서 언급은 하고 가는것이 맞는거 같아 제가 Spring을 처음 접하면서 겪었던 불편함을 잠시 말씀드리겠습니다.

처음 Spring을 접하면서 가장 불편했던점은 바로 Spring의 개발 환경을 구축하는것이었습니다.

Spring의 기술을 사용하기 위해서 해야되는 설정이 생각보다 복잡했고, Spring에 대한 근본 지식이 없는 상태에서 설정을 하다가 에러를 만나게 되면 해결하는것이 그리 만만치 않았다는 것입니다.

이번 포스팅을 위해서 오랜만에 Spring 개발 환경 설정을 해보았는데 역시나 설정하는데 오래 걸리더군요. 보통 밤 12시 전에 잠을 자는데 설정하고 정상적으로 동작하는지 확인하느라 12시를 넘겨버리고 말았습니다. ^^;

그럼 Spring 프레임워크를 사용하여 개발하는데 있어서 어떤 설정을 해주어야 하는지에 대해서 간단하게만 말씀 드리고 이번 포스팅을 마치도록 하겠습니다.

==== dispatcher-servlet.xml ===

dispatcher-servlet.xml에는 웹 프리젠테이션 계층의 빈(Bean)을 등록하는 설정 파일입니다. ToDo 애플리케이션의 경우 샘플 애플리케이션이다 보니 많은 빈(Bean)이 등록되지 않았으나 애플리케이션의 기능이 늘어날수록 빈 설정의 수는 늘어날 것입니다. 현재는 응답 데이터를 JSON으로 변환해주는 Converter와 JSP 뷰를 리졸빙해주는 Resolver만 설정되어 있습니다.

==== web.xml ====



    
        contextConfigLocation
        /WEB-INF/spring-config/applicationContext.xml
    
    
        org.springframework.web.context.ContextLoaderListener
    
    
        dispatcher
        org.springframework.web.servlet.DispatcherServlet
        
            contextConfigLocation
            /WEB-INF/spring-config/dispatcher-servlet.xml
        
        1
    
    
        dispatcher
        /
    
    
        CORSFilter
        com.itvillage.filter.CORSFilter
    
    
        CORSFilter
        /*

Servlet 사용 시 필요한 web.xml 파일에 Spring 연동을 위한 설정들이 추가로 포함되었습니다. ContextLoaderListener를 통해 Root Web Application Context를 등록하고, 앞서 보았던 dispatcher-servlet.xml 파일의 경로를 추가함으로써 Servlet Web Application Context를 등록하였습니다. 그리고 추가적으로 CORS(Cross Origin Resource Sharing) 문제를 해결하기 위해서 Filter 설정이 포함되었습니다.

이 포스팅에서는 이런 설정들이 정확하게 무엇을 하는지 몰라도 상관없습니다. 이런 설정들을 해야지만 Spring을 사용할 수 있다라는 정도만 알고 계시면 될것 같습니다.

설정이 간단해 보이지만 직접 한번 해보시면 다양한 에러를 만나실 수 도 있을것입니다. ^^; 제 경우는 Spring 설정 + IDE 설정 + CORS 문제 등등으로 시간이 좀 걸렸습니다.

아무튼 Spring의 이런 설정상의 불편함때문에 개발자들이 정작 핵심 개발에 집중을 하지 못하고 Spring 설정에서부터 벽에 부딪치는 경우도 종종 있다고 알고 있는데요. 아시는 분들은 아시겠지만 이런 불편함이 추후에 개선이 되었더랬죠.

이 부분에 대해서는 다음 시간에 말씀을 드리도록하고, 오늘은 이만 여기서 포스팅을 마무리해야겠습니다. 그럼 다음 시간에 다시 찾아뵐게요~

[Kevin의 알기 쉬운 Java 개발자 로드맵 이야기] 인프런 강의 바로가기

현실적인 개발자 로드맵(5) - jQuery의 등장

Kevin's IT Village — Fri, 21 Sep 2018 19:46:09 +0900

현실적인 개발자 로드맵 - jQuery의 등장

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-front-javascript 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, Kevin입니다. 추석을 앞두고 비가 오더니 집에 올때 쯤 그쳤네요. 오늘은 조금 일찍 퇴근해서 이렇게 글을 적고 있습니다. 오늘도 아직 끝나지 않은 개발자 로드맵에 관한 이야기를 해볼까 합니다.

지난 시간에는 Ajax 기술이 등장함으로 인해서 Front-end와 Back-end가 나누어지는 기술의 추세를 잠깐 언급을 했었는데요.

제가 Ajax 기술을 처음으로 접했던게 2007년이었던가 2008년 이었던가 아무튼 오래되서 기억이 가물 가물한데 아무튼 제 기억으로는 Ajax 기술을 처음 접한 이후, 오래지 않아서 순수 자바스크립트 Ajax 기술의 복잡함을 단순화 시킬 수 있는 기술이 등장을 하게됩니다.

그것은 바로.. jQuery입니다. 두둥~

처음 jQuery를 접했을땐 조금 충격적이었습니다. 그 당시만해도 자바스크립트는 이해하기 쉽지 않은 언어였었고, 자바스크립트 Ajax 통신을 통해서 가져온 데이터를 이용하여 DOM을 조작해서 UI를 업데이트 하는것이 결코 쉬운 작업이 아니었습니다. 자바스크립트로 그런 복잡한 작업을 하다가 jQuery를 사용하여 똑같은 작업을 하면서 어떻게 이렇게 간결하게 작성할 수 있을까라며 놀라움을 금하지 못하던 때가 분명히 있었네요. ^^;

그럼 지난 시간에 순수 자바 스크립트 Ajax 기술을 사용해서 서버와 통신을 하던 부분을 jQuery로 똑같은 기능을 하도록 작성을 해보겠습니다.

먼저 순수 자바 스크립트로 작성한 것을 다시 한번 보도록 하겠습니다.

        function registerTodo(){
            var todoName = document.getElementById("todoName").value;
            var todoDate = document.getElementById("todoDate").value;

            if(!todoName){
                alert("할일을 입력해주세요.");
                return false;
            }

            if(!todoDate){
                alert("날짜를 입력해주세요.");
                return false;
            }

            var xhr = new XMLHttpRequest();
            xhr.open('POST', 'http://localhost:8080/todoAjax', true);
            xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');

            xhr.onload = function(){
                if(xhr.status == 200 || xhr.status == 201){

                    // 화면에 반영
                    var todoList = JSON.parse(xhr.responseText);
                    var html = "";
                    for (var i in todoList) {
                        var todo = todoList[i];
                        html += '' + todo.todoName + '' + todo.todoDate + '';
                    }
                    var todoContents = document.getElementById("todoContents");
                    todoContents.innerHTML = '';
                    todoContents.innerHTML = html;
                }else{
                    // 에러 처리
                }
            };
            xhr.send('todoName=' + todoName + '&todoDate=' + todoDate);
        }

15번 라인에서 36번 라인까지가 자바스크립트 Ajax 기술을 사용하여 서버와 데이터를 주고 받는 부분인데요. 소스 코드 자체가 복잡해보이는건 어쩔 수 없습니다.

그럼 이제 위 소스코드를 jQuery로 다시 한번 구현을 해보도록 하겠습니다. jQuery로 구현한 코드는 아래와 같습니다.

$(document).ready(function(){
   $("#btnReg").click(function(){
       var todoName = $("#todoName").val();
       var todoDate = $("#todoDate").val();

       if(!todoName){
           alert("할일을 입력해주세요.");
           return false;
       }

       if(!todoDate){
           alert("날짜를 입력해주세요.");
           return false;
       }

       $.post("http://localhost:8080/todoAjax", {
           todoName: todoName,
           todoDate: todoDate
       }, function(todoList) {
           var contents = "";
           for (var i in todoList) {
               var todo = todoList[i];
               contents += '' + todo.todoName + '' + todo.todoDate + '';
           }

           $("#todoContents").html(contents);
       }, 'json');
   });
});

저희의 TODO 프로젝트 UI가 단순하다보니 UI쪽 코드는 코드 길이도 그렇게 차이나지 않고 복잡함에 있어서도 별 차이가 나지 않네요. 하지만 Ajax 통신하는 부분을 한번 보십시요. 소스 코드 길이도 물론 반으로 줄었고, 한눈에 봐도 되게 단순해 보이지 않나요?

하지만 이렇게 승승장구 할것만 같았던 jQuery도 세월이 흐르면서 서서히 한계를 드러내기 시작을 했더랬습니다. 그 이야기는 나중에 다시 하도록하고, 어쨌든 오늘은 보시면 아시겠지만 저희가 개선한 코드를 통해 추출할 수 있는 기술은 딱 한가지입니다.

바로 jQuery이지요. jQuery의 사용 빈도가 점점 줄어들고 있는건 사실이긴하지만 그래도 한국에서는 여전히 많이 사용되고 있는 기술중에 하나이기때문에 익혀두는것이 결코 나쁘지는 않습니다. jQuery 자체가 간결함을 지향하는 기술이기 때문에 학습 곡선 역시도 크게 가파르지 않으므로 조금만 시간 투자를 하시면 금방 익숙하게 사용하실 수 있을거라고 생각합니다.

자, 그럼 오늘 추출한 기술을 포함한 지금까지의 로드맵을 마인드 맵으로 한번 그려 볼까요?

[jQuery 기술이 추가된 개발자 로드맵]

기술이 점점 늘어가고 있군요. ^^

이번 시간까지는 Front-end쪽의 기술의 변화를 살펴봤으니 다음 시간에는 다시 Back-end쪽의 기술의 변화를 살펴보도록 하겠습니다.

선선한 가을 바람이 부는 금요일 밤인데 저는 잠깐 조깅을 하러 나가봐야겠습니다. 추석 연휴 잘들 보내시길 Kevin이 진심으로 기원하겠습니다. 다음 시간에 뵐게요~

[ Kevin의 알기 쉬운 Java 개발자 로드맵 이야기 ] 인프런 강의 바로가기

현실적인 개발자 로드맵(4) - Ajax의 등장

Kevin's IT Village — Fri, 14 Sep 2018 22:36:38 +0900

현실적인 개발자 로드맵 - Ajax의 등장

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-front-javascript 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, 오늘도 여전히 금요일 저녁에 찾아뵙네요. 평일엔 일 하느라 바빠서 포스팅을 할 수 없어서 금요일만 되면 포스팅 할 수 있다는 설레는 마음으로 이렇게 컴퓨터 앞에 앉아있습니다. ^^;

자, 그럼 지난 시간에 이어서 개발자 로드맵에 대해서 계속 이야기 해볼까요?

지난 시간에는 JSP 모델1을 개선한 모델2까지에서 추출한 로드맵을 그려보았습니다. 바로 아래와 같죠?

[JSP 모델2 방식에서 추가된 개발자 로드맵]

자, 그런데 JSP를 사용해보신 분들이라면 다들 알고 계시겠지만 JSP에는 한가지 문제점이 있습니다. 사실 문제점이라기 보다는 JSP 등의 서버 사이드 언어를 사용하면 당연시 여기던 것이었는데요. 저희는 아래와 같은 TODO 애플리케이션을 만들고 있습니다.

[TODO 애플리케이션]

그림과 같이 할일과 날짜를 입력한 후 [등록] 버튼을 클릭하게 되면 할일 데이터를 서버로 전송하게 되는데요. 이때 화면이 깜빡 거리는것을 볼 수 있습니다. 깜빡임의 이유는 [등록] 버튼을 클릭하게 되면 서버에 데이터를 전송한 후, 서버에서 todo_model1.jsp로 다시 포워딩을 시키면서 화면이 바뀌게 되기 때문입니다. 이해 되셨죠?

TODO 애플리케이션의 경우 서버에서 처리하는 시간이 얼마 되지 않기 때문에 잠시 깜빡거리겠지만 실무에서 많은 데이터를 처리할 경우에는 [등록] 버튼을 누른후에도 한참을 화면이 바뀌지 않거나 화면이 바뀌고 난 후에 서버에서 처리가 끝날때까지 브라우저에서 한참 동안 흰색 화면만 표시되는 경우도 있다는걸 아시는분들은 아실겁니다.

이렇게 페이지 전체를 refresh 하게되면 사용자들은 서버의 처리가 끝날때까지 아무것도 하지 못한채 기다려야 하죠. 이런 문제점을 개선하기 위해서 나온 기술이 바로 Ajax(Asynchronous Javascript and XML) 기술입니다.

Ajax 기술을 통해 페이지 전체를 refresh 하지 않고, 페이지의 일부분에 표시되는 데이터를 서버측으로 부터 받아서 화면의 깜빡임 없이 데이터를 갱신하는것이죠. Ajax 기술로 인해 페이지의 특정 부분의 데이터 또는 UI만 갱신 되므로 페이지 전체가 refresh 될때까지 기다릴 필요가 없게 되었습니다.

JSP가 처음 등장할 당시 클라이언트측에 표시되는 UI 화면을 구성하는 HTML + Javascript + CSS 소스코드들이 서버측 소스들과 함께 서버측에 위치하는 경우가 많았는데 Ajax 기술이 등장함으로 인해서 슬슬 HTML + Javascript + CSS 등의 소스 코드들은 웹서버에 위치시키고 서버측에는 순수하게 서버측 언어로 구성된 소스 코드들만 위치 시키는 소위 말하는 Front-end와 Back-end로 역할 구분을 하게됩니다.

자기 역할에 충실할 수 있도록 구성되는것은 어찌보면 너무나 당연한것이라고 볼 수 있는건데 말이죠.

자, 그럼 HTML + Javascript + CSS로 구성된 Front-end 의 소스 코드를 보시겠습니다. Back-end 소스 코드는 여전히 서블릿으로 구성되어 있으므로 손대지 않겠습니다.

 
    
    Todo List
    
    


    TO DO 등록
    
        
            
            
            
        
    
    
        TO DO List
        
            
            
                todo name todo date
            
            

            
            할 일이 없습니다.

todo name	todo date
할 일이 없습니다.

[front_javascript.html]

26번 라인부터 45번 라인까지가 Ajax 기술을 이용해 Back-end 쪽에 할일 데이터를 전송하고 응답으로 할일 목록 데이터를 전송 받는 부분입니다. 조금 복잡해 보이지 않나요?

어쨌든 여기서 저희는 로드맵에 하나의 기술을 더 추가할 수 있게되었네요.^^ 바로 아래와 같겠죠?

[Ajax 기술이 추가된 개발자 로드맵]

개발자 로드맵에 Ajax 기술이 추가되었습니다. ^^;

사실 요즘에는 Javascript로 Ajax 기술을 직접적으로 사용하는일은 많지 않습니다. 소스 코드를 보시면 아시겠지만 처음 보는 분들한테는 소스코드가 결코 단순하지는 않습니다.

그럼에도 불구하고 Ajax 기술을 로드맵에 포함시킨것은 순수 Javascript의 Ajax 기술을 사용하라는 의미는 아니고 최소한 Ajax의 원리는 이해를 해야한다는 의미에서 로드맵에 포함을 시킨거였습니다.

그럼, 다음 시간에는 순수 Javascript의 Ajax 기술의 복잡함을 극복하도록 Front-end 측 소스 코드를 개선해 보도록 하겠습니다.

모두들 즐거운 불금 보내시고 저는 이만 다른 공부를 좀 해야겠습니다. 그럼 다음시간에 뵐게요~

[ Kevin의 알기 쉬운 Java 개발자 로드맵 이야기 ] 인프런 강의 바로가기

현실적인 개발자 로드맵(3) - JSP 모델2

Kevin's IT Village — Fri, 7 Sep 2018 23:15:30 +0900

현실적인 개발자 로드맵 - JSP 모델2

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-jsp 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, Kevin입니다. 지난 시리즈에 이어 개발자 로드맵 이야기를 계속 해보겠습니다. 지난 시간에 어떤 이야기를 했는지 기억나시나요?^^ 지난 시간에는 Java 개발자로 입문하면서 필수적으로 배워야 할 것들이 무엇인지 JSP Model1 방식으로 구현한 TO DO 애플리케이션을 통해서 알아보았습니다. 지난 시간까지 알아본 바로는 아래와 같은 기술들을 배워야 한다고 했죠?

[JSP 모델1 방식에서 추출한 기술]

자, 그럼 오늘은 JSP Model1 방식으로 만든 TODO 애플리케이션을 조금 더 개선 해보면서 어떤 기술들을 더 알아야하는지 알아보겠습니다.

클라이언트 + 서버 통합(JSP 모델2)

지난 시간과 비슷하게 오늘은 JSP 모델2 방식의 구성도를 먼저 보도록 하겠습니다.

[JSP 모델2 구성도]

JSP 모델1의 구성도와 어떤 차이가 있는지 느껴지시나요? 모델1의 경우 JSP에서 클라이언트의 요청을 직접 받고 클라이언트에게 응답으로 돌려줄 View 까지 생성했더랬습니다. 그야말로 JSP가 모든 일을 다 하는거라고 보시면 됩니다. 그렇기 때문에 소스 코드 상에서도 요청을 처리하는 Java 코드가 뷰를 구성하는 JSP 코드에 구현 되어 있는것을 보실 수 있었는데요.

모델1에서 요청을 처리하는 코드와 뷰를 구성하는 코드가 JSP에 모두 구성되어 있는 반면에 JSP 모델2 방식은 Servlet이라는 자바 클래스가 요청을 받아서 뷰에 표시될 데이터들만 JSP에게 넘겨 주고, JSP는 이 데이터들을 HTML 코드에 잘 보이도록 적절하게 랜더링한 후, 클라이언트에게 넘겨줍니다.

한마디로 말해서 각자의 할 일은 각자 하자는 구성 방식이라고 볼 수 있습니다. 요청을 처리하는 역할은 Servlet이 맡고 , JSP는 뷰로써의 역할만 하자는 역할 분리가 이루어진셈입니다.

실제 코드를 보면 조금 더 이해 하시기 쉬울겁니다. 소스 코드를 한번 볼까요?

==== web.xml ====

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"
         xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
         http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

    <display-name>To Do JSP</display-name>

    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

    <servlet>
        <servlet-name>Todo</servlet-name>
        <servlet-class>com.itvillage.servlet.TodoServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>Todo</servlet-name>
        <url-pattern>/todo</url-pattern>
    </servlet-mapping>
</web-app>

모델2 방식에서는 클라이언트의 요청을 처리하게 되는 Servlet 설정 정보를 위와 같이 web.xml에 설정해주어야합니다. 이렇게 Servlet 클래스와 URL의 매핑을 해주어야지만 클라이언트에서 /todo URL로 요청을 보냈을때 /todo URL에 매핑되는 TodoServlet 클래스가 요청을 처리할 수 있습니다.

==== ToDoServlet ====

package com.itvillage.servlet;

import com.itvillage.vo.ToDo;

import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

@WebServlet(name = "TodoServlet")
public class TodoServlet extends HttpServlet {
    // Database를 대신한다.
    private List<ToDo> todoList;

    @Override
    public void init() throws ServletException {
        super.init();
        this.todoList = new ArrayList<>();
    }

    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        request.setCharacterEncoding("UTF-8");
        response.setContentType("text/html;charset=UTF-8");

        System.out.println("Hello Servlet doPost!");

        String todoName = request.getParameter("todoName");
        String todoDate = request.getParameter("todoDate");

        todoList.add(new ToDo(todoName, todoDate));

        RequestDispatcher dispatcher =
                request.getRequestDispatcher("/todo_model2.jsp");
        request.setAttribute("todoList", todoList);

        dispatcher.forward(request, response);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        System.out.println("Hello Servlet doGet!");

        RequestDispatcher dispatcher =
                request.getRequestDispatcher("/todo_model2.jsp");
        request.setAttribute("todoList", todoList);
        dispatcher.forward(request, response);
    }
}

클라이언트에게서 받은 요청을 처리하는 TodoServlet 클래스입니다. doPost()에서 할 일을 등록한 후, 등록된 할 일 데이터를 JSP로 넘겨주고 doGet()에서는 단순히 등록된 할일을 JSP로 넘겨줍니다.

doPost() 안에 있는 소스 코드들은 이전 시간에 봤던 모델1 방식에서 result_model1.jsp 안에 포함되어 있던 코드들인데 이렇게 TodoServlet 클래스 안으로 분리되었습니다.

==== todo_model2.jsp ====

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
<html>
<head>
    <meta http-equiv="Content-Language" content="ko"/>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

    <title>TODO 등록</title>
    <style>
        #todoList {
            border: 1px solid #8F8F8F;
            width: 500px;
            border-collapse: collapse;
        }

        th, td {
            padding: 5px;
            border: 1px solid #8F8F8F;
        }
    </style>
    <script>
        function registerTodo(){
            var todoName = document.getElementById("todoName").value;
            var todoDate = document.getElementById("todoDate").value;

            if(!todoName){
                alert("할일을 입력해주세요.");
                return false;
            }
            if(!todoDate){
                alert("날짜를 입력해주세요.");
                return false;
            }

            var form = document.getElementById("todoForm");
            form.submit();

        }
    </script>
</head>
<body>
    <h3>TO DO 등록</h3>
    <div>
        <form id="todoForm" method="POST" action="/todo">
            <input type="text" name="todoName" id="todoName" value=""/>
            <input type="date" name="todoDate" id="todoDate" value=""/>
            <input type="button" id="btnReg" value="등록" onclick="registerTodo()"/>
        </form>
    </div>
    <div>
        <h4>TO DO List</h4>
        <table id="todoList">
            <thead>
                <tr>
                    <td align="center">todo name</td>
                    <td align="center">todo date</td>
                </tr>
            </thead>

            <tbody>
                <c:choose>
                    <c:when test="${fn:length(todoList) == 0}">
                        <tr>
                            <td align="center" colspan="2">할 일이 없습니다.</td>
                        </tr>
                    </c:when>
                    <c:otherwise>
                        <c:forEach items="${todoList}" var="todo">
                            <tr>
                                <td>${todo.todoName}</td>
                                <td align="center">${todo.todoDate}</td>
                            </tr>
                        </c:forEach>
                    </c:otherwise>
                </c:choose>
            </tbody>
        </table>
    </div>
</body>
</html>

todo_model2.jsp는 todo_model1.jsp와 변한게 없으므로 넘어가겠습니다.

자, 그럼 지난 시간과 마찬가지로 이번에도 우리가 배워야 할 기술들을 추출해 보겠습니다. 눈치채신 분도 계시겠지만 이번 시간에 변화 된것은 딱 한가지 밖에 없습니다. 바로 Servlet입니다. 저희가 배워야 될 기술에 Servlet만 포함시키면 됩니다.

"오래된 방식인데 꼭 배워야 해?"라고 말씀하시는 분들이 많겠지만 일단 포함을 시켜보겠습니다. Servlet이 포함된 추가된 로드맵은 다음과 같겠죠?

[JSP 모델2 방식에서 추가된 개발자 로드맵]

자, 그럼 Servlet은 과연 배워야 할까요? Servlet을 사용하고 있는 회사라면 당연히 배워야됩니다. 하지만 아직도 Servlet을 사용하고 있는 기업이라면.. 음.. 저 멀리 아주 멀리, 시대에 동 떨어진 회사라고 봐도 될 것 같습니다.

Servlet을 여전히 메인 방식으로 사용하고 있는 회사라면 과감하게 입사를 포기하든가 아니면 입사하셔서 여러분이 직접 회사를 바꾸시면 되겠습니다. ^^;

오늘은 이쯤에서 포스팅을 마치기로 하고, 다음 시간에는 오늘 포스팅 한 소스 코드를 살짝만 더 개선해보도록 하겠습니다.

그럼 좋은 주말 보내세요~

[ Kevin의 알기 쉬운 Java 개발자 로드맵 이야기 ] 인프런 강의 바로가기

현실적인 개발자 로드맵(2) - 무엇부터 배워야 할까요?

Kevin's IT Village — Sat, 1 Sep 2018 17:54:38 +0900

현실적인 개발자 로드맵 - 무엇부터 배워야 할까요?

# 포스팅에서 사용된 코드의 전체 코드는 https://github.com/ITVillage-Kevin/roadmap-jsp 에서 다운로드 받으실 수 있습니다.

# 해당 포스팅은 IT Village 유튜브 채널(https://www.youtube.com/channel/UCSIvsntWA8aJ3Apoc7kTxig)에서도 시청하실 수 있습니다.

안녕하세요, Kevin입니다. 지난 시리즈에 이어 오늘은 개발자가 되려면 무얼 배워야 하는지에 대한 이야기부터 하겠습니다. 당연한 이야기이겠지만 개발자가 되기위해서 배워야 할 기술들은 상당히 다양하고 많습니다. 그리고 여기서 말하는 개발자는 주로 웹 개발자입니다. 아래 로드맵을 먼저 살펴보시면 "우와, 이걸 언제 다 배워??" 라고 한숨부터 나올지도 모르겠네요. ^^ 그래도 일단 스크롤을 내려서 끝까지 주욱 살펴보시길 권해드립니다.ㅎ

2018 웹 개발자 로드맵

[출처: https://github.com/devJang/developer-roadmap]

현실적인 개발자 로드맵

쭈욱 살펴 보셨나요? 참고로 위에서 보셨던 로드맵은 번역본이고 실제 작성자는 해외에서 활동하시는분으로 추정되며(작성하신분은 현재 독일 베를린에서 활동하시는 개발자인것 같습니다.), 해외에서 개발자로 일을 하고 싶으신 분에게 추천 드리고 싶은 좋은 로드맵이라고 생각됩니다. 물론 이 로드맵의 작성자분도 필수적으로 알아야 할 부분과 선택적으로 배우길 추천하는 부분을 색깔로 잘 표시해놨지만 저는 일단 이 로드맵 안에 있는 항목들 중에서 웹 개발자로써 취업을 하기 위해서 최소한으로 배워야 할 기술들만 추스려서 말씀을 드릴생각입니다. 특히나 한국의 특수한 상황을 고려해서 한국에서 취업하기에 조금이라도 더 용이한 기술들 위주로 말씀드리겠습니다. 이건 어디까지나 저의 개인적인 의견일 뿐이니 다른 의견을 가지시는 분이 있으시면 언제든지 댓글로 남겨주시면 감사드리겠습니다.^^

여러분들의 이해를 쉽게 하기 위해서 우선 간단한 코드를 먼저 보여드리고, 해당 코드에서 저희가 배워야 할 기술들을 추출해서 간단하게 로드맵을 한번 그려보겠습니다.

클라이언트 + 서버(JSP Model 1)

먼저 아래의 구성도를 한번 보도록 하겠습니다. 아래 구성도는 JSP Model1 방식의 아키텍처인데요. 웹 애플리케이션을 만들기 위한 서버측 언어로는 JSP, PHP, ASP 등이 있는데, 제가 Java 개발자이기때문에 JSP를 기준으로 우선 설명을 드리도록 하겠습니다.

[JSP 모델1 구성도]

JSP Model1 방식은 아주 오래된 개발 방식인데 이를 설명하는 이유는 오래된 기술을 간단하게 리뷰함으로 인해서 오늘날 사용하고 있는 최신 기술들이 얼마나 잘 발전되어 왔는지를 조금 더 체감을 할 수 있지 않을까라고 생각하기때문입니다. 이 기술을 어떻게 사용하는지도 중요하지만 이 기술을 왜 사용해야 하는지에 대해서 알고 난 후에 해당 기술을 사용하는것이 훨씬 중요하다는 생각때문에 JSP 까지 설명을 하고 있네요. ^^

구성도를 보시면 웹 브라우저에서 요청을 받은 서버에서 JSP를 통해 해당 요청을 가공한 후, HTML 페이지를 응답으로 돌려줍니다. 실제로 JSP 코드를 보시면 HTML 코드와 JSP 코드가 뒤섞여있는것을 보실 수 있습니다.

여러분들의 이해를 조금 더 돕기 위해서 초간단 TODO 애플리케이션을 만들었습니다. 아래 화면을 보시죠.

[TO DO 웹 애플리케이션]

할일과 날짜를 입력하고 서버측으로 전송하는 간단한 애플리케이션인데요. 이 애플리케이션의 소스 코드를 보면서 저희가 배워야 할 기술들을 한번 추출해보도록 하겠습니다.

그럼, JSP Model1 방식으로 구성된 TO DO 애플리케이션의 소스 코드를 보시죠.

==== todo_model1.jsp ====

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
<html>
<head>
    <meta http-equiv="Content-Language" content="ko"/>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

    <title>TODO 등록</title>
    <style>
        #todoList {
            border: 1px solid #8F8F8F;
            width: 500px;
            border-collapse: collapse;
        }

        th, td {
            padding: 5px;
            border: 1px solid #8F8F8F;
        }
    </style>
    <script>
        function registerTodo(){
            var todoName = document.getElementById("todoName").value;
            var todoDate = document.getElementById("todoDate").value;

            if(!todoName){
                alert("할일을 입력해주세요..");
                return false;
            }
            if(!todoDate){
                alert("날짜를 입력해주세요.");
                return false;
            }

            var form = document.getElementById("todoForm");
            form.submit();

        }
    </script>
</head>
<body>
    <h3>TO DO 등록</h3>
    <div>
        <form id="todoForm" method="POST" action="/result_model1.jsp">
            <input type="text" name="todoName" id="todoName" value=""/>
            <input type="date" name="todoDate" id="todoDate" value=""/>
            <input type="button" id="btnReg" value="등록" onclick="registerTodo()"/>
        </form>
    </div>
    <div>
        <h4>TO DO List</h4>
        <table id="todoList">
            <thead>
                <tr>
                    <td align="center">todo name</td>
                    <td align="center">todo date</td>
                </tr>
            </thead>

            <tbody>
                <c:choose>
                    <c:when test="${fn:length(todoList) == 0}">
                        <tr>
                            <td align="center" colspan="2">할 일이 없습니다.</td>
                        </tr>
                    </c:when>
                    <c:otherwise>
                        <c:forEach items="${todoList}" var="todo">
                            <tr>
                                <td>${todo.todoName}</td>
                                <td align="center">${todo.todoDate}</td>
                            </tr>
                        </c:forEach>
                    </c:otherwise>
                </c:choose>
            </tbody>
        </table>
    </div>
</body>
</html>

할일과 날짜를 입력 받아서 리스트로 표시하는 뷰 페이지입니다. 앞에서 말씀드린대로 <tbody></tbody> 부분에 보면 HTML 코드와 JSP 코드가 뒤섞여 있는것이 보이시나요?

==== result_model1.jsp ====

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
<%@ page import="com.itvillage.vo.ToDo" %>

<%
    request.setCharacterEncoding("UTF-8");
    response.setContentType("text/html;charset=UTF-8");

    System.out.println("Hello Servlet doPost!");

    String todoName = request.getParameter("todoName");
    String todoDate = request.getParameter("todoDate");

    ToDo.todoList.add(new ToDo(todoName, todoDate));

    RequestDispatcher dispatcher = request.getRequestDispatcher("/todo_model1.jsp");
    request.setAttribute("todoList", ToDo.todoList);

    dispatcher.forward(request, response);
%>
<html>
<head>
    <meta http-equiv="Content-Language" content="ko"/>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

    <title>TODO 등록</title>

    <script>

    </script>
</head>
<body>

</body>
</html>

todo_model1.jsp에서 랜더링된 뷰 페이지, 즉 할 일 등록 폼에서 사용자가 할 일을 입력하면 result_model1.jsp에서 해당 데이터를 저장 한 후에 다시 todo_model1.jsp로 포워딩 시킵니다. 여기서는 간단한 애플리케이션인지라 DB를 사용하지 않고, ArrayList에 할 일 데이터를 저장했습니다.

==== ToDo.java ====

package com.itvillage.vo;

import java.util.ArrayList;
import java.util.List;

public class ToDo {
    private String todoName;
    private String todoDate;
    public static List todoList = new ArrayList<>();

    public ToDo(String todoName, String todoDate) {
        this.todoName = todoName;
        this.todoDate = todoDate;
    }

    public String getTodoName() {
        return todoName;
    }

    public String getTodoDate() {
        return todoDate;
    }
}

사용자가 입력한 할 일 데이터를 저장하는 Java Bean 클래스입니다. 이 Java Bean에 담아서 DB에 저장하는것이 일반적이나 여기서는 ArrayList에 담아서 메모리에서 가지고 있습니다. 물론 서버를 restart 시키면 해당 데이터는 사라지겠죠.

자, 그럼 이 JSP 모델 1 방식의 소스 코드로부터 저희가 배워야 할 기술들이 뭐가 있는지 한번 추출 해 볼까요?

[JSP 모델1 방식에서 추출한 기술]

짜잔~ 여러가지 기술들이 추출 되었습니다. ^^ 웹 브라우저에서 사용자들에게 보여지는 부분은 HTML로 구성이 됩니다. 그리고 HTML로 구성된 화면을 조금 더 예쁘게 보여주기 위해서 CSS가 사용되며, 폼을 전송하는 부분에서는 Javascript가 사용이 됩니다.

사실 Javascript를 TODO 애플리케이션에서 사용하지 않고, 데이터를 전송할 수 있으나 실무에서는 폼 데이터를 전송하기 전에 클라이언트측에서 데이터를 전송하기 전에 해당 데이터가 올바른 데이터인지 검사를 하는데 그 검사를 Javascript가 맡아서 하게 되는겁니다. 물론 Javascript로 검사한다고 해서 그 검사를 우회해서 데이터를 변조하는 방법이 있기때문에 서버측에서 반드시 유효성 검사를 다시 해야되나 이런 부분은 주제를 벗어나기때문에 우선은 생략하도록 하겠습니다.

HTML과 Javascript, CSS는 개발자가 되기 위한 필수 기술이기때문에 꼭 학습을 해야되는 부분입니다. 다만 Javascript를 공부하다보면 굉장히 방대하고 공부하면 할수록 점점 어려워진다는 사실을 알 수 있을텐데 Javascript를 많이 알고 능숙하게 사용하실 수 있다면 그만큼 자신의 경쟁력을 향상시키는것이라고 보시면 될것 같네요. ^^

그럼 JSP는 배워야 할까요 배우지 말아야 할까요? 이건 어떤 기업에 입사를 하느냐에 많이 좌우되는데 Ajax 기술이 발달함으로 인해서 JSP의 사용 빈도는 점점 줄어들고 있는 추세입니다. 기술 트렌드를 잘 따라가는 기업일수록 JSP 사용 빈도가 작지 않을까 생각합니다.

Java는 Java 개발자가 되기위해서는 반드시 알아야 될 기술이기에 따로 설명을 드리지 않아도 되겠죠? ^^

데이터베이스의 경우 클라이언트 측으로부터 전달 받은 데이터를 저장하는 가장 범용적인 방법이기때문에 반드시 배우셔야 하는데 MySQL(또는 MariaDB) 등의 오픈 소스 DB에 대한 사용법과 SQL 쿼리 작성에 대한 학습을 꾸준히 하시는게 좋을것 같습니다. 데이터베이스 종류가 다양하지만 한국에서 가장 많이 사용되는 데이터베이스는 MySQL(또는 MariaDB)과 Oracle + MSSQL 이지 않을까 하는데요. 기업에서는 PHP + MySQL(또는 MariaDB), JSP + Oracle, ASP + MSSQL 의 조합으로 많이들 사용해왔습니다.

마지막으로 말씀드릴게 IDE(Integrated Development Enviroment)인데요.

코딩, 디버깅, 테스트, 컴파일, 배포를 하나의 환경에서 할 수 있도록 제작된 한마디로 말해서 맥가이버 같은 개발 도구라고 보시면 됩니다. 자바 개발에 있어서 오픈 소스 IDE인 이클립스가 전통적으로 가장 많이 사용되고 있을것으로 생각됩니다. 저는 개인적으로 몇년전부터 IntelliJ를 사용하고 있는데 현재까지는 최고의 IDE라는 생각이 듭니다. 기업에서 사용하려면 유료라는게 단점이긴 하지만 개인이 사용 가능한 커뮤니티 버전이나 학생용 라이센스를 잘 활용할 수 있으니 참고하시길 바랍니다. IDE 이외에 서브라임텍스트, Atom 등의 Editor가 있으니 참고하시길요.

이번 시간에는 JSP Model1 방식을 통해 웹 개발자로 입문하기 위해서 무엇부터 배워야 할지를 알아보았는데요. 제가 Java 개발자인 관계로 서버측 언어로 Java를 사용하고 있으니 이 점 염두에 두시고 읽어주시면 감사드리겠습니다.

다음 시간에는 JSP Model1 방식의 문제점을 살펴보고 이를 개선한 방식에서 저희가 알아야 할 기술에는 어떤게 있는지 살펴보도록 하겠습니다.

그럼 좋은 하루 보내시길 바라면서..

[ Kevin의 알기 쉬운 Java 개발자 로드맵 이야기 ] 인프런 강의 바로 가기

[참고 사이트]

https://github.com/kamranahmedse/developer-roadmap

https://github.com/devJang/developer-roadmap

https://namu.wiki/w/JSP

https://ko.wikipedia.org/wiki/PHP

https://ko.wikipedia.org/wiki/%EC%95%A1%ED%8B%B0%EB%B8%8C_%EC%84%9C%EB%B2%84_%ED%8E%98%EC%9D%B4%EC%A7%80

https://ko.wikipedia.org/wiki/%EC%9E%90%EB%B0%94%EB%B9%88%EC%A6%88

https://www.w3schools.com/html/default.asp

https://www.w3schools.com/css/default.asp

https://www.w3schools.com/js/default.asp

https://ko.wikipedia.org/wiki/Ajax

https://www.eclipse.org/

https://www.jetbrains.com/idea/

https://www.sublimetext.com/

https://atom.io/

현실적인 개발자 로드맵(1) - Intro

Kevin's IT Village — Fri, 31 Aug 2018 12:44:52 +0900

안녕하세요? Kevin 이라고 합니다.

블로그 개설한지 4년이나 지났는데 바쁘다는 핑계로 거의 방치하다시피 했네요. 아주 아주 새로운 마음으로 이제 다시 시작하려 합니다. ^^

제 소개를 잠깐 드리자면, 저는 올해로 개발 10년차가 되는 자바 개발자로 대한민국에서 꿋꿋하게 개발자로 버티고 살아가고 있는 평범한(?) 40대 현업 개발자입니다. ㅡ.,ㅡ;

개발자로 억지로 버티면서 살아가고 싶은 마음은 눈꼽만큼도 없지만 주위에서 저를 버티고 살아가게 만들더군요. 개발자로 즐겁게 살아갈 수 있는 날이 올 수 있으려나 모르겠지만 저 나름대로 개발을 천직으로 알고 즐겁게 살아가기 위해 노력중이죠. 아무튼 제 얘기는 글을 쓰면서 종종 들려드리도록 하구요.

IT Village 라는 블로그를 시작하게 된 계기, 그리고 앞으로 블로그를 어떤식으로 운영할 것인가에 대해서 짤막하게 나마 말씀을 드리는것이 제 블로그를 찾아주시는 분들이 조금 더 관심을 가지고 제가 올린 글들을 흥미롭게 읽어주시고 그 분들에게 작은 도움이나마 드릴 수 있지 않을까 하네요.

블로그 시작 계기

그럼 먼저 이 블로그를 시작하게 된 계기를 짤막하게 얘기 드려볼까요? ^^;

사실 이 블로그 이전에 제가 10년전부터 운영을 했던 IT Village 카페(http://cafe.daum.net/ITVillage)가 현재도 존재합니다. 회원수가 무려 500명이 넘는다는.. ^^; 회원수가 너무 작죠?

뭐 어쨌든간에 이 카페에 나름 제가 10년동안 개발자 생활을 해오면서 나름 개발 입문자분들에게 도움을 주고자 많은 글들을 포스팅했는데,

기술이 하루가 다르게 변해가는데도 불구하고 이직, 결혼 등등으로 인해 3년전부터 거의 관리를 못하게 되었더랬습니다. 이렇게 관리를 못하고 방치를 할 바에는 차라리

카페를 폐쇄할까라는 생각도 했었는데 그러기에는 가끔씩 찾아주시는 회원분들의 “좋은 정보 알게되어서 감사합니다”라는 한마디에 차마 그럴 수 없었네요. ㅠㅠ

결론은 여전히 카페에 남아 있는 단 하나의 유용한 정보라도 찾아주시는 분들에게 제공할 수 있기때문에 카페는 회원제가 아닌 누구나 정보를 확인할 수 있도록 오픈할 예정입니다.

그리고 카페에 남기지 못했던 나날이 변해가는 기술들에 대한 이야기는 이곳 IT Village 블로그에서 모두 하려합니다. 부디 이곳에서도 많은 분들에게서 도움이 되었다는 한마디를 들을 수 있길 바래보겠습니다.

블로그 포스팅 방식 및 순서

어제, 오늘 한강 시민 공원을 뛰면서 블로그를 어떤 식으로 운영하는것이 좋을까라고 숨을 헐떡헐떡 거리면서 생각을 해봤었는데요.ㅎ

기존의 카페와 블로그에 포스팅한 글들은 거의 대부분이 독자들을 배려했다기 보다는 제 위주의 글들이었고, 소프트웨어 개발에 처음 입문하는분들에 대한 배려가 거의 없었다고 생각합니다.

의도된건 아니지만 아무튼 그랬습니다. 어쨌거나 이 블로그에서는 소프트웨어 개발 입문자들이나 초급 개발자분들한테 실질적으로 도움을 줄 수 있는 현실적인 이야기들을 많이 하려고합니다.

블로그도 블로그이지만 블로그로 나누기에 부족한 내용들의 경우 다른 SNS나 유튜브를 통해서 소통을 할 수 있도록 노력할 생각입니다.

현재까지 생각한 포스팅 순서는 다음과 같습니다.

Intro

Intro에서는 소프트웨어 개발 입문자들이 현시점에서 알아야하는 기술들이 어떤것들이 있는지 간단한 프로젝트를 같이 수행해보면서 입문자분들이 개발자로서 바른길을 걸어갈 수 있는 방향을 제시할 수 있는 로드맵을 그려보는것을 위주로 포스팅을 할까 합니다.

그 외에 입문자들이 실무에서 반드시 알았으면 좋겠다 싶은 내용이 있으면 제가 알고 있는것들은 모두 알려드려볼까 합니다. 회사 생활하면서 겪은 내용들이 많으니 작은 도움이라도 드릴 수 있지 않을까 생각하게 되네요.

제가 자바 개발자이다 보니 주로 자바 개발 위주로 알려드리긴 하겠지만 프로그래밍 언어와 상관없는 공통 부분도 존재한다는것 또한 미리 말씀을 드리겠습니다.

40대 개발자 생존 전략

말씀 드렸다시피 저는 현재 40대 초중반을 바라보는 현업 자바 개발자입니다. ^^;

대한민국에서 40대 개발자로 살아간다는게 흔한 일인지 드문 일인지 솔직히 잘은 모르겠지만 다만, 제 주위의 현실을 객관적으로 들여다보면 40대 개발자가 그리 많지 않은것 같다가 제 결론입니다.

저희 회사만 해도 저랑 비슷한 나이대 분들중에 개발하시는 분들은 한분도 못봤습니다. 저빼고 모두 팀장, 부서장, 임원급이라는.. ㅡ.ㅡ; 한마디로 관리직이나 영업직이라는 얘기죠.

여러분들은 어떠세요? 40대가 되어서도 여전히 개발을 하고 싶으신가요? 아니면 개발을 하고 싶은데 어쩔 수 없이 관리직이나 영업직으로 전환하고 싶으신가요? 저는 백발이 희끗해도(물론 지금도 흰머리가 셀 수 없이 많긴하지만..ㅎ) 여전히 개발이 하고 싶기때문에 저와 같은 생각을 가지고 계신분들에게 어떻게 하면 40대에도 여전히 개발을 할 수 있는지에 대해 제 경험과 생각을 들려드릴까합니다.

저와 비슷한 생각을 가지는 분들에게 조금이나마 도움이 될 수 있길 바라면서 조심스럽게 글을 써 볼 예정이니 조금만 기다려주시길 부탁드려볼게요.

프로그래밍 강좌

현업에 종사하시는 많은 분들, 그리고 현업에 종사하지 않더라도 프로그래밍에 관심있는 멋진 분들이 프로그래밍 강좌를 많이들 올려주셔서 저도 그런 강좌들을 보면서 많은 것을 배워왔더랬습니다. 그렇기때문에 저 역시도 제가 알고 있는 프로그래밍 언어들에 대한 강좌를 진행해볼까 합니다.

Intro 섹션에서 나중에 말씀드리겠지만 거기서 만든 로드맵에 있는 기술들중에서 제가 알고 있는 기술들에 한해서 강좌를 진행해볼 생각입니다. 10년차 개발자이지만 여전히 부족한것이 많은 놈이니 강좌를 보시고 부족한 부분이 보이면 언제든지 말씀해주시면 감사드리겠습니다. 그래야 저도 더 배우고 성장할 수 있으니까요.

이게 끝나면 뭘 할까요? 끝날리가 없죠. ^^ 저 3가지만해도 많은 시간이 흘러갈테고, 그때가 되면 또 새로운 이야기들을 할 수 있는 기회가 계속 생길꺼라고 봐요. ^^

개인적으로 맥주를 사랑하는 저이기때문에 기회가 되면 맥주에 대한 포스팅도 번외로 진행을 해볼까 합니다.

그럼 다음 시간에는 간단한 프로젝트를 진행 해보면서 개발 입문자들을 위한 앞으로의 로드맵을 그려보도록 하겠습니다.

그럼 다음 시간에 뵙도록 하겠습니다. Coming soon..

[kevin의 알기 쉬운 Java 개발자 로드맵 이야기] 인프런 강의 바로가기

소프트 키보드 오픈 시, 리스트뷰의 아이템(체크박스, 버튼 등) 상태 유지 안됨

Kevin's IT Village — Fri, 3 Feb 2017 13:15:19 +0900

안드로이드 학습을 하다가 다시 그만두다가를 반복했는데 필요에 의해서 다시 학습을 시작하고 있다.

1차 목표는 리스트 뷰를 사용하여 아이템을 등록하고, 해당 아이템의 상태를 변경하는 간단한 앱을 만들어서 마켓에 올리는 것이다.

[그림1] 아이템의 상태 변경

[그림2] 아이템의 상태 변경

개발중에 가장 문제가 되었던것중에 하나가

우선, [그림1]에서와 같이 아이템의 체크박스에 체크를 하고, 구매 상태를 변경한 후에 EditText에 포커싱이 되어서 소프트 키보드가 오픈이 되는 순간

[그림1]에서 변경했던 상태가 [그림2]에서처럼 유지가 되지 않는것이었다.

How to use ng-cloak

Kevin's IT Village — Tue, 7 Jun 2016 10:16:18 +0900

Users may see expressions which is defined at inline template, when they use a device with low speed.

In that case, We can use ng-cloak directive.

<input type="radio" ng-model="data.mode" value="{{button}}" ng-checked="$first"/> {{button}}

</label>

</div>

<thead>

<tr>

<th>Action</th>

</tr>

</thead>

<td>{{$index + 1}}</td>

</tr>

</table>

</div>

<ol>

{{item.action}}<span ng-if="item.complete">(Done)</span>

</li>

</ol>

</div>

Select another option to display a layout

</div>

Listing up branch

Kevin's IT Village — Wed, 12 Aug 2015 08:10:19 +0900

* Listing up just local branch

$ git branch

* RB_1.0.1

master

IT Village

AI 시대에 Java 개발자로 입문하기 위한 경쟁력에 대한 이야기

1. Java 개발자로 입문하는 길은 더 좁아졌다?

2. 개발자는 더 적게 필요해진다?

3. 어떻게 보면 좋은 개발자가 되기 더 쉬워졌을 수 있다.

4. AI 시대에 맞는 경쟁력 있는 좋은 개발자란?

5. 아는만큼 활용할 수 있는 AI

6. 프로그래밍 기본기를 습득하는 방식의 변화

7. 미니 프로젝트를 스스로 해보는 것의 중요성

7. 결론

Spring Boot 콘솔 애플리케이션에서 H2 인메모리 데이터베이스를 TCP 서버 모드로 설정하는 방법

✅ Spring Boot 콘솔 프로젝트에서 H2 DB를 TCP 서버 모드로 설정하는 이유

웹 애플리케이션 vs 콘솔 애플리케이션의 차이점

H2 TCP 서버 모드 설정 방법

1. Spring Boot 기본 H2 설정

2. H2 TCP 서버를 코드로 실행하기

IntelliJ에서 연결하기

흔히 발생하는 오류와 해결 방법

잘못된 설정 예시

정상 설정 예시

H2 관련 포트 정리

마무리 요약

[4편] 1부 이후, 2부에선 어떤 걸 배우게 될까?

1부는 입문, 2부는 확장입니다

2부에서 바뀌는 것들

✅ 프로젝트의 성격이 달라집니다

✅ 설계가 더 중요해집니다

✅ 테스트와 리팩터링의 감각을 배웁니다

조금 더 실무에 가까워지는 여정

이런 분께 2부를 추천합니다

강의 둘러보기

시리즈 목차

[3편] 강의 방식: 스스로 만들고, 비교하며 성장하기

직접 해보는 것만큼 강력한 학습은 없다

그다음, 비교가 시작됩니다

혼자 구현할 때 얻는 것

코드가 아니라, '사고방식'을 배우는 강의

참고 강의

시리즈 목차 & 다음 글 안내

[2편] 작은 프로젝트에서 배우는 객체지향

객체지향은 '이해'보다 '적용'이 어렵다

작은 프로젝트 = 객체지향 훈련장

중요한 건 '정답'이 아니라 '시도'

이 강의에서는 이런 훈련을 합니다

참고 강의

시리즈 목차 & 다음 글 안내

[1편] 왜 구현이 막막할까? – Java 입문자의 고민

익숙하지만 낯선 그 순간

제자들의 사례

이유는 명확합니다

그래서 이 시리즈를 시작합니다

참고 강의

시리즈 목차 & 다음 글 안내

[0편] “Java 문법은 아는데 구현이 막막해요” – 그럴 땐 이렇게 했습니다

Java 프로젝트가 막막할 때, 작게 시작해 보세요

Spring 전에, 작고 단단한 구현 경험이 필요합니다

이 강의는 어떤 강의인가요?

이런 분들에게 꼭 추천합니다

수강 전 vs 수강 후, 이렇게 달라집니다

수강생의 실전 감각을 키우는 방식

지금 수강하면 할인된 가격에 수강할 수 있어요

이 강의로 기대할 수 있는 것

관련 시리즈 안내

마무리

시리즈 목차 & 다음 글 안내

Java Stream API 한방에 이해하기

Java의 Stream은 위에서 아래로 흐르는 시냇물이다

Stream은 각자 자기 할 일만 한다

Stream은 ‘대용량 데이터’를 흘려 보내기 위해 태어났다

기존 방식:

Stream 방식:

Java의 Stream과 Lambda는 베스트 프렌드이다. 그래서 게으르다

Stream을 어떨 때 사용하면 좋을까?

실제로 어떻게 써보면 좋을까?

JwtAuthorizationFilter에 try ~ catch 문이 있고, 없고의 차이

JwtAuthorizationFilter에서 인증이나 접근 권한 등의 예외를 try ~ catch로 잡는 경우

JwtAuthorizationFilter에서 인증이나 접근 권한 등의 예외를 try ~ catch로 잡지 않는 경우

ObjectMapper를 이용한 JSON 역직렬화(Deserialization) 이야기

디폴트 생성자가 있을 경우,

디폴트 생성자가 없을 경우,