연재: AI 시대의 SE·프로그래머를 위한 AI 벽치기(AI Wall-hitting) 실전 입문

전 5회 | 제2회 / 5 이 연재는, AI를 「정답을 내는 기계」가 아니라, 「전제를 파고들고, 선택지를 늘리며, 판단을 검증하는 파트너」로 사용하기 위한 실전 시리즈입니다.

만들고 싶은 것은 있다.

하지만, 사양(Specification)으로 옮기려고 하면 손이 멈춘다.

이런 경험이 없으신가요?

개인 개발이든 업무든, 「하고 싶은 것」은 있는데 그것을 「무엇을 만들 것인가」, 「무엇을 만들지 않을 것인가」로 분해하지 못하는 상황은 많습니다. AI에게 기획서를 전달해도 그럴싸한 문장은 돌아오지만, 실제로 개발을 시작할 수 있는 수준의 사양은 되지 않습니다.

지난 기사에서는 AI 벽치기의 기본으로서 G-C-C-J-R(목적·배경·제약·판단 기준·역할)의 5요소를 소개했습니다. 이번에는 이 사고방식을 **요구사항 정의(Requirements Definition)**에 적용합니다.

• 요구사항 정의에서 AI에게 「정답」을 내게 하면 실패하는 이유
• AI에게 미확정 사항·모순·확인 질문을 내게 하는 벽치기 패턴
• 복사해서 바로 쓸 수 있는 요구사항 정의 벽치기 템플릿
• 벽치기 실례 ("개인용 AI 태스크 관리 도구"를 주제로)
• 수락 조건(Given-When-Then) 만드는 법

먼저 결론부터 말씀드립니다.

요구사항 정의 벽치기에서는 AI에게 완성판 사양서를 갑자기 만들게 하는 것보다, 다음 사항을 내게 하는 것이 가치가 더 높습니다.

즉, AI는 「사양서를 쓰는 상대」가 아니라, 「사양을 확정하기 전에 빈틈을 찾는 상대」로 사용합니다.

요구사항 정의에서 AI를 사용하려고 할 때, 다음과 같이 질문하는 경우가 있습니다.

태스크 관리 앱의 사양서를 만들어 주세요.

이렇게 질문하면 AI는 다음과 같은 「그럴싸한」 사양서를 반환합니다.

• 사용자 등록 기능
• 태스크의 CRUD
• 카테고리 분류
• 리마인더 알림
• 대시보드

언뜻 보기에는 좋아 보이지만, 다음과 같은 문제가 있습니다.

• 누구를 위한 태스크 관리 앱인지 결정되지 않음
• 어디까지 만들 것인지(MVP 또는 풀 기능)가 불명확
• 자신의 제약(기술·시간·예산)이 반영되지 않음
• AI가 멋대로 기능을 늘려 스코프(Scope)가 팽창함

그 결과, 「사양서는 만들어졌지만, 개발을 시작할 수 없는」 상태에 빠지게 됩니다.

요구사항 정의 벽치기에서는 AI의 사용법을 다음의 3가지 패턴으로 나누면 안정적입니다.

1. 아이디어 도출 패턴
아이디어 단계에서 「무엇을 결정해야 하는가」를 씻어내기 위한 패턴입니다.

다음 아이디어를 요구사항 정의로 구체화하기 위한 벽치기를 해주세요.
아이디어:
{아이디어}
...

포인트는, 「먼저 사양서를 만들지 말 것」이라고 명시하는 것입니다. 이 문장이 없으면 AI는 갑자기 기능 목록을 만들기 시작합니다.

2. 질문 유도 패턴
스스로는 깨닫지 못하는 「물어봐야 할 질문」을 AI에게 내게 하는 패턴입니다.

다음 개발 기획에 대해, 요구사항을 확정하기 위해 내가 확인해야 할 질문을 20개 내주세요.
기획 개요:
...

이 패턴은 「무엇을 물어봐야 할지 모르는」 단계에서 특히 유효합니다. AI가 낸 질문에 스스로 답해 나가는 것만으로 요구사항이 정리되어 갑니다.

3. 수락 조건 생성 패턴
요구사항이 확정되어 가는 단계에서 「완성의 판단 기준」을 만들기 위한 패턴입니다.

다음 요구사항에 대해, 수락 조건을 Given-When-Then 형식으로 만들어 주세요.
요구사항:
...

수락 조건이 있으면 개발 중에 「이것을 만들어야 하는가?」라고 망설여질 때 판단 기준이 됩니다.

다음 템플릿을 복사해서 사용해 보세요. 지난번의 G-C-C-J-R을 요구사항 정의용으로 어레인지한 것입니다.

다음 아이디어를 요구사항 정의로 구체화하기 위해 벽치기를 해주세요.
아이디어:
- {만들고 싶은 것}
...

실제로 템플릿을 사용하여 벽치기를 해보겠습니다.

다음 아이디어를 요구사항 정의로 구체화하기 위해 벽치기를 해주세요.
아이디어:
- AI 에이전트가 실행 중인 태스크를 인간이 확인·승인할 수 있는 도구
...

🤖 AI (벽치기 상대):

요구사항 정리표:

가안에 대한 지적:

• 「태스크 등록 방법」이 미정의 — API로 받는다면, 에이전트 측의 구현도 필요함
• 「놓치는 것」이 과제인데 알림 기능을 대상 외로 설정함 — 간이 알림(브라우저 알림이나 Slack 연동)은 검토해야 함
• 로그를 남길지 여부가 미정 — 승인 판단의 근거를 나중에 확인할 수 없으면 감사성(Auditability)이 약해짐

MVP 제안:

• ✅ 태스크 목록 (API를 통해 등록, 브라우저에서 표시)

• ✅ 상태 관리 (진행 중/승인 대기/완료)

• ✅ 승인 버튼 + 승인 로그 저장

• ❌ 알림, 필터, 검색, 멀티 유저는 다음 페이즈로

「대상 외」의 타당성을 다시 물을 수 있었다: 놓치는 것이 과제인데 알림을 제외했던 모순을 깨달았다 -
입력 경로의 누락: 「태스크 목록을 표시한다」는 생각했지만, 「태스크를 어떻게 등록할 것인가」가 빠져 있었다 -
성공 조건의 구체화: 「놓치지 않는다」만으로는 모호하며, 측정 가능한 기준이 필요하다는 것을 알게 되었다 -
MVP의 경계 설정: 2주 동안 무엇을 만들고 무엇을 뒤로 미룰지가 정리되었다

벽치기(Wall-hitting)로 사양서가 완성되지는 않습니다. 하지만, 사양을 확정하기 위해 확인해야 할 사항 목록을 얻을 수 있습니다.

요건이 정리되면 수락 조건(Acceptance Criteria)을 만듭니다. 수락 조건이란, "이 기능이 완성되었다"라고 판단하기 위한 기준입니다.

다음 요건에 대해, 수락 조건을 Given-When-Then 형식으로
작성해 주세요.
요건: AI 에이전트가 등록한 태스크를 목록 표시하며,
...

수락 조건:

케이스 1: 태스크 목록 표시

• Given: 에이전트가 3건의 태스크를 등록 완료한 상태에서
• When: 브라우저에서 태스크 목록 화면을 열었을 때
• Then: 3건의 태스크가 상태와 함께 표시될 것

케이스 2: 승인 조작

• Given: 상태가 "승인 대기"인 태스크가 있는 상태에서
• When: 승인 버튼을 눌렀을 때
• Then: 상태가 "완료"로 바뀌고, 승인 로그가 기록될 것

케이스 3: 등록 없음

• Given: 태스크가 0건인 상태에서
• When: 태스크 목록 화면을 열었을 때
• Then: "태스크가 없습니다"라고 표시될 것

수락 조건이 있으면 개발 중에 "이 기능은 어디까지 만들어야 하는가"가 명확해집니다. 테스트 케이스의 바탕이 되기도 하므로, 구현 전에 만들어 두면 재작업(rework)을 줄일 수 있습니다.

요건 정의 벽치기를 실무에서 사용할 때는 다음 사항에 주의하십시오.

AI의 사양 제안을 맹신하지 말 것: AI가 "이 기능이 필요합니다"라고 말하더라도, 정말 필요한지는 사용자나 이해관계자(Stakeholder)에게 확인할 필요가 있다. AI는 일반적인 패턴을 제안하지만, 개별적인 업무 사정은 알지 못한다. -
이해관계자에 대한 확인은 인간이 수행할 것: AI가 내놓은 확인 질문은 유용하지만, 그것을 누구에게 물을지, 어떻게 물을지는 인간의 몫이다. 특히 사내 시스템의 경우, 실제 사용자에게 확인하는 것이 중요하다. -
기밀 정보를 넣지 말 것: 실재하는 프로젝트명, 고객명, 사내 업무 플로우를 그대로 AI에게 전달하지 마라. 가상의 예로 바꾼 뒤에 벽치기를 수행한다. -
요건 정의는 이터레이션(Iteration): 한 번의 벽치기로 모든 것이 결정되지는 않는다. 벽치기 결과를 가지고 돌아가 검토하고, 다시 벽치기를 한다. 이 사이클을 2~3회 반복하면 요건의 정밀도가 올라간다. -

요건 정의 벽치기를 시작하기 전에, 다음을 확인해 보세요.

• 만들고 싶은 것의 아이디어를 한 문장으로 쓸 수 있는가
• 누구를 위한 것인지 썼는가
• 왜 만들고 싶은지의 배경을 썼는가
• 기술·기간·예산의 제약 사항을 썼는가
• 나름의 가안을 작성했는가 (없어도 OK)
• AI에게 "갑자기 사양서를 만들지 말고, 불명확한 점을 알려줘"라고 전달했는가
• 성공 조건을 생각했는가 (무엇을 할 수 있으면 완성인가)

요구사항 정의 (Requirements Definition) 벽치기(Wall-hitting)는 AI에게 사양서를 쓰게 하는 작업이 아닙니다. AI는 내가 놓치고 있는 불명확한 점, 모순, 확인 질문을 던져주는 상대로서 활용해야 합니다.

이번 기사에서 소개한 내용을 되돌아봅니다.

AI에게 사양서를 통째로 맡기면 실패한다 — 스코프 (Scope)가 팽창하여 개발을 시작할 수 없게 됨
3가지 유형 (과제 분해형 · 확인 질문 생성형 · 수락 조건형)으로 벽치기를 안정화함
템플릿을 사용하면 누구나 요구사항 정의 벽치기를 시작할 수 있음
**수락 조건 (Acceptance Criteria)**을 먼저 만들면 개발의 판단 기준이 생김

다음 회차에서는 요구사항이 확정된 후의 '설계' 단계에서 AI와 어떻게 벽치기를 할 것인지를 다룹니다.

다음 회차에서는 구현 전에 AI와 설계 리뷰를 하기 위한 벽치기 절차를 다룹니다.

"일단 구현하고 나중에 파탄 난다", "설계안 비교가 어렵다", "왜 그 설계로 했는지 기록이 남지 않는다"라는 고민에 대해, AI와의 벽치기로 설계안 비교 · 트레이드오프 (Trade-off) 정리 · ADR (Architecture Decision Record)화를 수행하는 방법을 소개합니다.

이 기사에서는 AI의 답변을 그대로 정답으로 취급하는 것을 권장하지 않습니다.

실무 이용 시에는 기밀 정보를 입력하지 말 것, 출력을 검증할 것, 필요에 따라 인간이 판단할 것을 전제로 합니다.

• AI와의 벽치기는 '질문'이 아니라 '사고 프로세스 설계'이다

모호한 아이디어를 요구사항으로 바꾸는 AI 벽치기 템플릿 ← 이번 회차 - 구현 전에 AI와 설계 리뷰를 하기 위한 벽치기 절차

• AI에게 통째로 맡기지 않는 코드 리뷰 · 디버깅 벽치기 기술
• AI와의 벽치기 로그를 지식화하여 포트폴리오로 만드는 법