최준호

200만 소상공인이 사용하는 금융 장부 서비스에서 대용량 배치, 데이터 이관, 핵심 API와 운영 화면을 개발했습니다. 맡은 기능은 설계부터 배포와 운영까지 책임졌습니다.

• 부가세 배치 19시간 41분 → 약 30분 단축 (100만+ 사업장, Databricks 집계 기반 재설계).
• 발송 이력 2억 건을 Dual Write로 기존 쓰기 경로를 유지하며 이관 (서비스 중단 없음).
• 판매관리 핵심 API p95 80~84% 단축 (쿼리 재작성·무중단 인덱스 추가).
• 복권 리워드 지급에 트랜잭셔널 outbox 멱등 파이프라인 설계 (비멱등 외부 발급 API 위 중복 지급 방지, 동일 키 32 동시요청 → 외부 호출 1회 검증).

소상공인용 AI 비서 백엔드를 단독으로 설계하고 구현했습니다. 채팅과 실시간 스트리밍뿐 아니라 정책 엔진과 유료 멤버십까지 맡았습니다.

• AI 비서의 채팅, 정책 엔진, 유료 멤버십 백엔드를 단독으로 설계하고 구현.
• SSE 실시간 스트리밍 API를 신설해 AI 답변을 토큰 단위로 즉시 전달, 응답 대기 없는 채팅 경험을 구현.

100만+ 사업장 · 19시간 41분 → 약 30분 (97.5% 단축)

Problem

약 100만 사업장의 예상세액 계산에 19시간 41분이 걸렸습니다. 원본 카드매출을 직접 조회하는 구조라 단일 writer DB에 배치, API, 통계 쿼리가 몰렸습니다. 커넥션 풀 분리와 배치 튜닝만으로는 마감 시간을 맞출 수 없었습니다.

Solution

계산 작업을 OLTP 밖으로 옮기고 데이터실과 함께 부가세 전용 Delta Tables 증분 집계를 만들었습니다. 카드매출은 사전 집계값을 조회하도록 바꾸고, 매입세액 약 7천만 건은 월별로 나눠 처리해 GC 실패를 없앴습니다.

Result

전체 계산 시간을 약 30분으로 줄여 마감 전에 부가세 알림을 안정적으로 발송했습니다.

2억 건 · Dual Write · 기존 쓰기 경로 유지

Problem

두 DB에 흩어진 알림 발송 내역을 통합해야 했습니다. 초기 upsert 방식은 대량 적재 성능이 낮았고 JPA 기반 이관은 OOM을 일으켰습니다.

Solution

범위별로 DELETE한 뒤 batch INSERT하도록 바꾸고, 배치 크기를 30,000건, 조회 범위를 1주로 제한했습니다. 별도 v2 테이블과 Dual Write로 신규 데이터의 정합성을 유지했습니다. 이관 과정에서 연도 필터와 enum 매핑 버그도 발견해 수정했습니다.

Result

운영 중인 테이블에 영향을 주지 않고 2억 건을 이관했습니다. 사장님별 발송 이력은 한 곳에서 조회하도록 통합했습니다.

6.39억 행 · 핵심 API p95 80~84% 단축

Problem

약 6.39억 행(1.3TB)의 원본 POS 테이블을 조회해 인기 메뉴 응답에 최대 30초가 걸렸고, 90일 조회는 타임아웃됐습니다. 다른 조직이 관리하는 테이블이라 신규 인덱스 추가도 원칙적으로 불가능했습니다.

Solution

실행 계획을 확인해 불필요한 조인을 제거하고, 임시 테이블로 중복을 제거하던 쿼리를 EXISTS로 바꿨습니다. 조회하는 파티션을 84개에서 약 7개로 줄였고, 꼭 필요한 인덱스 1건만 Online DDL로 추가했습니다.

Result

인기 메뉴 p95 944.7ms → 185.7ms, 메뉴 이상 감지 174.9ms → 37.4ms, 판매 알림 246.1ms → 40.2ms로 단축하고 90일 타임아웃을 해소했습니다.

비멱등 외부 발급 API 위 멱등 지급 보장 · 동일 키 32 동시요청 → 외부 호출 1회

Problem

장부 미션 35종을 수행하면 복권 리워드를 지급해야 했습니다. 그런데 외부 리워드 발급 API가 호출할 때마다 발급되는 비멱등 방식이라, 중복 지급을 막을 책임이 호출하는 장부 쪽에 있었습니다. 미션마다 멱등 범위도 평생 1회, 일, 주, 월로 제각각이었습니다.

Solution

트랜잭셔널 outbox 기반 멱등 지급 파이프라인을 설계했습니다. 자연키 복합 UNIQUE로 PENDING 상태를 선점해 동시 요청을 막았고, 외부 발급 호출은 트랜잭션 밖에서 수행해 DB 커넥션을 점유하지 않게 했습니다. 성공하면 지급을 확정하고, 실패하면 outbox에 보존해 relay 워커가 백그라운드에서 재시도하다 한도를 넘기면 DEAD로 격리했습니다. outbox와 지급 양쪽의 멱등 키는 (사업장×유저×미션×주기버킷) 같은 단위로 맞췄습니다.

Result

미션 35종을 하나의 멱등 키 체계로 일반화하고 단위 테스트 62개로 검증했습니다. 동일 키로 32개를 동시에 요청해도 외부 호출이 정확히 1회만 일어나는지를 동시성 테스트로 확인했습니다. 적대적 자가 리뷰로 멀티사업장 멱등 불일치 같은 잠복 결함을 출시 전에 잡아 2026년 6월 프로덕션에 배포했습니다.

백엔드 1인 · 실시간 응답 스트리밍

Problem

AI 답변이 완성될 때까지 사용자는 빈 화면에서 기다려야 했습니다. 백엔드 개발자 한 명이 채팅, 스트리밍, 정책, 멤버십을 모두 설계해야 했습니다.

Solution

단방향 응답에 맞춰 SSE를 선택하고 청크, 도구 상태, 완료 신호로 구성된 응답 형식을 설계했습니다. 사용 한도 정책은 일별, 월별, 이벤트 규칙으로 나누고 Spring AI로 호출 방식을 추상화했습니다.

Result

채팅 API, 실시간 스트리밍, 정책 엔진, 유료 멤버십까지 4개 영역을 단독으로 설계하고 구현했습니다.

운영 830건 · p50 2.6분 · 성공률 93.9%

Problem

코드 리뷰 등록까지 수십 분이 걸렸습니다. AI SDK 4개에 의존했고 대규모 변경을 분석할 때 타임아웃이 발생해 운영 구조도 복잡했습니다.

Solution

저장소 캐시와 언어별 프롬프트를 적용하고, 리뷰 결과를 핵심과 상세로 나눠 출력하도록 바꿨습니다. AI 연동은 Claude Agent SDK 하나로 통합했습니다. Critical 이슈가 발견되면 변경 요청을 남기는 품질 게이트도 추가했습니다.

Result

리뷰 대기 시간을 2~3분으로 줄였습니다. 운영 데이터 830건에서 p50 2.6분, 성공률 93.9%를 기록했고 여러 저장소에 적용했습니다.

단발성 프로젝트 난립 → KOIN 단일 체제 · 레거시 → KOIN_API_V2 전면 마이그레이션

Problem

단발성 포트폴리오용 프로젝트가 반복해서 생겼다 중단되며 동아리 리소스와 온보딩 비용을 잠식했습니다. 레거시 API도 유지보수가 어려운 구조였습니다.

Solution

회장으로서 동아리를 단일 프로젝트(KOIN) 체제로 개편하고, 이벤트 스토밍 워크숍으로 도메인을 다시 설계했습니다. 레거시 API는 KOIN_API_V2로 단계적으로 마이그레이션했습니다.

Result

어드민을 제외한 모든 서비스의 마이그레이션을 완료해 함께 개발하고 유지할 수 있는 코드베이스로 전환했습니다.

조회 쿼리 7회 → 1회 · TPS +11% · 배포 다운타임 30초 → 0

Problem

7인 팀(FE 3, BE 4)으로 반려식물 관리 서비스를 만들면서, 조회 한 번에 N+1 쿼리가 발생해 응답이 느렸고 배포할 때마다 약 30초의 다운타임이 생겼습니다.

Solution

연관 조회의 N+1을 제거해 조회 쿼리를 7회에서 1회로 줄이고, Blue/Green 배포를 도입해 배포 중에도 서비스가 끊기지 않도록 했습니다.

Result

조회 TPS를 11% 높이고 배포 다운타임을 없앴습니다.