바이브코딩104 - 구현은 공짜다

AI 시대에 프로젝트가 망가지는 진짜 이유

바이브코딩104

구현은 공짜다: AI 시대에 프로젝트가 망가지는 진짜 이유

왜 AI로 코딩하는 프로젝트는 시간이 갈수록 더 복잡해질까?

코딩은 더 이상 문제가 아니다.

AI는 잘못된 코드도 금방 고친다.

심지어 왜 잘못됐는지도 설명해 준다.

문제는 그 다음이다.

기획 스펙은 분명 하나였다.

그걸 기준으로 작업을 시켰다.

그런데 일주일간의 작업이 끝나고 보니,

작업 보고서는 30개다.

어떤 건 새 문서고,

어떤 건 기존 문서를 업데이트했고,

어떤 건 새 폴더를 만들었고,

어떤 건 아예 다른 경로에 문서 폴더를 하나 더 파서

거기다 또 문서를 20개씩 쌓아둔다.

결과적으로

“무엇이 최신이고, 무엇이 진짜인가”를

사람이 다시 추적해야 한다.

이상하지 않다.

AI가 일을 못해서 생긴 문제가 아니다.

오히려 너무 성실해서 생긴 문제다.

구현은 공짜지만, 관리(Orchestration)는 비용이다.

코딩이 문제가 아니라면, 무엇이 문제인가?

AI는 구현을 실패하지 않는다.

실패는 항상 구현 이후에 시작된다.

코드는 고쳐진다.

기능도 돌아간다.

테스트도 통과한다.

그런데 프로젝트는 점점 다루기 어려워진다.

이유는 단순하다.

일이 끝났다는 개념이 시스템 안에 없기 때문이다.

사람은 일을 끝내면 자연스럽게 정리를 한다.

이건 너무나도 우리에겐 자연스러워서 가끔 시키는 걸 까먹는다.

여기서 발생하는 저 가끔이 항상 문제가 된다.

기획 스펙은 하나였는데, 왜 작업 결과는 30버전이 되는가?

사람은 이렇게 생각한다.

“이 기능을 구현했고,

이제 끝났으니까 다음으로 가자.”

하지만 AI는 다르게 행동한다.

작업이 끝날 때마다

AI는 “완료된 결과”를 자동으로 남기지 않는다.

그래서 기록을 요청하면

새로운 기록을 남긴다.

어쩌면 보고서 하나,

아니면 요약 문서 하나,

잘하면 정리본 하나,

이상한 백업처럼 보이는 문서 하나.

정확히 무엇을 어떻게 하라고 시키지 않으면 뭐가 나올지 모른다.

그게 쌓이고, 또 쌓인다.

기준은 늘 하나였는데

기록만 늘어난다. 그것도 매번 다른 버젼으로.

이 늘어난 문서에 매번 똑같이 업데이트를 시키지 않는다.

왜냐고? 지가 만들어놓고 지가 까먹거든.

AI는 왜 기록을 계속 만들어내는가?

AI에게는

기존 문서를 덮어쓰는 건 위험하다.

지우는 건 더 위험하다.

그래서 AI가 선택하는 가장 안전한 행동은 이거다.

“하나 더 만든다.”

이건 실수가 아니다.

리스크 회피 전략이다.

“다음 작업 진행해줘”라는 말이 왜 위험한가?

문제가 터지는 지점은 항상 같다.

“자, 다음 작업 진행하자.

남은 작업 리스트업 해줘.”

이 말은 사람에겐 너무 자연스럽다.

하지만 이 질문에는 전제가 하나 깔려 있다.

현재 상태를 대표하는 문서가 하나 있고

그 문서를 기준으로 판단할 수 있다

현실에는 그런 문서가 없다.

내가 직접 만들어서, 이게 기준문서야 라고 아무리 말해줘도

정말 이따금씩 한번씩 깜빡하고 다른 문서를 작성한다.

이때부터

모든 판단은 랜덤이 된다.

AI는 현재 상태를 어떻게 판단하려고 하는가?

AI는 추론한다.

여러 문서 중 하나를 고른다.

가장 최근처럼 보이는 것,

가장 상세해 보이는 것,

우연히 먼저 읽힌 것.

그리고 그 문서를 현재 상태로 간주한다.

문제는,

그 선택이 매번 다르다는 거다.

아까부터 말햇듯이 완전 랜덤박스다.

왜 이미 있는 기능을 다시 구현하게 되는가?

체크가 안 된 문서를 기준으로 보면

결론은 항상 하나다.

“아직 안 했네요.”

그래서 AI는 다시 만든다.

기존 코드가 있어도,

확신할 수 없으면 쓰지 않는다.

다시 만드는 게 더 안전하기 때문이다.

이 순간부터

같은 기능이 두 개가 된다.

같은 기능이 여러 개 생기면 어떤 문제가 발생하는가?

이건 코드 중복 문제가 아니다.

구조 문제다.

사람으로 치면 이렇다.

나 - "자 팔 두개 다 만들었지?"

AI - "네 팔이 이제 두개 입니다."

그럼 나는 이렇게 말한다.

“시계는 왼팔에 차고, 숟가락은 오른손에 쥐어줘.”

AI가 묻는다.

“어… 왼팔이 두 갠데요? 기능A-왼팔작동, 기능A-왼팔동작. 뭐가 맞는거죠?”

왼팔이 두 개 생겼다.

오른팔은 아직 없다.

이 대화,

코드베이스에서는 매일 벌어진다.

기능 이름이 제각각이면 왜 더 치명적인가?

"기능 A-왼팔"이라고 적혀 있으면

그나마 정말 감지덕지다.

현실은 이렇다.

왼팔A

왼손플랜

왼손목+@

LEFT_ARM

LEFTIE

RYU_HJ

같은 기능이다. 다 왼팔이다.

하지만 이름이 다르다.

이건 단순한 네이밍 문제가 아니다.

어쩌면 저 모든 왼팔의 기능이 다 돌아갈수도 있고,

어쩌면 저중에 일부만 기능이 연결되어 있을수도 있다.

어쩌면 저 신호가 꼬여서 제대로 작동하는척 할수도 있다.

문제는 단순한 검색으로는 저 모든걸 한번에 찾을수가 없다.

AI는 왜 중복된 기능을 지우지 않는가?

"자 이거 문제가 있으니까 고쳐보자"

열심히 AI가 다시 작업을 한다.

나중에 보면 비활성화된 왼팔이 19개

새로 만들어진 왼팔이 한개

검색되지 못해서 비활성화 되지 못한 왼팔이 6개

비활성화 되었다가, 다른 작업중에 다시 활성화 된 왼팔이 2개.

난리다.

"야! 좀 제대로 고쳐봐!"

AI는 내가 명확히 무엇을 지워!라고 하지 않고 고치라고 명령을 하면, 이렇게 생각한다.

지우는 순간 책임이 생긴다.

이게 진짜면 어떡하지?

저쪽에서 쓰고 있으면?

최신은 이쪽 아닐까?

그래서 AI는 지우지 않는다.

비활성화를 택한다.

대신 하나 더 만든다.

증식은 실수의 결과가 아니라

합리적인 선택의 누적이다.

똑똑한 자들의 실수처럼, 만일을 대비하는 모든 것이 내 현재를 망친다.

이 상태가 계속되면 프로젝트는 어떻게 변하는가?

이제 나는 왼팔에 집착한다.

왼팔 기능부터 완성시키기로 한다.

막고,

찌르고,

베고,

잡고.

시간이 지나서 보니

왼팔이 28개쯤 달려 있다.

기능은 하나씩이다.

중복도 있다.

어떤 왼팔은 찌르기로 잡고,

어떤 왼팔은 막는 자세로 인사한다.

그리고 아직 오른팔은 없다.

왼다리와 오른다리에도

왼팔이 달려 있다.

기능은 다 있다.

걷는 기능만 빼고.

이게 실제로 벌어지는 일이다.

문서가 많아지는 게 왜 진짜 문제는 아닌가?

문서 수는 본질이 아니다.

문제는 이거다.

문서 수만큼 다양한 이야기를 담고 있다는 것.

문서 수가 많지만 이것들이 동일한 상태를 여러 방면에서 비춰주고 있는거라면 최고다.

하지만 이게 몇개는 지금, 2개는 어제, 19개는 지난달, 1개는 내일을 말하고 있다면?

그리고 이 219개의 문서가 네이밍이 조금씩 다르다면?

그걸 기반으로 AI가 코딩을 했다면?

같은 기능이 서로를 모른다

시스템이 자기 자신을 이해하지 못한다

이 시점부터

바이브코딩은 자동화가 아니라 고고학이 된다.

어제의 클러드가 한일을 오늘의 GPT가 파내야한다.

제미나이가 거기에 뭍은 흙을 조심스럽게 털어내고,

비슷한 코드끼리 나열한 후, 현미경으로 하나하나 관찰해야 한다.

문서 규칙이나 네이밍 규칙으로 해결할 수 없는 이유는 무엇인가?

기준이 여러 개인 상태에서는 규칙은 항상 깨진다.

아무리 규칙을 만들어도

“어느 문서가 기준인가”가 정해지지 않으면 전부 무력하다.

그렇다면 무엇을 고정해야 하는가?

문서를 줄이는 게 아니다.

형식을 통일하는 것도 아니다.

진실의 위치를 고정해야 한다.

“이것만 보면 된다.”

이 문장이 성립해야 한다.

이런 문서가 있어야 한다. 그걸 SSOT라고 부른다.

단일 진실 공급원(Single Source of Truth, SSOT)

절대적인 진실을 담은 성서

AI가 무엇을 하든 봐야하는 하나의 문서.

이걸 만들지 못하면

당신이 만든 잠자리가 코끼리 다리가 달리고, 독수리 날개가 달린 키메라가 되는 건 순식간이다.

그럼 어떻게 해야 하는가?

결론부터 말하면 별 거 없다.

일을 시작할 때와, 일을 끝낼 때를 사람이 직접 잡아줘야 한다.

일을 시작할 때는

정확한 스펙 문서를 하나 집어서 알려줘야 한다.

“자, 다음 일은 이거다.

이 문서를 기준으로 구현 계획을 세워보자.”

AI가 뭘 해야 하는지가 아니라,

어디를 기준으로 생각해야 하는지를 먼저 고정하는 거다.

일이 끝났을 때도 마찬가지다.

정확한 구현 진행사항 문서가 어느 것인지를 알려주고,

이렇게 말해줘야 한다.

“지금 작업한 내용을 여기에 기입하고,

다음 할 일이 뭔지 체크해보자.”

문서를 새로 만들지 말고,

여기다 쓰라고 지정해 줘야 한다.

이번엔 이거,

다음엔 이거.

하나하나 차근차근,

일일이 가르쳐줘야 한다.

---

귀찮다.

엄청 귀찮다.

마치 유치원생 아들내미 따라다니면서

코 흘리면 닦아주고,

밥 먹다 흘릴까 봐 턱받이 대주고,

물티슈로 입 닦아주고,

“코 막혔네. 흥 해.

흥! 쎄게!”

이러는 것 같다.

맞다.

딱 그 수준이다.

하지만 이걸 설계하지 않으면 어떻게 되느냐?

AI는 계속 성실하게 일한다.

그리고 프로젝트는 계속 성실하게 망가진다.

문서는 늘어나고,

기능은 분열되고,

기준은 사라진다.

AI는 잘못한 게 없다.

아무도 ‘이제 여기로 돌아오라’고 말해주지 않았기 때문이다.

그래서 바이브코딩의 시작은

더 똑똑한 프롬프트가 아니다.

일의 시작과 끝을사람이 직접 지정해 주는 구조다.

여길 설계하지 않으면,

AI는 계속 성실하게 망가뜨린다.

물론, 매번 이렇게 하나하나 가르치고

문서를 지정해 주고

시작과 끝을 직접 잡아주는 건

정상적인 사람 짓은 아니다.

계속 이걸 하고 있으면

AI를 쓰는 게 아니라

유치원 담임이 된다.

---

그래서 다음 편에서는

이걸 매번 하지 않아도 되는 방법에 대해 이야기해보려고 한다.

일을 시작할 때마다

“이 문서가 기준이다”라고 말하지 않아도 되게 만드는 법

일이 끝날 때마다

“여기에 써라”라고 지정하지 않아도 되게 만드는 구조

AI가 스스로

시작할 문서와 돌아올 문서를 헷갈리지 않게 만드는 장치

즉,

사람이 매번 “흥 해!”를 외치지 않아도

알아서 흥 하는 시스템을 만드는 방법이다.

다음 편에서는

그 구조를 다룬다.