프로세스 1 — 의도 포착

이 장에서 배우는 것 한 줄짜리 요청이 어떻게 실행 가능한 명세가 되는지, 그리고 왜 되묻는 단계가 따로 있는지.

시작은 한 줄입니다

현실에서 요청은 이렇게 옵니다.

이 한 줄로는 만들 수 없습니다. 정해지지 않은 게 너무 많습니다.

되묻는 단계

PM 에이전트가 모호함을 질문으로 걷어냅니다.

마지막 질문이 이 단계의 가치입니다. 요청한 사람도 생각 못 한 지점을 만들기 전에 발견했습니다.

왜 사람이 아니라 에이전트가 묻나

사람 PM이 물어도 됩니다. 다만 차이가 있습니다.

세 번째가 실무에서 큽니다. 문답이 곧 명세라서 따로 정리할 일이 없습니다.

산출물 — 해석의 여지가 없는 명세

"범위 밖"이 있는 것에 주목하세요. 범위를 하지 말 것으로 적는 것이 여기서도 그대로 적용됩니다.

여기서 남긴 애매함은 어떻게 되나

저절로 해결되지 않습니다. 뒤 단계에서 AI가 하나를 골라 진행하고, 그 선택이 그럴듯하게 굳습니다.

graph TD
  A["명세에 안 적힌 것"] --> B["AI가 임의로 결정"]
  B --> C["코드에 반영됨"]
  C --> D["테스트도 그 기준으로 생성"]
  D --> E["전부 통과 · 아무도 이상함을 모름"]
  E --> F["나중에 발견: '이게 왜 이렇게 돼 있죠?'"]

테스트까지 그 기준으로 만들어지기 때문에 검증 단계에서도 안 걸립니다. 그래서 이 단계가 프로세스의 첫 번째인 것입니다.

실무 요령

되묻는 질문을 목록으로 가지세요

같은 유형의 작업이면 물어야 할 것도 비슷합니다.

"생각 안 해봤다"가 나오면 좋은 신호입니다

되묻기의 목적이 정확히 그것입니다. 그 답을 지금 정하는 것과 나중에 발견하는 것의 비용 차이가 큽니다.

확인

1. 이 단계에서 남긴 애매함이 왜 뒤에서 안 걸립니까?

2. PM 에이전트가 사람 PM과 다른 실무적 이점은?

3. 요청자가 "생각 안 해봤다"고 답하면 어떻게 봐야 합니까?

명세가 준비되면 여러 에이전트가 동시에 붙습니다 → 프로세스 2 — 에이전트 오케스트레이션