바이브 코딩 뒤에 숨은 진짜 문제

안녕하세요, 리키입니다. 오늘은 우리가 요즘 많이 이야기하는 바이브 코딩이라는 것에 대해, 진짜 문제는 언제 오는지, 그리고 어떻게 해결해야 하는지에 대해 이야기해 보려고 합니다.

요즘 많은 분들이 커서(Cursor)나 클로드 코드(Claude Code) 같은 도구를 사용해서 원하는 것을 말로 설명하면 코드가 뚝딱 만들어지는 경험을 하시죠. 그 속도와 생산성은 정말 좋더군요. 하지만 아무도 크게 이야기하지 않는 것이 있습니다. 바로 프로토타입 단계를 넘어 실제 사용자가 들어오기 시작할 때, 코드베이스가 너무 커졌을 때 발생하는 문제 말입니다.

이때 벽이 나타납니다. 이 벽은 한 번에 무너지는 것이 아니라, 보이지 않게 쌓인 빚이 어느 날 갑자기 한꺼번에 청구되는 느낌입니다. 예를 들어, 보안 연구자가 엔드포인트 노출을 알리거나, DB가 느려지거나, 새로운 팀원이 코드를 이해하지 못하는 상황이 생기죠. 이는 시스템이 커지는 속도를 우리가 이해하는 속도가 따라가지 못한다는 증상입니다. AI 에이전트가 학습 데이터에서 가장 흔한 패턴을 따라 코드를 만들기는 하지만, 실제 돈이 오가고 보안 요구사항이 복잡하게 얽힌 프로덕션 환경에서는 그 패턴이 통하지 않는다는 것이죠.

이러한 문제의 핵심은 AI가 코드를 작성하는 속도는 매우 빠르지만, 그 코드가 왜 그렇게 만들어졌는지, 어떤 결정으로 이루어졌는지에 대한 이해는 자동으로 따라가지 못한다는 점입니다. 코딩 속도가 폭주하는 와중에, 이 모든 결정의 이유를 적어두는 일은 거의 일어나지 않습니다. 결국 작성과 이해 사이의 간격이 벌어지면서 시스템이 부러질 때까지 기다리게 되는 것이죠. 이는 도구의 실패가 아니라, 도구의 속도를 따라가지 못한 주변 관행의 문제라고 봐야 합니다.

그렇다면 우리는 무엇을 해야 할까요? 무거운 엔터프라이즈 프로세스를 따를 필요는 없습니다. 대신 가볍고 정확한 세 가지를 같이 굴려야 합니다. 첫째는 문서화입니다. 에이전트가 컨텍스트로 읽을 수 있는 구조화된 문서, 즉 결정의 이유를 담은 ADR(Architecture Decision Record) 같은 것이 필요합니다. 둘째는 엔지니어링 기본기입니다. 테스트, 보안 코드 리뷰, 그리고 사용자가 알기 전에 내가 먼저 알 수 있게 해주는 옵저버빌리티 같은 기본기를 갖춰야 합니다. 마지막으로 세 번째는 경계가 있는 에이전트입니다. 에이전트가 어디까지 손을 뻗을 수 있는지, 무엇을 보고해야 하는지에 대한 가드레일을 설정해야 합니다.

이 모든 것은 AI 네이티브 개발에서 작동하는 버전이며, 2015년식의 무거운 엔터프라이즈 플레이북보다 훨씬 가볍습니다. 오늘 당장 할 수 있는 가장 레버리지 높은 한 가지는 바로 '에이전트 인스트럭션 파일'을 작성하는 것입니다. 이 파일에 한 시간 정도 시간을 투자하면, 앞으로 진행할 모든 AI 세션의 행동이 완전히 달라질 수 있습니다. 여러분도 이 점을 꼭 기억하시고 적용해 보시길 바랍니다.

---

---

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