도라의 개발 블로그

소프트웨어 개발/웹

웹 개발을 위한 네트워크 기초

boradora 2026. 7. 26. 15:54

작업일2026. 07

TCP/IP HTTP DNS IP 주소 URL HTTPS

주소창에 주소를 치고 엔터를 누르면 1초도 안 돼서 페이지가 뜹니다. 그 짧은 사이에 컴퓨터들끼리 어떤 대화가 오가는지, 순서대로 따라가 보려고 합니다.

주소창에 URL을 입력하고 엔터를 누르면 무슨 일이 일어날까요?
이 질문 하나를 따라가다 보면 네트워크 기초를 이해할 수 있습니다.

요즘은 AI에게 시켜서 코드를 만드는 바이브 코딩이 흔해졌습니다. 덕분에 화면 하나 띄우는 일은 확실히 빨라졌지만 막상 에러가 나면 어디부터 봐야 할지 막막할 때가 있습니다. 404와 500이 무엇이 다른지, 주소창의 https는 어떤 역할을 하는지조차 헷갈리는 경우가 많습니다.

웹 개발은 보통 HTML부터 배웁니다. 하지만 그 HTML 파일이 어떻게 서버에서 브라우저까지 전달되는지는 쉽게 지나치곤 합니다. 프론트엔드든 백엔드든 결국 우리가 만드는 것은 네트워크를 통해 오가는 데이터입니다. 그래서 이번 글에서는 웹 개발을 위해 꼭 알아야할 네트워크 기초를 정리해보겠습니다. 

인터넷과 웹

인터넷은 전 세계 컴퓨터를 연결한 물리적인 통신망입니다. 케이블, 광섬유, 공유기, 라우터 같은 장비로 이루어진 실제 네트워크를 말합니다. 웹, 이메일, 파일 전송 모두는 이 인터넷 위에서 동작하는 서비스입니다. 즉, 웹(WWW)은 인터넷 자체가 아니라 인터넷을 이용하는 여러 서비스 중 하나입니다.

서비스 (Application)
웹 (WWW)
HTTP
이메일
SMTP · IMAP
파일 전송
FTP
원격 접속
SSH
인프라 (Infrastructure)
인터넷
케이블 · 라우터 · 스위치 · 컴퓨터

인터넷은 깔려 있는 망이고, 웹은 그 위에서 도는 서비스 중 하나입니다.

구분 인터넷 (Internet) 웹 (World Wide Web)
정체 컴퓨터를 연결한 통신망 (인프라) 정보를 공유하는 공간 (서비스)
구성 케이블, 라우터, 스위치 (하드웨어) HTML, HTTP, URL, 브라우저 (소프트웨어)
기준 계층 하위 계층 (인터넷·전송 계층) 최상위 계층 (응용 계층)
관계 웹을 포함한 모든 서비스의 기반 인터넷 위 수많은 서비스 중 하나

흐름을 보면 이렇습니다

지금의 인터넷이 어떻게 만들어졌는지도 간단히 짚고 가겠습니다.

 
1960년대
미국 국방부 ARPANET 프로젝트
떨어진 연구소 컴퓨터를 연결해 본 것이 시작
 
1970~80년대
TCP/IP 프로토콜 개발
서로 다른 망을 하나로 묶는 공통 규칙이 생김
 
1990년대
WWW 등장 → 대중화
1989년 팀 버너스리가 www를, 1991년 HTML을 만듦
 
2000년대~
모바일 · 클라우드 · IoT
연결되는 기기의 종류가 폭발적으로 늘어남

웹을 이루는 세 가지

웹은 크게 세 가지로 이루어져 있습니다. 어떻게 보낼지, 어디로 보낼지, 무엇을 보낼지입니다. 앞의 두 가지가 이번 글의 내용이고, 마지막 HTML은 다음 글에서 정리하겠습니다.

어떻게 보낼까
HTTP
브라우저와 서버가 대화하는 규칙
어디로 보낼까
URL
자원이 어디 있는지 가리키는 주소
무엇을 보낼까
HTML
다음 글에서 다룹니다

인터넷을 이루는 세 가지

그럼 인터넷이라는 망은 무엇으로 만들어져 있을까요. 크게 세 가지입니다.

  • 종단 시스템: 데이터를 만들거나 소비하는 양 끝의 기기. 요청하는 쪽이 클라이언트(노트북, 스마트폰), 응답하는 쪽이 서버입니다. 각각 IP 주소를 받아 식별됩니다.
  • 전송 매체: 신호가 실제로 지나가는 길. 광케이블·LAN선 같은 유선과 Wi-Fi·5G 같은 무선이 있습니다.
  • 네트워크 장비: 데이터를 다음 목적지로 넘겨주는 중계기. 라우터가 서로 다른 네트워크를 잇고 경로를 정하며, 스위치가 한 네트워크 안의 기기들을 연결합니다.

통신을 계층으로 나눈 이유

프로토콜은 데이터를 주고받기 위해 미리 정해둔 규칙입니다. 그런데 이 규칙을 하나로 묶어버리면 문제가 생기게 됩니다. 전기 신호를 보내는 방식, 데이터를 목적지까지 전달하는 방식, 오류를 복구하는 방식이 전부 얽혀 있으면 한 부분만 바뀌어도 전체를 수정해야 하기 때문입니다. 

그렇기 때문에 기능을 계층(Layer)으로 나눴습니다. 각 계층은 자신의 역할만 수행하고, 다른 계층의 동작 방식은 신경 쓰지 않습니다. 계층 구조를 이해하기 위해 사용하는 것이 OSI 7계층이고, 실제 인터넷은 TCP/IP 4계층을 기반으로 동작합니다.

계층 하는 일 대표 프로토콜 데이터 단위(PDU)
Application 사용자 앱과 직접 대화 HTTP, DNS, FTP, SMTP Message
Transport 목적지까지 정확하게 전달 TCP, UDP Segment / Datagram
Internet 최적 경로를 찾고 IP 주소 부여 IP, ICMP Packet
Network Access 케이블·랜카드로 비트 단위 전송 Ethernet, Wi-Fi Frame → Bit

맨 아래 Network Access 계층은 OSI 모델의 물리 계층과 데이터 링크 계층을 하나로 합친 것입니다. 유선 Ethernet과 무선의 Wi-Fi(IEEE 802.11)가 여기에 속하며, 데이터를 실제 케이블이나 무선 신호를 통해 전송하는 역할을 합니다.

층마다 붙는 헤더, 캡슐화

데이터는 위에서 아래로 내려가면서 각 층의 헤더(Header)가 하나씩 붙는데, 이 과정을 캡슐화라고 합니다. 계층마다 헤더가 달라지기 때문에 데이터를 부르는 이름도 달라지는데, 이 이름을 PDU라고 합니다. 받는 쪽에서는 아래 계층부터 헤더를 하나씩 제거하면서 원래 데이터만 남게 됩니다.

Application
데이터
Message
Transport
TCP
데이터
Segment
Internet
IP
TCP
데이터
Packet
Network Access
Ethernet
IP
TCP
데이터
Frame
▼ 마지막엔 0과 1의 전기 신호 (Bit) 로 케이블에 실립니다

보내는 쪽은 헤더를 붙이며 내려가고, 받는 쪽은 벗기며 올라갑니다.

IP 주소와 MAC 주소

네트워크에서는 IP 주소와 MAC 주소를 함께 사용합니다. IP 주소는 어느 네트워크에 연결되어 있는지를 타나내는 논리적 주소이고, MAC 주소는 장치 자체를 식별하는 물리적 주소입니다.

IP 주소는 인터넷에서 장치를 식별하는 논리적 주소입니다. 네트워크가 바뀌면 IP 주소도 바뀔 수 있습니다.

  • IPv4: 192.168.0.1처럼 점으로 구분된 32비트 주소입니다.
  • IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334처럼 콜론으로 구분된 128비트 주소로, IPv4 주소 부족 문제를 해결하기 위해 만들어졌습니다. 

반면 MAC 주소는 랜카드에 부여된 영구히 기록된 물리적 주소입니다. 일반적으로 48비트, 16진수 12자리로 표기하고, 네트워크가 바뀌어도 값이 변하지 않습니다. 

구분 IP 주소 MAC 주소
성격 논리적 주소 (소프트웨어가 부여) 물리적 주소 (하드웨어에 기록)
변경 네트워크가 바뀌면 같이 바뀜 바뀌지 않음
계층 Internet Layer Network Access Layer

공인 IP와 사설 IP

집에 있는 노트북, 폰, TV가 각각 전 세계에서 유일한 주소를 가질 필요는 없습니다. 그래서 주소를 두 겹으로 씁니다. 집 안에서는 사설 IP를 쓰다가, 밖으로 나갈 때 공유기가 하나의 공인 IP로 바꿔 주는 방식입니다. 이 변환 기술을 NAT이라고 합니다.

우리 집 안 (LAN) · 사설 IP
노트북192.168.0.5
스마트폰192.168.0.6
TV192.168.0.7
공유기
NAT
인터넷 (WAN) · 공인 IP
203.0.113.7
밖에서 보이는 우리 집 대표 주소 하나. 세 기기가 이 주소를 나눠 씁니다.

Windows는 ipconfig /all, macOS는 ifconfig를 터미널에 입력해보면 확인해볼 수 있습니다.

$ ifconfig en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether ba:91:a7:**:**:**                    ← MAC 주소 (물리)
	inet 192.168.219.46 netmask 0xffffff00     ← 사설 IP (논리)
	status: active

ether 옆이 랜카드에 박혀 있는 MAC 주소이고, inet 옆이 공유기가 나눠준 사설 IP입니다. 이 사설 IP는 카페 와이파이로 옮기면 바뀌지만, MAC 주소는 그대로입니다.

여기서 한 번 더: 이 상태로 브라우저에 "what is my ip"를 검색해 보세요. 거기 뜨는 숫자가 공인 IP입니다. 터미널에서 본 192.168.x.x와 값이 전혀 다를 텐데, 그 사이에서 변환을 해주고 있는 것이 바로 NAT입니다.
궁금!사설 IP는 왜 하필 192.168로 시작할까?
아무 주소나 내부용으로 쓰면 진짜 공인 IP와 겹치기 때문에, 처음부터 내부 전용으로 떼어 둔 대역이 있습니다. 10.0.0.0~, 172.16.0.0~, 192.168.0.0~ 세 덩어리입니다.

이 중 192.168로 시작하는 대역이 가장 작아서 가정용 공유기 기본값으로 굳어졌습니다. 큰 회사나 학교에서는 기기가 많아 10.으로 시작하는 대역을 쓰는 경우가 많습니다.

URL 구조

URL은 자원이 어디에 있는지를 알려주는 주소 규약입니다. 그냥 한 줄처럼 보이지만, 뜯어보면 다섯 조각으로 나뉩니다.

https://
프로토콜
www.example.com
도메인
:443
포트
/blog/post.html
경로
?id=1
쿼리
  • 프로토콜: 어떤 방식으로 통신할지 (http / https)
  • 도메인: 서버의 위치. DNS가 IP 주소로 바꿔 줍니다.
  • 포트: 서버의 어느 문으로 들어갈지. HTTP는 80, HTTPS는 443이 기본이라 보통 생략합니다.
  • 경로: 서버 안에서 자원이 있는 위치
  • 쿼리: 서버에 넘기는 값 (key=value)

맨 뒤의 쿼리, 즉 물음표(?) 뒤에 붙는 부분이 GET 방식이 데이터를 실어 보내는 자리입니다. 뒤에서 한 번 더 다루겠습니다.

궁금!포트 번호 80과 443은 누가 정한 걸까?
포트 번호는 IANA라는 기관에서 등록·관리합니다. HTTP는 80번, HTTPS는 443번처럼 서비스별 기본 포트가 정해져 있어, 브라우저는 URL에 포트 번호가 없으면 이를 자동으로 사용합니다.

다만 강제 규칙은 아니므로 서버는 다른 포트도 사용할 수 있습니다. 예: https://example.com:8443

이름을 주소로 바꾸는 DNS

우리는 naver.com을 기억하지 223.130.192.247을 외우지 않습니다. 하지만 컴퓨터는 IP 주소로만 통신합니다. 이 간극을 메우는 것이 DNS(Domain Name System)입니다.

DNS는 사람이 읽는 도메인 이름을 컴퓨터가 쓰는 IP 주소로 번역해 주는 시스템입니다. 브라우저는 URL에 접속하기 전, 먼저 DNS를 통해 해당 도메인의 IP 주소를 찾습니다. 

nslookup 명령어로 직접 확인할 수 있습니다. Windows와 macOS 모두 같습니다.

$ nslookup naver.com

Server:		203.248.252.2
Address:	203.248.252.2#53

Non-authoritative answer:
Name:	naver.com
Address: 223.130.192.248
Name:	naver.com
Address: 223.130.200.219
Name:	naver.com
Address: 223.130.200.236
Name:	naver.com
Address: 223.130.192.247

위쪽 Server는 DNS 조회를 처리한 서버의 주소이고, 아래쪽 Addressnaver.com의 IP입니다. IP가 여러개인 이유는 트래픽을 분산하기 위해 서버를 여러 대 운영하기 때문이며, 접속을 할 때마다 다른 IP로 연결될 수 있습니다.

궁금!DNS 서버는 누가 관리할까?
최상위인 루트 DNS는 ICANN이라는 국제기구가 총괄하고, 실제 서버는 전 세계 12개 기관이 나눠 운영합니다. 그 아래 .com, .kr 같은 최상위 도메인은 각각 담당 기관이 따로 있습니다. .kr은 한국인터넷진흥원(KISA)이 맡고 있습니다.

우리가 평소에 질의하는 것은 이 서버들이 아니라, 통신사가 자동으로 물려주는 DNS 서버입니다. 구글의 8.8.8.8이나 클라우드플레어의 1.1.1.1로 직접 바꿔 쓸 수도 있는데, 이걸 바꾸면 접속 속도가 달라지기도 합니다.

TCP와 UDP

주소를 찾았다면 이제 데이터를 보낼 차례입니다. Transport 계층에는 성격이 다른 프로토콜 TCP와 UDP가 있습니다.

TCP연결 지향적입니다. 데이터를 보내기 전에 양쪽이 먼저 연결을 확립하는 3-Way Handshake를 거칩니다.

클라이언트
서버
 
 
 
SYN (연결 요청)
 
SYN + ACK (수락 응답 + 연결 요청)
 
ACK (연결 확립)
클라이언트
서버
연결 확립: 이제 데이터를 주고받습니다

TCP는 연결을 맺은 뒤 데이터 유실 시 재전송하고, 전달 순서도 보장합니다. 대신 확인 절차가 있어 UDP보다 느리고 오버헤드가 큽니다.

 

반대로 UDP는 비연결형입니다. 별도 합의 없이 데이터를 보내며, 수신 여부나 순서를 보장하지 않습니다. 그만큼 가볍고 빠르지만 데이터 유실이나 순서 변경은 직접 처리해야 합니다.

 

구분 TCP UDP
연결 연결 지향 (핸드셰이크 O) 비연결형 (핸드셰이크 X)
신뢰성 높음 (재전송·순서 보장) 낮음 (유실돼도 그대로)
속도 느리고 오버헤드 큼 빠르고 가벼움
쓰는 곳 웹(HTTP), 파일 전송(FTP), 이메일(SMTP) 실시간 스트리밍, 온라인 게임

영상 통화에서 한 프레임이 유실되더라도 그냥 넘어가는 편이 낫습니다. 그 프레임 하나를 재전송받느라 통화가 1초 밀리면 더 불편하기 때문입니다. 이러한 실시간 통신에는 UDP가 적합한 것이죠.

현재 내 컴퓨터의 네트워크 연결과 열린 포트는 다음 명령어로 확인할 수 있습니다.

Windows는 netstat -an, macOS는 lsof -i TCP -P -n입니다.

$ lsof -i TCP -P -n

COMMAND     PID   FD   TYPE   NAME
rapportd    668   10u  IPv4   TCP *:62753 (LISTEN)
Google      921   45u  IPv4   TCP 192.168.219.46:51234->142.250.76.100:443 (ESTABLISHED)

LISTEN은 그 포트를 열어두고 요청을 기다리는 상태입니다. ESTABLISHED는 실제로 연결이 맺어져 데이터를 주고받는 상태입니다. 두 번째 줄은 내 사설 IP가 구글 서버의 443번 포트에 연결된 것을 보여 줍니다, 즉 TCP의 3-Way Handshake가 끝난 상태입니다.

HTTP 요청과 응답

DNS로 주소를 찾고, TCP로 연결도 맺었다면 이제 서버에 원하는 자원들 달라고 말할 차례입니다. 이때 사용하는 규칙이 바로 HTTP입니다.

HTTP는 브라우저와 서버가 자원(HTML, CSS, JS, 이미지)을 주고받기로 약속한 규칙입니다. 클라이언트가 요청을 보내면 서버가 응답을 돌려주는 구조입니다.

요청 (Request)  클라이언트 → 서버
Request Line
GET /index.html HTTP/1.1
Headers
Host: example.com
User-Agent: Mozilla/5.0
Body
서버로 보낼 데이터 (GET은 보통 비어 있음)
응답 (Response)  서버 → 클라이언트
Status Line
HTTP/1.1 200 OK
Headers
Content-Type: text/html
Server: nginx
Body
<html>...</html>

요청과 응답 모두 첫 줄 · 헤더 · 바디의 세 부분으로 되어 있습니다. 첫 줄에는 요청의 목적이나 응답 결과, 헤더에는 부가 정보, 바디에는 실제 데이터가 담깁니다. 

메서드: 무엇을 하고 싶은지

요청 첫 줄의 메서드는 요청 목적을 나타냅니다.

구분 GET POST
목적 자원을 조회 자원을 생성·수정
데이터 위치 URL 뒤 쿼리스트링에 노출 Body에 담김
검색 결과 보기, 게시글 읽기 회원가입, 글쓰기, 로그인

이 외에 PUT, PATCH, DELETE, HEAD, OPTIONS 등이 있으며, REST API에서 자주 사용합니다.

상태 코드: 결과가 어땠는지

응답 첫 줄에는 상태 코드가 붙습니다. 앞자리 숫자만으로도 응답 결과를 대략 알 수 있습니다.

1xx
정보
처리 중
2xx
성공
200 OK
201 Created
3xx
리다이렉션
304 Not Modified
4xx
클라이언트 잘못
400 Bad Request
404 Not Found
5xx
서버 잘못
500 Internal
Server Error

 

404와 500을 구분하면 디버깅이 빨라집니다. 404는 요청한 주소가 없다는 뜻이므로 내가 보낸 URL을 확인하고, 500은 서버 내부의 오류이므로 서버 로그를 봐야 합니다.

웹 서버

요청을 받아 HTML·CSS·JS·이미지를 돌려주는 프로그램을 웹 서버라고 합니다. 대표적으로 다음 세 가지를 많이 사용합니다.

웹 서버 특징
Apache 1995년 등장. 오픈소스이고 모든 운영체제에서 동작합니다.
Nginx 이벤트 기반 비동기 처리로 가볍고 빠릅니다. 지금 가장 많이 쓰입니다.
Microsoft IIS Windows 전용. Windows 생태계에 최적화돼 있습니다.

HTTP와 HTTPS

HTTPS는 HTTP에 SSL/TLS 암호화를 적용한 것입니다. 다만 모든 정보가 암호화되는 것은 아니므로, 무엇이 보호되고 드러나는지 알아둘 필요가 있습니다.

공개됨
목적지 주소: 도메인과 IP
어떤 사이트에 접속했는지는 드러납니다
암호화됨
요청·응답의 헤더와 바디 전부
그 안에서 무엇을 주고받았는지는 가려집니다

오늘날 HTTPS는 웹의 기본 표준입니다. 적용하지 않으면 Chrome 같은 브라우저에서 "안전하지 않음" 경고가 표시될 수 있습니다.

엔터를 누르면 일어나는 일

이제 처음의 질문으로 돌아가겠습니다. 주소창에 URL을 입력하고 엔터를 누르면, 브라우저는 다음 순서로 동작합니다. 

사용자
브라우저
DNS 서버
웹 서버
 
 
 
 
 
URL 입력 (www.example.com)
 
DNS 요청 (www.example.com)
 
IP 주소 응답 (93.184.216.34)
 
TCP 연결 수립 요청 (3-Way Handshake)
 
TCP 연결 수립 승인 (3-Way Handshake)
 
HTTP 요청 전송 (GET / HTTP/1.1)
 
HTTP 응답 (HTML / CSS / JS)
 
 
HTML / CSS / JS 렌더링
 
웹 페이지 표시
사용자
브라우저
DNS 서버
웹 서버
직접 확인: 크롬에서 F12 → Network 탭을 열고 아무 사이트나 들어가 보세요. 요청 하나를 클릭하면 지금까지 이야기한 Request Header, Response Header, 상태 코드를 확인할 수 있습니다. 

정리하면

마지막으로 상황에 따라 무엇을 고르면 되는지 정리하겠습니다.

  • TCP vs UDP: 정확한 전달이 중요하면 TCP, 실시간성이 중요하면 UDP.
  • HTTP vs HTTPS: 실제 서비스라면 HTTPS. 로그인·결제가 있다면 필수
  • GET vs POST: 조회는 GET, 값을 바꾸거나 생성·전송할 떄는 POST. ( 민감한 정보는 POST여부와 관계없이 반드시 HTTPS로 보호)
한 줄 정리: URL을 입력하면 → DNS가 IP를 찾고 → TCP가 연결을 맺고 → HTTP로 요청과 응답을 주고받아 → 브라우저가 화면에 그립니다. 웹 통신은 이 다섯 단계입니다.

참고

다음 글에서는 이렇게 받아온 HTML·CSS·JavaScript가 각각 무슨 일을 하는지 정리해보겠습니다.