바이브 코딩, 진짜 문제는 두 달 뒤에 옵니다

안녕하세요, 리키입니다. 오늘은 우리가 요즘 많이 이야기하는 '바이브 코딩'이라는 것이 실제로는 어떤 문제들을 안고 있는지, 그리고 그 뒤에 숨겨진 진짜 문제는 무엇인지에 대해 이야기해 보려고 합니다.

요즘은 커서(Cursor)나 클로드 코드(Claude Code) 같은 도구를 사용해서 원하는 것을 말로 설명하면 코드가 뚝딱 만들어지는 경험을 하게 되더군요. 그 속도와 생산성은 정말 좋지만, 우리가 크게 이야기하지 않는 부분이 있습니다. 바로 프로토타입 단계를 넘어 실제 사용자가 들어오기 시작할 때, 코드베이스가 커졌을 때 발생하는 문제들입니다. 마치 보이지 않게 쌓인 빚이 어느 날 갑자기 한꺼번에 청구되는 느낌이랄까요.

이런 문제들이 생기는 이유는 시스템이 커지는 속도를 우리가 이해하고 관리하는 속도가 따라가지 못하기 때문입니다. 에이전트가 코드를 생성할 때는 학습 데이터와 프롬프트에 있는 컨텍스트만 가지고 움직이기 때문에, 실제 운영 환경에서 발생하는 보안 요구사항이나 확장성 문제, 아니면 CI/CD 과정에서의 테스트 부족 같은 중요한 맥락을 놓치기 쉽습니다. 에이전트는 가장 흔한 패턴을 따라가기 때문에, 실제 돈이 오가는 프로덕션 시스템에서는 충분하지 않다는 것이죠.

특히 바이브 코딩에서 이 문제가 심각한 이유는, 에이전트가 '돌아가는 코드'를 작성할 뿐 '왜 그렇게 작성했는지'에 대한 이해를 자동으로 쌓지 못하기 때문입니다. 코딩 속도는 폭주하지만, 그 결정의 이유를 기록하고 이해하는 일은 거의 일어나지 않습니다. 이 때문에 작성과 이해 사이의 간격이 벌어지고, 어느 순간 시스템이 부러질 때까지 문제가 쌓이게 되는 것입니다.

그렇다면 이 문제를 해결하기 위해 엔터프라이즈 프로세스처럼 무거운 해법을 찾을 필요는 없습니다. 오히려 더 가볍고 정확한 세 가지 접근이 필요합니다. 첫째는 '문서화'입니다. 에이전트가 컨텍스트로 읽을 수 있는 구조화된 문서, 즉 결정의 이유를 담은 ADR(Architecture Decision Record) 같은 것이 필요합니다. 둘째는 '엔지니어링 기본기'입니다. 테스트, 보안 검토, 그리고 사용자가 알기 전에 내가 먼저 알 수 있게 해주는 옵저버빌리티 같은 기본기를 갖춰야 합니다. 셋째는 '경계가 있는 에이전트'입니다. 에이전트가 어디까지 움직일 수 있는지 명확한 가드레일을 설정해야 합니다.

결국 AI 기반 개발에서 중요한 것은 도구의 속도를 따라가는 것이 아니라, 그 속도 안에서 시스템을 관리하는 주변 관행을 갖추는 것이더군요. 오늘 당장 가장 레버리지 높은 한 가지는 에이전트 인스트럭션 파일입니다. 이 파일에 한 시간을 투자하면 앞으로 모든 AI 세션의 행동을 바꿀 수 있습니다. 여러분도 이 점을 기억하시고, 시스템의 안정성을 함께 고민해 보셨으면 좋겠습니다.

---

---

참고 원문: https://brunch.co.kr/@abrahamsong/168