IP 주소, 공인과 사설로 갈리는 이유

아파트에서 305호라고 하면 그 단지 안에서는 통하지만 택배는 오지 않아요. 단지 밖에서도 통하는 도로명 주소가 따로 있어야 해요. 같은 집에 성격이 다른 두 주소가 붙어 있는 셈이에요.

기계가 통신할 때 쓰는 IP(Internet Protocol) 주소에도 비슷한 구분이 있어요. 공인 주소는 공용 인터넷에서 구별되도록 배정하고, 사설 주소는 각자의 내부 네트워크에서 사용해요. 다만 공인 주소가 있다고 누구나 접속할 수 있는 것은 아니에요. 그 주소로 가는 경로와 방화벽, 실제로 연결을 받는 프로그램이 함께 있어야 해요.

라우팅되지 않는 주소라는 발명

인터넷 주소 체계를 처음 규정한 1981년 문서는 주소를 네 옥텟, 곧 32비트의 고정 길이로 못 박았어요. 약 43억 개이고, 연구 기관 몇 곳이 컴퓨터를 잇던 시절에는 다 쓸 일이 없어 보이는 양이었어요. 그 예상은 개인용 컴퓨터와 손안의 기기가 인터넷에 붙으면서 무너졌어요.

대응은 두 갈래였어요. 하나는 주소를 더 길게 만든 새 체계를 준비하는 일이었고, 다른 하나는 지금 있는 주소를 아껴 쓰는 일이었어요. 아껴 쓰는 쪽의 핵심이 1996년 2월에 정리된 약속이에요. 주소 가운데 일부 구간을 떼어 각자의 울타리 안에서만 쓰는 주소로 정했어요.

사설 주소는 공용 인터넷에서 전역으로 전달하는 용도로 쓰지 않아요. 대신 집이나 회사의 내부 경로에서는 정상적으로 전달돼요. 서로 분리된 두 네트워크가 같은 사설 주소를 써도 되는 이유죠. 이 네트워크들을 나중에 직접 연결하려고 하면 주소가 겹치는 문제가 드러날 수 있어요.

통역 장치가 만드는 성질, 그리고 오해

울타리 안의 기계도 바깥과 이야기해야 하므로 문턱에 통역 장치를 둬요. 나가는 요청은 대표 주소로 바꿔 내보내고, 어느 안쪽 기계가 보낸 것인지 표에 적어 두었다가 답이 오면 그 표를 보고 전달해요. 이 표를 상태 테이블이라고 부르고, 이 방식을 NAT이라고 해요. 2001년에 정리된 문서는 전통적인 NAT에서 세션이 사설망에서 바깥으로 향하는 한 방향이며, 반대 방향은 미리 지정해 둔 고정 대응을 통해 예외적으로만 허용된다고 적어요.

여기서 성질 하나가 따라와요. 안쪽 기계는 먼저 말을 걸 수 있지만 바깥에서 먼저 불릴 수는 없어요. 표에 항목이 없는 연결은 전달할 곳을 모르기 때문이에요. 집의 공유기 뒤에 있는 노트북이 인터넷을 잘 쓰면서도 밖에서는 보이지 않는 이유가 이것이에요.

이 성질을 방화벽으로 착각하는 경우가 많은데, NAT은 보안을 위해 만들어진 것이 아니라 주소를 아끼려던 구조의 부수 효과예요. 안쪽이 감염되어 스스로 바깥으로 연결을 열면 표에 항목이 생기고 통로가 열려요. 규칙에 따라 무엇을 막을지 정하는 장치가 아니라, 아는 대화만 되돌려 주는 장치일 뿐이에요. 실제 경계는 별도로 세워야 해요.

이런 절약에도 중앙 재고는 결국 바닥났어요. 2011년 2월 3일 주소를 관리하는 기구가 지역 기관에 마지막 몫을 나눠 주면서 소진됐어요. 새 체계로 옮겨 가는 일은 그 뒤로도 느리게 진행 중이에요.

겹쳐도 된다는 성질의 청구서

사설 대역을 겹쳐 써도 된다는 편의에는 나중에 청구서가 와요. 서로 다른 두 네트워크를 잇는 순간, 같은 대역을 쓰고 있으면 어느 쪽 305호인지 구분할 방법이 없어져요. 회사를 합치거나 사무실과 클라우드를 연결하거나 사설망끼리 직접 연결할 때 흔히 부딪치는 문제이고, 해결은 대개 한쪽의 주소를 전부 바꾸는 고통스러운 작업이 돼요.

그래서 사설 대역은 처음 만들 때부터 좁게 잡고 겹치지 않게 배분해 두는 편이 나아요. 지금 쓸 만큼만 잡는 것이 아니라 나중에 무엇과 이어질지를 고려해 자리를 비워 두는 일이에요.

무엇	어디서 통하나	겹치면
사람이 외우는 이름	어디서나	등록 자체가 되지 않는다
인터넷에서 통하는 주소	어디서나	배정되지 않는다
울타리 안에서만 통하는 주소	그 울타리 안에서만	평소엔 문제없지만 두 망을 이을 때 막힌다

이름을 주소로 바꾸는 과정은 도메인 이름 시스템 이야기에서 다뤄요. DNS 이름이 반드시 공인 주소를 가리켜야 하는 것은 아니에요. 사설 주소를 가리키는 이름도 내부에서 유용하게 쓸 수 있어요. 다만 이름을 붙였다고 외부에서 그 주소로 갈 수 있는 네트워크 경로까지 생기지는 않아요.

저는 왜 주소를 적지 않는가

작은 앱을 만들면서 이 구분이 설계의 기본이 됐어요. 서비스를 이루는 조각 가운데 인터넷에서 직접 보여야 하는 것은 사실 얼마 되지 않아요. 사람이 앱에서 접속하는 입구 하나면 충분하고 나머지는 서로만 알면 돼요. 그래서 대부분을 사설 주소로만 두었어요.

그리고 이 글에는 그 주소를 하저도 적지 않았어요. 살아 있는 주소는 그 자체로 지도가 돼요. 어디를 두드려야 하는지 알려 주는 정보를 먼저 건넬 이유가 없어요. 기술 글은 구체적일수록 좋다고 여기기 쉽지만, 주소나 계정 이름처럼 그대로 재사용되는 값은 구체성이 곧 노출이 돼요. 개념은 정확하게 쓰고 좌표는 적지 않는 편이 나아요.