금융권 컨테이너 도입 — 금융감독원 소명자료
컨테이너 도입 여부 자체가 논의되던 시점에, 규제기관을 설득할 근거를 만들고 운영 역량까지 이관했습니다.
| 조직 | 시기 | 역할 |
|---|---|---|
| 넥스클라우드 | 2020.09 – 2021.05 | Consulting Team Leader |
출발점 — 쿠버네티스가 국내에서 아직 '검증 중'이던 시기. 금융권에 참조할 선례 없음.
문제
금융권에서 컨테이너는 도입할 수 있는가 자체가 논의 대상이었습니다.
금융보안 통제 항목은 물리 서버와 고정 IP를 전제로 쓰여 있습니다. 컨테이너는 그 전제를 하나씩 깹니다 — 인스턴스가 수시로 생멸하고, IP가 고정이 아니고, 하나의 노드에 여러 워크로드가 올라갑니다.
기술적으로 가능하다는 설명으로는 부족했습니다. "컨테이너는 격리됩니다"는 엔지니어에게는 설명이지만 감독기관에는 주장입니다.
제약
- 참조할 선례가 없었습니다. 국내 금융권에 사례가 없으니 "다른 곳도 합니다"를 쓸 수 없었습니다.
- 감독기관은 기술 문서가 아니라 통제 문서를 읽습니다.
- 컨설팅이 끝나면 저희는 빠집니다. 고객이 스스로 운영할 수 있어야 했습니다.
접근
1. 통제 항목 × 구현 수단 매핑
기존 금융보안 통제 항목 하나하나에 대해, 컨테이너 환경에서 그에 상응하는 통제가 무엇인지, 그것이 왜 동등하거나 더 나은지를 매핑했습니다.
예를 들어 "서버 접근 이력이 남는가"라는 항목에 대해, 컨테이너는 개별 접속이 아니라 선언된 구성과 배포 기록으로 답합니다. 사람이 서버에 들어가는 일 자체가 줄어들기 때문에 오히려 통제 가능성이 높아진다는 논리를, 근거와 함께 구성해야 했습니다.
이 방법론은 같은 시기 ISMS-P 대응에서 쓴 것과 동일합니다 — 규제 언어로 번역하고, 대체 수단의 동등성을 근거로 입증한다.
2. 금융감독원 소명자료 작성·제공
금융보안 환경에서 컨테이너를 어떻게 통제할 수 있는지를 규제기관에 설명하는 근거 문서를 작성했습니다.
3. 3개 영역의 통제 과제 도출과 역량 이관
| 영역 | 내용 |
|---|---|
| 구축 | 아키텍처 · 네트워크 · 격리 구성 |
| 운영 | 배포 · 변경 · 로깅 · 접근 통제 |
| 보안 | 이미지 · 런타임 · 권한 · 취약점 |
각 영역의 과제를 도출하고, Know-how 이관과 실무자 Hands-on까지 수행했습니다. 목표는 산출물이 아니라 고객의 자체 운영 역량이었습니다.
컨설팅 산출물만 남기면 감독기관 질의가 다시 왔을 때 고객이 답하지 못합니다. 그러면 그 문서는 한 번 쓰고 끝납니다.
결과
- 금융권에 컨테이너 도입을 검토할 수 있는 규제 대응 근거 확보
- 고객사 내부에 남은 Kubernetes 운영 역량
- 구축 · 운영 · 보안 3개 영역의 통제 과제 체계
회고
규제 대응은 기술 논쟁이 아니라 입증 책임의 문제입니다. "안전합니다"를 증명해야 하는 쪽은 도입하려는 쪽이고, 증명은 상대의 언어와 상대의 평가 기준으로 해야 성립합니다.
이 작업이 제 커리어의 방법론이 됐습니다. ISMS-P, 개인정보 현장점검, 방통위 중재 — 전부 같은 구조입니다. 규제 항목을 구조화하고, 각 항목에 대해 근거를 갖춰 답하고, 상대가 쓰는 판단 기준 안에서 설계한다.
규제는 우회 대상이 아니라 설계 변수입니다.
같은 시기 — NIPA 5G MEC 분석시스템 구축 PM
국가 R&D 과제의 PM으로 설계·구축·검증 전 과정을 총괄했습니다.
- Kubernetes · Prometheus · Grafana 기반 VR/AR 패킷 분석 시스템 설계
- 멀티테넌시 — 1 Cluster 안에 사용자별 3 Namespace + 1 Dedicated Node
- Multus(Multi-CNI)와 MetalLB로 Data Plane과 Management Plane 분리
- 참조 구현이 없어 요구사항 정의부터 아키텍처 설계까지 직접 수립
관련 케이스 — 클라우드 보안 프레임워크 · ISMS-P · 개인정보 유출 사고 대응 · 중립 데이터센터 지위 확보
금융감독원 금융보안 Kubernetes 컨테이너 통제 Multus MetalLB 5G MEC