올해 초에 진행된 무신사 AI ROOKIE NATIVE ENGINEERING 전형에 최종 합격하게 되었다🎉 채용 전환형 인턴을 뽑는 전형이라 과정이 길었다. 그래서 그 과정들을 회고해보려고 한다.

지원 계기

2022년 대학 입학 당시만 해도 ChatGPT가 없던 시절이였다. 하지만 졸업하는 시점인 지금은 바이브 코딩이 뜨고 Claude, Cursor, MCP, n8n 같은 도구들이 많이 생겨나고 있다.

단 몇 년 만에 명령어 몇 줄로 프로젝트를 완성하는 시대를 체감하다 보니, 앞으로는 이러한 AI 도구들을 목적에 맞게 잘 활용하는 능력이 개발자의 경쟁력을 결정하지 않을까 생각했다.

대부분의 공고들과 달리 AI agent를 활용해 개발하는 개발자를 뽑는다는 무신사의 공고를 보고 설레는 마음으로 지원했다!!

전형 과정은 아래와 같이 총 4단계였다. 1. 서류 전형 2. 1차 온라인 코딩테스트 3. 2차 온라인 코딩테스트 (AI Agent 활용) 4. 오프라인 인터뷰

1차 코딩테스트

시험은 구름 devth 사이트로 1시간 동안 진행되었고, 2문제었다. 문제 유형은 복잡한 알고리즘 문제가 아닌 많은 입출력과 예외 상황들을 구현하는 문제였다.

여기서도 전형의 목적이 드러났다❗

복잡한 알고리즘은 AI를 사용하면 1초만에 풀 수 있다.

🌟 하지만 주어진 요구사항을 제대로 분석하고, 코드로 정확하게 구현할 수 있는지는 사람의 개입이 필요하기에 그런 역량을 보는 것 같았다.

첫 번째 문제는 입출력부터 복잡하다고 느꼈기에 최대한 예제들을 참고해서 요구사항을 빠트리지 않으려고 노력했고, 35분이 걸렸다. 두번째 문제도 비슷한 유형이라 코드를 반쯤 입력하는 중에 시험이 종료되었다... 허허🤣

다행히 1문제만 잘 구현했다면 합격인 것 같았다..!

2차 코딩테스트

시험이 3시간 동안 진행되었고, AI agent를 사용하는 시험이었기에 여러 API들을 구현하는 문제가 아닐까 예상했었다.

이번 전형은 백과 프론트를 나누지 않고 뽑는 전형이라 프론트 영역이 나올까 걱정은 했지만 그래도 백엔드 구현에 집중하자고 마음 먹었다.

회사에서 Codex를 지원해주지만 평소에 사용하던 Claude로 진행했다.

👉 Claude에게 요구사항이 긴 예상 문제를 추천해달라고 했고, 그렇게 매일 1문제씩 타이머를 맞춰 구현하는 연습을 했다.

하지만 요구사항이 많으면 많을수록 말을 듣지 않았다...

그래서 3가지 정도를 미리 대비해두었다.

✔️ 단계별 md 파일 전략

요구사항 자체를 AI가 해석하고, 스스로 진행 순서를 md 파일로 나누어 한 단계가 구현될 때마다 내가 확인하는 방식으로 진행했다.

✔️ Claude.md 작성 공통적으로 지켜야 할 최소한의 규칙들을 미리 작성해서 아키텍처 구조나 공통 응답 방식, 예외 처리 같은 부분들은 나의 개발 방식에 맞추도록 했다. (그래도 지켜지지 않는 부분은 시험 당시에 즉각 claude.md에 다시 추가했다)

✔️ TDD 개발 필요하지 않은 메서드나 클래스를 미리 만들어 오류가 발생하는 경우가 빈번하게 발생했다. 좋은 방법이 없을까 고민하다가, 평소에 좋은 개발 방식인 것은 알고 있지만 사람이 직접 하면 속도가 느리기에 쉽게 하지 못했던 TDD 개발 방식을 지키도록 명령했다.

2026-musinsa-rookie 2차 코딩테스트 문제

다행히 연습한 방식대로 문제가 나왔고, 구현은 쉽게 할 수 있었다. 다만‼️

• 명시되는 요구사항을 어떤 스택을 사용하여 어떻게 구현할지
• 또 명시되지 않은 요구사항은 어디까지 구현할지

는 스스로 판단해야 했기에 그 부분이 어려웠다. 하지만 이게 시험의 포인트가 아닐까 생각한다 🌟

AI agent를 사용하면 백엔드 경험이 없더라도 누구나 기능이 돌아가게 만들 수 있는 시대다. 하지만

• 어떤 방식으로 락을 걸지?
• 락을 어디까지 적용할지?
• 현재 상황에서 우선순위가 무엇인지?

와 같은 것들은 사람의 개입이 꼭 필요하다. 그것이 개발의 질을 높이는 것이라 생각하기에 무신사가 그런 사람을 원하는 것 같았다.

실제 구현과 점검은 1시간 반 정도 걸렸지만, 요구하는 문서들이 많았기에 문서를 쓰는 데 시간을 많이 썼다.

• 내가 어떻게 AI를 사용했고,
• 요구사항들을 어떻게 해석했고,
• 어디까지 구현할지에 대한 근거들을 자세하게 작성했다.

자격증 시험과 날짜가 비슷해서 잠을 줄여가며 연습했고, 최선을 다했기에 결과에 대한 후회는 없을 것이라 생각했다.

근데.. 진짜 합격..!!🤩 AI로 채점을 해서 그런지 결과가 빨리 나왔고, 설 연휴 전에 좋은 소식을 받아 너무너무 기뻤다.

인터뷰

사전에 인터뷰 관련 메일을 받았다. 인터뷰는 1,2차 코딩테스트와 제출한 포트폴리오에 대한 질문이라고 했다.

그래서 노션에 회고를 하며 예상 질문들을 잔뜩 적고 답하면서 연습했다. 추가로 AI에 대한 나의 생각이나 기본적으로 나오는 기술 질문, 컬쳐핏 질문들도 준비했다.

면접 경험이 많이 없었기에 유튜브에 면접 팁들을 많이 찾아봤고, 카드를 입에 물고 웃는 연습까지... ㅋㅋㅋㅋ 했다^^😁 (너무 간절해서...)

면접은 1:1로 1시간 동안 진행되었다. 크게 세 가지에 대해 길게 대화했다.

❓ 2차 코딩테스트에서 나왔던 수강신청 로직

• 왜 이렇게 구현했는지
• 이렇게 구현했을 때의 문제점이 무엇인지
• 그 문제점을 해결하려면 어떻게 해야 하는지
• 해결 방법을 적용했을 때의 Trade-off가 무엇인지 등 꼬리 질문들이 이어졌다.

하지만 힌트도 주시고 편한 분위기라 꼬리 질문들에 대한 내 생각을 이야기하는 과정이 토론하는 것처럼 재밌었다.

❓ 포트폴리오에 작성한 수강신청 시스템

이전에 대용량 트래픽 수강신청 시스템을 개발한 경험이 있었기에 그 프로젝트와 비교하는 질문들도 있었다. 또 그 당시 JMeter를 이용해서 대용량 트래픽을 테스트 했었는데,

• 그때 JMeter를 어떻게 사용했고
• 어떤 기준으로 결과를 분석했고
• 어떤 테스트 시나리오들이 있었는지도 물어보셨다.

❓ AI 활용 방법과 한계점

위에 적어둔 2차 코딩 테스트의 3가지 전략을 AI 활용 방법으로 설명했다. 하지만 이 방법이 완벽한 것은 아니기에, AI가 올바르게 구현하도록 하기 위한 또 다른 방법으로 *무신사 블로그에서 본 글을 언급하며 대답했다. *

질풍노도의AI에게 엄격한 선생님 장착하기

(면접 전에 기술 블로그를 읽고, 예상 질문 답변과 함께 답할 수 있는 부분이 있는지 살펴보는 것도 도움이 되었다)

이 외에는 간단한 컬쳐핏 질문 두 문제 정도와 마지막 질문이 있는지 여쭈어보셨다.

어떤 팀에 소속되어 있는지 여쭈어봤는데 29CM의 결제 직전까지의 모든 사용자 단계를 개발하는 팀이었다.😲

이전에 대용량 트래픽 시스템을 개발하면서 확장 가능한 코드를 작성하느라 많이 노력했지만 7천명 이상에서는 한계가 있었다. 그래서 29CM의 쿠폰 발급처럼 트래픽이 몰리는 상황에서는 어떻게 구현되는지 공부해보고 싶다고 말씀드렸다.

최종 합격

너무 간절해서였을까.. 인터뷰 전형 합격 소식과 함께 입사 조건 검토 메일이 왔다!!🥳

4학년때부터 준비한 취업 과정이 너무 길게 느껴질 만큼 힘들었는데, 묵묵히 최선을 다한 덕분에 졸업하자마자 이런 좋은 기회를 얻을 수 있어 너무 감사했다.

첫 회사가 무신사라는게 너무 설레서 잠도 못 자고 밥도 안 들어갔다.. ㅎㅎ 행복해서 다크서클이 생긴건 처음이다...

6개월 동안 좋은 동료들과 함께 많은 경험을 쌓고, 많이 배우는 시간이 되었으면 좋겠다. 파이팅💪🏻

여러 수업에 참여했지만, 그중에서도 특히 기억에 남고 의미 있었던 대표 수업 세 가지를 언급하겠다. 🌟이 경험들이 단순한 ‘교육 활동’에 머무르지 않고 개발자로서의 커뮤니케이션 능력을 키우는 데에도 많은 도움이 되었기 때문이다.

📍성산중 디지털 윤리 수업

성산중학교에서는 혼자 강사로 수업을 맡아 디지털 윤리 수업을 진행하게 되었다. 윤리라는 주제 자체는 학생들에게 익숙한 내용이 많았지만, 디지털 환경에서의 개념(ex IP, 서버, 인터넷망)은 낯설어하는 학생들이 많다.

🧠 그래서 나는 최대한 추상적인 기술 개념을 아이들의 언어로 쉽게 풀어 설명하려고 노력했다.

• "인터넷은 눈에 보이지 않지만 서로 연결되어 있는 거대한 거미줄이라고 생각해볼래?

• "우리가 각자 사용하는 컴퓨터는 거미줄 끝의 ‘서버’라고 할 수 있어. 이 서버들이 줄을 타고 연결되어 있어야 서로 메시지를 주고받을 수 있겠지?"
• "그런데 서버가 누구인지를 알아야 연결할 수 있으니 IP주소는 서버의 집 주소와 같은 역할을 해."
• "데이터를 주고받을 땐 한번에 가지 않고 '택배처럼 잘게 나뉘어서' 가는 ‘패킷’이라는 것도 있어."

이런 식으로 시각 자료와 함께 설명했더니 학생들의 이해도가 훨씬 높아졌다. PPT 자료는 단순한 텍스트보다 시연 영상과 퀴즈 요소를 넣어서 구성했고 수업 전에는 여러 번 리허설을 하며 시간 배분도 꼼꼼히 점검했다.

🎨 수업 후반에는 Canva라는 AI 기반 디자인 도구를 활용해 학생 각자가 ‘자기만의 명함’을 만드는 활동도 진행했다. 단순히 정보를 전달하는 수업이 아니라 디지털 도구를 실생활에서 어떻게 응용할 수 있는지 체험해보는 시간으로 구성하고 싶었다.

📍 2. 김천여중 알티노 자율주행차 코딩 수업

김천여중에서는 1~4교시에 걸쳐 자율주행차(알티노)를 블록코딩으로 제어하는 수업을 진행했다. 🧠 이 수업은 특히 반복문(for, while)이나 조건문 같은 기초 코딩 개념을 처음 접하는 아이들에게 어떻게 쉽게 설명할 수 있을지 고민이 많았던 수업이다.

아이들은 대부분 코딩을 처음 접해보는 친구들이었기 때문에, 추상적인 용어보다는 친근한 일상 예시를 들어 설명하려고 했다.

예를 들어 for문은 이렇게 설명했다.

"라면을 끓일 때 물을 붓고 → 스프를 넣고 → 면을 넣고 → 3분간 끓이는 과정을 세 번 반복한다고 생각해봐. 그러면 이게 바로 for문이야!"

while문은 조금 다르게 접근했다.

"while문은 ‘엄마가 그만하라고 할 때까지 게임하기’ 같은 거야. 언제 끝날지 모르고 계속 반복되니까 while은 조건이 참일 때 계속 도는 거고, for는 정해진 횟수만큼 반복되니까 달라!"

이렇게 설명하니 아이들이 금방 고개를 끄덕이며 이해하는 모습을 보여줬고, 직접 블록을 조립해서 자율주행차가 ‘실제로 움직이는’ 과정을 보면서 흥미를 느끼는 듯했다.

‘내가 입력한 코드가 진짜로 작동하고 있구나’라는 성취감을 아이들 스스로 느낄 수 있게 해주고 싶었고, 그 부분은 충분히 전달된 것 같아 뿌듯했다.

📍 3. 경일여고 데이터분석 자격증 수업

경일여고에서는 방학 특강으로 4일간의 AI 데이터 분석(AICE Junior) 자격증 수업 보조를 맡았다. 🧠 이 수업은 비교적 난이도가 높은 수업이었고 딱딱한 개념들이 많다 보니 어떻게 하면 ‘기계적인 암기’가 아닌 ‘이해 기반’의 수업이 될 수 있을까를 가장 많이 고민했다.

예를 들어, MAE와 MSE의 차이를 이렇게 설명했다.

"친구 생일을 1일 틀리는 것과, 10일 틀리는 건 느낌이 다르지? MAE는 평균 오차고, MSE는 큰 오차에 더 민감하게 반응해. MSE는 오차를 제곱하니까 실수를 더 크게 받아들이는 방식이야."

또 머신러닝의 종류를 설명할 때는 이렇게 말했다.

"단순 회귀는 딱 하나의 조건만 가지고 예측하는 거야. 예를 들어 ‘공부 시간만 가지고 시험 점수를 예측하는 것’ 다중 회귀는 여러 개를 고려하는 거지. ‘공부 시간, 수면 시간, 식사 여부까지 다 고려해서 점수를 예측하는 것’!"

이렇게 예시를 들어 설명했을 때, 아이들이 훨씬 자연스럽게 받아들이는 것을 보면서 ‘설명이 어렵고 복잡하다고 느껴지는 건 결국 예시가 없어서 그런 게 아닐까’라는 생각이 들었다.

💡이 활동이 나에게 어떤 의미였는가?

나는 백엔드 개발자가 되기 위해 다양한 프로젝트를 진행하며 기술적인 역량을 키워왔다. 하지만 실제 프로젝트를 하는 과정에서 프론트엔드나 기획자 등 다른 직군과의 소통이 매우 중요하다는 것을 자주 느꼈다.

이 강사 활동을 시작한 것도, 단순히 교육이 하고 싶어서가 아니라 "기술을 기술 언어로만 설명하지 않고, 상대방의 눈높이에 맞게 전달하는 연습"을 하고 싶었기 때문이다.

실제로 이런 연습이 많이 되었고, 프로젝트를 진행하면서 큰 도움이 되었다.

예를 들어, 프론트엔드 팀원에게 Redis와 SSE 구조를 설명해야 할 일이 있었는데 이렇게 설명한 적이 있다.

"Redis의 pub/sub 구조를 통해 서버A가 서버B에게 '지금 들어와도 돼!'라는 메시지를 실시간으로 보내주고 이때 클라이언트는 SSE를 통해 서버B와 연결된 상태로 계속 대기하다가, 서버 B가 A에게 메시지를 받으면 클라이언트에게 신호를 보내요"

이렇게 설명했더니 프론트팀도 쉽게 이해하고 그에 맞춰 설계해줬다. 결국 기술은 사람을 위한 것이고, 그 기술을 잘 전달할 수 있어야 진짜 개발자라고 생각한다.

앞으로도 나는 단순히 코드를 잘 짜는 개발자가 아니라, 기술을 이해시키고 함께 만들어갈 수 있는 개발자가 되고 싶다. 그 방법 중 하나가 기술을 모르는 사람에게 쉽게 설명하는 연습이라고 생각한다.

사용자 화면에서도 좌석 수가 즉시 반영되는 것을 확인할 수 있다. ❓우리는 어떻게 이런 실시간 좌석 반영 기능을 만들었을까❓

1. 고민 과정

💭 실시간 여석 수를 MySQL에서 가져와야 할까?

초기에 수강신청 여석은 MySQL 컬럼에서 관리했다. 하지만 실시간성 요구가 커질수록 디스크 기반 DB에서 잦은 조회는 부하가 크고 응답 속도도 한계가 있었다. 앞서 프로젝트에서 Redis를 사용했던 경험이 있었기 때문에 “좌석 수만큼은 Redis에서 관리하면 더 빠르게 실시간 처리가 되지 않을까?”라는 생각이 들었다.

🌟결국 MySQL은 정합성을 보장하는 저장소로, Redis는 실시간 여석 수를 관리하는 역할로 분리하게 되었다.

💭 그렇다면 어떻게 실시간을 전송할까?

✔️ Polling 기반 계획 처음에는 프론트에서 일정 주기로 잔여 좌석 조회 API를 호출하는 것을 계획했었다. 하지만 이 방식은 사용자 수가 늘어날수록 서버에 불필요한 요청이 폭주했고 실시간성도 “주기적 갱신”이라는 한계에 부딪혔다.

✔️ WebSocket 고려 양방향 통신이 가능해 강력했지만 이번 요구사항은 단방향 알림(서버→클라이언트)만 필요했다. 인프라 관리와 구현 난이도를 고려했을 때 과도한 선택이라고 판단했다.

✔️ SSE(Server-Sent Events) 선택 HTTP 기반 단방향 스트리밍이라 브라우저 기본 지원이 가능했고 프론트 적용도 단순했다. 서버는 필요한 시점에만 알림을 push하면 되었기 때문에 Polling 대비 서버 부하를 크게 줄일 수 있었다. 무엇보다 Redis와 함께 사용했을 때 빠른 조회 + 실시간 전송이라는 요구사항을 가장 깔끔하게 충족할 수 있었다.

2. 설계와 구현

실시간 기능을 적용하기 위해 아래와 같은 구조를 도입했다.

👉 Redis

• 좌석 수는 course:{id}:remaining 키에 저장
• 수강신청 성공 시 decrement(), 취소 시 increment()로 즉시 반영
• Redis는 메모리 기반이라 조회/갱신 속도가 매우 빠름

👉 SseEmitterManager

private final Map<Long, SseEmitter> emitters = new ConcurrentHashMap<>();
private final Map<Long, List<Long>> subscribedCourses = new ConcurrentHashMap<>();

• 사용자당 Emitter는 단 하나만 유지
• 각 emitter에 사용자가 구독한 courseId 리스트를 매핑
• 불필요한 중복 연결을 막아 서버 자원 효율성을 확보

👉 SseSeatService

• 구독 시점에 Redis 값을 조회 → 프론트에 초기 여석 값 전달
• 이후 좌석이 변하면 notifyRemainingChanged()에서 해당 courseId를 구독한 사용자에게만 이벤트 push

👉 EnrollmentService

• 수강신청/취소가 성공하면 Redis 좌석 변경
• 최신 좌석 값을 조회 후 구독자들에게 즉시 전송

📌 페이징을 사용하지 않은 이유

처음에는 강의 수가 많으니 페이징을 도입하는 것이 맞을까 고민했다. 하지만 몇가지 이유로 최종적으로는 페이징을 적용하지 않기로 결정했다.

• Redis 조회 속도는 매우 빠르기 때문에 많은 강의 여석을 한 번에 내려주더라도 서버 부하가 크지 않았다.
• 페이징을 적용하면 한 사용자가 여러 페이지(course 리스트)를 구독해야 하므로 사용자 1명당 여러 개의 SSE 채널이 발생하게 된다.
• 이는 오히려 서버 부하를 증가시키고 클라이언트 측에서도 연결 관리가 복잡해진다.

그래서 전체 강의 구독 + 사용자당 단일 SSE emitter 유지라는 구조로 선택했다.

3. 느낀점

이번 기능을 구현하면서 단순히 새로운 기술을 학습한 것이 아니라, 💡“이전에 배운 기술들을 실제 문제 상황에 맞게 도입하고 적용한 경험”을 얻을 수 있었다.

• 처음에는 MySQL만으로 좌석 수를 관리했지만 실시간 조회라는 요구사항 앞에서 한계를 느꼈다.
• 그때 앞서 학습하고 이미 사용해본 Redis의 특성을 떠올려 여석 수를 Redis로 옮겼고
• 마찬가지로 Polling 방식의 비효율을 개선하기 위해 과거 학습했던 SSE(Server-Sent Events)를 실서비스에 도입했다.

즉, 단순히 새로운 기술을 도입하는 것이 아니라 이전에 습득한 기술들을 문제 해결의 맥락에 맞게 해석하고 실제 기능에 녹여냈다는 점에서 의미가 컸다.

1. 기존 구조: Map 기반 관리의 한계

초기에는 서버 내부에서 아래와 같이 관리했다.

• 대기열: List<QueueUser> 형태로 메모리에 저장
• 입장한 사용자: Map<Long studentId, Long timestamp> 으로 추적
• 빈자리 발생 시: 수강신청 서버가 대기열 서버에 HTTP 요청(/notify)을 보내 ALLOWED 처리를 요청

이 구조는 간단하지만 다음과 같은 명확한 한계가 있었다:

2. Redis 구조 전환

이러한 문제를 해결하기 위해 시스템은 전체 구조를 Redis 중심으로 재설계했다. 단순한 캐시 용도가 아닌, 실시간 데이터 처리, 자동 만료, 비동기 메시지 전송까지 담당하는 핵심 인프라로 동작하게 되었다.

✅ Redis 구조 요약

💡 구조 개선 효과

• 입장 후 로그인 여부를 시스템이 자동으로 판단할 수 있다.
  TTL이 설정된 키를 통해 사용자가 로그인하지 않으면 자동으로 자리가 회수되고 별도의 관리 로직이 필요 없다.

• 빈자리 발생 시 대기열 서버로 정확하게 알릴 수 있게 되었다.
  기존에는 HTTP 요청으로 수동 알림을 보냈지만, 이제는 Redis Pub/Sub을 사용하여 수강신청 서버가 메시지를 발행하면
  대기열 서버는 이를 구독 중인 상태에서 자동으로 수신하여 실시간으로 반응할 수 있게 되었다.

  

  👉 서버 간 강한 의존 없이 느슨하게 연결되는 구조(Low Coupling)로 바뀌었다.

• 순번 계산이 간단하다.
  LPOS, LRANGE 등을 통해 Redis 내부에서 순번을 계산할 수 있어서 별도의 인덱스 관리가 필요 없기에 대기 순번도 자동으로 이동된다.

• BatchManager가 필요 없게 되었다.
  기존에는 미입장 사용자를 수동으로 관리하기 위해 별도의 로직이 존재하였지만, Redis TTL 구조로 자동 만료가 가능해지면서 이 기능을 제거할 수 있게 되었다.

3. 시스템 흐름

➡️ 대기열 접속 시 해당 사용자의 토큰을 Redis List에 저장

redisTemplate.opsForList().rightPush("queue:waiting", token);

➡️ 사용자에게 SSE를 통해 아래와 같은 메시지를 전송

{
  "queueNumber": 125,  //대기순번
  "status": "WAITING"
}

➡️ 빈자리 발생 → 입장 로직 수강신청 서버에서 로그아웃, TTL 만료 등 변화 발생 시

stringRedisTemplate.convertAndSend("entrance-channel", String.valueOf(currentSessionCount));

대기열 서버는 entrance-channel을 구독 중이며 메시지를 수신하면 다음 순서로 로직을 수행한다:

• Redis에서 LPOP으로 입장 대상 토큰들을 꺼냄
• 꺼낸 토큰에 대해 SSE로 status:ALLOWED 전송
• Redis에 session:{studentId}로 TTL 기반 세션 저장

stringRedisTemplate.opsForValue().set(
  "session:" + studentId,
  "active",
  SESSION_TTL,
  TimeUnit.MILLISECONDS
);

TTL이 지나면 자동 삭제되어 별도 정리 필요 없음 → 빈자리 발생으로 간주 가능 또한 수강신청 서버는 현재 인증된 사용자 수를 Redis에서 즉시 조회 가능

Redis 도입은 단순한 성능 향상이 아닌 정확하게 입장시킬 사람을 판단하고, 로그인하지 않은 사용자의 자리를 시스템이 자동으로 회수할 수 있도록 만든 구조 개편이었다.

또한 Pub/Sub 구조 도입을 통해 수강신청 서버와 대기열 서버 간의 의존성을 줄이고 실시간 메시지 전송을 안정적으로 처리할 수 있게 되었다.

✅ “입장”을 판단하고 ✅ “알리는 방식”까지 모두 개선함으로써 수강신청 시스템의 실시간성, 정합성, 확장성이 모두 확보되었다.

기존 수강신청 시스템은 Polling 방식으로 동작하고 있었다. 사용자는 일정 간격으로 자신의 대기 상태를 확인하며, ALLOWED 상태가 되었는지를 계속 서버에 요청해야 했다.

Polling 방식은 단순하고 안정적이라는 장점이 있었지만 대기 인원이 많아질수록 불필요한 요청이 반복적으로 발생했고, 서버는 매 요청마다 사용자 상태를 계산하고 응답해야 했다.

"사용자가 굳이 물어보지 않아도 되게 할 수 없을까❓"

그렇게 도입하게 된 구조가 바로 SSE(Server-Sent Events)이다.

2. SSE란?

SSE(Server-Sent Events)는 서버가 클라이언트에 단방향으로 실시간 데이터를 푸시하는 기술이다.

HTTP 기반으로 동작하며 브라우저가 서버와 연결을 유지하고 있다가 서버에서 이벤트가 발생할 때마다 event-stream을 통해 바로 데이터를 받을 수 있다.

📌 특징

• 연결 방식: 단방향 (서버 → 클라이언트)
• 전송 프로토콜: HTTP + text/event-stream
• 장점: WebSocket보다 가볍고 브라우저 호환성도 뛰어남
• 사용 시점: 실시간 알림, 상태 푸시, 실시간 대시보드 등

👉 우리는 이 구조를 활용해 “입장 가능” 과 “순번 상태 변경”을 실시간으로 알려주는 방식으로 전환했다.

➡️ 왜 Polling보다 효율적인가?

➡️ Spring에서 SSE 구현 방식 Spring에서는 SseEmitter라는 클래스를 제공한다. 이를 통해 클라이언트에 메시지를 비동기적으로 푸시할 수 있다.

@GetMapping(value = "/sse/{uuid}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter subscribe(@PathVariable String uuid) {
    return sseQueueService.subscribe(uuid);
}

• MediaType.TEXT_EVENT_STREAM_VALUE → SSE 프로토콜을 사용한다는 의미
• 연결된 사용자 별로 SseEmitter 인스턴스를 발급해 연결 상태를 관리한다.

✅ 지속 연결 관리 – EmitterManager EmitterManager는 사용자별로 연결된 SSE 통신 채널(SseEmitter)을 관리하는 역할을 한다.

private final Map<String, SseEmitter> emitters = new ConcurrentHashMap<>();

• token(UUID)를 키로 사용해 각 사용자의 SseEmitter를 저장
• ConcurrentHashMap을 사용해 멀티스레드 환경에서도 안전하게 동작

에러, 타임아웃, 종료 이벤트는 자동으로 감지되며 해당 시점에 emitter.complete() 및 removeEmitter(token)을 호출해 메모리 누수를 방지했다.

3. 구현 흐름

전체 흐름은 다음과 같이 변경되었다.

1️⃣ 사용자가 /join을 통해 대기열에 진입하면 서버는 사용자 정보를 큐에 등록하고 상태 WAITING과 순번을 반환한다.

2️⃣ 1번 과정에서 클라이언트는 SSE에 연결된다. 이제부터 클라이언트가 주기적으로 상태를 요청하지 않아도 서버는 상태가 변경되면 실시간으로 메시지를 보낸다.

3️⃣ 빈자리가 발생하면 수강신청 서버에게 /notify API로 알림을 받고, 큐의 앞쪽에 있는 기준으로 입장 대상자를 선정한다. 해당 사용자들에게 ALLOWED 상태의 메시지를 SSE로 push한다.

4️⃣ ALLOWED 사용자는 로그인 시도 입장 완료 후 SSE 연결 종료! 대기 중인 사용자들 순번을 다시 계산하여 WAITING 상태와 순번을 반환한다.

4. 비동기 전송 구조 도입

SSE는 서버가 클라이언트에게 실시간으로 데이터를 push하는 구조지만 이 전송은 내부적으로 I/O 작업이다. 즉, 데이터를 보내는 순간까지 해당 스레드는 블로킹 상태가 될 수 있다.

만약 여러 사용자에게 동시에 메시지를 보내야 하는 상황이라면❓ ✔️ 각 사용자의 전송이 순차적으로 처리되면 전체 처리 시간이 늦어지고 ✔️ 하나의 사용자 전송이 지연되면 나머지 사용자 알림도 지연되는 문제가 생긴다.

그래서 SSE 전송 로직을 별도 클래스로 분리하고 @Async를 통해 비동기 전송이 되도록 리팩토링했다.

🖥️ SseAsyncSender.java

@Slf4j
@Component
@RequiredArgsConstructor
public class SseAsyncSender {

    private final SseEmitterManager emitterManager;

    @Async("sseAsyncExecutor")
    public void send(SseEmitter emitter, String event, Object data, String token) {
        try {
            emitter.send(SseEmitter.event()
                .name(event)
                .data(data));
            log.info("✅ send 성공!!");

            if ("allowed".equals(event)) {
                emitter.complete();
                emitterManager.removeEmitter(token);
                log.info("✅ emitter 종료 및 제거 완료: token={}", token);
            }
        } catch (IOException e) {
            log.warn("🚨 SSE 전송 실패: event={}, message={}", event, e.getMessage());
        }
    }
}

• @Async("sseAsyncExecutor")를 붙여 이 메서드는 별도 스레드풀에서 비동기로 실행
• 동시에 수십 명에게도 병렬로 빠르게 전송 가능
• "allowed" 이벤트일 경우 emitter를 종료하고 등록된 emitter도 정리
• 전송 성공/실패 로그를 통해 상태 추적 가능

이 구조가 없었다면… 수천명의 대기자가 동시에 입장이 허용되는 상황에서 사용자 1명의 전송이 지연될 때 나머지 모두가 기다려야 했을지도 모른다.. 🤣 비동기화는 성능을 위한 선택이 아니라 필수였다!

5. 비동기 스레드풀 조정

기존에는 톰캣 기본 스레드풀을 조정해 요청 처리를 분산하고 있었지만 이번에는 SSE 전송 전용 비동기 스레드풀을 별도로 도입하고 튜닝을 진행했다. 왜냐하면 SSE 메시지 전송은 I/O 작업이기 때문에 수많은 사용자에게 메시지를 한꺼번에 보내야 하는 순간 서버의 처리 병목이 생길 수 있기 때문이다.

✅ 비동기 스레드풀이란? Spring에서는 @Async를 통해 특정 메서드를 별도 스레드풀에서 병렬 실행할 수 있다. 우리는 SseEmitter.send() 전송을 비동기로 처리하기 위해 다음처럼 스레드풀을 정의했다.

private static final int CORE_POOL_SIZE = 16;
private static final int MAX_POOL_SIZE = 64;
private static final int QUEUE_CAPACITY = 800;

그리고 이 풀을 sseAsyncExecutor로 지정하여 SSE 전송 전용 비동기 처리 스레드풀로 사용했다.

• CORE_POOL_SIZE : 요청이 없어도 유지되는 기본 스레드 수
• MAX_POOL_SIZE : 큐가 가득 찼을 때 생성 가능한 최대 스레드 수
• QUEUE_CAPACITY : 대기 큐 크기. Core를 초과한 요청이 일시적으로 저장되는 공간

➡️ 1차 설정 (과대 설정)

CORE_POOL_SIZE = 64  
MAX_POOL_SIZE = 256  
QUEUE_CAPACITY = 2000  

• 오히려 오류율이 높았음
• CPU 사용량만 높고 실제 전송은 제대로 병렬처리되지 않음
• 📌t3.large 인스턴스의 성능 한계로 과도한 스레드는 컨텍스트 스위칭만 유발함

➡️ 2차 → 3차 → 4차... 테스트 스레드풀의 크기를 단계적으로 줄여가며 오류율을 비교한 결과 오류율이 다시 높아지는 시점을 기준으로 최적점을 찾아낼 수 있었다. 그 결과 실제 배포 환경인 t3.large 인스턴스(vCPU 2, RAM 8GB)에 가장 적합한 설정은 다음과 같았다:

CORE_POOL_SIZE = 16
MAX_POOL_SIZE = 64
QUEUE_CAPACITY = 800

이 설정은 테스트 과정에서 충분한 병렬 처리 성능을 제공하면서도 불필요한 컨텍스트 스위칭이나 CPU 과소비 없이 안정적인 전송 처리가 가능했다.

🌟중요🌟

단순히 스레드를 많이 할당한다고 성능이 오르지 않는다는 점을 실험을 통해 직접 확인할 수 있었다. 서버 리소스와 작업 특성을 고려한 실험적 튜닝이 가장 중요하다!!

카프카는 기본적으로 자가 호스팅이 가능한 오픈소스 메시징 플랫폼이지만, 운영 및 유지보수에 대한 부담을 줄이기 위해 SaaS(Software as a Service) 형태로 제공되는 서비스들도 존재한다. 대표적으로는 AWS의 MSK(Amazon Managed Streaming for Apache Kafka)와 Confluent Cloud가 있다.

Confluent Cloud는 카프카의 핵심 개발자인 제이 크렙스가 창업한 기업에서 운영하는 공식 관리형 서비스이다. Kafka 클러스터의 설치, 구성, 운영, 확장, 보안 등을 모두 웹 기반으로 관리할 수 있도록 해준다.

🌟 장점

• Zookeeper, Broker, Topic, Connect 등 인프라 구성을 직접 하지 않아도 됨
• Kafka 클러스터의 생성을 클릭 몇 번으로 완료할 수 있고 토픽 생성, 삭제, Connect 설정, Schema Registry 관리 등도 웹 UI 기반으로 수행 가능
• AWS, GCP, Azure 등 원하는 클라우드 환경에서 실행 가능
• Kafka를 직접 운영할 때 흔히 발생하는 설정 이슈(토픽 리텐션, 파티션 조정, ACL 등)나 운영 노하우 부족에서 오는 시행착오를 줄일 수 있음

REST API를 통해 Kafka Connect를 동적으로 설정할 수 있기 때문에, 지속적으로 커넥터 기반 파이프라인을 확장해야 하는 환경에서는 직접 개발 없이도 자동화된 구성이 가능하다. ✔️ Confluent Cloud와 같은 SaaS 기반 Kafka 서비스를 도입하면 스트리밍 플랫폼 운영에 대한 부담을 줄이고 실제 데이터 처리와 서비스 로직 구현에 집중할 수 있는 개발 환경을 구축할 수 있다‼️

2. 빅데이터 플랫폼 아키텍처와 카프카

➡️ 초기 빅데이터 처리 방식 각 서비스 애플리케이션으로부터 데이터를 배치방식으로 수집해 일괄 처리하는 구조였다. ⚠️ 실시간 데이터 반영이 느리고, 파편화된 데이터로 인해 데이터의 흐름과 히스토리를 추적하기 어려운 단점이 있었다. +개인정보 보호, 데이터 품질, 생명주기 등을 체계적으로 관리하는 데이터 거버넌스 측면에서도 유연성이 부족했다.

➡️ 람다 아키텍처

람다 아키텍처는 다음 세 가지 계층으로 구성된다:

• 배치 레이어: 과거 데이터를 모아 일정 주기로 일괄 처리 ex) Spark job
• 스피드 레이어: 실시간 데이터 분석을 위한 계층 ex) Kafka
• 서빙 레이어: 처리된 데이터를 외부 서비스가 접근할 수 있도록 저장

실시간성과 정확도를 동시에 만족시키기 위한 목적이었지만 ⚠️ 동일한 로직을 배치/실시간에 각각 구현해야 한다는 이중 관리 문제 디버깅, 배포, 모니터링 역시 두 시스템을 별도로 다뤄야 하는 번거로움이 있었다.

➡️ 카파(Kappa) 아키텍처

배치 레이어를 제거하고 모든 데이터를 스트리밍 기반의 스피드 레이어에서 처리하도록 구성한다. 즉 Kafka를 중심으로 운영하는 것이다. 스트리밍 처리 하나로 데이터 파이프라인을 단순화할 수 있다는 장점이 있다.

➡️ Streaming Data Lake 아키텍처

서빙 레이어마저 제거! Kafka를 일시적인 메시지 큐가 아닌 장기 저장과 쿼리 분석이 가능한 데이터 레이크처럼 사용하자는 발상!

💡 이를 위해선 두가지를 갖추어야한다.

1. 스트리밍 데이터를 배치처럼 조회할 수 있어야 한다
2. 자주 조회하지 않는 데이터는 저렴한 저장소로 자동 이전하는 기능이 필요하다

이러한 개선이 아직 진행 중이긴 하지만 Kafka가 스트리밍부터 저장,분석까지 아우르는 중심 플랫폼으로 진화하고 있다는 흐름은 분명하다.

가까운 미래에는 Kafka가 단순한 메시지 브로커가 아니라 완전한 빅데이터 플랫폼의 핵심 엔진으로 자리 잡을 가능성이 높다고 한다.

3. 아파치 카프카의 미래

카프카는 왜 이렇게까지 많이 쓰일까? 그리고 앞으로도 계속 쓰일까? 결론은 🅾️ 이미 너무 많은 기업들이 핵심 데이터 파이프라인에 카프카를 사용하고 있다. 원래 카프카는 링크드인 내부에서 여러 메시지 시스템들을 붙여 쓰다가 “너무 복잡하고 유지보수 힘들다”는 이유로 만들기 시작한 거였다. 그때의 문제는 지금도 여전히 많은 기업들이 겪고 있는 문제다. 그래서 Kafka는 지금도 "필요한 기술"로 받아들여진다.

🌟특히 좋은 점은

• 데이터를 엄청 빠르게 보낼 수 있다.
• 서버만 늘리면 확장도 쉽다.
• 컨슈머가 읽어가도 데이터가 사라지지 않아서 여러 팀에서 동시에 써도 괜찮다.

이런 특성 덕분에 카프카는 네이버, 카카오 같은 대기업은 물론 빠르게 성장하는 스타트업에게도 많은 관심을 받고 있다고 한다. 초기에는 작게 시작해서 쓰다가 나중에 서비스가 커지면 그대로 확장하면 되니까 부담도 없다.

📢 요즘은 Kafka 본체만 쓰는 게 아니라 -> Kafka Streams, Connect, ksqlDB 같은 기능도 계속 늘어나고 있다. 심지어 웹에서 토픽을 만들고, 커넥터를 붙이고, 모니터링까지 할 수 있는 SaaS 서비스도 나와 있다.

즉, 카프카는 단순한 메시지 큐가 아니라** 실시간 데이터 플랫폼으로 계속 진화 중**이다. 앞으로도 실시간 로그, 트래픽 분석, 추천 시스템처럼 데이터를 빨리 다뤄야 하는 곳에서는 더 자주 쓰이게 될 거다.

✔️ 결론? 개발자로 일한다면 언젠가는 꼭 마주하게 될 기술이니까 가볍게라도 알아두자!!

https://blog.voidmainvoid.net/325

2. 카프카 프로듀서 애플리케이션

👉 Producer 역할

• Topic에 해당하는 메시지 생성
• 특정 Topic으로 데이터를 publish
• 처리 실패/재시도

⚠️ 카프카는 브로커 버전과 클라이언드 버전의 호환성을 꼭 확인해야한다.

🖥️ Producer.java

Properties configs = new Properties();
configs.put("bootstrap.servers", "localhost:9092");
configs.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
configs.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

• Kafka 서버 주소와 직렬화 방식 설정
• 실제 서비스에서는 2개 이상의 브로커 주소를 넣는 것을 권장!

KafkaProducer<String, String> producer = new KafkaProducer<>(configs);
ProducerRecord record = new ProducerRecord<>("click_log", "login");
producer.send(record);
producer.close();

• 위 설정을 기반으로 KafkaProducer 객체 생성
• click_log 토픽에 "login" 메시지 전송
• 키를 지정하지 않으면 Kafka가 파티션을 자동으로 분배
• .send()로 메시지를 비동기 전송
• .close()는 리소스를 해제하는 필수 작업

⚠️ send에 key값을 "1","2"와 같이 설정을 한다면 그림과 같이 데이터가 나뉘어지지만, 파티션이 하나 추가된다면 key와 파티션 매칭이 깨져서 key <-> 파티션 일관성이 보장되지 않는다.

3. 카프카 컨슈머 애플리케이션

👉 Consumer 역할

• Topic의 partition에서 데이터 polling
• Partition offset 위치 기록 (commit)
• Consumer group을 통해 병렬처리

🖥️ Consumer.java

configs.put("bootstrap.servers", "localhost:9092");
configs.put("group.id", "click_log_group");
configs.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
configs.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

• Kafka 브로커 주소 및 컨슈머 그룹 ID 설정
• Key/Value 디시리얼화 -> Kafka 메시지 읽기 준비 완료!

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(configs);
consumer.subscribe(Arrays.asList("click_log"));

• "click_log" 토픽을 구독
• subscribe()는 전체 파티션을 자동 분배받음
• 특정 파티션만 읽고 싶다면 assign()을 사용해야 함

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
    for (ConsumerRecord<String, String> record : records) {
        System.out.println(record.value());
    }
}

• 0.5초 동안 메시지를 기다렸다가 처리
• 한 번에 여러 개의 메시지를 받아오고 record.value()로 개별 처리
• 실제 서비스에서는 DB, 로그 저장 등으로 확장 가능

⚠️ 컨슈머가 파티션이 2개인 click_log 토픽에서 데이터를 가져가는 중에 실행이 중지되어도, 어느 offset까지 읽었는지 consumer_offset 에 저장되어 있어 오류 시작위치부터 다시 복구할 수 있다. = ✔️고가용성의 특징

⚠️여러 파티션에 대해 병렬처리를 원한다면 컨슈머 수는 파티션 수보다 적거나 같아야한다.

⚠️하나의 토픽에 들어온 데이터는 여러 컨슈머 그룹이 독립적으로 소비하여 서로 간섭 없이 각자의 역할에 따라 처리한다.

4. 카프카 스트림즈 애플리케이션

Kafka Streams는 카프카에서 공식으로 제공하는 Java 기반의 스트림 처리 라이브러리이다. 기존의 Kafka Consumer를 사용하는 방식보다 더 빠르고 안정적인 데이터 처리가 가능하고 실시간 데이터 파이프라인 구축에 적합하다.

✅ Kafka와 완벽하게 호환 Kafka Streams는 Kafka의 버전에 맞춰 함께 업데이트되므로 보안 기능이나 트랜잭션 처리 등 최신 기능과의 호환성이 뛰어나다. -> 즉 Kafka 클러스터와 항상 완벽하게 맞물려 돌아가는 구조!! +Exactly Once Processing(정확히 한 번 처리) 기능을 기본 지원해 데이터 유실이나 중복 없이 안전하게 처리 가능

✅ 별도의 클러스터 없이 운영 가능 컨슈머처럼 애플리케이션 단독으로 배포하면 된다. -> 즉, 클러스터나 스케줄러 없이도 운영이 가능하다는 점에서 구조가 단순하고 유연!! 데이터 양이 적다면 애플리케이션 몇 개만 띄워도 충분하고 처리량에 따라 자연스럽게 수평 확장할 수 있다.

✅ DSL과 Processor API 제공 스트림 처리에 필요한 대부분의 기능을 DSL로 제공한다. ex) filter, map, join, window 등은 모두 간단한 메서드 호출로 구현 가능 -> 복잡한 로직이 필요한 경우에는 Processor API를 통해 직접 로직을 정의해 더 세밀한 제어도 가능하다.

5. 카프카 커넥트

Kafka에서 공식적으로 제공하는 데이터 파이프라인 컴포넌트이다. 데이터 송수신을 반복적으로 처리해야 하는 환경에서는 도입을 적극 검토할 만한 플랫폼이다.

➡️ 커넥트 vs 커넥터

• Connect는 커넥터를 실행시키는 플랫폼 역할, 일종의 실행환경(Processor)
• Connector는 실제 데이터를 송수신하는 로직이 담긴 코드 뭉치(JAR 패키지)

➡️ 커넥터의 종류

• Source Connector: 외부 데이터 소스(DB 등) → Kafka 토픽으로 데이터를 보내는 역할 (프로듀서 역할)
• Sink Connector: Kafka 토픽 → 외부 저장소(DB, Elasticsearch 등)로 데이터를 저장하는 역할 (컨슈머 역할)
• ex) 오라클 DB 데이터를 Kafka로 가져오고 싶다면 → Oracle Source Connector

➡️ 커넥트 실행 방식

• 단일 모드 (Standalone Mode): 개발/테스트용으로 간단히 실행 가능
• 분산 모드 (Distributed Mode): 프로덕션 환경에서 사용하는 방식 여러 커넥트 인스턴스를 클러스터로 구성하여 장애 발생 시 자동 복구(Failover)가 가능하다.

➡️ 실행 방법: REST API로 간단하게 커넥트는 REST API 기반으로 커넥터를 실행할 수 있다. 즉, 커넥터 코드를 별도로 배포하거나 다시 개발할 필요 없이 JSON 설정 파일 하나로 파이프라인을 반복적으로 생성한다.

ex) 동일한 Kafka 토픽 데이터를 오라클 테이블 A, 테이블 B에 각각 저장하고 싶다면? JSON 설정을 두 개 만들고 REST API로 두 번 요청만 하면 되는 것이다.

-> 복잡한 배포, 컨슈머 개발 없이 템플릿 기반으로 빠르고 효율적인 데이터 흐름 구성이 가능해진다.

서비스 초기에는 Source Application과 Target Application이 직접 연결된 단방향 구조를 사용한다. 하지만 애플리케이션 수가 늘어날수록 각 애플리케이션 간 데이터 흐름이 복잡해지고 포맷 파편화나 배포 충돌, 장애 대응의 어려움 같은 문제가 발생한다.

이러한 문제를 해결하기 위해 등장한 것이 Apache Kafka이다‼️

Kafka는 메시지 브로커(message broker)로서 Source와 Target 사이에 위치한다. 즉 데이터 생산자와 소비자 간의 결합도를 낮추는 역할을 수행하는 것이다. 👉 Source Application은 데이터를 Kafka에 전송하고 👉 Target Application은 Kafka에서 원하는 데이터를 구독한다.

2. 토픽이란?

Kafka에서 데이터를 구분하고 저장하기 위해 사용하는 논리적인 단위이다.

데이터베이스의 테이블, 파일 시스템의 폴더처럼 데이터의 카테고리를 나누는 개념이다.

• 즉 Producer는 특정 Topic에 데이터를 보내고 Consumer는 해당 Topic에서 데이터를 구독해 처리한다.

• Topic은 목적에 따라 이름을 명확하게 짓는 것이 좋다 🔽

  

Partition이란❓

Kafka에서 데이터의 저장과 처리 단위를 나누기 위한 물리적 단위이다. 하나의 Topic은 내부적으로 여러 개의 Partition으로 나뉜다.

각 Partition은 append-only 로그 구조로 데이터를 순차적으로 저장한다. Consumer는 가장 오래된 데이터부터 순서대로 읽어간다. 데이터를 읽은 후에도 삭제되지 않고 새로운 Consumer가 붙으면 다시 읽을 수 있다.

🌟 Partition 수만큼 Consumer를 병렬로 붙일 수 있어 성능 확장성이 뛰어나다.

✅ 메시지 분배 방식 producer가 특정 Partition에 분배할 때는

• 라운드 로빈 : 키를 지정하지 않은 경우, 순차적으로 Partition에 분배
• 키 기반 : 해시 메시지에 키가 있는 경우, 해시값을 기준으로 특정 Partition에 분배

메시지 삭제 방법은 아래와 같은 설정으로 처리한다. log.retention.ms 메시지 보존 최대 시간 (기본값: 7일) log.retention.bytes 최대 저장 크기

3. 브로커, 복제, ISR(In-Sync-Replication)

➡️ broker란? Kafka가 설치되어 있는 서버 단위

복제는 하나의 파티션 데이터를 여러 브로커에 복제 저장하는 방식이다. 이를 통해 고가용성(HA)을 확보할 수 있다. 예를 들어, 파티션 수가 1이고 replication이 3이면 다음과 같은 구조가 된다.

• partition: 1 → 실제 저장할 파티션은 하나
• replication: 3 → 총 3개의 브로커에 해당 파티션이 복제됨

⚠️ 즉 브로커 개수가 3이면 replication이 4가 될 수 없음

• Leader: 실제로 Producer로부터 데이터를 받아 저장하는 주체
• Follower: Leader의 데이터를 따라 복제만 수행함
• Producer는 오직 Leader 파티션에만 데이터 전송을 시도함

➡️ ISR이란? Leader와 동기화된 상태의 Follower들 집합을 의미한다. 만약 Leader가 장애로 중단되면, ISR 내에서 가장 적합한 Follower가 새로운 Leader 역할을 승계한다. 이를 통해 무중단 운영 및 데이터 손실 없는 전환이 가능해진다.

➡️ ack 옵션 Producer는 데이터를 보낼 때 ack 옵션을 설정할 수 있고 이는 데이터 전송에 대한 신뢰 보장 수준을 정한다.

❓그럼 복제 수는 많을수록 좋을까? 복제 수가 많을수록 안정성은 높아지지만 브로커 리소스를 더 많이 사용하게 된다. Kafka 클러스터의 브로커 수, 데이터 처리량, 보관 시간 등을 고려하여 적절한 복제 수를 설정하는 것이 중요하다!!

4. 파티셔너(Partitioner)란?

레코드에 포함된 메시지 키 또는 값에 따라서 어떤 파티션에 넣을지 결정하는 역할을 한다.

Producer를 사용할때 파티셔너를 따로 설정하지 않으면 UniformStickyPartitioner로 설정된다. 이것은 메시지 키가 있을때와 없을때 다르게 동작한다. 👉 메시지 키 있을 때

• 파티셔너에 의해 특정한 해시값 생성
• 동일한 키 -> 동일한 해시값 -> 동일한 파티션에 들어감
• 즉, 순서를 지켜 데이터 처리한다는 장점이 있음

👉 메시지 키 없을 때

• 프로듀서에서 배치로 모을 수 있는 최대한의 레코드를 모아 파티션으로 보냄
• 라운드 로빈 방식

📢 카프카는 커스텀 파티셔너를 만들 수 있도록 파티션 인터페이스를 제공한다.

• 메시지 키,값,토픽이름에 따라 어느 파티션에 데이터를 보낼지 결정 가능
• ex) vip 고객의 데이터를 더 빠르게 처리해야하는 상황 -> 10개의 파티션 중 8개를 vip 고객 데이터를 처리하도록 함

5. 컨슈머 랙(Consumer Lag)이란?

파티션에 데이터가 하나씩 들어갈 때 오프셋이라는 숫자가 붙게된다. Producer가 데이터를 넣는 속도가 Consumer가 가져가는 속도보다 빠르다면 👉 Producer가 넣은 데이터의 오프셋과 Concumer가 가져간 데이터의 오프셋에 차이가 발생한다. 이것이 Consumer lag이다.

• lag 숫자를 통해 해당 토픽에 파이프라인으로 연계되어 있는 Producer, Consumer 상태 유추가 가능
  • 주로 Consumer 상태에 대해 볼 때 사용

만약 여러 파티션이 존재한다면❓ 한개의 토픽에 여러 파티션이 존재한다면 여러 lag가 존재하며, 그 중 높은 숫자의 lag를 records-lag-max라고 부른다.

6. 컨슈머 랙 모니터링 애플리케이션, 카프카 버로우(Burrow)

Cusumer lag 모니터링을 도와주는 독립적인 애플리케이션

아래와 같은 3가지 큰 특징이 존재한다 : ➡️ 멀티 카프카 클러스터 지원 카프카 클러스터가 여러개라도 Burrow 한개만 실행해서 연동한다면 카프카 클러스터들에 붙은 컨슈머의 lag를 모두 모니터 가능

➡️ Sliding window를 통한 Consumer의 status 확인 status를 'ERROR', 'WARNING', 'OK'로 표현 WARNING: 데이터가 일시적으로 많아져 프로듀서 offset이 컨슈머 offset보다 더 빠르게 증가 ERROR: 데이터의 양이 많은데 컨슈머가 다 가져가지 못하는 경우

➡️ HTTP api 제공 response 받은 데이터를 시계열DB 같은 곳에 저장하는 application을 만들어서 사용할 수도 있음

7. 카프카, 레빗엠큐, 레디스 큐의 차이점

메시징 플랫폼이라고 부르는 것들은 두가지로 나뉜다. ✔️ 메시지 브로커 데이터를 보내고 처리하고 삭제한다. ex) 레빗엠큐, 레디스 큐

✔️ 이벤트 브로커 데이터 처리 후 삭제하지 않고 이벤트 브로커의 큐에 저장한다. ex) 카프카, AWS의 키네시스

• 단일 진실 공급원으로 사용 가능
• 장애가 발생했을 때 장애가 일어난 시점부터 처리 가능
• 많은 양의 실시간 데이터를 효과적으로 처리

⚠️이벤트 브로커는 메시지 브로커로 역할을 할 수 있지만 반대는 불가하다.

우리 팀은 일반적인 MVC 구조로 수강신청 서비스를 개발했다.

사용자는 로그인한 뒤, 바로 수강신청 API를 호출하는 방식이었다. 처음엔 잘 작동했지만 JMeter 테스트에서 수천명이 동시에 접속할때 CPU와 DB 커넥션 풀이 빠르게 고갈되었고 서버는 병목 상태에 빠져 오류율이 컸다.

💡가장 먼저 든 생각은 “일단 한 번에 들어오지 않도록 막자”였다. 단순하게 생각하면, 입장할 수 있는 인원을 정해두고 그 외의 사람은 기다리게 하면 된다. 그렇다면 누가 기다려야 하고 누가 들어올 수 있는지 판단하는 서버가 따로 필요해진다.

🔽 그래서 수강신청 서버와는 별도로 대기열 서버를 구성하기로 했다.

2. 대기열 시스템 도입

기능을 나누면 아래와 같다.

• 대기열 서버 : 사용자 순서 관리 및 입장 여부 판단 담당
• 수강신청 서버 : 자리 발생 시 대기열 서버에게 알림, 실제 수강신청 DB 처리 담당

💡그런데 한가지 의문점이 들었다. 그럼 입장 가능하다는 건 사용자에게 어떻게 알려주지❓ 클라이언트가 아래와 같이 대기열 시스템에 일정한 주기로 계속 물어보면 되지 않을까?

“지금 들어가도 되나요?” "지금은요?”

그게 바로 Polling 방식이었다.

polling 방식 적용 후 아키텍처는 위와 같이 바뀌었다. 자세한 로직 🔽

3 Polling 방식 적용

🌟 내부 로직 흐름

1. 클라이언트 대기열 진입 클라이언트는 POST /join API를 통해 대기열에 진입한다. 서버는 토큰 기반으로 사용자 정보를 생성해 큐에 저장한다. 사용자에게 현재 대기 순번을 응답한다.

2. 상태 확인 (Polling) 클라이언트는 GET /{uuid} API를 일정 주기로 호출해 자신의 상태를 확인한다. 서버는 WAITING 또는 ALLOWED 상태와 남은 순번을 반환한다. 클라이언트는 상태가 ALLOWED가 될 때까지 polling을 계속한다.

3. 빈자리 발생 시 수강신청 서버 → 대기열 서버 알림 수강신청 서버는 빈자리를 감지하면 POST /notify API를 호출해서 앞 순서 n명의 사용자에게 입장 허용 요청을 보낸다. 대기열 서버는 해당 인원을 ALLOWED 상태로 바꾼다.

4. ALLOWED 사용자 로그인 ALLOWED 상태가 된 사용자만 수강신청 서버에 로그인할 수 있다. 로그인 시 해당 사용자는 큐에서 제거된다.

🔍 내부 구성 요약

📘 API 요약

4. JMeter 테스트 결과

우리는 100명부터 10,000명까지 다양한 시나리오를 구성해 총 4가지 상황에서 부하 테스트를 진행했다. 📌 각 시나리오에 대한 상세 설명은 아래 글에 정리되어 있다. 🔗 시나리오 설명 보러가기

대기열 시스템 도입과 Polling 방식을 적용한 현재 아키텍처는 이전 구조와 비교했을 때 오류율이 눈에 띄게 감소했다.

동시 5,000명 접속 시나리오에서의 변화를 예로 들어보겠다.

📉 MVP 초기 구조 vs Polling 도입 후 오류율

시나리오1

시나리오2

시나리오3

시나리오4

위 결과를 보면

• Polling은 사용자가 ALLOWED가 될 때까지 계속 요청하기 때문에 표본 수가 많은것을 볼 수 있고 그 결과 정상적으로 많은 요청을 처리할 수 있는것으로 판단된다.
• 또한 대기열 도입으로 부하도 줄었다는것을 확인할 수 있다.

😲 평균적으로 약 80% 이상 오류율이 감소했다. 대기열 도입과 polling 적용 후 안정성 올라갔다는 걸 수치로 확인할 수 있었고 그 수치는 엄청난 차이였다.

🎯 마무리

우리 팀은 처음부터 대기열 시스템 도입과 polling을 쓰려고 했던게 아니다. 수강신청 서버가 트래픽을 감당하지 못하고 터지는 걸 경험하면서

• 👉 "모두가 한 번에 들어오지 않게 하려면 어떻게 해야 하지?"라는 고민에서 대기열을 도입하게 되었고
• 👉 "입장 가능 여부를 사용자에게 어떻게 알릴까?"라는 물음 끝에 Polling 방식이 자연스럽게 도출되었다.

❌ 물론 완벽한 구조는 아니다. 서버가 반복적으로 요청을 받아야 하기에 리소스가 소모되고 실시간성도 다소 부족하다. 그래서 이 방법말고 회의를 통해 나온 다른 후보의 방법들도 사용해보려고 한다.

이번에 수강신청 시스템을 구현하면서 가장 먼저 한 일은 코드를 짜는 것이 아니라 로직을 플로우차트로 그려보는 것이었다.

이 차트를 먼저 만들고 나니 구현이 훨씬 쉬워졌다. ✔️ 무엇을 언제 검사해야 하는지, 예외는 어디에서 발생할 수 있는지, 그리고 트랜잭션의 시작과 끝을 어디에 둘 것인지가 명확해졌다. ✔️ 특히 락 타임아웃, DB 좌석 확인, 트랜잭션 경계처럼 헷갈릴 수 있는 부분도 미리 체크할 수 있어서 실수 없이 구현할 수 있었다.

🔐 DB 비관적 락

📌 수강신청의 본질: 경쟁과 충돌

수강신청은 단순히 "누가 먼저 클릭했느냐"의 싸움이 아니다. 수십 명, 수백 명이 같은 강의를 동시에 신청하기 때문에 시스템 내부에서는 굉장한 충돌이 발생한다.

이런 상황에서 가장 중요한 건 바로 정합성(일관성)이다. 강의 정원이 40명인데 동시에 41명이 들어오면 누군가는 잘못 등록되는 것이다. 이걸 막기 위해 DB 수준에서의 동시성 제어가 필요했다.

그래서 선택한 방법이 바로 DB 비관적 락 (Pessimistic Lock)이다.

💡 왜 락이 필요한가? 예를 들어, A와 B가 동시에 같은 강의를 신청한다고 하자. 두 요청이 거의 같은 시점에 DB에서 "현재 정원이 39명"인 걸 확인하고, 동시에 1명을 추가해 41명이 되면 어떻게 될까? 시스템은 데이터 무결성 오류를 일으키게 된다.

이 문제를 방지하려면 동시에 같은 데이터를 읽는 순간부터 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 막아야 한다.

📢 낙관적인 락(Optimistic Lock)을 쓰지 않은 이유

• 낙관적 락은 데이터를 읽을 땐 그냥 읽고, 쓰기 시점에 버전 정보를 비교해서 다른 트랜잭션이 변경했는지 확인한다. 충돌이 감지되면 예외를 던지거나, 재시도 로직이 필요하다.
• 수강신청에서 낙관적 락을 사용하면 충돌이 자주 발생하고, 그때마다 예외 처리나 재시도 로직을 추가로 구현해야 한다.
• 즉, 락은 가볍지만 로직은 더 복잡해진다.

반면, 비관적 락(Pessimistic Lock)은 충돌 자체를 원천 차단하는 방식이다. 한 사용자가 특정 강의 데이터를 조회하고 수정하려 할 때, 다른 사용자가 해당 데이터를 동시에 수정하지 못하도록 DB가 직접 막아준다.

수강신청처럼 정합성이 매우 중요한 작업에서는 충돌을 감지하고 복구하는 것보다 애초에 충돌이 발생하지 않도록 막는게 훨씬 안전하고 단순하다. 그래서 이번 구현에서는 비관적 락을 선택하게 됐다.

** 🔽 비관적 락 적용** JPA에서 제공하는 @Lock 애너테이션을 통해 PESSIMISTIC_WRITE 락을 걸었다. 아래는 실제 사용한 코드다.

🔺CourseReader.java

public Optional<Course> readWithPessimisticLock(Long courseId) {
    return courseRepository.findWithPessimisticLock(courseId);
}

🔺CourseRepository.java

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT c FROM Course c WHERE c.id = :courseId")
Optional<Course> findWithPessimisticLock(@Param("courseId") Long courseId);

이 코드는 해당 강의에 대해 트랜잭션이 종료될 때까지 다른 트랜잭션이 이 강의 데이터를 수정하거나 읽지 못하게 막는 역할을 한다.

PESSIMISTIC_WRITE 락은 쿼리 실행 시점에 DB 레벨에서 exclusive lock을 걸고 트랜잭션이 끝나기 전까지 다른 요청은 대기 상태로 들어간다. 만약 락을 기다리는 시간(timeout)이 초과되면 예외가 발생한다.

🧨 테스트 코드

이 락이 실제로 동시성 문제를 잘 막아주는지 확인하기 위해 100명이 동시에 40명 정원의 강의를 신청하는 시나리오를 테스트 코드로 작성했다.

assertEquals(40, successCount.get(), "정원이 40명이므로 40명만 성공해야 함");
assertEquals(60, failCount.get(), "100명 중 60명이 실패해야함");
assertEquals(40, course.getParticipant(), "Course의 participant 필드도 40이어야 함");

이 테스트를 통해 동시에 요청을 보내도 정확히 40명까지만 수강에 성공하고 나머지는 모두 실패하는 걸 확인할 수 있었다.

또한 System.out.println("실패한 studentId: ...") 로그를 통해 실제로 어떤 사용자들이 실패했는지도 체크할 수 있어 디버깅에 도움이 됐다.

➡️ 추후에는 Redis 락으로?

현재는 DB 락만으로도 코드를 구현했지만, 우리 서비스는 만명까지 테스트하는 것을 목표로 두고 있기 때문에 수강 인원이 수천 명을 넘기 시작하면 또 다른 문제가 생길것이다.

DB는 락을 처리하면서 성능 저하가 올 수 있고 락 대기 시간이 길어지면 타임아웃이 잦아질 수 있다.

그래서 장기적으로는 Redis 기반의 분산 락을 도입하는 것을 고려하고 있다.

이 방법을 쓰면 DB가 아닌 메모리 기반에서 빠르게 락을 제어할 수 있고 분산 서버 환경에서도 동일한 락을 공유할 수 있다.

물론 도입 자체는 단순하지 않지만 장기적으로 봤을 때 확장성 면에서는 더 유리할것이다.

💡 느낀 점

• 설계 없이는 절대 안정적인 시스템을 만들 수 없다.
• 무작정 코드를 짜기보다는 플로우차트를 먼저 그려보자.
• DB 락은 강력한 도구다. 그러나 상황에 따라 다르게 선택해야 한다.
• 실전에서는 테스트 코드만으로는 부족할 수 있다. 시뮬레이션을 통한 예외 확인도 병행해야 한다. -> JMeter 도입

수천 명 이상이 동시에 몰리는 수강신청 상황에서 시스템이 다운되지 않고 얼마나 잘 버티는지, 특히 제한된 자원(t3.large) 환경에서 얼마만큼의 트래픽을 처리할 수 있는지를 보기 위해 이번 테스트를 진행햇다.

👉이 시스템은 다음과 같은 특성이 있다:

• 짧은 시간 내 폭발적인 접속
• 실시간 좌석 정보와 동기성 중요
• 백엔드 성능이 느려지면 사용자 불신이 직접적으로 이어짐

👉 테스트 아키텍처

• 백엔드: Spring Boot
• 웹 서버: Nginx
• DB: Amazon RDS (MySQL)
• 캐시: Redis (후속 도입 예정)
• 메시지 브로커: Kafka (후속 도입 예정)
• 서버 인프라: EC2 t3.large (2vCPU, 8GiB RAM)
• 테스트 도구: Apache JMeter + Puppeteer (브라우저 기반 시뮬레이션)

이번 글은 MVP 구조에서의 테스트만 다루며 이후 보완된 단계는 별도 포스트로 기록할 예정이다.

📢 테스트의 성능 측정 결과는 JMeter에서 수집된 데이터를 기반으로 HTML 리포트로 시각화해 확인했다. 각 요청별 응답시간 분포, 실패율, TPS, 네트워크 전송량 등 지표를 정량적으로 비교할 수 있었다. 아래는 실제 리포트 시각화 예시 캡처 이미지이다.

2. 시나리오 구성

테스트는 총 6가지 인원 케이스(100 / 1,000 / 3,000 / 5,000 / 7,000 / 10,000명)로 나누어 수행했고, 아래 5가지 핵심 시나리오를 중심으로 구성했다:

• ENROLL_1: 로그인 유지 부하
• ENROLL_2: 특정 교양 강의 신청 집중
• ENROLL_3: 서로 다른 전공 그룹이 각각 하나의 전공 강의 신청
• ENROLL_4: 3조건에서 신청 -> 취소 반복
• ENROLL_5: 다수 전공 그룹이 다수 강의에 대한 분산 신청

3. 실험별 상세 분석

100명~1,000명까지는 비교적 안정적이었지만 3,000명 이상부터 502 Bad Gateway 오류가 급증했고, 10,000명 접속 시 실패율은 83.54%에 달했으며 대부분 Timeout 또는 서버 내부 오류였다.

502는 Spring Boot 백엔드가 응답을 제때 주지 못해 Nginx가 대신 에러를 반환한 것으로 500 오류는 내부 Thread Pool 포화 혹은 HikariCP 커넥션 부족이 원인으로 보였다.

➡️ Nginx worker_connections 변화

Nginx에서 worker_connections란? 클라이언트의 요청을 처리하는 동시 연결 수를 조절하는 값이다. 이 숫자가 작으면 많은 유저가 몰릴 경우 요청이 차단되거나 지연된다.

• worker_connections 값을 768 → 4096으로 증가시키며 테스트
• 결과: 502 오류율은 점진적으로 감소했지만 전체 실패율은 91~93%로 유사함
• 이유: Nginx 입구는 넓어졌지만 백엔드(Spring+DB) 병목은 여전했기 때문

📌 정리하면, Nginx 튜닝은 효과가 있지만 입구만 뚫린 상태로 내부 문제는 여전했다.

➡️ Spring Thread Pool 실험

Thread Pool이란? 애플리케이션에서 동시에 여러 요청을 처리할 수 있도록 해주는 작업 스레드 모음이다. 너무 작으면 처리 병목이 생기고, 너무 크면 시스템 자원과 충돌한다.

• Thread Pool 크기를 200 → 300 → 400으로 늘려가며 평균 응답 시간, TPS(초당 처리 수), CPU 점유율, 실패율을 측정
• 결과: Thread 수 증가에도 불구하고 평균 응답시간은 늘고 TPS는 감소함
• 이유: Spring Boot 애플리케이션 내부 Thread가 동시 처리할 수 있는 요청을 늘어났지만, DB 커넥션 풀이 부족해 Thread는 대기만 하게 됨

📌 결론: Thread만 늘리면 오히려 병목 심화됨 → 반드시 DB Connection Pool과 함께 조정해야 함

➡️ DB 커넥션 풀 (HikariCP) 실험

DB 커넥션 풀(HikariCP)이란? DB와 연결할 수 있는 커넥션들을 미리 만들어 풀(Pool) 형태로 관리하는 구조다. 필요할 때 커넥션을 즉시 꺼내 쓸 수 있어 빠르고 효율적이다.

• active 커넥션: 현재 DB와 연결되어 사용 중인 커넥션 수
• idle 커넥션: 아직 사용되지 않고 대기 중인 커넥션 수
• waiting: 커넥션을 받기 위해 대기 중인 요청 수
• Pool size = 10일 때
  • Active 10 / Idle 0 / Waiting 190 (타임아웃 다수 발생)
• Pool size = 100일 때
  • Active 99 / Idle 1 / Waiting 6 (안정적 처리 가능)

커넥션 풀이 부족하면 Thread는 살아 있어도 DB 연결을 못 받아 대기 상태로 빠지고 이로 인해 TPS 하락, 응답 시간 증가, 502/500 오류 증가로 이어졌다.

📌 결론: 적절한 커넥션 풀 확보만으로도 전체 시스템 안정성이 비약적으로 향상됨

4. 요약

• Thread만 늘리는 방식은 오히려 지연을 초래했고 DB와 함께 튜닝해야 했다
• Nginx 튜닝은 입구 처리량은 높였지만 백엔드 병목 해결에는 역부족이었다

🌟 결론적으로 현재 구조(MVP)에서는 3,000명 이상의 동시 접속에서 시스템 안정성 확보가 어렵다는 것을 실험으로 확인했고 비동기 구조 도입 없이는 이 한계를 넘기 어렵다고 판단했다.

Spring JPA를 처음 배우면 대부분 @Query를 쓰거나 findByXXX() 같은 메서드 네이밍 전략을 사용해서 데이터를 조회한다. 이때 사용하는 쿼리 언어가 JPQL(Java Persistence Query Language)이다.

JPQL은 SQL처럼 생겼지만, 테이블이 아닌 엔티티를 대상으로 한 객체 지향 쿼리이다.

@Query("SELECT c FROM Course c WHERE c.department = :dept AND c.grade = :grade")
List<Course> findByDepartmentAndGrade(String dept, int grade);

⚠️ 그런데 문제는

• 문자열 기반 : 쿼리를 " " 안에 문자열로 작성해야 해서 오타가 나도 컴파일 타임에 알 수 없음
• 런타임 오류 : 잘못된 필드명을 써도 에러는 실행 시점에 발생함
• 조건문이 많을 때 : if문을 여러번 사용해야하고 코드가 복잡해짐 특히, 동적 필터 기능이 많아질수록 JPQL은 구조적으로 한계에 부딪히게 된다.

2. QueryDSL이란?

Java 코드로 SQL처럼 쿼리를 작성할 수 있도록 도와주는 프레임워크

즉! 우리가 직접 문자열로 SQL을 쓰는 것이 아니라, 타입 안정성이 보장된 Java 메서드 체이닝 방식으로 쿼리를 작성하는 도구이다.

• 타입 안정성 : 컴파일 타임에 필드 오타를 체크할 수 있음
• IDE 자동완성 : 엔티티 기준으로 쿼리 작성 시 자동완성 지원
• 동적 쿼리 : 조건을 메서드로 조립하여 동적으로 where절 생성 가능

❓그럼 QueryDSL은 어떻게 동작할까❓ QueryDSL은 내부적으로 Q타입 클래스를 자동으로 생성한다. 예를 들어 Course라는 엔티티가 있으면 QCourse라는 클래스를 만든다. 이 Q클래스는 빌드할때 Gradle의 annotationProcessor를 통해 생성되고 이 객체를 통해 타입 안전성 있는 필드를 사용할 수 있는 것이다.

public class QCourse extends EntityPathBase<Course> {
    public final StringPath name = createString("name");
    public final NumberPath<Integer> grade = createNumber("grade", Integer.class);
    ...
}

위는 Q타입 클래스 예시이다. QCourse course = QCourse.course라고 선언하면 이 클래스 안에 있는 필드들을 course.name, course.grade처럼 타입 안전하게 사용할 수 있다.

3. 기존 프로젝트 코드 방식

➡️ 모든 강의 조회

< JPQL 없이 직접 조회 + 반복 로직> 처음에는 아래와 같이 모든 강의를 조회하고, 각각 시간 정보를 별도로 불러오는 구조였다.

public List<CourseListRes> getCourseList() {
    List<Course> courses = courseReader.findAllCourses(); // 전체 강의 조회

    return courses.stream()
        .map(course -> {
            List<CourseTime> times = courseReader.findCourseTimesByCourseId(course.getId()); // 강의별 시간 조회
            String time1 = CourseTimeFormatter.formatTime(times, 0);
            String time2 = CourseTimeFormatter.formatTime(times, 1);
            return CourseListRes.of(course, time1, time2);
        })
        .toList();
}

⚠️ 문제점

• 강의가 100개면 -> 시간조회 쿼리 100번 발생 -> N+1 문제 발생
• 필터링 기능(전공, 학년, 과목코드 등)이 들어가면 조건문(if문) 난무 -> 유지보수 어려움

➡️ 강의를 신청한 인원 조회

< JPQL 사용 >

@Query("SELECT new com.allclearwas.domains.enrollment.dto.CourseEnrollmentCountDto(e.course.id, COUNT(e)) "
        + "FROM Enrollment e WHERE e.course.id IN :courseIds GROUP BY e.course.id")
    List<CourseEnrollmentCountDto> countByCourseIds(@Param("courseIds") List<Long> courseIds);

⚠️ 문제점

• JPQL은 문자열 기반이라 오타나 필드명이 바뀌어도 컴파일 타임에 잡히지 않음
• DTO 생성자 기반이라 필드 순서 변경 시 오류 가능성 있음
• 추후 동적 조건이 생기면 쿼리 문자열을 다시 조립해야 하므로 유연하지 않음

4. QueryDSL로 리팩토링한 코드

📌 설정

@Configuration
public class QuerydslConfig {
    @PersistenceContext
    private EntityManager em;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(em);
    }
}

이 설정은 QueryDSL에서 쿼리를 생성할 때 사용하는 핵심 도구인 JPAQueryFactory를 빈으로 등록한다.

• EntityManager는 JPA의 모든 쿼리 동작을 관리하는 핵심 객체
• JPAQueryFactory는 EntityManager를 기반으로 QueryDSL 쿼리를 만들어주는 역할

이 설정을 통해서 QueryDSL을 구현하는 클래스에서 queryFactory를 주입받아 쿼리를 작성할 수 있게된다.

➡️ 모든 강의 조회

queryFactory
    .select(...)
    .from(course)
    .join(course.courseInfo, courseInfo)
    .where(
        equalsIfNotNull(courseInfo.category, request.category()),
        equalsIfNotNull(courseInfo.grade, request.grade()),
        equalsIfNotNull(courseInfo.department, request.department()),
        equalsIfNotBlank(course.courseCode, request.code())
    )
    .fetch();

• select()에는 CourseListDao 생성자에 필요한 정보만 골라 조회
• selectTimeString()으로 서브쿼리를 이용해 시간 정보를 2줄만에 깔끔히 처리
• null 조건은 자동으로 제거되므로 if문 필요 없음

private Expression<String> selectTimeString(QCourseTime time, QCourse course, int offset) {
    return JPAExpressions.select(
            Expressions.stringTemplate(
                "concat({0}, ' ', {1}, '~', {2})",
                time.dayOfWeek.stringValue(),
                time.startTime.stringValue(),
                time.endTime.stringValue()
            )
        )
        .from(time)
        .where(time.course.eq(course))
        .orderBy(time.id.asc())
        .offset(offset)
        .limit(1);
}

• 강의 하나당 time1, time2만 뽑아서 시간 문자열을 생성하고, 메인 강의 조회 쿼리 안에 서브쿼리 형식으로 조립해서 한 번에 처리한다.
• 즉! 강의가 100개든 1000개든 추가적인 쿼리 실행은 발생하지 않고,
• 메인 쿼리 1개 + 시간 정보 서브쿼리 2개(각 time1, time2)*만 QueryDSL 내부적으로 작성되어 쿼리는 실제로 한 번에 실행된다.

➕ JPAExpressions? QueryDSL에서 서브쿼리(하위 쿼리)를 작성할 수 있도록 도와주는 클래스 🔺 기존 SQL에서 다음과 같은 서브쿼리를 작성한다고 하면: SELECT (SELECT name FROM student WHERE id = 1) AS studentName

🔺 아래와 같이 똑같이 표현할 수 있다:

JPAExpressions.select(student.name)
    .from(student)
    .where(student.id.eq(1))

❓ 그럼 애초에 JPQL로 조인하면 안되는가 ❓ 조인 자체는 JPQL로도 가능하지만 JPQL로도 조인해서 해결할 수 있는 건 '1:1' 또는 '다대일 관계'의 단순 조회일 뿐이다. 우리 프로젝트와 같이 Course와 CourseTime이 1:N 관계이고, 시간 2개만 선택하고 싶은 경우에는 여러 문제가 발생한다.

➡️ 강의를 신청한 인원 조회

queryFactory
    .select(Projections.constructor(CourseEnrollmentCountDao.class,
        enrollment.course.id,
        enrollment.count()))
    .from(enrollment)
    .join(enrollment.course, course)
    .where(course.id.in(courseIds))
    .groupBy(course.id)
    .fetch();

• 특정 강의 목록(courseIds)에 대해 몇 명이 신청했는지 집계하는 쿼리
• count()와 groupBy()를 사용하여 쿼리 한 번에 수강인원 수를 조회
• DTO를 바로 생성자 방식으로 반환하여 불필요한 변환 로직 생략

📢 연관관계란?

DB 테이블은 서로 연결되어 있고, 이 연결을 관계(연관관계)라고 부른다. 예를 들어, 강의(course)와 학생(student)이 있을 때 "한 명의 학생이 여러 강의를 수강할 수 있다"면 1:N 관계(일대다 관계)인 것이다. 이런 관계를 코드 안에서도 표현해줘야 하는데 JPA에서는 @OneToMany, @ManyToOne, @OneToOne, @ManyToMany 같은 어노테이션을 사용하여 관계를 표현한다.

🌟주의 연관관계를 이해할 때 가장 헷갈리는 부분은 코드에서는 객체끼리 연결되고, DB에서는 테이블끼리 외래키(FK)로 연결된다는 점이다. JPA는 이 둘을 자동으로 매핑해주지만 항상 “객체는 참조”, “DB는 외래키”라는 관점을 구분해서 바라보아야한다.

📢 단방향 vs 양방향 연관관계

👉 단방향 연관관계

한 쪽에서만 다른 객체를 참조하는 방식 ex) CourseTime은 Course만 알고 있고, Course는 CourseTime을 모름

//CourseTime
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "course_id")
private Course course;

👉 양방향 연관관계

서로 참조하는 구조 ex) CourseTime도 Course를 알고, Course도 CourseTime 목록을 가지고 있음

//Course
@OneToMany(mappedBy = "course")
private List<CourseTime> courseTimes = new ArrayList<>();

Course에서도 CourseTime을 탐색할 수 있어서 단방향보다 더 많은 정보를 가져올 수 있지만, 주의해야할 것들이 있음 (아래에 🔽)

⚠️ 양방향 연관관계는 주인 꼭 지정!!

양방향 연관관계를 만들면 JPA가 헷갈릴 수 있기 때문에, 둘 중 한 쪽을 '주인'으로 정해야 한다. 연관관계의 주인은 실제로 외래키를 갖고 있는 객체이다. mappedBy는 주인이 아닌 쪽에서 사용하는 속성으로, "나는 반대편 필드를 따라갈게"라는 뜻이다. 그래서 mappedBy = "course"는 CourseTime 엔티티 안의 course 필드를 기준으로 관계를 맺는다는 뜻이다. 이걸 정하지 않으면 JPA는 관계를 두 번 맺으려고 하고 쓸데없는 쿼리가 날아가게된다.

➕식별관계 vs 비식별관계

추가로 DB 설계 쪽 얘기를 잠깐해보겠다. 우리가 JPA로 연관관계를 맺으면, 결국 DB에도 테이블 간 관계가 생기는데 이걸 식별관계와 비식별관계로 나눌 수 있다.

📌 식별관계

자식 테이블이 부모 테이블의 기본키(PK)를 포함해서 자기 PK를 만드는 경우 즉, 부모 없이는 자식이 존재할 수 없다. 잘 쓰면 정합성이 좋아지지만 JPA에서는 복잡해져서 실무에서는 많이 쓰지 않는다고 한다.

📌 비식별관계

자식 테이블이 자기만의 PK를 갖고, 부모의 PK는 외래키로만 사용 우리 프로젝트의 CourseTime → Course 관계도 여기에 해당한다.

📘 Course
 └─ 🔑 course_id (PK)

📗 CourseTime
 ├─ 🔑 course_time_id (PK)
 └─ 🔗 course_id (FK, 비식별관계)

이렇게 설계하면 구조가 단순하고, 나중에 확장하거나 수정하기도 쉽다. 그래서 JPA에서는 대부분 비식별관계로 설계하는게 기본이라고 한다.

❗ 양방향 연관관계, 실제로 겪은 문제

• 처음에는 Course와 CourseTime 사이를 양방향으로 설정했다. 수강신청한 강의의 시간을 가져오려면 Enrollment -> Course -> CourseTime 순으로 접근해야한다고 생각했기 때문이다.
• 이 구조는 보기에는 편하지만 문제가 생기기 시작한 건 조회 쿼리에서였다.CourseTime을 단순히 조회하려고 했을 뿐인데 예상치 않게 Course까지 함께 불러오는 쿼리가 나갔다. (즉시 로딩처럼 작동) 이로 인해 불필요한 join과 데이터 로딩이 발생했다.
• 게다가 Course에서 course.getCourseTimes()를 호출하는 경우, 강의마다 수업 시간이 여러 개 있을 때 반복적으로 지연 로딩이 일어나면서 N+1 문제로 확산될 수 있다는 점도 고려해야 했다.
• 결국 Course 쪽에 있던 List<CourseTime>을 제거하고, 필요한 경우에만 JPQL의 fetch join을 통해 명시적으로 조회하도록 구조를 변경했다.

💡 단방향으로도 충분할 때가 많다 JPA는 단방향만으로도 기능을 구현할 수 있는 경우가 많다. 화면에서 역방향으로 탐색할 일이 없다면 굳이 양방향으로 만들어 성능이 떨어지는 상항을 만들지 않아야겠다는 생각이 들었다.

🧭 LAZY vs EAGER/ Fetch Join

연관된 객체를 언제 불러올지도 중요한 설정이다.

👉 LAZY (지연 로딩)

• 객체를 처음 조회할 땐 연관 객체를 가져오지 않는다.
• 진짜 필요할 때(DB를 터치할 때) 불러온다.
• 기본값으로 많이 사용된다.

  👉 EAGER (즉시 로딩)

• 처음 객체를 가져올 때 연관 객체도 바로 같이 불러온다.
• 객체가 여러 개 연결돼 있다면 성능이 급격히 떨어질 수 있다. ex) CourseTime이 여러개일 경우

  👉 Fetch Join

• LAZY로 설정해도 JPQL에서 직접 join fetch를 써서 한 번에 가져올 수 있다.
• 원하는 상황에서만 불러올 수 있어서 성능 튜닝에 좋다.
• SELECT ct FROM CourseTime ct JOIN FETCH ct.course

이번에 수강신청 현황 조회 기능을 리팩토링하면서 '편하려고 만든 연관관계가 오히려 나중에 발목을 잡을 수 있다'는 걸 확실히 느꼈다. 앞으로는 연관관계를 만들 때 무조건 편한 쪽보다 정확하고 단순한 쪽을 먼저 고려하는 습관을 들여야겠다.

Github 수강신청현황조회 PR

1. Hello 서블릿 등록 및 테스트

서블릿은 톰캣 같은 웹 애플리케이션 서버를 직접 설치하고, 그 위에 서블릿 코드를 클래스 파일로 빌드해서 올린 다음, 톰캣 서버를 실행하면 된다. 👉 번거롭다! 👉 스프링 부트는 톰캣 서버를 내장하고 있어서 톰캣 서버 설치 없이 편리하게 서블릿 코드를 실행할 수 있다.

@ServletComponentScan : 스프링 부트가 서블릿을 직접 등록해서 사용할 수 있도록 지원

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String username = request.getParameter("username");
        response.setContentType("text/plain");
        response.setCharacterEncoding("UTF-8");
        response.getWriter().write("hello " + username);
    }
}

브라우저에서 http://localhost:8080/hello?username=world를 호출하면 hello world가 출력된다.

2. HttpServletRequest - 요청 객체

서블릿은 HTTP 요청메시지를 파싱하여 HttpServletRequest 객체에 담아 개발자에게 제공한다. 즉, 개발자는 이 객체를 사용하여 요청 메시지를 편리하게 조회할 수 있다.

➡️ 주요 기능

• 요청 메서드(GET/POST), URI, 프로토콜, 쿼리스트링 등 조회
• 헤더, 파라미터, 쿠키, Body 등 다양한 정보 조회 가능
• 임시 저장소 기능 (setAttribute, getAttribute)
• 세션 관리 기능 (getSession())

➡️ HTTP 요청 메시지를 통해 서버로 데이터 전달하는 3가지 방법

1. GET - 쿼리 파타리터 2. POST - HTML Form 3. HTTP message body

📌 GET/POST

GET은 URL 쿼리 파라미터를 통해, POST는 메시지 바디에 데이터를 전달한다. 그러나 서버 입장에서는 둘 다 key=value 형식으로 같기 때문에 request.getParameter()로 동일하게 조회할 수 있다.

//단일 파라미터 조회
String username = request.getParameter("username");
//복수 파라미터 조회
String[] values = request.getParameterValues("username");

ex) http://localhost:8080/request-param?username=kim&age=20

• GET 요청: URL에 파라미터 포함
• POST 요청 (HTML Form): application/x-www-form-urlencoded

GET은 HTTP 메시지 바디를 사용하지 않아 content-type이 없지만, POST는 HTTP 메시지 바디에 해당 데이터를 포함해서 보내기 때문에 데이터가 어떤 형식인지 content-type을 지정해야한다. 이렇게 폼으로 데이터를 전송하는 형식을 application/x-www-form-urlencoded 라 한다.

참고로 request.getParameter()는 같은 이름의 파라미터가 여러 개 있을 경우 첫 번째 값만 반환한다. 모두 조회하려면 getParameterValues()를 사용해야 한다.

📌 HTTP message body

• HTTP API에서 주로 사용, JSON, XML, TEXT
• 데이터 형식은 주로 JSON
• POST, PUT, PATCH

➕ 단순 텍스트 (text/plain)

ServletInputStream inputStream = request.getInputStream();
String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

위와 같이 InputStream을 사용하여 Body에 담긴 순수 문자열을 직접 읽을 수 있다.

➕ JSON 파싱 (application/json)

ObjectMapper objectMapper = new ObjectMapper();
HelloData data = objectMapper.readValue(messageBody, HelloData.class);

JSON은 단순한 텍스트 형태로 전달되지만 이를 객체로 변환하려면 Jackson,Gson 같은 JSON 파싱 라이브러리가 필요하다. 스프링 부트로 Spring MVC를 선택하면 Jackson 라이브러리(ObjectMapper)를 제공한다.

이러한 방식은 모바일 앱이나 API 서버 통신처럼 메시지 바디에 JSON 데이터를 담아 전달할 때 주로 사용된다. 이때 주로 사용하는 HTTP 메서드는 POST, PUT, PATCH 등이다.

3. HttpServletResponse - 응답 객체

➡️ 주요 기능

• HTTP 응답코드 지정
• 헤더/바디 생성
• 편의 기능 제공 (Content-Type, 쿠키, Redirect)

📌 응답 상태 코드

response.setStatus(HttpServletResponse.SC_OK); // 200 OK

서블릿은 요청을 처리한 결과를 상태 코드로 표현한다. 200 OK 외에도 400 Bad Request, 404 Not Found 등의 상태 코드를 설정할 수 있다.

📌 헤더/바디 설정

//헤더
response.setContentType("application/json");
response.setCharacterEncoding("utf-8");

//바디
PrintWriter writer = response.getWriter();
writer.println("ok");

응답의 문자 인코딩을 명확히 지정하지 않으면 브라우저가 문자를 잘못 해석해 깨지는 현상이 발생할 수 있다. UTF-8 설정은 다국어 처리에서 특히 중요하다.

👉 위 예시처럼 단순 텍스트가 아닌 HTML or JSON 형태라면?

• HTML 응답
  • contextType을 text/html로 지정하고 바디는 아래와 같이 설정하면 된다.
  • java writer.println("<html>"); writer.println("<body>"); writer.println(" <div>안녕?</div>"); writer.println("</body>"); writer.println("</html>");
• JSON 응답
  • contextType을 application/json로 지정하고 바디는 아래와 같이 설정하면 된다.
  • java HelloData data = new HelloData(); data.setUsername("kim"); data.setAge(20); String result = objectMapper.writeValueAsString(data); response.getWriter().write(result);
  • Jackson 라이브러리가 제공하는 objectMapper.writeValueAsString()을 사용하면 객체를 JSON 문자로 변경할 수 있다.

📌 쿠키 / 리다이렉트

Cookie cookie = new Cookie("myCookie", "good");
cookie.setMaxAge(600);  //600초
response.addCookie(cookie);
response.sendRedirect("/home");

쿠키는 클라이언트에 데이터를 저장할 때 사용하며 setMaxAge()를 통해 유효 시간을 설정할 수 있다. sendRedirect()는 클라이언트를 지정한 URL로 리다이렉트시키는 메서드로 브라우저가 새로운 요청을 보내도록 유도한다.

더 자세한 코드는 깃허브 기록을 보자! https://github.com/MinjiSeo16/inflearnSpring/commits/main/mvc1

이번 글에서는 한이음 공모전에서 진행하고있는 수강신청 시스템 개발 시작 과정을 정리하려고 한다. 수강신청 서버는 특히 대용량 트래픽에 취약하기 때문에 '터지지 않는 시스템'을 만들자는 목표로 공모전 프로젝트를 시작하게되었다.

➡️ 기본 MVP

이 프로젝트는 처음부터 복잡한 기술 스택을 도입하기보다는, 기본 기능을 먼저 구현하고 부하 테스트를 통해 문제를 확인하여 점진적으로 개선해나가는 방식으로 진행하고자 한다. 우선, 아래는 이번 프로젝트에서 설정한 기본 MVP 기능이다.

➡️ 협업과 진행방식

• Slack
  • 실시간 커뮤니케이션 및 데일리 스탠드업 공유
  • 긴급 이슈나 장애 발생 시 신속한 대응
  • 논의된 사항 빠르게 기록 및 알림
• Confluence
  • 기술 설계와 구조 도식화 문서 작성 (아키텍처, API 명세, 회고 등)
  • 테스트 결과 및 병목 지점 정리
  • 스프린트 리뷰 및 피드백 기록
• Jira
  • 기능을 작은 단위 업무로 나눠 관리
  • 마일스톤 기반 작업 계획 수립 및 진행률 시각화
  • To Do → In Progress → Done 상태로 진행 상황 추적

아래는 실제 Jira 보드에서 수강신청 기본 기능을 Task 단위로 나누어 정리한 모습입니다.

🌟 목표 단위 중심의 애자일 전략

프로젝트를 진행할 때 ‘전체 기능을 한 번에 구현’하는 방식보다, 작은 단위로 쪼개어 빠르게 실현하고 반복적으로 개선하는 방식을 선택했습니다. 프론트와 백엔드가 각자 담당할 Task를 나눈 뒤, 매 스프린트마다 우선순위를 정해 협업하고 테스트하며 점진적으로 기능을 완성합니다.

• Epic(에픽)
  • 전체 목표 단위
  • 위 MVP 기반으로 작성
• User Story(사용자 스토리)
  • 사용자 중심 기능 정의
  • 실제 사용자의 행동 기반으로 표현 (사용자는 ~할 수 있다)
• Ticket(티켓)
  • 실제 개발 단위
  • GitHub 브랜치 네이밍도 티켓 키 기준으로 통일 (ex feature/QUEUE-52-login-api)

즉, 작게 만들고, 빠르게 적용하고, 반복적으로 개선하는 애자일 개발 전략을 따릅니다.

➡️ ERD

기능 구현에 앞서, 핵심 데이터 흐름과 테이블 간 관계를 먼저 정의했고, 그에 따라 설계된 주요 테이블 구조는 아래와 같다.

👉 테이블 간 관계 및 설계 의도 student ↔ student_policy (1:1 관계) → 한 학생마다 고유의 수강 정책이 존재하기 때문에 명확히 분리

student ↔ course_enrollment ↔ course (N:M 관계) → 수강 신청 로직에는 단순 연결 외에도 ✔ 중복 신청 방지 ✔ 시간 중복 체크 ✔ 신청 마감 여부 검증 등 복잡한 로직이 존재 → 이를 모두 처리하기 위해 중간 테이블을 중심으로 구조 설계

course ↔ course_time (1:N 관계) → 하나의 강의가 여러 요일/시간대에 개설될 수 있는 구조 → ex) 월/수, 화/목 각각 다른 시간대 강의

course ↔ course_info (N:1 관계) → 과목 자체에 대한 분류 정보(전공/교양, 학기 등)를 course_info에 따로 분리하여 필터링 성능을 높이고, 재사용 가능한 메타 정보로 활용

➡️ 서버 아키텍처

① 사용자 (Client) 사용자가 수강신청 버튼을 클릭하면 요청은 Spring REST API 서버로 전송

② Spring 서버 (Docker 컨테이너) 서버는 EC2 인스턴스 내 Docker 컨테이너에 배포되어 있음 수신된 요청을 처리하고 필요한 비즈니스 로직(중복 검사, 정원 제한 등)을 수행 이때 @Transactional 기반 트랜잭션 처리와 DB 레벨의 Lock을 통해 동시성 제어

③ RDS (MySQL) 검증을 통과한 신청 정보는 AWS RDS에 위치한 MySQL DB에 저장

➡️ 다음 단계

지금까지 수강신청 시스템의 기본 기능을 어떻게 설계하고 구현했는지 살펴보았습니다. 하지만 실제로 이 시스템이 수백 명, 수천 명의 동시 요청을 견딜 수 있을지는 아직 확인되지 않았습니다.

다음 단계에서는 JMeter를 활용해 부하 테스트를 진행하고, 어떤 시점에 병목이 발생하는지, 그 병목을 어떻게 개선할 수 있을지 구체적으로 분석해보려고 합니다.

단순히 잘 작동하는 것이 아니라 많은 사용자를 견디는 시스템으로 확장해나가는 과정을 기록할 예정입니다.

➡️ 웹 서버(Web Server)

• HTTP 기반으로 동작
• 정적인 리소스(HTML, CSS, JS, 이미지 등)를 클라이언트에게 제공
• ex) Nginx, Apache

단순히 요청받은 정적 파일을 그대로 응답해주는 역할이다.

➡️ 웹 애플리케이션 서버(WAS: Web Application Server)

• HTTP 기반으로 동작
• 동적인 데이터를 생성해 HTML 또는 JSON으로 응답
• 프로그램 코드를 실행해서 애플리케이션 로직 수행
• ex) Tomcat, Jetty

웹 서버 기능을 포함하고 애플리케이션 로직을 실행할 수 있는 서버이다.

➡️ WEB + WAS + DB 구성 실제 대규모 시스템은 웹 서버, WAS, DB가 각각 역할을 나누어 수행한다.

WAS + DB만으로 시스템 구성은 가능하지만 웹 서버는 정적 리소스를 제공하고 복잡한 처리는 WAS로 위임한다면 ❗WAS 과부하 우려가 줄고 ❗WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

2. 서블릿

서버는 HTTP 요청을 받으면 아래와 같이 처리해야할 업무가 매우 많다.

하지만 핵심은 초록색 박스가 의미있는 비즈니스 로직이라는 것이다. 이 업무를 대신해주는 것이 바로 서블릿이다.

👉 특징

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void service(HttpServletRequest req, HttpServletResponse res) {
        // 요청 처리
}

• urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행
• HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
• HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
• 개발자는 HTTP 스펙을 매우 편리하게 사용

👉 HTTP 요청, 응답 흐름

📌서블릿 컨테이너

• 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.
• 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
• 서블릿 객체는 싱글톤으로 관리된다.
  • So, 공유 자원은 주의해야한다.
  • 최초 요청 시 서블릿 객체를 생성하고 이후 모든 요청은 해당 객체를 재사용한다.
• 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.

3. 멀티 쓰레드

_* 쓰레드는 한번에 하나의 코드 라인만 수행하기 때문에 동시 처리가 필요하면 쓰레드를 추가로 생성해야한다. _

그럼 다중 요청 시 요청당 쓰레드를 생성해야할까❓ ❌ 아니다!

• 쓰레드 생성/제거 비용과 컨텍스트 스위칭 비용이 발생한다.
• 응답 속도가 느려진다.
• 많은 요청이 오면 CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.

➡️ 쓰레드 풀(Thread Pool)의 도입

• 필요한 쓰레드를 풀에 보관하여 필요할 때 꺼내어 사용하고 반납한다.
• 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. -> 톰캣은 최대 200개 기본 설정(변경 가능)
• 쓰레드 수가 초과되면 요청을 대기시키거나 거절할 수 있다.
• 쓰레드 생성/종료 비용이 절약되고 응답 시간도 빠르다.
• 최대치가 있어서 너무 많은 요청이 들어와도 안전하게 처리할 수 있다.

🌟 실무 Tip

• WAS의 주요 튜닝 포인트는 최대 쓰레드 (max thread) 수이다!
  • 이 값을 너무 낮게 설정하면 -> 동시 요청 많을 시 응답이 지연되고
  • 이 값을 너무 높게 설정하면 -> 동시 요청 많을 시 CPU, 메모리 리소스 임계점 초과로 서버 다운
• *장애 발생 시 *
  • 클라우드면 일단 서버부터 늘리고 이후에 튜닝
  • 클라우드가 아니면 열심히 튜닝

*‼️개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 되며 이 부분은 WAS가 처리한다는 것이 핵심이다. *

4. HTML, HTTP API, CSR, SSR

👉 정적 리소스

• 고정된 HTML 파일, CSS, JS, 이미지, 영상

👉 HTML 페이지

• 동적 HTML, JSP, 타임리프 등 서버에서 HTML을 동적으로 생성

👉 HTTP API

• HTML이 아니라 JSON 데이터를 주고받는 구조
• 다양한 시스템에서 호출 가능
  • 웹 브라우저에서 자바스크립트를 통한 HTTP API 호출
  • 앱 클라이언트
  • React,Vue.js 같은 웹 클라이언트
  • 서버 to 서버 (ex) 주문 서버 -> 결제 서버)

➡️ SSR (서버 사이드 렌더링)

• HTML 최종 결과를 서버에서 만들어 웹 브라우저에 전달
• 주로 정적인 화면에 사용
• 관련 기술 : JSP, 타임리프 -> 백엔드 개발자

➡️ CSR (클라이언트 사이드 렌더링)

• HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
• 주로 동적인 화면에 사용하고 웹 환경을 마치 앱 처럼 필요한 부분부분 변경 가능

5. 자바 웹 기술 역사

➕ 과거 기술

• 1997 서블릿 : HTML 생성이 불편
• 1999 JSP : HTML은 편리하나 비지니스 로직까지 너무 많은 역할 담당
• 서블릿, JSP 조합 MVC 패턴 사용 : 모델, 뷰 컨트롤러로 역할 나누어 개발
• 2000 MVC 프레임워크 춘추전국시대 : Spring MVC(과거버전), Struts 등

➕ 현재 기술

• *애노테이션 기반의 스프링 MVC 등장 *
• Spring Boot 등장 -> 서버 내장, Jar로 빌드 배포 단순화

➕ 최근 기술

• Web Servlet - Spring MVC
• Web Reactive - Spring WebFlux
  • 비동기 넌 블러킹 처리/ 최소 쓰레드로 최대 성능/ 함수형 스타일 개발의 장점
  • But, 난의도 매우 높고 RDS 지원 부족해 실무에서 거의 사용 X

➕ 뷰 템플릿 역사

• JSP: 느리고 기능 부족
• Freemarker, Velocity: 속도 문제 해결, 다양한 기능
• Thymeleaf
  • HTML 구조를 유지하며 뷰 템플릿 적용 가능
  • 스프링 MVC와 강력한 기능 통합
  • 최선의 선택이지만 성능은 프리마커, 벨로시티가 더 빠름

빈이 존재하는 생명 주기 범위를 지정하는 것이다.

스프링에서는 기본적으로 모든 빈이 싱글톤이다. 즉, 애플리케이션 시작 시 한 번만 생성되고 모든 의존 주입 시 동일한 인스턴스를 공유하게 된다. 그런데 이렇게 항상 같은 객체를 공유하는 것이 불편한 상황도 있다. 예를 들어, 매번 새로운 객체가 필요한 경우나 요청마다 다른 객체가 필요할 경우이다. 이럴 때 사용하는 개념이 바로 빈 스코프이다.

👉 스프링은 아래와 같은 스코프를 지원한다.

• 싱글톤 : 기본값. 컨테이너 시작~종료까지 1개의 인스턴스 유지
• 프로토타입 : 요청할 때마다 매번 새로운 인스턴스 생성
• 웹 관련 스코프:
  • request : 웹 요청마다 새로운 빈 생성
  • session : HTTP 세션마다 하나의 인스턴스 유지
  • application : 서블릿 컨텍스트 범위와 같은 스코프
  • websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프

👉 빈 스코프 지정하는 방법

@Component
@Scope("prototype")
public class HelloBean {}

또는 수동으로

@Bean
@Scope("prototype")
public HelloBean helloBean() {
    return new HelloBean();
}

2. 프로토타입 스코프

싱글톤과 달리 프로토타입(prototype) 스코프는 스프링 컨테이너가 매번 새로운 인스턴스를 생성해서 반환한다.

💡 동작 흐름

1. 스프링 컨테이너가 요청을 받으면 (프로토타입 빈을 생성하고 필요한 의존 관계를 주입 + 초기화)
2. 매번 새로운 객체를 생성하여 반환
3. 이후 이 객체에 대한 생명주기 관리는 스프링이 아닌 클라이언트가 책임 -> 따라서 @PreDestory 메서드도 호출되지 않음!!

@Scope("prototype")
static class PrototypeBean {
    @PostConstruct
    public void init() {
        System.out.println("init");
    }

    @PreDestroy
    public void destroy() {
        System.out.println("destroy");
    }
}

이렇게 작성하고 ac.getBean(PrototypeBean.class)을 2번 호출하면 서로 다른 인스턴스가 생성되어init()은 각각 호출되지만 destroy()는 호출되지 않는다. ‼️ 즉, 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.

3. 싱글톤 빈과 함께 사용시 문제점

아래 그림은 싱글톤 빈(clientBean)이 프로토타입 빈(PrototypeBean)을 주입받아 사용하는 구조를 보여준다.

1. clientBean이 생성될 때 프로토타입 빈이 한 번 주입
2. 클라이언트 A가 logic()을 호출하면 count는 1
3. 클라이언트 B도 같은 clientBean을 사용하므로 다시 호출 시 count가 2로 증가

⚠️ 싱글톤 빈은 생성 시점에만 의존성이 주입되기 때문에 프로토타입 빈이 사용 시마다 새로 생성되지 않고 처음 주입된 인스턴스를 계속 사용하게 된다. 즉, 프로토타입의 의미가 사라지는 것이다!

// 생략된 코드 동일하게 유지
ClientBean clientBean1 = ac.getBean(ClientBean.class);
int count1 = clientBean1.logic(); // count = 1

ClientBean clientBean2 = ac.getBean(ClientBean.class);
int count2 = clientBean2.logic(); // count = 2

프로토타입의 생명주기를 활용하고 싶다면 매번 새롭게 요청하는 방식으로 로직을 수정할 필요가 있다.

4. Provider

싱글톤 빈에서 프로토타입 빈을 사용할 때마다 새로 생성되게 하려면 가장 간단한 방법은 필요할 때 스프링 컨테이너에 직접 요청하는 것(DL)이다.

이는 의존관계를 외부에서 주입받는 것(DI)이 아니라 필요한 의존관계를 직접 찾는 것(Dependency Lookup)이다.

그런데 ApplicationContext 전체를 주입받는 방식은 스프링 컨테이너에 종속적인 코드가 되고 단위 테스트도 어려워진다.

1️⃣ ObjectProvider 사용 (스프링 제공)

@Autowired
private ObjectProvider<PrototypeBean> provider;

public int logic() {
    // 매번 새 인스턴스 반환
    PrototypeBean prototypeBean = provider.getObject(); 
    prototypeBean.addCount();
    return prototypeBean.getCount();
}

• 스프링은 지금 필요한 프로토타입 빈을 컨테이너에서 대신 찾아주는 즉 DL 역할만 하는 ObjectProvider를 제공한다
• provider.getObject()를 호출하는 시점에 스프링 컨테이너가 새로운 프로토타입 빈을 생성하여 반환한다.

2️⃣ JSR-330 Provider 사용 (자바 표준)

@Autowired
private javax.inject.Provider<PrototypeBean> provider;

public int logic() {
    PrototypeBean prototypeBean = provider.get();
    prototypeBean.addCount();
    return prototypeBean.getCount();
}

• 자바 표준 방식으로 다른 DI 컨테이너에서도 사용 가능하다.
• 단점은 별도 라이브러리 의존이 필요하다.
  • ex) javax.inject:javax.inject:1

_자바 표준과 스프링 기능이 겹치는 경우, 특별히 다른 컨테이너를 사용할 일이 없다면 스프링이 제공하는 기능을 사용하자!_

5. 웹 스코프와 프록시 사용

스프링에서는 웹 애플리케이션을 개발할 때 요청마다 새롭게 생성되어야 하는 객체가 필요할 때가 있다. 예를 들어, HTTP 요청마다 고유한 로깅 정보를 담고 싶은 경우이다. 이럴 때 사용하는 것이 바로 웹 스코프(Web Scope)이다.

_아래는 가장 많이 사용되는 request 스코프를 중심으로 설명한다._

✅ 예제 – 요청마다 고유한 로그를 남기고 싶다!

MyLogger라는 클래스를 만들어 요청마다 고유한 UUID를 생성하고 로그에 찍도록 설계한다.

@Component
@Scope(value = "request")
public class MyLogger {

    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("[" + uuid + "][" + requestURL + "] " + message);
    }

    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean created: " + this);
    }

    @PreDestroy
    public void destroy() {
        System.out.println("[" + uuid + "] request scope bean closed: " + this);
    }
}

❌ 그런데 문제 발생!

다음처럼 MyLogger를 일반 싱글톤 컨트롤러에 그냥 주입하면 애플리케이션 실행 시점에 에러가 난다.

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    private final MyLogger myLogger; // ❌ 에러 발생
    ...
}

💡 왜 에러가 날까?

• @Scope("request")는 HTTP 요청이 있을 때만 생성될 수 있다.
• 하지만 싱글톤 빈은 애플리케이션 실행 시점에 먼저 생성된다.
• 이 시점에서는 HTTP 요청이 없기 때문에 MyLogger 빈도 만들 수 없다.

✅ 해결 1: ObjectProvider

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final ObjectProvider<MyLogger> myLoggerProvider;

    @RequestMapping("/log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        // 요청 시점에 빈 생성
        MyLogger myLogger = myLoggerProvider.getObject(); 
        myLogger.setRequestURL(request.getRequestURL().toString());
        myLogger.log("controller test");
        return "OK";
    }
}

이렇게 하면 getObjcet()를 호출하는 시점에 HTTP 요청이 진행중이므로MyLogger 빈이 생성된다. 즉, 빈 생성을 지연시켜서 문제를 해결하는 것이다.

✅ 해결 2: 프록시(proxy)

더 간단히 처리할 수 있는 방법은 프록시 객체를 사용하는 것이다.

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
    ...
}

이 설정을 추가하면 스프링이 MyLogger를 상속받은 가짜 객체(프록시)를 먼저 만들어서 싱글톤 빈들에 미리 주입해놓는다. 그럼 컨트롤러는 아래와 같이 평범하게 사용할 수 있다.

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    private final MyLogger myLogger; // ➡️ 프록시 객체가 들어옴

    @RequestMapping("/log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        myLogger.setRequestURL(request.getRequestURL().toString());
        myLogger.log("controller test");
        return "OK";
    }
}

프록시 객체는 내부에서 실제 request scope 빈을 찾아서 필요할 때 위임한다. 즉, 개발자는 마치 싱글톤처럼 쓰지만 내부에서는 요청마다 새 객체가 사용되는 것이다.

프록시가 실제로 동작하는지 확인하려면 System.out.println("myLogger = " + myLogger.getClass()); 로 출력을 하면 myLogger = ..MyLogger$$EnhancerBySpringCGLIB... 라고 출력이된다.

• CGLIB 라는 라이브러리로 가짜 객체가 생성된 것을 확인할 수 있다.
• 이 객체는 내부적으로 진짜 request scope빈을 찾아서 사용하는 기능만 가지고 있는 프록시이다.
• 가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게 동일하게 사용할 수 있다. (다형성)

_특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자. 무분별하게 사용하면 유지보수하기 어려워진다. _

🌟 두 방식의 핵심 공통점은 모두 실제 빈 생성을 필요한 시점까지 미룬다는 것이다. 실제 객체는 지연 생성되고 로직은 그대로 유지할 수 있다는 점이 큰 장점이다.

💡 왜 생명주기 콜백이 필요할까?

어플리케이션을 실행할 때 꼭 필요한 작업들이 있다.

• 서버 시작 시 외부 서버와 네트워크 연결
• 애플리케이션 종료 시 네트워크 연결 해제

이처럼 객체 생성 -> 의존관계 주입 -> 초기화 -> 사용 -> 종료 전 정리 과정이 필요하다. 스프링은 이 과정을 자동으로 관리할 수 있는 콜백 메커니즘을 제공한다.

🔁 스프링 빈의 라이프사이클

스프링 빈은 아래와 같은 순서로 동작한다.

1. 스프링 컨테이너 생성
2. 스프링 빈 생성
3. 의존관계 주입
4. 초기화 콜백
5. 빈 사용
6. 소멸 전 콜백
7. 스프링 종료 🌟 핵심은 초기화 작업은 의존관계 주입 이후에 실행돼야 한다는 것이다!!!

생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면 초기화는 이렇게 생성된 값들을 활용해 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.

조금 더 이해하기 쉽도록 아래와 같은 예시를 보며 이해해보자!

[NetworkClient 클래스]

public NetworkClient() {
    System.out.println("생성자 호출, url = " + url);
    connect(); // 문제: 아직 URL이 주입되지 않음
}

객체 생성하는 단계에는 url이 없고, 객체를 생성한 다음에 외부에서 수정자 주입을 통해 setUrl()이 호출되어야 url이 존재하게 된다. 즉 url이 아직 주입되기 전이라 null 상태에서 connect()가 실행되는 것이다. 따라서 초기화는 생성자가 아니라 따로 분리해서 처리해야한다.

스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 즉 위에서 언급한대로 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까?

✅ 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다.

‼️ 생명주기 콜백 방법 3가지

1. 인터페이스 방식 (InitializingBean, DisposableBean)

스프링이 제공하는 인터페이스를 직접 구현해서 초기화/소멸 메서드를 정의하는 방법이다.

• afterPropertiesSet()은 빈이 생성되고 의존관계 주입이 끝난 뒤 자동으로 호출된다.

• destroy()는 컨테이너가 종료되기 전에 호출된다.

  public class NetworkClient implements InitializingBean, DisposableBean {
    private String url;
  
    public void setUrl(String url) {
        this.url = url;
    }
  
    @Override
    public void afterPropertiesSet() {
        connect();
        call("초기화 메시지");
    }
  
    @Override
    public void destroy() {
        disconnect();
    }
  }

• 👉 단점 *

• 스프링 전용 인터페이스이기 때문에 스프링에 종속된다. 즉 스프링이 없는 환경에선 재사용이 불가능하다.

• 메서드 이름을 바꿀 수 없다.

• 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

요즘은 거의 사용하지 않는 방식이다!!

2. @Bean 등록 시 메서드 지정

@Bean 어노테이션에서 초기화/종료 메서드의 이름을 지정해준다. 빈 클래스 내부에 init(), close() 등의 메서드를 자유롭게 만들고 설정에서 지정하는 방식이다.

public class NetworkClient {
    public void init() {
        connect();
        call("초기화 메시지");
    }

    public void close() {
        disconnect();
    }
}

@Configuration
static class Config {
    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient client = new NetworkClient();
        client.setUrl("http://hello.dev");
        return client;
    }
}

*👉 장점 *

• 메서드 이름을 자유롭게 지을 수 있다.
• 스프링 코드에 의존하지 않는다.
• 외부 라이브러리에도 적용 가능하다.

*👉 단점 *

• 설정에서 메서드 이름을 지정해줘야한다.

_Tip : destroyMethod는 기본값이 "inferred"로 되어 있어서 메서드 이름이 close나 shutdown이면 자동으로 호출된다. → 굳이 destroyMethod = "close" 안 써도 된다. _

3. @PostConstruct / @PreDestroy 애노테이션

최신 스프링에서 가장 권장하는 방법이다. 자바 표준 애노테이션 @PostConstruct, @PreDestroy를 사용하면 간단히 초기화/소멸을 구현할 수 있다.

public class NetworkClient {
    @PostConstruct
    public void init() {
        connect();
        call("초기화 메시지");
    }

    @PreDestroy
    public void close() {
        disconnect();
    }
}

*👉 장점 *

• 코드에 애노테이션만 붙이면 되니까 매우 간편하다.
• 스프링 전용이 아니라 자바 표준이기 때문에 다른 컨테이너에서도 동작 가능하다.
• 컴포넌트 스캔과 잘 작동한다.

*👉 단점 *

• 외부 라이브러리에는 애노테이션을 직접 붙일 수 없으니 적용이 불가하다.

결론은 ❓

• 직접 만든 빈이면 → @PostConstruct, @PreDestroy 사용!
• 외부 라이브러리라면 → @Bean(initMethod, destroyMethod) 사용!

➡️ 1) 생성자 주입

• 생성자 호출시점에서 딱 1번만 호출되는 것이 보장된다.

• 불변, 필수 의존관계에 사용한다.

  @Component
  public class OrderServiceImpl implements OrderService {
  
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
  
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
    }
  }

  ⚠️ 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입이 된다.

➡️ 2) 수정자 주입

• setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법이다.

• 자바빈 프로퍼티의 수정자 메서드 방식이다. (=setter)

• 선택, 변경 가능성이 있는 의존관계에 사용한다.

  ...
  @Autowired
  public void setMemberRepository(MemberRepository memberRepository) {
     this.memberRepository = memberRepository;
  }
  
  @Autowired
  public void setDiscountPolicy(DiscountPolicy discountPolicy) {
     this.discountPolicy = discountPolicy;
  }
  ...

  ⚠️ @Autowired 는 주입할 대상이 없으면 오류가 발생한다. 오류가 발생하지 않게 하려면 @Autowired(required = false)로 지정해야한다.

➡️ 3) 필드 주입

• 코드가 간결하고 쉽다.
• But, 외부에서 값을 주입하거나 변경할 수 없어서(setter도 없고 생성자를 통한 주입도 아니니) 테스트에서 객체를 바꿔 넣기 어렵다는 단점이 있다.
• DI 프레임워크(스프링) 없이는 객체를 만들 수 없다.
  • ⚠️ 스프링 컨테이너는 @Conponent 등이 붙은 클래스들을 자동으로 스프링 빈에 등록하여 관리해주는 통이다. 이 통 안에 들어간 객체만 스프링이 주입(@Autowired)도 관리도 해주기 때문에 new로 직접 객체를 생성하면 스프링은 몰라서 null이 될 수도 있다.

    ...
    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;
    ...

• 즉, 사용하지말자 ‼️
• 아래의 경우는 고려해보자
  • 애플리케이션의 실제 코드와 관계 없는 테스트 코드
  • 스프링 설정을 목적으로 하는 @Configuration 같은 곳

➡️ 4) 일반 메서드 주입

• 한번에 여러 필드를 주입 받을 수 있다.
• 잘 사용하진 않는다.

  ...
  @Autowired
  public void init(MemberRepository memberRepository, DiscountPolicy 
  discountPolicy) {
  this.memberRepository = memberRepository;
  this.discountPolicy = discountPolicy;
    }

2. 옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 때가 있다. 그런데 @Autowired만 사용하면 required 옵션의 기본값이 true로 되어 있어서 자동 주입 대상이 없으면 오류가 발생한다.

해결방법은 다음 3가지이다.

• @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력됨
• Optional<> : 자동 주입 대상이 없으면 Optional.empty가 입력됨

(@Nullable, Optional은 스프링 전반에 걸쳐서 지원된다. 예를 들어서 생성자 자동 주입에서 특정 필드에만 사용해도 된다.)

//호출 안됨
@Autowired(required = false)
 public void setNoBean1(Member member) {
    System.out.println("setNoBean1 = " + member);
 }
 //null 호출
@Autowired
 public void setNoBean2(@Nullable Member member) {
    System.out.println("setNoBean2 = " + member);
 }
 //Optional.empty 호출
@Autowired(required = false)
 public void setNoBean3(Optional<Member> member) {
    System.out.println("setNoBean3 = " + member);
 }

Member는 스프링 빈이 아니기 때문에 아래와 같이 setNoBean1 자체는 호출이 되지 않는 결과가 나온다.

3. 왜 생성자 주입을 권장할까?

💡 불변성 보장

• 대부분의 의존 객체는 한 번 주입되면 변경되면 안된다.
• 생성자 주입은 객체 생성 시점에만 호출되기 때문에, 객체가 생성된 후에는 절대 바뀌지 않는다.
• final 키워드를 사용할 수 있어서 컴파일 타임에 안정성을 확보한다.

  💡 의존성 누락 방지 (컴파일 오류)

• java: variable discountPolicy might not have been initialized
• 수정자 주입이나 필드 주입은 의존성 누락이 있어도 컴파일 오류 없이 실행되어 NPE 가능성이 있다.
• 생성자 주입은 생성자 파라미터가 필수이므로 누락되면 컴파일 에러로 알려줘서 안전하다.

  💡 순수 자바 코드로 테스트 가능

  // 생성자 주입은 테스트에서도 명확하게 어떤 의존 객체가 필요한지 알 수 있음
  OrderServiceImpl service = new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());

• DI 프레임워크 없이도 new를 이용하여 객체를 만들 수 있어서 스프링 없이도 테스트가 가능하다.

✅ 항상 생성자 주입을 선택하자! 그리고 가끔 옵션이 필요하면 수정자 주입을 선택하도록 하자.

🛠 룸복으로 더 간단하게!

롬복 라이브러리가 제공하는@RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 컴파일 시점에 생성자를 자동으로 만들어준다. (자바의 애노테이션 프로세서라는 기능을 이용) ➕ 생성자가 하나일 경우 @Autowired 생략이 가능하기 때문에 아래와 같이 코드가 훨씬 간단해진다.

@RequiredArgsConstructor
@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

4. 의존성 주입 충돌 (빈이 2개 이상일 때)

@Autowired는 타입 기준으로 주입을 시도하여 같은 타입에 등록된 빈이 2개 이상일 경우 NoUniqueBeanDefinitionException 오류가 발생한다.

@Autowired
private DiscountPolicy discountPolicy; 
// DiscountPolicy 빈이 2개라면?  (FixDiscountPolicy, RateDiscountPolicy)

이 문제를 해결하는 방법 3가지는 아래와 같다.

👉 필드명 매칭

@Autowired는 먼저 타입 매칭을 시도하고 여러 빈이 있을 때 추가로 동작하는 기능이다. 아래와 같이 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

@Autowired
private DiscountPolicy rateDiscountPolicy; // 빈 이름과 일치

👉 @Qualifier 사용

추가 구분자를 붙여주는 방법이다. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것이 아니다! 주의하자!

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Autowired
public OrderServiceImpl(
    MemberRepository memberRepository,
    @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    ...
}

만약 @Qualifier("mainDiscountPolicy")을 찾지 못한다면 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는다. 추가로 찾을 시에도 없다면 NoUniqueBeanDefinitionException 오류가 발생한다.

👉 @Primary 사용

우선 순위를 정하는 방법이다. @Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권을 가진다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

✅ @Qualifier vs @Primary

• @Primary는 기본(default) 빈으로 지정하는 것이고 별다른 지정이 없을 때 주입된다.
• @Qualifier는 명시적으로 특정 빈을 지정하는 것이고 @Primary보다 우선순위가 높다.
• 자주 사용하는 빈은 @Primary, *가끔 *사용하는 빈은 @Qualifier로 지정하면 깔끔하게 관리할 수 있다.

커스텀 애노테이션으로 간결하게!

@Qualifier("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일시 타입 체크가 안된다.

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, 
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {}

자바 애노테이션에는 상속이 없고, 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다.

//빈 정의 시
 @Component
 @MainDiscountPolicy
 public class RateDiscountPolicy implements DiscountPolicy {}

//생성자 자동 주입시
@Autowired
 public OrderServiceImpl(MemberRepository memberRepository,
                         @MainDiscountPolicy DiscountPolicy discountPolicy) {
      this.memberRepository = memberRepository;
      this.discountPolicy = discountPolicy;
}

But, 명확한 목적 없이 무분별하게 사용하면 유지보수에 혼란이 생기므로 주의하자!

5. List, Map으로 전체 빈 주입받기

할인 서비스를 제공하는데 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자! 이럴 땐 모든 DiscountPolicy 구현체를 한번에 주입받고 클라이언트 선택에 따라 전략적으로 실행하는 방법이 있다.

@Component
public class DiscountService {

    private final Map<String, DiscountPolicy> policyMap;
    private final List<DiscountPolicy> policies;

    // 모든 DiscountPolicy 빈이 Map과 List로 자동 주입됨
    public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
        this.policyMap = policyMap;
        this.policies = policies;
    }

    public int discount(Member member, int price, String discountCode) {
        DiscountPolicy policy = policyMap.get(discountCode);
        // 클라이언트가 고른 빈의 discount 메서드 실행 
        return policy.discount(member, price);
    }
}

• Map : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• List : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

6. 자동, 수동의 올바른 실무 운영 기준

1. 편리한 자동 기능을 기본으로 사용하자

• 컴포넌트 스캔과 자동 주입을 사용하는 선호하는 추세이다.
• 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있다.

2. 그럼 언제 빈 등록을 사용할까 ❓

• 애플리케이션은 크게 아래와 같이 나눌 수 있다.
  • 업무 로직 빈 : 보통 비지니스 요구사항 개발할 때 추가되거나 변경되며 컨트롤러, 서비스, 레포지토리 등이 해당된다.
  • 기술 지원 빈 : 데이터 베이스 연결이나 공통 로그 처리처럼 업무 로직을 지원하기 위한 공통 기술들이다. (ex : AOP 처리 시 사용)
• 숫자도 많고 한번 개발하면 어느정도 유사한 패턴이 있는 업무 로직은 자동 기능을 활용하고, 수가 적고 광범위하게 영향을 미치며 문제 발생 시 찾기 어려운 기술 지원은 수동으로 등록하는 것이 좋다.

3. 비지니스 로직 중 다형성을 적극 활용할 때는 ❓

• 자동으로 등록된다면, 다른 개발자가 구현한Map<String, DiscountPolicy> 에 어떤 빈들이 주입될지 파악하기 어렵다.
• 이런 경우 수동 빈으로 등록하거나 자동으로하면 특정 패키지에 같이 묶어두는게 좋다!

📅 2월

• 대성 지역 아동 센터 수업 참관
• 코디니 활용 블록코딩 교육 시연 관찰
• 수업 진행 시 강사의 태도와 아이들과의 소통 방식 학습

📅 3월

• AICE Future 정기시험(2025년 제2회) 응시
• 1급, 2급, 3급 자격증 모두 취득

🏅 자격증 인증샷

🌟 더 많은 교육 활동에 참여하며 아이들이 IT를 어떻게 접하고 배우는지 알아가고 싶다. 나만의 방식으로 아이들에게 IT를 전하는 것이 나의 다음 목표다!!