9강. AI 기획서는 화면이 아니라 파이프라인입니다

🤔 Question

👉 AI 서비스 기획서를 쓰라고 하면, 대부분 가장 먼저 무엇을 떠올릴까?
화면, 버튼, 입력창, 결과 화면 같은 UI 시안이다.

하지만 AI 서비스에서 화면은 결과일 뿐이다.
실제로 서비스 품질을 결정하는 것은 화면 뒤에서 돌아가는 파이프라인다.

🤔 Question

👉 “GPT로 답변해 주세요”라는 요구사항은 왜 항상 개발자에게 욕을 먹을까?

그 문장 안에는 어디서 데이터를 가져오는지, 무엇을 기준으로 판단하는지, 틀리면 어떻게 처리하는지가 전부 빠져 있기 때문이다.

🎯 AI 기획의 본질은 ‘흐름’이다

👉 AI 기획서는 화면 설계서가 아니다.
입력 → 처리 → 판단 → 출력이 어떻게 이어지는지 설명하는 문서다.

가장 기본적인 AI 파이프라인은 아래 구조를 가진다.

 사용자 입력 ↓ 검색 (DB / Vector / 외부 API) ↓ LLM (요약, 추론, 생성) ↓ 출력 (텍스트, JSON, 화면) 

🎯 화면 중심 기획이 망하는 이유

👉 많은 PM 기획서가 이런 식이다.

 1. 사용자가 질문을 입력한다 2. AI가 답변한다 3. 결과를 화면에 보여준다 

이 문서에는 개발자가 구현할 수 있는 정보가 거의 없다.

• AI는 어디서 답을 가져오는가?
• 검색 결과가 없으면 어떻게 하는가?
• 여러 문서가 충돌하면 어떤 기준을 쓰는가?
• 틀린 답을 검증하는 단계는 있는가?

이 질문에 답하지 못하는 기획서는 결국
“일단 GPT 붙여보고 안 되면 고치죠”로 끝난다.

🎯 파이프라인 중심 기획 예시

👉 같은 기능을 파이프라인 관점에서 다시 써보자.

 [1] 사용자 질문 입력 - 텍스트 길이 제한 - 금칙어 필터링 [2] 검색 단계 - 사내 문서 Vector 검색 (Top 5) - 결과 없으면 “정보 없음” 응답 [3] LLM 처리 - 검색 결과만 근거로 답변 - 출처 문서 ID 포함 [4] 출력 단계 - 요약 답변 + 출처 표시 - 신뢰도 낮으면 경고 메시지 노출 

이 문서는 개발자에게 바로 구현 가능한 설계도다.

🎯 왜 PM은 파이프라인을 그려야 하는가

👉 AI는 기능이 아니라 확률적 시스템이다.
따라서 “잘 되게 빌기”보다 “망가질 지점 통제하기”가 훨씬 중요하다.

• 입력 단계에서 무엇을 막을 것인가
• 검색이 실패하면 어떻게 우회할 것인가
• LLM이 틀릴 가능성을 어디서 줄일 것인가
• 사람이 개입하는 지점은 어디인가

이 질문에 답하는 것이 바로 AI PM의 역할이다.

☔ 정리

👉 AI 기획서는 화면이 아니라 파이프라인다.

❌ “GPT로 답변해 주세요”
✅ “이 데이터를 검색해서, 이 기준으로 판단하고, 이 형태로 출력합시다”

이 순간부터 PM은
디자인 요청자가 아니라 시스템 설계자가 된다.

 

If I was of any help to you, please buy me coffee 😿😢😥

If you have any questions, please leave them in the comments

Buy me a coffee

▶ Youtube Sub

🧭 References

[1] reference : https://doctorson0309.tistory.com/

[2] Ads : https://apps.apple.com/us/app/beluga-classic-film-filters/id6744041061