송현우

1. 결제 구조 설계와 레거시 리팩토링

• PG별 분기가 서비스 코드 전반에 흩어져 있던 구조를 요청·인증·승인·완료의 공통 도메인 단계로 다시 정의하고, PG마다 다른 처리는 구현체 안으로 옮겨 결제수단 하나를 추가할 때 영향 범위가 전 구간으로 번지던 문제를 없앴습니다.
• 인터페이스를 고쳐야 하는 지점이 나오면 그 PG의 특수성이 아니라 공통 계약 설계의 결함으로 보고, 특정 PG에 종속된 시그니처를 걷어내는 쪽으로 계약을 다듬었습니다.
• 기존 서비스와 얽혀 있던 회원·이용권·결제는 도메인 경계를 다시 긋고 테이블과 모델을 새로 설계해, 운영 중인 기존 서비스는 건드리지 않은 채 단계적으로 분리했습니다.
• 운영 중인 결제 서비스라 회귀 테스트로 현재 동작을 고정한 뒤 결제수단 단위로 옮기고 기존 흐름과 결과를 비교하며 전환했습니다.
• 구독·무료 이용권의 유료 전환·프로모션처럼 조건이 얽힌 과금은 상태 기반 모델로 통합해, 정책이 추가돼도 결제 로직에 분기를 더하지 않도록 했습니다.

2. 결제 정합성 : 멱등성, 동시성 제어, 재처리

• 주문 ID를 멱등키로 삼아 Redis 선점(1차)과 DB Unique 제약(최종 방어)을 겹치는 구조를 표준으로 정리해, 월 1~20건의 중복 결제 요청을 차단하고 있습니다.
• Webhook은 수신 즉시 원문을 로그 테이블에 적재하고 후속 처리를 분리해, 이벤트가 중복으로 오거나 순서가 뒤바뀌어도 원본으로 상태를 추적하고 복구할 수 있습니다.
• 동시 요청 구간은 상태 조건을 건 UPDATE(WHERE status = 'READY')로 단 1건만 상태 전이에 성공하도록 보장하고, 분산 락은 트랜잭션 커밋 이후에 해제되도록 경계를 설계해 커밋 전 해제로 인한 중복 처리를 막았습니다.
• PG 원장과 내부 DB를 비교하는 일 단위 대사 배치와 보정 우선순위 규칙을 정의하고 전 결제수단으로 대상을 넓혀, 장애 이후에도 사람이 손대지 않고 정합성이 수렴하는 안전망을 뒀습니다.

[ 장애 대응 사례 ] 결제 1건에 이용권이 2건 발급된 문제 (Webhook 중복 수신)

• 원인 : 동일한 결제 완료 Webhook이 중복 수신됐는데 지급 로직에 중복 진입을 막는 장치가 없어, 결제 원장은 1건, 지급 원장은 2건으로 벌어졌습니다. (월 5~10건 규모로 이미 발생 중)
• 조치 : 결제 원장 기준으로 중복 지급 건을 전수 추출하고 보정 기준(정상 1건 유지, 초과분 회수)을 먼저 정의한 뒤 전량 보정. 지급 직전 주문 상태를 다시 조회하도록 로직도 보완
• 재발 방지 : ① Redis SETNX 선점(1차 차단) ② 지급 테이블 주문 ID Unique 제약(최종 방어) ③ PG 원장 대조 일 대사 배치(사후 검증) 세 겹
• 결과 : 이후 도입한 카카오페이·페이팔·토스페이에 같은 구조를 그대로 적용해 동일 유형 재발 0건. 대사 배치는 지금도 월 평균 약 10건의 불일치를 CS 접수 전에 검출

[ 동시성 이슈 사례 ] 일회성 결제 전 구간의 중복 지급 취약점 (다중 서버 중복 응답 수신)

• 원인 : 이중화된 두 서버에 같은 주문의 승인 응답이 각각 전달되면서 지급 로직이 서로 다른 프로세스에서 동시에 진입. 일회성 결제의 중복 검사가 단일 서버를 전제로 짜여 있어 서버 간 경합을 막지 못함
• 판단 : 결제수단이 아니라 지급 로직의 공통 진입 지점에 방어를 세움. 진입 차단은 프로세스 외부(Redis SETNX), 최종 확정은 UPDATE … SET 지급상태='지급완료' WHERE order_id=? AND 지급상태='미지급' 형태로 영향 행 수가 1일 때만 지급해 시간창 자체를 제거
• 결과 : 일회성 결제 전 구간에 같은 방어를 적용해 동일 유형 재발 0건. 이용권과 정산 데이터 정합성을 함께 회복했고 이후 추가되는 결제수단은 별도 구현 없이 같은 보호를 받음

3. 정산과 대사 : 오차를 사람보다 배치가 먼저 찾게

• 대사 흐름을 원장 수집·정규화·비교·판정·보정의 공통 단계로 쪼개고 PG마다 다른 부분은 수집·정규화 어댑터로만 국한시켜, 비교와 판정 로직을 하나로 합쳤습니다. 신규 PG는 어댑터만 구현하면 대사 대상에 들어옵니다.
• 자정 전후 승인 건처럼 경계 시점 거래의 귀속 규칙을 기준 시각과 함께 정의해 매일 대사 결과가 흔들리지 않도록 했습니다.
• 판정 결과를 사유별로 분류해 자동 보정 대상과 사람이 확인할 대상을 분리했습니다. PG 승인·내부 미반영 건은 자동 지급, 내부만 반영·PG 미승인 건은 회수 대상으로 격리한 뒤 알림을 보냅니다.
• 포인트와 카드가 함께 쓰이는 복합 결제에서 부분 취소·부분 환불 시 금액 배분 규칙을 정의해 정산 오차 0건을 유지하고 있습니다.
• 배치는 임시 테이블에 적재한 뒤 본 테이블과 원자적으로 교체해, 중간에 실패해도 부분 반영으로 데이터가 오염되지 않게 했습니다.

4. 부하 격리와 무중단 운영

• 실시간 API(캐싱 기반)와 정기결제 갱신·집계 배치(Spring Batch)를 분리해 부하를 격리, 갱신이 몰리는 시간대에도 실시간 결제 응답에 영향이 가지 않도록 했습니다.
• 배치 중복 실행 방지·실패 이력 관리·구간 재처리가 가능한 표준 골격을 정의하고 실패 시 즉시 알림이 가도록 구성했습니다.
• 실행계획을 보고 쿼리와 인덱스를 다시 잡아 대용량 조회 구간의 응답 속도를 개선했습니다.
• 전 구간 로그를 적재하고 Grafana·Scouter로 결제 성공률·응답시간·배치 실행 지표를 모니터링해 장애 시 끊긴 구간을 바로 짚습니다.
• 결제 서비스를 포함한 레거시 서버 30대를 영업 중단 없이 클라우드로 옮겼습니다. 서비스 영향도로 단위를 나눠 순차 전환하고, 개발·스테이징에서 이관 시나리오를 반복 리허설했습니다.

1. 토스페이 간편결제 도입과 PG 레거시 구조 리팩토링 (2026.02 ~ 2026.03)

성과 : 인증과 승인 방식이 다른 PG를 공통 도메인 모델로 통합해, 이후 신규 결제수단은 공통 로직 수정 없이 구현체 추가만으로 붙는 구조 확보

• 기존 KCP·PAYCO와 달리 토스페이는 인증과 승인이 분리돼 공통 처리 로직을 그대로 재사용할 수 없었고, PG별 분기가 코드 전반에 흩어져 결제수단 하나 추가 시 영향 범위가 전 구간으로 번지는 문제가 있었습니다.
• 결제 흐름을 요청·인증·승인·완료의 공통 도메인 단계로 다시 정의하고 PG별 처리는 구현체로 분리. 주문 ID 기반 멱등 처리와 전 구간 로그 적재로 재시도·중복 요청에도 결제가 1건만 성립하도록 했습니다.
• 미완결 결제 건을 모아 판정하는 보정 배치를 설계해 장애·이탈 상황에서도 승인 여부를 PG 원장 기준으로 재확정했습니다.
• 결과 : 토스페이 도입 후 전체 결제 중 5~10% 비중 확보, 신규 PG 연동은 구현체 추가만으로 대응 가능

2. 결제 대사 체계 전면 분석과 재정비 (2026.07 ~ 2026.08)

성과 : 결제수단이 늘 때마다 대사 로직을 복제하던 구조를 공통 대사 파이프라인으로 정리하고, 신규 PG를 대사 대상에 넣는 작업을 어댑터 구현 수준으로 축소

• PG마다 원장 제공 방식(파일·API)·필드·시각 기준이 달라 대사 로직이 결제수단별로 복제돼 있었고, 일부 결제수단은 대사 대상에서 빠져 불일치 사각지대가 있었습니다.
• 전 결제수단의 대사 흐름을 원장 수집·정규화·비교·판정·보정의 공통 단계로 분해하고 PG별 차이를 수집·정규화 어댑터로만 국한, 비교·판정 로직을 단일화했습니다.
• 토스페이·네이버페이처럼 빠져 있던 결제수단은 기존 대사와 병행 운영하며 결과를 비교한 뒤 순차 편입해 운영 서비스에 영향이 가지 않도록 했습니다.
• 결과 : 전 결제수단이 일 대사 대상에 포함되어 사각지대 해소, 신규 PG는 어댑터 구현만으로 대사 대상에 편입

3. 알리페이 결제 도입 (해외 유료 투표권 구매 지원) (2026.08)

성과 : 앞서 리팩토링한 공통 게이트웨이에 알리페이 구현체만 추가해 도입. 공통 결제 로직을 고치지 않고 신규 결제수단을 붙일 수 있음을 실제 도입으로 검증

• 기존 게이트웨이는 국내 PG 위주로 설계돼, 통화 표기·결제 결과 통지 지연·취소 가능 조건 같은 해외 PG 특유의 차이를 구현체가 흡수할 수 있는지 검증되지 않은 상태였습니다.
• 공통 로직에 알리페이 전용 분기를 넣지 않는다는 원칙 아래 요청 파라미터 매핑·응답 코드 해석·취소 가능 조건을 전부 구현체 안으로 흡수. 결과 통지가 늦는 해외 결제 특성을 고려해 승인부터 지급까지 로그를 적재하고 동일한 멱등 처리를 적용했습니다.
• 결과 : 해외 팬의 유료 투표권 구매 경로 확보, 도입 이후 관련 장애 0건. 앞선 리팩토링이 실제 확장 비용을 낮췄음을 확인

4. NHN 벅스 에센셜 매장음악 서비스 구축 (매장 대상 B2B 신규 사업) (2025.09 ~ 2025.11)

성과 : 백엔드 2인 중 회원·결제·구독 빌링·VAN사 연동 전 영역을 단독 설계·개발해 신규 B2B 수익 모델의 기술 기반을 출시 일정 안에 완성

• VAN사 가맹 사업자 검증 : KCP·KOCES 모두 조회 API 없이 파일 배치만 제공. 매일 새벽 스케줄러가 파일을 받아 포맷·건수를 검증한 뒤 적재하는 3단계 비동기 구조와 거래 고유키 중복 방지 제약으로 대사 대상 전 건을 누락·중복 0건으로 적재
• 구독형 빌링과 무료→유료 전환 : 종료일 기준 전환 대상 배치와 이용권 상태·잔여 기간·결제 가능 여부 축의 상태 기반 전환 로직 구현. 전환 실패 건은 재시도 큐로 빼 과금 누락 0건 달성
• 프로모션 확장 대비 : 기존 에센셜 서비스와 분리된 회원·이용권·결제 테이블을 새로 설계해 정책 변경이 기존 서비스에 영향을 주지 않도록 함
• 결과 : 출시 일정 안에 개발 완료, 출시 이후 결제·구독 빌링 관련 장애 0건 유지

5. 페이팔 결제 도입 (해외 결제, Webhook 비동기 처리) (2025.03 ~ 2025.04)

성과 : Webhook 원문 선적재 구조로 이벤트 중복 수신과 순서 역전 상황에서도 결제 상태 오염 0건

• Webhook 전용 API로 수신 즉시 원문을 로그 테이블에 적재한 뒤 후속 처리로 넘겨, 후속 처리가 실패해도 원본 이벤트가 남도록 했습니다.
• 주문 ID 기준 멱등 처리와 이벤트 타임스탬프 기반 상태 전이 검증으로 순서가 뒤바뀐 이벤트가 최신 상태를 덮어쓰지 못하게 막고, 처리 단위를 트랜잭션으로 나눠 실패 건만 재처리했습니다.
• 비동기 결제에는 로그 선적재·멱등성·순서 검증·재처리 가능성 네 가지가 같이 있어야 함을 체감했고, 이후 토스페이 도입에 그대로 적용했습니다.

6. 카카오페이 간편결제 도입과 대사 체계 구축 (2025.06)

성과 : 도입 후 전체 결제수단 중 약 15% 비중 확보, 일 단위 대사 배치로 PG와 내부 DB 불일치를 자동 검출·보정

• 사용자 이탈·비정상 종료 시 PG 데이터와 내부 결제 데이터가 어긋날 수 있었고, 멤버·빌링 등 여러 서버로 나뉜 환경이라 결제 데이터 유실 여지가 있었습니다.
• PG 원장과 내부 DB를 주기적으로 비교하는 일 대사 배치를 구현하고 주문 ID(멱등키) 기준 비교 규칙·보정 우선순위를 정의. Redis 기반 중간 저장과 서버 간 동기화로 데이터 유실을 방지했습니다.
• 결과 : 전체 결제수단 중 약 15% 비중, 대사 배치는 상시 동작하며 월 평균 약 10건의 불일치를 CS 접수 전에 보정

7. 외부 채널 연동과 복합 결제 (SK 베네피아, 오퍼월, 앱 내 결제) (2024.01 ~ 2025.08)

성과 : 복지몰·오퍼월·앱 내 결제처럼 성격이 다른 외부 채널을 하나의 결제 구조로 흡수

• 요청부터 응답까지 전 구간 로그 테이블을 설계·적재해 장애 시 원인 구간을 바로 짚을 수 있게 하고, API 키 암호화 저장·상점 ID 암호화 검증 구조를 설계했습니다.
• 배치 실패 시 재처리가 어려웠던 문제는 임시 테이블 적재 후 본 테이블과 원자적 교체 방식으로 바꾸고, 실패 시 즉시 알림 메일로 복구 시간을 줄였습니다.
• 포인트와 카드가 함께 쓰이는 복합 결제에서 부분 취소·부분 환불 금액 배분 규칙을 정의해 정산 오차 0건 유지

8. 세이클럽 인기투표 서비스 도입 (2024.12 ~ 2025.01)

성과 : 실시간 API와 집계 배치를 분리 설계해 세이클럽 MAU 약 5% 증가에 기여

• 처리 목적·부하 특성이 다른 실시간 투표 API(캐싱 기반)와 일별 집계(Spring Batch + Cron)를 나눠 부하를 격리했습니다.
• 투표 발생 시 캐시와 DB를 맞추는 로직을 설계하고 동점·중복 투표 같은 예외 케이스를 먼저 정의한 뒤 처리 쿼리를 작성했습니다.
• 런칭 후 월간 참여 횟수가 계속 늘며 세이클럽 MAU 약 5% 증가에 기여

9. 레거시 서버 NHN Cloud 이관 (2026.04 ~ 2026.06)

성과 : 결제 서비스를 포함한 레거시 서버 30대를 서비스 중단 없이 이관하고 배포 환경 표준화 기반 마련

• 설정값·스케줄러·외부 연동을 항목화한 체크리스트로 사전 검증을 돌려 이관 후 장애 가능성을 낮췄습니다.
• 영업 중인 서비스라 30대를 한 번에 옮기지 않고 서비스 영향도 기준으로 이관 단위를 나눠 순차 전환하고, 개발·스테이징에서 이관 시나리오를 반복 리허설했습니다.
• 장애 없이 운영 환경 전환을 마치고 서버 운영·배포 환경 표준화의 기반을 마련

1. 사이렌24 신용평가 자동화 (2023.02 ~ 2023.04)

성과 : 일주일 넘게 걸리던 신용평가와 결과 반영 업무를 1일 이내로 단축 (약 86% 감소)

• 수동 신용평가 프로세스를 자동화하며 신용평점 산정 로직을 DB 프로시저로 개발하고, 금융감독원 정책 변경에 따른 산정 방식 수정을 맡았습니다.
• 사업팀 수기 결과와 자동 산정 데이터를 1:1로 대조하며 오차 원인을 찾고 정책 변경 이력을 반영, 예외 케이스는 규칙 기반으로 세분화해 수기 결과와 전 건 일치를 확인했습니다.
• 금융 데이터 보안 요건을 고려해 테이블 설계·프로시저 개발 단계에서 암호화·복호화, 저장·삭제 주기를 먼저 반영했습니다.

• 기술 블로그 운영 : shw7349.tistory.com (결제 정합성, Apache Kafka, Kubernetes 등 백엔드·인프라 주제로 누적 50편)
• Kafka 기반 결제 이벤트 파이프라인 (Kotlin / Spring Boot) : 실무에서 겪은 Webhook 중복 수신 장애를 이벤트 드리븐으로 다시 설계한 개인 프로젝트. 원문 선적재, 컨슈머 멱등 처리, 재시도와 DLQ 격리, 대사 배치까지 구현
• GitHub : github.com/shw7349