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

이 글의 요점

• AI 목업 선행의 요구사항 정의란, 사양서(Specification)를 작성하기 전에 AI로 작동하는 화면 목업을 만들고, 그것을 보면서 의뢰자와 인식을 맞추는 진행 방식입니다.
• 문서 기반의 요구사항 정의에서는 '읽은 사람마다 다른 그림이 머릿속에 떠오르는' 경향 때문에 인식 차이가 남지만, 목업이라면 모두가 같은 화면을 보기 때문에, 그 인식 차이를 구현 전에 표면화할 수 있습니다.
• 다만, 목업은 시각적 합의에는 강한 반면, 비기능 요구사항이나 예외 처리에 취약하므로, 문서 사양과 병행하여 사용하는 것이 현실적입니다.

요구사항 정의에서 인식 차이가 발생하는 이유

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

원인은 단순히 문서가 모호해서만은 아닙니다. 같은 문장을 읽어도 사람은 자신의 경험으로 빈틈을 채웁니다. 예를 들어 '목록 화면에서 필터링이 가능해야 한다'라고 썼다고 가정해 봅시다.

• 의뢰자는 화면 상단의 검색 박스를 상상합니다.
• 디자이너는 왼쪽의 필터 패널을 상상합니다.
• 구현자는 일단 드롭다운 메뉴를 놓으면 된다고 생각합니다.

모두가 '합의했다'고 생각하지만, 머릿속 그림은 사람마다 다릅니다. 게다가 이 차이는 문서 리뷰에서는 거의 발견되지 않습니다. 아무도 잘못된 것을 쓰지 않았기 때문입니다.

문서 사양이 안고 있는 3가지 약점

• 빈틈을 읽는 사람이 임의로 보완함
• 화면 전환이나 상태 변화가 글자로서는 추적하기 어려움
• 의뢰자가 리뷰를 흘려보기 쉬움 (긴 문서는 읽히지 않음)

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

AI 목업 선행의 요구사항 정의란

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

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

기존 방식과의 비교

절차: AI 목업 선행으로 요구사항을 확정하는 5단계

여기서는 Claude Code와 같은 코딩 에이전트를 사용한다고 가정하고 작성했습니다 (공식 문서: https://docs.claude.com/en/docs/claude-code/overview). 다른 도구에서도 생각은 같습니다.

단계1: 목록(Bullet Point) 1장만 준비하기

사양서는 쓰지 않습니다. 히어링 메모를 A4 용지 1장 분량의 목록으로 정리합니다.

• 누가 사용할 것인가 (역할)
• 무엇을 달성하고 싶은가 (목적)
• 현재 어떤 어려움이 있는가 (현황)

기능 목록은 이 단계에서는 불필요합니다. 기능을 먼저 나열하면, 목업이 '기능의 전시'가 되어버립니다.

단계2: '폐기 가능한 것(Throwaway)'임을 명시하고 목업을 생성하게 하기

첫 번째 지시에서 본 버전 품질을 요구하지 않는다고 전달합니다. 다음은 프롬프트 예시입니다.

아래 메모를 바탕으로 화면 목업 1개를 만들어 주세요.
- 목적: 영업 담당자가 당일 방문 예정을 확인하고, 결과를 입력한다
- 제약: 백엔드는 필요 없음. 데이터는 더미(Dummy)로 코드 내에 포함
...

핵심은 '불명확한 점은 요 확인 배지(Badge)로 표시하게 하는 것'입니다. AI는 빈틈을 자연스럽게 채워버리기 때문에, 채운 부분을 시각화하면 그 부분이 그대로 질문 목록이 됩니다.

단계3: 의뢰자에게 '만져보도록' 하기

화면 공유로 보는 것만으로는 부족합니다. 의뢰자 본인에게 조작해 보도록 하고, 멈춘 곳, 되물은 곳을 기록합니다.

인식이 일치하면, 확정된 목업(Mock-up)을 근거로 사양(仕様)을 문장으로 작성합니다. 화면별 항목, 입력 체크, 상태 전이 등을 목업을 보면서 적어 나갑니다.

여기서 비로소 문서가 등장합니다. 순서만 바뀌었을 뿐인데도, 문서의 정확도는 상당히 높아질 것입니다. '쓰기 전에 답이 손에 있는' 상태이기 때문입니다.

목업에서 발견되는 인식 차이의 전형적인 예시

참고 기사와 일반적인 개발 현장의 사례를 바탕으로, 목업을 통해 드러나기 쉬운 차이점들을 정리합니다.

• 용어의 차이: '고객'이 법인을 지칭하는지 개인을 지칭하는지
• 세부 수준(粒度)의 차이: 한 화면에서 끝내고 싶은 사람과, 위자드 형식(Wizard form)을 상상한 사람
• 권한의 차이: 누가 편집할 수 있고, 누가 열람만 할 수 있는지
• 상태의 차이: '완료' 이후에 취소할 수 있는지
• 우선순위의 차이: 의뢰자가 실제로 사용하는 것은 사실 2가지 기능뿐이었던 경우

용어나 권한의 차이는 문서로도 작성할 수 있습니다. 그럼에도 누락되는 이유는, 작성하는 쪽이 '당연하다'고 생각하고 있기 때문입니다. 화면에 더미 데이터(Dummy data)를 놓으면, 그 당연함이 실제 숫자나 문자가 되어 이질감으로 나타납니다.

실제로 정리해 본 소감

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

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

단점・적합하지 않은 사람・잘 안 되는 경우

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

적합하지 않은 경우

• 화면이 거의 없는 프로젝트: 배치 처리(Batch processing), 데이터 연동, API 설계가 중심이라면 보여줄 것이 없습니다.
• 비기능 요구사항이 주역인 프로젝트: 성능, 가용성, 보안은 목업으로는 확인할 수 없습니다.
• 계약상 사양서가 성과물이 되는 프로젝트: 목업만으로는 나중에 '어디까지가 범위인지'를 보여주기 어려워집니다.
• 법령・감사 대응이 무거운 영역: 근거를 문서로 남길 필요가 있습니다.

발생하기 쉬운 실패

• 목업이 너무 훌륭해서 '이미 완성되었다'고 오해받는 경우
• 외관에 대한 논의만 과열되어 업무 규칙 확인이 소홀해지는 경우
• AI가 보완한 사양이, 확인되지 않은 채 확정되는 경우
• 목업 코드를 그대로 본방(本番)에 유용하여 품질 부채를 안게 되는 경우

첫 번째 항목에 대한 대책은, 처음부터 '버리다'라고 입으로 말하는 것입니다. 더미 데이터임을 화면상에도 명기해 두면, 오해가 줄어듭니다.

적합하지 않은 사람

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

운영 요령: 목업을 사양의 '정답'으로 삼지 않기

목업과 사양서가 모두 있으면, 어느 것이 옳은지 헷갈리는 상황이 생깁니다. 정해두어야 할 규칙은 다음 두 가지입니다.

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

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

다음에 취할 행동

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

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

• 문서만으로는 발견하지 못한 차이점은 몇 개였는가?
• 확인 필요 배지 중, 의뢰자가 즉답하지 못했던 것은 무엇인가?

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

자주 묻는 질문

AI로 목업을 만들 때, 어떤 도구를 사용하면 좋을까요?

코드를 작성하여 작동시킬 수 있는 AI 코딩 도구라면, 기본적으로 어느 것이나 괜찮습니다. Claude Code와 같은 에이전트형 도구는 파일 생성부터 수정까지 일관되게 의뢰할 수 있습니다. 단일 HTML 파일로 출력하게 하면 공유도 쉽습니다.

목업 선행이면, 요구사항 정의서는 필요 없나요?

필요하지 않습니다. 목업(Mock-up)으로는 비기능 요구사항, 예외 처리, 권한 세부 사항 등이 전달되지 않기 때문에, 합의 후에 목업을 문장으로 명세화하는 것이 기본입니다. 단지 문서 작성 순서가 바뀔 뿐입니다.

비엔지니어 의뢰자에게도 목업을 만져보게 할 수 있나요?

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

AI가 만든 목업 내용이 틀렸다면 어떻게 하나요?

오히려 오류는 예상 범위 내에 있습니다. 목업의 목적은 정답을 만드는 것이 아니라, 오차(ズレ)를 찾는 것이기 때문입니다. AI에게 '불명확한 점은 확인 필요 배지로 표시'하도록 지시하면 잘못된 보완점을 찾기 쉽습니다.

목업 코드를 그대로 본방에 사용해도 되나요?

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

목업 선행이 특히 적합한 프로젝트는 어떤 경우인가요?

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

사내에서 목업 선행을 제안할 때 무엇부터 시작해야 하나요?

작은 프로젝트로 한 번만 시도해 보고, 오차를 발견한 건수를 기록하는 것이 현실적입니다. 실적을 보여줄 수 있다면 팀 전체에 대한 제안이 통과되기 쉽습니다. 처음부터 표준 프로세스에 포함시키려고 하지 않는 편이 성공적입니다.

Discussion