기획 에이전트 설계하며 만난 5 Whys
요즘 코딩 씬에서 Claude Code가 꽤 화제입니다.
이미 다양한 코딩 에이전트들이 나와 있지만, 그중에서도 프로젝트 전체 코드 베이스를 맥락으로 이해한 상태에서 작업을 수행하는 능력이 다른 툴보다 더 좋다는 이야기가 자주 보이는 것 같습니다.
이걸 보면서 문득 이런 생각이 들었습니다.
“우리 팀에서는 기획서를 전부 마크다운 파일로 관리하고 있는데, 이걸 하나의 지식 베이스로 삼아서 기획팀에서도 기획 에이전트를 만들 수 있지 않을까?”
사실 이번에 처음 든 생각은 아니었고, 이전에 제 글 서비스 기획 자동화에 꽂힌 이유에서도 소개했었는데요. 그땐 계획에만 그치고 실제 작업으로 이어지지 않았었던 터라, 이번에 Claude Code를 활용하여 다시 한번 시도해 보게 되었습니다.
평소 문제 정의, UI/UX 설계, 기능 명세서 작성까지 기획자가 반복적으로 하는 일이 있습니다. 이 과정들에서 수행하는 작업들을 구조화해서 AI에게 맡기면 부분적으로 자동화할 수 있지 않을까 하는 생각이 들었습니다.
그래서 기획 워크플로우를 그대로 쪼개서 각 단계를 담당하는 서브 에이전트를 만들어보자는 방향으로 접근해 봤습니다. 대략적으로 보면 문제 정의를 담당하는 에이전트 → UI/UX 설계를 돕는 에이전트 → 기능 명세서를 정리해 주는 에이전트 이런 흐름으로 서브 에이전트가 각 단계를 수행하고 그 산출물을 기반으로 다시 다음 서브 에이전트의 입력값으로 활용할 수 있는 구조로 설계해 보았습니다.
그중에서도 기획의 가장 첫 출발점인 문제 정의 서브 에이전트를 설계했는데요. 막상 시스템 프롬프트를 쓰기 시작하니 생각보다 쉽지 않았습니다. 이 단계가 흐트러지면 이후 설계나 명세 단계도 자연스럽게 흔들리기 때문에 더욱 신경 쓰였던 것도 있고, “문제를 깊이 이해하라”, “사용자 니즈를 파악하라” 같은 문장은 너무 추상적이었기 때문입니다.
무엇보다 실제 우리가 현업에서 마주하는 문제들은 기능 요청 하나만 놓고 봐도, 그 뒤에는 업무 방식, 조직 구조, 커뮤니케이션 방식 같은 맥락이 얽혀 있는 경우도 있어서 추상적으로 질문하면 엉뚱한 결과가 나오거나, 현실과 동떨어진 허황된 응답이 나올 때도 있었습니다.
이걸 에이전트에게 어떻게 시킬 수 있을지 고민하다가 알게 된 게 바로 5 Whys였습니다.
5 Whys는 방식 자체는 단순합니다. 어떤 문제에 대해 “왜?”라고 묻고, 그 답변에 다시 “왜?”를 5번 반복하는 방식입니다. 중요한 건 질문의 횟수보다는 질문을 반복하면서 문제가 단순한 현상 설명이 아니라 구조적인 이유로 내려가는 지점을 찾는다는 점입니다.
이 방식이 문제 정의 서브 에이전트의 사고 구조로 꽤 잘 어울릴 것 같다는 생각이 들었습니다.
그래서 사용자의 요구 사항이 들어오면 5 Whys를 통해 문제를 한 단계씩 파고들 수 있도록 시스템 프롬프트를 구성했고, 그 결과가 실제로 어떤지 확인하기 위해 사례 하나를 적용해 봤습니다.
결과는 아래와 같았습니다.
User Input :
개발 PM인데요. 로드맵 공유하기 버튼 클릭하면 링크가 복사되는데, 링크가 아니라 이미지로 공유하는 기능을 넣어주세요. 링크로 하면 실무자들이 클릭하고 들어오지도 않고 안 봐요.
AI Response:
사용자 요구: "링크 복사 말고, 로드맵을 이미지로 저장하는 기능을 만들어주세요."
Why 1: 왜 링크가 아니라 이미지로 공유하고 싶은가요?
(답변) 링크를 보내면 사람들이 클릭해서 들어오지 않기 때문입니다.
Why 2: 왜 사람들은 공유받은 링크를 클릭하지 않을까요?
(답변) 로그인이 귀찮기도 하고, 바쁜 와중에 새로운 웹 페이지가 뜨는 것 자체가 심리적 장벽이기 때문입니다.
Why 3: 왜 링크를 클릭해서 들어오게 만드는 것이 중요한가요?
(답변) 로드맵의 핵심 내용(일정, 진척도)을 이해관계자에게 즉시 확인시켜야 보고나 협업이 진행되기 때문입니다.
Why 4: 왜 이미지 형태가 그 대안이 될 수 있나요?
(답변) 메신저(슬랙, 카톡)나 이메일 본문에서 별도의 액션 없이 스냅샷(Snapshot) 형태로 즉시 정보를 전달할 수 있기 때문입니다.
Why 5: 왜 현재 로드맵 링크는 그 역할을 못 하고 있나요?
(답변) 현재 로드맵 기능은 '실시간 편집/열람'에는 최적화되어 있지만, 제3자에게 '특정 시점의 요약된 정보'를 휘발성으로 빠르게 전달하는 '브리핑' 기능이 결여되어 있기 때문입니다.
[분석 기반 문제 정의]
5 Whys를 통해 도출된 진짜 문제는 '이미지 파일의 부재'가 아니라 '정보 전달의 즉시성 부족'입니다.
[최종 문제 정의]
"우리 사용자는 협업 부서나 상사에게 로드맵을 공유하여 의사결정을 받고 싶어 하지만, 현재의 링크 공유 방식은 수신자의 접근 허들(로그인, 페이지 전환)이 높아 정보가 즉시 전달되지 못하고 있다. 이로 인해 PM은 보고를 위해 화면을 캡처하거나 별도의 장표를 만드는 불필요한 공수를 들이고 있다."
[솔루션 제안]
단순히 "이미지 저장 버튼"만 만드는 것을 넘어, 문제 정의를 바탕으로 더 나은 기획안을 도출할 수 있습니다.
1. 단순 개선 (Point): 로드맵 화면을 PNG/PDF로 다운로드하는 기능 추가.
2. 구조적 확장 (Expansion): 메신저(Slack/MS Teams) 공유 시, 로드맵의 주요 요약본이 이미지 미리 보기(Preview) 형태로 자동 생성되게 함.
결과를 봤을 때 들었던 생각은 이미 비슷한 방향으로 고민했던 부분도 있었고, 결과 역시 전혀 생각하지 못했던 해답이라기보다는 어느 정도 예상 가능한 수준이었습니다. 물론 케이스에 따라서 제가 전혀 생각하지 못했던 방향이 나올 수도 있겠지만요.
다만, 혼자 고민했을 때의 사고 과정을 구조화된 형태로 한 번 더 비교해 볼 수 있다는 게 꽤 의미 있었던 것 같습니다. 그리고 무엇보다 “정답”을 얻었다기보다 팀과 이야기할 수 있는 “재료”가 생긴 느낌이어서 좋았습니다.
사용자는 이런 요청을 했고, 우리가 당장 가장 쉽게 해결할 수 있는 방법은 이거고, 한편으로는 근본적인 문제는 이런 구조인 것 같은데 지금 리소스 상황에서는 어떤 방향이 가장 현실적 일지 같이 이야기해 보자는 식의 대화의 흐름을 가져가기 좋을 것 같았습니다.
그리고 개인적으로 이 과정이 더 의미 있었던 이유는 저희 팀에는 기획자가 저 혼자라서, 보통은 문제 정의부터 이후 설계 과정에서의 질문, 반박, 정리까지 전부 혼자서 하고 있는데요. 그러다 보면 생각이 특정 방향으로 고정되거나, 이 정도면 됐겠지 하고 넘어가는 순간도 생깁니다.
AI를 활용해 5 Whys를 돌려보면서, 이 결과물이 완전한 정답이라서 따라야 한다는 느낌보다는 오히려 내가 미처 생각하지 못했던 관점이나 팀에 던져보면 좋을 질문들이 생기는 게 좋았습니다. 특히 혼자 고민할 때 놓칠 수 있는 부분들을 질문 형태로 채워주는 느낌에 가까웠습니다.
지금은 기획 에이전트 설계의 첫 단계인 문제 정의 서브 에이전트만 만들었는데도, 개인적으로는 꽤 만족스러운 결과가 나온 상태입니다. 그래서 다음으로는 UI/UX 설계나 기능 명세를 돕는 다른 서브 에이전트들도 차례대로 만들어보고, 이를 하나의 흐름으로 오케스트레이션 해보려고 합니다.
일단 모든 과정을 자동화하기보다는 각 단계 중간마다 제가 직접 확인하고 필요하다면 다시 질문하는 식의 휴먼 인 더 루프 포인트를 두고, 중요한 판단만 개입해 주는 방식으로 구성해가려고 하고 있습니다. 그리고 이렇게 하나씩 구성하다 보면 정말 기획 업무의 상당 부분을 자동화해 볼 수 있지 않을까 하는 기대를 하고 있습니다.
나중에 어느 정도 형태가 잡히면, 그 결과도 다시 한번 공유해 보겠습니다. :)
