AI에게 유저 스토리보다 미결정 질문을 묻기

“사용자는 필터링된 보고서를 내보낼 수 있어야 한다.”

이 문장을 AI 어시스턴트에 붙여 넣으면, 페르소나와 수용 기준까지 포함된 사용자 스토리가 몇 초 만에 나옵니다. 완성된 것처럼 보일 겁니다.

하지만 그렇지 않습니다.

여기서 “필터링된”이란 무슨 뜻일까요? 일치하는 모든 레코드를 말하는 걸까요, 아니면 사용자가 보고 있는 페이지만 말하는 걸까요? 필터는 어느 날짜를 기준으로 하나요? 누군가 열을 숨겼다면, 다운로드에도 그 열이 여전히 포함되어야 할까요?

이건 어떤 글쓰기 문제도 아닙니다. 제품 결정의 문제이고, 누군가는 그것을 내려야 합니다. 그러니 AI에게 요구사항 작성을 시키기 전에, 아직 아무도 내리지 않은 결정을 찾아보라고 하세요. 그 단계에서 필요한 것은 팀에게 던질 질문 목록입니다.

자신감 있는 빈칸의 문제

AI는 모호한 요청을 구체적인 문장으로 바꾸는 데 능숙합니다. 그게 문제입니다. 구체적이라고 해서 검증되었다는 뜻은 아니니까요.

예를 들어 운영팀이 주간 보고서를 요청했다고 합시다. 메모에는 CSV 다운로드, 날짜 필터, 그리고 승인된 레코드로만 접근을 제한한다는 내용이 확인되어 있습니다. 중복에 대한 언급은 없습니다. 그런데 초안에는 “중복 레코드를 제거한다”는 문장이 들어갑니다. 그럴듯해 보이니 누구도 의심하지 않습니다.

하지만 그 한 줄은 비즈니스 규칙을 새로 만들어낸 것입니다. 두 레코드가 중복이라는 기준은 무엇일까요? 겉보기에는 같은 두 행이 실제로는 서로 다른 두 사건일 수도 있지 않을까요? 이런 모호함은 나중에 개발이나 테스트 단계에서 다시 드러나고, 그때는 정리하는 데 더 많은 비용이 듭니다.

저는 이런 것들을 자신감 있는 빈칸이라고 생각합니다. 팀이 미처 살펴보지 않은 구멍을 모델이 조용히 메워 버렸기 때문에, 결과물은 확실해 보이지만 사실은 그렇지 않은 지점들입니다.

초안 대신 세 묶음을 요청하세요

해결은 무엇을 요청하느냐에서 시작됩니다. 어시스턴트에게 사용자의 작업, 원하는 결과, 이미 확인한 규칙, 그리고 원본 메모를 주십시오. 그런 다음 모든 내용을 세 묶음으로 분류하라고 하세요:

확인됨: 검증된 정보입니다. 추정을 “확인됨”이라고 표시할 수도 있으니, 확인된 항목마다 출처 문장을 인용하라고 요청하세요.

가정됨: 누군가는 그렇게 생각하지만 아무도 확인하지 않은 내용입니다.

미확인: 메모 어디에도 관련된 내용이 없습니다.

내보내기 예시라면, 간단한 결정 기록은 다음과 같을 수 있습니다. 아래 항목들은 예시이며, “확인됨”은 제공된 메모로 뒷받침된다는 뜻입니다.

가장 유용한 부분은 각 문장이 어디에서 왔는지 볼 수 있다는 점입니다. AI의 제안은 적절한 맥락을 가진 사람이 확인하기 전까지는 가정일 뿐입니다. 그 대화가 끝나면 합의된 규칙과 그 출처를 기록에 업데이트하세요.

그리고 빈칸을 메우지 말라고 지시하세요. AI가 제안하는 모든 내용은 적절한 이해관계자가 동의하기 전까지는 제안일 뿐입니다. 그 한 가지 지시만으로도 출력이 완전히 달라집니다. “여기 당신의 스토리가 있습니다”에서 “아직 확인해야 할 것이 이것입니다”로 바뀝니다.

모든 빈칸이 회의를 열 만한 가치는 없습니다

열려 있는 질문이 40개나 되는 목록은, 숨겨진 가정이 40개나 있는 스토리만큼이나 별 도움이 되지 않습니다. 지금 무엇이 중요한지에 대한 판단은 여전히 필요합니다.

예를 들어 “고객은 반품을 취소할 수 있다”라고 작성된 리테일 반품 기능을 생각해 봅시다. 택배기사가 이미 소포를 수거한 뒤에도 취소할 수 있을까요? 이미 진행 중인 환불은 어떻게 될까요? 이런 답은 고객 경험, 물류, 결제 전반에 걸쳐 영향을 미칩니다. 누구도 확인 메시지를 다듬기 훨씬 전에 정리되어야 합니다.

간단한 테스트가 도움이 됩니다. 모든 빈칸에 대해 다음 세 질문을 던지세요:

1. 답에 따라 범위가 달라질 수 있는가?
2. 누가 무엇을 할 수 있는지가 달라질 수 있는가?
3. 데이터나 결과의 실제 의미가 달라질 수 있는가?

하나라도 “예”라면 그 빈칸의 우선순위를 올리세요. 어시스턴트에게 각 미해결 질문이 무엇을 바꿀 수 있는지 풀어 쓰게 한 다음, 팀과 함께 목록을 검토하세요. 논의는 여전히 중요합니다. AI가 해야 할 일은 그 논의를 형성하는 것입니다.

내보내기 요청이 조용히 예약 보고서, 알림, 새로운 대시보드로까지 커져서는 안 됩니다. 있으면 좋은 기능도 별도의 묶음으로 두세요.

정제 작업에 더 나은 질문을 가져오세요

이미 정제 작업이나 Three Amigos, 또는 Example Mapping을 사용하고 있다면, 이 접근법은 그 작업 안에 자연스럽게 들어갈 수 있습니다. 정제 작업은 팀이 스토리를 명확히 할 수 있는 공간을 제공합니다. Three Amigos는 비즈니스, 개발, 테스트 관점을 대화에 가져옵니다. Example Mapping은 규칙, 구체적인 예시, 답이 없는 질문을 통해 그 논의를 구조화합니다.

AI 리뷰는 그런 대화를 준비하는 데 도움이 될 수 있습니다. AI가 제안한 공백을 정련 과정에 가져오고, 어떤 항목이 중요한지 그룹에 물은 뒤, 예시를 사용해 답변을 검증해 보세요. 내보내기 이야기의 경우, 누군가 “일치하는 레코드가 20,000개이고 화면에는 50개만 보인다면, 파일에는 무엇이 들어가야 하나요?”라고 물으면 “모든 일치하는 레코드”는 훨씬 더 구체적이 됩니다. 그 자리에 있는 사람들은 여전히 동작 방식에 대해 합의해야 합니다.

다가오는 요구사항 하나에 먼저 적용해 보세요. 어떤 질문이 유용했는지, 어떤 질문이 잡음이었는지, 그리고 검토에 얼마나 시간이 걸렸는지 기록하세요. 팀이 중요한 결정을 더 일찍 발견했나요? 논의가 더 명확한 예시와 더 적은 가정으로 끝났나요?

바로 그 지점에서 저는 가치를 찾겠습니다. 누군가 구현을 시작하기 전에 팀이 이야기를 더 잘 이해하게 되는지 여부입니다.

스토리는 마지막에 작성하기

이해관계자들이 중요한 질문에 답한 뒤에는, 합의된 내용을 적어 두세요: 규칙, 소유자, 그 출처, 그리고 아직 열려 있는 것. 그제야 AI에게 승인 기준 초안을 작성하라고 요청하고, 그 기록을 바탕으로 초안을 작성하게 하세요.

예를 들어, 보고 팀이 내보내기에 모든 일치하는 승인된 레코드가 포함되고 사용자가 선택한 열만 포함된다고 확인했다고 합시다. 그러면 기준은 설명할 실제 대상을 갖게 됩니다. 날짜 경계와 접근 규칙은 여전히 별도의 정의가 필요하며, 잘 작성된 시나리오로도 그것을 대신할 수는 없습니다.

그 작은 결정 기록은 종종 스토리 자체보다 더 큰 가치가 됩니다. 요구사항이 몇 달 뒤 바뀌더라도, 팀은 문장을 추측하는 대신 그 결정을 다시 검토할 수 있습니다.

시작할 때 사용할 수 있는 프롬프트는 다음과 같습니다:

제공된 증거만 사용하여 이 메모를 검토하세요. 확정된 요구사항, 가정, 미확인 사항을 구분하세요. 누락된 각 결정을 위해 그 결과를 설명하고 관련 이해관계자에게 물어볼 질문을 제안하세요. 선택적 개선 사항은 별도로 유지하세요. 비즈니스 규칙을 지어내거나 최종 승인 기준을 작성하지 마세요.

결정이 확정되면:

이 확정된 결정들을 바탕으로 승인 기준 초안을 작성하세요. 각 기준을 그 배경이 된 결정과 연결하고, 해결되지 않은 종속성도 나열하세요.

조직에서 승인한 AI 환경에서 이를 실행하고, 공개가 허용된 내용만 공유하세요. 결과물, 질문, 초안 모두에 대한 책임은 여전히 분석가에게 있습니다.

면책 조항: 이 글에 표현된 진술과 의견은 저자들의 것이며, 반드시 Thoughtworks의 입장을 반영하는 것은 아닙니다.

출처

• 원문: https://www.thoughtworks.com/insights/blog/generative-ai/dont-ask-ai-to-write-the-user-story-yet (2026-10-22 · Himanshu Sharma)