결제·핀테크 엔지니어링 브리핑
← 목록으로

개정 전자금융거래법, PG 정산자금 외부관리 의무화가 개발팀에 요구하는 것들

2026-08-18규제·정책
#전자금융거래법#PG#정산#규제
Ad slot

PG(전자지급결제대행업자)는 온라인에서 결제를 대신 처리해주는 회사다. 손님이 물건을 사면 카드사에서 돈을 받아, 그 돈을 물건을 판 가맹점에 다시 보내주는 중간 다리 역할을 한다. 문제는 이 "가맹점에 보내야 할 돈"(정산자금)을 PG사가 자기 회사 돈과 섞어서 관리해도 되는지가 오랫동안 느슨하게 방치돼 있었다는 점이다.

2025년 11월 28일 국회를 통과하고 12월 16일 공포된 개정 전자금융거래법이 2026년 12월부터 이 부분을 명확히 손본다. 핵심은 하나다 — PG사는 가맹점에 줘야 할 돈을 회사의 다른 돈과 섞이지 않게 따로, 외부 기관에 보관해야 한다.

정확한 법 조문 해설은 법무법인들이 이미 잘 정리해놨다(아래 참고자료). 이 글은 그 대신 "PG 회사의 개발팀은 시행일 전까지 시스템을 어떻게 바꿔야 하는가"에 집중한다.

왜 이런 규제가 나왔나

계기는 명확하다. 2024년, 온라인 쇼핑몰 티몬·위메프가 판매자에게 줘야 할 정산대금을 제때 주지 못해 큰 사회 문제가 됐다(흔히 "티메프 사태"라고 부른다). 판매자들이 받아야 할 돈이 회사 운영자금처럼 쓰이다가, 회사가 어려워지자 돌려주지 못하는 상황이 벌어졌다.

기존 전자금융거래법은 PG사에게 "가맹점에 줄 돈을 회사 돈과 분리해서 관리하라"고 강제하지 않았고, 이 틈에서 정산대금이 회사 운영자금으로 흘러들어가는 일이 가능했다. 개정법은 이 구조 자체를 막는다.

동시에 '다단계 PG(n차 PG)' 구조에 대한 규제도 강화된다. 카드사·은행과 직접 계약하는 1차 PG가 가맹점 모집·관리를 2차 PG에 맡기는 구조에서, 수수료가 중간에서 겹겹이 붙거나 불법거래를 대신 처리해주는 일이 생긴 전례가 있었기 때문이다.

개정 핵심 3가지

항목 개정 전 개정 후
PG업 정의 모호함 "제3자 거래 정산 대행"으로 명확화
정산자금 관리 회사 계좌와 섞어도 규제 없음 외부(신탁·예치 등)에 분리 보관 의무
결제 리스크 관리 별도 가이드라인 없음 2026.1.5~2027.1.14 가이드라인 시행

1. PG업이 정확히 뭔지 명확히 정했다 그동안 PG업이 정확히 무슨 일을 하는 회사인지 법에 애매하게 적혀 있었다. 개정법은 PG업을 "자기 사업이 아니라, 제3자(가맹점)와 손님 사이의 거래에서 수수료를 받고 정산을 대신 처리해주는 일"로 명확히 정의했다. 반대로 자기 쇼핑몰에서 자기가 파는 물건을 정산하는 경우(대규모유통업법 등 다른 법이 적용되는 경우)는 PG업으로 보지 않는다. 자사 커머스 안에서 입점 판매자 정산까지 직접 처리해온 회사라면, "PG업 등록을 꼭 해야 하는지"부터 법무팀과 다시 확인해볼 필요가 있다.

2. 가맹점에 줄 돈은 회사 밖에 따로 맡겨야 한다 가맹점에 줄 돈을 회사 계좌에 그냥 넣어두면 안 되고, 은행 같은 외부 기관에 맡겨서 관리해야 한다는 뜻이다(법에서는 신탁, 예치, 지급보증보험 같은 방식을 쓴다고 표현한다). 미리 충전해둔 포인트 같은 돈(선불충전금)에는 이미 비슷한 규칙이 있었는데, 이제 PG의 정산대금에도 거의 같은 규칙이 적용된다. 회사가 실무적으로 해야 할 일은, 정산에 쓰는 계좌와 회사가 자유롭게 쓰는 운영 계좌를 완전히 분리하고, 정산 계좌에서 돈을 빼거나 옮기는 권한을 시스템적으로 제한하는 것이다.

3. 결제가 잘 되고 있는지 감시하는 규칙도 따로 생긴다 2026년 1월 5일부터 2027년 1월 14일까지 별도의 가이드라인이 시행된다. 아직 세부 내용이 다 나오지 않았지만, 정산이 늦어지거나 오류가 났을 때 이를 미리 감지하는 체계를 요구할 가능성이 높다.

여기에 결제수수료를 얼마나, 어떻게 공개해야 하는지에 대한 규제 확대까지 겹치면서, PG사는 "정산이 정확하다"와 "수수료가 투명하다"를 둘 다 시스템으로 증명해야 하는 상황에 놓인다.

개발팀이 지금 점검해야 할 것

계좌 분리와 권한 경계 정산에 쓰는 계좌(신탁·예치 계좌)와 회사가 자유롭게 쓰는 운영 계좌 사이에는 시스템(코드) 레벨에서도 분명한 경계가 있어야 한다. 하나의 서비스 계정(자동화 프로그램이 쓰는 접속 권한)이 두 계좌에 모두 이체 권한을 갖고 있다면, 개발자의 작은 실수 하나가 곧바로 법 위반으로 이어질 수 있다. 돈을 옮기는 걸 "실행"하는 권한과 그 실행을 "승인"하는 권한을 나누는 것(흔히 4-eyes 원칙이라 부르는, 한 사람이 아니라 최소 두 사람이 확인해야 처리되게 하는 방식)도 검토할 만하다.

원장(장부) 설계 — 맡아둔 돈과 회사 돈을 처음부터 나눠 적기 원장은 회사의 모든 돈의 흐름을 기록하는 장부다. 가맹점에 줘야 할 돈이 회사 자산과 헷갈리지 않으려면, 이 장부 자체에서부터 "맡아두고 있는 돈(예치자산)"과 "회사가 진짜 쓸 수 있는 돈(고유자산)"을 다른 항목으로 나눠 기록해야 한다. 단순히 잔액 하나만 관리하는 구조였다면, 이번 기회에 복式부기(모든 거래를 들어온 쪽과 나간 쪽 양쪽에 동시에 기록하는 회계 방식) 구조로 바꾸는 걸 권한다. 이렇게 하면 "이 돈이 누구 것인지"를 장부 자체가 증명해주기 때문에, 나중에 감사받을 때 훨씬 수월하다.

정산 배치의 정합성 — 실수 하나가 이중 지급으로 이어지지 않게 정산은 보통 하루에 한 번씩, 쌓인 거래를 한꺼번에 처리하는 프로그램(배치)으로 이뤄진다. 이 프로그램이 안전하려면 세 가지가 필요하다.

  • 같은 배치를 두 번 실행해도 돈이 두 번 나가지 않아야 한다(멱등성). 배치마다 고유 번호를 매기고 처리 상태를 기록해두는 방식으로 막는다
  • 일부만 실패했을 때 전체를 다시 실행하면 오히려 이중 지급 위험이 생긴다. 실패한 건만 따로 골라내 재처리해야 한다
  • 배치가 끝나면 "실제 계좌에 있는 돈"과 "장부에 적힌, 가맹점에 줘야 할 돈의 합계"가 일치하는지 자동으로 맞춰보고(대사, reconciliation), 안 맞으면 바로 알림이 가야 한다

감사로그 — 나중에 고칠 수 없게 남기기 누가, 언제, 왜 정산 계좌에 접근하거나 돈을 옮겼는지 남긴 기록이다. 이 기록을 나중에 수정할 수 있는 구조라면, 감사받을 때 "이 로그가 진짜인지" 자체를 의심받는다. 그래서 한 번 쓰면 지우거나 고칠 수 없는 방식(append-only)으로 남겨야 한다. AWS를 쓴다면 CloudTrail(누가 무엇을 했는지 자동으로 기록해주는 서비스)로 로그를 남기고, 그 로그를 별도 계정의 S3 Object Lock(정해진 기간 동안 파일을 절대 수정·삭제 못 하게 잠그는 기능)에 저장하는 조합이 정석이다.

장애 시나리오 대응 정산이 늦어졌을 때 가맹점이 "언제쯑 돈을 받을 수 있는지" 실시간으로 확인할 수 있는 화면이나 API가 거의 필수가 될 것으로 보인다. 앞서 말한 리스크 관리 가이드라인이 요구할 가능성이 높은 항목이다.

체크리스트

  • 우리 서비스가 PG업 등록 대상인지, 부수적인 정산 대행이라 면제 대상인지 법무팀과 확인했는지
  • 정산 계좌와 운영 계좌 사이의 권한이 시스템적으로 분리돼 있는지
  • 장부(원장)에서 맡아둔 돈과 회사 돈이 계정과목 수준에서 분리되어 있는지
  • 정산 배치가 같은 배치를 두 번 돌려도 안전한지(멱등성), 일부만 실패했을 때 그 건만 재처리하는지
  • 정산 관련 접근·이체 기록이 나중에 수정 불가능한 형태로 남는지
  • 결제 규모가 기준(2026년 월평균 5,000억원 이상)에 해당한다면 수수료 공시 자동화도 미리 준비했는지

시행일까지 시간이 넉넉해 보이지만, 장부(원장) 구조를 바꾸는 작업은 시간이 오래 걸린다. 다음 분기 계획에 넣어야 할 일인지 지금 판단해두는 게 낫다.

참고자료

관련 글

Ad slot