견고함의 원칙

전산에서 견고함의 원칙(robustness principle)은 소프트웨어를 위한 일반적인 설계 지침이다.

당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게. (종종 “보내는 것은 엄하게, 받는 것은 너그럽게”로도 일컬어진다.)

이 원칙은 전송 제어 프로토콜(TCP)의 초기 명세를 쓴 존 포스텔(Jon Postel)의 이름을 따, 포스텔의 법칙(Postel's law)이라는 이름으로도 알려져 있다.

TCP 구현은 견고함의 원칙을 따라야 한다: 당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게.

명령이나 자료를 다른 컴퓨터(또는 같은 컴퓨터의 다른 프로그램)에 보내는 코드는 명세를 철저하게 따르되, 입력을 받는 코드는 의미가 분명한 한은 명세를 따르지 않는 입력까지도 받아들여야 한다.

해석

RFC 1122(1989년)는 포스텔의 원칙을 보충하여, 프로그래머가 “가능한 최악의 효과를 나도록 고안된 패킷을 전송하는 악의적인 존재들로 네트워크가 채워져 있다고 간주”하길 권했다. 프로토콜은 모르는 코드를 포함한 메시지도 받아들이는 식으로 나중 버전에서 기존의 필드에 새로운 코드가 추가될 것을 감안해야 한다. 프로그래머는 “프로토콜에 명세되어 있긴 하나 불분명한 기능들”은 보내는 메시지에 포함하지 말아야 한다. 메시지를 받는 쪽에서 미처 구현하지 못한 기능일 수 있다. 또, “명세대로 동작하지 않는 다른 호스트와도 잘 돌아가게만 할 것이 아니라, 그런 호스트들이 공유 통신 설비에 악영향을 초래하는 것도 제한하는 식으로 협조”하도록 코드를 설계해야 한다.

반론

RFC 3117에서, 마셜 로즈(Marshall Rose)는 새로운 응용 프로토콜을 설계함에 있어 포스텔의 원칙을 적용할 때 만나는 여러 현실적인 문제를 지적했다. 예를 들어, 한 결함이 있는 구현이 명세에서 벗어난 메시지를 보내게 되어 있고, 그런 메시지를 허용하는 구현들하고만 연결되어 쓰이고 있었는데, 몇년 후 그런 메시지를 허용하지 않는 구현과도 연결되게 된다. 그런 상황에서 발생하는 문제는 확인이 불가능할 때가 많고, 해결하는 비용도 커질 수 있다. 마셜 로즈는, 그런 이유로 “추가적인 구현 비용을 요수하게 되더라도 … 프로토콜에서의 명시적으로 정합성 검사”를 권했다.

같이 보기

• 개방-폐쇄 원칙
• 유닉스 철학