내가 공부하는 방법 (2) RFC 문서

내가 공부하는 두 번째 방법은 RFC 문서를 직접 읽는 것이다. 이 방법을 처음 접한 건 2014년, 회사에서 맡은 특별한 프로젝트 덕분이었다. 그때는 HTTP/2가 아직 공식 발표되기 전이었다. 하지만 업계에서는 이미 차세대 웹 프로토콜 논의가 한창이었다. 우리 팀의 미션은 “HTTP/2를 공식화되기 전에 미리 지원하는 서버를 구축하라”였다. 문제는 그 시점에 HTTP/2의 전신인 SPDY를 구현한 서버가 거의 Apache뿐이었다는 점이다. 제대로 된 한글 자료도 없었다. 구글에서 SPDY를 검색하다가 처음으로 RFC(Request for Comments) 라는 문서를 알게 되었다. RFC는 IETF에서 발행하는 기술 명세로, 이름 그대로 “의견을 요청하는 문서”라는 뜻을 가진다. 모든 RFC가 표준이 되는 것은 아니지만, 그중 상당수는 결국 인터넷의 공식 표준이 된다. 처음 접했을 때는 당황스러웠다. 책처럼 친절하지도 않고, 형식은 딱딱했다. 심지어 줄바꿈이나 문서 포맷이 낯설게 느껴졌다. RFC를 읽는 목적은 단순히 참고 자료를 얻기 위함이 아니었다. 기술의 구조를 명확히 이해하고, 명세가 정의한 동작에 따라 구현하기 위해서였다. RFC는 "이렇게 동작해야 한다(MUST)"라는 형태로 구현체가 지켜야 할 기준을 명확히 규정한다. 개발자는 RFC를 통해 기술이 실제로 어떻게 작동해야 하는지, 어떤 제약과 예외가 존재하는지를 정확히 파악할 수 있다. 이 과정에서 API나 프레임워크 수준의 사용법을 넘어 프로토콜·포맷·아키텍처의 근본적인 설계 원리를 이해하게 된다. RFC는 특정 기업이나 제품에 종속되지 않는다. 모든 구현체가 따라야 하는 공통 기준을 정의하기 때문이다. 그래서 RFC를 이해하면 어떤 프레임워크를 사용하더라도 기술의 본질을 꿰뚫을 수 있다. Axios가 아닌 HTTP 자체를, Socket.io가 아닌 WebSocket 프로토콜 자체를 이해하게 되는 것이다. 결국 RFC는 일시적인 트렌드나 도구를 넘어, 시간이 지나도 변하지 않는 기술의 원형과 규칙을 보여주는 문서다. SPDY의 경우 나는 draft 1부터 최종 버전까지 전부 읽었다. 영어 문서라 쉽지 않았지만, ‘MUST’, ‘SHOULD’, ‘MAY’ 같은 단어가 단순한 동사가 아니라 구현 강제성의 정도를 나타낸다는 걸 배웠다. 나중에 [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119)에서 이 용어들이 공식 정의되어 있다는 것도 알게 되었다. SPDY 스펙을 읽고 Apache의 `mod_spdy` 코드를 분석하며, 명세서에 적힌 내용이 실제로 어떻게 구현되는지 직접 확인했다. Wireshark로 패킷을 캡처해 실제 8바이트 헤더 구조 속에서 첫 비트가 control bit로 사용되는 걸 확인했을 때, 문서와 현실이 일치하는 그 순간의 쾌감은 이루 말할 수 없었다. 이 경험은 나중에 디버깅·보안·최적화 능력을 크게 키워주었다. RFC는 프로토콜의 경계와 예외 케이스를 명확히 정의하므로, 문제를 “버그”가 아닌 “규격 위반”으로 진단할 수 있게 된다. [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231)의 “safe methods” 개념만 이해해도 REST 설계 오류를 근본적으로 피할 수 있다. RFC의 또 다른 장점은 변천 과정(draft history) 을 통해 기술의 진화를 따라갈 수 있다는 것이다. SPDY/1, SPDY/2, SPDY/3을 거쳐 HTTP/2로 발전하는 과정을 읽으면서 “왜 헤더 압축 방식이 바뀌었는가?”, “왜 서버 푸시가 도입되었는가?” 같은 맥락을 이해할 수 있었다. 한 번 RFC를 읽는 습관이 들자, 이후에는 다른 기술을 배울 때도 항상 RFC부터 찾게 되었다. 블로그나 책보다 더 정확하고 완전하기 때문이다. 진입장벽은 높지만, 익숙해지면 오히려 효율적이다. 이후 팀장이 된 뒤에는 이 방법을 팀원들과 공유했다. 특히 OAuth2를 다루던 시기, 여러 책의 설명이 제각각이라 [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749)를 팀 전체가 함께 스터디했다. 그 경험 덕분에 API 보안과 인증 로직을 설계할 때 흔들림이 없었다. --- 내가 RFC로 공부하는 방법 1. 최신 버전만 보지 않는다. draft 변천사까지 읽으며 설계 배경을 이해한다. 2. 명세만 보지 않는다. 실제 구현체와 비교하며 동작을 검증한다. 3. 혼자 읽지 않는다. 동료들과 함께 토론하며 서로의 해석을 교차검증한다. RFC는 분명 어렵지만, 기술의 근본을 이해하고 싶다면 이것만큼 확실한 자료는 없다.