Kafka의 저장 구조 - 세그먼트와 오프셋, 페이지 캐시와 zero-copy Notes Kafka가 빠른 이유를 “메모리를 쓰니까”로 설명하면 틀린다. Kafka 브로커는 메시지를 JVM 힙에 쌓아 두지 않는다. 디스크에 append하고, 커널의 페이지 캐시(커널이 파일 내용을 메모리에 들고 있는 영역)에 맡긴다. 이 구조를 알아야 “브로커 힙을 늘려도 왜 안 빨라지는가”, “왜 컨슈머가 밀리면 갑자기 디스크를 읽는가”가 설명된다. ... 2026/01/16 Infrastructure
키 생성 병목을 추적해 구조를 바꾼 기록: Part 2 - SELECT 안에서 UPDATE가 일어나고 있었다 Notes 1편에서는 계약 생성 처리에 2분이 걸리고 동시 요청과 배치에서 대기가 커졌다는 증상, 그리고 그 원인이 계약 코드를 받아 오는 SELECT next_seq('CONTRACT_CODE') 한 줄 안의 시퀀스 증가였다는 데까지 적었다. 남은 질문은 메커니즘이었다. 이 글은 그 함수 안을 열어, 읽기처럼 보이는 문장이 어떤 락을 걸고 그 락이 왜 다른 요... 2026/01/14 Common 키 생성 병목을 추적해 구조를 바꾼 기록 2편
SLASH 21 리뷰 - 결제 시스템의 SDK와 API 디자인: 4단계를 2단계로, DELETE·PUT을 버린 이유, 한글 enum Conference 발표 SLASH 21 연사 이홍채 (토스페이먼츠 Technical Product Owner), 박순영 (토스페이먼츠 Server Developer), 이현섭 (토스페이먼츠 Frontend Developer) 자료 ... 2026/01/13 Toss 토스 커뮤니티 백엔드 발표 리뷰 3편
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 4장 외부 연동이 문제일 때 살펴봐야 할 것들 Book 외부 시스템 연동은 “우리 코드가 아닌 부분”이 섞이기 때문에 장애 해석이 더 어렵다. 실무에서는 연동 자체보다 실패를 어떻게 다루는가가 더 중요하다. 외부 연동은 결제 대행사, 본인 인증, 지도, 메시지 발송처럼 우리 서비스가 다른 회사나 다른 팀의 API를 호출하는 모든 경우를 말한다. 우리 쪽에서는 상대 서버의 상태를 볼 수 없고, 고칠 수도 ... 2026/01/12 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
일관성 모델 - 선형화, 순차, 최종 일관성, 그리고 CAP를 설정값의 언어로 Notes “강한 일관성”과 “최종 일관성” 두 단어로 분산 시스템의 일관성을 이야기하면, 정작 설정 파일 앞에서 막힌다. Kafka의 acks, PostgreSQL의 synchronous_commit, MongoDB의 writeConcern·readConcern은 전부 일관성 모델을 값으로 고르는 자리인데, 두 단어짜리 어휘로는 그 값을 고를 수 없다. 이 글... 2026/01/12 Architecture
SLASH 21 리뷰 - SRE 사례 소개: Redis 리밸런싱 ASK 에러, Memcached 재분배 실패, Prometheus가 바꾼 GC 패턴 Conference 발표 SLASH 21 연사 조규희 (토스 서버 플랫폼팀, Site Reliability Engineer) 자료 발표 영상 · SLASH 21 토스 서버 플랫폼팀이 운영 중에 겪은 문제 세 ... 2026/01/09 Toss 토스 커뮤니티 백엔드 발표 리뷰 2편
격리 수준과 이상 현상 - 표준이 정의한 것과 MySQL·PostgreSQL이 실제로 하는 것 Notes 격리 수준을 “READ COMMITTED는 커밋된 것만 읽는다” 정도로 외우고 있으면, 실무에서 만나는 질문에 답할 수 없다. 같은 REPEATABLE READ인데 MySQL에서는 팬텀이 안 보이고 PostgreSQL에서는 갱신이 실패하며, 두 DB 모두 표준을 지키고 있다. 표준이 무엇을 정의했고 무엇을 정의하지 않았는지를 나누면 이 차이가 설명된다... 2026/01/06 Database
키 생성 병목을 추적해 구조를 바꾼 기록: Part 1 - 2분짜리 계약 생성과 SELECT 한 줄 Notes 음원 플랫폼 회사에서 콘텐츠 플랫폼(MCP)을 전면 개편하던 2024년, 계약을 생성하는 처리가 2분씩 걸렸다. 이 시리즈는 그 2분의 원인이 된 채번 구조와, 그 구조를 바꾼 방법, 나중에 그 설계에 남은 결함까지 확인한 기록이다. Part 1(이 글): 시스템과 증상, 그리고 원인으로 지목된 SELECT 한 줄. Part 2: 그 SEL... 2026/01/03 Common 키 생성 병목을 추적해 구조를 바꾼 기록 1편
대량 배치 안정성을 높이기 위한 구조 개선: Part 1 - 시스템을 압박하기 시작한 배치 Notes Part 0에서는 지분율 삭제·재등록 작업이 예외 상황에서 무엇을 보장하지 못했는지 정리했다. 이 글은 그중 삭제 배치 하나에 집중한다. 2시간 넘게 걸리던 삭제가 어디서 시간을 쓰고 있었는지, 실행계획과 데이터 분포를 차례로 확인한 과정을 적는다. 전제 이 글의 판단은 다음 조건에서 나왔다. 데이터: 유통사별 월 단위 정산에 쓰는 저작... 2026/01/03 Common 대량 배치 안정성을 높이기 위한 구조 개선 1편
대량 배치 안정성을 높이기 위한 구조 개선: Part 2 - 전체 삭제 후 전체 등록 구조의 위험성 Notes Part 1에서는 삭제가 2시간 넘게 걸린 원인을 찾았다. OR로 묶인 기간 조건이 인덱스를 타지 못했고, 협회와 일부 대형 유통사가 데이터의 80% 이상을 차지해 스캔 범위가 컸다. 그런데 쿼리를 고쳐도 남는 문제가 있었다. 이 글은 쿼리가 아니라 “전체를 지우고 전체를 다시 넣는” 작업 구조 자체가 가진 위험을 정리하고, 그 위험에서 개선 기준을 ... 2026/01/03 Common 대량 배치 안정성을 높이기 위한 구조 개선 2편