ParityPay로 검증하는 결제 정합성 5 - DB 커밋과 Kafka 발행 사이: Transactional Outbox와 at-least-once 소비자 개인 프로젝트 Notes 1편에서 여섯 불변조건 중 INV-004(“같은 업무 참조의 금융 효과는 한 번만 발생한다”)는 저장소 트리거가 아니라 애플리케이션 계층에 있어야 한다고 썼다. 요청 식별의 문제이기 때문이다. 이 글은 그 문장이 HTTP 요청이 아니라 이벤트에 적용될 때 무엇이 필요한지를 다룬다. 결제가 승인되면 거래내역 프로젝션이 갱신되고 판매자 정산 항목이 생겨야... 2026/03/16 Notes, ParityPay ParityPay로 검증하는 결제 정합성 5편
프록시의 한계 - self-invocation, final, JDK와 CGLIB의 선택 Notes @Transactional을 붙였는데 트랜잭션이 안 걸린다. @Cacheable을 붙였는데 캐시가 안 된다. @Async를 붙였는데 같은 스레드에서 돈다. 증상은 다르지만 원인은 하나다. 그 호출이 프록시를 지나지 않았다. 스프링 AOP는 프록시 기반이고, 세 증상 모두 이 사실에서 나온다. 프록시가 하는 일 스프링은 @Transactional이 ... 2026/03/15 Notes, Spring
SLASH 22 리뷰 - 왜 은행은 무한스크롤이 안되나요: 채널계가 거래내역을 직접 갖기 위한 여덟 가지 방어 Conference 발표 SLASH 22 연사 이응준 (토스뱅크 송금 서버 개발자) 자료 발표 영상 · SLASH 22 은행 앱의 거래내역은 왜 기간을 지정해야 하고, 토스뱅크는 왜 트위터처럼 무한스크롤이 되... 2026/03/15 Conference, Toss 토스 커뮤니티 백엔드 발표 리뷰 19편
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 7장 I/O 병목, 어떻게 해결하지 Book 백엔드 서비스는 CPU보다 I/O 때문에 느려지는 경우가 많다. DB, 파일, 네트워크, 외부 API 모두 I/O 자원이다. I/O 병목이 보이는 신호 CPU는 남는데 응답 시간이 느리다 스레드가 많이 쌓인다 connection pool 대기가 늘어난다 외부 호출이나 DB 호출 시간이 길다 왜 중요한가 I/O 병목은 애플리케이... 2026/03/11 Book, 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 8장 실무에서 꼭 필요한 보안 지식 Book 보안은 별도 팀의 일이 아니라 백엔드 개발자의 기본 책임이다. 특히 인증, 인가, 입력 검증, 비밀 관리, 로그 처리처럼 애플리케이션 레벨 보안은 개발자가 가장 먼저 맞닥뜨린다. 최소한 알아야 할 것 1. 인증과 인가 구분 인증: 누구인가 인가: 무엇을 할 수 있는가 둘을 섞으면 권한 버그가 생긴다. 2. 비밀번호/토큰/세션 ... 2026/03/11 Book, 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
동시성 도구의 비용 - synchronized, ReentrantLock, CAS가 경쟁에서 갈리는 지점 Notes “synchronized는 느리니 AtomicInteger를 쓰자”는 조언을 자주 듣는다. 절반만 맞다. 경쟁이 없으면 둘 다 거의 공짜이고, 경쟁이 심하면 CAS 쪽이 더 나빠지는 구간이 있다. 각 도구가 경쟁 아래에서 무엇을 하는지 보면 언제 무엇을 쓸지가 정해진다. synchronized: 경쟁이 없으면 거의 공짜다 JVM의 모니터 락은 경쟁... 2026/03/09 Notes, Java
ParityPay로 검증하는 결제 정합성 4 - 실험 27종이 찾아낸 결함 12건: 문서와 코드를 읽어서 나온 것은 하나도 없었다 개인 프로젝트 Notes ParityPay의 설계 문서는 열여섯 개였다. 제품 기획서부터 도메인 상태 전이, 원장 분개 카탈로그, 정합성과 장애 복구 설계, 테스트 전략까지. ADR(결정과 그 맥락을 남기는 기록)도 열한 개였다. 자동화 테스트는 백엔드 317개, 프론트엔드 56개, E2E 7개이고 전부 통과한다. 그 상태에서 부하와 장애 실험 27종을 돌렸다. 결함 12건... 2026/03/08 Notes, ParityPay ParityPay로 검증하는 결제 정합성 4편
Postgres 커넥션 하나의 비용 - 풀을 키우면 대기가 사라지는 게 아니라 볼 수 없는 곳으로 옮겨간다 실무 사례 Notes 커넥션과 세션에서 “풀이 작으면 애플리케이션 쪽에서 대기하고, 크면 DB 안에서 보이지 않게 대기한다”고 썼다. 그 글은 문서를 근거로 썼고 마지막에 네 가지를 재 보자고 적어 뒀다. 이 글이 그 측정이다. 저장소는 data-ops-lab이고 재실행은 한 줄이다. ./.venv/bin/python experiments/connection/run.p... 2026/03/05 Notes, Database
컨슈머 그룹과 리밸런스 - eager, cooperative, static membership Notes 컨슈머를 한 대 추가했을 뿐인데 전체 처리가 몇 초 멈춘다. 배포할 때마다 랙이 튀고, 롤링 업데이트에서 인스턴스 수만큼 그 일이 반복된다. 이 글은 리밸런스가 무엇을 멈추는지, 그 멈춤을 줄이는 선택지가 무엇인지 다룬다. 그룹, 파티션, 소유권 컨슈머 그룹은 토픽의 파티션을 나눠 갖는다. 규칙은 하나다. 한 파티션은 그룹 안에서 한 컨슈머만 읽는... 2026/03/03 Notes, Infrastructure
2026-02-27-TIL: Codex 사용 후기 TIL 최근에 Codex를 본격적으로 사용해보았다. 나는 AI 에이전트를 능숙하게 다루지는 못하기 때문에 Claude Code보다는 오히려 Codex가 UI/UX 측면에서는 훌륭하다고 느꼈다. 현시점에서 가장 큰 차이점은 Claude Code에서 GUI기반의 데스크톱 앱을 지원하지 않는다는 것이다. 나는 개인적으로 GUI로 충분히 가능한 기능을 CLI를 통해... 2026/02/27 TIL, 2026-TIL