
프롬프트를 세 번 고쳤습니다. AI 말을 믿고 API까지 연결했습니다. 그래도 안 됐습니다. 결국 구조를 바꿨고, 지능과 팩트를 분리하는 것이 에이전틱 워크플로우의 실체였습니다.
AI 말을 믿었다
SET1에서 이상한 일이 생겼다.
"치앙마이 대기질이 염려돼"라고 입력하면 Gemini가 검색도 하지 않고 바로 RISK 판정을 내렸다.
사용자가 걱정한다고 했으니 위험하다고 답한 것이다. 추론이 아니라 에코였다.
프롬프트를 고쳤다. 그래도 같은 문제가 났다.
다시 고쳤다. 또 안 됐다. 세 번 고쳤다. 세 번 다 안 됐다.
그때마다 AI가 다음 방법을 제안했다.
Grounding을 켜보라고 했다. 따라갔다. 안 됐다.
Custom Search API를 연결해 보라고 했다. 따라갔다. 설정이 막혔다.
다른 API를 추천받았다. 또 따라갔다.
멈췄다.
매번 AI가 제안한 방법이었고, 매번 안 됐다. 프롬프트를 고치는 게 문제가 아니었다.
구조를 바꿨다
Gemini에게 검색과 판단을 동시에 시키는 구조 자체가 문제였다.
Gemini는 검색이 필요한지 스스로 판단했고, 프롬프트로 강제할 수 없었다.
해결책은 역할을 분리하는 것이었다.
Gemini는 추론만 한다.
팩트는 검색 API가 가져온다.
중간에 검증된 데이터가 강제로 주입되는 구조. 이렇게 바꾸고 나서야 됐다.
의심이 생겼다
구조를 바꾸고 나서 한 가지 의심이 들었다.
"그냥 Gemini한테 한 번에 묻는 게 낫지 않나?"
호출이 늘었고 구조가 복잡해졌다.
단순하게 가는 게 맞지 않을까 싶었다.
그런데 따져보니 반대였다.
Gemini가 내부에서 알아서 검색하면 근거가 된 데이터는 휘발된다.
결과만 있고 팩트가 없는 시스템이 된다.
LLM을 여러 번 연쇄 호출하면 앞 단계의 오류가 다음 단계에서 증폭된다.
중간에 팩트가 강제로 주입될 때만 그 오류가 차단된다.
의심이 확신으로 바뀌었다.
분리가 맞았다.
LLM은 추론만 하고, 팩트는 검증된 API가 주입하는 구조. 이게 에이전틱 워크플로우의 실체였다.
프롬프트로 안 되면 구조를 바꿔라. LLM은 도구이지 설계자가 아니다.
이것으로 시리즈가 마무리된다.
1편에서 질문이 틀리면 제품도 틀린다고 했다.
2편에서 AI는 폭주했고,
3편에서 바이브 코딩의 한계를 봤다.
4편에서 완성된 코드를 버렸고,
5편에서 프롬프트가 엔진이라는 걸 알았다.
그리고 6편에서 구조가 답이었다.
돌아보면 전부 같은 말이다. 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 빌더' 카테고리의 다른 글
| [AI와 제대로 일하는 법 #2]AI에게 내 기준을 이식하는 5단계 | 아는 것과 쓸 수 있는 것은 다르다 (0) | 2026.05.14 |
|---|---|
| [AI와 제대로 일하는 법 #1]AI로 만들었는데 왜 내가 더 바빠질까 | 판단 기준 없이 시작한 대가 (0) | 2026.05.07 |
| [추론 엔진 #5] LLM 앱은 코드베이스가 두 개다 | 프롬프트 엔지니어링은 개발이다 (0) | 2026.04.27 |
| [추론 엔진 #4] 완성된 코드를 버리기로 결정한 날 | AI 빌더의 피벗 (0) | 2026.04.25 |
| [추론 엔진 #3] 바이브 코딩의 한계 | Reasoning Engine을 만들다 막힌 날 (0) | 2026.04.24 |