사례 1
해외결제 서비스: 구축부터 상품별 혜택 정책 변경까지
서비스. 원화로 충전한 선불카드로 해외에서 결제하고 ATM에서 출금합니다. 해외결제 수수료를 면제하고 환율은 매매기준율로 적용해서, 카드사가 청구하는 금액과 고객이 내는 금액의 차이를 발급사가 고객 혜택으로 보전합니다. 이 서비스를 처음 만들 때부터 혜택 정책을 바꾼 올해까지 이어서 맡았습니다.
1단계, 구축 (2023년 2월 ~ 8월). 해외 ATM 출금과 온라인, 오프라인 결제를 국제 브랜드 규격에 맞춰 열었습니다. 혜택 계산 로직은 사업 담당자와 함께 설계했고, WBS 작성과 승인 서버 설계, 개발을 맡았습니다. 설계 중에 승인과 정산 흐름이 동기로 묶여 느린 하위 연동 하나가 실시간 승인 경로를 붙잡는 구조를 발견했고, 승인 판단과 응답만 동기 경로에 남기고 매입 데이터 생성, 정산, 후처리는 RabbitMQ 큐 뒤로 보냈습니다.
2단계, 상품별 혜택 제외 (2026년 6월 중순 ~ 8월 중순). 법인 상품에는 같은 혜택을 줄 필요가 없어졌습니다. 카드 상품 단위로 혜택을 끌 수 있게 바꾸면서, 결제 시점에 상품의 혜택 설정을 조회하고 그 결과에 따라 고객 출금액을 다르게 계산하게 했습니다. 개발요건 정의(요구사항 정의서 작성, WBS 리뷰)와 출금액 차등 계산, 결제 시 혜택 설정 확인을 맡았고, 상품, 어드민, 앱, 정산, QA 담당과 한 일정으로 움직였습니다.




정책 결정
| 설계 결정 | 결정 | 왜 |
|---|---|---|
| 동기와 비동기의 경계 (1단계) | 승인 판단, 응답, 전문 보정만 동기. 매입 데이터, 정산, 대사, 알림은 큐 뒤로 | 후처리가 느려져도 승인은 멈추지 않아야 한다 |
| 혜택 판단 시점 (2단계) | 결제 시점에 카드 상품의 혜택 제외 여부를 정책 서버에서 조회 | 상품 설정을 바꾸면 다음 결제부터 바로 반영된다 |
| 출금액 계산 | 제외 상품은 카드사 전문의 원화금액(전신환매도율, 수수료 포함) 그대로. 적용 상품은 외화금액 × 매매기준율 + 고객부담금액, 수수료 면제. 원 단위 미만 절삭 | 예시: USD 10이 13,479원과 10,992원으로 갈리고 차액 2,487원 = 수수료 172 + 환율 우대 2,315 |
| 결과 기록 | 거래마다 혜택 적용 여부, 수수료 면제액, 환율 우대액 저장 | 정산 보고서의 혜택 구분과 보전 금액, 앱 거래내역 표시가 같은 값을 본다 |
결과. 1단계는 7개월 만에 오픈했고, 오픈 뒤 제휴 카드 상품이 늘었지만 처음 잡은 승인, 출금 구조를 바꾸지 않고 확장해 쓰고 있습니다. 2단계는 6월 중순 착수해 8월 중순 사내 오픈했고 9월 초 앱 심사까지 마쳤습니다.
사례 2
매입사를 거치지 않는 직가맹점 연동: 편의점 결제, 충전, 환불과 택시 직승인
축. 가맹 채널을 매입사 경로에 태우지 않고 직가맹점 연동 전문으로 승인 서버에 직접 붙였습니다. 편의점에서는 그 덕분에 결제뿐 아니라 충전과 환불까지 같은 창구에서 열었고, 같은 방식을 택시 결제로 넓혔습니다.
편의점 (2021년 ~ 현재). 편의점 채널에서는 선불 지갑으로 결제만 가능했고, 국내 계좌를 연결할 수 없는 이용자는 잔액을 채울 방법이 없었습니다. CU에 IC 카드 결제에 더해 앱 바코드 기반 결제, 충전, 환불을 열었고 GS25에는 바코드 기반 여러 결제 수단을 열었습니다. 그 채널 위에서 외국인 방문객이 계좌 없이 편의점에서 충전해 쓰고 출국 전에 남은 잔액을 편의점에서 환불받는 서비스를 정의해 런칭했습니다. 전문 규격보다 "누가, 어디서, 무엇을, 얼마까지"를 편의점 본사와 정하는 일이 컸습니다.
택시 (2026년 6월 중순 ~ 진행 중). 지금까지는 택시 단말이 IC 칩 데이터로 지역화폐 카드인지 판별해, 지역화폐 카드는 VVAN 전문으로, 그 외 카드는 다른 경로로 직접 나눠 보냈습니다. 바뀐 구조에서는 단말이 모빌리티 플랫폼으로만 보내고, 플랫폼이 카드빈 대역으로 판별해 지역화폐 카드만 직가맹점 연동 전문으로 승인 서버에 보냅니다. 택시는 결제만 제공합니다. 승인 담당으로 요건 정의, 승인 서버 설계와 개발, 외부 테스트를 맡았고 정산은 별도 담당자가 맡았습니다. 가장 중요한 부분은 단말에서 올라오는 IC 칩 데이터가 플랫폼을 거쳐 승인 서버까지 온전히 오는지이고, 지금도 그 검증을 진행하고 있습니다.



정책 결정
| 정책 항목 | 결정 | 왜 |
|---|---|---|
| 연결 방식 | 매입사 경로가 아니라 직가맹점 연동 전문으로 승인 서버에 직접 | 결제 외의 선불 고유 거래(충전, 환불)를 열 수 있다 |
| 편의점: 누가 | 회원과 파트너 계약 회원. 외국인 선불카드는 계좌 연결 없이 | 계좌를 만들 수 없는 이용자가 서비스의 대상 |
| 편의점: 무엇을 | 결제, 충전, 잔액 환불을 같은 창구에서. 원거래 취소는 별도 흐름 | 환불과 취소를 섞으면 정산이 깨진다 |
| 편의점: 예외 | 충전 통신 실패 시 수납 취소가 우선. 환불은 응답 후 현금 지급 | 현금이 오간 뒤 전산이 틀어지면 매장에서 수습이 안 된다 |
| 택시: 분기 위치 | 단말이 아니라 플랫폼이 카드빈 대역으로 분기. 플랫폼 쪽 기존 전문은 수정 없이 | 지역화폐 카드만 직가맹점 연동 전문으로 받는다 |
| 택시: 가맹점과 대사 | 가맹점 번호 채번 방식(ASP, KA), 법인과 개인 분리. 차량 ID와 운전자 ID 실시간 전달, 승인대사 파일에 추적번호 | 택시 한 대, 기사 한 명 단위로 승인과 대사를 맞춘다 |
| 택시: 제공 범위 | 결제, 취소, 망취소. 충전과 환불 없음 | 결제 전용 채널. 현금이 오가는 충전과 환불은 편의점 창구에서만 |
결과. 편의점은 파트너 계약 회원들이 지금 이 결제, 충전, 환불 서비스를 쓰고 있고, 외국인 선불카드 서비스로 계좌를 만들 수 없는 이용자층에 서비스가 열렸습니다. 택시는 운영 배포까지 마쳤고, 단말 IC 칩 데이터를 플랫폼과 함께 검증하는 단계입니다.
사례 3
규제와 브랜드의 승인을 기획에 넣는 법: VISA 3-D Secure 등록, WeChat QR 매장 런칭
VISA 3-D Secure (7개월, 2018.02 – 08). 인증 서비스를 만들고 회사를 VISA 공식 서비스 프로바이더로 등록해야 했습니다. 세 당사자가 정해진 순서로 "예"를 해야 끝나는 일이었습니다. VISA 글로벌 기술팀의 인증 테스트, 태국 금융 규제기관의 질의, 런칭 날짜가 필요한 사업 쪽. 인증 테스트가 실패하면 그것이 내 구현 때문인지, 환경 차이인지, 규격 해석 차이인지부터 갈라야 했습니다.
WeChat QR (4개월, 2017.08 – 11). WeChat 해외 결제 시스템을 통한 Static QR 단말 결제를 태국 Central Group 매장에 런칭했습니다. 요구사항 협의, 개발, 런칭 당일 매장에 서 있는 것까지 맡았습니다.
정책 결정
| 배운 것 | 지금도 쓰는 방식 |
|---|---|
| 파트너의 테스트가 이유 없이 실패하면 | 내 코드를 고치기 전에 상대 하네스를 규격대로 로컬에 재현한다. 대부분 평범한 버그가 된다 |
| 규제기관과 브랜드는 우회할 장애물이 아니라 | 완료의 정의다. 처음부터 그 기준으로 계획과 보고를 짠다 |
| 세 당사자가 다른 속도로 움직이면 | 주 단위로 "남은 미지수 목록"을 줄이는 것을 진척으로 보고한다 |
결과. TreePay Thailand가 VISA V3D 서비스 프로바이더로 정식 등록됐고, WeChat QR은 Central Group 매장에서 4개월 만에 열렸습니다.
부록
직접 만든 기획 산출물과 공개 코드
회사 업무가 아니라 개인적으로 만든 것입니다.
아래는 회사 업무가 아니라 제가 개인적으로 만든 것입니다. 결제 API 스펙을 쓰는 쪽과 읽는 쪽을 모두 해 본 사람이 어떤 문서를 만드는지 보여 드리기 위해 넣었습니다.
| 산출물 | 내용 | 공고와의 접점 |
|---|---|---|
| 결제 SDK, API 연동 표면 분석 (2026-07, 한 POS 플랫폼의 공개 개발자 문서 기준) | 연동 트랙 4개(프론트 플러그인, POS 플러그인, Open API와 웹훅, Windows DLL)로 정리하고 트랙별로 상대 개발자가 누구이고 무엇을 먼저 묻는지 매핑. 문서에 없는 것은 가정으로 표시 | 결제 API 및 인터페이스 스펙 정의, 파트너 연동 기획 |
| 웹훅 시뮬레이터 | 정상, 중복 수신, 순서 역전, 느린 핸들러, 서명 불일치, 429 여섯 시나리오를 하드닝 전후로 비교. 서명은 실제 HMAC 계산 | 결제 실패와 예외 케이스 정책 수립 |
| 파트너 온보딩 키트 | 연동 플로우, 자가진단 10항목, 실패 10선, 결제 필드 번역표(승인번호, VAN, 공급가, 정산 등), 담당자 확인 목록 | 백오피스, 어드민 기획, 파트너 커뮤니케이션 |
| github.com/bgpark80/tosspayments-integration-demo | 결제 SDK와 코어 API 연동 데모. 금액 변조 방지, 멱등키, 웹훅 기반 후처리. Spring Boot | 승인, 취소, 환불 라이프사이클 구현 관점 |
| github.com/bgpark80/netty-tcp-server | TCP 서버 라이브러리. 프레이밍, 스레드 분리, 읽기 타임아웃, 정상 종료. 설계 문서와 CI 포함 | 결제 전문 서버의 세션 관리를 코드로 옮긴 형태 |
범위
이 포트폴리오에 적지 않은 것
- 거래 건수, 거래액, 회원 수 같은 회사 영업 정보.
- 회사명, 사람 이름, 사내 시스템명. 설계서와 WBS 캡처는 이것들을 지우거나 일반 명칭으로 바꿔 실었고, 나머지 도식은 설명을 위한 단순화입니다.
- 결제 성공률, 승인율 같은 지표 체계를 직접 운영한 경험. 없는 것은 없다고 적는 편이 면접에서 서로 시간을 아낍니다.