실패는 처음이 아니라 중간에서 온다
에이전트가 작업을 망친 경험이 있다면, 그 실패가 어느 지점에서 시작됐는지 제대로 봤는가? SyncSoft.AI의 분석에 따르면, 코딩 에이전트의 실패는 대부분 첫 단계가 아닌 중간 어딘가에서 조용히 시작된다. 에이전트는 태스크를 정확히 읽고, 첫 동작도 깔끔하게 수행한다. 문제는 4번째 스텝쯤에서 슬그머니 잘못된 가정을 하나 박아 넣고, 이후 20개 스텝을 그 위에 쌓아올린다는 것이다. 결과물은 틀렸지만 플래시 표면적으로는 그럴듯하다. 크래시도 아니고, 신택스 에러도 아니다. 그냥 조용히 망가진 것이다.
왜 우리는 이 지점을 놓치나
문제의 뿌리는 평가 방식에 있다. SWE-bench 같은 벤치마크는 태스크의 최종 결과만 판단한다. 테스트를 통과하면 성공, 아니면 실패. 이 이진법 신호는 실제로 유용하지만 동시에 극도로 조잡하다. 30단계 궤적의 끝에서 얻은 패스/페일 판정은 어디서, 왜 망가졌는지를 전혀 알려주지 않는다. 같은 0% 점수를 받은 두 에이전트가 사실 완전히 다른 이유로 실패했을 수 있다. 하나는 태스크 자체를 잘못 읽었고, 다른 하나는 9번째 스텝에서 파일 수정을 하나 잘못했을 뿐인데.
결과 중심의 트레이닝 데이터는 또 다른 문제를 만든다. 정제된 (문제 → 정답) 쌍만 학습한 모델은 실수가 없는 세계만 경험한다. 실수의 질감을 모르니, 실수 안에서 빠져나오는 법도 모른다. 시니어 엔지니어링의 핵심이 틀렸을 때 감지하고, 진단하고, 수정하고, 계속 가는 루프라는 걸 감안하면, 현재 대부분의 에이전트는 그 절반도 학습받지 못한 셈이다.
진단 데이터로 무엇을 해야 하나
팀 레벨에서 당장 적용할 수 있는 접근은 세 가지다.
첫째, 궤적 전체를 로깅하라. 결과만 기록하면 디버깅에 필요한 데이터를 이미 날린 것이다. 모든 스텝, 모든 툴 콜, 모든 관측값을 남겨야 한다.
둘째, 스텝 레벨 평가를 구축하라. '어느 스텝에서 실패가 시작되는가'를 히트맵으로 그릴 수 있어야 한다. pass@1 숫자 하나보다 이 히트맵이 훨씬 더 많은 정보를 담고 있다.
셋째, 중간 실패 상태를 eval에 심어라. 모든 eval이 깨끗한 초기 상태에서 시작한다면, 에이전트가 회복 능력이 있는지 전혀 테스트하지 않은 것이다. 의도적으로 망가진 중간 상태를 심고, 에이전트가 그걸 감지하는지 측정해야 한다. 대부분의 에이전트는 감지하지 못한다. 그 갭이 곧 개선 로드맵이다.
메모리가 없으면 복구도 없다
여기서 실패 진단은 메모리 아키텍처 설계 문제로 자연스럽게 이어진다. 에이전트가 중간에 무너지는 이유 중 하나는, 이전 세션에서 비슷한 실패를 이미 경험했음에도 그 기억이 없기 때문이다. 스테이트리스 에이전트는 매 실행마다 처음부터 같은 실수를 반복할 수 있다. 이건 아키텍처적 선택의 결과다. 단순하게 유지하는 대신, 영원히 평범한 수준에 머문다.
오픈소스 에이전트 런타임인 Hermes Agent는 이 문제를 정면으로 건드린다. 핵심은 OERC 사이클이다. Observe → Execute → Reflect → Crystallize. 실행 후 반성 단계(Reflect)에서 GEPA(Genetic-Pareto Prompt Evolution) 시스템이 실행 트레이스를 분석해 실패 지점을 찾고, 왜 회복이 작동했는지를 모델링한다. 그 결과물은 구조화된 스킬 파일로 ~/.hermes/skills/에 저장된다(Crystallize). 다음 세션의 Observe 단계에서 에이전트는 이 파일을 먼저 스캔한다. 같은 실수를 두 번 할 이유가 줄어든다.
메모리 아키텍처의 설계 디테일이 품질을 결정한다
Hermes의 메모리 구조는 세 레이어로 나뉜다. 세션 컨텍스트(휘발성 워킹 메모리), MEMORY.md에 저장되는 에피소딕 메모리(약 800토큰), 그리고 사용자 패턴을 담는 USER.md(약 500토큰). 여기서 중요한 것은 사이즈 캡이다. Hermes 팀은 이를 임의로 정한 게 아니라, 컨텍스트 주입이 너무 많아지면 오히려 모델 성능이 떨어지는 지점을 실험으로 찾아 설정했다고 밝힌다. 메모리 설계는 '많을수록 좋다'가 아니다. 신호 대 잡음비가 반전되는 지점을 알고 그 앞에 멈추는 것이다.
검색 레이턴시도 실용적으로 해결했다. 벡터 DB 없이 SQLite FTS5로 수천 개의 대화 기록을 10ms 이내에 스캔한다. 인프라 복잡도를 최소화하면서 성능을 확보하는 선택이다. 에이전트 인프라에서 '간단한 것이 실제로 작동한다'는 원칙을 보여주는 사례다.
그래프 메모리: 맥락을 연결하는 다른 접근
Long-Horizon은 다른 각도에서 같은 문제를 푼다. 컨텍스트 지속성을 파일 기반 메모리 대신 그래프 구조로 구현한다. 모든 결정, 교훈, 패턴이 노드가 되고, 이들은 leads_to, caused_by, learned_from 같은 타입이 있는 엣지로 연결된다. 에이전트는 이 지식 그래프를 순회하며 현재 태스크에 관련된 맥락을 찾는다.
실용적 장점은 중단 내성이다. 어떤 이유로든 실행이 멈춰도 에이전트는 그래프를 읽고 정확히 중단된 지점부터 재개한다. 외부 의존성도 없다. 벡터 DB도, 클라우드도, API 키도 필요 없다. 순수 Node.js와 파일시스템만으로 작동한다. 철학적으로 Hermes의 SQLite 선택과 같은 방향이다. 복잡성을 줄이면서 신뢰성을 높인다.
AI-First 워크플로우에서 이 모든 게 수렴하는 지점
세 가지 접근이 각자 다른 레이어에서 같은 문제를 가리킨다. 코딩 에이전트의 중간 실패 패턴 분석은 궤적 데이터를 퍼스트클래스로 취급하라고 말한다. Hermes의 OERC 사이클은 실행 후 반성을 자동화해 절차적 메모리로 결정화하라고 말한다. Long-Horizon의 그래프 메모리는 맥락을 구조적으로 연결해 중단 후 재개를 보장하라고 말한다.
팀 레벨 시사점은 명확하다. 에이전트를 프로덕션에 올리기 전에 세 가지 질문을 먼저 해야 한다. 에이전트가 중간에 잘못된 결정을 내릴 때 우리가 그걸 알 수 있는가? 같은 실패를 다음 번에도 반복하지 않도록 학습 구조가 있는가? 실행이 중단됐을 때 맥락을 잃지 않고 재개할 수 있는가. 이 세 질문에 모두 '예스'라고 답하기 전까지, 에이전트는 데모일 뿐 프로덕트가 아니다.
2026년 에이전트 신뢰성의 경쟁 축
앞으로 에이전트 신뢰성의 경쟁은 모델 성능보다 메모리 아키텍처와 궤적 데이터 품질로 이동할 가능성이 높다. 가장 영리한 프롬프트를 가진 팀이 이기는 게 아니라, 에이전트의 경로를 로깅하고, 실패 지점을 레이블링하고, 그 데이터로 지속적으로 개선하는 루프를 갖춘 팀이 이긴다. 메모리는 에이전트를 편리하게 만드는 기능이 아니다. 반복 실패를 구조적으로 차단하는 신뢰성 레이어다. 설계 단계에서 이걸 결정하지 않으면, 나중에 고치는 비용이 훨씬 비싸진다.