개발나라코드천국

[AI] MCP(Model Context Protocol)에 대해서 알아보자(이론편)

jin_e_us — Sat, 11 Apr 2026 17:09:48 +0900

회사에서 AI를 활용한 업무 자동화나 AI 개발 대회 등을 통해 AI로 업무 능률을 높이는 부분을 강조하고 있어, 저 역시 실제 업무나 개발 과정에서 활용할 수 있도록 AI 기술에 관심을 가지고 학습해보려고 합니다.

대학교에서 추천 시스템, 컴퓨터 비전, 자연어 처리 등을 이론적으로 배우고 프로젝트에도 적용해본 경험은 있지만, 이미 만들어진 AI 서비스나 모델을 실제 서비스와 연계하여 개발 생산성을 높이는 방식으로 활용해본 경험은 많지 않았습니다...

그래서 먼저 MCP(Model Context Protocol)에 대해 공부해보려고 합니다.

MCP가 무엇인가요?

MCP란 LLM이 외부의 다양한 도구(tool)와 구조화된 방식으로 상호작용할 수 있도록 설계된 프로토콜입니다.

과거에는 AI가 외부 기능이나 데이터에 접근하기 위해서 각 도구마다 별도의 연동 코드를 작성해야하는 불편함이 있었습니다. MCP는 외부 시스템들과 연동하는 방법, 과정을 표준화하여 훨씬 더 단순하고 일관된 구조를 제공합니다.

MCP를 공부하기 전에 확실히 알아야 할 부분은 MCP란 LLM이 외부 시스템을 호출할 수 있게 하는 인터페이스라는 점입니다. MCP를 새로운 AI 모델이나 에이전트 프레임워크처럼 이해하는 경우가 있는데, 실제로는 LLM이 데이터베이스 조회, 웹 검색, 내부 API 호출과 같은 외부 기능을 사용할 수 있도록 표준화된 방식으로 연결할 수 있도록 해준다고 이해하고 내용을 이어가겠습니다.

MCP 아키텍처

https://modelcontextprotocol.io/docs/learn/architecture

MCP는 클로드 데스트톱, 커서와 같은 MCP Host는 사용자의 입력을 받아, 필요한 기능을 실행하기 위해 MCP 서버에 요청을 전달하는 Client -Server 아키텍처를 따릅니다.
MCP의 Client-Server 구조에서 Client는 2개의 구성 요소로 나누어 이해할 수 있습니다. 사용자와 직접 상호작용을 하는 MCP Host와, MCP Host 내부에 포함되어 LLM이 선택한 도구에 대한 요청을 외부 MCP 서버로 전달하는 MCP Client가 있습니다.

그럼 MCP Host, MCP Client, MCP Server에 대해서 알아보겠습니다.

https://mcpcat.io/blog/mcp-server-client-host

1. MCP Host

MCP Host는 사용자가 직접 상호작용하는 AI 어플리케이션 인터페이스입니다. 사용자의 요청을 입력받고, LLM을 통해 요청을 해석한 뒤 결과를 사용자에게 보여주는 역할을 합니다.
대표적인 MCP Host의 예시로는 Claude Desktop이나 Cursor가 있습니다.

2. MCP Client

MCP Client는 MCP Host 내부에서 동작하는 컴포넌트로, LLM이 특정 도구(Tool)를 사용해야 한다고 판단했을 때, 해당 요청을 MCP Server로 전달하고 MCP Server에서 실행된 결과를 받아 MCP Host로 전달하는 역할을 합니다.

3. MCP Server

MCP Server는 각 도구(Tool) 기능을 실제로 수행하는 주체로, 클라이언트와 LLM이 생성한 요청(tool_use)에 응답하고, 결과 메시지(tool_result)를 반환하는 서버 역할을 합니다.
MCP Server는 크게 Tools, Resources, Prompts라는 3가지 핵심 구성 요소가 있습니다.

3-1. Tools (@mcp.tool())
- 도구(Tool)는 LLM이 호출할 수 있는 외부 함수로, 사용자가 요청한 작업을 실행하는 역할을 합니다.
- MCP에서는 @mcp.tool()로 등록하여 사용합니다.

3-2. Resources (@mcp.resource())
- 리소스는 LLM이 참고할 수 있도록 문맥이나 데이터를 사전에 제공하는 역할로, 사용자 프로필, 회사 정보, 시스템 로그처럼 LLM이 참고할 수 있는 배경 정보나 맥락을 보완하는 용도로 활용합니다.
- MCP에서는 @mcp.resource()를 사용해 리소스를 등록하고 활용합니다.

3-3. Prompts (@mcp.prompt())
- 프롬프트는 LLM에 주어지는 지시문 또는 입력 문장으로, 사용자의 요청을 일관된 방식으로 해석하고 처리할 수 있도록 도웁니다.
- MCP에서는 @mcp.prompt() 또는 add_prompt()를 사용해 프롬프트를 등록합니다.

MCP 통신 방식

MCP에서는 클라이언트와 서버 간의 요청과 응답을 주고 받기 위해서 Stdio(표준 입출력), ~~SSE(Server-Sent Events)~~, Streamable HTTP를 지원합니다. 사용자는 사용 환경이나 구현 목적에 따라서 전송 방식을 선택할 수 있습니다.

Stdio 방식

https://modelcontextprotocol.io/docs/develop/connect-remote-servers

Stdio 방식은 MCP 서버와 클라이언트가 표준 입출력(stdin, stdout)을 통해 직접 데이터를 주고 받는 통신 방식입니다.MCP 서버는 명령 프롬프트나 터미널 환경에서 실행되며, 클라이언트는 표준 입출력을 통해 서버와 직접 데이터를 주고 받습니다.이러한 통식 방식은 일반적으로 클라이언트와 서버가 동일한 컴퓨터에서 실행될 때 사용되며, 로컬 테스트나 개발 중인 MCP 서버를 빠르게 실행해보기 위한 환경에 적합합니다.

SSE(Server-Sent Events) 방식 (권장 X)

MCP Server가 HTTP 기반의 스트리밍 통신을 통해 클라이언트에게 실시간으로 데이터를 전송하는 방식입니다.

기본적인 HTTP 요청/응답은 클라이언트가 요청(Request)을 한 번 보내고 서버가 응답(Response)을 한 번 보내고 연결이 끝납니다. 그러나 MCP 서버에서는 하나의 요청을 처리하는 과정에서 긴 작업이 수행될 수 있으며, 이 과정에서 중간 진행 상황을 전달하거나 응답을 여러 조각으로 나누어 스트리밍 형태로 전송해야 하는 경우가 있습니다.

SSE 방식에서는 클라이언트가 SSE 엔드포인트에 한 번 연결(구독)하면, 서버는 해당 연결을 유지하면서 서버에서 새로운 이벤트나 응답이 발생할 때마다 이를 실시간으로 클라이언트에 전송할 수 있는 구조입니다.

그러나, 2025-03-26 버전부터 FastMCP에서는 SSE 방식의 통신은 더 이상 권장되지 않는 방식이며, Streamable HTTP 방식을 사용할 것을 권장하고 있습니다.

Streamable HTTP 방식

https://medium.com/@higress_ai/comparison-of-data-before-and-after-using-streamable-http-b094db8b414e

Streamable HTTP는 기존 SSE(Server-Sent Events) 방식의 한계를 보완하기 위해 도입된 MCP의 새로운 통신 방식입니다. 단일 HTTP 엔드포인트를 통해 요청과 응답을 처리하면서, 필요에 따라 스트리밍 응답도 지원하도록 설계되었습니다.

기존 SSE 방식에서는 클라이언트가 별도의 SSE 엔드포인트에 연결하고, 서버는 SSE 연결을 통해서만 클라이언트로 메시지를 전달하는 구조였습니다. 이 방식은 서버가 장시간 SSE 연결을 유지해야 하고, 다수의 클라이언트의 연결을 관리해야하는 문제가 발생할 수 있었습니다.

Streamable HTTP는 별도의 SSE 엔드포인트 대신에 모든 통신을 하나의 HTTP 엔드포인트로 통합하고, 서버는 클라이언트 요청의 유형에 따라 일반적인 HTTP 응답 또는 SSE 스트리밍 방식 중 하나를 선택할 수 있습니다.

[데이터엔지니어링] Hadoop Yarn에 대해서 알아보자 - (4편)

jin_e_us — Wed, 1 Apr 2026 16:32:44 +0900

Yarn의 등장

Hadoop 1.x에서는 클러스터의 자원 관리(Resource Management)와 애플리케이션의 라이프사이클 관리를 Apache Hadoop의 JobTracker가 단일 컴포넌트로 담당했습니다.
클러스터의 자원관리와 어플리케이션의 라이프사이클 관리를 Job Tracker가 모두 담당하여 병목현상이 발생하게 되었고, 이러한 병목현상을 개선하기 위해 Hadoop 2.0부터는 자원 관리와 어플리케이션의 실행을 분리할 수 있도록 YARN을 도입했습니다.

Yarn의 구조

Yarn은 cpu, Memory와 같은Computing Resource를 관리하고 할당해주는 소프트웨어입니다.

또한 Yarn은 HDFS와 완전히 독립적인 역할을 합니다.
HDFS는 Storage에 대한 기능을 제공하고,Yarn은 어플리케이션 실행 및 리소스 관리 기능을 제공합니다,

Yarn Architecture

(1) Resource Manager

Yarn Cluter 전체를 관리하는 Master 서버의 역할로 각 Node Manager의 리소스 상태를 관리합니다.

아래에서 간단히 설명하겠지만, Resource Manager는 Scheduler를 통해서 리소스 할당을 결정하는 중요한 역할을 합니다.
Resource Manager는 Scheduler와 Application Manager로 구성되어 있습니다.
- Scheduler : 다양한 Application에 리소스 할당을 어떻게 할지 결정.
- Application Manager : 사용자가 제출한 Application 전체 lifecycle 관리.

(2) Application Master

https://westlife0615.tistory.com/735

Yarn Client에 의해서 요청된 Application을 생성하고 관리하는 역할을 수행합니다.
실행할 Application마다 Application Master가 독립적으로 생성되고, Application Master는 하나의 어플리케이션만을 관리합니다.

예를 들어, Yarn에 A라는 Job이 제출되면 가장 먼저 Application Master를 생성하고, 생성된 Application Master는 A Job의 실행과 관리를 책임지게 됩니다. Application Master는 A라는 Job의 실행을 위해 Resource Manager와 통신하며 필요한 리소스를 요청합니다.

(3) Node Manager

Node Manager는 각 Node들의 리소스(CPU, Memory)를 관리하고, 컨테이너 실행 및 상태 관리 담당합니다.

Application Master의 요청과 Resource Manager의 할당 결과를 기반으로 컨테이너를 실행하며, 실행 중인 컨테이너의 상태와 리소스 사용량을 모니터링합니다. 또한, 노드의 리소스 상태와 컨테이너 실행 정보를 Resource Manager에 주기적으로(heartbeat) 보고합니다.

Yarn의 Workflow

1) 클라이언트가 어플리케이션 실행을 요청 -> Resource Manager에서 새로운 Application ID를 발급.

2) Resource Manager에서 Application Master를 실행할 Node Manager를 선택.

3) 선택된 Node Manager는 Container를 생성하고 Application Master를 실행

4) Application Master는 리소스 매니저에게 어플리케이션 실행을 위한 리소스를 요청하면, Resource Manager는 리소스 상태를 확인한 후 Application Master에게 Node Manager 목록을 전달

5) Application Master는 할당받은 Node Manager들에게 컨테이너 실행을 요청.

6) Node Manager들은 Container를 실행하고, 해당 컨테이너에서 실제 작업을 실행.

[데이터엔지니어링] Hadoop MapReduce에 대해서 알아보자 - (3편)

jin_e_us — Sat, 7 Mar 2026 17:16:27 +0900

Hadoop MapReduce는 대규모 데이터를 병렬로 처리할 수 있도록 지원하는 분산 데이터 처리 프레임워크입니다.

MapReduce와 HDFS가 동일한 노드 집합에서 동작하는 경우, MapReduce는 데이터가 저장된 노드에서 작업을 실행하도록 Task를 스케줄링할 수 있어, 불필요한 데이터 전송을 최소화하여 효율적으로 데이터를 처리할 수 있습니다.

Map 작업과 Reduce 작업

https://www.edureka.co/blog/mapreduce-tutorial/

MapReduce는 Map과 Reduce라는 두 가지 작업으로 구성됩니다.

Map 단계에서는 입력 데이터 블록을 읽고 처리하여 중간 출력물인 key-value 쌍을 생성한 이후 Reduce 작업으로 전달됩니다.
Reduce 단계에서는 여러 맵 작업으로부터 Key-Value값 쌍을 받아, 동일한 key를 가진 값들을 집계하여 최종 결과를 생성합니다.

MapReduce 구현을 위한 Mapper, Reducer Interface

Mapper Interface

Mapper는 입력 key-value 쌍을 중간 key-value 쌍으로 매핑하는 역할을 합니다.

Hadoop MapReduce 프레임워크는 각 InputSplit마다 하나의 Map Task를 생성하고, InputSplit에 포함된 각 key-value 쌍에 대해 map() 메서드를 호출하여 중간 key-value 쌍을 생성합니다.

동일한 출력 키와 관련된 모든 중간 값들은 프레임워크에 의해 그룹화되며, 이후 최종 결과를 생성하기 위해 Reducer로 전달됩니다.

Reducer Interface

Reducer는 같은 키를 공유하는 중간 값들의 집합을 더 작은 값 집합으로 축소합니다.
Reducer에는 Shuffle, Sort, Reduce 세 가지 주요 단계가 있습니다.

1. Shuffle
각 Mapper에서 생성된 중간 데이터를 Reducer로 전달하는 과정.

2. Sort
Reducer로 전달된 데이터를 키 값 기준으로 정렬하는 과정

3. Reduce
정렬된 데이터를 기반으로 Reducer가 데이터를 처리하고 최종 결과를 생성하여 저장하는 과정

Apache Spark의 탄생

MapReduce는 여러 작업을 연결하는 워크플로우를 지원하지 않습니다.
따라서 여러 MapReduce 작업 단계를 거쳐야 하는 경우, 각 작업의 출력 디렉토리를 다음 작업의 입력 경로로 지정하는 방식으로 디렉토리 경로를 통해 암묵적으로 워크플로우를 구성해야 합니다.

MapReduce Job1 → 결과(HDFS) → MapReduce Job2 → 결과(HDFS) → MapReduce Job3

이와 같이 여러 MapReduce 작업을 연결하기 위해 각 Job의 결과를 HDFS에 저장하는 방식으로 중간 상태를 구체화(materialization)하는게 필요합니다. 하지만 이 과정에서 매 단계마다 디스크 I/O와 네트워크 전송이 발생하기 때문에 실행 시간이 길어지고 비효율이 발생할 수 있습니다.

이를 해결하기 위해서 Spark는 중간 계산 결과를 디스크에 저장하는 대신 메모리에 유지하여 디스크 I/O를 줄이고 실행 속도를 향상시켰습니다.

이러한 특징 덕분에 Spark는 대규모 데이터 처리 환경에서 Hadoop MapReduce를 대체하는 처리 엔진으로 널리 사용되기 시작했습니다.

[데이터엔지니어링] Hadoop HDFS에 대해서 알아보자 - (2편)

jin_e_us — Sun, 25 Jan 2026 15:12:33 +0900

Hadoop Distributed File System은 Apache Hadoop의 핵심 스토리지 시스템으로, 대용량 데이터를 분산 저장하고 안정적으로 관리하기 위해 설계된 파일 시스템입니다.

HDFS의 디자인 목표

1. 하드웨어 Failure

HDFS는 파일 시스템의 데이터를 수백, 수천 대의 서버 머신(Node)에 분산하여 저장하는 구조를 갖습니다. 이 때 해당 머신들에서 다양한 장애가 발생할 수 있습니다. (ex : 디스크 장애로 인한 데이터 유실, 네트워크 장애로 인한 접근 불가 등…)

HDFS는 이러한 장애를 빠르게 감지하고 대처할 수 있게 설계 되었습니다. HDFS에 데이터를 저장하면, 복제본도 함께 저장되어 데이터 유실을 방지하고, NameNode와 DataNode 간에는 주기적인 Health Check(Heartbeat)를 통해 장애가 발생한 노드를 빠르게 감지하고 대처할 수 있게 합니다.

2. 스트리밍 데이터 접근

HDFS는 동일한 시간 내에 더 많은 데이터를 처리하는 것을 목표로 합니다. 그래서 User와의 상호작용 보다는 배치 처리를 더 잘 할 수 있도록 설계되었습니다.

HDFS에 저장되는 파일은 여러 개의 대용량 블록(Block) 으로 나뉘어 여러 DataNode에 분산 저장되어 파일 내 특정 위치를 찾는 Random Access 방식에는 적합하지 않습니다. 다만, HDFS는 파일의 처음부터 끝까지 데이터를 순차적으로 읽는 Streaming Access 방식에 최적화되어 있어, 대규모 데이터 분석 작업에서 높은 성능을 발휘할 수 있습니다.

- Streaming Access: 데이터가 저장된 순서대로 순차적으로 접근.
- Random Access: 파일 내 임의의 위치를 지정하여 즉시 접근.

3. 대용량 데이터셋

HDFS는 하나의 파일이 GB~TB 수준의 데이터 크기로 저장될 수 있게 설계되었다.

4. 단순한 일관성 모델

HDFS에서는 파일에 대해 한 번 쓰고(write-once), 여러 번 읽는(read-many) 접근 모델을 필요로 한다. 따라서 한 번 저장한 데이터는 수정할 수 없고, 읽기만 가능하게 하여 데이터 무결성을 지킨다.

5. “연산을 이동하는 것이 데이터를 이동하는 것보다 저렴하다”

애플리케이션이 요청한 연산은, 그 연산이 수행되는 데이터와 가까운 위치에서 실행될수록 효율적이다. 이러한 방식은 네트워크의 혼잡을 줄이고 시스템 전체의 throughput을 높일 수 있다. 그래서 HDFS에서는 Computing 자원을 Data가 있는 위치로 이동시킨다.

6. 이기종 하드웨어 및 소프트웨어 플랫폼 간의 이식성

HDFS은 쉽게 HW/SW 플랫폼을 옮길 수 있도록 디자인 되었다.

HDFS 아키텍처 - NameNode, DataNode

HDFS는 NameNode와 DataNode로 구성됩니다. 간략하게 설명하자면, HDFS는 모든 파일을 일정 크기의 블록으로 나누어 여러 DataNode들에 분산 저장되고, 이때 어떤 파일이 어느 블록에 저장되어 있는지는 Namenode의 메모리에서 메타데이터를 관리합니다

NameNode

역할

- 파일 시스템의 메타데이터(파일의 위치, 권한 등)를 관리.
- 데이터 노드의 리스트를 관리, 유지, 변경.
- 데이터 노드가 전송하는 HeartBeat를 모니터링하여 데이터 노드를 관리.

특징

- 메모리에 모든 메타데이터 유지 → 빠른 접근
- Fsimage와 Edit Log라는 두 종류의 파일로도 메타데이터를 기록
- 단일 장애점(SPOF)이므로 Secondary NameNode 또는 HA 구성 필요

DataNode

역할

- 클라이언트가 HDFS에 저장하는 파일을 디스크에 유지.
- NameNode의 명령에 따라 블록 생성, 삭제, 복제 수행.
- 주기적으로 NameNode에게 HeartBeat 와 블록 리포트(Block들의 리스트와 상태)를 전송.

특징

- 클러스터 내 여러 대의 DataNode로 구성
- 로컬 디스크에 블록 데이터 저장
- 장애 발생 시 자동으로 다른 DataNode에서 복제

HDFS의 데이터 복제

HDFS에서의 파일을 구성하는 각각의 블록은 Fault Tolerance를 위해서 복제됩니다. 이때 각 파일마다 Block Size와 Replication Factor가 지정할 수 있는데, Replication Factor란 파일의 Replica 수를 의미합니다.

HDFS는 Replica 위치를 최적화하기 위한 규칙을 정의하는데, 이 중에 대표적인 것이 Rack-Awareness 방식입니다.
간단히 말하자면 Replica를 같은 랙이 아닌 다른 랙에다가 배치하여, Replica를 전체 랙에 골고루 분산하는 방식입니다.

HDFS 의 Read와 Write

Read 과정

1. 클라이언트가 Distributed FileSystem에 HDFS 파일을 읽겠다는 open() 요청을 보내면

2. 네임노드는 해당 블록을 가진 Datanode들의 위치를 반환한다.

3. Client는 read()메소드를 통해 파일의 첫 번째 블록이 있는 Datanode와 Connection을 맺는다.

4,5. 그렇게 계속 데이터 노드에 파일 블록을 요청한다.

6. end of block에 도달하면 Datanode와의 연결을 끊고 끝낸다.

Write 과정

1. 클라이언트가 NameNode에 파일 생성 요청

2. NameNode가 메타데이터를 생성하고, 블록을 저장할 DataNode를 할당하고 목록을 반환한다.

3. 클라이언트가 첫 번째 DataNode에 데이터 전송

4,5. DataNode들이 파이프라인 방식으로 복제본 전파

6. 모든 복제 완료 후 NameNode에 Write 작업이 끝났음을 알린다.

NameNode HA 구성

그럼 여기까지 들으면서 DataNode 같은 경우에는 확장이 가능하고, 데이터에 대한 복제도 잘 관리한다는 것을 알 수 있습니다.
하지만 NameNode가 하나만 존재할 경우, 해당 NameNode에 장애가 발생하면 전체 HDFS를 사용할 수 없게 되는 단일 지점 장애(SPOF)가 됩니다. 그래서 Namenode를 Active-Standby 구조로 구성하여 SPOF를 제거했습니다.

Active와 Standby Namenode를 각각 두어서 Active NameNode에 문제가 발생하면 Standby Namenode 드가 Active로 동작하게 됩니다. 그러나 장애 발생 여부를 자동으로 판단하는 것은 어렵기 때문에 보통 주키퍼를 이용하여 장애 발생시 자동으로 변경될 수 있도록 합니다.

장애 발생 시 즉시 전환되기 위해서는 메타데이터의 일관성(Consistency) 이 보장되어야 합니다. Consistency를 유지하기 위해 Active NameNode 와 Standby NameNode는 모두 Datanode로부터 블록 리포트와 하트비트를 받아서 동일한 메타데이터를 유지하고, 공유 스토리지나 저널 노드를 이용하여 Edit Log를 공유합니다.

[데이터엔지니어링] Hadoop에 대해서 알아보자 - (1편)

jin_e_us — Sun, 11 Jan 2026 13:57:58 +0900

네카라쿠배당토의 데이터엔지니어 공고

데이터 엔지니어 직무를 목표로 취업을 준비하면서 워크플로우 관리 도구인 Airflow, Observability를 위한 Grafana, 실시간 처리, 모니터링을 위한 EFK 스택 등을 경험해 봤지만, 대규모 분산 처리를 위한 Hadoop Ecosystem에 대한 이해나 실습 경험이 없었다...

그래서 이번 기회에 Hadoop Ecosystem을 중심으로 대용량 데이터 처리를 위한 기술 스택들을 공부해보려 합니다.

Hadoop이란?

온라인 서비스가 발전하면서 데이터의 양과 종류가 다양해졌습니다. 웹 로그와 같은 비정형 데이터를 기존의 RDBMS에 저장하기에는 데이터의 크기나 보관 측면에서 비용 부담이 컸고, 데이터 처리에 있어 RDBMS의 복잡하고 세밀한 기능이 반드시 필요한 상황도 아니었습니다.
그래서 하둡은 값비싼 고성능 서버 대신, 비싸지 않은 다수의 컴퓨터들(x86리눅스 서버)을 이용해 대량의 데이터를 병렬로 동시에 처리하기 위해 개발된 오픈소스 프레임워크입니다.

Hadoop의 구성 요소

https://data-flair.training/blogs/hadoop-architecture/

기본 Hadoop 프레임워크는 다음과 같은 4개의 모듈로 구성되어 있습니다.

1. HDFS(Hadoop Distributed File System)

여러 Hadoop 노드 로컬 저장소에 있는 데이터에서 작동하는 분산 파일 시스템입니다. 대용량 파일을 블록 단위로 분할해 여러 노드에 분산 저장한다. 이 과정에서 동일한 데이터를 여러 노드에 복제함으로써 장애가 발생하더라도 데이터를 안전하게 유지할 수 있는 내결함성을 제공합니다.

2. YARN(Yet Another Resource Negotiator)

YARN은 Hadoop 클러스터의 컴퓨팅 리소스를 관리하고 작업을 스케줄링 합니다. MapReduce, Spark, Flink 등 다양한 처리 엔진을 지원합니다.

3. MapReduce

MapReduce는 대용량 데이터의 분산 처리를 위한 프로그래밍 모델입니다. 데이터를 변환하는 Map 단계와 결과를 집계하는 Reduce 단계로 구성됩니다.

4. Hadoop Common

Hadoop Common은 Hadoop의 다른 모듈에서 공통으로 사용하는 공통 Java 라이브러리와 유틸리티를 의미합니다.

Hadoop은 어떻게 작동하나요?

https://medium.com/@swabhab.panigrahi/the-complete-guide-to-apache-hadoop-in-2025...

Hadoop을 사용하면 클러스터 서버의 모든 스토리지 및 처리 용량을 이용하여 대량의 데이터에 대해 분산 프로세스를 실행할 수 있습니다. 데이터의 처리는 여러 노드에서 동시에 병렬적으로 수행됩니다.

애플리케이션은 NameNode와 통신하여 파일 생성 및 메타데이터 관리를 요청하고, 실제 데이터는 NameNode가 결정한 DataNode들에 블록 단위로 분산 저장됩니다. 이후 데이터를 조회하거나 처리하기 위해 여러 맵으로 구성된 MapReduce 작업을 제출하면, 여러 Mapper와 Reducer 태스크가 DataNode에 분산 저장된 HDFS 데이터를 대상으로 병렬 실행됩니다.
실행 과정에서 필요한 클러스터 리소스 할당, 각 태스크의 스케줄링, 실행 관리는 YARN이 담당합니다.

Hadoop v1, v2 차이

Hadoop v1

2011년에 정식 발표된 Hadoop v1은 분산 파일 관리 시스템인 HDFS와 분산 데이터 처리를 위한 MapReduce 프레임워크만 제공했습니다.

분산저장은 네임노드와 데이터노드가 처리합니다. 네임노드는 블록정보를 가지고 있는 메타데이터와 데이터 노드를 관리하는 역할을 합니다. 데이터노드에서 데이터를 블록단위로 나누어서 저장합니다. 병렬처리는 잡트래커와 태스크트래커가 처리합니다. 잡트래커가 어플리케이션의 라이프사이클을 관리하고, 자원 관리도 처리하였습니다. 태스크트래커는 실제 작업을 처리하였습니다.

병렬처리의 작업 단위는 슬롯(slot)입니다. 맵 슬롯, 리듀스 슬롯의 개수가 정해져 있고, 실행 시점에 역할이 정해지면 슬롯의 용도를 변경할 수 없기 때문에 맵 작업이 진행중에는 리듀스 슬롯은 대기상태로 있었습니다. 이로 인해 클러스터가 100% 활용되지 않을때도 있었습니다.

Hadoop V2

클러스터의 자원관리와 어플리케이션의 라이프사이클 관리를 잡트래커가 모두 담당하여 병목현상이 발생하게 되었고, 이러한 병목현상을 개선하기 위해 YARN을 도입하였습니다. YARN은 잡트래커의 기능을 분리하여 자원관리는 리소스 매니저와 노드매니저가 담당하고, 애플리케이션의 라이프 사이클관리는 노드 매니저가 실행한 컨테이너 내부에서 동작하는 어플리케이션 마스터가 담당하며, 실제 작업(Map, Reduce 등)은 컨테이너 단위로 실행됩니다.

Hadoop v2에서도 노드와 파일 시스템은 HDFS를 근간으로 하지만, 그 이외에 모든 작업을 Yarn이라는 Resource Management 프레임워크를 이용해서 유연하게 분산 처리 작업을 작성하고 활용할 수 있는 아키텍처로 바꿨습니다.

[혼공네] 5장 응용 계층

jin_e_us — Fri, 26 Dec 2025 17:30:04 +0900

5-1. DNS와 자원

도메인 네임과 네임 서버

네트워크상의 호스트를 특정하기 위해 IP 주소를 사용하지만, 통신하는 모든 호스트의 IP 주소를 기억하기도 어렵고, 호스트의 IP 주소는 언제든지 바뀔 수 있어 IP 주소만을 사용하기에는 번거롭습니다. 그래서 일반적으로 사용자는 IP 주소보다는 도메인 네임을 많이 사용합니다.

도메인 네임 : 호스트 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보.

도메인 네임과 IP 주소는 네임 서버에서 관리하고, 도메인 네임을 관리하는 네임 서버를 DNS 서버라고 부릅니다.

도메인 네임의 계층적 분류

도메인 네임은 점(”.”)을 기준으로 계층적으로 분류됩니다. 최상단에 루트 도메인(.), 그 다음 최상위 도메인(TLD), 2단계 도메인처럼 계속 그 다음 단계의 도메인이 있는 식입니다. 도메인 네임을 모두 포함하는 도메인 네임을 전체 주소 도메인 네임(FQDN) 이라고 합니다.
도메인 네임이 이렇게 계층적인 형태를 띄는데, 이를 효율적으로 관리하기 위해서 네임 서버 또한 계층적인 형태를 하고 있습니다. 해당 네임 서버는 전 세계 여러 군데에 위치해 있습니다. 이렇게 계층적이고, 분산된 도메인 네임 관리 체계를 도메인 네임 시스템(DNS)라고 부릅니다.

계층적 네임 서버

IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정에 대해서 알아보겠습니다.

중요한 역할을 담당하는 네임서버는 크게 로컬 네임 서버, 루트 네임 서버, TLD 네임 서버, 책임 네임 서버 4가지가 존재합니다.

https://jaehyeon48.github.io/network/dns/

1. 로컬 네임 서버

클라이언트와 맞닿아 있는 네임 서버로 IP 주소를 알아내기 위해 가장 먼저 찾는 네임 서버입니다. 일반적으로 ISP(Internet Service Provider)에서 할당해주는 경우가 많지만, ISP에서 할당하는 로컬 네임 서버 말고도 공개 DNS 서버(EX : 구글 DNS 서버 8.8.8.8)도 사용 가능합니다.

2. 루트 네임 서버

로컬 네임 서버가 IP 주소를 모르는 경우, 루트 네임 서버에게 해당 도메인 네임을 질의하게 됩니다. 루트 네임 서버는 루트 도메인을 관리하는 네임 서버로 질의에 대해 TLD 네임 서버의 IP 주소를 반환 할 수 있습니다.

3. TLD 네임 서버

TLD(최상위 도메인)을 관리하는 네임 서버입니다. 질의에 대해 TLD의 하위 도메인을 관리하는 네임 서버 주소를 반환할 수 있습니다.

4. 책임 네임 서버

특정 도메인 영역을 관리하는 네임 서버로, 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 떠넘기지 않고, 답할 수 있는 네임 서버입니다. 즉, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버입니다.

도메인 네임 리졸빙

도메인 네임에 해당하는 IP 주소를 알아내기 위해 리졸빙하는 과정에 대해서 알아보겠습니다. IP주소를 알기 위해 로컬 네임 서버는 다른 네임 서버들에게 질의하게 되는데, 크게 '재귀적 질의'와 '반복적 질의' 2가지 방식으로 질의를 진행합니다.

재귀적 질의 (Recursive Query)

재귀적 질의 방식

클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버 → 루트 네임 서버 → TLD 네임 서버 → 책임 네임 서버 순으로 질의하고, 역순으로 최종 응답 결과를 전달받는 방식입니다.

반복적 질의 (Iterative Query)

반복적 질의

클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버가 루트 네임 서버에게 질의해서 다음 질의할 TLD 네임 서버 주소를 응답 받고, 로컬 네임 서버가 TLD 서버에게 질의해서 다음 질의할 책임 네임 서버 주소를 응답 받고, 로컬 네임 서버가 책임 네임 서버에게 질의 과정을 반복하는 걸 반복적 질의라고 합니다.

앞서 설명한 2가지 질의 방식에서는 IP로 변환하기 위해 8가지 단계를 거쳐야하는 것 처럼 시간이 오래 걸리고, 네트워크 상의 메시지 수가 지나치게 늘어날 수 있습니다.
그래서 실제로는 네임 서버들이 기존에 응답받은 결과를 DNS 캐시에 임시로 저장했다가 추후 같은 질의에 이를 활용할 수 있습니다. DNS 캐시는 영원히 남아있지 않으며, TTL(Time To Live)이라는 값에 따라 캐시 될 수 있는 시간 이후 소멸합니다.

자원을 식별하는 URI

지금까지는 클라이언트가 메시지를 주고받고자 하는 대상의 IP 주소를 식별하는 방법을 설명했다면, 송수신하고자 하는 정보를 식별하기 위한 URI에 대해서 알아보겠습니다. 두 호스트가 송수신하는 대상(자원)을 식별할 수 있어야하는데, 자원을 식별할 수 있는 정보를 URI(Uniform Resource Identifier)라고 부릅니다.

URI는 위치 기반 식별자인 URL과 이름 기반 식별자인 URN 2가지 방식으로 자원을 식별합니다.

URL (Uniform Resource Locator)

Scheme
URL의 첫 부분으로, '자원에 접근하는 방법'을 의미합니다. 일반적으로는 사용할 프로토콜이 명시됩니다.(ex:http://, https:// )
Authority
Authority에는 '호스트를 특정할 수 있는 정보'인 IP주소나 도메인 네임이 명시됩니다. 콜론(:) 뒤에 포트 번호를 붙일 수 있습니다.
Path
path에는 '자원이 위치한 경로'가 명시됩니다. 슬래시(/)를 기준으로 자원의 경로를 계층적으로 표현합니다.
Query
자원의 위치(path) 뿐만 아니라 다른 특정 조건을 추가할 때 query를 이용합니다. (ex: 쿼리 문자열, 쿼리 파라미터)
Fragment

자원의 한 조각을 가리키기 위한 정보로, HTML파일과 같은 자원에서 특정 부분을 가리키거나 이동하기 위해 사용합니다.

URN(Uniform Resource Name)

URL은 자원의 위치를 기반으로 식별하는데, 자원의 위치는 언제든지 변할 수 있습니다. URN은 자원에 고유한 이름을 붙이는 이름 기반 식별자이기 때문에 자원의 위치와 무관하게 식별할 수 있다는 장점이 있습니다.

DNS 레코드 타입

DNS가 올바르게 동작하기 위해 네임 서버가 무엇을 저장하는 지 알아보겠습니다.
네임 서버는 DNS 자원 레코드(DNS 레코드)라 불리는 정보를 저장하고 관리합니다.

도메인 구입 후 해당 도메인 주소를 IP 주소에 대응시키고자 한다고 하면, 도메인 네임 서버에 등록을 해야합니다. 이때 도메인 레코드 마다 공통으로 유지하는 정보인 호스트 이름(Record Name), 값(Value), TTL, Record Type 등을 설정해야 합니다. 각 레코드에는 유형이 정해져 있기에 레코드 유형이 달라지면 레코드의 이름과 값이 달라집니다.

레코드 유형	설명
A	특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계
AAAA	특정 호스트에 대한 도메인 네임과 IPv6 주소와의 대응 관계
CNAME	호스트 네임에 대한 별칭을 지정
NS	특정 호스트의 IP 주소를 찾을 수 있는 네임 서버
MX	해당 도메인과 연동되어 있는 메일 서버

다음과 같은 도메인 레코드가 있다고 가정하고, 해당 레코드의 의미를 해석해보겠습니다.

레코드 타입	이름	값	TTL
A	example.com	1.2.3.4	300
CNAME	www.example.com	example.com	3000

첫 번째 레코드(A)의 의미를 해석하면 exampel.com이 1.2.3.4에 대응되어 있다는 것을 보여줍니다. 그래서 네임 서버에 example.com을 질의하면 1.2.3.4을 응답 받을 수 있습니다.
두번째 레코드(CNAME)의 의미를 해석하면 example.com에 대한 별칭으로 www.example.com을 사용하겠다는 의미입니다. 그래서 CNAME을 등록해서 www.exmaple.com을 질의하면 1.2.3.4 을 응답 받을 수 있습니다.

5-2. HTTP(Hypertext Transfer Protocol)

HTTP의 특성

1. 요청-응답 기반 프로토콜

HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜로, 요청 메시지와 응답 메시지를 주고 받는 구조로 동작함.

2. 미디어 독립적 프로토콜

HTTP는 주고받을 자원의 특성을 제한하지 않고, 단지 자원을 주고 받을 수 있는 인터페이스를 정의합니다. 그래서 HTTP를 통해서 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원을 주고 받을 수 있습니다.
HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입, MIME 타입 이라고 부릅니다. 미디어 타입은 type/subtype의 형태로 구성됨.

3. Stateless 프로토콜

HTTP는 상태를 유지하지 않는 프로토콜로, 서버가 클라이언트와 관련된 상태를 기억하지 않습니다. 따라서 모든 HTTP 요청은 독립적인 요청으로 간주됩니다.
HTTP 서버는 다수의 클라이언트와 동시에 상호 작용하므로, 모든 클라이언트의 상태 정보를 유지하는 것은 비효율적입니다. 뿐만 아니라 서버가 한 대가 아니라 여러 대의 서버로 구성된 경우, 모든 서버에서 클라이언트의 상태를 공유하기 어렵습니다.
HTTP의 중요 설계 목표는 확장성(Scalability)과 견고성(Robustness)인데, Statless 특성을 통해 확장성이 높고, 견고성이 높을 수 있었습니다.

4. 지속 연결 프로토콜

기본적으로 HTTP는 TCP 상에서 동작합니다. TCP는 연결형 프로토콜이지만, HTTP는 비연결형 프로토콜입니다.
따라서 초기의 HTTP(HTTP/1.0)에서는 요청을 처리할 때마다 TCP의 3-way Handshake를 통해 연결을 수립한 뒤, 요청과 응답이 한 번 오고 가면 즉시 연결을 종료했습니다. 추가 요청이 있을 경우 매번 연결을 생성하고 종료해야 했고, 불필요한 네트워크 오버헤드가 반복되어 비효율적이라는 문제가 있었습니다.

최근 HTTP 버전(HTTP 1.1 이상)에서는 지속 연결(Keep-alive)이라는 기술을 제공하는데, 해당 기술을 통해 하나의 TCP 연결 상에 여러 개의 요청-응답을 주고 받을 수 있습니다.

HTTP 메시지 구조

HTTP 메시지는 시작 라인, 필드 라인, 메시지 본문으로 이루어져 있습니다.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages

시작 라인

시작 라인은 요청 메시지(요청 라인)인지 응답 메시지(상태 라인)인지를 나타내는 부분입니다.

요청 라인인 경우, 요청 라인 = 메서드 + 요청 대상 + HTTP 버전 으로 구성되고, 상태 라인인 경우, 상태 라인 = HTTP 버전+ 상태 코드 + 이유 구문(선택) 구성됩니다.

필드 라인

필드라인은 0개 이상의 HTTP 헤더(HTTP 통신에 필요한 부가 정보)가 명시되는 부분으로, 각 HTTP 헤더는 “:”을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성됩니다.

메시지 본문

HTTP 요청 혹은 응답 메시지에서 본문이 필요한 경우에 명시되는 값으로, 존재하지 않을 수도 있고, 다양한 콘텐츠 타입이 사용될 수 있습니다.

HTTP 메서드

HTTP 상태 코드

200번대 : 성공 상태 코드
300번대 : 리다이렉션 상태 코드
400번대 : 클라이언트 에러 상태 코드
500번대 : 서버 에러 상태 코드

5-3. HTTP 헤더와 HTTP 기반 기술

HTTP 헤더

HTTP 메시지의 2번째 줄인 필드 라인에 대해서 학습하겠습니다. 필드 라인은 다양한 HTTP 헤더들이 명시됩니다. 해당 HTTP 헤더의 종류는 매우 많기 때문에 자주 활용되는 HTTP 헤더 위주로 학습해보겠습니다.

요청시 활용되는 HTTP 헤더

HTTP 요청시 주로 활용되는 대표적인 헤더 'Host', ' User-Agent', 'Referer', 'Authorization' 헤더에 대해서 알아보겠습니다.
(1) Host
- 요청을 보낸 호스트를 나타내는 헤더로, 주로 도메인 네임으로 명시됩니다.

(2) User-Agent
- 요청 메시지 생성에 관여한 클라이언트 프로그램과 관련된 다양한 정보가 명시됩니다. (ex: OS, 브라우저 등)

(3) Referer
- 클라이언트가 요청을 보낼 때 머무르고 있던 URL로, 클라이언트의 유입 경로를 파악할 수 있습니다.

(4) Authorization
- 클라이언트의 인증 정보를 담는 헤더로, 인증 타입과 인증 정보가 차례로 명시 됩니다.

응답시 활용되는 HTTP 헤더

HTTP 응답 시 주로 활용되는 대표적인 헤더 'Server', 'Allow', 'Retry-After', 'Location', 'WWW-Authenticate' 헤더에 대해서 알아보겠습니다.
(1) Server
- 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보를 명시합니다.

(2) Allow
- 클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용됩니다.

(3) Retry-After
- 현재는 요청을 처리할 수 없을 때 503(Service Unavailable) 상태 코드와 함께 전송되는 정보로, 자원을 사용할 수 있는 날짜/시각을 나타냅니다.

(4) Location
- 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더입니다.

(5) WWW-Authenticate
- 자원에 접근하기 위한 인증 방식을 설명하는 헤더입니다.

캐시 (Cache)

불필요한 대역폭 낭비와 응답 지연 방지를 위해 정보의 사본을 임시로 저장하는 기술입니다. 사본을 저장해두면 동일한 요청에 대한 캐시된 데이터를 활용해 빠르게 데이터에 접근할 수 있습니다.

개인 전용 캐시 : 웹 브라우저에 저장
공용 캐시 : 클라이언트와 서버 사이에 위치한 중간 서버에 저장

캐시에서 주의할 점은 원본 데이터가 변경되는 상황이 있을 수 있으므로 클라이언트가 확보한 캐시된 데이터가 최신 상태인지 확인해야합니다. 이를 위해 캐시된 데이터에 유효 기간 설정하고, 유효 기간이 만료됐을 때 원본 데이터를 다시 요청하는 방식으로 최신성을 유지합니다.

쿠키 (Cookie)

서버에서 생성되어 클라이언트 측에 저장되는 데이터로, 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단입니다.
서버가 클라이언트의 상태를 알 수 있도록 하는 특별한 데이터로 서버가 생성하여 클라이언트에게 전송하고, 클라이언트는 전달받은 쿠키를 저장해 두었다가, 서버에게 보내는 요청 메시지에 쿠키를 포함하여 전송합니다.

[혼공네] 4장 전송 계층

jin_e_us — Sat, 13 Dec 2025 21:30:33 +0900

4-1. IP의 한계와 포트

전송 계층의 역할 2가지

IP 프로토콜의 한계

1. 비연결형 프로토콜

- 송,수신 호스트 간에 사전 연결 수립 작업을 거치지 않고, 수신지를 향해 패킷을 보내기만 한다.

2. 신뢰할 수 없는 프로토콜

- 통신과정에서 패킷의 데이터가 손상되거나, 중복된 패킷이 전송되었더라도 확인 할 수 없다.

전송 계층 역할 1. IP의 한계 보완

1. 전송 계층은 연결형 통신을 가능하게 한다.

- 연결형 통신의 대표적인 프로토콜인 TCP는 두 호스트가 정보를 주고 받기 전에 연결을 수립함.

2. 전송 계층은 신뢰성 있는 통신을 가능하게 한다.

- TCP 프로토콜의 경우 패킷이 수신지까지 올바른 순서대로 확실히 전달되는 것을 보장함

- 재전송을 통한 오류 제어, 흐름 제어, 혼잡 제어 등의 기능을 제공

전송 계층 역할 2. 응용 계층과의 연결 다리(포트)

포트의 역할 : 특정 어플리케이션 정보 식별

포트

패킷이 IP 주소에 해당하는 컴퓨터에 도달한다고 해서 통신이 종료되는게 아니라, 해당 컴퓨터 안에 어떤 프로그램인지, 어떤 어플리케이션에 전달되야 하는지를 알아야 한다.

즉 , 패킷이 특정 어플리케이션 정보를 식별할 수 있도록 하는 정보를 포트라고 부른다.

포트의 분류

포트 분류

포트번호는 0번부터 65535번까지, 총65536개가 존재한다. 포트 번호는 범위에 따라서 세 종류로 나뉜다.

잘 알려진 포트 : 0~1023번까지의 포트 번호로, 범용적으로 사용되는 프로토콜의 포트 번호.
등록된 포트 : 덜 범용적이지만, 흔히 사용되는 어플리케이션에 할당하기 위해 사용되는 포트 번호.
동적 포트 : 할당된 어플리케이션이 없고, 특별히 관리되지 않아 자유롭게 사용이 가능한 포트 번호.

서버로 동작하는 프로그램은 일반적으로 잘 알려진 포트 또는 등록된 포트를 사용하며, 서비스 특성상 포트 번호가 사전에 관례적으로 정해져 있는 경우가 많다.

반면에 클라이언트로서 동작하는 프로그램은 동적 포트 번호 중에서 임의의 번호가 할당되는 경우가 많다. 예를 들어 웹 브라우저를 통해 웹 사이트에 접속하면, 서버는 80번이나 443번과 같은 고정된 포트를 사용하지만, 웹 브라우저는 요청을 보낼 때 동적 포트 중 하나를 자동으로 할당받아 서버와 패킷을 주고받는다.

포트 기반 NAT

NAT란 IP 주소를 변환하는 기술이며, 주로 네트워크 내부에서 사용되는 사설 IP 주소와 공인 IP 주소를 변환하는데 사용된다고 했는데, 이러한 변환을 위해 주로 사용되는 것이 NAT 변환 테이블이다.

NAT 변환 테이블

NAT 변환 테이블을 이용한 통신 예시

NAT 변환 테이블을 보면 변환의 대상이 되는 IP 주소가 일대일로 대응되어 있다. 하지만 사설 IP 주소와 공인 IP 주소가 일대일로 대응된다면 네트워크 내부에서 사용되는 사설 IP 주소의 수만큼 공인 IP 주소가 필요하기 때문에 무리가 있다.

따라서 오늘날 대중적으로 사용되는 NAT 기술은 대부분 다수의 사설 IP 주소를 그보다 적은 수의 공인 IP 주소로 변환하는데, 여기서 포트가 활용된다.

NAPT(Network Address Port Translation)

NAPT를 통한 통신 예시

NAPT는 포트를 활용해 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있도록 하는 NAT의 일종이다. NAT 테이블에 변환할 IP 주소 쌍과 더불어 포트 번호도 함께 기록하고, 변환한다.

이처럼 공인 IP 주소가 같더라도 포트 번호가 다르면 네트워크 내부의 호스트를 특정할 수 있기 때문에, 다수의 사설 IP 주소를 그보다 적은 수의 공인 IP 주소로 변환할 수 있게 되므로, N:1로 관리할 수 있게 된다. 이러한 점에서 NAPT는 공인 IP 주소 수 부족 문제를 개선한 기술로도 간주된다.

4-2. TCP와 UDP

TCP 통신 단계와 세그먼트 구조

TCP는 통신 하기 전에 (1)연결을 수립하고, (2)데이터를 송수신 한 후, (3) 통신이 끝나면 연결을 종료한다.

TCP의 연결 수립과 종료를 알려면 MSS(Maximum Segment Size) 와 TCP 세그먼트 구조를 이해해야한다.

MSS(Maximum Segment Size)

MSS(Maximum Segement Size)란 TCP로 전송할 수 있는 최대 페이로드 크기를 의미한다.

MTU와 MSS

TCP 세그먼트 구조

송신지 포트, 수신지 포트 : 송신지, 수신지 어플리케이션의 포트 번호 명시하는 필드다.
순서 번호 : 송수신되는 세그먼트의 올바른 순서를 보장하기 위한 번호가 명시된 필드다.
확인 응답 번호 : 상대 호스트가 보낸 세그먼트에 대한 응답으로 수신하기를 기대하는 순서 번호가 명시된 필드다.
제어 비트 : 세그먼트에 대한 부가 정보를 나타내는 필드로 ACK, SYN, FIN과 같은 TCP Flag가 부여된다.
윈도우 : 한 번에 수신하고자 하는 데이터의 양을 의미한다.

TCP 연결 수립과 종료

연결 수립 : 3-Way Handshake

연결 종료 : 4-way HandShake

TCP 상태

TCP는 연결형 통신 & 신뢰할 수 있는 통신을 유지하기 위해 다양한 상태를 유지한다.

상태라는 것은 현재 어떤 통신 과정에 있는지를 나타내는 정보로, TCP는 상태를 유지하고 활용한다는 점에서 Stateful 프로토콜이라고도 부른다.

1. 연결이 수립되지 않은 상태

CLOSED : 아무런 연결이 없는 상태.
LISTEN : 연결 대기 상태로, Listen 상태의 호스트에게 SYN을 보내면 3-WAY Handshake가 시작.

2. 연결 수립 상태

SYN-SENT : SYN을 보낸 뒤 그에 대한 응답인 SYN+ACK를 기다리는 상태.
SYN-RECEIVED : SYN+ACK 세그먼트를 보낸 뒤, 그에 대한 ACK 세그먼트를 기다리는 상태.
ESTABLISHED : TCP 연결이 수립되어서, 데이터를 송수신할 수 있는 상태.

3. 연결 종료 상태

FIN-WAIT-1 : FIN 세그먼트를 보내 연결 종료를 요청한 상태.
CLOSE-WAIT : 종료 요청인 FIN 세그먼트를 받은 호스트가 ACK를 보낸 후 대기하는 상태.
FIN-WAIT-2 : FIN-WAIT-1 상태에서 ACK를 받게된 후, 상대 호스트의 FIN을 기다리는 상태
LAST-ACK : FIN을 전송한 뒤, 이에 대한 ACK를 기다리는 상태.
TIME-WAIT : FIN을 수신 후 이에 대한 ACK를 전송한 뒤 접어드는 상태로, 일정 시간(2*MSL)을 기다린 뒤 CLOSED 상태로 전이.

UDP 데이터그램 구조

UDP는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜이다. TCP와 다르게 연결 수립, 오류 제어, 흐름 제어, 혼잡 제어 등을 수행하지 않고, 상태를 유지하지도 않는다.

UDP는 TCP에 비해 적은 오버헤드로 패킷을 빠르게 처리할 수 있다는 장점이 있어, 스트리밍 서비스, 인터넷 전화처럼 실시간성이 강조되는 상황에서 많이 사용된다.

4-3. TCP의 오류, 흐름, 혼잡 제어

오류 제어, 흐름 제어, 혼잡 제어

(1) 오류 제어 : 재전송 기법

TCP는 신뢰성을 보장하기 위해서 잘못된 세그먼트를 재전송한다.

TCP 세그먼트에 포함된 체크섬(checksum) 필드는 세그먼트가 전송 중 훼손되었는지를 검증하는 역할을 하지만, 전송 과정에서의 문제까지는 판단할 수는 없다.
따라서 TCP는 신뢰성을 보장하기 위해 다음 두 가지 요소가 필수적이다.

송신 호스트가 송신한 세그먼트에 문제가 있음을 인지해야 한다.
오류를 감지하면 해당 세그먼트를 재전송해야 한다.

재전송 상황 1 : 중복된 ACK 세그먼트를 수신했을 때

TCP는 중복된 ACK 세그먼트를 수신했을 때 오류가 생겼음을 감지한다.

재전송 상황 2 : 타임아웃이 발생했을 때

TCP는 타임아웃이 발생하면 문제가 생겼음을 인지한다.

TCP 세그먼트를 송신하는 호스트는 모두 재전송 타이머라는 값을 유지한다. 세그먼트를 전송할 때 마다 재전송 타이머를 시작하게 되고, 카운트다운이 끝나면 타임아웃이 발생하게 된다.

타임아웃이 발생할 때 까지 ACK 세그먼트를 받지 못하면 상대 호스트에게 정상적으로 도착하지 않았다고 판단하여 재전송한다.

ARQ : 재전송 기법

수신 호스트의 답변(ACK)과 타임아웃 발생을 토대로 문제가 생긴 메시지를 재전송하는 걸 ARQ(Automatic Repeat Request)라고 한다.

ARQ에는 크게 3가지 방식이 존재한다.

Stop-and-Wait ARQ : 제대로 전달했음을 확인하기 전까지는 새로운 메시지를 보내지 않는 방식
Go-Back-N ARQ : 여러 세그먼트를 전송하고, 도중에 잘못 전송된 세그먼트가 발생할 경우, 해당 세그먼트부터 전부 다시 전송하는 방식
Selective Repeat ARQ : Go-Back-N ARQ처럼 여러 세그먼트를 전송하고, 올바르게 수신 받지 못한 ACK 세그먼트에 대해서만 재전송을 하는 방식

(2) 흐름 제어 : 슬라이딩 윈도우

Go-Back-N ARQ와 Selective Repeat ARQ와 같이 여러 세그먼트를 연속적으로 전송하는 파이프라이닝 기반 전송 방식에서는, 송신 측이 수신 측의 처리 능력을 초과하여 데이터를 보내지 않도록 흐름 제어를 함께 고려해야 한다.

전송할 때 수신 버퍼의 크기를 고려하지 않으면 버퍼 오버플로우가 발생한다.

수신 버퍼 : 수신된 세그먼트가 어플리케이션 프로세스에 의해 읽히기 전에 임시로 저장되는 공간
버퍼 오버플로 : 저장 가능한 공간보다 더 많은 데이터가 들어오면 버퍼가 넘치는 문제 상황을 의미

오늘날 TCP에서는 흐름 제어로 슬라이딩 윈도우(Sliding Window)를 사용한다. 윈도우란 송신 호스트가 파이프라이닝 할 수 있는 최대량을 의미하는데, 윈도우의 크기만큼 확인 응답을 받지 않고도 한 번에 전송이 가능하다.

수신 호스트는 TCP 헤더(윈도우 필드) 를 통해, 자신이 현재 수신 가능한 데이터의 양을 송신 호스트에게 알리면 송신 호스트는 이 값을 기반으로 전송 가능한 데이터의 범위, 즉 송신 윈도우 크기를 결정하고, 수신 호스트의 처리 능력을 초과하지 않도록 전송량을 조절한다.

이 과정에서 송신 호스트는 윈도우 범위 내에서 여러 세그먼트를 연속적으로 전송하며, ACK가 수신될 때마다 전송이 완료된 구간을 제외하고 새로운 데이터 전송 범위를 확장한다.

(3) 혼잡 제어

여러 호스트가 한 대의 라우터에 연결되어 있을 때, 해당 호스트들이 한번에 최대 양으로 세그먼트를 전송하면 라우터에 과부하가 생겨 모든 정보를 처리 못하게 된다. 이렇듯 혼잡이란 많은 트래픽으로 인해 패킷의 처리속도가 늦어지거나 유실될 우려가 있는 네트워크 상태를 의미한다.

흐름 제어의 주체가 수신 호스트라면 혼잡 제어의 주체는 송신 호스트로, 송신 호스트는 혼잡한 정도에 맞춰 유동적으로 전송량을 조절하며 전송해야 한다. 송신 호스트는 혼잡 윈도우의 크기가 어느정도가 적절할지 직접 계산해서 알아내야 한다.

혼잡 윈도우(CWND, Congestion WiNDow) : 혼잡 없이 전송할 수 있을 법한 데이터 양

혼잡 제어 알고리즘 종류

AIMD : 혼잡이 감지되지 않는다면 혼잡 윈도우를 RTT마다 1씩 선형적으로 증가, 혼잡이 감지되면 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복하는 알고리즘이다.
느린 시작 알고리즘 : 혼잡 윈도우를 1부터 시작해 문제없이 수신된 ACK 세그먼트 하나 당 1씩 증가시키는 방식이다.
혼잡 회피 알고리즘 : RTT(Round Trip Time)마다 혼잡 윈도우를 1 MSS(Maximum Segment Size)씩 증가시키는 알고리즘.
빠른 회복 알고리즘 : 세 번의 중복 ACK 세그먼트를 수신했을 때 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘.

[혼공네] 3장 네트워크 계층

jin_e_us — Sun, 12 Oct 2025 15:47:26 +0900

3-1. LAN을 넘어서는 네트워크 계층

데이터 링크 계층(Layer 2)의 한계

한계 1. 물리 계층과 데이터 링크 계층만으로는 다른 네트워크까지의 도달 경로를 파악하기 어렵다.

물리 계층, 데이터 링크 계층에서는 기본적으로 같은 네트워크(LAN) 단위를 다루는데, 다른 네트워크 간의 통신은 다루지 않는다.
패킷이 이동할 최적의 경로를 결정하는 것을 라우팅이라고 하고, 네트워크 계층에서는 라우팅을 수행하기 위해 라우터라는 것이 이용된다.

한계 2. MAC 주소만으로는 모든 네트워크에 속한 호스트의 위치를 특정하기 어렵다.

모든 호스트가 모든 네트워크에 속한 호스트의 MAC 주소를 서로 알고 있기는 너무 어렵기 때문에 MAC 주소만으로 이 세상 모든 호스트를 특정하는 것은 어렵다.
네트워크 계층에서는 IP 주소를 활용해서 수신지가 어디에 있는지 위치를 파악할 수 있다.

인터넷 프로토콜

IP 주소 형태

IP 주소

4 Byte(32bit)로 주소 표현이 가능하고, 네 개의 10진수로 표기되고, 각 숫자는 점으로 구분된다.
점으로 구분된 8비트를 옥텟이라고 한다.

IP의 기능

기능 1. IP 주소 지정 : IP 주소를 바탕으로 송수신 대상을 지정하는 것을 의미

기능 2. IP 단편화 : 전송하고자 하는 패킷의 크기가 MTU(Maximum Transmission Unit)보다 클 경우 복수의 패킷으로 나누는 것을 의미한다.

IPv4 패킷 헤더

이더넷 프레임 구조(위) , IPv4 패킷 구조 (아래)

식별자

패킷에 할당된 번호로, 전송 과정에서 IPv4 패킷이 여러조각으로 쪼개져서 전송되었을 때 수신지에서 재조합을 위해 사용한다.

플래그

IP 단편화 수행을 위해 존재하는 필드로 3비트로 구성된다.
- 첫 번째 비트는 항상 0으로 고정.
- 두 번째 비트는 DF(Don't Fragment)로 1이면 단편화를 하지 않음, 0이면 단편화 가능을 의미.
- 세 번째 비트는 MF(More Fragments)로 1이면 뒤에 단편화된 패킷이 더 있음, 0이면 마지막 패킷임을 의미.

단편화 오프셋

패킷이 단편화 되기 전 초기 데이터에서 몇 번째로 떨어진 패킷인지를 나타낸다.

TTL

패킷의 수명을 의미하는 단어다.
패킷이 하나의 라우터를 거칠 때마다 TTL이 1씩 감소하고, 0이 되면 폐기된다.
네트워크상에 패킷이 지속적으로 남아있는 것을 방지하기 위해 사용된다.

프로토콜

상위 계층의 프로토콜이 무엇인지를 나타내는 필드이다.
- TCP : 6, UDP : 17 등...

이외에도 IPv4 패킷에는 여러 필드들이 존재한다.

ARP (Address Resolution Protocol)

ARP란 동일 네트워크 내에서 IP 주소를 통해 상대 호스트의 MAC 주소를 알아내는데 사용하는 프로토콜이다.
기본적으로 네트워크에서는 IP 주소를 사용하지만, 패킷을 올바르게 송신하려면 상대 호스트의 MAC 주소가 필요하다.
따라서 같은 네트워크 내의 호스트로 데이터를 보낼 경우 상대 호스트의 MAC 주소, 다른 네트워크로 보낼 경우에는 라우터(게이트웨이)의 MAC 주소를 알아야 한다.

ARP 프로토콜 순서도

ARP 요청 : 같은 네트워크 내의 모든 호스트에게 브로드캐스트 메시지를 보냄.
ARP 응답 : 요청을 받은 호스트들 중 IP 주소가 일치하는 호스트만 자신의 MAC 주소를 유니캐스트로 응답한다.
ARP 테이블 갱신 : 모든 호스트는 ARP 테이블이라는 IP 주소와 그에 맞는 MAC 주소를 대응하는 표를 유지하는데, 송신자는 응답받은 MAC 주소를 ARP 테이블에 저장

3-2. IP 주소

클래스풀 주소 체계

하나의 IP 주소는 크게 네트워크 주소와 호스트 주소로 이루어짐
- 네트워크 주소 : 특정 네트워크를 식별하는 역할.
- 호스트 주소 : 네트워크 내에서 특정 호스트를 식별하는 역할.
필요한 호스트 IP 개수에 따라 네트워크 크기를 가변적으로 조정해 네트워크 주소와 호스트 주소를 구획할 수 있다.
클래스를 기반으로 IP 주소를 관리하는 주소 체계를 클래스풀 주소 체계(classful addressing)라고 한다.
A, B, C 클래스는 네트워크의 크기를 나누는 데에 실질적으로 사용된다. (D클래스는 멀티 캐스트를 위한 클래스, E 클래스는 특수한 목적을 위해 예약된 클래스)

클래스풀 주소 체계

A 클래스

네트워크 주소는 비트 0으로 시작하는 1옥텟이며, 호스트 주소는 3옥텟으로 구성된다.
이론상 2^7(128)개의 A 클래스 네트워크가 존재할 수 있으며, 2^24(16,777,216)개의 호스트 주소를 가질 수 있다.
A 클래스의 IP 주소의 범위는 0.0.0.0 ~ 127.255.255.255 이다.

B 클래스

네트워크 주소는 비트 10으로 시작하는 2옥텟이며, 호스트 주소도 2옥텍으로 구성된다.
이론상 2^14(16,384)개의 B 클래스 네트워크가 존재할 수 있으며, 2^16(65,534)개의 호스트 주소를 가질 수 있다.
B 클래스의 IP 주소의 범위는 128.0.0.0 ~ 191.255.255.255 이다.

C 클래스

네트워크 주소는 비트 110으로 시자하는 3옥텟이며, 호스트 주소는 1옥텟으로 구성된다.
이론상 2^21(2,097,152)개의 C 클래스 네트워크가 존재할 수 있으며, 2^8(256)개의 호스트 주소를 가질 수 있다.
C 클래스의 IP 주소의 범위는 192.0.0.0 ~ 223.255.255.255 이다.

단, 호스트 주소 공간을 모두 사용할 수 있는 것은 아니다.
- 호스트 주소가 전부 0인 IP 주소는 해당 네트워크 자체를 의미하는 네트워크 주소로 사용된다.
- 호스트 주소가 전부 1인 IP 주소는 브로드캐스트를 위한 주소로 사용된다.

클래스리스 주소 체계

클래스풀 주소 체계를 이용하면 네트워크의 영역을 결정하고 할당 가능한 호스트의 주소 공간을 유동적으로 관리할 수 있지만, 클래스별 네트워크의 크기가 고정되어 있기에 여전히 다수의 IP 주소가 낭비될 가능성이 크다는 문제가 있다.
그래서 나온게 클래스리스 주소 체계인데, 아래 주소의 CIDR(Classless Inter-Domain Routing) 설명 참고...

[AWS] VPC, Subnet 알아보기

CIDRCIDR이란 IP 주소의 영역을 여러 네트워크 영역으로 나누기 위해 IP를 묶는 방식을 의미합니다.CIDR의 NotationCIDR은 A.B.C.D/E의 형태를 띄고 있습니다. 예를 들어 10.0.0.0/24 , 172.16.0.0/12와 같은 형식입

itcodeheaven.tistory.com

공인 IP와 사설 IP 주소 체계

공인 IP 주소

- 전 세계에서 고유한 IP주소로, ISP나 공인 IP 주소를 할당 기관을 통해서 할당 받을 수 있다.

사설 IP 주소와 NAT

사설 IP 대역과 NAT 예시

사설 IP란, 사설 네트워크에서 사용하기 위한 IP 주소로 일반적으로 라우터가 할당한다.
할당받은 사설 IP 주소는 해당 호스트가 속한 사설 네트워크상에서만 유효한 주소이므로, 얼마든지 다른 네트워크상의 사설 IP 주소와 중복될 수 있다.
사설 IP 주소만으로는 일반적인 인터넷 접속을 비롯한 외부 네트워크 간의 통신이 어렵기 때문에 공인 IP로 주소를 변환해야하는데 이때 필요한게 NAT이다.
NAT는 네트워크 내부에서 사용되는 사설 IP 주소를 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는데 사용된다.

3-3. 라우팅

라우터 (Router)

라우터 이미지(왼) : https://www.sinsmarts.com/ , 라우터 네트워크(우) : https://yohanpro.com/

서로 다른 네트워크 간 통신을 위해 필요한 장치가 라우터다.
- 같은 네트워크 대역이란, 같은 서브넷에 속해 라우터를 거치지 않고 직접 통신할 수 있는 장치들의 집합을 말한다.
- 일반적으로 같은 라우터의 동일 인터페이스(또는 포트)에 연결된 장치들은 같은 네트워크에 속한다.

Router와 Hop

멀리 떨어져 있는 호스트 간의 통신 과정에서 패킷은 여러 라우터를 거쳐서 다양한 경로로 이동하며, 라우터와 라우터 간 하나의 과정을 홉(hop)이라고 부른다.

라우팅 테이블

(혼자 공부하는 네트워크) 라우팅 테이블 예시

라우팅 테이블이란 라우터가 저장하고 관리하는 테이블로, 특정 수신지까지 도달하기 위한 정보를 명시한 일종의 표이다.
라우터는 라우팅 테이블을 참고하여 수신지까지의 도달 경로를 판단한다.
라우팅 테이블은 다음과 같은 정보들로 구성된다.
- 수신지 IP 주소와 서브넷 마스크 : 최종적으로 퍀시을 전달할 대상을 의미한다.
- 다음 홉(or 게이트웨이) : 최종 수신지까지 가기 위해 다음으로 거쳐야 할 호스틩 IP 주소나 인터페이스를 의미한다.
- 네트워크 인터페이스 : 패킷을 내보낼 통로를 의미하며, NIC 이름이 직접 명시되거나 IP주소가 명시되기도 한다.
- 메트릭 : 해당 경로로 이동하는데 드는 비용을 의미한다. 메트릭 값이 낮은 경로를 선호된다.
패킷 내의 수신지 IP 주소가 라우팅 테이블에 있는 수신지 IP 주소, 서브넷 마스크 항목과 완벽하게 합치되는 경우는 해당 경로로 보내고, 라우팅 테이블에 없는 경로로 패킷을 보내는 경우에는 디폴트 라우트 라는 기본적으로 내보낼 경로를 설정한다.
- 디폴트 라우트는 수신지 IP 주소를 모든 IP 주소를 의미하는 0.0.0.0/0으로 명시한다.

정적 라우팅과 동적 라우팅

정적 라우팅

사용자가 직접 라우팅 테이블의 정보를 추가해서 라우팅하는 방법을 의미한다.

동적 라우팅

네트워크 규모가 커지면 정적 라우팅만으로 관리하기가 버거워진다. 따라서 자동으로 라우팅 테이블 항목을 만들고, 이를 이용하여 라우팅하는 동적 라우팅이 필요하다.
동적 라우팅은 라우팅 프로토콜을 통해 자동으로 채워진 라우팅 테이블 항목을 토대로 라우팅되는 방식이다.

라우팅 프로토콜

라우팅과 라우팅 프로토콜들

라우터끼리 자신들의 정보를 교환하며 패킷이 이동할 최적 경로를 찾는 프로토콜을 라우팅 프로토콜이라고 한다.
라우팅 프로토콜은 크게 AS(집단 네트워크) 내부에서 수행되느냐, AS 외부에서 수행되느냐에 따라 종류를 나눌 수 있다.
- AS : 동일한 라우팅 정책으로 운용되는 라우터들의 집단.

IGP (집단 네트워크 내부에서 수행)

RIP

거리 벡터 기반의 라우팅 프로토콜
인접한 라우터끼리 경로 정보를 주기적으로 교환하며 라우팅 테이블을 갱신
특정 수신지에 도달하기까지의 홉 수를 판단하여 가장 적은 홉이 최적 경로

OSPF

링크 상태 라우팅 프로토콜
라우터들의 연결 관계, 연결 비용 등 현재 네트워크의 상태를 그래프로 표현함.
표현된 그래프를 바탕으로 대역폭 기반의 메트릭을 계산해 최적 경로 결정

EGP (집단 네트워크 외부에서 수행)

RIP

AS(집단 네트워크)간의 통신에서 사용되는 대표적인 프로토콜

[혼공네] 2장 물리 계층과 데이터 링크 계층 - (2)

jin_e_us — Tue, 7 Oct 2025 17:27:29 +0900

3. 허브 (물리 계층)

물리 계층에는 주소 개념이 없기 때문에 단순히 통신 매체상의 정보를 송수신하는 역할만 수행한다.

허브

여러 대의 호스트를 연결하는 장치로, 리피터 허브 또는 이더넷 허브라고 부른다.
커넥터를 연결할 수 있는 연결 지점을 포트라고 하고, 포트를 통해 호스트와 연결된 통신 매체를 연결할 수 있다.

허브의 특징

특징 1. 전달받은 신호를 다른 모든 포트로 그대로 다시 내보낸다.

물리 계층에는 주소 개념이 없기 때문에 수신지를 특정할 수 없다. 따라서 신호를 전달 받으면 어떠한 조작이나 판단을 하지 않고 모든 포트에 그저 내보내기만 한다.
신호를 전달받은 모든 호스트는 데이터 링크 계층에서 자신의 MAC 주소가 아닌 경우에는 폐기한다.

특징 2. 반이중(Half-Duplex) 모드로 통신한다.

허브는 송수신을 동시에 양방향으로 할 수 없는 구조로, 한 번에 송신 또는 수신 중 하나만 가능하다.

콜리전 도메인

허브는 반이중(Half-Duplex) 통신을 지원하므로 한 호스트가 허브에 송신하는 동안 다른 호스트는 송신하고 싶은 것이 있어도 기다려야한다.
만약 동시에 허브에 신호를 송신하게 되면 충돌(콜리전)이 발생하게 되고, 허브에 많은 호스트가 붙을수록 충돌 발생 가능성이 높아진다.
콜리전 도메인이란 충돌이 발생할 수 있는 영역을 의미하고, 허브에 연결된 모든 호스트는 같은 콜리전 도메인에 속한다.

CSMA/CD

반이중 이더넷 네트워크에서 충돌(콜리전)을 방지하기 위한 대표적인 프로토콜이다.

1. 메시지를 보내기 전에 현재 네트워크상에서 전송 중인 것이 있는지 확인.

2. 다른 호스트가 전송 중이지 않을 때 메시지를 전송.

3. 복수의 호스트가 네트워크에 접근하여 충돌이 발생하면 전송이 중단되고, 임의 시간 대기 후 재전송 진행.

4. 스위치 (데이터링크 계층)

스위치

데이터 링크 계층의 네트워크 장비로 여러 호스트를 포트를 통해 연결할 수 있다.
스위치는 MAC 주소를 학습하여 특정 MAC 주소를 가진 호스트가 연결된 포트로만 프레임을 전달하고, 전이중(Full-Duplex) 통신을 지원하므로 동시에 송수신이 가능하다.
이러한 특징으로 인해 스위치를 이용하면 CSMA/CD 프로토콜을 이용하지 않고도 충돌 문제를 해결할 수 있다.

MAC 주소 학습

스위치는 각 포트에 연결된 호스트의 MAC 주소를 학습하여, 포트와 MAC 주소 간의 관계를 MAC 주소 테이블(MAC Address Table)에 저장한다. MAC 주소 테이블을 기반으로, 스위치는 해당 MAC 주소를 가진 호스트가 연결된 포트로만 프레임을 전달할 수 있다.
MAC 주소 테이블이 어떻게 작성되는지, 유지되는지를 이해하기 위해서는 플러딩, 포워딩과 필터링, 에이징이라는 스위치의 기본 동작을 알아야한다.

플러딩 (Flooding)

스위치의 MAC 주소 테이블에 목 적지 MAC 주소가 존재하지 않는 경우, 허브처럼 송신지 포트를 제외한 모든 포트로 프레임을 전송하는데 이를 플러딩이라고 함.

포워딩과 필터링

전달받은 프레임을 어떤 포트로 내보내고 어떤 포트로는 내보내지 않을지 결정하는 기능을 필터링이라고 함.
프레임이 전송될 포트에만 프레임을 내보내는 것을 포워딩 이라고 한다.

에이징

MAC 주소 테이블에 등록된 특정 포트에서 일정 시간 동안 프레임을 전송받지 못했다면 해당 항목이 삭제되는데, 이를 에이징이라고 한다.

VLAN (Virtual LAN)

스위치에 연결된 호스트들 중 서로 메시지를 주고 받을 일이 없거나, 브로드캐스트 메시지를 받을 필요가 없어서 굳이 같은 네트워크에 속할 필요가 없는 호스트들이 있을 수 있다. 이때마다 호스트들을 구분하기 위해 새로운 스위치 장비를 구매하는 것은 비효율적이다.
VLAN 이용하면 하나의 물리적 스위치를 여러 개의 스위치가 있는 것처럼 독립된 여러 개의 LAN 환경을 구성할 수 있다.

https://www.zframez.com/articles/switching/vlan-configuration-examples

위의 그림처럼 VLAN을 구성하면 VLAN 10(개발 부서)에 속한 PC1, PC2는 동일한 LAN에 있는 것으로 인식하지만, VLAN 20(총무 부서)에 속한 PC3, PC4는 물리적인 거리와 관계 없이 다른 LAN에 있는 것으로 인식한다.
VLAN10에 속한 호스트가 VLAN2에 속한 호스트와 통신하려면 데이터링크 계층(Layer 2)에서는 불가능하고, 네트워크 계층(Layer 3) 이상의 상위 계층 장비가 필요하다.

포트 기반 VLAN

스위치의 특정 포트에 VLAN을 할당하고, 해당 포트에 호스트를 연결함으로써 VLAN을 구성하는 방법이다.
한 대의 스위치만으로 VLAN 이용 시 포트가 부족해질 수 있는데, 이런 경우 VLAN 트렁킹(VLAN Trunking)을 이용해 두 대 이상의 VLAN 스위치를 효율적으로 연결하여 확장 가능하다.
VLAN 트렁킹이란 스위치 간의 통신을 위한 특별한 포트인 트렁크 포트(Trunk Port)에 VLAN 스위치를 서로 연결하는 방식이다.

MAC 기반 VLAN

MAC 기반 VLAN(MAC Based VLAN)은 포트가 VLAN을 결정하는 방식이 아니라 송수신하는 프레임 속 MAC 주소를 통해서 VLAN을 인식하는 방식으로 스위치가 각 MAC 주소에 대해 VLAN ID를 매핑해 관리한다

[혼공네] 2장 물리 계층과 데이터 링크 계층 - (1)

jin_e_us — Sun, 5 Oct 2025 18:49:20 +0900

2-1. 이더넷(Ethernet)

이더넷 표준

오늘날의 현대 유선 LAN 환경은 대부분 이더넷(Ethernet) 기술을 기반으로 구성되어 있다. (무선은 WIFI)
- 즉, 물리 계층에서는 이더넷 규격의 케이블을 사용하고, 데이터 링크 계층에서는 이더넷 프레임 형식에 따라 데이터를 주고받는다.
- 이더넷 표준을 준수한 덕분에 서로 다른 네트워크 장비들끼리 원활하게 통신할 수 있는 것이다.
이더넷이란 다양한 통신 매체의 규격들과 송수신되는 프레임의 형태, 프레임을 주고받는 방법 등이 정의된 네트워크 기술이다.
이더넷 관련한 다양한 기술(표준)들은 IEEE(전기전자공학자협회)에 의해 IEEE 802.3이라는 이름으로 표준화했다.
- IEEE 802.3u : 최대 100Mbps 속도를 지원하며, BASE를 이용하는 트위스티드 페어 케이블(100BASE-TX)
- IEEE 802.3ab : 최대 1000Mbps 속도를 지원하며, BASE를 이용하는 트위스티드 페어 케이블(1000BASE-T)

통신 매체 표기 형태

- 이더넷 표준 규격에 따라 구현된 통신 매체를 지칭할 때는 통신 매체의 속도와 특성을 한눈에 파악하기 쉽도록 다음과 같은 형태로 표기함.

- 전송 속도, BASE, 추가특성으로 이루어짐

1. 전송 속도

- 케이블이 지원하는 전송 속도를 의미한다

전송속도 표기	의미
10	10Mbps
100	100Mbps
1000	1000Mbps(1Gbps)
2.5G	2.5Gbps
10G	10Gbps
100G	100Gbps

케이블에서 100Base-T 케이블은 100Mbps를 지원하는 케이블을 의미함.

2. BASE

베이스밴드의 약자로, 변조 타입을 의미한다.
- 변조 타입 : 비트 신호로 변환된 데이터를 통신 매체로 전송하는 방법을 의미
대부분의 이더넷 통신 매체는 BASE를 이용
- EX) 1000BASE-CX

3. 추가 특성

통신 매체의 특성들이 명시된다.
- 전송가능한 최대 거리
- 물리 계층 인코딩 방식
- 레인 수 (비트 신호를 옮길 수 있는 전송로 수를 의미)
- 통신매체의 종류
EX) 1000BASE-LR4
- L : 장파장 광섬유 케이블
- R : 물리 계층에서의 인코딩 방식
- 4 : 비트를 전송할 전송로(레인) 수

통신 매체 종류

추가 특성에 적히는 통신 매체 종류에는 크게 4가지가 있다.

통신 매체의 종류 케이블 종류

C	동축 케이블
T	트위스티드 페어 케이블
S	단파장 광섬유 케이블
L	장파장 광섬유 케이블

100BASE-T 케이블 : 100Mbps를 지원하는 트위스티드 페어 케이블

이더넷 프레임

이더넷 프레임은 데이터 링크 계층에서 주고받는 프레임 형식이 정해져 있는데, 상위 계층에서 받아드린 정보에 헤더와 트레일러를 통해서 물리 계층으로 보내고, 수신지는 물리 계층에서 받아드린 정보에서 헤더와 트레일러를 제거한 뒤 상위 계층을 보내지게 된다.

헤더 : 프리앰블, 수신지/송신지MAC 주소, 타입/길이
트레일러 : FCS

이더넷 프레임

헤더

프리앰블

이더넷 프레임의 시작을 알리는 8바이트 크기의 정보
송수신지 간의 동기화를 위해 사용되는 정보

송신지/수신지 MAC 주소

MAC 주소 : 네트워크 인터페이스(NIC)마다 부여되는 6바이트 길이의 주소로, LAN 내의 수신지와 송신지를 특정할 수 있게 해준다.

타입/길이

이더넷 프레임의 상위 계층에서 이용된 프로토콜(타입)을 나타내거나, 프레임의 페이로드의 길이를 나타내는 역할을 한다.
- 값이 1500(0x05DC) 이하인 경우에는 페이로드의 길이를 의미하며, 1536(0x0600) 이상인 경우에는 상위 계층 프로토콜의 타입을 나타낸다.
- 타입 값 예시 : 0800 : IPv4, 86DD : IPv6, 0806 : ARP 등...

트레일러

FCS (Frame Check Sequence)

수신한 이더넷 프레임에 오류가 있는지 확인하기 위한 필드로, 데이터 링크 계층에서의 역할인 오류 검출을 담당한다.
이 필드에는 CRC(Cyclic Redundancy Check) 라 불리는 오류 검출용 값이 저장된다.
송신 측에서는 프리앰블을 제외한 나머지 모든 필드의 데이터를 바탕으로 CRC 값을 계산하여 FCS에 기록하고,
수신 측에서도 동일한 방식으로 CRC 값을 계산한 뒤, 수신한 FCS 값과 불일치할 경우 프레임을 폐기한다.

2-2. NIC와 케이블

NIC

통신 매체(전기, 빛)를 통해서 전달되는 신호를 컴퓨터가 이해할 수 있도록 변환을 담당하는 네트워크 장비
장비에 장착된 NIC마다 MAC 주소가 부여된다.

케이블 1. 트위스티드 페어 케이블

구리선으로 전기 신호를 주고받는 통신 매체로, 케이블 본체와 케이블 연결부인 커넥터로 이루어져 있다.
구리선으로 이루어진 상태에서 전기 신호를 주고받다보면 전자적 간섭이 생겨 노이즈가 발생할 수 있음.
그래서 구리 선을 그물 모양 철사(브레이드 실드) 또는 포일(포일 실드)로 감싸 보호하는 경우가 많음.

케이블 분류

STP(Shielded Twisted Pair) 케이블 : 브레이드 실드로 구리선을 감싸 노이즈를 감소시킨 케이블
FTP(Foil Twisted Pair) 케이블 : 포일 실드로 노이즈를 감소시킨 케이블
UTP(Unshielded Twisted Pair) 케이블 : 아무것도 감싸지 않고, 그냥 구리선만 있는 케이블

케이블 2. 광섬유 케이블

빛(광신호)를 이용해 정보를 주고받는 케이블
속도도 빠르고, 노이즈 간섭도 적다.

광케이블 커넥터 종류

싱글 모드 광섬유 케이블

코어의 지름이 작아 빛의 이동 경로가 하나인 케이블로, 케이블 색상이 대부분 노란색 또는 파란색이다.

멀티 모드 광섬유 케이블

코어의 지름이 커서 빛의 이동 경로가 여러개인 케이블로, 케이블 색상이 대부분 주황색 또는 하늘색이다.