클라우드 시대에 개발자가 알아야 하는 인프라 지식

NAT(Network Address Translation)

그동안 IT 업계에서 고립돼 무소불위의 권력을 휘두르던 네트워크를 비롯한 인프라 기술들이 SDx(Software Defined Something)라는 한 단어에 휘둘리고 있다. 뜬구름 잡는 것 같았던 클라우드 기술이 현실화돼 더 이상 네트워크나 인프라 전문가가 없어도 대형 사이트를 운영할 수 있는 상황이 되기도 했다. 이번 시간에는 다양한 인프라 기술을 경험했던 필자의 경험을 살려 클라우드 시대에 개발자가 알면 좋을만한 네트워크, 서버, OS, 하드웨어의 지식들을 풀어서 설명하고자 한다.

IPv6는 역사상 가장 큰 IT 프로젝트지만 이에 대해 제대로 알고 있는 사람이 드물다. 정작 잘 알아야 하는 사람들은 전혀 관심이 없는 비운의 프로젝트로, 항간에서는 10년 넘게 말만 많았던 ‘양치기’ 프로젝트라고 부르기도 한다. 사실 IPv6는 네트워크, 인프라 엔지니어 보다는 애플리케이션 개발자가 더 먼저 알고 고려해야 하는 분야다. 이번 시간에는 IPv6와 관련된 개발에 대한 이야기는 다루지 않았다. 하지만 이번 시간에 다루는 내용들은 향후에 기고할 IPv6 개발 내용과 연계돼 진행될 것이니 참고 바란다.

개발자와 네트워크

최근에는 게임을 개발하는 개발자들을 제외하고는 직접 프로토콜을 만드는 사람이 드물다. 예전처럼 전문 데이터 하나를 보내기 위해 소켓 프로그램을 일일이 작성할 필요도 없고, 네트워크에 대한 지식이 많지 않아도 네트워크 프로그래밍을 할 수 있는 좋은 기반 기술들이 많기 때문일 것이다. 그러다 보니 정작 네트워크에서 여러 애플리케이션들이 문제가 되는 상황이 빈번이 발생하고 있다. 이번 시간에 다루려고 하는 NAT(Network Address Translation)를 고려하지 않고 네트워크 프로그램을 작성해도 프로그램이 동작하는 데는 큰 이상이 없는 것 같아 보인다. 하지만 이로 인해 여러 가지 문제들이 발생하고 성능에도 많은 영향을 끼칠 수 있다. 한국에서는 3G, LTE와 같은 모바일 망에서 CGN(Carrier Grade NAT)이라는 기술을 사용한다. SKT, KT, LG U+와 같은 큰 네트워크 망사업자가 공유기에서 사용하는 NAT 기술을 이용해 망을 운영하는 기술인데, 한마디로 표현하면 모바일 망 자체가 거대한 공유기로 운영된다고 생각하면 쉽게 상상이 될 것이다. 현재의 IPv4 주소로는 엄청나게 많은 모바일 단말을 수용할 수 없어서 어쩔 수 없이 이런 기술을 운용해야 하지만, 이로 인한 문제점도 적잖이 발생하고 있다.

일반적인 클라이언트-서버 프로그램을 작성한다면 NAT 환경에 대한 고려를 많이 하지 않아도 된다. 하지만 최근 많이 사용하는 P2P 기반의 앱, mVoIP, 메신저 등과 같이 시간에 민감하게 반응해야 하는 프로그램을 하고 있다면 꼭 NAT를 고려해야 한다. 최근 필자는 CGN 관련 기능을 정의하고 개발 요청해야 하는 업무와 관련해 테스트 방법론을 작성해 테스트 하고, 각종 표준 문서를 이용해 개발자가 쉽게 개발할 수 있도록 도와주는 업무를 맡았다. 테스트를 위해 시중에서 많이 사용되는 mVoIP 앱들을 테스트해 볼 기회가 있었는데, 어떤 한 소프트웨어는 감동을 줄 정도로 집요하게 최적의 경로를 찾아서 좋은 품질의 음성통화를 들려줬던 기억이 난다. 반면에 몇몇 소프트웨어는 같은 기능을 구현하는데도 너무 단순하게 동작해서 그 품질을 의심케 하는 것도 있었다.

RTT

한국은 인터넷 강국이다. 우리들이 일반적으로 네트워크 성능과 관련해 이야기하는 Bandwidth 부분에서도 세계 최강을 자랑하지만, 네트워크 상의 응답시간에 직접적인 영향을 끼치는 RTT(round trip time) 또한 매우 좋다. 그러다 보니 일반적으로 한국 개발자들은 네트워크 응답시간이 끼치는 시간에 대해 크게 고려하지 않는 경우가 많다. 업무와 관련해 필자가 진행했던 테스트에서도 한국에서 제작한 앱들은 정말 단순하게 동작하는 경우가 많았고, 해외에서 제작하거나 해외 사용자를 겨냥한 앱들에서는 대체적으로 굉장히 효율적으로 동작하도록 노력하는 모습들이 많이 보였다. 보통 RTT 값은 정보를 보냈을 때 상대방이 응답하는 시간에서 서버 처리시간을 뺀 값을 말한다. 이 값은 거리의 영향을 가장 많이 받는다. 한국 내에서는 10ms 이내, 일본은 50ms 이내, 말레이시아나 싱가폴 같은 동남아시아는 100ms 내외, 그리고 미국은 200ms 내외 이다.



메신저나 시간에 민감한 소프트웨어를 개발해야 한다고 가정해 보자. 서버가 한국에 있을 수 있지만 아마존 같은 해외 클라우드 서비스를 사용할 수도 있다. 사용자는 한국에서 사는 사용자만을 대상으로 할 수도 있지만, 한글 서비스를 하더라도 최근에는 해외 사용자가 무시하지 못할 만큼 많기 때문에 해외 사용자의 응답시간이나 성능도 고려해야 하는 주요 요소가 됐다.



네트워크 관련 앱을 만들 때 기존 클라이언트-서버 방식인 경우와 P2P 형태로 구현할 경우를 보자. 네트워크 응답시간에 차이가 거의 나지 않는 경우도 있지만 해외 사용자, 혹은 해외 서버가 존재할 경우에는 응답시간에 큰 차이가 있다는 것을 확인할 수 있다. 최대한 간단하게 비교하기 위해 로그온, 인증과 같은 컨트롤 과정을 제외하고 1개의 메시지를 통신하는데 3개의 turn이 발생한다고 가정해 본다(3way handshake + request + response + ack and close). 또한 2명의 사용자가 메시지를 서로 주고받는다면 대략 6개의 turn이 발생한다고 가정하자. 사실 P2P 프로그램에도 초기 로그온이나 추후 상세하게 설명할 STUN (Session Traversal Utilities for NAT) 기반의 네트워크 체크 로직 등이 있지만, 이 부분은 단순 비교를 위해서 일단은 무시하도록 한다. 여기서 STUN이란 단말끼리 직접 통신할 수 있도록 해 주는 프로토콜 관련 기반 기술로, P2P 프로그램에서 꼭 필요한 기능이다.



만일 네트워크 프로그래밍을 뛰어나게 잘하는 개발자라면 클라이언트-서버 방식이 아닌 P2P 방식으로 네트워크 애플리케이션을 구현할 것이다. <표 2>의 네트워크 응답시간에 따른 성능뿐만 아니라 또 다른 요소가 개발 방식을 바꾸는 주요 요소인데, P2P 방식의 경우에는 기본적으로 주요 프로세싱을 클라이언트 단말로 넘기기 때문에 초기에 큰 서버가 필요 없다. 거기에 STUN 기반으로 동작해서 중재 서버를 거치지 않고 사용자들끼리 직접적으로 데이터를 주고받게 된다면 서버의 네트워크 대역폭도 많이 사용하지 않게 된다. 네트워크를 고려하고 네트워크 상황에 최적화한 프로그래밍을 하게 될 경우 서버 운영비용도 많이 아낄 수 있고, 호스팅이나 클라우드 사용 시 네트워크 사용료도 많이 줄일 수 있다. 여기에 더해 사용자들이 느끼는 체감 성능은 엄청나게 올라가고 향후 해외 서비스까지도 원활하게 제공할 수 있을 것이다. 이처럼 굉장히 좋은 인프라라도 개발할 때 네트워크를 고려해야 하는 이유는 명확하다.

P2P 기반의 프로그램

처음 P2P 기반의 프로그램이 나왔을 때 많은 이들이 놀라워했던 기억이 떠오른다. 이름이 넵스터였던 걸로 기억하는데 mp3를 사용자끼리 공유하는 앱이 동작해야 하다 보니 고려해야 할 것이 많다. 하지만 더 복잡한 것은 직접적으로 두 P2P 사용자가 통신할 수 있도록 네트워크 상황을 체크하는 과정이다. 최적의 연결 방법을 찾아서 통신해야 하기 때문에 앱 개발 때 고려해야 할 부분이 많아진다. 특히 문제가 되는 부분은 두 PC 간에 직접적인 통신을 방해하는 NAT 장비나 방화벽 장비인데, 이 부분에 대해 보다 자세히 알아보자.

NAT는 왜 필요한가

처음 인터넷을 만들었을 때와 현재의 인터넷은 많은 부분에서 다르다. 군사용 혹은 연구용으로 지정된 사람들만 사용하던 인터넷이 이렇게 엄청나게 커질 것이라고는 아무도 예측하지 못했다. 그러다 보니 여러 부분에서 처음에는 고려하지 못했던 여러 가지 문제점이 발생하게 됐다. 그 중 가장 심각한 부분이 IP 부족 현상이다.



초창기에는 클래스별 할당이라는 방식으로 IP를 배분했었다. IP를 신청하면 1600만 개 단위로 IP를 할당한 것이다. 그 뒤로 IP가 부족해서 6만5000여개 단위로 변경되기는 했지만 막상 직원이 1만 명도 안 되는 회사에서 1600만 개(정확하게는 1677만7216개)나 6만5000개를 받게 되면, 나머지 사용하지 않는 주소들은 전 세계 어디에서도 사용할 수 없게 된다. 그러다 보니 주소가 너무 빨리 소진되게 됐고 처음 생각했던 인터넷 구조가 변경돼야 한다는 생각에 이르게 됐다. IP 부족 현상을 해결하기 위한 대안은 3 단계로 분류됐다.

1. 단기 해결책 : 서브네팅
2. 중기 해결책 : 주소 변환 - NAT
3. 장기 해결책 : IPng - IPv6

우선 IP 주소 할당의 불합리함을 극복하고 IP 대역을 잘게 쪼개서 효율적으로 사용할 수 있도록 하는 단기 해결책이 나오게 된다. 이로 인해서 인터넷이 좀더 복잡해지긴 했지만 주소 고갈 현상을 해결할 수 있는 아주 훌륭한 방법으로 평가된다. 이와 관련해 상세한 내용은 위키피디아(http://en.wikipedia.org/ wiki/IPv4_subnetting_reference)를 참고하기 바란다.

중기 해결책으로 나온 방법이 NAT이며, 근본적인 해결을 위한 장기 해결책이 IP Next Generation으로 불리우는 IPv6이다. 사실 단기, 중기 해결책이 너무 훌륭해서 장기 해결책인 IPv6가 도입 되는데는 상당히 오랜 시간이 걸렸다. 하지만 단기와 중기 해결책에는 단점도 있어서 서브네팅이나 NAT로 인한 네트워크 복잡성의 증가로 문제가 생길 경우 해결이 어려웠고, 네트워크 엔지니어뿐만 아니라 애플리케이션 프로토콜 개발자까지도 NAT 환경을 고려해서 개발해야 하는 어려움이 따랐다.

그래서 장기 해결책으로 IPv6를 표준화하고 개발하는 측에서는 NAT를 필요악으로 규정하고, IPv6 전환의 목표 중 하나를 간섭 없는 엔드투엔드 통신으로 규정할 정도로 NAT 기법을 없애도록 노력하고 있다.

IP 주소 고갈의 중기 해결책인 NAT

알면 알수록 NAT를 사용할 경우 고려해야 할 사항은 많아진다. 프로토콜 개발자는 개발자데로 고민해야 할 부분이 많아지고, 방화벽이나 네트워크 엔지니어는 엔지니어데로 NAT 때문에 생기는 문제점을 해결하기 위해 많은 고민이 필요하다. 사실 정확하게 모를 뿐이고 개발자와 인프라 운영자의 중간지대이기 때문에 고려되지 않는 부분도 종종 있다.

하지만 NAT가 당장 없어질 기술도 아니고, NAT를 알고 네트워크 프로그래밍을 하는 것과 그렇지 않은 것은 아주 큰 차이가 있기 때문에 이에 대해 상세히 알아보자. 앞서 이야기한데로 IP 주소 고갈의 중기 해결책인 NAT 기법은, 정확하게 얘기하자면 NAT에서 공식적으로 사용할 수 있는 주소 체계를 정의한 것과 같다. 사설 주소(Private IP Address)라고 부르는 주소들이 이에 속한다(RFC 1918 참조 : http:// www.rfc-editor.org/rfc/rfc1918.txt). 사설 주소는 인터넷 상의 어디에도 존재하지 않는다. 만일 이 주소를 사용할 때 인터넷과 연결하려면 NAT 기법을 이용해 IP 주소를 공인 IP 주소(Public IP Address)로 변환해서 내보내야 한다. 대부분의 회사에서 이를 사용하고 있다. 물론 집에서도 공유기를 통해서 NAT 기법을 사용하고 있는 사람들이 대부분이다.

<리스트 1> 사설 IP 주소
10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

NAT에도 한 가지 방법만 있는 것이 아니라 여러 가지 방법이 존재한다. 공인 주소와 사설 주소를 어떤 방식으로 매핑하느냐에 따라서 1:1, 1:N, M:N과 같은 형식으로 분류한다. 공인 IP와 사설 IP를 하나씩 매핑할 경우를 ‘1:1’, 공인 IP 하나로 하나 이상의 네트워크(여러 개의 IP)를 매핑할 경우 ‘1:N’, 여러 개의 공인 IP를 여러 개의 사설 IP로 변환할 경우 ‘M:N’이라고 부른다. 1:1 매핑 방식은 IP 주소를 절약하기 위한 기법이 아니라 관리와 보안상 사용하는 기법이기 때문에 이번 시간에는 주로 1:N NAT에 대해서 다루려 한다. 1:N 매핑은 NAT 방식 중 PAT (Port Address Translation) 방식이라고 불린다. 포트를 매핑하기 때문에 1개의 IP로 여러 명이 통신할 수 있다.

PAT 방식은 트랜스포트 레이어의 포트 번호를 변경한다. 1:1 매핑 방식이 아니기 때문에 PAT 기능을 제공하는 장비에서는 항상 NAT 테이블이라는 세션을 저장하는 세션 저장소를 가지고 있어야 하고 이로 인해 방향성이 생기게 된다. 마치 회사에서 전화를 하는데 직통 번호가 없을 경우, 내부 사용자는 외부로 9번을 누르면 전화를 외부로 바로 걸 수 있지만 외부 전화 사용자는 내부 사용자에게 직접적으로 전화를 걸 수 없는 경우와 같다.

NAT의 역사

NAT가 처음 만들어 지고, 사용되기 시작했을 때는 M:N NAT 기법이 주로 활용됐다. 지금처럼 초고속 인터넷이 당연하다고 생각하기 이전에는 PPP 접속이라는 방식으로 PC 통신 회사나 인터넷 연결을 중계해 주는 회사 쪽에 모뎀으로 전화를 걸어 인터넷을 연결했다.



혼자 모뎀을 이용해서 인터넷에 연결하면 간단하지만 회사에서 여러 명이 인터넷에 연결해야 할 경우 여러 가지 비용 문제가 발생한다.

1. 각 PC에 모뎀이 장착될 경우의 비용
2. 각 PC에서 각자 모뎀으로 인터넷을 연결할 경우 통제가 불가능
3. PPP 연결에 필요한 ID 유지비용

이런 문제들로 인해서 중앙 집중화된 인터넷 연결 장치가 필요하게 됐고, 인터넷 게이트웨이에 여러 개의 모뎀이 장착돼 사용됐다. 마치 회사에서 ‘9’번을 눌러서 외부에 전화를 하는 것처럼 인터넷이 필요할 경우 인터넷 연결 시스템(게이트웨이) 장비를 통해서 현재의 전화 시스템과 유사하게 인터넷을 연결한 것이다.



실제로 과거에는 회사에 50명이 근무한다면 외부로 전화를 걸 수 있는 국선은 5개 정도만 신청하는 것이 일반적이었다. 모든 사람이 동시에 외부와 전화 통화를 할 일이 드물기 때문에 이런 디자인이 가능했던 것인데, 인터넷 시스템도 전화 회선을 이용했기 때문에 비슷하게 디자인됐던 것으로 추정된다. 이때의 인터넷 연결 시스템도 전화처럼 인터넷 연결을 시도하면 모뎀과 외부 회선 하나를 점유해야 했고, 5개의 모뎀이 있는 시스템이라면 전체 회사에서 동시에 5명만이 인터넷을 할 수 있었다.

전화 네트워크와 인터넷 네트워크

전화는 써킷(Circuit) 네트워크라 불린다. 한 명이 전화를 걸 경우 말을 하든 안하든 간에 회선 전체를 점유하게 되기 때문이다. 반면 현재 사용되는 인터넷 기술들은 모두 패킷 기반의 네트워크다. 회선을 한 명이 점유하는 것이 아니라 도로 위의 자동차들처럼 패킷이라는 단위로 데이터가 잘게 쪼개져서 여러 명이 회선을 공유해 사용할 수 있다. 이 기술이 인터넷 연결 시스템에 적용되면서 하나의 모뎀으로 여러 명이 동시에 인터넷을 연결할 수 있게 됐는데, 이때 적용된 기술이 1:N NAT이다. 말 그대로 공인 IP 한 개로 여러 명이 동시에 연결할 수 있게 해주는 기술로, 각 세션을 식별하고자 포트 번호를 변경해 통신하게 되기 때문에 이 기술을 PAT(Port Address Translation)라고 부르기도 한다. 1:N NAT 즉, PAT 기술을 통해서 공인 IP를 많이 아낄 수 있게 됐는데 이 기술에는 큰 단점이 있다. 우선 가장 큰 단점은 앞서 언급했던 것처럼 통신에 방향성이 생긴다는 점이다. 전용번호가 없는 회사에 전화를 걸 때를 생각해 보자. 직통번호가 없는 회사는 외부로 전화를 거는 것은 가능하나 전화가 올 때는 특정 사람만 받을 수 있다.

PAT를 사용하면 내부에서 시작한 세션에 대해서는 정상적인 처리를 통해 통신이 가능하지만, 외부에 있는 사용자가 먼저 세션을 시작할 경우에는 내부의 사용자와 통신이 불가능하다. 이런 특징이 보안을 강하게 해 준다고 생각하고, 보안 때문에 PAT를 도입하는 회사도 꽤 있는 듯하다. 하지만 사실 반만 맞는 얘기다. NAT의 보안에 대해서는 다음 시간에 STUN, TUN과 관련된 내용과 함께 다룰 예정이다.

NAT가 애플리케이션과 프로토콜에 끼치는 영향

이제 본격적으로 NAT(PAT)가 네트워크 프로그래밍에 끼치는 영향에 대해 알아보자. 초기에 PAT 기술이 나오고 난 후, 그리고 뒤이어 PAT 기술을 방화벽에 적용한 SPI(Stateful Packet Inspection) 엔진 기반의 방화벽이 나오고 난 후 몇 가지 통신 문제가 발생하게 된다. 여기서 SPI란 3세대 방화벽 엔진 기술로 현재 대중적으로 사용되고 있는 방화벽과 공유기에서 제공하는 기본적인 보안 기능을 말한다.



첫 번째 문제는 비동기 애플리케이션의 경우에 생기는 문제다. 예를 들면 비동기 애플리케이션을 작성했는데, 각자 보내고 받는 프로세스가 분리돼 있고 세션을 맺는 방향이 A에서 B, B에서 A 형태로 2개이면 PAT에서는 한 방향만 정상적인 통신이 가능하다. 내부에서 외부로 가는 세션은 정상적으로 통신이 가능하지만 외부에서 내부로 들어오는 세션은 세션 성립 자체가 불가능하기 때문이다. 문제에 대한 해결책은 여러 가지 방향이 있는데, 이에 대해서는 추후 기고에서 다룰 예정이다.



두 번째 문제는 컨트롤 프로토콜과 데이터 프로토콜을 나눠서 다른 프로세스로 동작시키는 경우다. 패킷이 PAT를 거치면서 주소를 변환하게 되는데, 이때 PAT 장비(공유기나 방화벽)는 컨트롤 프로토콜과 데이터 프로토콜이 하나의 애플리케이션이라는 것을 인지하지 못한다. 컨트롤 및 데이터 관련 프로세스가 달라서 다른 포트를 사용할 때, 방향성은 같더라도 주기적으로 패킷이 발생하지 않으면(컨트롤 프로세스만 주기적으로 패킷을 발생시키거나 그 반대 일 경우) 중간에 있는 PAT 장비에서 세션을 종료(expire)시킬 수 있다.



세 번째 문제는 애플리케이션 프로토콜 내부에 IP 주소를 넣어서 사용하는 경우다. 클라이언트와 서버가 통신할 때 클라이언트 IP를 이용해서 무언가 동작해야 하는 상황이 발생한다면, PAT 장비가 IP 주소를 변환하고 난 후에 정상적으로 동작하지 않을 수 있다. 왜냐하면 IP 주소는 PAT에 의해 변경됐더라도 애플리케이션 헤더 안에 있는 IP 주소는 그대로이기 때문이다. 최근 P2P 관련 애플리케이션들은 대부분 이런 이슈들을 가지고 있다. 그렇기 때문에 대부분의 잘 짜여진 P2P 애플리케이션들은 NAT를 식별하고 어떻게 동작하는지의 여부까지도 인지할 수 있도록 개발되고 있다.

사례로 보는 PAT의 문제점

예전에 데이터센터를 이전할 때, 특정 애플리케이션에 IP 주소를 넣어서 문제가 된 적이 있었다. 대외계에서 카드사와 서로 인증할 때 IP 주소를 애플리케이션 헤더 안에 넣어서 서로 인증을 하는 경우였는데, 데이터센터 이전을 완료하고도 일주일 동안 카드 포인트 전환 승인이 나지 않아서 엄청나게 고생했던 기억이 아직도 생생하다. PAT를 사용하게 될 경우 이런 문제점들이 발생하게 된다. 이 문제를 해결하기 위해서 여러 가지 각도로 여러 분야의 사람들이 노력해 왔고, 지금은 이런 문제들이 많이 일어나지는 않는다. 그렇지만 무작정 알지 못하는 상태로 잘 동작한다고, 마냥 그대로 사용할 수만은 없다. 앞서 이야기한 개인적인 사례처럼 변경이 일어났을 경우 큰 문제가 발생할 수 있고, 주위 환경과 기술도 지속적으로 변하고 있기 때문에, 특히 앞으로 다가올 IPv6 환경에서 기존에 사용하던데로 똑같이 사용한다면 여러 가지 문제가 발생할 수 있다. 그렇다면 이런 NAT를 사용하면서 생기는 문제점들을 어떻게 피할 수 있을까 그리고 무사히 NAT 장비를 통과할 수 있도록 하기 위해서는 어떤 사항이 고려돼야 할까

NAT의 문제점 해결

첫 번째 방법은 프로토콜을 개발할 때, NAT 환경을 고려하는 것이다. 보통 NAT Traversal이라고 불리는 기능을 프로토콜을 개발할 때 추가적으로 넣는다. 한마디로 표현하면 프로토콜 자체에서 NAT 환경을 고려해 NAT 장비를 잘 통과하도록 변경하는 기능이다. SIP라던지 IPSEC이라는 프로토콜들은 이런 기능을 가지고 있다. 두 번째 방법은 중간에 있는 PAT나 방화벽 장비에서 이런 프로토콜들을 이해하고 자신이 애플리케이션 내용까지 확인해서 변경하는 방법이다. 보통 이런 기능을 ALG(Application Layer Gateway)라고 부르고 시중에 나오는 방화벽들은 이런 ALG 기능을 몇 개 수준에서 수십 개 수준까지 지원한다. 하지만 이런 기능에도 제약은 따른다.

1. 우선 잘 알려진 프로토콜이어야 한다. 방화벽이나 PAT 장비에서 이해할 수 있을 만큼 많이 사용하고 표준화된 프로토콜이어야 한다.
2. 반대로 새로 개발된 최신 프로토콜의 경우 구현이 어렵다. 그리고 사용자가 직접 개발한 프로토콜은 지원이 되지 않는다고 보면 된다.
3. 방화벽과 PAT 장비 성능에 무리가 따른다. ALG 기능 구현을 위해서 애플리케이션 레이어 프로토콜을 일일이 확인하고 변경해 줘야하기 때문에 이 기능을 사용할 경우 원래 계획된 성능보다 장비 성능이 많이 떨어질 수 있다.

이런 제약 사항들 때문에 최근 CGN(Carrier Grade NAT : SKT, KT, LG U+ 같은 대형 사업자에서 사용하는 NAT 기술)에서는 가능하면 ALG 기능을이 ALG 기능을 사용하지 못한다면 PAT를 사용할 때 오래된 프로토콜이나 P2P 프로그램들을 정상적으로 사용할 수 없을 것이다. 그래서 CGN 기술에서 사용하는 NAT는 다른 대안을 가지고 있다. 이 부분에 대한 이해와 표준, 그리고 테스트 방법과 같은 내용은 다음 시간에 상세하게 다룰 예정이다.