전자금융감독규정상 클라우드 이용 절차, PG·선불사가 AWS 쓸 때 놓치는 것들
PG(결제 대행 회사)나 선불업자(포인트·상품권 같은 선불수단을 발행하는 회사)도 전자금융업자로 분류돼서, 서버를 AWS 같은 클라우드에 올릴 때 전자금융감독규정(금융회사의 보안·운영을 관리하는 규정)이 정한 절차를 그대로 따라야 한다. 그런데 이 절차가 요구하는 내용이 단순한 서류 작업이 아니라, 서버 구조 자체를 어떻게 짜야 하는지에 직접 영향을 준다. "일단 서버부터 만들고, 서류는 법무팀이 나중에 처리하겠지"라고 생각하면, 나중에 서버 위치를 옮기거나 재해 대비 시스템을 바꿀 때마다 전체 구조를 다시 짜야 하는 상황이 생긴다.
왜 지금 다시 봐야 하나
2023년에는 클라우드를 쓰기 전에 미리 금융감독원(금감원)에 알려야 했는데(사전보고), 이제는 먼저 쓰고 나서 알리는 방식(사후보고)으로 바뀌었다. 2025년 2월 5일부터는 제출해야 하는 서류도 더 줄었다. 또 개인의 신용정보를 다루지 않는 연구·개발 용도라면, 원래 엄격했던 "망분리"(회사 내부망과 외부 인터넷을 물리적으로 분리해두는 규칙) 요건도 일부 완화됐다. 회사 내부에서 클라우드 기반 소프트웨어(SaaS)를 쓸 때도 일정 보안 조건을 지키면 망분리 예외를 인정받을 수 있게 됐다.
규제가 계속 느슨해지는 방향으로 가고 있다는 뜻이지만, 그렇다고 실무 부담이 줄어드는 건 아니다. 오히려 "우리 서비스가 이 완화된 조건에 해당하는지 아닌지"를 정확히 판단해야 하는 부담이 늘었다.
절차가 요구하는 것
전자금융감독규정 제14조의2(금융회사가 클라우드를 쓸 때 지켜야 할 조항)에 따른 클라우드 이용은 7단계로 진행된다. 이 중에서 서버를 어떻게 설계할지에 직접 영향을 주는 지점이 세 곳 있다.
무엇을 어떻게 정해야 하나
1. "중요한 업무"인지 먼저 정해야 나중에 다시 안 만든다 결제·정산·회계 장부처럼 개인의 신용정보나 고유 식별정보를 다루는 서비스는 거의 전부 "중요업무"로 분류될 수밖에 없다. 중요업무로 분류되면 클라우드 회사 평가, 보안 조치, 계약서에 들어가야 할 내용까지 훨씬 엄격한 기준을 적용받는다. 문제는 이 분류를 서버를 만들기 전에 미리 안 해두면, 나중에 "이 서비스가 사실 중요업무였네"라는 걸 알게 됐을 때 이미 만들어둔 서버 구조·암호화 방식·계약서를 통째로 다시 손봐야 한다는 점이다. 그러니 새로운 서비스를 만들기 전에 "이건 중요업무인가?"부터 정해두고, 이 분류를 확인하지 않으면 배포가 안 되게 자동으로 막아두는 게 안전하다.
| 구분 | 중요업무 | 비중요업무 |
|---|---|---|
| 클라우드 회사 평가 | 필수 항목 + 대체·추가 항목까지 | 필수 항목만 |
| 보안 조치 | 필수 + 추가 보안 조치 | 필수 조치만 |
| 계약서 필수 기재사항 | 기본 + 추가 포함사항 | 기본 포함사항만 |
| 대표 예시 | 결제·정산·원장, 개인 신용정보 처리 | 비식별화된 로그 집계, 정적 콘텐츠 |
2. 서버 위치 — 해외로 데이터를 복제할 수 없다는 제약 개인 신용정보를 다루는 시스템은 서울에 있는 AWS 서버(리전)에만 둬야 한다는 게 사실상 강제된다. 그런데 보통 재해에 대비할 때는 "물리적으로 멀리 떨어진 곳에 복사본을 두는" 방식을 쓴다. 해외로 개인 신용정보를 복제할 수 없다면, 서울 안에서 여러 데이터센터(전문 용어로 AZ)에 나눠 두는 방식으로 안정성을 확보하고, 서울 지역 전체에 문제가 생기는 극단적인 상황에 대비해서는 국내의 또 다른 물리적 장소에 재해복구센터를 따로 마련해야 한다. "해외에 복사본을 두면 편한데"라는 흔한 방식이 이 업계에서는 처음부터 선택지가 아니라는 걸 설계 초반에 확실히 해둬야 한다.
3. 망분리 — 물리적으로 나누는 대신 논리적으로 나눌 때 증명이 필요하다 전통적으로는 회사 내부망과 외부 인터넷을 물리적으로 다른 선으로 연결해서 분리했는데, 이제는 클라우드 안에서 가상의 네트워크 구역(VPC)을 여러 개 만들고 그 사이를 제한적으로만 연결하는 방식(논리적 분리)으로도 인정받을 수 있다. 다만 이 경우 "논리적으로 충분히 분리돼 있다"는 걸 서류로 증명해야 한다. 결제를 처리하는 서버는 외부에서 직접 접속할 수 없는 구역(Private Subnet)에만 두고, 나가는 통신은 정해진 출구(NAT Gateway)로만 나가게 하는 게 기본이다. 이미 회사 내부망에서 클라우드 SaaS를 쓰는 예외 조건을 활용하려는 경우라면, 그 SaaS가 요구하는 보안 조건을 실제로 만족하는지도 따로 확인해야 한다.
4. 사후보고 — "중대한 변경"이 뭔지 회사 안에서 먼저 정해야 한다 계약을 새로 맺거나 크게 바꿀 때는 3개월 안에 금감원에 알려야 하는데, 무엇이 "크게 바꾼 것"(중대한 변경)인지는 회사가 스스로 정의해둬야 한다. 서버를 다른 지역으로 옮기거나, 사용하는 서비스 종류를 바꾸거나(예: 가상서버에서 컨테이너 방식으로), 클라우드 회사를 바꾸는 것 등이 여기에 해당할 수 있다. 개발팀이 인프라 설정을 바꿀 때마다 "이게 보고 대상인가?"를 컴플라이언스 담당자가 확인하는 절차를 미리 만들어두지 않으면, 보고 시점을 놓치기 쉽다.
체크리스트
- 결제·정산·회계 장부 관련 서비스를 "중요업무"로 분류해뒀는지, 새 서비스를 만들 때 이 분류부터 확인하는 절차가 있는지
- 개인 신용정보를 다루는 서비스가 국내(서울) 서버에만 있는지, 재해 대비 계획도 국내에서만 이뤄지는지
- 망분리를 물리적 방식과 논리적 방식(VPC 나누기) 중 무엇으로 했는지, 그 근거를 서류로 남겨뒀는지
- 회사 내부망에서 클라우드 SaaS를 쓰는 예외를 이용한다면, 그 SaaS가 보안 조건을 만족하는지 확인했는지
- 회사 안에서 "중대한 변경"이 뭔지 정의해뒀고, 인프라를 바꿀 때 보고 대상인지 확인하는 절차가 있는지
- 클라우드 회사와 맺은 계약서에 규정이 요구하는 내용(감사받을 권리, 계약 끝날 때 데이터를 돌려주거나 지울 의무 등)이 들어있는지
- 클라우드 이용을 끝낼 때 데이터를 어떻게 옮기거나 지울지 미리 문서로 정해뒀는지
참고자료
- 전자금융감독규정 제14조의2 – 국가법령정보센터
- 클라우드 이용절차 합리화 및 망분리 규제 완화 – 금융위원회 보도자료
- 금융 클라우드 길라잡이 A to Z Part 1 – 전자금융감독규정으로 풀어보는 클라우드 도입 첫걸음 – AWS 기술 블로그
관련 글
- 전자금융업이 뭔지, 우리 서비스가 등록 대상인지부터 확인하는 법 — 클라우드 이용 신고도 전자금융업 등록 이후에 따라오는 의무다
- PG/선불 사업에 필요한 최소 시스템 구성 — 원장·정산·리스크·감사로그 — 이 글에서 다룬 국내 리전 제약이 원장·정산 시스템 설계에 그대로 이어진다
- AWS 기반 결제 인프라 설계 — 국내 리전 제약 안에서 가용성·재해복구 확보하기 — 클라우드 이용 절차가 요구하는 이중화·재해복구를 AWS로 실제 구현하는 법