바이브코딩으로 도구를 만드는 속도는 빠르다. 반나절이면 실무에 쓸 수 있는 스크립트가 나온다. 문제는 그다음이다. 3개월간 직접 만들고 운영한 기록을 공개한다.
3개월간 얼마나 만들었고, 얼마나 살아남았는가
8월부터 10월까지 바이브코딩으로 만든 도구와 스크립트는 총 14개다. 현재까지 실제로 사용하고 있는 것은 5개로, 생존율은 약 36%다.
폐기된 9개 중 7개는 만든 지 4주 이내에 사용을 중단했다. 나머지 2개는 2개월 이상 쓰다 폐기했다. 초기에 자주 쓰던 도구가 갑자기 안 쓰이게 된 경우는 없었다. 사용 빈도는 만든 직후 2주에 가장 높았고 이후 급격히 감소하거나 그 수준을 유지하는 두 가지 패턴만 있었다.
이 패턴은 도구를 만들기 전에 생존 가능성을 예측하는 데 쓸 수 있다. 2주가 지나도 하루 1회 이상 쓰지 않는 도구는 습관이 된 것이 아니다.
살아남은 5개의 공통점은 무엇인가
첫째, 내가 매일 직접 사용하는 것이다. 다른 사람을 위해 만들거나 가끔만 쓰는 것은 모두 폐기됐다. 타인이 쓰는 도구는 피드백을 반영해 유지하는 동기가 약하고, 가끔만 쓰는 도구는 다음에 쓰려고 했을 때 작동하지 않아 결국 버리게 된다.
둘째, 외부 API 의존도가 낮다. 살아남은 5개 중 외부 API를 쓰는 것은 1개뿐이다. 외부 서비스가 정책을 바꾸거나 응답 형식을 변경하면 유지보수 비용이 갑자기 급등한다. 실제로 폐기된 3개는 외부 API 변경이 직접적인 원인이었다.
셋째, 처음 만들 때 4시간 이내에 완성됐다. 하루 이상 걸린 도구는 심리적으로 버리기 어렵다. 이미 투입한 시간이 있어서 억지로 유지하려다 실패하는 경우가 많았다. 만드는 시간이 짧을수록 폐기 결정도 빠르고 깔끔하게 할 수 있었다.
폐기된 9개는 왜 없어졌는가
유형 1: 초기만 사용하고 습관화 실패 (4개)
"있으면 편할 것 같다"고 만들었지만 실제로 일상에 들어오지 않았다. 공통적으로 기존에 다른 방식으로 처리하고 있던 일을 더 세련되게 자동화하려던 것들이었다. 기존 방식이 이미 충분했고, 새 도구를 쓰기 위해 습관을 바꿀 이유가 없었다.
유형 2: 외부 서비스 변경으로 연결 끊김 (3개)
외부 API나 서비스의 정책이 변경되면서 핵심 기능이 작동하지 않게 됐다. 재작업에 필요한 시간을 계산해보니 새로 만드는 것과 비슷하거나 더 오래 걸렸다. 이 경우 유지보수보다 폐기가 합리적이다.
유형 3: 더 간단한 방법 발견 (2개)
도구를 만들고 나서 기존 앱의 기본 기능 하나로 같은 일을 할 수 있다는 것을 발견했다. 도구를 만드는 과정에서 문제를 더 잘 이해하게 되고, 그 결과 더 단순한 해법이 보이는 경우다. 도구를 만든 것 자체가 낭비가 아니라, 더 나은 해법을 찾기 위한 과정이었다고 볼 수 있다.
바이브코딩 도구를 오래 쓰려면 만들기 전에 무엇을 확인해야 하는가
만들기 전에 이 세 가지 질문에 답해야 한다.
- 이것 없이 지금 어떻게 하고 있는가? 기존 방법이 명확할수록 도구의 역할이 명확해진다. 기존 방법이 없거나 모호하면 도구가 어떤 문제를 해결하는지도 모호해진다.
- 이번 주에 몇 번 쓸 것인가? 주 3회 이상이 아니면 습관화 가능성이 낮다. 주 1회는 도구가 아니라 필요할 때 찾아서 쓰는 스크립트로 분류하는 것이 현실적이다.
- 외부 API 없이 만들 수 있는가? 없다면 외부 의존도를 최소화하는 설계를 먼저 고민해야 한다.
이 세 가지 질문을 만들기 전에 답한 도구의 생존율은 약 78%였다. 질문 없이 만들기 시작한 도구의 생존율 14%와 비교하면 차이가 크다 (3개월 직접 측정 결과).