금융 서비스를 클라우드에 올릴 때, 전자금융감독규정이 허용하는 범위는 어디까지인가요
2023년 전자금융감독규정 개정으로 금융 클라우드 이용 절차가 대폭 간소화됐어요. 사전보고가 사후보고로 바뀌고, CSP 평가항목이 141개에서 54개로 줄었어요. 하지만 데이터 국내 저장 의무, 감독 접근권, 업무연속성 확보대책은 여전히 남아있어요. 이 글에서는 허용 범위와 제약을 정리하고, DR 설계부터 망분리 구현까지 실제 아키텍처 패턴을 다뤄요.
금융 서비스를 클라우드에 올려도 되나요? 짧은 답은 '된다'예요. 단, 조건이 있어요.
이전 글에서 전자금융감독규정의 개발자 관련 조항을 다뤘어요. 이번에는 클라우드 이용에 초점을 맞춰볼게요.
금융 클라우드 규제는 고속도로의 속도 제한과 비슷해요. 도로 자체는 빠르게 달릴 수 있지만, 구간마다 제한 속도가 다르고 단속 카메라가 있는 거예요. 어느 구간에서 얼마나 빠르게 달릴 수 있는지 알아야 사고 없이 목적지에 도달할 수 있어요.
처음에는 "규제가 많아서 클라우드 전환이 어렵다"는 인식이 업계에 팽배했어요. 하지만 실제로 규정을 들여다보면, 제약보다 허용 범위가 훨씬 넓어졌다는 걸 알 수 있어요.
금융 서비스를 클라우드에 올릴 수 있나요
결론부터 말하면, 개인신용정보를 포함한 대부분의 금융 업무를 퍼블릭 클라우드에서 처리할 수 있어요.
전자금융감독규정 제14조의2가 금융 클라우드의 근거 조항이에요. 이 조항의 변천사를 보면 규제 완화의 흐름이 명확하게 보여요.
| 시기 | 주요 변화 |
|---|---|
| 2016년 | 비중요 정보만 클라우드 허용 (개인신용정보 제외) |
| 2019년 1월 | 개인신용정보까지 클라우드 허용 (국내 소재 한정, 사전보고 의무) |
| 2023년 1월 | 업무 중요도 차등화, CSP 평가 141→54개, 사전보고→사후보고(3개월 이내) |
| 2025년 2월 | 규칙 293→166개(Rule→Principle), 재해복구센터 의무 대상 확대 |
| 2026년 4월 | SaaS 망분리 예외 시행 (보안 조건 충족 시) |
2016년에는 마케팅 데이터나 통계 시스템 정도만 클라우드에 올릴 수 있었어요. 2019년 개정으로 개인신용정보까지 허용됐지만, 국내 소재 클라우드에 한정됐어요. 진짜 변화는 2023년에 왔어요.
2023년 개정의 핵심은 "사전 승인"에서 "사후 책임"으로의 전환이에요. 금융사가 스스로 보안 수준을 판단하고, 이용 후 3개월 이내에 보고하는 방식으로 바뀐 거예요. 2025년 2월에는 규칙 기반 293개 조항이 원칙 기반 166개로 줄면서, 금융사의 자율적 판단 영역이 더 넓어졌어요.
실제 도입 현황도 이를 뒷받침해요. 2025년 기준 금융사의 92%가 퍼블릭 클라우드를 도입했거나 준비 중이에요. 코리안리는 국내 금융권 최초로 기간계와 정보계 전체를 AWS로 전환했고, 국민은행은 AWS 전환으로 약 40% 비용을 절감했어요.
금융 클라우드 전환은 이제 선택이 아니라 경쟁력의 문제가 됐어요.
2023년 규제 완화로 달라진 것과 여전히 남은 제약
2023년 개정의 핵심은 세 가지예요.
첫째, 업무 중요도 차등화예요. 모든 업무를 동일한 기준으로 평가하던 방식에서 벗어나, 중요도에 따라 요구사항을 달리 적용해요. 핵심 업무는 더 엄격하게, 비핵심 업무는 더 유연하게 관리할 수 있어요.
둘째, CSP 평가 간소화예요. 금융사가 직접 수행하던 CSP 안전성 평가 항목이 141개에서 54개로 줄었어요. 금융보안원의 CSP 안전성 평가 결과를 활용하면 중복 평가를 피할 수 있어요.
셋째, 사후보고 전환이에요. 클라우드 이용 시작 전 금융감독원에 사전보고하던 방식이 이용 후 3개월 이내 사후보고로 바뀌었어요. 신규 서비스 출시 속도가 빨라졌어요.
운영하면서 계속 느낀 건, 절차는 간소화됐지만 자율보안 책임은 오히려 커졌다는 거예요. 사전 승인이 사라진 대신, 금융사가 스스로 보안 수준을 판단하고 증명해야 하는 부담이 생긴 거예요.
그렇다고 모든 제약이 사라진 건 아니에요. 여전히 남아있는 제약을 정리하면 이래요.
| 남아있는 제약 | 근거 조항 | 핵심 내용 |
|---|---|---|
| 데이터 국내 저장 | 제14조의2 제8항 | 개인신용정보 등 국내 소재 서버에만 저장·처리 |
| 감독 접근권 | 별표 2의5 | 금융감독원·금융위 조사·접근권 계약서 기재 필수 |
| 위탁 계약 | 시행세칙 | CSP 합병·분할·재위탁 시 사후보고 의무 |
| 업무연속성 | 제23조 | 재해복구센터, 백업, 비상대응 훈련 의무 |
| 정보보호위원회 심의 | 내부통제 | 중요업무 클라우드 이용 시 심의 필수 |
절차 간소화와 자율보안 책임 증가는 트레이드오프 관계예요. 규제 당국이 사전 검증 대신 사후 책임을 강화하는 방향으로 전환한 거예요.
데이터 국내 저장 의무와 리전 선택
개인신용정보를 처리하는 시스템은 반드시 국내 소재 클라우드에서 운영해야 해요.
전자금융감독규정 제14조의2 제8항이 이 의무를 규정하고 있어요. 사고 발생 시 법적 분쟁, 소비자 보호, 감독 관할을 고려해서 개인신용정보 처리는 국내 소재 클라우드에 한해 허용한 거예요.
현재 금융보안원 CSP 안전성 평가를 통과한 주요 CSP와 국내 리전 현황을 정리하면 이래요.
| CSP | 국내 리전 | 가용영역 | 금융 인증 현황 |
|---|---|---|---|
| AWS | ap-northeast-2 (서울) | 4개 AZ | 2023년 대표평가 완료 (59개 금융사 참여), K-ISMS 인증 |
| OCI | 서울(2019.5) + 춘천(2020.5) | 복수 리전 | 금융보안원 보안 관리 참고서 대상 |
| NHN Cloud | 판교 + 평촌 | 복수 센터 | 금융보안원 보안 관리 참고서 대상 |
| Naver Cloud | 국내 복수 | 복수 센터 | 금융보안원 보안 관리 참고서 대상 |
| KT Cloud | 국내 IDC | 복수 센터 | 금융보안원 보안 관리 참고서 대상 |
AWS는 2023년 CSP 안전성 평가를 완료했어요. 금융보안원이 주관하는 대표평가에 59개 금융사가 참여했고, 서울 리전 4개 가용영역 전체가 평가 범위에 포함됐어요. 금융사 입장에서는 개별 감사를 수행하지 않아도 금융보안원의 대표평가 결과를 활용할 수 있어서 부담이 줄어든 거예요.
OCI는 서울 리전(2019년 5월)과 춘천 리전(2020년 5월)을 운영하고 있어요. 복수 리전을 활용하면 국내에서 Cross-Region DR 구성이 가능하다는 장점이 있어요.
금융보안원은 2025년에 AWS, OCI, Google Cloud, Microsoft 등 9개 CSP와 협업해서 '금융분야 상용 클라우드컴퓨팅서비스 보안 관리 참고서'를 발간했어요. 8개 분야 47개 보안 관리 기준으로 구성되어 있어요.
실수하기 쉬운 부분이 있어요. 데이터 상주 의무가 "저장"뿐 아니라 "처리"까지 포함한다는 거예요. 분석을 위해 해외 리전으로 데이터를 복제하거나, 해외 리전의 AI 서비스에 고객 데이터를 전송하는 것도 제약 대상이에요.
감독 접근권은 클라우드에서 어떻게 보장하나요
금융감독원과 금융위원회는 금융회사가 이용하는 클라우드 환경에 대해 조사·접근할 수 있는 권한을 가져요.
전자금융감독규정 별표 2의5는 클라우드 이용 계약서에 반드시 포함해야 하는 기재사항을 정하고 있어요. 그중 핵심은 감독당국의 접근권이에요.
계약서에 명시해야 하는 주요 사항을 정리하면 이래요.
| 기재사항 | 내용 |
|---|---|
| 감독당국 조사·접근권 | 금융감독원이 CSP 시설에 접근하여 조사할 수 있는 권한 |
| 서비스 수준 계약(SLA) | 가용성, 성능, 장애 대응 시간 기준 |
| 데이터 이전·파기 절차 | 계약 종료 시 데이터 반환 및 완전 삭제 |
| 책임 소재 | 사고 발생 시 금융사와 CSP의 책임 범위 |
| 재위탁 제한 | CSP가 제3자에게 재위탁 시 사전 동의 |
CSP 합병·분할·재위탁이 발생하면 금융사는 사후보고 의무를 이행해야 해요. 계약서에 이 상황에 대한 통보 의무를 명시해두지 않으면, 금융사가 변경 사실을 뒤늦게 파악하는 경우가 생겨요.
AWS Artifact를 활용하면 감독당국 제출용 컴플라이언스 보고서를 자동으로 확보할 수 있어요. AWS CloudTrail은 API 호출 이력을 모두 기록하기 때문에, 감독당국이 특정 시점의 접근 이력을 요청할 때 즉시 제출할 수 있어요.
CSP 합병·분할·재위탁이 발생하면 금융사는 사후보고 의무를 이행해야 해요. 계약서에 이 상황에 대한 통보 의무를 명시해두지 않으면, 금융사가 변경 사실을 뒤늦게 파악하는 경우가 생겨요. 실제로 대형 CSP들은 서브프로세서 목록을 주기적으로 업데이트하는데, 이 변경이 금융사의 보고 의무를 촉발할 수 있어요.
원인을 추적한 끝에 발견한 건, 감독 접근권이 단순히 계약서 문구의 문제가 아니라 기술적 구현이 필요하다는 거예요. 감독당국이 실제로 접근할 수 있으려면 감사 로그가 독립적으로 보관되어야 하고, 금융사가 CSP에 의존하지 않고 자체적으로 증적을 확보할 수 있어야 해요. 이 부분은 다음 섹션의 감사 로그 설계와 직결돼요.
업무연속성 확보대책과 DR 설계
전자금융감독규정 제23조는 금융회사에 업무지속성 확보방안 수립을 의무화하고 있어요.
이 조항은 장애·재해·파업·테러 등 긴급 상황에서도 업무가 중단되지 않도록 다음 내용을 포함한 대책을 수립하도록 요구해요.
- 상황별 대응절차
- 백업 또는 재해복구센터를 활용한 재해복구계획
- 비상대응조직의 구성 및 운용
- 모의훈련의 실시 (매년 1회 이상)
- 유관기관 및 관련업체와의 비상연락체제 구축
2025년 2월 개정에서는 재해복구센터 설치 의무 대상이 확대됐어요. 기존에는 은행, 금융투자업자, 보험회사만 의무였는데, 일정 규모를 갖춘 여신전문금융회사와 전자금융업자도 의무적으로 재해복구센터를 설치해야 해요.
클라우드 환경에서 DR을 설계할 때 고려해야 할 RPO/RTO 기준을 정리하면 이래요.
| DR 전략 | RPO | RTO | 적합한 업무 |
|---|---|---|---|
| Backup & Restore | 시간 단위 | 시간 단위 | 비중요 업무 (마케팅, 통계) |
| Pilot Light | 분 단위 | 10–30분 | 중요도 중간 (정보계) |
| Warm Standby | 초 단위 | 5–10분 | 중요 업무 (채널계) |
| Multi-AZ Active-Active | 거의 0 | 자동 failover | 핵심 업무 (결제, 인증) |
메리츠증권은 차세대 증권 플랫폼을 AWS 클라우드 네이티브로 구축하면서, 서울 리전 단일 리전으로 운영하되 Multi-AZ 기반의 재해복구 체계를 설계했어요. Amazon EKS, Amazon Aurora, Amazon MSK 등 핵심 서비스를 Multi-AZ로 배포해서 가용영역 장애 시 자동 페일오버가 가능하도록 구성한 거예요. RTO 3시간 달성이 목표였어요.
# 금융기관 Multi-AZ DR 구성 예시 (AWS 서울 리전)
primary:
region: ap-northeast-2
availability_zones:
- ap-northeast-2a
- ap-northeast-2b
- ap-northeast-2c
database:
engine: aurora-mysql
mode: multi-az
replication: synchronous # RPO < 1초
failover: automatic # RTO 1–5분
compute:
type: eks
pod_distribution: multi-az
min_replicas_per_az: 2
cache:
engine: elasticache-redis
mode: cluster
multi_az: true
backup:
schedule: daily
retention_days: 30
storage: s3-standard
archive_after_days: 90
archive_storage: s3-glacier # 5년 보관 (감독규정 준수)
dr_test:
frequency: annually # 제23조 연 1회 이상 모의훈련
documentation: required여기서 한 발짝 더 나아가야 한다고 생각해요. Multi-AZ만으로는 리전 전체 장애에 대응할 수 없어요. 2022년 카카오 데이터센터 화재 사태 이후 금융당국이 재해복구센터 의무를 확대한 것도 이 때문이에요. OCI 춘천 리전을 활용한 Cross-Region DR이나, 온프레미스 백업 센터와의 하이브리드 구성을 고려해야 해요.
하이브리드 클라우드 아키텍처 패턴
대부분의 금융사는 핵심계(계정계)를 온프레미스에 유지하고, 채널계와 정보계를 클라우드로 전환하는 하이브리드 패턴을 채택하고 있어요.
금융사의 하이브리드 클라우드 패턴을 정리하면 이래요.
| 영역 | 위치 | 이유 |
|---|---|---|
| 핵심계 (계정계) | 온프레미스 | 데이터 주권, 초저지연, 레거시 의존성 |
| 채널계 (모바일/웹) | 퍼블릭 클라우드 | 탄력적 확장, 빠른 배포, 비용 효율 |
| 정보계 (분석/AI) | 퍼블릭 클라우드 | 대규모 컴퓨팅, ML 서비스 활용 |
| DR/백업 | 클라우드 | 비용 효율적 DR, 탄력적 복구 |
메리츠증권은 이 패턴을 잘 보여주는 사례예요. 코어망(계정계)이 IDC에 위치하므로, AWS와 IDC 간 AWS Direct Connect 이중화를 구성해서 단일 장애점(SPOF)을 제거했어요. VPN 대비 안정적인 레이턴시와 높은 대역폭을 확보한 거예요.
하나은행은 프라이빗과 퍼블릭 클라우드를 혼용하는 전략을 채택했어요. '아이부자' 서비스는 AWS 클라우드 네이티브로 구축했고, 코어뱅킹은 온프레미스를 유지하는 듀얼 오퍼레이팅 모델을 운영하고 있어요.
토스증권은 한 단계 더 나아갔어요. 기존 메인프레임 기반 시스템을 클라우드 네이티브 MSA로 완전히 전환하면서, 아시아 최초로 나스닥과 직접 연계한 초당 250만건 이상 트래픽 처리가 가능한 시세 시스템을 구축했어요. 나스닥에서 AWS 버지니아주 리전으로 시세 트래픽을 발송하면, 서울 리전으로 보내 분산 프로세싱을 통해 고객에게 전달하는 구조예요.
코리안리는 국내 금융권 최초로 기간계와 정보계 전체를 AWS로 전환했어요. 20개월에 걸친 전환 프로젝트를 킨드릴이 수행했고, Multi-AZ 구성을 통해 기존 물리적 데이터센터 기반 DR 대비 복구 시간을 크게 단축했어요. 이 사례는 "기간계는 온프레미스에 있어야 한다"는 업계의 고정관념을 깬 첫 번째 사례로 꼽혀요.
망분리 구현과 감사 로그 5년 보관 설계
금융권 망분리는 클라우드 환경에서 VPC 기반의 논리적 분리로 구현해요.
2026년 4월 20일부터 SaaS에 대한 망분리 예외가 시행됐어요. 개인신용정보·고유식별정보를 처리하지 않는 내부업무용 SaaS(문서작성, 화상회의, 협업도구 등)는 금융보안원 평가를 통과한 서비스에 한해 자유롭게 이용할 수 있어요. 하지만 고객 데이터를 처리하는 시스템은 여전히 망분리 규제가 적용돼요.
이 변화는 금융사 내부 개발팀에 실질적인 영향을 줘요. 그동안 망분리 때문에 사용하지 못했던 협업 도구나 SaaS 개발 환경을 조건부로 활용할 수 있게 됐어요. 단, 보안 조건을 충족하는 서비스인지 사전에 확인해야 해요.
클라우드 환경에서 망분리를 구현하는 핵심 서비스를 정리하면 이래요.
| 서비스 | 역할 | 금융 활용 패턴 |
|---|---|---|
| Transit Gateway | VPC 간 중앙 라우팅 허브 | Hub-and-Spoke 아키텍처, 트래픽 검사 |
| VPC Peering | VPC 간 직접 연결 | 동일 리전 내 서비스 간 통신 |
| PrivateLink | AWS 백본 네트워크 통한 프라이빗 접근 | 퍼블릭 인터넷 우회, API 통신 |
| Direct Connect | 온프레미스-클라우드 전용선 | 코어뱅킹 연결 (이중화 필수) |
| Network Firewall | East-West 트래픽 검사 | VPC 간 통신 필터링 |
처음에는 VPC Peering만으로 충분하다고 생각했는데, 실제로 만들어 보니 금융사 규모에서는 Transit Gateway 기반의 Hub-and-Spoke 구조가 필수였어요. VPC가 수십 개로 늘어나면 Peering의 N:N 연결이 관리 불가능해지거든요.
감사 로그 5년 보관은 전자금융감독규정의 핵심 요구사항 중 하나예요. CloudTrail을 활용한 설계 패턴을 정리하면 이래요.
# 감사 로그 5년 보관 아키텍처
CloudTrail:
Management Events: 모든 API 호출 기록
Data Events: S3, DynamoDB 접근 기록
Log Integrity: SHA-256 해싱 + RSA 디지털 서명
Digest Files: 매시간 생성 (체인 구조로 위변조 탐지)
Storage Lifecycle:
0–30일: S3 Standard (즉시 접근)
30일–1년: S3 Standard-IA (비용 절감)
1–5년: S3 Glacier (장기 보관)
보호: S3 Object Lock (WORM, Compliance 모드)
Access Control:
감사자: Read-only IAM 정책
관리자: MFA Delete 필수
네트워크: VPC Endpoint 통한 프라이빗 접근만 허용
Query:
CloudTrail Lake: SQL 기반 쿼리 (감사 보고서 생성)
보관: 최대 10년 (EXTENDABLE_RETENTION_PRICING)
비용: $0.75/GB (수집), $0.023/GB/월 (1년 이후 보관)OCI 환경에서는 Audit 서비스가 동일한 역할을 해요. OCI Audit은 모든 API 호출을 자동으로 기록하고, Object Storage에 장기 보관할 수 있어요. 보관 정책을 설정하면 5년 이상 불변 저장이 가능해요.
금융사 입장에서 감사 로그 설계 시 놓치기 쉬운 부분이 있어요. 로그를 "저장"하는 것과 "검색 가능하게 저장"하는 건 다른 문제예요. 감독당국이 특정 사용자의 특정 시점 접근 이력을 요청할 때, Glacier에 보관된 로그를 복원하는 데 수 시간이 걸릴 수 있어요. CloudTrail Lake를 활용하면 SQL 쿼리로 즉시 검색이 가능해서, 감사 대응 시간을 크게 줄일 수 있어요.
핵심 요약
- 2023년 전자금융감독규정 개정으로 금융 클라우드 이용이 실질적으로 자유로워졌어요. CSP 평가항목 141→54개, 사전보고→사후보고 전환이 핵심이에요. 2025년 2월에는 규칙 293→166개로 줄면서 자율보안 체계로 전환됐어요.
- 데이터 국내 저장 의무(제14조의2 제8항)는 변하지 않았어요. 개인신용정보는 반드시 국내 소재 클라우드에서 저장·처리해야 해요. "저장"뿐 아니라 "처리"도 포함이에요.
- 대부분의 금융사는 핵심계(온프레미스) + 채널계(클라우드) 하이브리드 패턴을 채택하고 있어요. 메리츠증권, 하나은행, 토스증권, 코리안리가 대표 사례예요.
- DR 설계는 Multi-AZ 기반이 표준이에요. 2025년 개정으로 재해복구센터 의무 대상이 확대됐으므로, 여신전문금융회사와 전자금융업자도 준비해야 해요. 매년 1회 이상 모의훈련도 필수예요.
- 감사 로그 5년 보관은 CloudTrail + S3 Object Lock(WORM) 조합으로 구현할 수 있어요. 로그 무결성 검증(SHA-256 + RSA)은 필수이고, CloudTrail Lake를 활용하면 SQL 쿼리로 즉시 검색이 가능해요.
다음 글에서는 선불충전금 100% 별도관리를 시스템으로 어떻게 구현하는지 다룰게요.
FAQ
Q. 금융회사가 퍼블릭 클라우드를 사용할 수 있나요?
2023년 1월 1일부터 금융회사와 전자금융업자는 퍼블릭 클라우드를 사용할 수 있어요. 개인신용정보와 고유식별정보를 포함한 중요 업무도 조건부로 허용돼요. 다만 국내 소재 클라우드에 한정되고, CSP 안전성 평가, 업무연속성 계획, 정보보호위원회 심의 등의 절차를 거쳐야 해요.
Q. 금융 데이터를 해외 리전에 저장할 수 있나요?
개인신용정보와 고유식별정보는 해외 리전에 저장할 수 없어요. 전자금융감독규정 제14조의2 제8항이 국내 소재 클라우드 이용을 의무화하고 있어요. 비중요 정보(마케팅 데이터, 통계 등)는 해외 리전 저장이 가능하지만, 데이터 분류를 명확히 해야 해요.
Q. 금융 클라우드에서 DR은 어떤 수준으로 설계해야 하나요?
전자금융감독규정 제23조에 따라 업무지속성 확보방안을 수립해야 해요. 핵심 업무(결제, 인증)는 Multi-AZ Active-Active로 RPO 거의 0, RTO 자동 failover 수준을 권장해요. 채널계는 Warm Standby(RPO 초 단위, RTO 5–10분)가 적합해요. 매년 1회 이상 모의훈련도 필수예요.
Q. 클라우드 전환 시 금융감독원 사전 보고가 필요한가요?
2023년 개정으로 사전보고 의무가 사후보고로 전환됐어요. 클라우드 이용계약을 신규 체결하거나 중대한 변경이 있는 경우, 3개월 이내에 금융감독원에 사후보고하면 돼요. 제출 서류는 업무 중요도 평가 결과, CSP 안전성 평가 결과, 업무연속성 계획, 정보보호위원회 심의 결과, 이용계약서예요.