포트폴리오 | PM Lead (결제 스쿼드) 지원, 트래블월렛

결제 라이프사이클 정책과 파트너 연동 설계

결제 19년. 승인 서버를 직접 만들었고, 그 서버에 붙는 카드사, VAN, 편의점과 영화관 같은 가맹 브랜드, 지역화폐 운영사와의 연동을 요구사항부터 런칭까지 맡았습니다. 직함은 개발이었고 일의 절반은 기획이었습니다.

기여도 50% 이상으로 주도한 사례 3건입니다. 사례마다 배경, 역할과 기여, 플랫폼 구조와 백엔드 시퀀스 다이어그램, 정책 결정, 결과 순서로 적었습니다. 도식은 설명을 위해 단순화했고 사내 규격과 거래 규모는 적지 않았습니다.

경력
결제 19년 (2007년부터)
사례
3건, 모두 주 담당
수록
플랫폼 구조, 시퀀스 다이어그램, 데이터 구조, 정책 결정 표, WBS
공개 코드
github.com/bgpark80
연락처
이력서에 기재

사례 개요

  1. 사례 1해외결제 서비스: 구축부터 상품별 혜택 정책 변경까지

    연표, 플랫폼 구조, 시퀀스 2, 요구사항 그림, 데이터 구조, WBS

  2. 사례 2매입사를 거치지 않는 직가맹점 연동: 편의점 결제, 충전, 환불과 택시 직승인

    플랫폼 구조, 시퀀스 2, 택시 흐름(AS-IS, TO-BE), WBS

  3. 사례 3규제와 브랜드의 승인을 기획에 넣는 법: VISA 3-D Secure 등록, WeChat QR 매장 런칭

    이해관계자 흐름, 시퀀스 1, 배운 것 표

사례 1

해외결제 서비스: 구축부터 상품별 혜택 정책 변경까지

선불카드 해외결제 (KB카드, Mastercard)구축 2023.02 – 2023.08, 혜택 정책 변경 2026년 6월 중순 – 8월 중순역할: 혜택 계산 로직 공동 설계, WBS, 승인 서버 설계와 개발, 개발요건 정의기여도: 주 담당 (50% 이상)

서비스. 원화로 충전한 선불카드로 해외에서 결제하고 ATM에서 출금합니다. 해외결제 수수료를 면제하고 환율은 매매기준율로 적용해서, 카드사가 청구하는 금액과 고객이 내는 금액의 차이를 발급사가 고객 혜택으로 보전합니다. 이 서비스를 처음 만들 때부터 혜택 정책을 바꾼 올해까지 이어서 맡았습니다.

1단계, 구축 (2023년 2월 ~ 8월). 해외 ATM 출금과 온라인, 오프라인 결제를 국제 브랜드 규격에 맞춰 열었습니다. 혜택 계산 로직은 사업 담당자와 함께 설계했고, WBS 작성과 승인 서버 설계, 개발을 맡았습니다. 설계 중에 승인과 정산 흐름이 동기로 묶여 느린 하위 연동 하나가 실시간 승인 경로를 붙잡는 구조를 발견했고, 승인 판단과 응답만 동기 경로에 남기고 매입 데이터 생성, 정산, 후처리는 RabbitMQ 큐 뒤로 보냈습니다.

2단계, 상품별 혜택 제외 (2026년 6월 중순 ~ 8월 중순). 법인 상품에는 같은 혜택을 줄 필요가 없어졌습니다. 카드 상품 단위로 혜택을 끌 수 있게 바꾸면서, 결제 시점에 상품의 혜택 설정을 조회하고 그 결과에 따라 고객 출금액을 다르게 계산하게 했습니다. 개발요건 정의(요구사항 정의서 작성, WBS 리뷰)와 출금액 차등 계산, 결제 시 혜택 설정 확인을 맡았고, 상품, 어드민, 앱, 정산, QA 담당과 한 일정으로 움직였습니다.

그림 1-1 프로젝트 연표
2023 2024 2025 2026 1단계 해외결제 구축 2023년 2월 ~ 8월, 혜택 적용 상태로 오픈 운영과 확장: 제휴 카드 상품이 늘어도 같은 승인, 출금 구조 유지 2단계 상품별 혜택 제외 2026년 6월 중순 ~ 8월 중순 오픈
그림 1-2 플랫폼 구조 (설명용 단순화)
고객 앱 원화 충전 거래내역에 혜택 표시 해외 가맹점 / ATM Mastercard 네트워크 제휴 카드사 경유 결제 승인 서버 해외 승인 전문 수신 상품 혜택 설정 조회 출금 요청, 승인 응답 출금/계좌 서버 출금액 계산 (혜택 분기) 잔액 차감 해외결제 상세 저장 정책, 정산, 어드민 상품별 혜택 제외 설정 혜택 구분 정산 보고 보전 금액 산출 초록: 내가 설계에 참여한 구간. 1단계는 승인과 출금, 2단계는 혜택 분기와 그 결과가 흘러가는 정산, 화면까지.
그림 1-3 1단계 시퀀스: 승인과 후처리의 분리
브랜드 네트워크 승인 서버 RabbitMQ 매입/정산 처리 승인 요청 (브랜드 규격 전문) 검증, 칩 데이터 포맷 보정 승인 응답 승인 결과 이벤트 발행 (거래 키 포함) 소비: 매입 데이터 생성, 정산 반영 실패 시 재시도. 같은 키는 한 번만 반영 브랜드별 칩 데이터(9F10) 포맷이 달라 Mastercard 거래는 길이 값을 보고 보정하는 규칙을 동기 경로 안에 두었다.
그림 1-4 2단계 시퀀스: 혜택 제외 여부에 따른 출금액 분기 (설계서에서 이름과 사내 시스템명만 바꿈)
해외결제 혜택 분기 시퀀스 다이어그램
그림 1-5 2단계 요구사항 정의서에 넣으려고 만든 설명 그림 (예시 환율, 원 단위 미만 절삭)
혜택 제외와 적용의 출금액 비교
그림 1-6 데이터 구조 (개념 모델)
카드 상품 상품 식별자 혜택 제외 여부 (2단계 신규) 어드민에서 설정 해외결제 거래 상세 외화금액, 적용 환율 수수료, 고객 출금액 혜택 적용 여부 (2단계 신규) 수수료 면제액, 환율 우대액 정산 보고 혜택 구분 (2단계 신규) 보전 금액 산식 수정 거래내역 (앱, 어드민) 혜택 적용 거래 구분 표시 면제액, 우대액 함께 표시 혜택 여부를 상품에 한 번, 거래에 한 번 남겨서 상품 설정이 나중에 바뀌어도 과거 거래의 정산 근거가 남게 했다.
그림 1-7 2단계 WBS (1/2): 요건, 기획, 설계. 담당자 칸은 지움
WBS 요건부터 설계까지
그림 1-8 2단계 WBS (2/2): 개발, 테스트, 배포, 오픈
WBS 개발부터 오픈까지

정책 결정

설계 결정결정왜
동기와 비동기의 경계 (1단계)승인 판단, 응답, 전문 보정만 동기. 매입 데이터, 정산, 대사, 알림은 큐 뒤로후처리가 느려져도 승인은 멈추지 않아야 한다
혜택 판단 시점 (2단계)결제 시점에 카드 상품의 혜택 제외 여부를 정책 서버에서 조회상품 설정을 바꾸면 다음 결제부터 바로 반영된다
출금액 계산제외 상품은 카드사 전문의 원화금액(전신환매도율, 수수료 포함) 그대로. 적용 상품은 외화금액 × 매매기준율 + 고객부담금액, 수수료 면제. 원 단위 미만 절삭예시: USD 10이 13,479원과 10,992원으로 갈리고 차액 2,487원 = 수수료 172 + 환율 우대 2,315
결과 기록거래마다 혜택 적용 여부, 수수료 면제액, 환율 우대액 저장정산 보고서의 혜택 구분과 보전 금액, 앱 거래내역 표시가 같은 값을 본다

결과. 1단계는 7개월 만에 오픈했고, 오픈 뒤 제휴 카드 상품이 늘었지만 처음 잡은 승인, 출금 구조를 바꾸지 않고 확장해 쓰고 있습니다. 2단계는 6월 중순 착수해 8월 중순 사내 오픈했고 9월 초 앱 심사까지 마쳤습니다.

사례 2

매입사를 거치지 않는 직가맹점 연동: 편의점 결제, 충전, 환불과 택시 직승인

편의점 2021 – 현재택시 2026년 6월 중순 – 진행 중역할: 서비스 정의, 정책 결정, 편의점 본사 연동 창구, 택시 승인 요건 정의와 승인 서버 설계, 개발기여도: 주 담당 (50% 이상)

축. 가맹 채널을 매입사 경로에 태우지 않고 직가맹점 연동 전문으로 승인 서버에 직접 붙였습니다. 편의점에서는 그 덕분에 결제뿐 아니라 충전과 환불까지 같은 창구에서 열었고, 같은 방식을 택시 결제로 넓혔습니다.

편의점 (2021년 ~ 현재). 편의점 채널에서는 선불 지갑으로 결제만 가능했고, 국내 계좌를 연결할 수 없는 이용자는 잔액을 채울 방법이 없었습니다. CU에 IC 카드 결제에 더해 앱 바코드 기반 결제, 충전, 환불을 열었고 GS25에는 바코드 기반 여러 결제 수단을 열었습니다. 그 채널 위에서 외국인 방문객이 계좌 없이 편의점에서 충전해 쓰고 출국 전에 남은 잔액을 편의점에서 환불받는 서비스를 정의해 런칭했습니다. 전문 규격보다 "누가, 어디서, 무엇을, 얼마까지"를 편의점 본사와 정하는 일이 컸습니다.

택시 (2026년 6월 중순 ~ 진행 중). 지금까지는 택시 단말이 IC 칩 데이터로 지역화폐 카드인지 판별해, 지역화폐 카드는 VVAN 전문으로, 그 외 카드는 다른 경로로 직접 나눠 보냈습니다. 바뀐 구조에서는 단말이 모빌리티 플랫폼으로만 보내고, 플랫폼이 카드빈 대역으로 판별해 지역화폐 카드만 직가맹점 연동 전문으로 승인 서버에 보냅니다. 택시는 결제만 제공합니다. 승인 담당으로 요건 정의, 승인 서버 설계와 개발, 외부 테스트를 맡았고 정산은 별도 담당자가 맡았습니다. 가장 중요한 부분은 단말에서 올라오는 IC 칩 데이터가 플랫폼을 거쳐 승인 서버까지 온전히 오는지이고, 지금도 그 검증을 진행하고 있습니다.

그림 2-1 편의점 플랫폼 구조 (설명용 단순화)
회원 앱 / 선불카드 회원 식별 바코드 생성 잔액 조회 편의점 POS 바코드 스캔 현금 수납 (충전) 현금 지급 (환불) 편의점 본사 거래 중계 점포, 단말 식별 일 마감 대사 승인 서버 직가맹점 연동 전문 바코드 검증 잔액 확인, 차감, 증가 잔액 원장 / 정산 거래 유형별 원장 기록 편의점 정산 데이터 환불, 취소 구분 초록: 내가 설계와 연동 협의를 맡은 구간. 매입사를 거치지 않으므로 충전, 환불 같은 선불 고유 거래를 같은 전문으로 연다.
그림 2-2 편의점 시퀀스: 바코드 결제
회원 앱 편의점 POS 편의점 본사 승인 서버 잔액 원장 바코드 생성 요청 스캔한 바코드 + 금액으로 승인 요청 승인 요청 (점포, 단말 식별 포함) 바코드 유효성 검증 잔액 확인 후 차감, 거래 기록 결과 (잔액 부족 시 거절 사유) 승인 응답 (승인번호 또는 거절 코드) 응답 중계, 영수증 출력 정책: 승인 응답 전에는 어느 쪽도 거래를 완료로 보지 않는다.
그림 2-3 편의점 시퀀스: 충전과 환불
편의점 POS 편의점 본사 승인 서버 잔액 원장 충전 요청 (현금 수납 금액) 충전 요청 중계 충전 가능 조건 확인 후 잔액 증가 결과 충전 완료 응답. 실패 시 수납 취소가 우선 환불 요청 (환불 가능액 조회 선행) 환불 요청 중계 잔액 기준 환불액 확정, 차감, 환불 기록 환불 승인. 현금 지급은 응답 이후에만 환불은 '원거래 취소'가 아니라 '잔액 반환'이다. 둘을 원장에서 구분해야 편의점 정산과 회원 잔액이 둘 다 맞는다.
그림 2-4 승인 서버 안의 결제 시퀀스: 전문 수신, 가맹점 확인, 쿠폰과 포인트 혜택 적용, 잔액 차감, 후처리 이벤트까지 (설계서에서 사내 시스템명만 일반 명칭으로 바꿈)
승인 서버 결제 시퀀스 다이어그램: 전문 게이트웨이, 승인 서버, 가맹점 정보, 쿠폰, 혜택 정책, 포인트, 자동충전, 메시지 큐, 알림 서버
그림 2-5 택시 결제 흐름: 바뀌기 전과 후 (기능 요구사항에서 회사명과 사내 시스템명만 바꿈)
택시 결제 AS-IS와 TO-BE 흐름
그림 2-6 택시 직승인 WBS. 담당자 칸은 지움
택시 직승인 WBS

정책 결정

정책 항목결정왜
연결 방식매입사 경로가 아니라 직가맹점 연동 전문으로 승인 서버에 직접결제 외의 선불 고유 거래(충전, 환불)를 열 수 있다
편의점: 누가회원과 파트너 계약 회원. 외국인 선불카드는 계좌 연결 없이계좌를 만들 수 없는 이용자가 서비스의 대상
편의점: 무엇을결제, 충전, 잔액 환불을 같은 창구에서. 원거래 취소는 별도 흐름환불과 취소를 섞으면 정산이 깨진다
편의점: 예외충전 통신 실패 시 수납 취소가 우선. 환불은 응답 후 현금 지급현금이 오간 뒤 전산이 틀어지면 매장에서 수습이 안 된다
택시: 분기 위치단말이 아니라 플랫폼이 카드빈 대역으로 분기. 플랫폼 쪽 기존 전문은 수정 없이지역화폐 카드만 직가맹점 연동 전문으로 받는다
택시: 가맹점과 대사가맹점 번호 채번 방식(ASP, KA), 법인과 개인 분리. 차량 ID와 운전자 ID 실시간 전달, 승인대사 파일에 추적번호택시 한 대, 기사 한 명 단위로 승인과 대사를 맞춘다
택시: 제공 범위결제, 취소, 망취소. 충전과 환불 없음결제 전용 채널. 현금이 오가는 충전과 환불은 편의점 창구에서만

결과. 편의점은 파트너 계약 회원들이 지금 이 결제, 충전, 환불 서비스를 쓰고 있고, 외국인 선불카드 서비스로 계좌를 만들 수 없는 이용자층에 서비스가 열렸습니다. 택시는 운영 배포까지 마쳤고, 단말 IC 칩 데이터를 플랫폼과 함께 검증하는 단계입니다.

사례 3

규제와 브랜드의 승인을 기획에 넣는 법: VISA 3-D Secure 등록, WeChat QR 매장 런칭

TreePay 태국2017.08 – 2018.08역할: 요구사항부터 프로덕션, 인증과 규제 협의, 매장 런칭기여도: 주 담당 (50% 이상)

VISA 3-D Secure (7개월, 2018.02 – 08). 인증 서비스를 만들고 회사를 VISA 공식 서비스 프로바이더로 등록해야 했습니다. 세 당사자가 정해진 순서로 "예"를 해야 끝나는 일이었습니다. VISA 글로벌 기술팀의 인증 테스트, 태국 금융 규제기관의 질의, 런칭 날짜가 필요한 사업 쪽. 인증 테스트가 실패하면 그것이 내 구현 때문인지, 환경 차이인지, 규격 해석 차이인지부터 갈라야 했습니다.

WeChat QR (4개월, 2017.08 – 11). WeChat 해외 결제 시스템을 통한 Static QR 단말 결제를 태국 Central Group 매장에 런칭했습니다. 요구사항 협의, 개발, 런칭 당일 매장에 서 있는 것까지 맡았습니다.

그림 3-1 3-D Secure 등록까지의 흐름과 이해관계자
요구사항, 설계 VISA 규격 해석 사업 쪽 런칭 요구 내부 구현 범위 확정 구현, 자체 검증 인증 서버 구축 디렉토리 서버 동작을 규격대로 모사한 시뮬레이터 실패 원인을 구현/환경/해석으로 분류 VISA 인증 테스트 글로벌 기술팀과 영어 협의 테스트 하네스 실패 항목 추적 규제기관 질의 책임 소재, 데이터 보관 관점 질의 대응 열린 질문 0이 완료 기준 서비스 프로바이더 등록 VISA 공식 등록 매장과 가맹점에 서비스 개시 "동작한다"가 완료가 아니라 VISA 등록과 규제기관의 열린 질문 0이 완료였다. 그 기준으로 계획하고 보고했다.
그림 3-2 시퀀스: WeChat Static QR 매장 결제 (설명용 단순화)
고객 WeChat 앱 매장 QR / 단말 TreePay 결제 서버 WeChat 해외 결제망 매장 Static QR 스캔, 금액 입력 결제 요청 가맹점, 주문 확인 요청 확인 응답 결제 완료 통지 매장 단말에 완료 표시 Static QR은 단말이 결제를 '요청'하지 않고 '통지'를 받는 구조라, 완료 통지 유실 시 매장 확인 규칙을 먼저 정했다.

정책 결정

배운 것지금도 쓰는 방식
파트너의 테스트가 이유 없이 실패하면내 코드를 고치기 전에 상대 하네스를 규격대로 로컬에 재현한다. 대부분 평범한 버그가 된다
규제기관과 브랜드는 우회할 장애물이 아니라완료의 정의다. 처음부터 그 기준으로 계획과 보고를 짠다
세 당사자가 다른 속도로 움직이면주 단위로 "남은 미지수 목록"을 줄이는 것을 진척으로 보고한다

결과. 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-serverTCP 서버 라이브러리. 프레이밍, 스레드 분리, 읽기 타임아웃, 정상 종료. 설계 문서와 CI 포함결제 전문 서버의 세션 관리를 코드로 옮긴 형태

범위

이 포트폴리오에 적지 않은 것

  • 거래 건수, 거래액, 회원 수 같은 회사 영업 정보.
  • 회사명, 사람 이름, 사내 시스템명. 설계서와 WBS 캡처는 이것들을 지우거나 일반 명칭으로 바꿔 실었고, 나머지 도식은 설명을 위한 단순화입니다.
  • 결제 성공률, 승인율 같은 지표 체계를 직접 운영한 경험. 없는 것은 없다고 적는 편이 면접에서 서로 시간을 아낍니다.