네트워크 기초 Part 3 — 애플리케이션 프로토콜 10종
마지막 업데이트: 2026년 9월 14일
4부작 시리즈입니다
Part 1: 계층 모델과 링크·라우팅 · Part 2: 전송 계층과 TLS · Part 3: 애플리케이션 프로토콜 (현재 문서) · Part 4: 요청의 여정과 클라우드
전송 프로토콜이 제공하는 스트림·데이터그램 위에서 애플리케이션 프로토콜이 실제 서비스를 만듭니다. 이 파트는 이름 해석(DNS·DoH), 부트스트랩(DHCP), 운영 접속(SSH), 메일(SMTP), HTTP/3·WebSocket·WebRTC·gRPC·MQTT를 다룹니다.
5. 애플리케이션 계층 — 실제 서비스
DNS
정의: 도메인 이름을 IP 주소 등의 레코드로 변환하는 분산 디렉터리 시스템.
동작: 계층적 위임 구조입니다. 캐시에 답이 없으면 재귀 리졸버가 루트→TLD→권한 네임서버의 위임을 따라가거나 다른 리졸버에 전달합니다. 캐시가 있으면 일부 또는 전체 조회를 생략할 수 있습니다. A/AAAA는 주소, CNAME은 별칭, MX는 메일 서버, TXT는 여러 프로토콜이 사용하는 문자열을 담습니다.
실무 포인트: DNS는 분산 시스템이지만 특정 리졸버·공급자·설정이 공통 의존점이 될 수 있습니다. DNS 페일오버는 장애 감지, 레코드 갱신, 이미 캐시된 응답의 TTL, 애플리케이션 캐시, 기존 연결을 함께 고려해야 합니다. 지금 TTL을 줄여도 이전 응답의 캐시 수명은 단축되지 않습니다. 일부 리졸버는 정의된 장애 조건에서 만료된 응답을 제공할 수도 있습니다(RFC 8767). 각 단계를 측정하세요. 짧은 TTL만으로 전환 시간을 보장하지 못합니다. 로드밸런서와 애니캐스트를 보완적으로 사용할 수 있지만 각각의 상태 감지·수렴 시간도 필요합니다.
자주 쓰는 레코드 타입 한눈에:
| 타입 | 용도 | 실무 메모 |
|---|---|---|
| A / AAAA | 도메인 → IPv4 / IPv6 | 가장 기본 |
| CNAME | 별칭 → 정식 이름 | apex의 SOA/NS와 공존 불가; 공급자별 ALIAS/ANAME 또는 Route 53 Alias는 지원 대상에 apex 매핑 제공 |
| MX | 메일 수신 서버 | 우선순위 숫자가 낮을수록 먼저 |
| TXT | 임의 문자열 | SPF/DKIM/DMARC, 도메인 소유 검증 |
| NS | 위임 네임서버 | 하위 존 위임 |
| SRV | 서비스 위치(호스트+포트) | 일부 프로토콜의 디스커버리 |
| CAA | 인증서 발급 허용 CA 제한 | CA의 정책 준수가 필요하며 모든 잘못된 발급을 자체 차단하지는 않음 |
DNSSEC과 DoH는 다른 문제를 풉니다. DNSSEC은 검증된 신뢰 체인으로 서명된 DNS 데이터의 출처와 무결성을 인증하며 질의를 암호화하지 않습니다. DoH는 HTTPS로 선택한 리졸버를 인증하고 클라이언트–리졸버 구간의 기밀성·무결성을 보호합니다. 악의적이거나 잘못 설정된 리졸버의 응답이 권한 데이터와 일치함을 자체 증명하지는 않습니다. 둘은 함께 사용할 수 있습니다.
DoH
정의: DNS 질의를 HTTPS로 감싸 전송하는 방식.
동작: 전통적인 DNS는 일반적으로 평문 UDP와 TCP 53을 사용합니다. DoH는 DNS 메시지를 HTTPS로 전송해 해당 구간의 수동 도청과 변조를 방지합니다. 리졸버 주소와 트래픽 메타데이터로 DoH 사용을 식별할 가능성은 남고, 선택한 리졸버는 질의 내용을 볼 수 있습니다.
실무 포인트: 별도로 선택한 공개 DoH 리졸버는 조직 리졸버의 필터링·로깅을 우회하거나 사설 이름 해석에 실패할 수 있습니다. DoH 자체가 정책을 무력화하지는 않습니다. 관리형 DoH 리졸버도 로깅·필터링을 적용할 수 있고 브라우저·OS 정책으로 승인된 리졸버를 선택할 수 있습니다. 암호화 해제를 항상 전제하지 말고 분할 DNS와 단말 정책을 검증하세요.
DHCP
정의: 호스트에게 IP 주소와 네트워크 설정을 자동으로 할당하는 프로토콜.
동작: 일반적인 초기 DHCPv4 교환은 DORA, 즉 Discover→Offer→Request→Acknowledge입니다. 로컬 브로드캐스트나 DHCP 릴레이를 통해 서버에 도달합니다. 임대에는 IPv4 주소·서브넷 마스크·게이트웨이·DNS 설정이 포함될 수 있고 갱신은 더 짧은 교환으로 이루어질 수 있습니다. DHCPv6는 다른 메시지를 사용하며, IPv6 기본 라우터 정보는 보통 Router Advertisement로 받습니다. SLAAC도 IPv6 주소 설정 방법입니다.
실무 포인트: 클라우드에서는 대부분 추상화되어 보이지 않지만, VPC의 DHCP 옵션 세트로 DNS 서버와 도메인 네임을 지정하는 지점에서 다시 만납니다. 온프레미스 DNS를 쓰는 하이브리드 구성에서 이름 해석이 안 될 때 확인해야 하는 설정입니다.
SSH
정의: 암호화된 원격 셸 접속과 터널링을 제공하는 프로토콜.
동작: 서버 호스트 키로 서버를 인증하고, 키 교환으로 세션 키를 만든 뒤 사용자를 인증합니다(공개키 또는 비밀번호). 이후 모든 트래픽이 암호화됩니다. 원격 셸 외에 포트 포워딩, SFTP, 에이전트 포워딩까지 지원합니다.
실무 포인트: 정책에 맞춰 포워딩을 제한하고 서버 호스트 키를 검증하세요. 침해된 호스트가 전달된 에이전트 소켓에 접근하면 에이전트에 서명·인증을 요청할 수 있지만, 보통 개인키 자체가 그 호스트로 복사되는 것은 아닙니다. 에이전트 포워딩이 필요 없다면 점프 호스트(ProxyJump)를 검토하세요. 원시 키에는 자체 만료가 없지만 OpenSSH 인증서 유효기간이나 authorized_keys의 만료 제한을 사용할 수 있습니다. 퇴사자의 접근을 제거하고 자격 증명을 교체·폐기해야 합니다.
AWS Systems Manager Session Manager는 관리형 노드·IAM 권한·서비스 연결을 설정하면 인바운드 SSH 포트나 SSH 키 배포 없이 셸 접속을 제공할 수 있습니다. CloudTrail은 API 활동을 기록하며 셸 내용을 CloudWatch Logs/S3에 기록하려면 별도 설정이 필요합니다. Session Manager의 SSH·포트 포워딩 세션에는 세션 내용 로깅을 사용할 수 없습니다. IAM 기반 접속이라는 이유만으로 모든 명령이 기록되지는 않습니다.
SMTP
정의: 메일 서버 간에 메시지를 전달하는 프로토콜.
동작: 클라이언트는 제출 서버에 메일을 보내고, SMTP 서버는 보통 MX 조회로 경로를 정해 메시지를 릴레이하고 수신합니다. IMAP·POP3는 사용자가 이미 사서함에 저장된 메시지에 접근·조회하는 프로토콜이며 SMTP 서버의 수신 역할을 대체하지 않습니다.
실무 포인트: SMTP 인증과 TLS는 제출·전송을 보호하지만 표시되는 발신 도메인을 자체 증명하지는 않습니다. 다음 세 가지 도메인 인증 체계가 상호 보완적으로 사용됩니다.
- SPF — 봉투 MAIL FROM 또는 HELO 식별자의 발신 호스트를 허용합니다. 표시되는 From 헤더와 자동으로 일치하는 것은 아닙니다.
- DKIM — 서명 도메인의 DNS 키로 서명 대상 메시지 내용의 서명을 검증합니다. 서명 도메인은 표시되는 From 도메인과 다를 수 있습니다.
- DMARC — 표시되는 From 도메인과 통과한 SPF 또는 DKIM 식별자의 정렬(alignment)을 요구하고 처리·리포팅 정책을 게시합니다.
필요에 맞게 SPF·DKIM·DMARC를 함께 설정하고 보고서와 전달·메일링리스트 동작을 확인하세요. DMARC는 정렬된 인증 방식 하나가 통과해도 성공할 수 있습니다. 이 통제들이 전달 성공을 보장하거나 표시 이름·유사 도메인을 이용한 사칭까지 모두 막지는 않으며 수신자도 자체 정책을 적용합니다.
HTTP/3
정의: QUIC 위에서 동작하는 HTTP의 세 번째 메이저 버전.
동작: HTTP 의미론은 버전 간에 공유하지만 HTTP/3은 QUIC 스트림과 자체 프레이밍·매핑을 사용합니다. TCP의 스트림 간 순서 의존성을 제거하지만 스트림 내부 손실, QPACK 의존성, 공유 혼잡 제어에 따른 지연은 남습니다. 일반적인 전체 핸드셰이크는 약 1 RTT이고 지원되는 마이그레이션으로 주소 변경 후 연결을 이어갈 수 있습니다. 독립적인 스트림 전달에 대응하는 QPACK이 HPACK을 대체합니다.
실무 포인트: 클라이언트는 Alt-Svc, 사전 정보, 지원 프로토콜을 알리는 HTTPS DNS 레코드로 HTTP/3을 발견할 수 있습니다. Alt-Svc는 앞선 TCP 연결에서 배울 수 있고, HTTPS 레코드를 지원하는 클라이언트는 그 교환 전에 HTTP/3을 발견할 수 있습니다. 어느 방식도 도달성이나 일정한 지연 절감을 보장하지 않습니다.
독립 전달과 통합 핸드셰이크는 손실이나 지연이 큰 경로에서 도움이 될 수 있습니다. 실제 지연·처리량·CPU 비용은 구현·오프로드·워크로드·네트워크 조건에 따라 다릅니다. 항상 유리하거나 불리하다고 가정하지 말고 대표적인 모바일·데이터센터 트래픽을 측정하세요.
세 세대 비교로 보는 진화 방향:
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| 전송 | TCP | TCP | QUIC (UDP) |
| 연결당 요청 | 순차, 또는 응답 순서를 지키는 파이프라이닝 | 다중화 | 다중화 |
| HOL 블로킹 | 응답 순서와 TCP 전달 | 스트림 간 TCP 순서 의존성 | TCP 스트림 간 순서 의존성 제거; 다른 블로킹은 남음 |
| 헤더 압축 | 없음 | HPACK | QPACK |
| 암호화 | 선택(HTTPS) | HTTPS는 TLS 사용; 평문 HTTP/2도 존재 | QUIC에 TLS 1.3 통합 |
다중화는 순서 의존성이 발생하는 위치를 바꿉니다. HTTP/3은 블로킹 원인 하나를 줄이지만 스케줄링·흐름 제어·애플리케이션 의존성까지 모두 제거하지는 않습니다.
HTTP/1.1 요청과 응답 읽기
HTTP 버전들은 메서드·상태 코드·필드의 의미를 공유합니다. HTTP/1.1에서는 이 개념을 시작 줄 → 헤더 필드 줄 → 빈 줄 → 선택적 본문 형태로 볼 수 있습니다. 본문에는 텍스트나 바이너리가 들어갈 수 있습니다. “텍스트 형식의 HTTP/1.1”은 시작 줄과 헤더를 설명하는 말이지 모든 페이로드가 텍스트라는 뜻은 아닙니다.
아래는 설명용 HTTP/1.1 메시지이며 캡처 결과나 실행 명령이 아닙니다. 읽기 쉽도록 화면에는 LF 줄바꿈을 표시했습니다. 실제 전송에서는 시작 줄과 각 헤더 줄을 **CRLF(\r\n)**로 끝내고, 추가 CRLF로 헤더 영역을 종료합니다. 두 본문은 모두 ASCII 5바이트인 hello이며 끝에 개행이 없습니다. 코드 블록을 닫기 위해 화면에 표시된 마지막 줄바꿈은 본문에 포함하지 않습니다.
클라이언트 → 서버:
POST /echo HTTP/1.1
Host: example.test
Content-Type: text/plain; charset=utf-8
Content-Length: 5
hello서버 → 클라이언트:
HTTP/1.1 200 OK
Date: Mon, 14 Sep 2026 00:00:00 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 5
hello| 구성 요소 | 읽는 방법 |
|---|---|
| 요청 줄 | POST는 메서드, /echo는 요청 대상(여기서는 경로), HTTP/1.1은 버전입니다. 필수 Host 필드는 대상 호스트 이름과 선택적 포트(authority)를 지정합니다. |
| 상태 줄 | HTTP/1.1은 버전, 200은 상태 코드, OK는 선택적인 사유 문구입니다. 결과 해석에는 코드를 사용합니다. |
| 헤더 필드 | Name: value 줄에 메타데이터를 담으며 필드 이름은 대소문자를 구분하지 않습니다. Content-Type은 표현의 미디어 유형과 여기서는 문자셋을 설명합니다. |
| 빈 줄 | 헤더 영역을 끝냅니다. 뒤따르는 본문의 종료 위치까지 정하지는 않습니다. |
| 본문 | 실제 콘텐츠 바이트입니다. 여기서 Content-Length: 5는 시작 줄·헤더·구분자를 제외한 5바이트를 지정합니다. 유니코드 문자 수가 아닌 바이트 수를 셉니다. |
의미와 프레이밍은 서로 다른 질문에 답합니다. 메서드는 요청 동작을 나타냅니다. GET은 표현 조회, HEAD는 응답 콘텐츠 없이 대응하는 응답 메타데이터 조회, POST는 대상에 전달한 콘텐츠의 처리를 요청합니다. 상태 코드의 첫 자리는 1xx 정보, 2xx 성공, 3xx 리다이렉션, 4xx 클라이언트 오류, 5xx 서버 오류로 결과를 요약합니다. Content-Type은 콘텐츠 해석 방법을 알려주지만 경계를 정하지 않습니다. 이러한 공통 의미는 RFC 9110을 참고하세요.
HTTP/1.1 프레이밍은 재사용하는 TCP 스트림에서 어느 바이트까지가 한 메시지인지 결정합니다. 일반적인 본문 포함 메시지에서 Transfer-Encoding이 없다면 유효한 Content-Length가 길이를 지정합니다. Transfer-Encoding: chunked를 사용하면 청크 크기와 마지막 0 크기 청크, 그 뒤의 트레일러(있는 경우)와 최종 빈 줄로 경계를 정합니다. 송신자는 두 필드를 함께 보내면 안 됩니다. 일부 응답은 연결 종료로 경계를 정하지만 TCP 패킷 경계는 HTTP 메시지 경계가 아닙니다.
메서드·상태 규칙이 먼저 적용됩니다. HEAD 응답과 1xx·204·304 응답에는 허용된 메타데이터가 표현을 설명하더라도 메시지 본문이 없습니다. 성공한 CONNECT 응답은 터널을 시작합니다. 길이와 전송 코딩이 모두 없는 요청에도 본문이 없습니다. 이를 구분해야 다음 메시지를 콘텐츠로 잘못 읽지 않습니다(RFC 9112 §§2–6).
HTTP/2와 HTTP/3도 의미는 유지하지만 바이너리 프레이밍을 사용합니다. 텍스트 시작 줄과 CRLF 경계 대신 HEADERS·DATA 프레임 등을 사용하며, HTTP/2는 TCP 위에서, HTTP/3은 QUIC 스트림 위에서 메시지를 전달합니다. 둘 다 HTTP/1.1의 chunked 전송 코딩을 사용하지 않습니다. 도구가 디코딩한 필드를 읽기 쉬운 텍스트로 보여주어도 실제 전송 인코딩은 다를 수 있습니다(RFC 9113, RFC 9114).
HTTPS에서는 TLS가 전송 중인 HTTP 헤더와 본문을 보호하므로 세션 비밀값 없는 수동 캡처에서 이 평문을 읽을 수 없습니다(RFC 8446 §5). QUIC도 HTTP/3 애플리케이션 데이터를 보호합니다. 권한이 있는 끝점이나 TLS 종료 지점에서 디코딩된 메시지를 확인하고 어느 연결 구간을 관측하는지 구분하세요.
📎 Linux HTTP 메시지 실습을 진행한 뒤 같은 구분을 컨테이너 서비스·쿠버네티스 Ingress·AWS 로드밸런서에 적용하세요.
WebSocket
정의: 하나의 연결에서 양방향 메시지를 주고받는 애플리케이션 프로토콜.
동작: HTTP/1.1 핸드셰이크는 Upgrade와 성공 응답 101을 사용합니다. HTTP/2·HTTP/3은 지원되는 경우 Extended CONNECT를 사용합니다(RFC 8441·9220). 연결 후 양쪽은 반복적인 HTTP 폴링 없이 WebSocket 메시지를 전송할 수 있습니다.
실무 포인트: 장기 연결을 고려해 해당 유휴 타임아웃보다 짧은 하트비트, 배포 시 점진적 연결 종료, 지터를 넣은 재접속 백오프를 설계하세요. 소켓은 연결을 소유한 인스턴스에 남습니다. 공유 애플리케이션 상태나 Redis Pub/Sub 같은 메시징은 인스턴스 간 이벤트를 전달할 수 있지만 살아 있는 소켓을 이전하거나 자체적으로 영속 전달을 제공하지는 않습니다. 협상된 HTTP 버전의 핸드셰이크와 프록시 지원을 확인하세요.
WebRTC
정의: 브라우저·미디어 서버 등 호환되는 끝점 사이에서 실시간 미디어와 데이터를 교환하는 API와 프로토콜.
동작: NAT는 직접 도달을 어렵게 할 수 있지만 양쪽이 NAT 뒤에 있어도 직접 연결에 성공할 수 있습니다. ICE는 호스트, STUN으로 알아낸 서버 반사(server-reflexive), TURN 릴레이 후보를 교환하고 검사합니다. 애플리케이션 시그널링이 세션 설명과 후보를 전달하며 실제 경로는 연결 검사와 정책에 따라 선택됩니다. 미디어는 SRTP를 사용하며 보통 DTLS-SRTP로 키를 설정합니다. 데이터 채널은 SCTP over DTLS를 사용합니다.
실무 포인트: TURN 사용량은 대역폭·인프라 비용에 영향을 주며 직접 미디어 경로에서도 시그널링·STUN 등 서비스 비용은 남습니다. NAT 매핑·필터링과 방화벽 동작이 연결에 영향을 주므로 “대칭형 NAT”라는 분류만으로 중계가 항상 필수라고 단정할 수 없습니다. TURN 폴백 비용을 계획하고 실제 망을 시험하세요. 다자간 통화에서는 서버 대역폭·연산을 사용해 완전 P2P 메시보다 클라이언트 업로드를 줄이는 SFU가 흔한 선택입니다.
gRPC
정의: 표준 네이티브 전송에 HTTP/2를 사용하며 보통 Protocol Buffers 서비스·메시지 스키마를 사용하는 RPC 프레임워크.
동작: Protocol Buffers 정의로 클라이언트·서버 코드를 생성할 수 있고 단일 요청·응답, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍을 지원합니다. 바이너리 인코딩은 간결할 수 있지만 JSON 대비 크기·속도는 데이터·구현·압축에 따라 달라지며 프로토콜 보장이 아닙니다.
실무 포인트: 네이티브 gRPC는 여러 서비스 API에 적합합니다. 브라우저 API가 네이티브 gRPC의 모든 요구 기능을 노출하지 않으므로 브라우저는 보통 gRPC-Web과 호환 서버 또는 변환 프록시를 사용합니다. 스트리밍 지원 범위는 구현에 따라 다릅니다. 스키마를 이해하는 도구로 내용을 확인하고 디버깅하세요.
gRPC 채널은 0개 이상의 HTTP/2 연결을 사용할 수 있고 많은 RPC가 장기 연결을 공유할 수 있습니다. L4 분산은 연결별 백엔드를 선택하므로 연결 풀이 작으면 RPC 트래픽이 집중될 수 있으며 RPC별 분산을 보장하지 않습니다. 적절한 클라이언트 정책이나 gRPC를 이해하는 L7 프록시를 검토하세요. 서비스 메시가 그 프록시를 제공할 수도 있습니다. 이미 수립된 스트림은 선택된 백엔드에 남습니다. 스키마 변경 시 삭제한 Protocol Buffers 필드 번호·이름을 예약하고 번호를 재사용하지 마세요.
📎 Istio에서의 gRPC 처리는 Istio gRPC 고급 참고.
MQTT
정의: 발행-구독 모델의 경량 메시징 프로토콜.
동작: 클라이언트가 브로커에 연결해 토픽으로 발행·구독합니다. 고정 헤더는 최소 2바이트지만 실제 패킷에는 가변 헤더·속성·페이로드가 추가될 수 있습니다. QoS 0/1/2는 해당 송신자–수신자 구간의 프로토콜 전달에서 최대 1회·최소 1회·정확히 1회를 제공합니다. 발행자→브로커와 브로커→구독자 전달은 별도입니다. 설정된 Will은 특정 연결 종료 조건에서 발행될 수 있으며 MQTT 5의 Will Delay와 재접속 동작에 따라 시점이 달라집니다.
실무 포인트: 손실·중복 허용 범위와 비용에 따라 QoS를 선택하세요. 성공하는 일반적인 QoS 2 전달은 PUBLISH·PUBREC·PUBREL·PUBCOMP를 교환하지만 애플리케이션의 데이터베이스 부수 효과나 전체 업무 흐름을 정확히 한 번 실행하게 만들지는 않습니다. QoS 1과 애플리케이션 중복 제거도 선택지입니다. 제품에 맞춰 브로커 가용성, 세션·메시지 영속 상태와 복구를 설계하세요. TLS와 적절한 디바이스 인증·인가를 사용하며 클라이언트 인증서는 발급·교체 관리가 필요한 한 가지 방법입니다.