스펙 부채는 고친다고 사라지지 않습니다. 이동할 뿐입니다.
문제를 해결한다고 해서 반드시 해결되는 것은 아닙니다. 때로는 문제를 다른 곳으로 옮길 뿐입니다.
최근에 스펙 부채(spec debt)를 찾기 위해 프로젝트를 감사했습니다. 스펙 부채란 버그나 잘못된 AI 동작을 유발하는 지침상의 공백을 의미합니다. 저는 7가지 특정 항목을 수정했습니다. 수정 후 테스트는 통과했고, 모든 결과는 '그린(pass)'으로 나타났습니다.
하지만 부채는 사라지지 않았습니다. 피처 파일(feature files)에서 스텝 정의(step definitions)로 이동했을 뿐입니다.
이러한 항목들을 수정하며 배운 점은 다음과 같습니다:
- 정밀함이 중요합니다. "응답이 빠르다"라고 말하는 대신, "주문 제출 후 12초 이내에 응답이 반환된다"라고 말하세요. 이렇게 해야 타이밍을 명확히 고정할 수 있습니다.
- 모호함을 피하세요. "2회 재시도"는 불분명합니다. 총 시도가 2번이라는 뜻인가요, 아니면 3번인가요? 확실하게 하기 위해 "총 결제 요청은 2회를 초과할 수 없다"와 같이 표현하세요.
- 메커니즘의 이름을 명시하세요. "재고가 해제된다"라고 말하는 것은 모호합니다. "재고 서비스가 품목 X에 대한 해제 요청을 받는다"라고 구체적으로 명시하세요.
- 거짓 보증을 제거하세요. 아직 기능이 존재하지 않아서 특정 단계가 통과되는 것이라면, 그 단계를 삭제하세요. 존재하지 않는 흐름에 대해 통과된 테스트는 거짓입니다.
- "정확함"을 정의하세요. 구체적인 값 없이 "정확한" 또는 "적절한"과 같은 단어를 사용하지 마세요. "올바른 ID를 포함한다" 대신 "order_id 123을 포함한다"라고 사용하세요.
이러한 문제를 찾기 위한 프레임워크를 구축했습니다. 모든 시나리오에 대해 다음 다섯 가지 질문을 던져보세요:
- 이 시나리오의 소유자는 누구인가?
- 이로 인해 결정되지 않고 남겨진 사항은 무엇인가?
- 모든 용어가 여기서 정의되었는가?
- 이것은 동작(behavior)을 설명하는가, 구현(implementation)을 설명하는가?
- 이 설명에서 누락된 것은 무엇인가?
가장 큰 함정은 텍스트와 코드 사이의 간극입니다. 스펙에 완벽하고 정밀한 지침을 작성할 수 있습니다. 하지만 기반 코드가 해당 테스트를 통과하기 위해 지름길(shortcut)을 사용한다면, 여전히 부채는 남아 있습니다.
스펙에는 "API를 통해 주문을 생성한다"라고 되어 있습니다. 하지만 실제 코드는 시간을 아끼기 위해 데이터베이스에 주문을 직접 주입(inject)합니다. 테스트는 통과하지만, 부채는 요구사항에서 구현 단계로 이동한 것입니다.
처음부터 완벽한 스펙을 쓰려고 하지 마세요. 일단 쓰고, 감사하고, 수정하세요.
Source: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25
Optional learning community: https://t.me/GyaanSetuAi