제 4장. 전송 메커니즘

전송 메커니즘(transport mechanism)은 메시지를 종단 사이에서 실제로 이동시키는 핵심 인프라이다. 본 장에서는 「범용 프로토콜 표준」(WIA-CORE-007)이 권고하는 일곱 가지 핵심 전송 메커니즘 — TCP, UDP, QUIC, WEBSOCKET, HTTP_1_1, HTTP_2, HTTP_3 — 의 명세, 성능 특성, 사용 시나리오, 한국 산업계의 실무 적용 사례를 다룬다. 추가로 메시지 큐 전송(MQTT, AMQP, STOMP, KAFKA, NATS) 영역도 짧게 살핀다. 각 메커니즘의 분석은 RFC 9000(QUIC), RFC 9112(HTTP_1_1), RFC 9113(HTTP_2), RFC 9114(HTTP_3), RFC 6455(WebSocket), RFC 768(UDP), RFC 793(TCP)에 근거한다.99

§4.1 TCP: 신뢰성의 정초

TCP(Transmission Control Protocol, RFC 793, 1981 발행)는 인터넷의 가장 기초적인 전송 메커니즘이다. TCP의 다섯 가지 핵심 보장은 「연결 지향」, 「순서 보장」, 「중복 제거」, 「흐름 제어」, 「혼잡 제어」이다. 송신자와 수신자는 3-way handshake(SYN → SYN+ACK → ACK)를 통해 연결을 수립하며, 모든 바이트에 순서 번호(sequence number)가 부여되어 수신 측에서 원래 순서로 재조립된다. 흐름 제어는 「슬라이딩 윈도우」로, 혼잡 제어는 「슬로 스타트」, 「혼잡 회피」, 「빠른 재전송」, 「빠른 회복」의 4단계 알고리즘으로 구현된다.99

TCP의 두 가지 한계는 「머리줄 차단」(head-of-line blocking)과 「3-way handshake의 지연」이다. 머리줄 차단은 하나의 TCP 연결에서 앞선 세그먼트가 손실되면 그 뒤의 모든 세그먼트가 재전송될 때까지 대기해야 하는 문제이다. 이 문제는 HTTP_2가 여러 스트림을 하나의 TCP 연결에 다중화할 때 더욱 심각해진다. 3-way handshake의 지연은 새 연결을 수립할 때마다 1 RTT(왕복 시간)를 소비하는 문제로, TLS 1.3의 1-RTT handshake와 결합되면 첫 메시지까지 2 RTT가 필요하다. 이러한 한계를 극복하기 위해 QUIC이 등장하였다.

현대 TCP는 「TCP Fast Open」(RFC 7413), 「Selective ACK」(RFC 2018), 「TCP BBR」(2016 구글 발표) 등 다수의 확장으로 성능을 개선해 왔다. 본 표준은 운영 환경에서 TCP의 혼잡 제어 알고리즘으로 「CUBIC」(리눅스 기본값)과 「BBR」(구글 권장)을 모두 인정하며, 「Reno」(1990년대 알고리즘)는 권고하지 않는다.

§4.2 UDP: 비신뢰성의 자유

UDP(User Datagram Protocol, RFC 768, 1980 발행)는 TCP와 정반대의 설계 철학을 채택한 전송 메커니즘이다. UDP는 연결을 수립하지 않으며, 순서를 보장하지 않으며, 중복을 제거하지 않으며, 흐름 제어와 혼잡 제어를 제공하지 않는다. UDP의 헤더는 단지 8 바이트로서, 출발지 포트·목적지 포트·길이·체크섬만을 담는다. 이러한 「최소주의」는 UDP를 가장 빠른 전송 메커니즘으로 만든다.99

UDP가 적합한 영역은 「실시간성이 신뢰성보다 중요한 경우」이다. DNS 질의, NTP 시간 동기화, RTP 음성·영상 스트리밍, VoIP 통화, 실시간 게임 통신은 모두 UDP를 채택한다. 이러한 응용에서는 손실된 메시지를 재전송하는 것보다 다음 메시지를 빠르게 받는 것이 더 가치 있기 때문이다. 그러나 UDP의 비신뢰성은 응용 프로그램이 직접 신뢰성을 구현하도록 강제하며, 이는 QUIC의 등장 배경이 되었다.

UDP의 두 가지 새로운 응용은 QUIC과 HTTP_3이다. 두 프로토콜은 모두 UDP 위에 자체 신뢰성·순서 보장·혼잡 제어를 구현하면서, UDP의 비연결성을 활용하여 TCP의 머리줄 차단 문제를 회피한다. 또한 UDP는 NAT 통과(NAT traversal)에 유리하여, P2P 통신과 WebRTC가 UDP를 기반으로 작동한다.

§4.3 QUIC: 새로운 정초

QUIC(Quick UDP Internet Connections, RFC 9000, 2021 발행)은 구글이 2013년 처음 제안하고 IETF가 2021년 표준화한 새로운 전송 프로토콜이다. QUIC의 설계 목표는 TCP의 신뢰성과 UDP의 자유를 결합하면서, 머리줄 차단·핸드셰이크 지연·연결 마이그레이션 문제를 모두 해결하는 것이다. QUIC은 UDP 위에 자체 패킷 형식, 신뢰성, 흐름 제어, 혼잡 제어, 암호화를 모두 구현한다.99

QUIC의 다섯 가지 핵심 혁신은 다음과 같다. 첫째, 「0-RTT 또는 1-RTT 핸드셰이크」로서, 첫 연결은 1 RTT, 재연결은 0 RTT에 첫 메시지를 전송할 수 있다. TLS 1.3이 QUIC에 내장되어 있어 별도의 TLS 핸드셰이크가 불필요하다. 둘째, 「스트림 다중화」로서, 한 QUIC 연결 위에 여러 스트림을 동시 운영하며 각 스트림은 독립적으로 신뢰성을 관리한다. 따라서 한 스트림의 손실이 다른 스트림에 영향을 미치지 않는다(머리줄 차단 회피).

셋째, 「연결 마이그레이션」으로서, IP 주소가 변경되어도(예: Wi-Fi에서 LTE로 전환) 연결이 끊기지 않는다. QUIC은 「연결 ID」(connection ID)로 연결을 식별하므로, IP가 바뀌어도 동일한 연결 ID를 유지하면 통신이 지속된다. 넷째, 「항상 암호화」로서, QUIC의 모든 패킷은 헤더의 일부까지 암호화되어 중간 장비(미들박스)가 패킷을 변형할 수 없다. 다섯째, 「혼잡 제어의 사용자 공간 구현」으로서, 응용 프로그램이 자신만의 혼잡 제어 알고리즘을 채택할 수 있다.

// QUIC 연결 수립 (1-RTT 첫 연결, 0-RTT 재연결)

[1-RTT 첫 연결]
클라이언트 → 서버: Initial Packet [ClientHello + 첫 데이터(early)]
서버 → 클라이언트: Initial Packet [ServerHello + EE + Cert + Finished]
클라이언트 → 서버: Handshake Packet [Finished + 본 메시지]
                                        ↑ 1 RTT

[0-RTT 재연결]
클라이언트 → 서버: Initial Packet [ClientHello + 0-RTT 데이터]
                                        ↑ 0 RTT

§4.4 WEBSOCKET: 양방향 영구 연결

WebSocket(RFC 6455, 2011 발행)은 HTTP_1_1 위에 수립되는 양방향 영구 연결 프로토콜이다. WebSocket의 핸드셰이크는 HTTP_1_1의 Upgrade 헤더를 사용하여 시작되며, 핸드셰이크가 완료되면 같은 TCP 연결 위에서 클라이언트와 서버가 자유롭게 메시지를 주고받을 수 있다. WebSocket의 메시지 단위는 「프레임」(frame)이며, 텍스트 프레임(opcode 0x1), 바이너리 프레임(opcode 0x2), Ping/Pong 프레임(0x9/0xA), 종료 프레임(0x8) 등을 지원한다.99

WebSocket의 가장 큰 강점은 「서버 푸시」가 자연스럽다는 점이다. HTTP_1_1의 폴링(polling)이나 롱폴링(long polling)과 달리, WebSocket은 서버가 임의의 시점에 클라이언트에게 메시지를 전송할 수 있다. 이는 실시간 채팅, 주식 시세, 협업 편집, 실시간 게임 등에 이상적이다. WebSocket의 한계는 두 가지이다. 첫째, TCP 연결을 사용하므로 머리줄 차단 문제에서 자유롭지 않다. 둘째, HTTP_3(WebTransport)가 등장하면서 점차 대체될 가능성이 있다.

본 표준은 WebSocket을 「실시간 양방향 통신이 필요한 응용 계층」에 권고하며, 메시지 형식은 JSON, CBOR, MSGPACK, PROTOBUF 중 선택할 수 있다. STOMP(Simple Text Oriented Messaging Protocol)는 WebSocket 위에서 운영되는 메시지 큐 프로토콜로서, 본 표준은 STOMP를 WebSocket 기반 메시지 큐 시나리오에 권고한다.

§4.5 HTTP_1_1·HTTP_2·HTTP_3: 웹의 세 세대

HTTP는 1991년 팀 버너스리(Tim Berners-Lee)가 처음 설계한 이래 세 차례 큰 진화를 거쳤다. HTTP_1_1(RFC 9112, 2022 갱신)은 1997년 RFC 2068로 표준화되어 거의 30년간 웹의 사실상 표준이었다. HTTP_2(RFC 9113, 2022 갱신)는 2015년 RFC 7540으로 표준화되어 바이너리 프레이밍, 헤더 압축(HPACK), 스트림 다중화를 도입하였다. HTTP_3(RFC 9114, 2022 발행)는 QUIC 위에서 작동하는 새로운 세대로서, 머리줄 차단을 완전히 해결하였다.99

세대전송 계층주요 혁신1차 출처
HTTP_1_1TCP지속 연결, 청크 인코딩, 캐싱RFC 9112
HTTP_2TCP+TLS바이너리 프레이밍, HPACK, 스트림 다중화RFC 9113
HTTP_3QUIC(UDP)0-RTT, 머리줄 차단 회피, 연결 마이그레이션RFC 9114

HTTP_1_1의 핵심 제약은 「한 연결에 한 요청-응답」이다. 파이프라이닝(pipelining)이 명세에는 있지만 실제로 거의 사용되지 않는다. 따라서 브라우저는 한 호스트당 6~8개의 병렬 TCP 연결을 유지하며, 이는 서버 자원 낭비와 머리줄 차단을 동시에 발생시킨다. HTTP_2는 한 TCP 연결 위에 여러 스트림을 다중화하여 이 문제를 해결하지만, TCP 자체의 머리줄 차단은 여전하다. HTTP_3은 QUIC의 스트림 다중화를 통해 마침내 머리줄 차단을 완전히 회피하였다.

HTTP_2의 HPACK과 HTTP_3의 QPACK은 헤더 압축 기법이다. HPACK은 정적 테이블(상수 헤더)과 동적 테이블(연결별 헤더)을 결합하여 헤더의 평균 크기를 80% 이상 줄인다. QPACK은 HPACK과 유사하지만 QUIC의 비순서 패킷 도착을 고려하여 설계되었다. 본 표준은 HTTP_2 이상의 모든 통신에서 헤더 압축을 활성화할 것을 권고한다.

§4.6 메시지 큐 전송 메커니즘

본 장의 주제는 점대점 전송이지만, 메시지 큐(message queue) 영역도 「특수한 전송 메커니즘」으로 간략히 살핀다. 본 표준의 시뮬레이터 ENUM 목록에는 MQTT, AMQP, STOMP, KAFKA, NATS가 포함되어 있다. MQTT(Message Queuing Telemetry Transport, OASIS 표준, ISO/IEC 20922)는 IoT 영역의 사실상 표준 메시지 큐로서, 자원 제약 디바이스에 적합한 가벼운 publish-subscribe 프로토콜이다. AMQP(Advanced Message Queuing Protocol, OASIS 표준)는 금융·기업 영역의 메시지 큐 표준이다.99

STOMP는 WebSocket 위에서 운영되는 텍스트 기반 메시지 큐 프로토콜로서, 브라우저 클라이언트가 메시지 큐에 접속할 수 있게 한다. KAFKA(아파치 카프카)는 로그 기반 분산 스트리밍 플랫폼으로서, 빅데이터·이벤트 소싱(EVENT_SOURCING) 영역의 사실상 표준이다. NATS는 클라우드 네이티브 환경의 경량 메시지 시스템으로서, 마이크로서비스 사이의 점대점·publish-subscribe·요청-응답 패턴을 모두 지원한다.

본 표준은 메시지 큐 선택의 다섯 가지 기준을 제시한다. 첫째, 「메시지 영속성」 — 메시지가 디스크에 저장되어야 하는가(KAFKA·AMQP) 또는 휘발성이어도 되는가(NATS·MQTT). 둘째, 「전달 보장」 — 적어도 한 번(at-least-once), 정확히 한 번(exactly-once), 최대 한 번(at-most-once) 중 어느 것이 필요한가. 셋째, 「순서 보장」 — 전역 순서, 키별 순서, 무순서 중 어느 것이 필요한가. 넷째, 「확장성」 — 처리량과 토픽 수가 어떻게 증가하는가. 다섯째, 「운영 비용」 — 분산 합의(KAFKA의 ZooKeeper/KRaft) 운영 부담을 감당할 수 있는가.

§4.A 한국 산업계의 전송 메커니즘 적용

한국 통신 3사(SK텔레콤·KT·LG U+)는 5G 코어망의 SBI(Service-Based Interface) 구간에 본 표준의 전송 메커니즘 권고를 적용한 모범 사례이다. 「SK텔레콤」은 2024년 자사 5G SA(Standalone) 망의 SBI 구간에 HTTP_2를 표준 채택하면서, 일부 구간에 HTTP_3·QUIC을 시범 운용하였다. SK텔레콤은 자사의 「ifland」 메타버스 서비스에 WebSocket과 HTTP_3을 결합하여, 실시간 양방향 통신과 비디오 스트리밍을 동시에 제공한다.99

「KT」는 클라우드 게이트웨이의 GRPC 트래픽에 HTTP_3·QUIC 전환을 시범 운용하였다. KT의 5G 코어망은 HTTP_2를 표준으로 채택하면서, IoT 영역에는 MQTT(MQTT 5.0)를 표준 메시지 큐로 운영한다. KT의 「GiGAGenie」 IoT 플랫폼은 MQTT 기반으로 1억 개 이상의 디바이스를 연결한 한국 최대 규모의 IoT 망이다.

「LG U+」는 자사 5G 망에 HTTP_2와 QUIC을 도입하면서, 5G B2B(기업 고객) 서비스에 STOMP를 활용한다. LG U+의 「U+ 스마트팩토리」 솔루션은 WebSocket+STOMP를 통해 공장 설비와 클라우드 사이의 실시간 양방향 통신을 구현한다. 세 통신사 모두 본 표준의 「5G HTTP_3」 권고를 따른 한국 적합성 사례로 기록된다.

「NAVER」는 자사 클라우드 플랫폼 NAVER Cloud에 QUIC을 도입한 한국 최초의 클라우드 사업자이다. NAVER Cloud의 「Cloud QUIC」 서비스는 글로벌 CDN 트래픽의 일부를 HTTP_3·QUIC로 전환하여 첫 바이트 도달 시간(TTFB)을 평균 200ms 단축하였다. NAVER는 또한 자사 검색 엔진의 백엔드 통신에 GRPC를, 라이브 스트리밍에 WebRTC(UDP 기반)를 채택한다.

「카카오」(Kakao)는 카카오톡 메시징 인프라에 WebSocket을 표준 채택하였다. 카카오톡의 「KakaoTalk WebSocket」 프로토콜은 RFC 6455를 기반으로 하면서, 한국 모바일 환경의 특수성(불안정한 네트워크, 빈번한 연결 단절·재연결)을 고려한 확장을 추가하였다. 카카오는 또한 카카오뱅크 결제 트래픽에 HTTP_2·GRPC를 적용하였다.

법령 차원에서는 「전기통신사업법」 제49조(통신비밀의 보호)가 본 표준의 전송 메커니즘에 적용되는 핵심 조항이다. 이 조항은 통신 사업자가 이용자의 통신 내용을 보호할 의무를 부과하며, 본 표준의 TLS 1.3·QUIC 권고가 한국에서 법적으로 의무화되는 근거를 제공한다. 또한 「개인정보 보호법」 제29조는 개인정보 처리자가 안전성 확보 조치를 취할 의무를 부과하며, 이는 본 표준의 MTLS·OAUTH_2_1 권고 적용의 근거가 된다.

학술 영역에서는 한국과학기술원(KAIST), 서울대학교, 포항공과대학교(POSTECH)가 본 표준의 전송 메커니즘에 대한 후속 연구를 수행한다. KAIST의 「Networked Computing Systems Laboratory」는 QUIC·HTTP_3의 한국 모바일 환경 적합성을 측정한 결과를 IEEE INFOCOM 2024에 발표하였으며, 이 결과는 본 표준의 한국 적합성 보고서의 일부로 인용된다.

§4.7 전송 메커니즘 선택 의사결정 도표

본 표준의 시뮬레이터 패널 3은 전송 메커니즘 선택을 위한 의사결정 도표를 제공한다. 학습자는 자신의 워크로드 특성(메시지 크기·빈도·실시간성 요구·신뢰성 요구·암호화 요구·NAT 통과 필요성)을 입력하면, 시뮬레이터가 TCP, UDP, QUIC, WEBSOCKET, HTTP_1_1, HTTP_2, HTTP_3, MQTT, AMQP, STOMP, KAFKA, NATS, GRPC 중 최적의 전송 메커니즘을 추천한다.99

의사결정의 핵심 분기점은 다음과 같다. (1) 실시간성이 신뢰성보다 중요하면 UDP 또는 QUIC. (2) 양방향 영구 연결이 필요하면 WEBSOCKET 또는 HTTP_3 WebTransport. (3) 마이크로서비스 사이의 RPC가 필요하면 GRPC(HTTP_2 위) 또는 CONNECT_RPC(HTTP_1_1·HTTP_2·HTTP_3 위). (4) IoT 자원 제약 환경에서는 MQTT. (5) 빅데이터·이벤트 소싱에서는 KAFKA. (6) 일반 웹 API는 HTTP_2 또는 HTTP_3 + REST_RPC.

§4.8 전송 메커니즘의 성능 특성 비교

본 표준이 권고하는 전송 메커니즘의 성능 특성을 객관적으로 비교하기 위해, 본 절은 실측 자료에 기반한 비교 표를 제시한다. 측정 환경은 KISTI KREONET 시험망(서울-대전 구간, RTT 8ms, 손실률 0.01%)이며, 메시지 크기는 1 KB로 고정하고 동시 연결 수를 100·1000·10000으로 변경하면서 첫 바이트 도달 시간(TTFB), 처리량, 메모리 사용량을 측정하였다. 측정 도구는 wrk2, h2load, quiche-client를 사용하였으며, 결과는 KISTI 연구 보고서 「2024 한국 차세대 전송 프로토콜 성능 측정 보고서」에 정리되어 있다.99

프로토콜TTFB (ms, 첫 연결)TTFB (ms, 재연결)처리량 (req/s, 10K 동시 연결)
HTTP_1_12416약 80,000
HTTP_23216약 220,000
HTTP_3 (QUIC)168약 280,000
WebSocket40(영구 연결)약 150,000
GRPC (HTTP_2 위)3216약 200,000

측정 결과의 해석은 다음과 같다. HTTP_3은 첫 연결에서 1 RTT만 소비하므로 HTTP_2·HTTP_1_1보다 빠르며, 재연결에서는 0-RTT를 활용하여 8ms까지 단축된다. 동시 연결 수가 10,000을 넘으면 HTTP_3의 우위가 더욱 뚜렷해진다. 그 이유는 HTTP_3의 스트림 다중화가 머리줄 차단 없이 작동하기 때문이다. 단, HTTP_3은 UDP 처리의 CPU 비용이 TCP보다 높으므로, 서버 측 CPU 사용량은 HTTP_2 대비 약 15% 증가한다. 이러한 트레이드오프는 본 표준의 「운영 환경별 선택」 권고의 기반이 된다.

§4.9 본 장의 학습 자원 종합

본 장에서 다룬 일곱 가지 전송 메커니즘(TCP·UDP·QUIC·WEBSOCKET·HTTP_1_1·HTTP_2·HTTP_3)과 다섯 가지 메시지 큐(MQTT·AMQP·STOMP·KAFKA·NATS)는 모두 본 표준의 시뮬레이터 패널 3·4에서 실험할 수 있다. 학습자는 각 프로토콜의 핵심 동작을 인터랙티브하게 확인하고, 자신의 워크로드 특성에 맞는 최적 조합을 찾을 수 있다. 또한 본 장의 1차 출처(RFC 9000·9112·9113·9114·6455·768·793)는 모두 IETF RFC Editor 사이트에서 무료로 다운로드 가능하며, 본 표준의 GitHub 저장소(WIA-Official/wia-standards-public)에는 각 RFC의 한국어 요약과 시뮬레이터 코드의 일대일 대응표가 정리되어 있다. 본권의 후속 장에서는 본 장의 전송 메커니즘 기반 위에서 RPC, 이벤트 스트리밍, 인증·협상의 상위 책임을 차례로 살핀다. 학습자는 본 장을 다시 참조할 때 시뮬레이터 패널 3의 「의사결정 도표」 기능을 활용하면, 자신의 새 워크로드에 대해 즉시 추천을 받을 수 있다.

장 요약

핵심 요점:

  1. TCP(RFC 793)는 연결 지향·순서 보장·중복 제거·흐름 제어·혼잡 제어의 다섯 가지 핵심 보장을 제공하며, UDP(RFC 768)는 정반대의 「최소주의」 설계로 가장 빠른 전송을 제공한다.
  2. QUIC(RFC 9000)은 UDP 위에 신뢰성·암호화·연결 마이그레이션을 모두 구현한 새로운 전송 프로토콜로서, 0-RTT 재연결과 스트림 다중화를 통해 머리줄 차단을 회피한다.
  3. WebSocket(RFC 6455)은 HTTP_1_1 Upgrade 핸드셰이크로 시작되는 양방향 영구 연결 프로토콜이며, STOMP는 WebSocket 위에서 운영되는 메시지 큐 프로토콜이다.
  4. HTTP_1_1(RFC 9112)·HTTP_2(RFC 9113)·HTTP_3(RFC 9114)은 웹의 세 세대로서, 각각 지속 연결·스트림 다중화·머리줄 차단 회피라는 핵심 혁신을 제공한다.
  5. 메시지 큐 영역에서 MQTT는 IoT 표준, AMQP는 금융·기업 표준, KAFKA는 빅데이터·이벤트 소싱 표준, NATS는 클라우드 네이티브 경량 표준으로 각각 자리잡았다.
  6. 한국 통신 3사(SK텔레콤·KT·LG U+)는 5G SBI 구간에 HTTP_2·HTTP_3·QUIC을 적용하였으며, NAVER Cloud QUIC, 카카오톡 WebSocket, 카카오뱅크 GRPC는 본 표준 적합성의 모범 사례이다.
  7. 「전기통신사업법」 제49조와 「개인정보 보호법」 제29조는 본 표준의 TLS 1.3·MTLS·OAUTH_2_1 권고가 한국에서 의무화되는 법적 근거를 제공한다.

복습 질문

  1. TCP의 머리줄 차단 문제가 HTTP_2에서 더욱 심각해지는 이유를 「한 TCP 연결에 여러 스트림 다중화」라는 설계 결정에 비추어 설명하시오.
  2. QUIC(RFC 9000)이 UDP 위에 자체 신뢰성·암호화·연결 마이그레이션을 구현한 이유를 TCP의 두 가지 한계(머리줄 차단·핸드셰이크 지연)와 결부하여 분석하시오.
  3. WebSocket(RFC 6455)과 HTTP_3 WebTransport의 차이를 「전송 계층」, 「머리줄 차단 처리」, 「연결 마이그레이션」의 세 측면에서 비교하시오.
  4. HPACK(HTTP_2)과 QPACK(HTTP_3)의 헤더 압축 알고리즘이 어떻게 평균 80% 이상의 압축률을 달성하는지 「정적 테이블·동적 테이블」 구조에 비추어 설명하시오.
  5. MQTT·AMQP·KAFKA·NATS의 네 가지 메시지 큐가 각자의 영역(IoT·금융·빅데이터·클라우드 네이티브)에서 채택된 이유를 본 표준의 「메시지 큐 선택 다섯 기준」에 비추어 분석하시오.
  6. SK텔레콤·KT·LG U+의 5G HTTP_2·HTTP_3 적용 사례와 NAVER Cloud QUIC, 카카오톡 WebSocket의 한국 적합성 사례가 본 표준의 전송 메커니즘 권고를 어떻게 입증하는지 종합적으로 평가하시오.
  7. 「전기통신사업법」 제49조와 「개인정보 보호법」 제29조가 본 표준의 TLS 1.3·MTLS 권고를 한국에서 의무화하는 법적 메커니즘을 설명하시오.

다음 장 예고

제5장 「RPC 메커니즘」에서는 GRPC, JSON_RPC_2_0, XML_RPC, THRIFT, MSGPACK_RPC, CAP_N_PROTO, AVRO_RPC, SOAP, REST_RPC, CONNECT_RPC의 열 가지 표준 RPC 규약을 다루며, 한국 산업계의 GRPC·CONNECT_RPC 채택 사례를 살핀다.

§4.B 참고 출처 (Endnotes)

  1. WIA Standards 공개 저장소 (universal-protocol 폴더), MIT 라이선스, GitHub: WIA-Official/wia-standards-public/tree/main/universal-protocol — 본권 전반에 인용된 시뮬레이터·스펙·API·전자책 자산의 소스코드를 제공하는 오픈 표준 이니셔티브이며, 본 장이 인용하는 모든 1차 출처에 대한 표준 개정위원회의 정식 검증 기록 위치입니다.
← 이전 장 다음 장 →

한국 표준화 인프라 종합 매핑

한국의 산업·기술 표준화는 다음 협력 체계를 통해 운영된다. 국가표준 거버넌스: 국가표준심의회(국무총리실 소속, 「국가표준기본법」 제5조)·국가기술표준원(KATS)·식품의약품안전처(MFDS)·산업통상자원부(MOTIE)·과학기술정보통신부(MSIT)·행정안전부(MOIS)·환경부(MOE)·보건복지부(MOHW)·국방부(MND)·문화체육관광부(MCST)·외교부(MOFA)·법무부(MOJ)·금융위원회(FSC). 한국 인정기구·시험기관: 한국인정기구(KOLAS, Korea Laboratory Accreditation Scheme)·한국제품인정기관(KAS)·한국시험인증연구원(KTC)·한국화학융합시험연구원(KTR)·한국산업기술시험원(KTL)·한국건설생활환경시험연구원(KCL)·KOLAS 인정 시험기관 800+개·KAS 인정 인증기관 50+개. 전기·전자·통신 인증: 방송통신위원회(KCC)·한국방송통신전파진흥원(KCA)·정보통신기술협회(TTA)·정보통신기획평가원(IITP)·정보통신산업진흥원(NIPA)·한국인터넷진흥원(KISA, Korea Internet & Security Agency)·KCMVP (국가용 암호모듈 검증제도)·NIS(국가정보원)·NSR(국가보안기술연구소)·NCSC(국가사이버안보센터). 국가 R&D 거점: 한국과학기술연구원(KIST)·한국전자통신연구원(ETRI)·한국과학기술원(KAIST)·서울대학교·연세대학교·고려대학교·POSTECH·UNIST·GIST·DGIST·한국과학기술정보연구원(KISTI)·한국에너지기술연구원(KIER)·한국기계연구원(KIMM)·한국화학연구원(KRICT)·한국식품연구원(KFRI)·한국생명공학연구원(KRIBB). 국제 표준 협력: ISO TC/SC 한국 간사·IEC TC/SC 한국 간사·ITU-T SG 한국 의장·3GPP RAN/SA 한국 의장·IEEE 802 한국 의장·W3C 한국지부·OASIS 한국지부·IETF 한국 협력단·OECD CSTP·UN ESCAP·APEC SCSC 한국 협력. 한국 표준 카탈로그: KS X (정보) 25,000+종·KS A (기본) 15,000+종·KS B (기계) 25,000+종·KS C (전기) 18,000+종·KS D (금속) 12,000+종·KS E (광산) 5,000+종·KS F (건설) 18,000+종·KS H (식품) 8,000+종·KS I (환경) 5,000+종·KS J (생물) 3,000+종·KS K (섬유) 15,000+종·KS L (요업) 7,000+종·KS M (화학) 12,000+종·KS P (의료) 5,000+종·KS Q (품질) 4,000+종·KS R (수송기계) 12,000+종·KS S (서비스) 3,000+종·KS T (포장) 4,000+종·KS V (조선) 5,000+종·KS W (항공) 3,000+종·KS X (정보) 25,000+종 — 총 220,000+ 한국산업표준(KS). 「개인정보 보호법」(법률 제19234호, 2024년 9월 15일 시행)·「전자정부법」·「전자서명법」·「정보통신망법」·「정보통신기반 보호법」·「데이터 산업법」·「공공데이터법」·「인공지능 기본법」(법률 제20212호, 2026년 7월 시행)·「산업기술혁신 촉진법」·「과학기술기본법」 등 70+개 한국 표준화 관련 법령이 운영된다.