
AI 빌더가 가장 먼저 배워야 할 것은 기능이 아니라 질문입니다. 추론 엔진을 만들기 전에 "이게 검색이랑 뭐가 달라?"를 먼저 물어야 했던 이유를 정리했습니다.
처음 AI에게 던진 질문은 이거였다.
"수마트라 어때? 로 시작해서 샌다칸에서 14박 일정을 만든 그 과정을 로직화해서 추론 엔진으로 만들고 싶어."
잘못된 질문이었다. 당시엔 몰랐다.
AI는 충실하게 답했다. 구조를 제안하고, 기능을 나열하고, 화면을 그려줬다.
그런데 개발이 진행될수록 이상했다.
코드는 쌓이는데 "이게 뭔 제품이야?"라는 질문에 답이 안 됐다.
나중에서야 알았다.
내가 물어본 건 어떻게 만드는가였고, 아직 무엇을 만드는가가 없었다.
전환점은 질문을 바꾼 순간이었다.
"지금 이 제품이 rule-based 시스템이랑 다른 게 뭘까?"
이걸 물었더니 AI의 대답이 달라졌다.
Rule-based는 A→B 경로가 고정되어 있다.
여행 앱으로 치면 "필터 걸면 목적지 나옴" 구조다.
그런데 내가 만들려던 건 달랐다.
사용자가 "수마트라 어때?"라고 말하는 순간, 그 말 안에는 '덥고 싶다'는 욕망도 있고, '사람 없는 곳'이라는 회피도 있고, 말하지 않은 컨텍스트도 있다.
그걸 분해해서 추론하는 게 목적이었다.
Rule-based는 입력을 걸러낸다.
내가 원한 건 입력을 해석하는 것이었다.
이 차이 하나가 제품 정의를 바꿨다.
검색이 아니라 발견이다.
Search는 알고 있는 걸 찾는 것, Discovery는 몰랐던 걸 발견하는 것. 이 한 줄이 포지셔닝을 확정했다.
그리고 이 한 줄이 나오는 데 꽤 많은 시간이 걸렸다.
왜 이렇게 됐을까. 돌아보면 이유가 명확하다.
AI는 질문에 최적화된 답을 준다.
"이거 만들어줘"를 물으면 만드는 방법을 준다.
"이게 X랑 뭐가 달라?"를 물으면 차별점을 준다.
"이게 진짜 그 역할을 하나?"를 물으면 검증을 해준다.
기획자·PM 입장에서 생각해보면, 이건 익숙한 실수다.
요구사항 정의서를 쓰기 전에 솔루션을 먼저 정해버리는 것.
"우리 앱에 이 기능 넣자"가 "우리 사용자한테 이 문제가 있다"보다 먼저 나오는 것.
AI와 작업할 때도 똑같이 반복된다.
오히려 AI가 빠르게 구체화해주니까 더 빨리 틀린 방향으로 달려간다.
제품 정의가 잡히고 나서야 UI 결정도 자연스럽게 따라왔다.
"경로가 화면에 보여야 한다. 지나치지 않은 길도 남아있어야 한다."
Rule-based 필터 UI라면 결과만 보여주면 된다.
그런데 추론 과정을 보여주는 제품이라면, 소거된 선택지도 화면에 남아있어야 한다.
사용자가 "왜 이 목적지가 나왔는가"를 따라갈 수 있어야 한다.
이건 UX 결정인 동시에 아키텍처 결정이었다.
그리고 카드 구조가 나왔다.
이렇게 읽었어요 ← 사용자 말에서 want/avoid/경험 태그 추출
핵심은 이거예요 ← 교집합을 한 문장으로
그래서 이렇게 물어봤어요 ← LLM에 실제로 던진 쿼리
발견 ← 결과
개발자 언어로 하면 청킹, 주성분 추출, 구조화 쿼리, 추론 결과다.
제품 안에서는 구어체로 쓴다. 같은 개념인데 청중에 따라 언어가 달라야 한다.
이것도 포지셔닝의 일부다.
정리하면 이렇다.
AI에게 기능을 물어보기 전에, 이 두 질문을 먼저 해야 한다.
- 첫째, 이게 X랑 뭐가 달라? — 포지셔닝이 없는 상태에서 기능을 나열하면 경쟁 제품을 다시 만들게 된다.
- 둘째, 누가, 언제, 어떤 상태에서 쓰는가? — 제품의 정의는 기능이 아니라 이 질문에서 나온다.
수마트라로 시작한 대화가 샌다칸으로 끝난 건 우연이 아니었다.
그 과정 자체가 이 제품이 보여주려는 것이다.
그리고 그 과정을 제품으로 만들기 위해, 먼저 올바른 질문을 찾는 데 가장 많은 시간을 썼다.
다음 편: AI에게 맡겼더니 AI가 폭주했다 — 코드는 완성됐는데 목적이 사라진 이야기
그리고 이 시리즈의 결과물이 궁금하신 분은 직접 체험해 보실 수 있습니다.
글에서 다룬 추론 엔진, 탐색의 기술에서 실제로 작동하고 있습니다.
2026.04.21 - [AI 빌더] - 작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오
작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오
AI 도입이 작동하지 않는 이유는 구조의 문제입니다. AX 컨설턴트 gtpmore 포트폴리오 — 지식 구조화(RAG), 판단 기준 알고리즘, 자율 추론 엔진 3가지 축으로 실제 업무에 작동하는 AX를 설계합니다.
gtpmore.tistory.com
'AI 빌더' 카테고리의 다른 글
| [추론 엔진 #3] 바이브 코딩의 한계 | Reasoning Engine을 만들다 막힌 날 (0) | 2026.04.24 |
|---|---|
| [추론 엔진 #2] AI에게 맡겼더니 AI가 폭주했다 | 추론 엔진 개발자의 실패 기록 (0) | 2026.04.23 |
| [사색의 기술 — AI 빌더 실전기] 추론 엔진을 만들면서 배운 것들 (0) | 2026.04.22 |
| 작동하는 AX를 설계합니다 — AX Studio 포트폴리오 (0) | 2026.04.21 |
| [AI 빌더 실전 #7]페르소나별 제언(2) - 비개발자 빌더 (0) | 2026.04.18 |