애플리케이션 현대화
레거시 모놀리스를 유지 보수하기 쉬운 플랫폼으로 교체
작업은 평가로 시작합니다. 코드와 데이터베이스를 검토하고, 의존성을 도식화하며, 어떤 기능을 누가 얼마나 자주 사용하는지 분석합니다. 이를 바탕으로 구성 요소를 비즈니스 가치와 위험도에 따라 순위를 매긴 현대화 계획을 수립하여, 첫 릴리스에서 가치가 가장 높은 구성 요소부터 다룹니다.
마이그레이션은 스트랭글러 피그(strangler-fig) 패턴을 따릅니다. Spring Boot와 Next.js로 구축한 새 서비스가 라우팅 계층 뒤에서 한 번에 하나의 기능씩 넘겨받고, 기존 시스템은 나머지 기능을 계속 제공합니다. 사용자는 전 과정에서 하나의 애플리케이션으로 작업하며, 대체 구성 요소가 운영 환경에서 검증될 때까지는 어떤 구성 요소도 중단하지 않습니다.
코드는 건전하고 플랫폼만 노후한 경우에는 대신 애플리케이션을 리플랫폼합니다. 애플리케이션을 컨테이너화하여 AWS ECS로 이전하고, 독점 미들웨어를 교체하며, 데이터베이스를 지원되는 버전의 PostgreSQL로 전환합니다.
- 우선순위가 정해진 현대화 로드맵을 포함한 평가
- API 게이트웨이 또는 리버스 프록시 뒤에서의 스트랭글러 피그 마이그레이션
- Java EE 및 기타 JVM 애플리케이션을 Spring Boot와 컨테이너로 리플랫폼
- 전환 시마다 대사 보고서를 제공하는 데이터 마이그레이션
클라우드 마이그레이션
웨이브마다 롤백 경로를 갖춘 단계적 AWS 마이그레이션
마이그레이션은 서버를 복사하는 것 이상의 작업입니다. 당사는 계정 구조, 네트워킹, 보안을 먼저 구축한 다음, 각각 롤백 경로를 갖춘 웨이브 단위로 워크로드를 이전합니다.
랜딩 존부터
귀사의 네트워크 및 컴플라이언스 요건에 맞는 계정 구조에서 시작하십시오. 운영 환경과 비운영 환경을 분리한 AWS Organizations 계정, 중앙 집중식 로깅, 공유 키 대신 IAM 역할, 그리고 요건에 맞는 VPC 설계를 갖춥니다. 전체 구성은 Terraform으로 정의하고 검토하며 버전을 관리합니다.
마이그레이션 웨이브
다운타임은 합의된 시간대 안에서만 발생합니다. 워크로드를 의존성에 따라 묶어 중요도가 가장 낮은 것부터 웨이브 단위로 이전하며, 각 웨이브에는 테스트 계획, 전환 시간대, 롤백 절차가 있습니다. 데이터베이스는 복제 방식으로 이전합니다.
워크로드별 최적의 대상
애플리케이션 서비스는 ECS의 컨테이너에서, 데이터베이스는 관리형 PostgreSQL에서, 이벤트 기반 작업은 서버리스 함수에서 실행합니다. 리프트 앤 시프트는 재작성이 아직 타당하지 않은 경우에만 사용하며, 각 선택의 근거는 문서로 남깁니다.
모든 웨이브에 적용되는 보안
데이터는 이전되는 동안에도 보호됩니다. 저장 시 및 전송 중 암호화, 관리형 저장소의 시크릿, 최소 권한 역할, 그리고 TLS·WAF·DDoS 방어를 위한 엣지의 Cloudflare가 모든 웨이브에 적용됩니다. 각 웨이브에는 보안 검토가 포함됩니다.
비용 가시성
태깅 표준과 예산을 통해 모든 환경과 팀이 처음부터 자체 지출을 확인할 수 있습니다. 마이그레이션 후에는 실제 사용량이 파악되는 시점에 적정 규모 조정과 예약 용량을 검토합니다.
인계 또는 운영 대행
귀사 팀이 환경 운영에 필요한 Terraform 코드, 런북, 교육을 받거나, 운영 대행 계약에 따라 InterCloud가 계속 운영합니다.
시스템 연동
시스템 간 수기 재입력을 대체하는 연동
기업은 ERP, 인사, CRM, 이커머스와 수많은 부서별 도구를 운영하며, 직원들은 이들 사이에서 데이터를 다시 입력하는 경우가 많습니다. 당사는 이러한 수작업 전송을 문서화되고 모니터링되며 귀사가 소유하는 연동으로 대체합니다.
동기식 요구 사항은 OpenAPI로 기술된 REST API로 충족하고, 비동기식 흐름은 이벤트와 큐를 사용하여 느리거나 응답하지 않는 시스템이 다른 시스템을 막지 않도록 합니다. 레거시 SOAP 서비스, 파일 전송, 데이터베이스 링크는 어댑터로 감싸 나머지 시스템이 하나의 일관된 인터페이스로 작동하게 합니다.
모든 연동은 무엇을 언제 전송했는지 기록하고, 안전하게 재시도하며, 실패 시 알림을 발생시킵니다. 따라서 대사 작업은 매월 하는 일이 아니라 예외적인 절차가 됩니다.
- 버전 관리되어 귀사 팀에 공개되는 REST 및 OpenAPI 규격
- 큐와 멱등성 컨슈머를 이용한 이벤트 기반 연동
- SOAP, SFTP, 플랫 파일, 데이터베이스 직접 인터페이스용 어댑터
- GlowScale, Orbio 및 외부 ERP, CRM, 결제 시스템과의 연동
데이터 및 분석
경영 의사 결정을 위한 신뢰할 수 있는 보고
보고 프로젝트는 대개 데이터 품질과 적시성 문제로 실패합니다. 그래서 당사는 파이프라인과 지표 정의를 먼저 구축하고 대시보드는 그다음에 만듭니다.
데이터 웨어하우스
하나의 중앙 저장소에서 시간에 따른 추세를 비교하십시오. 데이터 웨어하우스는 PostgreSQL 또는 AWS 분석 서비스에서 운영되며, 귀사 애플리케이션에서 오는 예약 기반 및 이벤트 기반 파이프라인으로 데이터를 받고 이력을 보존합니다.
공통 지표 정의
재무 부서와 운영 부서가 같은 수치를 기준으로 일합니다. 매출, 현재고, 사이클 타임 같은 각 지표에는 합의된 정의가 하나씩 있으며, 이를 문서화하여 모든 보고서에 적용합니다.
대시보드와 보고서
역할마다 필요한 수치를 확인할 수 있습니다. 경영진, 관리자, 실무자를 위한 역할 기반 대시보드, 이메일로 발송되는 정기 보고서, 스프레드시트에서 추가 분석할 수 있는 내보내기 기능을 제공합니다.
AI 활용 준비
어시스턴트와 예측은 정제되고 관리되는 데이터에 달려 있습니다. 같은 데이터 웨어하우스가 InterCloud AI와 AI 및 데이터 솔루션에서 소개하는 모델에 데이터를 공급합니다.
로드맵
일반적인 전환 로드맵
실제로는 각 단계가 겹쳐 진행됩니다. 아래 순서는 다음 단계를 안전하게 진행하기 전에 무엇이 갖춰져 있어야 하는지를 반영한 것입니다.
- 1
평가 및 우선순위 설정
애플리케이션, 데이터, 연동 현황을 목록화하고, 현업 책임자를 인터뷰하며, 단기 개선 과제, 기반 구축 과제, 장기 교체 과제를 구분한 로드맵을 수립합니다.
- 2
기반 구축
AWS 랜딩 존, CI/CD 파이프라인, 모니터링, API 게이트웨이를 구축합니다. 이 구성 요소들은 이후의 모든 작업에서 공유되며, 대개 가장 먼저 눈에 보이는 결과물이 됩니다.
- 3
웨이브 단위의 이전과 현대화
워크로드를 AWS로 이전하고, 레거시 구성 요소를 기능 단위로 하나씩 교체하며, 문서화된 인터페이스로 시스템을 연결합니다. 각 웨이브는 사용자가 새 버전으로 업무를 시작하는 것으로 마무리됩니다.
- 4
데이터 통합
데이터 웨어하우스로 이어지는 파이프라인, 합의된 지표 정의, 첫 대시보드를 제공합니다. 이 단계에서 발견된 데이터 품질 문제는 애플리케이션 백로그에 추가합니다.
- 5
운영 및 개선
환경은 운영 대행으로 전환하거나 귀사 팀에 인계하며, 다음에 무엇을 현대화, 폐기 또는 자동화할지 분기마다 검토합니다.
확정하기 전에 위험과 비용을 파악하십시오
현대화 평가를 통해 귀사가 전체 프로그램을 확정하기 전에 우선순위가 정해진 로드맵과 위험 및 비용에 대한 명확한 그림을 얻을 수 있습니다.