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

'탄력성'과 '장애 격리'라는 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의 아키텍처 복잡도를 높이지만, '돈'과 관련된 데이터 정합성을 보장하기 위한 필수적인 설계입니다