내가 공부하는 방법 (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 7230](https://datatracker.ietf.org/doc/html/rfc7230#section-6.3)의 Keep-Alive 구조, [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231)의 헤더 설계 철학, [RFC 7234](https://datatracker.ietf.org/doc/html/rfc7234)의 캐싱 메커니즘 등을 통해 그 원리를 직접 확인할 수 있다. RFC 문서 자체에는 “왜 이렇게 설계했는가”가 직접적으로 적혀 있지 않지만, **draft 변천사와 구조를 함께 보면 설계자의 의도를 추론할 수 있다.** 이런 원본 문서를 따라가다 보면 기술의 본질을 훨씬 깊이 이해하게 된다. 또한 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는 분명 어렵지만, 기술의 근본을 이해하고 싶다면 이것만큼 확실한 자료는 없다.