지사 SD-WAN vs 기존 VPN: 비용·성능·운영 3차원 비교

시나리오 설정: 5~10개 지사의 실제 부담

지난달 미윈에서 장비 임대업을 하는 회사가 저를 찾아왔습니다. 주변 두 거점을 막 인수한 터였는데, 기존 VPN이 갑자기 병목이 되어버렸습니다. 프로젝트 매니저는 전화 너머로 한숨을 쉬며 말했습니다. “본사에서 ERP 시스템을 ping하면 200ms가 넘고, 창고 쪽은 더 심해서 견적서 하나 보내는 데 30초를 기다릴 때도 있습니다.” 이건 개별 사례가 아닙니다. 지사 수가 2~3개에서 5개 이상으로 늘어나면 기존의 스타형 VPN 토폴로지는 한계를 드러내기 시작합니다. 본사 출구 라우터가 모든 암호화 터널을 감당하면서 동시에 애플리케이션 라우팅 정책까지 처리해야 하니, CPU 사용률이 연중 70%에서 시작합니다. 이런 시나리오는 베이징 주변 제조업이나 체인 유통 기업에서 매우 흔합니다. 이 글에서는 하드웨어 투자, 회선 품질, 애플리케이션 경험 세 가지 차원에서 SD-WAN과 기존 VPN을 낱낱이 풀어보며, 지금 솔루션 선정을 진행 중인 IT 책임자가 마음의 기준을 잡도록 돕고자 합니다.

하드웨어 투자: 일회성 비용과 장기 분할 상각

기존 VPN 방식은 하드웨어 측면의 진입 장벽이 확실히 낮습니다. 주요 제조사의 통합 라우터(화웨이 AR, H3C MSR 시리즈)는 800~2,000위안/대 수준이면 기본적인 암호화 포워딩 요구를 충족할 수 있고, 8개 지사에 본사 코어 장비 한 대를 더해도 총 하드웨어 예산을 2만 위안 이내로 묶는 것은 어렵지 않습니다. 조달 주기도 짧아서 징둥에서 주문하면 3일 안에 전부 도착하고, 설정도 이틀이면 가동됩니다. 그런데 여기에는 숨은 함정이 있습니다. 단일 장비의 성능 상한이 매우 낮다는 점입니다. 1,500위안짜리 라우터는 IPsec 터널을 최대로 열면 처리량이 표기값의 40%-50%에 그치는 경우가 많습니다. 업무 피크 시간이 되면 패킷 손실과 지연이 무작위로 나타나기 시작하고, 운영 담당자는 장비를 재부팅해 임시로 버티는 방법밖에 없습니다. SD-WAN의 하드웨어 논리는 완전히 다릅니다. Viptela, Cisco Meraki, 화웨이 AC-CONNECT로 대표되는 제품은 CPE 장비 자체 가격이 3,000~8,000위안/대 구간(포트 수와 License 라이선스에 따라 다름)으로, 언뜻 보면 기존 라우터보다 3~5배 비쌉니다. 하지만 이런 하드웨어는 “제로 구성 온보딩”을 전제로 설계되었습니다. 장비에 전원을 넣고 네트워크에 연결하면 컨트롤러에서 정책을 자동으로 가져오므로, 하드웨어 차원에서 대수별 파라미터 조정이 필요하지 않습니다. 8개 지사를 모두 배포 완료하는 실제 공기는 2 영업일로 단축할 수 있습니다. 저희가 순이의 한 자동차 부품 업체의 마이그레이션을 도왔을 때 산출해본 적이 있습니다. 원래 6개 지사가 각각 저가형 라우터를 구매했는데, 3년 안에 장비 노후화와 성능 부족으로 4대를 차례로 교체해 누적 하드웨어 투자가 1만 8,000위안이었습니다. SD-WAN 방식으로 바꾼 뒤에는 일회성 투자 3만 2,000위안이 들었지만 5년 내 하드웨어 교체 계획이 없어, 연간으로 나누면 오히려 비용이 더 낮습니다.

링크 집약과 대역폭 효율: 누가 진짜로 네트워크를 활용하는가

기존 VPN이 다중 링크를 다루는 방식은 “액티브-스탠바이 전환”입니다. 광대역 두 회선을 끌어와 하나는 주력으로, 다른 하나는 콜드 스탠바이로 둡니다. 문제는 예비 회선의 대역폭이 늘 유휴 상태로 남고, 전환 시 30~90초의 라우팅 수렴 시간 동안 모든 업무가 중단된다는 점입니다. 실시간 연결이 필요한 POS 시스템이나 재고 동기화에는 경험이 상당히 나쁩니다. SD-WAN의 링크 집약은 서로 다른 통신사 광대역 여러 개(차이나 모바일, 차이나 유니콤, 차이나 텔레콤 혼합)를 하나의 자원 풀로 보고 스케줄링합니다. 애플리케이션 식별로 업무 유형을 파악한 뒤 핵심 트래픽을 최적 경로에 동적으로 배분합니다. 제가 본 전형적인 구성이 있습니다. 한 매장이 200M 차이나 모바일 가정용 회선과 100M 차이나 유니콤 비즈니스 전용선을 동시에 연결했는데, SD-WAN 컨트롤러가 실시간 회선 품질에 따라 ERP 트래픽은 차이나 유니콤 전용선(지연이 더 낮음)으로, 위챗 미니프로그램 주문 요청은 차이나 모바일 회선(대역폭이 더 큼)으로 보내 두 링크의 이용률을 동시에 최대로 끌어올렸습니다. 이런 정밀 스케줄링은 본사 집중형 시나리오에서 특히 효과가 큽니다. 기존 VPN 구조에서는 본사 출구 라우터가 모든 지사 트래픽의 합류점이어서, 8개 지사가 동시에 업무 데이터를 업로드하면 본사 측에 혼잡이 생기기 쉽습니다. SD-WAN은 지사 간 “동서 방향 트래픽”의 직접 통신을 지원해 본사 중계를 건너뛰므로, 다지사 협업 시나리오에서 본사 출구 대역폭의 30% 이상을 절약할 수 있습니다.

애플리케이션 식별과 클라우드 직통: 핵심 업무를 가장 안정적인 길로

애플리케이션 식별은 SD-WAN의 핵심 경쟁력 중 하나입니다. 기존 IPsec VPN은 IP 주소와 포트만 인식할 뿐, 돌아가는 것이 SAP인지 화상회의인지 알지 못하고, 두 업무의 우선순위를 어떻게 구분해야 하는지는 더더욱 모릅니다. 직원이 근무 시간에 회사 네트워크로 BT 자료를 받으면 VPN 라우터는 대역폭으로 버티는 수밖에 없고, 핵심 업무는 큐 뒤로 밀립니다. SD-WAN 장비에는 DPI(심층 패킷 검사) 엔진이 내장되어 수천 종의 애플리케이션 프로토콜을 식별할 수 있습니다. 딩톡, 위챗 워크, SAP GUI, Oracle ERP는 물론 각종 SaaS 서비스의 트래픽 특성까지 포함합니다. 식별한 뒤에는 정책을 연결할 수 있습니다. 예를 들어 “ERP 시스템 트래픽은 항상 전용선으로 우선 전달”, “P2P 다운로드 트래픽은 1Mbps로 속도 제한” 같은 방식입니다. 이런 규칙은 컨트롤러에서 일괄 배포되어 모든 지사에 즉시 적용되며, 라우터마다 로그인해 설정을 바꿀 필요가 없습니다. 또 하나 쉽게 간과되는 기능은 클라우드 직통(Cloud OnRamp)입니다. 기존 VPN의 트래픽 모델은 “지사 → 본사 → 인터넷”으로, 모든 클라우드 접속이 본사 출구를 우회해야 합니다. 지점 직원이 알리바바 클라우드의 OMS 시스템에 접속할 때 경로는 “지점 → 본사 VPN 터널 → 본사 라우터 → NAT 외부 → 알리바바 클라우드”로, 단방향에 홉이 3~4번 겹쳐 지연 누적이 매우 두드러집니다. SD-WAN의 클라우드 직통은 지사 CPE 측에서 클라우드 사업자까지 최적화 터널을 직접 맺을 수 있습니다. Azure, AWS, 알리바바 클라우드를 예로 들면, SD-WAN 컨트롤러가 최적 출구 지점을 계산해 트래픽을 가장 가까운 POP 노드에서 클라우드로 바로 올려보내, 본사라는 중계 지점을 우회합니다. 저희가 의료기기 유통 기업에 배포할 때 그 회사는 전국에 7개 창고가 있었고, 예전에는 본사 ERP에 접속하려면 베이징 본사의 NAT를 거쳐야 했지만 지금은 각 창고가 알리바바 클라우드 항저우 노드에 직결되어 평균 지연이 85ms에서 32ms로 떨어졌고, 주문 응답 속도는 두 배 이상 빨라졌습니다.

운영 업무량: “소방수”에서 “규칙 조정”으로

제가 이끌었던 운영 팀에는 불문율이 하나 있었습니다. 당직을 서는 사람은 지사 회선 단절만은 겪지 않기를 빌어야 한다는 것이었습니다. 기존 VPN 환경에서 장애 원인 파악은 기술이 필요한 일입니다. 먼저 통신 회선 측 문제인지 VPN 터널 자체의 문제인지 확인하고, 본사 라우터에 로그인해 터널 상태 테이블을 본 다음, 지사 장비를 한 대씩 ping하며 위치를 좁혀야 합니다. 이런 추적 경로는 지사 8개 규모에서도 문제 근원을 찾는 데 빠르면 40~60분이 걸리며, 그동안 업무 부서의 재촉 전화가 끊이지 않습니다. SD-WAN은 이 업무 방식을 바꿉니다. 모든 지사 CPE의 상태, 회선 품질, 트래픽 분포가 컨트롤러 플랫폼에 집계되어, 운영 담당자가 웹 콘솔을 열면 8개 지사의 온라인 상태가 한눈에 들어오고, 빨간색으로 표시된 노드는 “이좡 매장의 차이나 유니콤 전용선 패킷 손실률 8%”라고 바로 알려줍니다. 장애 위치 파악 시간은 10분 이내로 단축됩니다. 신규 지사 추가 절차의 차이는 더욱 뚜렷합니다. 기존 VPN 방식에서는 지사를 하나 추가하려면 장비 구매 → 현장으로 택배 발송 → 현장 IT 담당자가 본사 라우터에 로그인해 터널 파라미터 설정 → 테스트 검증의 과정을 거쳐야 하며, 이 흐름이 빨라도 3~5 영업일이 걸립니다. SD-WAN의 논리는 “제로 터치 구성”입니다. 새 장비가 현장에 도착해 전원을 넣고 네트워크에 연결하면 컨트롤러에서 템플릿 설정을 자동으로 가져오고, 운영 담당자가 플랫폼에서 “가동 승인”을 한 번 누르면 끝이므로 서비스 창구는 2시간 이내로 단축할 수 있습니다.

1. 장애 위치 파악 시간: 기존 VPN 40~90분 vs SD-WAN 5~15분
2. 신규 지사 가동: 기존 VPN 3~5 영업일 vs SD-WAN 2~4시간
3. 정책 일괄 배포: 기존 VPN은 대수별 로그인 필요 vs SD-WAN 컨트롤러 원클릭 동기화
4. 일상 점검: 기존 VPN은 로그 수동 추출 vs SD-WAN은 회선 품질 보고서 자동 생성

물론 SD-WAN도 새로운 학습 비용을 수반합니다. 컨트롤러 플랫폼 자체에 일정한 구성 논리가 있어, 초기에는 애플리케이션 인식, 정책 라우팅 같은 개념을 이해하는 데 시간을 들여야 합니다. 하지만 이 투자는 가치가 있습니다. 템플릿을 한 번 만들어두면 이후 운영 부담은 계속 줄어들며, 기존 방식처럼 지사 수가 늘어날수록 선형으로 불어나지는 않기 때문입니다.

비용/성능/운영의 3차원 결론

이 비교를 한 문장으로 요약하자면: 기존 VPN은 지사 5개 이내, 트래픽 모델이 단순하고 예산이 극도로 빠듯한 시나리오에서는 여전히 비용 우위가 있습니다. 그러나 지사 수가 7~8개 이상이고, 비즈니스의 클라우드 애플리케이션 의존도가 높으며, 운영 팀이 “수동적 소방”에서 “능동적 관리”로 전환하기를 기대한다면 SD-WAN의 종합적 가치가 분명히 우위를 점합니다. 5~10개 지사가 바로 이 임계 구간에 해당합니다. 전자라면 “그럭저럭 쓸 만하다”고 느끼겠지만, 후자라면 경험의 병목을 뚜렷하게 체감하게 됩니다. 더 중요한 것은 IT 투자의 회계가 하드웨어 구매 비용만으로 계산되어서는 안 된다는 점입니다. 운영 인력의 숨은 비용, 지사 확장의 비즈니스 손실, 장애 시간의 기회비용은 방안을 평가할 때 흔히 과소평가됩니다. 저희는 많은 고객을 위해 total cost of ownership(TCO) 분석을 진행해 왔으며, SD-WAN은 3년 주기 내 종합 투입이 기존 방안보다 더 낮은 경우가 많습니다. 네트워크 아키텍처 업그레이드를 평가하고 계신다면, 먼저 현재 네트워크 아키텍처 다이어그램을 정리하신 후 저희에게 연락해 맞춤형 비교 방안을 받아보시기 바랍니다. Siwenlide는 베이징에서 IT 운영 분야에 14년간 깊이 종사해 왔으며, 수많은 지사 네트워크 개조 사례를 다뤄왔습니다. 성숙한 방안과 현지 서비스 대응력이 저희의 핵심 경쟁력입니다.