Hacker News를 눈팅하다가 제 편두통을 유발하는 질문을 하나 발견했습니다.
"공용 네트워크에서 VXLAN over WireGuard가 낫나요, 아니면 WireGuard over VXLAN이 낫나요?"
질문자는 아마 꽤나 진지하게 고민했을 겁니다. 하지만 15년 차 엔지니어의 관점에서 이 질문은 마치 "폭탄을 안고 불 속으로 뛰어들까요, 아니면 불을 붙이고 폭탄을 던질까요?"라고 묻는 것과 같습니다.
결론부터 말하자면, 둘 다 하지 마세요. 정말 불가피한 상황이 아니라면, 네트워크 오버레이를 중첩하는 건 새벽 3시에 PagerDuty 알람을 스스로 예약하는 행위입니다.
오늘은 왜 이런 '터널 속의 터널' 구조가 엔지니어의 수명을 갉아먹는지, 그리고 굳이 하겠다면 무엇을 조심해야 하는지 이야기해보겠습니다.
1. MTU 지옥: 당신의 패킷은 이미 잘려나가고 있다
네트워크 엔지니어링에서 가장 간과하기 쉬우면서도 치명적인 것이 바로 MTU(Maximum Transmission Unit)입니다.
보통 인터넷 상의 MTU는 1500 바이트입니다. 여기에 프로토콜 헤더가 붙습니다. VXLAN 헤더가 붙고, 그 위에 WireGuard 헤더가 붙습니다. 거기에 IP 헤더, UDP 헤더까지 감안하면 실제 데이터(Payload)가 들어갈 공간은 급격히 줄어듭니다.
이든 그 반대든, 패킷을 이중으로 감싸는 순간(Encapsulation), 오버헤드는 눈덩이처럼 불어납니다.
결과가 어떨까요?
- 단편화(Fragmentation) 발생: 패킷이 MTU를 초과하여 조각납니다.
- 성능 저하: 라우터와 서버 CPU가 조각난 패킷을 처리하느라 비명을 지릅니다.
- Silent Drop: 어떤 방화벽은 조각난 패킷을 보안 위협으로 간주하고 조용히 버립니다.
로그에는 아무런 에러도 없는데, 특정 API 호출만 타임아웃이 나는 유령 같은 장애. 그게 바로 이 MTU 설정 미스에서 옵니다. 제가 네이버 검색 인프라팀에 있을 때, 이런 '보이지 않는 패킷 드랍' 때문에 3일 밤을 새운 적이 있습니다. 범인은 결국 잘못 설정된 터널링 MTU였습니다.
2. VXLAN은 보안 도구가 아닙니다
Hacker News 댓글 중 가장 핵심을 찌르는 지적은 이것입니다.
OpenBSD 매뉴얼에 따르면 VXLAN은 '신뢰할 수 있는 환경'을 위해 만들어졌습니다.
VXLAN은 기본적으로 암호화를 제공하지 않습니다. 그냥 L2 네트워크를 L3 위로 확장해 주는 기술일 뿐입니다. 이걸 공용 인터넷망에 그대로 노출시킨다? 대문을 활짝 열어두고 "도둑님, 들어오세요" 하는 꼴입니다.
그러니 굳이 둘 중 하나를 택해야 한다면, VXLAN over WireGuard가 맞습니다. WireGuard가 튼튼한 암호화 터널(L3)을 뚫어주고, 그 안에서 VXLAN(L2) 통신을 태우는 것이죠.
하지만 여기서 다시 묻고 싶습니다. 왜 굳이 L2를 인터넷 너머로 확장하려 하시나요?
3. 구글을 따라 하지 마세요
어떤 댓글 작성자가 이렇게 말하더군요. "구글은 내부적으로 IPSec, VXLAN 등을 3중으로 꼬아서 씁니다. 계층이 침해되더라도 정보를 숨기기 위해서죠."
이 말을 듣고 "오, 구글이 하니까 나도 해야지"라고 생각했다면 당장 멈추십시오.
당신은 구글이 아닙니다.
구글은 전용 광케이블을 깔고, 네트워크 장비의 펌웨어부터 커널까지 직접 뜯어고치는 회사입니다. 그들은 MTU를 제어할 수 있고, 패킷 손실을 하드웨어 레벨에서 커버할 수 있습니다.
우리는 AWS나 IDC의 범용 회선을 빌려 쓰는 처지입니다. 구글의 아키텍처를 흉내 내다가는 가용성은커녕, 복잡도에 깔려 운영팀만 죽어납니다. 넷플릭스에서도 수만 대의 인스턴스를 관리하지만, 불필요한 네트워크 복잡도는 죄악으로 취급합니다.
4. XY 문제를 의심하라
이 스레드에서 가장 현명한 댓글은 기술적인 분석이 아니라 이 질문이었습니다.
"도대체 뭘 하려는 건가요? (What problem are you trying to solve?)"
질문자는 아마 "서로 다른 리전에 있는 서버들을 마치 같은 스위치에 물려있는 것처럼(L2) 통신하게 하고 싶다"는 욕구가 있었을 겁니다. 그래서 VXLAN을 떠올렸고, 보안 때문에 WireGuard를 섞으려 했겠죠.
하지만 현대적인 클라우드 아키텍처에서 L2 네트워크를 WAN 구간으로 확장하는 것(Stretching L2)은 안티 패턴입니다. 브로드캐스트 스톰이 글로벌하게 퍼질 수 있고, 트러블 슈팅 난이도가 기하급수적으로 올라갑니다.
대부분의 경우, 그냥 L3 라우팅만으로 해결되거나, 애플리케이션 레벨에서 서비스 디스커버리를 사용하는 것이 훨씬 깔끔합니다.
5. 죽지 않고 일하려면
엔지니어로서 기술적 호기심, 이해합니다. 저도 주니어 때는 온갖 오픈소스를 덕지덕지 붙여서 '나만의 멋진 아키텍처'를 만드는 게 꿈이었습니다. 하지만 시니어가 되고 스태프 레벨이 되면서 깨달은 진리는 하나입니다.
Simple is safest.
새벽 3시에 장애가 났을 때, 안에 이 있고 그 안에 태그가 붙어있는 패킷을 디버깅하고 싶으신가요? 저는 절대 사양입니다.
만약 여러분이 지금 복잡한 터널링 구조를 설계하고 있다면, 잠시 모니터에서 눈을 떼고 스스로에게 물어보세요.
"이게 정말 최선인가? 단순히 L3 라우팅이나 VPN 하나로 끝낼 수는 없는가?"
화려한 아키텍처가 연봉을 올려줄 것 같지만, 실제로는 시스템의 안정성이 여러분의 연봉과 수면 시간을 지켜줍니다. 99.999%의 가용성을 목표로 하다가 여러분 인생의 가용성을 0%로 만들지 마세요. 투박하더라도, 3년 뒤의 후임자가 욕하지 않을 단순한 구조를 만드십시오.
