하이브리드 추론 에이전트: 잠재 사고, 텍스트 행동

LLM 에이전트에 대한 불편한 진실을 하나 말씀드리죠. 에이전트가 생성하는 토큰 대부분은 비싼 군더더기라는 겁니다. 수학 문제를 푸는 추론 에이전트는 “질문을 다시 읽어보자”, “지금까지 찾은 바로는...” 같은 문장을 실제 추론 비용을 그대로 지불하며 신나게 써 내려갑니다. 실제 연산과 수사적인 헛기침에 똑같이 컴퓨트를 쓰는 셈이죠. 잠재 추론, 즉 생각을 텍스트가 아니라 모델의 은닉 상태 안에서 처리하는 방식은 늘 당연한 해법으로 꼽혔고, 하이브리드 추론 에이전트에 관한 새 논문은 이제 그것이 실용적이라는 걸 보여줍니다. 다만 이 해법에는 이 분야의 누구도 반기지 않는 대가가 따릅니다. 모델이 무슨 생각을 하는지 더는 읽을 수 없게 된다는 거죠.

수년간 팀들이 chain-of-thought를 더 저렴하게 만들려고 애쓰는 모습을 지켜봤습니다. 모든 접근법이 같은 벽에 부딪히는데, 하이브리드 방식이 왜 다른지 이해할 가치가 있습니다. 그리고 그럼에도 저는 조용한 실패를 감당할 수 없는 곳에는 여전히 이것을 배포하지 않을 겁니다.

텍스트 기반 Chain-of-Thought가 토큰을 낭비하는 이유

Chain-of-thought는 정말 대단한 발견이었습니다. 중간 단계를 모델이 적어 보이게 하면 수학, 논리, 다단계 질문에서 정확도가 극적으로 오릅니다. 문제는 언어가 연산을 담기에 끔찍한 직렬화 형식이라는 점입니다. 단어는 손실이 많고 중복되며, 여러분의 추론 청구서에 결정적인 영향을 주는 건 순차적이라는 점입니다.

모델이 풀이 전에 “문제를 다시 정리하자면”이라며 문제를 되풀이할 때를 생각해 보세요. 이는 수백 토큰을 하나씩 생성하는 것이고, 매번 전체 forward pass가 필요한데 정보량은 거의 0입니다. 문제 설명은 이미 컨텍스트에 있으니까요. 요즘 추론 모델은 이런 것투성이입니다. 최신 모델의 추론 트레이스를 한 번이라도 본 사람이라면, 사람 엔지니어가 노이즈라고 부를 자기 확신, 반복, 머뭇거림이 단락째 이어지는 걸 봤을 겁니다. 도구 호출이 있는 에이전트 작업에서는 더 심합니다. 모델이 무엇을 하려는지 설명하고, 그것을 실행하고, 방금 한 일을 다시 설명하죠.

경제성은 에이전트 규모에서 더 불어납니다. 도구를 열 번 호출할 때마다 장황한 추론 서두를 붙이는 에이전트는 토큰 예산의 80%를 내레이션에 쓸 수도 있습니다. 토큰당 과금을 받는다면, 그리고 여러분은 그렇게 하고 있을 텐데, 그건 실제 비용입니다. 사람이 기다리는 에이전트에게는 지연 시간이기도 하고요. 이것은 더 저렴하고 빠른 추론 티어를 밀어붙이는 것과 같은 압력입니다. 병목은 지능이 아니라 그것을 말로 표현하는 비용입니다.

실패한 시도들: 잘라내기, 증류, 순수 잠재 추론

이 분야는 세 방향에서 공략했고, 각각 교훈적인 방식으로 무너졌습니다.

시도 1: 그냥 토큰을 덜 생성하기

Budget forcing, 길이 페널티, 간결한 추론 파인튜닝. 순진한 접근은 모델이 텍스트로 덜 생각하게 만드는 것입니다. 어느 정도까지는 효과가 있지만, 그 뒤로는 정확도가 절벽처럼 떨어집니다. 장황한 트레이스가 전부 낭비는 아니어서, 겉보기에 중복처럼 보이는 일부는 실제로 계산을 떠받치고 있습니다. 무작정 압축하면 군더더기와 함께 계산도 버리게 되고, 바깥에서는 둘을 구분할 수 없습니다.

시도 2: 순수 잠재 추론

더 우아한 아이디어는 사고 토큰을 아예 만들지 않는 것입니다. 모델의 출력 임베딩을 다시 입력으로 넣어, 이산적인 단어 대신 연속적인 “생각 벡터”를 쓰고, 답을 내기 전에 내부에서 여러 단계 추론하게 합니다. COCONUT 같은 연구는 일부 과제에서 적은 forward pass로 텍스트 chain-of-thought와 맞먹거나 능가할 수 있음을 보여줬습니다. 하지만 에이전트 관점에서 순수 잠재 추론에는 치명적인 문제가 두 가지 있습니다. 첫째, 외부 세계는 텍스트로 말합니다. 도구 API는 문자열 인자를 받고, 검색엔진은 쿼리를 받고, 사용자는 산문으로 된 답을 원합니다. 벡터로만 생각하는 모델도 경계에서 모든 것을 번역해야 하고, 오류는 바로 그 번역 과정에 숨어 있습니다. 둘째, 그리고 이건 사람들이 논쟁하는 지점인데, 사고가 블랙박스가 됩니다. 추론 트레이스 자체를 잃게 되는데, 이것이 지금 우리가 모델이 왜 그런 행동을 했는지 들여다볼 수 있는 유일하게 쓸 만한 창입니다.

시도 3: 일시 정지 토큰과 채움 계산

조용한 흐름으로, 내용 없는 “일시 정지” 토큰을 넣어 내용 없이 추가 연산을 주려는 시도도 있었습니다. 결과는 기껏해야 엇갈렸고, 연구실 밖으로 나오지 못했습니다. 알고 보니 중간 토큰의 존재보다 그 내용이 계산을 조종하는 데 중요했습니다.

실제로 작동하는 방법: 하이브리드 추론 에이전트

HybridAgent 논문은 제가 더 많은 연구가 취했으면 하던 실용적인 입장을 취합니다. 잠재 추론과 텍스트 추론 중 하나를 고르지 말고, 모델이 생성 도중에 둘 사이를 오가게 하자는 것입니다. 내부 연산을 할 때는 잠재로 생각하고, 도구를 호출하거나 그 출력을 읽거나 사람에게 설명해야 할 때는 텍스트로 전환하는 식입니다.

이 아키텍처에서 알아둘 만한 부분은 세 가지입니다. HybridLink라는 가벼운 모듈이 전환을 담당합니다. 잠재 구간의 마지막 은닉 상태를 텍스트 모드 모델이 이어 받을 수 있는 형태로 바꾸고, 그 반대도 합니다. 연속 작업 메모리는 턴 전체에 걸쳐 하이브리드 컨텍스트를 유지하므로, 1턴의 잠재 사고가 텍스트 요약으로 뭉개지지 않고 5턴에서도 여전히 쓸 수 있습니다. 학습 쪽은 두 단계입니다. HybridSFT가 백본에 HybridLink와 협응하는 법을 가르치고, 이어서 HybridRL이 강화학습으로 각 모드를 언제 쓸지, 그 비용이 값어치가 있는지를 가르칩니다.

제 생각에 진짜 기여는 마지막 부분입니다. 어려운 문제는 “모델이 잠재 공간에서 추론할 수 있는가”가 아니었습니다. 그건 이미 가능하다는 걸 알고 있었죠. 어려운 문제는 정책입니다. 과제의 어느 부분이 저렴하지만 불투명한 연산을 받을 자격이 있고, 어느 부분이 비싸지만 들여다볼 수 있는 텍스트를 받을 자격이 있는지 말이죠. 실제 과제 보상을 두고 강화학습으로 그 정책을 배우는 것이, 데모용이 아닌 실제로 돌아가는 무언가를 만드는 방법입니다.

보고된 수치는 인상적입니다. 수학, 과학, 의학, 검색, 에이전트 추론에 걸친 11개 벤치마크에서 하이브리드 에이전트는 텍스트 기반과 잠재 기준선 모두보다 약 10% 높은 성능을 주장하며, 토큰은 35~55% 줄고, 추론은 1.8~2.6배 빨라지고, 비용은 약 3배 절감된다고 합니다. 단일 논문의 벤치마크 주장은 늘 그렇듯 가려서 들어야 합니다. 벤치마크는 실제 워크로드의 모습을 자주 놓칩니다. 그래도 결과의 방향은 이론과 맞아떨어집니다. 트레이스의 대부분이 군더더기라면, 그 대부분을 걷어내면 주로 비용이 줄어야지 능력이 줄어서는 안 됩니다.

코드로 보는 잠재 추론의 실제 모습

기술적으로 이 트릭은 말보다 단순합니다. 텍스트 모드에서는 토큰을 샘플링하고, 임베딩하고, 다시 입력으로 넣습니다. 잠재 모드에서는 샘플링을 건너뛰고 모델 자신의 출력 벡터를, 작은 프로젝션을 거칠 수도 있지만, 바로 다음 입력으로 되먹임합니다. 어떤 모드인지는 특수 제어 토큰이나 학습된 게이트가 결정합니다. 개략적으로는 다음과 같습니다:

def hybrid_step(hidden_state, mode_gate, hybrid_link):
mode = mode_gate(hidden_state)  # learned: LATENT or TEXT
if mode == LATENT:
# No sampling. Feed the continuous thought back in.
next_input = hybrid_link.latent_in(hidden_state)
return next_input, None  # nothing human-readable emitted
# TEXT mode: normal autoregression
logits = lm_head(hidden_state)
token = sample(logits)
next_input = hybrid_link.text_in(embed(token))
return next_input, token  # inspectable output

실제 시스템에는 작업 메모리와 학습 장치가 더해지지만, 핵심 루프는 이것이 전부입니다. 이것이 서빙 스택에 무엇을 의미하는지 주목하세요. 잠재 단계도 여전히 완전한 forward pass입니다. 절약되는 것은 토큰 수, 즉 출력 길이, 컨텍스트 증가, 긴 트레이스에서 오는 KV 캐시 압박이지, 단계당 연산이 아닙니다. 2배 이상의 추론 속도 향상은 공짜 사고 때문이 아니라, 주로 시퀀스가 짧아지고 자기회귀 텍스트 디코딩이 줄어든 데서 나옵니다. 이 논문에 달린 한 댓글은 텍스트 생성과 병렬로 잠재 경로를 돌리자고 더 나아갔는데, 어차피 forward pass 비용은 치르고 있으니 말이 됩니다. 꽤 흥미로운 아이디어이고, 이 설계 공간이 얼마나 어린지 보여주기도 합니다.

아무도 치르고 싶어 하지 않는 해석 가능성 비용

이제 건너뛰면 직무 태만이 될 부분입니다. 추론 트레이스는 단순한 디버깅 편의가 아니라 안전장치입니다. 프로덕션에서 에이전트가 이상한 행동을 하면, 가장 먼저 하는 일이 트레이스를 읽는 것입니다. 정렬 연구자들이 기만적 행동을 탐지할 때도 최종 답과 모순되는 추론을 찾습니다. 추론을 벡터로 옮기면 두 워크플로우 모두 깜깜해집니다.

논문은 연속 작업 메모리가 잠재 사고를 “직접 검사 가능”하게 만든다고 주장합니다. 저는 그것을 기술적으로는 맞지만 실무적으로는 오해를 낳는 말로 분류하겠습니다. 벡터는 어떤 은닉 상태든 검사하는 방식으로 들여다볼 수 있습니다. 프로브 분류기, 디코더 투영, 임베딩 공간의 최근접 이웃 분석 등이죠. 그건 연구용 도구이지, 온콜 워크플로우가 아닙니다. 로그 파일을 읽는 것과 코어 덤프에 디버거를 붙이는 것의 차이입니다. 저를 포함한 몇몇은 오래전부터 해석 가능성에 대한 과장된 주장에 회의적이었는데, 작업 메모리 버퍼가 근본적인 비대칭을 바꾸지는 않습니다. 텍스트는 누구나 읽을 수 있지만, 잠재 벡터는 거의 아무도 읽을 수 없습니다.

덜 얘기되는 실패 모드도 있습니다. 바로 조용한 오류 전파입니다. 텍스트 트레이스에서는 잘못된 중간 단계가 눈에 보이고, 때로는 스스로 바로잡힙니다. 모델이 다시 읽으면서 자기 실수를 잡아내기도 하니까요. 하지만 잘못된 잠재 사고는 텍스트 흔적 하나 남기지 않고 작업 메모리를 타고 퍼집니다. 에이전트의 최종 답은 잠재 숙고가 건전했든 쓰레기였든 똑같이 유창해 보입니다. 프로덕션에서 에이전트를 운영하는 팀에게 이것은 격리 대 모니터링의 트레이드오프와 직결됩니다. 모니터링이 훨씬 어려워졌기 때문에, 하이브리드 에이전트는 격리 쪽으로 기울게 만듭니다.

이 논문을 둘러싼 논의에서는, 잠재 추론이 바로 이런 이유로 연구 커뮤니티 일부에서 비공식적으로 금기였다는 점이 언급되었습니다. 그 금기는 분명히 끝났습니다. 그것이 자동으로 나쁜 일이라고는 생각하지 않습니다. 다만 효율 수치를 찬양하는 사람들은, 그 수치를 사기 위해 해석 가능성을 지불하고 있다는 사실을 솔직히 인정해야 합니다.

논문과 여러분의 GPU 사이의 간극

코드, 가중치, 데이터가 모두 공개된 건 정말 훌륭합니다. 그리고 곧바로 현실 점검이 이루어졌습니다. 몇 시간 안에 공개 모델을 로컬에서 돌리던 실무자들이 퇴화된 동작을 보고했습니다. 한 양자화된 8B 빌드는 “교황은 누구인가”라는 질문에 같은 텍스트 모드 추론 단락을 끝없이 반복했고, 14B 빌드는 평범한 검색 후 요약 과제에서 5분 동안 같은 단락의 변형만 되풀이했습니다. 비슷한 다른 모델들은 이 과제를 잘 처리합니다.

양자화 아티팩트나 채팅 템플릿 불일치일 수도 있습니다. 완전히 새로운 아키텍처에 대한 llama.cpp 지원은 늘 주사위 던지기니까요. 하지만 저는 이 루핑 실패가 우연이 아니라고 봅니다. 모드 전환은 학습된 행동이고, 학습된 행동은 양자화와 분포 변화가 가장 먼저 깨뜨리는 것입니다. 잠재-텍스트 정책이 조금이라도 어긋난 모델은 크게 실패하지 않습니다. 생각을 멈추기로 결정하지 못하는 방식으로 실패합니다. 이건 프로덕션 에이전트에게 잘못된 답보다 훨씬 골치 아픈 실패입니다. 예산을 무한정 태우기 때문입니다. 지금 에이전트 루프를 만든다면, 어떤 추론 패러다임을 택하든 모든 모델 호출 주변에 엄격한 턴 및 토큰 예산을 두라는 근거가 하나 더 생긴 셈입니다. 에이전틱 CLI가 루프를 구성하는 방식에서 다룬 규율이 여기에도 필요합니다.

그래서 신경 써야 할까? 실용주의자의 결론

네, 다만 의존성이 아니라 이정표로서입니다. 제 솔직한 판단은 이렇습니다:

• 효율성 논리는 실재하며 구조적입니다. 텍스트는 내부 연산에 나쁜 매체이고, 에이전트의 작업 시간이 길어질수록 내레이션에 붙는 토큰 세금은 늘어날 수밖에 없습니다. 좋든 싫든 어떤 형태의 잠재 추론이든 프로덕션 모델에 들어올 겁니다. 선도 연구소들의 불투명한 “추론 요약” 방식은 이미 그 길의 한 걸음이라고 할 수 있습니다.
• 해석 가능성 비용도 실재하며, 현재는 과소평가되어 있습니다. 의학, 금융, 규제 대상 분야 등 에이전트가 왜 행동했는지 감사해야 한다면, 텍스트 트레이스는 포기하기에 너무 위험한 기능입니다.
• 현재의 결과물은 연구 수준입니다. 단순한 프롬프트에서의 퇴화된 루프, 불확실한 양자화 동작, 쉽게 검사할 수 없는 모드 전환 정책은 고객 대면 API 뒤에 둘 만한 것이 아닙니다.
• 하이브리드 관점이 옳은 틀입니다. 순수 잠재 추론은 도구 API와 사용자를 만나면 살아남지 못했을 것이고, 순수 텍스트 추론은 추론 청구서 앞에서 버티지 못합니다. 둘 사이의 학습된 경계가 결국 종착점이 될 것입니다.

더 깊은 요점은, “말로 생각하기”가 원래 이 모델들을 훈련시킨 방식의 우연이었지 인지의 법칙이 아니었다는 것입니다. 언어가 기계 사고의 올바른 입도라는 정리는 없습니다. 놀라운 점은 그것이 생각보다 잘 작동했다는 것이죠. 하이브리드 추론 에이전트는 그다음에 올 것에 대한 첫 번째 믿을 만한 스케치입니다. 모델이 사적으로 숙고하고, 말해야 할 일이 있을 때만 말하는 모델들이죠. 기계의 작업을 검증할 수 있는 능력을 잃지 않고 그 미래를 만들 수 있을지가, 제 생각에는 지금 에이전트 설계에서 가장 중요한 미해결 질문입니다.