CJ대한통운 해외 IDC의 AWS 전환기 1편: 의존성 분석과 랜딩존 설계

이 글은 CJ대한통운 해외 IDC의 AWS 전환 과정을 다룬 시리즈 중 1편입니다.

1편: CJ대한통운 해외 IDC의 AWS 전환기 1편: 의존성 분석과 랜딩존 설계
2편: CJ대한통운 해외 IDC의 AWS 전환기 2편: 컷오버와 안정화

이 글은 CJ대한통운 TES 물류기술연구소가 해외 거점 IDC를 AWS로 이전한 경험을 두 편에 나눠 정리한 것입니다. 1편에서는 마이그레이션을 시작하게 된 배경, 사전 분석과 도구 선택, 랜딩존과 보안 아키텍처를 어떻게 설계했는지 다룹니다. 2편에서는 Windows와 SQL Server, Active Directory 이전 과정과 함께 다국적 조직의 협업 체계, 마이그레이션 프레임워크와 Wave 전략, 컷오버 시나리오, 안정화 과정에서 겪은 문제와 비용 이야기를 이어서 소개합니다.

회사 소개

CJ대한통운은 1930년에 설립된 대한민국을 대표하는 종합 물류 및 SCM 기업입니다. 국내 계약물류, 택배, 항만하역뿐만 아니라 전 세계 40개국 글로벌 네트워크를 바탕으로 항공, 해상 운송까지 선도하고 있습니다.

TES 물류기술연구소는 CJ대한통운의 기술 혁신을 담당하는 연구개발 조직입니다. AI, 클라우드, 데이터, 로봇 등 다양한 기술을 연구하고 실제 물류 서비스에 적용하여 글로벌 물류 플랫폼을 고도화하고 있습니다. 또한 물류 시스템 개발부터 글로벌 인프라 구축, 클라우드 전환, AI 기반 플랫폼 개발까지 직접 수행하며 기술 내재화를 추진하고 있습니다. 이번 해외 거점 IDC의 AWS 클라우드 마이그레이션 역시 글로벌 IT 인프라 현대화와 Cloud Native 기반 마련을 목표로 수행한 프로젝트입니다.

CJ대한통운의 항공, 해상, 육상 운송과 세계 주요 도시를 연결하는 글로벌 물류 네트워크

그림 1. CJ대한통운의 글로벌 물류 서비스

왜 마이그레이션이 필요했나

CJ대한통운의 글로벌 서비스 기반인 해외 거점 IDC는 오랜 기간 핵심 서비스를 안정적으로 운영해 왔습니다. 하지만 기존 IDC의 애플리케이션 구조와 운영 환경에서는 서비스 변경과 배포의 리드타임이 길고, 비즈니스 성장에 맞춰 인프라를 유연하게 확장하는 데 한계가 있었습니다. 이러한 환경에서는 빠르게 변화하는 글로벌 비즈니스 요구사항에 민첩하게 대응하기 어려웠으며, 향후 Cloud Native 기반의 서비스 운영 체계를 구축하기에도 제약이 있었습니다.

이번 프로젝트의 목표는 단순히 서버를 AWS로 이전하는 것이 아니었습니다. AWS 기반의 표준 아키텍처와 운영 거버넌스를 구축하고, 향후 Cloud Native 및 AI Native 환경으로 확장할 수 있는 기반을 마련하는 것을 핵심 목표로 설정했습니다. 또한 글로벌 서비스를 본사 중심으로 일관되게 운영할 수 있도록 핵심 운영 역량을 내재화하고, 특정 IDC나 운영 방식에 대한 의존도를 낮추는 데 중점을 두었습니다.

이번 프로젝트는 외부 수행사 없이 인프라팀, 운영팀, 보안팀이 아키텍처 설계부터 컷오버와 운영 안정화까지 전 과정을 직접 수행했습니다. 수개월 동안 다국적 조직 수십 명이 협업하여 수십 대의 서버와 다수 서비스를 AWS로 이전했으며, 표준화된 운영 체계와 마이그레이션 프레임워크를 함께 구축했습니다.

AWS EBA로 마이그레이션의 기반 다지기

AWS 기반 대규모 마이그레이션을 처음 수행하는 상황에서 가장 큰 과제는 무엇을 어떤 순서로 수행해야 하는지에 대한 기준이 없었다는 점이었습니다. 팀 내에는 대규모 AWS 마이그레이션 경험자가 없었고, 표준화된 마이그레이션 프레임워크와 운영 체계 또한 갖춰져 있지 않았습니다.

이를 해결하기 위해 AWS EBA(Experience-Based Acceleration)를 통해 8주간의 마이그레이션 스프린트를 진행했습니다. 이 과정에서는 AWS Transform MGN(구 AWS Application Migration Service)을 활용한 워크로드 마이그레이션을 직접 실습하고, 워크로드 분석, To-Be 아키텍처 설계, 표준 마이그레이션 프레임워크를 함께 수립하며 실제 프로젝트를 수행하기 위한 기반을 마련했습니다.

AWS EBA는 단순한 교육 프로그램이 아니라 실제 프로젝트를 위한 실행 과정이었습니다. AWS 전문가와 함께 기술 워크숍과 리뷰를 반복하며 아키텍처, 운영, 보안, 프로젝트 관리 전반을 검토했고, 이후 프로젝트에서 활용할 의사결정 기준과 표준 운영 방식을 구체화했습니다.

특히 AWS Transform MGN 워크숍에서는 실제 워크로드를 대상으로 마이그레이션 절차를 검증하며 전략을 구체화했습니다. 방화벽 정책과 IP 주소 체계를 유지한 상태에서의 이전 가능성을 확인하고, Windows Server와 Microsoft SQL Server 라이선스 정책 등 실제 이전 과정에서 발생할 수 있는 기술적 이슈를 사전에 점검했습니다.

마이그레이션의 시작, ADS 설치와 인벤토리 분석

수십 년간 운영된 해외 거점 IDC에는 문서에 드러나지 않은 통신 경로가 존재했습니다. 월말 배치와 비정기 작업처럼 특정 시점에만 발생하는 통신까지 포함해 의존성 지도를 그리는 것이 출발점에서 가장 어려운 과제였습니다.

성공적인 마이그레이션의 첫 단계는 현재 운영 환경을 정확하게 이해하는 것이었습니다. 이를 위해 해외 거점 IDC에 AWS Application Discovery Service(ADS)를 설치하여 서버, 애플리케이션, 네트워크 통신 정보를 자동으로 수집하고 기존 인프라 인벤토리를 체계적으로 분석했습니다. 특히 특정 시점의 단편적인 정보만으로는 월말 배치나 비정기 업무와 같은 실제 서비스 간 통신 관계를 빠뜨릴 수 있기 때문에, 최소 30일 이상의 통신 로그를 확보하는 것을 목표로 데이터를 수집했습니다. 수집된 데이터를 기반으로 워크로드 간 의존성과 주요 통신 경로를 파악하고, 기존에 관리하는 서버 인벤토리를 통해 운영체제, 미들웨어, Windows Server 및 Microsoft SQL Server 라이선스 현황과 EOS(End of Support) 여부를 함께 점검했습니다.

ADS가 수집한 데이터는 출발지, 도착지, 포트 단위의 네트워크 통신 메타데이터입니다. 저희가 수집한 통신 로그는 약 350만 건으로, 출력된 CSV 그대로는 패턴을 파악하기가 어려웠습니다. 수집한 통신 데이터를 LLM 기반 분석 도구에 제공하고, “이 서버가 통신하는 대상을 그룹별로 요약해줘”, “월말에만 발생하는 통신 패턴을 찾아줘”와 같이 자연어로 분석을 요청했습니다. 이를 통해 기존 문서에 없던 의존성과 통신 대상을 식별할 수 있었습니다. 다만, 수집된 메타데이터만으로는 IP가 어떤 시스템에 해당하는지 식별하기 어렵기 때문에, 인프라 및 서비스 담당자의 확인이 필요합니다. 이러한 분석 결과는 마이그레이션 대상 선정과 웨이브(Wave) 구성의 기준이 되었으며, 방화벽 정책과 네트워크 연결 요건을 사전에 식별하는 데에도 중요한 역할을 했습니다.

ADS가 수집하는 네트워크 정보는 출발지와 도착지의 IP, 포트 같은 연결 정보뿐이며 패킷 페이로드는 수집하지 않습니다.
ADS는 2025년 11월 7일부터 신규 고객에게 더 이상 제공되지 않습니다. 기존 사용 고객은 계속 쓸 수 있으며, 새로 시작한다면 AWS가 대안으로 안내하는 AWS Transform의 디스커버리 기능을 검토해 보시기 바랍니다.

AWS Migration Hub 콘솔의 서버 목록 화면으로, Agent 상태의 3개 서버(b2bindev4, iwmsdev, gemdev)와 각각의 IP 주소(192로 시작)가 표시됨

그림 2. ADS로 수집한 서버 인벤토리 화면

중앙의 대상 서버를 중심으로 서버 01~24와 09~19가 네트워크로 연결된 서버 간 통신 관계도

그림 3. 서버 간 네트워크 연결 관계 예시

AWS Transform MGN, 마이그레이션 완성도를 높이는 핵심 도구

AWS Transform MGN은 AWS 환경과 긴밀하게 통합되어 있는 Lift & Shift 마이그레이션 도구입니다. 복제 서버의 시작 설정(Launch Settings)과 EC2 시작 템플릿(Launch Template)을 활용해 인스턴스 유형, 네트워크, Security Group, IAM, EBS 등 AWS 리소스를 환경에 맞게 표준화할 수 있으며, 여러 번 인스턴스를 생성하더라도 동일한 구성을 일관되게 유지할 수 있었습니다.

또한 여러 서버를 동시에 복제하고 전환할 수 있다는 점도 중요한 장점이었습니다. 덕분에 수십 대의 서버를 짧은 기간에 같은 절차로 옮기면서 작업 시간을 많이 줄이고 품질도 고르게 유지할 수 있었습니다. 운영 환경은 테스트 인스턴스로 애플리케이션, 네트워크, AD 연동, 방화벽 정책을 먼저 검증한 뒤 컷오버했습니다. 개발 환경은 일정과 특성을 고려해 테스트 단계를 건너뛰고 바로 컷오버했는데, 이는 저희 상황에 맞춘 예외였습니다. AWS 문서에서도 컷오버 전에 테스트 인스턴스로 검증하는 것을 권장하고 있으니, 가능하면 테스트 단계를 거치는 편이 안전합니다.

Windows Server와 SQL Server 라이선스 점검

해외 거점 인프라는 Windows, SQL Server, Active Directory 비중이 높았는데, 실제로 들여다보니 예상보다도 Windows 시스템이 많았습니다. Windows Server와 SQL Server 워크로드는 기술적인 호환성만큼이나 라이선스 조건이 마이그레이션 방식과 비용 구조를 크게 좌우하기 때문에 미리 검토해야 했습니다. 국내 클라우드 환경은 대부분 Linux 워크로드 중심이라 저희에게 Windows와 SQL Server 라이선스는 꽤 낯선 영역이었습니다. 처음에는 라이선스를 어떻게 적용해야 하는지, 어떤 제약이 있는지 해석하기가 쉽지 않았고, AWS SA의 도움을 받아 적용 가능한 범위를 하나씩 확인해 나갔습니다.

이에 따라 OS와 SQL Server의 버전, 에디션, EOS 여부, 서버 역할과 구성 현황을 정리해 AWS에서 지원되는지 살폈고, 기존 계약서와 구매 증빙을 바탕으로 BYOL(Bring Your Own License)이 가능한지도 확인했습니다.

검토 결과, 기존 라이선스가 물리 서버에 종속된 형태로 계약되어 있어 AWS EC2 환경에서 BYOL 적용은 불가능한 것으로 판단되었습니다. 이에 따라 라이선스 위반 리스크를 방지하고 운영 복잡도를 줄이기 위해 라이선스가 포함된 AWS 제공 AMI를 선택했습니다.

최종적으로 해당 AMI 기반으로 EC2를 구성하여 라이선스 준수와 운영 안정성을 확보하고, 향후 라이선스 관리 및 비용 구조 최적화 기준을 마련했습니다.

여러 VPN을 위한 네트워크 아키텍처와 Terraform

여러 거점과 VPN 터널을 수동으로 관리하면 설정 오류가 반복될 위험이 크고, AWS Direct Connect를 쓰기에는 트래픽 규모와 구축 기간이 맞지 않아 구성 방식 자체부터 다시 결정해야 했습니다.

해외 거점 IDC와 AWS 간의 안정적인 연결을 위해 AWS Direct Connect와 AWS Site-to-Site VPN 기반의 AWS Transit Gateway(TGW) 연동 방식을 함께 검토했습니다. 초기에는 전용 회선을 통한 Direct Connect 도입도 고려했지만, 워크로드 특성과 트래픽 패턴을 분석한 결과 대용량 데이터 전송이 지속적으로 발생하는 환경은 아니었습니다. 이에 비용 효율성과 구축 기간을 종합적으로 고려하여 기존 VPN 터널을 활용해 AWS Transit Gateway에 연동하는 아키텍처를 채택했습니다. 또한 다수의 VPN 연결과 라우팅 구성을 일관되게 관리하기 위해 Terraform 기반의 Infrastructure as Code(IaC)를 적용하여 네트워크 리소스를 표준화하고 자동화했습니다. 이를 통해 향후 VPN 추가 및 변경 작업을 코드 기반으로 관리할 수 있는 체계를 마련하고, 운영 효율성과 구성 일관성을 함께 확보했습니다.

AWS Control Tower 기반 글로벌 거버넌스 설계

국내와 글로벌 환경을 하나의 OU로 합칠지, 따로 나눌지를 두고 고민이 길었습니다. 당장의 운영 복잡도와 앞으로의 확장성을 함께 놓고, 어느 쪽이 길게 봤을 때 더 안전한지 판단해야 했습니다.

CJ대한통운은 2025년에 AWS Control Tower로 랜딩존을 구축해 이미 수십 개의 계정을 운영하고 있었습니다. 이번 마이그레이션에 앞서 이 랜딩존을 바탕으로 글로벌 서비스에 맞는 To-Be 아키텍처를 설계했고, 국내와 글로벌 환경이 하나의 표준 거버넌스 위에서 함께 확장될 수 있도록 구조를 잡았습니다.

AWS Organizations 루트 아래 공통 서비스, 국내 워크로드, 글로벌 워크로드 OU로 나뉘고, 글로벌 OU는 해외 거점별로 세부 OU를 갖는 계층 구조

그림 4. 글로벌 워크로드를 위한 OU 구성

글로벌 서비스는 국내 서비스와 운영 정책, 보안 요구사항이 달랐습니다. 그래서 같은 AWS Organizations OU(Organizational Unit)에 두지 않고 별도의 Global OU로 분리했습니다. 국내와 같은 OU 안에서 계정 하나로 합쳐 운영하는 방안도 검토했지만, 글로벌 확장성과 정책 독립성, 나중에 국가별로 서비스를 나눌 가능성까지 생각하면 길게 가져가기 어렵다고 봤습니다. 그래서 처음부터 계정과 OU를 확실히 나누는 쪽으로 설계했습니다.

이렇게 나누면 서비스 제어 정책(SCP), 계정 생성 정책, 권한 관리 같은 거버넌스를 글로벌 환경에 맞게 따로 운영할 수 있습니다. SCP는 상위 OU에 붙이면 하위 OU와 계정에 상속되고, 계정에서 쓸 수 있는 최대 권한의 범위를 정할 뿐 권한을 직접 부여하지는 않습니다. 이 구조의 핵심은 국내와 글로벌 서비스 사이의 관리 경계를 분명히 그어서 서로 영향을 주지 않게 하는 것입니다. 국내 쪽 정책을 바꿔도 글로벌 환경에는 영향이 가지 않도록 설계해 운영 안정성과 확장성을 함께 챙겼고, 앞으로 글로벌 서비스가 늘어나더라도 같은 거버넌스와 보안 정책을 적용할 수 있는 바탕이 됐습니다.

해외 IDC 환경은 한국 본사의 거버넌스 체계 안으로 들였습니다. 물리적으로는 떨어져 있어도 정책과 통제 기준은 본사와 똑같이 적용되도록 했습니다. 방화벽은 비용과 운영 표준화를 고려해 글로벌 서비스 리전에 공통 방화벽 솔루션으로 배치했습니다. 처음에는 한 리전에서 통합 운영하며 비용을 아끼고, 나중에 다른 리전의 글로벌 지사가 들어오더라도 같은 방화벽을 다시 쓸 수 있게 하려는 의도였습니다. 실제로 이후 글로벌 계정이 추가되면서 같은 방화벽을 함께 쓰게 됐고, 처음 의도했던 대로 비용과 운영 일관성 두 가지를 모두 얻었습니다.

Amazon WorkSpaces로 망분리 VDI 환경 전환

해외 거점 IDC 시스템은 접근통제와 운영 모니터링을 위해 별도의 VDI 환경을 쓰고 있었습니다. 서버와 Active Directory를 AWS로 옮기면서 운영자 접속 환경도 Amazon WorkSpaces로 함께 바꿨습니다. 전환 과정에서는 기존 접근통제 수준을 유지하면서 계정과 데스크톱 환경을 일관된 기준으로 관리하는 데 중점을 뒀습니다.

운영자가 사내 접속암호로 인증하여 Streaming 엔드포인트와 WorkSpaces Personal을 거쳐 TGW의 업무 접속점으로 연결되고, Inspection VPC의 방화벽을 거쳐 업무 VPC의 업무 서버에 접근하며, 해외 IDC 서버로도 연결되는 WorkSpaces 기반 접속 보안 아키텍처

그림 5. Amazon WorkSpaces 기반 운영자 접속과 보안 아키텍처

사용자 계정은 기존 Active Directory와 연동하고, 관리자 계정은 일반 사용자 계정과 분리했습니다. 네트워크 정책으로 내부 시스템의 접근 범위를 업무에 필요한 수준으로 제한하고, AWS 리소스 관리 권한도 역할별로 필요한 범위에 한정했습니다.

데스크톱에는 업무 특성에 맞는 표준 이미지를 적용하고, 백신 설치와 볼륨 암호화 등 기본 보안 통제를 함께 구성했습니다. 로컬 관리자 권한과 셀프 서비스 기능을 제한해 사용자가 환경을 임의로 바꾸지 못하도록 했습니다. AWS CloudTrail의 관리 작업 이력을 수집했습니다. 이를 바탕으로 사용자 접속 현황과 관리자 설정 변경 내역을 확인하고, 보안 점검과 감사에 활용할 수 있도록 했습니다.

네트워크 랜딩존과 GWLB로 통합 보안 아키텍처 만들기

해외 거점 IDC는 오래 운영되면서 서비스 변경과 예외 요청이 생길 때마다 방화벽 정책이 계속 쌓여 왔습니다. 이번 전환에서는 이 정책을 그대로 옮기지 않고, 하나하나 정말 필요한지, 적절한지부터 다시 따져 봤습니다. ADS로 확인한 실제 통신 관계와 업무 필요성을 기준으로 네트워크 접근 정책을 새로 정리해 최소 권한 기반의 표준 보안 정책으로 바꿨습니다.

이 과정에서 오래 누적된 예외 정책을 대폭 줄이고, 여러 AWS 계정과 VPC에 동일한 보안 기준을 적용할 수 있는 중앙 집중형 네트워크 보안 체계를 마련했습니다.

CloudFront와 AWS WAF로 보호된 사용자 요청이 Workload VPC의 IGW, GWLB 엔드포인트, ALB, 업무 서버, DB를 거쳐 흐르고, TGW를 통해 Inspection VPC의 GWLB 엔드포인트와 Egress VPC의 NAT, IGW를 거쳐 인터넷으로 나가는 GWLB 기반 중앙 검사 아키텍처

그림 6. 주요 연결 관계를 단순화한 GWLB 기반 중앙 검사 아키텍처 개념도

공통 방화벽 계층을 통한 트래픽 검사

Gateway Load Balancer(GWLB)를 이용해 여러 VPC가 공통 방화벽 계층을 사용하도록 구성했습니다. 각 VPC는 GWLB 엔드포인트를 통해 검사 대상 트래픽을 전달하고, 방화벽 정책에 따라 허용된 통신이 목적지로 이어지도록 했습니다.

통신 특성에 맞춘 접근 경로 구성

인터넷에서 들어오는 사용자 요청은 Amazon CloudFront와 AWS WAF를 거쳐 업무 환경으로 전달되며, 방화벽 검사 후 업무 서버에 도달하도록 구성했습니다. 업무 환경의 외부 통신과 IDC 연동에는 Transit Gateway를 활용해 연결을 관리하고, 필요한 트래픽에 보안 검사를 적용했습니다.

이러한 구조를 통해 여러 업무 환경에 공통 보안 기준을 적용하고, 방화벽 정책을 중앙에서 관리할 수 있도록 했습니다. 새로운 업무 환경을 연결할 때도 기존 보안 체계를 활용할 수 있는 기반을 마련했습니다.

다음 편에서는

1편에서는 마이그레이션의 바탕이 된 분석과 도구 선택, 그리고 거버넌스, 네트워크, 보안 아키텍처를 살펴봤습니다. 2편에서는 이 기반 위에서 실제로 Windows 서버와 SQL Server, Active Directory를 어떻게 옮겼는지 소개합니다. 이어서 언어와 문화가 다른 수십 명이 함께 일하기 위해 만든 협업 체계와 마이그레이션 프레임워크를 다룹니다. 서비스 영향도를 기준으로 Wave를 나눈 방식과, 150분 안에 끝내야 했던 컷오버의 준비 과정도 함께 소개합니다. 마지막으로 오픈 이후 며칠 동안 드러난 문제들과 비용 이야기를 전해 드리겠습니다.

AWS 기술 블로그