PG/선불 사업에 필요한 최소 시스템 구성 — 원장·정산·리스크·감사로그
정산자금 외부관리나 클라우드 이용 신고 같은 규제 대응은 사실 하나의 공통된 기반 시스템 위에서만 가능하다. 그 기반이 되는 네 가지가 있다 — 장부(원장), 정산 처리, 부정거래 탐지, 기록 보관(감사로그). 이 네 개를 처음부터 제대로 만들어두지 않으면, 규제가 바뀔 때마다 매번 급하게 고치는 신세가 된다. 이 글은 "무엇을 만들어야 하는가"보다 "선택지들 사이에서 무엇을 얻고 무엇을 포기해야 하는가"에 집중한다.
왜 이 네 개인가
PG/선불 회사의 규제 대응은 결국 네 가지 질문으로 요약된다. 이 돈이 누구 것인지 증명할 수 있는가(장부/원장), 정산이 정확하고 다시 확인해봐도 똑같은 결과가 나오는가(정산), 이상한 거래를 걸러낼 수 있는가(부정거래 탐지), 누가 언제 무엇을 했는지 나중에 고칠 수 없는 형태로 남길 수 있는가(감사로그). 이 넷 중 하나라도 빠지면, 나머지 셋이 아무리 잘 돼 있어도 감사나 수사가 들어왔을 때 뚫리는 지점이 된다.
무엇을 선택할지, 무엇을 포기할지
1. 장부(원장) — 직접 만들지, 전용 도구를 쓸지 "복式부기(차변·대변)"란, 돈이 들어오고 나가는 걸 항상 두 방향으로 동시에 기록해서 나중에 검증할 수 있게 하는 회계 방식이다. 이 방식의 장부를 회사가 이미 쓰고 있는 일반 데이터베이스(RDBMS) 위에 직접 만들면, 기존 클라우드 인프라(클라우드 이용 절차 참고)를 그대로 쓸 수 있다는 장점이 있다. 다만 여러 거래가 동시에 들어와도 계산이 꼬이지 않게 만드는 게 생각보다 어렵다. 반대로 TigerBeetle 같은, 결제 장부만을 위해 따로 만들어진 전용 데이터베이스를 쓰면 이런 동시성 문제를 도구가 대신 해결해준다. 다만 새로운 사용법을 배워야 하고, 국내에서 직접 운영·이중화까지 책임져야 한다(전문 업체가 대신 관리해주는 서비스가 아직 흔하지 않다). Formance Ledger는 회사들이 많이 쓰는 PostgreSQL(일반 데이터베이스) 위에서 동작해서 절충안이 될 수 있지만, 딸려오는 부가 기능까지 쓰면 그 도구에 종속되는 정도가 커진다. Midaz는 소스가 공개돼 있지만 완전한 오픈소스 라이선스는 아니라서(Elastic License 2.0) 법무 검토가 먼저 필요하다. 결제·정산 건수가 초당 수백 건을 넘어가는 큰 규모가 아니라면, 전용 도구를 새로 들여오는 것보다 기존 데이터베이스 위에 복式부기 구조를 제대로 짜는 쪽이 오히려 운영하기 편하다.
| 옵션 | 장점 | 단점 |
|---|---|---|
| 일반 데이터베이스(RDBMS) 직접 구현 | 기존 클라우드 인프라 재사용 | 동시성 처리를 직접 올바르게 짜야 함 |
| TigerBeetle | 동시성 문제를 도구가 해결 | 새 사용법 학습, 국내 직접 운영·이중화 부담 |
| Formance Ledger | PostgreSQL 기반, 기존 노하우 재사용 | 부가 기능 쓸수록 도구 종속 커짐 |
| Midaz | 소스 공개, 감사 가능성 | 완전한 오픈소스 아님(Elastic License 2.0), 법무 검토 필요 |
2. 정산 처리 — 직접 관리할지, 클라우드에 맡길지 정산은 보통 하루에 한 번씩, 쌓인 거래를 한꺼번에 처리하는 프로그램(배치)으로 이뤄진다. Airflow 같은, 여러 작업의 순서와 흐름을 관리해주는 도구(오케스트레이터)를 직접 운영하면 어떤 작업이 어떻게 진행되는지 한눈에 보기 좋지만, 이 도구 자체도 클라우드 이용 규정이 요구하는 이중화 대상이 된다는 점을 잊기 쉽다. AWS의 Step Functions나 EventBridge Scheduler 같은, 클라우드 회사가 대신 관리해주는 도구를 쓰면 이중화 부담은 줄지만 그 클라우드 회사에 더 의존하게 된다. 어느 쪽을 고르든, 도구 선택보다 중요한 건 "같은 작업을 두 번 실행해도 안전한가"다 — 각 정산 작업에 고유 번호를 매기고 진행 상태를 기록해서, 같은 작업이 중복 실행되더라도 돈이 두 번 나가지 않게 해야 한다. 일부만 실패했을 때는 전체를 다시 실행하지 말고, 실패한 부분만 따로 골라서 다시 처리해야 한다(전체를 다시 실행하면 오히려 이중 지급 위험이 커진다).
3. 부정거래 탐지 — 직접 만들지, 전문 업체 서비스를 쓸지 부정거래를 잡아주는 전문 업체 서비스(SaaS)는 빠르게 도입할 수 있고 최신 사기 수법에도 상대적으로 빠르게 대응하지만, 결제 데이터를 실시간으로 그 업체에 보내야 하므로 그 업체까지 클라우드 이용 신고·보안 검토 대상에 포함해야 한다 — 업체 하나를 추가할 때마다 확인해야 할 컴플라이언스 항목이 하나씩 늘어난다는 뜻이다. 직접 만드는 경우(정해진 규칙으로 걸러내는 방식, 또는 실시간으로 데이터를 흘려보내며 이상한 패턴을 잡아내는 방식)는 데이터가 회사 밖으로 안 나가서 컴플라이언스 부담이 작지만, 사기 수법에 대응하는 속도는 전문 업체보다 느릴 수밖에 없다. 처음에는 직접 만든 규칙으로 시작하고, 손실이 일정 수준을 넘어서면 그때 전문 업체 서비스 도입을 검토하는 단계적 접근이 현실적이다.
4. 기록 보관(감사로그) — 코드로 지키게 할지, 인프라로 지키게 할지 누가, 언제, 왜 정산 계좌에 접근했거나 돈을 옮겼는지에 대한 기록이 나중에 고쳐질 수 없어야 한다는 요구는 정산자금 외부관리 글에서 이미 다뤘다. 방법은 두 가지다 — 각 기록마다 바로 앞 기록의 지문(해시)을 남겨서 중간에 하나라도 고치면 전부 티가 나게 만드는 방식을 애플리케이션 코드로 직접 구현하거나, AWS CloudTrail(누가 무엇을 했는지 자동 기록해주는 서비스)과 별도 계정의 S3 Object Lock(정해진 기간 동안 파일을 절대 수정·삭제 못 하게 잠그는 기능)을 함께 쓰는 것. 감사받을 때는 후자가 유리하다 — "우리 코드가 정직하게 짜여 있다"를 증명하는 것보다 "인프라 자체가 수정을 물리적으로 거부한다"를 증명하는 게 감사인 입장에서 훨씬 확인하기 쉽다.
체크리스트
- 장부(원장)가 복式부기(차변·대변) 구조인지, 단순히 잔액 하나만 관리하고 있지 않은지
- 결제 처리 건수를 기준으로, 일반 데이터베이스와 전용 원장 도구 중 무엇이 더 맞는지 다시 검토했는지
- 정산 작업이 두 번 실행돼도 안전하게(고유 번호 + 상태 기록) 설계됐는지, 정산 도구 자체의 이중화도 돼 있는지
- 부정거래 탐지 데이터가 외부 업체로 나간다면, 그 업체까지 클라우드 이용 신고·보안 검토 대상에 포함했는지
- 기록 보관(감사로그)이 코드 레벨이 아니라 인프라 레벨에서 수정 불가능하게(Object Lock 등) 돼 있는지
- 선불 사업도 함께 한다면, 선불충전금(미리 충전받은 돈, 100% 이상을 회사 밖에 따로 보관해야 하는 의무가 있다)을 PG 정산자금과 장부에서 완전히 다른 항목으로 나눠뒀는지, 발행 잔액·연간 총발행액이 등록이 면제되는 소규모 기준(각각 30억원·500억원)을 넘는지 주기적으로 확인하는지
참고자료
- TigerBeetle – 결제 전용 원장 데이터베이스 (GitHub)
- Formance Ledger – PostgreSQL 기반 프로그래머블 원장 (GitHub)
- Midaz – 소스공개 코어뱅킹 플랫폼 (GitHub)
- 전자금융거래법 – 국가법령정보센터
- 선불전자지급수단 이용자 보호 강화 및 소액후불결제 – 금융위원회 보도자료
관련 글
- 개정 전자금융거래법, PG 정산자금 외부관리 의무화가 개발팀에 요구하는 것들 — 이 글에서 다룬 원장 설계가 실제로 대응해야 하는 규제
- 전자금융감독규정상 클라우드 이용 절차, PG·선불사가 AWS 쓸 때 놓치는 것들 — 이 시스템들을 어느 리전에, 어떻게 배치해야 하는지에 대한 규정
- AWS 기반 결제 인프라 설계 — 국내 리전 제약 안에서 가용성·재해복구 확보하기 — 원장·정산 시스템을 실제로 AWS 위에 올릴 때의 가용성 설계
- 결제 시스템 모니터링·관측성 스택 — 오픈소스 vs 상용 APM — 이 글에서 다룬 시스템들이 실제로 잘 도는지 지켜보는 관측성 계층을 다룬 후속편
- 카드번호, 우리 서버에 저장해도 될까 — 토큰화 볼트 선택지 비교 — 원장·정산과 별개로, 카드정보 자체를 어디에 어떻게 보관할지에 대한 아키텍처 선택