바이브코딩 102 - AI가 멍청한 게 아닙니다
AI가 멍청한 게 아닙니다. 님이 ‘진상 상사’라서 그래요
바이브코딩 102
AI가 멍청한 게 아닙니다. 님이 ‘진상 상사’라서 그래요
바이브코딩을 하다 보면 이상한 순간이 온다.
코드는 계속 늘어나고, 기능도 계속 붙는데,
내 손을 떠난 느낌이 점점 강해진다.
분명 어제까지는 내가 만들고 있다고 생각했는데,
어느 순간부터는 그저 옆에서 구경하고 있는 기분이 든다.
“내가 지금 뭘 만들고 있는 거지?”
이 질문이 떠오르는 순간부터,
이미 한 발 늦었다.
개발자가 코딩할 때 가장 많이 하는 일이 뭘까.
코드 작성일까.
문법일까.
프레임워크 선택일까.
아니다.
결정이다.
이 기능을 지금 넣을지, 아니면 나중으로 미룰지.
구조를 나눌지, 그냥 붙일지.
이 데이터를 지금 저장할지, 필요할 때 계산할지.
개발자는 이걸 결정하고 있다는 사실을 안다.
왜냐하면 그게 결정이라는 걸 배웠기 때문이다.
하지만 비개발자는 다르다.
바이브코딩을 시작한 비개발자는 이렇게 생각한다.
결정의 순간에 AI가 한 질문의 무게를 모른다.
이건 그냥 구현 디테일이겠지.
AI가 알아서 좋은 쪽으로 해주겠지.
나중에 고치면 되겠지.
문제는 여기 있다.
지금 내리고 있는 선택이
나중에 고칠 수 없는 결정인지조차 모른다는 것.
그 차이를 구분할 기준이 없기 때문이다.
그런 바보가 어디있냐고?
그게 나야
나는 실제로 이런 결정을 계속 내리고 있었다.
그때는 전혀 모르고 있었다.
데이터베이스를 지금 만들어야 할지 말지.
로그인 없이 기능부터 만들어도 되는지.
이 기능이 정말 MVP에 필요한지.
이 상태를 파일로 남길지, 메모리에만 둘지.
그때 내 머릿속에는 이 말밖에 없었다.
“일단 되게 만들어보자.”
그런데 시간이 지나고 나서야 깨달았다.
이 말의 진짜 의미는 이거였다.
“모든 결정을 AI에게 위임하자.”
처음에는 아무 문제 없어 보인다.
버튼이 눌리고,
화면이 뜨고,
데이터가 나오는 것 같으니까.
하지만 어느 순간부터 이상한 일이 생긴다.
하나를 고치면 세 개가 깨진다.
방문을 열었더니, 화장실 물이 내려가고
축구선수가 공을 찼더, 감독이 날아간다.
공을 막은 골키퍼가 공과 함께 폭발한다.
왜 이렇게 되어 있는지 아무도 모른다.
AI에게 물어보면 그럴듯한 설명은 한다.
그런데 누구도 확신을 가지지 못한다.
이미 코드는 12만줄이 넘어가고, 그 안에서
뭐가 어떻게 꼬여서 무엇이 일어나고 있는지는 진짜 이제 아무도 모른다.
이건 AI가 멍청해서가 아니다.
결정이 어떻게 내려졌는지,
왜 그렇게 되었는지,
그 기록이 없기 때문이다.
개발자가 종종 하는 말이 있다.
“이건 나중에 바꾸기 힘들어요.”
“이건 지금 정해야 합니다.”
“이건 구조부터 잡아야 해요.”
이 말이 괜히 나오는 게 아니다.
개발자는 알고 있다.
구현은 언제든 바꿀 수 있지만,
결정은 한 번 굳으면 구조가 된다는 걸.
문제는 바이브코딩에서는
이 구조가 생기는 순간이 전부 가려진다는 점이다.
AI가 코드를 쓰고,
파일이 생기고,
기능이 하나씩 추가되는 동안
사용자는 착각한다.
아직 설계 단계겠지.
아니다.
이미 구조는 생겼다.
이미 결정은 끝났다.
다만 아무도 그 사실을 알려주지 않았을 뿐이다.
그래서 비개발자는 항상 같은 말로 망한다.
여기 좀 고쳐줘.
이거 방향 바꿔줘.
아예 다시 만들어줘.
이 말이 반복되는 순간,
이미 결정은 너무 많이 쌓여 있다.
AI는 성실하다.
말한 대로 전부 고쳐준다.
하지만 그건
기존 결정 위에 덧칠을 하는 일일 뿐이다.
멍청한 상사 밑에서 일해본 적 있는가.
아니면 유난히 짜증나는 클라이언트를 만난 적은?
처음엔 늘 이렇게 시작한다.
“이거 여기 조금만 고쳐봅시다.”
그래서 고쳐온다.
그러면 말한다.
“아 좋네. 근데 이번엔 여기 살짝만.”
다시 고친다.
“음… 여기 말고 저기 조금.”
이게 한 번으로 끝나면 다행이다.
"아니 여기 저기 요기"
"아니아니 이번엔 여기 저기 고기 거기"
두 번, 세 번, 열 번, 스무 번.
‘아주 조금만 수정’이 계속 반복된다.
그쯤 되면
처음 만들던 건 이미 사라져 있다.
처음의 목적도 없고,
니 취향도 아니고,
내 취향도 아닌,
괴상하고 흉측한 무언가만 남는다.
그러면 그 상사가 이렇게 말한다.
“음… 맨 처음 걸로 다시 가자.
허허헛… 역시 자네야!”
이런 일이 벌어지면 뭐 그날 밤 소주 안주는 그 상사다.
왜 이런 일이 벌어질까.
'개떡 같이 말하는 상사'와 일해본 경험이 있다면 안다.
상사가 멍청해서일까.
클라이언트가 변덕스러워서일까.
아니다. (맞다!)
결정이 단계로 다뤄지지 않고,
즉흥적인 수정 요청으로만 처리됐기 때문이다.
(아니다 상사가 바보라 그렇다!)
지금 이게 방향 결정인지,
단순한 구현 수정인지,
되돌릴 수 없는 선택인지
아무도 구분하지 않았다.
그래서 모든 수정이
기존 결정 위에 계속 덧칠되었고,
결국 아무도 책임질 수 없는 결과가 나왔다.
바이브코딩에서도 똑같은 일이 벌어진다.
그래서 흔히 나오는 조언이 하나 있다.
“처음에 결정을 다 해놓고 시작하세요.”
하지만 이 말을
바이브코딩 초보에게 던지는 순간,
사람은 멈춘다.
DB는 뭘로요?
아키텍처는요?
폴더 구조는요?
에러 처리는요?
이건 조언이 아니다.
마비다.
문제는 결정을 안 해서 망한 게 아니다.
결정을 늦게 해서 망한 것도 아니다.
결정을 한 덩어리로 다루려고 했기 때문이다.
내가 GitHub에서 Spec Kit을 처음 봤을 때,
멈춰 섰던 이유도 여기에 있었다.
기능이 인상적이어서가 아니었다.
툴이 새로워서도 아니었다.
접근 방식이 완전히 달랐다.
이건 결정을 한 번에 다 하라는 게 아니구나.
결정을 잘게 씹어서 먹게 만드는 구조구나.
그 순간 이해했다.
결정의 문제는
양의 문제가 아니라
입자 크기의 문제라는 걸.
우리는 그동안 이렇게 믿어왔다.
컨텍스트를 많이 주면
AI가 더 똑똑해질 거라고.
하지만 실제로는 반대다.
AI는 집중력이 짧은 아이다.
이야기가 길어지면
중간은 흘려듣고,
마지막에 가서야 고개를 끄덕인다.
“네! 이해했습니다!”
마치 8살된 우리 아들에게 화장실 가면
변기시트 올리고, 오줌싸고, 소매 고, 비누로 손씻고 나와
라고 아무리 말해도
변기시트에는 오줌이 늘 묻어있고, 소매는 젖어 있는 이유다.
AI도 마찬가지다.
문제는 그 이해가 우리가 기대한 이해가 아니라는 점이다.
꽉찬 모차렐라를 기대했는, 속이 숭숭 뚫린 스위스 치즈 같은게 나온다는 정도의 차이다.
그래서 스펙은
완벽한 설계도가 아니다.
스펙은
AI에게 한입씩 떠먹이는 식단표에 가깝다.
지금 이 단계에서는
이 정도만 결정하고,
이 정도만 실행하게 만드는 장치.
그 이상도, 그 이하도 아니다.
문제는 내가 결정을 안 했던 게 아니다.
결정을 한 번에 다 하려고 했던 것도 아니다.
문제는
결정을 언제, 얼마나, 어떤 단위로 해야 하는지
통제하지 못했다는 것이다.
이걸 모르면
바이브코딩은 계속 같은 방식으로 망한다.
다음 글에서는
“결정을 잘하라”는 뻔한 이야기를 하지 않을 생각이다.
대신
결정을 잘게 쪼개는 방법에 대해 이야기하려 한다.
한 번에 먹는 설계가 아니라,
한입씩 먹이는 설계.
그게 내가
바이브코딩이 실패하지 않기 시작한
첫 번째 전환점이었다.
