지금도 수많은 개발자들이 요구사항을 문서화하고, 그 문서를 바탕으로 코드를 작성한다. 그 과정에서 종종 등장하는 질문이 있다. “충분히 상세한 사양(spec)이면 실제 코드와 같은가?” 이 물음은 단순히 문서의 양에 관한 것이 아니라, 우리가 소프트웨어를 어떻게 사고하고 만들어 가는지에 대한 깊은 고민을 필요로 한다.
사양이란 말은 보통 이해하기 쉬운 언어로 기능과 제약 조건을 정리한 것이다. 하지만 실제 개발 현장에서는 이 사양이 얼마나 ‘정확’해야 하는지가 문제된다. 한 단락이라도 모호하면 구현자는 그 부분을 자유롭게 해석하게 되고, 결국 서로 다른 버전의 소프트웨어가 탄생한다. 반대로 사양이 지나치게 세밀해지면 문서 자체가 코드처럼 길어지고, 읽고 쓰는 데 드는 시간이 커진다.
이런 점에서 사양과 코드는 같은 영역에 속할 수 있다. 둘 다 문제를 정의하고 해결책을 명세하는 작업이며, 두 방식 모두 정확성을 요구한다. 실제로 ‘충분히 상세한’ 사양은 테스트 케이스와 거의 동일한 역할을 수행한다. 테스트가 실패하면 사양이 잘못됐음을 알리는 신호가 되고, 반대로 사양이 완전하다면 테스트 없이도 코드가 올바르게 동작할 가능성이 높아진다.
하지만 여기에는 또 다른 문제가 있다. 사양을 코드를 닮게 만들면 그 자체로 버그를 유발할 수 있다. 문서화 과정에서 생기는 ‘정적’ 오류는 나중에 실행해 보지 않으면 발견하기 어렵다. 코드와 마찬가지로 사양도 반복적인 검증과 리뷰가 필요하다.
그래서 최근 논의되는 아이디어 중 하나는 ‘버전 관리된 사양(specification) 시스템’을 도입하는 것이다. 버전 관리는 소스 코드를 관리할 때처럼 사양을 추적하고, 변경 이력을 명확히 보존한다. 또한 CI/CD 파이프라인에 사양 검증 단계를 넣어 자동으로 오류를 잡아내는 방식이다. 이는 개발자들이 사양을 코드와 동일시하면서도 실수를 최소화하는 방법 중 하나다.
그럼에도 불구하고, 사양과 코드를 완전히 교환 가능한 개념으로 보는 것은 위험하다. 사양은 여전히 비즈니스 이해관계자와 기술 팀 간의 의사소통 도구이며, 그 목적은 ‘정확한 요구를 전달’하는 데 있다. 반면 코드 자체는 실행 가능한 구현이다. 두 가지가 서로 보완적이어야 하며, 어느 한쪽이 다른 쪽을 완전히 대체할 수 없다는 점을 기억해야 한다.
결국 사양이 코드처럼 정밀해지면 개발 과정에서 불필요한 복잡성을 줄일 수 있지만, 동시에 문서화와 검증에 드는 비용도 늘어난다. 이 균형을 잡는 것이 바로 현대 소프트웨어 엔지니어링의 핵심 과제 중 하나이다.
원문 링크: https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
