baby-t 님의 블로그

[DB Deep Dive] 5. 내 쿼리의 성적표 EXPLAIN: Using filesort 제거와 Using where의 이해

baby-t — Thu, 21 May 2026 23:32:48 +0900

1. 대용량 스파이크 부하 테스트: 옵티마이저를 깨워라

지난 [상편]에서 우리는 데이터가 고작 43건일 때 MySQL 옵티마이저가 복합 인덱스를 무시하고 풀 테이블 스캔(ALL)을 때려버리는 영리한 배신을 목격했습니다. 인덱스의 진짜 위력을 증명하기 위해, 저는 JMeter를 활용하여 운영 환경과 유사한 대용량 트래픽을 강제로 발생시키기로 했습니다.

단순히 데이터를 넣는 것을 넘어 서버의 비동기 처리(Async) 성능까지 함께 검증하기 위해, Ramp-up(진입 시간)을 단 1초로 설정하고 10,000건의 주문 요청을 동시에 쏘는 스파이크(Spike) 부하 테스트를 세팅했습니다. 찰나의 순간에 쏟아지는 폭격을 Tomcat 스레드와 비동기 큐가 어떻게 버텨낼지 확인하기 위함이었습니다.

2. 예기치 못한 에러, 그러나 완벽한 TPS 측정

JMeter 발사 버튼을 누르고 찰나의 시간이 흐른 뒤 결과를 확인해보니, 예기치 못한 상황이 발생했습니다. 10,000건의 주문이 모두 비즈니스 로직 단에서 "잔액 부족" 사유로 차단(실패)된 것입니다.

홈페이지 거래 내역

실패한 테스트일까? 오히려 완벽한 시스템 한계 측정!

주문은 비록 잔액 부족으로 튕겼지만, JMeter의 결과 지표 중 Throughput: 400.3/sec라는 아주 유의미한 수치를 얻어냈습니다. 1초 만에 10,000개의 요청이 쏟아졌음에도 서버가 터지지 않고(Error 0%), 초당 400건(TPS)의 속도로 꾸역꾸역 예외 처리를 해내며 비동기 큐를 안정적으로 비워냈다는 뜻입니다. 단일 서버 기준 훌륭한 방어력을 증명한 셈입니다.

JMeter 결과

무엇보다 중요한 것은, 주문 상태가 '실패'로 처리되었을 뿐 orders 테이블에는 제 user_id와 order_date가 박힌 물리적인 데이터가 10,000건 이상 완벽하게 INSERT(적재) 되었다는 사실입니다. 드디어 옵티마이저를 자극할 충분한 모수가 모였습니다.

3. 짜릿한 성적표: type: ref와 사라진 filesort

데이터가 2만 건 가까이 적재된 상태에서, 드디어 떨리는 마음으로 [상편]에서 날렸던 그 쿼리 앞에 다시 EXPLAIN을 붙여 실행해 보았습니다.

실행계획 결과

✨ 최종 EXPLAIN 검증 결과 (데이터 누적 후)

type : ref (복합 인덱스 사용 성공!)
key : idx_user_date
rows : 2 (필요한 소량의 데이터만 스캔 예측)
Extra : NULL (Using filesort 완벽 제거!)

결과는 완벽한 대성공이었습니다. 데이터가 많아지자 옵티마이저는 풀 테이블 스캔을 포기하고 드디어 우리가 설계한 복합 인덱스(idx_user_date)를 타기 시작했습니다 (type: ref).

가장 짜릿한 부분은 악명 높았던 Using filesort가 감쪽같이 사라졌다는 점입니다. 복합 인덱스의 순서를 (user_id, order_date)로 묶어둔 덕분에, B+Tree 인덱스를 타는 순간 데이터가 이미 order_date 순으로 정렬되어 있어 DB가 메모리 위에서 추가적인 정렬(Sorting)을 할 필요가 완벽히 사라진 것입니다. (참고: SELECT * 로 엔티티 전체를 조회하여 Data Lookup이 발생했기에 커버링 인덱스(Using index) 대신 Extra가 비어있는 가장 건강한 상태가 출력되었습니다.)

4. [심화 트러블슈팅] 인덱스에 없는 조건을 추가하면 어떻게 될까?

인덱스가 완벽히 작동하는 것을 확인한 후, 저는 호기심이 생겼습니다. "방금 실패한 거래가 많았으니, 상태가 '실패'인 거래내역 20건만 가져오도록 WHERE 절 조건을 추가하면 어떻게 될까?"

WHERE user_id = 1 AND status = '실패' 조건을 넣고 실행 계획을 까본 결과, type은 여전히 ref로 인덱스를 잘 타고 있었지만, Extra 컬럼에 Using where가 등장하고 filtered 컬럼에 50.00이 찍혔습니다. 이것은 성능 저하를 의미하는 걸까요?

실행계획 결과

Using where와 카디널리티(Cardinality)의 미학

우리의 인덱스에는 status(상태) 정보가 없습니다. 따라서 스토리지 엔진은 user_id만 보고 인덱스를 타서 데이터를 가져온 뒤, MySQL 엔진 레벨에서 status = '실패'가 아닌 데이터들을 직접 쳐내는 필터링 작업을 수행합니다. 이때 등장하는 메시지가 바로 Using where입니다.

"그럼 복합 인덱스를 (user_id, status, order_date) 3개로 묶으면 Using where도 안 뜨고 더 빠른 거 아냐?" 라고 생각할 수 있지만, 이는 실무적으로 좋은 선택이 아닙니다. status(성공, 실패, 대기)처럼 값의 종류가 몇 개 없는 컬럼은 카디널리티(Cardinality)가 극도로 낮아 인덱스 트리에 추가해 봤자 변별력이 떨어지고 용량 오버헤드만 커집니다. 차라리 지금처럼 user_id로 1차 스캔 범위를 대폭 줄인 뒤, 나머지 데이터를 Using where로 가볍게 필터링하게 두는 것이 성능과 용량 사이의 완벽한 트레이드오프(Trade-off)입니다.

5. 시리즈를 마치며: 인덱스는 마법이 아니라 '구조적 설계'다

B+Tree의 기본 원리를 다룬 1편, 커버링 인덱스와 물리 구조의 차이를 분석한 2편에 이어, JMeter 부하 테스트와 EXPLAIN으로 제 프로젝트의 쿼리 성능을 수치로 증명해 낸 3편 실전 튜닝기까지 대장정이 마무리되었습니다.

이 과정을 통해 "인덱스만 걸면 무조건 빠를 것이다"라는 막연한 환상을 완벽하게 깰 수 있었습니다. 데이터의 모수(건수)에 따라 영리하게 노선을 변경하는 옵티마이저를 이해하고, 비동기 시스템의 TPS 한계를 뼈저리게 측정해 보았으며, Using filesort를 없애기 위한 컬럼 순서 설계의 중요성, 그리고 카디널리티를 고려한 Using where 필터링의 수용까지.

데이터베이스 성능 튜닝은 단순한 암기가 아니라, 철저한 통계적 검증과 구조적 설계의 산물이라는 것을 깨달은 값진 트러블슈팅 경험이었습니다.

[DB Deep Dive] 4. 인덱스를 걸었는데 풀 스캔(ALL)이 뜬다고? (feat. 옵티마이저의 배신)

baby-t — Thu, 21 May 2026 23:26:54 +0900

1. 시작하며: 완벽하다고 믿었던 내 복합 인덱스의 배신

가상 자산 거래소 프로젝트를 진행하며 가장 데이터가 많이 누적될 테이블은 단연 orders (주문 내역) 테이블이었습니다. 유저가 자신의 과거 거래 리스트를 조회할 때, 시스템은 특정 유저의 ID를 조건으로 검색하고, 주문 일시를 기준으로 최신순 정렬 및 페이징 처리를 수행해야 합니다.

이에 대비하여 저는 데이터베이스 설계 단계에서부터 user_id와 order_date를 묶은 복합 인덱스(Multi-Column Index)인 idx_user_date를 생성해 두었습니다. 동등 조건으로 검색 범위를 좁히고, B+Tree 인덱스 구조를 통해 정렬 부하를 완벽히 제거하겠다는 정석적인 전략이었습니다.

// 가상 자산 주문 내역 조회를 위한 JPA Repository Repository 코드
public interface OrderRepository extends JpaRepository<Order, Long> {
    @Query(value = "select o from Order o join fetch o.stock where o.user.id = :userId order by o.orderDate desc",
            countQuery = "select count(o) from Order o where o.user.id = :userId")
    Page<Order> findAllByUserIdWithStock(@Param("userId") Long userId, Pageable pageable);
}

연관된 stock(가상자산 종목) 데이터의 N+1 문제를 방지하기 위해 join fetch까지 깔끔하게 적용했고, Order 입장에서 Stock은 @ManyToOne 관계이므로 DB 레벨의 페이징 쿼리(LIMIT)도 안전하게 작동하는 무결점의 코드였습니다. 이제 내 인덱스가 의도대로 잘 작동하는지 EXPLAIN(실행 계획)을 통해 검증할 차례였습니다. 하지만, 모니터러링 화면에는 충격적인 성적표가 찍혔습니다.

2. 충격적인 실행 계획: 왜 ALL(풀 스캔)과 filesort가 뜰까?

인덱스 검색 결과

인덱스 현황을 조회했을 때 기본키(PRIMARY)와 외래키 인덱스 외에 우리가 설계한 idx_user_date가 선행 컬럼 user_id(Seq 1), 후행 컬럼 order_date(Seq 2)로 정교하게 물리 결합해 있는 것을 확인했습니다. 그러나 실제 조회 쿼리 앞에 EXPLAIN을 붙여 실행한 결과는 끔찍했습니다.

실행 계획 결과

최초의 EXPLAIN 검증 결과

type : ALL (Table Full Scan)
key : NULL (인덱스를 전혀 사용하지 않음)
rows : 43
Extra : Using where; Using filesort

명시적으로 복합 인덱스를 지정해 주었음에도 옵티마이저는 이를 철저히 무시한 채 테이블 전체를 뒤지는 ALL 스캔을 선택했고, 인덱스의 정렬 구조를 쓰지 못해 메모리 버퍼에서 소팅 연산을 무겁게 수행하는 Using filesort 경고까지 내뿜고 있었습니다. 기껏 설계한 인덱스 아키텍처가 완전히 무력화된 순간이었습니다.

3. 범인은 43건: 똑똑한 옵티마이저의 영리한 배신

코드를 몇 번이나 뒤지며 자책하던 중, rows: 43이라는 통계 수치에 시선이 멈췄습니다. 당시 개발 및 테스트 초기 단계였던 제 데이터베이스 테이블에는 고작 43건의 주문 데이터만 저장되어 있었습니다.

여기서 MySQL의 핵심 두뇌인 옵티마이저(Optimizer)의 반전 트리거를 깨달았습니다. 데이터베이스 엔진은 비용 기반 최적화(CBO) 모델을 따릅니다. 무조건 인덱스가 있다고 해서 타는 것이 아니라, '인덱스를 타는 비용'과 '풀 스캔을 때리는 비용'을 저울질하여 더 저렴한 경로를 선택합니다.

인덱스 스캔의 숨겨진 비용, Data Lookup

인덱스를 사용한다는 것은 B+Tree 인덱스 노드를 타고 내려가 원하는 값을 찾은 뒤, 그곳에 저장된 PK 값을 들고 다시 실제 데이터 페이지(디스크 블록)로 점프하는 랜덤 I/O(Data Lookup) 과정을 동반합니다. 데이터 모수가 수십 건 정도로 극도로 적을 때는, 인덱스 나무를 타는 수고와 디스크 점프를 반복하느니, 차라리 메모리에 한 번에 테이블 전체를 풀 스캔(ALL)으로 긁어와 직접 정렬(filesort)해 버리는 것이 컴퓨터 공학적으로 훨씬 빠릅니다.

즉, 제가 인덱스를 잘못 설계한 것이 아니었습니다. 데이터가 너무 적어서 옵티마이저가 의도적으로 인덱스를 '패스'했던 것입니다. 면접 단골 질문인 "인덱스를 걸었는데 왜 실행 계획에 ALL이 뜰까요?"에 대한 완벽한 실무적 정답을 제 눈으로 직접 목격한 셈이었습니다.

4. 디테일 타임: 내 테이블에 자동으로 생성된 인덱스들의 정체

원인을 파악한 김에, SHOW INDEX FROM orders; 결과 구조에 나타난 인덱스들의 정체와 데이터베이스 물리 계층의 연관 지식을 확실하게 정리하고 넘어가고자 합니다.

Key_name	Column_name	인덱스 유형 및 물리 구조의 비밀
PRIMARY	id	클러스터드 인덱스 (Clustered Index) 저는 이 구조를 명시적으로 선언한 적이 없습니다. 하지만 MySQL InnoDB 엔진은 테이블에 PK가 선언되는 순간, 해당 PK를 기준으로 데이터 행 전체를 물리적으로 정렬하여 B+Tree 사전 구조로 자동 빌드합니다. 최상위 성능을 보장하는 단 하나의 인덱스입니다.
idx_user_date	user_id (Seq 1)	넌클러스터드 복합 인덱스 (Composite Index) 성능 최적화를 위해 컬럼 2개를 하나로 묶어 생성한 인덱스입니다. InnoDB 스토리지 엔진 특성상, 이 복합 인덱스의 리프 노드(Leaf Node)에는 `user_id`와 `order_date`뿐만 아니라 논리적 주소 역할을 수행할 실제 PK(id) 값도 물리적으로 자동 포함됩니다.
idx_user_date	order_date (Seq 2)
FK9kccy...	stock_code	외래키 자동 인덱스 JPA로 `@ManyToOne` 관계를 맺으면 Hibernate가 DDL을 밀어 넣을 때 외래키 제약조건을 형성합니다. 이때 MySQL 엔진은 외래키를 활용한 조인 연산의 효율성을 보장하기 위해 물리적인 외래키용 인덱스를 내부적으로 자동 생성해 줍니다. (단, `user_id`는 이미 복합 인덱스의 선행 컬럼으로 포함되었기에 중복 생성이 생략되었습니다.)

5. 상편 마무리에 기하며: 진짜 무대를 위한 빌드업

결국 인덱스의 진정한 성능과 실효성을 검증하기 위해서는, 옵티마이저가 무시할 수 없을 정도의 대용량 데이터 환경(Production 레벨)을 강제로 구축해야 한다는 결론에 도달했습니다.

저는 곧바로 부하 테스트 툴인 JMeter를 장전했습니다. 동시 접속 스레드 100개가 찰나의 순간인 1초 만에 10,000건의 주문 요청을 서버에 폭격하듯 때려 박는 '스파이크 부하 테스트'를 기획한 것입니다. 과연 제 Spring Boot 서버의 비동기 아키텍처는 이 대량의 압박 속에서 무사히 데이터를 적재할 수 있었을까요? 그리고 데이터가 10,000건 이상 쌓인 뒤 데이터베이스의 실행 계획은 어떻게 뒤바뀌었을까요?

대용량 트래픽 폭격의 생생한 결과와, 마침내 베일을 벗은 복합 인덱스의 진짜 위력(하편)에서 이어가도록 하겠습니다!

[DB Deep Dive] 3. "인덱스를 걸었는데 왜 안 탈까요?" EXPLAIN 실행 계획 분석과 튜닝

baby-t — Tue, 19 May 2026 21:06:41 +0900

1. 시작하며: 내 쿼리는 정말 인덱스를 타고 있을까?

우리가 아무리 열심히 B+Tree 복합 인덱스를 설계해 두었다고 해도, 쿼리를 잘못 작성하면 DB의 옵티마이저(Optimizer)는 인덱스를 쿨하게 무시하고 테이블 풀 스캔(Full Scan)을 때려버립니다. 대규모 트래픽 환경에서 이는 곧바로 장애로 이어집니다.

따라서 백엔드 개발자는 쿼리를 작성한 후 반드시 EXPLAIN(실행 계획) 명령어를 통해 옵티마이저의 속마음을 들여다보고 쿼리가 의도대로 작동하는지 검증해야 합니다. 수많은 실행 계획 컬럼 중, 실무에서 쿼리 튜닝을 할 때 가장 중요하게 쳐다보는 핵심 컬럼들(type, Extra, rows)을 완벽하게 분석해 보겠습니다.

실행계획 예시

2. 튜닝의 핵심 지표: type 컬럼 (접근 방식)

type 컬럼은 옵티마이저가 테이블의 레코드를 어떤 방식(풀 스캔 vs 인덱스 스캔)으로 읽었는지 알려주는 가장 중요한 지표입니다. 여러 가지 타입이 있지만, 성능이 가장 좋은 순서대로 알아야 할 4대장은 다음과 같습니다.

성능 최고: const (또는 eq_ref)

조회 결과가 반드시 1건임을 보장하는 최고의 접근 방식입니다.
주로 WHERE id = 5 처럼 PK(Primary Key)나 Unique Key를 동등 조건(=)으로 검색할 때 나타납니다.

‍♂️ 성능 좋음: ref

동등 조건(=)으로 검색하지만, PK나 Unique Key가 아닌 일반 인덱스를 타서 결과가 여러 건일 수 있을 때 나타납니다.
충분히 매우 빠른 레코드 조회 방식입니다.

성능 보통: range

인덱스를 하나의 값이 아닌 특정 범위로 스캔하는 방식입니다.
<, >, IS NULL, BETWEEN, IN, LIKE 연산자를 사용할 때 주로 나타나며, 실무에서 가장 많이 보게 되는 준수한 성능의 타협점입니다.

튜닝 대상 1순위: ALL (Table Full Scan)

가장 끔찍한 단어입니다. 인덱스를 타지 못하고 테이블을 처음부터 끝까지 전부 다 읽어버렸다는 뜻입니다.
데이터가 적을 땐 괜찮지만, 대용량 테이블에서 type: ALL이 뜨면 무조건 인덱스를 추가하거나 쿼리를 수정해야 합니다.

3. 내 쿼리의 성적표: Extra 컬럼

Extra 컬럼은 옵티마이저가 쿼리를 어떻게 가공하고 처리했는지에 대한 내부적인 힌트를 제공합니다. 여기서 개발자를 울고 웃게 만드는 대표적인 메시지 2가지를 소개합니다.

✨ 축복의 메시지: Using index (커버링 인덱스)

지난 2편에서 배운 커버링 인덱스(Covering Index)가 제대로 발동했다면, Extra 컬럼에 당당하게 Using index가 출력됩니다! 데이터 파일을 읽기 위한 디스크 점프(Data Lookup) 없이, 메모리에 올라와 있는 인덱스 트리만 읽어서 쿼리가 끝났다는 뜻으로, 엄청나게 빠른 속도를 보장합니다.

⚠️ 경고 메시지: Using filesort

쿼리에 ORDER BY가 들어있는데 정렬 기준이 인덱스를 타지 못할 때 발생합니다. DB가 데이터를 다 가져온 뒤 별도의 메모리 버퍼(Sort Buffer)에 올려두고 직접 퀵 소트 등으로 정렬했다는 뜻으로 엄청난 부하를 일으킵니다. 복합 인덱스의 순서를 정렬 기준에 맞게 재설계하는 등의 튜닝이 시급합니다.

보너스 팁: 성능 감각을 키워주는 rows 컬럼

rows 컬럼은 옵티마이저가 쿼리 처리를 위해 "대략 몇 건의 데이터를 읽어야 할까?"라고 예측한 수치입니다. 만약 type이 인덱스를 잘 탔다고 나오더라도, 이 rows 값이 전체 데이터 수에 육박할 정도로 지나치게 크다면 비효율적인 스캔이 발생하고 있다는 뜻입니다. 무늬만 인덱스 스캔일 뿐 실질적인 성능은 풀 스캔과 다를 바 없으므로 튜닝을 의심해봐야 하는 아주 좋은 통찰력 지표입니다.

4. 면접 핵심: "인덱스를 걸었는데 왜 ALL(풀 스캔)이 뜰까요?"

면접에서 가장 자주 묻는 함정 질문입니다. 인덱스는 잘 만들어져 있지만, 개발자가 쿼리를 잘못 짜서 B+Tree 구조를 무력화시키는 3대 악마의 쿼리 패턴이 있습니다.

-- 1. 인덱스 컬럼을 직접 가공(함수 사용)하는 경우
[BAD] SELECT * FROM USER WHERE YEAR(created_at) = 2024;
[GOOD] SELECT * FROM USER WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';
(B+Tree는 원본 데이터 기준으로 정렬되어 있습니다. 컬럼 자체에 함수를 씌우면 정렬 구조가 깨져 풀 스캔을 합니다.)

-- 2. LIKE 검색 시 와일드카드(%)가 앞에 있는 경우
[BAD] SELECT * FROM USER WHERE name LIKE '%길동';
[GOOD] SELECT * FROM USER WHERE name LIKE '홍%';
(영어 사전을 찾을 때 'ple'로 끝나는 단어를 찾는다고 상상해 보세요. 첫 글자를 모르면 무조건 처음부터 다 뒤져야 합니다.)

-- 3. 묵시적 형 변환이 일어나는 경우
[BAD] SELECT * FROM USER WHERE phone = 01012345678;  -- (phone이 VARCHAR일 때)
[GOOD] SELECT * FROM USER WHERE phone = '01012345678';
(문자열 컬럼에 숫자 타입으로 검색하면, DB가 몰래 문자열을 숫자로 형변환하는 함수를 씌워버려 인덱스를 타지 못합니다.)

5. 3편을 마무리하며

지금까지 우리는 B+Tree의 원리(1편), Clustered와 Non-Clustered의 물리적 구조 차이와 커버링 인덱스(2편), 그리고 마지막으로 내가 짠 쿼리의 성능을 증명해 내는 EXPLAIN 실행 계획 분석(3편)까지 달려왔습니다. 이 세 가지 포스팅은 서로 유기적으로 연결되어 "데이터베이스의 병목을 구조적으로 분석하고 해결하는 백엔드 개발자"라는 완벽한 서사를 만들어냅니다.

이론적 기초 체력을 기르셨으니, 이제부터는 이 무기들을 실제 프로젝트 코드에 적용하고 장애를 해결한 생생한 트러블슈팅 경험으로 넘어가 볼 차례입니다!

6. 추가 링크

https://zzang9ha.tistory.com/436#google_vignette

MySQL EXPLAIN 실행계획 마스터하기(feat. RealMySQL 8.0)

MySQL EXPLAIN 실행계획 마스터하기(feat. RealMySQL 8.0) 실행 계획(EXPLAIN) 이란? 대부분의 DBMS는 많은 데이터를 안전하고, 빠르게 저장 및 관리하는 것이 주목적이다. 이러한 목적을 달성하기 위해 사

zzang9ha.tistory.com

[DB Deep Dive] 2. Clustered vs Non-Clustered 인덱스의 차이와 InnoDB의 비밀

baby-t — Mon, 18 May 2026 21:21:44 +0900

1. 시작하며: 인덱스, 디스크 위에는 어떻게 저장될까?

지난 1편에서는 인덱스의 논리적인 자료구조인 B+Tree에 대해 알아보았습니다. 하지만 이 B+Tree가 실제 하드 디스크(물리적 공간) 위에 어떻게 배치되는지에 따라 데이터베이스의 아키텍처는 완전히 두 갈래로 나뉘게 됩니다.

오늘은 인덱스의 두 가지 핵심 물리적 구현체인 Clustered Index(클러스터드 인덱스)와 Non-Clustered Index(논클러스터드 인덱스)의 결정적인 차이를 알아보고, 실제 쿼리를 날릴 때 어떤 인덱스가 유리한지 성능을 비교해 보겠습니다.

2. 영어 사전 vs 찾아보기 색인 (Clustered vs Non-Clustered)

데이터베이스 테이블에 인덱스를 거는 방식은 크게 두 가지 비유로 완벽하게 설명할 수 있습니다.

Clustered Index (영어 사전 방식)

테이블의 실제 데이터 레코드들을 물리적으로 재배열하여 정렬합니다.
마치 영어 사전이 A부터 Z까지 순서대로 인쇄되어 있는 것과 같습니다. (리프 노드 = 실제 데이터)
데이터 자체가 정렬되어 있으므로 테이블당 딱 1개만 생성할 수 있습니다. (주로 PK 설정 시 자동 생성)
장점: 이미 정렬되어 있어 범위 검색 등 조회 속도가 압도적으로 빠릅니다.
단점: 중간에 새로운 데이터가 INSERT 되면, 물리적인 순서를 맞추기 위해 뒤쪽 데이터들을 전부 뒤로 밀어내야 하는 엄청난 오버헤드가 발생합니다.

Non-Clustered Index (책 맨 뒤의 색인 방식)

실제 데이터는 원래 있던 자리에 그대로 두고, 정렬된 별도의 인덱스 페이지(색인)를 따로 만듭니다.
일반 전공 서적 맨 뒤에 있는 '찾아보기' 페이지와 같습니다.
물리적인 제약이 없으므로 테이블당 여러 개를 생성할 수 있습니다. (Secondary Index라고도 부름)
장점: 데이터를 물리적으로 이동시킬 필요가 없으므로 INSERT 시의 오버헤드가 상대적으로 적습니다.
단점: 인덱스를 찾은 뒤, 다시 실제 데이터가 있는 곳으로 포인터를 타고 점프해서 가야 하므로 조회 속도는 Clustered보다 약간 느립니다.

면접관의 단골 꼬리 질문: "조회 패턴에 따른 두 인덱스의 성능 차이는?"

1) 단건 조회 (Point Query, WHERE id = 5): 딱 하나의 데이터만 찾을 때는 둘 다 트리 구조를 한 번만 타고 내려가면 되므로 성능 차이가 거의 없습니다. 이럴 때는 삽입/수정 오버헤드가 적은 논클러스터드 인덱스를 우선 고려하는 것이 좋습니다.

2) 범위 조회 (Range Query, WHERE id BETWEEN 10 AND 100): 여기서 압도적인 차이가 발생합니다! 클러스터드 인덱스는 데이터가 이미 물리적으로 정렬되어 있어 시작점부터 쭉 연속해서 읽어오면 끝입니다. 반면 논클러스터드 인덱스는 정렬되지 않은 원본 데이터를 찾기 위해 디스크 이곳저곳을 찌르는 랜덤 I/O가 발생하여 성능이 크게 떨어집니다.

3. MySQL InnoDB만의 독특한 인덱스 아키텍처

여기서 아주 중요한 실무 지식이 등장합니다. 오라클(Oracle) 등 일반적인 DB는 Non-Clustered Index의 리프 노드에 '실제 데이터가 있는 디스크 물리적 주소(ROWID)'를 저장합니다. 색인을 보고 몇 페이지 몇 번째 줄인지 바로 찾아가는 상식적인 방식입니다.

하지만 MySQL의 핵심 엔진인 InnoDB는 리프 노드에 '물리적 주소' 대신 'Primary Key(PK) 값'을 저장합니다. 도대체 왜 한 번에 갈 수 있는 주소를 놔두고, 다시 PK를 검색하게 만드는 구조를 택했을까요?

⚠️ 데이터 이동의 나비효과를 막아라!

앞서 Clustered Index(PK)에 새로운 데이터가 끼어들면, 물리적 순서를 맞추기 위해 뒤쪽 데이터들이 밀려나면서 '물리적 주소'가 전부 바뀐다고 했습니다. 만약 Non-Clustered Index가 물리적 주소를 들고 있었다면, 데이터가 이동할 때마다 수많은 Non-Clustered Index들을 싹 다 뒤져서 주소를 업데이트해야 하는 대참사가 벌어집니다.

하지만 PK 값을 들고 있으면, 데이터의 물리적 위치가 이사를 가더라도 PK 값 자체는 변하지 않으므로 Non-Clustered Index를 수정할 필요가 전혀 없어집니다. 즉, 조회 시 한 번 더 트리를 타야 하는 약간의 비용을 지불하고, 안정성과 유지보수성을 획득한 천재적인 아키텍처 설계입니다.

4. 궁극의 최적화 스킬: 커버링 인덱스 (Covering Index)

InnoDB의 구조를 배웠다면, 이제 쿼리 튜닝의 마법인 커버링 인덱스(Covered Query)를 완벽하게 이해할 수 있습니다. 이를 이해하기 위해서는 먼저 '데이터 룩업'이라는 성능 저하의 주범을 알아야 합니다.

데이터 룩업 (Data Lookup) 이란?

우리가 나이(age) 컬럼에 일반적인 단일 인덱스를 걸었다고 가정해 봅시다. SELECT 이름(name) FROM USER WHERE 나이 = 23; 이라는 쿼리를 날리면, DB는 먼저 나이 인덱스를 뒤져서 '23'을 찾고 그곳에 적힌 PK 값(id)을 얻어냅니다.

하지만 쿼리에서 요구한 '이름' 데이터는 나이 인덱스 페이지에 존재하지 않습니다. 결국 DB는 방금 얻은 PK 값을 들고, 실제 데이터가 있는 원본 테이블(클러스터드 인덱스)로 다시 한번 무거운 발걸음을 옮겨야 합니다. 이처럼 인덱스를 탄 후 원본 데이터를 찾으러 점프하는 과정을 '데이터 룩업'이라 부르며, 디스크 랜덤 I/O를 발생시켜 쿼리를 느리게 만드는 주범이 됩니다.

그렇다면, 논클러스터드 인덱스 자체에 내가 찾고자 하는 데이터들을 처음부터 같이 넣어둘 순 없을까요? 이것이 바로 복합 인덱스를 활용한 커버링 인덱스의 핵심 아이디어입니다.

--   나이(age)와 이름(name)을 묶어서 복합 인덱스로 생성한 상태
SELECT 나이, 이름 FROM USER WHERE 나이 = 23;

✨ 커버링 인덱스의 마법: 원본 테이블 방문 생략!

위 복합 인덱스 구조에서는 인덱스 리프 노드에 [ 나이 | 이름 | id(PK) ]가 한 세트로 묶여서 정렬되어 저장됩니다.

이 상태로 쿼리를 날리면, DB는 인덱스 노드 안에서 나이가 23인 레코드를 찾음과 동시에 그 옆에 나란히 적혀있는 '홍길동'이라는 이름까지 통째로 읽어 들입니다. 쿼리가 필요로 하는 모든 컬럼이 인덱스에 다 있으니, 굳이 무거운 원본 테이블(클러스터드 인덱스)로 2차 방문(Data Lookup)을 하지 않고 인덱스 안에서 상황을 종료해 버립니다. 이를 커버링 인덱스라고 부르며, 디스크 I/O를 극적으로 줄여 성능을 몇 배나 끌어올리는 튜닝 기법입니다.

️ 한 걸음 더: 복합 인덱스 확장과 내부 동작의 디테일

여기서 한 단계 더 깊은 시스템 내부의 동작 원리를 짚고 넘어가야 면접에서 확실한 차별점을 가져갈 수 있습니다.

1) 3개 이상의 컬럼 확장: (나이, 이름, 생일)
복합 인덱스는 2개뿐만 아니라 3개, 4개 이상의 컬럼도 하나로 묶을 수 있습니다. 만약 (나이, 이름, 생일)로 인덱스를 생성하면 리프 노드는 [ 나이 | 이름 | 생일 | id(PK) ] 구조를 갖게 됩니다. 이 상태에서 아래와 같이 쿼리를 날리면 완벽한 커버링 인덱스가 작동합니다.

SELECT 나이, 이름, 생일 FROM USER WHERE 나이 = 23;

2) 인덱스 컬럼의 부분 집합(Subset) 조회
그렇다면 3개 컬럼이 묶인 인덱스 환경에서 딱 2개만 조회하면 어떻게 될까요? SELECT 나이, 이름 FROM USER WHERE 나이 = 23; 쿼리를 실행하더라도 커버링 인덱스는 아주 잘 작동합니다. DB 엔진은 인덱스 노드 내부에서 필요한 데이터가 전부 포함되어 있다면(부분 집합 관계라면), 쓰이지 않는 '생일' 데이터가 존재하더라도 원본 테이블을 찾지 않고 인덱스 내부에서 조회를 끝내기 때문입니다.

3) 쿼리 내비게이션 AI: 옵티마이저(Optimizer)의 역할
쿼리를 보면 FROM USER라고만 적혀있을 뿐, 어떤 인덱스를 사용하라고 명시하지 않았습니다. 그런데 DB는 어떻게 알고 인덱스로 바로 찾아가는 걸까요? 바로 데이터베이스 내부에 존재하는 옵티마이저(Optimizer) 덕분입니다. 옵티마이저는 쿼리문과 테이블 통계 정보를 분석하여 "이 쿼리는 원본 테이블 전체를 읽는 것보다 우리가 만들어 둔 복합 인덱스를 타는 게 비용이 가장 적게 들겠구나!"라고 판단하여 가장 최적의 인덱스 경로를 자동으로 선택해 줍니다.

면접관을 감동시키는 결정적 팁

MySQL InnoDB의 논클러스터드 인덱스는 구조상 리프 노드에 항상 PK 값을 기본적으로 포함하고 있습니다. 따라서 복합 인덱스를 따로 설계하지 않고 (나이) 단일 인덱스만 걸려있더라도, SELECT id, 나이 FROM USER WHERE 나이 = 23; 과 같이 PK와 인덱스 컬럼만 조회하는 쿼리는 추가적인 데이터 룩업이 일어나지 않는 커버링 인덱스로 자동 작동합니다. 이 물리적 저장 구조의 특징과 옵티마이저의 탐색 흐름을 명확히 인지하고 쿼리를 설계하는 것이 시니어와 주니어를 가르는 핵심 기준입니다.

[DB Deep Dive] 1. 내 쿼리는 왜 느릴까? 인덱스(Index)의 본질과 B+Tree가 선택받은 이유

baby-t — Mon, 18 May 2026 20:59:59 +0900

1. 시작하며: 왜 내 쿼리는 데이터가 많아질수록 느려질까?

우리가 구축한 플랫폼이나 대규모 서비스를 운영하다 보면, 초기에는 순식간에 끝나던 조회(SELECT) 쿼리가 데이터가 10만 건, 100만 건을 넘어가는 순간 급격하게 느려지는 현상을 마주하게 됩니다. 데이터베이스의 모든 레코드를 처음부터 끝까지 싹 다 뒤지는 전체 탐색(Full Scan)이 일어나기 때문입니다.

이 문제를 해결하기 위해 백엔드 개발자가 손에 쥐어야 할 가장 강력한 무기가 바로 인덱스(Index)입니다. 오늘은 인덱스의 본질적인 개념과 장단점, 그리고 데이터베이스가 왜 하필 수많은 자료구조 중 B+Tree를 선택했는지 그 내부 깊은 곳의 작동 원리를 파헤쳐 보겠습니다.

2. 인덱스(Index)의 본질과 양날의 검 (Overhead)

인덱스는 쉽게 말해 '책의 맨 뒤에 있는 색인(찾아보기)'과 같습니다. 수천 페이지짜리 전공 서적에서 특정 단어를 찾기 위해 첫 페이지부터 한 장씩 넘기는 바보 같은 짓을 하지 않듯, 데이터베이스도 데이터와 그 데이터가 저장된 물리적 위치를 묶은 별도의 자료구조를 만들어 두고 빠르게 찾아갑니다.

인덱스는 단순히 조회의 속도만 높이는 것이 아닙니다. UPDATE나 DELETE 연산을 수행할 때도 해당 대상을 먼저 '조회'해야 수정을 하든 삭제를 하든 할 수 있기 때문에, 전반적인 데이터 제어 성능이 함께 향상됩니다.

⚠️ 세상에 공짜는 없다: 인덱스의 오버헤드

인덱스를 무차별적으로 생성하면 DB가 터집니다. DBMS는 인덱스를 항상 '최신의 정렬된 상태'로 유지해야 하므로, 데이터 변경이 일어날 때마다 다음과 같은 무거운 추가 연산(오버헤드)이 발생합니다.

INSERT: 새로운 데이터에 대한 인덱스 노드를 새로 추가하고 정렬해야 함.
DELETE: 데이터를 지울 때 인덱스를 완전히 삭제하는 게 아니라 '사용하지 않음' 처리를 해둠. (인덱스 크기가 줄어들지 않음)
UPDATE: 기존 인덱스를 '사용하지 않음' 처리하고, 갱신된 데이터에 대한 인덱스를 새로 추가함. (기존 데이터와 신규 데이터 오버헤드가 동시에 발생)

만약 수정과 삭제가 빈번한 컬럼에 인덱스를 남용하면, 실제 데이터는 10만 건인데 인덱스 찌꺼기는 100만 건이 쌓여 오히려 성능이 심각하게 저하되는 역효과를 낳게 됩니다. 따라서 인덱스는 데이터의 규모가 크고, 중복도가 낮으며(정밀도가 높고), 삽입/변경보다 조회가 압도적으로 많은 컬럼에 신중하게 걸어야 합니다.

3. 왜 해시 테이블(Hash Table)이 아니라 B-Tree 계열일까?

인덱스를 구현할 때 가장 먼저 떠오르는 자료구조는 단연 시간 복잡도 O(1)을 자랑하는 해시 테이블(Hash Table)일 것입니다. Key 값을 넣으면 단 한 번의 연산으로 원하는 가치를 찾아내니 완벽해 보입니다. 하지만 실제 데이터베이스 인덱스의 메인은 해시 테이블이 아닌 B-Tree 계열이 차지하고 있습니다. 이유가 무엇일까요?

해시 테이블의 치명적인 한계: 부등호 연산의 불가능

해시 함수는 값이 단 1만 달라져도 완전히 다른 해시 값을 생성합니다. 이는 정확히 일치하는 등호(=) 연산에는 특화되어 있지만, 부등호(<, >) 연산이나 범위 검색에는 무용지물임을 뜻합니다.

우리가 개발하는 플랫폼에서 WHERE 가격 >= 10000 이라거나 WHERE 생성일자 BETWEEN A AND B 같은 범위 검색 쿼리를 날릴 때, 해시 테이블 인덱스는 정렬되어 있지 않기 때문에 혜택을 전혀 받지 못하고 결국 Full Scan으로 돌아가게 됩니다. 데이터베이스의 탐색은 정렬을 기반으로 한 '범위 스캔'이 핵심이기에, 우리는 항상 정렬된 상태를 유지하는 Tree 계열 자료구조를 사용해야 합니다.

4. B-Tree vs B+Tree: 데이터베이스 최적화의 정수

이진트리를 확장하여 하나의 노드가 2개 이상의 자식 노드를 가질 수 있도록 균형을 맞춘 구조가 바로 B-Tree입니다. 노드 내부의 데이터들이 항상 정렬된 상태를 유지하고, 자식 노드들이 부모의 값 범위를 나누어 가지기 때문에 탐색 속도가 O(log N)으로 매우 안정적입니다.

여기서 한 단계 더 나아가 실제 현대의 RDBMS(예: MySQL InnoDB)가 채택한 구조는 B-Tree를 인덱스 전용으로 더욱 극대화한 B+Tree 자료구조입니다. 두 구조의 결정적인 차이점은 크게 두 가지입니다.

[ B-Tree ]

- 모든 내부 노드와 리프 노드가 Key와 함께 실제 데이터(Value)를 주렁주렁 들고 있음.

[ B+Tree ]

- 내부 노드(Index Node)들은 오직 경로를 찾기 위한 'Key(가이드)'만 가짐.
- 실제 데이터(Value)는 오직 최하단의 '리프 노드(Leaf Node)'에만 몰아서 저장됨.
- 결정적으로 리프 노드들끼리 LinkedList(InnoDB는 Double LinkedList)로 연결되어 있음!

B+Tree가 인덱싱에 압도적으로 유리한 이유

첫째, 내부 노드가 무거운 실제 데이터를 들고 있지 않기 때문에 하나의 메모리 페이지에 훨씬 더 많은 인덱스 Key들을 촘촘하게 채워 넣을 수 있습니다. 이는 결과적으로 트리의 전체 높이(Depth)를 낮추어 디스크 I/O 탐색 횟수를 획기적으로 줄여줍니다.

둘째, 범위 검색 시 B-Tree는 다른 노드로 가기 위해 다시 부모 노드를 거쳐 위아래로 복잡하게 트래킹해야 하지만, B+Tree는 원하는 범위의 시작 리프 노드로 단 한번 내려간 뒤, 리프 노드 간 연결된 LinkedList를 타고 오른쪽으로 쓱 밀면서 순차 검색(Linear Scan)을 끝내버릴 수 있습니다. 이 차이가 대용량 데이터 범위 조회 시 성능을 수십 배 가르는 핵심 원리입니다.

5. 1편을 마무리하며

오늘은 데이터베이스 검색 최적화의 첫 단추인 인덱스의 기본 메커니즘과, 왜 모든 메이저 RDBMS가 B+Tree라는 정교한 자료구조를 핵심 엔진으로 채택했는지 알아보았습니다. 면접관이 "왜 해시 인덱스를 안 쓰고 B+Tree를 쓰나요?"라고 묻는다면 이제 막힘없이 범위 검색과 디스크 I/O 효율성, LinkedList 스캔을 엮어서 당차게 대답할 수 있을 것입니다.

자료구조라는 기본 뼈대를 이해했으니, 이제 다음 2편에서는 이 B+Tree 아키텍처가 실제 디스크 공간 위에 어떤 형태로 물리적으로 배치되는지 알아보는 Clustered Index(영어 사전) vs Non-Clustered Index(찾아보기 색인)의 치명적인 차이점과, 면접에서 90% 이상 출제되는 MySQL InnoDB만의 독특한 구조를 낱낱이 파헤쳐 보겠습니다!

6. 추가 링크

https://mangkyu.tistory.com/96

[Database] 인덱스(index)란?

1. 인덱스(Index)란? [ 인덱스(index)란? ] 인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 만약 우리가 책에서 원하는 내

mangkyu.tistory.com

https://code-lab1.tistory.com/217

[자료구조] B-트리(B-Tree)란? B트리 그림으로 쉽게 이해하기, B트리 탐색, 삽입, 삭제 과정

B- 트리란?보통 B 트리라고 하면 B- 트리를 의미한다. B 트리는 트리 자료구조의 일종으로 이진트리를 확장해 하나의 노드가 가질 수 있는 자식 노드의 최대 숫자가 2보다 큰 트리 구조이다. 이러

code-lab1.tistory.com

순수 Java로 WAS 구현 (9) - 프론트 컨트롤러에 Jackson 도입하기: 역직렬화와 리플렉션의 비밀

baby-t — Sat, 16 May 2026 18:11:02 +0900

1. 시작하며: GET 요청의 한계와 JSON 바디의 필요성

지금까지 우리는 GET 방식을 통해 URL로 들어오는 요청을 프론트 컨트롤러로 동적 라우팅하는 데 성공했습니다. 하지만 실제 웹 서비스에서는 회원가입이나 로그인처럼 보안이 중요하고 데이터 양이 많은 경우 무조건 POST 방식을 사용해야 합니다.

POST 방식은 데이터를 URL이 아닌 HTTP 메시지의 Body(본문) 안에 안전하게 숨겨서 보냅니다. 최근에는 이 본문 데이터로 JSON(JavaScript Object Notation) 포맷을 가장 많이 사용합니다. 이번 시간에는 클라이언트가 보낸 JSON 문자열을 자바 객체(DTO)로 변환해 주는 마법의 도구, Jackson 라이브러리를 도입해 보겠습니다.

2. Jackson 라이브러리와 역직렬화(Deserialization)의 이해

코드를 짜기 전에, Jackson이 도대체 무슨 일을 하는지 핵심 개념 하나만 짚고 넘어가겠습니다. 바로 '역직렬화(Deserialization)'입니다.

직렬화(Serialization): 자바 객체(DTO)를 네트워크로 전송하기 위해 JSON 문자열로 바꾸는 과정
역직렬화(Deserialization): 네트워크를 통해 들어온 JSON 문자열을 다시 자바 객체(DTO)로 조립하는 과정

클라이언트가 POST 요청 바디에 {"email": "test@gmail.com"} 이라는 텍스트를 담아 보내면, Jackson 라이브러리는 이를 읽고 UserDTO라는 자바 객체로 역직렬화해 줍니다.

Jackson과 자바 리플렉션(Reflection)
Jackson 라이브러리가 역직렬화를 할 때 사용하는 핵심 기술이 바로 우리가 6편에서 배웠던 리플렉션입니다. 구체적인 클래스 타입을 알지 못하더라도 리플렉션을 통해 동적으로 접근하여 기본 생성자로 빈 깡통 객체를 먼저 생성한 후, Setter 등을 통해 값을 주입하게 됩니다. (이 사실을 꼭 기억해 주세요! 뒤에서 엄청난 에러와 마주하게 됩니다.)

2-1. 라이브러리 세팅 및 타겟 컨트롤러 준비

이론을 알아봤으니 본격적으로 build.gradle에 Jackson의 핵심 모듈을 추가해 줍니다.


// JSON 파싱을 위한 Jackson 코어 라이브러리 (자바 프로젝트용)
implementation 'com.fasterxml.jackson.core:jackson-databind:2.18.2'

그리고 회원가입 로직을 처리할 UserController에 UserDTO를 파라미터로 받는 join 메서드를 추가합니다.


package org.example.controller;
import org.example.dto.UserDTO;

public class UserController {
    // POST 요청을 받아 처리할 메서드
    public String join(UserDTO dto) {
        System.out.println("--- 회원가입 로직 실행 ---");
        System.out.println("이메일: " + dto.getEmail());
        System.out.println("이름: " + dto.getName());
        
        // 처리 결과를 JSON 형태의 문자열로 직접 조립하여 반환
        return "{ \"message\": \"" + dto.getName() + "님 환영합니다!\" }"; 
    }
}

3. DispatcherServlet 고도화: POST 분기 처리

이제 프론트 컨트롤러가 POST 요청을 구별하여 Jackson에게 역직렬화를 지시하도록 로직을 수정합니다. 이 부분이 바로 스프링의 @PostMapping과 @RequestBody가 탄생한 배경이기도 합니다.


// DispatcherServlet.java 내부
String httpMethod = request.getMethod(); // "GET" or "POST"
String body = request.getBody();         // JSON 텍스트 (POST일 때만 존재)

String resultBody = "";

if (httpMethod.equals("POST")) {
    //     핵심: Jackson 라이브러리의 ObjectMapper 출동!
    ObjectMapper objectMapper = new ObjectMapper();
    
    //     핵심: JSON 문자열(body)을 UserDTO 자바 객체로 역직렬화 (데이터 바인딩)
    UserDTO userDTO = objectMapper.readValue(body, UserDTO.class);

    // 리플렉션으로 메서드를 실행할 때, 변환된 DTO를 파라미터로 넘겨줌!
    Method method = clazz.getMethod(methodName, UserDTO.class);
    resultBody = (String) method.invoke(controllerInstance, userDTO);

} else if (httpMethod.equals("GET")) {
    // 파라미터가 없는 기존 GET 방식 로직
    Method method = clazz.getMethod(methodName);
    resultBody = (String) method.invoke(controllerInstance);
}

response.setBody(resultBody);

4. 트러블슈팅: Jackson과 기본 생성자 에러의 비밀

자, 이제 포스트맨(Postman)이나 개발자 도구를 이용해 POST 요청을 날려보겠습니다. 성공할 줄 알았는데 콘솔에 어마어마한 에러가 쏟아졌습니다.

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `org.example.dto.UserDTO` (no Creators, like default constructor, exist)

에러 메시지를 직역하면 "UserDTO 객체를 만들 수 없어! 기본 생성자(default constructor)가 없잖아!"라는 뜻입니다.

왜 이런 에러가 났을까?
앞서 2번 목차에서 Jackson은 리플렉션을 통해 객체를 생성한다고 설명했습니다. 리플렉션은 newInstance()를 호출하여 일단 파라미터가 없는 깡통 객체를 만들어야 하는데, 제 UserDTO에는 파라미터가 있는 생성자만 존재하여 자바가 기본 생성자를 자동으로 만들어주지 않았습니다. 그 결과 Jackson이 깡통 객체를 만들지 못해 폭발해 버린 것입니다.

️ 해결 방법

원인을 알았으니 해결은 아주 간단합니다. UserDTO에 빈 껍데기 역할을 할 기본 생성자를 명시적으로 추가해 줍니다. (스프링에서 DTO나 Entity를 만들 때 @NoArgsConstructor가 필수인 이유가 바로 이 잭슨의 역직렬화 원리 때문입니다!)


public class UserDTO {
    String email;
    String name;
    String password;

    //     핵심: Jackson의 리플렉션을 위한 기본 생성자 필수 추가!
    public UserDTO() {} 

    // ... 파라미터 생성자, Getter, Setter 생략 ...
}

5. 최종 테스트: 완벽하게 동작하는 나의 미니 스프링

버그를 수정하고 다시 서버를 띄운 뒤, 클라이언트(브라우저 콘솔)에서 fetch API를 통해 JSON 데이터를 담아 POST 요청을 날려보았습니다.

[서버 인텔리제이 콘솔 출력]


/0:0:0:0:0:0:0:1와 연결 성공!
Start Line: POST /user/join HTTP/1.1
--- 회원가입 로직 실행 ---
이메일: test@gmail.com
이름: 스프링장인
비밀번호: 1234

[클라이언트 브라우저 응답 확인]


{ "message": "스프링장인님 환영합니다!" }

서버 내부에서 클라이언트가 보낸 JSON이 DTO로 완벽히 변환되어 비즈니스 로직을 타고, 컨트롤러가 뱉어낸 응답이 다시 클라이언트에게 예쁘게 도착했습니다!

6. 대장정을 마무리하며

이로써 '순수 Java로 WAS 프레임워크 만들기'라는 긴 여정이 막을 내렸습니다. 톰캣이 열어주는 소켓 연결부터, HTTP 메시지 파싱, 프론트 컨트롤러의 동적 라우팅, 그리고 Jackson을 이용한 데이터 바인딩까지 모두 직접 구현해 보았습니다.

이 프로젝트를 통해 @RestController, @PostMapping, @RequestBody 같은 스프링의 마법 같은 어노테이션들이 내부적으로 어떻게 동작하는지 그 원리를 바닥부터 뜯어볼 수 있었습니다. 이제 스프링 프레임워크를 사용할 때, 단순히 사용법을 암기하는 것이 아니라 그 이면에 숨겨진 '이유'를 알게 된 뜻깊은 시간이었습니다.

순수 Java로 WAS 구현 (8) - 프론트 컨트롤러(DispatcherServlet) 직접 구현과 HTTP 응답 조립

baby-t — Sat, 16 May 2026 07:54:17 +0900

1. 시작하며: if-else 지옥에서 벗어나기

이전 포스팅에서 우리는 수많은 API 요청을 if-else문으로 처리하는 것의 한계를 깨닫고, 프론트 컨트롤러(Front Controller) 패턴을 도입하기로 결정했습니다. 이번 시간에는 단 하나의 문지기 서블릿(DispatcherServlet)이 리플렉션(Reflection)을 무기로 모든 요청을 알맞은 컨트롤러에 동적으로 분배하는 마법을 직접 코드로 구현해 보겠습니다.

2. 아키텍처 설계 및 HandlerMapping (매핑 사전) 만들기

가장 먼저 프론트 컨트롤러인 DispatcherServlet 클래스를 만듭니다. 이 문지기는 클라이언트가 요청한 URL(예: /user)을 보고, 실제 메모리에 있는 어떤 자바 클래스(예: org.example.controller.UserController)를 실행해야 할지 알아야 합니다. 이를 위해 매핑 사전(Map)을 정의합니다.


public class DispatcherServlet {
    // 스프링의 HandlerMapping과 같은 역할을 하는 매핑 사전
    private static final Map<String, String> handlerMapping = new HashMap<>();

    // 정적 초기화 블록 (Static Initialization Block)
    static {
        handlerMapping.put("user", "org.example.controller.UserController");
    }
    
    // ... servlet 메서드 구현 (아래 참고)
}

왜 static 블록을 사용할까? (자바 정적 초기화 블록)
서버에 1만 명의 접속자가 몰릴 때마다 매번 사전에 put을 한다면 엄청난 리소스 낭비입니다. static {} 블록을 사용하면 톰캣(WAS)이 켜지면서 이 클래스가 메모리에 올라갈 때 단 한 번만 초기화됩니다. 마치 식당 오픈 전에 메뉴판을 한 번만 걸어두는 것과 같은 이치이며, 실제 스프링 프레임워크 내부에서도 매우 빈번하게 사용되는 기법입니다.

3. 타겟 컨트롤러 생성 및 리턴 타입의 분리

테스트를 위해 간단한 UserController를 만듭니다. 여기서 핵심은 컨트롤러가 HttpResponse 객체를 직접 만지는 것이 아니라, 순수한 데이터(String)만 반환하도록 역할을 철저히 분리(Separation of Concerns)하는 것입니다.


package org.example.controller;

public class UserController {
    // 뷰(View)의 이름이나, 클라이언트에게 보낼 순수 데이터를 반환합니다.
    public String login() {
        return "Login Success!";
    }
}

4. 동적 라우팅 구현 (리플렉션의 활용)

이제 DispatcherServlet의 핵심 로직을 구현합니다. 파싱된 URI를 쪼개어 매핑 사전에서 클래스를 찾고, 리플렉션으로 동적 실행을 합니다.


public static HttpResponse servlet(HttpRequest request) throws Exception {
    HttpResponse response = new HttpResponse();
    response.setVersion(request.getVersion());
    
    // 1. URI 분석 (예: /user/login)
    String[] tokens = request.getUri().split("/");
    if (tokens.length < 3) return null; // 잘못된 URL 방어
    
    String prefix = tokens[1]; // "user"
    String methodName = tokens[2]; // "login"
    
    // 2. 매핑 사전에서 패키지 풀 네임 찾기
    String className = handlerMapping.get(prefix);
    
    // 3. 리플렉션(Reflection)을 이용한 동적 실행!
    Class<?> clazz = Class.forName(className); // 설계도 훔쳐오기
    Object controllerInstance = clazz.getDeclaredConstructor().newInstance(); // 인스턴스 생성
    Method method = clazz.getMethod(methodName); // 메서드 찾기
    
    // 4. 실행 후 반환된 String("Login Success!")을 응답 바디에 담기
    String resultBody = (String) method.invoke(controllerInstance);
    response.setBody(resultBody);
    
    // 5. HTTP 상태 코드 기본 세팅
    response.setStatus_code("200");
    response.setReason_phrase("OK");

    return response;
}

트러블슈팅: Class.forName()의 깐깐함
처음에는 Class.forName("user")처럼 입력하면 될 줄 알았으나 에러가 발생했습니다. 리플렉션으로 클래스를 로드할 때는 반드시 org.example.controller.UserController 처럼 패키지 경로가 포함된 풀 네임(FQN)을 명시해야 함을 뼈저리게 배웠습니다.

5. HTTP 응답(Response) 객체 설계와 생성

동적 라우팅을 통해 컨트롤러를 실행하고 나면, 그 결과를 담아 브라우저로 쏴줄 데이터 바구니가 필요합니다. HTTP 응답 규격(Status Line, Header, Body)을 명확하게 매핑할 수 있도록 다음과 같이 HttpResponse 객체를 설계하고 매인 로직에서 생성해 주었습니다.


package org.example.dto;

import java.util.HashMap;
import java.util.Map;

public class HttpResponse {
    private String version;         // HTTP/1.1 등
    private String status_code;     // 200, 404 등
    private String reason_phrase;   // OK, Not Found 등

    // 다중 헤더 관리를 위한 Map 구조 데이터 바구니
    private Map<String, String> headers = new HashMap<>();
    private String body;            // 변환된 데이터 본문

    public String getVersion() { return version; }
    public void setVersion(String version) { this.version = version; }

    public String getStatus_code() { return status_code; }
    public void setStatus_code(String status_code) { this.status_code = status_code; }

    public String getReason_phrase() { return reason_phrase; }
    public void setReason_phrase(String reason_phrase) { this.reason_phrase = reason_phrase; }

    public Map<String, String> getHeaders() { return headers; }
    public void addHeader(String key, String value) { this.headers.put(key, value); }

    public String getBody() { return body; }
    public void setBody(String body) { this.body = body; }
}

6. HTTP 응답(Response) 포맷 직접 조립하기

컨트롤러에서 데이터 처리가 끝났다고 해서 out.println(response)처럼 자바 객체를 브라우저에 그대로 던지면 안 됩니다. 브라우저는 자바의 주소값을 이해하지 못하며, 오직 HTTP 규약(Start Line + Header + Empty Line + Body)에 맞는 순수 텍스트 문자열만 읽을 수 있기 때문입니다.

따라서 HttpResponse 객체 내부에 스스로의 메타데이터를 HTTP 텍스트 규격 프로토콜에 완벽하게 맞춰 출력 스트림으로 밀어 넣어주는 send() 메서드를 구현했습니다.


// HttpResponse.java 내부
public void send(PrintWriter out) {
    // 1. Status Line 조립 (예: HTTP/1.1 200 OK)
    out.print(this.version + " " + this.status_code + " " + this.reason_phrase + "\r\n");
    
    // 2. Response Headers 데이터 생성 (한글 깨짐 방지 및 Body 길이 세팅)
    out.print("Content-Type: text/plain;charset=UTF-8\r\n");
    if (this.body != null) {
        out.print("Content-Length: " + this.body.getBytes().length + "\r\n");
    }
    
    // 3. 헤더와 바디를 구분하는 빈 줄 (CRLF) 필수!
    out.print("\r\n");
    
    // 4. Message Body 발사
    if (this.body != null) {
        out.print(this.body);
    }
    
    out.flush(); // 스트림에 고인 데이터를 브라우저로 완전히 밀어내기!
}

이제 마지막으로 점원인 RequestHandler가 이 기능을 이어받아 response.send(out);을 단 한 줄 호출해 주면, 서버 내부에서 동적으로 뜯고 맛본 비즈니스 데이터 결과물이 프로토콜 텍스트로 탈바꿈하여 정상 송출되는 전체 통신 사이클이 비로소 완성됩니다.

7. 브라우저 개발자 도구(F12)로 결과 확인하기

서버를 띄우고 크롬 주소창에 http://localhost:8080/user/login을 입력하니, 화면에 "Login Success!"가 아주 예쁘게 출력되었습니다.

크롬 화면

하지만 여기서 끝낼 수 없죠! 개발자 도구(F12)의 Network 탭을 열어 우리가 조립한 패킷이 잘 도착했는지 뜯어보았습니다.

8. 마무리하며

스프링 프레임워크가 뒤에서 조용히 처리해 주던 DispatcherServlet의 동적 라우팅과, @ResponseBody가 해주는 HTTP 규약 변환 과정을 순수 자바로 밑바닥부터 구현해 냈습니다. 이로써 스프링 MVC 아키텍처의 핵심 심장부를 완벽히 이해하게 되었습니다.

지금까지는 파라미터가 없는 단순한 GET 요청을 처리했습니다. 다음 포스팅에서는 드디어 외부 라이브러리인 Jackson을 도입하여, 클라이언트가 보내는 POST 요청의 JSON 바디 데이터를 자바 객체(DTO)로 변환(데이터 바인딩)하는 과정을 다뤄보겠습니다!

순수 Java로 WAS 구현 (7) - 톰캣의 정체와 프론트 컨트롤러(Front Controller)의 탄생

baby-t — Fri, 15 May 2026 15:43:33 +0900

1. 서론: 100개의 API, 100개의 if문?

지금까지 우리는 클라이언트의 요청(HTTP 메시지)을 읽고, 파싱하고, 리플렉션이라는 마법의 도구까지 손에 넣었습니다. 하지만 막상 파싱된 URI(예: /login, /join, /board)를 바탕으로 비즈니스 로직을 실행하려고 하니 막막해집니다.

만약 서버가 처리해야 할 API가 100개라면, RequestHandler 안에 if (uri.equals("/login")) { ... } else if (uri.equals("/join")) { ... } 처럼 100개의 분기문을 만들어야 할까요? 이는 유지보수 관점에서 끔찍한 일입니다. 이 문제를 과거의 선배 개발자들은 어떻게 해결했을까요?

2. 서블릿(Servlet)과 톰캣(Tomcat)의 진짜 정체

이 문제를 해결하기 위해 등장한 자바의 표준 규약이 바로 서블릿(Servlet)입니다. 서블릿은 '클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술'입니다.

과거(CGI 시절)에는 요청이 올 때마다 무거운 '프로세스(Process)'를 통째로 복제해서 실행했기 때문에 사용자가 조금만 몰려도 서버가 뻗어버렸습니다. 이를 혁신하기 위해 톰캣(Tomcat, 서블릿 컨테이너)이 등장합니다.

놀라운 사실: 우리가 만든 코드가 바로 '미니 톰캣'입니다!
우리가 작성한 WebApplicationServer가 소켓을 열어 연결을 받고, RequestHandler를 스레드(Thread)로 실행시키는 구조 기억하시나요? 이것이 바로 톰캣이 동작하는 핵심 원리입니다. 톰캣은 프로세스 대신 가벼운 스레드를 사용하여 서블릿 객체를 실행시킵니다.

[면접 단골 질문] 톰캣은 스레드를 매번 새로 만들까요?

우리의 코드는 현재 new Thread().start()를 통해 매번 스레드를 생성합니다. 하지만 진짜 톰캣은 서버 메모리를 보호하기 위해 스레드 풀(Thread Pool)을 사용합니다. 미리 일정 개수(기본 200개)의 스레드를 만들어 두고, 요청이 오면 쉬고 있는 스레드를 할당해 준 뒤 작업이 끝나면 다시 반납받는 방식을 사용하여 성능을 극대화합니다.

3. 서블릿의 매핑 지옥과 한계

톰캣 덕분에 성능 문제는 해결되었지만, 초창기 서블릿에는 여전히 치명적인 단점이 있었습니다. 바로 1 URL = 1 서블릿 클래스라는 규칙 때문이었습니다.

/login을 처리하는 LoginServlet, /join을 처리하는 JoinServlet 등 URL이 늘어날 때마다 무수히 많은 클래스를 만들어야 했고, 이 연결 고리를 web.xml이라는 설정 파일에 일일이 다 적어주어야 했습니다. (이를 매핑 지옥이라고 부릅니다.)

4. 구원자, 프론트 컨트롤러(Front Controller) 패턴의 등장

매핑 지옥에 지친 개발자들은 아주 기발한 아키텍처 패턴을 고안해 냅니다. 바로 프론트 컨트롤러(Front Controller) 패턴입니다.

클라이언트 ➡️ [ 프론트 컨트롤러 (단 1개의 서블릿) ] ➡️ 각 Controller 메서드로 분배

서버의 입구에 문지기 역할을 하는 단 하나의 대표 서블릿(DispatcherServlet)만 둡니다.
모든 요청은 일단 이 문지기가 다 받습니다.
문지기는 우리가 6편에서 배운 리플렉션(Reflection) 기술을 활용하여, 들어온 URI를 보고 알맞은 일반 자바 클래스(Controller)의 메서드를 쏙쏙 찾아내어 동적으로 실행(Invoke)해 줍니다.

이것이 바로 현재 전 세계에서 가장 많이 쓰이는 웹 프레임워크인 Spring MVC의 핵심 동작 원리입니다. 개발자는 더 이상 서블릿을 만들거나 web.xml을 건드릴 필요 없이, @GetMapping("/login") 같은 어노테이션 하나만 달아주면 스프링의 프론트 컨트롤러가 알아서 찾아가는 마법이 여기서 시작된 것입니다.

5. 다음 단계로

이제 목표가 아주 명확해졌습니다. 우리가 만들었던 RequestHandler의 역할을 더욱 고도화하여, 스프링의 심장인 DispatcherServlet(프론트 컨트롤러)을 직접 구현해 볼 차례입니다.

이전 편에서 파싱해 둔 HttpRequest 객체의 URI 정보를 꺼내고, 리플렉션을 이용해 알맞은 컨트롤러 메서드를 찾아 실행하는 동적 라우팅 시스템을 다음 포스팅에서 본격적으로 코딩해 보겠습니다!

순수 Java로 WAS 구현 (6) - 프레임워크의 마법, 리플렉션(Reflection) 완벽 이해

baby-t — Fri, 15 May 2026 14:29:20 +0900

1. 리플렉션(Reflection)이란?

WAS나 스프링(Spring) 프레임워크를 쓰다 보면 문득 궁금해집니다. "내가 만든 클래스나 메서드 이름을 프레임워크가 어떻게 알고 실행해 주는 걸까?"

그 해답이 바로 리플렉션(Reflection)입니다. 리플렉션은 구체적인 클래스 타입을 알지 못해도, 런타임(실행 중)에 클래스의 이름만으로 해당 클래스의 정보(메서드, 타입, 변수 등)에 접근하고 객체를 생성하거나 메서드를 호출할 수 있게 해주는 자바의 강력한 API입니다.

2. Class 객체를 가져오는 3가지 방법

리플렉션을 시작하려면 가장 먼저 해당 클래스의 메타데이터가 담긴 Class 객체를 메모리(JVM 힙 영역)에서 가져와야 합니다. 상황에 따라 3가지 방법을 사용할 수 있습니다.


// 예시로 사용할 타겟 클래스
public class User { ... }

// 1. 객체가 이미 생성되어 있을 때 (인스턴스 사용)
User user = new User();
Class<?> clazz1 = user.getClass();

// 2. 코딩할 때 클래스 타입을 정확히 알고 있을 때 (클래스 리터럴 사용)
Class<?> clazz2 = User.class;

// 3. 클래스 이름(문자열)만 알고 있을 때 (WAS나 프레임워크에서 가장 많이 사용!)
Class<?> clazz3 = Class.forName("org.example.User");

3. 동적으로 클래스 조작하기 (생성자, 필드, 메서드)

가장 중요한 Class.forName()을 사용하여, 문자열만으로 객체를 생성하고 필드를 조작하며 메서드를 실행하는 실전 예시를 살펴보겠습니다.

[타겟 클래스 준비]

일부러 private 필드와 매개변수가 있는 메서드를 만들어 보았습니다.


package org.example;

public class UserController {
    private String name = "초기값";

    public void hello(String message) {
        System.out.println(name + "님의 메시지: " + message);
    }
}

[리플렉션 실행 코드]


import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Method;

public class ReflectionDemo {
    public static void main(String[] args) throws Exception {
        // 1. 클래스 정보 로드
        Class<?> clazz = Class.forName("org.example.UserController");

        // 2. 동적으로 생성자 가져와서 객체 초기화 (인스턴스 생성)
        Constructor<?> constructor = clazz.getDeclaredConstructor();
        Object controller = constructor.newInstance(); 
        // 결과: new UserController() 와 동일!

        // 3. 동적으로 private 필드 가져와서 강제로 값 조작하기
        Field nameField = clazz.getDeclaredField("name");
        nameField.setAccessible(true); //   private 접근 허용 (핵심!)
        nameField.set(controller, "홍길동"); 

        // 4. 동적으로 메서드 가져와서 실행(invoke)하기
        // "hello"라는 이름에, 파라미터로 String을 받는 메서드 찾기
        Method helloMethod = clazz.getDeclaredMethod("hello", String.class);
        
        // invoke(실행할 인스턴스, 넘겨줄 파라미터)
        helloMethod.invoke(controller, "반갑습니다!"); 
        // 출력 결과: 홍길동님의 메시지: 반갑습니다!
    }
}

왜 private 필드까지 조작할까?
스프링을 쓸 때 @Autowired나 @Value 어노테이션을 private 변수 위에 달아도 의존성이 주입되는 것을 본 적이 있을 것입니다. 스프링이 바로 이 리플렉션의 setAccessible(true)를 사용하여 강제로 값을 밀어 넣어주기 때문입니다.

4. 왜 평소에는 사용하지 않을까? (리플렉션의 단점)

이렇게 마법 같은 기술임에도 불구하고, 일반적인 비즈니스 로직에서는 리플렉션 사용을 지양해야 합니다.

컴파일 타임 에러 검출 불가: 클래스명이나 메서드명을 문자열로 넘기기 때문에 오타가 나도 컴파일(빌드) 시점에 잡히지 않고, 런타임에 서버가 터지게 됩니다.
성능 저하: 일반적인 메서드 호출보다 캡슐화 확인, 타입 검사 등의 추가 과정이 필요하므로 실행 속도가 느립니다.
객체지향 파괴: private 접근 제어자를 무시할 수 있어 캡슐화 원칙이 깨집니다.

5. 다음 목표: WAS의 라우팅과 프론트 컨트롤러(Front Controller)

결론적으로 리플렉션은 '우리처럼 프레임워크나 WAS를 직접 만들 때만' 사용하는 강력한 무기입니다.

이전 포스팅에서 클라이언트의 HTTP 요청을 HttpRequest 객체로 파싱해 두었습니다. 이제 이 파싱된 URI(ex: /login)를 보고 적절한 Controller 메서드를 동적으로 찾아 실행해야 합니다. 이를 구현하기 위해, 다음 포스팅에서는 Java Servlet의 개념과 프론트 컨트롤러(Front Controller) 패턴에 대해 먼저 학습하고 코드로 적용해 보겠습니다.

순수 Java로 WAS 구현 (5) - HTTP 요청 파서(Parser) 구현과 3가지 트러블슈팅

baby-t — Fri, 15 May 2026 13:47:33 +0900

1. 아키텍처 설계: 점원과 번역가의 역할 분리

지난번 HTTP 스펙 분석을 통해, 클라이언트가 보내는 요청이 결국 '정해진 규칙을 가진 긴 문자열'이라는 것을 알게 되었습니다. 이제 이 문자열을 잘라서 의미 있는 자바 객체로 변환해 주는 파서(Parser)를 만들어야 합니다.

본격적인 코딩에 앞서, 객체지향적인 책임 분배를 위해 클래스 구조를 다음과 같이 설계했습니다.

WebApplicationServer: 가게 입구(Port 8080)를 지키며 소켓 연결을 무한 대기합니다.
RequestHandler: 손님이 오면 할당되는 '점원(Thread)'입니다. 입출력 스트림을 관리합니다.
HttpRequestParser: 문자열을 잘라주는 '번역가'입니다. (유틸리티 클래스로 활용)
HttpRequest: 파싱된 결과(Method, URI, Header, Body)를 예쁘게 담을 '바구니(DTO)'입니다.

2. 구현 1단계: Start Line (시작 줄) 파싱

브라우저가 보낸 첫 줄인 Start Line(예: GET /index.html HTTP/1.1)을 읽어 들여 메서드, URI, 버전을 추출합니다. 문자열의 첫 번째 줄만 읽으면 되므로 readLine()을 사용합니다.


// 1. Start Line 읽기
String startLine = in.readLine();
if (startLine == null) return null; // 비정상 종료 방어

// 공백을 기준으로 3토막 내기
String[] tokens = startLine.split(" ");

HttpRequest request = new HttpRequest();
request.setMethod(tokens[0].trim());
request.setUri(tokens[1].trim());
request.setVersion(tokens[2].trim());

3. 구현 2단계: Header (헤더) 파싱

헤더는 빈 줄(Empty Line)이 나올 때까지 여러 줄이 이어집니다. while 문을 돌며 필드명: 값 형태를 추출하여 Map에 저장합니다.


// 2. Header 읽기
String headerLine;
// 빈 줄("")이 나올 때까지 무한 반복
while ((headerLine = in.readLine()) != null && !headerLine.isEmpty()) {
    // 콜론을 기준으로 분리
    String[] headerTokens = headerLine.split(":", 2);
    request.addHeader(headerTokens[0].trim(), headerTokens[1].trim()); 
}

4. 구현 3단계: Message Body (바디) 파싱

바디는 헤더와 달리 끝을 알리는 기호가 없습니다. 따라서 헤더의 Content-Length를 확인한 뒤, 정확히 그 길이만큼만 바이트 단위로 읽어와야 합니다.


// 3. Body 읽기 (Content-Length가 있는 경우만)
if (request.getHeaders().containsKey("Content-Length")) {
    int contentLength = Integer.parseInt(request.getHeaders().get("Content-Length"));
    char[] bodyBuffer = new char[contentLength];
    
    // 정확히 contentLength만큼만 읽어서 배열에 저장
    in.read(bodyBuffer, 0, contentLength);
    request.setBody(new String(bodyBuffer));
}

5. 핵심 트러블슈팅: 구현 시 반드시 고려해야 할 3가지

파서를 구현하면서 마주했던 가장 중요한 기술적 판단 지점들을 정리해 보았습니다.

고민 1. 헤더 파싱에도 Jackson(JSON) 라이브러리를 써야 할까?
Jackson은 JSON 데이터를 파싱하는 도구입니다. 하지만 HTTP 헤더는 단순 텍스트 규약일 뿐 JSON이 아닙니다. 무거운 라이브러리 대신 순수 자바의 Map<String, String>을 사용하는 것이 가볍고 설계상으로도 정석임을 확인했습니다. (Jackson은 나중에 Body의 JSON을 파싱할 때 활약할 예정입니다!)

문제 2. split(":")의 치명적인 함정
단순히 split(":")을 쓰면 Host: localhost:8080 같은 데이터가 3토막으로 깨집니다. split(":", 2)를 사용하여 아무리 콜론이 많아도 딱 2등분(키와 값)만 되도록 방어 로직을 구축했습니다.

문제 3. 바디를 readLine()으로 읽으면 안 되는 이유
바디 데이터 끝에는 줄바꿈 기호(\r\n)가 없을 수 있습니다. 이때 readLine()을 쓰면 줄바꿈이 올 때까지 스레드가 영원히 대기하는 무한 블로킹(Blocking)에 빠집니다. 반드시 in.read()를 써서 정확한 길이만큼만 읽어야 합니다.

6. 실전 테스트: 브라우저 연동 및 Ghost Connection 문제 해결

이제 진짜 크롬(Chrome) 브라우저를 열어 주소창에 http://localhost:8080/test를 입력해 보았습니다. 콘솔에 브라우저가 보낸 날것의 데이터가 예쁘게 찍힙니다!


서버 소켓 작동 중... 손님을 기다립니다.
/0:0:0:0:0:0:0:1와 연결 성공!
Start Line: GET /test HTTP/1.1
추출된 메서드: GET
추출된 URI: /test
--- 파싱된 헤더 목록 ---
Key: [User-Agent], Value: [Mozilla/5.0 ...]
Key: [Host], Value: [localhost:8080]
... (중략) ...
----------------------

돌발 에러 발생: NullPointerException
테스트 도중 간헐적으로 다음과 같은 에러 로그가 찍혔습니다.


Exception in thread "Thread-1" java.lang.NullPointerException: Cannot invoke "HttpRequest.getMethod()" because "request" is null

이는 현대 브라우저가 성능 최적화를 위해 데이터 없이 빈 연결만 미리 맺어보는 'Ghost Connection' 특성 때문이었습니다. 파서가 null을 반환할 때의 방어 로직을 RequestHandler에 추가하여 해결했습니다.


// RequestHandler.java 버그 픽스
HttpRequest request = HttpRequestParser.parse(in);

if (request == null) return; // 의미 없는 빈 연결은 즉시 종료!

System.out.println("추출된 메서드: " + request.getMethod());

7. 마무리하며

순수 자바만으로 복잡한 HTTP 요청을 HttpRequest 객체로 완벽하게 변환해 냈습니다. 이 과정에서 라이브러리의 소중함과 동시에, 그 마법 같은 기능 뒤에 숨겨진 텍스트 처리와 예외 방어 로직의 본질을 이해할 수 있었습니다.

다음 포스팅에서는 이렇게 파싱된 요청들을 적절한 비즈니스 로직으로 연결해 주는 '리플렉션 기반의 동적 라우팅'을 다뤄보겠습니다.