AI 토큰, 많이 쓸수록 더 생산적인가?…스토리 포인트의 전철을 밟는 토큰맥싱
수십 년간 소프트웨어 엔지니어링은 ‘생산성 퍼포먼스’에 시달려 왔다. 몇 년마다 업계는 새로운 허상 지표에 쏠리는데, 대개 그 시대에 유행하는 기술에 편승한 지표다. 창의성과 문제 해결을 근간으로 하는 분야에서 진보를 입증하는 방식으로는 부적절하다. 그런데도 우리는 또다시 같은 상황에 놓여 있다. 패턴은 언제나 비슷하다. 쉽게 셀 수 있는 것을 붙잡고, 그러는 사이 정작 달성해야 할 목표를 놓쳐버린다.
양보다 질 : 언제나 틀린 측정 방식
1990년대 소프트웨어 엔지니어로 성장하던 시절을 돌이켜보면, 일부 기업은 코드 한 줄 한 줄에 대해 엔지니어에게 보수를 지급하는 방식을 채택했다. 생산성 퍼포먼스 중 최악의 사례로 꼽을 만하며, 부정적 인센티브와 비효율적인 프로세스, 전반적으로 나쁜 엔지니어링으로 이어졌다. 개발자들은 문제 해결에 실제로 필요한 것보다 훨씬 많은 코드를 작성할 때 보상을 받았다. 전형적인 ‘양 우선, 질 나중’이었으며, 그 결과 유지보수가 사실상 불가능한 비대하고 취약한 코드베이스만 남았다. 신뢰할 수 있는 소프트웨어로 실제 사용자 문제를 해결한다는 목표는 생산량 인센티브에 묻혀버렸다.
2000년대에는 애자일의 부상과 함께 스토리 포인트가 등장했다. 다른 작업 대비 태스크의 복잡성, 노력, 리스크를 추상적으로 추정하는 방식이다. “이 작업을 완료하는 데 얼마나 걸리는가?”가 아니라 “이전에 해온 작업과 비교해 이 작업은 얼마나 큰가?”라는 질문에 답하기 위한 접근법이었다. 이론적으로는 그럴듯하지만, 실제로는 일부 개발팀이 추정치를 부풀리고, 생산적으로 보이기 위해 과도하게 설계하며, 자신들이 만들어내는 결과물이 실제로 가치를 창출하는지는 외면하는 방식으로 시스템을 악용하는 법을 터득했다. 다시 한번, 지표 자체가 목표가 되어버렸고, 비즈니스에 실질적인 성과를 내놓는다는 진짜 목표는 뒷전으로 밀렸다.
앞서 언급한 지표들이 모두 실패한 이유는 동일하다. 가치가 아닌 노력을 측정했기 때문이다.
AI 시대의 양 추구
오늘날 토큰맥싱이 등장했다. 개발자와 팀이 AI 모델 토큰을 최대한 많이 소비하는 방향으로 최적화하는 트렌드로, 원시적인 소비량을 곧 산출물과 동일시한다. 소프트웨어 엔지니어링 분야에 등장한 최신 허상 지표라 할 수 있다. 토큰맥싱은 ‘코드 줄 수’나 부풀린 ‘스토리 포인트’를 벤치마크로 삼는 것만큼이나 무용한 허상 지표에 불과하다.
토큰맥싱은 다음과 같은 몇 가지 행동 방식에서 비롯된다.
- 프롬프트 플러딩: 방대한 코드베이스와 문서, 맥락 정보를 모든 프롬프트에 우겨 넣는 방식으로, 모델이 실제로 필요로 하지 않는 맥락에 토큰을 낭비한다.
- 에이전트 스웜: 여러 AI 에이전트를 병렬로 실행해 코드 출력을 극대화하는 방식으로, 작업의 조율이나 일관성 여부는 고려하지 않는다.
- 백그라운드 루프: AI 세션이나 에이전트를 백그라운드에서 지속적으로 실행해 토큰 지출을 축적하는 방식으로, 무엇이 생산되고 있는지, 왜 생산되는지에 대한 명확한 책임 소재가 없다.
AI가 소프트웨어 개발 방식을 재편하고 있다는 것은 공공연한 사실이며, 앞서 언급한 행동 방식들은 그 재편의 결과이기도 하다. AI에 코드베이스를 제공하거나, 여러 에이전트를 동시에 실행하거나, 코딩 어시스턴트에 의존해 도움을 받는 것 모두 나름의 쓸모가 있다. 그러나 어떤 변경을 만들고 있는지, 왜 만들고 있는지에 대한 통제력을 잃는 순간, 오래된 문제의 새로운 버전과 마주하게 된다. 잘못된 지표로 엔지니어링 생산성을 측정하는 문제 말이다.
더 유용한 질문은 “토큰을 얼마나 썼는가?”가 아니라 “우리가 실제로 어떤 문제를 누구를 위해 해결했는가?”이다.
목표 없는 자원 소비
AI가 소프트웨어 엔지니어에게 더 적은 자원으로 더 많은 것을 해내고, 빠르게 움직이며, 기존에는 불가능했던 방식으로 실험할 수 있는 능력을 부여하고 있는 것은 사실이다. 그러나 AI를 통해 생산성을 수행하는 것처럼 보이는 데만 활용하고 실제 생산성을 내놓지 못한다면, 코드 품질과 팀 역량, 비즈니스 신뢰성 모두를 잃는 함정에 빠지게 된다.
CTO로서 AI 실험에는 전적으로 찬성한다. AI를 활용해 프로그램을 더 낫고 강력하며 미래 지향적으로 만들고 싶다. 다만 AI가 우리를 과잉 소비로 내몰면서 정작 보여줄 성과는 거의 없는 상황으로 이어지는 것은 원하지 않는다.
늘 되돌아오는 기준은 단순하다. AI가 생성한 결과물이 실제로 중요한 무언가를 출시하는 데 도움이 되는가? 사용자의 불편함을 줄이거나, 워크플로의 공백을 메우거나, 고객에게 더 높은 안정성을 가져다주는가? 이 질문에 명확히 답하지 못한다면, 인적 자원과 컴퓨팅 자원 모두를 정의된 목표 없이 소비하고 있는 것이다. 그것은 엔지니어링이 아니다. 그냥 활동에 불과하다.
스펙 중심 개발 : 가치가 정의되는 곳
이제는 스펙 중심 개발(spec-driven development)과 같은 새로운 접근법을 받아들일 때다. 엔지니어가 먼저 상세한 사양을 작성하고, AI가 그 사양에 맞춰 코드를 생성하는 방식이다. 프롬프트 플러딩과 에이전트 스웜에 의존하며 AI가 최선의 결과를 내놓기만을 기대하는 방식에서 벗어나, 요구사항을 정의하고, AI가 생성한 결과물을 검토하며, 의도를 갖고 시스템을 조율하는 방향으로 전환해야 한다.
스펙 중심 개발은 단순한 방법론을 넘어선다. 엔지니어링의 의도와 비즈니스 가치가 함께 정의되는 공간이다. 스펙은 단 한 개의 토큰도 쓰이기 전에 “왜 이것이 중요하고, 어떤 문제를 해결하는가?”라는 질문에 답하는 자리다.
소프트웨어 엔지니어들은 오랫동안 우아한 코드를 작성하는 것에 자부심을 가져왔다. AI가 그 자부심을 높이는 것이 아니라 떨어뜨리는 방향으로 작용하는 것은 바람직하지 않다. AI 우선 시대에도 장인 정신은 사라져서는 안 되며, 다만 상류로 이동해야 할 뿐이다. 이제 우아함이 살아있는 곳은 스펙이며, 스펙은 과거에 코드 자체에 쏟았던 것과 같은 수준의 세심한 주의를 받아 마땅하다.
소프트웨어 엔지니어링의 본질은 기술적 과제를 정의하고 분석하며 해결하는 것이다. 그 모든 것을 기꺼이 AI에 내맡긴다면, 우리 분야의 완결성과 가치를 입증할 능력을 잃게 된다. 최대한 많은 토큰을 소비해 코드를 생산하는 것은 인상적인 일이 아니다. 세심하게 다듬어진 의도적인 프롬프트로 특정 문제를 해결하는 것, 그것이 진정 가치 있는 작업이다.
생산성 퍼포먼스를 멈추고 실제 생산성을 찾아라
지금은 변곡점이다. 많은 기업이 활동 기반 지표를 기본값으로 삼아 AI를 얼마나 사용했는지를 측정하면서도, 그것이 납품 속도나 제품 품질, 비즈니스 성과를 개선하는지는 따지지 않는다.
가치 있는 질문은 “이번 스프린트에 AI를 얼마나 사용했는가?”가 아니다. “우리가 사용자, 팀, 비즈니스를 위해 어떤 가치를 전달했는가?”다. 치명적인 버그를 더 빠르게 해결하는 능력을 얻었는가? 고가치 기능의 사이클 타임을 단축했는가? 이전에는 몇 시간씩 걸리던 고객 워크플로가 이제 몇 분 만에 끝나는가? 그런 것들이 성과다. 그런 것들이 측정할 가치가 있는 항목이다.
AI는 의미 있는 성과를 더 빠르게 달성하는 데 도움이 될 수 있다. 단, 다른 모든 엔지니어링 및 비즈니스 결정에 요구하는 것과 동일한 엄밀함과 의도를 갖고 활용할 때만 그렇다. AI가 또 다른 형태의 생산성 퍼포먼스가 되도록 내버려 두지 말아야 한다. AI 시대에 가장 성공적인 엔지니어링 기업은 토큰을 가장 많이 소비한 곳이 아니다. 처음부터 무엇을 만들고 있는지, 왜 만들고 있는지를 결코 잊지 않은 기업일 것이다.