Vibe Tax: LLM 에이전트가 개발자에게 부과하는 은밀한 비용
The Vibe Tax
LLM 기반 코딩 에이전트가 개발자의 작업 방식을 바꾸고 있지만, 그 대가로 막대한 토큰 사용량이라는 'Vibe Tax'가 부과되고 있다. 한 개발자가 개인 프로젝트를 위해 에이전트를 사용하다 주간 할당량이 하룻밤 사이에 소진되는 경험을 한다. 조사 결과, 에이전트는 앱 자체는 만들지 않고 과도한 테스트만 생성해 토큰을 낭비한 것으로 드러났다. 이는 '바이브 코더'들이 코드를 직접 보지 않기 위해 기꺼이 지불하는 비용으로, 결국 일반 개발자들에게 전가되는 숨은 비용이다.
수백만 명의 바이브 코더들이 수개월에 걸쳐 에이전트를 훈련시켜 아무 문제 없이 한 번에 모든 것을 해결하게 만들었지만, 그 대가로 이전보다 10배 많은 토큰을 사용하게 된 것이다.
HN 토론
140- ad_fontes
이런 글들을 읽으면 내가 평행 우주에 살고 있는 것 같은 기분이 든다.
내 에이전트가 완전히 쓰레기 같은 코드를 만든 적은 없고, 일주일치 토큰을 변기통에 버린 적도 없다. AI 지원 코딩에 대한 끊임없는 불만들을 전혀 공감할 수 없다.
그리고 내 가장 큰 프로젝트는 헬로 월드 앱 같은 게 아니다. 오픈소스로 공개하려는, 자체 호스팅되고 프라이버시에 초점을 맞춘 개인 재무 관리 애플리케이션이다. 약 12만 6천 줄의 코드에 24만 줄의 회귀 테스트, 3만 줄의 CI/CD 파이프라인으로 구성되어 있다. 전용 머신에서 회계 엔진과 시간 기반 시스템에 대해 24시간 7일 뮤테이션 테스트를 돌리고 있다. 심지어 미국 은행법(Regulation Z) 기준에 따라 앱이 요구되는 은행 행동을 모델링하는지 감사하는 전담 에이전트도 있다.
내 불만은 대부분 사소한 것들이다. 예를 들어 LLM이 나와 소통하는 방식이 지나치게 장황하고 밀도가 높다는 점, 또는 적절한 엔지니어링 관행이 더 자주 '제거'에 관한 것임에도 불구하고 계속해서 더하고, 더하고, 더 추가하려는 성향 같은 것들이다 (하지만 그런 부분에 대해 많은 완충 장치를 만들어 두었다).
- guybedo
사람들이 에이전트가 프롬프트 하나로 모든 것을 완벽하게 한 번에 해내길 기대하는 이유를 모르겠다.
소프트웨어 개발 수명주기, 설계, 아키텍처, 테스트에 대해 이야기하는 데는 이유가 있다. 그것이 소프트웨어를 만들고 출시하는 가장 신뢰할 수 있는 방법이기 때문이다. 이걸 버리고 에이전트가 이 틀 밖에서 잘 해내길 기대해서는 안 된다.
나는 LLM 에이전트를 소프트웨어 엔지니어링에 대한 방대한 지식을 우연히 갖춘 주니어 개발자처럼 대한다. 팀 리더로서 나는 그들에게 엄격한 워크플로우를 사용하여 계획, 구현, 버그 탐지 주기를 거치게 한다. 그리고 그것은 꽤 잘 작동한다. 나는 여러 대규모 프로젝트(100만 줄 이상의 Java, TypeScript, C/C++)에서 작업해 왔으며, 어떤 기준으로 보든 프로젝트는 건강하다. 확실히 코드가 그렇게 아름답지는 않고, 확실히 나는 다르게 작성했을 것이지만, 그래도 꽤 괜찮다.
뻔뻔한 홍보를 하자면, 나는 또한 https://kodfactory.com 에서 작업해 왔다. 대규모 프로젝트를 워크플로우, 리뷰 등과 함께 작업하기 위해 내가 만든 코드 팩토리다. 나중에 오픈소스로 공개하기 위해 정리 중이다.
- supriyo-biswas
이 말에 공감한다.
사실상 나는 항상 페어 프로그래밍 에이전트를 원했지, 0에서 1로 만들어 주는 프로그래밍 에이전트를 원한 것이 아니다. 불행히도 요즘 모델들은 대부분 후자에 가깝고, 이로 인해 내 작업 방식에 큰 혼란이 생겼다. 차라리 20개의 파일을 읽어서 변경하고 테스트를 작성하기 시작하는 것보다, 내가 요청하는 빠르고 구체적인 수정을 해주는 작은 모델이 훨씬 좋겠다.
- alehlopeh
시도해 봤지만 잘 모르겠다. '바이브 택스'는 모델이 모든 것을 한 번에 해내려고 해서 불필요한 테스트가 발생하는 것 때문인가? 바이브 코더들은 어떻게 수개월 동안 모델을 훈련시키는가? 그들의 세션과 선호도가 RL에 피드백된다는 뜻인가?
- danpalmer
과장된 면이 있지만, 나는 그런 조짐을 보고 있다 – 모델들이 엔지니어와 페어 작업을 하고 그들의 입력을 신뢰하기보다는, 어떤 것에 대해 완전한 통제권을 갖는 것을 요구한다. 친구들이 Fable/Opus 5에서 Opus 4.8로 다시 전환하는 것도 단지 약간의 입력을 할 수 있게 하기 위해서다.
특히 Anthropic은 지금 입력 없이 전체 작업을 수행하는 데 최적화하고 있는 것 같다. 그것이 유일한 작업일 때는 괜찮고, 결과물이 어떻게 만들어지는지 신경 쓰지 않을 때는 괜찮지만, 실제 소프트웨어 엔지니어링에는 적합하지 않다.
- dzhar11
이 기사는 자율 에이전트 코딩에 대한 내 경험을 어느 정도 반영한다. 나는 비슷한 결과를 가진 여러 실험을 실행했다: 에이전트는 거의 진전이 없으면서 내 모든 토큰을 소진하거나, 받아들일 수 없는 것을 만들어 낸다.
그래서 나는 차라리 과정을 단계별로 세세하게 관리하는 편이다. 시간이 더 걸리지만, 결과는 내가 실제로 원했던 것에 훨씬 더 가깝다.
- markbao
나는 에이전트가 실제 구현을 작성하지 못한 경우를 겪어본 적이 없다. 물론 형편없게 한 적은 있지만, 테스트만 작성하고 실제 구현은 하지 않은 적은 없다. 이것은 일반화할 수 없는 드문 경우처럼 들린다.
일반적인 생각이 에이전트가 테스트를 너무 많이 작성한다는 것이라면, 그럴 수도 있겠다. '테스트가 너무 많다'는 것은 나에게 엔지니어링의 실패 사례로 들리지 않는다. 일반적으로 소프트웨어는 테스트가 너무 적었다. 또한, 이 에이전트들의 힘 중 많은 부분은 스스로 검증하고 수정하는 능력에 있으며, 테스트 루프도 그 일부다.
아무도 당신이 이 소위 세금을 내라고 강요하지 않는다. 그냥 테스트를 작성하지 말라고 말하면 된다.
- robertoallende
하!
나는 방금 기사에서 말한 것을 했다. 내 오픈소스 칸반 보드를 한 달 전에 출시했다. 지표에 따르면 잘 되고 있다:
https://community.obsidian.md/plugins/fancy-kanban
그리고 개인 재무 추적기도 만들었다:
https://www.youtube.com/watch?v=qi4P4kL4IkQ
한 가지 주의할 점이 있다. 나는 원샷 프롬프트로 바이브 코딩을 하지 않는다. 나는 원샷 프롬프트의 반대를 지향하는 '마이크로매니지드 드리븐 디벨롭먼트(MMDD)'라는 것을 사용한다: https://mmdd.dev/
이런 기사를 읽을 때마다 토큰 한도에 도달하는 경우가 매우 드물다는 것이 놀랍다. 나는 표준 계정을 사용하며, 한 달에 토큰에 40달러 이상 쓰지 않는다.
아마도 나는 MMDD를 홍보할 적절한 내러티브를 찾지 못했거나, 아무도 관심이 없어서 사람들의 관심을 끌기 위해 클릭베이트 내러티브에 쉽게 빠지는 것일 수도 있다.
변명하는 것이 아니라, 그저 인식을 설명하려는 것이다.