Gartner는 2027년까지 에이전틱 AI (Agentic AI) 프로젝트의 40% 이상이 중단될 것이라고 예상합니다. 모델이 나쁘기 때문이 아닙니다. 안전망을 구축하지 않았기 때문입니다.

이 통계는 너무 많이 인용되어 이제는 사실상 그 충격이 무뎌졌을지도 모릅니다. 하지만 제 말을 끝까지 들어보세요. 그 통계 속에 숨겨진 이유는 대부분의 팀이 여전히 이야기하지 않고 있는 바로 그것, 즉 **부적절한 리스크 컨트롤 (risk controls)**이기 때문입니다. 비용 문제가 아닙니다. "불분명한 ROI" 문제도 아닙니다. 리스크 컨트롤의 문제입니다.

만약 당신이 핀테크 (fintech)나 헬스텍 (healthtech) 기업을 위해 에이전틱 AI (Agentic AI)를 구축하고 있다면, 이 문구는 다른 어떤 문구보다 당신을 더 걱정하게 만들어야 합니다. 왜냐하면 이것은 데모 (demo)의 문제가 아니라, 프로덕션 (production)의 문제이기 때문입니다. 그리고 규제가 엄격한 환경에서 프로덕션 문제는 예산 검토 단계에서 폐기되는 것이 아니라, 컴플라이언스 (compliance) 검토 단계에서 폐기됩니다.

주요 정의 🧐

이런 일이 왜 발생하는지 알아보기 전에, 명확히 짚고 넘어가야 할 몇 가지 용어가 있습니다.

에이전틱 루프 (agentic loop)란 무엇인가?

에이전트가 답변을 하기에 충분한 정보가 있는지 결정할 때 실행하는 '검색(retrieve) → 평가(evaluate) → 재검색(retrieve-again)' 사이클을 말합니다. 무해하게 들릴 수도 있지만, 대부분의 문제가 시작되는 지점입니다.

증거 무시 (Evidence Override)란 무엇인가?

리트리버 (retriever)가 실제로 올바른 문서를 가져와 모델에게 전달했음에도 불구하고, 모델이 그것을... 제대로 사용하지 않는 상황을 말합니다. 대신 더 익숙한 것에 의존해 버립니다. 증거는 거기 있었지만, 생성 (generation) 단계에서 이를 무시한 것입니다.

연쇄적 환각 (cascading hallucination)이란 무엇인가?

다단계 추론 체인 (multi-step reasoning chain)의 초기 단계에서 발생한 하나의 잘못된 주장이 이후 모든 단계의 "컨텍스트 (context)"가 되는 현상입니다. 각 단계는 이전 단계와 논리적으로 일관성을 유지하기 때문에, 전체 과정이 매우 자신감 있고 일관성 있게 읽힙니다. 비록 두 단계 전부터 이미 틀린 내용이었음에도 말입니다.

두려움은 "작동하지 않는 것"이 아닙니다 😬

솔직히 말해서 실제 두려움은 이것입니다. 에이전트가 틀린 답을 내놓는 것이 아닙니다. 에이전트가 맞아 보이는 틀린 답을 내놓는 것입니다. 형식이 잘 갖춰져 있고, 내부적으로 일관되며, 자신감 넘치는 답 말입니다. 검토자의 눈을 그대로 통과해 버릴 법한 그런 종류의 오답 말입니다.

월요일에 패치로 해결할 수 있는 창피한 버그 수준이 아닌, 규제가 엄격한 환경(regulated environment)에서는 이야기가 다릅니다. 그것은 사고 보고서(incident report) 대상입니다. 감사 지적 사항(audit finding)입니다. 그리고 제대로 된 답변을 내놓지 못해 규제 기관으로부터 질문을 받게 되는 상황입니다.

파일럿(Pilot) 단계는 누군가가 모든 출력물을 면밀히 감시하고 있기 때문에 생존할 수 있습니다. 하지만 프로덕션(Production) 단계는 그런 방식으로 생존할 수 없습니다. 규모(scale)의 문제로 인해 아무도 모든 출력물을 면밀히 감시할 수 없으며, 에이전트(agent)는 "자신감 있게 맞은 것"과 "자신감 있게 틀린 것" 사이의 차이를 내부적으로 구분할 능력이 없기 때문입니다.

모두가 가정하는 실패 vs 실제로 일어나고 있는 실패

대부분의 팀에게 왜 자신들의 RAG 에이전트가 환각(hallucination)을 일으켰는지 물어보면, 거의 매번 "잘못된 검색(bad retrieval)"이라는 답변이 돌아옵니다. 잘못된 청크(chunk)가 추출되었다는 것이죠. 그러면 청킹(chunking)을 수정하고, 임베딩(embeddings)을 수정해서 다시 배포하면 된다고 생각합니다.

하지만 최신 연구에 따르면 그것은 대개 잘못된 진단입니다. 검색 측면의 실패가 아닌 생성 측면의 실패인 증거 무시(Evidence Override)가 실제 검색 실패보다 몇 배나 더 자주 나타납니다. 검색기(retriever)는 제 역할을 다했습니다. 올바른 증거가 컨텍스트(context) 안에 바로 놓여 있었습니다. 단지 모델이 그것에 적절한 가중치를 두지 않았을 뿐입니다.

이 차이는 실제로 매우 중요합니다. 왜냐하면 어떤 유형의 실패냐에 따라 해결책이 완전히 다르기 때문입니다. 검색 실패는 더 나은 청킹으로 해결할 수 있습니다. 하지만 생성 실패는 모델이 전달받은 증거를 가지고 실제로 _무엇을 했는지_를 확인하는 무언가가 필요합니다. 이것은 검색(search)의 문제가 아니라 검증(validation)의 문제입니다.

에이전트는 왜 조용히 실패하고, API는 절대 그러지 않는가 🔗

일반적인 API 호출은 실패할 때 요란하게 드러납니다. 에러가 발생하거나, 타임아웃(timeout)이 나거나, 상태 코드(status code)를 받거나, 스택 트레이스(stack trace)를 받게 되어 무언가 고장 났다는 것을 알 수 있습니다.

반면 에이전틱 루프(agentic loop)는 조용히 실패합니다. 그것은 계속 진행함으로써 실패합니다. 엄격한 중단 규칙(hard stopping rule)이 없다면, "충분한 정보가 있는가?"라는 질문에 대한 기본 답변은 항상 "더 가져와"가 됩니다. 그래서 루프는 다시 검색하고, 단계를 높이고(escalates), 다시 검색하며, 정답에 가까워지지도 못한 채 과정 내내 토큰(tokens)만 태우게 됩니다.

더 심각한 것은, 실수가 누적된다는 점입니다. 초기에 발생한 환각(hallucination) 기반의 주장은 그저 조용히 머물러 있는 것이 아니라, 다음 추론 단계가 구축하는 토대(foundation)가 되어버립니다. 시스템이 잘못 거짓말을 하는 것이 아닙니다. 나쁜 전제(premise)로부터 깨끗하게 추론하고, 자신감 넘치고 틀렸으며 완전히 추적 가능한 것처럼 보이는 결론에 이르게 합니다.

프레임워크 선택은 선호가 아닌 제어 표면입니다 🎲

여기서 여러분이 고르는 도구(tooling)가 실제로 중요하며, 이에 대해서는 솔직하게 이야기할 가치가 있습니다.

CrewAI의 기본 복구 동작(default recovery behavior)은 도구 호출(tool call)에 실패했을 때 동일한 접근 방식으로 재시도하는 것입니다. 이는 여러분이 직접 커스텀 콜백(custom callbacks)을 만들어 멈추게 하지 않는 한 영원히 루프를 돌 수 있습니다.

LangGraph는 다른 경로를 따릅니다. 인터럽트 및 체크포인트(interrupt-and-checkpoint) 모델은 정의된 지점에서 워크플로우를 일시 중지하고, 인간의 결정을 기다린 후 정확한 그 상태에서 재개할 수 있게 해줍니다. 모든 AI 결정에 감사 추적(audit trail)이 필요한 규제 환경에서는 이것이 의미상 훨씬 더 적합합니다.

간단한 복합 예시 🤓

(특정 회사 어느 한 곳의 패턴이 아니라, 클라이언트들 사이에서 반복적으로 보는 패턴을 기반으로 구축했습니다. 명확히 하기 위해서입니다.)

한 헬스케어 기술(healthtech) 수리 에이전트가 들어오는 환자 문서를 분류하고 적절한 내부 시스템으로 라우팅했습니다. 테스트 결과는 좋았습니다. 파일럿 단계에서 높은 정확도를 보였습니다.

하지만 실제 운영 환경에서는, 모호한 문서 유형이

그것이 바로 변화의 핵심입니다. 업계 전체가 지난 2년 가까이 검색 (Retrieval) — 더 나은 청킹 (Chunking), 더 나은 임베딩 (Embeddings), 더 나은 벡터 스토어 (Vector stores) — 에 집착하며 시간을 보냈습니다. 하지만 검색이 문제의 전부는 아니었습니다. 생성 (Generation) 단계와 에이전트(Agent) 자체의 의사결정 루프 (Decision loop) 역시 검색이 이미 받았던 것과 동일한 수준의 정밀한 검토가 필요합니다. 대부분의 아키텍처는 여전히 이 단계에 충분한 주의를 기울이지 않고 있습니다.

해결책: 패치가 아닌 체크포인트 (Checkpoint) 🚀

실제 운영 환경에서 살아남는 패턴은 검색기 (Retriever)와 모델 사이에 임시방편으로 끼워 넣은 단일 검증 인터셉터 (Validation interceptor)가 아닙니다. 그것은 오케스트레이션 그래프 (Orchestration graph) 내에 직접 구축되어, 에이전트가 실제로 중요한 결정을 내리는 모든 지점에 위치하는 체크포인트 (Checkpoint)입니다.

User Query
    │
    ▼
...

첫째, 폴백 (Fallback)이 단순히 "재시도 (Retry)"가 아니라는 점에 주목하십시오. 재시도는 대개 루프를 발생시킨 근본 원인인 경우가 많습니다.

다음으로, 진정한 폴백은 에이전트가 스스로 에스컬레이션 (Escalation)하는 인간 검토 큐 (Human review queue)입니다. 이는 신뢰도 (Confidence)가 임계값 아래로 떨어지거나, 결정이 정의된 정책 경계(Policy boundary)를 넘어서는 경우 — 예를 들어 컴플라이언스 (Compliance)에 민감한 분류, 일정 규모 이상의 트랜잭션, 또는 진단과 관련된 모든 사항 — 에 작동합니다.

마지막으로, 인간 검토자는 에이전트가 본 것과 정확히 동일한 내용을 확인하고, 이를 승인하거나 거부하며, 워크플로 (Workflow)는 해당 체크포인트에서 정확히 재개됩니다. 이는 우연이 아니라, 규제 기관이나 내부 컴플라이언스 팀이 결국 요구하게 될 감사 추적 (Audit trail)을 정확히 제공하는 방식입니다.

이것이 바로 취소 리스크 (Cancellation-risk) 연구에서 반복적으로 나타나는 "역량-배포 검증 격차 (Capability-deployment verification gap)"입니다. 즉, 모든 파일럿 테스트는 통과하지만, 실제 운영 환경이 필요로 하는 에스컬레이션 경로 (Escalation path)를 갖추지 못한 채 구축된 에이전트들을 의미합니다. 격차의 원인은 모델이 아니었습니다. 바로 누락된 체크포인트였습니다. 🔗

귀하의 빌드가 실제로 어디에 위치하는지 확인하십시오 🔍

귀하의 아키텍처에 이러한 체크포인트가 있는지, 아니면 단순히 체크포인트의 탈을 쓴 재시도 루프 (Retry loop)에 불과한지 확신할 수 없다면, 바로 그것이 저희의 **AI 신뢰도 스코어카드 (AI Reliability Scorecard)**가 보여드리고자 하는 핵심입니다.

스코어카드는 다음을 점검합니다:

• 실패가 검색 (Retrieval) 단계에서 발생하는지, 생성 (Generation) 단계에서 발생하는지, 아니면 하류 (Downstream) 단계에서 사람이 알아차릴 때까지 발견되지 않는지
• 에이전틱 루프 (Agentic loops)를 위한 명시적인 중단 규칙 (Stopping rule)이 있는지, 아니면 암시적인 토큰/시간 제한에 의존하며 요행을 바라고 있는지
• 신뢰도가 낮거나 정책 경계 (Policy-boundary)에 걸치는 결정이 실제 인간 검토 큐 (Human review queue)로 에스컬레이션되는지, 아니면 단순히 재시도 (Retry)만 하는지
• 파이프라인 내의 모든 AI 기반 결정이 무엇을 보았고, 무엇을 결정했으며, 무엇이 무시되었는지에 대한 감사 가능한 기록 (Auditable record)을 남기는지
• 현재 아키텍처가 다단계 체인 (Multi-step chains) 전반에 걸쳐 발생하는 연쇄적 환각 (Cascading hallucination)에 얼마나 노출되어 있는지

여기서 확인해보세요: https://www.topiax.xyz/audit

그 이후의 과정: 단일 등급이 아닌, 위의 격차(Gaps)와 직접 매핑된 카테고리별 점수 분석 결과와 함께, 귀하의 특정 스택 및 산업군에서 어떤 실패 모드 (Failure mode)가 가장 큰 프로덕션 리스크인지에 대한 짧은 서면 리포트를 받게 됩니다. 만약 점수가 실제 노출 위험을 나타낸다면, 귀하의 아키텍처에 특화된 체크포인트 패턴 (Checkpoint pattern)을 검토하기 위한 20분간의 통화 초대를 보내드립니다. 제품 소개서 (Pitch deck)는 없습니다. 오직 귀하의 결과와 우리가 가장 먼저 수정해야 할 사항만을 다룹니다.

글을 읽어주셔서 감사합니다. 유익했다면 팀 내에서 "에이전트가 왜 저렇게 행동했지?