프로토콜·계층·주소·이름·경로

연결만으로는 대화가 시작되지 않는다

두 사람이 같은 전화선을 써도 서로 다른 언어로 말하고, 누가 먼저 말할지 모르며, 끊겼을 때의 처리도 합의하지 않았다면 대화가 성립하지 않는다. 컴퓨터 통신도 메시지의 모양과 순서, 상대를 찾는 방법, 실패 처리에 대한 공통 규칙이 필요하다. 이 많은 책임을 한 장치와 한 규칙에 몰아넣지 않고 계층으로 나누면 서로 다른 제작자의 장비도 같은 약속 아래 연결할 수 있다.

먼저 되짚기: 인터페이스와 계층

인터페이스는 두 요소가 주고받을 입력·출력·규칙·오류의 약속이다. 계층은 인접한 인터페이스와 책임을 따라 복잡성을 나누며, 위 계층은 아래 계층의 약속을 사용한다. 네트워크는 이 분리 원리를 원격 통신에 적용한다.

원격 인터페이스를 계층별 프로토콜로 나눈다

서비스 인터페이스를 원격 통신에 적용하면 응용 프로토콜이 메시지 의미·순서를 정하고, 네트워크 계층화가 전송·네트워크·링크·물리 책임을 나눈다. 각 층의 주소·상태·오류를 분리하여 이름에서 서비스 결과까지 추적한다.

인터페이스와 계층 개념을 원격 통신에 적용하면 각 층이 책임질 메시지·상태·오류를 분리할 수 있다.

프로토콜

프로토콜은 통신하는 주체들이 메시지를 같은 의미로 해석하도록 정한 규칙의 집합이다. 규칙에는 메시지의 형식과 각 필드의 의미, 메시지를 주고받는 순서, 허용 시간, 오류·중복·재전송 처리와 상태 전이가 포함된다. 단순한 데이터 형식은 한 메시지의 모양만 정하지만 프로토콜은 시간에 따라 이어지는 대화 전체를 정한다.

주소·이름·경로 전에 프로토콜을 다시 잇는다

프로토콜은 메시지 형식뿐 아니라 의미·순서·시간·오류 처리 규칙을 정한다. 대상을 찾고 전달하는 주소·이름·경로도 이러한 통신 규칙 안에서 해석된다.

도달성과 대화 성공을 같은 것으로 보지 않는다

메시지가 올바른 주소와 경로를 따라 목적지까지 도달해도 응용 메시지의 상태순서가 프로토콜 계약을 어기면 서비스는 실패한다. 네트워크 도달성과 프로토콜 상태를 따로 검증한다.

네트워크 계층화

네트워크 계층화는 통신 책임을 여러 층의 계약으로 분리해 각 층이 바로 아래 층의 기능을 사용하고 바로 위 층에 기능을 제공하게 한 구조다. 물리 층은 신호 전달, 링크 층은 한 구간의 프레임 전달, 네트워크 층은 여러 구간의 패킷 경로 선택, 전송 층은 종단 프로그램의 통신 접점을 구별하고 데이터를 프로그램 사이에 전달하는 책임을 주로 맡는다. 전송 방식에 따라 순서 유지, 손실 복구, 흐름·혼잡 제어를 제공할 수도 있고 제공하지 않을 수도 있으므로 막연히 전달 품질이라고 묶지 않는다. 응용 층은 사용자 서비스의 메시지 의미와 대화 절차를 맡는다. 실제 기술 묶음마다 층의 수와 이름은 다를 수 있지만 책임을 분리하고 인접 계약으로 연결한다는 원리는 같다.

주소·이름·경로

이름은 사람이 서비스나 대상을 의미 있게 부르는 식별자이고, 주소는 통신 체계가 대상의 위치나 접점을 구별해 전달에 사용하는 값이다. 이름 해석은 이름을 현재 사용할 주소로 대응시키는 과정이다. 경로는 출발지에서 목적지까지 거칠 링크와 중간 장치의 연속이며, 라우팅은 도달 가능성·비용·정책을 바탕으로 다음 전달 방향을 고르는 일이다. 이름, 주소, 경로는 모두 대상을 찾는 데 쓰이지만 의미·위치·이동 순서를 각각 맡는다.

이름을 입력한 뒤 응답이 돌아오기까지

이름과 경로가 맞아도 응용 상태 계약을 따로 확인한다 · 상태 따라가기

order-api를 조회해 10.20.30.40을 얻는다. 모든 단계에서 이름·경로·세션 상태의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

order-api를 10.20.30.40으로 해석하면 이 예에서는 /24와 /16 중 더 구체적인 /24의 R2를 고른다. 링크 A·중간장치·링크 B를 거쳐 목적지 통신 접점에 닿은 뒤 응용의 OPEN→AUTH→REQUEST→CLOSE 계약으로 결과를 해석한다. AUTH 생략·실패이면 도달해도 업무 요청은 거절된다. 응답은 같은 종류의 계층을 거치며 물리 경로가 같을 필요는 없다.

이 예의 조건

• order-api를 10.20.30.40으로 해석하면 이 예에서는 /24와 /16 중 더 구체적인 /24의 R2를 고른다. 링크 A·중간 장치·링크 B를 거쳐 목적지 통신 접점에 닿은 뒤 응용의 OPEN→AUTH→REQUEST→CLOSE 계약으로 결과를 해석한다. AUTH 생략·실패이면 도달해도 업무 요청은 거절된다. 응답은 같은 종류의 계층을 거치며 물리 경로가 같을 필요는 없다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상서비스 이름	원 설명order-api
대상목적지 주소	원 설명10.20.30.40
대상다음 전달 경로	원 설명/24 → R2 선택 / 링크 A → 중간 → 링크 B
대상목적지 프로그램	원 설명전송 접점 확인
대상응용 대화 계약	원 설명OPEN → AUTH 성공 / REQUEST → CLOSE
대상서비스 결과	원 설명의미·순서·오류 판정

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결서비스 이름 → 목적지 주소	원 라벨·방향이름 해석 / 정방향 / 실선
연결목적지 주소 → 다음 전달 경로	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결다음 전달 경로 → 목적지 프로그램	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결목적지 프로그램 → 응용 대화 계약	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결응용 대화 계약 → 서비스 결과	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
이름 확인 order-api를 조회해 10.20.30.40을 얻는다.	값·보충 정보 이름·경로: DNS→10.20.30.40 세션 상태: 세션 미수립	변화·이유 이름 응답이 업무 처리 성공은 아니다.
더 구체적 경로 /16보다 구체적인 /24에 맞는 R2 경로를 선택한다.	값·보충 정보 이름·경로: /24→R2 세션 상태: 연결 준비	변화·이유 경로 선택은 인증을 대신하지 않는다.
세션 처리 OPEN 뒤 AUTH를 확인해야 허용된 REQUEST로 진행한다.	값·보충 정보 이름·경로: 선택 경로 유지 세션 상태: OPEN→AUTH→REQUEST	변화·이유 실제 허용된 세션 조건에서만 업무를 요청한다.
세션 종료 처리 뒤 CLOSE로 세션을 닫으며 업무 결과의 확인은 별도다.	값·보충 정보 이름·경로: 주소·경로 유지 세션 상태: CLOSE	변화·이유 연결 종료와 업무 성공을 같게 세지 않는다.

이름과 경로가 맞아도 응용 상태 계약을 따로 확인한다 · 상태 따라가기

order-api를 조회해 10.20.30.40을 얻는다. 모든 단계에서 이름·경로·세션 상태의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

order-api를 10.20.30.40으로 해석하면 이 예에서는 /24와 /16 중 더 구체적인 /24의 R2를 고른다. 링크 A·중간장치·링크 B를 거쳐 목적지 통신 접점에 닿은 뒤 응용의 OPEN→AUTH→REQUEST→CLOSE 계약으로 결과를 해석한다. AUTH 생략·실패이면 도달해도 업무 요청은 거절된다. 응답은 같은 종류의 계층을 거치며 물리 경로가 같을 필요는 없다.

이 예의 조건

• order-api를 10.20.30.40으로 해석하면 이 예에서는 /24와 /16 중 더 구체적인 /24의 R2를 고른다. 링크 A·중간 장치·링크 B를 거쳐 목적지 통신 접점에 닿은 뒤 응용의 OPEN→AUTH→REQUEST→CLOSE 계약으로 결과를 해석한다. AUTH 생략·실패이면 도달해도 업무 요청은 거절된다. 응답은 같은 종류의 계층을 거치며 물리 경로가 같을 필요는 없다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상서비스 이름	원 설명order-api
대상목적지 주소	원 설명10.20.30.40
대상다음 전달 경로	원 설명/24 → R2 선택 / 링크 A → 중간 → 링크 B
대상목적지 프로그램	원 설명전송 접점 확인
대상응용 대화 계약	원 설명OPEN → AUTH 성공 / REQUEST → CLOSE
대상서비스 결과	원 설명의미·순서·오류 판정

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결서비스 이름 → 목적지 주소	원 라벨·방향이름 해석 / 정방향 / 실선
연결목적지 주소 → 다음 전달 경로	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결다음 전달 경로 → 목적지 프로그램	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결목적지 프로그램 → 응용 대화 계약	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결응용 대화 계약 → 서비스 결과	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
이름 확인 order-api를 조회해 10.20.30.40을 얻는다.	값·보충 정보 이름·경로: DNS→10.20.30.40 세션 상태: 세션 미수립	변화·이유 이름 응답이 업무 처리 성공은 아니다.
더 구체적 경로 /16보다 구체적인 /24에 맞는 R2 경로를 선택한다.	값·보충 정보 이름·경로: /24→R2 세션 상태: 연결 준비	변화·이유 경로 선택은 인증을 대신하지 않는다.
세션 처리 OPEN 뒤 AUTH를 확인해야 허용된 REQUEST로 진행한다.	값·보충 정보 이름·경로: 선택 경로 유지 세션 상태: OPEN→AUTH→REQUEST	변화·이유 실제 허용된 세션 조건에서만 업무를 요청한다.
세션 종료 처리 뒤 CLOSE로 세션을 닫으며 업무 결과의 확인은 별도다.	값·보충 정보 이름·경로: 주소·경로 유지 세션 상태: CLOSE	변화·이유 연결 종료와 업무 성공을 같게 세지 않는다.

사용자가 서비스 이름을 입력하면 이름 해석 체계가 그 이름에 대응하는 주소를 찾는다. 송신 장치는 주소를 패킷에 넣고, 각 중간 장치는 자신의 경로표와 정책을 보고 다음 장치로 넘긴다. 각 링크에서는 링크 계층의 프레임이 바뀌지만, 위 계층의 응용 메시지는 해당 프로토콜 규칙에 따라 목적지 프로그램이 해석한다. 응답도 같은 종류의 계층을 거치되 반드시 완전히 같은 물리 경로를 돌아올 필요는 없다.

계층마다 보는 제어정보도 다르다. 링크 장치는 현재 구간의 프레임을, 경로 선택 장치는 패킷의 네트워크 주소를, 목적지 프로그램은 전송 접점과 응용 메시지를 본다. 이 분리는 아래 매체가 광섬유에서 무선으로 바뀌어도 위 응용 규칙을 유지하게 한다.

PN-1: 이름→주소→경로→응용 상태를 한 번에 추적한다

IPv4 주소는 8비트씩 네 묶음, 총 32비트다. /24는 앞 24비트(이 예에서는 10.20.30)가 같아야 한다는 뜻이므로 10.20.30.0부터 10.20.30.255까지를 포함한다. /16은 앞 16비트(10.20)만 고정하므로 10.20.0.0부터 10.20.255.255까지다. 끝의 .40은 두 범위에 모두 들고 24>16이므로 더 긴 prefix를 고른다. /0은 고정된 앞 비트가 없는 기본 경로다. 포함 판정과 호스트에 배정 가능한 주소 판정은 서로 다르다.

IPv4는 Internet Protocol version 4, 인터넷 프로토콜 4판을 가리킨다. 점으로 나눈 각 숫자는 바이트 한 묶음을 십진수로 쓴 것이며 prefix(접두부)는 주소의 앞부분이다. 여기서 업무 포트는 같은 주소의 컴퓨터 안에서 요청을 받을 프로그램의 통신 접점을 구별하는 번호를 말한다. 주소와 경로는 컴퓨터에 도달할 방향을 찾고 포트·응용 상태는 어떤 대화를 받을지 구별하므로, 한쪽의 성공을 다른 쪽의 성공으로 옮기지 않는다.

OPEN은 대화 시작, AUTH는 인증, REQUEST는 업무 요청, CLOSE는 종료라는 자체 상태 이름이다. ping은 별도 진단 메시지의 응답을 보는 도구이므로 성공해도 업무 포트·인증·주문 처리를 시험한 것은 아니다. 반대로 진단 응답을 막은 환경에서는 ping 실패만으로 모든 업무통신 실패를 결론 내리지 않는다.

AUTH는 상대가 누구인지 확인하는 단계로 읽으며 이 예에서는 그 확인이 성공한 뒤에만 REQUEST를 허용한다. OPEN 뒤 AUTH를 보내 성공 확인을 받으면 현재 대화 상태가 인증됨으로 바뀌고 REQUEST를 처리할 수 있다. AUTH가 실패했거나 생략되면 같은 목적지 주소여도 업무 요청을 거절한다. 메시지가 도착했다는 사실과 허용된 상태에서 처리되었다는 사실의 차이다.

사용자가 서비스 이름 order-api를 입력했고 이름 해석 결과가 주소 10.20.30.40이라고 하자. 이 예의 경로표는 다음과 같다.

목적지 10.20.30.40은 /24와 /16에 모두 포함되므로 더 구체적인 /24 경로 R2를 고른다고 가정한다. 경로가 맞아 목적지 프로그램까지 도달했다고 해도 응용 프로토콜이 OPEN → AUTH → REQUEST → CLOSE 순서를 요구하는데 OPEN → REQUEST를 보내면 상태 계약 위반이다.

따라서 “주소로 ping이 된다”와 “응용 요청이 올바르게 처리된다”는 같은 증거가 아니다. 이름 해석 결과, 목적지 주소, 선택 경로, 전송 접점, 응용 메시지 순서를 각각 확인한다.

증상에 맞는 책임층을 먼저 찾는다

계층은 책임을 찾는 지도이지 현실을 무조건 다섯 상자로 자르는 규칙이 아니다. 한 장애가 여러 층에 걸칠 수 있으므로 가장 낮은 확실한 정상 지점에서 위로 올라가며 범위를 줄인다. 이름을 주소처럼 고정해 저장할지, 변하는 주소를 이름 해석으로 찾을지는 이동성·변경 빈도·장애 시 대체 경로를 기준으로 결정한다.

형식이 같아도 의미와 시간이 다르면 실패한다

프로토콜 버전이 다른 양쪽이 같은 필드 이름을 다른 단위로 해석하면 메시지 형식은 맞아도 결과는 틀린다. 응답이 유실됐을 때 재시도 규칙이 없으면 처리가 멈추고, 무조건 재시도하면 같은 작업이 중복될 수 있다. 프로토콜은 정상 흐름뿐 아니라 시간초과, 중복, 순서 역전과 종료를 정의해야 한다.

이름 기록이 오래되어 이미 바뀐 주소를 가리키거나, 주소 범위를 잘못 설정하거나, 경로표가 서로를 다음 지점으로 가리키면 도달하지 못하거나 순환한다. 상위 계층이 하위 계층의 특정 장비에 직접 의존하면 교체 가능성도 사라진다. 문제를 고칠 때는 이름 해석, 주소 유효성, 경로 정보의 안정성, 프로토콜 상태를 구분해 확인한다.

자체 10점 문제

프로토콜·네트워크 계층화·이름·주소·경로의 관계를 설명하시오.

요구어는 설명이다. 통신규칙, 계층책임, 식별과 전달경로를 한 흐름으로 연결한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 프로토콜
2. 네트워크 계층화
3. 이름과 주소
4. 경로·라우팅
5. 도달성과 응용 상태 구분

10점 답안 도식

이름→주소→경로→접점→응용 계약의 그림을 따라 각 책임을 설명한다. 이름은 의미 있는 식별자, 주소는 전달 값, 경로는 이동 순서이며 목적지 도달과 응용 대화 성공은 별도다.

모범답안 축약본: 이름에서 응용 대화까지 책임을 추적한다

문제: 프로토콜과 네트워크 계층화, 이름·주소·경로의 관계를 설명하시오. 프로토콜은 통신 주체가 해석할 메시지 형식, 의미, 순서, 시간과 오류 처리 규칙의 집합이다. 계층화는 신호전송, 같은 링크의 프레임, 여러 망의 패킷 경로, 프로그램 간 전달, 응용 메시지 의미의 책임을 나누고 인접 계층 인터페이스로 연결한다. 이름은 사람이 이해하는 대상 식별자, 주소는 전달에 사용할 위치·접점 값, 경로는 목적지까지 거치는 링크와 장치의 순서다. 클라이언트는 이름을 주소로 해석하고 경로를 따라 전송계층 연결이나 메시지를 보내 응용 프로토콜로 대화한다. 장애 분석은 응용 증상만 보고 전체를 재시작하지 말고 이름 해석, 목적지 주소, 경로, 포트·전송상태, 응용 응답을 순서대로 확인한다. 계층 경계와 오류 책임을 명확히 해야 내부 변경을 가두고 상호운용성을 유지할 수 있다.

자체 25점 문제

이름으로 접속되지 않거나 응용 요청만 실패하는 서비스를 계층·주소·경로·프로토콜 관점에서 진단하시오.

요구어는 진단이다. 낮은 계층의 확인된 정상 지점부터 위로 올라가며 원인을 좁힌다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 증상·시각·대상 범위
2. 물리·링크 정상 여부
3. 이름 해석 결과
4. 목적지 주소·prefix
5. 선택 경로·다음 지점
6. 전송 접점
7. 응용 프로토콜 상태순서
8. 변경·복구·재현 증거

25점 답안 도식

가장 낮은 확인된 정상 지점에서 시작한다. 링크가 정상인지 확인한 뒤 이름·주소·선택 경로·전송 접점·응용 상태를 추적하고, 책임층 진단표와 아래 두 교육용 관찰 사례로 원인을 좁힌다. 링크가 정상이라는 증거 없이 뒤 단계의 성공을 가정하지 않는다.

25점 모범답안

먼저 장애가 모든 대상인지 특정 이름·주소·요청만인지 범위를 고정한다. 링크가 정상이라면 이름 order-api의 현재 해석 결과를 확인하고, 얻은 목적지 주소가 유효한지와 경로표에서 어떤 prefix가 선택되는지 본다.

PN-1처럼 10.20.30.40이 /24와 /16에 동시에 맞는다면 이 예에서는 더 구체적인 /24 R2를 선택한다. 주소로 목적지까지 도달해도 응용 프로토콜이 OPEN → AUTH → REQUEST를 요구하는데 AUTH를 생략하면 네트워크 경로가 아니라 상태 계약 실패다.

따라서 이름 해석·주소·경로·전송 접점·응용 메시지 순서를 순서대로 확인하고, 가장 낮은 확실한 정상 지점에서 위로 범위를 줄인다. 이름을 주소처럼 고정하거나 도달성을 업무 성공으로 오해하지 않는다.

교육용 관찰표를 두 장애로 나누어 적용한다.

관찰	좁혀진 실패 지점	조치와 재시험
이름 결과가 옛 10.20.30.41, 승인된 현재 주소는 .40이며 .40의 업무 접점은 응답	이름과 주소 대응 오류 후보	이름 기록·캐시 만료를 확인해 .40으로 교정 후 이름을 통한 접속 재시험
이름은 .40, /24 R2 선택·업무 연결 성공, OPEN 다음 REQUEST에서 인증 필요 오류	응용 상태 계약	AUTH 성공 뒤 REQUEST로 변경하고 인증 실패·정상 두 경로 재시험

첫 경우도 .41이 왜 남았는지 확인하지 않고 이름 해석 서버 전체를 재시작하지 않는다. 두 번째는 경로를 변경해도 AUTH 누락이 해결되지 않는다. 재시험에는 변경 전·후 이름 결과와 상태순서, 시각, 오류 응답을 남긴다.

출처와 적용 경계

계층·프로토콜·이름·주소·경로의 역할은 안정된 네트워크 기초개념이다. PN-1의 주소·prefix·R0/R1/R2와 응용 상태순서는 학습용 자체 예이며 실제 DNS·라우팅·응용 프로토콜 설정을 뜻하지 않는다.

30초 정리

1. 프로토콜은 메시지 형식뿐 아니라 의미·순서·시간·오류 처리까지 정한 대화 규칙이다.
2. 네트워크 계층화는 신호, 링크, 경로, 프로그램 전달과 응용 의미의 책임을 나눈다.
3. 이름은 의미 있는 식별자, 주소는 전달에 쓰는 위치·접점 값, 경로는 목적지까지의 이동 순서다.
4. 통신 장애는 증상에 맞는 책임층에서 시작해 이름 해석·주소·경로·프로토콜 상태를 차례로 좁힌다.

자기교정과 조건 변경

/24 경로가 사라지면? 목적지가 /16에 포함된다면 이 예의 다음 후보 R1을 검토하고 실제 경로 정책을 확인한다.

이름 해석이 두 주소를 반환하면? 이름 자체를 단일 고정 위치로 보지 말고 선택·부하분산·실패대체 정책을 별도로 확인한다.

AUTH가 선택 단계로 바뀌면? 응용 상태계약과 테스트 순서를 함께 바꾸며 네트워크 경로판정은 그대로 유지한다.