# IETF

## 개요

**IETF**(Internet Engineering Force, 인터넷 엔지니링 태스크 포스)는 인넷의 설계, 개발 운영을 위한 기술 표준을 제정하는 국제적인 자율 표준화 기입니다. IETF 인터넷의 핵심 프로토콜인 TCP/IP, HTTP, SMTP, DNS 등 대부분의 기반 기술을 개발하고 유지보수하며, 인터넷이 안정적이고 확장 가능하게 작동할 수 있도록 하는 데 중요한 역할을 합니다. 독립적인 비영리 조직으로 운영되며, 회원제가 아닌 누구나 참여할 수 있는 개방형 구조를 가지고 있습니다.

IETF는 기술 중심의 실용적 접근을 중시하며, "거의 작동하는 것(running code)"을 우선시하는 철학을 따릅니다. 즉, 이론적인 설계보다 실제로 구현되어 동작하는 기술을 표준화하는 데 초점을 둡니다. 이러한 특성 덕분에 IETF는 인터넷 기술의 진화에서 핵심적인 동력으로 평가받고 있습니다.

## 조직 구조 운영 방식

### 참여 방식

IETF는 누구나 참여할 수 있는 개방형 커뮤니티입니다. 개발자, 연구자, 기업 소속 엔지니어, 정부 관계자 등 다양한 이해관계자가 기술 논의에 참여할 수 있습니다. 주요 활동은 **워킹 그룹**(Working Group)을 중심으로 이루어지며, 각 그룹은 특정 기술 주제(예: 보안, 네트워크, 응용 프로토콜 등)에 집중합니다.

워킹 그룹은 IETF의 공식 메일링 리스트를 통해 논의를 진행하며, 정기적으로 연 3회 정도 **IETF 미팅**(IETF Meeting)을 개최합니다. 이 미팅은 전 세계에서 순회 개최되며, 대면 또는 원격으로 참여할 수 있습니다.

### 리더십 구조

IETF는 다음과 같은 주요 기구들로 구성됩니다:

- **IESG**(Internet Engineering Steering Group): 기술 문서(요청 평가서, RFC)의 기술적 승인을 담당합니다. 워킹 그룹의 활동을 감독하며, 표준화 과정의 흐름을 관리합니다.
- **IAB**(Internet Architecture Board): 인터넷의 장기적인 기술 아키텍처와 전략을 감독하며, IETF의 정책적 문제를 다룹니다. 또한 IESG와 협력하여 표준화 프로세스의 품질을 유지합니다.
- **IETF 사무국**(IETF Secretariat): 행정 및 회의 운영을 지원하며, IETF의 일상적인 운영을 뒷받침합니다.

## 표준화 프로세스

IETF의 표준화 과정은 문서 중심으로 진행되며, 최종 산출물은 **RFC**(Request for Comments, 의견 요청서)라는 형식으로 출판됩니다. RFC는 기술 사양, 프로토콜 설명, 최고의 실천 방법(Best Current Practice) 등을 포함할 수 있습니다.

### RFC 문서의 단계

IETF의 표준화 문서는 다음과 같은 단계를 거칩니다:

1. **인터넷-드래프트**(Internet-Draft): 초기 제안 단계의 문서로, 6개월마다 갱신하지 않으면 만료됩니다.
2. **정보 제공용**(Informational): 기술적 정보를 제공하지만 표준이 아닌 문서.
3. **실험용**(Experimental): 새로운 기술을 실험적으로 제안하는 문서.
4. **최고의 실천 방법**(Best Current Practice, BCP): 운영상의 권고사항을 제시.
5. **표준 트랙**(Standards Track): 표준으로 채택될 수 있는 문서로, 다음 세 단계를 포함:
   - Proposed Standard (제안된 표준)
   - Draft Standard (초안 표준) – 현재는 거의 사용되지 않음
   - Internet Standard (인터넷 표준)

대표적인 RFC 예시:
- **RFC 791**: IPv4 프로토콜
- **RFC 2616**: HTTP/1.1 (현재는 RFC 7230~7237로 대체됨)
- **RFC 1034, 1035**: DNS 프로토콜
- **RFC 5246**: TLS 1.2

## 주요 기여와 영향

IETF는 인터넷의 기반을 형성하는 수많은 프로토콜과 기술을 개발했습니다. 대표적인 기여로는:

- **IP**(Internet Protocol): 네트워크 계층의 핵심 프로토콜로, IPv4와 IPv6의 설계 및 표준화.
- **TCP/UDP**: 전송 계층 프로토콜로, 신뢰성 있는 데이터 전송과 경량 전송을 가능하게 함.
- **HTTP/HTTPS**: 웹 브라우징의 기반이 되는 응용 계층 프로토콜.
- **SMTP, IMAP**: 이메일 전송 및 수신을 위한 프로토콜.
- **TLS**(Transport Layer Security): 인터넷 통신의 보안을 위한 암호화 프로토콜.

특히, 최근에는 **IPv6**, **HTTP/3**(QUIC 기반), **DNS over HTTPS**(DoH), **DPRIVE**(DNS 개인정보 보호) 등의 새로운 기술 표준화에 주력하고 있습니다.

## 관련 기관 및 협력

IETF는 다음과 같은 기관과 긴밀히 협력합니다:

- **ISOC**(Internet Society): IETF를 지원하는 부모 기관으로, 인터넷의 개방성과 발전을 촉진.
- **ICANN**(Internet Corporation for Assigned Names and Numbers): IP 주소 및 도메인 이름 관리.
- **W3C**(World Wide Web Consortium): 웹 기술 표준화 기관으로, 응용 계층 기술에서 협력.
- **ITU-T**, **IEEE**: 일부 기술 분야에서 협업.

## IETF의 철학과 의사결정 원칙

IETF는 전통적인 투표 방식 대신 **"거친 합의와 실행 가능한 동의(Rough Consensus and Running Code)"**라는 독특한 의사결정 원칙을 고수합니다.

### 거친 합의 (Rough Consensus)
만장일치를 추구하지 않습니다. 모든 참여자가 완벽하게 동의하는 것이 아니라, 기술적인 핵심 쟁점에 대해 중대한 반대 의견이 더 이상 제기되지 않는 상태를 '거친 합의'로 간주합니다. 이는 소수의 강력한 반대 의견(Strong Objection)을 경청하되, 그것이 기술적으로 타당하지 않다면 다수의 합의를 통해 빠르게 결론을 내리는 민주적이고 실용적인 방식입니다.

### 실행 가능한 동의 (Running Code)
이론적인 설계도나 논문보다는 **실제로 구현되어 동작하는 코드**를 가장 강력한 증거로 채택합니다. 아무리 이론적으로 완벽한 제안이라도 실제 환경에서 구현되지 않았거나 성능이 검증되지 않았다면 표준으로 채택되기 어렵습니다.

**[실제 적용 사례]**
- **TCP 혼잡 제어**: 초기 TCP 설계 당시, 수학적 모델링보다 실제 네트워크 패킷 손실 상황에서 어떻게 반응하는지에 대한 구현체들의 동작 결과를 바탕으로 알고리즘이 수정 및 보완되었습니다.
- **HTTP/2 및 HTTP/3**: 구글(Google)이 SPDY 프로토콜을 통해 실제 브라우저와 서버 간의 성능 향상을 입증한 후, 이를 바탕으로 IETF 내에서 표준화 논의가 가속화되어 표준으로 채택되었습니다.

## RFC 생명주기와 진화 과정

RFC 문서는 한 번 발행되면 수정되지 않는 불변의 기록이지만, 기술의 발전에 따라 다음과 같은 상태 변화를 통해 진화합니다.

### RFC 상태 변화 흐름도
`Internet-Draft` $\rightarrow$ `Proposed Standard` $\rightarrow$ `Internet Standard` $\rightarrow$ `Obsoleted` 또는 `Updated`

### 문서의 갱신 및 폐기 개념
- **Obsoleted (대체됨)**: 새로운 RFC가 기존 RFC의 내용을 완전히 대체하여, 기존 문서는 더 이상 유효하지 않게 된 상태입니다. (예: HTTP/1.1의 구 버전 RFC $\rightarrow$ 최신 RFC로 대체)
- **Updated (갱신됨)**: 기존 RFC의 기본 틀은 유지하되, 특정 부분에 수정 사항이나 추가 사양이 반영된 상태입니다. 기존 문서와 갱신 문서를 함께 참조해야 합니다.

## QUIC 도입과 성능 혁신

IETF는 전송 계층의 고질적인 문제인 TCP의 지연 시간을 해결하기 위해 UDP 기반의 **QUIC(Quick UDP Internet Connections)** 프로토콜을 표준화하였으며, 이를 기반으로 **HTTP/3**로의 전환을 이끌었습니다.

### 도입 배경
TCP는 연결 설정 시 3-way handshake 과정이 필요하며, 패킷 손실 시 모든 스트림이 멈추는 '헤드 오브 라인 블로킹(Head-of-Line Blocking)' 현상이 발생하여 웹 페이지 로딩 속도를 저하시켰습니다.

### 성능 비교 지표
| 비교 항목 | TCP (HTTP/1.1, 2) | QUIC (HTTP/3) | 기대 효과 |
| :--- | :--- | :--- | :--- |
| **연결 설정 시간** | 2~3 RTT (TCP+TLS) | 0~1 RTT (결합된 핸드셰이크) | 초기 접속 속도 획기적 단축 |
| **패킷 손실 영향** | 전체 스트림 중단 (HOL Blocking) | 해당 스트림만 영향 | 네트워크 불안정 시 체감 속도 향상 |
| **연결 유지** | IP 주소 변경 시 연결 끊김 | Connection ID 기반 유지 | 모바일-Wi-Fi 전환 시 끊김 없는 통신 |

## 현대적 도전 과제와 논쟁

인터넷 환경이 복잡해짐에 따라 IETF는 단순한 기술 표준화를 넘어 사회적, 정치적 쟁점들에 직면해 있습니다.

- **개인정보 보호 (Privacy)**: DNS over HTTPS(DoH)와 같은 기술은 사용자 프라이버시를 강화하지만, 동시에 네트워크 관리자의 가시성을 떨어뜨려 보안 관제에 어려움을 준다는 논쟁이 지속되고 있습니다.
- **인터넷 분절화 (Splinternet)**: 국가별로 서로 다른 기술 표준을 강제하거나 인터넷 망을 통제하려는 시도가 늘어남에 따라, '하나의 통합된 글로벌 인터넷'이라는 IETF의 기본 가치를 유지하기 위한 기술적/정책적 대응이 요구되고 있습니다.
- **제로 트러스트 (Zero Trust)**: 경계 기반 보안의 한계를 극복하기 위해 "아무도 믿지 않는다"는 전제의 보안 표준을 수립하고 있으며, 이를 위해 인증 및 권한 부여 프로토콜의 전면적인 재검토가 진행 중입니다.

## 참고 자료

- [IETF 공식 웹사이트](https://www.ietf.org/)
- [RFC Editor](https://www.rfc-editor.org/)
- [Internet Society (ISOC)](https://www.internetsociety.org/)
- Stallman, R. (2002). *Free Software, Free Society: Selected Essays of Richard M. Stallman*. IETF의 개방성과 자유 소프트웨어 운동의 연관성에 대한 논의 포함.

IETF는 인터넷의 기술적 기반을 지속적으로 발전시키는 핵심 기관으로, 그 활동은 전 세계 인터넷 사용자 모두에게 직접적인 영향을 미칩니다.