요구사항 정의는 AI 목업(Mock) 선행으로 변경: 인식 차이를 구현 전에 해소하는 절차

• AI 목업(AIモック) 선행의 요구사항 정의란, 사양서(仕様書)를 작성하기 전에 AI로 작동하는 화면 목업을 만들고, 그것을 보면서 의뢰인과 인식을 맞추어 나가는 진행 방식입니다.
• 글(文章)의 요구사항 정의에서는 '읽는 사람마다 다른 그림이 머릿속에 떠오르기' 때문에 차이가 남게 되지만, 목업이라면 모두가 같은 화면을 보기 때문에, 차이를 구현 전에 표출할 수 있습니다.
• 다만, 목업은 외형적인 합의에는 강한 반면, 비기능 요구사항이나 예외 처리에 약하기 때문에, 글로 된 사양과 병용한다는 전제 하에 사용하는 것이 현실적입니다.

요구사항 정의서를 작성했는데도, 구현 후에 '생각했던 것과 다르다'는 말을 들은 경험이 없으신가요?

원인은 단순히 글이 모호해서만은 아닙니다. 같은 글을 읽어도 사람은 자신의 경험으로 공백을 채웁니다. 예를 들어 '일람 화면에서 필터링할 수 있음'이라고 썼다고 가정해 보겠습니다.

• 의뢰인은 상단 검색 박스를 상상합니다.
• 디자이너는 좌측 필터 패널을 상상합니다.
• 구현자는 일단 드롭다운만 놓으면 된다고 생각합니다.

모두가 '합의했다'고 생각했지만, 머릿속 그림은 사람마다 다릅니다. 게다가 이 차이는 글 리뷰로는 거의 발견할 수 없습니다. 아무도 틀린 것을 쓰지 않았기 때문입니다.

• 공백을 읽는 사람이 임의로 보완합니다.
• 화면 전환이나 상태 변화가 글로 되어 있으면 따라가기 어렵습니다.
• 의뢰인이 리뷰를 흘려 읽기 쉽습니다 (긴 문서는 읽히지 않습니다).

세 번째는 특히 심각합니다. 긴 사양서에 '문제없습니다'라고 답한 사람이, 작동하는 화면을 보자마자 수정점을 10개나 제시하는 경우입니다. 현장에서는 흔히 볼 수 있는 광경입니다.

AI 목업 선행이란, 요구사항을 글로 확정하기 전에, AI 코딩 도구로 작동하는 화면의 초안을 만들고, 그것을 공통의 '정답 후보'로서 논의하는 방법입니다.

예전에는 목업 제작이 디자이너의 일이었습니다. 시간과 노력이 걸리기 때문에, 요구사항이 확정된 후에 만드는 것이 일반적이었습니다. AI가 이 과정을 몇 분에서 몇 시간으로 단축시키면서, 순서를 바꿀 의미가 생겼습니다. 즉 '목업은 합의의 결과'에서 '목업은 합의의 재료'로 변한 것입니다.

• 용어의 불일치: '고객'이 법인을 지칭하는지 개인을 지칭하는지
• 세밀도의 불일치: 한 화면으로 끝내고 싶은 사람과 위자드(Wizard) 형태를 상상한 사람
• 권한의 불일치: 누가 편집할 수 있고, 누가 보기만 할 수 있는지
• 상태의 불일치: '완료' 후에 취소할 수 있는지
• 우선순위의 불일치: 의뢰자가 실제로 사용하는 것은 사실 2가지 기능뿐이었다

용어나 권한의 불일치는 문장으로도 작성할 수 있습니다. 그럼에도 누락되는 부분은, 작성하는 쪽이 '당연하다'고 생각하기 때문입니다. 화면에 더미 데이터를 배치하면, 그 당연함이 실제 숫자나 글자로 바뀌면서 위화감으로 나타납니다.

참고 기사를 읽고 같은 절차를 자신의 업무에 대입하여 머릿속으로 추려보았습니다. 가장 효과적일 것 같다고 느낀 것은 스텝 2의 '요 확인 배지'입니다.

저는 평소 모호한 부분을 질문 목록으로 정리하여 의뢰자에게 보냅니다. 하지만 리스트는 '질문이 떠오른 만큼'만 쓸 수 있습니다. AI가 임의로 보완한 부분을 기계적으로 도출해내는 형태라면, 생각나지 않았던 질문까지도 포착할 수 있을 것이라고 읽으면서 예상했습니다. 이 점은 소규모 프로젝트에서 실제로 시도하여 확인하고 싶은 부분입니다.

편리한 방법이지만 만능은 아닙니다. 다음과 같은 경우에는 문서 선행이 더 안전합니다.

• 화면이 거의 없는 프로젝트: 배치 처리, 데이터 연동, API 설계가 중심이라 보여줄 것이 없습니다

• 비기능 요구사항이 주역인 프로젝트: 성능, 가용성, 보안은 목업으로는 확인할 수 없습니다

• 계약상 사양서가 결과물이 되는 프로젝트: 목업만으로는 나중에 '어디까지가 범위인지'를 보여주기 어려워집니다

• 법령/감사 대응이 무거운 영역: 근거를 문장으로 남겨야 합니다

• 목업이 너무 훌륭해서 '이미 완성되었다'고 오해받을 수 있습니다.

• 외관상의 논의만 활발해지고, 업무 규칙 확인이 소홀해질 수 있습니다.

• AI가 보완한 사양이 확인되지 않은 채 확정되어 버릴 수 있습니다.

• 목업 코드를 그대로 본방에 적용하여 품질 부채를 안게 될 수 있습니다.

첫 번째 문제에 대한 대책은 처음부터 '버리다'라고 입 밖에 내는 것입니다. 더미 데이터임을 화면 위에도 명기해 두면, 오해가 생길 가능성이 더욱 줄어듭니다.

'문서로 논리적으로 채우고 싶은' 유형의 의뢰자에게는 목업이 가볍게 보일 수 있습니다. 그럴 경우, 목업과 짧은 문서를 나란히 제시하면 받아들이기 쉬워집니다.

목업과 사양서 둘 다 있으면, 어느 것이 맞는 것인지 혼란스러운 상황이 생깁니다. 미리 정해두어야 할 규칙은 다음 2가지입니다.

• 합의 후, 정답은 사양서로 하고, 목업은 참고 자료로 격하합니다.
• 목업 코드는 원칙적으로 본방에 가져오지 않습니다.

애자일 소프트웨어 개발 선언문에도 '포괄적인 문서보다 작동하는 소프트웨어를'라고 되어 있지만(https://agilemanifesto.org/iso/ja/manifesto.html), 이는 문서를 버리라는 의미가 아닙니다. 오른쪽(문서)에도 가치가 있음을 명시하고 있습니다. 목업과 문서는 역할 분담으로 사용해야 합니다.

우선은 손에 있는 작은 프로젝트 하나를 골라보세요. 사양서를 쓰기 시작하기 전 30분을 목업 생성 및 의뢰자와의 조작 확인에 사용합니다.

시도한 후에 확인하고 싶은 것은 다음 질문입니다.

• 문서만으로는 발견하지 못한 불일치는 몇 개였는가?
• 요 확인 배지 중, 의뢰자가 즉답할 수 없었던 것은 무엇인가?

이 두 가지 답이 자신의 팀에서 목업 선행을 표준으로 삼아야 할지 판단하는 자료가 됩니다.

코드를 작성하여 움직일 수 있는 AI 코딩 툴이라면 기본적으로 어떤 것이든 상관없습니다. Claude Code와 같은 에이전트형 툴은 파일 생성부터 수정까지 일관되게 의뢰할 수 있습니다. 단일 HTML 파일로 출력하게 하면 공유도 쉽습니다.

쓸모 없어지는 것은 아닙니다. 목업으로는 비기능 요구사항, 예외 처리, 권한의 세부 규칙 등이 전달되지 않기 때문에, 합의 후에 목업에서 사양을 문장으로 만드는 것이 기본입니다. 글을 쓰는 순서만 바뀔 뿐입니다.

단일 HTML 파일이라면 브라우저로 열기만 하면 만져볼 수 있습니다. 화면 공유로 설명하는 것보다 본인이 조작하는 편이 지적의 질이 높아집니다. 조작 중 나오는 발언을 기록해 두면, 나중에 요구사항에 반영하기 쉽습니다.

실수는 오히려 예상 범위 내입니다. 목업의 목적은 정답을 만드는 것이 아니라, 불일치를 찾는 것이기 때문입니다. AI에게 '불명확한 점은 요 확인 배지로 표시하라'고 지시해 두면, 잘못된 보완을 찾기 쉬워집니다.

추천하지 않습니다. 목업은 더미 데이터 전제이며, 설계나 테스트도 고려되지 않았기 때문입니다. 화면 구성이나 문구는 참고하되, 본방 구현은 별도로 재설계하는 편이 안전합니다.

화면을 중심으로 사용하는 업무 도구나 신규 서비스의 출범에 적합합니다. 의뢰자 스스로가 요구사항을 언어화하지 못한 단계에서 특히 효과를 보기 쉽습니다. 반대로 배치 처리나 API 중심의 프로젝트에서는 효과가 제한적입니다.

작은 프로젝트에서 단 한 번만 시도해보고, 오차가 발견된 횟수를 기록하는 것이 현실적입니다. 실제 성과를 보여주면 팀 전체에 제안하기가 더 수월합니다. 처음부터 표준 프로세스에 통합하려고 하지 않는 편이 성공적입니다.