요약

  • 1991년 10월의 정보성(Informational) 메모인 RFC 1263은 당시 제안된 형태 그대로의 RFC 1072와 RFC 1185의 하위 호환 TCP 확장을 추진하는 데 반대했다. 같은 TCP 헤더 안에 모든 새로운 필요를 또 하나의 옵션으로 넣는 대신, 프로토콜 진화를 위한 명시적 경로를 제안했다.
  • 호환성은 한 번의 동기화된 배포 없이도 변화를 확산시킬 수 있었지만, 그렇다고 변화가 공짜가 되는 것은 아니라고 이 RFC는 주장했다. 인프라가 선택하는 두 개의 단순한 버전보다 하나의 프로토콜이 더 복잡해질 수 있다는 것이다. 이 메모는 설계·비용 가설을 제시했을 뿐, 자신의 TCP 제안이 구현되거나 배포되었다는 증거는 제공하지 않는다.

헤더가 비용의 전부는 아니었다

RFC 1263의 제목은 확장 자체에 대한 경고처럼 들린다. 그러나 더 유용한 논지는 시스템이 변화의 대가를 어디에서 지불하는가에 관한 것이다. 프로토콜은 기존 헤더를 보존하고 새 동작을 옵션 공간에 맞춰 넣음으로써 단절을 피한 것처럼 보일 수 있다. 그러나 그 작업은 사라지지 않는다. 협상 규칙, 파서 분기, 옵션 크기 제한, 구현 부담, 그리고 어느 종단이 어느 조합을 이해하는지에 대한 불확실성으로 다시 나타날 수 있다.

이 메모는 세 가지 접근에서 출발한다: 새 프로토콜을 만들 것인가, 하위 호환을 유지하며 기존 것을 확장할 것인가, 아니면 기존 와이어 포맷을 보존하지 않고 프로토콜을 진화시킬 것인가. 각각에는 눈에 보이는 비용이 있다. 새 프로토콜은 인터페이스와, 사용 가능해질 만큼의 커뮤니티 채택이 필요하다. 하위 호환 확장은 자기 속도로 확산될 수 있어 동기화된 배포의 필요를 줄인다. 진화적 변경은 설계자에게 더 많은 자유를 주지만 버전 간 전환을 명시적으로 만들어야 한다.

RFC 1263의 주장은 호환성이 결코 도움이 되지 않는다는 것이 아니었다. 그 이점이 비용 제거와 혼동될 수 있다는 것이었다. 하나의 헤더에 쉽게 도입할 수 있는 변경은 확장과 조합이 쌓이면 이해하고 유지하기 어려워질 수 있다. 반대로 공통 메커니즘이 종단이 사용할 버전을 선택할 수 있다면, 두 버전이 반드시 서로 무관한 완전한 두 설계인 것은 아니다.

TCP가 사례 연구가 된 이유

예시는 RFC 1072와 RFC 1185의 고지연·고속 TCP 제안이었다. RFC 1072는 윈도 스케일링, 선택적 확인 응답, 에코 타임스탬프로 큰 대역폭-지연 곱을 다루었다. RFC 1185는 고속 경로를 위한 TCP 확장을 검토했다. RFC 1263이 반대한 것은 단순히 그들의 목표가 아니라, 추가 의미 체계를 하위 호환 옵션 체계를 통해 전달하는 방식이었다.

그 대안은 TCP 버전을 구분할 수 있는 프로토콜 식별자가 있는 더 크고 단순한 헤더였다. 이 스케치는 시퀀스·확인 번호를 64비트로, 윈도를 32비트로 늘리고 에코 필드를 추가했다. 새 서비스가 필요 없는 종단은 기존 TCP를 계속 사용할 수 있었다. 필요한 종단은 추가된 가상 프로토콜 계층을 통해 다른 프로토콜 버전을 선택할 수 있었다.

이 제안에는 여러 형태가 있었다. 저자들은 기존 TCP를 그대로 두고 별도의 버전 선택 메커니즘을 사용하는 방식을 선호했다. 하나의 단일 프로토콜을 고집하는 독자를 위해 SYN 교환에서 협상되는 TCP VERSION 옵션도, 그리고 새 정보를 옵션에 담는 헤더 호환 대안도 설명했다. 이 옵션들은 복잡성에서 동등하지 않았다: 설계가 더 많은 호환성을 보존하려 할수록 더 많은 기존 제약을 끌고 갔다.

"두 버전"은 이미 암묵적 가능성이었다

RFC 1263은 날카로운 예측을 했다: 그들의 보기로는 어차피 많은 시스템이 TCP의 두 버전을 유지해야 할 것이었다. 따라서 선택은 단순히 "하나의 프로토콜" 대 "둘"이 아니었다. 확장하는 조건부 동작 집합을 가진 하나의 프로토콜을 유지할 것인가, 아니면 버전 간 명확한 경계를 정의하고 인프라가 그 사이에서 선택하도록 할 것인가의 문제였다.

이 메모는 두 개의 사본을 유지하는 추가 메모리 비용을 인정하면서도, 두 개의 단순한 프로토콜을 유지하는 비용이 하나의 복잡한 프로토콜을 유지하는 것보다 낮을 수 있다고 말했다. 또한 새 프로토콜을 만드는 배포·인터페이스 비용도 인정했다. 이 진술들은 설계 판단이지 측정이 아니다. 이 문서는 어떤 아키텍처가 실제 시스템에서 더 저렴했는지 확립하는 비교 구현 연구를 제공하지 않는다.

그래서 이 제목은 의도적으로 범위가 제한된 주장이다. RFC 1263은 호환성이 모든 경우에 해롭거나, 버전 계층이 배포하기 더 쉽다는 것을 증명하지 않았다. "호환"이라는 단어에 숨겨진 비용을 독자들이 검토하도록 요청했을 뿐이다. 익숙하지 않은 옵션을 무시하는 수신자는 기존 연결을 계속 작동시킬 수 있지만, 주변 시스템은 여전히 어떤 기능이 협상되었는지, 옵션 공간이 얼마나 남았는지, 파서가 어떻게 동작하는지, 미래의 변경이 어떻게 들어맞을지를 결정해야 한다.

전환 메커니즘은 새로운 운영 표면이다

명시적 버전 경계는 조정을 폐지하는 것이 아니라 옮긴다. 선택 계층은 어떤 버전이 사용 가능한지 알아야 한다. 양쪽 끝은 공통 버전을 선택할 방법이 필요하다. 기존 종단은 파싱할 수 없는 헤더를 우연히 받지 않으면서 계속 도달 가능해야 한다. 새 종단에는 발견과 선택을 위한 경로가 필요하다. 버전 식별자는 이 구분을 프로토콜 소프트웨어에 보이게 하지만, 그 자체로 모든 중간 장치나 운영자가 이를 올바르게 다룬다는 보장은 되지 못한다.

RFC 1263의 요지는 이러한 비용을 점점 정교해지는 호환 확장의 유지 부담과 정직하게 비교하라는 것이었다. 그 제안은 프로토콜 배포를 기존 프로토콜 안에 영원히 숨겨야 하는 드문 이벤트가 아니라, 반복된 사용을 통해 개선될 수 있는 인프라로 다루었다. 이는 패킷 배치만큼이나 제도적·엔지니어링 인센티브에 관한 논쟁이었다.

그러나 이 메모는 중립적인 비용 모델이 아니었다. 저자들은 더 단순하고 빠르게 진화하는 프로토콜 설계를 선호했고, 당시의 표준화 과정을 날카롭게 비판했다. 이 문서는 거버넌스 지연이 프로토콜 변경의 결정적 장벽이었다는 것을 확립하지 않으며, 자신의 배포 메커니즘이 더 잘 작동했을 것임을 보여주지도 않는다. 그 기여는 남겨진 질문이다: 호환성 계층이 아무도 조정할 필요가 없다고 약속할 때, 누가 그 대가를 지불하는가?

이 문서가 보여주는 것과 보여주지 않는 것

이 RFC는 정보성(Informational)으로 발행되었다. 제안에 대한 논평이자 프로토콜 생성, 호환 확장, 진화에 관한 사고 방식을 제공한다. 최종 TCP 표준을 규정하거나, 완료된 마이그레이션을 기록하거나, 배포된 버전 선택 계층을 확인하거나, 대체 스택의 유지 비용을 측정하지 않는다. 64비트 시퀀스 번호, 확대된 윈도, 새 헤더 필드, 가상 프로토콜 선택은 이 문서에서 제안 상태로 남아 있다.

지속되는 역사적 요점은 "하위 호환은 나쁘다"보다 더 좁다. 호환성은 새 동작이 확산되는 동안 기존 시스템이 계속 작동하기 때문에 가치가 있을 수 있다. 그러나 호환성에도 운영 표면이 있다: 협상, 파서 규칙, 유한한 옵션 공간, 확장 간 상호작용, 장기적 구현 의무. 별개의 버전 경계는 이 의무들을 보이게 할 수 있지만, 그 자체의 선택·배포·지원 작업을 도입한다.

RFC 1263은 프로토콜 설계자들에게 기존 와이어 포맷을 모든 미래 요구의 무료 컨테이너로 다루지 말라고 요청했다. 모든 인터넷 프로토콜이 그 선을 어디에 그어야 하는지 결정하지는 않았다. 그 선 자체를 양쪽에 비용이 있는 설계 결정으로 만들었다.

출처와 한계

이 글은RFC 1263,TCP Extensions Considered Harmful, 그RFC Editor 기록,RFC 1072,TCP Extensions for Long-Delay Paths, 그리고RFC 1185,TCP Extensions for High-Speed Paths에 의존한다. 첫 출처는 세 갈래 프로토콜 변경 프레이밍, 당시 제안된 TCP 옵션에 대한 저자들의 비판, 버전 선택 대안들, 확대된 헤더 제안, 그리고 복잡성·메모리·배포 비용에 대한 그들의 주장을 뒷받침한다. RFC 1072와 1185는 논의되는 제안들의 근거가 된다.

이 출처들은 RFC 1263의 대안이 구현되었거나, 인터넷 커뮤니티에 의해 선택되었거나, 실제로 더 저렴했거나, 이후 어떤 TCP 설계의 원인이 되었다는 것을 확립하지 않는다. 호환성이 비용을 복잡성으로 이동시킬 수 있다는 주장은 메모의 논지이자 그 설계 비교에 대한 이 글의 해석이지, 관찰된 비용 측정이 아니다.