LLM 시대에도 변하지 않는 기초: Engineer가 TCP/IP와 HTTP를 알아야 하는 진짜 이유 1편 - 브라우저에 www.google.com을 입력하면 벌어지는 일

LLM 기반 서비스가 빠르게 확산되고 있습니다. 모델의 파라미터 수, 추론 최적화, 프롬프트 엔지니어링이 주요 화두가 되었습니다. 그러나 한 걸음 물러나 생각해보면, 우리가 사용하는 모든 AI 서비스는 결국 네트워크 위에서 동작합니다. LLM API를 호출하는 행위 역시 하나의 HTTP 요청입니다.

 

모델의 성능이 아무리 뛰어나더라도 요청과 응답이 오가는 경로에서 병목이 발생한다면 사용자가 체감하는 속도는 달라집니다. CDN을 경유하고, Edge 노드를 거치며, API Gateway를 통과하는 구조에서 발생하는 지연은 모델 자체의 문제와 구분되어야 합니다. 이러한 구분은 네트워크 계층에 대한 이해 없이 이루어지기 어렵습니다.

 

이 글에서는 브라우저에 www.google.com을 입력했을 때 어떤 일이 발생하는지를 따라가며, Internet과 WWW의 본질, 그리고 Routing의 구조를 정리해보고자 합니다. 이 과정은 단순한 교양 지식이 아니라, 애플리케이션 성능을 이해하는 출발점이라고 생각합니다.

 

---

 

Internet이란 무엇인가

 

Internet이라는 용어는 일상적으로 사용되지만, 기술적으로는 명확한 정의를 가집니다. Internet Engineering Task Force에서 표준화한 문서들을 기준으로 보면 Internet은 TCP/IP 프로토콜 스위트를 기반으로 상호 연결된 네트워크들의 집합입니다.

 

RFC 791는 Internet Protocol(IP)을 정의합니다. IP는 패킷 단위의 데이터 전달 방식을 규정하며, 송신지와 수신지 주소를 기반으로 데이터를 전달합니다. 중요한 점은 IP가 신뢰성을 보장하지 않는다는 사실입니다. 이는 best-effort delivery 모델로 설명됩니다. 즉, 최선을 다해 전달하지만 도착을 보장하지는 않습니다.

 

RFC 1122는 호스트가 구현해야 할 요구사항을 정의하며, TCP/IP 스택이 어떤 방식으로 동작해야 하는지 구체화합니다. 또한 RFC 1180는 TCP/IP 구조를 이해하기 위한 튜토리얼 성격의 문서로, packet switching network의 개념을 설명합니다.

 

Internet은 회선 교환이 아닌 패킷 교환 기반 네트워크입니다. 데이터는 작은 패킷으로 분할되어 각기 다른 경로를 통해 전달될 수 있습니다. 이 구조는 확장성과 장애 회복성을 확보하는 데 유리합니다.

 

또 하나 중요한 개념은 end-to-end principle입니다. 네트워크 내부는 단순하게 유지하고, 복잡한 기능은 종단 시스템에서 처리한다는 철학입니다. 이 원칙은 TCP가 신뢰성을 보장하고, 애플리케이션이 세션을 관리하는 구조로 이어집니다.

 

정리하자면 Internet은 단순히 물리적 인프라 자체만을 의미한다기 보다는 IP 기반 패킷 교환 네트워크들의 상호 연결 구조를 의미합니다.

 

---

 

WWW란 무엇인가

 

Internet과 WWW는 동일한 개념이 아닙니다. Internet이 전송 인프라라면, WWW는 그 위에서 동작하는 애플리케이션 계층 시스템입니다.

 

Tim Berners-Lee는 하이퍼텍스트 문서를 네트워크를 통해 연결하는 구조를 제안했습니다. 이 구조는 URL로 자원을 식별하고, HTTP로 전송하며, HTML로 표현하는 방식입니다.

 

이후 표준화는 World Wide Web Consortium에서 담당하게 됩니다. 이 기관은 HTML, CSS, 웹 API 등 웹 표준을 정의합니다.

 

따라서 Internet이 없으면 WWW는 존재할 수 없지만, Internet이 곧 WWW를 의미하지는 않습니다. 이메일, FTP, VoIP 역시 Internet 위에서 동작하지만 WWW는 아닙니다. 이 구분은 구조를 이해하는 데 중요한 기준이 됩니다.

 

---

 

브라우저에 www.google.com을 입력하면 일어나는 일

 

브라우저에 www.google.com을 입력하는 순간 여러 단계가 순차적으로 진행됩니다.

 

먼저 DNS 조회가 수행됩니다. 도메인 이름은 사람이 읽기 쉽도록 만든 식별자이며, 실제 통신은 IP 주소로 이루어집니다. DNS 서버에 질의하여 해당 도메인의 IP를 얻는 과정에서 네트워크 왕복이 발생합니다. 이 단계에서 지연이 발생할 수 있습니다.

 

IP를 획득하면 TCP 연결을 수립합니다. 이때 3-way handshake가 수행됩니다. SYN, SYN-ACK, ACK의 교환을 통해 연결이 성립합니다. 이 과정 역시 최소 한 번의 RTT를 필요로 합니다.

 

HTTPS 통신이라면 이어서 TLS handshake가 수행됩니다. 서버 인증서 교환과 키 합의 과정이 진행되며, 이 단계에서도 추가적인 RTT가 발생합니다.

 

연결이 수립되면 HTTP 요청이 전송됩니다. 서버는 요청을 처리하고 응답을 반환합니다. 응답이 브라우저에 도달하면 HTML이 파싱되고, 추가적인 리소스 요청이 발생할 수 있습니다.

 

이 일련의 과정은 단순해 보이지만, 각 단계마다 지연 요소가 존재합니다. 모델 추론 시간만이 응답 지연의 전부는 아닙니다.

 

---

 

Routing이란 무엇인가

 

IP 패킷은 목적지까지 도달하기 위해 여러 라우터를 거칩니다. 이때 사용되는 핵심 프로토콜 중 하나가 BGP입니다. BGP는 AS(Autonomous System) 간 경로 정보를 교환하는 프로토콜입니다.

 

AS는 단일한 라우팅 정책을 따르는 네트워크 집합입니다. 인터넷은 수많은 AS로 구성되어 있으며, 각 AS는 정책 기반으로 경로를 선택합니다. 이 때문에 실제 데이터 경로는 물리적으로 가장 짧은 경로와 다를 수 있습니다.

 

해외 API 호출이 느린 이유 중 하나는 이러한 경로 선택 구조에 있습니다. 지리적으로 가까워 보이더라도, 트래픽이 여러 국가의 AS를 우회할 수 있습니다. 이는 애플리케이션 코드 수준에서는 보이지 않는 영역입니다.

 

---

 

애플리케이션 개발자가 놓치기 쉬운 병목 지점

 

실무에서 종종 “코드는 빠른데 응답이 느리다”는 상황을 마주합니다. 이때 애플리케이션 내부 로직만 점검하는 것은 충분하지 않을 수 있습니다.

 

DNS 조회가 매 요청마다 발생한다면 지연이 누적됩니다. TCP handshake와 TLS handshake 역시 연결 재사용이 되지 않으면 반복 비용이 발생합니다. HTTP Keep-Alive나 HTTP/2의 연결 다중화 기능을 적절히 활용하지 못하면 성능 저하로 이어질 수 있습니다.

 

또한 TLS 설정, 인증서 체인 길이, CDN 경유 여부 등도 응답 시간에 영향을 미칩니다. 이러한 요소들은 모두 네트워크 계층 이해를 전제로 분석이 가능합니다.

 

---

 

마무리하며

 

Internet은 IP 기반 패킷 교환 네트워크이며, WWW는 그 위에서 동작하는 애플리케이션 시스템입니다. 우리가 사용하는 모든 LLM 서비스 역시 HTTP 요청을 통해 접근됩니다.

 

모델의 추론 속도만이 사용자 경험을 결정하지는 않습니다. DNS, Routing, TCP, TLS의 흐름을 이해하면 지연의 원인을 더 구조적으로 바라볼 수 있습니다.

 

이 글은 네트워크 이론을 다시 정리하며, 애플리케이션 개발자로서 기본기를 점검해본 기록입니다. LLM 시대라 하더라도 TCP/IP와 HTTP에 대한 이해는 여전히 유효한 토대라고 생각합니다.