업데이트됨 1개월 전
브라우저에 127.0.0.1 또는 localhost를 입력하면, 루프백 주소를 사용하는 것입니다. 이 주소는 컴퓨터를 동시에 송신자이자 수신자로 만드는, 시스템에 하드웨어적으로 내장된 지름길입니다. 트래픽은 절대 네트워크 선을 타지 않고, 네트워크 카드를 통과하지도 않으며, 컴퓨터 밖으로 나가지도 않습니다. 지구 반대편 서버와 통신할 때 쓰는 것과 똑같은 프로토콜로 컴퓨터가 자기 자신과 나누는 대화입니다.
이것은 꼼수나 임시방편이 아닙니다. 1980년대 초부터 모든 운영체제에 내장된 근본적인 아키텍처입니다. 실제로 어떤 일이 일어나는지 이해하고 나면, 개발하면서 마주치던 수십 가지 수수께끼 같은 동작들이 갑자기 이해되기 시작합니다.
언제나 집을 가리키는 주소
127.0.0.1은 루프백 주소입니다. 이 주소로 패킷을 보내면, 운영체제가 하드웨어에 닿기 전에 가로챕니다. 네트워크 카드도 없고, 라우터도 없고, 케이블도 없습니다. 패킷은 TCP/IP 스택 안에서, 순전히 소프트웨어 레벨에서 되돌아옵니다.
이 메커니즘은 TCP/IP를 사용하는 모든 시스템에 하드코딩되어 있습니다. Windows, macOS, Linux, 스마트폰 어디서든 127.0.0.1은 항상 "이 컴퓨터"를 의미하며 그 외에 아무것도 의미하지 않습니다. 같은 네트워크에 있는 다른 기기가 아니고, 데이터 센터의 서버도 아닙니다. 언제나 집입니다.
127.0.0.1이라는 값의 선택은 1983년 Bill Joy와 Sam Leffler가 4.2BSD의 기반이 된 Berkeley Unix 코드베이스를 작업하면서 이루어졌습니다. 그들은 루프백 기능을 위해 기억하기 쉽고 일관된 주소가 필요했습니다. 40년이 지난 지금도 우리는 그들의 선택을 그대로 사용하고 있습니다.
자신과 통신하기 위한 1,600만 개의 주소
대부분의 사람들은 127.0.0.1만 알고 있지만, 127.0.0.0/8 블록 전체가 루프백용으로 예약되어 있습니다. 127.0.0.0부터 127.255.255.255까지 — 컴퓨터가 자기 자신과 통신하는 용도로 지정된 16,777,216개의 주소입니다.
이 예약은 1981년 RFC 776으로 거슬러 올라갑니다. Jon Postel은 각 주소 클래스의 첫 번째와 마지막 네트워크를 예약하는 정책을 가지고 있었는데, 127에 대한 구체적인 계획이 있었던 것 같지는 않습니다. RFC 1122(1989)는 모든 인터넷 호스트에 루프백 지원을 필수로 규정했습니다.
핵심은 이렇습니다. 1981년에는 IPv4 주소가 무한한 것처럼 보였습니다. 아무도 주소가 고갈될 거라 상상하지 못했습니다. 오늘날 조직들은 IPv4 할당을 위해 상당한 돈을 지불하고, 주소 이전을 중개하는 사업이 생겨났으며, 남은 공급을 늘리기 위해 점점 더 무리한 NAT 방식이 동원되고 있습니다. 한편, 전체 IPv4 주소의 1/256이 컴퓨터가 자기 자신과 통신하기 위해 예약되어 있고, 그 1,600만 개의 주소 중 실제로 흔히 쓰이는 것은 단 하나뿐입니다.
해당 범위의 모든 주소는 반드시 루프백되어야 합니다. 라우터가 루프백이 아닌 인터페이스에서 127.x.x.x 주소의 패킷을 만나면, 그 패킷은 "화성에서 온 패킷(Martian packet)"으로 간주됩니다 — 말 그대로 화성에서 왔을 리 없는, 있을 수 없는 주소라는 뜻으로 — 즉시 폐기되어야 합니다.
루프백이 가능하게 하는 것들
인터넷 없이 개발하기. 비행기 모드를 켠 채 고도 35,000피트 상공에서도 프론트엔드, 백엔드, 데이터베이스, 캐시, 큐를 갖춘 완전한 웹 애플리케이션을 노트북에서 실행할 수 있습니다. 루프백 인터페이스는 Wi-Fi나 이더넷 케이블이 없어도 아무 상관 없습니다.
프로세스 간 통신하기. 같은 컴퓨터에서 실행 중인 프로세스들이 익숙한 네트워킹 프로토콜로 서로 통신할 수 있습니다. 하나는 127.0.0.1:8080에서 서버로, 다른 하나는 클라이언트로 동작합니다. 원격 통신에 사용하는 것과 동일한 API를 사용하지만, 트래픽은 컴퓨터 밖으로 나가지 않습니다.
네트워크 스택 검증하기. 127.0.0.1에 핑을 보낼 수 있다면, TCP/IP 스택이 정상 작동하고 있다는 뜻입니다. 네트워크 카드가 뽑혀 있거나, Wi-Fi가 고장났거나, 라우터에 불이 붙었어도 마찬가지입니다. 루프백은 어떤 하드웨어와도 무관하게 네트워킹 소프트웨어가 제대로 동작한다는 것을 증명합니다.
격리를 통한 보안 강화하기. 127.0.0.1에 바인딩된 서비스는 다른 기기에서 절대 접근할 수 없습니다. 확실히 말씀드립니다. 같은 Wi-Fi에 연결된 스마트폰에서도, 같은 LAN에 있는 다른 컴퓨터에서도, 인터넷에서도 접근이 불가능합니다.
localhost 대 127.0.0.1
이 둘을 혼용해서 쓰는 경우가 많지만, 미묘한 차이가 있습니다.
127.0.0.1은 직접적인 IP 주소입니다. 시스템이 이름 해석을 건너뛰고 즉시 연결합니다. DNS가 망가져도 작동이 보장됩니다.
localhost는 해석이 필요한 호스트명입니다. 매핑은 보통 Unix 계열 시스템에서는 /etc/hosts, Windows에서는 C:\Windows\System32\drivers\etc\hosts를 통해 이루어집니다. 표준 설정에서는 localhost가 IPv4의 127.0.0.1과 IPv6의 ::1에 매핑됩니다.
해석에 드는 오버헤드는 무시할 수준입니다. 첫 번째 조회 후 보통 캐시됩니다. 하지만 특정 상황에서는 이 차이가 중요합니다. MySQL은 이 둘을 다르게 처리합니다. localhost는 Unix 도메인 소켓 연결을 사용하고, 127.0.0.1은 루프백을 통한 TCP를 사용합니다. 권한, 성능 특성, 디버깅 경로가 모두 달라집니다.
DNS 문제를 디버깅할 때나 IPv4가 특별히 필요한 경우에는 127.0.0.1을 직접 사용하세요.
일상에서 루프백을 만나는 곳
로컬 개발 서버. npm start나 flask run을 실행하면 "Server running at http://127.0.0.1:3000"과 같은 메시지를 보게 됩니다. 웹 서버와 브라우저가 같은 컴퓨터에 있으면서 루프백 인터페이스를 통해 대화하는 것입니다.
데이터베이스. PostgreSQL, MySQL, MongoDB — 대부분의 데이터베이스 시스템은 기본적으로 127.0.0.1에 바인딩됩니다. 로컬 컴퓨터에서의 연결만 받아들입니다. 원격 접근이 필요하다면? 설정을 명시적으로 변경해야 합니다.
Docker와 컨테이너. Docker Desktop, Kubernetes 클러스터, 각 언어별 개발 서버 — 모두 루프백을 적극 활용합니다. 복잡한 마이크로서비스 아키텍처를 노트북 한 대로 구축하고 테스트할 수 있습니다.
SSH 터널. 원격 서버에 연결해서 원격 포트 5432를 내 컴퓨터의 127.0.0.1:5432로 포워딩합니다. 이렇게 하면 원격 데이터베이스에 마치 로컬에서 실행 중인 것처럼 연결할 수 있습니다.
트래픽이 절대 밖으로 나가지 않는 이유
127.0.0.1로 전송된 트래픽이 다른 기기에 도달하는 것은 물리적으로 불가능합니다.
애플리케이션이 127.0.0.0/8 범위의 어떤 주소로든 패킷을 보내면, 운영체제가 링크 계층에서 — 하드웨어에 도달하기 전에 — 가로챕니다. 패킷은 절대 네트워크 인터페이스 카드에 닿지 않습니다. 케이블이나 Wi-Fi 신호에 실리지도 않습니다. 라우터 로그에 나타나지도 않습니다.
애플리케이션 입장에서는 평범한 네트워크 요청을 하는 것입니다. 네트워크 스택은 다른 모든 트래픽과 동일하게 처리합니다 — 단, 왕복이 소프트웨어 안에서만 완전히 이루어지며, 물리적으로 이동하는 거리는 0입니다.
특수 하드웨어로 네트워크를 모니터링해도 루프백 트래픽은 절대 보이지 않습니다. 컴퓨터 바깥에는 존재하지 않으니까요.
IPv6 루프백: ::1
IPv6에도 자체 루프백 주소가 있습니다: ::1. 이것은 0000:0000:0000:0000:0000:0000:0000:0001의 압축 표현으로, 마지막 비트를 제외한 128비트가 전부 0입니다.
IPv4의 1,600만 개의 루프백 주소와 달리, IPv6는 단 하나만 지정합니다. 총 340언데실리온(undecillion)개의 IPv6 주소를 사용할 수 있으므로, 전체 범위를 예약할 필요가 없습니다. 하지만 이것은 설계 차원의 인정이기도 합니다. 우리는 1,600만 개의 루프백 주소가 필요하지 않았습니다. 하나로 충분했을 것입니다.
이 주소는 127.0.0.1과 정확히 같은 역할을 합니다. ::1로 보내는 패킷은 호스트를 벗어나지 않습니다.
localhost에 연결할 때, 시스템은 설정에 따라 127.0.0.1 또는 ::1로 해석할 수 있습니다. 일부 운영체제는 기본적으로 IPv6를 선호합니다. 대부분의 애플리케이션에서 이 차이는 눈에 보이지 않습니다 — 둘 다 동일하게 작동합니다. 하지만 네트워크 문제를 디버깅할 때는 실제로 어떤 주소가 사용되고 있는지 파악해 두는 것이 좋습니다.
127.0.0.1 대 0.0.0.0: 중요한 보안 차이
서비스가 주소에 어떻게 바인딩되는지 이해하는 것은 필수입니다. 127.0.0.1과 0.0.0.0의 차이는 서비스가 자신의 컴퓨터에만 잠겨 있느냐, 전체 네트워크에 노출되느냐의 차이를 의미할 수 있습니다.
127.0.0.1에 바인딩: 서비스가 로컬 컴퓨터에서의 연결만 받아들입니다. 컴퓨터가 192.168.1.100 같은 LAN 주소나 공인 IP를 가지고 있더라도, 해당 인터페이스들은 루프백에 바인딩된 서비스에 접근할 수 없습니다. 다른 기기는 연결 자체가 불가능합니다.
0.0.0.0에 바인딩: 서비스가 사용 가능한 모든 네트워크 인터페이스에서 동시에 수신 대기합니다. 어떤 IP 주소로든 패킷을 라우팅할 수 있는 사람이라면 잠재적으로 연결할 수 있습니다.
0.0.0.0:5432에 바인딩된 데이터베이스는 네트워크에 있는 누구나 — 또는 방화벽에 허점이 있다면 원격 공격자도 — 접근할 수 있습니다. 같은 데이터베이스가 127.0.0.1:5432에 바인딩되어 있다면, 방화벽 규칙과 무관하게 컴퓨터 외부에서는 접근이 불가능합니다.
외부 접근이 꼭 필요한 경우가 아니라면 127.0.0.1을 기본으로 사용하세요. 로컬 API에서 모바일 앱을 테스트하는 중인가요? 일시적으로 0.0.0.0에 바인딩하고, 컴퓨터의 IP 주소를 공유한 다음, 완료되면 다시 되돌리세요.
프로덕션 서비스는 보통 외부 연결이 필요하기 때문에 0.0.0.0에 바인딩하지만, 방화벽, API 게이트웨이, 리버스 프록시, 네트워크 분리 등 여러 보안 계층에 의존합니다.
원칙은 간단합니다. 필요에 맞는 가장 제한적인 설정을 기본으로 삼으세요.
로컬호스트에 관해 자주 묻는 질문들
왜 127.0.0.1을 "localhost"라고 부르나요?
localhost는 호스트명이고, 127.0.0.1은 그것이 일반적으로 해석되는 IP 주소입니다. 이 이름은 "로컬 호스트" — 현재 사용 중인 컴퓨터 — 라는 개념에서 비롯되었습니다. 호스트명과 IP 주소 간의 매핑은 DNS가 아닌 시스템의 hosts 파일에 정의되어 있습니다.
누군가 localhost를 통해 해킹할 수 있나요?
원격으로는 불가능합니다. 127.0.0.1로의 트래픽은 컴퓨터를 절대 벗어나지 않으므로, 공격자가 악용할 수 있는 네트워크 경로 자체가 없습니다. 하지만 이미 컴퓨터에 악성 소프트웨어가 실행 중이라면, 다른 로컬 프로세스처럼 localhost에 바인딩된 서비스에 연결할 수 있습니다. 이 보호는 외부 접근을 막는 것이지, 이미 침투한 로컬 소프트웨어를 막는 것이 아닙니다.
왜 어떤 애플리케이션은 127.0.0.1을, 다른 것들은 localhost를 사용하나요?
127.0.0.1을 직접 사용하면 DNS 해석을 건너뛰고 IPv4를 보장합니다. localhost는 더 읽기 쉽지만 이름 해석이 필요하고, 일부 시스템에서는 ::1(IPv6)로 해석될 수 있습니다. 일부 애플리케이션(MySQL 등)은 이 둘을 다르게 처리합니다 — localhost는 Unix 소켓 연결을 사용할 수 있고, 127.0.0.1은 TCP를 강제합니다. 확실하지 않다면 일관성을 위해 127.0.0.1을 사용하세요.
다른 컴퓨터에서 127.0.0.1에 접근하려고 하면 어떻게 되나요?
그 컴퓨터는 여러분의 루프백이 아닌 자신의 루프백 인터페이스에 연결합니다. 모든 기기의 127.0.0.1은 자기 자신을 가리킵니다. 이 주소로 다른 컴퓨터에 접근하는 것은 불가능합니다. 관례가 아니라 물리 법칙입니다.
참고 자료
이 페이지가 도움이 되었나요?