AI를 어디까지 믿을지 설계하는 일 — 무너지는 네 곳

AI 페어 프로그래밍

바이브코딩은 어디서 무너지는가

AI를 어디까지 믿을지 설계하는 일 — 무너지는 네 곳

핵심 요약

• 바이브코딩의 진짜 기술은 코딩이 아니라 "AI를 어디까지 믿을지 정밀하게 보정하는 것"이다. 프로토타입까진 공짜지만, "동작한다"를 "믿을 수 있다"로 끌어올리는 건 다른 일이다.
• AI는 국소적 생성(한 함수·한 화면)은 믿어도 되지만, 검증 · 판단 · 기억 · 일관성에선 믿으면 안 된다 — 이 네 곳이 "믿으면 안 되는 지점의 지도"다(각각 따로 깊게 다뤘다).
• 네 곳의 뿌리는 하나 — 모델의 출력을 무조건 믿은 것. 대응도 하나 — 믿을 수 있는지를 모델 바깥에서 검증하는 구조를 두는 것.
• 그래서 사람의 일이 "코드를 쓰는 것"에서 "AI를 어디까지·어떻게 믿을지를 설계하는 것"으로 옮겨간다.

1.프로토타입까진 공짜였다

바이브코딩으로 뭔가 만들어 본 사람이면 안다 — 프로토타입까진 거의 공짜다. 의도를 말하면 코드가 나오고, 돌려보면 동작한다. 며칠 만에 쓸 만한 제품의 뼈대가 선다.

문제는 그 다음이다 — "동작한다"를 "믿을 수 있다"로 끌어올리는 구간. 진짜 사용자, 진짜 돈, 진짜 동시성이 얽히기 시작하면 빠르게 만든 코드가 조용히 무너진다. 흥미로운 건, 무너지는 자리가 매번 랜덤이 아니라는 것이다. 늘 같은 네 곳이다. 그리고 그 네 곳을 안다는 건, 결국 AI를 어디까지 믿어도 되는지를 안다는 뜻이다.

2.무너지는 건 늘 같은 네 곳

AI는 한 가지를 정말 잘한다 — 국소적 생성(한 함수, 한 컴포넌트, 한 화면에 다 보이는 패턴). 거기선 사람보다 빠르고 정확할 때도 많다. 반면 아래 네 곳에서 구조적으로 무너지고, 각각을 따로 한 편씩 깊게 다뤘다.

• 검증 — "버그를 잡는 테스트"가 아니라 "통과하는 테스트"를 짠다. → AI가 짠 테스트는 다 통과한다 — 그게 함정이다
• 판단 — 자원·과금을 설계하면 일단 막으려 든다(아키텍처와 싸우고 매출까지 거절하면서). → AI는 일단 막으려 한다
• 기억 — 세션이 끝나면 다 잊고, 어제 고친 함정을 오늘 또 밟는다. → 어제 고친 버그를 오늘 또 만드는 AI
• 일관성 — 흩어진 계약에서 7곳 중 1곳만 고치고 "완료"라 한다. → AI는 7곳 중 1곳만 고치고 "완료"라고 한다

각각을 따로 들여다볼 땐 별개의 사건처럼 보인다. 그런데 나란히 놓고 보면, 넷은 같은 결함의 네 얼굴이다.

3.공통점 — 모델을 오라클로 대했기 때문

네 실패는 표면이 다르지만 뿌리가 같다. 전부 모델의 출력을 진실로 믿어서 터진다. "테스트 통과했다"를 믿고, "이게 안전한 설계"라는 첫 제안을 믿고, "저번에 알아냈으니 이번에도 알겠지"를 믿고, "다 고쳤다"를 믿는다.

그리고 네 번의 해법도 모양이 똑같다 — 모델을 오라클로 대하길 멈추고, 모델 바깥에 검증 가능한 구조를 세우는 것. 진짜 DB로 테스트를 돌리고, 설계 원칙을 글로 박고, 함정을 파일로 외부화하고, grep으로 고아를 찾는다. 넷 다 "더 좋은 프롬프트"로 푼 게 아니다.

4.그래서 만든 것 — LLM 둘레의 "규율 레이어"

시간이 지나며 LLM 둘레에 일종의 규율 레이어가 쌓인다. 약점마다 가드레일 하나씩.

무너지는 곳	증상	세운 가드레일
검증	"완료"라는데 실제론 안 돌아감	테스트를 먼저(TDD) + 경계는 진짜로 + "완료"는 실제 실행으로
판단	일단 막으려 듦(불필요한 제한)	"보호인가, 결제 강제인가?" 원칙 + 막지 말고 가격으로
기억	어제 밟은 함정을 오늘 또 밟음	비자명한 함정을 파일로 외부화 + 모든 새 세션에 자동 주입
일관성	7곳 중 1곳만 고치고 "완료"	단일 출처(codegen)로 자리 줄이기 + 계약 체크리스트 + grep 검증

오른쪽 열의 주체는 모델이 아니다

이 표의 가드레일은 전부 모델이 아니라 사람과 저장소가 책임지는 것들이다. 모델은 여전히 똑똑하게 생성한다 — 다만 그 생성물을 진실로 승격시키는 단계에 사람이 만든 관문이 하나 생겼을 뿐이다.

5.사람의 일 = 신뢰를 보정하는 것

네 가지를 다 갖추고 나면 일의 성격이 달라진다. 더 이상 모든 라인을 키보드로 치지 않는다. 대신 —

1. 컨벤션을 글로 박는다 — 어떻게 짜야 하는지를 매번 말하지 않게.
2. 모델이 빠지는 함정을 카탈로그화한다 — 같은 실수를 두 번 보지 않게.
3. 모델의 주장을 검증하는 하네스를 만든다 — "됐습니다"를 결론이 아니라 가설로 받게.

코드를 쓰는 사람에서, AI를 어디까지 믿을지 설계하는 사람으로 옮겨가는 것이다. 어디선 전적으로 믿고 (국소적 생성), 어디선 의심하고(위 네 곳) — 그 경계를 정밀하게 긋고 구조로 강제하는 게 핵심 기술이다. 흔히 말하는 프롬프트 엔지니어링이 아니라 신뢰 보정 + 검증 하네스다.

6.정직한 트레이드오프

이게 공짜는 아니다. 솔직한 비용 셋.

• 앞단 비용이 든다 — 규칙을 쓰고, 함정을 적고, 진짜 테스트를 짜는 건 "그냥 시키는 것"보다 느리다. 빠른 프로토타입 단계엔 과하다. 규율은 믿을 수 있어야 할 때부터 값을 한다.
• 레이어 자체가 유지보수 대상 — 규칙도 학습 기록도 낡는다. 관리하지 않으면 그것대로 노이즈가 된다.
• 그래도 모델은 가끔 놀래킨다 — 규율 레이어는 사고를 줄이지 없애지 못한다. 마지막 판단은 여전히 사람 몫이고, 사실 그게 핵심이다.

그러니 이건 "AI를 못 믿는다"가 아니다. "AI를 어디까지, 어떻게 믿을지를 설계한다"에 가깝다.

7.정리

한 문장으로: 바이브코딩의 핵심 기술은 "AI를 어디까지 믿을지를 보정하는 것"이다. 국소적 생성은 믿되, 검증 · 판단 · 기억 · 일관성 네 곳에선 믿지 않고 — 모델 바깥에 검증 구조를 둬서 그 경계를 강제한다.

바이브코딩을 확장 가능하게 만드는 건 더 똑똑한 프롬프트도, 더 큰 모델도 아니다. 어디까지 믿을지를 설계하는 그 보정 능력이다.

바이브코딩 · AI와 더 잘 일하는 법