티스토리 뷰

TECH AND AI/DEVOPS

ALB가 외부 종단인 아키텍처에서 IPv6 듀얼스택을 '아직' 보류한 이유 - "왜 지금은 안 켰는가"라는 결정 근거를 찾는 독자에게

ebson 2026. 4. 27. 22:19
  •  

들어가며

VPC를 새로 그리는 자리에 앉을 때마다 한 번쯤은 "그래서 IPv6는 어떻게 하실 건가요"라는 질문이 따라옵니다. 듀얼스택을 켜 두는 일이 마치 모던 인프라의 표지처럼 받아들여지는 분위기도 분명히 있습니다. 그러나 듀얼스택이 만들어내는 효용과 그것이 데려오는 운영 비용은 분리해서 살펴봐야 합니다. 둘을 같은 표 위에 올려놓고 단순히 더해 봤을 때, 합계가 양(+)인 아키텍처가 있고 음(-)인 아키텍처가 있다고 생각합니다.

본 글에서 정리하려는 것은 개인 프로젝트로 VPC를 설계하고 IaC로 구축하는 과정에서 "지금 단계에서는 IPv6 듀얼스택을 적용하지 않는다"는 결정을 내린 흐름입니다. 실제 트래픽이 흐르는 운영 단계의 회고가 아니라 설계와 구축 단계에서 검토한 가정과 합계를 정리하는 글이라는 점을 먼저 밝혀 둡니다. 결정 자체보다는 그 결정에 다다르기 위해 어떤 항목을 어떤 무게로 따져 보았는지, 그리고 그 결정을 나중에 뒤집을 수 있도록 어떤 흔적을 설계 안에 남겨 두었는지를 함께 적어 보려 합니다. 사실관계는 가능한 한 AWS 공식 문서에서 확인되는 범위 안에서만 다루겠습니다. 같은 결정에 다다른 자리라도 그 근거가 서로 다를 수 있고, 정답을 제시하기보다는 결정 회계의 한 사례를 공유하는 정도로 읽어 주시면 좋겠습니다.

결정의 근거를 두 줄로 요약하면 다음과 같습니다.

근거 1. 외부 종단이 ALB와 그 앞단의 CloudFront로 그려져 있기 때문에, IPv6 엔드포인트가 외부 사용자에게 직접 보이지 않습니다. 따라서 IPv6 도입에서 흔히 기대하는 '대외 가치' 항목이 거의 비어 있습니다.

근거 2. 듀얼스택을 켤 경우 SG, NACL, 라우팅 테이블, IaC 모듈, Flow Logs 등의 운영 항목이 실질적으로 두 배가 됩니다. AWS 공식 문서를 따라가 보면 데이터 계층의 일부 서비스가 IPv6 엔드포인트를 전면 지원하지는 않음을 안내하고 있습니다.

 


이 프로젝트의 외부 종단 구조와 IPv6 엔드포인트의 가치

이 프로젝트가 설계한 외부 종단은 단순한 EC2가 아닙니다. 사용자의 트래픽은 CloudFront에 먼저 닿고, WAF를 경유해 ALB에 도달하며, ALB가 다시 Private 서브넷의 워크로드로 트래픽을 분배하는 구조로 그려져 있습니다. 이 구조에서 IPv6 사용자가 마주하는 종단은 CloudFront이지 ALB가 아닙니다. CloudFront는 IPv4와 IPv6 클라이언트를 모두 받아들이도록 설정할 수 있고, 그 설정은 오리진 측 프로토콜과 독립적으로 동작합니다. 즉, 오리진인 ALB가 IPv6 엔드포인트를 갖고 있든 그렇지 않든, 외부 IPv6 사용자의 접속에는 영향이 없습니다.

이 점이 본 글의 출발점입니다. 흔히 IPv6 듀얼스택을 도입하는 가장 큰 동기는 'IPv6 사용자가 우리 서비스에 접속할 수 있어야 한다'입니다. 그러나 이 프로젝트의 아키텍처에서는 그 요구가 CloudFront 한 단계에서 이미 충족됩니다. 그렇다면 ALB와 그 뒤 사설망에서 IPv6를 켜는 일은 어떤 추가 가치를 만드는가, 라는 질문이 자연스럽게 따라옵니다. 외부 사용자에게는 사실상 보이지 않으며, 내부 워크로드 사이의 트래픽도 사설 IPv4 안에서 충분히 다뤄질 것으로 예상됩니다. 결정 회계의 '대외 가치' 칸이 0에 수렴한다는 의미입니다.

물론 IPv6 도입은 외부 가시성 외에도 여러 부수적 이점을 제공합니다. NAT Gateway 비용을 줄일 가능성, IPv4 주소 고갈에 대한 장기적 방어, 일부 서비스에서 IPv6 전용 엔드포인트가 제공하는 기능 차이가 그것입니다. 이 항목들 하나하나는 가볍게 무시해도 될 이야기는 아닙니다. 다만 이 프로젝트가 가정한 트래픽 패턴과 비용 구조를 두고 봤을 때, 이 항목들이 듀얼스택 도입에 따른 운영 비용을 상쇄할 만큼 크지는 않다는 판단이었습니다. 같은 AWS 위에서도 자리마다 다른 결론에 도달할 수 있는 종류의 판단이라고 생각합니다.


두 배가 되는 운영 항목, 회계로 환산해 보기

듀얼스택을 켤 때의 비용은 어디서 발생할까요. 항목별로 나누어 보면, 운영의 거의 모든 곳에서 IPv4 규칙과 IPv6 규칙이 별도의 라인으로 관리됩니다. 이 점이 회계 관점에서 가장 무겁게 다가오는 부분입니다.

먼저 보이는 것은 Security Group입니다. AWS 공식 문서는 Security Group 규칙을 작성할 때 IPv4와 IPv6의 CIDR을 별도로 지정하도록 안내합니다. 같은 의미를 갖는 정책도 IPv4 한 줄, IPv6 한 줄로 두 번 적게 됩니다. Security Group에는 규칙 수의 한도가 있고, 공식 문서에 그 기본 값이 명시되어 있습니다. 듀얼스택 환경에서는 의미상 한 줄짜리 정책이 두 줄을 차지하므로, 한도에 닿는 속도가 그만큼 빨라집니다. quota를 늘리는 일이 불가능한 것은 아니지만, 이는 곧 SG 하나가 표현하는 정책의 복잡도를 키우는 일이기도 합니다. 정책이 복잡해지는 만큼 리뷰와 디버깅의 비용이 함께 늘어납니다.

NACL도 같은 결을 따릅니다. 인바운드와 아웃바운드 룰 모두 IPv6 미러링이 필요합니다. NACL은 본디 stateless하고 규칙 번호 기반이라 사람의 실수에 더 민감한 영역입니다. 룰을 미러링하는 과정에서 한쪽만 갱신되거나 번호가 어긋나는 사고가 발생하기 쉽고, 이런 사고는 종종 즉시 드러나지 않습니다. 한 쪽 IPv4 트래픽은 잘 흐르는데 IPv6 트래픽만 막힌다든가 그 반대 상황이 시간 차를 두고 발견되는 식입니다. 사고가 묶음으로 오는 것이 아니라 서로 다른 평행선에서 따로따로 도착한다는 점이 운영 입장에서 가장 까다롭습니다.

라우팅 테이블도 두 항목으로 늘어납니다. IPv4의 0.0.0.0/0 기본 경로 외에, IPv6의 ::/0 경로를 별도로 관리해야 합니다. 그리고 Private 서브넷의 IPv6→IPv6 아웃바운드는 NAT Gateway가 아니라 Egress-only Internet Gateway를 통해야 합니다. AWS 공식 문서는 IPv6 인스턴스의 IPv6 인터넷 아웃바운드에는 Egress-only IGW를 사용한다는 점을 분명하게 안내하고 있습니다. NAT Gateway는 NAT64를 통해 IPv6→IPv4 변환을 자동으로 제공하므로 "IPv4 전용"으로 단정하기보다는 "IPv6→IPv6 아웃바운드 경로는 아니다"라고 이해하는 편이 정확합니다. 이 차이는 IPv6 라우팅을 처음 그려보는 엔지니어들이 한 번씩 헷갈려 하는 지점이기도 합니다. 같은 '아웃바운드 게이트웨이'라는 단어 아래 서로 다른 역할의 자원이 존재한다는 사실 자체가, 운영 문서와 신규 입사자 온보딩 문서를 두 갈래로 나뉘게 만듭니다.

조금 더 깊이 들어가면 Flow Logs와 IaC 모듈에서도 양분이 일어납니다. VPC Flow Logs의 필드는 IPv4와 IPv6 주소를 모두 담을 수 있도록 설계되어 있지만, 후속 분석 파이프라인이나 알람 룰에서 두 가지 형식을 모두 처리하도록 명시적으로 다듬어야 합니다. 출발지 주소를 정규식으로 잡거나 CIDR 매칭을 거는 룰이라면, IPv6 표기 규칙(짧은 표기, 압축 표기, 대소문자 차이)에 맞춰 다시 검토해야 합니다. IaC 모듈에서는 assign_ipv6_address_on_creation, ipv6_cidr_block 같은 속성이 추가되며, VPC·서브넷·Security Group·Route Table 모듈이 모두 듀얼스택을 인지하도록 다시 정리되어야 합니다. 변수 하나를 추가하는 일이 아니라, 모듈의 조합 가능성과 디폴트 값의 의미가 달라지는 변경이라는 점을 강조하고 싶습니다.

이렇게 항목을 적어 두고 보면, '두 배가 된다'는 표현이 단지 수사적 강조가 아님을 알게 됩니다. SG, NACL, 라우팅 테이블, Flow Logs, IaC 모듈, 정책 리뷰 절차, 사고 시 디버깅 동선까지 거의 모든 운영 항목이 IPv4 라인과 IPv6 라인이라는 두 평행선을 갖게 됩니다. 어떤 자리에서는 이 두 평행선이 충분히 감당할 수 있는 비용일 수 있고, 어떤 자리에서는 그렇지 않을 수 있습니다. 이 프로젝트의 경우 후자에 가까웠다는 정도로 정리해 두고 싶습니다.


AWS 공식 권고와 데이터 계층의 IPv6 한계

AWS는 IPv6 도입을 점진적으로 확대해 왔으며, 공식 문서에서도 듀얼스택 설계를 권장하는 흐름이 분명합니다. 컴퓨트 측면에서는 Fargate가 듀얼스택 작업을 지원하도록 진화해 왔고, 이 변경은 플랫폼 버전 정책과 함께 안내되어 왔습니다. 정확한 플랫폼 버전과 지원 범위는 시점에 따라 차이가 있을 수 있으므로 AWS 공식 문서에서 최신 상태를 확인하시는 편이 안전합니다. 본 글에서는 어떤 시점에 어떤 기능이 GA되었는지를 단정하지 않겠습니다.

이 프로젝트의 결정에 더 큰 영향을 미친 것은 데이터 계층의 IPv6 지원 현황이었습니다. AWS 공식 문서를 따라가 보면, 데이터 계층의 일부 서비스에서 IPv6 엔드포인트의 지원 범위와 조건이 컴퓨트 계층만큼 균일하지 않다는 점이 확인됩니다. 예를 들어 Amazon MSK의 부트스트랩 서버 엔드포인트나 Aurora MySQL 클러스터의 Writer 엔드포인트는 IPv6 지원의 조건이 단순하지 않으며, 클러스터 구성·엔진 버전·엔드포인트 종류에 따라 다르게 안내됩니다. 이 프로젝트가 채택한 데이터 계층 구성에 IPv4 전용으로 묶이는 경로가 하나라도 남아 있다면, 사설망 내부에서는 결국 IPv4가 권위 있는 경로로 남게 됩니다. 그 위에 IPv6를 한 겹 더 얹는 일은 데이터 흐름의 단순성이라는 가치와 충돌합니다.

이 지점에서 한 가지 표현은 분명히 해 두고 싶습니다. AWS의 IPv6 지원이 부족하다는 이야기가 아닙니다. 공식 문서가 안내하는 범위 안에서, 컴퓨트 계층은 듀얼스택으로 운영하기에 충분한 옵션을 제공하고 있습니다. 다만 이 프로젝트가 채택한 데이터 서비스 조합에서만큼은, IPv6 경로가 트래픽 종단까지 균일하게 닿지 않는 구간이 남아 있고, 그 구간이 IPv6 도입의 효용을 깎는 요소로 작용했다는 의미입니다. 같은 AWS라도 어떤 서비스 조합을 쓰느냐에 따라 듀얼스택 합계는 달라질 수 있다고 생각합니다.

온프레미스 환경과 비교해 보면, 사내망은 거의 IPv4-only로 구성되는 경우가 많고 듀얼스택은 보통 LB나 WAF의 앞단에서 종단되는 형태로 다뤄집니다. 클라우드의 경우에도 외부 종단을 ALB나 CloudFront에 맡기는 구조라면, 사실상 사내망과 비슷한 트래픽 모형이 사설망 안에서 재현되는 셈입니다. 이 프로젝트의 결정은 그런 구조적 유사성과 자연스럽게 맞물려 있습니다. 온프레와 클라우드를 단순 비교하기 위해서가 아니라, 듀얼스택의 효용이 종단의 위치에 따라 어떻게 달라지는지를 설명하는 보조선으로 짚어 두는 정도입니다.


결정의 가역성을 남기는 설계

지금 시점에서는 IPv6 듀얼스택을 켜지 않기로 했지만, 이 결정이 영구적이라고는 생각하지 않습니다. AWS의 IPv6 지원은 계속 확장되고 있고, 이 프로젝트가 가정한 트래픽 패턴이나 비용 구조도 시간이 지나면서 변할 수 있습니다. 그래서 설계 단계에서 '나중에 IPv6를 도입할 여지'를 의도적으로 남겨 두기로 했습니다.

가장 눈에 띄는 흔적은 CIDR 계획입니다. VPC 전체 CIDR 안에 Reserved 영역(예: 10.30.128.0/17)을 비워 두었고, 이 영역은 추후 듀얼스택 도입 시 IPv4 측 서브넷을 다시 분할할 필요가 생기더라도 흡수할 수 있도록 잡혀 있습니다. IPv4 서브넷이 한 번 그려진 뒤에는 재분할이 매우 까다롭다는 점, 그리고 듀얼스택을 도입하면 서브넷별로 IPv6 /64를 추가 할당하면서 라우팅 정책을 다시 짜야 한다는 점을 함께 고려한 결정입니다. 구체적인 CIDR 회계는 본 시리즈의 다른 글에서 더 자세히 다룰 예정입니다.

물리적 흔적뿐 아니라 절차적 흔적도 남겨 두었습니다. Egress-only IGW를 도입할 위치, 각 서브넷에 IPv6 /64를 차례대로 배정할 순서, 듀얼스택 도입 시 SG와 NACL을 어떤 PR 단위로 쪼갤지에 대한 메모가 운영 문서에 함께 적혀 있습니다. 한 번에 모든 자원에 IPv6를 켜는 것이 아니라, 일부 서브넷에서 시작해 점진적으로 적용 범위를 넓힐 수 있도록 시나리오를 분할해 두었습니다. 이렇게 해 두면 IPv6 도입의 비용을 한 번에 일시불로 지불하지 않고 분할 결제하듯이 풀어낼 수 있습니다.

가역성을 강조하는 이유는 단순합니다. 인프라 결정은 '옳다/그르다'의 이분법으로 환원되기 어렵고, 환경이 바뀌면 같은 결정이 다른 합계를 갖게 됩니다. 합계가 음(-)이라는 이유로 듀얼스택을 보류했지만, 합계를 다시 계산해야 할 시점이 분명히 옵니다. 그때 가서야 처음부터 설계를 다시 그리는 일은 피하고 싶었습니다. '오늘의 결정이 내일의 자유도를 깎지 않도록' 하는 것이 인프라 설계에서 늘 머릿속에 두려는 원칙입니다.


마무리 — '안 쓴다'가 아니라 '아직 쓰지 않는다'

이 글에서 정리한 결정을 한 줄로 줄이면, "지금 우리 아키텍처에서 IPv6 듀얼스택의 합계가 음(-)이기 때문에, 운영 단순성을 우선해 보류하되 가역성을 남겨 둔다"가 됩니다. '안 쓴다'가 아니라 '아직 쓰지 않는다'는 차이는 작아 보여도 작지 않습니다. 전자는 환경이 변해도 결정을 유지하는 태도이고, 후자는 환경의 변화를 기다리는 태도입니다.

개인적으로 이 결정을 정리하면서 얻은 인사이트는, 인프라의 '모던함'이라는 표현이 종종 한 가지 합계만을 가정한다는 점이었습니다. 듀얼스택은 기본적으로 좋은 방향이지만, 그 가치가 실제로 발현되는 지점은 외부 종단의 위치, 데이터 계층의 IPv6 지원 정도, 정책 관리에 들일 수 있는 여력 같은 여러 변수에 의해 결정됩니다. 어떤 자리에서는 합계가 양(+)이고, 어떤 자리에서는 같은 결정이 음(-)으로 떨어집니다. 그러므로 인프라의 현대성을 평가하는 기준은 어떤 기능을 켜 두었는가가 아니라, 그 결정을 내릴 때 어떤 합계를 계산해 보았는가에 더 가깝다고 느끼게 되었습니다.

또 하나 남는 인상은, 좋은 설계가 결정을 잘 내리는 일만큼이나 결정을 잘 보류하는 일을 포함한다는 점입니다. CIDR의 Reserved 영역을 비워 두고 Egress-only IGW의 도입 시점과 절차를 미리 적어 두는 일은 당장의 코드를 늘리지 않습니다. 하지만 미래의 결정 비용을 줄이는 가장 저렴한 방법이기도 합니다. 인프라는 한 번 그려진 선이 오래 남는 영역이라, 처음 그릴 때 비워 두는 공간이 곧 나중의 자유도가 됩니다. 본 시리즈의 다음 글들에서는 이 글이 짧게 언급한 CIDR 회계와 SG·NACL의 책임 분담 같은 항목을 한 단계 더 내려가 다뤄 볼 예정입니다. 이 글이 비슷한 자리에서 같은 고민을 마주한 분들의 결정 회계에 작은 참고가 되기를 바라며 마무리합니다.


참고한 공식 문서

'TECH AND AI > DEVOPS' 카테고리의 다른 글

왜 prod에는 NAT Gateway 3개를, dev/beta에는 1개를 두었는가 — 환경별 회계의 한 줄 변수 — 환경별 가용성 분기를 고민하는 SRE/DevOps 엔지니어에게  (0) 2026.04.29
왜 Private-App 서브넷을 /20으로 잡았는가 - Fargate ENI 한 개의 무게로 본 CIDR 회계 - "/24가 아니라 /20인 이유"의 산술적 근거를 찾는 독자에게  (0) 2026.04.28
CI/CD와 Jenkins 4편 - Jenkins를 관측 가능하게 : Prometheus Plugin, OpenTelemetry Plugin, Pushgateway  (0) 2026.04.20
CI/CD와 Jenkins 3편 - Jenkins Declarative Pipeline을 운영에서 버티게 만드는 다섯 가지 설계 결정  (0) 2026.04.20
CI/CD와 Jenkins 2편 - Spring의 CI/CD: 여섯 가지 선택지와 Jenkins를 선택하는 기준  (0) 2026.04.20