네트워크 계층 완전 정복 — 서버가 작동하는 4가지 구조와 FastAPI의 정체

서버가 뭔지는 알겠는데, 왜 작동하는지는 모른다. 대부분의 입문자가 여기서 막힌다. 답은 생각보다 단순하다. 서버는 네트워크 계층이라는 4개의 약속 위에서 움직인다. 이 구조를 한 번 잡으면, FastAPI가 왜 존재하는지도 자연스럽게 이해된다.

이 글에서는 네트워크 계층 4단계의 역할을 순서대로 정리하고, 그 끝에 FastAPI의 정체를 직접 확인한다.

네트워크 계층이란 — 4개 층으로 이루어진 통신 구조

두 컴퓨터가 데이터를 주고받으려면 4가지 약속이 필요하다. 이 약속의 묶음을 네트워크 계층이라고 부른다.

맨 아래부터 위로 쌓이는 구조다. 전화선이 없으면 주소도 의미가 없고, 주소가 없으면 데이터를 어디로 보낼지 모른다. 4개 층이 순서대로 맞아떨어져야 통신이 성립한다.

1층 — 물리적 연결, 전화선이 먼저다

네트워크 액세스 계층은 말 그대로 물리적 연결이다. 유선이냐 무선이냐에 따라 규약이 나뉜다.

유선 연결은 이더넷(Ethernet) 규약을 따른다. 우리가 흔히 쓰는 랜선이 이 기준으로 만들어진다. 무선 연결은 4G / 5G / LTE 같은 이름들이 여기에 해당한다. 스마트폰에서 쓰는 무선 네트워크를 어떻게 구성하느냐에 대한 규약이다.

아무리 정교한 소프트웨어도 물리적 연결이 없으면 움직이지 않는다. 서버 개발이 항상 유선 환경에서 이루어지는 이유도 여기에 있다.

2층 — 주소를 정의하는 인터넷 계층

연결이 됐으면 다음은 주소다. 상대방이 어디 있는지 알아야 데이터를 보낼 수 있다.

주소 정의 방식의 국제 규약은 IPv4와 IPv6 두 가지다.

현재 인터넷의 약 99%는 IPv4를 사용한다. IPv4가 점점 고갈되고 있기 때문에 IPv6로의 전환을 준비 중이지만, 실무에서는 여전히 IPv4가 표준이다.

우리 컴퓨터에도 이 두 주소가 공존한다. 집주소에 지번 주소와 도로명 주소가 동시에 존재하는 것과 같다.

3층 — 전송 방식을 정하는 전송 계층

주소까지 정해졌으면 이제 어떻게 보낼 것인가를 약속해야 한다. 데이터를 어떤 방식으로 던지고, 상대방은 어떻게 받을지에 대한 규약이 전송 계층이다.

대표적인 방식은 TCP와 UDP 두 가지다.

TCP는 3-Way Handshake 방식으로 작동한다. 데이터를 보내고, 잘 받았는지 한 번 더 확인하고, 상대방이 “잘 받았어”를 돌려줘야 완결된다. 만약 응답이 없으면 재전송한다. 우리가 영상 스트리밍에서 경험하는 버퍼링이 바로 이 확인 과정이 지연될 때 발생하는 현상이다.

UDP는 그냥 던지고 끝이다. 확인 없이 속도가 생명인 실시간 게임에 주로 쓰인다. 서버 개발의 약 90%는 TCP를 쓴다.

4층 — 요청과 응답의 형식, 응용 계층

마지막은 응용 계층, 즉 프로토콜이다. 데이터를 어떤 형식으로 포장해서 보낼 것인지에 대한 약속이다.

대표적인 프로토콜은 FTP와 HTTP다.

FTP는 최초의 통신 프로토콜이다. 구조가 단순해서 요청은 “동사 + 목적어” 형태로, 응답은 상태 코드와 데이터로 이루어진다.

HTTP는 1991년 팀 버너스-리가 FTP의 한계를 해결하기 위해 만들었다. 요청과 응답의 구조가 더 풍부하다.

서버를 만든다는 것은 결국 이 7가지 요소를 다루는 일이다. 요청에서 필요한 정보를 꺼내 함수를 실행하고, 응답 형식에 맞게 결과를 돌려주는 구조다.

URL에 데이터를 담는다는 게 무슨 뜻인가

처음 들으면 낯설다. URL은 그냥 주소 아닌가? 맞다. 동시에 데이터를 담는 그릇이기도 하다.

예를 들어 서버에 “3 더하기 4″를 요청할 때 URL을 이렇게 구성할 수 있다.

https://서버주소/add/3/4

여기서 /3/4가 데이터다. 서버는 이 숫자를 꺼내 더하기 함수를 실행하고 7을 돌려준다.

URL에 데이터를 넣는 방식은 2가지다.

둘 다 같은 데이터를 서버에 전달한다. 어떤 방식을 쓸지는 개발자 취향이다.

HTTP 메서드 — GET과 POST는 뭐가 다른가

HTTP 요청에는 메서드(Method)가 있다. 서버에게 “중요한 정보가 어디 있는지” 알려주는 힌트다.

브라우저 주소창에 URL을 입력하고 엔터를 치면 자동으로 GET 요청이 간다. 중요한 정보가 URL에 담겨 있다는 뜻이다. POST는 로그인 비밀번호처럼 URL에 노출하면 안 되는 정보를 Body에 숨겨서 보낼 때 쓴다.

실무에서는 GET이 약 90%, POST가 약 10%, 나머지 특수 메서드는 1% 이하다.

FastAPI의 정체 — 네트워크 설정을 한 줄로 끝내는 이유

여기까지 읽었으면 한 가지 질문이 남는다. 서버를 만들 때 저 4개 계층을 매번 직접 설정해야 하나?

답은 “대부분의 개발자는 안 해도 된다”다.

서버를 만드는 사람들의 약 99%는 같은 조합을 쓴다.

• 유선 연결
• IPv4 주소
• TCP 전송
• HTTP 프로토콜

이 조합이 너무 일반적이기 때문에, 누군가가 이 설정 전체를 단 한 줄로 처리해주는 도구를 만들었다. 그게 바로 FastAPI다.

FastAPI는 네트워크 설정을 자동으로 처리한다. 개발자가 신경 써야 할 건 딱 하나, 요청이 왔을 때 어떤 함수를 실행할 것인가다.

from fastapi import FastAPI

app = FastAPI()

@app.get("/add/{num1}/{num2}")
def add(num1: int, num2: int):
    return {"result": num1 + num2}

이 코드가 하는 일이 서버 개발의 전부다. 네트워크 계층 4개를 자동으로 설정하고, URL에서 데이터를 꺼내 함수를 실행하고, 결과를 HTTP 응답 형식으로 돌려준다.

Django, Flask 같은 프레임워크도 같은 역할을 한다. 프레임워크라고 불리는 도구들의 핵심 역할은 결국 하나다. 네트워크 설정을 대신 해주는 것.

마무리 — 서버 개발이 어렵지 않은 이유

서버 개발의 본질을 한 줄로 정리하면 이렇다.

요청에서 데이터를 꺼내 → 함수를 실행하고 → 응답 형식에 맞게 돌려준다.

네트워크 계층 4개는 그 통신이 가능하도록 받쳐주는 구조다. FastAPI는 그 구조를 자동화해서 개발자가 함수에만 집중할 수 있게 해주는 도구다.

현장에서 새 설비를 들일 때도 비슷한 학습 곡선을 거친다. 처음에는 배선도와 통신 규격을 하나하나 손으로 확인해야 마음이 놓인다. 그런데 결국 매번 같은 조합을 쓴다는 걸 알게 되면, 그 조합을 표준화한 설비로 갈아타면서 디테일에서 해방된다. FastAPI가 네트워크 계층 위에서 하는 일이 정확히 이것이다.

기능을 하나씩 추가할 때마다 서버는 성장한다. 네이버도 처음엔 함수 하나였다.

함께 읽으면 좋은 글

HTTP 요청/응답 구조를 잡았다면, 다음은 API 개념 전체를 한 흐름으로 이어서 보는 것이 좋다.

• API 란 무엇인가 — REST API · FastAPI까지 3개 개념을 한 번에 잡는 법

FastAPI가 파이썬 기반이라면, 개발 환경 세팅부터 확인해두는 것이 실수를 줄인다.

• 가상환경 설정이 웹서비스 개발 첫날에 필요한 3가지 이유 — venv + Django 입문 가이드

FastAPI 공식 문서는 fastapi.tiangolo.com에서 한국어 번역본을 포함해 확인할 수 있다.

FAQ