LLM 에이전트의 신뢰성은 모델만으로 결정되지 않는다: Harness Engineering에서 State-Aware Runtime으로

1. 에이전트 분야는 마침내 '모델만' 이야기하는 단계를 벗어났다

최근 CMU와 Yale 같은 연구기관에서 Agent Harness Engineering 관련 리뷰 논문이 발표되었습니다. 이 논문의 등장은 매우 강한 업계적 상징적 의미를 가집니다. 그것은 **"대규모 언어 모델(LLM) 에이전트의 신뢰성을 모델 단독으로만 추구해서는 안 된다"**는 합의로의 전환을 공식 선언했기 때문입니다.

지금까지 에이전트에 대한 기대는 단순한 선형 외삽에 기반했습니다. 모델 파라미터가 커지면 에이전트는 똑똑해지고, 컨텍스트 윈도우가 길어지면 더 복잡한 태스크를 처리할 수 있으며, 외부 API 도구가 많으면 능력의 경계가 넓어진다는 사고방식입니다.

이 판단은 틀리지 않았지만, 너무 불충분합니다.

2. 왜 모델이 강화되어도 에이전트는 실패하는가

실제로 장기 태스크를 실행한 개발자라면, 에이전트가 무너지는 이유가 갑자기 논리적 추론 능력을 상실해서가 아니라, 시스템 전체에 안정적인 런타임 구조가 결여되어 있기 때문임을 깨닫게 될 것입니다.

• 현재 태스크의 주된 흐름을 무의식적으로 잊어버림
• 할루시네이션을 포함한 추론을 확정된 사실로 메모리에 기록
• 파괴적인 도구를 호출한 후 세계 상태를 동기화 업데이트하지 않음
• 치명적인 오류 판단 후에도 매우 자신감 넘치는 어조로 잘못된 인과관계를 따라 추진

이러한 시스템 수준의 눈사태는 수천억 파라미터의 모델로 교체하거나, 1M 컨텍스트 윈도우에 채워 넣는다고 해결할 수 있는 문제가 아닙니다.

에이전트란 단순한 "모델 + 시스템 프롬프트"가 아니며, "모델 + 몇 개의 Function Call"도 아닙니다. 진정한 산업 수준의 에이전트는 모델, 상태 머신, 메모리 흐름, 실행 샌드박스, 밸리데이터, 모니터링/트레이스, 그리고 복구 전략이 공동으로 구성하는 복잡한 운영 체제입니다.

3. Harness의 주목도는 높지만, 종착점은 아니다

CMU/Yale의 리뷰는 Harness Engineering이 업계의 주요 학문이 되었음을 증명했습니다. 그러나 제 연구 관점에서 Harness는 어디까지나 첫 단계에 불과하다고 생각합니다.

Harness가 해결하는 것은 정적인 문제입니다. 즉 "에이전트의 외접 시스템은 어떤 컴포넌트로 구성되는가"라는 것입니다.

한편 제가 탐구하는 것은 더 심각한 동적인 문제입니다. **"이러한 컴포넌트들이 어떻게 장기적이고 안정적이며, 감사 가능하고, 롤백 및 복구 가능한 실행 상태를 공동으로 유지하는가"**라는 것입니다.

저는 이 방향성을 **"State-Aware Runtime (상태 인식 런타임)"**으로 정의하고 있습니다.

4. Harness 다음은 진정한 문제가 Runtime으로 이동한다

여기서 말하는 State-Aware Runtime이란 단순히 에이전트에 메모리를 추가하거나, 기록을 긴 컨텍스트에 채워 넣는 것이 아닙니다. 에이전트의 모든 실행 단계를 "검증 가능한 상태 전이"로 모델링하는 것입니다. 시스템은 현재 상태가 무엇인지, 어떤 조작이 후보에 불과한지, 어떤 조작이 커밋되었는지, 어떤 상태가 롤백 가능한지, 그리고 어떤 실패를 격리하고 인간에게 맡겨야 하는지 파악하고 있어야 합니다.

Anthropic와 OpenAI의 지난 1년간 플랫폼 진화는 사실 모두 같은 일을 하고 있습니다. LLM을 채팅박스에서 분리하고, 제어 가능한 엔지니어링 지지체(scaffolding)에 통합하는 것입니다. Anthropic는 조합 가능한 에이전트 패턴(Context Engineering / Long-running Harness)을 강조하고, OpenAI는 플랫폼 네이티브한 기능(State / Guardrails / Monitoring)을 추진하고 있습니다.

Harness Engineering의 대두는 정교한 컴포넌트 맵을 제공해주었습니다. 그러나 지도에 강과 산이 표시되어 있어도, 지도 자체가 기계를 움직일 수는 없습니다.

① Runtime에서의 상태 유지 중요성

장기 에이전트에서 진정한 핵심은 고빈도 상태 전이입니다. 한 번의 동작은 단순히 다음 토큰을 생성하는 것이 아니라, 다음과 같은 프로세스입니다.

이 실행 흐름에서 가장 무서운 것은 모델이 잘못된 답을 출력하는 것이 아니라, 시스템이 현재 상태를 전혀 파악하지 못하는 것입니다.

어떤 사실은 변경 불가능한 상식인가. 어떤 것이 일시적인 세션 컨텍스트인가. 어떤 조작이 이미 데이터베이스에 영구적으로 기록되었는가. 오류가 발생했을 때 시스템은 상태 포인터를 어떤 안전한 세이브 포인트까지 되돌려야 하는가.

명시적 상태 관리가 없으면, 에이전트는 "겉으로는 매우 똑똑해 보이지만 내부 상태는 모순투성이인 텍스트 생성기"에 불과합니다.

② 긴 컨텍스트는 장기 상태 관리가 아니다

현재 많은 기업이 컨텍스트 윈도우 확대에 혈안이 되어 있지만, 이는 핵심적인 엔지니어링 고통점을 가리고 있습니다. 긴 컨텍스트는 결코 장기 상태 관리와 동일하지 않습니다.

수만 글자 기록을 단순히 모델에 주입하면, 안정적인 기억이 얻어지기는커녕 오히려 재앙을 초래할 수 있습니다. 초기의 엄격한 설정이 중반의 수다에 덮어쓰기되고, 일시적인 추측이 진리로 고정되며, 요약 압축 과정에서 태스크의 원래 의도가 은밀히 변조될 가능성이 있습니다.

Context Engineering의 핵심 질문은 "어떻게 올바른 정보를 프롬프트에 전달할 수 있는가"입니다. 대신 State-Aware Runtime의 질문은 더 엄격합니다. "현재 상태란 무엇인가. 누가 상태를 변경할 권한을 가지는가. 오염된 상태를 어떻게 격리하고 복구하는가"입니다. 이것이야말로 진정한 시스템 엔지니어링입니다.

③ 잘못된 상태의 "커밋"이라는 위험

기존의 LLM 평가(MMLU 등)에서는 최종 답변만 봅니다. 정답이면 성공, 틀리면 실패입니다. 그러나 에이전트의 평가에서 이 사고방식은 통용되지 않습니다. 에이전트의 실패는 프로세스 중간에서 양성되고, 연쇄적으로 전파 (Cascading Failure) 되는 특성을 가지기 때문입니다.

모델이 사용자의 의도를 오인하더라도, 그것이 "후보 텍스트" 단계라면 재시도로 해결할 수 있습니다. 그러나 그 오인이 시스템의 장기 메모리에 기록되는 순간, 이후 수십 단계에 걸친 계획은 무너진 토대 위에 구축되게 됩니다.

마찬가지로, 위험한 API 호출을 생성하더라도, 외부 밸리데이터가 차단하면 시스템은 안전합니다. 그러나 그 호출이 실제로 외부 데이터베이스나 게임 세계의 상태를 변경해버린다면, 오류는 "언어적 할루시네이션"에서 "외부 상태 오염이라는 물리적 영향"으로 변모합니다.

따라서 장기 에이전트의 핵심 설계는 모델에게 "절대 틀리지 않는 것"을 강요하는 것이 아니라, "후보 출력과 커밋된 상태를 엄격히 구분하는" 탄탄한 경계 방어를 구축하는 데 있습니다.

④ 성공 데모가 아닌 "실패의 궤적"으로 신뢰성을 판단한다

현재 AI 분야는 모델이 자율적으로 계획을 세우고, API를 호출하며, 완벽하게 태스크를 수행하는 화려한 성공 데모로 넘쳐납니다. 그러나 연구자로서 저는 이러한 생존자 편향에 의한 정보의 가치를 의심합니다. 고신뢰 시스템을 구축하는 데 있어, 완벽한 데모보다 실제적이고 상세한 실패의 궤적 (Failure Trajectory)이 훨씬 가치가 높습니다.

트레이스를 깊이 해부해야만 다음과 같은 것이 판명됩니다.

• 무너짐은 어디서 일어났는가. 상태 투영의 결여인가, 혹은 도구 실행 체인의 단절인가.
• 모델이 출력 형식을 무시한 것인가, 아니면 밸리데이터의 규칙이 너무 느슨했는가.
• 잘못된 기억이 불시에 기록되었는가, 혹은 재시도 시 데드 루프에 빠져 오류가 확대되었는가.

이것이 제가 **Trace-Native Evaluation (궤적 네이티브 평가)**를 권장하는 이유입니다. 단순히 "마지막에 succeeded했는가"를 묻는 것이 아니라, "이 결과가 어떻게 스텝바이스텝으로 생성되었는가", "중간 상태에 오염은 없었는가", "시스템이 정확하게 오류를 식별하고 복구를 실행할 수 있었는가"를 물어야 합니다.

독립 연구자가 깊이 파고들어야 할 "시스템 통제 불가" 문제

최근 제 독립 연구를 돌아보면, 처음부터 "State-Aware Runtime"이라는 개념을 가지고 있던 것은 아닙니다. 처음에는 다음과 같은 단순한 의문이었습니다.

• 왜 모델은 정답을 출력하면서 프로세스는 불안정한가.
• 왜 장편 서사 에이전트는 대화는 유창하면서 캐릭터의 지식이나 관계성의 상태가 표류(drift)하는가.
• 왜 구조화 생성 태스크에서 표현은 자연스러운데 저류의 수학적 구조가 은밀히 변경되는가.

이러한 문제들은 서로 다른 태스크에 분산되어 있었지만, 점차 하나의 공통 모순이 부상했습니다.

LLM의 생성 능력은 향상되고 있지만, 생성 프로세스에 안정적인 상태 경계, 프로세스 제약, 및 실패 복구 메커니즘이 결여되어 있다.

• 규범적 추론에서는 정답과 프로세스 충실성의 괴리 (procedural fidelity)에 주목했습니다.
• 장편 서사 에이전트에서는 캐릭터의 인식상 기억 (epistemic memory)에 주목했습니다.
• 멀티 에이전트 사회 상호작용에서는 사회적 정보 채널이나 규범이 에이전트의 행동을 어떻게 형성하는지에 주목했습니다.
• 구조화 생성 태스크에서는 언어의 유창성과 구조의 충실성의 괴리에 주목했습니다.
• 게임 에이전트 Runtime에서는 자유 대화와 세계 상태의 커밋 경계에 주목했습니다.

이것들은 흩어진 방향이 아니라, 모두 하나의 트렌드를 가리킵니다. 장기 에이전트의 신뢰성 문제는 더 이상 단일 모델 능력으로 설명할 수 없으며, 런타임 계층의 상태 관리, 프로세스 감사, 게이트 차단, 및 실패 복구로 이행해야 합니다.

따라서 제 현재 연구 포지셔닝은 다음과 같습니다.

장기 LLM 에이전트에서의 상태 유지, 프로그램 준수, 프로세스 감사, 게이트 및 롤백 메커니즘에 주목하고, 그것을 단순한 프롬프트 엔지니어링이나 메모리 확장의 문제가 아닌, "State-Aware Runtime"의 문제로 이해한다.

계산 자원이 정의로 여겨지는 LLM 시대에, 자원이 제한된 독립 연구자가 모델 훈련이나 벤치마크 점수 경쟁에 뛰어드는 것은 현명하지 않습니다.

그러나 State-Aware Runtime은 독립 연구자가 깊이 파고들기에 매우 적합하며, 장기적 진입 장벽을 쌓을 수 있는 영역입니다. 여기서는 수천 기의 GPU 어레이가 아니라, 시스템 실패에 대한 매우 예민한 감각과 인내가 무기가 됩니다. 혼자서 고밀도의 Failure Trace의 분석, 상태 표류의 분석, 밸리데이터와 롤백의 실험을 수행하고, 상세한 "에이전트 붕괴 분류학 (Failure Taxonomy)"을 구축하는 것은 충분히 가능합니다.

대기업의 관점은 "어떻게 모델에게 정답을 더 많이 출력하게 할 수 있는가"에 집중되기 쉽지만, 독립 연구자는 "시스템이 필연적으로 잘못될 때, 어떻게 모든 것을 파괴하지 않고 넘어갈 수 있는가"라는 어둠 속의 연구를 깊이 파고들 수 있습니다.

결론: 에이전트의 후반전은 "시스템의 전쟁"이다

LLM은 더욱 강해지고, 컨텍스트 윈도우는 극한까지 확장되며, 구현 지능이나 멀티모달 API가 파도처럼 밀려올 것입니다.

그러나 조수가 빠진 후 남는 진정한 산업적 병목은 모델이 충분히 똑똑한지 여부가 아닙니다. 승패를 가르는 척도는 다음과 같은 점이 될 것입니다. "매우 혼란스러운 외부 환경에서 내부 상태를 장기적으로 유지할 수 있는가", "메커니즘으로 인해 오조작의 커밋을 차단할 수 있는가", "설명 가능한 감사 트레이스를 남기고, 눈사태가 발생한 후 우아하게 롤백하여 복구할 수 있는가"

모델이 "무한한 생성 가능성"을 담당하고, Harness가 "물리적 제약 환경"을 제공하며, 그리고 State-Aware Runtime이 "상태의 일관성", "프로세스의 충실성", "파멸적 커밋의 저지"를 담당합니다.

에이전트 경쟁의 후반전에서, 이들 고능력이지만 불안정한 모델을, 감사 가능하고 복구 가능한 상태 머신 시스템에 안전하게 통합할 수 있는 자가, 차세대 지능 운영 체제의 진정한 해자(Moat)를 쌓게 될 것입니다.