노트포스텔의 법칙
Postel's Law (Robustness Principle)
설계#architecture · 연결된 개념 5개
쉽게 말하면
포스텔의 법칙은 '내가 보내는 건 꼼꼼하게, 남이 보낸 건 너그럽게 받자'는 말이에요. 악필 편지도 웬만하면 읽어 내는 우체부처럼, 서로 조금씩 달라도 시스템끼리 잘 통하게 하려는 거예요.
비유가 깨지는 곳 너무 너그러우면 잘못된 입력이 사실상 표준이 되어 나중에 못 바꾸고, 보안에서는 검증 우회의 틈이 돼요. 그래서 요즘은 어긋난 입력을 분명히 거절하라는 쪽으로 무게가 옮겨 가요.
"자신이 하는 일에는 보수적으로, 남에게서 받는 것에는 관대하게." 존 포스텔(Jon Postel)이 TCP(Transmission Control Protocol) 명세에 적은 견고성 원칙(Robustness Principle)이다. 출력은 명세를 엄격히 지키고, 입력은 조금 어긋나도 받아들여 시스템 간 상호 운용성을 높이라는 뜻이다.
- API(Application Programming Interface)를 설계할 때 응답 형식은 엄격하게 지키고, 요청은 사소한 차이(대소문자, 여분 필드 등)를 너그럽게 받는다
- 브라우저가 잘못된 HTML(HyperText Markup Language)도 최대한 렌더링하는 것이 관대한 수신의 예다
한계
- 관대하게 받아 준 잘못된 입력은 곧 사실상의 표준이 되어, 나중에 엄격하게 바꿀 수 없게 된다(하이럼의 법칙)
- 보안에서는 오히려 위험하다. 애매한 입력을 너그럽게 해석하면 검증 우회의 틈이 된다. 신뢰 경계에서는 엄격하게 검증한다(Bean Validation, 프로토타입 오염)
- 그래서 최근에는 "명확히 정의하고, 어긋난 입력은 분명하게 거절하라"는 쪽으로 무게가 옮겨 가는 추세다
출처: Laws of Software Engineering: Postel's Law · RFC 761 2.10절 Robustness Principle
연결된 개념
이 노트를 가리키는 문서
뜻이 가까운 노트
- 데이터 무결성
데이터 무결성(data integrity)은 저장된 데이터가 정확하고 일관되며 믿을 수 있는 상태로 유지되는 것이다. 재고가 100개로 보이는데 실제로 50개라면 무결성이 깨진 것이다. 관계형 DB는 이를 제약 조건(constraint)으로 강제한다.
- 심플 디자인
켄트 벡이 XP(Extreme Programming)에서 제시한 단순한 설계의 네 가지 규칙. 우선순위 순으로 ① 모든 테스트를 통과하고 ② 의도를 드러내고 ③ 중복이 없고 ④ 요소가 가장 적다. 마틴 파울러가 이렇게 정리한 형태가 널리 쓰인다.
- 최종 일관성
최종 일관성(eventual consistency)은 "지금 당장은 저장소마다 값이 다를 수 있지만, 새 변경이 멈추면 결국 같아진다"는 보장이다. 원본 DB와 검색 색인·캐시·다른 서비스처럼 물리적으로 분리된 저장소를 한 트랜잭션으로 묶을 수 없을 때 받아들이는 일관성 모델(consistency model)이다.
- 누수 추상화의 법칙
자명하지 않은 모든 추상화는 어느 정도 새어 나온다는 법칙. 조엘 스폴스키(Joel Spolsky)가 2002년 글에서 TCP(Transmission Control Protocol)가 불안정한 IP(Internet Protocol) 위에서 신뢰성을 흉내 내지만 결국 네트워크 문제가 드러나는 사례 등으로 소개했다.
- 테스트 냄새
테스트 코드나 테스트 습관에서 나는, 더 깊은 문제를 알리는 신호. 제라드 메스자로스의 xUnit 테스트 패턴 정리가 이름을 붙였다.