blog.

Chapter14. 전송 제어 프로토콜 (TCP) 4.3 ~

ttoance — Sat, 13 Jun 2026 22:17:24 +0900

4. TCP 연결

TCP 는 연결형 프로토콜이다.
- 연결형 전송 프로토콜은 발신지와 목적지 간에 가상 경로를 설정한다.
- 하나의 메시지에 속하는 모든 세그먼트는 이러한 가상 경로를 통하여 전송한다.
비연결형 프로토콜인 IP 서비스를 이용하는 TCP가 어떻게 연결형을 제공할 수 있는지가 궁금할 것이다.
- 요점은 TCP 연결은 실제가 아닌 가상이라는 것이다.
- TCP는 상위 단계에서 동작한다.
- TCP는 수신 측에서 각 세그먼트를 전송하기 위해서 IP 서비스를 이용하지만, TCP 자체에서 연결을 제어한다.

4.1 연결 설정

TCP는 전이중 full-duplex 방식으로 데이터를 전송한다.
- ㅇ두 기기에 있는 TCP가 서로 연결되면, 이들은 동시에 서로 세그먼트를 주고받을 수 있다.
3-방향 핸드셰이크 three-way handshaking
- 이 절차에서 클라이언트는 응용 프로그램은 서버라는 응용 프로그램과 전송층 프로토콜인 TCP를 이용하여 연결을 설정한다.
- 절차는 서버에서부터 시작한다. (수동 개방 passive open)
- 클라이언트 프로그램은 능동 개방 active open을 위한 요청을 실행한다.
  - 수동 개방이 되어있는 서버와 연결을 설정하고자 하는 클라이언트는 자신의 TCP에게 특정 서버와 연결을 설정한다는 것을 알린다.
동시 개방
- 두 프로세스가 동시에 서로에게 능동 개방을 요구하는 상황이 일어날 수 있다.
- 이 경우, 양쪽 TCP는 서로에게 SYN + ACK 세그먼트를 전송하게 되고 하나의 단일 연결이 두 TCP 사이에 설정된다.
SYN 플러딩 공격 SYN flooding attack
- 악의에 찬 공격자가 데이터그램의 발신지 IP주소를 위조하여 서로 다른 클라이언트로 가장한 후에 많은 수의 SYN 세그먼트를 하나의 서버에 전송하는 경우에 발생한다.
- 이 공격은 서비스 거부 공격 denial of service attack 이라는 보안 공격의 일종이다.

4.2 데이터 전송

연결이 설정된 후에는 양방향으로 데이터가 전송될 수 있다.

푸시 데이터
- 송신 TCP는 송신 응용 프로그램에서 오는 데이터 스트림 저장하기 위하여 버퍼를 이용한다.
  - 송신 TCP는 세그먼트의 크기를 선택할 수 있다.
- 수신 TCP는 수신한 데이터를 저장하기 위한 버퍼를 가지고 있으며, 응용 프로그램이 수신할 준비가 되어있을 때 데이터를 응용 프로그램으로 전달한다.
- 하지만, 특정 응용 프로그램의 경우 (ex, 대화 프로그램) 푸시(push) 동작을 통해 창아 디 찰때까지 기다리지 않고 즉시 전송할 수 있다.
긴급 데이터
- 응용 프로그램이 긴급 다이트를 전송할 필요가 있을때, URG 비트를 1로 설정해서 긴급하는 것을 알린다.

4.3 연결 종료

데이터를 교환하는 어느 쪽도 연결을 종료할 수 있지만, 일반적으로는 클라이언트에서 종료를 시작한다.
현재 대부분의 구현에서는 연결 종료를 위하여 3-방향 핸드셰이크와 절반-닫기 옵션을 가진 4-방향 핸드셰이크 등의 2가지 옵션이 사용된다.
3-방향 핸드셰이크

절반-닫기
- TCP에서 한쪽 데이터를 수신하면서 데이터 전송을 종료할 수 있다.
- 서버나 클라이언트에서 모두 시작할 수 있다.

4.4 연결 재설정

한쪽 편에 있는 TCP는 RST(reset) 빝트를 1로 설정함으로써 연결 요청을 거절하거나, 연결을 중단하거나, 휴지 상태에 있는 연결을 종료할 수 있다.
연결 거절
- 한쪽의 TCP가 존재하지 않은 포트로 연결 요청하는 경우, 다른쪽의 TCP는 요청 거부하기 위해 RST 비트를 설정한 세그먼트를 전송한다.
연결 중단
- 한 TCP는 비정상적인 상황의 경우에 설정되어 있는 연결을 중단할 수 있다.
- 이 경우 TCP는 연결 종료하기 위하여 RST 세그먼트를 전송한다.
휴지 연결의 종료
- 한쪽 TCP는 다른 편의 TCP가 오래 시간 동안 휴지 상태에 있다는 것을 확인한 후, 연결을 해제하기 위하여 RST 세그먼트를 전송한다.

5. 상태 천이 다이어그램

6. TCP 창

TCP는 데이터 전송을 위해 각 방향에 대해 두 개의 창(송신 창과 수신 창)을 사용하며
양방향 통신을 위해서 네 개의 창이 필요하다.

6.1 송신 창

TCP 창은 바이트의 번호를 나타낸다.

6.2 수신 창

7. 흐름 제어

생산자가 데이터를 생성하는 속도와 소비자가 데이터를 처리하는 속도와 균형을 맞추는 것이다.

7.1 창 열기와 닫기

연결 설정할 때 양쪽 끝에서 버퍼의 크기는 고정되지만, 흐름 제어를 수행하기 위해 TCP는 송신측과 수신 측으로 하여금 자신의 창의 크기를 조정하도록 한다.

7.2 창 축소

수신 창은 축소될 수 없다.
그렇지만 수신 측에서 창의 축소를 야기하는 rwnd값을 통보하는 경우 송신창은 축소될 수 있다.
창 폐쇄
- 수신 측에서 잠시 송신 측으로부터 데이터 수신하고 싶지 않을 때 발생한다.

8. 오류 제어

8.1 검사합

각 세그먼트에는 검사합 필드가 있으며, 이 필드는 세그먼트가 훼손되었는지를 검사하기 위해 사용한다.
만일 세그먼트의 확인된 검사합이 다르면, 목적지 TCP는 세그먼트가 손상된 것으로 간주하고 세그먼트를 폐기한다.

8.2 확인응답

데이터 세그먼트의 수신을 확인해 주기 위하여 확인 응답을 사용한다.
확인응답 유형
- 누적 확인응답 (ACK)
  - 수신 측에서 세그먼트가 폐기되거나, 손실되거나, 중복 수신되었다는 것에 대한 어떠한 피드백을 제공해주지는 않는다.
- 선택적 확인응답 (SACK)
  - 송신 측에 부가 정보를 알려주기 위해 사용된다.
  - 순서에 어긋나게 들어온 데이터 블록과 중복 세그먼트 블록을 알려준다.

8.3 재전송

RTO Retransmission TIme out 이후의 재전송
- 송신 TCP는 하나의 재전송 타임아웃 타이머를 구동한다.
- 타이머가 만료되어 타임 아웃이 발생하면, TCP는 버퍼 앞에 있는 세그먼트 전송하고 타이머를 재구동한다.
세 개의 중복 ACK 세그먼트 이후에 재전송
- 타임 아웃 기다리기보다 빨리 재전송하도록 함으로써 세 개의 중복 ACK 규칙을 따른다.
- 이러한 특징을 빠른 재전송이라고 한다.

8.4 순서가 어긋난 세그먼트

순서에 어긋나게 들어오는 세그먼트들을 버리지 않고, 일시적으로 세그먼트들 저장하며, 손실된 세그먼트가 도착하기 전까지 이 세그먼트들을 순서가 어긋난 세그먼트로 표시한다.

9. 혼잡 제어

TCP의 혼잡 제어는 개방 루프와 폐 루프 메커니즘을 기반으로 한다.

9.1 혼잡 창

송신자는 수신자에 의해서 광고되는 창 크기와 혼잡 창 크기 정보 가지고 있으며, 창의 실제 크기는 두 정보 중에 최솟값이다.
실제 창의 크기 = 최솟값 (rwnd, cwnd)

9.2 혼잡 제어 원칙

혼잡을 처리하는 일반적인 원칙은 느린 시작, 혼잡 회피, 그리고 혼잡 감지라는 세 단계를 기반으로 한다.
- 느린 시작 단계에서 송신자는 매우 낮은 전송률로 시작하지만 임계치에 도달할 때까지 급격히 증가한다.
- 임계치에 도달하면 증가 속도를 감소시킨다.
- 마지막으로 혼잡이 감지되면, 혼잡이 감지된 정도에 따라서 느린 시작이나 혼잡 회피로 돌아간다.

10. TCP 타이머

10.1 재전송 타이머

한 세그먼트에 대한 확인 응답 기다리는 시간인 재전송 타임 아웃 RTO Retransmission TImeout 값으로 설정되는 타이머를 가지고 있다.

10.2 영속 타이머

창크기 0을 통보하는 경우 처리하기 위해 타이머가 필요하다.
수신 TCP가 창 크기 0으로 통보하였다고 가정하면, 송신 TCP는 수신 TCP로부터 0이아닌 창 크기 알리는 확인응답 수신전까지 전송 보류하고, 이러한 확인응답도 손실된 경우, 수신 TCP는 송신 TCP세그먼트를 기다릴 수 있다.
- 교착 상태가 발생한다.
이러한 교착 상태 해결 위해 각 연결마다 영속 타이머를 사용한다.
- 창 크기 0 가진 확인응답 수신하면, 송신 TCP는 영속 타이머를 구동한다.

10.3 킵얼라이브 타이머

TCP 사이에 설정된 연결이 오랜 시간 동안 휴지 상태에 있는 경우 방지하기 위해 사용된다.

10.4 시간 대기 타이머

연결 종료 동안에 사용된다.

Chapter12. 전송층 개요

ttoance — Sun, 17 May 2026 11:22:55 +0900

학습 목표

전송층의 프로세스-대-프로세스-통신을 정의하고, 이것과 네트워크층의 호스트-대호스트 통신을 비교한다.
전송층의 주소 메커니즘, 포트 번호, 그리고 여러 가지 목적을 위해 사용되는 포트 번호의 범위를 정의한다.
전송층의 패킷화 문제, 그리고 메시지의 캡슐화와 역캡슐화를 설명한다.
전송층에서 제공하는 다중화(다-대-일)와 역다중화(일-대-다)를 설명한다.
전송층에서 흐름 제어가 어떻게 동작하는지를 설명한다.
전송층에서 오류 제어가 어떻게 동작하는지를 설명한다.
전송층에서 혼잡 제어가 어떻게 동작하는지를 설명한다.
전송층의 비연결형과 연결형 서비스를 설명한다.
단순 프로토콜, 정지-대기 프로토콜, N-프레임-후퇴 프로토콜 그리고 선택적 반복 프로토콜 등 4개의 일반 전송층 프로토콜과 응용들의 동작을 설명한다.
피기배깅 방법을 이용한 전송층의 양방향 통신 방식에 대하여 설명한다.

1. 개요

전송층은 네으춰크 층과 응용층 사이에 위치한다.
전송층은 두 으용층 사이에서 프로세스-대-프로세스 통신을 제공하는데, 하나는 로컬 호스트이고 하나는 원격 호스트이다.

2. 전송층 서비스

2.1 프로세스-대-프로세스 통신

전송층 프로토콜의 첫 번째 임무는 프로세스-대-프로세스 통신을 제공하는 것이다.
네트워크층은 컴퓨터 레벨의 통신(즉, 호스트-대-호스트 통신)만 책임을 진다.
- 목적지 컴퓨터에게만 메시지를 전송한다.

2.2 주소 체계: 포트번호

가장 보편적인 방법은 클라이언트 서버 패러다임을 이용하는 것이다.
- 클라이언트라는 로컬 호스트에 있는 프로세스는 보통 서버라는 원격 호스트에 있는 프로세스로부터 제공되는 서비스를 필요로 한다.
로컬 호스트와 원격 호스트는 IP주소를 이용하여 정의된다.
프로세스를 정의하기 위해서는 포트 번호 라는 두 번째의 식별 번호가 필요하다.
TCP/IP 프로토콜 모음에서 포트 번호는 0과 65,535 사이의 정수이다.
클라이언트 프로그램은 임시 포트 번호 라는 임의의 포트 번호로 자신을 지정한다.
- 단명하며 일반적으로 클라이언트의 수명은 짧기 때문이다.
서버 포트 번호는 임의로 지정할 수 없다.
- 임의로 지정하게 된다면 서버 이용하기 원하는 클라이언트 측의 프로세스는 서버의 포트 번호를 알 수가 없다.
ICANN 범위
- 잘 알려진 포트번호 well-known port number 0~ 1023
- 등록된 포트번호 registered port number 1024 ~ 49151
  - INCANN에 의해서 배정되거나 제어되지 않는다. 중복 피하기 위해 ICANN에 등록될 수 있다.
- 동적 포트번호 dynaminc port number 49152 ~695335
  - 제어되거나 등록되지 않는다.
  - 임시 또는 사설 포트 번호로 사용될 수 있다.
소켓 주소
- IP주소와 포트 번호의 조합을 소켓 주소라고 한다.
- 클라이언트 소켓 주소는 클라이언트 프로세스를 유일하게 정의하고 서버 소켓 주소는 서버 프로세스를 유일하게 정의한다.

2.3 캡슐화와 역캡슐화

캡슐화는 전송 측에서 수행된다.
- 전송할 메시지가 있는 프로세스는 메시지와 한 쌍의 소켓 주소, 그리고 전송층 프로트콜에 필요한 정보들을 전송층으로 보낸다.
- 전송층은 수신한 데이터에 전송층 헤더를 붙인다.
- 전송층 패킷을 사용자 데이터그램, 세그먼트 , 또는 패킷이라고 한다.
역캡슐화는 수신 측에서 수행한다.
- 메시지가 목적지 전송층에 도착하면, 전송층은 헤더를 제거하고 메시지를 응용층에서 실행하는 프로세스로 전달한다.
- 수신된 메시지에 대한 응답을 보낼 경우를 대비하여 송신 측 소켓 주소가 프로세스로 전달된다.

2.4 다중화와 역다중화

개체가 여러 발신지로부터 정보 수신하는 경우를 다중화 multiplexing이라고 하며, 개체가 여러 목적지로 정보를 전달하는 경우를 역다중화 demultiplexing이라고 한다.
송신측 전송층은 다중화를 수행하며, 수신 측 전송층은 역다중화를 수행한다.

2.5 흐름 제어

하나의 개체가 정보를 생성하고 다른 개체가 정보 소비할때 생성률과 소비율 간에 균형이 이루어져야 한다.
만일 정보가 소비되는 속도보다 더 빨리 생산된다면, 소비자 측에서 데이터 과도하게 수신되게 되어 정보의 일부가 손실될 수 있다.
- 흐름 제어(flow control)
생성되는 정보가 소비되는 속도보다 더 늦다면, 소비자 측은 정보의 수신을 기다리게 되어 시스템의 효율성이 떨어진다.
밀기와 끌기
- 정보를 생산자에서 보시자로 전달하는 방법은 밀기와 끌기 중 하나로 이루어질 수 있다.
- pushing : 소비자의 요청 없이 정보가 생성될 때마다 전송 측에서 정보를 전달하는 경우
  - 흐름 데어가 필요하다.
- pulling : 소비자가 요청한 경우에만 생성자가 정보 전달하는 경우
  - 흐름 제어가 필요하지 않다.
전송층에서의 흐름 제어

버퍼
- 흐름 제어의 여러가지 방법 중, 일반적인 방법은 버퍼를 두는 것이다.
- 송신 전송층에 하나, 그리고 수신 전송층에 하나 등 2개의 버퍼를 이용할 수 있다.
- 버퍼는 송신 측과 수신 측에서 패킷을 저장할 수 있는 메모리 영역이다.
- 소비자에서 생산자로 신호를 전송하는 경우에 흐름 제어 기반의 통신이 이루어진다.

2.6 오류 제어

인터넷에서는 네트워크층이 신뢰성을 제공하지 않기 때문에, 응용층에서 신뢰성을 요구하는 경우에 전송층에서 신뢰성을 제공할 수 있어야 한다.
신뢰성은 전송층에 오류 제어 서비스를 추가함으로써 제공할 수 있다.
- 훼손된 패킷의 감지 및 폐기
- 손실되거나 제거된 패킷을 추적하고 재선종
- 중복 수신 패킷을 확인하고 폐기
- 손실된 패킷이 도착할 때까지 순서에 어긋나게 들어온 패킷을 버퍼에 저장
순서 번호
- 패킷의 순서 번호를 저장할 수 있또록 전송층 패킷에 한 필드를 추가해야한다.
- 어떤 패킷이 중복되었는지 또는 순서가 어긋나게 도착하는지 알 수 있다.
확인응답
- 오류 제어를 위하여 긍정과 부정 신호를 모두 사용할 수 있다.
- 수신 측에서는 오류 없이 잘 수신된 패킷들에 대해서 확인응답을 전송할 수 있다.
- 수신 측은 훼손된 패킷을 단순히 버린다.
- 송신 측에서는 타이머를 사용해서 패킷의 손실을 감지한다.
  - 패킷 전송한 후 송신 측은 타이머 구동하고, 타이머 만료되기 전까지 ACK가 도착하지 않으면 송신 측은 패킷을 재전송한다.

2.8 혼잡 제어

전송되는 패킷의 수를 나타내는 네트워크의 로드가 네트워크의 처리할 수 있는 패킷의 수를 넘어가는 경우에 혼잡이 발생한다.
- 혼잡은 라우터나 스위치가 패킷을 저장하기 위한 버퍼나 큐를 가지고 있기 때문에 발생한다.
혼잡 제어는 혼잡이 일어나지 않도록 사전에 방지하거나, 또는 만일 발생하면 호납을 제거하기 위한 기술과 메커니즘을 말한다.
개방 루프 혼잡 제어
- 혼잡을 사전에 방지하기 위한 정책들이 적용된다.
재전송 정책
창 정책
- 선택적 반복 selective-repeat 창 방식과 N-프레임-후퇴 go-back-N창 방식
확인응답 정책
- 수신 측에서 자신이 전송할 패킷이 있거나 또는 특정 타이머가 만료되는 경우에
- 혹은 한번에 N개의 패킷에 대해 확인 응답 처리
폐 루프 혼잡 제어
- 혼잡이 발생한 후에 혼잡을 완화시키기 위한 방식
- 혼잡이 발생하면 창의 크기를 조절한다.

2.9 비연결형과 연결형 서비스

비연결형 서비스
- 패킷은 순서에 어긋나게 목적지에 도착할 수 있다.
- 동일한 메시지에 속하는 서로 다른 데이터그램이 서로 다른 경로를 겹칠 수 있다.
- 흐름 제어나 오류 제어 또는 혼잡 제어가 구현될 필요가 없다.
연결형 서비스
- 클라이언트와 서버는 먼저 연결을 설정하고 데이터 교환은 연결이 설정된 이후에 가능하다.
- 데이터 교환이 완료된 후에야 연결은 해제된다.

3. 전송층 프로토콜

3.1 단순 프로토콜

흐름 제어나 오류 제어가 없다.
이 프로토콜에서는 수신 측은 수신한 패킷을 즉시 처리할 수 있다고 가정한다.

3.2 정지-후-대기 프로토콜

흐름 제어와 오류 제어를 모두 제공한다.
송신 측과 수신 측은 모두 크기가 1인 미닫이 창을 사용한다.
송신 측은 한번에 하나의 패킷을 전송하고 확인응답이 오기 전까지는 다음 패킷을 전송하지 않는다.
패킷이 훼손되었는지 검사하기 위해 각 게이터 패킷에 검사합을 추가한다.
송신 측은 패킷을 전송할 때마다 타이머를 구동한다.
- 타이머가 만료되기 전에 확인응답이 도착하면, 타이머는 정지되고 송신측은 다음 패킷을 전송한다.
- 만일 타이머가 만료되면, 송신측은 패킷이 손실되거나 훼손되었다고 간주하고 패킷을 재전송한다.

3.3 N-프레임-후퇴 프로토콜

전송 효율을 향상시키기 위해서는 송신 측은 확인 응답을 기다리는 동안에 여러 개의 패킷을 전송할 수 있어야 한다.
N-프레임-후퇴 프로토콜은 확인응답을 수신하기 전에 여러 개의 패킷을 전송할 수 있다.

3.4 선택적 반복 프로토콜

N-프레임-후퇴 프로토콜은 하부의 네트워크 프로토콜에서 많은 패킷이 손실될 때마다 비효율적이다.
- 하나의 패킷이 손실되거나 훼손될 때마다, 송신 측은 모든 미해결 패킷들을 재전송한다.
선택적 반복 프로토콜은 손실된 패킷만 선택적으로 재전송된다.

3.5 양방향 프로토콜 : 피기백킹

앞에서 설명한 네 개의 프로토콜은 모두 단방향이다.
피기백킹 이라는 기술은 양방향 통신의 효율을 향상시키기 위해 사용된다.
- A에서 B로 데이터 전달하는 패킷은 또한 B로부터 수신한 패킷에 대한 확인응답과 관련된 피드백 정보도 같이 전달할 수 있다.
- 마찬가지로 B에서 A로 전달하는 패킷에도 A로부터 수신된 패킷에 대한 확인응답과 관련된 피드백 정보도 같이 전달할 수 있다.

Chapter7~8. 페킷 헤더 확인과 덤프 분석 / 근거리 통신망: 유선 이더넷

ttoance — Fri, 1 May 2026 12:25:04 +0900

Chapter7. 패킷 헤더 확인과 덤프 분석

1.3 Frame, Ethernet , 패킷, 세그먼트 헤더

Frame 부분은 와이어샤크에 의해 생성된 메타데이터 부분이다. 실제 프레임은 Ethernet 부분 부터 시작된다.
Frame은 매체 접근 제어 헤더부터 MAC 트레일러까지이다.
Ethernet은 실제 프레임으로 프레임의 시작과 종료를 정확하게 알 수 있다.
패킷 Packet 은 프레임에 캡슐화되어 있는 내용으로 TCP/IP 통신에서 패킷IP 헤더에서 시작해서 프레임의 트레일러 바로 앞까지이다.
세그먼트는 Transmission Control Protocol 헤더에서 시작되는 내용이다.
세그먼트는 HTTP와 같은 응용층 헤더와 데이터를 포함한다.

2. 덤프 분석

Chatper8. 근거리 통신망: 유선 이더넷

근거리통신망(LAN : Local Area Network) 은 빌딩이나 대학과 같은 지역적으로 제한된 지역에서 독립적인 장치들이 서로 통신할 수 있게 하는 데이터 통신 시스템이다.
오늘날의 LAN들은 대부분 광역 통신망(WAN : Wide Area Network)이나 인터넷에 연결되어 있다.

1. IEEE 표준 인터넷

Ethernet 은 원래 무선 통신을 전제로 했기 때문에 하나의 주파수로 통신할때눈 무전기처럼 누군가가 이야기하고 있는 동안에 다른 사람은 수신만 할 수 있다.
- 이것은 CSMA/CD(반송파 탐지 다중 접속/충돌 검출)방식이라 불리며, 송신 또는 수신을 한쪽만 하는 반이중 데이터 통신에서 이용되고 있다.
논리 링크 제어 (LLC)
- 흐름 제어, 오류 제어와 프레임 생성 일부분에 대한 역할을 논리 링크 제어라는 하나의 부계층에서 처리한다.
- 프레임 생성은 LLC 부계층과 MAC 부계층 양쪽에서 모두 처리한다.
매체 접근 제어 (MAC)
- 각각의 LAN을 위한 특별 접근 방법인 매체접근제어 만들었다.
  - ex, 이더넷 LAN을 위한 매체 접근 방식으로써 CSMA/CD를 정의하고, 토큰 링이나 토큰 버스 LAN을 위해 토큰 패싱 방식을 정의하였다.

2. Ethernet 프레임 형식

Ethernet은 데이터 링크층 프로토콜이다.
6개의 필드로 구성되어 있다.
- 프리엠블 preamble : 시스템에 들어오는 프레임을 수신하게 하고, 입력 타이밍을 맞추게 한다.
- 목적지 주소 destination address
- 발신지 주소 source address
- 이더넷 유형 ether type
- 데이터 data
- 프레임 확인 순서 frame check sequence

Chapter4.IP주소

ttoance — Sun, 12 Apr 2026 08:50:21 +0900

학습 목표

일반적인 주소 공간 개념과 특정한 경우의 IPv4 주소 공간 개념을 소개한다.
클래스 기반 구조와 각 클래스에서 사용 가능한 블록에 대해 설명한다.
계층적 주소지정 개념과 클래스 기반 주소지정 시스템에서 이의 구현에 대해 설명한다.
클래스 기반 구조를 위한 서브넷팅과 슈퍼넷팅에 대해 설명하고, 이들이 클래스 기반 주소지정의 단점을 어떻게 해결하는지 살펴본다.
주소 공간 고갈과 같은 클래스 기반 주소지정의 문제를 해결하기 위해 고안된 새로운 구조인 클래스 없는 주소지정에 대해 설명한다.
클래스 기반 주소지정에서 적용한 서브넷팅 아이디어가 클래스 없는 주소지정에서 어떻게 쉽게 구현될 수 있는지 설명한다.
특수 블록과 각 블록의 특수 주소를 설명한다.
NAT 기술을 설명하고 이 기술을 이용하여 IPv4의 주소 부족 문제를 어떻게 완화시킬 수 있는지 설명한다.

1. 개요

인터넷에 연결되어 있는 각 장치를 구별하기 위해 TCP/IP 프로토콜 모음의 IP 계층에서 사용하는 식별자를 인터넷 주소 또는 IP 주소 라고 한다.
IPv4 주소는 32비트 주소로서 인터넷에 있는 호스트나 라우터의 연결을 전 세계적으로 유일하게 나타낸다.
- 유일하다는 것은 각 주소는 인터넷에서 오직 한 개의 연결만 지정한다는 것을 의미한다.
- 인터넷에서 어떤 장치가 두 개의 네트워크와 연결되어 있다면, 두 개의 IPv4주소를 갖는다.

1.1 주소

IPv4는 32비트 주소를 가지므로 주소공간은 2의 32승이고 4,294,967,296이고 이는 40억 개 이상이다.

1.2 표기법

2진 표기법, 점 10진 표기법, 16진 표기법이 있고 가장 많이 사용되는 방법은 기수 256 표기법이다.
- 2진 표기법 예시: 11000000 10101000 00000000 00000001 (32비트 IPv4 주소 예시)
- 점 10진 표기법: 192.168.0.1 (기수 256 표기법)
- 16진 표기법 예시: C0 A8 00 01 (위의 2진수를 16진수로 변환한 값)

2. 클래스 기반 주소지정

처음부터 IP 주소는 클래스 개념을 사용했다.
1990년대 중반에 새로운 구조가 등장하였는데, 이를 클래스 없는 주소지정 이라고 한다.

2.1 클래스

클래스 기반 주소지정에서 IP 주소 공간은 다섯 개의 클래스 (A, B, C, D, E)로 나누어진다.

클래스 기반 주소지정에서 클래스 A, B, C의 IP주소는 네트워크를 구분하는 netid와 hostid로 나누어진다.

2.2 클래스와 블록

클래스 기반 주소지정에서 발생하는 한 가지 문제점은 각 클래스가 정해진 수의 블록으로 나뉘고 각 블록의 크기는 고정되어 있다는 점이다.
- 클래스 A는 2의 7승 128개의 기관에 할당될 수 있다.
- 클래스 B는 2의 14승 16,384개의 블록으로 나뉘어지고 할당될 수 있다.
  - 각 기관은2의 16승 65,536개의 주소를 포함하게된다.
- 클래스 C는 2의 21승 2,097,152 블록으로 나누어지고 각 블록은 256개의 주소를 포함하게 된다.

2.3 2계층 주소지정

네트워크 주소
- 네트워크 주소인 첫 주소는 목적지 주소로 패킷을 전송하는데 사용되므로 매우 중요하다.
- 네트워크 주소는 실제로 네트웤의 식별자이다.
네트워크 마스크
- 인터넷 내의 라우터는 패킷의 목적지 주소에서 네트워크 주소를 추출하기 위하여 보통 알고리즘을 사용한다.
- n개의 왼쪽 비트는 1이고 (32-n)개의 오른쪽 비트는 0인 32비트 수이다.

2.4 3계층 주소지정 : 서브넷팅

클래스 A나 B블록을 받은 조직은 보안과 관리를 잘 할 수 있도록 네트워크를 몇 개의 서브네트워크로 나눌 필요가 있었다.
클래스 A와 B의 블록은 이미 거의 소진되었으나 클래스 C 블록은 대부분의 조직이 필요로 하는 크기보다 작으므로 클래스 A나 클래스 B블록을 받은 조직은 블록을 더 작은 서브 블록으로 나누어 다른 조직들과 공유할 수가 있었다.
- 블록을 작은 블록으로 나누는 개념을 서브넷팅이라고 한다.
서브넷 마스크
- 네트워크 마스크는 넥트워크가 서브넷팅하지 않을 때 사용한다.
- 네트워크를 몇 개의 서브넷으로 나눌 경우 서브넷에 대해여 서브넷 마스크를 생성할 필요가 있다.

2.5 슈퍼넷팅

클래스 C 블록의 크기는 인터넷에 연결하기 원하는 조직의 요구사항을 만족시키기에 충분하지 않아서 슈퍼넷팅이라는 해결책이 도입하였다.
슈퍼넷팅을 사용함으로써, 기관은 큰 범위의 주소를 생성하기 위해 몇 개의 클래스 C 블록을 결합할 수 있었다.
슈퍼넷 마스크
- 서브넷 마스크의 반대로 클래스 C에서 서브넷 마스크는 디폴트 마스크보다 1의 개수가 더 많다.

3. 클래스 없는 주소지정

클래스 기반 주소지정 방식에서 서브넷팅과 슈퍼넷팅은 주소 고갈 문제를 해결하지 못했으며 주소의 배분이나 경로 설정 과정이 더 복잡하게 되었다.
IPv6라는 긴 주소 공간을 확보하는 장기적인 해결책도 제공했지만, 동일한 주소 공간 사용하면서 기관들에게 균등하게 배분할 수있도록 하는 단기적인 해결책도 제시되었다.

3.2 2단계 주소 체계

술래시 표기법
- 클래스 없는 주소지정 방식에서 주소의 블록을 알기 위해서 프리픽스 길이 정보가 주소 정보에 포함되어야 한다.
- 주소 옆에 슬래시(/)로 구분되어 추가되어야한다.
- 공식적으로는 CIDR 클래스 없는 도메인 간 라우팅 표기법 이라고 한다.
네트워크 마스크
- 32비트로 구성되며, 왼쪽부터 n개의 연속적인 비트는 1로 설정되고 그 나머지 비트는 0으로 설정한다.

3.3 블록 할당

블록 할당에 대한 임무는 ICANN Internet Corporation for Assigned Names and Address 라는 국제 관리 기구에서 수행한다.
ICANN은 대용량의 주소 블록을 ISP에게 할당한다.

4. 특수 주소

4.1 특수 블록

모두-0인 주소
- 하나의 단일 주소로 표현되는 0.0.0.0/32 블록은 IPv4 패킷을 전송하고자 하는 호스트가 자신의 IPv4 주소를 모르는 경우에 통신을 위하여 사용된다.
- 호스트는 자신의 주소를 알기 위하여 이 주소를 발신지 주소로 설정하고 목적지 주소로 제한된 브로드캐스트 주소로 설정한 IPv4패킷을 부트스트랩 서버로 전송된다.
모두-1인 주소 : 제한된 브로드케스트 주소
- 현재 네트워크 내의 제한된 브로드캐스트 주소로 예약되었다.
  - 네트워크 내의 모든 호스트에게 메시지를 저송하고자 하는 호스트는 이 주소를 IPv4 패킷의 목적지 주소로 사용한다.
루프백 주소
- 127.0.0.0/8 블록은 루프백 주소로 사용된다.
- 루프백 주소는 컴퓨터에 설치된 소프트웨어를 시험하기 위하여 사용되는 주소이다.
- 컴퓨터 외부로 전송되지 않고 프로토콜 소프트웨어로 보낸다.
- 또 다른 예로, 루프백 주소는 클라이언트 프로세스가 동일한 컴튜너에 있느 서버 프로세스로 메시지 전송할 때 사용한다.
사설 주소
- 일반 가정이나 기업 내부 네트워크에서 기기들을 식별하기 위해 사용하는 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 가정용 공유기, 소규모 사무실
멀티캐스트 주소
- 224.0.0.0/4 블록은 멀티캐스트 통신 위하여 예약된 블록

4.2 각 블록에서 사용되는 특수 주소

네트워크 주소
- 네트워크 주소는 특정 네트워크 그 자체를 대표하는 이름과 같습니다.
- 구조: IP 주소의 호스트 부분(Host ID)이 모두 비트 0으로 채워진 상태입니다.
- 용도: 라우터가 데이터를 어디로 보낼지 결정하는 '라우팅 테이블'에서 특정 네트워크 범위를 식별하는 용도로 사용됩니다.
- 특징: 실제 컴퓨터(호스트)나 장비에 이 주소를 할당할 수 없습니다.
직접 브로드캐스트 주소
- 특정 네트워크에 속한 모든 호스트에게 동시에 데이터를 전송하기 위해 사용되는 주소입니다.
- 구조: IP 주소의 호스트 부분(Host ID)이 모두 비트 1로 채워진 상태입니다.
- 용도: 외부 네트워크에서 특정 내부 네트워크의 모든 기기에게 메시지를 뿌릴 때 사용합니다.
- 특징: 네트워크 주소와 마찬가지로 일반 PC나 서버에 할당할 수 없습니다.

5. IPv6 주소

IPv4주소 길이의 4배로 128비트 또는 16바이트 길이이다.

5.1 표기법

점 10진 표기법
- 길이가 길어져서 IPv6에는 사용되지 않는다.
콜론 16진 표기법
- 128비트를 16비트씩 8개 블록으로 나누고, 각 블록을 16진수로 표기한 뒤 콜론(:)으로 구분한다.
- 3ffe:1900:4545:0003:0200:f8ff:fe21:67cf
혼합 표기법
- 앞의 96비트는 IPv6 형식(보통 16진수)으로, 뒤의 32비트는 익숙한 IPv4의 점 10진 표기법으로 씁니다.
- 예시: ::ffff:192.168.10.2
CIDR 표기법
- 구조: 주소/프리픽스 길이
- 예시: 2001:db8::/32 (앞의 32비트가 네트워크 식별자)

5.2 주소 공간

2의 128승이고, IPv4 주소의 2의 96승 배이다. (절대로 주소가 고갈되지 않는다.)

5.3 세 가지 주소 유형

ipv6에서 목적지 주소는 유니캐스트, 에니캐스트, 멀티캐스트라는 세 가지 범주 중 하나에 속해있다.
유니캐스트 주소
- 단일 인터페이스를 정의한다.
- 유니캐스트 주소로 보내진 패킷은 특정 수신자로 전달된다.
애니케스트 주소
- 단일 주소를 모두 공유하는 컴퓨터 그룹을 정의한다.
- 애니케스트 주소를 가진 패킷은 가장 접근이 쉬은 그룹의 멤버 중 하나에게만 전달한다.
멀티케스트 주소
- 멀티캐스팅은 그룹의 각 멤버가 복사본을 수신받는다.

6. IPv6 주소 공간 할당

Chapter3. 네트워크층 개요

ttoance — Sun, 29 Mar 2026 08:28:26 +0900

학습 목표

- 교환(switching)과 네트워크층의 데이터 전달 메커니즘인 패킷 교환을 소개한다.

- 패킷 교환망이 제공하는 연결형 서비스와 비연결형 서비스를 설명한다.

- 비연결형 패킷 교환망에서 패킷의 목적지 주소와 라우팅 테이블을 사용하여 라우터가 패킷을 전달하는 과정을 설명한다.

- 연결형 패킷 교환망에서 패킷의 레이블과 라우팅 테이블을 사용하여 라우터가 패킷을 전달하는 과정을 설명한다.

- 논리 주소 체계와 발신지, 각 라우터, 그리고 목적지로 전달 등과 같이 네트워크 층에서 제공되는 서비스에 관해 설명한다.

- 네트워크층에서는 직접 제공되지는 않지만, 간혹 보조 프로토콜이나 인터넷에 이후 추가될 프로토콜에 의해 제공되는 서비스에 대해 설명한다.

1.개요

- 개념적인 수준에서 인터넷은 수백만 대의 컴퓨터를 연결하는 블랙박스 네트워크로 생각할 수 있다.

ㄴ 그러나 인터넷은 하나의 네트워크로 구성된 것이 아니고 연결 장치 통하여 연결된 수많은 네트워크 (또는 링크)로 구성된다.

- 이 모델에서 라우터와 같은 연결 장치는 교환기로서 동작한다.

ㄴ 패킷이 라우터의 한 포트에 도착하면 이 패킷은 다른 포트 통하여 다음 교환기로 전달된다.

2. 교환

연결 장치는 한 포트를 다른 포트에 연결하는 교환기 역할을 한다.

2.1 회선 교환

- 교환에 대한 한 가지 해결책은 회선 교환 (circuit switching) 이라고 한다.

- 회선 교환에서는 메시지 전달 전에 발신지와 목적이 사이에 물리 회선이 생성된다.

- 회선이 생성된 후 전체 메시지가 발신지에서 목적지로 전달된다.

- 발신지는 메시지 전달이 완료되면, 이를 네트워크에 통보해서 네트워크가 다른 연결 위해 사용할 수 있게 한다.

- 회선 교환은 네트워크 층에는 구현되지 않고 대부분 물리층에서 사용된다.

2.2 패킷 교환 packet switching

- 오늘날 인터넷의 네트워크층은 패킷 교환망이다.

- 이 네트워크에서는 상위 계층의 메시지가 관리 가능한 크기의 패킷(datagram)으로 분할되고 각 패킷이 네트워크를 통하여 전달된다.

- 메시지 발신지는 패킷을 한개씩 송신하고 목적지는 패킷을 한 개씩 수신한다.

- 목적지는 같은 메시지에 속하는 모든 패킷이 도착하면, 메시지를 상위 계층으로 전달한다.

- 패킷 교환망의 연결 장치는 패킷을 최종 목적지까지 어떻게 보낼지 결졍해야 한다.

3. 네트워크층에서의 패킷 교환

인터넷의 패킷 교환 네트워크층은 원래 비연결형 서비스로 설계되었으나 최근에 연결형 서비스로 전환되고 있는 추세이다.

3.1 비연결형 서비스

- 인터넷이 시작되었을 때 네트워크층은 비연결형 서비스를 제공하도록 설계되었는데 이 서비스에서 네트워크층은 각 패킷을 상호 독립적으로 다룬다.

- 한 메시지 내의 패킷은 목적지까지 같은 경로로 전송될 수도 있고 아닐 수도 있다.

- 이 네트워크 내의 교환기를 라우터 라고 한다.

- 각 패킷은 헤더에 속한 정보인 발신지 주소와 목적지 주소를 기반으로 전달된다.

3.2 연결형 서비스

- 연결형 서비스에서 한 메시지에 속한 모든 패킷 사이에는 관계성이 있다.

- 한 메시지에 속한 모든 데이터그램이 송신되기 전에 데이터그램의 경로를 나타내는 가상 회선 virtual circuit 이 생성되어야 한다.

- 연결이 생성된 후 데이터그램은 같은 경로를 따라 전달된다.

- 연결형 서비스의 경우 패킷은 발신지 주소, 목적지 주소와 함께 패킷이 전달되는 가상 회선을 지정하는 가상 회선 식별자 virtual circuit identifier 인 흐름 레이블 flow label 도 가지고 있어야 한다.

- 연결형 서비스를 생성하기 위해 연결 과정 setup, 데이터 전송 data transfer과 연결 해제 teardown로 구성된 세 단계 과정이 사용된다.

3.2.1 설정 단계 setup phase

- 라우터는 가상 회선을 위한 엔트리를 생성한다.

3.2.2 데이터 전송 과정 data transfer

- 모든 라우터는 특정 가상 회선을 위한 라우팅 테이블을 생성한 후 하나의 메시지에 속한 네트워크층 패킷을 순서대로 전송한다.

- 메시지 내의 모든 패킷은 목적지에 도달할 때까지 같은 레이블 순서를 따른다.

- 패킷은 목적지에 순서대로 도달한다.

3.2.3 연결 해제 과정 teardown phase

- 발신지 A가 B에게 모든 패킷을 보낸 후 해제 패킷이라는 특별한 패킷을 보낸다.

- 목적지 B는 확인 패킷으로 응답한다.

- 모든 라우터는 자신의 테이블에서 해당하는 엔트리를 삭제한다.

4. 네트워크층 서비스

인터넷에서 주로 사용되는 비연결형 서비스를 기반으로 한다.

4.2 논리 주소 체계

- 네트워크층은 종단-대-종단 통신을 제공하므로 상호 통신하는 두 컴퓨터는 네트워크층 주소 또는 놀리 주소라는 인터넷 공통의 식별자 시스템이 필요하다.

- 이 유형의 식별자 시스템은 전역 주소 시스템을 통하여 네트워크층에서 제공된다.

- 인터넷을 사용하는 각 개체는 모든 주소 공간에서 유일한 주소를 할당받는다.

4.3 발신지 컴퓨터에서 제공되는 서비스

- 발신지 컴퓨터의 네트워크층에서는 네 가지 서비스를 제공하는데, 이는 패킷화, 다음-홉 논리 주소 찾기, 다음-홉 물리 주소 찾기, 필요한 경우 데이터그램 단편화이다.

1) 패킷화

- 네트워크층의 첫 번째 임무는 상위 계층으로부터 받은 데이터를 데이터그램으로 패킷화하는 것이다.

- 이 과정에서 데이터에 패킷 발신지와 목적지 논리 주소, 단편화 정보, 서비스를 요청한 프로토콜의 ID, 데이터 길이를 포함하는 헤더를 추가한다.

- 데이터그램 헤더만을 대상으로 계산된 검사합도 포함한다.

2) 다음 홉의 논리 주소 찾기

- 준비된 데이터그램은 패킷의 발신지와 목적지 주소를 가지고 있다.

- 데이터그램은 최종 목적지에 도달하기 위하여 여러 네트워크를 통과해야 한다.

- 목적지 컴퓨터가 발신지와 같은 네트워크에 연결되어 있지 않으면 데이터그램은 다음 라우터로 전달해야 한다.

- 데이터그램의 발신지 주소와 목적지 주소로는 다음 홉의 논리 주소를 알지 못하고 발신지 컴퓨터의 네트워크층은 라우팅 테이블을 참조하여 다음 홉의 논리 주소를 찾아야 한다.

3) 다음 홉의 MAC 주소 찾기

- 네트워크층은 실제로 데이터그램 전달하지 않고 데이터 링크층에 전달을 맡기는데 전달 위해 MAC 주소가 필요하다.

- 다음 홉의 MAC 주소를 찹기 위하여 또 다른 테이블을 사용하여 다음 홉의 논리 주소를 MAC 주소로 변환해야 한다.

- 이 임무는 ARP Address Resolution Protocol 을 사용하는데 ARP로 논리 주소를 받아 다음 홉의 MAC 주소를 알려준다.

4) 단편화

- 데이터그램은 아직 데이터 링크층에 전달될 수 없을 수도 있다.

ㄴ 대부분의 LAN과 WAN은 한 프레임에 전달할 수 있는 최대 데이터 크기를 가지고 있고 이 크기를 최대 전송 단위 MTU 라고 한다.

- 네트워크층에 준비된 데이터그램이 MTU 보다 큰 경우 단편화 과정이 이루어진다.

- 단편화 과정에서도 헤더은 같은 내용이어야 한다.

4.5 목적지 컴퓨터에서 제공되는 서비스

- 목적지 컴퓨터의 네트워크층은 간단하다.

ㄴ 전달은 더이상 필요없으나 목적지 컴퓨터는 데이터를 목적지에 전달하기 전에 단편들을 조립할 필요가 있다.

- 각 데이터그램의 유효성을 검증한 후 각 단편에서 데이터 추출하고 저장된다.

- 네트워크층은 재조립 타이머를 설정한다.

- 만약 타이머가 만료되면 모든 데이터 단편은 폐기되고 모든 단편을 재전송해야 한다는 오류 메시지가 전송된다.

5. 네트워크층 문제점들

5.1 오류 제어 error control

- 오류 제어란 훼손되거나 손실되거나 중복한 데이터그램을 탐지하는 메커니즘을 호맣하는 것을 의미한다.

ㄴ 오류를 탐지한 후 수정하는 메커니즘도 포함한다.

- 인터넷에서 네트워크층은 오류 제어 메커니즘을 제공하지 않는다.

- 직접 오류 제어는 제공하지 않지만 인터넷은 ICMP라는 프로토콜 이용해서 데이터그램이 폐기되거나 헤더 내에 알려지지 않은 정보가 포함되는 경우 이에 대한 오류 제어 할 수 있는 메커니즘을 제공한다.

5.2 흐름 제어 flow control

- 수신자의 수신 능력을 초과하지 않도록 발신지의 데이터 전송 양을 조절한다.

- 인터넷의 네트워크층은 직접 흐름 제어를 제공하지 않는다.

5.3 혼잡 제어 congestion control

- 혼잡이란 인터넷 내부에 데이터그램이 너무 많이 존재하는 상황이다.

- 발신지 컴퓨터에 의해 송신된 데이터그램의 수가 네트워크나 라우터의 용량을 넘는 경우 혼잡이 발생한다.

ㄴ 이 경우 일부 라우터는 데이터그램의 일부를 폐기할 수 있다.

- 그러나 더 많은 데이터그램이 폐기될 수록 상위 계층의 오류 제어 메커니즘에 의해 송신자가 분실된 패킷을 중복하여 송신하게 되므로 상황은 더 약화될 수 있다.

- 비연결형 네트워크에서의 혼잡 제어

ㄴ 해결책 중의 하라는 신호방식 signaling 이다.

ㄴ 후향 신호방식 backward signaling 에서는 혼잡이 발생한 방향과 반대 방향으로 전달되는 데이터그램 내의 한 비트를 1로 설정하여 송신자에게 혼잡이 발생하였음을 알리고 송신자가 패킷을 전송하는 속도를 낮추도록 한다.

- 연결형 네트워크에서 혼잡 제어

ㄴ 설정 과정에서 진보된 협상 advanced negotiation

ㄴ 가상 회선 설정할 때 송신자와 수신자는 트래픽 수준을 합의할 수 있다.

5.4 서비스 품질

- 가능하면 네트워크층을 수정하지 않기 위해 서비스 품질 QOS 은 상위 계층에 구현되어있다.

Chapter2. OSI 모델과 TCP/IP 프로토

ttoance — Sat, 21 Mar 2026 08:55:15 +0900

학습 목표

- 데이터 통신과 네트워킹, 그리고 계층 간의 상호 관계에서 다중 계층구조에 대한 개념을 알게 된다.

- OSI 모델과 계층구조, 계층 간의 인터페이스를 알게 된다.

- OSI 모델에서 각 계층의 기능을 알게 된다 .

- TCP/IP를 소개하고, TCP/IP 계층과 OSI 모델에서 해당 계층을 비교할 수 있다.

- 몇 가지 예를 통해서 TCP/IP 프로토콜의 각 계층의 기능을 알게 된다.

- 발신지에서 목적지까지 메시지 전달을 위한 TCP/IP 프로토콜의 일부 계층에서 사용하는 주소지정 메커니즘을 알게 된다.

- 와이어샤크는 근거리통신망 LAN 을 통해서 전달되는 패킷을 캡처해서 분석하는 도구이다.

ㄴ 패킷이란 네트워크에 접속되어 있는 컴퓨터끼리 통신 통하여 주고받는 데이터 단위를 말한다.

ㄴ 이 데이터는 약속에 따라 작성되고, 정해진 약속에 따라 송/수신된다.

- 서로 떨어져 있는 컴퓨터끼리 서로 제멋대로 데이터를 보낸다면 통신은 성립되지 않는다.

- 1990년대 이전까지는 데이터 통신과 네트워크에 대한 계층 모델은 개방 시스템 상호연결 모델이었다. (OSI 모델)

- TCP/IP 프로토콜은 인터넷에서 광범위하게 시험을 거쳐서 사용되어 왔기 때문에 지배적인 상업적 구조가 되었으나 OSI 모델은 완전히 구현되지 않았다.

1. 프로토콜 계층구조

1.1 계층 구조

- 여기서 중요한 것은 임무가 계층구조에 주어진 순서대로 행해져야 한다는 것이다.

- 송신 측에서, 편지가 작성되어, 암호로 변환되고, 편지 운반자가 전달하기 전에 우체통에 넣어서 우체국으로 전달된다.

1.2 서비스

- 송신 측에 있는 각 계층은 자신의 아래에 있는 계층의 서비스를 이용한다.

- 위 계층에 있는 송신자는 중간 계층의 서비스를 이용한다.

- 중간 계층은 하위 계층의 서비스를 이용한다.

2. OSI 기본 참조 모델

- 1974년에 설립된 국제표준화기구는 세계적으로 인정받는 국제 표준을 제정하는 다국적 기관이다.

- 네트워크 통신을 전체적으로 다루고 있는 ISO 표준은 OSI 기본 참조 모델이다.

- 개방 시스템(Open System)은 기반 주고와 관계없이 서로 다른 시스템 간의 통신을 제공하는 프로토콜의 집합니다.

ㄴ OSI 모델은 하드웨어나 소프트웨어 기반의 논리적인 변화에 대한 요구 없이 서로 다른 시스템 간의 통신을 원활하게 하는 데 목적이 있다.

2.1 계층화된 구조

- 물리층, 데이터 링크층, 네트워크층, 전송층, 세션층, 표현층, 응용층으로 구성되어 있다.

- 장치 A에서 장치 B로 전송될때 관련되는 계층을 보여주고 있다.

- 메시지가 A에서 B로 전송되는 도중에 많은 중간 노드를 거칠 수 있다.

ㄴ 이 중간 노드는 항상 OSI 모델의 처음 3계층만 이용한다.

2.2 계층-대-계층 통신

1) 계층 간 인터페이스

- 데이터와 네트워크 정보가 송신 장치의 각 계층을 따라 전달되고, 다시 수신 장치의 각 계층을 따라 올라가는 것은 인접한 계층 간의 인터페이스를 통해 이루어진다.

- 각 인터페이스는 한 계층이 바로 위의 계층에게 제공해야 하는 정보와 서비스를 정의한다.

- 한 계층이 바로 위의 계층으로 미리 정의된 서비스를 제공한다면, 다른 계층을 전혀 바꾸지 않고도 그 계층의 기능을 구현하는 방식을 변경하거나 대체화할 수 있다. => 모듈화 가능

2) 계층의 구성

- 7개의 계층은 3개의 그룹으로 나눌 수 있다.

- 제 1,2,3 계층은 물리층, 데이터 링크층, 네트워크층으로 한 장치에서 다른 장치로 데이터 전송할 때 필요한 물리적인 면(전기적인 규격, 물리적인 연결, 물리 주소, 전송 시간과 신뢰도 등)을 처리한다.

- 제 5,6 계층인 세션층, 표현층, 응용층은 사용자 지원 계층으로 서로 관련이 없는 소프트웨어 시스템 간의 상호 연동을 가능하게 한다.

- 전송중인 제 4계층은 두 그룹을 연결하고, 하위 계층에서 전송한 내용을 상위 계층이 사용할 수 있는 형태가 되도록 보장한다.

2.3 캡슐화

- 제 7계층의 패킷은 제6계층의 패킷으로 캡슐화한다.

- 제 6계층의 패킷은 제 5계층의 패킷으로 캠슐화된다.

- 즉, 제 N계층의 전체 패킷은 N-1계층 패킷의 데이터 부분으로 전송된다.

ㄴ N-1계층은 캡슐화된 패킷의 데이터인지 헤더 또는 트레일러인지 모르기 때문에 캡슐화라고 한다.

2.4 OSI 모델의 계층 구조

1) 물리층 physical layer

- 물리 매체 통하여 비트 스트림을 전달하는 데 필요한 기능들을 조정한다.

- 물리층은 장치와 전송 매체 간에 인터페이스의 특성을 규정한다.

- 물리층 데이터는 해석되지 않은 비트 스트림으로 구성되어 있다.

- 전송률도 물리층에서 규정된다.

- 송신자와 수신자는 같은 비트율을 사용할 뿐만 아니라 비트 레벨에서 동기화되어야 한다.

- 회선 구성을 구성한다. ex, 점대점, 다중점 ..

- 물리적 접속형태를 규정한다. ex, 그물형 접속형태, 성형 접속형태, 링형 접속형태, 버스형 접속형태

- 전동모드를 규정한다 ex, 단방향 모드, 반이중 모드, 전이중 모드

2) 데이터 링크층 data link layer

- 물리층에 있는 전송 설비를 신뢰할 수 있는 링크로 변환한다.

- 비트 스트림을 프레임이라는 데이터 단위로 나눈다.

- 프레임의 송신자/수신자를 지정하기 위해 프레임에 해더를 더한다.

- 데이터 전송률을 조정한다. (흐름 제어)

- 손상되고 손될된 프레임을 탐지한다. (오류 제어)

- 둘 또는 그 이상의 장치가 같은 링크에 연결되어 있을때 제어권을 결정한다. (접근 데어)

3) 네트워크층 network layer

- 데이터 링크층이 같은 네트워크 상에서 두 시스템 간에 패킷 전달을 책임지면, 네트워크층은 각 패킷이 발신 지점에서 최종 목적지까지 갈 수 있도록 보장한다.

ㄴ 만약 두 시스템이 같은 링크에 있다면, 항상 네트워크 층이 필요 없다.

- 논리 주소를 지정한다.

- 네트워크 간 연결 또는 규모가 큰 네트워크 연결하려면 경로지정이나 스위칭이 이루어진다.

4) 전송층 transport layer

- 전체 메시지의 프로세스 대 프로세스 전달을 책임진다.

- 네트워크 계층이 개별 패킷의 발신지-대-목적지 전달을 책임지지만, 이들 패킷 간의 관계는 처리하지 않는다.

- 서비스 지점의 주소를 지정한다.

- 분할과 재조립 : 메시지는 각 세그먼트가 순서 번호가 들어있는 전송 가능한 세그먼트로 나누는데, 이 순서 번호는 메시지가 목적지의 전송층에 정확하게 도착하여 재조립되고 패킷이 전송 중에 손실되거나 교체된 것에 대한 식별을 가능하게 한다.

- 비연결층이나 연결층에 따라, 먼저 연결을 만들지를 결정한다. (연결 제어)

- 데이터 링크층처럼 흐름을 제어하나, 단일 링크라기 보다는 종단-대-종단에서 수행한다. (흐름 제어)

- 프로세스-대-프로세스로 오류를 제어한다.

5) 세션층

- 두 프로세스 간에 반이중이나 전이중 모드로 통신하는 것을 허용한다. (대화 제어)

- 데이터 스트림에 확인점을 추가한다. (동기화)

6) 표현층

- 서로 다른 부호화 방법 간에 상호 운영성을 책임진다. (변환)

- 중요한 정보를 전달하기 위해서 프라이버시를 보장해야 한다. (암호화)

- 데이터 압축을 통해 정보에 들어있는 비트의 수를 줄여준다. (압축)

7) 응용 계층

- 사용자가 네트워크에 접속하는 것을 가능하게 한다.

- 전자우편, 원격 파일 접속과 전송, 공유된 데이터베이스 관리, 분산된 정보서비스의 또 다른 유형과 같은 서비스를 지원하고 사용자 인터페이스를 제공한다.

- 응용 계층에 의해 제공되는 특정 서비스는 다음과 같다.

ㄴ 네트워크 가상 터미널

ㄴ 파일 전송, 접근, 관리

ㄴ 전자우편 서비스

ㄴ 디렉토리 서비스

2.5 OSI 계층의 요약

3. TCP/IP 프로토콜

- TCP/IP 프로토콜은 OSI 기본 참조 모델보다 먼저 개발되었다.

- 다섯계층인 물리층, 데이터 링크층, 네트워크층, 전송층, 응용층으로 구성되어 있다.

ㄴ 처음 네 계층은 OSI 모델의 네 계층과 일치하는 물리적인 표준, 네트워크 인터페이스, 네트워크 간 상호연결, 그리고 전송 기능을 제공한다.

ㄴ 최상위 세 계층은 TCP/IP에서 제공하는 응용층이라는 하나의 계층으로 표현된다.

3.1 TCP/IP와 OSI 그룹 간 비교

- TCP/IP 모델의 응용층은 세 계층의 조합으로 생각할 수 있다.

이유 1) TCP/IP는 하나 이상의 전송층 프로토콜을 가지고 있어서, 세션층의 기능들 중 일부는 전송층 프로토콜의 일부로 이용할 수 있다.

이유 2) 응용층은 소프트웨어의 일부분만이 아니다. 많은 응용이 이 계층에서 개발될 수 있다. 만약에 세션층과 표현층에서 언급된 기능중 일부가 특정 응용에 필요하다면 소프트웨어로 개발해서 포함시킬 수 있다.

3.2 TCP/IP 프로토콜의 계층들

1) 물리층

- 특정 프로토콜을 규정하지 않고, 모든 표준과 기술적인 프로토콜을 지원한다.

- 이 레벨에서 통신은 두 홉 또는 노드 간, 컴퓨터나 라우터 간이다.

- 통신 단위는 단일 비트이다.

- 물리층의 책임은 비트의 전달에 추가하여 OSI 모델의 물리층에 대한 언급한 것과 일치하다.

2) 데이터 링크층

- 특정 프로토콜을 규정하지 않고, 모든 표준과 프로토콜을 지원한다.

- 이 레벨에서 통신은 두 홉이나 노드 간이다.

- 통신 단위는 프레임이다.

ㄴ 프레임은 네트워크층으로부터 받은 데이터에 헤더가 더해지고 트레일러가 더해짐으로써 캡슐화된 패킷이다.

3) 네트워크층

- TCP/IP는 인터넷프로토콜(IP) 을 지원한다.

ㄴ IP는 3개의 지원 프로토콜(ARP, ICMP, IGMP)을 포함한다.

cf1) 인터넷 프로토콜

- 신뢰성 없는 비연결형 데이터그램 프로토콜로서 최선의 노력으로 전달을 제공하는 전송 서비스이다.

ㄴ 최선의 노력이란 IP가 오류 검사나 추적을 제공하지 않는다는 것을 의미한다.

- 각기 개별적으로 전송되는 데이터그램이라는 패킷 형태로 데이터를 전송한다.

- 데이터그램은 서로 다른 경로로 전달될 수 있으므로 순서대로 도착하지 않거나 중복되어 도착할 수 있다.

- 경로를 기록하지 않고, 일단 목적지에 도착한 데이터그램을 재전송하는 기능도 제공하지 않는다.

cf2) 주소 변환 프로토콜 ARP

- IP주소를 물리적인 주소로 변환해주는다.

- LAN같은 물리적인 네트워크에서, 링크상의 각 장치는 네트워크 인터페이스 카드의 물리주소인 로컬 주소에 의해 구분된다.

- ARP은 인터넷 주소를 알고 있을때 노드의 물리주소를 찾는데 사용된다.

cf3) 인터넷 제어 메시지 프로토콜 ICMP

- 송신자에게 데이터그램의 문제점을 알려주기 위해 호스트와 게이트웨이가 사용하는 메커니즘이다.

- ICMP는 조회와 오류 보고 메시지를 보낸다.

4) 전송층

- TCP/IP에서 전송층은 3개의 프로토콜(TCP,UDP,SCTP)을 갖는다.

ㄴ IP는 호스트-대-호스트 프로토콜로서 패킷을 하나의 물리적인 장치에서 다른 물리적인 장치로 전달 할 수 있다는 것을 의미한다.

ㄴ UDP, TCP, SCTP는 하나의 프로세스에서 다른 프로세스로 메시지 전달하는 기능 갖는 전송 레벨 프로토콜이다.

cf1) 사용자 데이터그램 프로토콜 UDP

- 표준 TCP/IP 프로토콜보다 단순하다.

- 포트 주소, 감사함 오류 제어, 상위 계층으로부터 받은 데이터 길이 정보만 추가한다.

- 프로세스-대-프로세스 프로토콜이다.

cf2) 전송 제어 프로토콜

- 응용에 대한 모든 전송층 서비스를 제공한다.

- 신뢰성 있는 스트림 전송 프로토콜이다.

ㄴ 스트림이란 연결형을 의미하고, 데이터 전송하기 전에 양 존당 간의 연결을 설정해야 한다.

- 각 전송의 송신 종단에서 TCP는 데이터 스트림 세그먼트라는 작은 단위로 나눈다.

- 각 세그먼트는 수신된 세그먼트에 대한 확인응답 번호와 함께, 수신 후에 순서를 맞추기 위한 순서번호를 포함하고 있다.

cf3) 스트림 제어 전송 프로토콜

- UDP와 TCP 장점을 결합한 전송 제어 프로토콜이다.

- 네트워크층은 컴퓨터 A에서 컴퓨터 B까지 개별적인 데이터그램을 보내는 책임을 갖지만, 전송층은 A에서 B까지 사용자 데이터그램, 패킷, 세그먼트라는 전체 메시지를 전달하는 책임이 있다.

5) 응용층

- TCP/IP에서 응용층은 OSI 모델의 세션, 표현 그리고 응용층을 합친 것과 같다.

- 종단 사용자가 직접 눈으로 볼 수 있는 층으로 사용자에 대해서 직접 통신 기능을 제공한다.

4. 주소 지정

- TCP/IP 프로토콜을 이용한 인터넷은 4개의 서로 다른 계층의 주소가 사용되는데, 이는 물리 주소, 논리 주소, 포트 주소, 응용 지정 주소 등이 있다.

4.1 물리 주소

- 링크 주소로 알려진 물리 주소는 LAN이나 WAN에서 정의된 노드의 주소이다.

ㄴ 데이터 링크 층에 의해 사용되는 프레임이 포함된다.

- 유니캐스트, 멀티캐스트, 브로캐스트 물리 주소

ㄴ 물리 주소는 unicast, multicat, broadcast가 될 수 있다.

ㄴ 어떤 네트워크는 이 세 주소를 모두 지원한다. ex, ethernet

4.2 논리 주소

- IP 주소라고도 하는 논리 주소는 기존 물리적인 네트워크와 독립적인 전 세계적인 통신 서비스를 위해 필요하다.

- 물리주소는 서로 다른 네트워크가 서로 다른 주소 형태 갖는 네트워크 간 상호 접속 환경에는 적합하지 않다.

- 기존의 물리적인 네트워크에 관계없이, 각 호스트를 유일하게 식별할 수 있는 전 세계적인 주소지정 시스템이 필요해서 논리 주소가 나오게 되었다.

- 논리 주소는 현재 인터넷에 연결된 호스트를 유일하게 식별할 수 있는 32비트 주소체계를 사용하며 인터넷상의 두 호스트는 동일한 IP주소를 사용할 수 없다.

- 논리주소는 유니캐스트, 멀티캐스트, 브로드캐스트가 될 수 있다.

ㄴ 브로드캐스트 주소에는 제한이 있다.

4.3 포트 주소

- 다량의 데이터를 발신지에서 목적지 호스트까지 전송하기 위해서는 IP주소와 물리 주소가 필요하다.

but 목적지 호스트에 도착하는 것이 인터넷을 통한 데이터 통신의 최종 목적이 아니고 한 프로세스가 다른 프로세스와 통신할 수 있도록 하는 것이 중요하다.

- 프로제스를 식별하는 방법이 필요해 포트 주소라는 개념이 나오게 되었다.

- 포트 주소 길이는 16비트이다.

4.4 응용 지정 주소

- 어떤 응용은 특정 응용을 위해 설계된 사용자에게 친근한 주소를 사용한다.

ex, 전자우편 주소와 url

[이벤트 기반 마이크로서비스 구축] Chapter14. 지원 도구

ttoance — Sun, 8 Mar 2026 00:32:24 +0900

14. 지원 도구

14.4 쿼터

- 쿼터는 대개 보편적인 수준으로 이벤트 브로커에 설정한다.

ex, 한 프로듀서나 컨슈머 그룹이 CPU 처리 시간의 20%까지만 사용하도록 정할 수 있다.

14.5 스키마 레지스터리

ex,컨플루언트 (아파치 카프카용 스키마 레지스트리 구현체)

- 스키마 레지스트리가 있으면 프로듀서가 이벤트를 기록하는데 사용한 스키마 등록할 수 있으며 차별화된 이점이 생긴다.

ㄴ 스키마 ID를 사용하므로 이벤트 스키마를 이벤트와 함게 전송할 필요가 없어 대역폭 사용량을 줄일 수 있다.

ㄴ이벤트 스키마를 가져올 때 스키마 레지스트리 한 곳만 참조하면 된다.

ㄴ 스키마가 있으면 데이터 검색, 자유 텍스트 검색이 가능하다.

- 프로듀서는 이벤트를 생산하기 전에 직렬화하고 스키마 레지스트리에 스키마 등록해 스키마 ID를 얻는다.

- 이 스키마 ID를 직렬화한 이벤트에 추가한 다음

- 똑같은 스미카를 레지스트리에서 다시 쿼리하지 않도록 프로듀서 캐시에 넣는다.

- 컨슈머는 이벤트를 받고 캐시 또는 스키마 레지스트리에서 주어진 스키마 ID에 해당하는 스키마 얻는다.

- 스키마를 적용하여 역직렬화한다.

- 새로운 스키마라면 컨슈머 캐시에 넣는다.

14.6 스키마 생성/변경 알림

- 스키마 업데이트는 스키마 스트림에서 할 수 있고 연관된 이벤트 스트림도 상호 참조할 수 있다.

- 접근 통제 리스트 (ACL)은 어느 서비스가 어느 이벤트 스트림을 소비하는지 관련 정보 제공하고 마이크로서비스-팀 배정 시스템 통해 서비스를 소유한 팀에 이 사실을 통보한다.

14.7 오프셋 관리

- 오프셋 리셋

ㄴ 마이크로서비스 로직을 변경하면 이전에 쌓인 이벤트부터 재처리가 불가피한 경우에 사용

- 오프셋 전진

ㄴ 옛 데이터는 필요 없고 최근 데이터만 소비한다면 최초 대신, 최종 오프셋으로 애플리케이션 오프셋 리셋

- 오프셋 지정

ㄴ 오프셋을 특정 시점으로 되돌려야 할 때 ex, 멀티클러스터 환경에서 페일오버할때 메시지가 하나라도 누락되면 안되지만 처음부터 다시 시작하고 싶지 않을 때 장애 발생 n분전으로 오프셋 리셋하고 메시지 처리하도록 하면 된다.

14.8 이벤트 스트림 권한과 ACL

- 권한 및 ACL은 각 경계 콘텍스트가 자신의 경계를 벗어나지 않도록 강제한다.

- 어떤 이벤트 스트림의 접근 권한은 프로듀서 쪽 마이크로서비스를 소유한 팀에만 부여해야 한다.

14.10 컨슈머 오프셋 랙 모니터링

- 컨슈머 랙은 이벤트 기반 마이크로서비스의 확장 필요성을 가장 잘 나타내는 지표이다.

- 버로우 같은 아파치 카프카 모니터링 시스템은 렉 상태를 계산할 때 오프셋 렉의 이력까지 고려할 수 있다.

- 마이크로서비스는 필요한 만큼 자유롭게 규모를 늘리거나 줄일 수 있어야 하는데 시스템이 한도 끝도 없이 확장되고 축소되는 것을 방지하기 위해 히스테리시스(허용 임계치)를 사용한다.

ㄴ 히스테리시스는 신호를 평가하는 로직의 일부로서 AWS 클라우드워치 Cloudwatch, 구글 클라우

드 오퍼레이션 등 대부분의 최신 클라우드 플랫폼에서 사용할 수 있다.

14.14 디펜던시 추적과 토폴로지 시각화

[이벤트 기반 마이크로서비스 구축] Chapter13. 이벤트 기반 마이크로서비스와 요청-응답 마이크로서비스의 통합

ttoance — Sat, 7 Mar 2026 23:29:01 +0900

13. 이벤트 기반 마이크로서비스와 요청-응답 마이크로서비스의 통합

13.1 외부 이벤트 처리

- 외부에서 생성된 이벤트는 크게 두 종류로 나뉜다.

ㄴ 자율적으로 생성된 이벤트

ㄴ 반응하여 생성된 이벤트

13.1.1 자율적으로 생성된 이벤트

- 주기적인 상태 측정이나 센서가 읽어들인 값 또는 사용자가 하고 있는 일에 관한 정보를 메트릭 형태로 수집한 이벤트

ex, 넷플릭스 같은 미디어 스트리밍 서비스는 가입자가 어떤 영화를 보기 시작했는지, 얼마나 오래 보았는지 등을 측정하기 위해 분석 이벤트를 독립적으로 수집한다.

13.1.2 반응하여 생성된 이벤트

- 어떤 서비스의 요청에 반응하여 생성된 이벤트로 서비스는 요청을 만들어 엔드포인트로 보낸 다음 응답을 기다리게 된다.

- 경우에 따라 클라이언트 입장에서 요청이 수신됐다는 사실만 중요할 뿐 자세한 응답 내용은 필요하지 않을 수도 있다.

13.2 자율적으로 생성된 분석 이벤트 처리

- 분석 이벤트는 한데 모아 주기적으로 전송하거나 발생 즉시 전송한다.

- 외부 클라이언트 애플리케이션은 분석 이벤트 수신기 서비스로 보내고 이 서비스는 다시 해당 출력 이벤트 스트림으로 이벤트를 전달한다.

13.3 서드파티 요청-응답 API 연계

- 마이크로서비스는 이벤트기반의 로직에 따라 API를 호출한 뒤 응답을 기다리고 응답이 도착하면 파싱해서 해당 스키마를 준수하는지 확인한 다음, 어느 이벤트 처리와 마찬가지로 비즈니스 로직을 적용한다.

- 장점으로 첫째, 비즈니스 로직을 적용하는 동안 요청-응답 API와 이벤트 처리를 혼합할 수 있고 둘째, 서비스는 필요한 모든 API를 호출할 수 있고, 병렬 처리도 가능하다.

- 단점으로는 외부 서비스에 요청하면 결국 워크플로우에 비확정적인 요소가 스며들어 실패한 이벤트 재처리하면 처음에 호출했던 것과 결과가 달라질 수 있다.

13.4 상태 저장 데이터 처리 및 서비스

13.4.1 내부 상태 저장소를 이용해 실시간 요청 처리

- 마이크로서비스는 자신의 내부 상태에서 소싱한 결과를 제공할 수 있다.

- 클라이언트 요청이 로드 밸런서로 전달되면 로드 밸런서는 이 요청을 하부 마이크로서비스 인스턴스 중에서 하나로 보내게 된다.

- 모든 내부 상태는 키에 따라 샤딩되며 키 있는 값은 오직 하나의 파티션에만 할당된다.

ㄴ 키는 단일 파티션에만 매핑된다.

ㄴ 파티션은 하나의 컨슈머 인스턴스에만 할당된다.

13.4.2 외부 상태 저장소를 이용해 실시간 요청 처리

- 내부 상태 저장소 대신 외부 상태 저장소를 이용하면 두 가지 장점이 있다.

ㄴ 첫째, 각 인스턴스가 모든 상태를 사용할 수 있다 = 내부 스토리지 모델에 따라 데이터를 호스팅하는 마이크로서비스로 요청을 전달할 필요가 없다.

ㄴ 둘째, 모든 상태는 인스턴스 외부에 유지되므로 컨슈머 그룹 리밸런스가 일어나도 마이크로서비스가 새 인스턴스에 내부 상태를 다시 구체화할 필요가 없다.

- 이벤트 기반 마이크로 서비스를 구체화하여 요청 처리

- 별도 마이크로 서비스를 통해 요청 처리

13.5 이벤트 기반 워크플로 내에서 요청 처리

- 왼쪽 그림은 객체를 생성하고 DB에 직접 기록하는 저농적인 방식,

- 오른쪽 그림은 먼저 요청을 이벤트로 파싱하여 해당 이벤트 스트림에 발행한 다음, 이벤트 기반 워크플로우가 이벤트를 소비하기 전에 비즈니스 로직을 적용해서 DB에 저장하는 이벤트 우선 방식이다.

ㄴ 이벤트를 우선 이벤트 소비에 기록하면 모든 서비스가 이 데이터를 구체화하여 쓸 수 있다는 장점이 있지만 그만큼 지연이 발생하고 서비스가 결과를 사용하려면 데이터 저장소에 구체화될 때까지 기다려야 한다는 단점도 있다.

13.5.1 UI 이벤트 처리

- 요청을 이벤트로 처리하는 애플리케이션은 반드시 비동기 UI를 포함하도록 설계해야 한다.

ㄴ ex, '잠시 기다려주세요'

- 사용자의 추가 입력을 기다리는 와중에도 계속 유입되는 비사용자 이벤트를 마이크로 서비스가 처리해야 한다.

- ex, 신문 발행 워크플로 (승인 패턴)

ㄴ 신문 편집기 마이크로서비스는 조판, 광고, 기사 스트림을 받아 관계형 DB에 넣는다.

ㄴ 조판 담당자가 작업을 마치고 신문을 승인 요청할 준비가 되면 편집된 신문을 PDF파일에 넣고 편집된 신문 스트림을 생산한다.

ㄴ 승인은 별개의 마이크로 서비스가 실행한다.

ㄴ 편집자 승인 서비스와 광고주 승인 서비스를 분리해야 한다는 비즈니스 요건이 생긴다면 ?

13.6 요청-응답 애플리케이션과 마이크로프런트앤드

- 프론트앤드/백엔드 서비스는 크게 세 가지 방식으로 비즈니스 가치를 제공한다.

ㄴ 모놀리식 벡엔드는 조직 규모에 상관없이 일반적이다.

ㄴ 마이크로서비스 백엔드는 동기식 이벤트 기반의 마이크로 서비스를 점점 더 많이 사용하면서 인기를 얻고 있다.

ㄴ 마이크로프런트앤드는 백엔드부터 프론트엔드까지 모든 구현을 완전히 비즈니스 관심에 맞춘다.

13.7 마이크로프런트앤드의 장점

- 조합형 마이크로 서비스

ㄴ 일종의 조합형 패턴이라 기존 UI에 필요한 만큼 서비스를 추가할 수 있다.

- 비즈니스 요건에 맞추기 쉽다.

13.8 마이크로프런트앤드의 단점

- UI 엘리먼트와 스타일의 일관성이 어긋날 수 있다.

- 복합적인 프레임워크의 조각들이라 성능이 일관적이지 않을 수 있다.

[이벤트 기반 마이크로서비스 구축] Chapter9 FaaS 응용 마이크로서비스

ttoance — Sat, 21 Feb 2026 18:14:44 +0900

Chapter9 FaaS 응용 마이크로서비스

서비스로서의 함수 function as a service FaaS

9.1 함수 기반 솔루션을 마이크로서비스로 설계

솔루션을 구성하는 함수와 내부 이벤트 스트림은 반드시 어떤 경계 콘텍스트에 속해야 한다.
FaaS 프레임워크는 단일 함수를 쉽게 작성하고 여러 서비스에 재사용 가능하다는 장점이 있다.
하지만 함수 소유권이 모호해지며 어느함수를 변경할 경우 다른 서비스에 어떤 부정적인 영향일 미칠지 불확실해질 수 있다.

9.2 FaaS 공급자 선택

무료 오픈 소스는 오픈위스크, 오픈FaaS, 쿠블리스 등 기존 컨테이너 관리 서비스 옵션 존재함
aws, gcp, azure 에서도 특화된 프레임워크 제공함

9.3 함수를 마이크로 서비스로 개발

4가지 컴포넌트
- 함수
- 입력 이벤트 스트림
- 트리거 로직
- 메타데이터를 이용한 에러 및 확장 정책

9.5 트리거로 함수 시동

1 새 이벤트에 반응해 트리거 : 이벤트 - 스트림 리스너

구글, 마이크로소프트, 아마존의 FaaS 솔루션은 자사 상용 이벤트 브로커 전용 트리거를 제공, 오픈 소스 브로커에서 직접 트리거하는 것은 지원하지 않는다
오픈FaaS, 쿠블리스, 누클리오 같은 오픈 소스 솔루션은 카프카, 펄사, NATS 등 다양한 이벤트 프로커에서 쓸 수 있는 플로그인 제공

2 컨슈머 그룹 랙에 반응해 트리거

3 스케줄에 따라 트리거

4 웹훅에 반응해 트리거

5 리소스 이벤트에 반응해 트리거

9.8 함수에서 다른 함수 호출

1 이벤트 기반 통신 패턴

토폴로지 안에 있는 함수가 각각 작업이 끝나면 오프셋을 커밋해서 자신의 컨슈머 그룹 오프셋을 관리할 수 있다.
이벤트 스트림 처리 외에는 함수 간에 별다른 조정이 필요 없고 코레오그래피 패턴은 물론 오케스트레이션 패턴도 적용할 수 있다.
이벤트 처리 중 실패해도 이벤트 브로커에 이벤트가 남아 있기 때문에 그 다음 함수 인스턴스가 재처리하면 되므로 데이터 손실이 발생할 일도 없다.

2 직접 호출 패턴

자기 코드에서 직접 다른 함수를 호출하는 패턴
타 함수를 직접 비동기 호출하거나, 동기 호출 한 다음 반환값을 기다리는 방식으로 작동된다.

[이벤트 기반 마이크로서비스 구축] Chapter8 마이크로서비스 워크플로 구축 - 미쉐린은 오케스트레이션을 버렸고, Netflix는 오케스트레이션을 만들었다

ttoance — Fri, 20 Feb 2026 20:35:44 +0900

Chapter8 마이크로서비스 워크플로 구축

워크플로(작업 흐름/절차)란 논리적 분기, 보상 액션 등 비즈니스 프로세스를 구성하는 특정한 작업을 지칭한다.

워크플로 구성할 때 고려해야 하는 항목

워크플로 생성 및 수정
- 워크플로 내부의 서비스들은 어떻게 서로 연관되는가?
- 기존 워크플로를 수정할 때 다음과 같은 일들이 생기지 않도록 하려면 어떻게 해야 하나?
  - 이미 진행 중인 작업을 중단시킨다.
  - 여러 마이크로서비스를 변경해야 한다.
  - 모니터링과 가시성이 깨진다
워크플로 모니터링
- 어떤 이벤트에 대해 워크플로가 언제 완료됐는지 어떻게 알 수 있나?
- 이벤트 처리 도중 실패하거나 워크플로 어딘가에서 막혔는지 여부를 어떻게 판단할까?
- 워크플로의 전체 상태는 어떻게 모니터링할 것인가?
분산 트랜잭션 구현
- 대부분의 워크플로는 여러 액션이 함께 일어나거나 아무 액션도 일어나지 않아야 한다.
  분산 트랜잭션은 어떻게 구현할 것인가?
- 분산 트랜잭션은 어떻게 롤백하나?

8.1 코레오그래피 패턴 choregraphed architecture(리액티브 아키텍쳐 reactive architecture)

고도로 분리된 마이크로서비스 아키텍쳐를 가리키는 용어
일체의 차단과 대기 없이 입력 이벤트가 도착하는 대로 반응
새로운 단계를 워크플로 끝부분에 쉽게 추가하는 것은 간단하지만 중간에 단계를 삽입하거나 워크플로우 순서 바꾸면 문제가 될 수 있다.
개별적으로 분산되어 있어서 특정 이벤트의 진행 상황을 파악하기 어려운 경우가 많다.

michelin 오케스트레이션 → 코레오그래피

Moving from orchestration to choreography - Part 3

Here our journey together almost comes to an end with the third article of this series "moving from orchestration to choreography". In part 1 [https://blogit.michelin.io/choregraphy-or-orchestration-thats-the-question/], I explained how we convinced our or

blogit.michelin.io

One of the first challenge we faced was the absence of error handling; in case of something going wrong during the processing of an event, nothing would be able to "catch" the error. This discovery led to a first set of
technical solutions, with the creation of a framework that would allow for the streaming process to continue without crashing, using a generic error-handling mechanism.

우리가 직면했던 첫 번째 과제 중 하나는 오류 처리의 부재였습니다. 이벤트 처리 중에 문제가 발생할 경우, 오류를 "포착"할 수 있는 방법이 없었습니다. 이러한 문제점을 발견하면서 일반적인 오류 처리 메커니즘을 사용하여 스트리밍 프로세스가 중단 없이 계속될 수 있도록 하는 프레임워크를 개발하는 초기 기술적 해결책을 마련하게 되었습니다.

The second axis came from our ambition: knowing that we had a couple hundreds micro-services ahead of us, it seemed vital to us to figure out how to standardize the code implementation , through factorization and an abstraction layer preventing common setup mistakes during development phase. This abstraction layer was integrated in the same framework mentioned previously, and allows us to fully implement a deployment-ready microservice in a matter of a few days, if not hours, versus a couple weeks at the beginning of the project. Here is the abstract class that each micro-service app inherits from:

두 번째 축은 우리의 야망에서 비롯되었습니다. 수백 개의 마이크로서비스를 개발해야 한다는 것을 알고 있었기에,
코드 구현을 표준화하는 것이 매우 중요하다고 생각했습니다. 이를 위해 코드 분해(팩토링)와 추상화 계층을 구축하여 개발 단계에서 흔히 발생하는 설정 오류를 방지하고자 했습니다. 이 추상화 계층은 앞서 언급한 프레임워크에 통합되었으며, 프로젝트 초기에는 몇 주가 걸리던 작업을 이제는 며칠, 심지어 몇 시간 만에 배포 준비가 완료된 마이크로서비스를 구현할 수 있게 되었습니다. 다음은 각 마이크로서비스 앱이 상속받는 추상 클래스입니다.

The last axis was centered around a well known issue when dealing with multiple systems:
how do we ensure non-regression without spending months in testing phases?

마지막 축은 여러 시스템을 다룰 때 발생하는 잘 알려진 문제, 즉 테스트 단계에 몇 달씩 소요하지 않고 회귀 오류를 방지하는 방법을 중심으로 했습니다.

8.2 오케스트레이션 패턴

중앙의 마이크로서비스가 하위 워커 마이크로 서비스에게 명령을 내린 뒤 응답을 기다린다.
속도는 상대적으로 느리지만 작업은 더 안정적이고, 간헐적인 실패를 잘 처리한다.
오케스트레이션 워크플로를 가시화할 수 있어 특정 이벤트의 진행 상황 및 워크플로에서 발생 가능한 이슈를 파악하기 쉽다.

netflix 코레오그래피 → 오케스트레이션

Netflix Conductor: A microservices orchestrator

visibility into distributed workflows

netflixtechblog.com

Process flows are “embedded” within the code of multiple applicationsOften, there is tight coupling and assumptions around input/output, SLAs etc, making it harder to adapt to changing needsAlmost no way to systematically answer “What is remaining for a movie’s setup to be complete”?

프로세스 흐름은 여러 애플리케이션의 코드 내에 "내장"되어 있습니다.종종 입력/출력에 대한 긴밀한 연관성과 가정이 존재합니다.SLAs등등으로 인해 변화하는 요구에 적응하기가 더욱 어려워집니다."영화의 설정이 완성되기 위해 남은 것은 무엇인가?"라는 질문에 체계적으로 답할 방법은 거의 없다.

출처 : 미슐랭 기술 블로그 https://blogit.michelin.io/choregraphy-or-orchestration-thats-the-question/

관련 내용을 한국 기술 블로그에서 찾아봤으나 (네이버 / 당근마켓 / 배달의민족 ) 정확히 그런 용어는 쓰지 않았음.

https://techblog.woowahan.com/7835/

회원시스템 이벤트기반 아키텍처 구축하기 | 우아한형제들 기술블로그

최초의 배달의민족은 하나의 프로젝트로 만들어졌습니다. 배달의민족의 주문수는 J 커브를 그리는 빠른 속도로 성장했고, 주문수가 커지면서 자연스럽게 트래픽 또한 매우 커졌습니다. 하나의

techblog.woowahan.com

https://tech.kakaopay.com/post/event-driven-architecture/

이벤트 드리븐 적재적소에 사용하기 | 카카오페이 기술 블로그

슬랙과 상호작용하기 위해 적용한 이벤트 기반 구조를 소개합니다.

tech.kakaopay.com

8.3 분산 트랜잭션

둘 이상의 마이크로서비스에 걸쳐있는 트랜잭션을 말한다.
마이크로서비스는 각자 트랜잭션에서 자신의 분량을 처리하되 트랜잭션이 중단되어 되돌아갈 경우 처리한 내용을 되돌린다.
이벤트 기반 아키텍쳐에서 분산 트랜잭션은 보통 사가라고하며, 코레오그래피 패턴이나 오케스트레이퍼 패턴으로 구현한다.
사가 패턴에서는 참여하는 마이크로 서비스가 각자 트랜잭션에서 자신이 처리한 분량을 알아서 돌려야 한다.