서핑베어
홈 › 블로그 › 명세서 품질과 비용
명세서 품질이 개발 비용을 어떻게 바꾸는가
명세서를 더 자세히 쓸수록 항상 싸지는 것은 아닙니다. 비용을 줄이는 상세함과, 비용만 늘리는 상세함이 나뉩니다.
비용을 줄이는 상세함 과잉 명세 경계 설정
결론부터
명세서가 부실하면 개발사는 불확실성을 견적에 여유로 넣습니다. 그래서 부실한 명세서는 대개 비쌉니다.
그런데 반대로도 실패합니다. 구현 방법까지 지정하면 개발사는 더 좋은 방법을 알아도 쓸 수 없고, 명세대로 만든 결과가 원하는 결과와 다를 때 책임이 우리에게 옵니다. 상세히 쓸 곳과 열어 둘 곳이 따로 있습니다.
상세히 쓰면 비용이 줄어드는 것
지정하면 비용만 늘어나는 것
| 과잉 명세 | 왜 문제인가 | 대신 쓸 것 |
|---|---|---|
| 사용할 기술 스택 지정 | 개발사의 숙련 스택을 못 쓰게 만듭니다 | 성능·유지보수 요건으로 표현 |
| DB 테이블 구조 지정 | 요구사항이 바뀔 때 함께 틀어집니다 | 저장해야 하는 정보 항목만 명시 |
| 화면 픽셀 단위 지시 | 디자인 검토 비용이 반복됩니다 | 화면에 있어야 하는 정보와 동작 |
| 내부 알고리즘 지정 | 더 나은 방법을 배제합니다 | 입력과 기대 출력, 정확도 기준 |
| 일정 세부 배분 지정 | 실제 작업 순서와 충돌합니다 | 마일스톤과 검수 시점만 |
경계를 나누는 한 문장 기준
판단 기준은 하나입니다 — "이것이 틀리면 결과가 우리 업무에서 못 쓰이는가?" 그렇다면 명세합니다. "이것은 방법의 문제인가?" 그렇다면 열어 둡니다.
예를 들어 "월말 정산 시 미승인 건은 제외한다"는 업무 규칙이고, 틀리면 결과를 못 씁니다. 반드시 명세합니다. "정산 배치는 새벽 2시에 실행한다"는 방법이고, 요건은 "다음 영업일 시작 전까지 완료"입니다. 후자로 쓰면 개발사가 더 안전한 구성을 고를 수 있습니다.
이 기준으로 명세서를 한 번 훑으면 대개 분량이 줄고 정확도는 올라갑니다. 줄어든 부분이 과잉 명세였던 것입니다.
명세 정밀도가 계약 방식과도 연결된다
명세가 확정적이면 고정가 계약이 서로에게 유리합니다. 범위가 분명하니 개발사도 여유를 크게 넣을 이유가 없습니다.
반대로 요구사항이 진행하며 드러날 성격이면 고정가가 위험합니다. 변경마다 협상이 붙고, 개발사는 초기에 큰 여유를 넣습니다. 이때는 단계 분할이나 기간 단위 계약이 총비용에서 나은 경우가 있습니다.
어느 방식이든 변경 관리 절차는 계약에 넣으세요 — 변경 요청 형식, 영향 산정 방법, 승인 주체. 이 절차가 없으면 프로젝트 중반의 모든 변경이 분쟁이 됩니다.
자주 묻는 질문
명세서를 개발사가 써 주면 안 됩니까?
가능하지만 업무 규칙은 우리가 확정해야 합니다. 개발사가 쓴 명세서를 우리가 검토하는 방식이 현실적이고, 이때 검토의 초점은 "업무가 맞게 반영됐는지"입니다.
분량이 얼마나 되어야 적당합니까?
분량 기준은 없습니다. 위 여섯 항목이 다 있고 과잉 명세가 없으면 적당합니다. 화면 설명이 절반 이상인 명세서는 대개 과잉 쪽입니다.
중간에 요구사항이 바뀌면 어떻게 합니까?
바뀌는 것은 정상입니다. 중요한 것은 변경 관리 절차가 계약에 있는지입니다. 절차가 있으면 변경은 비용 산정의 문제이고, 없으면 분쟁이 됩니다.
AI로 명세서를 쓸 수 있습니까?
구조와 누락 점검에는 적합합니다. 위 여섯 항목이 다 채워졌는지 확인하게 하는 용도가 특히 유용합니다. 업무 규칙과 완료 기준은 사람이 확정해야 합니다.