메리츠증권의 AWS 클라우드 여정: 클라우드 기반 차세대 증권 플랫폼 설계

메리츠증권 소개

메리츠증권은 리테일 비즈니스 경쟁력 강화를 목표로, 기존 트레이딩 시스템의 고도화가 아닌 차세대 증권 플랫폼을 새롭게 설계하고 구축했습니다.

차세대 플랫폼은 단순한 증권 트레이딩 시스템을 넘어, 투자자 간의 상호작용과 정보 교류가 이루어지는 커뮤니티 중심 서비스를 함께 제공하는 것을 목표로 했습니다. 이러한 서비스 특성상, 사용자 참여가 확대될수록 트래픽 패턴이 예측하기 어려워지고, 시세 데이터와 커뮤니티 이벤트가 동시에 안정적으로 처리되어야 했습니다.

이러한 요구를 충족하기 위해 AWS 클라우드 네이티브 아키텍처를 기반으로 Amazon Elastic Kubernetes Service(이하 Amazon EKS), Amazon Managed Streaming for Apache Kafka(이하 Amazon MSK), Amazon ElastiCache 등 AWS 관리형 서비스를 결합하여, 추후 확장성과 운영 안정성을 고려한 설계를 완성했습니다.

이 블로그에서는 메리츠증권이 클라우드 기반 차세대 증권 플랫폼을 설계하면서 마주한 도전과제와 이를 해결한 아키텍처 설계 사례를 공유합니다.

도입 배경

메리츠증권은 2025년 사업 다각화 전략의 핵심 과제로 리테일 비즈니스 강화와 디지털 전환 가속을 설정했습니다. 이를 위해 플랫폼 기반 혁신을 전담하는 ‘이노비즈 본부‘를 신설하고, B2C 중심의 신규 서비스 확장을 본격 추진하고 있습니다.

기존 트레이딩 시스템을 클라우드로 마이그레이션하는 것이 아닌, AI와 커뮤니티를 핵심으로 한 차세대 증권 플랫폼을 신규로 구축하는 전략을 선택한 데에는 크게 세 가지 이유가 있었습니다.

첫째, 극단적인 트래픽 변동성에 대한 대응입니다.

증권 거래 시스템은 장 시작과 마감 시점에 평상시 대비 수십 배의 트래픽이 순간적으로 집중됩니다. 온프레미스 환경에서는 최대 트래픽을 기준으로 인프라를 상시 확보해야 했지만, AWS의 탄력적 확장 구조를 통해 필요 시점에만 리소스를 확장함으로써 안정성과 비용 효율성을 동시에 확보할 수 있었습니다.

둘째, 빠른 서비스 출시와 지속적인 개선입니다.

클라우드 네이티브 아키텍처와 AWS 관리형 서비스를 활용함으로써 인프라 구축과 운영 부담을 줄이고, 서비스 기획과 개발에 집중할 수 있는 환경을 마련했습니다. 또한 오픈소스 기반 기술 스택을 통해 전문 인력 확보와 조직 확장 측면에서도 유연성을 확보했습니다.

셋째, AI 기반 서비스 확장에 대한 준비입니다.

생성형 AI를 포함한 지능형 투자 서비스 확장을 고려할 때, Amazon Bedrock을 비롯한 AWS AI/ML 서비스 포트폴리오를 활용해 최신 기술을 빠르게 검증하고 적용할 수 있는 클라우드 환경은 필수적인 선택이었습니다.

다만, 금융 산업에서 클라우드 네이티브 증권 플랫폼을 신규로 구축하는 것은 기술적 선택을 넘어 규제 준수, 보안, 안정성을 함께 고려해야 하는 과제였습니다. 다음 장에서는 메리츠증권이 이러한 조건을 충족하기 위해 직면했던 핵심 도전과제를 살펴봅니다.

Well-Architected Design Workshop

아키텍처 설계에 앞서, 메리츠증권은 AWS와 함께 Well-Architected Design Workshop을 진행했습니다.

메리츠증권 이노비즈 본부, IT 본부, 정보보호본부와 AWS ProServe, AWS Solutions Architect, 파트너가 함께 참여하여, 메리츠증권이 구성한 워크로드가 AWS 환경과 금융 컴플라이언스 규제에 부합하는지 아키텍처 리뷰를 진행했습니다.

이 과정에서 보안, 안정성, 성능 효율성, 비용 최적화, 운영 우수성 관점의 개선 사항을 도출하고 아키텍처에 반영했습니다.

Figure 1. 서비스 아키텍처 디자인

클라우드에서 증권 플랫폼 구성을 위한 도전 과제

메리츠증권이 클라우드 기반 차세대 증권 플랫폼을 설계하면서 마주한 핵심 도전과제는 크게 세 가지였습니다.

도전과제 1: 금융 규제 준수와 하이브리드 클라우드

금융권 클라우드 도입에서 가장 먼저 해결해야 할 과제는 전자금융감독규정 준수입니다. 이 규정은 외부 인터넷과 내부 시스템 간 명확한 네트워크 격리, 침입 탐지 및 차단, 모든 접근에 대한 감사 추적을 요구합니다.

• DR(재해복구) 요건: 금융 서비스 연속성을 보장하기 위한 RTO 요건을 클라우드 환경에서 충족해야 했습니다.
• 연구개발망 분리: 전자금융감독규정상 내부망과 분리된 환경에서 AI 및 오픈소스 기술을 자유롭게 실험할 수 있어야 했습니다.
• 규제 vs 성능 트레이드오프: 전통적인 중앙 집중형 방화벽은 규제를 준수하지만, 모든 트래픽이 단일 지점을 경유하면서 레이턴시 증가와 병목이 발생합니다. 규제를 준수하면서도 성능 저하를 최소화하는 아키텍처가 필요했습니다.
• 하이브리드 연동: 코어 시스템(계정계)은 IDC에 위치하므로, AWS와 IDC 간 안정적이고 고가용성을 갖춘 네트워크 연결이 필수적이었습니다.

도전과제 2: 실시간 데이터 처리와 네트워크 성능

차세대 증권 플랫폼은 시세 데이터와 커뮤니티 콘텐츠, 두 축의 실시간 데이터를 동시에 처리해야 합니다. 장중에는 수천 개 종목의 가격/호가 정보가 초당 수만 건씩 쏟아지고, 투자자 커뮤니티에서도 피드/좋아요/댓글 등 대량 이벤트가 끊임없이 발생합니다. 이 두 가지 성격이 다른 실시간 트래픽을 지연 없이 전달하는 것이 핵심 과제였습니다.

• 시세 데이터: IDC 코어망에서 발생하는 가격시세 데이터를 AWS 환경의 사용자에게 밀리초 단위로 전달해야 했습니다.
• 커뮤니티 컨텐츠 피드: 투자자 커뮤니티의 피드, 좋아요, 댓글 등 대용량 이벤트를 실시간으로 처리하고 랭킹검색 기능을 제공해야 했습니다.

도전과제 3: 현대화 아키텍처와 클라우드 네이티브

빠른 서비스 출시와 지속적 혁신을 위해 클라우드 네이티브 아키텍처가 필요했습니다.

• 탄력적 확장: 극단적인 트래픽 변동성에 대응하는 자동 확장/축소
• DevOps: IaC 기반 인프라 관리와 CI/CD 자동화로 빠른 배포 사이클 확보
• Observability: 오픈소스 기반의 주요 지표 모니터링
• 오픈소스 기반: 벤더 종속 방지, 전문 인력 확보 용이성, 커뮤니티 생태계 활용

이러한 도전과제들을 해결하기 위해 메리츠증권이 설계한 아키텍처를 도전과제별로 살펴보겠습니다.

도전과제 1 아키텍처: 금융 규제 준수와 하이브리드 클라우드

계정 디자인

메리츠증권은 AWS 멀티 계정 전략을 채택하여 OU 기반으로 계정을 목적별로 분리하고, 환경별 격리와 보안을 확보했습니다.

핵심 설계 원칙:

• 환경별 계정 격리: 개발/스테이징/프로덕션을 계정 레벨에서 완전 분리하여 운영 환경의 안정성 확보
• 연구개발망 분리: 전자금융감독규정에 따라 내부망과 분리된 R&D 계정을 구성하여 AI 및 오픈소스 기술을 자유롭게 실험할 수 있는 환경 확보
• SCP 기반 가드레일: Service Control Policy를 통해 계정별 허용 서비스와 리전을 제한하고, 조직 차원의 보안 정책을 일괄 적용
• 보안 중앙화: Security OU에서 전 계정의 감사 로그를 중앙 집중 관리하여 규제 준수

네트워크 디자인

Distributed Firewall: 규제 준수와 성능의 양립

전통적인 중앙 집중형 방화벽 대신, AWS Gateway Load Balancer(GWLB)와 써드파티 방화벽을 활용한 분산 방화벽(Distributed Firewall) 아키텍처를 설계했습니다.

왜 Distributed Firewall인가?

Figure 2. Distributed Firewall 구성

다층 보안 구성:

• 1단계 (외부 위협 차단): GWLB 기반 써드파티 WAF/방화벽(DMZ)
• 2단계 (내부망 보호): DMZ-내부망 간 2차 방화벽, 주문 흐름과 시세 데이터 흐름의 네트워크 레벨 격리

하이브리드 연결: Direct Connect 이중화

코어망(계정계)이 IDC에 위치하므로, AWS와 IDC 간 안정적 연결이 서비스 품질을 직접 좌우합니다. AWS Direct Connect 이중화를 구성하여 단일 장애점(SPOF)을 제거하고, VPN 대비 안정적인 레이턴시와 높은 대역폭을 확보했습니다.

AWS Transit Gateway(TGW)를 중심으로 멀티 계정 간 네트워크를 허브-스포크 구조로 연결하고, Direct Connect 1Gbps × 2 이중화를 통해 IDC와의 안정적 연결을 확보했습니다.

Figure 3.  AWS Direct Connect 전용선 구성

전자금융감독규정에 따라 서울 리전 단일 리전으로 운영하며, Multi-AZ 기반의 재해복구 체계를 설계했습니다. Amazon EKS, Amazon Aurora, Amazon MSK등 핵심 서비스를 Multi-AZ로 배포하여 가용영역 장애 시 자동 페일오버가 가능합니다.

• RTO: 3시간 (핵심업무 기준 3시간 이내)
• RPO: 서버, 스토리지, 데이터베이스 등에 따라 차등 기준 적용

보안: 데이터 흐름 분리와 감사 체계

증권 거래 시스템의 두 가지 데이터 흐름을 보안 수준에 따라 분리했습니다.

• 시세 데이터: GWLB 기반 방화벽 룰 검사 적용, Broadcast 트래픽 예외 처리 정책 수립, Security Group 기반 접근 제어
• 주문 흐름: API parameter, payload 및 필드 레벨 암호화, 네트워크 격리, IAM Role 기반 최소 권한 원칙 적용

감사 및 규제 준수

• AWS CloudTrail: 전 계정의 모든 API 호출 감사 로그를 Security Account에 중앙 집중 저장
• VPC Flow Logs: 네트워크 트래픽 로그 수집
• AWS Config: 리소스 구성 변경 이력 추적

성과

• 전자금융감독규정 충족: GWLB 기반 Distributed Firewall, 데이터 흐름 분리, CloudTrail/VPC Flow Logs/AWS Config 기반 감사 체계로 네트워크 격리침입 탐지·감사 추적 요건을 클라우드 네이티브 방식으로 충족
• DR 요건 달성: 서울 리전 단일 리전 내 Multi-AZ 배포와 Direct Connect 1Gbps 이중화로 RTO 3시간 요건 충족. RPO는 서버, 스토리지, 데이터베이스 등에 따라 차등 기준 적용
• 클라우드 서비스 이용보고 기반 확보: 이용보고에 필요한 자료를 체계적으로 관리할 수 있는 기반 확보
• 연구개발망 구성: 내부망과 분리된 R&D 계정에서 AI/오픈소스 기술을 자유롭게 실험하고, 검증 완료된 기술만 운영 환경에 반영하는 프로세스 확립

도전과제 2 아키텍처: 실시간 데이터 처리와 네트워크 성능

데이터 인프라: Amazon MSK기반 실시간 스트리밍

왜 Amazon MSK(Managed Streaming for Apache Kafka)인가?

TGW 기반 멀티캐스팅 대신 Amazon MSK를 선택했습니다. 메리츠증권은 시세 데이터뿐 아니라 커뮤니티 이벤트, 알림 등 다양한 도메인의 실시간 데이터를 처리해야 했습니다. Kafka의 Consumer Group 기반 멀티캐스팅 모델은 동일한 데이터를 Amazon ElastiCache(실시간 조회), Amazon Aurora(영구 저장), Amazon OpenSearch(검색) 등 여러 목적지로 동시에 전달하는 데 적합합니다. 또한 도메인별로 클러스터를 분리하여 보안·성능·운영을 독립적으로 관리할 수 있고, MSK가 완전 관리형으로 클러스터 운영 부담을

줄여준다는 점도 고려했습니다. Kafka 4.1.x의 KRaft 모드를 채택하여 Zookeeper 의존성을 완전히 제거했으며, 이를 통해 클러스터 구성이 단순해지고 메타데이터 관리 성능이 향상되었습니다.

도메인별 클러스터 분리:

데이터 특성과 네트워크 요건에 따라 MSK 클러스터를 분리 운영합니다.

Figure 4. MSK를 통한 내부 이벤트 관리

Quote 클러스터는 IDC 기간계에서 유입되는 시세 데이터를 처리하며 DMZ 서브넷에 배치하여 외부 연동에 최적화했고, Common 클러스터는 커뮤니티·알림 등 서비스 내부 이벤트를 처리하며 DB 서브넷에서 내부 트래픽만 수용합니다.

ElastiCache (Valkey) — 초저지연 시세 조회:

왜 Valkey인가? 시세 데이터의 실시간 조회를 위해 ElastiCache(Valkey 호환)를 선택했습니다. Valkey는 Redis 호환 오픈소스 인메모리 데이터 스토어로, 마이크로초 단위 응답 성능을 제공하면서도 오픈소스 라이선스 기반으로 벤더 종속 없이 활용할 수 있습니다.

실시간 시세 브로드캐스팅에는 Sharded Pub/Sub을 활용합니다. 기존 Pub/Sub은 클러스터 모드에서 메시지를 모든 노드에 브로드캐스트하여 클러스터 리소스 사용량이 급증하는 문제가 있었습니다.

Sharded Pub/Sub은 메시지 전파 범위를 해당 샤드 내로 제한하여 노드 간 불필요한 브로드캐스트 부하를 제거하고, 고처리량 Pub/Sub 워크로드에서도 안정적인 성능을 유지합니다.

이를 통해 11,000개 이상의 종목 시세를 초당 30,000건 이상 처리하면서도 소스에서 WebSocket 세션까지 1ms 이내의 전달 지연을 달성했습니다.

Amazon OpenSearch — 검색 및 분석:

개인화 된 사용자의 피드 목록을 조회하고, 다양한 컨텐츠의 자동완성과 통합 검색을 제공하기 위해 OpenSearch를 활용합니다.

커뮤니티 서비스에서는 Kafka(MSK)를 이용하여 국내/외 사용자가 작성한 게시글을 준실시간으로 OpenSearch에 저장하고 필터하여 피드 목록을 제공합니다.

효울적인 조회 성능을 위하여 최근 게시글을 Hot Node에 저장하며, 자주 조회되지 않는 오래된 게시글은 Warm, Cold Node에 저장하도록 구성하였습니다.

게시글 이외의 종목/회원/채널/테마/뉴스 데이터도 함께 저장하여 자동완성 검색/통합 검색 결과를 제공하며, analysis-nori 형태소 분석기를 사용하여 한글 검색 및 초성 검색 기능을 제공합니다.

향후 AI 서비스 확장 시 벡터 검색(RAG) 기반으로도 활용할 수 있어 장기적 확장성을 고려한 선택이었습니다.

Amazon Managed Service for Apache Flink:

실시간 스트림 데이터의 변환, 집계 등 복잡한 스트림 처리에 Flink를 활용합니다. 시세/거래 도메인과 커뮤니티 도메인에 각각 독립적인 Flink 애플리케이션을 운영하고 있습니다.

시세 영역에서는 Kafka로 유입되는 Tick Data를 스트림 단위로 즉시 처리하여, 장중 가격 변동 알림(시가 대비 5% 이상 상승/하락), 52주 최고/최저가 경신 알림, 거래량 급증/급감 알림 등을 밀리초 단위 지연으로 생성합니다. 커뮤니티 영역에서는 페이지뷰 이벤트를 실시간으로 집계하여 채널/종목/ETF별 실시간 랭킹을 생성합니다.

틱 데이터(Tick Data)는 증권 거래소에서 발생하는 개별 거래 또는 호가 변동 하나하나를 시간순으로 기록한 가장 세밀한 단위의 시장 데이터입니다.

Flink의 Stateful Stream Processing으로 이전 시세와 현재 시세를 외부 저장소 없이 메모리 내에서 안전하게 비교하고, Exactly-once 시맨틱으로 장애 복구 시에도 중복 이벤트 없이 정확히 한 번만 알림을 발행합니다.

Event-time 기반 처리로 네트워크 지연이나 out-of-order 데이터가 유입되어도 올바른 시간 순서로 분석하며, 시간 기반 윈도우로 “1분 평균 가격”, “5분 내 최고가” 같은 복잡한 시계열 집계를 선언적으로 구성합니다.

Checkpoint와 Savepoint를 통해 장애 발생 시에도 정확한 시점에서 스트림 처리를 재개할 수 있어, 증권 거래처럼 데이터 정합성이 중요한 도메인에 적합합니다.

이 외에도 실시간 포트폴리오 손익 계산, 이상 거래 탐지 등 장 중 복잡한 실시간 연산이 필요한 다양한 도메인에서 Flink 기반 스트림 처리를 확대 적용하고 있습니다.

커뮤니티 플랫폼: 이벤트 드리븐 아키텍처

• Amazon MSK: 완전관리형 Apache Kafka로 이벤트, 스트리밍 데이터에 대한 처리
• Aurora: 피드, 댓글, 좋아요 등 트랜잭션 데이터 저장. Read Replica를 활용한 읽기/쓰기 분리
• OpenSearch: 피드/컨텐츠/뉴스 전문 검색, 종목별 토론 검색, 인기 콘텐츠 랭킹, 유저피드 구성
• S3 Data Lake: 원본 데이터 장기 보관, 분석용 가공 데이터 저장

배치 및 데이터 파이프라인

• Amazon MWAA (Managed Airflow): 일일 시세 집계, 주간 커뮤니티 랭킹, 정산 배치 등 워크플로 오케스트레이션
• AWS Transfer Family: IDC와의 파일 기반 데이터 연동에 활용

성과

• 레이턴시 최소화: 중앙 집중형 방화벽에서 GWLB Endpoint 분산 구성으로 전환하여 네트워크 홉 최소화
• 시세 데이터 팬아웃: MSK Quote 클러스터를 통해 IDC 기간계 시세 데이터를 다수의 Consumer Group(ElastiCache, Flink 등)이 독립적으로 소비하는 구조로, 단일 소스에서 다양한 처리 파이프라인으로 분기
• 초저지연 조회: Amazon ElastiCache(Valkey) 기반 마이크로초 단위 시세 조회 및 WebSocket 실시간 푸시. 사내 시세 전용 MSK 구축 및 클라우드 상에서 운영되는 시세 이벤트 컨슈머 TPS 30,000에서도 1μs 이하를 유지.

도전과제 3 아키텍처: 현대화 아키텍처와 클라우드 네이티브

이노비즈 본부의 핵심 인력은 네이버, 카카오, 토스 등 Digital Native 기업 출신으로 Kubernetes, Kafka, Prometheus 등 오픈소스 기반 기술 스택에 풍부한 경험을 보유하고 있습니다. 이를 기반으로 빠른 조직 구성과 전문 인력 확보가 가능했으며, 오픈소스 중심의 클라우드 네이티브 아키텍처를 자연스럽게 채택할 수 있었습니다.

Amazon EKS 기반 컨테이너 플랫폼

왜 Amazon EKS인가?

Kubernetes의 풍부한 오픈소스 생태계(Prometheus, Grafana, ArgoCD 등)를 활용할 수 있고, 벤더 종속 없이 표준화된 컨테이너 오케스트레이션 환경을 구성할 수 있다는 점이 결정적이었습니다. 또한 연구개발망에서 빠르게 서비스를 구성하고, 이를 내부망 개발 환경과 거의 동일한 환경에서 다양한 테스트가 가능하여 서비스 구성과 검증 속도가 크게 향상되었습니다.

Auto Scaling 전략:

• HPA (Horizontal Pod Autoscaler): CPU/메모리 및 Custom Metrics(Kafka Consumer Lag, API 응답시간) 기반 Pod 자동 확장
• EKS Auto Mode: 노드 레벨 자동 확장, 워크로드에 최적화된 인스턴스 타입 자동 선택 및 클러스터 운영 자동화

부하 테스트 기반 Auto Scaling 검증 결과:

약 98,000명 동시 접속, 최대 28,800 req/sec 부하 조건에서의 Auto Scaling 동작을 검증했습니다.

테스트 결과를 기반으로 HPA 임계값 조정, Connection Pool 최적화, PodDisruptionBudget 적용 등 안정적인 서비스 운영을 위한 스케일링 정책을 수립했습니다.

프론트엔드: 하이브리드 배포

React + Next.js 기반으로 정적 자산과 동적 콘텐츠를 분리 배포합니다.

MSA와 API Gateway

다수의 도메인 서비스를 독립적으로 개발·배포하는 마이크로서비스 아키텍처를 채택하고, Spring Cloud Gateway를 단일 진입점으로 구성하여 서비스 간 오케스트레이션과 공통 정책을 중앙에서 관리합니다.

Figure 5. API Gateway 디자인 패턴

API Gateway의 역할:

• 인증/인가 오프로딩: JWT(App)·Cookie(Web) 등 클라이언트별 상이한 인증 방식을 게이트웨이에서 통합 처리하여 개별 서비스의 인증 중복 제거
• 트래픽 제어: Rate Limit, Circuit Breaker, Retry 정책을 게이트웨이 레벨에서 일원화
• 관측성 전파: OpenTelemetry 기반 Trace/Span을 게이트웨이에서 시작하여 downstream 서비스까지 전파, Audit 로그 중앙 적재
• 단일 진입점: 프론트엔드는 하나의 엔드포인트로만 통신하므로 CORS 정책 단순화 및 API 호출 로직 간소화

MSA 서비스 구성:

DevOps: Terraform + GitLab CI/CD

Figure 6. Terraform + Gitlab  CI/CD 구성

• Terraform: 모든 인프라를 코드로 관리(IaC). EKS 클러스터, 네트워크, 보안 그룹 등 환경별 동일한 인프라를 재현 가능하게 구성
• GitLab CI/CD: Merge Request 기반 파이프라인으로 Build, Test, 컨테이너 이미지 빌드(Jib) 및 ECR Push를 자동화. 브랜치별(dev/stage/release) 환경 분기 배포이며, stage·production 환경은 전자금융감독규정에 따른 내부통제 요건을 충족하기 위해 GitLab Approval 기반 배포 승인 절차 적용
• ArgoCD (GitOps): Manifest 프로젝트의 이미지 태그 변경을 감지하여 EKS에 자동 배포. 선언적 배포 상태 관리로 배포 이력 추적 및 롤백 용이
• 무중단 배포: 변경 내용에 적합한 배포 전략을 수립하고 배포 (예: Blue/Green, Canary,Rolling Update)

Observability: 오픈소스 기반 통합 모니터링

Grafana Labs 생태계를 중심으로 메트릭, 로그, 트레이스를 통합하고, AWS 네이티브 서비스와 결합하여 규제 준수와 운영 가시성을 동시에 확보했습니다.

모니터링 스택 구성

Grafana Labs 생태계(Prometheus + Mimir + Loki + Tempo + Grafana)를 중심으로 구성한 이유는 다음과 같습니다.

• 통합 가시성: 메트릭(Mimir), 로그(Loki), 트레이스(Tempo)를 Grafana 단일 대시보드에서 상관 분석 가능
• OpenTelemetry 표준: 벤더 중립적인 계측 표준을 채택하여 향후 모니터링 백엔드 교체 시에도 애플리케이션 코드 변경 불필요
• 오픈소스 인력 확보: Prometheus, Grafana 등 널리 사용되는 오픈소스 기반으로 관련 경험을 가진 인력 확보가 수월

주요 모니터링 메트릭:

• 시세 스트림 처리량 (TPS) 및 Kafka Consumer Lag (임계값 초과 시 자동 알림 및 HPA 트리거)
• API Gateway 초당 요청 수 (RPS), 응답 시간 (P50, P95), 에러율 및 Circuit Breaker 상태
• 외부 게이트웨이 트래픽 (Route별 요청 수, 성공/실패율, HTTP Status Code 분포)
• JVM 힙 메모리, GC Pressure, 스레드 상태 등 애플리케이션 레벨 APM
• HPA 스케일링 현황 (현재/최소/최대 Replica, Target Metric 달성률)
• Pod 리소스 사용률 (CPU, Memory), 컨테이너 네트워크 I/O
• MSK 클러스터 헬스 (Broker 상태, Partition/Leader Count, Disk 사용률)

성과

• 비용 효율적 운영: EKS Auto Scaling(HPA + EKS Auto Mode)으로 트래픽에 연동한 리소스 자동 확장/축소를 구현하여, 피크 시간과 유휴 시간에 따라 인프라 비용이 탄력적으로 관리되는 구조 확보
• 빠른 배포: Terraform + GitLab CI/CD 기반 자동화로 내부통제 요건을 만족하며 배포 사이클 단축
• 통합 Observability: Grafana Labs 생태계(Prometheus, Mimir, Loki, Tempo) + OpenTelemetry + CloudWatch로 하이브리드 환경 전체의 메트릭로그·트레이스 통합 가시성 확보
• 빠른 조직 구성: Kubernetes, Kafka, Prometheus, Grafana 등 오픈소스 기반 기술 스택으로 구성하여 전문 인력 채용과 조직 구성이 수월
• 확장 용이성: 표준화된 오픈소스 생태계 위에 구축하여 새로운 기능 추가와 기술 확장이 용이하고, 벤더 종속 방지

향후 계획

메리츠증권의 클라우드 기반 차세대 증권 플랫폼은 2026년 상반기 서비스 출시를 목표로 준비 중입니다.

AI 서비스

AWS GenAI Innovation Center(GenAI IC)와 8주간 협력하여 생성형 AI 기반 서비스의 프로토타이핑을 완료했습니다. Amazon Bedrock 기반 Agentic AI 아키텍처를 활용한 자연어 종목 스크리닝 및 금융 Q&A 시스템을 설계·검증했으며, 향후 커뮤니티 플랫폼과 통합하여 출시할 예정입니다.

• 기술 기반: Amazon Bedrock (Foundation Model), Amazon OpenSearch (벡터 검색), Aurora (금융 데이터)
• 아키텍처: 복수의 전문화된 AI 에이전트가 협력하는 Agentic AI 방식
• 규제 준수: 투자 권유 차단, 면책 조항 자동 추가 등 금융 규제 준수 메커니즘 내장

AI Gateway 검토

향후 AI 서비스 확장에 맞춰 AI Gateway 구성을 검토 중입니다. LLM 호출 라우팅, 토큰 사용량 관리, 모델별 트래픽 제어 등을 중앙에서 관리하는 아키텍처를 고려하고 있습니다.

결론

메리츠증권의 AWS 클라우드 여정은 금융권에서 클라우드 네이티브 기반의 현대화된 채널계를 구축한 모범 사례입니다. 전자금융감독규정을 준수하는 하이브리드 클라우드 아키텍처 위에 Amazon EKS, Amazon MSK, Amazon ElastiCache 등 관리형 서비스와 Prometheus, Grafana, Kafka 등 오픈소스 기술을 결합하여, 실시간 시세 처리와 탄력적 확장이 가능한 플랫폼을 설계했습니다.

오픈소스 기반의 기술 스택은 빠른 인력 확보와 조직 구성을 가능하게 했고, AWS의 관리형 서비스는 인프라 운영 부담을 줄여 서비스 개발에 집중할 수 있는 환경을 제공했습니다. 또한 AWS GenAI Innovation Center와의 협력을 통해 생성형 AI 기반 서비스 확장의 기반을 마련했습니다. 이 사례가 클라우드 기반 금융 서비스 구축을 고려하는 기업들에게 실질적인 참고가 되기를 바랍니다.

저자 소개