FINTECH 101 — 트랜잭션이 실제로 작동하는 방식
I’m ready to translate the article for you, but I need the text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown syntax, and technical terms.
핵심 정신 모델
네 가지 기둥:
- 거래 상태
- 콜백 / 웹훅
- 조정 및 상태 조회
- 재시도, 역전 및 멱등성
이 중 하나라도 오해하면 결국 손해를 보게 됩니다.
거래 상태 (응답이 아님)
핀테크에서는 HTTP 응답만이 아니라 상태를 추적합니다.
표준 거래 라이프사이클
| 상태 | 설명 |
|---|---|
| INITIATED | 요청이 내부적으로 생성됨 |
| PROCESSING | 프로세서에 전송됨 |
| PENDING | 프로세서가 수락했지만 최종 상태가 아님 |
| SUCCESS | 돈이 전달된 것이 확인됨 |
| FAILED | 돈이 전달되지 않음 |
| REVERSED | 돈이 차감된 후 반환됨 |
| TIMEOUT | SLA 내에 응답 없음 |
이 상태들이 실제 의미하는 바
| 상태 | 의미 |
|---|---|
| INITIATED | 귀하의 시스템이 거래를 생성했습니다 |
| PENDING | 프로세서 또는 네트워크가 아직 작업 중입니다 |
| SUCCESS | 가치가 전달됨 (통화량, 데이터, 금액 등) |
| FAILED | 가치가 전달되지 않음 |
| REVERSED | 돈이 차감되었지만 환불되었습니다 |
Golden Rule
거래는 SUCCESS, FAILED, 또는 REVERSED(일시적) 중 하나로만 종료될 수 있습니다.
핀테크 시스템에서는 요청이 기술적으로 성공했더라도 금융 행위 자체가 완료되지 않을 수 있습니다(예: 잔액 부족, 은행 확인 대기, 컴플라이언스 검사 실패 등). 이러한 경우는 정상적인 비즈니스 결과이며 시스템 오류가 아닙니다.
HTTP 응답 코드를 기술적 성공을 나타내는 데 사용하고, 별도의 비즈니스 상태를 거래 결과를 나타내도록 하면 혼란을 방지하고, 안전하지 않은 재시도를 피하며, 결제 흐름을 이해하기 쉽게 만들 수 있습니다.
개념 vs. 목적
| 개념 | 목적 |
|---|---|
| Response Code | 기술적 결과 |
| Status | 비즈니스 상태 |
예시
{
"code": "99",
"status": "PENDING",
"message": "Transaction is being processed"
}HTTP 200은 단지 “요청을 받았습니다”라는 의미일 뿐이며, 거래가 성공했음을 의미하지 않습니다. status 필드가 진실을 나타냅니다.
Money Representation
절대로 부동소수점(float)이나 double을 금액에 사용하지 마세요.
컴퓨터는 이진수(2진법)를 사용하고 인간은 십진수(10진법)를 사용합니다. 일부 간단한 소수는 이진수로 정확히 표현할 수 없어 반올림 오류와 장부 불일치를 초래합니다.
The Correct Approach: Minor Units
최소 통화 단위로 금액을 저장합니다.
| 잘못된 경우 | 올바른 경우 |
|---|---|
100.00 (decimal) 로 저장 | 10000 (integer) 로 저장 |
일반적인 규칙
- 데이터베이스:
BIGINT(예:10.50은1050) - 코드: 정수 연산 (
1050 + 20) - 프론트엔드: 표시용으로만 변환 (예:
GH₵10.70)
콜백 (Webhooks)
콜백이란?
네트워크 지연, 은행 오프라인, 또는 프로세서 타임아웃으로 인해 거래가 아직 보류 중일 때 콜백이 발생합니다.
일반적인 콜백 흐름
- 요청을 보냅니다.
- 프로세서가 응답 → PENDING.
- 거래를 PENDING 상태로 저장합니다.
- 이후 프로세서가 귀하의 엔드포인트를 호출합니다.
- 거래를 업데이트 → SUCCESS / FAILED.
콜백 실패
- 네트워크 문제
- 프로세서 다운타임
- 프로세서 버그
콜백이 실패할 수 있기 때문에, 핀테크 시스템은 실제 상태를 복구하기 위해 status enquiry(pull)를 사용하기도 합니다.
- Push: 프로세서가 알려줍니다 (콜백).
- Pull: 귀하가 프로세서에 요청합니다 (status enquiry).
멱등성
악몽 시나리오
- 사용자가 “Pay” 버튼을 클릭한다.
- 네트워크 오류가 발생한다.
- 사용자가 다시 클릭한다.
- 두 번 청구가 발생한다.
해결책: 멱등성 키
- 중복된 레퍼런스를 거부한다.
- 데이터베이스 고유성을 강제한다 (
UNIQUE(reference)).
Retries
Retries are dangerous when there is:
- No response (timeout)
- Network error
A retry after a SUCCESS can cause duplicate charges, while a retry after a FAILED business outcome may be unnecessary.
리버설
리버설이 필요한 경우:
- SUCCESS 데빗이 이루어졌지만 배송에 실패한 경우.
- SLA 이후 콜백을 받지 못한 경우.
리버설 흐름
- 불일치 감지.
- 리버설 API 호출.
- 거래 업데이트 → REVERSED.
- 사용자에게 알림.
귀하의 기록은 프로세서와 완벽히 일치하지 않을 것입니다. 모든 불일치는 조사하고 수정해야 합니다.
로깅 요구사항
모든 핀테크 시스템은 다음을 기록해야 합니다:
- 요청 페이로드
- 응답 페이로드
- 상태 전환
- 타임스탬프
최종 정신 모델 (영원히 유지하세요)
- 첫 번째 응답을 절대 신뢰하지 마세요.
- 금전 시스템은 결국 일관성을 갖습니다.
- Status는 진실이며, HTTP 응답 코드가 아닙니다.
- 회계가 항상 승리합니다.
이러한 사고방식으로 핀테크를 구축한다면, 단순히 테스트를 통과하는 것이 아니라 실제 운영에서도 살아남을 수 있습니다.