Track 2. AI Infrastructure/Financial AI Arch

금융권 PaaS 설계 시, 반드시 감안해야 할 5가지

Context Lab 2025. 10. 25. 11:37

'탄력성'과 '장애 격리'라는 PaaS의 기본 원칙은 금융권의 특수한 환경과 엄격한 법적 규제를 만났을 때, 다른 산업과는 완전히 다른 차원의 설계 지침이 추가되어야 합니다.

 

일반 기업에서 'Best Practice(권장 사항)'인 것이, 금융권에서는 **'Mandatory Requirement(강제 사항)'**가 됩니다.

 

금융권 PaaS 설계 시, 기존 원칙에 반드시 추가되어야 할 5가지 사항을 정리합니다.

 

1. (법률) '망분리' 규제 준수를 위한 아키텍처

일반 기업의 '장애 격리'는 K8s NetworkPolicy 같은 논리적 격리로 충분할 수 있습니다. 하지만 금융권은 전자금융감독규정에 따른 '망분리'라는 강력한 법적 요구사항이 있습니다.

  • 추가 설계 지침: PaaS 플랫폼 자체를 **'채널계(DMZ/외부망) PaaS'**와 **'계정계(내부망) PaaS'**로 분리하여 구축해야 할 수 있습니다.
  • 영향:
    - 'PT(화면)' 앱은 '채널계 PaaS'에, 'BT(업무)' 앱은 '계정계 PaaS'에 배포됩니다.
    - 이 두 PaaS 간의 통신은 오직 승인된 '망연계 솔루션' 또는 **'F/W(방화벽)'**를 통해서만 이뤄져야 합니다.
    - 이는 K8s 내부 통신(Service-to-Service)보다 훨씬 복잡하며, 네트워크 레이턴시와 장애 포인트를 추가합니다. '장애 격리'의 복잡성이 기하급수적으로 증가합니다.

 

2. (환경) '계정계(Core Banking)' 연동 및 보호

PaaS의 '탄력성'은 양날의 검입니다. PaaS 위의 앱(MSA)은 HPA를 통해 1000개로 자동 확장(Scale-out)될 수 있지만, 이 앱들이 호출하는 **계정계(메인프레임/유닉스)**는 탄력성이 전혀 없습니다.

  • 추가 설계 지침: PaaS는 **'계정계 보호'**를 최우선으로 설계해야 합니다.
  • 영향:
    - PaaS 앱이 계정계로 보내는 트랜잭션을 제어할 'API 게이트웨이' 또는 **'Service Mesh'**가 필수입니다.
    - 여기에 **Throttling(요청 수 제한)**과 Circuit Breaker(장애 전파 차단) 패턴을 '강제'로 적용해야 합니다.
    - PaaS 앱의 '탄력성'이 '계정계'를 죽이는(Crash) 것을 막기 위해, 스스로의 탄력성을 의도적으로 제한하는 설계가 필요합니다.

 

3. (법률) 규제 준수를 위한 '감사' 및 '데이터 보관'

일반 기업의 '로그'는 장애 분석(Troubleshooting)용입니다. 하지만 금융권의 '로그'는 **금감원 제출을 위한 '법적 증거'**입니다.

  • 추가 설계 지침: PaaS에서 발생하는 모든 로그(K8s 감사 로그, 앱 로그, 네트워크 접근 로그)는 **'위변조가 불가능(Immutable)'**하게 설계되어야 합니다.
  • 영향:
    - 모든 로그를 PaaS 내부가 아닌, 별도의 WORM(Write-Once-Read-Many) 스토리지나 SIEM(보안 정보 이벤트 관리) 시스템으로 강제 전송해야 합니다.
    - 로그는 법규에 따라 최소 5년 이상(또는 그 이상) 보관해야 하므로, PaaS 설계 시 이 대용량 로그의 저장 비용과 아키텍처를 반드시 고려해야 합니다.

 

4. (법률) '데이터 주권(Residency)'과 '프라이빗 클라우드'

PaaS의 '탄력성'은 퍼블릭 클라우드(AWS, GCP)에서 극대화됩니다. 하지만 금융권은 고객의 **'개인정보보호법'**과 **'신용정보법'**에 따라 데이터를 국내에 보관(Data Residency)해야 하며, 중요 데이터는 퍼블릭 클라우드 사용에 제한이 있습니다.

  • 추가 설계 지침: PaaS는 '프라이빗 클라우드(Private Cloud)' (예: OpenStack) 또는 정부의 보안 인증(CSAP)을 받은 '특정 퍼블릭 클라우드 리전(Region)' 내에 구축되어야 합니다.
  • 영향:
    - 퍼블릭 클라우드처럼 '무한한' 탄력성을 누릴 수 없습니다. PaaS의 탄력성은 우리가 보유한 '프라이빗 클라우드의 물리적 용량' 안으로 제한됩니다.
    - Cluster Autoscaler를 설계할 때, "무한정 VM을 생성"하는 것이 아니라, "할당된 데이터센터의 용량(Quota) 내에서만" 확장/축소되도록 설계해야 합니다. **'경계가 있는 탄력성(Bounded Elasticity)'**이 됩니다.

 

5. (환경) '즉각적인 데이터 일관성' 요구

MSA와 PaaS 아키텍처는 '최종 일관성(Eventual Consistency)' (예: EDA/Kafka 사용)을 선호합니다. 하지만 "이체"와 같은 금융 핵심 거래는 '즉각적인 일관성(Immediate Consistency)'이 필수입니다.

  • 추가 설계 지침: PaaS 설계 시, '최종 일관성' 모델과 '즉각적인 일관성'을 위한 '분산 트랜잭션(Distributed Transaction)' 패턴을 함께 지원해야 합니다.
  • 영향:
    - PaaS 위에서 '최종 일관성'을 처리하는 앱(MSA)과, **TCC(Try-Confirm-Cancel)**나 Saga(Orchestration 방식) 등 복잡한 분산 트랜잭션 패턴을 처리하는 앱이 공존하게 됩니다.
    - 이는 PaaS의 아키텍처 복잡도를 높이지만, '돈'과 관련된 데이터 정합성을 보장하기 위한 필수적인 설계입니다