AI 에이전트가 쓸모없는 출력을 내놓나요? 문제는 당신이 토큰을 아끼느라 과감히 사용하지 못하는 데 있습니다.
저자: Systematic Long Short
번역 및 편집: TechFlow
TechFlow 서두: 이 글의 핵심 주장은 단 한 문장으로 요약됩니다. “AI 에이전트의 출력 품질은 당신이 투입하는 토큰 수에 비례한다.”
저자는 추상적인 이론을 막연히 논하지 않고, 오늘 당장 적용할 수 있는 두 가지 구체적인 방법을 제시하며, 동시에 ‘토큰을 아무리 많이 쓰더라도 해결할 수 없는 영역’—즉 ‘신선성 문제(novelty problem)’—를 명확히 경계합니다.
코드 작성이나 워크플로우 실행을 위해 현재 에이전트를 사용 중인 독자라면, 이 글은 정보 밀도와 실용성 측면에서 매우 높은 가치를 지닙니다.
서론
글 제목이 눈길을 확 사로잡는 건 사실입니다. 하지만 진심으로 말씀드리지만, 이건 결코 농담이 아닙니다.
2023년, 우리가 여전히 LLM을 활용해 실제 프로덕션 코드를 생성하고 있을 때, 주변 사람들은 모두 놀라 입을 다물지 못했습니다. 당시 일반적인 인식은 LLM이 쓸모없는 쓰레기 같은 결과물만 산출한다는 것이었기 때문입니다. 그러나 우리는 다른 사람들이 깨닫지 못했던 하나의 사실을 알고 있었습니다. 바로 ‘에이전트의 출력 품질은 투입된 토큰 수의 함수’라는 점이었습니다. 그게 전부입니다.
직접 몇 차례 실험을 해보면 금방 알 수 있습니다. 예를 들어, 제약 조건이 있는 볼록 최적화 알고리즘을 처음부터 직접 구현하는 등, 비교적 복잡하고 생소한 프로그래밍 과제를 에이전트에게 맡겨 보세요. 먼저 최소 사고 수준(thinking budget)으로 실행해 보고, 다음엔 최고 사고 수준으로 전환하여 스스로 작성한 코드를 리뷰하게 하여, 얼마나 많은 버그를 발견할 수 있는지 확인하세요. 중간 수준과 고수준도 각각 시도해 보십시오. 그러면 직관적으로 알 수 있습니다. 버그 수가 투입된 토큰 수에 따라 단조 감소한다는 것을 말입니다.
이해하기 어렵지 않죠?
토큰 수가 많을수록 오류는 줄어듭니다. 이 논리를 조금 더 나아가면, 거의 대부분의 코드 리뷰 제품들이 뒷받침하는 (단순화된) 핵심 아이디어가 바로 이것입니다. 전혀 새로운 맥락을 도입해 엄청난 양의 토큰을 투입하되(예: 코드를 한 줄씩 분석하며 각 줄에 버그가 있는지 판단), 이 방식을 통해 대부분, 혹은 심지어 모든 버그를 찾아낼 수 있습니다. 이 과정을 열 번, 백 번 반복할 수도 있습니다. 매번 ‘다른 관점’에서 코드베이스를 검토함으로써, 결국 모든 버그를 발굴해 낼 수 있습니다.
“토큰을 더 소비하면 에이전트 품질이 향상된다”는 주장에는 실증적 근거도 있습니다. 즉, 에이전트를 전 과정에 걸쳐 사용해 코드를 바로 프로덕션에 올리는 것을 성공적으로 실현했다고 주장하는 팀들은, 대개 기초 모델 공급사 자체이거나 자금력이 매우 풍부한 기업들입니다.
따라서, 아직도 에이전트가 프로덕션 수준의 코드를 만들어내지 못해 고민하고 계신다면, 솔직히 말씀드리겠습니다. 문제는 바로 ‘당신’에게 있습니다. 혹은 더 정확히 말하자면, ‘당신의 지갑’에 있습니다.
내가 소비한 토큰이 충분한지 어떻게 판단할까?
저는 이전에 한 편의 장문 기사를 통해, 문제의 원인이 절대 당신이 설계한 프레임워크(harness)에 있지 않다고 강조한 바 있습니다. “단순함을 유지하라”는 원칙만 지켜도 훌륭한 결과물을 만들 수 있으며, 지금도 이 견해를 굳게 지키고 있습니다. 그 글을 읽고 실제로 따라 해보셨지만, 여전히 에이전트의 출력에 실망하셨고, 저에게 DM을 보내셨습니다. 제가 읽음 표시는 했지만 답장을 드리지 않았다는 것도 아실 겁니다.
이 글이 바로 그 DM에 대한 답장입니다.
당신의 에이전트가 부진한 성능을 보이고 문제를 해결하지 못하는 이유는 대부분, 투입한 토큰 수가 부족하기 때문입니다.
한 문제를 해결하기 위해 필요한 토큰 수는 완전히 그 문제의 규모, 복잡도, 그리고 신선성(novelty)에 달려 있습니다.
“2+2는 얼마인가?”라는 질문에는 별다른 토큰이 필요하지 않습니다.
반면, “Polymarket과 Kalshi 간 모든 시장에 대해 스캔하여 의미상 유사하고 동일한 사건의 전후로 정산되어야 할 시장을 찾아내고, 무차익 경계를 설정한 후, 차익 기회가 발생하면 저지연 방식으로 자동 거래를 실행하는 봇을 만들어 달라”는 요청은 엄청난 양의 토큰을 소비해야 합니다.
실무 경험을 통해 흥미로운 사실 하나를 발견했습니다.
규모와 복잡도 때문에 야기되는 문제에 대해 충분히 많은 토큰을 투입한다면, 에이전트는 어떤 경우에도 반드시 해결할 수 있습니다. 다시 말해, 극도로 복잡하고 구성 요소와 코드 라인이 많은 것을 구축하려 한다면, 해당 문제에 충분한 토큰을 투입하면 결국 완전히 해결할 수 있습니다.
단, 하나의 작지만 중요한 예외가 있습니다.
당신의 문제가 지나치게 ‘신선한’ 경우는 안 됩니다. 현재 단계에서는, 아무리 많은 토큰을 투입해도 ‘신선성 문제’는 해결할 수 없습니다. 충분한 토큰은 복잡성에서 비롯된 오류를 제로로 낮출 수 있지만, 에이전트가 자신이 전혀 모르는 것을 ‘공중에서 창조해 내는’ 일은 불가능합니다.
이 결론은 오히려 우리에게 안도감을 줍니다.
저희는 기관 투자 프로세스를 거의 아무런 가이드 없이 에이전트가 재현해낼 수 있는지 실험하기 위해 막대한 노력과—매우, 매우, 매우 많은—토큰을 소비했습니다. 이 실험의 일부 목적은, 우리(양적 연구원으로서)가 AI에 의해 완전히 대체되기까지 얼마나 남았는지를 파악하는 데 있었습니다. 그런데 결과는, 에이전트가 제대로 된 기관 투자 프로세스에 근접조차 하지 못한다는 것이었습니다. 이는 아마도 에이전트가 그런 프로세스를 한 번도 본 적이 없기 때문이며, 즉 기관 투자 프로세스는 훈련 데이터 내에 아예 존재하지 않기 때문이라고 판단했습니다.
따라서, 만약 당신의 문제가 ‘신선한’ 것이라면, 단순히 토큰을 더 쌓는 것으로 해결되리라고 기대하지 마십시오. 당신이 직접 탐색 과정을 이끌어야 합니다. 그러나 일단 구현 방안을 확정짓고 나면, 코드베이스가 아무리 크고 구성 요소가 아무리 복잡하더라도, 마음 놓고 토큰을 추가 투입해 실행에 옮길 수 있습니다.
여기에 간단한 경험칙(heuristic)이 하나 있습니다. 토큰 예산은 코드 라인 수에 비례하여 증가시켜야 합니다.
추가로 소비된 토큰은 정확히 무엇을 하는가?
실무에서, 추가 토큰은 일반적으로 다음과 같은 방식으로 에이전트의 공학적 품질을 향상시킵니다:
동일한 시도 내에서 더 오랜 시간 동안 추론하도록 허용함으로써, 스스로 오류 있는 논리를 발견할 기회를 제공합니다. 추론이 깊어질수록 계획도 향상되고, 일회성으로 성공할 확률도 높아집니다.
다양한 해법 경로를 따르는 여러 차례의 독립적인 시도를 허용합니다. 어떤 경로는 다른 경로보다 더 우수합니다. 여러 차례 시도를 허용함으로써, 최적의 경로를 선택할 수 있습니다.
유사하게, 더 많은 독립적인 계획 시도를 통해 약한 방향은 포기하고 가장 희망 있는 방향만 유지할 수 있습니다.
더 많은 토큰은 에이전트가 이전 작업을 완전히 새로운 맥락에서 비판적으로 검토하고 개선 기회를 얻도록 허용합니다. 이는 특정 ‘추론 관성(inertia)’에 갇혀서 벗어나지 못하는 상황을 피하게 합니다.
물론, 제가 가장 좋아하는 점도 있습니다. 더 많은 토큰은 테스트와 도구를 활용해 자신의 작업을 검증할 수 있게 합니다. 코드를 실제로 실행해 보고 제대로 작동하는지 확인하는 것은, 정답의 정확성을 확인하는 가장 신뢰할 수 있는 방법입니다.
이 논리가 통하는 이유는, 에이전트의 공학적 실패가 무작위적이지 않기 때문입니다. 거의 항상 초기에 잘못된 경로를 너무 일찍 선택하거나, 그 경로가 실제로 유효한지 여부를 초기 단계에서 확인하지 못했기 때문이며, 또는 오류를 발견한 후 복구 및 되감기를 수행할 만큼 충분한 예산이 없었기 때문입니다.
결국 이야기는 이렇게 흘러갑니다. 토큰은 문자 그대로 당신이 ‘구매한 결정의 질’입니다. 이를 연구 업무에 비유해 보겠습니다. 누군가에게 어려운 문제를 즉석에서 풀라고 하면, 시간 압박이 커질수록 그 답변의 질은 떨어질 것입니다.
연구란 결국 ‘정답을 아는 상태’를 만들어내는 활동입니다. 인간은 생물학적인 시간을 들여 더 나은 답변을 만들어내고, 에이전트는 더 많은 계산 시간(토큰)을 들여 더 나은 답변을 만들어냅니다.
당신의 에이전트를 어떻게 향상시킬 수 있는가?
아마 여전히 반신반의하실 수 있지만, 이 주장을 뒷받침하는 수많은 논문이 존재합니다. 솔직히 말해, ‘추론 조절 노브(thinking knob)’라는 개념 자체가 바로 당신에게 필요한 전부인 증거입니다.
제가 특히 좋아하는 한 논문에서는, 연구자들이 소량의 정교하게 구성된 추론 샘플을 이용해 모델을 훈련시킨 후, 모델이 멈추려는 순간에 강제로 계속 생각하도록 유도했습니다. 구체적으로는, 모델이 멈추려는 지점에 ‘Wait(잠깐)’이라는 단어를 덧붙이는 방식이었습니다. 이 단순한 조치 하나만으로도, 특정 벤치마크 점수가 50%에서 57%로 상승했습니다.
말씀드리고 싶은 건, 단순히 ‘에이전트가 쓴 코드가 형편없다’고 불평하시는 분들이라면, 단일 시도에서 가능한 최고 사고 수준조차도 여전히 부족할 가능성이 매우 높다는 점입니다.
그렇다면, 아래 두 가지 매우 간단한 해결책을 드리겠습니다.
간단한 방법 1: WAIT(잠깐)
오늘 당장 시작할 수 있는 가장 쉬운 일: 자동 반복 루프를 구축하세요. 코드를 작성한 후, 에이전트가 완전히 새로운 맥락에서 N회 리뷰하고, 매번 문제를 발견하면 수정하도록 합니다.
이 단순한 기법이 당신의 에이전트 공학 성능을 개선시킨다면, 적어도 당신의 문제는 단순히 ‘토큰 수 부족’이라는 사실을 이미 이해한 것입니다. 그렇다면 이제 ‘토큰 소비 클럽’에 가입하세요.
간단한 방법 2: VERIFY(검증)
에이전트가 자신의 작업을 가능한 한 빠르고 자주 검증하도록 유도하세요. 선택한 경로가 실제로 작동함을 입증하기 위해 테스트를 작성하세요. 이는 특히 고도로 복잡하고 깊이 중첩된 프로젝트에 매우 유용합니다. 하나의 함수가 하위에 있는 수많은 다른 함수들에 의해 호출될 수 있기 때문입니다. 상위 단계에서 오류를 잡아내는 것만으로도, 이후에 소모될 막대한 계산 시간(토큰)을 절약할 수 있습니다. 따라서 가능하다면 전체 구축 과정 곳곳에 ‘검증 체크포인트’를 배치하세요.
어떤 부분을 작성한 후 메인 에이전트가 “완료!”라고 선언하더라도, 별도의 검증 전용 에이전트가 다시 한번 검토하도록 하세요. 서로 관련 없는 사고 흐름은 체계적인 편향의 근원을 보완해 줍니다.
기본적으로 여기까지입니다. 이 주제에 대해 더 쓸 수는 많지만, 위의 두 가지를 인식하고 철저히 실행에 옮긴다면, 95%의 문제를 해결할 수 있다고 확신합니다. 저는 ‘단순한 일을 극한까지 밀어붙인 후, 필요에 따라 복잡도를 점진적으로 추가하는 것’을 믿습니다.
앞서 ‘신선성(novelty)’은 토큰으로는 해결할 수 없는 문제라고 언급했습니다. 이 점을 다시 한 번 강조하고 싶습니다. 왜냐하면 당신은 언젠가 반드시 이 함정에 빠질 테고, 그때는 ‘토큰을 더 쌓아도 소용없다’며 저에게 하소연할 테니까요.
당신이 해결하려는 문제가 훈련셋에 포함되어 있지 않을 때, 진정한 해법을 제시해야 하는 사람은 바로 ‘당신’입니다. 따라서 여전히 도메인 전문 지식이 극도로 중요합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@systematicls
