비어 있는 spec/ 폴더가 곧 기능이다

NOKTRA 도구 셋은 언뜻 보면 기능 누락처럼 보이는 설계 결정을 공유합니다. RAM Toolkit은 MIL-HDBK-217F 계수 없이 출하됩니다. Ch10 Viewer는 IRIG 106 패킷 레이아웃 없이 출하됩니다. SECS/GEM Workbench는 SEMI 와이어 상수 없이 출하됩니다. 상자를 열면 셋 모두 자신이 막혀 있음을 분명히 알리고, 표준에 의존하는 것은 아무것도 파싱하지도 계산하지도 않습니다.

메커니즘은 셋 다 같습니다: 실행 파일 옆 spec/ 폴더의 평문 파일. 사람이 자기가 보유한 표준 사본에서 옮겨 적습니다 — 각 값마다 출처 절·페이지 표기와 함께. 로더는 출처 없는 행을 거부합니다. 파일을 채우면 제품 전체가 살아납니다. 재빌드도, 코드 수정도 없이.

왜 비워서 출하하는가? 첫 번째 이유는 법적이고 재미없습니다: 이 표준들은 라이선스 문서이고, 그 상수는 도구 제작자가 재배포할 수 있는 것이 아닙니다. 하지만 더 깊은 이유는 실패 양식에 있습니다. 어렴풋이 기억하는 계수로 도출된 신뢰도 수치, 추측한 바이트 오프셋으로 디코드된 비행시험 채널, 남의 구현에서 베껴온 포맷 코드로 파싱된 SECS 프레임 — 이것들은 요란하게 실패하지 않습니다. 그럴듯하지만 틀린 숫자를 만들어냅니다. 그리고 '그럴듯하지만 틀림'은 검증에서 가장 비싼 실패 유형입니다. 분석이 끝난 뒤에, 다른 사람에 의해 발견되기 때문입니다.

옮겨 적기 단계는 보이지 않는 리스크를 보이는 잡무로 바꿉니다. 그렇습니다, 누군가 핸드북과 텍스트 에디터로 오후를 보내야 합니다. 그 대가로 파이프라인의 모든 상수에 이름이 붙습니다 — 이 값은, 이 표에서, 이 페이지에서, 이 사람이 입력했다. 감사관이 숫자의 출처를 물을 때 답은 출처 표기이지, 고고학 프로젝트가 아닙니다. RAM Toolkit은 한 걸음 더 갑니다: 모든 리포트가 생성 시점에 유효했던 spec 발췌를 명시합니다.

이 메커니즘에는 조용한 능력 하나가 숨어 있습니다. 레이아웃이 코드가 아니라 데이터이므로, 비표준 변형 — 벤더의 사설 확장, 프로그램 특유의 프레이밍 — 은 벤더에게 빌드를 요청하는 게 아니라 텍스트 파일을 고쳐서 다룹니다. 정직을 강제하는 게이트가 곧 확장 지점을 겸합니다.

이 패턴은 훔쳐갈 만한 규칙으로 일반화됩니다: 도구의 정확성이 법적으로든 신뢰성으로든 내장할 수 없는 문서에 의존한다면, 도구는 그 문서의 '형태'를 지니되 '내용'을 추측하기를 거부해야 한다. 덜 담아 요란하게 출하하는 것이, 더 담아 틀리게 출하하는 것을 이깁니다.