결제 서비스와 체크아웃 아키텍처
돈의 이동을 중복·누락 없이 추적하고 복구하려면? 핵심 이론부터 사례 분석, 단계별 실습, 품질 검수, 종합 문제까지 혼자 학습할 수 있도록 구성한 전공 실습 교재입니다.
오늘의 질문과 학습목표
돈의 이동을 중복·누락 없이 추적하고 복구하려면? 이 질문에 자신의 말로 답할 수 있고, 설계 결과물을 직접 만들고 검수하는 것이 오늘의 완료 기준입니다.
주문과 결제 상태를 분리해 모델링한다.
멱등성 키로 중복 결제를 막는다.
승인·매입·취소·환불을 구분한다.
웹훅의 서명과 재전송을 안전하게 처리한다.
부분 실패에 보상 트랜잭션을 설계한다.
대사와 감사 로그로 금액 불일치를 찾는다.
혼자 공부하는 순서
- 용어를 암기하기 전에 사례에서 문제가 생기는 이유를 설명합니다.
- 좋은 예와 나쁜 예의 차이를 관찰 가능한 기준으로 적습니다.
- 예시를 보지 않고 종합 실습을 먼저 해결합니다.
- 모범답안과 비교한 뒤 빠진 조건을 다른 색으로 보완합니다.
교재 목차
- 학습 안내와 학습목표Page 02
- 제1장. 핵심 이론과 설계 원칙Page 04
- 제2장. 단계별 설계 실습Page 05
- 제3장. 사례 분석과 품질 검수Page 06
- 제4장. 종합 실습과 모범답안Page 07
- 핵심 용어와 최종 점검Page 08
- 자기주도 심화학습과 안내형 실습Pages 09–11
종합 실습 결과물, 자가진단 80점 이상, 핵심 질문 4개에 대한 자신의 답을 남기면 Day 9 학습을 완료한 것입니다.
결제 서비스와 체크아웃 아키텍처 핵심 이론
전문 용어는 복잡해 보이지만, 각 용어는 설계에서 반복되는 한 가지 문제를 해결하기 위해 존재합니다. 아래 표에서 “무엇을 뜻하는가”보다 “언제 필요한가”를 중심으로 학습하세요.
| 핵심 개념 | 설명 |
|---|---|
| Payment Intent | 결제를 시도하고 추적하는 업무 단위입니다. |
| Authorization | 결제 수단에서 금액 사용 가능 여부를 승인받는 단계입니다. |
| Capture | 승인된 금액을 실제 매입하는 단계입니다. |
| Idempotency Key | 같은 결제 요청의 중복 처리를 방지하는 식별자입니다. |
| Webhook | PG가 결제 상태 변화를 서버로 통지하는 비동기 요청입니다. |
| Reconciliation | 내부 장부와 PG 정산 자료를 비교하는 대사 과정입니다. |
좋은 설계와 나쁜 설계의 차이
피해야 할 접근
결제 버튼을 누를 때마다 새 승인 요청을 만들고 클라이언트 응답만으로 주문을 완료한다.
권장 접근
주문별 결제 의도와 멱등성 키를 저장하고 서버·웹훅 상태를 검증해 한 번만 상태를 전이한다.
[주문 금액 확정] → [Payment Intent] → [멱등 승인] → [서버 검증] → [주문 상태 전이] → [웹훅·대사·환불]
단계별 설계 절차
문제 정의
서버가 상품과 할인 규칙으로 최종 금액을 계산한다.
구조 추출
주문과 결제 시도를 별도 ID와 상태로 저장한다.
핵심 설계
PG 요청에 멱등성 키와 타임아웃을 적용한다.
실패 조건
클라이언트 성공 화면과 무관하게 서버에서 결과를 검증한다.
정책 연결
웹훅 서명·이벤트 ID·순서 역전을 처리한다.
검증과 추적
일별 대사로 주문, 결제, 환불, 수수료 차이를 탐지한다.
작동하는 예시
예시를 읽을 때 확인할 것
- 입력과 시작 조건이 명확한가?
- 정상 결과뿐 아니라 실패 결과도 관찰 가능한가?
- 중복·권한·동시성·외부 장애가 필요한 수준으로 다뤄졌는가?
- 요구사항과 구현 결과를 서로 추적할 수 있는가?
사례 분석과 품질 검수
스스로 설명해 보기
- 주문 상태와 결제 상태를 하나로 합치면 어떤 문제가 생기는가?
- 웹훅 서명 검증이 필요한 이유는?
- 금액을 클라이언트 값으로 믿으면 안 되는 이유는?
- 대사가 실시간 처리와 별도로 필요한 이유는?
각 질문에 2~3문장으로 답하고, 답을 뒷받침하는 사례를 하나씩 적으세요.
품질 자가진단 · 100점
| 영역 | 판단 기준 | 점수 |
|---|---|---|
| 정확성 | 개념과 기술 선택이 요구사항 및 사실에 맞는다. | 25 |
| 완전성 | 정상 흐름, 경계 조건, 실패와 복구를 함께 다룬다. | 25 |
| 일관성 | 용어, ID, 상태, 인터페이스가 산출물 사이에서 일치한다. | 20 |
| 검증 가능성 | 관찰 가능한 결과와 완료 기준을 제시한다. | 20 |
| 설명력 | 선택한 방법과 대안의 차이를 자신의 말로 설명한다. | 10 |
틀린 결과만 고치지 말고, 빠진 질문이 무엇이었는지 기록하세요. 좋은 엔지니어는 정답을 외우기보다 다음 설계에서 같은 누락을 막는 점검 기준을 만듭니다.
종합 실습과 모범답안
사용자가 결제 직후 새로고침을 5번 하고 PG 웹훅이 두 번 도착하는 상황을 설계하세요. 환불 중 네트워크가 끊기는 경우도 포함하세요.
- 핵심 가정과 미결정 사항을 먼저 적습니다.
- 주요 설계 결과물을 표, 코드 또는 다이어그램으로 작성합니다.
- 정상 흐름과 최소 3개의 실패·경계 조건을 포함합니다.
- 자가진단표로 채점하고 개선 전후를 비교합니다.
모범답안의 핵심 방향 보기
클라이언트 요청과 PG 요청 모두 동일한 주문 기반 멱등성 키를 사용합니다. 웹훅 이벤트 ID를 저장해 중복을 무시하고 허용된 상태 전이만 수행합니다. 환불은 REFUND_PENDING으로 먼저 기록한 뒤 재조회 또는 웹훅으로 최종 상태를 확인합니다.
답안 사용법
모범답안은 유일한 정답이 아닙니다. 자신의 설계가 다른 경우에는 요구사항, 비용, 복잡도, 위험 중 어떤 근거로 다른 선택을 했는지 설명할 수 있어야 합니다.
핵심 용어와 최종 점검
| 용어 | 쉽게 말하면 |
|---|---|
| PG | 가맹점과 카드사 사이 결제 처리를 중계하는 사업자 |
| Authorization | 결제 가능 금액을 승인받는 단계 |
| Capture | 승인 금액을 실제 청구하는 단계 |
| Webhook | 외부 서비스가 상태 변경을 통지하는 요청 |
| Ledger | 금액 변화를 변경 불가능한 기록으로 남긴 장부 |
| Reconciliation | 서로 다른 결제 기록을 비교해 차이를 찾는 작업 |
제출 전 8문항
- 오늘의 핵심 질문에 자신의 말로 답할 수 있는가?
- 설계의 입력, 조건, 결과가 명확한가?
- 정상 흐름뿐 아니라 실패와 복구를 포함했는가?
- 동시성, 중복 요청, 권한 문제를 검토했는가?
- 외부 시스템 장애와 타임아웃을 고려했는가?
- 선택한 방법의 단점과 대안을 설명할 수 있는가?
- 산출물 사이의 용어와 상태가 일치하는가?
- 테스트하거나 관찰할 수 있는 완료 기준이 있는가?
돈의 이동을 중복·누락 없이 추적하고 복구하려면? 오늘 만든 결과물을 근거로 이 질문에 답해 보세요.
맥락으로 이해하는 핵심 용어
용어를 정의만 외우지 말고 판단 도구로 익히세요. 각 행을 정의→필요한 이유→예시 또는 주의점 순서로 읽습니다.
| 용어 | 쉬운 정의 | 왜 중요한가 | 예시 또는 주의점 |
|---|---|---|---|
| PG | 카드사·은행과 가맹점 사이 결제를 중계하는 결제대행사 | 다양한 결제수단과 승인 절차를 통합 | 서버가 PG 승인 결과를 직접 검증해야 한다. |
| 승인과 매입 | 승인은 한도 확보, 매입은 실제 대금 청구 단계 | 취소 가능 시점과 정산 상태를 이해 | 상태를 단순 성공/실패 두 값으로 줄이지 않는다. |
| 웹훅 | PG가 결제 상태 변화를 서버에 보내는 비동기 알림 | 사용자가 화면을 닫아도 최종 상태를 동기화 | 서명 검증과 중복 이벤트 처리가 필요하다. |
| 멱등성 키 | 동일 결제 시도를 식별하는 고유 키 | 네트워크 재시도에 중복 청구 방지 | 주문 단위 키와 결과를 서버에 보관한다. |
| PCI DSS | 카드 데이터 보호를 위한 보안 표준 | 민감정보 처리 범위와 책임을 제한 | 가능하면 카드번호를 직접 저장하지 않는다. |
| 정산 | 승인된 결제 금액에서 수수료·환불 등을 반영해 지급하는 과정 | 회계 금액과 PG 금액을 맞추는 핵심 | 일별 대사와 불일치 처리 절차를 둔다. |
사용자가 결제 버튼을 두 번 누르고 첫 응답은 타임아웃되지만 PG에서는 승인된다. 이후 웹훅이 도착한다.
안내형 실습과 문제 해결
실습 상황
사용자가 결제 버튼을 두 번 누르고 첫 응답은 타임아웃되지만 PG에서는 승인된다. 이후 웹훅이 도착한다.
순서대로 수행하기
- 주문·결제·환불 상태와 허용 전이를 먼저 정의한다.
- 클라이언트 요청에 멱등성 키를 붙이고 서버 결과를 저장한다.
- 리다이렉트 결과와 별개로 웹훅 서명을 검증해 최종 상태를 반영한다.
- PG 거래 내역과 내부 원장을 정기적으로 대사한다.
산출물 1개, 핵심 가정 3개, 실패 사례 3개 이상을 저장하세요. 다른 학습자가 추가 질문 없이 판단 과정을 재현할 수 있어야 합니다.
결과가 다를 때 진단하기
| 관찰한 증상 | 가능한 원인 | 다음 조치 |
|---|---|---|
| 중복 청구 | 중복 클릭·재시도 식별 실패 | 주문별 멱등성 키 |
| 화면은 실패지만 실제 승인 | 클라이언트 응답만 신뢰 | 서버 조회와 웹훅으로 확정 |
| 위조 웹훅 처리 | 서명 검증 누락 | 원문 본문 기반 서명·시간 검증 |
스스로 이해도 확인하기
인출 연습 — 펼치기 전에 답하기
결제 성공 화면만 믿으면 안 되는 이유는?
브라우저 응답은 끊기거나 조작될 수 있어 서버가 PG와 최종 상태를 확인해야 합니다.
환불과 승인 취소는 항상 같은가?
아닙니다. 매입 전 취소와 매입 후 환불은 처리·정산 방식이 다를 수 있습니다.
결제 기능 완료 기준은?
중복·타임아웃·웹훅·환불·대사까지 금액 불일치 없이 검증해야 합니다.
페이지를 보지 않고 오늘의 핵심 판단, 대표 실패 원인, 검증 방법을 연결해 설명하세요. 세 가지가 이어지지 않으면 놓친 용어나 진단 사례로 돌아갑니다.