Blog

인증(Authentication)과 인가(Authorization)의 차이

웹 서비스나 서버를 공부하다 보면 인증과 인가라는 용어를 자주 접하게 됩니다. 특히 로그인 시스템을 구현하거나 API 보안을 설계할 때 반드시 이해해야 하는 핵심 개념입니다. 두 단어는 비슷해 보이지만, 의미와 역할은 명확히 다릅니다.

먼저 인증(Authentication)부터 살펴보겠습니다. 인증은 “당신이 누구인가?”를 확인하는 과정입니다. 즉, 사용자의 신원을 검증하는 절차입니다. 우리가 웹사이트에 로그인할 때 아이디와 비밀번호를 입력하는 행위가 바로 인증 과정입니다. 서버는 입력된 정보가 저장된 데이터와 일치하는지 확인하여 해당 사용자가 실제로 그 계정의 소유자인지 판단합니다.

인증 방법에는 여러 가지가 있습니다. 가장 기본적인 방식은 아이디와 비밀번호입니다. 최근에는 보안을 강화하기 위해 2단계 인증(OTP, 문자 인증), 생체 인증(지문, 얼굴 인식), OAuth 기반 소셜 로그인(Google, Kakao, Naver 로그인) 등 다양한 방식이 사용됩니다. 이 모든 방식의 목적은 동일합니다. 사용자의 신원을 확인하는 것입니다.

반면 인가(Authorization)는 “무엇을 할 수 있는가?”를 결정하는 과정입니다. 인증이 완료된 후, 해당 사용자가 어떤 자원에 접근할 권한이 있는지 판단합니다. 예를 들어 관리자 계정은 모든 게시글을 삭제할 수 있지만, 일반 사용자는 자신의 게시글만 삭제할 수 있도록 제한할 수 있습니다. 이것이 바로 인가입니다.

즉, 인증은 신원을 확인하는 것이고, 인가는 권한을 확인하는 것입니다.

이 둘의 관계를 순서로 정리하면 다음과 같습니다.
1단계: 인증 – 사용자가 누구인지 확인
2단계: 인가 – 그 사용자가 무엇을 할 수 있는지 결정

인증이 되지 않은 사용자는 인가 단계로 넘어갈 수 없습니다. 예를 들어 로그인하지 않은 사용자는 관리자 페이지에 접근할 수 없습니다. 로그인에 성공해도 일반 사용자라면 관리자 기능을 사용할 수 없습니다.

비유를 들어보면 이해하기 쉽습니다. 회사 건물에 들어갈 때 신분증을 제시하는 것이 인증입니다. 신분증을 통해 직원인지 방문객인지 확인합니다. 그리고 회의실, 서버실, 연구실 등 특정 공간에 들어갈 수 있는 권한을 부여받는 것이 인가입니다. 신분은 같더라도 직급이나 역할에 따라 접근 가능한 공간이 다릅니다.

웹 개발에서는 이 개념이 매우 중요합니다. 예를 들어 REST API 서버를 만든다고 가정해봅시다. /admin/users 삭제 API가 있다고 할 때, 서버는 먼저 사용자가 로그인했는지(인증)를 확인합니다. 그 다음 해당 사용자가 관리자 권한을 가지고 있는지(인가)를 확인합니다. 이 두 단계를 모두 통과해야 요청이 처리됩니다.

기술적으로는 인증 후에 토큰이나 세션이 발급됩니다. 예를 들어 JWT(JSON Web Token)를 사용하면, 로그인 성공 시 서버가 토큰을 발급합니다. 이후 요청 시 이 토큰을 함께 보내면 서버는 토큰을 검증하여 인증을 확인합니다. 그리고 토큰 안에 포함된 role 정보(예: USER, ADMIN)를 기반으로 인가를 수행합니다.

보안 측면에서도 인증과 인가는 명확히 분리되어야 합니다. 인증이 강력하지 않으면 계정 탈취 위험이 증가합니다. 인가 로직이 잘못 설계되면 권한 상승(Privilege Escalation) 공격이 발생할 수 있습니다. 예를 들어 일반 사용자가 관리자 기능을 실행할 수 있다면 심각한 보안 사고로 이어질 수 있습니다.

대규모 시스템에서는 RBAC(Role-Based Access Control) 같은 방식이 사용됩니다. 이는 사용자에게 역할(Role)을 부여하고, 역할에 따라 권한을 관리하는 방식입니다. 최근에는 ABAC(Attribute-Based Access Control)처럼 사용자 속성, 리소스 속성, 환경 조건 등을 종합적으로 고려하는 방식도 사용됩니다.

정리하자면 인증(Authentication)은 사용자의 신원을 확인하는 과정이고, 인가(Authorization)는 그 사용자가 어떤 행동을 할 수 있는지 결정하는 과정입니다. 인증이 먼저 수행되고, 그 다음 인가가 이루어집니다. 두 개념은 웹 보안의 핵심이며, 로그인 시스템과 API 보안을 설계할 때 반드시 구분해서 이해해야 합니다.

서버와 보안을 공부하는 입문자라면 “인증은 누구인지 확인하는 것, 인가는 무엇을 할 수 있는지 정하는 것”이라는 문장을 반드시 기억해야 합니다. 이 차이를 명확히 이해하는 것이 안전한 시스템 설계의 출발점입니다.

세션(Session)과 쿠키(Cookie)의 차이

웹사이트에 로그인하면 페이지를 이동해도 로그인 상태가 유지됩니다. 장바구니에 상품을 담아두면 다른 페이지로 이동해도 그대로 남아 있습니다. 그런데 HTTP는 기본적으로 무상태(Stateless) 프로토콜입니다. 즉, 요청과 응답이 끝나면 이전 상태를 기억하지 않습니다. 그렇다면 웹은 어떻게 사용자 상태를 유지할까요? 그 핵심이 바로 쿠키와 세션입니다.

먼저 쿠키(Cookie)부터 살펴보겠습니다. 쿠키는 서버가 브라우저에 저장하도록 보내는 작은 데이터 조각입니다. 브라우저는 이를 로컬에 저장해두고, 이후 같은 서버에 요청을 보낼 때 자동으로 함께 전송합니다. 쿠키는 키-값(key-value) 형태로 저장되며, 만료 시간(Expiration), 도메인, 경로(Path) 등의 정보를 포함할 수 있습니다.

예를 들어 사용자가 로그인하면 서버는 “login=true” 같은 쿠키를 브라우저에 저장할 수 있습니다. 이후 사용자가 다른 페이지를 요청할 때 이 쿠키가 함께 전송되어 로그인 여부를 확인합니다.

쿠키는 클라이언트(브라우저)에 저장된다는 점이 가장 큰 특징입니다. 따라서 사용자가 브라우저 개발자 도구를 통해 직접 확인하거나 수정할 수 있습니다. 이 때문에 민감한 정보(비밀번호, 주민번호 등)를 쿠키에 직접 저장하는 것은 매우 위험합니다.

반면 세션(Session)은 서버에 저장되는 사용자 상태 정보입니다. 사용자가 로그인하면 서버는 고유한 세션 ID를 생성하고, 해당 세션 ID와 사용자 정보를 서버 메모리나 데이터베이스에 저장합니다. 그리고 이 세션 ID를 쿠키에 담아 브라우저로 전달합니다.

이후 사용자가 요청을 보낼 때 브라우저는 세션 ID가 담긴 쿠키를 함께 전송합니다. 서버는 이를 통해 해당 사용자의 세션 정보를 조회합니다. 즉, 실제 데이터는 서버에 있고, 브라우저에는 세션을 식별하기 위한 ID만 존재합니다.

정리하면 다음과 같습니다.

쿠키는 클라이언트에 저장되는 데이터이고,
세션은 서버에 저장되는 데이터입니다.

그렇다면 왜 굳이 두 개념이 함께 등장할까요? 실제로 세션을 구현할 때 쿠키가 사용됩니다. 세션 ID를 클라이언트가 기억하고 있어야 서버가 사용자를 식별할 수 있기 때문입니다. 따라서 세션은 쿠키를 활용해 동작하는 구조라고 이해하면 됩니다.

보안 측면에서 보면 세션이 상대적으로 안전합니다. 중요한 데이터는 서버에만 저장되기 때문입니다. 하지만 세션 ID가 탈취되면 세션 하이재킹(Session Hijacking) 공격이 발생할 수 있습니다. 이를 방지하기 위해 HTTPS를 사용하고, HttpOnly, Secure 옵션을 설정합니다.

쿠키에도 다양한 옵션이 존재합니다.
HttpOnly: 자바스크립트에서 접근 불가하게 설정
Secure: HTTPS 연결에서만 전송
SameSite: 다른 사이트에서 쿠키를 보내지 못하도록 제한

이러한 설정은 XSS, CSRF 같은 웹 공격을 방지하는 데 중요합니다.

성능 측면에서도 차이가 있습니다. 쿠키는 요청마다 함께 전송되기 때문에 데이터 크기가 커지면 네트워크 부담이 증가합니다. 반면 세션은 서버 자원을 사용합니다. 사용자 수가 많아지면 서버 메모리 사용량이 증가할 수 있습니다. 그래서 대규모 서비스에서는 세션을 Redis 같은 외부 저장소에 저장하기도 합니다.

최근에는 JWT(JSON Web Token) 방식도 많이 사용됩니다. 이는 세션 대신 토큰 기반 인증을 사용하는 방식입니다. 서버가 상태를 저장하지 않고, 토큰 자체에 사용자 정보를 담아 무상태 인증을 구현합니다.

비유를 들어보면 쿠키는 사용자가 직접 들고 다니는 메모지와 같습니다. 메모지에 적힌 정보를 서버에 보여주는 구조입니다. 반면 세션은 서버에 보관된 출입 기록과 같습니다. 사용자는 출입증 번호(세션 ID)만 가지고 있고, 실제 정보는 서버가 관리합니다.

정리하자면 쿠키는 클라이언트에 저장되는 작은 데이터이고, 세션은 서버에 저장되는 사용자 상태 정보입니다. HTTP의 무상태 특성을 보완하기 위해 두 개념이 함께 사용됩니다. 로그인 유지, 장바구니, 사용자 인증 등 웹 서비스의 기본 기능은 대부분 세션과 쿠키를 기반으로 동작합니다. 서버와 웹 보안을 이해하려면 반드시 구분해서 알아야 할 핵심 개념입니다.

REST API란 무엇인가?

웹 개발이나 서버를 공부하다 보면 “REST API”라는 용어를 자주 접하게 됩니다. 현대 웹 서비스 대부분은 REST API 구조 위에서 동작한다고 해도 과언이 아닙니다. 그렇다면 REST API는 무엇이며, 왜 이렇게 널리 사용될까요?

먼저 API(Application Programming Interface)부터 이해해보겠습니다. API는 프로그램과 프로그램이 서로 통신하기 위한 인터페이스입니다. 예를 들어 프론트엔드(웹 화면)가 백엔드 서버에 데이터를 요청할 때, 정해진 규칙에 따라 요청을 보내고 응답을 받습니다. 이 통신 규칙이 바로 API입니다.

그렇다면 REST는 무엇일까요? REST(Representational State Transfer)는 2000년 로이 필딩(Roy Fielding)이 제안한 아키텍처 스타일입니다. REST는 웹의 기존 구조, 특히 HTTP 프로토콜의 특성을 최대한 활용하는 설계 방식입니다. 즉, REST API는 HTTP 기반으로 자원을 다루는 API 설계 원칙이라고 이해하면 됩니다.

REST의 핵심 개념은 “자원(Resource)”입니다. 여기서 자원은 서버가 관리하는 모든 데이터입니다. 예를 들어 사용자 정보, 게시글, 상품 목록 등이 자원이 됩니다. REST에서는 이 자원을 URI(Uniform Resource Identifier)로 표현합니다.

예를 들어 다음과 같은 URI를 생각해볼 수 있습니다.

GET /users
GET /users/1
POST /users
DELETE /users/1

이처럼 자원은 명사 형태로 표현됩니다. 동사는 HTTP 메서드가 담당합니다. 이것이 REST의 중요한 특징입니다.

HTTP 메서드는 자원에 대해 어떤 행위를 할 것인지를 나타냅니다. 대표적인 메서드는 다음과 같습니다.

GET: 자원 조회
POST: 자원 생성
PUT: 자원 전체 수정
PATCH: 자원 일부 수정
DELETE: 자원 삭제

예를 들어 /users/1에 GET 요청을 보내면 1번 사용자의 정보를 조회합니다. DELETE 요청을 보내면 해당 사용자를 삭제합니다. URI는 자원을 표현하고, HTTP 메서드는 행위를 표현합니다.

REST의 또 다른 중요한 특징은 무상태성(Stateless)입니다. 이는 서버가 클라이언트의 이전 요청 상태를 저장하지 않는다는 의미입니다. 각각의 요청은 독립적으로 처리되어야 하며, 필요한 모든 정보는 요청 안에 포함되어야 합니다. 이 구조 덕분에 서버는 확장성이 좋아집니다. 로드 밸런싱이나 수평 확장이 쉬워지는 이유가 바로 여기에 있습니다.

또한 REST는 클라이언트와 서버의 역할을 명확히 분리합니다. 클라이언트는 사용자 인터페이스와 사용자 경험을 담당하고, 서버는 데이터와 비즈니스 로직을 처리합니다. 이 분리 덕분에 프론트엔드와 백엔드를 독립적으로 개발할 수 있습니다.

실제 응답 데이터는 대부분 JSON 형식으로 전달됩니다. 예를 들어 GET /users/1 요청에 대해 다음과 같은 JSON이 반환될 수 있습니다.

{
“id”: 1,
“name”: “홍길동”,
“email”: “test@example.com“
}

이처럼 REST API는 데이터 중심으로 설계되며, 클라이언트는 이 데이터를 받아 화면에 표시합니다.

REST API가 널리 사용되는 이유는 단순성과 확장성 때문입니다. HTTP 표준을 그대로 활용하기 때문에 별도의 복잡한 규칙이 필요하지 않습니다. 또한 웹 환경에 최적화되어 있어 브라우저, 모바일 앱, 서버 간 통신 등 다양한 환경에서 쉽게 사용할 수 있습니다.

하지만 REST API가 모든 상황에 완벽한 것은 아닙니다. 대규모 데이터 조회나 복잡한 쿼리가 필요한 경우에는 GraphQL 같은 다른 방식이 더 적합할 수 있습니다. 그럼에도 불구하고 REST는 여전히 가장 보편적인 API 설계 방식입니다.

정리하자면, REST API는 HTTP 프로토콜을 기반으로 자원을 URI로 표현하고, HTTP 메서드를 통해 자원에 대한 행위를 정의하는 설계 방식입니다. 무상태성, 자원 중심 설계, 클라이언트-서버 분리 등의 특징을 가지고 있으며, 현대 웹 서비스의 핵심 구조라고 할 수 있습니다.

서버와 백엔드를 이해하려면 REST API 개념은 반드시 알아야 합니다. 웹 서비스가 어떻게 데이터를 주고받는지 이해하는 첫걸음이 바로 REST API입니다

방화벽(Firewall)의 역할과 작동 원리

인터넷에 연결된 서버나 개인 PC는 항상 외부 네트워크와 통신하고 있습니다. 하지만 모든 통신이 안전한 것은 아닙니다. 악성 트래픽, 해킹 시도, 불필요한 접근 요청이 끊임없이 발생합니다. 이러한 위협으로부터 시스템을 보호하는 핵심 장치가 바로 방화벽(Firewall)입니다.

방화벽은 말 그대로 “불을 막는 벽”이라는 의미를 가지고 있습니다. 건물에서 화재가 다른 구역으로 번지는 것을 막는 것처럼, 네트워크에서도 위험한 접근이 내부 시스템으로 들어오는 것을 차단하는 역할을 합니다. 즉, 네트워크의 출입을 통제하는 보안 장치입니다.

방화벽의 기본 역할은 네트워크 트래픽을 검사하고 허용하거나 차단하는 것입니다. 여기서 트래픽이란 인터넷을 통해 오가는 데이터 패킷을 의미합니다. 방화벽은 각 패킷의 정보를 확인하여 사전에 정의된 규칙에 따라 통과시킬지 막을지 결정합니다.

예를 들어 웹 서버는 80번(HTTP)이나 443번(HTTPS) 포트를 통해 외부 접속을 허용합니다. 하지만 22번(SSH) 포트는 관리자만 접근해야 할 수도 있습니다. 이 경우 방화벽에서 “외부에서는 80, 443 포트만 허용하고, 22번은 특정 IP만 허용한다”라는 규칙을 설정할 수 있습니다.

방화벽의 작동 원리는 크게 세 가지 방식으로 구분됩니다.

첫 번째는 패킷 필터링(Packet Filtering) 방식입니다. 가장 기본적인 형태의 방화벽으로, 각 패킷의 출발지 IP, 목적지 IP, 포트 번호, 프로토콜(TCP/UDP) 등을 기준으로 허용 또는 차단을 결정합니다. 비교적 단순하고 빠르지만, 패킷의 내부 내용까지 깊게 분석하지는 않습니다.

두 번째는 상태 기반 검사(Stateful Inspection) 방식입니다. 이는 단순히 개별 패킷만 보는 것이 아니라, 연결의 상태를 추적합니다. 예를 들어 내부에서 시작한 TCP 연결에 대한 응답 패킷은 허용하지만, 외부에서 갑자기 시작되는 비정상 연결은 차단합니다. 현재 대부분의 방화벽은 이 방식을 사용합니다.

세 번째는 애플리케이션 레벨 방화벽(Application Layer Firewall)입니다. 이는 OSI 7계층 중 애플리케이션 계층까지 분석하는 방식입니다. 단순히 포트만 보는 것이 아니라 HTTP 요청의 내용, 특정 URL 접근 여부, 악성 스크립트 포함 여부 등을 검사합니다. 보안 수준이 높지만 상대적으로 성능 부담이 있습니다.

방화벽은 위치에 따라 네트워크 방화벽과 호스트 기반 방화벽으로 나눌 수 있습니다. 네트워크 방화벽은 공유기나 라우터, 기업 보안 장비에 설치되어 전체 네트워크를 보호합니다. 반면 호스트 기반 방화벽은 개별 서버나 PC에 설치되어 해당 장치만 보호합니다. 예를 들어 리눅스의 iptables, ufw, Windows Defender Firewall이 이에 해당합니다.

클라우드 환경에서도 방화벽은 매우 중요합니다. AWS에서는 Security Group과 Network ACL이 방화벽 역할을 합니다. Security Group은 인스턴스 단위의 방화벽이고, Network ACL은 서브넷 단위의 방화벽입니다. 이를 통해 어떤 IP가 어떤 포트로 접근할 수 있는지 세밀하게 제어합니다.

방화벽은 기본적인 보안 장치이지만 만능은 아닙니다. 방화벽은 설정된 규칙에 따라 동작하기 때문에 규칙이 잘못 설정되면 보안이 무력화될 수 있습니다. 또한 내부에서 발생하는 공격이나 이미 허용된 트래픽 안에 숨겨진 악성 코드까지 완벽하게 막지는 못합니다. 그래서 IDS(침입 탐지 시스템)나 IPS(침입 방지 시스템)와 함께 사용되기도 합니다.

비유를 들어보면 방화벽은 건물의 출입 통제 시스템과 같습니다. 경비원이 방문자의 신분을 확인하고, 허가된 사람만 통과시킵니다. 하지만 경비 규칙이 잘못 설정되어 있다면 누구나 들어올 수 있습니다. 따라서 방화벽 설정은 매우 신중해야 합니다.

정리하자면 방화벽은 네트워크 트래픽을 검사하고, 허용 또는 차단하는 보안 장치입니다. 패킷 필터링, 상태 기반 검사, 애플리케이션 레벨 검사 등 다양한 방식이 있으며, 서버와 클라우드 환경에서 필수적인 보안 구성 요소입니다. 서버를 운영하거나 네트워크를 설계할 때 방화벽을 이해하지 못하면 보안 사고로 이어질 가능성이 높습니다. 따라서 방화벽의 역할과 작동 원리는 네트워크 기초를 공부하는 사람이라면 반드시 알아야 할 핵심 개념입니다.

NAT(Network Address Translation)란 무엇인가?

인터넷을 사용하다 보면 집이나 회사 내부에서는 여러 대의 기기가 동시에 인터넷에 접속합니다. 그런데 외부에서는 하나의 공인 IP 주소만 보이는 경우가 많습니다. 어떻게 이런 일이 가능할까요? 그 핵심 기술이 바로 NAT(Network Address Translation), 즉 네트워크 주소 변환입니다.

NAT는 내부 네트워크에서 사용하는 사설 IP 주소를 외부 통신 시 공인 IP 주소로 변환해주는 기술입니다. 쉽게 말해, 내부 주소와 외부 주소를 서로 바꿔주는 중간 변환 장치 역할을 합니다. 이 기능은 주로 공유기나 라우터에서 수행됩니다.

먼저 왜 NAT가 필요한지 이해해보겠습니다. IPv4 체계에서는 약 43억 개의 IP 주소만 사용할 수 있습니다. 전 세계 인구와 인터넷 기기 수를 고려하면 턱없이 부족합니다. 이를 해결하기 위해 내부 네트워크에서는 사설 IP 대역을 사용하고, 외부 인터넷과 통신할 때만 공인 IP를 사용하는 구조가 만들어졌습니다. NAT는 바로 이 연결 고리 역할을 합니다.

예를 들어 집에 노트북, 스마트폰, 태블릿이 각각 192.168.0.2, 192.168.0.3, 192.168.0.4라는 사설 IP를 가지고 있다고 가정해봅시다. 이 기기들이 웹사이트에 접속하면 외부 서버는 이 사설 IP를 직접 알 수 없습니다. 대신 공유기는 내부 요청을 받아 자신의 공인 IP 주소로 변환하여 인터넷에 요청을 보냅니다. 외부 서버는 그 공인 IP로 응답을 보내고, 공유기는 이를 다시 내부의 해당 사설 IP 장치로 전달합니다.

이 과정을 조금 더 기술적으로 설명하면 다음과 같습니다. 내부 장치가 패킷을 보내면 공유기는 출발지 IP 주소를 사설 IP에서 공인 IP로 변경합니다. 동시에 출발지 포트 번호도 함께 기록해 둡니다. 이 정보를 NAT 테이블에 저장합니다. 이후 외부에서 응답이 오면, 공유기는 목적지 포트 번호를 기준으로 NAT 테이블을 조회해 어떤 내부 장치가 요청했는지 확인하고 해당 사설 IP로 전달합니다.

NAT에는 몇 가지 유형이 있습니다. 가장 일반적인 것은 PAT(Port Address Translation)입니다. 이는 하나의 공인 IP를 여러 내부 장치가 공유하면서 포트 번호를 통해 구분하는 방식입니다. 우리가 가정용 공유기를 사용할 때 대부분 이 방식을 사용합니다. 이 덕분에 하나의 공인 IP로 여러 대의 기기가 동시에 인터넷을 사용할 수 있습니다.

또 다른 유형으로는 정적 NAT(Static NAT)가 있습니다. 이는 특정 사설 IP를 특정 공인 IP와 1:1로 고정 매핑하는 방식입니다. 주로 내부 서버를 외부에 공개해야 할 때 사용됩니다. 동적 NAT(Dynamic NAT)는 여러 공인 IP 풀 중 하나를 동적으로 할당하는 방식입니다.

NAT는 IP 주소 부족 문제를 해결하는 데 매우 중요한 역할을 했습니다. 만약 NAT가 없었다면 IPv4 환경에서는 훨씬 빠르게 주소가 고갈되었을 것입니다. 하지만 NAT는 완벽한 기술은 아닙니다. 몇 가지 단점도 존재합니다.

첫째, 외부에서 내부 장치로 직접 접속하기 어렵습니다. 기본적으로 NAT는 내부에서 외부로 나가는 연결만 허용합니다. 그래서 내부 서버를 외부에 공개하려면 포트 포워딩 설정을 해야 합니다. 예를 들어 192.168.0.10의 웹 서버를 외부에 공개하려면 공유기에서 80번 포트를 해당 사설 IP로 연결해줘야 합니다.

둘째, 일부 실시간 통신이나 P2P 서비스에서 NAT는 복잡성을 증가시킵니다. 그래서 STUN, TURN 같은 추가 기술이 필요합니다. 또한 IPv6가 도입되면서 NAT 없이도 충분한 IP 주소를 제공할 수 있는 환경이 만들어지고 있습니다.

비유를 들어보면 NAT는 회사의 대표 전화번호와 같습니다. 회사 전체에는 하나의 대표 번호(공인 IP)가 있지만, 내부에는 여러 부서(사설 IP)가 존재합니다. 외부에서 전화를 걸면 교환원이 어느 부서로 연결할지 판단해 전달합니다. 공유기가 바로 이 교환원 역할을 합니다.

정리하자면 NAT는 내부 사설 IP와 외부 공인 IP 사이를 연결해주는 주소 변환 기술입니다. 이를 통해 IP 주소 부족 문제를 해결하고, 내부 네트워크를 보호하는 기본적인 보안 효과도 제공합니다. 서버 운영, 포트 포워딩, 클라우드 네트워크 구성 등을 이해하려면 NAT 개념은 반드시 알고 있어야 합니다. 네트워크 구조를 이해하는 핵심 요소 중 하나가 바로 NAT입니다.

공인 IP와 사설 IP의 차이

인터넷을 사용하다 보면 “IP 주소”라는 말을 자주 듣게 됩니다. IP 주소는 인터넷에서 장치를 식별하는 고유한 번호입니다. 마치 집 주소처럼 네트워크 상에서 데이터가 어디로 가야 하는지를 알려주는 역할을 합니다. 그런데 IP에는 공인 IP와 사설 IP라는 두 가지 종류가 있습니다. 이 둘은 어떤 차이가 있을까요?

먼저 공인 IP(Public IP)부터 살펴보겠습니다. 공인 IP는 전 세계에서 유일한 주소입니다. 인터넷에 직접 연결된 장치가 사용하는 주소이며, 외부에서 접근이 가능합니다. 예를 들어 우리가 운영하는 웹 서버나 회사의 메일 서버는 외부 사용자들이 접속해야 하기 때문에 공인 IP를 사용합니다. 공인 IP는 인터넷 서비스 제공업체(ISP)로부터 할당받습니다.

반면 사설 IP(Private IP)는 내부 네트워크에서만 사용하는 주소입니다. 집이나 회사 내부에서 사용하는 공유기 뒤의 컴퓨터, 스마트폰, 노트북 등이 사용하는 IP가 바로 사설 IP입니다. 대표적인 사설 IP 대역은 다음과 같습니다.
10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

집에서 와이파이에 연결했을 때 192.168.0.x 같은 주소를 본 적이 있다면 그것이 바로 사설 IP입니다.

그렇다면 왜 굳이 두 가지를 나눠서 사용할까요? 가장 큰 이유는 IP 주소의 부족 문제입니다. IPv4는 약 43억 개의 주소만 제공할 수 있습니다. 전 세계 인터넷 사용자 수와 IoT 기기 수를 고려하면 매우 부족합니다. 그래서 내부 네트워크에서는 사설 IP를 사용하고, 외부와 통신할 때만 공인 IP를 사용하는 구조가 만들어졌습니다.

여기서 등장하는 개념이 NAT(Network Address Translation)입니다. 공유기는 내부 장치들이 사용하는 사설 IP를 외부 통신 시 공인 IP로 변환해줍니다. 예를 들어 집 안의 노트북이 웹사이트에 접속하면, 실제 인터넷 상에서는 공유기의 공인 IP로 요청이 나가게 됩니다. 외부 서버는 그 공인 IP로 응답을 보내고, 공유기가 다시 내부 장치의 사설 IP로 전달합니다.

이를 비유하면 아파트와 비슷합니다. 아파트 건물 전체에는 하나의 공식 주소(공인 IP)가 있지만, 각 세대에는 내부 호수(사설 IP)가 있습니다. 택배는 건물 주소로 오고, 관리인이 각 세대로 배달해줍니다. 공유기가 바로 이 관리인 역할을 합니다.

보안 측면에서도 차이가 있습니다. 공인 IP는 인터넷에 직접 노출되기 때문에 외부 공격 대상이 될 수 있습니다. 따라서 방화벽 설정과 보안 관리가 매우 중요합니다. 반면 사설 IP는 내부 네트워크에서만 사용되므로 외부에서 직접 접근할 수 없습니다. 이는 기본적인 보안 장벽 역할을 합니다.

서버를 운영할 때도 이 차이는 중요합니다. 예를 들어 AWS EC2 인스턴스를 생성하면 공인 IP와 사설 IP가 모두 할당될 수 있습니다. 사설 IP는 같은 VPC 내부의 서버 간 통신에 사용되고, 공인 IP는 외부 사용자 접속을 위해 사용됩니다. 클라우드 환경에서는 보안을 위해 가능한 한 내부 통신은 사설 IP로 처리하는 것이 일반적입니다.

또한 VPN을 사용할 때도 사설 IP 개념이 활용됩니다. VPN에 접속하면 내부 네트워크의 사설 IP를 부여받아 회사 내부 서버에 접근할 수 있습니다. 이는 외부에서 직접 공인 IP를 열지 않고도 안전하게 접속할 수 있도록 해줍니다.

정리해보면, 공인 IP는 인터넷에서 유일하게 식별되는 주소로 외부 접근이 가능하며, 사설 IP는 내부 네트워크에서만 사용하는 주소입니다. NAT를 통해 두 주소 체계가 연결되고, 이를 통해 IP 부족 문제를 해결하고 보안을 강화합니다.

서버와 네트워크를 이해하려면 이 두 개념을 명확히 구분할 수 있어야 합니다. 특히 클라우드 서버를 운영하거나 포트 포워딩을 설정할 때 공인 IP와 사설 IP의 차이를 이해하지 못하면 설정이 꼬이기 쉽습니다. 기본적이지만 매우 중요한 네트워크 개념 중 하나가 바로 공인 IP와 사설 IP의 차이입니다.

패킷(Packet)이란 무엇인가?

인터넷에서 우리가 보내는 모든 데이터는 하나의 덩어리로 통째로 이동하지 않습니다. 웹페이지를 열거나, 영상을 시청하거나, 파일을 다운로드할 때 데이터는 잘게 나뉘어 전송됩니다. 이때 네트워크를 통해 전달되는 작은 데이터 단위를 패킷(Packet)이라고 합니다. 패킷은 인터넷 통신의 가장 기본적인 전송 단위입니다.

먼저 왜 데이터를 나눌까요? 만약 큰 파일을 한 번에 통째로 보내려 한다면, 네트워크에 문제가 생겼을 때 전체를 다시 보내야 합니다. 이는 매우 비효율적입니다. 또한 여러 사용자가 동시에 네트워크를 사용하는 환경에서는 큰 데이터가 네트워크를 독점할 수 있습니다. 그래서 데이터를 일정 크기로 잘게 나누어 보내고, 도착지에서 다시 조립하는 방식이 사용됩니다.

패킷은 단순히 데이터만 담고 있는 것이 아닙니다. 크게 세 부분으로 구성됩니다. 첫 번째는 헤더(Header), 두 번째는 실제 데이터(페이로드, Payload), 세 번째는 트레일러(Trailer)입니다. 보통 트레일러는 오류 검사를 위한 정보가 들어갑니다.

헤더에는 매우 중요한 정보들이 포함됩니다. 예를 들어 출발지 IP 주소, 목적지 IP 주소, 포트 번호, 패킷 번호(시퀀스 번호), 프로토콜 종류 등이 담깁니다. 쉽게 말해, 패킷 헤더는 “이 데이터가 어디서 왔고 어디로 가야 하는지”를 설명하는 안내서와 같습니다.

비유를 들어보면 패킷은 택배 상자와 비슷합니다. 상자 안에는 실제 물건(데이터)이 들어 있고, 상자 겉면에는 보내는 사람 주소와 받는 사람 주소(IP 주소)가 적혀 있습니다. 택배 회사는 상자의 주소를 보고 배송합니다. 네트워크 장비인 라우터도 마찬가지로 패킷의 헤더를 보고 다음 경로를 결정합니다.

인터넷은 패킷 교환(Packet Switching) 방식으로 동작합니다. 이는 데이터를 여러 패킷으로 나누어 각각 독립적으로 전송하는 방식입니다. 각 패킷은 서로 다른 경로를 통해 이동할 수도 있습니다. 네트워크 상황에 따라 가장 효율적인 길을 선택합니다. 이 때문에 패킷은 반드시 순서대로 도착하지 않을 수 있습니다.

여기서 TCP와 UDP의 차이가 등장합니다. TCP는 패킷이 순서대로 도착하도록 보장하고, 손실된 패킷이 있으면 재전송을 요청합니다. 반면 UDP는 패킷이 손실되어도 별도의 재전송을 하지 않습니다. 즉, 패킷 자체는 동일한 개념이지만, 이를 어떻게 관리하느냐는 프로토콜에 따라 달라집니다.

패킷 크기에는 제한이 있습니다. 이를 MTU(Maximum Transmission Unit)라고 합니다. 일반적인 이더넷 환경에서는 약 1500바이트 정도가 기본입니다. 만약 전송해야 할 데이터가 이보다 크면 여러 개의 패킷으로 분할됩니다. 이를 단편화(Fragmentation)라고 합니다. 단편화가 많아지면 네트워크 성능이 떨어질 수 있기 때문에 MTU 설정은 서버 운영에서 중요한 요소입니다.

패킷은 전송 중 오류가 발생할 수 있습니다. 그래서 오류 검출을 위한 체크섬(Checksum) 정보가 포함됩니다. 수신 측에서는 체크섬을 확인해 데이터가 손상되었는지 판단합니다. 손상되었다면 TCP의 경우 재전송을 요청합니다.

네트워크 보안에서도 패킷은 중요한 분석 대상입니다. 패킷을 분석하는 도구로는 Wireshark 같은 패킷 스니핑 도구가 있습니다. 이를 통해 실제로 어떤 데이터가 오가는지 확인할 수 있습니다. 해킹 탐지, 네트워크 문제 해결, 성능 분석 등에 활용됩니다.

정리하자면, 패킷은 인터넷에서 데이터를 전달하기 위해 사용되는 작은 전송 단위입니다. 헤더에는 출발지와 목적지 정보가 포함되고, 페이로드에는 실제 데이터가 담깁니다. 인터넷은 패킷 교환 방식을 사용해 효율적으로 데이터를 전달하며, TCP와 UDP 같은 프로토콜이 패킷의 신뢰성과 전송 방식을 관리합니다.

우리가 단순히 웹사이트를 클릭하는 순간에도 수십, 수백 개의 패킷이 오가고 있습니다. 패킷을 이해하면 네트워크 구조와 서버 통신 원리를 훨씬 깊이 이해할 수 있습니다. 이는 서버, 클라우드, 보안, 인프라를 공부하는 데 있어 반드시 알아야 할 핵심 개념입니다.

3-Way Handshake란 무엇인가?

인터넷에서 우리가 웹사이트에 접속하거나 데이터를 주고받을 때, 단순히 “데이터를 보낸다”는 행위만으로 통신이 이루어지지는 않습니다. 특히 TCP 기반 통신에서는 데이터를 보내기 전에 반드시 서로 연결을 맺는 과정이 필요합니다. 이 연결 설정 과정을 3-Way Handshake라고 합니다. 직역하면 “세 번의 악수”라는 의미입니다.

TCP는 신뢰성을 보장하는 프로토콜입니다. 데이터가 순서대로 도착하고, 손실되면 재전송하며, 통신 상태를 유지합니다. 이러한 기능을 제공하려면 먼저 “서로 통신 준비가 되었는지” 확인해야 합니다. 이때 사용하는 절차가 바로 3-Way Handshake입니다.

3-Way Handshake는 총 세 단계로 이루어집니다.

첫 번째 단계는 SYN입니다. 클라이언트가 서버에 연결 요청을 보냅니다. 이때 보내는 패킷에는 SYN(Synchronize) 플래그가 설정되어 있습니다. 이는 “나와 연결을 시작하고 싶다”는 의미입니다. 동시에 클라이언트는 자신의 초기 시퀀스 번호(Sequence Number)를 함께 보냅니다. 시퀀스 번호는 이후 데이터의 순서를 관리하기 위해 사용됩니다.

두 번째 단계는 SYN-ACK입니다. 서버는 클라이언트의 요청을 받으면 응답을 보냅니다. 이 응답에는 SYN과 ACK(Acknowledgment) 플래그가 함께 설정됩니다. SYN은 “나도 연결을 수락한다”는 의미이고, ACK는 “너의 요청을 잘 받았다”는 확인 메시지입니다. 서버 또한 자신의 초기 시퀀스 번호를 함께 전달합니다.

세 번째 단계는 ACK입니다. 클라이언트는 서버의 응답을 확인한 후, 다시 ACK 패킷을 보냅니다. 이는 “서버의 응답을 잘 받았고 연결이 완료되었다”는 의미입니다. 이 세 번째 메시지가 전달되면 TCP 연결이 완전히 성립됩니다.

이 과정을 정리하면 다음과 같습니다.
클라이언트 → SYN → 서버
서버 → SYN + ACK → 클라이언트
클라이언트 → ACK → 서버

이 세 번의 교환이 완료되어야만 실제 데이터 전송이 시작됩니다.

왜 굳이 세 번이나 확인해야 할까요? 그 이유는 신뢰성과 동기화 때문입니다. 네트워크 환경에서는 패킷이 손실되거나 지연될 수 있습니다. 단순히 한 번의 요청과 한 번의 응답만으로는 양쪽이 동일한 상태에 있는지 보장하기 어렵습니다. 세 번의 교환을 통해 양쪽 모두가 서로의 존재와 준비 상태를 확실히 확인합니다.

또한 이 과정에서 교환되는 시퀀스 번호는 이후 데이터 흐름을 관리하는 핵심 요소입니다. TCP는 각 데이터 조각에 번호를 붙여 전송합니다. 만약 데이터가 순서가 바뀌어 도착하거나 일부가 손실되면, 이 시퀀스 번호를 기준으로 재정렬하거나 재전송을 요청합니다. 따라서 3-Way Handshake는 단순한 연결 요청이 아니라, 향후 데이터 관리의 기준을 설정하는 중요한 단계입니다.

비유를 들어보면 3-Way Handshake는 전화 통화와 비슷합니다.
A: “여보세요?”
B: “네, 들립니다.”
A: “저도 잘 들립니다.”
이 과정을 거쳐야 비로소 본격적인 대화가 시작됩니다.

이와 반대로 UDP는 이런 연결 과정이 없습니다. 데이터를 바로 전송합니다. 그래서 속도는 빠르지만 신뢰성은 낮습니다. 반면 TCP는 연결 설정 과정이 있어 초기 지연이 조금 발생하지만, 안정적인 통신을 보장합니다.

보안 측면에서도 3-Way Handshake는 중요합니다. 예를 들어 SYN Flood 공격은 이 과정을 악용하는 대표적인 DDoS 공격 방식입니다. 공격자는 다량의 SYN 요청을 보내고 마지막 ACK를 보내지 않아 서버 자원을 고갈시킵니다. 이를 방지하기 위해 SYN Cookie 같은 보안 기술이 사용됩니다.

정리하자면, 3-Way Handshake는 TCP 통신에서 연결을 설정하기 위한 세 단계의 확인 절차입니다. SYN, SYN-ACK, ACK의 과정을 통해 서로의 준비 상태를 확인하고, 시퀀스 번호를 동기화하며, 안정적인 데이터 전송 기반을 마련합니다. 서버와 네트워크를 이해하려면 반드시 알아야 할 핵심 개념이며, 웹 브라우징, 파일 다운로드, HTTPS 통신 등 대부분의 인터넷 활동 뒤에는 이 과정이 숨어 있습니다.

TCP와 UDP의 차이 쉽게 이해하기

인터넷에서 데이터는 어떻게 오갈까요? 우리가 웹사이트를 열고, 영상을 보고, 게임을 하고, 파일을 다운로드할 때 모든 데이터는 네트워크를 통해 전송됩니다. 이때 가장 핵심이 되는 통신 규칙이 바로 TCP와 UDP입니다. 둘 다 전송 계층(Transport Layer)에서 동작하는 프로토콜이며, 데이터를 목적지까지 전달하는 역할을 합니다. 하지만 동작 방식과 특징은 상당히 다릅니다.

먼저 TCP(Transmission Control Protocol)부터 살펴보겠습니다. TCP는 신뢰성을 가장 중요하게 생각하는 프로토콜입니다. 데이터를 보내기 전에 반드시 연결을 먼저 맺습니다. 이 과정을 3-Way Handshake라고 부릅니다. 클라이언트가 연결 요청을 보내고, 서버가 응답하고, 다시 클라이언트가 확인 응답을 보내면서 연결이 성립됩니다. 이 과정 덕분에 서로 통신 준비가 되었는지 확인할 수 있습니다.

TCP의 가장 큰 특징은 “데이터가 반드시 순서대로, 빠짐없이 도착하도록 보장한다”는 점입니다. 만약 전송 중에 데이터가 손실되면 재전송을 요청합니다. 또한 데이터가 도착할 때 순서가 뒤바뀌면 올바른 순서로 다시 정렬합니다. 이런 기능을 흐름 제어(Flow Control), 오류 제어(Error Control), 혼잡 제어(Congestion Control)라고 합니다.

그래서 TCP는 웹 브라우징(HTTP/HTTPS), 파일 다운로드, 이메일 전송처럼 정확성이 중요한 서비스에 사용됩니다. 예를 들어 웹페이지 HTML 파일이 일부만 빠져서 도착한다면 화면이 깨질 수 있습니다. 이런 상황을 방지하기 위해 TCP를 사용하는 것입니다.

반면 UDP(User Datagram Protocol)는 구조가 훨씬 단순합니다. UDP는 연결을 맺는 과정이 없습니다. 데이터를 그냥 목적지로 바로 전송합니다. 상대방이 준비되었는지, 제대로 받았는지 확인하지 않습니다. 이 때문에 속도가 빠르고 지연이 적습니다.

하지만 UDP는 데이터가 손실되어도 재전송하지 않습니다. 순서도 보장하지 않습니다. 즉, 신뢰성은 낮지만 속도는 빠릅니다. 그렇다면 이런 방식은 언제 필요할까요? 대표적인 예가 실시간 스트리밍과 온라인 게임입니다.

예를 들어 영상 통화를 한다고 가정해보겠습니다. 영상 데이터가 조금 손실되더라도 화면이 잠깐 깨지는 정도로 끝납니다. 하지만 재전송을 기다리느라 화면이 멈춘다면 오히려 사용자 경험이 더 나빠집니다. 그래서 실시간성이 중요한 서비스는 UDP를 사용하는 경우가 많습니다. 온라인 게임 역시 마찬가지입니다. 위치 정보가 아주 약간 손실되더라도 빠른 응답이 더 중요합니다.

비유를 들어보면 TCP는 등기우편과 같습니다. 보냈는지 확인하고, 도착했는지 확인하고, 누락되면 다시 보냅니다. 안전하지만 시간이 조금 더 걸립니다. 반면 UDP는 일반 엽서와 같습니다. 빠르게 보내지만 도착 여부는 보장하지 않습니다.

성능 측면에서도 차이가 있습니다. TCP는 연결 설정과 확인 과정이 있기 때문에 초기 지연이 발생합니다. 또한 혼잡 제어 알고리즘 때문에 네트워크 상황이 나쁘면 속도를 자동으로 줄입니다. UDP는 이런 제어 과정이 거의 없어 빠르지만, 네트워크 혼잡 상황에서는 패킷 손실이 늘어날 수 있습니다.

보안 관점에서도 차이가 있습니다. TCP는 연결 기반이기 때문에 상태를 유지합니다. 반면 UDP는 상태를 유지하지 않기 때문에 공격에 악용될 가능성도 있습니다. 예를 들어 DDoS 공격 중 일부는 UDP 특성을 이용합니다.

최근에는 HTTP/3처럼 UDP 기반으로 동작하는 새로운 기술도 등장했습니다. 이는 UDP의 빠른 특성을 활용하면서도 상위 계층에서 신뢰성을 보완하는 방식입니다. 즉, TCP와 UDP는 단순히 좋고 나쁜 것이 아니라 상황에 따라 선택되는 도구입니다.

정리하자면, TCP는 신뢰성과 정확성을 보장하는 연결 지향형 프로토콜이며, UDP는 속도와 실시간성을 중시하는 비연결형 프로토콜입니다. 웹사이트 접속과 파일 다운로드는 TCP가 적합하고, 실시간 스트리밍과 온라인 게임은 UDP가 적합합니다.

서버와 네트워크를 이해하려면 이 두 프로토콜의 차이를 반드시 알아야 합니다. 어떤 서비스가 어떤 프로토콜 위에서 동작하는지 이해하는 것만으로도 네트워크 구조를 훨씬 깊이 있게 볼 수 있습니다.

DNS는 어떻게 동작하는가? 도메인이 IP로 변환되는 과정

우리가 브라우저에 google.com 같은 도메인을 입력하면 몇 초도 되지 않아 웹페이지가 열립니다. 하지만 인터넷은 실제로 도메인을 이해하지 못합니다. 인터넷에서 통신의 기본 식별자는 IP 주소입니다. 예를 들어 142.250.196.14와 같은 숫자 형태가 실제 서버의 위치를 가리키는 주소입니다. 그렇다면 우리는 왜 숫자가 아닌 도메인을 사용할 수 있을까요? 그 중간에서 동작하는 시스템이 바로 DNS(Domain Name System)입니다.

DNS는 인터넷의 전화번호부라고 자주 비유됩니다. 사람은 이름을 기억하기 쉽지만, 컴퓨터는 숫자를 처리하기 쉽습니다. DNS는 사람이 이해하기 쉬운 도메인 이름을 컴퓨터가 이해하는 IP 주소로 변환해주는 분산형 데이터베이스 시스템입니다.

DNS 동작 과정을 단계별로 살펴보겠습니다. 사용자가 브라우저에 도메인을 입력하면 가장 먼저 브라우저는 로컬 캐시를 확인합니다. 이전에 방문한 적이 있다면 이미 IP 주소를 알고 있을 수 있습니다. 캐시에 정보가 없다면 운영체제의 DNS 캐시를 확인합니다. 여기에도 없다면 이제 본격적인 DNS 조회가 시작됩니다.

다음 단계는 DNS 리졸버(Resolver)입니다. 보통 통신사나 회사 네트워크에서 제공하는 DNS 서버가 이 역할을 합니다. 리졸버는 “이 도메인의 IP가 무엇인가?”라는 질문을 대신 수행합니다. 이 과정을 재귀적 질의(Recursive Query)라고 합니다.

리졸버는 먼저 루트 네임서버(Root Name Server)에 질의합니다. 루트 서버는 전 세계에 분산되어 있으며, “.com, .net, .org” 같은 최상위 도메인(TLD)을 관리하는 서버의 위치를 알려줍니다. 예를 들어 google.com이라면 루트 서버는 “.com을 관리하는 TLD 서버는 여기 있다”라고 응답합니다.

그 다음 리졸버는 .com TLD 서버에 질의합니다. TLD 서버는 해당 도메인을 실제로 관리하는 권한 네임서버(Authoritative Name Server)의 정보를 알려줍니다. 마지막으로 리졸버는 권한 네임서버에 질의하여 해당 도메인의 실제 IP 주소를 받아옵니다.

이렇게 IP 주소를 획득하면 리졸버는 그 결과를 사용자에게 전달하고, 동시에 일정 시간 동안 캐시에 저장합니다. 이 저장 시간을 TTL(Time To Live)이라고 합니다. TTL이 길면 조회 속도는 빨라지지만, IP 변경 시 반영이 늦어질 수 있습니다.

여기서 중요한 점은 DNS가 단일 서버가 아니라 계층 구조를 가진 분산 시스템이라는 것입니다. 루트 서버 → TLD 서버 → 권한 서버 구조로 나뉘어 있으며, 이 구조 덕분에 인터넷 전체가 안정적으로 동작할 수 있습니다. 만약 하나의 중앙 서버가 모든 도메인을 관리한다면 트래픽 폭증이나 장애에 매우 취약했을 것입니다.

DNS에는 다양한 레코드 타입이 존재합니다. 가장 많이 사용하는 것은 A 레코드입니다. 이는 도메인을 IPv4 주소로 매핑합니다. AAAA 레코드는 IPv6 주소를 매핑합니다. CNAME 레코드는 다른 도메인 이름으로 연결할 때 사용합니다. MX 레코드는 이메일 서버를 지정합니다. 이런 레코드들이 모여 하나의 도메인 설정을 구성합니다.

보안 측면에서도 DNS는 중요합니다. DNS 스푸핑이나 캐시 포이즈닝 같은 공격은 사용자를 가짜 사이트로 유도할 수 있습니다. 이를 방지하기 위해 DNSSEC(DNS Security Extensions) 같은 기술이 도입되었습니다. 또한 최근에는 HTTPS 기반의 DoH(DNS over HTTPS) 방식도 사용되어 DNS 요청 자체를 암호화합니다.

정리해보면, DNS는 사용자가 입력한 도메인을 실제 서버의 IP 주소로 변환하는 시스템이며, 계층적이고 분산된 구조로 설계되어 있습니다. 브라우저 → 캐시 확인 → 리졸버 → 루트 서버 → TLD 서버 → 권한 네임서버 순으로 조회가 이루어지고, 최종적으로 IP를 받아 서버와 통신하게 됩니다.

우리가 단순히 도메인을 입력하는 짧은 순간 뒤에는 이처럼 여러 단계의 네트워크 질의 과정이 존재합니다. DNS를 이해하면 서버, 네트워크, 클라우드 구조를 훨씬 깊이 있게 이해할 수 있습니다. 서버를 공부하는 입문자라면 반드시 알아야 할 핵심 개념 중 하나가 바로 DNS입니다.