AI 코딩 도구는 이제 단순히 “코드를 생성해주는 도구”를 넘어가고 있다.

예전에는 개발자가 요청을 입력하면 AI가 코드 조각을 만들어주는 수준이었다면, 최근에는 요구사항을 정리하고, 작업을 계획하고, 여러 역할로 나누어 실행하고, 결과를 검증하는 방식으로 발전하고 있다.

이런 흐름에서 등장한 것이 OMX와 OMC다.

OMX는 Codex CLI를 더 체계적으로 사용하기 위한 워크플로우 레이어이고, OMC는 Claude Code를 멀티 에이전트 방식으로 확장해주는 플러그인이다.

쉽게 말하면 둘 다 AI 코딩 도구를 실무형 작업 도구로 바꿔주는 보조 시스템이라고 보면 된다.

1. OMX란?

OMX는 oh-my-codex의 약자다.

OpenAI Codex CLI 위에 워크플로우, 작업 계획, 로그, 메모리, 상태 관리 기능을 얹는 도구다.

Codex CLI 자체를 대체하는 것은 아니고, Codex CLI를 더 잘 쓰기 위한 관리 레이어에 가깝다.

쉽게 비유하면 Codex CLI가 실제로 코드를 작성하는 실행 엔진이라면, OMX는 그 위에서 작업 순서, 기록, 상태, 역할 분담을 관리하는 작업 지휘 시스템이다.

2. OMX의 핵심 기능

OMX의 핵심은 AI 코딩 작업을 즉흥적으로 처리하지 않고, 일정한 흐름에 따라 진행하게 만드는 것이다.

대표적인 기능은 다음과 같다.

• 요구사항이 애매할 때 질문을 통해 명확하게 정리
• 구현 전에 계획을 먼저 수립
• 승인된 계획을 바탕으로 코드 작성
• 여러 에이전트를 병렬로 실행
• 작업 로그와 메모리를 .omx/ 디렉터리에 저장
• 세션 상태를 유지하여 이어서 작업 가능
• Codex CLI의 hook 설정 관리
• 현재 작업 상태를 확인할 수 있는 HUD 기능 제공

대표 명령어는 다음과 같다.

$deep-interview
$ralplan
$ralph
$team

각 명령어의 역할은 다음과 같다.

$deep-interview는 요구사항이 애매할 때 사용한다. AI가 바로 구현하지 않고 먼저 질문을 던지면서 요구사항을 명확하게 만든다.

$ralplan은 구현 전에 계획을 세울 때 사용한다. planner, architect, critic 같은 역할을 통해 계획을 검토하고 정리하는 방식이다.

$ralph는 승인된 계획을 바탕으로 끝까지 구현을 밀어붙이는 모드다. 단순한 답변이 아니라 실제 작업 완료를 목표로 한다.

$team은 여러 에이전트를 병렬로 실행할 때 사용한다. 예를 들어 프론트엔드, 백엔드, 테스트 역할을 나누어 동시에 진행하는 방식이다.

3. OMX 설치 및 사용 흐름

OMX는 보통 Codex CLI와 함께 설치해서 사용한다.

Codex CLI가 아직 설치되어 있지 않다면 다음처럼 설치한다.

npm install -g @openai/codex

이후 OMX를 설치한다.

npm install -g oh-my-codex

그다음 터미널에서 OMX 초기 설정을 진행한다.

omx setup

Codex를 실행한다.

codex

필요하면 OMX를 고성능 설정으로 실행할 수도 있다.

omx --madmax --high

실제 작업에서는 다음과 같이 사용할 수 있다.

$deep-interview "요구사항이 애매한 기능 정리"
$ralplan "구현 계획 수립"
$ralph "승인된 계획을 끝까지 구현"
$team 3:executor "3명이 병렬로 구현"

주의할 점은 omx setup은 Codex 대화창 안에서 입력하는 명령이 아니라, 터미널에서 실행하는 OMX CLI 명령이라는 점이다.

또한 기존에 Codex CLI를 Homebrew 등 다른 방식으로 설치했다면 npm 설치 버전과 충돌할 수 있으므로, 설치 경로를 확인하는 것이 좋다.

4. OMX를 쓰면 좋은 경우

OMX는 다음과 같은 상황에서 유용하다.

• Codex CLI를 매번 즉흥적으로 사용하고 있는 경우
• 작업 계획과 로그를 남기고 싶은 경우
• AI가 무엇을 했는지 추적하고 싶은 경우
• 요구사항 정리부터 구현, 검증까지 흐름을 고정하고 싶은 경우
• 여러 작업을 병렬로 처리하고 싶은 경우
• 하나의 긴 작업을 세션이 끊겨도 이어서 진행하고 싶은 경우

즉, 단순한 코드 생성이 아니라 프로젝트 단위의 작업 흐름을 만들고 싶을 때 OMX가 도움이 된다.

5. OMC란?

OMC는 oh-my-claudecode의 약자다.

Claude Code를 더 강력하게 사용하기 위한 플러그인이다.

Claude Code가 기본적으로 하나의 AI 개발 도구라면, OMC는 그 위에 여러 전문 에이전트와 실행 모드를 얹어서 더 복잡한 개발 작업을 처리할 수 있게 만든다.

예를 들어 단순히 “회원가입 기능 만들어줘”라고 요청하는 것이 아니라, 요구사항 분석, 설계, 구현, 테스트, 검증을 역할별로 나누어 처리하게 할 수 있다.

OMC의 핵심은 Claude Code를 단순한 코딩 도구가 아니라 팀처럼 움직이는 AI 개발 시스템으로 확장하는 것이다.

6. OMC 설치 및 초기 설정

OMC는 Claude Code의 플러그인 마켓플레이스를 통해 설치한다.

Claude Code 안에서 아래 명령을 한 줄씩 실행한다.

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode

/plugin install oh-my-claudecode

설치 후 초기 설정은 다음 명령으로 진행한다.

/omc-setup

일부 문서에서는 다음과 같은 형태로 안내되어 있을 수 있다.

/oh-my-claudecode:omc-setup

하지만 최신 빠른 시작 기준으로는 /omc-setup을 사용하는 것이 더 간단하다.

설치 후에는 다음 명령어로 상태를 점검할 수 있다.

/omc-doctor

프로젝트를 처음 시작할 때는 다음 명령어를 사용한다.

/deepinit

/deepinit은 프로젝트 구조를 분석하고, AI가 참고할 수 있는 AGENTS.md 문서를 생성하는 역할을 한다.

OMC는 .omc/ 디렉터리 아래에 상태, 메모리, 계획, PRD, 로그 등을 저장한다.

7. OMC의 주요 실행 모드

OMC에는 여러 실행 모드가 있다.

대표적인 모드는 다음과 같다.

autopilot

계획부터 구현, 테스트, 검증까지 자동으로 진행하는 모드다.

반복적이고 비교적 명확한 작업에 적합하다.

ralph

작업이 완료될 때까지 계속 밀어붙이는 모드다.

중간에 멈추지 않고 결과물을 끝까지 만드는 데 초점이 있다.

team

여러 에이전트가 팀처럼 역할을 나누어 작업하는 모드다.

프론트엔드, 백엔드, 테스트, 리뷰 등을 나누어 처리할 수 있다.

ultrawork / ulw

여러 개의 독립적인 작업을 병렬로 처리하는 모드다.

작업량이 많고 서로 의존성이 낮을 때 유용하다.

eco

비용 절감을 우선하는 모드다.

가능하면 저렴한 모델을 먼저 사용하고, 필요한 경우에만 강한 모델을 사용하는 방식이다.

deep-interview

요구사항이 애매할 때 사용하는 모드다.

바로 구현하지 않고 질문을 통해 요구사항을 명확하게 만든다.

ralplan

구현 전에 계획을 수립하고 검토하는 모드다.

planner, architect, critic 같은 역할을 통해 계획을 더 탄탄하게 만든다.

8. OMC를 쓰면 좋은 경우

OMC는 다음과 같은 상황에서 유용하다.

• Claude Code를 더 체계적으로 쓰고 싶은 경우
• 큰 기능을 한 번에 구현해야 하는 경우
• 요구사항 정리, 설계, 구현, 테스트를 나누고 싶은 경우
• 여러 에이전트를 동시에 활용하고 싶은 경우
• Claude Code 작업 기록과 상태를 유지하고 싶은 경우
• 비용을 아끼면서 AI 코딩을 돌리고 싶은 경우
• 프로젝트 전체 구조를 AI가 이해하게 만들고 싶은 경우

즉, Claude Code를 실무 개발팀처럼 사용하고 싶을 때 OMC가 적합하다.

9. OMX와 OMC 비교

OMX와 OMC는 비슷해 보이지만 사용하는 기반 도구가 다르다.

OMX는 OpenAI Codex CLI 기반이고, OMC는 Claude Code 기반이다.

OMX는 Codex CLI를 위한 워크플로우 레이어에 가깝고, OMC는 Claude Code를 멀티 에이전트 개발 환경으로 확장하는 플러그인에 가깝다.

정리하면 다음과 같다.

10. 어떤 걸 쓰면 좋을까?

Codex CLI를 주로 사용한다면 OMX가 적합하다.

Claude Code를 주로 사용한다면 OMC가 적합하다.

둘 중 하나가 무조건 더 좋다기보다는, 내가 사용하는 AI 코딩 도구가 무엇인지에 따라 선택하면 된다.

정리하면 다음과 같다.

• Codex CLI를 쓴다 → OMX
• Claude Code를 쓴다 → OMC
• 요구사항이 애매하다 → deep-interview
• 구현 전에 설계가 필요하다 → ralplan
• 큰 기능을 끝까지 구현하고 싶다 → ralph
• 여러 작업을 병렬로 처리하고 싶다 → team 또는 ultrawork
• 비용을 줄이고 싶다 → eco

11. 사용할 때 주의할 점

OMX와 OMC는 AI 코딩을 더 강하게 만들어주는 도구지만, 무조건 자동으로 완벽한 결과를 보장하는 것은 아니다.

특히 다음 부분은 주의해야 한다.

• 명령어와 설치 방식은 버전에 따라 바뀔 수 있다.
• AI가 만든 계획이나 코드는 사람이 반드시 검토해야 한다.
• 멀티 에이전트 방식은 편리하지만, 잘못된 방향으로 병렬 작업을 하면 오히려 수정 비용이 커질 수 있다.
• 대규모 작업을 맡길 때는 먼저 요구사항을 명확히 해야 한다.
• 실제 서비스 코드에 반영하기 전에는 테스트와 코드 리뷰가 필요하다.
• 비용이 발생하는 환경에서는 실행 모드와 모델 사용량을 확인해야 한다.

즉, OMX와 OMC는 개발자를 대체하는 도구라기보다는 개발자가 AI를 더 체계적으로 지휘하기 위한 도구에 가깝다.

12. 최종 정리

OMX와 OMC는 AI 코딩 도구를 더 실무적으로 사용하기 위한 도구다.

기존의 AI 코딩 방식은 개발자가 질문하고 AI가 답변하는 단순한 구조였다.

하지만 OMX와 OMC는 여기서 한 단계 더 나아가 요구사항 정리, 계획 수립, 역할 분담, 구현, 검증, 기록까지 하나의 흐름으로 관리할 수 있게 해준다.

결국 핵심은 AI에게 그냥 “코드 짜줘”라고 시키는 것이 아니다.

AI에게 명확한 요구사항을 주고, 계획을 세우게 하고, 역할을 나누고, 검증까지 시키는 구조를 만드는 것이다.

앞으로 AI 코딩을 실무에서 제대로 활용하려면 단순한 프롬프트보다 이런 워크플로우 도구가 더 중요해질 가능성이 높다.

OMX와 OMC는 그런 흐름에서 나온 도구라고 볼 수 있다.

Codex CLI를 쓴다면 OMX, Claude Code를 쓴다면 OMC를 활용해보면 좋다.

사이드 프로젝트로 별 헤는 밤이라는 커뮤니티 사이트를 배포하고 운영하면서, 기능을 만들고 고치고 다시 걷어내는 과정을 꽤 오래 겪었다.
그중에서도 가장 기억에 남는 건 날씨 캐싱 설계와 회원 탈퇴 처리였다.

지금 돌아보면, 정말 많은 시간을 쏟았는데 결과적으로는
“굳이 이렇게까지 했어야 했나?”라는 생각이 든다.

좌표 기반 온디맨드 날씨 캐싱 — 이상과 현실의 괴리

별 헤는 밤은 접속자의 좌표를 기준으로 도시를 판단하고, 그 도시의 날씨를 수집해 별 관측에 적합한지 알려주는 서비스였다.

제공하던 정보는 다음과 같았다.

• 구름량
• 날씨 상태
• 이를 기반으로 계산한 시정
• 오늘 별 관측 가능 상태 (Excellent ~ Bad)

처음에는 서버 비용과 성능을 모두 잡고 싶어서
온디맨드 방식의 캐싱 구조로 구현했다.

처음 설계

• 사용자가 접속
• 좌표 → 도시 판별
• 해당 도시 날씨 수집
• 15분 캐싱
• 이후 동일 도시 요청은 캐시 제공

이론상으로는 꽤 그럴듯했다.
“필요한 도시만 수집하니까 효율적이겠지”라는 생각이었다.

현실

• 구현이 생각보다 복잡해짐
• 좌표 기반 도시 판별 + 캐시 키 관리가 까다로움
• 사이트 특성상 트래픽이 많지 않음
• 결과적으로 캐시 히트율이 매우 낮음

정리하면,

복잡도는 높은데, 얻는 이득은 거의 없는 구조

였다.

단순화 이후 — 성능도, 비용도 더 좋아졌다

결국 구조를 단순하게 바꿨다.

변경 후 설계

• 주요 도시 기준
• 30분 간격으로 정기 수집
• 모든 사용자에게 동일 데이터 제공

결과는 의외로 훨씬 좋았다.

• 구현이 단순해짐
• 캐시 구조가 명확해짐
• 서버 비용 감소
• 성능 안정
• 운영 난이도 하락

“온디맨드”라는 말에 너무 끌렸지,
이 프로젝트에 정말 필요한 구조인지는 깊게 고민하지 않았던 것 같다.

탈퇴 처리 — 왜 이렇게 나눴는지 기억도 안 난다

회원 탈퇴 처리도 비슷한 시행착오를 겪었다.

초기 구현은 다음과 같았다.

• 일반 회원: 탈퇴 시 즉시 탈퇴
• 소셜 로그인 회원:
  • 탈퇴 후 1개월 이내 로그인 시 복구 가능

지금 와서 보면,

왜 이렇게 나눴는지 스스로도 설명을 못 하겠다.

아마도 “서비스답게 만들어야 한다”는 강박이 있었던 것 같다.

사실은 더 단순하게 구현할 수 있었다.

• 모든 회원 동일한 정책 적용
• 탈퇴 후 1개월 이내 로그인 시 복구
• 1년 경과 시 완전 삭제

이 정도면 충분했고,
유저 경험도 더 일관됐을 것이다.

진짜로 배운 점

이 프로젝트에서 얻은 가장 큰 교훈은 기술 그 자체가 아니었다.

• 더 복잡한 구조가
• 더 멋진 설계가
• 더 정교한 아키텍처가

항상 더 좋은 결과를 주는 건 아니었다.

특히 사이드 프로젝트나 작은 서비스일수록 더 그렇다.

Simple is Best.

트레이드오프를 고려해서
“지금 이 프로젝트에 정말 필요한가?”를 기준으로 선택해야 한다.

괜히 의미 없는 복잡함에 시간을 쓰기보다는,
단순하고 명확한 구조로 빠르게 검증하고 운영하는 게 훨씬 낫다.

마무리

돌이켜보면 진짜 개고생이었다.
그런데 이상하게도, 그 고생이 헛되다고만은 느껴지지 않는다.

이제는 안다.

• 무엇을 만들지보다
• 무엇을 만들지 말아야 하는지가 더 중요하다는 걸.

다음 프로젝트에서는
조금 덜 고생하고,
조금 더 현명한 선택을 할 수 있을 것 같다.

프로젝트를 시작한 이유

'별 헤는 밤'이라는 웹 서비스를 만들기로 결심한 이유는 세 가지였다.

1. 완성의 경험이 필요했다
   정규 학습 외에 내가 혼자 처음부터 끝까지 완성한 프로젝트가 없었다.

2. 실전 경험의 부재
   자바와 스프링을 공부만 하고 직접 개발하며 상황을 겪어보지 않으니 모든 것이 막연하게만 느껴졌다.

3. 단순한 열정
   우리나라에는 왜 우주 관련 커뮤니티 사이트가 없을까? 내가 한번 만들어보자는 어린 생각이었다.

나는 어렸을 때부터 천문학자가 꿈일 정도로 우주를 좋아했다. 하지만 공부를 그다지 잘하지 못해 취미로만 우주라는 콘텐츠를 즐겨왔다. 유튜브를 보면 많은 사람들이 우주 콘텐츠 영상을 좋아하는데, 왜 이런 주제를 다루는 사이트는 없는 걸까 궁금했다. 그래서 직접 만들어보기로 했다.

하지만 프로젝트를 진행하며 이것이 왜 '어린 생각'이었는지 깨닫게 되었다.

프로젝트를 통해 깨달은 현실

1. 우주는 매우 매니악한 주제다

진짜 쉽게 비유하자면 이렇다. 달에 소행성이 충돌했다는 뉴스 기사를 보고 다른 사람에게 이 주제를 꺼낸다면, 대부분은 "그래서 뭐 어쩌라고?"라고 반응한다.

우주는 우리 삶의 많은 부분에 영향을 끼치지만, 그 소식을 안다고 해서 당장 삶에 큰 메리트가 있는 분야는 아니다. 과학이라는 학문 자체가 대부분 확정적이지 않고 "그럴 것이다"라고 짐작하는 영역이다.

AI 시대가 도래한 지금, 사람들이 가장 원하는 것은 확답이다. 지금 내 삶에 직접적인 영향을 미치는 것에 관심을 가지는 게 당연하다. 우주는 그런 확답을 주기 어려운 주제였다.

2. 우주 콘텐츠는 비즈니스적으로 수익화가 어렵다

사람들은 매력적인 서비스가 등장하면 많은 돈을 내서라도 그 콘텐츠를 즐기기 위해 결제한다. 하지만 우주는 이미 시중에 무료 자료가 넘쳐난다. 돈을 지불하면서까지 즐기려는 경우는 드물다.

예를 들어, 헬스장 비용이 비싸다고 해도 사람들은 계속 다닌다. 운동하기 싫어도 건강을 위해 어쩔 수 없이 다니는 것이다. 하지만 우주는 다르다. 사람들이 돈을 지불하면서까지 이 콘텐츠를 즐길 이유가 없다.

따라서 우주라는 주제로 웹사이트를 만드는 것은 사실상 돈 벌 생각이 없다는 소리에 가깝다. 내 서비스는 비즈니스적으로 수익을 낼 방법이 거의 제로에 가깝다. 설령 내가 돈을 벌 생각이 없다 해도, 사람들이 언제든 즐길 수 있게 사이트를 열어두는 것 자체에도 비용이 든다. 최소한의 서버 유지비조차 감당하기 어렵다는 얘기다.

솔직히 말해서, 이번 프로젝트를 통해 규모를 키워보겠다는 생각은 엄연한 나의 착각이었고 어린 생각이었다.

3. 웹사이트는 점점 사용자가 줄어들고 있다

정확히 말하자면, 사람들은 더 이상 컴퓨터에 앉아 커뮤니티 게시판을 방문해 소통하고 양질의 콘텐츠를 생성하지 않는다. AI의 영향도 크고, 스마트폰에 익숙한 세대에게 커뮤니티 서비스를 PC로 즐기라는 건 구시대적 발상이다.

이전에 내 웹서비스를 다른 사람에게 소개했을 때가 생각난다. 첫 번째 질문은 "언제 앱 출시할 거냐?"였다. 그리고 두 번째 피드백은 "제공하는 정보들이 우주를 모르는 사람에게는 전혀 이해할 수 없는 내용이 많다"는 것이었다.

사실 나는 사용자 친화적인 서비스를 만들기 위해 여러 번 노력했다. 하지만 서비스를 처음 운영해봤기에 턱없이 부족했다. 그리고 위에서 언급했듯, 우주에 관심 없는 사람들은 어려운 용어나 익숙하지 않은 현상에 큰 관심이 없다. 결국 흥미를 잃는 것뿐이다.

마치며

'별 헤는 밤'은 나의 첫 완성 프로젝트였다. 비록 성공적인 서비스는 아니었지만, 이 과정을 통해 기술적 성장뿐 아니라 시장과 사용자에 대한 현실적인 통찰을 얻었다.

어쩌면 이 프로젝트의 가장 큰 가치는 실패를 통해 배운 교훈들에 있을지도 모른다.

나중에 이어서 기술적 요소들을 회고해보려 한다.

JPA에서 연관 관계가 LAZY 로딩일 때,

1번의 메인 쿼리 실행 후, 연관된 엔티티를 N번 추가 조회하는 현상

💡 예시 상황

java
복사편집
List<Post> posts = postRepository.findAll();
for (Post post : posts) {
    System.out.println(post.getUser().getName()); // 작성자 정보 조회
}

• Post와 User는 @ManyToOne(fetch = LAZY) 관계

• 게시글이 10개라면:

  • Post 조회 쿼리: 1번

  • 각 User 조회 쿼리: 10번

    → 총 11번 쿼리 발생 = N+1 문제

🍜 라면 비유로 이해하기

🔧 해결 방법 1: Fetch Join

java
복사편집
@Query("SELECT p FROM Post p JOIN FETCH p.user")
List<Post> findAllWithUser();

• JPQL에 JOIN FETCH 명시
• Post와 User를 한 번에 JOIN해서 가져옴
• 쿼리 1번으로 N+1 해결

🔧 해결 방법 2: EntityGraph

java
복사편집
@EntityGraph(attributePaths = {"user"})
List<Post> findAll();

• 메서드에 @EntityGraph 선언
• 내부적으로 JOIN FETCH처럼 작동
• JPQL 없이도 N+1 문제 해결

📊 쿼리 비교

⚖️ Fetch Join vs EntityGraph

✅ 핵심 요약

N+1 문제 = "1번 가져오고, 연관된 것 N번 더 가져오는 비효율"

이를 해결하는 방법은:

• 복잡한 조건이 있으면 → fetch join
• 단순 조회라면 → EntityGraph

Oracle 12c부터 DB를 CDB(큰 집)과 PDB(방)으로 나누어 관리해요.

여러 개의 데이터베이스를 하나의 DB 시스템 안에서 동임적으로 사용하고 싶을 때 필요해요.

🏢 비유로 이해하기

📌 주요 차이점 정보

🧪 예시로 정리

• CDB = 오라클 전체 시스템 (건물)
• PDB = 서비스에 쓰이는 DB 하나하나 (방)
• C##OUTVEN 사용자 → CDB에서 생성됨 → CREATE SESSION 권한을 PDB 안에서도 다시 주어야 사용 가능

🛠️ 자주 쓰는 명령어

-- 현재 접속한 DB가 어디인지 확인
SELECT SYS_CONTEXT('USERENV','CON_NAME') FROM dual;

-- CDB에서 PDB 리스트 확인
SELECT name, open_mode FROM v$pdbs;

-- CDB → PDB 접속 전환
ALTER SESSION SET CONTAINER = XEPDB1;

✅ 마무리

• 개발자는 대부만에서 PDB에 연결해서 사용해요.
• CDB에서 권한을 줄 경우도 PDB에서도 다시 주어야 적용되요.
• Spring에서 에러나는 대부만에서 PDB에서 권한이 없어서예에요!

업로드는 S3 Presigned URL, 조회는 CloudFront Signed URL로 성능과 보안을 동시에 확보한 과정

🎯 문제 상황

기존 구조의 한계

• 단일 S3 URL: 업로드와 조회 모두 동일한 S3 URL 사용
• 보안 취약점: 조회 URL이 영구적으로 노출되어 무단 접근 가능
• 성능 제약: CDN 없이 S3 직접 접근으로 글로벌 사용자 경험 저하
• 비용 증가: S3 직접 접근으로 인한 데이터 전송 비용 상승

요구사항

• 업로드: S3 Presigned URL로 직접 업로드 (서버 부하 최소화)
• 조회: CloudFront Signed URL로 보안 강화 + CDN 성능
• 기존 호환성: 기존 API 유지하면서 점진적 전환

🔧 해결 과정

1단계: 의존성 추가

build.gradle 수정

// AWS S3 & CloudFront
implementation 'software.amazon.awssdk:s3'
implementation 'software.amazon.awssdk:cloudfront'  // 추가
implementation 'software.amazon.awssdk:auth'

불필요한 의존성 제거

// 제거된 의존성
// testImplementation 'org.testcontainers:junit-jupiter'

2단계: Config Server 설정 추가

로컬 개발 환경 (byeolnight-local.yml)

cloud:
  aws:
    s3:
      bucket: byeolnight-bucket
    cloudfront:
      distribution-domain: 'dummy-cloudfront-domain.cloudfront.net'
      key-pair-id: 'APKAI23HVI2C4JEXAMPLE'
      private-key-path: '/path/to/cloudfront-private-key.pem'
      signed-url-expiration: 3600

운영 환경 (byeolnight-prod.yml)

cloud:
  aws:
    cloudfront:
      distribution-domain: '{cipher}d1234567890abcdef.cloudfront.net'
      key-pair-id: '{cipher}APKAI23HVI2C4JEXAMPLE'
      private-key-path: '/app/cloudfront-private-key.pem'
      signed-url-expiration: 3600

3단계: S3Service 리팩토링

CloudFront 기능 추가

@Value("${cloud.aws.cloudfront.distribution-domain}")
private String cloudFrontDomain;

@Value("${cloud.aws.cloudfront.key-pair-id}")
private String keyPairId;

@Value("${cloud.aws.cloudfront.private-key-path}")
private String privateKeyPath;

@Value("${cloud.aws.cloudfront.signed-url-expiration:3600}")
private int signedUrlExpiration;

/**
 * CloudFront Signed URL 생성 (조회/다운로드용)
 */
public String generateCloudFrontSignedUrl(String s3Key) {
    try {
        String resourceUrl = String.format("https://%s/%s", cloudFrontDomain, s3Key);
        Instant expiration = Instant.now().plusSeconds(signedUrlExpiration);

        Path privateKeyFile = Paths.get(privateKeyPath);

        CannedSignerRequest signerRequest = CannedSignerRequest.builder()
                .resourceUrl(resourceUrl)
                .privateKey(privateKeyFile)
                .keyPairId(keyPairId)
                .expirationDate(expiration)
                .build();

        CloudFrontUtilities utilities = CloudFrontUtilities.create();
        SignedUrl signedUrl = utilities.getSignedUrlWithCannedPolicy(signerRequest);

        return signedUrl.url();

    } catch (Exception e) {
        log.error("CloudFront Signed URL 생성 실패: {}", s3Key, e);
        // Fallback to direct S3 URL
        return String.format("%s/%s", baseUrl, s3Key);
    }
}

기존 메서드 수정

// 업로드 시 CloudFront URL 반환
String viewUrl = generateCloudFrontSignedUrl(s3Key);
result.put("url", viewUrl);  // CloudFront 조회용
result.put("uploadUrl", presignedUrl);  // S3 업로드용

4단계: API 엔드포인트 분리

새로운 API 추가

@PostMapping("/upload-url")
public ResponseEntity<CommonResponse<Map<String, String>>> getUploadUrl(
        @RequestParam("filename") String filename,
        @RequestParam(value = "contentType", required = false) String contentType) {
    // S3 업로드 전용 API
}

@GetMapping("/view-url")
public ResponseEntity<CommonResponse<Map<String, String>>> getViewUrl(
        @RequestParam("s3Key") String s3Key) {
    // CloudFront 조회 전용 API
}

@PostMapping("/presigned-url")
@Deprecated
public ResponseEntity<CommonResponse<Map<String, String>>> getPresignedUrl() {
    // 기존 호환성을 위한 레거시 API
}

5단계: 프론트엔드 수정

s3Upload.ts 업데이트

// 1. 업로드 URL 요청 (새로운 엔드포인트)
response = await axios.post('/files/upload-url', null, {
  params: { filename: file.name, contentType: file.type }
});

// 2. S3 직접 업로드
await fetch(presignedData.uploadUrl, {
  method: 'PUT',
  body: file,
  headers: { 'Content-Type': presignedData.contentType }
});

// 3. CloudFront 조회 URL 생성
const viewUrlResponse = await axios.get('/files/view-url', {
  params: { s3Key: presignedData.s3Key }
});
const viewUrl = viewUrlResponse.data.data.viewUrl;

// 4. CloudFront URL 반환
return {
  url: viewUrl,  // CloudFront URL
  s3Key: presignedData.s3Key,
  originalName: presignedData.originalName,
  contentType: presignedData.contentType
};

📊 성과 및 효과

보안 강화

• 임시 URL: CloudFront Signed URL로 1시간 제한 접근
• 무단 접근 차단: 서명된 URL 없이는 파일 접근 불가
• 키 관리: AWS Key Pair 기반 안전한 서명 시스템

성능 향상

• CDN 활용: 전 세계 엣지 로케이션에서 빠른 파일 제공
• 캐시 효율: CloudFront 캐싱으로 S3 직접 접근 감소
• 대역폭 절약: 압축 및 최적화된 전송

비용 최적화

• S3 요청 감소: CloudFront 캐시 히트로 S3 GET 요청 감소
• 데이터 전송 비용: CloudFront 요금이 S3 직접 전송보다 저렴
• 글로벌 서비스: 지역별 최적화된 비용 구조

아키텍처 개선

• 관심사 분리: 업로드(S3) vs 조회(CloudFront) 명확한 역할 분담
• 확장성: CDN 기반으로 트래픽 증가에 유연한 대응
• 모니터링: CloudFront 메트릭으로 상세한 사용량 분석

🚀 배포 및 운영

CloudFront 배포 설정

# 1. CloudFront Distribution 생성
aws cloudfront create-distribution --distribution-config file://cloudfront-config.json

# 2. Key Pair 생성 및 등록
aws cloudfront create-public-key --public-key-config file://public-key-config.json

# 3. Private Key 서버 배포
scp cloudfront-private-key.pem server:/app/

모니터링 설정

• CloudWatch 메트릭: 요청 수, 캐시 히트율, 오류율
• 로그 분석: CloudFront 액세스 로그로 사용 패턴 분석
• 알림 설정: 오류율 임계값 초과 시 자동 알림

장애 대응

• Fallback 메커니즘: CloudFront 실패 시 S3 직접 URL 제공
• 키 로테이션: 정기적인 Key Pair 교체 프로세스
• 캐시 무효화: 긴급 시 CloudFront 캐시 즉시 무효화

🔍 트러블슈팅

자주 발생하는 문제

1. CloudFront Signed URL 생성 실패

원인: Private Key 파일 경로 오류 또는 권한 문제
해결: 파일 경로 확인 및 읽기 권한 부여

2. Key Pair ID 불일치

원인: CloudFront에 등록된 Key Pair ID와 설정값 불일치
해결: AWS 콘솔에서 Key Pair ID 재확인 후 설정 업데이트

3. 캐시 문제

원인: CloudFront 캐시로 인한 이전 버전 파일 제공
해결: 파일 업데이트 시 캐시 무효화 또는 버전 관리

성능 최적화 팁

1. 캐시 정책 최적화

{
  "CachePolicyId": "custom-policy",
  "TTL": {
    "DefaultTTL": 86400,
    "MaxTTL": 31536000
  }
}

2. 압축 활성화

{
  "Compress": true,
  "ViewerProtocolPolicy": "redirect-to-https"
}

3. 지역별 최적화

{
  "PriceClass": "PriceClass_100",
  "Restrictions": {
    "GeoRestriction": {
      "RestrictionType": "whitelist",
      "Locations": ["KR", "JP", "US"]
    }
  }
}

📈 향후 개선 계획

단기 계획 (1-2개월)

• 이미지 최적화: CloudFront에서 WebP 변환 및 리사이징
• 보안 강화: WAF 연동으로 DDoS 및 악성 요청 차단
• 모니터링 고도화: 실시간 대시보드 및 알림 시스템

중기 계획 (3-6개월)

• 멀티 CDN: CloudFront + 다른 CDN 조합으로 가용성 향상
• 엣지 컴퓨팅: Lambda@Edge로 동적 이미지 처리
• 비용 최적화: 사용 패턴 분석 기반 캐시 정책 자동 조정

장기 계획 (6개월+)

• 글로벌 확장: 지역별 최적화된 CDN 전략
• AI 기반 최적화: 머신러닝 기반 캐시 예측 및 프리로딩
• 완전 자동화: 인프라 코드화 및 자동 스케일링

💡 교훈 및 베스트 프랙티스

핵심 교훈

1. 점진적 전환: 기존 API 유지하면서 새로운 구조 도입
2. Fallback 필수: 항상 대안 경로 준비
3. 모니터링 우선: 변경 사항의 영향도 실시간 추적
4. 보안과 성능: 두 마리 토끼를 모두 잡을 수 있는 설계

베스트 프랙티스

• 설정 암호화: 민감한 CloudFront 설정은 반드시 암호화
• 키 관리: Private Key 보안 저장 및 정기 로테이션
• 캐시 전략: 파일 타입별 차별화된 캐시 정책
• 비용 모니터링: CloudFront 사용량 정기 검토 및 최적화

🎯 결론: S3 + CloudFront 분리 구조로 보안 강화 + 성능 향상 + 비용 최적화를 동시에 달성했습니다.

평소와 같이 커피 한 잔과 함께 모니터링 대시보드를 확인하던 중, 별 헤는 밤 서비스에 접속이 안 되는 것을 발견했다. 브라우저에는 무정하게도 ERR_TOO_MANY_REDIRECTS 오류만 반복되고 있었다.

"어제까지 잘 되던 사이트가 갑자기 왜...?"

🔍 첫 번째 용의자: Nginx 리다이렉트 중복

처음에는 당연히 Nginx 설정 문제라고 생각했다. 최근 배포 과정에서 메인 서버와 프론트엔드에 있는 nginx.conf 파일 둘 다 리다이렉트 코드가 중복되어 있었고, API 키를 여러 번 호출해야 하는 우리 웹서비스 특성상 이게 근본 원인일 거라 확신했다.

# 급하게 Nginx 설정 수정
vim /etc/nginx/nginx.conf
# 중복된 리다이렉트 규칙 제거
sudo systemctl reload nginx

다행히 수정 후 서비스가 정상화되었다. "역시 Nginx 문제였구나" 하며 안도의 한숨을 쉬었다.

😱 데자뷰: 또 다시 발생한 동일 증상

며칠 후, 서비스가 잘 굴러가고 있다고 생각하며 새로운 기능을 배포했다. 그런데...

또 같은 이슈가 발생했다!

이번에는 브라우저 오류가 아니라 서버 로그에서 더 심각한 문제를 발견했다:

2025-09-18T07:01:29.821+09:00 ERROR 1 --- [byeolnight] [main] 
Caused by: java.lang.IllegalArgumentException: 
Could not resolve placeholder 'app.security.jwt.secret' in value "${app.security.jwt.secret}"

"Nginx 문제가 아니었다... 진짜 원인은 따로 있었구나."

🕵️ 진짜 범인을 찾아서

"Config Server는 살아있는데 JWT만 죽었다?"

로그를 자세히 보니 이상한 점이 있었다:

✅ Located environment: name=byeolnight, profiles=[prod]
✅ MySQL 비밀번호: 정상 복호화
✅ Redis 비밀번호: 정상 복호화  
✅ AWS API 키들: 정상 복호화
❌ JWT 시크릿: Could not resolve placeholder

"다른 암호화된 설정들은 멀쩡한데 JWT 시크릿만 왜...?"

미스터리한 암호화 데이터

byeolnight-prod.yml 파일을 열어보니 JWT 시크릿이 이상했다:

# 정상적인 다른 설정들
password: '{cipher}4f645acb62e6302d47f02b2d3b88c8cda3c90e64f91d042dc9ff2613955ba***'

# 문제의 JWT 시크릿
jwt:
  secret: '{cipher}eaebecbd17000326cf1b0281b5e9b9c905f10300270c747f95207cea0c029d34***'

추리 결과:

• 파일 복사 과정에서 암호화 데이터 일부 손실?
• Git 커밋 시 인코딩 문제?
• 다른 암호화 키로 암호화된 이력?

"범인은... 손상된 암호화 데이터였다!"

🚑 응급처치: 일단 살려놓고 보자

"평문으로라도 일단 서비스부터 살리자!"

운영 서비스가 다운된 상황에서 원인 분석보다는 빠른 복구가 우선이었다.

# 응급처치: JWT 시크릿을 평문으로 변경
jwt:
  secret: 'byeolnight-jwt-secret-key-2025-very-long-and-secure-key-for-production-use-only'

# 서버 재시작
docker-compose restart app

"휴... 일단 서비스는 살아났다. 이제 진짜 해결책을 찾아보자."

🔧 근본 해결: Config Server로 재암호화

"encrypt-simple.bat, 너가 내 구원자다!"

평문으로 임시 해결한 후, 보안을 위해 제대로 된 암호화를 진행했다.

# 1단계: Config Server 시작
cd config-server
gradlew.bat bootRun

# 2단계: JWT 시크릿 재암호화
encrypt-simple.bat "byeolnight-jwt-secret-key-2025-very-long-and-secure-key-for-production-use-only"

터미널 출력:

Encrypting: "byeolnight-jwt-secret-key-2025-very-long-and-secure-key-for-production-use-only"

8bab426a814eb620e297d3a336d22ebf6ede3b285003154b24898d87ba743416***[새로운 암호화 키 생성됨]

"새로운 암호화 키가 생성되었다! 이제 이걸로 교체하자."

최종 해결: 새 암호화 키 적용

# byeolnight-prod.yml 최종 수정
jwt:
  secret: '{cipher}8bab426a814eb620e297d3a336d22ebf6ede3b285003154b24898d87ba743416***'

🎉 해피엔딩: 별 헤는 밤이 다시 빛났다

"드디어 정상 로그가 떴다!"

# 서버 재시작 후 로그 확인
docker logs -f byeolnight-app-1

기다리던 성공 로그:

✅ JwtAuthenticationFilter: Filter 'jwtAuthenticationFilter' configured for use
✅ TomcatWebServer: Tomcat started on port 8080 (http)  
✅ ByeolnightApplication: Started ByeolnightApplication in 28.808 seconds
✅ 별 헤는 밤이 다시 살아났습니다! 🌟

검증: 모든 기능이 정상 작동

• ✅ JWT 토큰 생성/검증 완벽
• ✅ 사용자 로그인/로그아웃 정상
• ✅ API 호출 인증 성공
• ✅ 소셜 로그인 (Google, Kakao, Naver) 정상
• ✅ 실시간 채팅 WebSocket 연결 성공

"이제야 마음 놓고 커피를 마실 수 있겠다... ☕"

🔧 사용된 도구 및 기술

Config Server 암호화 구조

# Config Server (application.yml)
encrypt:
  key: byeolnight-config-encryption-key-2025!@#$%^&*()
  fail-on-error: false

암호화 스크립트 (encrypt-simple.bat)

@echo off
echo Encrypting: "%1"
curl -u config-admin:config-secret-2024 ^
  "http://localhost:8888/encrypt" ^
  -d "%1" ^
  -H "Content-Type: text/plain"

JWT 설정 구조

@Component
public class JwtTokenProvider {
    public JwtTokenProvider(@Value("${app.security.jwt.secret}") String secret, 
                           StringRedisTemplate redisTemplate) {
        this.key = Keys.hmacShaKeyFor(secret.getBytes(StandardCharsets.UTF_8));
        this.redisTemplate = redisTemplate;
    }
}

📚 학습 포인트

Spring Cloud Config 암호화 특성

• 대칭키 암호화 (AES) 사용
• 시간 기반 만료 없음 (JWT와 다름)
• 암호화 키 일치 시 언제든 복호화 가능
• 데이터 무결성 중요

문제 해결 접근법

1. 증상 vs 원인 구분
2. 다른 설정과 비교 분석
3. 단계별 검증 (임시 → 영구 해결)
4. 재현 가능한 해결책 적용

운영 환경 고려사항

• Config Server 고가용성 필요
• 암호화 키 백업 및 관리
• 모니터링 및 알림 체계
• 롤백 계획 수립

🚀 향후 개선 방안

1. 모니터링 강화

# Config Server Health Check
management:
  endpoints:
    web:
      exposure:
        include: health,info,decrypt

2. 암호화 검증 자동화

# 배포 전 암호화 검증 스크립트
validate-config.sh byeolnight prod

3. 백업 전략

• Config 파일 Git 이력 관리
• 암호화 키 안전한 저장소 보관
• 복구 절차 문서화

🎓 이 사건에서 배운 교훈들

1. "증상과 원인은 다를 수 있다"

• 처음 ERR_TOO_MANY_REDIRECTS는 Nginx 문제로 보였지만
• 진짜 원인은 JWT 암호화 데이터 손상이었다
• 근본 원인을 찾지 않으면 같은 문제가 반복된다

2. "Config Server 암호화는 생각보다 취약하다"

• 파일 복사, Git 커밋 과정에서 데이터 손상 가능
• 정기적인 암호화 데이터 검증이 필요하다
• 백업된 암호화 키 관리의 중요성

3. "응급처치 → 근본해결 순서가 중요하다"

• 운영 서비스 다운 시: 빠른 복구 우선
• 안정화 후: 보안을 고려한 근본 해결
• 평문 → 재암호화 단계적 접근이 효과적

에필로그: 그날 밤, 별 헤는 밤 서비스는 다시 평화롭게 사용자들의 우주 이야기를 담아내고 있었다. 때로는 예상치 못한 곳에서 문제가 발생하지만, 차근차근 원인을 찾아 해결하는 과정이야말로 개발자의 진짜 실력이 아닐까? 🌙✨

운영체제 개념이 어렵게 느껴지는 분들을 위해, 복잡한 이론 대신 우리에게 익숙한 '화장실'을 비유로 들어 쉽게 이해해보자

등장인물 비유 정리

• 프로세스 (Process): 화장실을 이용하려는 사람
• 임계영역 (Critical Section): 한 번에 한 사람만 들어갈 수 있는 변기칸
• 자원 (Resource): 변기칸을 사용할 권한, 즉 열쇠
• 운영체제 (OS): 화장실을 관리하는 관리자

각 개념별 비유 설명

🔐 뮤텍스 (Mutex: Mutual Exclusion) 변기칸이 하나뿐인 화장실에서, 열쇠를 가진 사람만 화장실을 사용할 수 있는 상황입니다. 열쇠는 오직 한 사람에게만 주어지며, 그 사람이 나오기 전에는 다른 사람은 절대 들어갈 수 없습니다.

• 특징: 상호 배제(Mutual Exclusion)를 보장하며, 열쇠(자원)를 소유한 사람만 잠금을 해제할 수 있습니다.

⚖️ 세마포어 (Semaphore) 변기칸이 여러 개 있는 화장실에서, 동시에 여러 사람(예: 3명)이 들어갈 수 있는 상황입니다. 세마포어는 사용 가능한 변기 수(자원 수)를 숫자로 관리하며, 이 숫자가 0이 되면 다음 사람은 대기해야 합니다.

• 특징: 제한된 동시 접근을 허용하며, 열쇠(자원)를 소유하지 않은 사람도 다른 사람이 열쇠를 반납하면 사용할 수 있습니다.

🔒 락 (Lock) 임계영역(변기칸)에 들어간 사람을 보호하는 잠금장치입니다. Lock은 Mutex, Semaphore 등을 포괄하는 넓은 개념으로, 자원에 대한 접근을 제어하기 위해 사용되는 모든 잠금 기술을 의미합니다.

🧳 모니터 (Monitor) OS가 변기칸의 잠금과 조건 대기를 알아서 자동으로 관리해주는 스마트 화장실 시스템입니다. 사용자(개발자)는 락이나 조건 변수를 직접 조작할 필요가 없어 실수가 줄어듭니다.

• 예시: 변기칸마다 자동 잠금장치가 있어 사람이 들어가면 자동으로 잠기고, 사용 시간이 초과되면 자동으로 잠금이 해제되어 다음 사람이 이용할 수 있게 되는 구조입니다. 자바의 synchronized가 대표적인 예입니다.

🔄 스핀락 (Spinlock) 화장실 문 앞에서 대기자가 계속 문을 당겨보며 "혹시 문이 열렸나?" 확인하는 상황입니다.

• 특징: 문이 곧 열릴 것을 예상하고 CPU를 놓지 않고 기다리는 방식이라, 짧은 대기 시간에는 효율적이지만 대기 시간이 길어지면 CPU 낭비가 심해집니다.

⛔ 데드락 (Deadlock) A가 1번 변기칸의 열쇠를 갖고 2번 변기칸 열쇠를 기다리고, B가 2번 변기칸 열쇠를 갖고 1번 변기칸 열쇠를 기다리는 상황입니다. 서로 다른 자원을 점유하고, 서로의 자원을 기다리느라 아무도 변기칸을 사용할 수 없게 됩니다.

• 핵심: 단순한 자원 점유가 아니라 '서로 상대방의 자원을 기다리는' 상호 대기가 데드락의 본질입니다.

↔️ 문맥 교환 (Context Switching) 변기를 이용하던 사람이 다음 사람에게 '바톤 터치'를 하는 과정입니다. 화장실 관리자(OS)가 사용 중인 사람의 상태(어디까지 사용했는지)를 저장하고, 다음 사람을 호출하는 행위를 의미합니다.

🌍 스케줄링 (Scheduling) 다음에 변기칸을 사용할 사람을 화장실 관리자(OS)가 결정하는 과정입니다.

• 예시:
  • FIFO(선착순): 먼저 온 사람이 먼저 사용
  • 라운드 로빈(Round Robin): 모든 사람이 공평하게 일정 시간만 사용하고 다음 사람에게 넘기기

전체 흐름 요약

1. 스케줄링을 통해 화장실을 이용할 다음 사람이 결정됩니다.
2. 이용자가 변기칸에 들어가려 할 때, Lock, Mutex, Semaphore를 사용해 자원(변기칸)을 경쟁적으로 사용하지 않도록 제어합니다.
3. 한 사람의 사용이 끝나면 문맥 교환(Context Switching)이 발생하여 다음 사람이 화장실을 사용할 수 있게 됩니다.
4. 만약 여러 사람이 서로의 자원을 끝없이 기다리는 상황이 되면 데드락이 발생해 아무도 화장실을 이용할 수 없게 됩니다.

마무리: 이처럼 비유를 통해 OS 개념을 이해하면, 복잡한 이론을 쉽게 설명하고 면접에서도 당신의 뛰어난 설명력을 어필할 수 있습니다. 운영체제는 개발자의 필수 기초 지식이므로 반드시 짚고 넘어가세요!

"분산락이 필요한 이유가 뭔가요? Redis와 Redisson의 차이점은?"

🎯 왜 Redisson을 도입했을까?

기존 상황

• Redis Template: 단순한 캐싱과 세션 관리에 사용
• 동시성 문제: 포인트 지급, 출석체크 등에서 Race Condition 발생 가능
• 기술면접 대비: 분산 시스템에서의 동시성 제어에 대한 깊은 이해 필요

🏗️ 구현 과정에서 겪은 시행착오

1단계: 기본 구조 설계

@Service
public class RedissonCacheService {
    private final RedissonClient redissonClient;

    // 기본적인 캐시 기능부터 시작
    public <T> void set(String key, T value, Duration ttl) {
        RBucket<T> bucket = redissonClient.getBucket(key);
        bucket.set(value, ttl.toSeconds(), TimeUnit.SECONDS);
    }
}

2단계: 분산 맵 기능 추가 시 첫 번째 실수

// ❌ 처음 시도: RMap 사용
public <K, V> void putToMap(String mapName, K key, V value, Duration ttl) {
    RMap<K, V> map = redissonClient.getMap(mapName);
    map.put(key, value, ttl.toSeconds(), TimeUnit.SECONDS); // 컴파일 에러!
}

문제점: RMap은 개별 키에 TTL을 설정할 수 없음

3단계: RMapCache로 해결

// ✅ 해결: RMapCache 사용
public <K, V> void putToMap(String mapName, K key, V value, Duration ttl) {
    RMapCache<K, V> map = redissonClient.getMapCache(mapName);
    map.put(key, value, ttl.toSeconds(), TimeUnit.SECONDS); // 성공!
}

🤔 개발 중 고민했던 포인트들

1. "인수가 2개여야 하는데 4개로 입력되어 있어?"

// 고민: TTL 없는 버전 vs TTL 있는 버전
putToMap(mapName, key, value)           // 2개 인수
putToMap(mapName, key, value, ttl)      // 4개 인수

결론: 분산락 효율성을 위해 TTL 포함 버전 선택

• 자동 만료로 데드락 방지
• 메모리 효율성 확보
• 예측 가능한 생명주기 관리

2. RMap vs RMapCache 선택

🧹 코드 정리 과정

불필요한 코드 제거

// 제거된 코드들
- RMap import 및 getMap() 메서드 (RMapCache만 사용)
- get() 메서드의 Class<T> type 파라미터 (미사용)

최종 핵심 기능

• RBucket: 단순 키-값 저장 (TTL 지원)
• RMapCache: 분산 맵 저장 (개별 키 TTL 지원)

🎯 결론

Q: Redis와 Redisson의 차이점은?

A: Redis는 인메모리 데이터베이스이고, Redisson은 Redis 기반의 
   Java 분산 객체 및 서비스 프레임워크입니다.

   - Redis Template: 단순한 키-값 조작
   - Redisson: 분산락, 분산 컬렉션 등 고급 기능 제공

Q: 분산락이 왜 필요한가요?

A: 분산 환경에서 동시성 제어를 위해 필요합니다.

   예시: 포인트 지급 시스템
   - 사용자가 동시에 여러 요청을 보낼 때
   - 중복 지급 방지를 위한 락 필요
   - TTL로 데드락 방지

Q: RMap과 RMapCache의 차이점은?

A: 개별 키 TTL 지원 여부가 핵심 차이점입니다.

   - RMap: 맵 전체에만 TTL 설정 가능
   - RMapCache: 개별 키마다 다른 TTL 설정 가능
   - 분산락에서는 RMapCache가 더 적합

📈 도입 효과

기술적 효과

• 동시성 제어: Race Condition 방지
• 메모리 효율성: TTL 기반 자동 정리
• 확장성: 분산 환경에서의 안정성 확보

학습 효과

• 분산 시스템 이해도 향상
• 동시성 제어 메커니즘 학습
• 기술면접 대비 실무 경험 축적

🔮 향후 활용 계획

적용 예정 도메인

1. 포인트 시스템: 중복 지급 방지
2. 출석체크: 동시 요청 제어
3. 게시글 좋아요: 중복 클릭 방지
4. 채팅방 입장: 동시 접속 제어

추가 학습 계획

• 분산락 패턴 심화 학습
• 성능 테스트 및 최적화
• 모니터링 및 알람 시스템 구축

💡 회고

잘한 점

• 실무 중심 접근: 왜 도입하였는지 명확한 목표제시
• 점진적 개선: 문제 발견 → 해결 → 정리의 체계적 과정
• 코드 품질: 불필요한 코드 제거로 가독성 향상

아쉬운 점

• 성능 테스트 부족: 실제 부하 상황에서의 검증 필요
• 모니터링 미비: 분산락 사용량 및 성능 지표 수집 필요

다음 단계

• 실제 도메인 적용: 포인트 시스템에 분산락 적용
• 성능 측정: 락 획득/해제 시간 모니터링
• 장애 시나리오: 락 타임아웃, 네트워크 분할 등 대응 방안 수립

🎯 핵심 메시지

기술면접 대비를 위해 시작한 Redisson 도입이 실제 분산 시스템의 동시성 제어에 대한 깊은 이해로 이어졌습니다. 단순한 기술 스택 추가가 아닌, 실무에서 마주할 수 있는 문제들을 미리 경험하고 해결책을 준비하는 과정이었습니다.

내가 직접 객체를 생성하지 않고, Spring이 필요한 객체를 대신 주입해주는 개념

→ 객체 간 결합도를 낮추고 테스트 가능성을 높임

🔥 DI 방식 3가지

🆚 @Autowired vs @RequiredArgsConstructor

🍪 개발자 감각 비유

• @Autowired = 쟁반: 먼저 쟁반 놓고 나중에 이것저것 올림 (중간에 이상한 거 섞일 수 있음)
• 생성자 주입 = 쿠키틀: 처음부터 필요한 재료만 넣을 수 있는 틀, 안전하고 변경 불가

❌ @Setter는 왜 지양할까?

✅ 실무에선 @Getter + @Builder 조합 + 불변 객체 설계를 선호

🧪 Mock이란?

테스트용 가짜 객체

실제 동작은 하지 않지만 호출 여부 / 반환값 설정 등을 통해 테스트를 빠르고 안전하게 할 수 있음

✅ JUnit + Mockito 조합은 Spring Boot 테스트의 사실상 표준

✅ 실무 기준 요약

✅ 1. Partitioning (파티셔닝)

Partitioning은 하나의 데이터베이스 내에서 테이블 데이터를 여러 파티션(partition)으로 분할하는 기법입니다.

🔹 종류

• 수평 파티셔닝 (Horizontal Partitioning)

  행(Row) 기준으로 데이터 분할

  → 예: 사용자 ID 110000 / 1000120000 등

• 수직 파티셔닝 (Vertical Partitioning)

  열(Column) 기준으로 데이터 분할

  → 예: 자주 조회되는 컬럼 / 드물게 쓰이는 컬럼 구분

🔹 장점

• 쿼리 성능 최적화 (필요한 파티션만 조회)
• 데이터 관리 및 유지보수 용이
• 백업 및 복구 단위 설정 가능

🔹 단점

• 잘못된 파티셔닝 설계 시 성능 저하
• JOIN/집계 연산 복잡해질 수 있음
• 단일 DB 서버에 의존

✅ 2. Sharding (샤딩)

Sharding은 데이터를 여러 개의 DB 서버에 분산시켜 저장하는 방식입니다.

수평 파티셔닝을 분산 시스템 수준으로 확장한 개념입니다.

🔹 샤딩 방식

• Range-based Sharding: 값의 범위로 샤드 분할
• Hash-based Sharding: 키 값을 해시로 계산하여 샤드 결정
• Directory-based Sharding: 라우팅 테이블로 샤드 위치 추적

🔹 장점

• 수평 확장성 (서버 추가로 확장 가능)
• 부하 분산
• 장애 격리 가능

🔹 단점

• 샤딩 로직 복잡 (개발/운영 부담)
• Cross-shard JOIN, 트랜잭션 어렵다
• 샤드 재배치(Migration) 까다로움

💼 실무 활용 사례

🔹 Partitioning

📦 아카이빙이란…

📁 "오래된 파일을 백업 폴더로 옮기는 것"

⛔️ "삭제하는 게 아니라, 덜 중요한 위치로 보내는 것"

🔹 Sharding

🧠 보완 팁

• Partitioning은 MySQL, PostgreSQL, Oracle 등에서 기본 기능으로 제공
• Sharding은 MongoDB, Cassandra, Vitess, Citus 등 분산 DB에서 자주 사용
• 둘은 함께 사용하는 경우도 많음 (ex. 샤딩된 DB 안에 파티셔닝된 테이블)

🖼️ 구조 다이어그램

✅ Partitioning vs Sharding 비유 정리

📦 Partitioning (파티셔닝)

하나의 창고 안을 구역별로 나눠서 데이터 관리

• 창고는 하나지만
• 그 안에서 구역(파티션)을 나눠서 월별, ID별, 카테고리별 등으로 데이터를 관리

🟡 예시

복사편집
하나의 사용자 테이블을 월별로 나눔
└─ 1월 파티션
└─ 2월 파티션
└─ 3월 파티션

📌 특징 요약

• DB 인스턴스는 하나
• 성능 최적화, 관리 편의를 위한 내부 분할
• DBMS가 직접 파티션 처리 가능

🏢 Sharding (샤딩)

창고를 아예 여러 개 지어서 데이터를 나눠 보관

• 서울 지점에는 서울 고객 데이터
• 부산 지점에는 부산 고객 데이터
• 대구 지점에는 대구 고객 데이터

👉 이때 각 지점이 샤드(Shard)입니다.

🟢 핵심 개념 정리

• 양식은 똑같다 → 같은 테이블 구조 (스키마)
• 보관 중인 데이터는 다르다 → 지역별, ID 범위별 데이터 분산
• 지점끼리는 독립적이다 → DB 인스턴스도 각각 따로 존재

📌 특징 요약

• DB 인스턴스가 여러 개
• 대규모 시스템에서 확장성과 성능을 위해 사용
• 샤딩 로직은 직접 구현하거나 미들웨어 사용 필요

“왜 요청은 성공했는데 브라우저는 응답을 못 받지?”
라는 혼란이 생기죠.

오늘은 이 CORS(Cross-Origin Resource Sharing) 개념을
스타벅스 비유로 쉽고 재밌게 설명해보겠습니다. 😎

🏬 배경 설정

우리는 제가 운영중인 프로젝트를 기준으로 설명해볼게요:

• 프론트엔드 (React) → https://byeolnight.com
• 백엔드 (Spring Boot) → http://localhost:8080 (또는 내부 API 주소)
• Nginx → 모든 요청을 받아 React 빌드 파일 or Spring API로 전달

🎭 비유 등장인물

🧾 시나리오

1. 손님이 카페에 들어온다

• 유저가 https://byeolnight.com 에 접속
• React 앱이 로딩되고, 카페 화면이 브라우저에 뜸

2. 손님이 “아이스 아메리카노 하나요~” 버튼 클릭

• React 앱에서 /api/post/create로 주문 요청을 보냄
• 이 요청은 Nginx를 통해 Spring 서버로 전달됨

3. 바리스타가 주문을 만들기 전에, 포스기(CORS)가 주문서를 스캔

• 포스기: “이 요청은 어디서 온 거지?”
• 요청 Header에 있는 Origin: https://byeolnight.com 확인

✅ 만약 백엔드에서 허용했다면?

Spring 서버가 응답에 이렇게 알려줌:

Access-Control-Allow-Origin: https://byeolnight.com
Access-Control-Allow-Credentials: true

포스기 OK! 바리스타는 주문을 만들어 손님에게 응답 전달 → 성공!

❌ 만약 허용하지 않은 Origin에서 요청했다면?

손님은 실제로는 https://evil-cafe.com에서 요청했는데, Spring 서버는 이 Origin을 허용하지 않음.

포스기: “어? 이 손님은 우리 매장 손님 아닌데?”
→ 주문 거절! (CORS 에러 발생)

🔒 CORS가 왜 필요한가요?

브라우저는 보안상, 다른 Origin에서 오는 요청을 무조건 신뢰하지 않아요.
특히 쿠키 인증, 민감한 데이터 요청이 포함되면 더욱 엄격해집니다.

그래서 서버는 반드시 명시적으로 허락된 Origin만 허용해야 해요.

👀 개발자가 자주 마주치는 에러

Access to fetch at 'http://localhost:8080/api/user' 
from origin 'http://localhost:3000' has been blocked 
by CORS policy: No 'Access-Control-Allow-Origin' header is present.

→ 요청은 갔는데 응답이 “CORS 정책 위반”으로 막힌 경우입니다.

🛠️ Spring Boot에서 CORS 설정하기

@Configuration
public class WebConfig implements WebMvcConfigurer {
  @Override
  public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/api/**")
      .allowedOriginPatterns("https://*.byeolnight.com")
      .allowedMethods("GET", "POST", "PUT", "DELETE")
      .allowCredentials(true);
  }
}

✅ 핵심 포인트:

• allowedOriginPatterns: 와일드카드 지원 (https://*.byeolnight.com)
• allowCredentials(true): 쿠키 인증 허용 시 꼭 필요
• allowedMethods: 허용할 HTTP 메서드 지정

✅ 비유 요약 정리

🧠 한 줄 정리

CORS는 백엔드가 “이 요청, 진짜 우리 손님 맞아?”를 판단하는 보안 절차다.
설정 안 하면, 요청은 가도 브라우저가 응답을 끝까지 못 받는다.

✍️ 마치며

기술적인 개념도 중요하지만, 이렇게 비유를 통해 감각적으로 이해하는 게
실전에서 에러를 빠르게 파악하고 대응하는 데 훨씬 큰 도움이 됩니다.

📌 여러분도 이제부터 브라우저 콘솔에 CORS 에러가 뜨면, 포스기가 주문을 거절한 장면을 떠올리세요. 바리스타는 아무 문제 없고, 문 앞에서 보안이 막은 거니까요!

이번 후기에선 단순한 요약을 넘어서,
제가 실제로 느끼고 배운 점, 그리고 실무와 포트폴리오에 어떻게 적용할지까지 함께 정리해보려 합니다.

✅ 행사 전체 분위기

• 장소: 스페이스쉐어 삼성 B1 (서울 강남구)
• 참가자: 현업 백엔드 개발자 + 커뮤니티 중심 개발자들
• 특징: Track 1 / Track 2 분리, 자유롭게 이동 가능

슬로건이 정말 인상 깊었습니다.

“빨리 가려면 혼자가고, 멀리 가려면 함께 가라.”

그 말처럼, 기술만이 아니라 동료 개발자들과 함께 성장할 수 있는 커뮤니티 문화가 강하게 느껴졌습니다.

🧭 내가 선택한 세션 루트

🔍 실전! MSA 트랜잭션 개발 가이드 – 김용욱

주제 요약

• MSA에서 데이터 정합성 유지
• Saga / Outbox / Compensation 등 실제 사례 중심의 분산 트랜잭션 설명

기억에 남는 내용

• 서비스 간 동기 호출보다 이벤트 기반 처리가 실무에서 더 안전하다는 점
• "완벽한 일관성은 포기하되, 예측 가능한 흐름은 보장하라" 는 설계 철학

내가 얻은 인사이트

📌 내 프로젝트의 게시글 작성 → 알림 발송 로직에 Outbox 패턴 적용할 계획
📌 트랜잭션 경계와 이벤트 발행 타이밍을 더 명확히 관리할 필요성 느낌

🧱 카카오뱅크 Spring Boot Starter – 손수민

주제 요약

• 공통 기능을 사내 starter 모듈로 만들어서 서비스별로 쉽게 사용하게 만든 구조 소개

재미있었던 표현

"하울의 움직이는 성 같은 레거시 시스템을 해체하기 위한 모듈화 전략"

Starter에 포함된 주요 기능

• 고정 길이 메시지 직렬화 (Jackson Custom Serializer)
• 사내 API용 HTTP Client 추상화
• 분산 트레이싱: traceId + baggage 구조

내가 얻은 인사이트

📦 공통 로깅, 예외, 인증 모듈을 따로 분리해서 나도 starter 구조 연습해볼 계획

⚙️ 레일웨이 지향 프로그래밍과 Spring – 이선협

주제 요약

• 함수형 예외 흐름 처리 전략: ROP (Railway Oriented Programming)
• 성공/실패 흐름을 명시적으로 분기 처리
• Result, Either, recover, fold, panic 등의 개념 활용

인상 깊었던 문장

"예외는 던지는 게 아니라, 다루는 것이다. 성공/실패 모두 하나의 값이다."

Spring에서의 적용 팁

• @Transactional은 예외 발생 시만 rollback → Result.failure는 rollback 안 됨
• 따라서 필요한 경우 명시적으로 .orElseThrow()를 사용해 예외로 전환해야 함

내가 얻은 인사이트

Result<User> user = validate(input)
  .flatMap(this::findUser)
  .flatMap(this::verifyPassword)
  .orElseThrow(UnauthorizedException::new);

💬 그 외 세션 요약 (간단 정리)

• 올리브영 물류 시스템 개선기

  • 운영 현장의 물류 흐름을 개발적으로 풀어낸 흥미로운 사례
  • 실측 데이터 기반 개선 접근이 좋았음

• Amazon Q Developer + 생성형 AI

  • AI가 점점 "함께 개발하는 팀원"이 되어가고 있음을 실감

• HR SaaS 인가 플랫폼 설계

  • 다양한 ABAC/RBAC 전략의 장단점 비교
  • 실무에서 느낀 보안 설계 현실이 인상 깊었음

🧠 행사에서 얻은 깨달음

• 단순히 “기능 구현”이 아닌, "어떻게 구조화하고 설계할 것인가"가 실력의 기준
• 설계를 잘 한다는 건, 공통성과 예외 흐름을 통제 가능하게 만든다는 것
• 커뮤니티 속 개발자들의 경험을 듣는 건 그 자체로도 설계 스킬을 높이는 길

🚀 나의 적용 계획

• Result<T> 도입해서 서비스 흐름 개선 + rollback 전략 실험
• 알림/이벤트 처리 로직에 Outbox 적용
• 공통 모듈 분리 → mini spring-boot-starter 패키징 시도
• Kotlin 기반 ROP 실험 (직접 모나드 구현)

🙏 마치며

이번 SpringCamp 2025는 단순한 기술 컨퍼런스가 아니었습니다.
“왜 이렇게 코드를 짜야 하는가?”라는 질문을 스스로에게 던지는 계기였고,
앞으로 개발자로서 한 단계 더 나아가기 위한 훌륭한 이정표였습니다.

내년에도 꼭 참석하고 싶고,
그땐 청중이 아닌 발표자 자격으로 무대에 서는 걸 목표로 삼아봅니다.

감사합니다, KSUG 🙇‍♂️

Spring Security에서 실제 인증 로직을 담당하는 핵심 컴포넌트

• 사용자의 ID/PW 또는 JWT 토큰 등으로부터 인증을 수행하고
• 인증된 사용자 정보(Authentication)를 반환함
• 다양한 인증 방식을 Provider로 분리할 수 있음 (예: Form Login, JWT, OAuth2 등)

🧠 동작 구조 요약

AuthenticationManager
      ↓ (delegates)
AuthenticationProvider(s)
      ↓
authenticate() 수행 → 성공 시 Authentication 객체 반환

• AuthenticationManager는 여러 Provider 중 하나에 위임하여 인증 수행
• supports() 메서드로 어떤 타입의 인증을 처리할지 판단

🔧 커스텀 구현 예시 (JWT 기반)

@Component
public class JwtAuthenticationProvider implements AuthenticationProvider {

    private final UserDetailsService userDetailsService;
    private final JwtTokenProvider jwtTokenProvider;

    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String token = (String) authentication.getCredentials();
        String username = jwtTokenProvider.getUsername(token);

        UserDetails userDetails = userDetailsService.loadUserByUsername(username);
        if (!jwtTokenProvider.validateToken(token, userDetails)) {
            throw new BadCredentialsException("Invalid JWT token");
        }

        return new UsernamePasswordAuthenticationToken(userDetails, token, userDetails.getAuthorities());
    }

    public boolean supports(Class<?> authentication) {
        return JwtAuthenticationToken.class.isAssignableFrom(authentication);
    }
}

⚙ JwtAuthenticationToken 클래스 예시

public class JwtAuthenticationToken extends UsernamePasswordAuthenticationToken {
    public JwtAuthenticationToken(String token) {
        super(null, token);
    }
}

🧩 연동 구조 요약

1. JWT 필터에서 토큰 추출
2. JwtAuthenticationToken을 생성하여 AuthenticationManager에 전달
3. AuthenticationManager → JwtAuthenticationProvider로 위임
4. Provider에서 검증 후, 인증 완료된 Authentication 객체 반환
5. SecurityContextHolder에 저장

🧠 면접용 정리 멘트

“AuthenticationProvider는 Spring Security에서 실질적인 인증 로직을 담당하는 컴포넌트입니다. JWT 기반 인증의 경우 커스텀 Provider를 구현해 토큰에서 사용자 정보를 추출하고, 인증된 Authentication 객체를 반환함으로써 유연한 인증 방식을 구성할 수 있습니다.”

스프링 시큐리티는 필터 기반으로 작동하며, 인증/인가 과정을 체계적으로 분리하여 처리함. FilterChain → AuthenticationFilter → AuthenticationManager → Provider 흐름으로 구성됨.

🔁 전체 인증 흐름 순서

1. 클라이언트 요청

• 로그인 시: /login, 또는 사용자 지정 엔드포인트
• 일반 요청 시: /api/** 등

2. Security Filter Chain

• 요청이 들어오면 FilterChainProxy에서 등록된 시큐리티 필터 체인을 거침

3. 주요 필터 구성

🧩 JWT 사용 시 흐름 (커스텀 인증 필터 포함)

클라이언트 → 요청
        ↓
SecurityFilterChain (여러 필터들)
        ↓
✅ JwtAuthenticationFilter (OncePerRequestFilter 상속)
        ↓
JWT 검증 & 사용자 정보 추출
        ↓
SecurityContextHolder.setAuthentication(...)
        ↓
인증 성공 → 다음 필터로 전달

🔒 인증 후 흐름

• Authentication 객체가 SecurityContextHolder에 저장됨
• 이후 컨트롤러/서비스에서 @AuthenticationPrincipal, SecurityContextHolder.getContext().getAuthentication() 등으로 접근 가능

📦 주요 클래스 요약

🧠 면접용 정리 멘트

“Spring Security는 필터 기반 구조로 요청이 들어오면 먼저 여러 보안 필터를 거칩니다. JWT를 사용하는 경우 OncePerRequestFilter를 상속한 커스텀 필터에서 토큰을 검증하고, 인증 정보를 SecurityContextHolder에 저장하여 이후 인가 처리까지 연동되도록 구성합니다.”

자바에서 다수의 요청을 처리하기 위해 미리 생성된 쓰레드 집합(Pool)을 재사용하는 구조

• 매번 새 쓰레드를 만들지 않고, 일정 개수의 쓰레드를 반복 사용하여 성능을 최적화
• 주로 비동기 작업, 백그라운드 작업, 대규모 요청 처리 등에 사용됨

🧠 왜 필요한가?

⚙ 핵심 구성 요소

🔧 사용 예시 코드

ExecutorService executor = Executors.newFixedThreadPool(5);

for (int i = 0; i < 10; i++) {
    executor.submit(() -> {
        System.out.println(Thread.currentThread().getName() + " 작업 처리 중");
    });
}

executor.shutdown();

☑️ Executors 팩토리 메서드 종류

🔍 실무에서 주의할 점

• Executors는 내부적으로 ThreadPoolExecutor를 감싸고 있어 세밀한 제어가 어려움
• 실무에서는 직접 ThreadPoolExecutor를 생성해 큐 종류, 정책, 예외 처리 전략 등을 명시적으로 설정함

🧠 면접용 정리 멘트

“ThreadPool은 자바에서 다수의 작업을 효율적으로 처리하기 위한 구조로, 미리 생성된 쓰레드를 재사용하여 성능을 최적화합니다. 주로 ExecutorService와 BlockingQueue를 활용하고, 실무에서는 직접 ThreadPoolExecutor를 설정해 자원 제어와 예외 처리 전략을 구성합니다.”

JWT는 무상태 인증 방식이기 때문에, 토큰을 클라이언트에만 저장하면 서버는 상태를 기억하지 못함. 이를 보완하기 위해 Redis를 사용해 로그아웃된 토큰이나 강제로 만료시킬 토큰을 관리하는 구조를 설계함.

🧭 인증 흐름 전체 구조

1. 로그인 시

• 클라이언트가 로그인 요청 → 서버가 JWT 발급 (access + optional refresh)
• 토큰은 클라이언트에 저장 (예: localStorage, cookie)

2. 요청 시

• 클라이언트가 Authorization 헤더에 토큰 포함하여 API 호출
• 서버에서는 필터에서 JWT를 디코딩 → 사용자 정보 추출
• 유효하다면 SecurityContextHolder에 사용자 정보 저장 → 이후 요청에서 인증 정보 사용 가능

3. 로그아웃 시

• 클라이언트가 로그아웃 요청
• 서버는 해당 JWT를 Redis 블랙리스트에 저장 + TTL은 토큰의 남은 만료 시간만큼 설정
• 이후 이 토큰으로 요청이 오면 Redis에서 차단됨

4. 토큰 검증 시 (필터 내부)

if (isValid(jwt)) {
    if (!redisService.hasKey(jwt)) {
        Authentication auth = getAuthentication(jwt);
        SecurityContextHolder.getContext().setAuthentication(auth);
    } else {
        // 블랙리스트에 등록된 토큰 → 인증 실패 처리
    }
}

📦 Redis의 역할

🔍 Redis 없이 구현하는 대안은?

➡️ 결론: Redis는 토큰 무효화와 세션 제어를 실시간으로 처리하면서도 퍼포먼스까지 확보할 수 있는 최적의 선택지

🧠 면접용 정리 멘트

“JWT는 무상태 인증 구조이기 때문에, 로그아웃이나 강제 만료가 어려운 단점이 있습니다. 이를 보완하기 위해 Redis에 블랙리스트를 관리하고 TTL을 설정함으로써, 서버 측에서 토큰을 실시간으로 무효화할 수 있도록 했습니다.”

JVM은 실행 중인 Java 애플리케이션의 메모리를 아래와 같이 구분해 관리함:

• Heap 영역: 객체가 저장되는 공간 (GC의 주요 대상)

  • Young Generation (Eden, Survivor)
  • Old Generation (Tenured)

• Method Area (PermGen / Metaspace): 클래스 정보, 메서드 정보

• Stack: 각 쓰레드마다 생성되는 프레임 기반 메모리 (지역 변수 저장)

• PC Register, Native Stack 등: 기타 JVM 내부 운영용

📦 Young Generation 구조 (객체 생명주기 중심)

1. Eden 영역

• new 연산자로 생성된 객체가 처음 저장되는 곳
• 가장 많은 객체가 여기서 생성되고, 대부분 GC 대상됨

2. Survivor 영역 (S0 / S1)

• Eden에서 Minor GC로 살아남은 객체가 잠깐 머무는 곳
• S0, S1 두 개가 있고, 번갈아가며 복사/교환
• 여러 번 Minor GC에서 살아남으면 Old로 승격

3. Old 영역 (Tenured)

• 장기간 살아남은 객체가 이동하는 공간
• 공간이 부족하면 Major GC(또는 Full GC) 발생
• GC 성능과 STW(Stop The World) 현상에 큰 영향

🔁 GC 동작 방식 요약

💡 객체 생명 흐름 정리 (직관적 설명)

[Eden] → [Survivor S0] → [Survivor S1] → [Old]
 (갓 생성됨)     (1번 생존)       (2~3번 생존)    (오래 살아남음)

• Eden: 메서드 호출로 생성된 객체가 저장됨
• Survivor: 살아남은 객체가 Old로 갈지 대기하는 중간 단계
• Old: 여러 번 살아남은 객체를 위한 장기 저장 공간

🔚 면접용 정리 멘트

“JVM은 새로 생성된 객체를 Eden에 저장하고, GC에서 살아남으면 Survivor → Old 순으로 이동시킵니다. 객체 생존 시간에 따라 영역을 분리해서, GC 비용을 최소화하려는 구조입니다.”

“Minor GC는 Eden이 가득 찼을 때 발생하고 빠르며, Major GC는 Old 영역이 가득 찰 때 발생해 상대적으로 느리고 Stop-The-World를 유발할 수 있습니다.”