Cloud Modernization 23
Site-to-Site VPN과 Direct Connect 선택 기준
둘 다 사내망과 AWS를 연결하는 기술이라 속도, 보안, 비용, 구축 시간의 trade-off가 보이지 않는다.
근거 · 교안 p94-p98
1장: VPN의 본질: 암호화된 인터넷 터널의 장점과 한계
솔라의 스마트폰 화면 위로 하얀 와이파이 아이콘이 선명하게 떠 있었다. 카페의 무료 와이파이에 막 접속한 참이었다. 잠시 후, 솔라는 익숙하게 VPN 앱을 열어 연결 버튼을 눌렀다. 화면 상단에 작은 열쇠 모양 아이콘이 나타나며, 이제부터 이 기기에서 오가는 모든 데이터가 암호화된 터널을 통과할 것임을 알렸다.
사무실에서 AWS 클라우드로 시스템을 이전하는 프로젝트를 맡은 이후, 솔라의 머릿속은 온통 ‘연결’이라는 단어로 가득 차 있었다. 특히 ‘Site-to-Site VPN’과 ‘Direct Connect’라는 두 가지 선택지를 두고 며칠째 고민 중이었다. 기술 문서에서 본 한 문장이 계속 맴돌았다. ‘VPN은 퍼블릭 인터넷을 통해 암호화된 터널로 연결한다.’
“언니, 잠깐만.”
마주 앉아 노트북을 보던 루나가 고개를 들었다.
“나 지금 이 카페 와이파이 쓰면서 회사 VPN 켰거든? 그런데 이상해. VPN은 인터넷으로 연결하는 거니까, 느리고 불안정하다고 생각했는데… 그냥 앱 하나 켜니까 바로 연결되고, 속도도 그럭저럭 괜찮네.”
솔라는 스마트폰을 가볍게 흔들며 말했다.
“그런데 우리 회사 전체 네트워크를 이걸로 AWS랑 연결해도 되는 걸까? 인터넷망을 쓰는 거면 중요한 데이터가 오갈 때 위험한 거 아니야? 속도도 보장 안 될 거고.”
솔라의 말에는 ‘인터넷’이라는 단어에 대한 막연한 불안감이 섞여 있었다. 누구나 쓰는 공용망, 예측할 수 없는 속도, 잠재적인 보안 위협 같은 이미지들.
루나는 솔라의 스마트폰과 그 위로 뜬 와이파이 및 열쇠 아이콘을 잠시 바라보았다. 그리고는 질문을 되돌렸다.
“방금 VPN 연결하는 거, 어려웠어?”
“아니? 그냥 버튼 한 번 누르니까 됐는데. 1초도 안 걸렸어.”
“그게 VPN의 첫 번째 특징이야. ‘구축 시간’.”
루나는 테이블 위 냅킨에 펜으로 간단한 그림을 그리기 시작했다. 한쪽에는 ‘솔라 폰’이라고 쓰고, 다른 쪽에는 구름 모양을 그려 ‘AWS’라고 적었다.
“지금 솔라 네 폰에서 AWS까지 데이터가 어떻게 여행할까? 우선 이 카페 공유기를 거치고, KT든 SK든 인터넷 서비스 제공업체(ISP)의 복잡한 네트워크를 지나가겠지. 수많은 라우터를 거쳐서 마침내 AWS 데이터 센터에 도착할 거야. 이 길은 우리가 선택하거나 통제할 수 없어. 그냥 ‘인터나이트’라는 거대한 공공 도로망을 그대로 이용하는 거지.”
솔라는 고개를 끄덕였다. 바로 그 점이 마음에 걸렸다.
“그러니까! 그 공공 도로에 아무나 돌아다니잖아. 그럼 우리 회사 데이터도 위험한 거 아니냐는 말이지.”
“맞아. 그래서 ‘터널’이 필요한 거야.”
루나는 ‘솔라 폰’과 ‘AWS’ 구름 사이에 구불구불한 점선을 그린 뒤, 그 점선을 따라 두꺼운 직선 터널을 덧그렸다.
“VPN은 그 시끄럽고 붐비는 공공 도로 위에 우리만 쓸 수 있는 비밀 통로를 만드는 기술이야. 이 터널은 아주 강력한 암호화 기술로 만들어져 있어서, 밖에서는 터널 안으로 무엇이 지나가는지 전혀 볼 수 없어. 데이터라는 화물을 특수 제작한 장갑차에 실어 보내는 것과 비슷해.”
“아…”
솔라의 눈이 반짝였다. 막연했던 개념이 구체적인 이미지로 잡히기 시작했다.
“그럼 보안은 괜찮다는 거네. 어차피 암호화된 장갑차로 옮기니까. 길에서 누가 훔쳐봐도 내용물은 안전하고.”
“정확해. Site-to-Site VPN은 데이터를 전송하는 동안 기본적으로 암호화해. 하지만 중요한 건, 그 장갑차가 달리는 ‘도로’ 자체는 여전히 퍼블릭 인터넷이라는 점이야.”
루나는 덧그린 터널을 펜 끝으로 톡톡 쳤다.
“만약 출퇴근 시간에 도로에 차가 몰리면 어떻게 될까? 아무리 내 차가 튼튼한 장갑차라고 해도, 도로가 꽉 막히면 서행하거나 멈출 수밖에 없지. 인터넷 트래픽이 몰리는 시간대나, 경로 상에 문제가 생기면 VPN 연결 속도도 덩달아 느려질 수 있다는 뜻이야. 속도를 보장할 수 없는 거지.”
솔라는 비로소 흩어져 있던 조각들을 맞출 수 있었다. VPN의 장점과 한계는 ‘퍼블릭 인터넷’이라는 기반의 양면성이었다.
“알겠다. 정리해보면… VPN은 이미 깔려 있는 인터넷망을 쓰니까, 구축은 엄청 빠르고(앱 켜듯이), 비용도 전용선을 까는 것보다 훨씬 저렴하겠네. 보안도 ‘암호화 터널’ 덕분에 해결되고. 하지만 이 모든 건 ‘공공 도로’를 이용한다는 전제 위에서니까, 도로 사정에 따라 속도가 널뛰기할 수 있다는 거구나.”
솔라는 자신이 막연하게 가졌던 ‘인터넷이라서 느리고 위험하다’는 생각이 얼마나 단순했는지 깨달았다. 위험한 건 ‘암호화 터널’로 막고, 느린 것은 ‘어쩔 수 없는’ 트레이드오프였던 것이다.
새로운 관점을 얻자, 곧바로 다음 질문이 떠올랐다.
“그렇다면 언니, Direct Connect는 이 ‘공공 도로’를 아예 안 쓰는 방식인 거야? 우리 회사에서 AWS까지 누구의 방해도 받지 않는 초고속 전용 도로를 직접 까는 개념인가? 그건 또 얼마나 다를까?”
2장: Direct Connect의 본질: 전용 광 링크의 가치와 대가
솔라의 질문이 채 끝나기도 전에, 루나는 자신의 노트북을 돌려 솔라에게 보여주었다. 화면에는 타임랩스 영상이 재생되고 있었다. 거대한 지하 관로를 따라 굵고 노란 광케이블 다발이 뱀처럼 미끄러지듯 깔리고 있었다. 장면이 바뀌자, 하얀 방진복을 입은 기술자들이 복잡하게 얽힌 서버 랙 사이에서 그 노란 케이블을 조심스럽게 끌어와 특정 포트에 연결했다. 화면 가득한 케이블들은 마치 정교하게 짜인 혈관처럼 보였다.
이것이 솔라가 기술 문서에서 읽었던 ‘데이터 센터에서 AWS 리소스까지 전용 광 링크를 구축한다’는 문장의 실체였다. 막연했던 개념이 압도적인 현실감으로 다가왔다.
“와… 정말 우리 회사만을 위한 고속도로를 까는 거네.”
솔라는 감탄하며 화면에서 눈을 떼지 못했다. VPN이 기존 도로 위에 암호화된 차선을 그리는 것이라면, 이건 아예 새로운 물리적 도로를 건설하는 것처럼 보였다.
“저렇게 우리 회사 데이터 센터랑 AWS를 직접 연결하면, 다른 차들이 끼어들 틈이 없으니까 속도는 무조건 보장되겠네. 우리만 쓰는 길이니까 안전은 말할 것도 없고. 그냥 최고 속도, 최고 보안이잖아?”
솔라의 목소리에는 ‘전용선’이라는 단어가 주는 절대적인 신뢰감이 묻어났다. 비싸고 오래 걸리는 만큼, 모든 면에서 완벽할 것이라는 기대였다.
루나는 영상을 잠시 멈췄다. 화면에는 기술자의 손에 들린 노란색 광케이블 끝단이 선명하게 보였다. 루나는 그 케이블 끝을 펜으로 가리켰다.
“이 길은 우리만 쓸 수 있는 ‘사유지’가 맞아. 그래서 다른 차들과 엉켜 교통체증이 생길 일이 없지. 속도가 일정하고 예측 가능한 가장 큰 이유야.”
그러고는 솔라를 보며 물었다.
“그런데, 이 사유지를 달리는 화물 트럭은 장갑차일까, 아니면 일반 트럭일까?”
“어…?”
예상치 못한 질문에 솔라는 잠시 말문이 막혔다. 장갑차는 시끄러운 공공 도로에서 데이터라는 화물을 지키기 위해 필요했던 것이었다.
“우리만 쓰는 안전한 사유지니까… 굳이 튼튼한 장갑차가 필요 없지 않나? 그냥 일반 트럭으로 실어 날라도 괜찮을 것 같은데.”
“바로 그 점이야.”
루나가 말했다.
“Direct Connect는 회사와 AWS 사이에 누구도 침범할 수 없는 물리적인 전용 통로를 만들어. 인터넷처럼 경로가 수시로 바뀌거나 다른 트래픽과 섞이지 않아. 하지만 이 통로는 데이터를 안전하게 ‘전달’할 뿐, 데이터 자체를 ‘보호’해주지는 않아. VPN의 ‘암호화 터널’ 같은 기능은 기본적으로 없어.”
루나는 멈춰둔 영상 속 케이블을 다시 한번 가리켰다.
“데이터는 저 케이블 안에서 아무런 포장 없이, 있는 그대로의 모습으로 달려가. 물론 외부인이 이 사적인 경로에 들어와 엿보는 건 거의 불가능에 가깝지. 하지만 ‘암호화’가 기본은 아니라는 게 중요해. 만약 금융 정보나 개인정보처럼 규제 때문에 반드시 암호화가 필요한 데이터를 전송한다면, 이 전용 도로 위에서도 데이터를 따로 암호화(예를 들어 VPN을 함께 사용)해야 할 수도 있어.”
솔라의 머릿속에서 ‘전용선 = 완벽한 보안’이라는 단순한 공식이 깨지는 소리가 났다.
“아… 그렇구나. 길 자체는 안전하지만, 그 위를 달리는 데이터는 무방비 상태일 수 있다는 거네. 속도와 안정성을 얻는 대신, 암호화는 우리의 선택이자 책임이 되는 거구나.”
솔라는 다시 영상으로 시선을 돌렸다. 지하 관로를 설치하고, 수많은 케이블을 정리하고, 물리적으로 장비를 연결하는 복잡한 과정이 빠르게 스쳐 지나갔다.
“그리고 이 모든 과정… VPN처럼 소프트웨어로 몇 분 만에 설정하는 거랑은 비교도 안 되게 복잡하고 오래 걸리겠지. 통신사와 계약하고, 선로 공사하고… 당연히 비용도 훨씬 비쌀 거고.”
솔라는 이제 Direct Connect가 가진 가치와 그 대가를 명확히 구분할 수 있었다. 그것은 무조건적인 상위 호환 기술이 아니었다. 명확한 트레이드오프를 가진 또 하나의 선택지였다.
VPN이 ‘공공 도로 위의 암호화된 장갑차’라면, Direct Connect는 ‘건설 비용과 시간이 많이 드는 비포장 전용 도로’와 같았다. 도로는 빠르고 안정적이지만, 그 위를 달릴 차(데이터)의 보안은 운전자의 몫이었다.
생각이 정리되자 새로운 질문이 고개를 들었다. 두 가지 선택지의 장단점과 본질적인 차이는 이제 알겠다. 하지만 진짜 문제는 이제부터였다.
“그럼 언니, 우리 프로젝트에는 대체 뭘 써야 하는 거야? 빠른 구축과 저렴한 비용이냐, 아니면 예측 가능한 고성능이냐… 단순히 이것만 보고 결정할 수는 없을 것 같아. 속도, 보안, 비용, 구축 시간, 이 네 가지를 저울 위에 올려놓고 우리 회사 상황에 딱 맞는 걸 고르는 기준이 필요해.”
3장: 최적의 연결 선택: 비즈니스 요구사항에 따른 트레이드오프 의사결정
솔라의 노트 위에는 깔끔하게 두 개의 열이 그려져 있었다. 왼쪽 열의 제목은 ‘VPN’, 오른쪽 열은 ‘Direct Connect’였다. 솔라는 지난 며칠간 루나와 나눈 대화를 정리하며 각 기술의 핵심 특징을 나름대로 요약했다. VPN 아래에는 ‘빠른 구축’, ‘저렴’, ‘인터넷 기반(속도 변동)’이라는 단어가, Direct Connect 아래에는 ‘느린 구축’, ‘비쌈’, ‘전용선 기반(속도 안정)’이라는 단어가 적혀 있었다.
표는 완성되었지만, 솔라의 고민은 조금도 해결되지 않았다. 오히려 명료하게 정리된 장단점들이 그녀를 더 깊은 혼란으로 밀어 넣었다. 표를 가만히 들여다보던 솔라는 결국 펜을 내려놓고 한숨을 쉬었다. 이분법적인 비교는 아무런 답을 주지 못했다. ‘빠른 것’과 ‘안정적인 것’ 사이에서, ‘저렴한 것’과 ‘고성능인 것’ 사이에서, 그녀의 생각은 시소처럼 오가기만 할 뿐이었다. ‘속도가 중요하면 Direct Connect, 비용이 중요하면 VPN’이라는 결론은 너무나 단순해서 현실의 복잡한 문제에 아무런 도움이 되지 않았다.
솔라의 미간에 잡힌 주름을 본 루나가 조용히 그녀의 노트 쪽으로 시선을 옮겼다. 루나는 솔라가 만든 표를 잠시 보더니, 말없이 새 페이지를 펼쳐 가로로 긴 네모 상자 세 개를 나란히 그렸다. 그리고 각 상자 위에 짧은 문장을 하나씩 적어 넣었다.
시나리오 1: 갑작스러운 서비스 장애로, 다른 지역에 긴급히 백업 시스템을 가동해야 할 때시나리오 2: 다음 분기까지 사내 데이터 센터의 수십 테라바이트 데이터를 클라우드로 모두 옮겨야 할 때시나리오 3: 1밀리초의 지연도 용납할 수 없는 실시간 금융 거래 시스템을 운영해야 할 때
루나는 펜을 솔라에게 건넸다.
“솔라. 이 표 위에 기술 이름을 올려놓지 말고, 이 상황들 아래에 한번 놓아봐. 어떤 도로가 필요한지.”
솔라는 루나가 만든 세 개의 시나리오를 꼼꼼히 읽어보았다. 더 이상 VPN과 Direct Connect라는 기술 이름은 보이지 않았다. 대신 ‘긴급 복구’, ‘대규모 이전’, ‘초저지연’이라는 구체적인 ‘요구사항’이 눈에 들어왔다. 질문의 관점이 완전히 바뀌어 있었다. ‘어느 기술이 더 좋은가?’가 아니라, ‘이 일에는 어떤 도구가 맞는가?’를 묻고 있었다.
솔라는 첫 번째 시나리오, ‘재해 복구(DR)’ 상자 아래에 펜을 가져갔다.
“긴급 상황… 일단 가장 중요한 건 속도 아닐까? 시스템이 빨리 복구되어야 하니까. 그럼 Direct Connect…?”
말을 내뱉는 순간, 솔라는 스스로의 말에 모순을 느꼈다. Direct Connect는 구축에 몇 주, 혹은 몇 달이 걸리는 물리적인 공사였다. ‘긴급’ 상황과는 전혀 어울리지 않았다.
“아니, 아니지. 재해는 언제 터질지 모르는데, 미리 전용선을 깔아두는 건 비효율적일 수 있어. 사용하지도 않는 비싼 도로를 놀리는 셈이잖아. 이럴 땐… 인터넷만 있으면 몇 분 안에 바로 연결할 수 있는 VPN이 훨씬 유리하겠구나. 일단 급한 불부터 끄는 게 중요하니까.”
솔라는 ‘시나리오 1’ 아래에 ‘VPN (신속한 임시 도로 확보)’이라고 적었다. 생각이 명확해지자 확신이 생겼다.
이어서 두 번째 시나리오로 넘어갔다. ‘대규모 데이터 이전’.
“이건 반대네. 수십 테라바이트나 되는 데이터를 옮기려면 도로가 무조건 넓고 안정적이어야 해. VPN처럼 공공 도로를 쓰면 언제 끝날지 알 수 없고, 중간에 데이터가 유실될 위험도 커져. 구축에 시간이 좀 걸리더라도, 한 번에 대량의 화물을 확실하게 실어 나를 수 있는 전용 도로, 즉 Direct Connect가 필요해. 프로젝트 기간 안에만 개통되면 되니까.”
솔라는 ‘시나리오 2’ 아래에 ‘Direct Connect (대용량 화물 운송을 위한 전용 도로)’라고 썼다.
마지막으로 세 번째 시나리오, ‘실시간 금융 거래’를 보았다. 이제는 망설일 필요가 없었다.
“금융 거래는 매 순간이 중요해. 인터넷의 트래픽 상황에 따라 지연 시간이 1밀리초라도 출렁인다면 큰 사고로 이어질 수 있어. 이건 비용이나 구축 시간을 따질 문제가 아니야. 무조건 예측 가능하고 안정적인 성능이 보장되어야 해. 정답은 Direct Connect네.”
솔라는 ‘시나리오 3’ 아래에도 ‘Direct Connect (일관된 속도 보장이 필수적인 도로)’라고 적고 펜을 내려놓았다.
세 가지 시나리오 아래에는 각기 다른 이유로 선택된 연결 방식이 명확하게 자리 잡고 있었다. 솔라는 자신이 처음 그렸던 단순한 흑백 논리의 표와, 지금 완성된 구체적인 상황 기반의 선택지를 번갈아 보았다.
‘빠르니까’, ‘싸니까’가 아니었다. ‘긴급하니까’, ‘대규모니까’, ‘안정적이어야 하니까’라는 비즈니스의 요구사항이 기술 선택의 기준이 되어야 했다. VPN은 ‘빠르게 구성 가능한 암호화 인터넷 터널’이었고, Direct Connect는 ‘물리 계약과 전용 회선이 필요한 안정적 고대역 연결’이었다. 각 기술의 본질을 이해하고 나니, 어떤 상황에 어떤 도구를 써야 할지가 비로소 보였다.
솔라는 자신의 노트북을 열어 빈 문서에 제목을 입력했다.
[AWS 연결 방식 제안서]
그리고 첫 번째 섹션으로 ‘주요 비즈니스 요구사항 분석’이라는 소제목을 달았다. 더 이상 기술의 장단점을 나열하는 대신, 자신들의 프로젝트가 풀어야 할 진짜 문제가 무엇인지부터 정의하기 시작했다. 초기 프로토타이핑 단계의 속도, 향후 예상되는 데이터 트래픽, 반드시 준수해야 할 보안 규제 등. 솔라의 손가락이 자신감 있게 키보드를 두드렸다. 그녀는 이제 최적의 연결 방식을 선택하고 그 이유를 명확하게 설명할 수 있었다.