# 대규모 시스템 전환과 분리 전략 사례 > Clean Markdown view of GeekNews topic #20871. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=20871](https://news.hada.io/topic?id=20871) - GeekNews Markdown: [https://news.hada.io/topic/20871.md](https://news.hada.io/topic/20871.md) - Type: news - Author: [baeba](https://news.hada.io/@baeba) - Published: 2025-05-13T10:00:11+09:00 - Updated: 2025-05-13T10:00:11+09:00 - Original source: [infoq.com](https://www.infoq.com/articles/architecting-real-time-systems-around-mainframe/) - Points: 9 - Comments: 1 ## Summary 점진적 **분리 전략**을 통해 기존 시스템을 점검하면서 **메인프레임 직접 접근** 대신 **CDC 기반 실시간 데이터 시스템**을 도입하였습니다. **GraphQL 도입**으로 복잡한 **BFF 계층**을 제거하고 **도메인 중심 팀 구조**로 혁신적 팀 책임 분리를 구현하였습니다. **이벤트 기반 아키텍처**와 **릴리스 트레인**을 통해 안정적 가치 전달과 시스템 확장을 지원하였습니다. 하이브리드 방식으로 **UWP 1.0/2.0**을 병행하며 프런트엔드와 백엔드의 완전 분리를 달성하였습니다. ## Topic Body ##### Key Takeaways * 기존 시스템을 전면 교체하지 않고도 점진적 분리로 전환을 이끌어냈다. * CDC 기반 실시간 데이터 시스템으로 메인프레임 직접 접근을 대체했다. * REST 대신 GraphQL로 BFF 계층 다수를 제거하고 유연성과 유지보수성을 확보했다. * 도메인 중심 팀 구조(Team Topologies)로 팀의 책임과 소유권을 명확히 했다. * 점진적 배포와 자동화를 통해 위험 없이 시스템을 전환하고 안정적으로 가치를 전달했다. --- ##### 도입 사례: 장애 중에도 살아남은 절반의 시스템 메인프레임 장애가 발생했지만, 클라우드 기반 스트리밍 아키텍처 덕분에 새 UI는 정상 동작했다. 기존 시스템이 다운되어도 신규 시스템은 고객 경험을 유지하며 복원력을 입증했다. --- ##### 핵심 전략: 다층 분리 (Decoupling) 1. **도메인 주도 설계(DDD)**: 메인프레임 중심 모델을 비즈니스 친화적으로 재구성 2. **Team Topologies**: 기능 중심 팀 조직으로 전환 3. **이벤트 기반 아키텍처**: 비동기 방식으로 시스템 간 결합도 완화 4. **Change Data Capture(CDC)**: 실시간 데이터 변화를 감지하여 레거시와 신 시스템 연결 --- ##### 이전 구조: Unified Web Portal 1.0 다양한 메인프레임 데이터를 ETL로 통합하여 SQL DB와 SaaS로 제공했으나, 실시간성 부족, 데이터 품질 저하, 직접 메인프레임 호출 등의 문제 발생. --- ##### 문제점 * ETL로 인한 데이터 지연 * 탄력적이지 못한 메인프레임과의 동기 연결 * 무수히 많은 BFF API 생성 * 조직 구조에 따른 병목과 릴리스 지연 * 급증 트래픽 시 메인프레임 과부하로 서비스 전체 장애 발생 --- ##### 새로운 목표 설정 기술적 목표: 메인프레임과 웹 분리, BFF 제거, 팀 자율성 확보 비즈니스 목표: 콜센터 문의 감소, 라이선스 비용 절감, 고객 만족 향상 --- ##### 새로운 아키텍처 개요 * 메인프레임은 여전히 시스템 오브 레코드 * CDC → Kafka → 도메인 DB (CosmosDB) * GraphQL + REST API → BFF → UI * 이벤트 기반 구조와 메시지 브로커로 모든 컴포넌트 연결 --- ##### Step 1: Change Data Capture * 실시간 데이터 스트리밍으로 시스템 오브 레퍼런스 구성 * 메인프레임 → Kafka → 변환 → 도메인 DB → API로 제공 * 메인프레임 스키마에 종속되지 않는 유연한 데이터 구조 확보 --- ##### Step 2: Domain-Driven Design + GraphQL * DDD로 도메인 모델 정의 (Entity, Command, Event) * 각 도메인을 GraphQL 노드로 구성, schema stitching을 통한 supergraph 생성 * 필요한 데이터만 조회하는 최적 쿼리 구조 지원 --- ##### 조직 구조 변화: Team Topologies * 기능 중심의 스트림 얼라인드 팀으로 재편성 * 복잡한 영역(예: 메인프레임 통합)은 전담 팀이 관리 * 기술 지원을 위한 Enablement 팀 운영 --- ##### 이벤트 기반 확장: 내부 도메인 이벤트 + 사가 패턴 * Outbox 패턴으로 도메인 변경 시 이벤트 발생 * Parallel Saga로 메인프레임 작업과 CDC 동기화 * 상태 머신 기반 워크플로우 구성 → 복합 플로우에도 대응 --- ##### 도전 과제 * 이벤트 기반 구조 도입에 대한 조직 내 인식 변화 필요 * 비동기 구조로 인한 관측 가능성 확보가 필수 * 메인프레임 배치 작업 → CDC 파이프라인 과부하 유발 * GraphQL schema 관리의 복잡성 및 federated approach 도입 고민 * 인증/로깅 등 공통 관심사는 별도 패키지 및 자동화로 관리 --- ##### 릴리스 전략: 릴리스 트레인 + Feature Flag * 각 팀은 독립 배포, 배포 리포지토리에서 통합 * Kustomize로 환경별 배포 파이프라인 구성 * 기능 플래그로 기능/보안 릴리스를 분리, trunk-based 개발 유지 --- ##### 하이브리드 아키텍처 적용 * UWP 1.0과 UWP 2.0을 공존시키며 점진적 전환 수행 * 에지 라우팅으로 유저 요청을 새로운 시스템으로 순차 전환 --- ##### 결론: 진화 가능한 플랫폼 구축 * 프런트엔드와 메인프레임 완전 분리 * 팀 중심 구조로 속도와 안정성 확보 * 고객 만족도 및 운영 비용 개선 * 향후 메인프레임 교체까지도 가능하게 만든 유연한 기반 확보 ## Comments ### Comment 38598 - Author: mhj5730 - Created: 2025-05-13T16:27:02+09:00 - Points: 1 점진전 개선 점진적 마이크로서비스 추출이 매우 중요한데...이런 글 보면 해당 프로젝트를 이끄는 PM이 정말 중요하고 대단하구나를 느낍니다. 이 많은것을 관리한다는게 ㄷㄷ