ProofU 초기 설계 - 근거를 추적하는 지원 문서 시스템과 기술 선택의 이유 Notes ProofU는 경력 사실과 증빙(Evidence)을 오래 쌓아 두고, 채용공고 요구사항에 맞춰 이력서와 자기소개서를 만드는 시스템이다. 만들어진 문장마다 어떤 사실과 증빙에서 나왔는지 거꾸로 따라갈 수 있어야 한다는 점이 일반적인 이력서 생성기와 다르다. 저장소의 첫 커밋은 2026-09-18이다. 이 글은 그날 새벽 첫 16개 커밋(5d6874b부... 2026/09/18 Proofu
ParityPay로 검증하는 결제 정합성 5 - DB 커밋과 Kafka 발행 사이: Transactional Outbox와 at-least-once 소비자 개인 프로젝트 Notes 1편에서 여섯 불변조건 중 INV-004(“같은 업무 참조의 금융 효과는 한 번만 발생한다”)는 저장소 트리거가 아니라 애플리케이션 계층에 있어야 한다고 썼다. 요청 식별의 문제이기 때문이다. 이 글은 그 문장이 HTTP 요청이 아니라 이벤트에 적용될 때 무엇이 필요한지를 다룬다. 결제가 승인되면 거래내역 프로젝션이 갱신되고 판매자 정산 항목이 생겨야... 2026/09/18 ParityPay ParityPay로 검증하는 결제 정합성 5편
Martin Kleppmann 「How to do distributed locking」 리뷰 — 효율을 위한 락과 정확성을 위한 락, fencing token이 막는 것과 못 막는 것, 그리고 lease의 시계는 누구 것인가 Tech Blog Review 원문: How to do distributed locking — Martin Kleppmann, 2016-02-08 10년 된 글이다. 이 시리즈의 첫 글로 고른 이유는, 분산락에 대해 내가 실무에서 만든 것과 프로젝트에서 잰 것이 전부 이 글의 문장 안에 들어가기 때문이다. 지분율 시스템의 SETNX + TTL + 소유 토큰 락은 원문이 “효율을 ... 2026/09/18 Kleppmann 권위자와 개인 기술 블로그 리뷰 1편
ParityPay로 검증하는 결제 정합성 4 - 실험 27종이 찾아낸 결함 12건: 문서와 코드를 읽어서 나온 것은 하나도 없었다 개인 프로젝트 Notes ParityPay의 설계 문서는 열여섯 개였다. 제품 기획서부터 도메인 상태 전이, 원장 분개 카탈로그, 정합성과 장애 복구 설계, 테스트 전략까지. ADR(결정과 그 맥락을 남기는 기록)도 열한 개였다. 자동화 테스트는 백엔드 317개, 프론트엔드 56개, E2E 7개이고 전부 통과한다. 그 상태에서 부하와 장애 실험 27종을 돌렸다. 결함 12건... 2026/09/17 ParityPay ParityPay로 검증하는 결제 정합성 4편
Airbnb 「Avoiding double payments in a distributed payments system」 리뷰 — 네트워크와 DB 트랜잭션을 섞지 않는 세 단계, 재시도 가능 여부의 분류, 그리고 복제본을 읽으면 이중 결제가 나는 이유 Tech Blog Review 원문: Avoiding double payments in a distributed payments system — The Airbnb Tech Blog, Jon Chew·Ninad Khisti, 2019-04-17 7년 된 글이다. 고른 이유는 이 글이 결제 멱등성 글의 원형이기 때문이다. 이후 국내외 결제 글이 “멱등 키를 받고, 재시도 가능 여부... 2026/09/17 Airbnb 빅테크 기술 블로그 리뷰 75편
ParityPay로 검증하는 결제 정합성 3 - 외부 승인 응답이 사라졌을 때: 타임아웃은 실패가 아니다 개인 프로젝트 Notes 외부기관을 호출하는 결제 시스템에는 세 번째 결과가 있다. 성공도 실패도 아닌 “모른다”다. 이 글은 ParityPay가 그 상태를 어떻게 다뤘는지, 왜 그것이 예외 처리가 아니라 상태 모델의 문제인지, 그리고 실험이 설계 문서에 없던 구멍을 어떻게 드러냈는지 정리한 기록이다. 문제: 응답이 없다는 것은 실패가 아니다 충전 요청의 흐름은 단순하... 2026/09/16 ParityPay ParityPay로 검증하는 결제 정합성 3편
ParityPay로 검증하는 결제 정합성 2 - 잠금을 필요 이상으로 오래 쥐고 있었다: 추론을 측정으로 바꾼 기록 개인 프로젝트 Notes 1편에서 잔액 비음수(INV-003)를 조건부 원자 UPDATE로 강제한다고 썼다. 이 글은 그 UPDATE가 동시 결제 아래에서 어떻게 동작했는지, 느려진 원인을 “안다”고 생각했던 것이 어디까지 측정이고 어디부터 추론이었는지, 그리고 측정 방법 자체가 결론을 만들 뻔한 두 번의 실수를 정리한 기록이다. 수치는 전부 실측값이고, 측정 조건과 설명하지... 2026/09/15 ParityPay ParityPay로 검증하는 결제 정합성 2편
TLS 핸드셰이크의 비용 - 세션 재개와 0-RTT의 대가 Notes HTTPS를 켜면 느려진다는 말은 절반만 맞다. 암호화 연산 자체는 현대 CPU에서 거의 공짜에 가깝고, 비용의 대부분은 연결을 맺을 때의 왕복에 있다. 그래서 대책도 암호화를 줄이는 쪽이 아니라 왕복을 줄이는 쪽이다. 비용이 어디에 있는가 TLS의 비용은 셋으로 나뉜다. 내용 크기 ... 2026/09/13 Network
2026-09-11-TIL: 잠금 전략보다 잠금을 쥐는 시간 TIL 최근 2주 가까이 쌓인 작업을 정리한다. 이 기간에 온라인 저지 code-drill과 결제·원장 시스템 parity-pay를 새로 열었고, 기존 저장소 중에서는 monticker가 가장 많이 움직였다. 새 저장소 둘 다 CLAUDE.md에 “작업은 커밋되어야 끝난다”는 규칙을 두고 Claude Code로 진행했다. 기록할 만한 판단이 남은 줄기 위주로... 2026/09/11 2026-TIL
ParityPay로 검증하는 결제 정합성 1 - 장애가 나도 지켜야 할 금융 불변조건 여섯 가지 Notes GitHub 저장소 ParityPay는 플랫폼 내장형 페이머니를 구현한 개인 프로젝트다. 사용자가 은행 계좌에서 페이머니를 충전하고, 주문을 결제하고, 취소하고, 판매자에게 정산되는 흐름을 백엔드로 만들었다. 기능 목록만 보면 흔한 결제 API 연동 과제처럼 보인다. 이 프로젝트의 목표는 그 기능들이 정상 요청에서 동작하는 것이 아니라, 중복 요청,... 2026/09/10 ParityPay ParityPay로 검증하는 결제 정합성 1편