RFC 873: 공급사 지원이라는 약속의 실제 가격

요약

RFC 873은 미국 국방부가 공급사 지원을 기다리면 네트워크 조달 비용을 줄일 수 있다는 1982년의 기대를 따졌다. ISO 참조 모델을 따른 프로토콜 묶음은 당시 아직 완성되지 않았다.
표준이 허용한 선택 기능을 한 회사만 구현해도 두 제품은 연결 단계에서 추가 작업을 요구할 수 있다. Padlipsky는 그 청구서가 구매자에게 돌아갈 가능성을 짚었다.

“공급사 지원”은 발주서에서 든든해 보인다. 패킷은 그 문구를 읽지 않는다. 반대편 컴퓨터가 같은 규칙으로 응답해야 움직인다. Michael A. Padlipsky가 1982년 9월의 RFC 873에서 따진 것도 이 차이다. 미국 국방부 안에서는 이미 쓰는 ARPANET 계열 프로토콜 대신, ISO 참조 모델에 맞춘 공급사 제공 프로토콜을 기다리자는 견해가 있었다. 정부 비용을 아낄 수 있다는 기대였다. Padlipsky는 절감액을 말하기 전에 견적서의 빈칸부터 세자고 했다.

먼저 무엇을 구매하는가. X.25는 통신 과정의 일부를 다루지만 컴퓨터끼리 자원을 공유하는 데 필요한 서비스 전체를 제공하지는 못한다고 그는 봤다. 접속과 주소에 관한 다른 문서를 함께 올려놓아도 완성된 묶음이 저절로 생기지 않는다. 당시 National Bureau of Standards가 추진하던 내용과 ISO의 작업도 모든 곳에서 일치하지 않았다. 조달 문서 한 줄에는 “완전한 프로토콜 묶음”을 쓸 수 있다. 실제 규칙은 여러 문서에 흩어져 있고 일부는 아직 채워지는 중이었다. 상자의 라벨을 먼저 인쇄한다고 내부 부품의 생산 일정이 앞당겨지지는 않는다.

다음은 시간이다. 국방부 조달에는 원래 긴 준비 기간이 들었다. Padlipsky가 글을 쓴 시점에 ISO 모델 기반 묶음은 불완전했고, 일부는 실제 운용으로 검증된 프로토콜보다 제안서에 가까웠다. 표준화에는 시간이 필요하지만 계약 논의는 현재 진행형이었다. 반면 ARPANET 모델 기반 프로토콜은 국방부가 사용하는 몇몇 운영체제에서 이미 구현되어 있었다. 그 코드 역시 유지와 수정이 필요하다. 그러나 작동하는 구현과 장차 나올 규격은 구매 일정에서 같은 자리에 놓을 수 없다. Padlipsky의 “더 빨리 조달할 수 있다”는 말은 당대 논쟁의 판단이며, 일정 단축을 재서 제시한 수치는 아니다.

그는 “지원”이라는 말의 기술적 속뜻도 살폈다. 계층형 참조 모델은 큰 구조를 설명한다. 두 제품을 연결하려면 층 사이의 약속까지 맞아야 한다. 긴급 데이터 신호는 응용 프로그램까지 어떻게 전달되는가? 전송 과정은 모든 계층을 반드시 거쳐야 하는가? 한 계층에 프로토콜을 여럿 둘 수 있는가? RFC 873은 이런 질문을 열거했다. 공통 구조도 한 장은 계약의 출발점이 될 수 있다. 실제 상호 운용은 두 구현에 같은 답이 들어 있고 함께 시험해 봐야 확인된다.

선택 기능을 보면 문제가 선명해진다. 첫 회사는 명세가 허용하는 기능을 사용했고, 둘째 회사는 그 기능을 구현하지 않았다. 어느 쪽도 규칙을 어기지 않았다. 각자 품질 검사에도 합격할 수 있다. 구매자가 둘을 연결하는 순간, 한 제품이 당연하게 기대한 기능을 다른 제품은 제공하지 않는다는 사실이 드러난다. 설정을 바꾸거나 프로그램을 손봐야 한다. 누가 값을 치를까? Padlipsky는 사용자가 비용을 떠안을 것이라고 내다봤다. 개발자에게 선택 사항이던 항목이 고객에게는 추가 계약서가 되는 셈이다.

기계 자체의 청구서도 있다. 네트워크 소프트웨어는 메모리와 CPU 시간을 쓴다. 당시 컴퓨터에서 그 자원은 넉넉한 공짜 물건이 아니었다. Padlipsky는 계층을 거치는 처리와 상태 유지의 비용을 따졌고, 잦은 확인 메시지가 운용 비용에 드러났던 Multics의 오래된 사례를 들었다. 그 일화 하나로 나중의 모든 구현 성능을 재단할 수는 없다. 다만 구매자가 물어야 할 질문은 분명하다. 설치가 끝난 뒤 평소의 통신이 자원을 얼마나 먹는가? “무료 소프트웨어”가 가장 비싼 컴퓨터에서 식사할 수도 있다.

글의 풍자는 공급사가 악의를 가졌다는 가정 없이도 통한다. 숙련된 두 팀이 서로 다른 선택을 내리고, 각 제품이 따로는 잘 돌아갈 수 있다. 공동 운용에서 나타난 차이를 메우는 작업과 유지보수, 메모리, 처리 시간은 각각 비용이다. 글 말미에 Padlipsky는 TCP/IP를 제공하거나 제공하려는 공급사가 늘고 있다고 덧붙였다. 논쟁에서 서로 반대편에 놓였던 “공급사 지원”과 기존 ARPANET 프로토콜도 현실에서는 만나기 시작한 것이다.

RFC 873이 남긴 것은 1982년 구매 결정을 앞둔 질문들이다. 지금 어떤 묶음이 완성돼 있는가? 국방부가 쓰는 기계에서 이미 돌아가는가? 양쪽 제품이 실제로 공유하는 선택 기능은 무엇인가? 해석이 다르면 누가 고치는가? 발주서에는 공급사 이름을 쓸 수 있다. 두 컴퓨터가 통한다는 사실은 함께 시험해야 얻는다.