[추론 엔진 #3] 바이브 코딩의 한계 | Reasoning Engine을 만들다 막힌 날

AI 빌더가 추론 엔진을 설계하는 과정을 시각화

개념만 갖고 복잡한 프로젝트를 시작하면 안 됩니다. 시나리오 → 시뮬레이션 → 코딩, 이 순서는 AI 시대에도 바뀌지 않습니다. 바이브 코딩이 무너지는 정확한 지점을 기록했습니다.

---

처음엔 그게 맞는 방법처럼 보였다.

AI와 대화하면서 아이디어를 정리하고, 정리된 내용을 바로 코드로 넘긴다.

기획서를 따로 쓸 필요가 없었다. Gemini가 구조를 잡아주고, Claude Code가 구현했다.

빠르게 진행됐다. 뭔가 만들어지는 느낌이 있었다.

 

그 느낌이 문제였다.

---

 

복잡한 프로젝트에서 바이브 코딩이 안 되는 이유는 간단하다.

 

AI는 매 요청마다 빈칸을 채운다.

설계가 없으면 AI의 해석으로 채워진다.

 

처음엔 티가 안 난다. 기능이 하나씩 붙으면서 코드가 쌓인다.

그런데 어느 시점에서 전체를 보면, AI가 채워 넣은 해석들이 서로 다른 방향을 가리키고 있다.

각 요청에는 최적화됐지만, 전체 목적에는 과적합된 상태다.

 

추론 엔진을 만들고 있었는데, 어느 순간 물류 최적화 도구가 되어 있었다.

코드는 완성됐다. 목적이 사라져 있었다.

---

진단은 명확했다. 순서가 틀렸다.

 

소프트웨어 개발에는 오래된 순서가 있다.

요구사항 → 설계 → 구현. AI가 등장하면서 이 순서를 건너뛸 수 있다는 착각이 생겼다.

 

단순한 기능 하나를 만들 때는 맞다.

그런데 단계 간 상태가 연결되고, 여러 API가 엮이고, 분기가 생기는 구조에서는 코드로 가기 전에 반드시 시뮬레이션이 있어야 한다.

 

"이 입력이 들어오면 어떤 경로로 흘러가는가"를 한 번 풀어내야 한다.

그게 없으면 AI는 방향을 모른다.

 

시나리오 → 시뮬레이션 → 코딩. 이 순서는 AI 시대에도 바뀌지 않는다.

---

C-2를 시작할 때는 코드보다 CLAUDE.md가 먼저였다.

IA, 추론 플로우 6단계, 카드 레이어 구조, 비즈니스 로직, 제약 조건이 전부 이 문서에 들어있다.

 

Claude Code는 이걸 보고 코딩을 시작한다.

그리고 제약 조건에는 이렇게 명시되어 있다.

순차 처리만 — Promise.all 등 병렬처리 금지

하루 최대 20회 (Redis 카운터)

 

C-1에서 실제로 벌어진 일이다.

병렬 처리 코드 하나가 무료 티어 일일 한도를 테스트 한 번에 날렸다.

C-2에서는 그 실패가 문서에 먼저 박혀있다.

 

AI는 이 제약을 어길 수 없지만 감시는 계속해야 한다.

CLAUDE.md는 설계서이면서 C-1의 반성문이다.

---

AI와 일하는 방식이 바뀐 게 아니라 순서로 돌아온 것이다.

오히려 AI가 빠르게 움직이기 때문에 이 순서를 더 엄격하게 지켜야 한다.

설계 없이 빠르게 달리면 틀린 방향으로 빠르게 달리는 것뿐이다.

 

C-1의 코드는 73단계까지 쌓였다. 동작했다. 그리고 버렸다.

---

다음 편: 피벗 — 완성된 코드를 버리기로 결정한 날

---

그리고 이 시리즈의 결과물이 궁금하신 분은 직접 체험해 보실 수 있습니다.

글에서 다룬 추론 엔진, 탐색의 기술에서 실제로 작동하고 있습니다.

2026.04.21 - [AI 빌더] - 작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오

작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오