웹 개발을 위한 네트워크 기초
작업일2026. 07
주소창에 주소를 치고 엔터를 누르면 1초도 안 돼서 페이지가 뜹니다. 그 짧은 사이에 컴퓨터들끼리 어떤 대화가 오가는지, 순서대로 따라가 보려고 합니다.
이 질문 하나를 따라가다 보면 네트워크 기초를 이해할 수 있습니다.
요즘은 AI에게 시켜서 코드를 만드는 바이브 코딩이 흔해졌습니다. 덕분에 화면 하나 띄우는 일은 확실히 빨라졌지만 막상 에러가 나면 어디부터 봐야 할지 막막할 때가 있습니다. 404와 500이 무엇이 다른지, 주소창의 https는 어떤 역할을 하는지조차 헷갈리는 경우가 많습니다.
웹 개발은 보통 HTML부터 배웁니다. 하지만 그 HTML 파일이 어떻게 서버에서 브라우저까지 전달되는지는 쉽게 지나치곤 합니다. 프론트엔드든 백엔드든 결국 우리가 만드는 것은 네트워크를 통해 오가는 데이터입니다. 그래서 이번 글에서는 웹 개발을 위해 꼭 알아야할 네트워크 기초를 정리해보겠습니다.
인터넷과 웹
인터넷은 전 세계 컴퓨터를 연결한 물리적인 통신망입니다. 케이블, 광섬유, 공유기, 라우터 같은 장비로 이루어진 실제 네트워크를 말합니다. 웹, 이메일, 파일 전송 모두는 이 인터넷 위에서 동작하는 서비스입니다. 즉, 웹(WWW)은 인터넷 자체가 아니라 인터넷을 이용하는 여러 서비스 중 하나입니다.
인터넷은 깔려 있는 망이고, 웹은 그 위에서 도는 서비스 중 하나입니다.
| 구분 | 인터넷 (Internet) | 웹 (World Wide Web) |
|---|---|---|
| 정체 | 컴퓨터를 연결한 통신망 (인프라) | 정보를 공유하는 공간 (서비스) |
| 구성 | 케이블, 라우터, 스위치 (하드웨어) | 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라고 합니다. 받는 쪽에서는 아래 계층부터 헤더를 하나씩 제거하면서 원래 데이터만 남게 됩니다.
보내는 쪽은 헤더를 붙이며 내려가고, 받는 쪽은 벗기며 올라갑니다.
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이라고 합니다.
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: activeether 옆이 랜카드에 박혀 있는 MAC 주소이고, inet 옆이 공유기가 나눠준 사설 IP입니다. 이 사설 IP는 카페 와이파이로 옮기면 바뀌지만, MAC 주소는 그대로입니다.
192.168.x.x와 값이 전혀 다를 텐데, 그 사이에서 변환을 해주고 있는 것이 바로 NAT입니다.궁금!사설 IP는 왜 하필 192.168로 시작할까?
10.0.0.0~, 172.16.0.0~, 192.168.0.0~ 세 덩어리입니다.이 중
192.168로 시작하는 대역이 가장 작아서 가정용 공유기 기본값으로 굳어졌습니다. 큰 회사나 학교에서는 기기가 많아 10.으로 시작하는 대역을 쓰는 경우가 많습니다.URL 구조
URL은 자원이 어디에 있는지를 알려주는 주소 규약입니다. 그냥 한 줄처럼 보이지만, 뜯어보면 다섯 조각으로 나뉩니다.
- 프로토콜: 어떤 방식으로 통신할지 (
http/https) - 도메인: 서버의 위치. DNS가 IP 주소로 바꿔 줍니다.
- 포트: 서버의 어느 문으로 들어갈지. HTTP는 80, HTTPS는 443이 기본이라 보통 생략합니다.
- 경로: 서버 안에서 자원이 있는 위치
- 쿼리: 서버에 넘기는 값 (
key=value)
맨 뒤의 쿼리, 즉 물음표(?) 뒤에 붙는 부분이 GET 방식이 데이터를 실어 보내는 자리입니다. 뒤에서 한 번 더 다루겠습니다.
궁금!포트 번호 80과 443은 누가 정한 걸까?
다만 강제 규칙은 아니므로 서버는 다른 포트도 사용할 수 있습니다. 예: 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 조회를 처리한 서버의 주소이고, 아래쪽 Address는 naver.com의 IP입니다. IP가 여러개인 이유는 트래픽을 분산하기 위해 서버를 여러 대 운영하기 때문이며, 접속을 할 때마다 다른 IP로 연결될 수 있습니다.
궁금!DNS 서버는 누가 관리할까?
.com, .kr 같은 최상위 도메인은 각각 담당 기관이 따로 있습니다. .kr은 한국인터넷진흥원(KISA)이 맡고 있습니다.우리가 평소에 질의하는 것은 이 서버들이 아니라, 통신사가 자동으로 물려주는 DNS 서버입니다. 구글의
8.8.8.8이나 클라우드플레어의 1.1.1.1로 직접 바꿔 쓸 수도 있는데, 이걸 바꾸면 접속 속도가 달라지기도 합니다.TCP와 UDP
주소를 찾았다면 이제 데이터를 보낼 차례입니다. Transport 계층에는 성격이 다른 프로토콜 TCP와 UDP가 있습니다.
TCP는 연결 지향적입니다. 데이터를 보내기 전에 양쪽이 먼저 연결을 확립하는 3-Way Handshake를 거칩니다.
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, 이미지)을 주고받기로 약속한 규칙입니다. 클라이언트가 요청을 보내면 서버가 응답을 돌려주는 구조입니다.
요청과 응답 모두 첫 줄 · 헤더 · 바디의 세 부분으로 되어 있습니다. 첫 줄에는 요청의 목적이나 응답 결과, 헤더에는 부가 정보, 바디에는 실제 데이터가 담깁니다.
메서드: 무엇을 하고 싶은지
요청 첫 줄의 메서드는 요청 목적을 나타냅니다.
| 구분 | GET | POST |
|---|---|---|
| 목적 | 자원을 조회 | 자원을 생성·수정 |
| 데이터 위치 | URL 뒤 쿼리스트링에 노출 | Body에 담김 |
| 예 | 검색 결과 보기, 게시글 읽기 | 회원가입, 글쓰기, 로그인 |
이 외에 PUT, PATCH, DELETE, HEAD, OPTIONS 등이 있으며, REST API에서 자주 사용합니다.
상태 코드: 결과가 어땠는지
응답 첫 줄에는 상태 코드가 붙습니다. 앞자리 숫자만으로도 응답 결과를 대략 알 수 있습니다.
201 Created
404 Not Found
Server Error
웹 서버
요청을 받아 HTML·CSS·JS·이미지를 돌려주는 프로그램을 웹 서버라고 합니다. 대표적으로 다음 세 가지를 많이 사용합니다.
| 웹 서버 | 특징 |
|---|---|
| Apache | 1995년 등장. 오픈소스이고 모든 운영체제에서 동작합니다. |
| Nginx | 이벤트 기반 비동기 처리로 가볍고 빠릅니다. 지금 가장 많이 쓰입니다. |
| Microsoft IIS | Windows 전용. Windows 생태계에 최적화돼 있습니다. |
HTTP와 HTTPS
HTTPS는 HTTP에 SSL/TLS 암호화를 적용한 것입니다. 다만 모든 정보가 암호화되는 것은 아니므로, 무엇이 보호되고 드러나는지 알아둘 필요가 있습니다.
오늘날 HTTPS는 웹의 기본 표준입니다. 적용하지 않으면 Chrome 같은 브라우저에서 "안전하지 않음" 경고가 표시될 수 있습니다.
엔터를 누르면 일어나는 일
이제 처음의 질문으로 돌아가겠습니다. 주소창에 URL을 입력하고 엔터를 누르면, 브라우저는 다음 순서로 동작합니다.
정리하면
마지막으로 상황에 따라 무엇을 고르면 되는지 정리하겠습니다.
- TCP vs UDP: 정확한 전달이 중요하면 TCP, 실시간성이 중요하면 UDP.
- HTTP vs HTTPS: 실제 서비스라면 HTTPS. 로그인·결제가 있다면 필수
- GET vs POST: 조회는 GET, 값을 바꾸거나 생성·전송할 떄는 POST. ( 민감한 정보는 POST여부와 관계없이 반드시 HTTPS로 보호)
참고
- MDN: HTTP 개요
- MDN: DNS
- W3Schools: HTTP Methods
- roadmap.sh: Frontend Beginner Roadmap
다음 글에서는 이렇게 받아온 HTML·CSS·JavaScript가 각각 무슨 일을 하는지 정리해보겠습니다.