최준호

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

• 부가세 배치 19시간 41분 → 약 30분 단축 (100만+ 사업장, Databricks 집계 기반 재설계).
• 발송 이력 2억 건을 Dual Write로 기존 쓰기 경로를 유지하며 이관 (서비스 중단 없음).
• 판매관리 핵심 API p95 80~84% 단축 (6.39억 행 DB, 쿼리 재작성·무중단 인덱스).
• 연말결산 파이프라인 10일 이내 출시 (200만 사업장, 카드매출 32억 건, Spark 최적화).

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

• AI 비서의 채팅, 정책 엔진, 유료 멤버십 백엔드를 단독으로 설계하고 구현.
• 3개 마이크로서비스의 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억 건을 이관했습니다. 사장님별 발송 이력은 한 곳에서 조회하도록 통합했습니다.

39종 표준화 · 17개 발신 프로필 통합 · 발송 오차 4시간 → 1분

Problem

프로젝트마다 알림톡 발송 기능을 중복으로 구현하고 있었습니다. 발송 로직은 레거시 정규식과 17개 발신 프로필에 강하게 결합돼 있었습니다.

Solution

SMS, LMS, 알림톡을 하나의 라이브러리로 묶고 배포용 Gradle 플러그인을 만들었습니다. 발송 대상과 메시지를 만드는 작업을 실제 발송 Job과 분리하고, Databricks → Kotlin 코루틴 → 카카오로 이어지는 3단계 구조를 구성했습니다.

Result

알림 39종을 표준화하고 발송 시간 오차를 4시간에서 1분으로 줄였습니다. 약 67.8만 사업장에 부가세 알림을 안정적으로 발송했습니다.

카드매출 약 32억 건 · 200만 사업장 · 10일 이내 출시

Problem

여러 매출 데이터를 통합해 200만 사업장의 지역별 순위와 7종 지표, 멤버십별 API를 10일 이내에 출시해야 했습니다.

Solution

Spark Window 연산과 collect 사용을 줄이고 작은 기준 데이터는 Broadcast Join으로 처리했습니다. 매출 데이터마다 달랐던 날짜와 금액 기준을 통일하고, 통계 테이블을 조회하는 Kotlin API와 멤버십별 혜택 분기를 구현했습니다.

Result

약 32억 건을 처리하는 파이프라인과 7종 지표, 멤버십별 혜택·예측 API를 10일 이내에 출시했습니다.

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일 타임아웃을 해소했습니다.

백엔드 1인 · 3개 마이크로서비스 · 실시간 응답 스트리밍

Problem

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

Solution

단방향 응답에 맞춰 SSE를 선택하고 3개 서비스의 청크, 도구 상태, 완료 신호 형식을 통일했습니다. 사용 한도 정책은 일별, 월별, 이벤트 규칙으로 나누고 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%를 기록했고 여러 저장소에 적용했습니다.