RFC

RFC 는 인터넷 기술을 정한 문서에 번호를 붙여 내는 공개 문서 모음입니다. 웹 요청의 뜻이나 시간 측정 방법 같은 약속이 한 편씩 번호를 달고 나옵니다. 한 번 나온 문서는 고치지 않습니다. 바꿀 것이 생기면 새 번호로 다시 냅니다.

상세

동아리 방 벽에 붙은 쪽지를 떠올리면 가깝습니다. 누구든 「이렇게 해 보면 어떨까」를 한 장 적어 붙입니다. 붙은 순서대로 귀퉁이에 번호가 하나씩 올라갑니다. 번호가 있다고 다 지켜야 하는 것은 아닙니다. 다 같이 지키기로 한 쪽지도, 그냥 적어 둔 생각도 섞여 있습니다.

RFC(Request for Comments)는 인터넷 기술 문서를 번호 순서대로 내는 모음입니다. 우리말로 옮기면 「의견 요청」입니다. 누구나 읽고 누구나 따라 만들 수 있는 공개 문서입니다. 번호는 발행 순서대로 하나씩 붙습니다. 같은 번호가 두 번 붙지 않습니다. 백엔드 개발자가 매일 쓰는 HTTP(HyperText Transfer Protocol)의 메서드와 상태 코드도 RFC 9110 이라는 한 편이 뜻을 정합니다.

이런 문서 모음이 필요한 것은 서로 모르는 사람들이 만든 장비와 프로그램이 한 망에서 말을 알아들어야 하기 때문입니다. 서버를 만든 쪽과 브라우저를 만든 쪽이 같은 문장을 보고 구현해야 둘이 맞물립니다. 그 문장을 번호 하나로 부를 수 있게 한 것이 RFC 입니다.

이름이 「의견 요청」인 까닭

이름은 첫 문서들의 성격에서 왔습니다. 첫 편인 RFC 1 은 1969년에 나왔습니다. 인터넷의 전신이 된 연구용 망을 만들던 사람들이 확정안이 아니라 「이렇게 해 보면 어떨까」를 적어 돌린 메모였습니다.

지금 나오는 RFC 는 대부분 여러 차례 검토를 거친 확정 문서입니다. 성격은 바뀌었어도 이름은 그대로 남았습니다. 이름만 보고 초안이라고 여기면 틀립니다. 아직 확정 전인 초안은 따로 Internet-Draft(인터넷 초안)라고 부릅니다.

한 편이 나오기까지

RFC 를 가장 많이 내는 곳은 IETF(Internet Engineering Task Force)입니다. 인터넷 기술 규격을 만드는 공개 공동체입니다. 회사가 아니라 개인 자격으로 참여합니다. 이 소절은 IETF 를 거쳐 나오는 문서 한 편의 길을 따라갑니다.

처음 손을 대는 것은 저자와 워킹그룹입니다. 워킹그룹은 주제별 논의 모임입니다. 저자가 인터넷 초안을 올리면 워킹그룹이 공개 메일링 리스트에서 고칠 곳을 짚어 돌려줍니다.

인터넷 초안에는 유효 기간이 있습니다. 새 판을 올리지 않은 채 여섯 달이 지나면 효력을 잃습니다. 논의가 이어지는 동안 초안이 계속 새 판으로 올라오는 것도 이 때문입니다.

워킹그룹은 투표로 정하지 않습니다. 반대 의견이 조금 남아 있어도 논의를 이끄는 의장이 대부분이 동의한다고 판단하면 합의로 봅니다. 이것을 대략적 합의(rough consensus)라고 부릅니다. 모두가 찬성할 때까지 기다리면 규격이 나오지 않기 때문입니다.

합의에 이른 초안은 IESG(Internet Engineering Steering Group)로 갑니다. IESG 는 IETF 안에서 문서를 최종 승인하는 운영진입니다. 아래 그림에서는 「승인단」으로 적었습니다.

승인이 나면 RFC Editor(RFC 편집자)가 문장과 형식을 다듬고 번호를 붙여 냅니다. 그림에서는 「편집자」로 적었습니다. 네 주체가 주고받는 순서를 한 장에 모으면 이렇습니다.

sequenceDiagram
    participant 저자
    participant 워킹그룹
    participant 승인단
    participant 편집자
    저자->>워킹그룹: 인터넷 초안을 올린다
    워킹그룹->>저자: 메일링 리스트에서 고칠 곳을 돌려준다
    Note over 저자,워킹그룹: 대략적 합의에 이를 때까지 되풀이한다
    워킹그룹->>승인단: 합의한 초안을 넘긴다
    승인단->>편집자: 검토하고 승인한다
    편집자->>편집자: 문장을 다듬고 번호를 붙여 낸다

IETF 만 RFC 를 내는 것은 아닙니다. 인터넷 구조를 살피는 위원회, 연구 모임, IETF 밖의 개인 저자도 같은 번호 줄에 문서를 냅니다. 번호가 붙었다는 사실만으로는 IETF 가 합의한 문서라고 읽을 수 없습니다.

번호마다 붙는 상태

RFC 라는 이름은 「표준」이라는 뜻이 아닙니다. 문서마다 상태가 하나씩 붙습니다. 그 상태가 이 문서를 얼마나 무겁게 읽을지 알려 줍니다. 상태는 문서 첫머리에 적혀 있습니다.

표에서 보듯 따라야 할 규격은 표준 트랙과 BCP 에 몰려 있습니다. 정보 제공이나 실험 상태의 문서는 지켜야 할 규칙이 아니라 참고할 글로 읽습니다.

표준 트랙 안에서도 단계가 둘로 갈립니다. 처음 오르는 단계가 제안 표준(Proposed Standard)이고, 널리 구현되어 검증을 거치면 인터넷 표준(Internet Standard)으로 올라갑니다. 실무에서 쓰는 규격 가운데 상당수가 제안 표준 단계에 머문 채 쓰입니다.

고치지 않고 새로 낸다

한 번 나온 RFC 의 본문은 바뀌지 않습니다. 오늘 읽는 RFC 9110 과 몇 해 뒤에 읽는 RFC 9110 은 글자 하나 다르지 않습니다. 번호로 인용하면 누구나 같은 문장을 보게 됩니다.

바꿀 것이 생기면 새 번호의 문서를 냅니다. 새 문서는 첫머리에 옛 문서와의 관계를 적습니다. 옛 문서를 통째로 대신하면 「폐기한다(Obsoletes)」, 일부만 고치면 「갱신한다(Updates)」입니다.

작은 오타나 실수는 새 문서를 내지 않고 정오표(errata)에 따로 모읍니다. 폐기와 갱신은 새 번호의 문서가 생깁니다. 정오표는 번호도 본문도 그대로 두고 틀린 곳만 옆에 적어 둡니다.

HTTP 의 뜻을 정한 문서가 새 번호로 두 번 바뀌었습니다.

flowchart TD
    A["RFC 2616"] -->|7231 이 폐기함| B["RFC 7231"]
    B -->|9110 이 폐기함| C["RFC 9110 (지금 따르는 문서)"]

RFC 번호를 인용한 글을 읽을 때는 그 번호가 뒤 문서에 폐기됐는지부터 확인합니다. 블로그나 라이브러리 주석이 RFC 2616 을 근거로 들었다면 이미 두 번 대체된 문서를 본 것입니다.

첫머리에서 읽을 것

RFC 한 편을 열면 맨 위에 몇 줄짜리 머리글이 있습니다. 위에서 본 관계와 상태가 전부 여기 적힙니다. 아래는 RFC 9110 의 머리글에서 필요한 줄만 추리고 오른쪽에 뜻을 붙인 것입니다.

Request for Comments: 9110  // 문서 번호
STD: 97                     // 표준 번호
Obsoletes: 7230, 7231, …    // 폐기한 문서
Updates: 3864               // 일부 고친 문서
Category: Standards Track   // 문서 상태

「Obsoletes」 줄을 보면 이 문서가 무엇을 대신하는지 알 수 있습니다. 「Category」 줄은 앞 소절의 상태 표 가운데 하나입니다.

머리글 둘째 줄은 STD(Standard, 표준) 번호입니다. 인터넷 표준 단계에 오른 규격에 붙는 번호입니다. RFC 번호는 판이 바뀔 때마다 새로 붙지만 STD 번호는 「HTTP 의 뜻」이라는 주제를 계속 가리킵니다. BCP 도 같은 방식으로 자기 번호를 따로 갖습니다.

요구 강도를 나타내는 낱말

RFC 를 읽다 보면 대문자로 적은 영어 낱말이 자주 나옵니다. 이 낱말들은 구현하는 쪽이 얼마나 반드시 지켜야 하는지를 나타냅니다. 낱말마다 뜻이 정해져 있습니다(RFC 2119). 백엔드 개발자가 RFC 를 읽을 때 제일 먼저 가려 읽어야 하는 낱말입니다.

이 뜻은 대문자로 적었을 때만 붙습니다. 소문자 「should」는 평범한 영어 문장입니다. 서버가 요청을 거절해도 되는지 따질 때는 그 문장이 MUST 인지 SHOULD 인지부터 봅니다.

관련 항목

RFC 를 만들고 내는 조직

IETF · IESG · RFC Editor · 워킹그룹 · IAB · IRTF · IANA · ISOC

RFC 가 거치는 단계와 상태

Internet-Draft · 제안 표준 · 인터넷 표준 · 표준 트랙 · BCP · STD · 정오표 · 대략적 합의

RFC 로 정의된 프로토콜과 포맷

HTTP · RFC 9110 · TCP · UDP · IP · DNS · TLS · JSON · URI · TZif

RFC 를 읽을 때 만나는 요구 강도 낱말

RFC 2119 · MUST · SHOULD · MAY

RFC 와 나란히 표준 문서를 내는 기구

ISO · IEEE · W3C · WHATWG · ITU-T

RFC 번호를 근거로 드는 기술 주제

지연 · 윤초 · 쿠키 · 문자 인코딩 · 라우팅