모든 에이전트의 실패는 일정한 패턴을 따릅니다. 일단 그 패턴을 알게 되면, 피해가 발생하기 전에 이를 포착할 수 있습니다.

저는 어제 AI 에이전트 주변에 안전 및 신뢰성 계층을 구축하는 규율인 하네스 엔지니어링 (harness engineering)을 소개했습니다. 오늘은 구체적인 내용을 다루고자 합니다. 다음은 모든 팀이 에이전트를 프로덕션 (production) 환경에서 실행할 때 마주치는 7가지 실패 모드(failure modes)와, 각 모드를 어떻게 감지하는지, 그리고 감지했을 때 무엇을 해야 하는지에 대한 내용입니다.

1. 무한 루프 (The Infinite Loop)

현상: 에이전트가 동일한 패턴으로 grep을 6번 호출하고, 매번 동일한 결과를 얻으며, 그 중 어떤 결과에도 반응하지 않습니다. 에이전트는 "컨텍스트를 수집 중 (gathering context)"인 상태입니다. 각 호출은 토큰 (tokens)을 소모합니다. 컨텍스트 윈도우 (context window)가 가득 찹니다. 결국 세션이 타임아웃되거나 쓰레기 값을 생성합니다.

도구들이 놓치는 이유: 관측성 (Observability) 대시보드에는 6번의 grep 호출이 표시됩니다. 이는 생산적으로 보입니다. 오케스트레이션 프레임워크 (Orchestration frameworks)는 각 호출을 충실히 실행합니다. 에러는 발생하지 않습니다. 세션은 중단될 때까지 "여전히 실행 중"인 상태입니다.

감지: 동일한 호출 횟수를 세지 마세요. 정보 이득 (information gain)을 추적하세요. 이 호출이 전진된 진행으로 이어지는 새로운 데이터를 생성했는가? 파일 쓰기, 테스트 통과, 결정, 상태 변화 등이 있었는가? 만약 동일한 입력값으로 동일한 도구를 사용하여 4회 연속으로 동일한 출력을 생성하면서 후속 조치가 없다면, 그것은 루프입니다.

해결: 가벼운 루프는 에이전트의 컨텍스트에 다음 단계로 넘어가거나 출력을 생성하도록 제안하는 메시지를 주입하여 자극을 줍니다. 심각한 루프(토큰 소모 가속화, 8회 이상의 턴 동안 진전 없음)는 회로 차단기 (circuit-break)를 작동시킵니다: 세션을 일시 중지하고, 체크포인트 (checkpoint)를 저장하며, 전체 트레이스 (trace)와 함께 사람에게 알림을 보냅니다.

2. 조용한 컨텍스트 사망 (Silent Context Death)

현상: 에이전트가 세션 내내 파일을 읽습니다. 8번째 턴이 되면 컨텍스트가 85%에 도달합니다. 10번째 턴이 되면 에이전트는 3번째 턴에서 읽었던 내용을 잊어버립니다. 에이전트는 해당 파일들을 다시 읽으며 컨텍스트를 더욱 채웁니다. 아무런 에러도 발생하지 않은 채 출력 품질이 저하됩니다.

도구가 이를 놓치는 이유: 실패 이벤트가 발생하지 않기 때문입니다. 에이전트는 출력을 생성하고 있지만, 단지 품질이 저하되고 있을 뿐입니다. 어떤 모니터링 도구도 _컨텍스트 압박 (context pressure) 대비 출력 품질_을 추적하지 않습니다. 이는 충돌(crash)이 아니라 조용한 하락입니다.

탐지 (Detection): 컨텍스트 압박을 윈도우(window) 대비 백분율로 추적하세요. 정보 밀도(information density)를 추적하세요. 즉, 컨텍스트의 어느 비율이 최신이며 실행 가능하고 관련성이 있는지, 반대로 얼마나 오래되었거나 중복되거나 쓸모없는지 확인해야 합니다. 중간 수정 없이 파일이 다시 읽히는 횟수를 추적하세요. 압박이 높은 상태에서 오래된 정보의 비율이 임계값을 넘으면 세션이 저하되고 있는 것입니다.

해결 (Fix): 컨텍스트 압축 (context compression)을 트리거하세요. 네 가지 계층을 적용합니다: 최근의 도구 출력은 보존하고, 오래된 컨텍스트는 요약하며, 중복된 파일 읽기는 제거하고, 현재의 작업과 추론 체인 (reasoning chain)은 온전하게 유지합니다. 에이전트는 압축을 전혀 알아차리지 못하며, 품질은 일관되게 유지됩니다.

3. 비용 급증 (The Cost Spike)

현상: 두 가지 유형이 있습니다. 폭주하는 비용 (Runaway cost): 에이전트가 조사 과정에서 미궁에 빠져 단순한 리팩토링에 12달러의 토큰 비용을 소모하는 경우입니다. 모델 불일치 (Model mismatch): 복잡한 아키텍처 변경 작업이 저렴한 모델로 라우팅되어 쓰레기 같은 결과물을 생성하고, 이를 재작업하는 비용이 처음부터 적절한 모델을 사용하는 것보다 더 많이 드는 경우입니다.

도구가 이를 놓치는 이유: 관측성 (Observability)은 사후에 비용을 보여줍니다. 게이트웨이 (Gateways)는 기본적으로 사용 가능한 가장 저렴한 모델로 라우팅합니다. 두 방식 모두 작업의 복잡성이 모델의 능력과 일치하는지 확인하지 않습니다.

탐지 (Detection): 작업 유형별, 모델별, 에이전트별로 비용을 이동 평균 (moving average)으로 추적하세요. 비용이 이동 평균의 3배를 초과하면 경고를 발생시키세요. 별도로 작업 복잡도를 분류하고 라우팅 전에 모델 적합성을 확인하세요. 이계도함수 (second derivative)를 추적하세요. 가속화되는 비용은 지속적으로 높은 비용보다 더 위험합니다.

해결 (Fix): 폭주하는 비용의 경우: 에이전트가 출력을 생성하거나 컨텍스트를 압축하도록 유도하세요. 모델 불일치의 경우: 세션 중간에 더 유능한 모델로 에스컬레이션 (escalate)하세요. 완료 기미 없이 비용이 가속화된다면, 작업을 일시 중지하고 사람에게 알리세요.

4. 비밀 유출 (The Secret Leak)

현상: 에이전트가 .env 파일이나 설정 파일을 읽습니다. 그리고 그 내용을 응답에 그대로 출력(Echo)합니다. 이제 API 키, 데이터베이스 비밀번호, 또는 JWT 비밀키가 로그 파일, 채팅 기록, 또는 Slack 스레드에 남게 됩니다.

도구가 이를 놓치는 이유: 가드레일(Guardrails)은 개인정보(PII)와 유해성(Toxicity)을 검사합니다. 하지만 API 키는 이 중 어디에도 해당하지 않는 단순한 문자열일 뿐입니다. SAST(정적 애플리케이션 보안 테스트)는 커밋 전의 코드를 스캔합니다. 이것은 런타임(Runtime) 동작입니다. 즉, 에이전트가 보호된 소스(Protected source)에서 보호되지 않은 싱크(Unprotected sink)로 정보를 이동시키는 상황입니다.

탐지: 에이전트가 콘텐츠를 생성한 시점과 그 콘텐츠가 외부 시스템에 도달하기 사이의 출력 경로(Output path)에서 탐지를 수행하세요. 정규 표현식 패턴(AWS 키 형식, JWT 구조, 일반적인 고엔트로피 문자열)과 엔트로피 분석(Entropy analysis)을 결합하십시오. 오탐(False positives)을 줄이기 위해 알려진 안전한 패턴과 대조하여 확인하세요.

해결책: 정보가 유출되기 전에 출력을 차단하십시오. 변경 불가능한 감사 기록(Immutable audit record)을 작성하세요. 어떤 비밀 정보가 유출될 뻔했는지, 어떤 에이전트가 이를 생성했는지, 어떤 파일에서 비밀 정보를 읽었는지, 유출로 이어진 작업 체인(Chain of actions)이 무엇인지에 대한 전체 추적 정보(Full trace)를 보안 팀에 알리세요. 이것은 서킷 브레이커(Circuit-break) 시나리오입니다. 권고나 경고 없이 즉각적인 개입이 필요합니다.

5. 멀티 에이전트 데드락 (The Multi-Agent Deadlock)

현상: 에이전트 A가 에이전트 B를 기다립니다. 에이전트 B는 에이전트 A를 기다립니다. 어느 쪽도 진행할 수 없습니다. 오케스트레이터(Orchestrator)는 각 에이전트가 출력을 생성할 때까지 충실히 기다립니다. 10분이 지나고, 세션은 타임아웃(Time out)됩니다. 작업은 손실됩니다.

도구가 이를 놓치는 이유: 오케스트레이터는 출력을 기다리는 두 개의 활성 세션을 보고 있습니다. 관측성(Observability) 도구는 에러를 발견하지 못합니다. 모든 것이 정상적으로 보입니다. 단지 느릴 뿐입니다. 멀티 에이전트 시스템은 데드락(Deadlocks), 중복 출력(Redundant outputs), 대화 정체(Conversation stalls)와 같은 실패 모드를 배가시킵니다.

탐지: 에이전트 간의 의존성 체인(Inter-agent dependency chains)을 추적하세요. 둘 이상의 에이전트가 60초 이상 서로를 기다리고 있다면 그것은 데드락입니다. 이와 별개로, 여러 에이전트가 동일한 출력을 생성하는 경우(다양성 붕괴, Variety collapse)나 45초 동안 어떤 에이전트도 메시지를 생성하지 않는 경우(대화 정체, Conversation stall)를 탐지하세요.

해결책 (Fix): 모든 대기 중인 에이전트의 컨텍스트(Context)에 강력한 메시지를 주입하여 사이클을 끊으세요. 30초 이내에 실패할 경우, 서킷 브레이크(Circuit-break)를 실행하세요: 체크포인트를 저장하고, 에이전트를 중단하며, 사람에게 알립니다. 다양성 붕괴(Variety collapse)의 경우, 서로 다른 접근 방식을 강제하는 다양성 신호(Diversity signals)를 주입하세요.

6. 목표 이탈 (Goal Drift)

현상: 에이전트가 "JWT 토큰을 사용하도록 인증 모듈을 리팩터링하라"는 작업으로 시작합니다. 8번째 턴(Turn)에 이르면 결제 모듈을 수정하고 있습니다. 12번째 턴에는 데이터베이스 스키마를 다시 작성하고 있습니다. 각 단계는 개별적으로는 논리적이었습니다. 하지만 전체적인 결과는 완전히 벗어났습니다. 어떤 에러도 발생하지 않았습니다. 에이전트가 작성한 코드는 유효합니다. 단지 아무도 요청하지 않은 코드일 뿐입니다.

도구들이 놓치는 이유: 이것은 환각 (Hallucination)이 아닙니다. 에이전트가 무언가를 지어내는 것이 아닙니다. 의도하지 않은 곳으로 이어진 추론 체인 (Chain of reasoning)을 따르고 있는 것입니다. 출력물은 유효한 코드입니다. 가드레일 (Guardrails)은 아무런 문제도 발견하지 못합니다. 오케스트레이터 (Orchestrator)는 각 단계를 정확하게 실행했습니다.

탐지: 의미론적 유사도 (Semantic similarity)를 사용하여 에이전트의 현재 작업과 원래 작업을 비교하세요. 거리가 보정된 임계값 (Calibrated threshold)을 넘어서면 이탈입니다. 이탈은 주관적이기 때문에 가장 어려운 탐지 문제입니다. 이탈처럼 보이는 것이 필요한 우회일 수도 있기 때문입니다. 임계값은 사용자의 재정의 (Overrides)를 통해 학습해야 합니다.

해결책 (Fix): 컨텍스트 주입 (Context injection)을 통해 에이전트를 원래 목표로 다시 유도하세요. 이탈이 지속되면 사람의 검토를 위해 일시 중지하세요. 모든 재정의 (Override) 정보는 탐지 임계값에 피드백됩니다.

7. 개선 격차 (The Improvement Gap)

현상: 모든 실패는 교훈을 줍니다. 그리고 그 교훈은 사람의 머릿속이나 Slack 스레드, 또는 사후 분석 (Post-mortem) 문서에 머뭅니다. 시스템으로 다시 돌아오지 않습니다. 지난주에 너무 느렸던 루프 탐지기 (Loop detector)는 이번 주에도 여전히 너무 느립니다. 지난달에 너무 관대했던 신선도 임계값 (Staleness threshold)은 이번 달에도 여전히 너무 관대합니다. 100번의 세션을 거친 후 당신은 많은 것을 배웠지만, 당신의 하네스 (Harness)는 아무것도 배우지 못했습니다.

도구가 이를 놓치는 이유: 탐지 임계값 (Detection thresholds)은 정적인 설정값입니다. 사고가 발생할 때마다 이를 업데이트하는 사람은 아무도 없습니다. 실패로부터 규칙 개선으로 이어지는 피드백 루프 (Feedback loop)는 전적으로 인간에게 의존하며, 인간은 늘 바쁩니다.

탐지: 이것이 바로 메타 문제 (Meta-problem)입니다. 즉, 실패를 탐지하는 시스템 자체가 실패하는 것입니다. 세션 감사 추적 (Session audit trails)을 수행하십시오. 실패 유형별로 클러스터링 (Clustering)하십시오. 어떤 탐지기가 너무 늦게 작동했는지, 혹은 전혀 작동하지 않았는지 식별하십시오.

해결책: 개선 사이클을 자동화하십시오. 약점 탐색 → 타겟팅된 규칙 수정 제안 → 회귀 테스트 (Regression tests)를 통한 검증 → 회귀 없이 결과가 개선되는 경우에만 적용. 이 메타 하네스 (Meta-harness)는 세션 전반에 걸쳐 지속적으로 실행됩니다. Shanghai AI Lab의 연구 (arXiv:2606.09498)에 따르면, 인간의 개입 없이도 6개의 모델 제품군(Model families)에서 통과율 (Pass rate)이 33-60% 향상됨을 검증했습니다. 이는 이론적인 이야기가 아닙니다.

공통점

이 일곱 가지 실패 사례를 다시 살펴보십시오. 모든 경우에서 다음과 같은 현상이 나타납니다:

• 에이전트가 충돌 (Crash)하지 않았습니다.
• 에러 (Error)가 발생하지 않았습니다.
• 오케스트레이터 (Orchestrator)는 충실히 실행되었습니다.
• 관측성 (Observability) 대시보드에는 피해가 발생한 이후에야 이상 징후가 나타났습니다.

이것이 바로 하네스 엔지니어링 (Harness engineering)이 존재하는 이유입니다. 하네스 엔지니어링은 오케스트레이션 (Orchestration)과 관측성 (Observability) 사이에 위치하여, 실시간으로 동작을 감시하며 그 누구도 묻지 않는 질문을 던집니다: "이 에이전트가 지금 이 순간 올바르게 행동하고 있는가?"

이 일곱 가지 실패를 포착하기 위한 도구들은 이미 존재합니다. 이를 구축하기 위한 원칙들도 알려져 있습니다. 유일한 질문은 당신의 에이전트에 아직 하네스가 있느냐 하는 것입니다.

참조 출처:

https://checkgenai.com/

https://github.com/jalajagrawalgenai/HarnessForge