코드를 쓰기 전에 취조를 받아요 — 바이브코딩이 산으로 가는 지점에 대하여

바이브코딩이라는 말이 이제 낯설지 않아요. 코드를 직접 쓰는 대신 AI에게 말로 시켜서 만드는 방식이요. 제가 저장해둔 강의 영상들을 보면 흐름이 보여요. 작년의 주제가 "이게 된다"였다면, 요즘의 주제는 "왜 자꾸 산으로 가는가"예요. 적어도 제가 보는 채널들은 한 바퀴 돌아서 숙취의 구간에 온 것 같아요.

저도 그 숙취를 겪었어요. 그리고 지금은 좀 이상한 처방으로 버티고 있어요. 코드를 쓰기 전에, AI에게 저를 취조하게 해요.

산으로 가는 배의 공통점

만들다 망한 프로젝트들을 돌아보면 공통점이 있었어요. 코드 자체가 결정타였던 적은 드물어요. 적어도 제가 만드는 규모에서 AI는 코드를 곧잘 써요. 문제는 대개 그 앞에 있었어요. 제가 뭘 원하는지 저도 확정하지 않은 채 시작했다는 것.

"대충 이런 앱 만들어줘"라고 하면 AI는 물어보지 않고 만들어요. 애매한 부분은 알아서 채워요. 그럴듯하게요. 그리고 사흘쯤 지나서 알게 돼요. AI가 채운 그 빈칸들이 제가 원하던 것과 조금씩 달랐고, 그 "조금씩"이 쌓여서 이제는 고치는 게 새로 만드는 것보다 비싼 지경이 됐다는 걸요.

사람 개발자와 일할 때는 이 지점에서 질문이 날아와요. "로그인은 뭘로 해요?", "이 데이터는 지워져도 돼요?" 귀찮은 질문들이 사실은 안전장치였던 거예요. AI도 시키면 질문을 해요. 다만 기본값이 순종이라, 그냥 두면 묻는 대신 만들어요. 시키면 시키는 대로요. 그게 편해서 쓰기 시작했는데, 그게 함정이 될 줄은 몰랐어요.

순종을 끄는 스위치

그래서 절차를 하나 만들었어요. 새로 뭔가를 만들기 전에, AI에게 역할을 바꿔 달라고 해요. 시공자가 아니라 취조자가 되어 달라고요. 규칙은 이래요. 방향을 가르는 결정이 열려 있는 한, 코드를 쓰지 말고 나에게 한 번에 하나씩 물어라. 하나씩인 이유는 소박해요. 질문 열 개를 한꺼번에 받으면 저는 성의 없이 답하게 되더라고요. 물론 만들다 보면 새 결정이 또 나와요. 그때는 추측하지 말고 다시 물어 달라고 해두면 돼요.

그러면 질문이 시작돼요. 사용자가 한 명이에요, 여러 명이에요. 데이터가 날아가면 얼마나 곤란해요. 이 기능과 저 기능이 충돌하면 뭐가 이겨요. 대답하다 보면 제가 얼마나 많은 걸 "대충 알아서"에 맡기려 했는지 드러나요. 어떤 질문에는 답이 막혀요. 그 막히는 지점이 바로, 사흘 뒤에 배를 산으로 보냈을 지점이에요. 코드 한 줄 쓰기 전에 그걸 미리 만나는 거예요.

취조가 끝나면 결정들이 문서 한 장으로 남아요. 그 문서를 받고서야 시공이 시작돼요. 시간이 더 드는 것 같지만, 제 경험으로는 반대였어요. 취조에 쓴 30분이 재작업으로 날렸을 며칠을 줄여줬어요.

말로 시키는 시대의 역설

바이브코딩 시대에 사람의 역할이 뭐냐는 질문을 많이 받는 것 같아요. 저의 잠정 답은 이래요. 코딩이 사라진 자리에 남는 건 결정이에요. 뭘 만들지, 뭘 포기할지, 뭐가 틀렸을 때 더 아픈지. AI는 이 결정을 대신하지 않아요. 대신, 결정하지 않았다는 티를 내지 않고 만들어주는 경우가 많아요. 그게 더 무서운 거고요.

말로 시키는 게 쉬워질수록, 말하기 전에 정해야 할 것들의 값이 올라가요. 저는 그 정하는 시간을 확보하려고 취조를 받아요. 만드는 건 AI가 하니까, 저는 취조당할 준비를 하고 갑니다.