서로 다른 회사가 만든 프로그램이 인터넷에서 만나면, 규격서를 한 글자라도 다르게 읽은 순간부터 통신이 끊기기 쉽습니다. 그런데 초창기 인터넷은 그런 작은 차이 속에서도 어떻게든 이어졌습니다. 그 비결로 자주 거론되는 말이 바로 ‘포스텔의 법칙(Postel’s Law)’입니다.

포스텔의 법칙이란 쉽게 말해 ‘보낼 때는 규격에 엄격하고, 받을 때는 해석이 가능한 범위에서 너그럽게 대하라’는 통신 설계 원칙을 의미합니다. 정식 문서에서는 ‘강건성 원칙(Robustness Principle)’이라고도 부릅니다.

본 자료에서는 포스텔의 법칙이 어디에서 나왔는지, 왜 인터넷에 필요했는지, 일상과 개발 현장에서 어떻게 나타나는지, 그리고 오늘날 왜 비판받는지까지 차례로 살펴보겠습니다.

포스텔의 법칙의 이해

포스텔의 법칙은 어디에서 나왔을까

이 법칙의 이름은 미국의 컴퓨터 과학자 조너선 포스텔(Jonathan B. Postel, 1943~1998)에게서 왔습니다. 그는 남캘리포니아 대학교 정보과학연구소(USC ISI)에서 일하며, 1969년부터 세상을 떠날 때까지 인터넷 표준 문서인 RFC 시리즈의 편집을 맡았고, 주소와 번호를 관리하는 IANA의 중심 역할도 했습니다.

1980년 1월, 포스텔이 정리한 인터넷 규격 RFC 760(인터넷 프로토콜)과 RFC 761(전송 제어 프로토콜)에는 강건성 원칙이 실렸습니다. 그 핵심 문장은 “보낼 때는 보수적으로, 받을 때는 관대하게(be conservative in what you do, be liberal in what you accept from others)”였습니다. 이 말은 1981년 TCP 표준인 RFC 793에도 이어졌고, 이후 ‘포스텔의 법칙’이라는 이름으로 널리 불렸습니다.

포스텔은 규격이 아무리 자세히 적혀 있어도 사람마다 해석이 어긋날 수 있다고 보았습니다. 그래서 보내는 쪽은 깨끗하고 표준에 맞는 자료를 만들고, 받는 쪽은 뜻이 분명하면 작은 형식 오류까지 트집 잡지 말라고 권한 것입니다.

왜 보낼 때는 엄격하고 받을 때는 너그럽게 할까

인터넷은 한 회사가 만든 기계만 쓰는 닫힌 망이 아닙니다. 서로 다른 운영체제, 다른 언어, 다른 버전의 프로그램이 같은 규약을 따라 대화해야 합니다. 이때 양쪽이 모두 ‘조금만 달라도 거절’하면, 작은 해석 차이만으로도 연결이 끊깁니다.

(1) 보내는 쪽의 엄격함
형식·길이·필수 항목을 규격에 맞춰 정확히 채우면, 상대가 어떤 구현을 쓰든 이해하기 쉬워집니다. 자기 편의로 규격을 늘리면 상대는 그 변형을 전부 받아 주어야 합니다.

(2) 받는 쪽의 너그러움
뜻이 분명한 자료라면 사소한 형식 문제를 이유로 전부 버리지 않습니다. 이렇게 해야 서로 다른 구현이 한동안 함께 살아갈 수 있습니다.

(3) 상호 운용성의 우선
완벽한 일치보다 ‘일단 통하게’를 먼저 두는 태도입니다. 초창기처럼 구현이 제각각이던 환경에서는, 이 관용이 네트워크를 키우는 윤활유가 되었습니다.

(4) 규격의 불완전함을 인정함
문서에 구멍이나 애매한 표현이 있을 수 있음을 전제로 합니다. 그래서 받는 쪽의 여유를 두되, 보내는 쪽은 그 여유에 기대지 말고 더 조심하라는 균형이 핵심입니다.

일상과 개발에서 보는 포스텔의 법칙

이 원칙은 네트워크 안에만 있지 않습니다. 웹 브라우저가 조금 틀린 HTML도 화면에 그려 주는 일, 이메일 프로그램이 형식이 어긋난 편지를 어떻게든 열어 보이려는 일도 같은 정신에 가깝습니다.

소프트웨어 인터페이스에서도 비슷한 선택이 반복됩니다.

• 공개 인터페이스(Public API): 밖으로 내보내는 요청과 응답은 문서에 적힌 형식만 쓰고, 실험적인 필드를 몰래 끼워 넣지 않습니다.
• 입력 검증(Input Validation): 필수 값과 위험한 값은 엄격히 확인하되, 의미가 같은 사소한 표기 차이는 허용할지 팀 규칙을 미리 정합니다.
• 버전 호환(Backward Compatibility): 새 버전이 옛 자료를 읽을 수 있게 두면, 시스템이 한꺼번에 갈아엎지 않아도 됩니다.
• 로그와 오류 메시지(Clear Errors): 너그럽게 받더라도, 무엇이 어긋났는지는 기록해 두어야 나중에 규격을 고칠 수 있습니다.

쉽게 말해, ‘내가 말할 때는 또박또박, 상대 말을 들을 때는 뜻을 헤아린다’는 태도를 기계 사이의 대화에 옮긴 것입니다.

오늘날 왜 이 법칙을 다시 따져 볼까

포스텔의 법칙은 인터넷을 크게 키우는 데 도움이 되었지만, 시간이 지나며 부작용도 드러났습니다. 받는 쪽이 너무 관대하면, 애매한 해석이 쌓이고 그 틈을 악용하는 공격이 생기기 쉽습니다. 또한 잘못된 형식을 조용히 받아 주면, 규격 자체가 고쳐지지 않은 채 오래 남을 수 있습니다.

최근 인터넷 표준 논의에서는 “관용만으로는 장기적인 상호 운용이 보장되지 않는다”는 비판이 나왔습니다. 마틴 톰슨(Martin Thomson) 등은 규격이 고정되어 있다고 가정한 채 관용만 강조하면, 오히려 모호함이 표준처럼 굳어질 수 있다고 지적했습니다.

그래서 오늘날의 실무는 원칙을 버리기보다 균형을 다듬는 쪽에 가깝습니다.

• 보내기 엄격(Strict Send): 밖으로 나가는 자료는 규격과 검사기를 통과하게 만듭니다.
• 받기 신중(Careful Accept): 허용할 변형의 범위를 문서와 테스트로 분명히 하고, 그 밖은 거절합니다.
• 명세 갱신(Evolve Specs): 현장에서 자주 보이는 차이는 조용히 덮지 말고 규격과 예제를 고쳐 나갑니다.
• 보안 우선(Security First): 관용이 공격 면적을 넓히는지 먼저 살핍니다.

포스텔의 법칙은 ‘완벽한 규격’보다 ‘서로 다른 구현이 함께 사는 법’을 먼저 고민했던 인터넷 초기의 지혜입니다. 동시에, 관용이 모호함과 위험을 키울 수 있다는 경고이기도 합니다.

보낼 때는 더 또박또박, 받을 때는 뜻을 살피되 한계를 분명히 하는 것, 그것이 서로를 잇는 시스템을 만드는 일의 첫걸음입니다.