💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

"쿠버네티스 도입하면 배포가 빨라진다면서요?" 금융사 인프라 조직에서 이 말을 들으면 웃음부터 나옵니다. 기술적으로는 맞는 말이지만, 금융권에서 쿠버네티스를 도입한다는 것은 단순히 클러스터를 띄우는 문제가 아니기 때문입니다. 전자금융감독규정, 망분리 요건, 클라우드 이용 보고 절차, 감사 추적 의무, 재해복구훈련 — 이 모든 규제 요건을 클라우드 네이티브 아키텍처 위에서 만족시켜야 비로소 "운영해도 되는" 플랫폼이 됩니다.

이 글은 금융권 환경에서 쿠버네티스 플랫폼을 설계·운영해 본 관점에서, 규제와 클라우드 네이티브가 공존하는 아키텍처를 정리한 것입니다. 일반 기업의 쿠버네티스 모범 사례와 무엇이 다른지, 그리고 그 차이를 어떻게 기술로 메우는지에 집중합니다.

먼저 분명히 해 둘 점이 있습니다. 이 글은 기술 블로그이며 법률 자문이나 규제 해석을 제공하지 않습니다. 실제 도입 시에는 반드시 소속 기관의 준법감시·정보보호 조직, 그리고 필요하다면 금융감독원의 유권해석을 거쳐야 합니다.

금융권 쿠버네티스의 현실 — 규제 환경 이해

전자금융감독규정이라는 출발점

한국 금융권 인프라의 모든 설계는 전자금융감독규정에서 출발합니다. 이 규정은 전자금융거래의 안전성 확보를 위해 금융회사가 지켜야 할 인적·물적 요건을 정의합니다. 쿠버네티스 플랫폼 관점에서 특히 중요한 조항들의 주제는 다음과 같습니다.

- 정보처리시스템의 내부망과 외부망 분리(망분리)

- 전산자료 보호 대책과 접근 통제

- 정보처리 업무 위탁(클라우드 이용 포함) 시 절차와 보고

- 재해복구센터 구축과 재해복구훈련 실시

- 전산원장(계정계 데이터) 관리와 변경 통제

2023년 이후 망분리 규제는 단계적으로 합리화되는 흐름이고, 2024년 발표된 금융분야 망분리 개선 로드맵에 따라 SaaS 이용과 생성형 AI 활용 범위가 넓어지고 있습니다. 그러나 계정계와 같은 핵심 시스템에 대한 보수적 통제는 여전히 유효합니다. 즉, "규제가 풀리고 있으니 다 된다"도 아니고 "아무것도 못 한다"도 아닌, 시스템 등급별로 다른 통제를 적용하는 시대가 되었습니다.

망분리와 클러스터 분리 아키텍처

망분리 요건을 쿠버네티스에 적용하면 가장 먼저 부딪히는 질문이 "클러스터를 몇 개로 나눌 것인가"입니다. 일반적인 금융사 구성은 다음과 같습니다.

[ 인터넷 ]

+--------+--------+

| 외부 방화벽 |

+--------+--------+

..........................|.......................... DMZ 구간

: +--------+--------+ :

: | DMZ 클러스터 | :

: | - 채널 게이트웨이 | :

: | - WAF/프록시 | :

: | - 대외계 어댑터 | :

: +--------+--------+ :

......................... | ..........................

+--------+--------+

| 내부 방화벽/IPS | <- 단방향성 통제, 허용 포트 최소화

+--------+--------+

..........................|.......................... 내부망(업무망)

: +----------------+ | +------------------+ :

: | 내부망 클러스터 +---+---+ 정보계 클러스터 | :

: | - 채널계 서비스 | | - 배치/분석 | :

: | - 공통 서비스 | | - 데이터 파이프라인| :

: +-------+--------+ +------------------+ :

: | :

: +-------+--------+ +-------------------+ :

: | 계정계(코어뱅킹) | | 운영/관리 영역 | :

: | 전통 인프라 또는 | | - CI/CD, 레지스트리| :

: | 전용 클러스터 | | - 모니터링, 로그 | :

: +----------------+ +-------------------+ :

.....................................................

핵심 원칙은 다음과 같습니다.

1. **DMZ 클러스터와 내부망 클러스터는 물리적으로 분리**합니다. 하나의 클러스터를 네임스페이스로 나눠 DMZ와 내부망을 겸용하는 구성은 망분리 취지에 어긋난다고 보는 것이 보수적 해석입니다.

2. **DMZ에서 내부망으로의 통신은 방화벽에서 목적지·포트 단위로 화이트리스트** 처리합니다. 쿠버네티스 NetworkPolicy는 보조 수단이지 방화벽의 대체재가 아닙니다.

3. **운영/관리 영역(CI/CD, 레지스트리, 모니터링)은 별도 영역**으로 두고, 각 클러스터로의 접근을 단방향으로 설계합니다. 레지스트리에서 클러스터가 이미지를 당겨가는(pull) 구조가 기본입니다.

4. 개발망과 운영망의 분리도 잊지 말아야 합니다. 개발자는 개발망 클러스터까지만 직접 접근하고, 운영망 반영은 GitOps 파이프라인을 통해서만 이루어집니다.

클라우드 이용 규제 흐름 — 중요도 평가와 보고

퍼블릭 클라우드 위에 쿠버네티스(EKS, AKS, GKE 등 관리형 서비스 포함)를 올리려면 전자금융감독규정상 클라우드컴퓨팅서비스 이용 절차를 따라야 합니다. 실무 흐름은 대략 다음과 같습니다.

[1] 이용 대상 업무 식별

[2] 중요도 평가

| - 고유식별정보/개인신용정보 처리 여부

| - 전자금융거래의 안전성·신뢰성에 미치는 영향

+--> 중요업무 아님 --> [3a] 자체 절차 + 이용 현황 관리

+--> 중요업무 해당 --> [3b] 업무 연속성 계획 + 안전성 확보조치

[4] 정보보호위원회 심의·의결

[5] 금융감독원 사전 보고 (중요업무, 이용 7영업일 전)

[6] 계약 체결 + 이용 개시

[7] 사후 관리: 연 1회 이상 안전성 점검, 변경 시 재평가

플랫폼 엔지니어 입장에서 중요한 것은, **이 절차의 산출물이 플랫폼 설계의 입력값**이 된다는 점입니다. 중요도 평가 결과 "중요업무"로 분류된 워크로드는 더 강한 격리(전용 클러스터 또는 전용 노드풀), 더 긴 감사 로그 보관, 더 높은 DR 등급을 요구받습니다. 평가 결과를 네임스페이스 라벨로 코드화해 두면 정책 엔진이 자동으로 차등 통제를 적용할 수 있습니다.

apiVersion: v1

kind: Namespace

metadata:

labels:

bank.example.com/criticality: "critical" # 중요도 평가 결과

bank.example.com/data-class: "pci-personal" # 데이터 등급

bank.example.com/dr-tier: "tier-1" # DR 등급

bank.example.com/owner-dept: "payments-dev" # 소관 부서

멀티테넌시 — 네임스페이스로 나눌 것인가, 클러스터로 나눌 것인가

쿠버네티스 멀티테넌시의 고전적 질문이지만, 금융권에서는 판단 기준이 더 명확합니다. 격리 수준을 결정하는 것은 기술 선호가 아니라 **데이터 등급과 규제 경계**입니다.

| 격리 기준 | 네임스페이스 분리로 충분 | 클러스터 분리 필요 |

| --- | --- | --- |

| 망 구간 | 동일 망 구간 내 | DMZ와 내부망 사이 |

| 데이터 등급 | 동일 등급(예: 일반 정보계) | 개인신용정보 처리계와 비처리계 |

| 조직 경계 | 동일 본부 내 팀 단위 | 자회사, 외부 위탁 운영 조직 |

| 장애 영향 | 일부 채널 지연 허용 | 코어뱅킹 등 전행 장애로 직결 |

| 변경 통제 | 동일 결재 라인 | 결재 주체와 점검 주기가 다름 |

| 커널/노드 요건 | 표준 노드 이미지 | 전용 HSM 연동, 특수 커널 모듈 |

계정계는 어디까지 올릴 것인가

가장 뜨거운 주제입니다. 계정계(코어뱅킹) — 원장 처리, 여신·수신 거래, 일마감 배치 — 를 쿠버네티스에 올릴 수 있는가. 2026년 현재 현실적인 답은 "주변부터, 단계적으로"입니다.

- **1단계: 계정계 조회성 API.** 원장을 직접 갱신하지 않는 잔액 조회, 거래내역 조회 API를 컨테이너화합니다. 읽기 전용이므로 장애 시 영향이 제한적입니다.

- **2단계: 계정계 주변 보조 서비스.** 수수료 계산, 한도 검증, 알림 발송 등 원장 트랜잭션의 전후 처리를 분리합니다.

- **3단계: 신규 상품의 원장 분리.** 신규 디지털 상품의 원장을 별도 마이크로 원장으로 설계해 처음부터 클라우드 네이티브로 구축합니다. 인터넷전문은행들이 검증한 경로입니다.

- **최후: 기존 원장의 전환.** 일마감 배치의 시간 제약, 트랜잭션 정합성, 감독 보고 체계까지 모두 재검증해야 하므로 수년 단위 프로그램으로 접근합니다.

네임스페이스 격리를 선택한 구간에서도 기본 골격은 갖춰야 합니다. ResourceQuota와 LimitRange로 자원 경계를, NetworkPolicy로 통신 경계를, RBAC으로 권한 경계를 긋습니다.

apiVersion: v1

kind: ResourceQuota

metadata:

namespace: payment-core

spec:

hard:

requests.cpu: "64"

requests.memory: 256Gi

limits.cpu: "96"

pods: "300"

services.loadbalancers: "0" # LB 생성은 플랫폼팀만

보안 강화 스택 — 게이트는 코드로

금융권 보안 점검의 특징은 "증적"입니다. 통제가 존재한다는 사실뿐 아니라, 통제가 동작했다는 기록을 제시해야 합니다. 정책을 코드로 관리하면 두 가지가 동시에 해결됩니다.

Pod Security Admission 기본선

PodSecurityPolicy가 제거된 지 오래이므로, 기본선은 Pod Security Admission(PSA)입니다. 운영 네임스페이스는 restricted를 기본으로 강제합니다.

apiVersion: v1

kind: Namespace

metadata:

labels:

pod-security.kubernetes.io/enforce: restricted

pod-security.kubernetes.io/enforce-version: latest

pod-security.kubernetes.io/audit: restricted

pod-security.kubernetes.io/warn: restricted

Kyverno로 구현하는 금융 정책 게이트

PSA가 다루지 못하는 조직 고유 정책은 Kyverno로 구현합니다. 대표적인 세 가지 — 폐쇄망 레지스트리 강제, 이미지 서명 검증, 취약점 스캔 통과 증명 — 를 하나의 흐름으로 묶을 수 있습니다.

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

spec:

validationFailureAction: Enforce

background: true

rules:

규칙 1: 사내 폐쇄망 레지스트리 외 이미지 차단

- name: restrict-registry

match:

any:

- resources:

kinds: ["Pod"]

validate:

message: "사내 레지스트리(registry.bank.internal) 이미지만 허용됩니다."

pattern:

spec:

containers:

- image: "registry.bank.internal/*"

규칙 2: latest 태그 금지 — 변경 추적 불가

- name: disallow-latest-tag

match:

any:

- resources:

kinds: ["Pod"]

validate:

message: "이미지는 불변 태그(digest 또는 버전)를 사용해야 합니다."

pattern:

spec:

containers:

- image: "!*:latest"

이미지 서명 검증은 Sigstore Cosign과 Kyverno의 verifyImages를 결합합니다. CI 파이프라인이 빌드 후 서명하고, 클러스터 입구에서 서명을 검증하므로 "승인된 파이프라인을 거치지 않은 이미지는 기동 자체가 불가"하다는 증적이 만들어집니다.

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

spec:

validationFailureAction: Enforce

webhookTimeoutSeconds: 30

rules:

- name: require-cosign-signature

match:

any:

- resources:

kinds: ["Pod"]

namespaceSelector:

matchLabels:

bank.example.com/criticality: critical

verifyImages:

- imageReferences:

- "registry.bank.internal/*"

attestors:

- entries:

- keys:

publicKeys: |-

-----BEGIN PUBLIC KEY-----

MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...

-----END PUBLIC KEY-----

취약점 스캔 attestation 검증: Critical 취약점 0건 증명

attestations:

- type: https://cosign.sigstore.dev/attestation/vuln/v1

conditions:

- all:

- key: "{{ scanner }}"

operator: Equals

value: "trivy"

폐쇄망 레지스트리 운영

인터넷 차단 환경에서는 이미지 공급망 자체를 내재화해야 합니다.

[ 외부 인터넷 구간 (제한적 허용) ]

docker.io / ghcr.io / quay.io

v (1) 미러링 전용 서버에서 주기적 동기화

[ 검역 구간 ]

스테이징 레지스트리 --> (2) Trivy/Grype 전수 스캔

| (3) 정책 통과 시 서명(cosign sign)

v (4) 승인 이미지만 내부 반입

[ 내부망 ]

Harbor (registry.bank.internal)

|- proxy-cache 프로젝트: 베이스 이미지

|- apps 프로젝트: 사내 빌드 산출물

+- 복제(replication): DR 사이트 레지스트리

Harbor를 쓰면 프로젝트 단위 RBAC, 취약점 스캔 연동, 태그 불변성(immutability), 보존 정책을 한 번에 해결할 수 있어 금융권 폐쇄망 표준 구성으로 널리 쓰입니다.

감사 추적 — 모든 변경은 기록되고 승인된다

API 감사 로그의 장기 보관

쿠버네티스 API 서버의 audit log는 "누가 언제 무엇을 변경했는가"의 1차 증적입니다. 전자금융감독규정의 기록 보존 취지에 맞춰 통상 1년 이상, 기관 정책에 따라 5년까지 보관하도록 설계합니다.

apiVersion: audit.k8s.io/v1

kind: Policy

rules:

시크릿 접근은 메타데이터 수준까지 모두 기록

- level: Metadata

resources:

- group: ""

resources: ["secrets", "configmaps"]

워크로드 변경은 요청 본문까지 기록

- level: RequestResponse

verbs: ["create", "update", "patch", "delete"]

resources:

- group: "apps"

resources: ["deployments", "statefulsets", "daemonsets"]

- group: ""

resources: ["pods", "services"]

조회성 요청은 기록 최소화 (저장 비용 통제)

- level: None

verbs: ["get", "list", "watch"]

users: ["system:kube-proxy", "system:apiserver"]

- level: Metadata

omitStages: ["RequestReceived"]

보관 파이프라인은 변조 방지가 핵심입니다. audit log를 노드 로컬에 두지 말고, Fluent Bit 등으로 즉시 외부 로그 시스템에 전송한 뒤, WORM(Write Once Read Many) 속성의 오브젝트 스토리지에 일 단위로 아카이브합니다. 해시 체인이나 스토리지의 오브젝트 잠금 기능으로 무결성을 증명할 수 있게 합니다.

GitOps와 전자결재의 연동

금융사의 변경 관리는 "결재 없이는 반영 없다"로 요약됩니다. GitOps는 이 요건과 의외로 궁합이 좋습니다. Git이 단일 진실 공급원이므로, 결재 시스템과 Git 머지를 연동하면 변경 통제가 자동화됩니다.

개발자 Git 저장소 전자결재 시스템 ArgoCD

| | | |

|--- PR 생성 --------->| | |

| |--- 웹훅: 결재 기안 --->| |

| | |--- 승인선 결재 -->|

| | | (팀장/보안/ |

| | | 변경관리위원회) |

| |<-- 승인 콜백 ----------| |

| | (머지 잠금 해제) | |

|--- 머지 ------------>| | |

| |<------------------- 동기화(폴링/웹훅) ----|

| | | |

| | 운영 클러스터에 적용 + 적용 결과를 |

| | 결재 문서에 자동 첨부(증적 회수) |

구현 포인트는 세 가지입니다.

1. **운영 브랜치 보호 규칙**: 결재 승인 상태를 확인하는 status check가 통과해야만 머지할 수 있게 합니다.

2. **긴급 변경(브레이크글라스) 경로**: 장애 시 선조치·후결재 경로를 미리 정의하고, 사용 시 자동으로 사후 결재 기안과 알림이 발생하게 합니다.

3. **드리프트 탐지**: ArgoCD의 selfHeal과 드리프트 알림으로 "Git에 없는 변경"을 즉시 탐지합니다. 이것이 곧 무단 변경 탐지 통제의 증적이 됩니다.

가용성 설계 — DR은 등급으로 말한다

RTO/RPO 등급 체계

금융권 DR은 시스템마다 일률적이지 않고 등급제로 운영합니다. 중요도 평가 결과와 연동된 전형적인 등급표는 다음과 같습니다.

| --- | --- | --- | --- | --- |

쿠버네티스 관점의 구현은 계층별로 나뉩니다.

- **클러스터 토폴로지**: Tier 1·2는 멀티 AZ 노드 분산이 기본입니다. topologySpreadConstraints와 PodDisruptionBudget으로 단일 AZ 장애에 서비스가 살아남게 합니다.

- **리전 간 DR**: 주 센터와 DR 센터(또는 주 리전과 DR 리전)에 각각 독립 클러스터를 두고, GitOps로 동일 매니페스트를 양쪽에 적용합니다. "클러스터를 복구"하는 것이 아니라 "어디서든 같은 상태를 재현"하는 모델이 클라우드 네이티브 DR의 본질입니다.

- **상태 데이터**: 진짜 어려운 것은 데이터입니다. 데이터베이스는 스토리지/DB 계층의 복제 기능에 맡기고, 쿠버네티스에는 무상태 워크로드 위주로 올리는 것이 초기 전략으로 안전합니다.

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 6

template:

spec:

topologySpreadConstraints:

- maxSkew: 1

topologyKey: topology.kubernetes.io/zone

whenUnsatisfiable: DoNotSchedule

labelSelector:

matchLabels:

app: channel-api

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

spec:

minAvailable: 4

selector:

matchLabels:

app: channel-api

재해복구훈련을 플랫폼 기능으로

금융사는 정기적인 재해복구훈련(통상 연 1회 이상, 핵심 시스템은 더 자주)이 의무입니다. 이를 수작업 이벤트가 아니라 플랫폼의 반복 가능한 기능으로 만들어야 합니다.

- DNS/GSLB 전환, DR 클러스터 스케일아웃, 데이터 정합성 검증을 스크립트화하고 훈련마다 동일 절차를 실행합니다.

- 훈련 결과(전환 소요 시간, 데이터 손실량, 실패 항목)를 자동 수집해 보고서를 생성합니다. 이 보고서가 감독 보고와 내부 감사 증적이 됩니다.

- 평시에 DR 클러스터를 정보계 배치나 검증 환경으로 활용하면 비용을 상쇄할 수 있습니다. 단, 훈련 시 즉시 비울 수 있는 워크로드만 배치합니다.

자격과 접근 통제 — 사람이 가장 큰 변수

인사 시스템 연동

금융권 감사에서 단골로 지적되는 항목이 "퇴직자·전배자 계정 미회수"입니다. 쿠버네티스 접근 권한도 예외가 아니므로, 인사 시스템을 권한의 원천으로 삼아야 합니다.

인사 시스템(HR) ---> IdP (Keycloak/AD) ---> OIDC ---> kube-apiserver

| | |

| 발령/퇴직 이벤트 | 그룹 멤버십 자동 갱신 | RBAC 그룹 바인딩

+------------------->| (부서 코드 = IdP 그룹) |

+--- 미사용 90일 계정 자동 잠금 |

kubeconfig에 정적 토큰이나 클라이언트 인증서를 배포하는 방식은 회수가 불가능하므로 금지하고, 반드시 OIDC 단기 토큰으로 통일합니다. RBAC은 개인이 아닌 IdP 그룹에 바인딩해서, 인사이동 시 권한이 자동으로 따라가게 합니다.

PIM(특권 접근 관리) 패턴

운영 클러스터의 상시 admin 권한은 0명이 원칙입니다. 필요할 때 신청하고, 승인되면 시간 제한부 권한을 받는 Just-in-Time 패턴을 적용합니다.

평시: 운영자는 읽기 전용 그룹에만 소속

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

subjects:

- kind: Group

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: ClusterRole

apiGroup: rbac.authorization.k8s.io

[승격 흐름]

운영자 --> PIM 포털에서 사유 입력 + 대상 네임스페이스 + 시간(최대 4h) 신청

--> 승인자(타인) 승인 --> 자동화가 임시 RoleBinding 생성

--> 만료 시각에 컨트롤러가 RoleBinding 자동 삭제

--> 승격 구간의 모든 kubectl 명령은 audit log에서 별도 태깅·리뷰

세션 레코딩이 필요한 환경이라면 Teleport 같은 액세스 프록시를 앞단에 두어 kubectl exec 세션까지 녹화 증적을 남깁니다.

네트워크 정책 — 기본 거부에서 출발

망분리가 거시적 경계라면, 클러스터 내부의 미시적 경계는 NetworkPolicy입니다. 원칙은 단순합니다. **기본 거부(deny-all)를 깔고, 필요한 통신만 화이트리스트**합니다.

1단계: 네임스페이스 기본 거부 (Ingress + Egress)

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

namespace: payment-core

spec:

podSelector: {}

policyTypes: ["Ingress", "Egress"]

2단계: DNS는 허용 (egress 차단 시 가장 먼저 깨지는 것)

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

namespace: payment-core

spec:

podSelector: {}

policyTypes: ["Egress"]

egress:

- to:

- namespaceSelector:

matchLabels:

kubernetes.io/metadata.name: kube-system

ports:

- protocol: UDP

port: 53

- protocol: TCP

port: 53

CNI 선택은 Cilium과 Calico가 양강입니다. Cilium은 L7 정책(HTTP 메서드·경로 단위 제어)과 Hubble 기반 통신 가시화가 강점이라, "이 파드가 실제로 어디와 통신했는가"라는 감사 질문에 플로우 로그로 답할 수 있습니다. Calico는 성숙한 정책 모델과 BGP 연동, 엔터프라이즈판의 정책 추천 기능이 강점입니다. 어느 쪽이든 정책 적용 전에 모니터링 모드로 플로우를 수집해 허용 목록 초안을 만든 뒤 강제 모드로 전환하는 순서를 권장합니다.

계정계 방향 egress는 특히 좁게 잡습니다. Cilium이라면 FQDN 정책으로 특정 인터페이스 도메인만 열 수 있습니다.

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

namespace: channel-api

spec:

endpointSelector:

matchLabels:

app: transfer-service

egress:

- toFQDNs:

- matchName: "mca-gateway.core.bank.internal"

toPorts:

- ports:

- port: "8443"

protocol: TCP

관측과 컴플라이언스 보고 자동화

관측 스택(Prometheus, Loki, Tempo, Grafana)은 일반 기업과 크게 다르지 않지만, 금융권에는 두 가지 요구가 추가됩니다.

1. **보고 자동화.** 감독 보고·내부 점검에 들어가는 지표(가용률, 장애 건수, 변경 건수, 취약점 조치율)를 대시보드가 아니라 **정기 산출물**로 만들어야 합니다. Grafana 리포팅이나 배치 잡으로 월간 PDF/CSV를 생성해 결재 시스템에 자동 기안하는 수준까지 가면 운영 부담이 크게 줄어듭니다.

2. **컴플라이언스 상시 점검.** CIS Kubernetes Benchmark 기반 점검(kube-bench), 런타임 이상 탐지(Falco), 정책 위반 현황(Kyverno PolicyReport)을 주기 실행하고 결과를 시계열로 적재합니다. "점검은 연 1회 수검 때만"이 아니라 "상시 점검 + 수검 시 이력 제출" 체계로 전환하는 것입니다.

[증적 파이프라인]

kube-bench (주 1회) --+

Falco 이벤트 (상시) ---+--> 로그 파이프라인 --> WORM 스토리지 (장기 보관)

PolicyReport (상시) --+ |

audit log (상시) -----+ +--> 월간 컴플라이언스 리포트 잡 --> 전자결재 기안

레거시 연계 — MCA/ESB와 서비스 메시의 경계

금융사 내부에는 이미 MCA(Multi Channel Architecture)나 ESB(Enterprise Service Bus)라는 통합 계층이 있습니다. 쿠버네티스 위의 신규 서비스가 계정계와 통신하는 경로는 이 레거시 통합 계층을 우회할 수 없는 경우가 대부분입니다.

+---------------------------- 내부망 클러스터 ----------------------------+

| |

| [채널 서비스 A] --\ |

| [채널 서비스 B] ---+--> [메시 egress 게이트웨이] ---+ |

| [채널 서비스 C] --/ (mTLS 종단, 트래픽 통제) | |

| | |

+----------------------------------------------------|------------------+

[어댑터 서비스 (프로토콜 변환)]

REST/gRPC <-> 전문(고정길이)

[MCA / ESB]

+------------+-----------+

| 계정계 (원장/여신/수신) |

| 대외계 (금결원/VAN망) |

+------------------------+

설계 원칙은 다음과 같습니다.

- **메시의 경계는 클러스터까지.** Istio/Linkerd의 mTLS와 트래픽 정책은 클러스터 내부와 egress 게이트웨이까지만 적용하고, MCA/ESB 구간은 기존 전문 보안 체계(구간 암호화, 전문 무결성 검증)를 존중합니다. 메시를 레거시까지 확장하려는 시도는 대부분 비용 대비 효과가 없습니다.

- **어댑터 서비스에 변환을 집중.** 고정길이 전문, EBCDIC 변환, 전문 헤더의 거래코드 매핑 같은 레거시 특수성은 어댑터 한 곳에 모읍니다. 채널 서비스들이 전문 포맷을 알게 하면 레거시가 클러스터 안으로 전염됩니다.

- **타임아웃과 서킷브레이커는 계정계 기준으로.** 계정계 전문 응답의 타임아웃 규약(예: 3초 응답, 미응답 시 취소 전문)을 메시의 재시도 정책이 깨지 않도록 설계합니다. 무분별한 자동 재시도는 이중 거래 사고로 직결됩니다. 멱등키와 취소(보상) 전문 설계를 먼저 확인해야 합니다.

도입 로드맵 — 정보계에서 대외계까지

빅뱅 전환은 금융권에서 선택지가 아닙니다. 위험도가 낮은 영역부터 단계적으로 확장합니다.

| 단계 | 대상 | 기간(예시) | 목표와 검증 항목 |

| --- | --- | --- | --- |

| 0 | 플랫폼 구축 | 3~6개월 | 클러스터 표준, 레지스트리, GitOps, 정책 게이트, 관측 스택 |

| 1 | 정보계 | 6개월 | 배치·분석 워크로드 이전, 운영 절차와 증적 체계 검증 |

| 2 | 내부 업무계 | 6개월 | 사내 포털·업무 API, 인사연동 접근 통제 실증 |

| 3 | 채널계 | 6~12개월 | 모바일/인터넷뱅킹 API, 무중단 배포, Tier 2 DR 실증 |

| 4 | 대외계 | 6~12개월 | 금결원·VAN 연동 어댑터, DMZ 클러스터, 보안성 심의 |

| 5 | 계정계 주변 | 지속 | 조회 API → 보조 서비스 → 신규 원장 순 확장 |

각 단계의 종료 조건을 "워크로드 개수"가 아니라 **"증적으로 입증 가능한 운영 능력"**으로 정의하는 것이 요령입니다. 예를 들어 1단계의 종료 조건은 "정보계 배치 50개 이전"이 아니라 "장애 훈련 1회, DR 전환 1회, 감사 로그 기반 변경 추적 시연 1회 완료"가 되어야 합니다.

체크리스트

도입·운영 점검용 체크리스트입니다.

**규제·거버넌스**

- 클라우드 이용 중요도 평가를 수행하고 결과를 네임스페이스 라벨로 코드화했는가

- 중요업무 해당 시 정보보호위원회 의결과 감독원 사전 보고를 완료했는가

- 변경 관리(결재)와 GitOps 머지가 시스템적으로 연동되어 있는가

- 브레이크글라스 절차와 사후 결재 경로가 정의되어 있는가

**아키텍처**

- DMZ/내부망 클러스터가 물리 분리되고 방화벽 화이트리스트가 최소화되어 있는가

- 데이터 등급·조직 경계 기준의 클러스터/네임스페이스 분리 기준 문서가 있는가

- Tier별 RTO/RPO가 정의되고 멀티 AZ 분산과 PDB가 적용되어 있는가

- 재해복구훈련이 스크립트화되어 반복 실행 가능한가

**보안**

- 모든 운영 네임스페이스에 PSA restricted가 강제되는가

- 폐쇄망 레지스트리 외 이미지가 정책으로 차단되는가

- 이미지 서명과 취약점 스캔 증명이 admission에서 검증되는가

- NetworkPolicy 기본 거부가 전 네임스페이스에 적용되어 있는가

- 운영 클러스터 상시 admin이 0명이고 JIT 승격이 동작하는가

**감사·관측**

- audit log가 변조 방지 스토리지에 정책 기간 이상 보관되는가

- 퇴직·전배 시 클러스터 접근 권한이 자동 회수되는가

- 컴플라이언스 점검(kube-bench, 정책 리포트)이 상시 실행되고 이력이 남는가

- 감독 보고용 지표 산출이 자동화되어 있는가

함정과 안티패턴

- **"규제 때문에 안 됩니다"의 남용.** 실제 규정을 확인하면 절차를 거쳐 가능한 경우가 많습니다. 규정 원문과 유권해석을 직접 확인하고, 막연한 관행을 규제로 착각하지 않아야 합니다.

- **네임스페이스 만능주의.** 망 구간이 다른 워크로드를 한 클러스터에 욱여넣으면 수검 때 전체 아키텍처를 다시 그리게 됩니다.

- **정책 게이트 없이 워크로드 먼저.** 이전을 시작한 뒤 정책을 끼우면 기존 워크로드가 대거 위반 상태가 되어 강제 모드 전환이 불가능해집니다. 게이트가 먼저입니다.

- **audit log를 노드에 방치.** 노드 장애나 침해 시 증적이 함께 사라집니다. 실시간 외부 전송이 기본입니다.

- **DR을 문서로만 보유.** 훈련에서 한 번도 전환해 보지 않은 DR은 없는 것과 같습니다. 훈련 자동화에 투자해야 합니다.

- **메시로 레거시까지 덮으려는 시도.** MCA/ESB 구간은 기존 통제를 존중하고 어댑터로 경계를 긋는 것이 현실적입니다.

- **재시도 정책 방치.** 메시·클라이언트의 자동 재시도가 계정계 멱등성 설계와 충돌하면 이중 이체 사고가 납니다. 금융 시스템에서 가장 비싼 버그입니다.

마치며

금융권 쿠버네티스 플랫폼의 본질은 "규제 요건을 코드로 변환하는 작업"입니다. 망분리는 클러스터 토폴로지로, 변경 통제는 GitOps와 결재 연동으로, 접근 통제는 인사연동 OIDC와 JIT 승격으로, 감사 대응은 WORM 증적 파이프라인으로 번역됩니다. 이 번역이 잘 된 조직에서는 규제가 더 이상 속도의 적이 아니라, 자동화된 가드레일 안에서 오히려 더 빠르게 움직일 수 있는 기반이 됩니다.

규제와 클라우드 네이티브는 공존할 수 있습니다. 다만 그 공존은 저절로 오지 않고, 플랫폼 팀이 규정 문서와 YAML을 동시에 읽을 수 있을 때 비로소 가능해집니다.

참고 자료

- [Kubernetes 공식 문서 — Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/)

- [Kubernetes 공식 문서 — Auditing](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)

- [Kubernetes 공식 문서 — Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)

- [Kyverno 공식 문서](https://kyverno.io/docs/)

- [Sigstore Cosign 공식 문서](https://docs.sigstore.dev/)

- [Cilium 공식 문서 — Network Policy](https://docs.cilium.io/en/stable/security/policy/)

- [Calico 공식 문서](https://docs.tigera.io/calico/latest/about/)

- [Harbor 공식 문서](https://goharbor.io/docs/)

- [Argo CD 공식 문서](https://argo-cd.readthedocs.io/)

- [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)

- [국가법령정보센터 — 전자금융감독규정](https://www.law.go.kr/)

- [금융감독원](https://www.fss.or.kr/)

- [BIS — Principles for Operational Resilience](https://www.bis.org/bcbs/publ/d516.htm)