"AI가 짠 코드라 잘 모르겠어요!"

사내 세션을 준비하며 정리한 생각이다.

바이브코딩으로 개발하는 사람이 많아졌다. 개발자만의 얘기도 아니다. 회사에서도 개발이 아닌 다른 포지션 사람들이 바이브코딩으로 직접 기능을 만들기 시작했다.

회사가 원하는 방향과도 잘 맞는다. 사업성은 POC와 MVP로 먼저 확인한다. 일단 만들어서 보여주고, 반응을 보고, 될 것 같으면 키운다. 그래서 요구는 늘 “최대한 빨리”다. 며칠 걸리던 화면이 AI와 대화 몇 번이면 나오니 바이브코딩은 이 요구에 딱 맞는다. 그리고 MVP는 한 번 내놓고 끝나지 않는다. 반응이 있으면 그 위에 다음 기능이 계속 붙는다.

그렇게 몇 달이 지나고 문제가 생기면 이런 말이 나온다. “AI가 짠 코드라 잘 모르겠어요.” 확인하지 않고 넘어간 질문이 쌓이면 나오는 말이다.

질문은 만드는 동안 넘어간다

행사 신청 기능을 예로 들어 보자. 이름을 받고 버튼을 누르면 명단에 들어가는 기능은 금방 만들어진다. 그런데 이 기능에는 아무도 묻지 않은 질문이 붙어 있다. 정원이 차면 어떻게 막나. 같은 사람이 두 번 누르면 어떻게 되나. 사람이 몰리면 버티나.

직접 코드를 짤 때는 이런 질문이 손에 걸린다. 저장하는 줄을 쓰다가 ’두 번 오면?’이 떠오르는 식이다. 바이브코딩에서는 그 줄을 AI가 쓰고, 질문은 걸리지 않고 지나간다. 묻지 않았다고 답이 없는 건 아니다. 코드와 기본값이 이미 정했고, 만든 사람은 그 답을 모르는 채로 배포한다.

AI에게 물으면 대부분 설명해준다. 하지만 설명을 듣고 납득하는 것과 서비스에서 실제로 그렇게 동작하는 걸 확인하는 건 다른 일이다. AI가 대신해주는 건 앞쪽이고, 뒤쪽은 일정이 급할수록 건너뛰게 된다.

“된다”의 범위가 넓어진다

버튼을 눌렀더니 확정이 뜨고 명단에 한 건이 들어갔다.

행사 신청 정원 100명 · 99명 신청

이름신청

신청이 확정되었습니다.

• 사실한 번 누르면 저장 한 건, 확정 안내
• 예상여러 명이 신청해도 괜찮을 것 같다
• 모름응답이 끊겨 다시 누르면? 마지막 한 자리에 두 명이 동시에 누르면?

여기서 확인된 건 “한 사람이 한 번 신청하면 된다”까지다. 그런데 결과물이 빨리 나오면 이 말이 “신청 기능 된다”로 넓어진다. 듣는 사람은 두 번 누르는 경우, 동시에 누르는 경우까지 된다고 받아들이고, 아직 모름에 있던 질문은 그대로 넘어간다.

넘어간 질문은 쌓인다

기능 하나에서 넘어간 질문은 그 기능에서 끝나지 않는다.

바이브코딩에서는 코드가 왜 그렇게 짜였는지가 코드가 아니라 대화 속에 있다. 대화는 끝나면 묻힌다. 기능 하나일 때는 괜찮다. 다시 물어보면 된다. 그런데 MVP로 시작한 코드에 기능이 수십 개 쌓이고 나면, 어떤 결정이 어디에 걸려 있는지 아는 사람이 없다.

이때 “취소하고 다시 신청하게 해주세요”가 온다.

취소하고 다시 신청새 요구 · 프롬프트 몇 번이면 붙는다

한 사람 한 신청처음 정한 규칙 · 이유는 대화 속에

정원 계산?

통계?

확정 메일?

관리자 명단?

취소 기능 자체는 프롬프트 몇 번이면 붙는다. 그런데 정원 계산, 통계, 확정 메일, 관리자 명단 중 어디가 ’한 사람 한 신청’이라는 처음 규칙에 기대고 있었는지는 AI도 모르고 만든 사람도 모른다. 프롬프트 몇 번으로 사이드이펙트까지 처리될까? 이미 만든 기능을 처음부터 하나씩 다시 점검할 수 있을까?

확인하지 않고 넘어간 질문은 커진 코드베이스 곳곳에 그대로 남아 있다가, 요구가 바뀌거나 사용자가 몰리는 날 한꺼번에 드러난다. 그때 나오는 말이 “AI가 짠 코드라 잘 모르겠어요”다. 하지만 배포한 코드의 동작은 서비스의 동작이고, 설명도 사람이 해야 한다.

그래서 남긴다

모든 질문을 확인하면 바이브코딩을 쓰는 의미가 없다. 대신 무엇을 넘어갔는지는 남겨둔다. 방법은 세 가지 정도면 충분하다.

확인한 것과 안 한 것을 나눠 말한다. 위의 그림처럼 사실, 예상, 아직 모름을 구분한다. 이것만 해도 확인 안 한 걸 됐다고 말하는 일이 줄어든다.

지금 확인할 것을 고른다. 기준은 셋이다. 틀리면 영향이 큰가, 나중에 되돌리기 쉬운가, 만드는 사람이 정할 수 있는 일인가. 정원 초과는 핵심 약속이고 터지면 되돌리기 어려우니 지금 확인한다. 통계가 몇 초 늦게 바뀌는 건 이유를 적어두고 미룬다. 메일이 얼마나 늦어도 되는지는 운영과 같이 정한다.

결정에는 이유를 한 줄 남긴다. 대화 속에 묻히기 전에, 코드 옆이나 문서에.

취소 없는 행사 기준. 재신청 요구가 오면 정원 규칙 재검토.

처음 선택이 틀려서 남기는 게 아니다. 취소가 없던 조건에선 맞았다. 그 조건이 언제 바뀌는지 적혀 있어야 나중에 고칠 곳을 찾는다.

정리

바이브코딩으로 빨리 만드는 건 문제가 아니다. 다만 빨리 넘어간 만큼 확인한 것, 넘어간 것, 그렇게 정한 이유는 남겨두자. 기능이 쌓인 뒤에 그걸 다시 찾는 건 처음 만들 때보다 훨씬 어렵다.