클라우드 마이그레이션, 구조 진단 없이 시작하면 생기는 일

핵심 요약: 마이그레이션 실패의 핵심 원인이 구조 파악 부재인 이유를 설명해요. 83%의 프로젝트가 예산·일정을 초과하는 현실에서 종속성, 배치, 유휴 자산을 먼저 진단하는 방법을 정리했어요.

실제 엔터프라이즈 환경에서는 클라우드 전환 프로젝트가 시작된 지 몇 달이 지나도록 "우리 시스템이 어떻게 연결되어 있는지 모른다"는 말이 나오는 상황이 빈번하게 발생해요.

인프라 담당자는 서버 목록을 알고 있어요. 개발팀은 애플리케이션 구조를 알고 있어요. 하지만 두 팀이 함께 앉아서 "이 서비스가 저 DB에 연결되어 있고, 저 배치 잡이 이 API를 호출한다"는 전체 그림을 그려본 적이 없는 경우가 많아요. 마이그레이션은 그 그림 없이 시작되고, 문제는 전환 이후에 터져요.

이 글에서는 왜 구조 진단이 마이그레이션의 선행 조건인지, 그리고 진단에서 실제로 무엇을 확인해야 하는지를 다뤄볼게요.

마이그레이션 프로젝트가 실패하는 이유

마이그레이션 실패의 핵심 원인은 기술 부족이 아니라 구조 파악 부재예요.

클라우드 전환이 어렵다는 건 이미 알려진 사실이에요. 하지만 얼마나 많은 프로젝트가 실패하는지를 수치로 보면 체감이 달라져요.

Gartner 조사에 따르면, 데이터 마이그레이션 프로젝트의 83%가 예산이나 일정을 초과하거나 실패해요. McKinsey의 TMT 인사이트 분석에서는 마이그레이션 비효율로 인해 고객사당 연간 14%의 초과 비용이 발생하고, 전 세계적으로 3년간 1,000억 달러 이상이 낭비될 것으로 추산했어요. BCG의 2024년 클라우드 전환 분석에서도 절반 이상의 프로젝트가 3년 내에 의도한 목표를 달성하지 못한다고 나와요.

원인을 추적한 끝에 공통된 패턴을 발견했어요. 대부분의 프로젝트가 "무엇을 옮길지"는 알고 있지만, "어떻게 연결되어 있는지"는 모른 채 시작한다는 거예요.

서버 목록은 있어요. 하지만 그 서버들이 서로 어떤 포트로 통신하는지, 어떤 배치 잡이 새벽 2시에 돌아가는지, 어떤 레거시 시스템이 예상치 못한 곳에서 호출되는지는 문서화되어 있지 않아요. 이 상태에서 전환을 시작하면, 오래된 건물을 리모델링하려다 벽 안에 배선이 얼마나 복잡한지 뒤늦게 발견하는 것과 비슷한 상황이 벌어져요.

구조 진단이란 무엇인가요

구조 진단은 서비스 간 연결 관계와 데이터 흐름을 확인하는 사전 분석이에요. 단순한 인벤토리 수집과는 다른 작업이에요.

서버 목록을 만드는 건 인벤토리고, 구조 진단은 그 서버들이 어떻게 연결되어 있는지를 파악하는 작업이에요. 구체적으로는 세 가지를 확인해요.

첫째, 현재 인프라의 물리적·논리적 구성이에요. 어떤 서버가 어떤 역할을 하고, 어떤 OS와 미들웨어 버전을 쓰고 있는지를 파악해요.

둘째, 서비스 간 종속성이에요. 어떤 애플리케이션이 어떤 DB에 연결되어 있고, 어떤 API를 호출하는지, 그 호출이 동기인지 비동기인지를 확인해요.

셋째, 데이터 흐름과 트래픽 패턴이에요. 어떤 시간대에 어떤 서비스에 부하가 집중되는지, 배치 처리가 어떤 순서로 실행되는지를 분석해요.

이 세 가지를 파악하고 나면, 어떤 서비스를 먼저 옮겨야 하는지, 어떤 서비스는 함께 옮겨야 하는지, 어떤 서비스는 클라우드 전환 전에 먼저 정리해야 하는지가 보여요.

반드시 확인해야 할 4가지 영역

인프라 현황

서버 수, OS 버전, 미들웨어 버전, 라이선스 현황을 파악해요. 특히 라이선스는 클라우드 전환 비용에 직접 영향을 줘요. Oracle DB나 Windows Server처럼 클라우드에서 라이선스 비용이 달라지는 제품들은 사전에 총소유비용(TCO)을 계산해야 해요.

한국 엔터프라이즈 환경에서는 망분리 구성도 반드시 확인해야 해요. 인터넷망과 업무망이 분리된 환경에서는 클라우드 연결 방식 자체가 달라지고, ISMS-P 인증을 유지해야 하는 고객사라면 클라우드 전환 후에도 동일한 보안 통제를 유지할 수 있는지 검토가 필요해요.

서비스 종속성

처음엔 단순해 보이는 시스템도 종속성을 그려보면 복잡한 경우가 많아요. 특히 오래된 시스템일수록 문서화되지 않은 연결이 많아요.

종속성 파악에서 중요한 건 방향이에요. A가 B를 호출하는지, B가 A를 호출하는지에 따라 마이그레이션 순서가 달라져요. 양방향 호출이 있는 서비스는 함께 전환하거나, 전환 기간 동안 브릿지 구성이 필요해요.

데이터 흐름과 배치 처리

운영하면서 계속 느낀 건, 배치 처리가 마이그레이션에서 가장 많이 간과된다는 거예요. 실시간 서비스는 눈에 보이지만, 새벽에 돌아가는 배치 잡은 문서에 없는 경우가 많아요.

배치 처리의 실행 순서, 의존 관계, 실패 시 재처리 방식을 파악해두지 않으면 전환 후 데이터 정합성 문제가 발생해요.

유휴 자산과 기술 부채

Flexera의 2025년 State of the Cloud 보고서에 따르면, 고객사 클라우드 예산의 평균 29%가 낭비로 추정돼요. 온프레미스 환경에서도 비슷한 패턴이 있어요. 실제로 사용하지 않는 서버, 오래된 스냅샷, 방치된 테스트 환경이 마이그레이션 대상에 포함되면 불필요한 비용이 클라우드로 그대로 이전돼요.

구조 진단 단계에서 유휴 자산을 정리하면, 마이그레이션 범위 자체를 줄일 수 있어요.

진단 없이 전환했을 때 생기는 문제들

구조 진단 없이 전환을 진행한 프로젝트에서 반복적으로 나타나는 문제는 크게 세 가지예요.

가장 흔한 건 예상치 못한 종속성으로 인한 장애예요. A 서비스를 클라우드로 옮겼는데, 온프레미스에 남아 있는 B 서비스가 A를 직접 호출하고 있었던 거예요. 네트워크 레이턴시가 늘어나면서 타임아웃이 발생하고, 원인을 찾는 데만 며칠이 걸려요.

두 번째는 비용 초과예요. 온프레미스에서 하나의 물리 서버에서 돌아가던 여러 서비스를 클라우드에서 각각 인스턴스로 분리하면 비용이 예상보다 훨씬 높아져요. 라이트사이징(Right-sizing) 없이 전환하면 이런 문제가 반복돼요.

세 번째는 일정 지연이에요. McKinsey 조사에서 38%의 고객사가 1분기 이상 마이그레이션 지연을 경험했고, 33%가 레거시 시스템을 지연의 주요 원인으로 꼽았어요. 레거시 시스템의 복잡성은 진단 없이는 예측이 불가능해요.

아모레퍼시픽의 사례는 반대 방향을 보여줘요. 800VM 규모의 리플랫폼 마이그레이션(Replatform Migration)을 진행하면서 IDC를 완전히 종료하고, 월 11억 원의 비용을 절감했어요. 40개 서비스의 현대화(Modernization)까지 함께 진행할 수 있었던 건, 사전에 애플리케이션·DB·서비스 간 연관관계를 정리하고 체계적인 운영 기준을 수립했기 때문이에요.

구조 진단 도구와 접근 방식

구조 진단에는 크게 두 가지 접근 방식이 있어요. 에이전트를 설치해서 데이터를 수집하는 방식과, 에이전트 없이 네트워크 트래픽이나 API를 통해 수집하는 에이전트리스(Agentless) 방식이에요.

에이전트 방식은 더 상세한 데이터를 수집할 수 있지만, 보안 정책이 엄격한 환경에서는 에이전트 설치 자체가 승인 프로세스를 거쳐야 해요. 금융권이나 공공기관처럼 보안 감사가 강한 환경에서는 에이전트리스 방식이 현실적인 선택이에요.

주요 도구들을 비교하면 아래와 같아요.

도구	방식	특징
AWS Migration Evaluator	Agentless	TCO 분석, 종속성 매핑, AWS 전환 최적화
Azure Migrate	Agentless	라이트사이징 권장, Azure 전환 특화
Google Migration Center	자동/수동	네트워크 종속성, TCO 리포트
Hyper Mig (메가존클라우드)	Agentless	한국 MSP 특화, 트래픽 기반 구조 맵, 종속성 시각화

퍼블릭 클라우드 벤더의 도구들은 자사 클라우드로의 전환을 전제로 설계되어 있어요. AWS Migration Evaluator는 AWS 전환 시나리오에 최적화되어 있고, Azure Migrate는 Azure 전환에 특화되어 있어요. 멀티클라우드 전략을 고려하고 있다면, 특정 벤더에 종속되지 않는 도구를 선택하거나 여러 도구를 병행하는 게 나아요.

메가존클라우드의 Hyper Mig는 머니투데이 보도에 따르면, 기존에 4개월·45맨먼스가 소요되던 IT 시스템 구조 진단을 30% 공수 절감을 목표로 개발된 도구예요. 한국 엔터프라이즈 환경의 특수성, 특히 망분리 구성이나 그룹사 구조를 고려한 설계가 되어 있어요.

실무에서의 트레이드오프와 주의점

구조 진단이 중요하다는 건 알겠는데, 얼마나 깊이 해야 하는지가 실무에서 가장 어려운 질문이에요.

진단을 너무 얕게 하면 전환 후 문제가 터지고, 너무 깊게 하면 진단 자체에 수개월이 걸려요. 실제로 진단 기간이 길어지면서 프로젝트 모멘텀이 떨어지는 경우도 있어요.

진단 깊이와 기간의 균형이 첫 번째 고려사항이에요. 모든 시스템을 완벽하게 파악하려다 보면 진단이 끝나지 않아요. 핵심 서비스와 복잡도가 높은 시스템에 집중하고, 단순한 시스템은 빠르게 처리하는 방식이 현실적이에요.

데이터 주권과 수집 범위도 고려해야 해요. 에이전트리스 도구라도 네트워크 트래픽을 분석하거나 시스템 정보를 수집하는 과정에서 민감한 데이터가 포함될 수 있어요. 금융보안원 가이드라인이나 ISMS-P 요구사항에 따라 수집 범위와 데이터 보관 방식을 사전에 정의해야 해요.

조직 역량도 현실적으로 봐야 해요. 진단 도구가 아무리 좋아도, 결과를 해석하고 마이그레이션 전략으로 연결하는 건 사람이 해야 해요. 내부에 클라우드 아키텍처 경험이 없다면, 도구 도입과 함께 외부 전문가의 지원을 병행하는 게 나아요.

BCG 분석에서 클라우드 전환을 비즈니스 전환의 일부로 실행한 고객사가 인프라 중심 전환 대비 12–15배의 이점을 얻었다는 결과가 있어요. 구조 진단도 마찬가지예요. 인프라 현황 파악에만 집중하지 않고, 비즈니스 목표와 연결해서 "어떤 서비스를 어떤 순서로 전환해야 비즈니스 가치를 빠르게 실현할 수 있는가"를 함께 고민해야 해요.

에이핀은 AWS·OCI 기반 멀티클라우드 전환과 구조 진단, ISMS-P 보안 통제 매핑을 함께 검토하는 방식으로 프로젝트를 진행해요. 인프라 가시성 확보부터 전환 전략 수립까지 한 흐름으로 연결하는 게 실패 확률을 줄이는 가장 현실적인 방법이에요.

핵심 요약

• 마이그레이션 프로젝트의 83%가 예산이나 일정을 초과하거나 실패하는 주요 원인은 사전 구조 파악 부족이에요
• 구조 진단은 서버 목록 수집이 아니라, 서비스 간 종속성과 데이터 흐름을 파악하는 작업이에요
• 인프라 현황, 서비스 종속성, 데이터 흐름, 유휴 자산 4가지 영역을 반드시 확인해야 해요
• 한국 엔터프라이즈 환경에서는 망분리 구성, ISMS-P 요구사항, 보안 감사 프로세스를 진단 단계에서 함께 고려해야 해요
• 진단 도구 선택 시 특정 클라우드 벤더 종속 여부와 데이터 수집 범위를 사전에 검토해야 해요

FAQ

Q. 구조 진단은 얼마나 시간이 걸리나요?

규모와 복잡도에 따라 다르지만, 일반적인 진단 프로젝트에서는 중견 규모 환경 기준 4–8주가 소요돼요. 에이전트리스 도구를 활용하면 데이터 수집 기간을 단축할 수 있지만, 결과 분석과 마이그레이션 전략 수립까지 포함하면 최소 4주는 잡아야 해요. 메가존클라우드의 Hyper Mig처럼 자동화된 도구를 활용하면 기존 대비 30% 이상 공수를 줄일 수 있어요.

Q. 클라우드 벤더가 제공하는 무료 진단 도구만으로 충분한가요?

AWS Migration Evaluator나 Azure Migrate 같은 벤더 제공 도구는 해당 클라우드로의 전환 시나리오에 최적화되어 있어요. 단일 클라우드로 전환하는 경우라면 충분할 수 있지만, 멀티클라우드 전략을 고려하거나 온프레미스 일부를 유지하는 하이브리드 구성이라면 벤더 중립적인 도구를 병행하는 게 나아요. 도구가 수집한 데이터를 해석하고 전략으로 연결하는 과정에서 전문가 지원이 필요한 경우가 많아요.

Q. ISMS-P 인증을 유지하면서 클라우드로 전환할 수 있나요?

가능해요. 다만 ISMS-P 인증 범위에 클라우드 환경이 포함되도록 인증 범위를 재정의하거나, 클라우드 서비스 제공자의 인증 현황을 확인해야 해요. 구조 진단 단계에서 현재 ISMS-P 통제 항목이 클라우드 환경에서 어떻게 구현될지를 미리 매핑해두면, 전환 후 인증 갱신 과정이 훨씬 수월해져요. 특히 접근 통제, 로그 관리, 암호화 요구사항은 클라우드 환경에서 구현 방식이 달라지는 경우가 많아요.

Q. 레거시 시스템이 많은데 구조 진단이 의미가 있나요?

오히려 레거시 시스템이 많을수록 구조 진단이 더 중요해요. McKinsey 조사에서 33%의 고객사가 레거시 시스템을 마이그레이션 지연의 주요 원인으로 꼽았어요. 레거시 시스템은 문서화가 부족하고 종속성이 복잡한 경우가 많아서, 진단 없이 전환을 시작하면 예상치 못한 문제가 연쇄적으로 발생해요. 진단을 통해 레거시 시스템의 복잡도를 파악하고, 전환 전에 정리할 부분과 그대로 이전할 부분을 구분하는 게 현실적인 접근이에요.

Q. 구조 진단 결과는 어떤 형태로 문서화해야 하나요?

진단 결과는 크게 세 가지 산출물로 정리하는 게 실무에서 활용하기 좋아요. 첫째, 서비스 종속성 맵으로 어떤 서비스가 어떤 서비스에 의존하는지를 시각화한 다이어그램이에요. 둘째, 전환 우선순위 매트릭스로 비즈니스 중요도와 전환 복잡도를 기준으로 각 서비스를 분류한 표예요. 셋째, 리스크 레지스터로 전환 과정에서 발생할 수 있는 위험 요소와 대응 방안을 정리한 문서예요. 이 세 가지가 갖춰지면 마이그레이션 계획 수립 단계에서 팀 간 커뮤니케이션 비용이 크게 줄어요.