서론: 복잡성에 직면한 글로벌 금융사의 도전
하루 수십억 건의 거래를 처리하는 글로벌 금융사의 인프라는 단순한 기술 스택을 넘어서 비즈니스의 핵심입니다. 산탄데르는 투자은행, 자산관리, 보험 등 다양한 금융 서비스를 확장하면서 200개가 넘는 핵심 시스템을 운영하게 되었고, 이로 인해 전례 없는 기술적 복잡성이 발생했습니다. 가장 큰 문제는 두 가지였죠. 첫째, 새로 프로비저닝되는 서비스가 정해진 아키텍처 정의를 따르도록 보장해야 했고, 둘째, 인프라 구축에 걸리는 시간이 최대 90일이나 되어 막대한 운영 노력이 필요했습니다. 이 문제를 해결한 것은 'Catalyst'라는 혁신적인 플랫폼 엔지니어링 프로젝트였습니다. 이 글은 해당 사례를 통해 얻은 주요 인사이트와 결과를 분석합니다. 자세한 근거자료는 AWS 공식 블로그에서 확인할 수 있습니다.
본론 1: Catalyst 플랫폼의 핵심 아키텍처와 작동 원리
Catalyst는 개발자 포털 형태의 프론트엔드와 Amazon EKS 기반의 컨트롤 플레인 클러스터를 중심으로 설계되었습니다. 복잡한 인프라 프로비저닝을 추상화하고, 아키텍처 준수를 표준화하며, 새로운 기술 도입을 가능하게 하는 프레임워크를 만드는 것이 목표였죠.
주요 구성 요소:
- 통합 개발자 포털: 모든 프로비저닝 및 리소스 관리 요구사항을 위한 단일 인터페이스.
- 컨트롤 플레인 클러스터 (Amazon EKS): 전체 운영을 오케스트레이션하는 '뇌' 역할.
- Crossplane: 멀티 클라우드 리소스를 일관되게 관리하는 범용 프로비저너.
- 데이터 플레인 클레임 (ArgoCD): GitOps 개념을 활용한 애플리케이션 스택의 지속적 동기화 및 배포.
- 정책 카탈로그 (OPA): 모든 운영의 규정 준수와 보안을 보장하는 중앙 정책 저장소.
- 스택 카탈로그: 복잡한 환경을 빠르고 표준화된 방식으로 생성할 수 있는 Composite Resource 정의 라이브러리.
이 아키텍처를 통해 산탄데르는 프로비저닝 시간을 90일에서 몇 시간, 경우에 따라 몇 분으로 획기적으로 단축할 수 있었습니다.
본론 2: 실전 적용 사례와 한국 개발 생태계에서의 시사점
Catalyst는 단순한 인프라 자동화 도구를 넘어 다양한 전략적 워크로드를 구축하는 데 활용되었습니다.
주요 성공 사례:
- 생성형 AI 에이전트 스택: Amazon Bedrock, S3, KMS, 커스텀 IAM 정책을 통합한 완전한 스택을 구축하여 AI 에이전트 구현 시간을 105일에서 24시간으로 단축.
- 모던 데이터 플랫폼: Databricks 통합, 데이터 레이크, 자동화된 ETL 워크플로우를 포함한 플랫폼으로, 데이터 실험 환경 프로비저닝 관련 월 3,000건의 티켓을 대폭 감소.
- 클라우드 프로세스 오케스트레이션: 레거시 워크플로우를 AWS Step Functions로 마이그레이션하고 재시도 패턴을 구현.
한국 개발 생태계에서의 적용 맥락: 국내 많은 기업, 특히 규모가 있는 조직에서도 비슷한 '인프라 구축의 병목'을 경험합니다. SI 프로젝트 환경에서는 각 팀별로 산발적으로 인프라를 관리하다 보니 표준화 부재와 보안 이슈가 발생하기 쉽죠. Catalyst와 같은 플랫폼 엔지니어링 접근법은 이러한 문제를 해결하는 강력한 패러다임입니다. 내부 개발자 포털을 통해 '셀프 서비스' 문화를 정착시키고, Crossplane 같은 도구로 멀티클라우드/하이브리드 클라우드 환경을 일관되게 관리하는 전략은 국내에서도 충분히 적용 가능한 모델입니다. 특히, 마이크로서비스 아키텍처와 팀 독립성을 강조하는 수직형 마이크로프론트엔드(VMFE) 접근법과 플랫폼 엔지니어링은 상호 보완적일 수 있습니다. VMFE가 프론트엔드 팀의 자율성을 높인다면, 플랫폼 엔지니어링은 그 팀들이 필요로 하는 백엔드 인프라를 안전하고 빠르게 제공하는 기반이 되기 때문입니다.
이 접근법의 한계와 주의사항: 초기 설계와 구축에 상당한 시간과 전문성(Platform Engineering, Kubernetes, GitOps 등)이 필요합니다. '만능 해결사'가 아니라 조직의 특정 문제(예: 프로비저닝 시간, 표준화 부재)를 명확히 정의하고 시작해야 합니다. 또한, 강력한 표준화는 일부 유연성을 떨어뜨릴 수 있어, 개발팀의 요구와 플랫폼 팀의 통제 사이에서 적절한 균형을 찾는 것이 중요합니다.
결론: 기술적 문제 해결을 넘어 비즈니스 혁신의 기반으로
Catalyst는 단순한 기술 도구가 아닌, 은행의 클라우드 개발 표준을 재정의하는 디지털 전환의 동력이 되었습니다. 이 플랫폼을 통해 산탄데르는 확장된 환경의 도전 과제를 해결했을 뿐만 아니라 지속적인 혁신과 미래 성장을 위한 견고한 기반을 마련했습니다.
다음 단계 학습 방향 제시: 플랫폼 엔지니어링에 관심이 생겼다면, Crossplane, ArgoCD, Backstage(개발자 포털)와 같은 핵심 도구들의 개념과 간단한 튜토리얼부터 시작해보는 것을 추천합니다. 또한, GPU 프로그래밍의 복잡성을 해결하는 CUB의 새 단일 호출 API와 같은 도메인 특화적 혁신 사례도 함께 살펴보면, '개발자 경험(DX) 개선'이라는 더 큰 그림을 이해하는 데 도움이 될 것입니다.
함께 보면 좋은 글:
이 사례는 플랫폼 엔지니어링이 기술적 문제를 해결하는 것을 넘어 새로운 비즈니스 가능성을 열어주고, 조직 문화까지 변화시킬 수 있는 강력한 도구임을 보여줍니다.