ioh's Development

PostgreSQL과 ClickHouse, 같은 조회 요구를 왜 다르게 풀어야 할까?서론: 한 응답에 두 데이터베이스가 등장한 이유현재 회사에서는 PostgreSQL에서 관리 정보를, ClickHouse에서 시간별 관측 이력을 읽고 애플리케이션에서 두 결과를 합쳐 사용합니다. 처음에는 두 데이터베이스의 차이를 알려면 SQL 문법을 비교하면 된다고 생각했습니다. 그런데 같은 '대상별 최신값'과 '값이 없는 시간 구간'을 조회해 보니 저장 구조부터 행을 고르는 순서, NULL과 중복을 다루는 방식, 읽는 범위까지 달랐습니다. 두 저장소를 함께 쓰는 이유를 이해해야 쿼리 차이도 제대로 설명할 수 있겠다고 생각해 이 글을 쓰게 됐습니다. 먼저 저장 방식만 간단히 보면, PostgreSQL은 한 행의 여러 열을 ..

검색어 자동완성 시스템 설계: 트라이로 계산하고 키-값으로 서빙하는 구조와 급상승 검색어 반영스터디에서 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』의 검색어 자동완성 장을 맡아 화이트보드로 발표했습니다. 발표가 끝나고 받은 질문 네 개가 모두 "트라이 캐시와 트라이 DB를 실제로 무엇으로 만드느냐"였고, 저는 그 답을 제대로 정리하지 못한 채 발표를 마쳤습니다. 그래서 발표 뒤에 대본, 당일 질문과 답변, 제가 세운 설계 판단을 문서로 정리했습니다. 정리하면서 숫자를 직접 계산해 보니 발표 때 말한 설계 가운데 여섯 곳을 바꾸게 됐습니다. 아래에서는 책의 설계와 계산을 먼저 짚고, 이어서 바꾼 판단을 하나씩 근거와 반례를 붙여 적었습니다. 본문에서 쓰는 표시는 세 가지입니다. 원문은 책에 있는 ..

채팅 설계의 복제 로그 자리에 Kafka를 넣었을 때 바뀌는 설정과 남는 설계1편과 2편에서는 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』 12장의 채팅 시스템을 출발점으로 설계를 정리하면서, 메시지를 먼저 기록하는 곳을 "여러 노드에 복제된 추가 전용 로그"라고만 적고 어떤 기술로 구현할지는 정하지 않았습니다. 이 편에서는 그 로그를 Apache Kafka로 구현합니다. 대화의 순서는 Conversation Shard가 정하고, Kafka는 번호가 붙은 메시지를 복제해 보관합니다. 앞의 두 편에서 정한 약속이 Kafka의 어떤 설정과 절차로 바뀌는지, Kafka가 대신해 주지 않는 것은 무엇인지 살펴봅니다.핵심을 먼저 말하면, Kafka에 메시지를 기록하는 것만으로 채팅의 순서와 중복 문제가 ..

채팅 메시지의 순서를 대화별 단일 writer와 세대 번호로 지키는 방법1편에서 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』 12장의 채팅 시스템을 출발점으로 전체 구조를 정리하면서, 순서 문제는 따로 다루겠다고 남겨 두었습니다. 설계 문서를 쓰는 동안 가장 오래 붙잡고 있던 질문이 "같은 대화에 있는 사람들이 모두 같은 순서로 메시지를 보게 하려면 무엇이 필요한가"였기 때문입니다. 이 질문은 번호를 어디서 붙이느냐에서 시작해, 번호를 붙이는 서버가 바뀌는 순간 이전 서버를 어떻게 막느냐로 이어졌습니다. 이 편에서는 그 순서대로 제가 공부하고 설계한 내용을 적습니다. 쉽게 말해 단말 시계에 찍힌 시간이 아니라 서버가 대화마다 매긴 번호를 모두가 같은 순서로 보게 하는 문제입니다. 1편에서 설명한..

채팅 시스템 설계: 웹소켓 연결부터 메시지 수락, 전달, 재접속 복구까지스터디에서 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』 12장 채팅 시스템 설계를 공부했습니다. 발표 대본과 화이트보드 준비 문서를 만들면서 책의 설계를 그대로 외우기보다, 책이 정하지 않고 넘어간 두 가지를 직접 정해 보고 싶었습니다. 서버가 송신자에게 "받았다"고 답하는 시점은 언제인지, 그리고 연결이 끊겼다가 다시 붙은 단말은 무엇을 채워야 하는지입니다. 글에서는 책에 있는 내용을 원문, 제가 스터디에서 더한 판단을 원문 밖 확장, 계산을 위해 정한 값을 설계 가정으로 표시했습니다. 부하 테스트나 운영 지표로만 정할 수 있는 값은 무엇을 재면 정해지는지 함께 적었습니다.메시지 한 건으로 보는 전체 구조이 글에서 정한 메..

뉴스 피드 팬아웃 선택 기준: 관계 모델과 지연뉴스 피드를 만들 때는 새 글을 올리는 순간 친구들의 피드에 미리 넣을지(푸시), 누군가 피드를 열 때 글을 모을지(풀) 정해야 합니다. 이 글에서는 두 방법의 작업량과 지연을 계산해 선택 기준을 찾습니다. 결론은 관계 수에 상한이 있느냐에 따라 달라집니다. 이 글의 트래픽과 처리량 가정에서, 시간 역순 뉴스 피드의 친구 수를 5,000명 이하로 제한한다면 푸시 전용으로 처리할 수 있습니다. 일방향 팔로우를 허용해 관계 수의 상한을 보장할 수 없다면 푸시를 기본으로 두고, 팔로어가 많거나 큰 포스팅을 동시에 처리할 여유가 부족할 때 풀로 보내야 합니다. 관계와 부하 조건선택이유친구 관계만 제공하고 최대 5,000명으로 제한푸시 전용가정한 피크 부하와 처리량 ..

[Sutskever's List 스터디] RNN의 dropout 위치와 CTC 학습, 디코딩을 직접 계산해 본 기록RNN의 dropout 위치와 CTC 학습, 디코딩을 직접 계산해 본 기록앞선 글 「AlexNet의 계산량, ResNet의 기울기, LSTM의 기억을 직접 계산해 본 기록」에서 AlexNet의 파라미터 수와 ResNet의 기울기, RNN과 LSTM의 기억을 계산해 봤습니다. 이번 글은 같은 책의 다음 범위입니다. 스터디는 K-DEVCON에서 모집한 읽기 모임이고, 저는 모임과 별도로 논문의 구조를 계산해 보고 작은 실험을 돌려 보고 있습니다. 지난 범위가 RNN과 LSTM이 무엇인지였다면 이번 범위의 첫 번째 질문은 큰 LSTM 언어 모델이 작은 학습 데이터에서 왜 쉽게 과적합하고, drop..

[Sutskever's List 스터디] AlexNet의 계산량, ResNet의 기울기, LSTM의 기억을 직접 계산해 본 기록AlexNet의 계산량, ResNet의 기울기, LSTM의 기억을 직접 계산해 본 기록요즘 ML, 딥러닝, LM, LLM, 벡터 DB, RAG를 공부하고 있습니다. 깊이는 아직 얕지만 범위를 넓게 잡았습니다. 백엔드 개발을 하면서 실무에서 AI를 더 잘 활용하고 싶어서입니다. 그런데 쓰는 법을 공부할수록 지금의 모델이 왜 이런 구조로 만들어졌는지가 궁금해졌습니다. ML(machine learning)은 규칙을 사람이 짜 넣지 않고 데이터에서 학습하게 하는 방법이고, 딥러닝은 그중 신경망을 여러 단계로 깊게 쌓아 학습시키는 방법입니다. LM(language model)은 앞에 나온..

RAG를 만들기 전에, 검색할 데이터를 어떻게 다룰지 생각하게 한 책한빛미디어 서평단 활동을 위해 책을 제공받아 작성한 서평입니다.도서: 『벡터 데이터베이스』지은이: 니틴 보르완카르옮긴이: 정영균출판사: 한빛미디어도서 정보 : 『벡터 데이터베이스』 한빛 도서 페이지RAG를 안다고 생각했는데, 벡터를 어디에 두는지는 설명하기 어려웠다백엔드 개발자인 내가 왜 LLM과 RAG, 벡터 데이터베이스까지 공부하는지 의아할 수 있다. 나도 처음에는 AI를 개발 도구로 잘 쓰면 충분하다고 생각했다. 그런데 쓰다 보니 모델이 답을 만드는 과정뿐 아니라, 질문에 필요한 자료를 어디서 어떻게 찾아오는지가 궁금해졌다. 그 과정은 내가 익숙한 데이터 저장·검색·갱신의 문제와 맞닿아 있었다. RAG를 설명할 때 나는 보통 “..

알림 시스템의 어려움은 처리량이 아니라 경계다결제 서비스의 알림 시스템을 설계했다. 이 글은 대규모 시스템 설계 기초 10장 알림 시스템 설계를 읽고, 책이 한 문장으로 넘긴 "알림이 사라지면 안 된다"는 요구를 판정 가능한 형태로 만들어 본 기록이다.제목의 경계는 서비스 경계가 아니라 보장 경계다. 어디까지를 코드로 보장하고 어디부터는 다른 설계로 대신할지를 확인하는걸 말한다. 처리량이 문제가 아니라는 뜻은 아니다. 처리량을 해결하고 나서도 보장 문제는 그대로 남는다는 뜻이다.1. 아무것도 고장나지 않았는데 62분이 걸린다책의 개략 구조는 채널별로 큐를 하나씩 두고, 먼저 들어온 것이 먼저 나간다. 그러면 마케팅 캠페인과 결제 승인 알림이 같은 푸시 큐에 들어간다.이 글에 나오는 숫자는 모두 아래 가정..

웹 크롤러 설계: 예의를 지킬 대상이 무엇인지부터 정하지 않았다웹 크롤러의 기본 알고리즘은 세 줄로 끝난다. 시드 URL을 목록에 넣고, 하나씩 꺼내 다운로드하고, 거기서 뽑은 링크를 다시 목록에 넣는다. 그런데 여기에 "한 사이트에는 1초에 한 번만 요청한다"는 규칙 하나를 얹는 순간 결정이 여럿 갈린다. 목록을 어디에 둘지, 누가 그 URL을 꺼낼 권한을 갖는지, 무엇을 "한 사이트"로 셀지가 전부 그 한 줄에 묶여 있기 때문이다. 이 글은 대규모 시스템 설계 스터디에서 웹 크롤러를 다룬 기록이고, 그중 예의를 지킬 대상을 무엇으로 셀 것인가라는 질문에 무게를 둔다. 먼저 용어를 하나 고정한다. 이 글에서 예의 정책은 "동일한 요청 간격 키에 대해 직전 요청이 완료된 뒤 1초를 띄운다"로 정의한다. ..

한빛미디어 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다.도서명: 『컨텍스트 엔지니어링으로 완성하는 AI 에이전트』저자: 박경민출판사: 한빛미디어도서 정보: 『컨텍스트 엔지니어링으로 완성하는 AI 에이전트』 한빛미디어 도서 페이지 비결정적인 Coding Agent를 통제하는 방법Context, Evidence, Evaluation, Permission으로 설계한 AI Harness『컨텍스트 엔지니어링으로 완성하는 AI 에이전트』를 읽고들어가며: 코드 한 줄이 아니라 판단의 시작점이 틀렸다AI에게 코드 작성을 맡기다 보면 두 종류의 실패를 만난다.하나는 눈에 잘 띈다. 컴파일이 안 되거나, 존재하지 않는 메서드를 호출하거나, 테스트가 빨간불이 된다. 이런 실패는 시스템이 알려주기 때문에 곧바로 ..

URL 단축기 설계: 모든 결정을 고가용성으로 뭉뚱그리지 않기tinyurl 같은 URL 단축기는 겉보기에 단순하다. 긴 URL을 짧게 바꾸고, 짧은 URL을 누르면 원래로 보낸다. 그런데 설계에 들어가면 결정이 여럿 갈리고, 처음에는 그 결정을 전부 "고가용성 때문"으로 뭉뚱그리기 쉽다. 이 글은 대규모 시스템 설계 스터디에서 URL 단축기를 다룬 기록이고, 각 결정이 실제로는 어느 요구사항이나 추정치에서 나왔는지를 분리하는 데 중점을 두고 설계를 진행했습니다. 책의 해당 챕터는 요구사항과 추정에서 출발해 단축키 생성 방법을 비교하고, base-62 변환으로 상세 설계를 만든 뒤 리디렉션과 캐시로 마무리한다. 스터디에서는 개념 정리에 더해 각 결정의 동인을 분해하고, 7장 유일 ID 생성기(여러 서버가 ..

한빛미디어 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다.AI가 글을 다 써주는 시대에도 개발자에게 글쓰기 능력이 필요할까?『AI도 모르는 글쓰기』를 읽고도서명: 『AI도 모르는 글쓰기』저자: 정나래출판사: 한빛미디어도서 정보: 『AI도 모르는 글쓰기』 한빛미디어 도서 페이지AI에게 업무 메일이나 공지문을 작성해 달라고 요청하면 몇 초 만에 그럴듯한 글이 나온다. 기술 블로그의 목차를 정리하거나 문장을 다듬는 일도 이전보다 훨씬 쉬워졌다.그렇다면 AI가 글을 대신 써주는 시대에도 글쓰기 능력이 필요할까?『AI도 모르는 글쓰기』는 AI 시대에 글쓰기의 필요성이 사라진 것이 아니라, 사람에게 요구되는 역할이 달라졌다고 설명한다. AI가 초안을 만드는 속도는 빨라졌지만, 무엇을 전달할지 결정하고 결..

분산 유일 ID 생성기 설계: auto_increment가 분산에서 깨지는 지점부터단일 DB의 auto_increment는 한 노드 안에서 유일성과 증가 순서를 공짜로 준다. 그런데 이 전제가 분산에서 깨진다. 이 글은 대규모 시스템 설계 스터디에서 분산 유일 ID 생성기를 다룬 기록이다. 책의 해당 챕터는 단일 DB의 한계에서 출발해 네 가지 후보를 비교하고, 트위터 스노플레이크의 64비트 절 분할을 상세히 본 뒤, 시계 역행이나 worker ID 배정 같은 실무 함정까지 다룬다. 스터디에서는 개념 정리에 더해 각 후보가 어느 요구사항에서 걸리는지를 발표로 검증하고, 백엔드 개발자 관점에서 이 ID가 DB 인덱스·이벤트 설계·배포 환경과 맞물리는 지점까지 파고들었다. 이 글은 그 전개와 토론, 딥다이브..

Anthropic Messages API와 Claude Code를 기준으로 승인 게이트, 컨텍스트 비용, 프롬프트 캐시의 실제 구현을 살펴본다 개관에서는 하네스를 다섯 층으로 나눠 진단 프레임을 잡았다. 층이 있다는 사실과, 그 층이 HTTP 요청 하나하나로 실제로 어떻게 구현되는지는 다른 이야기다. 이 글은 후자다. 승인 게이트가 실행 경로의 어느 지점에 물리적으로 존재하는지, 컨텍스트 비용이 왜 제곱으로 붙는지, 캐시가 어떻게 조용히 깨지는지를 본다.먼저 범위를 못 박아 둔다. 이 글은 Anthropic Messages API와 Claude Code를 기준으로 썼다. 메시지 역할, 종료 사유(stop_reason), 캐시 무효화 조건, 권한과 훅 필드는 그 구현에 해당한다. 다른 벤더에도 비슷한 통제..

모델을 더 똑똑하게 만드는 대신, 모델이 틀릴 수 있는 표면을 구조로 좁힌다프롬프트를 고치던 습관을 버린 지점AI가 원하는 결과를 안 내놓을 때 나는 오래 프롬프트를 고쳤다. 지시를 더 명확히 쓰고, 예시를 붙이고, 하지 말라는 문장을 추가했다. 실무 세션을 몇 번 돌리고 나서 실패 로그를 다시 봤더니 원인이 프롬프트에 있던 경우가 생각보다 적었다.없는 컬럼을 참조한 건 지시가 부족해서가 아니라, 그 스키마가 애초에 컨텍스트에 없었기 때문이다.같은 실수를 세 번 반복한 건 모델이 멍청해서가 아니라, 실패 내용이 다음 시도의 입력에 안 들어갔기 때문이다.위험한 작업이 확인 없이 실행된 건 모델이 규칙을 어겨서가 아니라, 실행 통로가 그냥 열려 있었기 때문이다.셋 다 문장을 고쳐서 해결되는 문제가 아니다. ..

할루시네이션을 어떻게 시스템으로 막는가발생 자체를 없애는 것이 아니라, 불확실한 출력을 사용자에게 전달하기 전에 걸러낸다프롬프트 한 줄로는 안 된다는 걸 먼저 인정한다LLM에 "거짓말하지 마, 모르면 모른다고 해"를 붙여봤다. 그래도 지어냈다. 나는 이걸 프롬프트를 더 정교하게 쓰면 풀리는 문제로 오래 봤는데, 방향이 틀렸다. 프롬프트는 모델의 출력 경향에 영향을 줄 수 있지만, 사실성을 보장하는 장치는 아니다.그래서 질문을 바꿨다. 할루시네이션을 "모델을 더 똑똑하게 만들어 없앨 문제"로 볼 것인가, "생성물은 원래 틀릴 수 있다를 전제로 시스템이 걸러낼 문제"로 볼 것인가. 나는 후자로 정리했다. 모델 성능이 개선되면 오류 빈도가 낮아질 수 있지만, 생성 결과를 항상 사실로 보장하기는 어렵다. 그렇다..

RAG 파이프라인, 검색을 코드로 짜면서 배운 것RAG를 "LLM에 문서 검색을 붙이는 것" 정도로만 알고 있었다. 막상 파이프라인을 코드로 짜 보니, 정작 어려운 건 LLM이 아니라 검색이었다. 색인부터 평가까지 각 단계에서 무엇을 결정해야 하는지 정리한다.RAG를 다시 정의하기: 무엇을 아는가 vs 어떻게 말하는가처음엔 파인튜닝과 RAG를 같은 서랍에 넣고 있었다. 둘 다 "모델에 지식을 넣는 법"이라고 생각했다. 코드를 짜면서 경계가 분명해졌다.파인튜닝은 모델 가중치를 바꾼다. RAG는 가중치를 그대로 두고, 답을 생성하기 전에 외부 저장소에서 관련 문서를 찾아 프롬프트에 끼워 넣는다. 이번 프로젝트 목적을 기준으로 단순화하면, 최신 근거를 제공하는 문제는 RAG에, 반복되는 응답 방식과 형식을 학..

분산 유일 ID 생성기 설계: auto_increment가 분산에서 깨지는 지점부터단일 DB의 auto_increment는 한 노드 안에서 유일성과 증가 순서를 공짜로 준다. 그런데 이 전제가 분산에서 깨진다. 이 글은 대규모 시스템 설계 스터디에서 분산 유일 ID 생성기를 다룬 기록이다.책의 해당 챕터는 단일 DB의 한계에서 출발해 네 가지 후보를 비교하고, 트위터 스노플레이크의 64비트 절 분할을 상세히 본 뒤, 시계 역행이나 worker ID 배정 같은 실무 함정까지 다룬다. 스터디에서는 개념 정리에 더해 각 후보가 어느 요구사항에서 걸리는지를 발표로 검증하고, 백엔드 개발자 관점에서 이 ID가 DB 인덱스·이벤트 설계·배포 환경과 맞물리는 지점까지 파고들었다. 이 글은 그 전개와 토론, 딥다이브를..

안정 해시 설계: 서버가 늘어도 데이터를 옮기지 않는 법여러 서버에 데이터를 나눌 때 가장 단순한 방법은 hash(key) % 서버_수다. 그런데 이 방식은 서버를 한 대만 늘려도 거의 모든 데이터를 재배치한다. 안정 해시(consistent hashing)는 이 재배치 폭발을 막는 기법이다. 이 글은 대규모 시스템 설계 스터디에서 안정 해시를 다룬 기록이다.책의 해당 챕터는 일반 해시의 재배치 문제에서 출발해 해시 링, 가상 노드, 복제, 핫스팟까지 쌓아 올린다. 스터디에서는 개념을 정리하는 데서 멈추지 않고, 각 단계에서 "이게 무엇을 강제하는가"를 따지고 발표 자리에서 서로의 이해를 반론으로 검증했다. 이 글은 그 개념 전개와 토론을 함께 담는다. 핵심 흐름 한 줄 지도일반 해시 재배치 문제 → 해..

처리율 제한 장치 설계: 요구사항 네 개가 모든 결정을 강제한다처리율 제한 장치(rate limiter)는 클라이언트나 서비스가 보내는 트래픽의 양을 제어하는 장치다. 정해둔 임계치를 넘는 요청은 막고 HTTP 429를 돌려준다. 이 글은 대규모 시스템 설계 스터디에서 이 rate limiter를 설계한 기록이다.책의 해당 챕터는 배치 위치, 알고리즘 다섯 종, 저장소, 규칙 설정, 장애 대응까지 다룬다. 스터디에서는 그 내용을 읽기 전에 먼저 요구사항만으로 골격을 잡고(1차), 그다음 책 학습과 심화 분석으로 빈칸을 채웠다(2차). 이 글은 그 before/after와, 발표 자리에서 오간 반론을 함께 담는다. 한 가지 관점을 미리 못박아 둔다. 이 설계를 가른 것은 기능 요구사항이 아니라 비기능 요구..

키-값 저장소 설계: 단일 서버에서 대규모까지키-값 저장소는 key로 value를 넣고 빼는 것만 하는 데이터베이스다. Redis, Amazon DynamoDB, Cassandra가 여기 속한다. 이 글은 대규모 시스템 설계 스터디에서 이 키-값 저장소를 설계한 기록이다. 책의 해당 챕터는 단일 서버 저장소에서 출발해 파티셔닝, 복제, 정족수, 장애 처리까지 분산 저장소의 핵심 개념을 쌓아 올린다. 스터디에서는 그 개념을 읽고 정리하는 데서 멈추지 않고, 직접 설계를 그린 뒤 매주 서로의 설계를 놓고 토론하며 다듬었다. 개념을 손으로 설계해보고 다른 개발자의 반론에 답하는 과정에서 이해가 붙었다.1주차에 순수 안정 해시로 초안을 잡았고, 대규모 트래픽이라는 전제를 숫자로 못박자 그 초안이 흔들리는 걸 확..

1. AI는 개발자를 대체하기보다 개발자의 역량을 증폭한다AI가 개발 과정에 본격적으로 들어오면서 코드 작성에 필요한 비용은 빠르게 낮아지고 있다. 일부 구현 작업에서는 과거 며칠이 필요했던 결과물을 몇 시간 안에 초안 형태로 만들 수 있고, 반복 작업이나 문서 작성, 코드 분석과 테스트 코드 생성도 상당 부분 AI의 도움을 받을 수 있게 되었다.그러나 코드를 빠르게 만드는 것과 좋은 제품을 만드는 것은 같은 문제가 아니다.무엇을 만들어야 하는지 발견하고, 해결할 문제를 구체화하고, 여러 대안 가운데 적절한 구조를 선택하고, 결과물이 실제 요구사항을 충족하는지 판단하는 과정은 여전히 사람의 역할이다.AI는 구현 속도를 높여주지만, 만들어야 할 방향까지 자동으로 결정해주지는 않는다. 오히려 구현 비용이 낮..

혹시 이런 상황, 생각해본 적 있으신가요?이커머스에서 결제를 처리한다고 해보자. 요구사항은 한 줄이다."결제가 완료되면 PG에 거래 확정 API를 호출하고, 주문 상태를 PAID로 업데이트해줘"코드로 옮기면 보통 이렇게 시작한다.@Transactionalpublic void completePayment(Long orderId) { Order order = orderRepository.findById(orderId).orElseThrow(); pgClient.confirm(order.getPgKey()); // 외부 HTTP 호출 order.markPaid(); // DB 상태 변경}이 코드를 본 동료가 묻는다."동시성 문제가 있을 것 같은데, 비관..

이번 주에 새로 배운 것개념을 제대로 이해하면, 아키텍처가 보이기 시작한다이번 주에 가장 크게 느낀 건 "개념을 정확히 아는 것이 아키텍처 역량과 연결된다"는 거였다. 예전엔 아키텍처를 잘 짜는 사람은 뭔가 감이 좋은 사람이라고 막연히 생각했다. 그런데 10주를 돌아보니 그게 아니었다. 개념 하나를 깊이 이해하면 그 개념이 설계 선택의 근거가 되고, 근거가 쌓이면 아키텍처가 자연스럽게 나온다.복합 인덱스의 B+Tree 리프 노드 정렬 방식을 이해하니까 "카디널리티가 먼저가 아니라 등호 조건이 먼저"라는 실제 규칙이 보였고, 트랜잭션이 ThreadLocal에 바인딩된다는 걸 직접 코드로 부딪혀보니까 비동기 콜백에서 왜 @Transactional이 안 먹히는지가 설명이 됐다. 원리를 안 채로 설계를 하는 것..

TL;DR한 번에 집계해서 교체해야 하는 작업에 청크 기반 처리를 선택하면서, 프레임워크의 장점은 살리지 못하고 복잡성만 늘어났다. 그 과정에서 도구의 형식보다 문제의 본질에 맞는 선택이 더 중요하다는 것을 배웠다.이번 글에서 다루는 문제이커머스 서비스에서 “이번 주 인기 상품 TOP 100”을 만들어야 했다.사용자가 상품을 조회하거나, 좋아요를 누르거나, 주문할 때마다 이벤트가 쌓인다. 이 이벤트를 주 단위로 모아 상품별 점수를 계산하고, 점수가 높은 순서대로 상위 100개 상품을 저장하면 된다.이미 데이터베이스에는 ranking_event 테이블이 있었다.이 테이블에는 “어떤 상품에 어떤 행동이 언제 발생했는지”라는 원본 이벤트 데이터가 저장돼 있었다. 이 데이터를 다시 읽어서 원하는 방식으로 점수를..

기술을 쓰는 개발자에서, 선택의 이유를 설명하는 개발자로루프팩 3기를 마치며서론. 나는 왜 다시 배우기로 했을까돌아보면 저는 늘 기술 가까이에 있었습니다.백엔드 개발자로서 기능을 만들고, 운영 이슈를 해결하고, 장애를 마주하고, 다시 구조를 손보는 일을 반복해 왔습니다. 실무 안에서 많은 것을 배웠고, 그만큼 익숙해진 기술도 많았습니다. 그런데 어느 순간부터 아주 선명하게 느껴지는 한계가 있었습니다. “써본 적은 있는데, 정말 설명할 수 있는가?”이직을 준비하면서 그 질문이 더 크게 다가왔습니다.왜 이 구조를 선택했는지, 왜 이 트랜잭션 경계가 필요한지, 어떤 기준으로 동기와 비동기를 나눴는지. 막상 이런 질문 앞에 서면, 구현 경험은 분명 있는데 그것을 설계 의도와 판단 근거의 언어로 풀어내는 일은 아..

Spring Batch 실전에서 만난 3가지 함정한 줄 요약:Spring Batch로 주간 랭킹 집계를 만들고, 테스트 4개를 짰고, 전부 통과했다. 그런데 실제로 돌리면 결과 테이블이 매번 비어있었다. 원인을 추적하니, 테스트 자체가 3개의 치명적 결함을 구조적으로 숨기고 있었다. 이 글은 그 3가지 함정을 발견하고 수정한 기록이다.배경: 뭘 만들었나이커머스 서비스에서 "이번 주 인기 상품 TOP 100" 같은 랭킹을 보여주려면, 사용자의 행동(상품 조회, 좋아요, 주문)을 모아서 점수를 매기고, 높은 순서대로 정렬해야 한다.기존에는 실시간 일간 랭킹이 있었다. 사용자가 상품을 조회하면 Kafka(메시지 큐)를 통해 이벤트가 전달되고, Consumer(이벤트 수신기)가 이를 받아 Redis라는 인메모리..

이번 주에 새로 배운 것"best-effort니까 괜찮다"는 설계가 아니다Kafka Consumer에서 DB에 메트릭을 적재하는 기존 파이프라인에 Redis ZSET 랭킹 점수를 추가해야 했다. try-catch로 감싸면 Redis가 죽어도 DB 트랜잭션은 안 깨진다. "best-effort니까 이 정도면 충분하지 않을까?"이 판단이 틀렸다. 같은 best-effort인데 ZINCRBY를 TX 안에 넣느냐, TX 커밋 후에 넣느냐에 따라 결함의 방향이 달랐다.TX 안에서 ZINCRBY → TX COMMIT 실패 시 → Redis에는 반영됨, DB에는 안 됨 → 재처리 시 → double increment (over-count)TX 커밋 후 ZINCRBY → COMMIT 성공 ..