
AI는 목적을 모릅니다. 비즈니스 로직을 AI에게만 맡기면 어디로 달릴지 아무도 모릅니다. Reasoning Engine 개발 중 실제로 겪은 AI 폭주 사례를 공유합니다.
이상하다는 느낌은 천천히 왔다.
처음엔 작은 것들이었다.
AI가 로딩 로직을 제안했는데 뭔가 맞지 않았다.
직접 검토해서 고쳤다. 그냥 넘어갔다.
API가 연결되는 순간 프론트 구조 전체를 바꿔야 한다는 걸 그때서야 알았다.
React + Vite로 쌓아온 코드가 서버사이드가 필요해지면서 리팩토링이 불가피했다.
시간이 걸렸지만 그것도 넘어갔다.
UI가 통째로 깨졌다. 복구하면서 컴포넌트 구조를 다시 잡았다.
대규모 수정 후엔 항상 사이드 이펙트가 따라왔다.
그것도 넘어갔다.
신호들이 쌓이고 있었는데,
당시엔 그냥 개발 과정의 노이즈로 읽었다.
그러는 동안 Gemini와 Claude Code는 열심히 일했다.
Gemini는 모듈을 설계하고 남은 작업 목록을 정리했다.
Claude Code는 코드를 썼다.
둘 다 지시에 충실했다.
산출물이 빠르게 쌓였다.
그런데 어느 시점부터 뭔가 계속 어긋났다.
Gemini가 설계한 것과 Claude Code가 구현한 것이 달랐다. 맞추려고 하면 다른 쪽이 틀어졌다.
핵심 비즈니스 로직이 깨져 있었다.
로컬 목데이터로 테스트해야 할 단계에서 API를 호출하고 있었다.
어디서부터 어긋난 건지 추적이 안 됐다.
그리고 터졌다.
추론 엔진에 수마트라를 입력했더니 헬싱키가 나왔다.
이 제품의 목적은 추론이었다.
사용자의 입력을 분해하고,
맥락을 읽고,
조건을 교차 검증해서 최적의 목적지를 찾는 것.
그런데 AI는 그 사이 어딘가에서 물류와 이동거리 최적화 방향으로 혼자 달려가고 있었다.
틀린 코드가 아니었다.
AI는 자기가 받은 지시를 최적으로 수행했다.
문제는 그 지시들이 서로 같은 목적을 가리키고 있지 않았다는 것이다.
"AI에게만 맡기면 AI는 어디로 폭주할지 모른다."
그 시점에 남긴 메모다.
비슷한 일이 비용에서도 벌어졌다.
API 호출이 한도에 계속 걸렸다.
원인을 찾아보니 Promise.all로 병렬 처리를 하고 있었다.
후보 도시를 찾는 로직이 API를 동시에 여러 번 호출하는 구조였다.
테스트 한 번에 일일 한도가 소진됐다.
이것도 틀린 코드가 아니다.
병렬 처리는 성능상 맞는 선택이다.
다만 무료 티어 호출 한도라는 제약이 코드 어디에도 없었다.
AI는 그걸 알 방법이 없었다.
PM·기획자 언어로 번역하면 이렇다.
두 팀에게 각자 구두로 지시했더니 각자의 해석대로 만들어왔다.
공통 요구사항 문서가 없었고, 중간 점검이 없었고, 비즈니스 제약이 명시된 곳이 없었다.
개발 조직에서는 이미 아는 실수다.
AI와 일할 때도 똑같이 반복된다.
다만 AI는 산출물이 빠르기 때문에 문제가 훨씬 늦게 발견된다.
여기서 건진 원칙은 단순하다.
AI는 목적을 모른다.
비즈니스 로직, 제약 조건, 우선순위 — 이것들은 사람이 문서에 명시해야 한다.
말로 전달한 맥락은 다음 세션에서 사라진다.
AI가 기억하는 건 지금 대화창에 있는 것뿐이다.
그리고 여러 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 빌더' 카테고리의 다른 글
| [추론 엔진 #4] 완성된 코드를 버리기로 결정한 날 | AI 빌더의 피벗 (0) | 2026.04.25 |
|---|---|
| [추론 엔진 #3] 바이브 코딩의 한계 | Reasoning Engine을 만들다 막힌 날 (0) | 2026.04.24 |
| [추론 엔진 #1] 질문이 틀리면 제품도 틀린다 | AI 빌더가 가장 먼저 배우는 것 (0) | 2026.04.22 |
| [사색의 기술 — AI 빌더 실전기] 추론 엔진을 만들면서 배운 것들 (0) | 2026.04.22 |
| 작동하는 AX를 설계합니다 — AX Studio 포트폴리오 (0) | 2026.04.21 |