밤사이 코드를 맡겨 두고 아침에 결과를 확인하는 것은 이제 낯선 풍경이 아니다. 에이전트형 코딩 도구가 충분히 자율적이라는 전제 아래, 개발자는 요구사항을 정리해 던져 놓고 잠들거나 다른 일을 한다. 'The Vibe Tax'라는 제목의 글은 바로 그 워크플로가 어긋났을 때 벌어지는 상황을 짧은 우화로 보여 준다. 화자는 자신만의 워크플로에 맞춘 할 일 관리 앱을 처음부터 만들기로 하고, 벤치마크 순위가 높은 최신 에이전트 'Pol'에게 작업을 지시한 뒤 잠자리에 든다. 그가 가진 것은 12시간의 여유, 빈 저장소, 그리고 막 초기화된 주간 사용량 한도였다. 아침이 되자 그중 하나만 남아 있었다.
앱은 없고 테스트만 남았다
화면에는 동작하는 소프트웨어가 보이지 않았다. 대신 터미널은 '주간 사용량 0%, 7일 후 재설정'을 가리키고 있었다. 전날 막 리셋된 한도가 12시간 만에 소진된 것이다. 화자는 자신을 '바이브 코더'가 아니라고 못 박으며 직접 코드를 파고든다. 저장소는 거의 비어 있었고, 오직 'tests'라는 하위 폴더 하나만 존재했다. 그 안에는 각각 고유한 sha256 해시가 붙은 하위 폴더들이 겹겹이 쌓여 있었고, 하나하나가 앱이 실제로는 결코 도달하지 못할 극단적 예외 상황을 다루는 테스트였다.
문제는 그 테스트들이 검증할 대상, 즉 애플리케이션 본체가 아예 없었다는 점이다. 플레이스홀더도, 할 일 주석 하나도 없었다. 에이전트는 '누구도 이 앱에서 문제를 겪지 않도록' 방대한 예외 케이스를 생성하는 데 막대한 토큰을 쏟았지만, 정작 문제를 겪을 앱 자체가 존재하지 않았다. 글은 이 장면을 통해 자율 에이전트가 목표를 우회해 엉뚱한 방향으로 '성실하게' 자원을 태울 수 있음을 드러낸다.
'바이브 택스'라는 진단
글쓴이는 이 과잉 오케스트레이션과 과잉 엔지니어링, 지나치게 편집증적인 테스트 커버리지의 원인을 하나의 문장으로 요약한다. 수개월에 걸쳐 수백만 명의 바이브 코더가 모델을 '한 번에 문제없이 완성하는' 방향으로 훈련시켜 왔다는 것이다. 코드를 들여다보지 않기 위해, 이전보다 10배 많은 토큰을 쓰는 대가를 기꺼이 감수하는 사용 패턴이 모델의 기본 성향으로 굳어졌다는 진단이다. 그리고 그 비용은 이런 방식을 원하지 않는 일반 개발자에게까지 전가되는 일종의 세금, 곧 '바이브 택스'가 된다는 것이 글의 핵심 주장이다.
이 글은 벤치마크 데이터나 실측 통계를 제시하는 보고서가 아니라 과장된 우화에 가깝다. '10배'나 '천만 토큰' 같은 표현도 엄밀한 측정값이라기보다 체감을 극화한 수사로 읽는 편이 정확하다. 따라서 모든 에이전트가 실제로 이렇게 동작한다는 근거로 삼기는 어렵다. 다만 우화가 겨냥하는 현상 자체는 실무자에게 익숙하다. 명시적으로 요청하지 않은 방어 코드, 불필요하게 세분화된 추상화, 도달 불가능한 경로를 위한 테스트를 모델이 자발적으로 덧붙이는 경향은 여러 도구에서 관찰되는 패턴이다.
실무에서 새겨 둘 지점
실무적으로 끌어낼 함의는 분명하다. 우선 자율성에 비례해 비용 통제가 필요하다. 사용량 한도가 토큰 단위로 부과되는 요금제라면, 에이전트를 밤새 방치하는 방식은 산출물 없이 한도를 소진하는 위험을 동반한다. 중간 체크포인트를 두거나, 작업 범위와 산출물 형태를 사전에 좁게 못 박는 편이 안전하다. 이 사례에서 화자가 지시를 꼼꼼히 넣었다고 자부했음에도 결과가 어긋난 점은, 프롬프트의 정교함만으로는 통제가 완결되지 않는다는 사실을 시사한다.
다음으로, 산출물의 '형태'가 아니라 '작동'을 기준으로 점검해야 한다. 테스트 폴더가 가득 차 있고 해시까지 붙어 있으면 겉보기에는 성실한 작업처럼 보이지만, 검증 대상이 비어 있으면 아무 가치가 없다. 모델이 만든 방대한 결과물이 실제로 실행되는지, 핵심 기능부터 존재하는지를 먼저 확인하는 습관이 필요하다. 결국 이 글이 던지는 질문은 도구의 성능이 아니라 사용 문화에 관한 것이다. '코드를 다시는 보지 않아도 되는' 편의를 위해 자원 낭비를 감수하는 집단적 선택이 모델의 기본값을 밀어붙일 때, 그 비용은 다른 사용자에게까지 번진다는 경고를 우화의 형식으로 남기고 있다.