Learning

개발하면서 배우고 공부한 내용들을 주제별로 정리합니다. 백엔드 학습은 기초 → 스프링 → 데이터/설계 → 운영/모니터링 → 심화/시스템 설계 → 복습(Q&A) 모듈로 나누어 지속적으로 업데이트하며, 커리큘럼·주제 카드·최신 노트가 자동으로 정렬됩니다. 학습 순서는 타임라인 페이지에서 study_order 기준으로 확인할 수 있습니다.

• 학습 타임라인: /learning/timeline/에서 study_order 순서대로 확인합니다.
• 커리큘럼 카드: Backend Roadmap 토픽 글이 자동으로 순서대로 표시됩니다.
• 주제 카드: Spring/Database/Kafka/DevOps 등 토픽별 최신 글을 한 번에 확인합니다.
• 최근 학습 노트: 최신순 정렬, 더보기/토픽별 필터 지원.

처음 온 사람을 위한 진입 경로

글이 많아질수록 가장 큰 문제는 “좋은 글이 있는가"보다 “지금 내 상황에서 무엇부터 읽을지"입니다. 그래서 Learning 영역은 단순 목록이 아니라, 목표별로 다른 출발점을 잡도록 설계합니다.

• 백엔드 기초가 흔들리는 경우: 커리큘럼 개요를 먼저 읽고, 1단계: 백엔드 기초 다지기에서 네트워크·자료구조·JVM·OS 글을 순서대로 봅니다. 이 단계에서는 깊은 설계보다 용어를 정확히 설명하는 힘을 우선합니다.
• 스프링/JPA 실무 감각을 올리고 싶은 경우: 2단계: 스프링 핵심 공략과 3단계: 데이터베이스 & 데이터 시스템을 묶어서 봅니다. 트랜잭션, 영속성 컨텍스트, 인덱스, 락은 따로 공부하면 쉬워 보여도 실제 장애에서는 함께 나타납니다.
• 운영과 장애 대응이 약한 경우: 5단계: 시스템 안정성 & 회복탄력성에서 timeout/retry/circuit breaker를 잡고, 6단계: 클라우드 네이티브 & DevOps에서 배포·관측성·CI/CD로 확장합니다.
• 면접 답변을 정리해야 하는 경우: 복습(Q&A)와 백엔드 면접 실전 트랙을 함께 봅니다. 답변은 암기보다 “결론 → 원리 → 사례 → 트레이드오프” 구조로 정리하는 것을 목표로 합니다.

읽는 순서보다 중요한 것

이 섹션의 글은 완독률보다 재사용성을 더 중요하게 봅니다. 한 글을 읽고 나서 아래 세 가지 중 하나라도 남으면 성공입니다.

1. 선택 기준: “언제 Redis Cache를 쓰고, 언제 DB 인덱스/쿼리 개선을 먼저 해야 하는가"처럼 의사결정 기준을 한 줄로 남깁니다.
2. 재현 가능한 예시: 로그 한 줄, SQL 실행 계획, 작은 테스트 코드처럼 다시 실행할 수 있는 근거를 남깁니다.
3. 틀린 가정 수정: 기존에 막연히 알고 있던 내용을 “이 상황에서는 맞고, 저 상황에서는 틀리다"로 좁힙니다.

특히 데이터베이스, 메시징, 분산 시스템 글은 개념을 읽는 것만으로 끝내기 쉽습니다. 가능하면 각 글을 읽은 뒤 “내 서비스라면 어디에 이 문제가 숨어 있을까"를 생각하고, 관측 지표나 실패 시나리오를 하나 붙여보는 방식으로 복습합니다.

운영 가능한 학습 루프

학습 글이 많아질수록 중요한 것은 글 수가 아니라 다음 행동을 만들어 주는가입니다. 그래서 Learning 섹션의 글은 되도록 아래 루프 중 하나에 연결되도록 운영합니다. 이 기준이 있으면 새 글을 추가할 때도 단순 요약인지, 실제로 다시 꺼내 쓸 수 있는 지식인지 판단하기 쉬워집니다.

예를 들어 API 버전 관리 글을 읽었다면 “URL Path 방식이 가장 유명하다"에서 멈추지 않습니다. 외부 파트너 API인지, 모바일 앱처럼 배포 통제권이 낮은 클라이언트인지, 캐시 키와 로그에서 버전을 구분할 수 있는지까지 확인합니다. 그 다음에는 deprecated API의 호출량, 고유 클라이언트 수, 차단 플래그, sunset 공지 경로를 같이 적어야 운영 가능한 지식이 됩니다.

데이터베이스 글도 마찬가지입니다. 인덱스 원리를 읽었다면 실제 쿼리에서 EXPLAIN 결과가 어떻게 달라지는지, 락/트랜잭션 글을 읽었다면 대기 이벤트와 timeout 설정이 어디에서 관측되는지까지 이어 붙입니다. 이 블로그의 학습 노트는 “맞는 설명"보다 “장애 전에 확인할 수 있는 체크포인트"를 더 가치 있게 봅니다.

새 글을 보강할 때는 아래 순서로 품질을 확인합니다.

1. 선행 지식 연결: 모듈, 타임라인, 관련 글 중 최소 하나와 연결합니다.
2. 실무 예시 추가: 로그, SQL, 설정값, API 계약, 배포 절차 중 하나를 예시로 둡니다.
3. 실패 조건 명시: 이 방법이 틀릴 수 있는 상황을 적습니다.
4. 복습 질문화: 나중에 Q&A 글로 옮길 수 있는 질문을 1개 이상 남깁니다.
5. 운영 체크리스트화: 바로 점검할 지표나 파일, 대시보드, 명령을 한 줄로 정리합니다.

이 루프를 지키면 글을 추가할수록 단순 아카이브가 아니라 개인 지식 베이스에 가까워집니다. 특히 시스템 설계, 분산 처리, 데이터 일관성처럼 추상도가 높은 주제는 “개념 설명 → 선택 기준 → 장애 징후 → 되돌리는 방법"까지 이어질 때 다시 읽을 가치가 생깁니다.

최근 보강된 운영 학습 경로

실시간 기능을 다루는 팀이라면 장기 연결 운영 글을 따로 묶어 읽는 편이 좋습니다. WebSocket, SSE, gRPC streaming은 일반 HTTP API처럼 요청 단위로만 보면 배포와 장애 대응 기준이 자주 빗나갑니다. 연결 하나가 사용자 세션, 구독 상태, 마지막 이벤트 위치, heartbeat, backpressure 상태를 함께 들고 있기 때문입니다.

추천 순서는 아래처럼 잡습니다.

1. Graceful Shutdown에서 프로세스 종료와 readiness 전환의 기본 흐름을 먼저 봅니다.
2. Drain-aware 배포 플레이북으로 새 트래픽 차단, 기존 요청 대기, 강제 종료 조건을 운영 절차로 넓힙니다.
3. WebSocket/SSE 패턴과 gRPC 서비스 설계에서 프로토콜별 연결 유지 방식과 재연결 전제를 확인합니다.
4. WebSocket·SSE·gRPC 장기 연결 드레이닝 플레이북에서 배포, 스케일다운, 장애 격리 중 실제로 어떤 close code, retry hint, drain timeout, replay buffer를 둘지 정리합니다.
5. 로드밸런서 헬스체크와 Session Affinity와 Stateful Routing로 인프라 계층의 연결 유지, sticky session, 상태 복구 기준을 붙입니다.

이 경로의 핵심 질문은 “연결을 얼마나 오래 살릴 것인가"가 아닙니다. 끊겨도 사용자가 예측 가능하게 복구되는가, 재연결이 인증/DB/메시징 계층의 두 번째 장애를 만들지 않는가, 마지막 이벤트 위치를 근거로 메시지 유실을 보정할 수 있는가입니다. 그래서 실시간 서비스 글을 읽을 때는 항상 아래 체크포인트를 같이 남깁니다.

• readiness false 이후에도 살아 있는 연결 수와 최대 drain 시간을 관측하는가?
• 클라이언트 재연결에 jitter, backoff, 서버 제공 retry_after가 있는가?
• last_event_id, offset, sequence처럼 누락분을 다시 받을 기준이 있는가?
• sticky session에 기대는 상태와 durable store에 남겨야 하는 상태를 분리했는가?
• 배포 drain과 보안 긴급 종료의 timeout을 다르게 가져갈 수 있는가?

학습 방법

• 개념 → 실험 → 기록: 읽고 끝내지 말고, 작은 코드/재현으로 확인한 뒤 내 말로 정리합니다.
• 선택 기준 만들기: “언제 A, 언제 B”를 한 줄이라도 남기면 실전에서 재사용됩니다.
• 복습(Q&A): 막힌 포인트를 질문/답 형태로 쌓아두면 다시 꺼내보기 쉬워집니다.

복습 체크리스트

• 글 제목만 보고 핵심 개념을 30초 안에 설명할 수 있는가?
• “장점"뿐 아니라 장애·운영·비용 관점의 주의점을 하나 이상 말할 수 있는가?
• 같은 주제의 Q&A 글이나 예제 글로 이동해 이해를 검증했는가?
• 실무에서 바로 적용하기 전에 필요한 전제 조건과 롤백 방법을 적었는가?
• 다음에 이어 읽을 글을 하나 정했는가?

Learning 메인은 앞으로도 “글 모음"보다 “학습 경로” 역할을 우선합니다. 새 글이 추가되면 해당 글이 어느 모듈에 들어가는지, 어떤 선행 지식이 필요한지, 어떤 Q&A로 복습할 수 있는지를 함께 보강하는 방식으로 운영합니다.