전용 회선을 쓰면 보안이 해결된다고 생각하시나요? 저도 그렇게 믿었습니다. Direct Connect를 개통하고 나서야 전용 회선은 시작일 뿐이라는 걸 깨달았습니다. VPN 터널이 터지고, 회선 점검 때 서비스가 멈추고, 그제야 하이브리드 네트워크 설계가 얼마나 입체적인 문제인지 몸으로 배웠습니다.
VPN의 한계, 그리고 Direct Connect를 선택한 이유
처음 하이브리드 클라우드 구성을 맡았을 때, 저는 Site-to-Site VPN부터 손댔습니다. IKEv2 설정에 사전 공유 키(PSK)를 넣고, BGP 라우팅까지 어찌어찌 붙여놓고는 "됐다"고 생각했습니다. BGP란 서로 다른 네트워크 사이에서 경로 정보를 교환하는 프로토콜로, 인터넷을 포함한 대규모 네트워크에서 트래픽 흐름을 결정하는 핵심 라우팅 기술입니다.
문제는 운영 환경에 올리고 나서 터졌습니다. 피크 타임마다 온프레미스 DB 동기화가 느려지는 현상이 반복됐고, 처음에는 쿼리 튜닝부터 뒤졌습니다. 이틀을 허비하고 나서 CloudWatch 지표를 열어보니, VPN 터널 처리량이 이미 최대치를 찍고 있었습니다. 네트워크 병목이었던 겁니다.
Site-to-Site VPN은 인터넷 구간을 IPsec으로 암호화해 연결하는 방식입니다. IPsec이란 네트워크 계층에서 데이터를 암호화하고 인증하는 보안 프로토콜로, VPN 터널을 구성하는 표준 기술입니다. 비용이 낮고 구성이 빠르다는 장점이 있지만, 인터넷 회선을 공유하는 구조상 대역폭이 보장되지 않고 레이턴시가 들쑥날쑥합니다. 트래픽이 일정 수준을 넘는 순간 이 구조적 한계가 그대로 드러납니다.
AWS 공식 문서에 따르면 Direct Connect는 온프레미스와 AWS 클라우드를 물리 전용 회선으로 잇는 서비스로, 일관된 네트워크 성능과 Data Transfer Out 비용 절감이 핵심 이점입니다(출처: AWS 공식 문서). 저는 이 문서를 경영진 앞에 꺼내놓고 도입 필요성을 설명했지만, 초기 구축 비용과 회선 계약 기간이 발목을 잡았습니다. 설득에만 몇 주가 걸렸고, 이후 LOA-CFA를 발급받아 파트너 IDC에서 크로스 커넥트를 구성하기까지 총 6주가 소요됐습니다. LOA-CFA란 Letter of Authorization-Connecting Facility Assignment의 약자로, Direct Connect 회선을 물리적으로 연결하기 위해 AWS가 발급하는 승인 서류입니다. 이 서류가 없으면 IDC 측에서 실제 케이블 연결 작업을 진행할 수 없습니다.
전용 회선의 실제 성능, 그리고 놓친 것
Direct Connect가 개통된 직후 체감 차이는 분명했습니다. 레이턴시가 VPN 대비 절반 이하로 떨어졌고, 대용량 파일 전송 속도도 눈에 띄게 달라졌습니다. 솔직히 이건 예상 밖이었습니다. 수치는 알고 있었지만 실제로 모니터링 그래프가 바뀌는 걸 보는 건 다른 느낌이었습니다.
Direct Connect는 가상 인터페이스, 즉 VIF(Virtual Interface)를 통해 트래픽을 목적지별로 분리합니다. VIF란 하나의 물리 회선 위에서 논리적으로 트래픽 유형을 나누는 가상 인터페이스로, 단일 VPC에 연결하는 프라이빗 VIF, S3 같은 퍼블릭 서비스에 접근하는 퍼블릭 VIF, Transit Gateway와 연동하는 전송 VIF 세 가지 유형이 있습니다. 초기 구성에서 저는 프라이빗 VIF만 설정했고, 전송 VIF의 존재는 나중에야 알았습니다.
그런데 여기서 제가 가장 뼈아프게 후회한 실수가 있습니다. 이중화 구성을 빠뜨린 것입니다. 회선 유지보수 공지를 못 보고 있던 사이 서비스 장애가 터졌습니다. 단일 회선으로만 연결해뒀으니 대안이 없었습니다. 그제서야 VPN을 백업 경로로 붙이는 Active-Standby 구성을 부랴부랴 갖췄습니다.
이후 Transit Gateway를 도입하면서 구조가 훨씬 깔끔해졌습니다. Transit Gateway란 여러 VPC와 온프레미스 네트워크를 중앙 허브 하나에 연결하는 AWS 관리형 라우터로, 허브-스포크 구조를 통해 각각의 VPC마다 별도 연결을 관리하는 복잡도를 대폭 줄여줍니다. 전송 VIF와 Transit Gateway를 연결하면 온프레미스에서 여러 VPC에 단일 회선으로 접근할 수 있어, VPC가 늘어날수록 효과가 커집니다.
이중화 설계, 처음부터 고려해야 할 것들
제 경험에서 얻은 가장 명확한 교훈은 이것입니다. 이중화는 운영 중에 붙이는 게 아니라 설계 단계에서 그려야 합니다.
Direct Connect 이중화를 설계할 때 현실적으로 고려할 수 있는 구성은 다음과 같습니다.
- Active-Active: 두 회선이 동시에 트래픽을 처리하며, 한 회선이 끊겨도 나머지가 전체를 감당합니다. 비용이 두 배지만 가용성이 높습니다.
- Active-Standby: 평소에는 Direct Connect를 주경로로, 장애 시 Site-to-Site VPN이 백업으로 동작합니다. 비용을 절충하면서 안정성을 확보할 수 있습니다.
- BGP MED 조정: MED(Multi-Exit Discriminator)란 BGP에서 외부 AS로 트래픽이 나갈 때 경로 선호도를 조정하는 속성으로, 수치가 낮을수록 우선순위가 높습니다. 이를 통해 Direct Connect를 기본 경로로, VPN을 보조 경로로 세밀하게 제어할 수 있습니다.
한 가지 더 짚어두고 싶은 부분이 있습니다. 하이브리드 클라우드를 마케팅 문구처럼 쓰는 분위기가 있는데, 정작 레거시 시스템 연동의 복잡도는 잘 설명되지 않습니다. 제 경험상 이건 좀 다릅니다. 보안 그룹, 라우팅 테이블, NAT 설정, DNS 해석까지 레이어 전반을 다 들여다봐야 하고, 전용 회선이 곧 '안전'이라는 착각도 경계해야 합니다. 회선 위에 암호화 정책, IAM 권한 분리, CloudTrail 로깅까지 별도로 쌓아야 진짜 보안입니다. 2025년 현재 하이브리드 클라우드는 국내외 IT 시장의 주요 흐름으로 자리잡고 있지만(출처: AWS Korea Blog), 조직 규모와 트래픽 규모에 맞지 않으면 Direct Connect의 비용 대비 효과는 오히려 낮아질 수 있습니다. 중소규모 환경이라면 VPN을 더 정교하게 설계하는 쪽이 현실적일 수 있습니다.
하이브리드 네트워크는 결국 '연결했다'가 끝이 아닙니다. 어떤 트래픽이, 어떤 경로로, 얼마나 안정적으로 흘러야 하는지를 처음부터 설계 문서에 담아야 합니다. 장애를 맞고 나서야 이중화를 붙이는 건 너무 비싼 수업료입니다. Direct Connect 도입을 검토 중이라면 LOA-CFA 발급부터 크로스 커넥트 구성, VIF 설계, BGP 우선순위 설정, 그리고 이중화 경로까지 전체 흐름을 먼저 그린 다음 구현에 들어가시길 권장합니다.
참고:
- - AWS 공식 문서 – Hybrid Network Connections: https://docs.aws.amazon.com/ko_kr/whitepapers/latest/hybrid-connectivity/hybrid-network-connections.html
- AWS Korea Blog – AWS Direct Connect 서비스 소개: https://aws.amazon.com/ko/blogs/korea/category/aws-direct-connect/
- 디지털서비스 이슈리포트 – 하이브리드 클라우드 2025 트렌드 (2025.02): https://m.digitalmarket.kr
- AWS Korea Blog – Amazon EKS Hybrid Nodes 출시 (2024.12): https://aws.amazon.com/ko/blogs/korea/use-your-on-premises-infrastructure-in-amazon-eks-clusters-with-amazon-eks-hybrid-nodes/