2026년 8월 3주차 회고: DND 세미나 발표와 실무지식 5장

3줄 요약

• DND 개발자 세미나에서 3개월 동안 오픈소스에 기여한 경험을 발표했다.
• 『주니어 백엔드 개발자가 반드시 알아야 할 실무지식』 5장도 읽었다. 비동기의 대가는 지연과 중복이고, 어느 방식을 골라도 멱등 처리가 전제다.

지난주 Try 점검

• 『주니어 백엔드 개발자가 반드시 알아야 할 실무지식』 5장 읽고 정리하기 → 읽고 스터디 노트에 정리했다. 기억할 것만 아래에 남긴다.

이번 주의 발표: 오픈소스 기여가 커리어에 도움이 되는지 20명 앞에서 발표했다

DND 개발자 세미나에서 오픈소스 기여 경험을 발표했다. 참여자는 20명 가까이 됐다. 커리어에 도움이 될까 싶어서 3개월 동안 fixture-monkey에 기여했고, 그 경험을 15분으로 정리했다.

어디서 찾는지

기여할 이슈는 good first issue 라벨에서 찾았다. 메인테이너가 입문자용으로 미리 골라 둔 이슈라서, 무엇을 해도 되는지 고민할 필요가 없었다.

어떻게 기여하는지

작은 기여부터 순서대로 올라갔다. 오타, 문서 번역, 이슈 제안, 기능 구현, 유지 작업 순이다.

이 순서로 움직일 때 신경 쓴 것이 있다. 메인테이너 손이 덜 타는 일부터 맡아 프로젝트 이해도를 높였다. 이해도가 올라가니 메인테이너를 번거롭게 하는 질문이 줄었다. 그렇게 기여 빈도와 기간을 늘려 갔다.

메인테이너가 기여 이력이 있는 사람의 PR을 더 잘 받아준다는 건 연구로도 확인된다. PR 수락 요인을 분석한 Gousios 외(2014)는 기여자의 이력을 수락 요인으로 꼽았고, Tsay 외(2014)는 프로젝트 안에서 주고받은 이력이 많을수록 수락 확률이 올라간다고 봤다.

실제 기록은 이렇다.

이력서에 어떻게 쓰는지

이 부분이 가장 조심스러웠다. 사람마다 기준이 다른 주제라 시작할 때 전제를 먼저 깔았다. 발표에 나오는 평가는 내 판단이니 각자 기준으로 다시 설계해 보라고 말했다.

취업에서 오픈소스 기여는 대외활동 수준으로 읽힌다. 임팩트가 크면 대외활동 상위권, 작으면 하위권에 놓인다. 그래서 취업에 필요한 것들을 먼저 챙기고, 그다음에 오픈소스에 기여하는 방향을 권했다.

내 경우엔 첫 취업 때 오픈소스 이야기가 가점이 됐다. 그 이유도 함께 공유했다. 어떻게 기여했고 무엇을 배웠는지를 말할 수 있었기 때문이다. 배운 것은 두 가지였다.

• TDD로 문제를 단계적으로 좁혔다. 원하는 로직을 테스트로 먼저 적어 두면 처음엔 실패한다. 실패한 테스트의 스택트레이스를 따라가면서 고칠 위치를 찾았다.
• 추상화의 장단점을 직접 겪었다. 교체 가능한 클래스를 만들려고 인터페이스를 여러 겹 쌓아 둔 구조여서 디버깅이 힘들었다. 추상화를 늘리면 클래스 수와 코드 라인이 같이 늘어난다. 적절한 선을 잡는 게 어려웠다.

『육각형 개발자』는 개발자가 구현 하나로 평가받지 않는다는 관점을 담은 책이다. 책이 말하는 여섯 축에 내 기여를 하나씩 대응해 봤다.

축마다 어떤 기여를 근거로 삼았는지는 아래와 같다.

이번 주의 공부: 『주니어 백엔드 개발자가 반드시 알아야 할 실무지식』 5장

5장은 비동기 연동을 언제 어떻게 쓰는지 다룬다. 자세한 정리는 스터디 노트에 있고, 판단에 필요한 결론만 남긴다.

• 외부 연동 결과가 당장 필요 없으면 비동기를 고려한다. 기준은 시차 허용, 재시도·수동 처리 가능, 실패 무시 가능 여부다.
• 수단은 다섯 가지다 — 별도 스레드, 메시징, 트랜잭션 아웃박스, 배치 전송, CDC. 어느 쪽이든 전달 보장은 at-least-once라서 멱등 처리가 전제다.
• 별도 스레드와 아웃박스는 아래 실무에 적용할 점에서 이어서 다룬다.

실무에 적용할 점

• 같은 문제, 두 가지 설계 — 보상 트랜잭션과 아웃박스
  • 외부 API 연동의 정합성, 분산락, 그리고 테스트 전략에서 포인트 전환의 이중 쓰기 문제를 동기 호출 + 보상 트랜잭션 + 대사로 풀었다.
  • 5장을 읽고 나니 같은 문제를 아웃박스로도 설계할 수 있다. 보상 조치가 줄어드는 대신 궁극적 일관성과 발행 지연을 받아들여야 한다.
  • 선택 기준: 사용자가 응답에서 결과를 확인해야 하는 기능이면 동기 + 보상, 결과 확인이 늦어도 되는 기능이면 아웃박스.
• 별도 스레드 비동기 연동은 세 관점으로 점검한다
  • 스레드 관점: 예외로 죽은 워커는 풀이 새 워커로 교체한다. 예외가 빈번하면 스레드 재생성 비용이 쌓인다.
  • 태스크 관점: 예외를 던진 태스크는 재시도되지 않고 유실된다. submit()으로 넣고 get()을 안 부르면 예외도 조용히 사라진다.
  • 프로세스 관점: 재배포나 크래시가 나면 큐에 있던 작업이 전부 유실된다. 유실이 허용되지 않으면 작업을 먼저 DB에 저장하고 상태를 갱신하는 구조로 간다. 아웃박스와 같은 모양이다.
• Spring Boot 스레드 풀 기본값을 그대로 쓰지 않는다

  • 기본값은 core 8에 max와 queue가 무제한이다. 큐가 무한이라 스레드 생성 조건(큐 포화)에 도달하지 않아 풀이 8개로 고정되고, 작업이 밀리면 큐가 힙을 채워 OOM으로 죽는다. (spring-boot#22835)

  • queue-capacity를 유한값으로 지정하고, 거부 정책은 제출한 스레드가 직접 실행하는 CallerRunsPolicy를 기본으로 한다.

    

더 알아볼 것 / 질문

읽으면서 생긴 질문들이다. 답도 직접 찾아봤다.

• 2PC는 왜 느린가 — 아웃박스가 2PC를 대체하는 이유를 파봤다.

  • 코디네이터가 모든 참여자에게 prepare를 보내 전원의 동의를 받은 뒤 commit을 보낸다. 단계마다 네트워크 왕복이 생기고, 참여자마다 각 단계의 결정을 디스크에 기록해야 한다.

  • prepare에 동의한 참여자는 commit 지시가 올 때까지 잠금을 쥔 채 기다린다. 커밋 한 번의 비용이 로컬 트랜잭션의 몇 배가 된다.

  • 액티브MQ 글로벌 트랜잭션이 이 방식이다. 아웃박스는 커밋 시점에는 로컬 트랜잭션 하나만 쓰고, 브로커 전달을 릴레이에 넘겨 이 비용을 커밋 경로 밖으로 뺀다.

    

• @Scheduled는 파드가 여러 개면 어떻게 하나 — 아웃박스 릴레이를 폴링으로 구현하면 바로 만나는 문제다. 인스턴스마다 스케줄러가 독립적으로 돌아 같은 작업이 중복 실행된다.

  • ShedLock: 실행 직전 공유 저장소에 잠금 레코드를 쓰고 성공한 인스턴스만 실행한다. 이미 쓰는 DB를 재사용할 수 있어 도입 비용이 가장 낮다. 중복 방지만 하고 놓친 스케줄 보상은 없다.
  • Quartz 클러스터: 놓친 스케줄 재실행까지 필요할 때 쓴다. 전용 테이블 11개를 관리해야 한다.
  • 실행 주체 분리(k8s CronJob, 전용 인스턴스): 중복 문제가 구조적으로 사라진다. CronJob은 매 실행에 JVM 기동 시간만큼 소요되므로 배치 작업에 맞다.
  • 리더 선출: 리더만 실행하고 죽으면 팔로워가 승계한다. 구현 복잡도가 가장 높다.
  • 공통 결론: 어느 방식이든 노드 장애와 잠금 만료가 겹치면 중복 실행될 수 있다. 작업 멱등성까지 갖춰야 한다. ShedLock의 구조가 부록 C “DB로 분산 잠금 구현하기”의 패턴 그대로라, 부록 C 읽을 때 다시 본다.

• CDC를 크게 운영하면 무엇이 문제가 되나 — 토스증권의 Debezium 개선 여정을 읽었다.

  • 스트리밍은 측정부터 어렵다. DB 이벤트 발생 시각부터 타겟 도착까지 지연을 재고, 파이프라인을 Tier 1(300ms)부터 Tier 4(1시간)까지 등급으로 나눠 운영한다.
  • 구축 시간이 도입 장벽이다. 초기 적재를 배치로 돌리고 Debezium은 스트리밍만 맡는 방식으로 초기 구성을 12시간에서 1시간으로 줄였고, 기존 파이프라인에 테이블 추가는 5분 안에 끝낸다.
  • CDC를 검토하게 되면 구현 여부보다 지연 티어 정의와 초기 스냅샷 전략부터 따진다.

다음 주 Try

• 『주니어 백엔드 개발자가 반드시 알아야 할 실무지식』 6장 읽고 정리하기 — 낙관적 락과 비관적 락의 선택 기준을 포인트 전환 사례와 붙여 정리한다
• CDC 로컬에서 직접 테스트해보고 겪은 경험 정리하기 — Debezium + MySQL binlog 구성으로 5장 CDC 절과 토스증권 사례에서 정리한 내용(지연 측정, 초기 스냅샷)을 손으로 확인한다