DB 모델링·확장부터 Spring Batch, DDD·헥사고날, 그리고 기술 선택의 근거
43편
CI/CD 일곱 편 중 둘째다. 파이프라인이 서 있는 첫 전제인 형상관리를 연다. CD가 사람 손을 어디까지 뗄 수 있는지 그 경계를 먼저 긋고, Git이 파일을 Working Directory · Stage(Index) · Repository 세 곳에 나눠 두는 구조에서 「되돌린다」가 왜 두 번 갈리는지, 그리고 실무 배포의 기준이 왜 브랜치가 아니라 태그인지까지 간다.
알림 생성과 알림 조회를 한 서버에 두면 무엇이 먼저 마르는지, 좋아요 서비스가 알림 서버를 동기로 부르는 순간 장애가 왜 중요도의 반대 방향으로 흐르는지를 먼저 본다. 그렇게 서버를 쪼갠 대가로 생기는 도메인 코드 두 벌 문제를 한 프로젝트 안의 멀티모듈로 받아 내고, 의존 방향과 Gradle 선언 키워드가 그 경계를 실제로 강제하는 자리까지 내려간다. 마지막은 여기서 멈출 것인가 MSA로 갈 것인가의 기준이다.
저장소를 고르기 전에 정리해야 할 것들을 다룬다. 관계형 모델이 「관계」를 물리적으로 어디에 저장하는지, NoSQL 네 유형이 각각 무엇을 잘하고 못하는지, 그리고 제품 선택을 성능이 아니라 문제 해결·비용·유지·보수로 판정하는 이유다.
개체-관계 모델의 네 요소와 카디널리티 표기, 이상현상을 없애는 정규형 1NF~5NF, 반정규화를 꺼내도 되는 조건과 3원칙, 쿼리가 모델을 결정하는 NoSQL 모델링, 그리고 데이터 표준이 실제로 줄이는 비용을 정리한다.
선택지 열두 개가 각각 무엇을 얻고 무엇을 내주는지, 장애 아홉 가지가 어떤 증상으로 드러나는지를 표로 모으고, 저장소 선택·모델링·SQL·트랜잭션에 걸친 34개 질문에 결론부터 답한다.
선택지 열여섯 개가 각각 무엇을 얻고 무엇을 내주는지, 실패 모드 열한 가지가 어떤 증상으로 드러나고 무엇으로 되받는지를 표로 모았다. 파티셔닝과 샤딩, 복제, 분산 시스템, 합의에 걸친 서른두 개 문답은 먼저 답을 내고 근거를 뒤에 붙인다.
사내 인증 서비스 여섯 편의 마지막이다. 앞의 다섯 편을 세 벌로 다시 엮는다. 고를 때 저울질하는 선택지 다섯, 증상만 보고는 원인을 잘못 짚기 쉬운 실패 모드 여덟, 설명해야 할 때 필요한 문답 스물다섯과 길게 답해야 하는 넷이다.
알림센터 다섯 편의 마지막이다. 앞의 네 편이 주제별로 나눠 답한 것을 질문이 실제로 오는 세 자리로 다시 세운다 — 아직 아무것도 정하지 않은 「고를 때」, 이미 돌고 있는데 증상이 나온 「터졌을 때」, 그 판단의 근거를 남에게 대야 하는 「설명해야 할 때」다.
CI/CD 일곱 편의 마지막. 앞 여섯 편이 나눠 답한 것을 질문이 오는 세 자리로 다시 세운다 — 고를 때·터졌을 때·설명해야 할 때.
요청이 컨트롤러에서 테이블까지 내려가는 계층을 세우고 그 위에 로그인 상태를 붙이는 구간을 다룬다. 상태를 서버에 두는 방식과 토큰에 담아 보내는 방식이 각각 무엇을 얻고 무엇을 포기하는지, 그리고 접근 토큰과 갱신 토큰으로 나누는 회전 정책이 그 저울을 어떻게 매듭짓는지가 이 편의 주제다.
한 대의 서버 안에 있던 애플리케이션을 클러스터 위로 옮기는 구간을 다룬다. 소스가 이미지로 굳어 레지스트리를 거쳐 배포에 닿는 경로, 살아 있는지와 받을 준비가 되었는지를 갈라 보는 두 점검, 복제본을 늘리기 위해 치러야 하는 조건이 차례로 나온다. 마지막은 조직이 바뀌었을 때 코드를 건드리지 않고 데이터만 고쳐 대응하는 자리다.
CI/CD 일곱 편 중 여섯째다. 서비스를 내리지 않고 버전을 바꾸는 세 전략이 각각 무엇을 대가로 무엇을 얻는지, Nginx와 Health Check가 트래픽 전환을 어디서 가르는지, 그리고 파이프라인을 실패시키는 쪽의 관문이 어디에 붙는지를 다룬다.
요구사항 명세서에서 ERD로 내려오는 구간을 따라간다. 기능 요구 문장 옆에 엔드포인트를 붙여 추적할 수 있는 표로 만들고, 그 표에서 되풀이되는 명사를 엔티티로 꺼내고, 한 사람이 역할을 둘 이상 가진다는 요구 한 줄이 어떻게 열 하나를 테이블 하나로 갈라놓는지를 본다. 떠올려서 그린 저장 구조와 표에서 뽑아낸 저장 구조가 무엇이 다른지가 이 편의 주제다.
CI/CD 일곱 편 중 셋째다. 파이프라인이 서 있는 나머지 전제인 재현 가능한 실행 단위를 연다. 병합 세 방식이 히스토리에 서로 다른 것을 남기는 이유, 브랜치 전략 네 종이 릴리즈 단위를 어디서 끊는지, 그리고 「내 로컬에서는 됐는데」를 없애는 컨테이너 이미지가 무엇을 담아 나르는지까지 간다.
같은 데이터를 여러 벌 두면 가용성과 읽기 처리량을 얻지만, 그 순간부터 복제본끼리 값이 다를 수 있다는 문제를 떠안는다. 토폴로지 세 가지가 그 문제를 어떻게 처리하는지, 동기·반동기·비동기가 무엇을 담보로 속도를 사는지, 복제 지연과 장애가 무엇을 사라지게 하는지를 정리한다.
여러 머신에 걸친 순간, 예산이나 기술로 밀어낼 수 없는 제약이 붙는다. 이 글은 분산 시스템이 어떤 장애를 상정하고 출발하는지, 완벽한 합의가 왜 불가능한지, 네트워크가 끊어졌을 때와 멀쩡할 때 각각 무엇을 내주게 되는지, 그리고 그 한계 위에서 장애 감지와 리더 선출과 결함 격리를 어떻게 배치하는지를 다룬다.
노드가 여러 대로 늘어난 순간 커밋은 선언이 아니라 합의가 된다. 이 글은 2PC가 코디네이터 장애에서 정확히 무엇을 잃는지, 3PC·Calvin·Spanner와 Saga가 그 대가를 각각 어디로 옮기는지, Paxos·Raft·PBFT가 견디는 장애 모델이 어떻게 다른지, 그리고 분산 원장이 데이터베이스와 갈라지는 지점을 정리한다.
CI/CD 일곱 편의 지도다. CI와 CD가 각각 무엇을 자동화하고 실패가 어디까지 번지는지, 그 자동화가 형상관리와 컨테이너라는 두 전제 위에 서 있다는 것, 그리고 「파이프라인」·「스테이지」·「게이트」처럼 편마다 다른 것을 가리키는 낱말을 이 시리즈에서 어떤 뜻으로 쓸지를 먼저 정한다.
CI/CD 일곱 편 중 다섯째다. 도구 두 갈래 중 둘째인 Jenkins를 연다. 빌드가 어느 기계에서 도는지를 직접 정해야 하는 모델에서 Controller와 Agent와 Executor가 무엇을 맡는지, 설정을 폼에 채우는 것과 코드로 적는 것이 무엇을 가르는지, Declarative 문법과 사람이 누르는 승인 게이트가 어디에 놓이는지까지 간다.
서버를 두 대로 늘리는 순간 세 가지가 동시에 깨진다. 트래픽 분배, 로그인 세션, 그리고 서버 간 메시지 전파다. 이 글은 앞의 둘이 왜 일반적인 문제이고 마지막 하나만이 WebSocket 고유의 난점인지, 그리고 브로커를 넣어도 남는 것이 무엇인지를 다룬다.
실시간 채팅 시리즈가 내린 판단을 세 벌로 다시 짠다. 아직 방식을 고르는 중이라면 선택지 표를, 이미 돌아가는 서비스에서 메시지가 안 오거나 연결이 끊긴다면 증상에서 출발하는 진단 표를, 근거를 설명해야 한다면 25문답을 쓴다.
「배치로 돌립시다」는 느리게 해도 된다는 허가가 아니라 지연을 내주고 처리량을 사는 거래다. 이 글은 이커머스 거래 체인의 어디에 배치가 붙는지, 그 결정이 어떤 청구서를 되돌려 주는지, Spring Batch가 그 지형에서 책임지는 범위가 어디까지인지를 정한다.
「실시간으로 만들어 달라」는 요구는 기술의 이름이 아니라 증상의 이름이다. 이 글은 서버가 먼저 말을 걸어야 하는 문제를 다섯 가지 전송 방식으로 갈라 언제 무엇을 고르는지 정하고, WebSocket을 골랐을 때 실제로 무엇이 오가는지를 핸드셰이크·프레임·하트비트 세 층에서 본다.
알림은 지워지는 계기가 없어 무한히 쌓이는데 실제로 읽히는 것은 언제나 최신 스무 건뿐이다. 이 비대칭 위에서 저장소를 문서형으로 고른 근거를 도메인 특성에서 끌어내고, 기준값을 넘겨 받는 페이징과 읽음 경계를 시각 한 값으로 푸는 설계, 가장 자주 불리는 엔드포인트를 캐시로 받는 자리, 그리고 90일이 지난 문서를 배치 없이 치우는 만료 인덱스까지 차례로 본다.
알림센터 다섯 편의 지도다. 좋아요 한 번이 알림 한 줄이 되기까지 어떤 서버와 어떤 저장소를 지나는지, 그 경로를 왜 조회와 생성으로 쪼개고 사이에 브로커를 끼우는지, 그리고 「파티션」·「모듈」·「이벤트」처럼 편마다 다른 것을 가리키는 낱말을 이 시리즈에서 어떤 뜻으로 쓸지를 먼저 정한다.
병렬화는 튜닝 축 다섯 개 중 하나의, 그 안에서도 한 칸이다. 그마저도 병목이 어디인지 확정한 뒤에야 의미를 갖는다. 이 글은 측정 설비를 세우는 데서 시작해 Multi-threaded Step·Parallel Step·Partitioning 셋이 각각 무엇을 쪼개고 무엇을 깨뜨리는지, 그리고 여기서 말하는 파티셔닝이 왜 저장 구조를 바꾸는 파티셔닝과 다른 결정인지를 정한다.
Spring Batch를 쓴다는 것은 재시작 가능한 배치를 직접 설계하지 않겠다는 결정이다. 3계층 아키텍처가 무엇을 어디에 두었는지, JobRepository에 남는 기록이 어떻게 재시작이라는 성질로 이어지는지, 그리고 그 재시작이 안전하려면 배치 쪽이 무엇을 지켜야 하는지를 정한다.
사내 인증 서비스 여섯 편의 지도다. 로그인이 시스템마다 따로인 상황에서 출발해 범위 기술서 한 장이 API 표가 되고 그 표가 스키마와 파드 개수까지 내려가는 경로를 그린다. 「역할」·「토큰」·「세션」처럼 편마다 다른 층을 가리키는 낱말도 여기서 먼저 갈라 둔다.
전사 통합 인증을 만들기 전에 정해야 하는 것들을 다룬다. 인증과 인가를 왜 끝까지 따로 써야 하는지, 하나의 로그인을 여럿이 인정하게 만드는 방식들이 각각 무엇을 전제하는지, 그리고 그 결정이 범위 기술서·이벤트 목록·유스케이스·액티비티 다이어그램을 거쳐 다음 단계가 받아 쓸 수 있는 형태로 굳는 과정을 따라간다.
배치 Step의 세 인터페이스 중 둘은 한 건을 받고 하나는 묶음을 받는다. 이 비대칭이 트랜잭션 커밋 간격을 정하고, 그 간격이 Cursor냐 Paging이냐를 정하며, JPA를 얹는 순간 같은 계산이 전부 다시 돌아간다.
CI/CD 일곱 편 중 넷째다. 도구 두 갈래 중 첫째인 GitHub Actions를 연다. 저장소 이벤트가 그대로 트리거가 되는 모델이 무엇을 공짜로 주고 무엇을 대가로 가져가는지, Workflow → Job → Step 세 층과 Runner 두 종이 무엇을 격리하며 그 사이로 값과 파일을 어떻게 넘기는지까지 간다.
캐시 무효화 방식 네 가지와 TTL 설계 원칙, Stampede·Penetration·Avalanche 방어, Spring Cache 구현 3계층의 함정, 그리고 원자 카운터와 분산 락으로 동시성을 다루는 법을 정리한다.
ACID 네 특성이 각각 어떤 장치로 구현되는지, 읽기 일관성과 격리수준 네 단계가 어떤 이상현상을 허용하고 막는지, 락이 어떻게 블로킹과 데드락으로 이어지는지, 그리고 데드락을 실무에서 어떤 순서로 없애는지를 정리한다.
수평으로 자르기로 정한 다음의 질문은 무엇을 기준으로 자를 것인가다. Range·Hash·List·Composite 네 전략이 각각 무엇을 사고 무엇을 내주는지, 인덱스를 로컬로 둘지 글로벌로 둘지, 조각이 머신 경계를 넘는 순간 무엇이 되돌릴 수 없게 되는지를 다룬다.
데이터가 커졌을 때 손댈 수 있는 축은 나누는 것과 복사하는 것 둘뿐이다. 이 글은 그 지도를 먼저 그리고, 파티셔닝의 값어치가 조회 성능보다 운영 작업 쪽에서 나온다는 것, 그리고 수직과 수평이 각각 무엇을 노리는 분할인지를 다룬다.
브로커를 끼워 넣으면 장애가 거꾸로 번지는 경로는 사라지지만 그 대가로 지연과 중복과 순서 뒤집힘이 청구된다. 토픽과 파티션이 무엇을 정하는지, 컨슈머를 늘려도 처리량이 늘지 않는 구간이 왜 생기는지, 오프셋을 언제 커밋하느냐가 전달 보장을 어떻게 바꾸는지를 차례로 본다. 이어서 순서가 지켜지는 범위와 중복을 견디는 도메인 설계, 끝내 실패하는 한 건을 줄 밖으로 빼내는 장치까지 다룬다.
소셜 로그인은 비밀번호를 우리가 들고 있지 않으면서 사용자를 식별하는 방법이다. 이 글은 Authorization Code를 한 번 더 거치는 이유, Spring Security가 폼 로그인과 대칭으로 그것을 얹는 구조, 그리고 인증이 끝난 뒤 필요한 채팅 도메인 모델과 페이징·알림 설계를 다룬다.
캐시를 붙이기 전에 끝내야 할 세 가지 결정을 정리한다. 캐싱 대상 판별 기준, 요구사항에 맞는 Redis 자료구조 선택, 그리고 Look-Aside부터 Write-Back까지 네 가지 캐시 전략의 트레이드오프다.
캐시 전략과 자료구조 선택지를 한 표로 모으고, 운영에서 실제로 밟는 실패 모드 여덟 가지와 대응, 그리고 설계·무효화·동시성·운영에 걸친 25개 질문에 결론부터 답한다.
좋아요·구독을 Set으로 푸는 근거와 멱등 API 설계, 댓글을 Redis가 아닌 저장소에 두는 판단, 단일 스레드 모델이 낳는 운영 제약, 영속화·축출 정책·고가용성 구성을 정리한다.
앞의 네 편이 쌓아 온 판단을 세 벌로 다시 짠다. 아직 무엇으로 읽고 어떻게 벌릴지 고르는 중이라면 선택지 표를, 이미 도는 배치가 윈도우를 넘기거나 숫자가 안 맞는다면 증상에서 출발하는 실패 모드 표를, 그 선택의 근거를 대야 한다면 25문답을 쓴다.
같은 데이터에서 어떤 SQL만 느려지는 이유를 네 자리에서 짚는다. 하드 파싱과 바인드 변수, B-Tree 인덱스와 복합 인덱스의 선두 컬럼 규칙, 실행계획의 access와 filter 구분, 그리고 조인 알고리즘 세 가지의 선택 기준이다.
생 WebSocket은 바이트를 옮길 뿐 목적지를 모른다. 이 글은 그 공백을 STOMP가 어떤 규약으로 메우는지, Spring이 그것을 세 층위로 어떻게 감싸는지, 그리고 destination 접두사를 잘못 나누면 인가 검사가 통째로 우회되는 이유를 다룬다.