요구사항과 설계 문서 - 개발 산출물 테일러링 1 (04/08)

AI 시대의 방법론 테일러링 · Ep.04

치수를 재지 않고
옷부터 지었다.

개발 산출물 테일러링 1 - 요구사항과 설계 · HFC Consulting

---

시연회는 성공적이었다. AI로 사흘 만에 만든 프로토타입에 발주 부서가 박수를 쳤다. 석 달 뒤, 검수 회의에서 같은 화면을 두고 싸움이 났다. "이 기능은 저렇게 동작하기로 한 적 없습니다." 근거를 찾으려 요구사항정의서를 폈다. 프로토타입보다 두 달 늦게, 프로토타입을 베껴 쓴 문서였다. 치수를 재기 전에 옷부터 지은 값을 검수 단계에서 치르고 있었다.

개발 산출물의 첫 재단대. 요구사항정의서, 요구사항추적표, 화면설계서, 프로그램명세서 — 형해화 논쟁이 가장 뜨거운 문서들이다.

존재 이유 — 합의를 증명하는 문서와 의도를 전달하는 문서

이 네 문서는 한 묶음으로 불리지만 증명하는 것이 다르다. 요구사항정의서는 합의를 증명한다. 무엇을 만들기로 했는가 — 검수와 하자담보책임의 기준선이고, 표준계약서가 과업 내용의 확정을 요구하는 이유다. 반면 화면설계서와 프로그램명세서는 의도의 전달을 위해 존재했다. 기획자의 머릿속을 개발자의 손으로 옮기는 유일한 통로가 문서였던 시대의 장치다. 1기 3화에서 사라지는 산출물의 목록을 세었다면, 이번에는 어느 것이 사라져도 되는지 가른다.

형해화 — 전달의 문서는 죽고, 합의의 문서는 뒤로 밀렸다

의도가 프롬프트로 직행하는 시대다. 4기 9화에서 본 대로, 스펙을 쓰면 코드가 나온다. 화면은 문서로 그리는 것보다 만들어 보여주는 것이 빠르다. 전달 수단이었던 문서는 존재 이유를 잃었다. 문제는 그 소용돌이에 합의의 문서까지 휩쓸린다는 것이다. 프로토타입이 요구사항을 앞지르면, 합의는 "봤으니 된 것"으로 대체된다. 도입부의 분쟁이 정확히 그 값이다. 본 것과 합의한 것은 다르다. 화면은 동작을 보여주지만, 예외 상황과 데이터 기준과 성능 조건은 보여주지 않는다.

판정 — 요구·설계 산출물 판정표

산출물	판정	근거와 재설계
요구사항정의서	강화	검수 기준선이자 스펙의 원천. 프로토타입 확인 결과를 반영해 갱신하는 살아 있는 합의 문서로 격상
요구사항추적표	축소	수기 대응표는 폐지 수준으로 축소. 요구 ID와 코드·테스트의 연결은 도구가 추적하고 문서는 요약만
화면설계서	축소	동작은 프로토타입이 증명. 문서에는 화면이 못 보여주는 것만 — 예외 처리, 권한, 데이터 규칙
프로그램명세서	폐지	코드와 생성형 문서화가 완전 대체. 유지하는 순간 코드와 어긋나는 이중 진실이 된다
스펙 (실행 가능한 요구 문서)	신설	요구사항정의서와 코드 사이의 새 층위. AI에게 주는 작업 지시이자 검증 기준 — 관리 대상 산출물로 등재

반론과 대응 — 애자일 선언은 문서를 버리라 했는가

반론. "동작하는 소프트웨어가 문서보다 낫다고 애자일 선언이 말하지 않았나." 맞다. 다만 선언의 원문은 문서를 버리라 하지 않았다 — 왼쪽 항목이 더 가치 있다는 우선순위를 말했을 뿐이고, 오른쪽 항목에도 가치가 있다고 명시했다. 발주와 수급이 갈리는 계약 구조에서는, 동작하는 소프트웨어를 무엇에 비추어 검수할지의 기준 문서가 여전히 필요하다. 그 기준이 요구사항정의서다.

실무 원칙은 하나로 정리된다. 프로토타입은 합의를 앞당기는 도구이지, 합의를 대신하는 문서가 아니다. 프로토타입 시연마다 확인된 사항과 변경된 요구를 요구사항정의서에 반영하는 절차를 계약 초기에 세워 두면, 속도와 기준선을 둘 다 가질 수 있다. 그 절차가 없으면 시연이 늘어날수록 검수 기준은 오히려 흐려진다.

요구·설계 체크포인트 — 프로토타입 확인 결과가 요구사항정의서에 반영되는 절차가 있는가 / 화면설계서에서 프로토타입이 대체한 쪽수는 몇 %인가 / 프로그램명세서를 실제로 읽는 사람이 있는가 / 스펙이 산출물 목록에 등재되어 있는가

재단사는 옷을 다 지어 놓고 치수를 재지 않는다. 프로토타입의 속도는 축복이지만, 합의의 순서까지 뒤집으라는 뜻은 아니다. 다음 편은 개발 산출물의 나머지 절반 — 코드와 테스트 증빙이다.

※ 본 연재의 판정·재설계 기준은 일반적 참고용이며, 발주기관의 표준과 계약 조건, 사업 특성에 맞는 조정이 필요합니다.

📎 더 읽을거리
· 소프트웨어 분야 표준계약서 6종 (과학기술정보통신부) — 과업 내용 확정과 검수 기준의 표준 문안
· 애자일 소프트웨어 개발 선언 (한국어) — "동작하는 소프트웨어" 원칙의 원문

HFC Consulting의 관점

프로토타입 중심으로 진행 중인 사업이라면, 요구사항정의서가 검수 기준으로 기능할 수 있는 상태인지 점검해 드립니다. 분쟁은 검수 단계에 터지지만, 원인은 언제나 요구 단계에 있습니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 연재 · AI 시대의 방법론 테일러링
◀ 이전 편 (03/08) 주간보고와 회의록 - 보고 산출물 테일러링
다음 편 ▶ (05/08) 코드와 테스트 증빙 - 개발 산출물 테일러링 2
연재 전체 보기 →