✔️ASurvey on AgentOps: Categorization, Challenges, and Future Directions

논문 정보

제목	ASurvey on AgentOps: Categorization, Challenges, and Future Directions
링크	https://arxiv.org/abs/2508.02121
인용수	1
발행일	2025년 8월 4일

 

1 서론 (1 Introduction)

DeepSeek-R1 및 Claude와 같은 기술의 출현으로, 현재 대규모 언어 모델(LLM)의 추론 능력은 지속적으로 향상되고 있습니다. LLM을 강력한 인지 엔진으로 활용함으로써, 기존의 LLM 기반 에이전트 시스템, 특히 다중 에이전트 시스템은 다양한 도구를 갖추었을 때 광범위한 복잡한 작업과 사회 시뮬레이션을 수행할 수 있는 능력을 얻었습니다. 마이크로서비스 아키텍처와 같은 전통적인 시스템과 비교하여, 에이전트 시스템은 더 나은 자동화, 향상된 해석 가능성, 그리고 더 큰 유연성을 제공합니다.

결과적으로, 에이전트 시스템의 연구 및 산업 적용이 번성하고 있으며, 고객 지원 및 추천 시스템과 같은 점점 더 많은 온라인 서비스가 이러한 에이전트 시스템을 채택하고 있습니다. 하지만, 에이전트 시스템의 광범위한 적용에도 불구하고, 결함이 없는 것은 아닙니다. 전통적인 마이크로서비스 시스템과 비교할 때, 에이전트 시스템이 제공하는 더 큰 유연성은 또한 더 많은 이상(anomalies)을 야기합니다. 그림 1에서 보듯이, 작업 실행은 종종 환각(hallucinations)과 같은 문제로 인해 실패합니다. 역할극 시나리오에서는 단일 에이전트에 대한 공격이 전체 시뮬레이션의 붕괴를 초래할 수 있습니다. 따라서, 에이전트 시스템의 보안 및 안정성을 유지하고 추가적인 발전을 촉진하기 위해서는 효율적인 운영 및 유지 관리가 필수적입니다. 이러한 이상들은 불안정성과 불안전성을 초래하여 에이전트 시스템의 추가적인 개발을 저해합니다.

비록 운영 기술이 초기 수동 운영부터 규칙 기반 방법, 그리고 이후 AIOps(Artificial Intelligence for IT Operations)에 이르기까지 시간이 지남에 따라 발전해 왔지만, 에이전트 시스템은 본질적으로 전통적인 시스템과 크게 다릅니다. LLM 기반 에이전트의 행동 특성은 하드 코딩된 전통적인 시스템의 특성과 근본적으로 다릅니다. 주요 차이점은 다음과 같습니다:

1. 에이전트 시스템에서는 더 광범위한 종류의 이상이 발생합니다.
2. 에이전트 시스템은 전통적인 시스템보다 더 높은 관찰 가능성(observability)을 요구하며, LLM과 같은 모듈에 추가적인 주의가 필요합니다.
3. 이상의 다양성으로 인해 에이전트 시스템에서는 이상 감지 및 근본 원인 분석에 통합된 접근 방식을 사용하는 것이 불가능합니다.
4. 에이전트 시스템에서의 해결(Resolution)은 상대적으로 복잡하고 도전적이며, 여러 관점에서의 고려와 반복적인 최적화가 필요합니다.

결과적으로, 전통적인 운영 기술은 에이전트 시스템에 적용하기 어렵기 때문에, 이러한 시스템을 위한 새롭고 맞춤화된 운영 기술이 시급히 요구됩니다. 현재, 에이전트 시스템만을 위한 효과적인 운영 및 유지 관리 전략에 대한 포괄적인 연구가 부족합니다. 대부분의 연구는 에이전트 시스템의 전반적인 운영 문제에 집중하기보다는 고립된 측면에 머물러 있습니다.

예를 들어

• Durante et al.은 에이전트 패러다임과 분류에 대해 설명하고
• Chakraborty et al.은 정의 및 감지 방법을 다루면서 파운데이션 모델의 환각을 깊이 탐구하고
• Deng et al.은 주로 외부 악성 공격을 다루고 위협을 실행 내 보안 및 상호 작용 보안으로 분류하면서 다중 에이전트 시스템의 보안 문제를 탐구하며
• Shi et al.은 GUI 에이전트의 보안 문제와 평가 방법에 대한 상세한 통찰을 제공합니다.

에이전트 시스템의 발전을 더욱 진전시키기 위해, 이 논문은 Agent System Operations(AgentOps)의 개념을 도입합니다. AgentOps는 에이전트 시스템을 위해 특별히 설계된 새로운 운영 및 유지 관리 프레임워크입니다.

첫째, 우리는 에이전트 시스템 내 이상에 대한 정확한 정의를 제공하고, 주로 에이전트 내(intra-agent) 이상과 에이전트 간(inter-agent) 이상으로 분류하며 체계적인 분류를 제시합니다. 이 두 가지 범주는 에이전트 시스템 수명 주기의 사전 실행(pre-execution), 실행(execution), 및 사후 실행(post-execution) 단계를 포괄합니다.

또한, 전통적인 운영 관행에서 영감을 받아, 우리는 에이전트 시스템의 운영 및 유지 관리 프로세스를 네 단계로 나눕니다. 모니터링, 이상 감지, 근본 원인 분석, 및 해결. 각 단계에 대해, 우리는 에이전트 시스템 내에서 발생하는 새로운 도전 과제를 식별하고 상세한 정의와 잠재적인 해결책을 제안합니다. 우리의 지식으로는, 이 작업이 AgentOps의 개념을 체계적으로 제안하고 그 다양한 프로세스의 정의를 표준화하는 첫 번째 작업입니다.

2.1 에이전트 시스템의 정의 (Definition of Agent Systems)

에이전트 시스템은 환경을 인지하고, 결정을 내리며, 행동을 취하고, 궁극적으로 작업을 자율적으로 완료할 수 있는 지능형 시스템을 지칭합니다.

표 1에서 볼 수 있듯이, 이러한 시스템들은 일반적으로 다수의 에이전트로 구성되며 네 가지 핵심 기능을 구현합니다.

대규모 언어 모델(LLM)의 출현과 발전 덕분에, 현대의 에이전트 시스템은 멀티모달 데이터를 이해하고 추론하는 뛰어난 능력과 도구 활용 능력 때문에 이러한 LLM을 기반으로 하는 경우가 많습니다. 따라서, 이 논문은 주로 LLM 기반 에이전트 시스템의 운영에 초점을 맞춥니다.

표 1은 LLM 기반 에이전트 시스템에서 네 가지 핵심 기능이 구체적으로 어떻게 나타나는지를 보여줍니다.

구성 요소 (Componets)LLM 기반 에이전트 시스템 기능방법 (Methods)

상호작용 환경 인지 (Perception of the Interactive Environment)	도구 호출 (Tool Calling)	함수 호출 (Function Call), MCP
자율적 추론 및 의사 결정 (Autonomous Reasoning and Decision-Making)	추론 및 행동 (Reasoning and Act)	ReAct, Reflexion
지식 관리 (Knowledge Management)	단기 및 장기 메모리 (Short & Long Memory)	프롬프트 (Prompt), RAG
다중 에이전트 상호작용 (Multi-Agent Interaction)	에이전트 통신 (Agent Communicating)	A2A, ACP, ANP

 

도구 호출 (Tool Call)에 대한 추가 설명

• LLM 기반 에이전트 시스템은 도구 호출을 사용하여 환경과 상호작용하며, 피드백으로 관찰 데이터를 지속적으로 획득합니다. 이 피드백은 추론 및 의사 결정 프로세스의 자동화를 위한 참고 자료로 사용됩니다.
• 초기에는 도구 호출이 함수 호출을 통해 구현되었는데, 특정 작업에 맞는 함수가 작성되고 그 설명이 포맷팅되어 LLM에 입력되었습니다. 하지만 LLM마다 차이가 있어 포맷팅 등의 정보 조정이 빈번하게 필요했습니다.
• 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)의 등장은 LLM, 외부 데이터 소스, 도구 간의 통신 프로토콜을 표준화하여 이 문제를 근본적으로 해결했습니다.
• MCP의 아키텍처(그림 3)에 따르면, 호스트는 MCP 클라이언트를 통해 MCP 서버와 연결을 설정하고, MCP 서버는 적절한 리소스에 연결하여 필요한 도구를 실행한 후 결과를 클라이언트에게 반환합니다. MCP의 도입은 제공업체가 해당 서비스 API를 개발하는 것을 용이하게 하고 리소스 낭비를 방지합니다.

추론 및 행동 (Reasoning and Act)에 대한 추가 설명

• DeepSeek-R1과 같은 추론 LLM의 출현으로, LLM의 추론 능력은 점점 더 강력해져서 LLM 기반 에이전트 시스템이 의사 결정을 자동화하고 다양한 복잡한 작업을 실행할 수 있도록 충분히 지원하고 있습니다.
• 프롬프트 엔지니어링을 활용하여 LLM의 추론 능력을 효과적으로 사용하여 에이전트 시스템을 향상시키는 여러 방법들이 있습니다.
  • Chain-of-Thought (CoT): 몇 가지 예시를 사용하여 LLM이 단계별로 추론하도록 안내합니다.
  • ReAct: 생각(thought)이 행동(action)에 선행하는 방법을 제안합니다.
  • Reflexion: 일정 시간이 지난 후 전체 추론 경로에 대해 성찰(reflection)할 것을 제안합니다.

단기 및 장기 메모리 (Short & Long Memory)에 대한 추가 설명

• 인간과 마찬가지로, LLM 기반 에이전트 시스템은 토큰 크기 제약으로 인해 지식을 저장하는 능력이 제한적이므로, 효과적인 지식 관리가 필요합니다.
• 단기 메모리는 현재 작업과 밀접하게 연결된 소량의 지식과 관찰 내용으로 구성되며, 일반적으로 프롬프트 엔지니어링을 통해 LLM에 제공됩니다.
• 장기 메모리는 당면한 작업과 즉시 관련이 없을 수 있지만, 작업 실행의 특정 단계에서 필요할 때만 에이전트 시스템에서 사용할 수 있는 대량의 지식을 포함합니다. 장기 메모리는 일반적으로 검색 증강 생성(RAG) 및 벡터 데이터베이스를 사용하여 관리됩니다. 지식은 쿼리 벡터와 지식 벡터 간의 유사성을 기반으로 필요할 때 검색됩니다.

에이전트 통신 (Agent Communicating)에 대한 추가 설명

• 다중 에이전트 시스템에 대한 관심이 증가하고 있음에도 불구하고, 많은 연구들은 일부 시나리오에서 그 성능이 단일 에이전트보다 나을 것이 없음을 지적하며, 이는 에이전트 통신의 중요한 역할을 강조합니다.
• 효율적인 분업과 통신은 이상적으로는 향상된 결과를 가져와야 합니다.
• LLM 에이전트를 위한 통신 표준 및 프로토콜이 제안되었는데, 잘 알려진 것으로 Agent-to-Agent (A2A) 프로토콜이 있습니다. A2A는 각 에이전트의 능력을 체계적으로 정의하기 위해 에이전트 카드(agent card) 개념을 도입하며, 클라이언트 에이전트가 작업과 관련된 모든 에이전트를 효율적으로 관리할 수 있도록 합니다. Agent Communication Protocol (ACP) 및 Agent Network Protocol (ANP)과 같은 다른 프로토콜도 존재합니다.

2.2 TaxonomyofAgent Systems

LLM에 의해 구동되는 에이전트 시스템 연구에서, 에이전트 시스템에 대한 근본적인 분류는 참여하는 에이전트의 수를 기준으로 이루어질 수 있습니다. 그림 4(Figure 4)에 나타난 바와 같이, 에이전트 시스템은 단일 에이전트 시스템(Single-Agent Systems, SAS)과 다중 에이전트 시스템(Multi-Agent Systems, MAS)으로 나뉩니다.

 

1. 단일 에이전트 시스템 (Single-Agent Systems, SAS)

SAS는 단일 LLM 기반 에이전트를 중심으로 하며, 이 에이전트가 핵심 처리 장치 역할을 합니다.

이러한 시스템들은 일반적으로 다음 유형의 작업에 사용됩니다.

• 추론 (Reasoning): 에이전트가 내장된 지식 또는 문맥적 단서를 활용하여 논리적 또는 수학적 추론, 그리고 인과적 추론을 수행합니다. 예를 들어, AI Scientist는 개방형 추론 프로세스를 통해 자동화된 과학적 발견을 탐구합니다.
• 대화 (Conversation): 에이전트가 대화 상태를 유지하고, 사용자 의도를 해석하며, 의미적으로 일관된 응답을 생성합니다. 대화 작업은 텍스트 상호작용을 넘어 이미지, 오디오, 비디오를 포함하는 다중 모달 통신도 포함합니다 (예: GPT-4o).
• 상호작용 (Interaction): 에이전트가 정보를 교환하거나 행동을 실행함으로써 비교적 단순하고 예측 가능한 외부 환경과 직접적으로 상호작용합니다. 대표적인 예로, WebArena에서 에이전트가 구조화된 웹 인터페이스와 상호작용하는 경우를 들 수 있습니다.

2. 다중 에이전트 시스템 (Multi-Agent Systems, MAS)

MAS는 공유 환경 내에서 작동하는 다수의 LLM 기반 에이전트로 구성됩니다. 이 에이전트들은 서로 협력하거나 경쟁할 수 있습니다. MAS는 분산되거나, 동시적이거나, 전략적으로 복잡한 문제에 특히 적합하며, 이는 단일 에이전트 시스템에게는 어려운 문제입니다.

일반적인 MAS 애플리케이션은 다음과 같습니다

• 역할극 및 시뮬레이션 (Role-Playing and Simulation): 에이전트에게 특정 정체성, 배경 및 행동 규칙이 할당되며, 미리 정의된 프레임워크 내에서 역할에 일관된 방식으로 상호작용합니다. 이러한 시뮬레이션은 미시적 상호작용에서 발생하는 사회 역학, 경제 시스템, 전염병 확산과 같은 거시적 수준의 현상 연구를 가능하게 합니다. 예를 들어, 지정학적 갈등을 시뮬레이션하는 WarAgent와 거시경제 활동을 모델링하는 EconAgent가 있습니다.
• 협력 및 공동 작업 (Cooperation and Collaboration): 다수의 에이전트가 공통 목표 또는 부분적으로 일치하는 목표를 공유하며, 작업 분해, 협상 및 정보 교환을 통해 목표를 달성합니다. 예를 들어, ChatDev에서 에이전트들은 코드 생성 및 디버깅에 공동으로 기여합니다.
• 게임 이론적 상호작용 (Game-Theoretic Interaction): 목표가 잠재적으로 상충될 수 있는 시나리오에서, 에이전트는 다른 에이전트의 전략을 자신의 의사 결정 과정에서 고려해야 합니다. 여기에는 경매, 다중 에이전트 협상, 제로섬 게임과 같은 경쟁, 협상, 인센티브 메커니즘 설계 요소가 포함됩니다.

3. 분류 선택 및 고려 사항

MAS는 종종 향상된 성능으로 전통적인 SAS 작업을 수행할 수 있습니다. 그러나 이는 시스템 복잡성 증가, 잠재적인 출현적 오류(emergent failures) 발생, 그리고 더 높은 유지보수 오버헤드를 대가로 합니다. 따라서 SAS와 MAS 중 어떤 것을 선택할지는 대상 애플리케이션 도메인의 특정 요구 사항과 제약 조건에 기반하여 결정되어야 합니다.

 

3 에이전트 시스템의 이상 (Anomalies in Agent Systems)

3.1에이전트 시스템의 이상 정의 (Definition of Anomalies in Agent Systems)

이전 논의에서는 다양한 유형의 에이전트 시스템에서 성공률이 특별히 높지 않다는 점을 강조했으며, 이는 작업의 성공적인 완료를 방해하는 수많은 예외(exceptions)가 존재함을 시사합니다.

 

Who&When에 따른 초기 정의

Who&When에 따르면, 이러한 시스템 내의 이상은 주로 작업 실행 중 특정 단계에서 주로 발생한다고 가정합니다. 공식적으로, 만약 어떤 특정한 이상 단계에 개입하여 그 단계를 정상 단계로 전환시키고($g(\sigma, i)$), 그로 인해 작업이 성공적으로 완료되도록($f(g(\sigma, i)) = 1$) 보장한다면, 해당 단계가 이상 단계로 식별될 수 있습니다.

이를 공식적으로 표현하면 다음과 같습니다: 작업의 실행 궤적(trajectory)이 $\sigma = (s_0, a_1, s_1, \dots, a_t, s_t)$ 라고 가정합니다. 여기서 $s_i$는 에이전트 시스템의 상태를 나타내고, $a_i$는 특정 행동을 나타냅니다. 함수 $f(\sigma)$는 궤적 $\sigma$가 작업을 성공적으로 완료하는지 여부를 1(성공) 또는 0(실패)으로 나타내며, 함수 $g(\sigma, i)$는 특정 단계 $a_i$를 정상 단계로 수정한 것을 나타냅니다. 만약 $f(\sigma) = 0$ 이고 $f(g(\sigma, i)) = 1$이라면, $i$번째 단계가 이상 단계로 식별됩니다.

 

확장된 정의

그러나 이 정의는 상당히 제한적입니다. 전통적인 마이크로서비스 시스템은 일반적으로 장기간 안정적으로 실행되며 사전 실행(pre-execution) 및 사후 실행(post-execution) 단계를 고려할 필요가 없습니다. 이와 대조적으로, 에이전트 시스템의 작업 실행은 사전 실행 프롬프트와 강하게 연관되어 있으며, 사후 실행 완료가 성공적이라고 해서 이상이 발생하지 않았다는 것을 의미하지는 않습니다 (추론 환각(reasoning hallucinations) 등이 여전히 부정확한 답변을 제공할 수 있기 때문입니다).

따라서, 그림 5에 나타난 바와 같이, 우리는 에이전트 시스템의 이상을 사전 실행, 실행, 또는 사후 실행 단계 동안 발생하는 모든 이벤트로 정의하며, 이는 작업 중단이나 효과적인 완료 실패로 이어집니다. 에이전트 시스템의 이상 발생 단계는 다음을 포함합니다:

 

① 사전 실행 (Pre Execution): 작업 명세(Task Specification), 구성(Configuration) 등.

② 실행 (Execution): 추론 이상(Reasoning Anomalies), 계획 이상(Planning Anomalies) 등.

③ 사후 실행 (Post Execution): 조기 종료(Premature-Stop), 멈추지 않는 작업(Unstoppable) 등.

 

이상 분류 (Taxonomy) 도입

이러한 정의에 비추어 볼 때, 우리는 에이전트 시스템의 이상에 대한 새로운 분류 방법을 제안합니다. 앞서 논의했듯이, 에이전트 시스템은 단일 에이전트 시스템과 다중 에이전트 시스템으로 분류될 수 있습니다. 결과적으로, 이상은 단일 에이전트 내부에서 발생하거나 다수의 에이전트 간 상호 작용 중에 발생할 수 있습니다. 이는 전통적인 서비스 아키텍처에서 이상이 단일 서비스의 내부 프로세스 내에서 발생하거나 서비스 간 통신 중에 발생할 수 있다는 점과 유사합니다. 따라서, 그림 6에 묘사된 바와 같이, 우리는 모든 이상을 두 가지 유형으로 분류합니다

1. 에이전트 내 이상 (Intra-Agent Anomalies): 주로 단일 에이전트 내부의 문제에 초점을 맞춥니다. 일반적으로 에이전트가 하위 작업을 수행하는 동안 발생할 수 있는 다양한 오류를 다룹니다.
2. 에이전트 간 이상 (Inter-Agent Anomalies): 개별 에이전트를 넘어 다른 에이전트 간의 상호 작용뿐만 아니라 전체 시스템의 보안, 안정성 및 작업 실행에 초점을 맞춘 전역적인 관점에서 검토됩니다.

이러한 이상들은 발생하는 단계에 따라 에이전트 내 이상은 추론 이상, 계획 이상, 행동 이상, 메모리 이상, 환경 이상으로 더 분류될 수 있으며, 에이전트 간 이상은 작업 명세 이상, 보안 이상, 통신 이상, 신뢰 이상, 출현적 행동 이상, 종료 이상으로 분류될 수 있습니다.

3.2 Intra-Agent Anomalies

3.2.1 추론 이상 (Reasoning Anomalies)

에이전트는 인지 시스템을 사용하여 추론을 수행하며, 이는 후속 행동을 안내하고 복잡한 작업을 완료하는 기초가 됩니다. 이러한 기술적 지원에도 불구하고, 추론 과정에서는 이상 현상이 자주 발생하며, 그중 가장 두드러진 것은 환각(Hallucinations)입니다.

 

환각의 정의 및 특성

• 환각은 알려진 사실과 모순되는 신뢰할 수 없는 텍스트를 생성하는 것을 의미합니다.
• 환각은 원래의 프롬프트와 무관한 콘텐츠를 응답으로 생성하는 것으로 간주되기도 합니다.
• Chakraborty et al.은 환각의 네 가지 주요 특성으로 규정 준수(compliance), 바람직성(desirability), 관련성(relevancy), 그리고 그럴듯함(plausibility)을 식별합니다.
• Yang et al.은 환각을 불확실한 답변을 부적절한 자신감을 가지고 제공하는 부정직함(dishonesty)의 한 형태로 설명합니다.
• 요약하자면, 환각은 정상적인 논리와 사실에 모순되는 비정상적인 상상이며, 현재 LLM 사용에서 피할 수 없는 현상으로 여겨집니다.
• 발생 원인: LLM은 대규모 데이터셋으로 훈련되어 훈련 데이터에 민감하며, 지식 망각(knowledge forgetting)에 취약합니다. 또한, 훈련된 LLM은 자연계에서 끊임없이 발생하는 새로운 지식으로 업데이트될 수 없어, 오래된 정보 문제를 일으키기도 합니다.

3.2.2 계획 이상 (Planning Anomalies)

자율적인 계획 및 도구 호출은 에이전트 시스템의 핵심 기능이지만, 현재 LLM의 확률론적 특성(probabilistic nature)으로 인해 이상 현상은 불가피하며, 이는 주로 계획 단계에서 발생하는 환각에서 기인합니다.

• 유형 및 예시
  • Park et al.은 환각을 부정확한 행동 실행 가능성을 예측하는 것으로 설명합니다.
  • Kwon et al.은 LLM이 이전 추론과 일관성 없는 행동을 자주 생성한다고 관찰합니다.
  • Wang et al. 및 Ren et al.은 LLM과 같은 생성 모델이 비합리적이고 부정확한 계획을 생성하는 경향이 높다고 주장합니다.
  • Hu et al.은 계획 환각이 부정확한 도구나 매개변수와 같은 존재하지 않는 엔티티와 상호 작용하는 것을 포함한다고 설명합니다.
• 결과: 계획 이상은 작업 계획 단계에 중대한 영향을 미치며, 종종 작업 실패를 유발하므로 상당한 주의가 필요합니다.

3.2.3 행동 이상 (Action Anomalies)

행동 이상은 주로 비표준적이거나 일관성 없는 인터페이스와 같은 문제로 인해 발생하기 쉽습니다.

• 함수 호출 관련 문제: 초기에는 행동이 함수 호출을 통해 구현되었는데, WANG et al.은 API 호출 지연, 부정확한 API 선택, 시스템 장애와 같은 문제를 강조했습니다. 또한, Wu et al.은 공격자가 LLM이 민감한 기능을 호출하거나 제한을 우회하도록 특정 요청을 조작하는 "탈옥(jailbreak)" 위험을 지적했습니다.
• MCP 관련 문제: 모델 컨텍스트 프로토콜(MCP)의 등장으로 LLM과 도구 간의 상호 작용이 표준화되었지만, 실제 응용 프로그램에서 MCP 서버의 구성 변경이 자주 행동 이상을 초래하는 경우가 있습니다.

3.2.4 메모리 이상 (Memory Anomalies)

에이전트의 메모리는 단기 메모리와 장기 메모리로 나뉘며, 각기 다른 유형의 이상을 겪습니다.

• 단기 메모리 (컨텍스트) 이상
  • 단기 메모리는 LLM의 컨텍스트를 의미합니다. LLM 컨텍스트가 확장됨에도 불구하고, 여전히 작업 요구 사항을 충족하지 못하는 경우가 많습니다.
  • 컨텍스트 관리를 위해 슬라이딩 윈도우를 사용하면 작업 완료 지침과 같은 중요한 초기 정보가 손실될 수 있습니다.
  • Liu et al.은 컨텍스트 크기가 충분하더라도 LLM이 긴 컨텍스트 중간에 있는 정보를 간과하는 "Lost in the Middle" 문제를 겪을 수 있으며, PI-LLM은 LLM의 작업 메모리(working memory)에 병목 현상이 있음을 시사합니다.
• 장기 메모리 (RAG) 이상
  • 장기 메모리는 RAG(Retrieval-Augmented Generation)를 사용하여 검색되는 지식을 의미합니다.
  • 검색 정확도와 생성 신뢰성 측면에서 많은 한계가 있습니다.
  • QE-RAG는 기존 RAG 구현이 노이즈에 매우 민감하다고 지적하며, Astute RAG는 내부 지식과 외부 지식 간의 충돌이 궁극적으로 RAG 환각을 초래할 수 있다고 강조합니다.
  • Chen et al.은 많은 기술 지원에도 불구하고 현재 RAG 시스템의 정확도가 높지 않다고 지적합니다.

3.2.5 환경 이상 (Environment Anomalies)

에이전트 시스템의 규모가 계속 확장됨에 따라 상당한 리소스 소모가 발생하며, 에이전트가 리소스 집약적인 작업을 로컬에서 실행할 때 환경 관련 이상이 발생할 수 있습니다. 여기에는 자원 부족이나 과도한 CPU 사용량과 같은 문제가 포함됩니다.

3.3 에이전트 간 이상 (Inter-Agent Anomalies)

3.3.1 작업 명세 이상 (Task Specification Anomalies)

작업 명세 이상은 주로 불분명한 작업 정의나 잘못된 에이전트 역할 구성에서 기인하는 실패를 말하며, 이는 사전 실행(pre-execution) 단계에서 발생합니다.

• 불명확한 작업 정의: Cemri et al.은 불충분하게 명확한 프롬프트와 같은 불분명한 작업 정의가 많은 작업 수준 실패의 원인이라고 지적합니다. Altmann et al.은 작업이 불완전하게 정의되면, 개별 에이전트의 행동이 비교적 합리적일지라도 추격(chasing) 및 차단(blocking)과 같은 상황이 쉽게 발생할 수 있다고 강조합니다.
• 일탈 및 공모: SentinelAgent는 작업 설명이나 프롬프트가 잠재적인 협업 모드를 충분히 다루지 못하면, 에이전트들이 일탈(deviate)하거나, 공모(collusion)하거나, 프롬프트 인젝션과 같은 예기치 않은 행동을 보일 수 있다고 언급합니다. 따라서 사전 실행 단계에서 작업 설명의 완전성을 평가하고 실행 단계에서 이를 반영하는 것이 필수적인 운영 단계입니다.
• 잘못된 구성: 부정확한 에이전트 역할 구성은 가장 흔한 이상 중 하나입니다. Platon et al.은 불분명한 구성과 역할 혼동이 조정 실패(coordination failures)와 적대적 오정렬(adversarial misalignments)의 빈번한 원인이라고 지적합니다. OG에 따르면, 에이전트가 지정된 책임 범위를 벗어난 행동을 수행할 때, 이는 직접적으로 충돌, 비일관성, 비효율성을 초래합니다. AgentFM은 데이터베이스 에이전트의 경우 모호한 역할 구성이 일반적인 실패 원인이라고 언급합니다.

3.3.2 보안 이상 (Security Anomalies)

에이전트 간 통신을 표준화하기 위해 A2A 및 ACP와 같은 프로토콜이 개발되었지만, 이는 프로토콜의 전반적인 보안을 해결하지는 못합니다.

• 악성 공격: Frost et al.은 실제 에이전트 시스템에서 일부 에이전트가 악성 공격을 받아 DDoS 공격과 유사하게 요청이나 메시지를 자주 보내게 될 수 있다고 언급합니다.
• 공격 대상: He et al.은 그림 7에 제시된 바와 같이, 에이전트 시스템을 목표로 하는 구체적인 공격 방법들이 에이전트 자체와 에이전트 간 통신 모두를 공격할 수 있다고 제안합니다.

3.3.3 통신 이상 (Communication Anomalies)

통신 이상은 에이전트 간 메시지 교환 중에 자주 발생합니다.

• 메시지 스톰: Bronsdon은 과도한 메시징으로 인해 메시지 스톰(message storms)이 발생할 수 있으며, 이는 리소스 고갈과 지연 증가를 유발하여 궁극적으로 작업 실패를 초래한다고 언급합니다.
• 메시지 중복: AgentPrune은 메시지 중복(redundancy) 문제를 식별하며, 과도한 수의 메시지는 에이전트 시스템의 효율성을 높이지 못하고, 오히려 에이전트가 혼란을 느끼게 하는 원인이 된다고 지적합니다.

3.3.4 신뢰 이상 (Trust Anomalies)

신뢰 이상은 LLM 에이전트가 들어오는 모든 메시지를 동등하게 취급하는 데서 비롯됩니다.

• 검증 부재: ATrust는 A2A 통신이 증가함에 따라 메시지의 신뢰성 평가 필요성이 커지고 있음을 지적합니다. He et al.은 LLM 에이전트가 다른 에이전트로부터의 메시지를 일관성 검증 없이 수락하고 컨텍스트에 통합하며, 그 메시지가 신뢰할 수 있는지 여부를 고려하지 않는다고 강조합니다.
• 능력 차이: 다른 에이전트들은 기초 모델이나 메모리 등의 차이로 인해 특정 영역에서 능력 차이가 현저할 수 있습니다 (예: 코드 에이전트의 프로그래밍 능력이 일반 에이전트보다 훨씬 강함).
• 결과: 모든 에이전트의 메시지를 맹목적으로 신뢰하면 정보 충돌이나 오류가 발생할 수 있습니다. 반대로, 아무도 신뢰하지 않으면 시스템은 협업 능력을 상실하여 협력 효율성에 막대한 영향을 미치게 됩니다.

3.3.5 출현적 행동 이상 (Emergent Behavioral Anomalies)

이러한 이상은 여러 에이전트 간의 복잡한 상호 작용에서 발생하는 거시적인 패턴 또는 행동을 말합니다.

• 정의: Sanjeev는 출현적 행동이 여러 에이전트 간의 상호 작용에서 발생하며, 개별 에이전트를 고립적으로 분석할 때는 예측하거나 쉽게 설명할 수 없는 시스템 수준의 행동을 초래한다고 제안합니다. Bronsdon은 이 이상이 어떤 단일 에이전트의 행동만으로는 설명할 수 없다고 주장합니다.
• 현재 상태: 출현적 행동 이상은 비교적 덜 이해된 이상 유형이지만, 심각한 결과를 초래할 수 있습니다.

3.3.6 종료 이상 (Termination Anomalies)

종료 이상은 작업이 너무 일찍 끝나거나 무한 루프에 빠지는 형태로 나타납니다. 조기 종료(Premature-stop)는 에이전트 시스템의 중요한 이상 범주로 간주됩니다.

• 조기 종료: Smurfs는 단일 에이전트 모드에서 DFSDT(Deep First Search Decision Tree)가 조기 종료 문제를 자주 겪는다고 지적하는데, 시스템이 다단계 추론을 완료하지 않고 너무 빨리 종료 도구를 호출하는 경우 발생합니다. Zhang et al.은 조기 종료가 다중 에이전트 시스템에서 흔하고 정확하게 위치를 파악할 수 있는 실패의 원인으로 식별된다고 언급합니다. 이 문제는 복잡한 작업의 완전성과 논리적 일관성에 심각한 영향을 미칠 수 있습니다.
• 무한 루프: Zhu et al.은 에이전트가 작업을 하위 에이전트에게 지속적으로 위임하여 무한 재귀 체인을 생성하고 결국 재귀 깊이 제한이나 시간 초과에 도달하게 하는 "Undercommitment anomalies"를 식별합니다. Drake는 에이전트가 끝없는 재귀 또는 자기 최적화 루프에 갇혀 끝점을 찾지 못하는 "신경성 하울라운드(neural howlround)" 개념을 도입했습니다. 이 현상은 시스템을 정체시키거나 "인지적 정체(cognitive stagnation)"를 유발하는 끝없는 재귀 루프인 "지속적 사고(perseverative thinking)"로 이어질 수 있습니다.

4 AgentOps:Agent System Operations

이름 (Name) / 정의 (Definition)

DevOps	소프트웨어 개발 라이프사이클을 단축하고 고품질 소프트웨어를 제공하기 위해 소프트웨어 개발(software development)과 IT 운영(IT operations)을 병합합니다.
AIOps	IT 운영을 자동화하기 위해 기계 학습(machine learning)을 사용합니다.
MLOps	기계 학습 모델의 유지 관리 및 관리를 위해 다양한 운영 기술을 적용하는 것을 의미합니다.
AgenticOps	전통적인 시스템의 운영 및 유지 관리를 위해 에이전트를 사용하는 것을 의미합니다.
AgentOps	에이전트 시스템의 관리 및 유지 관리를 위해 다양한 운영 기술을 사용하는 것을 의미합니다.

 

4.1 운영의 진화 (Evolution of Operations)

운영 기술은 시간이 지남에 따라 지속적으로 발전해 왔습니다 [44, Figure 8]. 초기 수동 운영부터 규칙 기반 자동 운영에 이르기까지, 각 단계는 상당한 진전을 이루었습니다. 특히 기계 학습, 그리고 딥러닝의 급속한 발전은 운영 기술의 발전을 더욱 가속화했습니다. 최근 몇 년 동안, LLM의 강력한 추론 및 분석 능력은 LLM 에이전트를 활용한 자동화된 운영 방법을 증가시켰습니다.

운영 기술의 진화 외에도, 운영의 대상 또한 변화했습니다 [46, Figure 8]. 초기에는 운영이 마이크로서비스 시스템과 같은 전통적인 하드웨어 및 소프트웨어 시스템에만 초점을 맞추었습니다. 기계 학습의 급속한 발전과 함께, 모델의 규모가 커지고 훈련 및 추론과 같은 프로세스에서 결함이 더 자주 발생함에 따라, 기계 학습 모델을 관리하기 위한 운영 기술인 MLOps의 적용 필요성이 생겼습니다. 최근 몇 년 동안, LLM 에이전트가 작업을 자율적으로 완료할 수 있게 되면서, 많은 서비스가 에이전트를 대체재로 채택하고 있습니다. 그 결과, 에이전트 시스템은 오늘날 업계에서 서비스 구축을 위한 주류 방법이 되었습니다.

그러나 에이전트 시스템은 전통적인 시스템과 현저하게 다릅니다. 전통적인 시스템은 기본 코드에 의해 지시되는 결정론적 행동(deterministic behaviors)을 특징으로 하는 반면, 에이전트는 확률론적 모델 기반으로 인해 추론과 행동에서 확률적 특성(stochasticity)을 보입니다. 따라서, 에이전트 시스템 관리에 관련된 운영은 전통적인 시스템과 크게 다르며, 전통적인 기술을 에이전트 시스템에 직접 적용하는 것은 비실용적입니다. 이것이 바로 AgentOps를 제안하는 이유입니다.

4.2 전통적인 시스템 운영과 에이전트 시스템 운영 간의 차이점 (Difference between Traditional System Operations and Agent System Operations)

산업계에서는 일반적으로 운영을 네 단계로 나눕니다.

• 모니터링 (Monitoring): 시스템의 실행 시간 데이터를 가능한 한 포괄적으로 수집하여 이상 감지와 같은 후속 프로세스를 지원합니다.
• 이상 감지 (Anomaly Detection): 시스템 장애 발생 시, 모니터링 데이터를 사용하여 신속하게 이상을 감지하고 실패의 전파를 막습니다.
• 근본 원인 분석 (Root Cause Analysis, RCA): 문제 발생 시 여러 구성 요소에서 경고가 발생할 수 있는데, 근본 원인 분석을 통해서만 근본적인 원인을 식별하여 문제를 신속하게 해결할 수 있습니다.
• 해결 (Resolution): 근본 원인이 식별되면 SRE(Site Reliability Engineer)에게 알리거나 자동화된 복구 방법을 사용하여 문제를 해결합니다.

전통적인 시스템 운영과 에이전트 시스템 운영은 유사한 타임라인을 공유하지만, 각 단계에서 크게 다릅니다 [48, Figure 9]. 이러한 차이 때문에 새로운 운영 프레임워크인 AgentOps가 필요합니다.

• 모니터링: 주요 차이점은 모니터링 데이터의 유형입니다. 전통적인 시스템 운영은 주로 메트릭, 로그, 트레이스에 초점을 맞추지만, 에이전트 시스템에서는 서비스가 LLM 에이전트에 의해 제공되므로 LLM 에이전트의 관련 모듈에 대한 추가 모니터링이 필수적입니다.
  • LLM 측면에서는 모델 매개변수, 어텐션 맵, 토큰 로짓 등 관련 상태를 모니터링합니다.
  • 에이전트 측면에서는 메모리 및 환경과 같은 체크포인트를 단계별로 모니터링하는 것이 필수적입니다. 이러한 에이전트 수준의 체크포인트 모니터링은 에이전트 시스템의 상태를 명확히 이해하게 할 뿐만 아니라, 강력한 조작성 덕분에 전통적인 시스템과 달리 롤백(rollback) 작업을 용이하게 하는 중요한 이점을 제공합니다.
• 이상 감지: 차이점은 주로 이상 감지의 적용 시점에 있습니다. 결정론적 시스템에 적용되는 전통적인 시스템 운영은 데이터가 일반적으로 정확하고 신뢰할 수 있다고 간주하여 데이터를 직접 입력으로 사용합니다. 이와 달리, 에이전트 시스템은 LLM 에이전트를 통해 데이터가 생성되므로 정확성이 보장되지 않습니다. 따라서 이상 감지는 데이터 생성의 합리성을 검증하는 것 외에도 이 데이터를 사용하여 시스템의 상태를 평가해야 합니다.
• 근본 원인 분석: 차이점은 주로 로컬라이제이션(localization)의 대상과 세분성에 있습니다. 전통적인 RCA는 서비스, 파드, 환경 수준 또는 코드를 식별하는 데 중점을 둡니다. 에이전트 시스템에서는 LLM 에이전트의 개입으로 인해 로컬라이제이션이 에이전트의 특정 행동이나 LLM 프로세스의 특정 단계에서의 환각을 식별하는 데까지 영역이 확장될 수 있습니다.
• 해결: 주요 차이점은 해결 프로세스에 있습니다. 전통적인 시스템 운영에서, 고장 지점과 원인이 알려지면 관련 도메인 지식 기반의 결정론적 절차를 사용하여 신속하게 문제를 해결할 수 있습니다. 그러나 에이전트 시스템에서는 내재된 무작위성으로 인해 해결 프로세스가 장기간에 걸쳐 복잡하며, 지속적인 테스트와 모니터링 단계의 관련 데이터를 활용한 롤백을 통해 궁극적으로 최적의 상태에 도달해야 합니다. 예를 들어, 근본 원인이 불합리한 프롬프트인 경우 지속적인 A/B 테스트를 통한 프롬프트 최적화가 필요할 수 있습니다.

4.3 결론 (Conclusion)

위에서 언급된 차이점들에 기반하여, 우리는 Agentic System Operations (AgentOps)를 사전 실행, 실행, 사후 실행 단계를 포괄하는 포괄적인 운영 프레임워크로 정의합니다. AgentOps는 전통적인 시스템 운영과 마찬가지로 모니터링, 이상 감지, 근본 원인 분석, 해결의 네 단계를 포함합니다.

AgentOps와 전통적인 시스템 운영(예: AIOps) 간의 근본적인 차이는 운영 주체의 특성에 있으며, 이러한 주체의 차이는 모든 단계에서 중요한 차이를 유발하며, 각 단계에서 새로운 기술 솔루션을 필요로 합니다.

5 에이전트 시스템 모니터링 (Monitoring Agent System)

5.1 모니터링 데이터의 설명 (Illustration of Monitoring Data)

5.1.1 전통적인 데이터 (Traditional Data)

전통적인 모니터링 데이터에서는 OpenTelemetry를 사용하여 수집된 메트릭, 로그, 그리고 추적(traces)이 마이크로서비스 시스템과 에이전트 시스템 모두에 존재합니다. 그러나 앞서 언급했듯이, 에이전트 시스템의 데이터는 마이크로서비스 시스템의 데이터와 상당히 다릅니다.

 

메트릭 (Metrics): 첫째, 표 4에 나타난 바와 같이, 전통적인 마이크로서비스 시스템은 일반적으로 시스템 메트릭(예: CPU 사용량, 메모리 사용량, 네트워크 RTT)과 APM(Application Performance Monitoring) 메트릭(예: 요청 수, 클릭률, 전환율) 모니터링에 중점을 둡니다. 그러나 LLM 에이전트를 통합하는 에이전트 시스템의 맥락에서는, LLM 지연 시간 및 도구 호출 지연 시간과 같은 LLM 및 에이전트 관련 추가적인 메트릭이 도입됩니다. 더욱이, 비용이 에이전트 시스템에서 중요한 요소이므로, 사용된 토큰 수나 작업 완료당 API 호출 비용과 같은 다양한 비용 관련 메트릭도 포함됩니다. 현재 수직 산업 애플리케이션에서 RAG(검색 증강 생성)는 필수적이므로, 청크 정확도 및 문서 회수율과 같은 RAG 관련 메트릭 역시 필요합니다.

 

추적 (Traces): 추적과 관련하여, 그림 10에서 보듯이, 마이크로서비스 추적은 일반적으로 API 호출을 통한 서비스 간 상호 작용을 의미합니다. 이러한 API 호출의 매개변수는 사용자 행동이나 사전 정의된 시스템 규칙에 의해 결정되므로, 상대적으로 안정적이고 간단합니다. 그러나 에이전트 시스템에서는 각 에이전트의 입력 및 출력, 그리고 에이전트 간 상호 작용(에이전트-도구 호출 포함)이 종종 LLM에 의해 생성되어 높은 불확실성을 초래합니다. 이러한 불확실성은 추적 데이터의 핵심 요소입니다. 따라서, 에이전트 시스템의 추적은 에이전트와 도구 간의 관계뿐만 아니라 각 단계의 입력 및 출력까지 포괄합니다. 결과적으로, 추적 데이터는 에이전트 시스템의 가장 중요한 측면입니다.

 

로그 (Logs): 로그의 경우, 그림 11에서 보듯이 마이크로서비스 시스템과 에이전트 시스템은 상당히 유사합니다. 마이크로서비스 시스템의 로그는 서비스의 전반적인 행동을 기록하는 반면, 에이전트 시스템에서는 에이전트의 행동을 포착합니다.

5.1.2 모델 데이터 (Model Data)

데이터 보안 우려가 계속 증가함에 따라, 점점 더 많은 온라인 에이전트 시스템이 로컬에 배포된 오픈 소스 LLM을 추론 엔진으로 사용하기로 선택하고 있습니다. LLM을 내부 상태를 고려하지 않는 순수한 블랙박스 모델로 취급하면, 관찰할 수 있는 정보가 입력과 출력으로 제한적입니다. 이 정보는 LLM 자체 내에서 발생하는 이상을 감지하기에는 불충분합니다. 결과적으로, 화이트박스 모델로 LLM을 취급하여 히든 레이어 및 토큰 로짓과 같은 내부 매개변수를 수집하는 접근 방식이 증가하고 있습니다.

5.1.3 체크포인트 데이터 (Checkpoint Data)

마이크로서비스 시스템과 비교하여, 에이전트 시스템은 더 큰 제어력을 제공하여, 주어진 순간의 상태를 데이터로부터 재현(reproduced)할 수 있게 합니다. 이는 에이전트 시스템 운영에 상당한 이점을 제공합니다. 그림 12에서 보듯이, 우리는 메모리 환경과 같은 체크포인트 정보를 포함하여 에이전트 시스템의 상태를 다양한 시점에서 기록할 수 있습니다. 시스템 장애가 발생하면, 이러한 체크포인트 데이터는 이전 상태로 롤백(roll back)하고, 문제를 해결하며, 궁극적으로 정확한 결과에 도달할 수 있도록 합니다.

5.2 현재 모니터링 방법 (Current Monitoring Methods)

LLM 기반 에이전트 시스템을 위한 관찰 가능성 도구는 빠르게 발전하고 있습니다. 이러한 도구들은 앞서 언급된 메트릭, 로그, 추적 데이터 수집 원칙을 주로 따릅니다.

대부분의 에이전트 시스템 관찰 가능성 도구들은 추적, 메트릭, 데이터셋, 실험, 평가, 프롬프트 최적화 및 관리와 같은 기능들을 통합합니다. 표 5는 다양한 도구들의 기능을 비교합니다.

• LangDB: Rust로 완전히 개발된 최초의 관찰 가능성 도구이며, 비용 통제를 위한 라우터 최적화와 내부적으로 통합되어 더 높은 효율성을 제공합니다.
• Langfuse: OpenTelemetry 통합을 지원하며 오픈 소스 커뮤니티에서 가장 활발한 관찰 가능성 도구입니다.
• Helicone: 관찰 가능성 외에도 캐시 관리를 통합하여 지연 시간을 줄이고 리소스를 절약하며, 게이트웨이 폴백과 같은 메커니즘을 통해 보안 및 확장성을 보장합니다.
• HoneyHive: 분산 추적을 사용하며 멀티모달 시스템을 효과적으로 처리하고 특정 시스템 측면에 초점을 맞추기 위해 사용자 정의 스팬을 허용합니다.
• PromptLayer: 원래 프롬프트 최적화를 위해 설계되었으며, 프롬프트 순위 및 점수 매기기와 같은 기능을 포함하는 관찰 가능성 기능을 통합합니다.
• TruLens: Python 패키지로서 LLamaIndex와 같은 다양한 프레임워크와 원활하게 통합되며, 인간 피드백을 사용하여 에이전트 시스템을 반복적으로 최적화합니다.
• OpenLLMetry: OpenTelemetry 표준을 준수하여 다양한 프레임워크와의 호환성을 제공하지만, 프롬프트 최적화 및 평가 테스트와 같은 기능은 부족합니다.
• LangWatch 및 Literal AI: 표준 관찰 가능성 도구로 기능하며, LangWatch는 이미 MCP 서버로 통합되어 있습니다.
• MLFlow: 전통적인 딥러닝에서 유래되었으며, 에이전트 시스템에서 사용자 정의 메트릭을 지원합니다.
• DeepEval: 주로 평가에 초점을 맞추고 관찰 가능성 기능은 부족합니다.
• AgentOps: 관찰 가능성 기능과 함께 전체 시스템에 대한 운영 감독을 강조합니다.

5.3 도전 과제 (Challenges)

에이전트 시스템을 위한 수많은 관찰 가능성 도구가 있음에도 불구하고 도전 과제는 여전히 존재합니다.

• 방대한 양의 데이터 (Vast Amounts of Data): 에이전트 시스템이 계속 성장함에 따라 에이전트 수가 증가하고, 각 에이전트는 상당한 양의 데이터를 생성합니다. 특히 모델 데이터와 체크포인트 데이터가 추가되면서 이 문제가 두드러집니다. 이러한 대규모 데이터셋의 수집, 저장 및 분석은 중대한 도전 과제를 제시합니다.
• 다양한 모니터링 데이터 부족 (Lack of Diverse Monitoring Data): 앞서 언급했듯이, 전통적인 마이크로서비스 시스템과 비교하여 에이전트 시스템은 불충분한 로그, 추적 및 메트릭으로 인해 어려움을 겪습니다.
• 보안 취약성 (Security Vulnerabilities): 에이전트는 메모리를 수정할 수 있는 도구를 자율적으로 호출할 수 있습니다. 적절한 모니터링 및 경고 없이는 이는 데이터 유출 및 기타 손실로 쉽게 이어질 수 있습니다. 따라서 에이전트 모니터링 개선에는 아직 갈 길이 멉니다.

6 이상 감지 및 완화 (Anomaly Detection & Mitigation)

6.1 추론 이상 (Reasoning Anomalies)

추론 이상, 특히 환각(hallucination)을 감지하고 완화하는 방법은 사용되는 입력 정보의 유형에 따라 화이트박스(white-box), 그레이박스(grey-box), 블랙박스(black-box)로 분류될 수 있습니다.

• 화이트박스 접근법 (White-box): 토큰 시퀀스, 각 토큰의 관련 확률, 그리고 모델 매개변수를 활용합니다.
  • SPALMA: LLM은 이전 상태가 정확한지 독립적으로 평가할 수 있는 능력을 가지고 있지만, 환각을 생성하는 것을 막지는 못합니다. 이는 LLM이 토큰 예측기(token predictor)로서 각 단계에서 비교적 높은 확률을 가진 토큰을 예측하려고 시도하기 때문입니다. SPALMA는 LLM의 내부 매개변수가 환각을 어느 정도 반영할 수 있다고 제안하며, LLM 매개변수를 기반으로 하는 분류기를 제안합니다. 이 분류기는 대규모 데이터셋으로 훈련되어 제로샷(zero-shot) 방식으로 환각을 감지할 수 있습니다.
  • OPERA: SPALMA와 같은 방법과 달리, OPERA는 추가 데이터나 모델 훈련 없이 추론 단계에서 환각을 해결할 것을 제안합니다. 자체 어텐션 맵(self-attention maps)에서 특정 요약 토큰 주변의 어텐션 점수가 집합 패턴(aggregation pattern)이라는 기둥 모양의 구조를 보이는 "부분적인 과신(partial over-trust)" 현상을 관찰한 데서 동기를 얻습니다. 이를 해결하기 위해 OPERA는 이 집합 패턴을 식별하는 열 기준 메트릭(column-wise metric)을 도입하고, 토큰 생성 확률을 조정하는 페널티를 설계하여 환각을 줄입니다. 또한, 점수를 기반으로 환각이 감지되면 요약 토큰으로 되돌아가 토큰 시퀀스를 재생성하는 롤백 전략을 제안합니다.
  • Honesty: 환각은 질문이 LLM의 지식 경계를 초과할 때 발생한다고 봅니다. 정직한 모델은 지식이 있는 질문에 공개적으로 답하고, 필요 지식이 부족할 때는 겸손하게 인정해야 한다는 LLM의 정직성에 초점을 맞춥니다. 모델이 자신의 능력 범위를 넘어서는 질문에 응답했는지 평가하는 진화적 메트릭이 정의되며, 모델이 지식 경계를 초과할 경우 IDK ("I don't know") 응답을 하도록 요구하는 응답이 도입됩니다. 이 이상을 해결하기 위해 프롬프트 엔지니어링 및 지도 미세 조정(SFT)과 같은 기술이 탐색됩니다.
• 그레이박스 접근법 (Grey-box): 모델 매개변수를 사용하지 않으며, 주로 토큰 로짓(token logits)에 의존합니다.
  • LURE: 대규모 고품질 데이터로 광범위하게 훈련하여 환각을 줄이는 것은 실현 가능하지 않다고 주장하며, 경량 접근 방식을 제안합니다. 공동 발생(co-occurrence), 불확실성(uncertainty), 객체 위치(object position)라는 세 가지 요인을 식별하고 이를 활용하여 환각 샘플과 정상 샘플을 구성합니다. 이 데이터를 기반으로 학습된 수정기(revisor)는 추론 단계에서 환각을 감지하고 응답을 직접 수정합니다.
  • Conformal: 적합 예측(conformal prediction)에서 영감을 얻어, 언어 모델의 샘플링 공간이 제한적이지만, 샘플링 및 가지치기(pruning) 방법을 통해 더 나은 응답을 얻을 수 있다고 제안합니다. 토큰 시퀀스의 로짓을 계산하여 샘플링된 응답의 품질을 평가하고, 특정 중단 규칙을 충족하면 응답을 유지하고 그렇지 않으면 버립니다.
• 블랙박스 접근법 (Black-box): 토큰 시퀀스에만 의존합니다.
  • Debate: 기존의 방법들이 단일 모델 인스턴스에 초점을 맞추는 것과 달리, Debate는 다양한 관점을 제공할 수 있는 다른 LLM이나 에이전트의 아이디어를 활용합니다. 각 인스턴스는 다른 모든 인스턴스의 응답을 읽고 평가하여 자신의 답변을 업데이트합니다. 반복적인 개선을 통해 더 정확한 해결책에 도달하는 것을 목표로 합니다.
  • CoK (Chain-of-Knowledge): LLM이 답변 프로세스 중에 위키나 데이터베이스와 같은 다중 이종 지식 소스를 적극적으로 쿼리하여 정확한 사실 정보를 얻을 수 있도록 하는 혁신적인 추론 프레임워크입니다. 이 정보는 생성된 추론 체인에 점진적으로 통합되어 환각의 위험을 줄입니다.

6.2 계획 이상 (Planning Anomalies)

계획 이상은 발생 위치에 따라 단일 단계(single-step) 이상과 다중 단계(multiple-step) 이상으로 분류될 수 있습니다.

• 단일 단계 (Single-step)
  • Introspective: LLM이 비실용적이거나 상식에 모순되는 계획을 자주 생성한다는 것을 식별합니다. 이를 해결하기 위해 두 가지 기술을 제안합니다.
    • 첫째, RAG를 사용하여 유사한 계획을 검색하여 그럴듯한 다음 단계를 생성하는 것을 돕습니다.
    • 둘째, 적합 예측 기술을 사용하여 토큰 확률을 기반으로 여러 고품질 답변을 생성하고, 인간 피드백을 사용하여 선택을 더욱 개선합니다.
  • API-bank: LLM을 미세 조정(fine-tuning)하는 것이 계획 능력을 향상시켜 환각을 줄일 수 있다고 주장합니다. 실제 API 호출을 포함하는 대규모 대화 데이터셋을 수집하여 모델을 훈련시키고, 이는 모델의 계획 능력을 크게 향상시킵니다.
  • ReAct: 모델이 단순히 이력 정보만으로는 계획을 생성하기 어렵다고 제안하며, "추론 및 행동(reasoning and act)" 접근 방식을 제안합니다. 모델은 먼저 이력 데이터를 기반으로 추론한 후, 그 추론 능력을 사용하여 계획을 수립합니다. 이 추론 및 행동의 두 단계는 모델에게 성찰하고 오류를 수정할 수 있는 버퍼 기간을 제공하여 더 세련된 계획으로 이어집니다. 이 접근 방식은 프롬프트 엔지니어링을 통해 구현될 수 있습니다.
• 다중 단계 (Multiple-step):
  • Toolllm: 기존 방법들이 주로 단일 API 호출에 국한되는 한계를 극복하기 위해, Toolllm은 대규모 API를 수집하고 단일 도구 및 다중 도구 지침을 모두 생성합니다. 또한, 새로운 깊이 우선 탐색 기반 의사결정 트리를 제안하여 일관된 계획 경로를 생성합니다. 이 데이터를 사용하여 LLM을 미세 조정하여 도구 호출 능력을 향상시킵니다.
  • Reflexion: 에이전트가 여러 반복 후 환각을 경험할 수 있다고 가정합니다. 이를 해결하기 위해 외부 피드백을 기반으로 하는 접근 방식을 제안하며, 에이전트가 이전 실행 단계를 성찰하고 후속 궤적을 최적화할 수 있도록 합니다. 피드백은 단순한 이진 환경 피드백, 일반적인 실패 사례에 대한 사전 정의된 발견적 방법, 그리고 LLM을 사용한 자체 평가(결정용) 또는 자체 작성 단위 테스트(프로그래밍용)와 같은 세 가지 유형으로 분류될 수 있습니다.
  • CodeAct: JSON을 통한 기존의 도구 호출 방식이 매개변수 오류와 같은 환각에 취약하여 작업 실패로 이어질 수 있음을 관찰합니다. 이를 해결하기 위해 전체 계획 프로세스를 코드로 변환하고, 이를 Python 실행기(executor)가 실행하도록 제안합니다. 이는 매개변수가 정확하고 정밀하게 전달되도록 보장하여 작업 성공 가능성을 높입니다.

6.3 행동 이상 (Action Anomalies)

행동 이상은 일반적으로 함수 호출 및 MCP를 통해 실행되므로, 함수 호출 이상과 MCP 이상으로 나눌 수 있습니다.

• 함수 호출 (Function Call): 초기 단계에서는 함수 호출을 통해 행동 실행이 구현되었으며, 오류가 발생하면 즉시 오류 메시지를 반환했기 때문에 이상 감지 및 완화가 비교적 간단하여 자세히 다루지 않습니다.
• MCP (Model Context Protocol)
  • AI-Infra-Guard: 에이전트 기술을 활용하여 도구 포이즈닝 공격(tool poisoning attacks) 및 러그 풀(rug pulls)과 같은 MCP 내의 잠재적 위험을 감지합니다. MCP의 이상 감지는 AI-Infra-Guard의 기능 중 하나일 뿐이며, AI 컴포넌트에 대한 보안 스캔도 수행할 수 있습니다.
  • MCP Guardian: MCP를 기반으로 하는 AI 시스템에 "보안 우선(security-first)" 미들웨어 레이어를 추가하는 것을 핵심 메커니즘으로 합니다. 이 레이어는 클라이언트(MCP 클라이언트)와 데이터 소스/도구 서버(MCP 서버) 간의 통신을 향상시키며, 인증, 속도 제한, 상세한 호출 정보 로깅, 그리고 패킷 내용의 심층 검사라는 네 가지 주요 구성 요소로 이루어져 있습니다.

6.4 메모리 이상 (Memory Anomalies)

에이전트의 메모리는 단기 메모리와 장기 메모리로 나뉘므로, 메모리 이상은 단기 메모리 이상과 장기 메모리 이상으로 분류될 수 있습니다.

• 단기 메모리 (Short-Term Memory)
  • PI (Position Interpolation): 기존 방법들이 짧은 컨텍스트 윈도우에서 훈련되고 긴 컨텍스트에서 추론되어 약한 외삽(extrapolation) 속성을 초래하는 문제를 해결합니다. 이 방법은 위치 인코딩이 비정수 값을 가질 수 있는 속성을 활용하여 전체 윈도우를 조정(예: 4096을 2048로 축소)하여 모델의 컨텍스트 윈도우 길이 제한 내에 맞춥니다.
  • CoA (Chain of Agents): 미세 조정과 같은 기존 방법들이 "Lost in the Middle" 문제를 쉽게 초래할 수 있다고 주장합니다. 이를 해결하기 위해 다중 에이전트 협업 접근 방식을 제안합니다.
    • 1단계에서 서로 다른 에이전트들이 입력의 서로 다른 청크를 처리하고 그 결과를 후속 에이전트들에게 전달하며,
    • 2단계에서 관리 에이전트가 이러한 입력을 통합하여 최종 답변을 제공합니다.
• 장기 메모리 (Long-Term Memory - RAG)
  • ReDeep: RAG 프로세스 중 외부 지식과 모델의 내부 매개변수 간의 충돌이 환각 이상을 쉽게 초래할 수 있다고 봅니다. ReDeep은 외부 컨텍스트 점수와 매개변수 지식 점수라는 두 가지 점수를 계산하고 처리하여 환각을 평가합니다. 잔차 스트림(residual stream) 내의 지식 피드 포워드 네트워크(FFNs) 및 복사 헤드(Copying Heads)의 기여도를 조절하여 환각을 완화합니다.
  • LRP4RAG: 고전적인 알고리즘인 계층별 관련성 전파(Layer-wise Relevance Propagation, LRP)를 활용합니다. 생성기가 로짓을 출력한 후 LRP를 역방향으로 수행하여 관련성 행렬을 얻고, 이 행렬을 사전 훈련된 분류기에 입력하여 환각을 감지합니다.

6.5 환경 이상 (Environment Anomalies)

환경 이상은 일반적으로 환경 관련 메트릭 또는 로그 이상에서 반영됩니다. 결과적으로, 시계열 이상 감지와 같은 전통적인 마이크로서비스 기반 모니터링 및 이상 감지 방법이 이러한 문제를 효과적으로 해결할 수 있으므로, 여기서는 더 이상 자세히 다루지 않습니다.

6.6 작업 명세 이상 (Task Specification Anomalies)

불분명한 작업 명세는 작업 실패를 쉽게 초래하지만, 이 유형의 이상은 종종 간과됩니다. 전통적인 시스템은 인간의 참여가 거의 없었으며, 운영은 주로 실행 단계에 초점을 맞추었기 때문에 사전 실행 단계의 인간 구성(human configurations)은 다루지 않았습니다. AgentOps에서는 인간이 에이전트 시스템의 핵심 구성 요소이며, 인간이 야기하는 이상은 무시할 수 없습니다.

• 현재 연구의 한계: 현재 이 문제에 초점을 맞춘 연구는 제한적이며, 일부 연구에서 이를 중요한 이상 유형으로 인정하지만, 효과적인 해결책은 거의 제안되지 않았습니다.
• 실현 가능한 접근 방식: 환각 감지와 유사한 방법을 사용하여 다른 프롬프트에 대한 LLM의 잠재 상태(latent states)를 평가하는 것이 실현 가능한 접근 방식입니다. 그 이유는 명확한 프롬프트는 후속 단계에서 무작위성(randomness)이 적은 결과를 초래하는 반면, 불분명한 프롬프트는 더 넓은 범위의 가능한 경로로 이어질 수 있기 때문입니다.

6.7 보안 이상 (Security Anomalies)

보안 이상은 시스템 안전을 심각하게 위협할 수 있으며, 이에 대응하여 이러한 악성 공격을 감지하려는 수많은 방법이 제안되었고, 주로 그래프 기반 접근 방식을 사용합니다.

• 그래프 (Graph):
  • GUARDIAN: 다중 에이전트 투표 접근 방식이 에이전트 간의 의존성을 간과한다고 주장합니다. 따라서 에이전트 시스템을 그래프로 모델링하고, 인코더-디코더 프레임워크를 사용하여 전체 그래프를 압축 및 재구성합니다. 재구성 점수를 기반으로 잠재적인 이상 위치를 식별합니다.
  • SentinelAgent: 다중 에이전트 시스템에서 많은 보안 이상, 특히 다중 에이전트 조정 위험이 흔하게 발생한다는 점을 인식합니다. 이를 해결하기 위해 글로벌 관점에서 시작하여 더 상세한 검사로 심화되는 3단계 감지 접근 방식을 제안합니다.

6.8 통신 이상 (Communication Anomalies)

통신 이상의 주된 원인은 에이전트 시스템의 지속적인 확장으로 인해 전송되는 메시지 볼륨이 증가하는 데 있지만, 이 중 상당수가 불필요하며, 과도한 중복성은 작업 실패로 이어질 수 있습니다.

• 중복성 (Redundancy):
  • AgentPrune: 대화 내(intra-dialogue) 및 대화 간(inter-dialogue) 통신 모두 통신 중복을 초래할 수 있으며, 에이전트들이 많은 토큰을 소비하고 비효율적인 교환에 참여한다고 주장합니다. 이를 해결하기 위해 전체 에이전트 시스템을 그래프로 구성한 다음, 저랭크 원리 기반 그래프 마스크를 훈련합니다. 이 마스크는 그래프의 중요한 부분에 초점을 맞춰 통신을 추출하고 효율성을 향상시킵니다.
  • G-Designer: 최적의 통신 토폴로지가 작업에 따라 달라진다고 주장하며 보다 거시적인 관점을 취합니다. 특정 작업에 맞춤화된 다양한 토폴로지를 생성합니다. 구체적으로, 그래프 오토인코더를 사용하여 전체 에이전트 시스템을 압축하고 최적의 토폴로지를 재구성합니다.

6.9 신뢰 이상 (Trust Anomalies)

신뢰 이상은 일반적으로 에이전트의 메시지가 신뢰할 수 있는지 여부를 평가하는 것을 포함합니다. 추론 이상을 다루는 방법을 사용하여 이 문제를 해결하는 것이 간단한 접근 방식일 수 있지만, 시스템 수준 관점에서 문제를 고려하는 것이 새로운 통찰력을 제공할 수 있습니다.

• ATrust: A2A 통신이 인기를 얻으면서 다양한 출처 에이전트로부터의 메시지의 신뢰도를 평가할 필요성이 커지고 있음을 강조하며, 이를 실패하면 작업 보안을 심각하게 훼손할 수 있다고 지적합니다. ATrust는 사실적 정확성, 논리적 일관성, 관련성, 편향, 언어 품질, 명확성이라는 여섯 가지 차원에 걸친 어텐션 맵을 기반으로 신뢰도를 평가합니다.

6.10 출현적 행동 이상 (Emergent Behavioral Anomalies)

출현적 행동 이상은 다중 에이전트 간의 복잡한 상호 작용에서 발생하며, 시스템 수준의 행동을 초래하며, 이는 어떤 단일 에이전트에게도 귀속될 수 없습니다. 이 이상은 어떤 개별 에이전트의 제약 조건을 위반하지 않으면서도 바람직하지 않은 시스템 결과를 초래할 수 있기 때문에 특히 은밀합니다. 현재 업계에서는 이 유형의 이상에 대한 효과적인 감지 방법이 없습니다.

6.11 종료 이상 (Termination Anomalies)

이러한 유형의 이상은 무한 루프 또는 조기 종료로 나타날 수 있습니다.

• 무한 루프: 로그 및 추적(traces)을 통해 쉽게 감지될 수 있습니다.
• 조기 종료: 일반적으로 작업 성공률 및 유사한 메트릭을 모니터링하여 식별됩니다. 현재 이 주제에 대한 최첨단 연구는 없습니다.

7 근본 원인 분석 (Root Cause Analysis, RCA)

7.1 에이전트 실패의 근본 원인 분류 (A Taxonomy of Root Causes for Agent Failures)

실패를 효과적으로 진단하기 위해서는 실패의 원인을 정확하게 귀속시킬 수 있는 분류 체계가 필요합니다. 우리가 제안하는 분류는 단순히 학술적 목적을 넘어, 실행 가능하도록 구성되어 있으며 가장 새로운 도전 과제에 공동체의 관심을 집중시키도록 설계되었습니다.

이 분류의 설계는 두 가지 핵심 동기에 의해 이루어졌습니다:

1. 실용적인 실행 가능성 (Actionability): 에이전트 시스템 구축 및 유지 관리에 관련된 고유한 기술 스택 및 팀 책임에 직접적으로 부합합니다. 이는 RCA 프로세스의 결과가 추상적인 발견이 아니라, 시스템 문제에 대한 DevOps/SRE, 모델 중심 문제에 대한 ML 엔지니어링, 오케스트레이션 논리에 대한 에이전트 개발자 등 적절한 팀에 대한 명확한 지침이 되도록 보장합니다.
2. 전략적 집중 (Strategic Focus): 이 분류는 "오래된" 문제 (시스템 신뢰성)를 "새로운" 문제 ("소프트 로직" 오케스트레이션의 초기 및 가장 중요한 도전 과제)로부터 전략적으로 분리합니다. 이를 통해 필요에 따라 수십 년간의 기존 엔지니어링 관행을 활용할 수 있으며, 에이전트 패러다임이 도입한 고유한 복잡성에 연구 및 도구 개발 노력을 집중할 수 있습니다.

우리는 모든 에이전트 실패의 근본 원인이 다음 세 가지 직교적(orthogonal)이며 포괄적인 차원 중 하나로 분류될 수 있다고 제안합니다:

• 시스템 중심 (System-centric): 에이전트의 운영을 지원하는 하드 인프라와 외부 종속성을 다룹니다. 이는 전통적인 시스템 신뢰성 및 성능에 초점을 맞추며, 문제들은 일반적으로 결정론적입니다.
• 모델 중심 (Model-centric): 에이전트의 인지적 핵심 역할을 하는 LLM의 내재된 불확실성 및 능력 한계에 초점을 맞춥니다. 이는 논리적 추론 실패뿐만 아니라 지식 격차, 도구 상호 작용에서 학습하지 못하는 능력, 또는 과도한 미세 조정으로 인한 일반 작업 성능 저하 등을 포괄합니다. 모델 자체에서 발생하는 이러한 문제들은 종종 확률적이고 예측 불가능합니다.
• 오케스트레이션 중심 (Orchestration-centric): AgentOps에 고유하며, 시스템과 모델을 연결하는 **"소프트 로직"**을 다룹니다. 이는 모델이 생각하고 행동하는 방식을 안내하는 전략과 지침에 관한 것입니다. 현재 RCA 영역에서 가장 복잡하고 덜 이해된 영역입니다.

이 분류는 "에이전트가 실패했다"와 같은 모호한 문제를 책임 영역이 명확히 정의된 문제로 변환하기 위한 표준화된 언어를 제공합니다.

7.2 이상 감지에서 RCA로의 매핑 (Mapping from Anomaly Detection to RCA)

실제로는 RCA 프로세스가 이상 감지(AD) 시스템의 경고에 의해 트리거됩니다. AD는 무엇이 잘못되었는지에 답하지만, RCA는 왜인지를 조사해야 합니다. 이 논문의 일관된 논리를 위해, AD 섹션에서 식별된 이상 유형과 RCA 프레임워크의 근본 원인 범주 간의 명확한 매핑을 설정하는 것이 중요합니다.

AD 프레임워크는 이상을 에이전트 내(intra-agent) (단일 에이전트의 내부 인지 과정 관련) 및 에이전트 간(inter-agent) (에이전트와 환경 간의 광범위한 상호 작용 관련) 두 가지 수준으로 분류합니다. 우리의 RCA 프레임워크는 이러한 관찰된 이상들을 시스템 중심, 모델 중심, 또는 오케스트레이션 중심 차원 내의 근원으로 체계적으로 추적할 수 있습니다.

매핑의 중요 통찰: 이 매핑은 하나의 고수준 이상 유형이 단 하나의 근본 원인을 갖는 경우는 드물다는 중요한 통찰을 보여줍니다.

• 예시: AD 시스템에 의해 감지된 **추론 이상(Reasoning anomaly)**은 다음과 같은 원인에서 비롯될 수 있습니다:
  • 시스템 중심 문제: RAG 데이터베이스가 노이즈가 많거나 오래된 컨텍스트를 제공하는 경우.
  • 모델 중심 문제: **핵심 모델의 환각(core hallucination)**이나 사실적 부정확성.
  • 오케스트레이션 중심 문제: 결함이 있는 CoT(Chain-of-Thought) 프롬프트나 오해를 유발하는 모호한 지침.

따라서 RCA 프로세스의 역할은 다음 섹션에서 설명할 방법론을 사용하여 이러한 잠재적인 원인들을 명확히 구분하고 실패의 진정한 근원을 정확히 찾아내는 것입니다. 이 구조화된 접근 방식은 팀이 실제로 데이터 문제나 프롬프트 엔지니어링 문제일 수 있는 것에 대해 모델을 성급하게 비난하는 것을 방지합니다.

7.3 에이전트 RCA를 위한 핵심 방법론 및 전략 (Core Methodologies and Strategies for Agent RCA)

AgentOps를 위한 효과적인 RCA 전략은 기존의 운영 지혜를 기반으로 하면서도 새로운 도전을 위한 새로운 도구를 구축합니다. 우리는 확립된 AIOps 방법론과 새롭게 등장하는 에이전트별 진단 기술을 통합하는 하이브리드 접근 방식을 지지합니다.

7.3.1 기본: 전통적인 AIOps를 에이전트 시스템에 적용하기 (The Foundation: Adapting Traditional AIOps for Agent Systems)

많은 시스템 중심 실패를 진단하는 데 있어 AIOps와 전통적인 모니터링의 강력한 도구 키트는 여전히 매우 관련성이 높고 효과적입니다. 이러한 방법들은 모든 RCA 프로세스의 첫 번째 방어선을 형성합니다.

• 로그 및 메트릭 상관관계 (Log and Metric Correlation): 성능 메트릭(예: 지연 시간, CPU 사용량)을 구조화된 오류 로그와 상관시키는 고전적인 접근 방식은 인프라 병목 현상, 서비스 실패 또는 리소스 고갈을 식별하는 데 기본적입니다. 이는 시스템 중심 차원의 많은 결정론적 문제를 직접적으로 다룹니다.
• 분산 추적 (Distributed Tracing): 분산 추적(예: OpenTelemetry)의 개념은 에이전트가 상호 작용할 수 있는 데이터베이스, 외부 API 및 기타 내부 시스템을 포함하여 다양한 마이크로서비스 전반에서 요청을 추적하는 데 필수적입니다.

그러나 이러한 방법들은 실패의 원인이 의미론적(semantic)이거나 논리적일 때는 부족합니다. 예를 들어, AIOps 도구는 API 호출이 404 오류를 반환했다고 보고할 수 있지만, 에이전트가 애초에 존재하지 않는 엔드포인트를 호출하기로 결정한 이유는 설명할 수 없습니다. 바로 이 지점에서 에이전트별 전략이 필수 불가결해집니다.

7.3.2 선봉: 에이전트별 실패를 위한 새로운 전략 (The Vanguard: Novel Strategies for Agent-Specific Failures)

모델 중심 및 오케스트레이션 중심 차원 내의 복잡하고 종종 확률적인 실패를 진단하기 위해, 우리는 시스템 메트릭을 넘어 의미론적 및 논리적 분석 영역으로 이동해야 합니다.

전략 1: 풀 스택 에이전트 추적성 (Full-Stack Agent Traceability) [105–108]

• LLM의 확률적 특성 때문에 동일한 입력이 동일한 출력을 생성하지 않을 수 있어, 전통적인 재현이 어렵습니다.
• 에이전트 추적성은 상태를 추론하는 것에서 벗어나, 에이전트의 내부 인지 상태를 각 단계에서 명시적으로 기록하도록 발전해야 합니다. 이는 진정한 **재생 가능성(replayability) 및 감사 가능성(auditability)**을 달성하기 위한 전제 조건입니다.
• 포괄적인 에이전트 추적은 **행동("무엇")**뿐만 아니라 **행동으로 이어진 상태("왜")**도 캡처해야 합니다.
• 포함해야 할 구성 요소:
  • 인지 상태 스냅샷 (Cognitive State Snapshots): 각 결정 지점 이전에 에이전트의 내부 상태를 캡처합니다. 이는 고전적인 BDI(Belief-Desire-Intention) 모델과 밀접하게 일치하며, 다음을 기록해야 합니다:
    • 믿음 (Beliefs): 초기 입력 및 이전 관찰로부터 파생된 세계 상태에 대한 현재 이해.
    • 메모리 (Memory): 그 순간의 단기(예: 컨텍스트 윈도우) 및 장기(예: 검색된 RAG 문서) 메모리 내용.
    • 계획/의도 (Plan/Intent): 에이전트가 실행하려는 현재 고수준 계획 또는 하위 목표.
  • 추론 프로세스 기록 (Reasoning Process Records): 이는 "내면의 독백" 또는 **CoT(Chain-of-Thought)**이며, 인지 상태를 결정으로 변환하는 모델의 추론 프로세스에 대한 명시적인 기록입니다.
  • 행동 및 환경 상호 작용 (Action & Environment Interactions): 생성된 특정 도구 호출, 사용된 정확한 매개변수, 환경에서 반환된 **필터링되지 않은 원본 출력(관찰)**을 포함합니다.
• 이러한 내부 상태를 직접 캡처함으로써, 에이전트의 전체 의사 결정 수명 주기에 대한 고충실도, 재생 가능한 기록을 생성하게 됩니다. 이 추론적(inferential) 관찰에서 직접적(direct) 상태 관찰로의 전환은 AIOps에서 AgentOps로의 가장 중요한 진화입니다.

전략 2: 가설 주도 진단 및 대안적 사실 시뮬레이션 (Hypothesis-Driven Diagnosis with Interactive Counterfactual Simulation) [109–112]

• 이는 AIOps의 수동적인 사후 분석에서 벗어나 AgentOps에 고유한 능동적, 실험적 접근 방식으로의 패러다임 전환을 나타냅니다.
• 에이전트 시스템은 불연속적인 인지 주기(예: 생각, 행동, 관찰)로 작동하며, 추적성 전략을 통해 전체 내부 상태를 각 단계에서 체크포인트할 수 있습니다. 이는 에이전트 워크플로우 내에서 **대화형으로 "시간 여행"**할 수 있는 혁신적인 기능을 제공합니다.
• 방법론:
  1. 추적 로드: 실패한 실행의 고충실도 추적을 로드합니다.
  2. 체크포인트로 이동: 실패가 시작된 것으로 의심되는 추론 프로세스의 특정 단계로 직접 이동합니다.
  3. 대안적 사실 개입 수행: 이 체크포인트에서 에이전트 상태의 단일 요소를 대화형으로 수정합니다 ("만약 이랬다면" 실험).
  4. 실행 재개: 수정된 체크포인트에서 에이전트의 실행을 재개합니다.
  5. 결과 관찰: 후속 행동이 스스로 수정되어 작업이 성공하면, 근본 원인이 높은 신뢰도로 분리된 것입니다.
• 이러한 목표 지향적이고 대화형인 개입 능력은 오케스트레이션 및 모델 중심 차원에서 흔히 발생하는 비결정론적이고 의미론적인 실패를 디버깅하는 강력한 기능입니다. 그러나 LLM의 확률적 특성은 완벽한 재현성을 달성하는 데 도전 과제를 제기하므로, 효과적인 대안적 사실 시뮬레이션은 에이전트의 상태뿐만 아니라 모델의 내부 샘플링 매개변수까지 체크포인트하고 복원하는 능력에 달려 있습니다.

전략 3: 의미론적 비교 분석 (Semantic Comparative Analysis)

• 직접적인 가설 설정이 어려울 때, 실패한 추적을 성공한 추적 (유사한 입력에 대한)과 비교하는 것은 강력한 단서를 제공합니다.
• 이 접근 방식은 NLP의 대조 설명(contrastive explanations) 작업에서 영감을 받았으며, 단순히 메트릭을 비교하는 것이 아니라 추론 경로의 **의미론적 차이(semantic diff)**에 중점을 둡니다.
• 분석은 "어떤 단계에서 추론이 발산했는가?", "RAG 컨텍스트가 달랐는가?", 또는 "두 에이전트가 동일한 지침을 다르게 해석했는가?"와 같은 질문에 초점을 맞춥니다.
• 이 기술은 미묘한 오케스트레이션 또는 모델 수준의 문제를 밝혀내는 데 매우 효과적입니다.

요청하신 "8 해결 (Resolution)" 섹션의 내용을 제공된 출처를 바탕으로 상세히 해석해 드립니다.

8 해결 (Resolution)

AgentOps의 해결 단계는 에이전트 시스템에서 탐지된 이상을 수정하고 시스템의 안정성을 회복하는 최종 단계입니다.

---

8.1 해결 유효성 검증 (Resolution Validation)

에이전트 시스템 운영(AgentOps)에서 가장 중요한 구성 요소 중 하나는 구현된 해결책이 탐지된 이상을 효과적으로 수정하고 부작용을 도입하지 않았는지 확인하기 위한 체계적인 유효성 검증입니다.

• 주요 평가 기준: 주된 평가 기준은 **작업 성공률(Task Success Rate)**입니다. 해결책은 적용 후 에이전트가 이전보다 일관되게 더 높은 작업 성공률을 달성할 때 효과적인 것으로 간주됩니다

에이전트 시스템 운영(AgentOps)에서 가장 중요한 구성 요소 중 하나는 구현된 해결책이 탐지된 이상을 효과적으로 수정하고 부작용을 도입하지 않았는지 확인하기 위한 체계적인 유효성 검증입니다.

• 주요 평가 기준: 주된 평가 기준은 **작업 성공률(Task Success Rate)**입니다. 해결책은 적용 후 에이전트가 이전보다 일관되게 더 높은 작업 성공률을 달성할 때 효과적인 것으로 간주됩니다.
• 평가 방법론: 현재 이 기준을 평가하는 두 가지 주요 방법론이 있습니다:
  1. 수동 주석 (Manual Annotation): 인간 전문가가 상세한 평가 기준(rubric)에 따라 에이전트 성능을 검토합니다. 이는 정확도 측면에서 **골드 스탠더드(gold standard)**로 간주되며, 작업 성공과 출현적 행동(emergent behaviors)의 미묘함에 대한 미묘한 판단을 제공합니다. 그러나 자원 집약적이며 지속적인 실시간 모니터링에는 효과적으로 확장되지 않습니다.
  2. LLM-as-a-Judge: 확장 가능한 대안으로서, 별도의 강력한 LLM을 사용하여 에이전트의 성능을 평가합니다. "심판(judge)" LLM은 미리 정의된 성공 기준과 채점 기준에 따라 에이전트 로그 및 출력을 평가하며, 작업 성공률의 빠르고 대규모의 자동화된 평가를 가능하게 합니다.

8.2 해결 스키마: 반복적 교정 및 다중 턴 유효성 검증 (Resolution Schema: Iterative Remediation and Multi-Turn Validation)

전통적인 IT 시스템에서 이상 해결이 종종 선형적이고 이산적인 "탐지-진단-교정" 워크플로를 따르는 것과 대조적으로, 에이전트 시스템의 이상을 해결하려면 지속적이고 반복적인 관리로의 패러다임 전환이 필요합니다.

• 전통적인 가정의 무효화: 현대 에이전트 시스템에서는 영향의 국지화에 대한 가정이 근본적으로 유효하지 않습니다. 그 이유는 두 가지 핵심 속성 때문입니다:
  1. 확률적 행동 (Probabilistic Behavior): LLM 기반 에이전트의 행동은 본질적으로 확률적이고 비결정적이어서, 주어진 입력이 여러 번의 시도에서 동일한 출력을 보장하지 않습니다.
  2. 복잡 적응 시스템 (Complex Adaptive System): 시스템은 복잡 적응 시스템으로 작동하며, 전체적인 행동은 이러한 비결정적 에이전트들 간의 수많은 국지적 상호 작용의 **출현적 속성(emergent property)**입니다.
• 시스템적 평형의 교란: 따라서, 단일 에이전트의 이상을 교정하는 것은 단순한 수리가 아니라, 시스템적 평형의 교란(perturbation of the systemic equilibrium), 즉 상호 작용하는 모든 에이전트에 대한 운영 환경을 변화시키는 개입이 됩니다.
• 2차 효과 및 시스템 불안정성: 핵심적인 어려움은 2차 효과(second-order effects) 및 연쇄적인 행동 변화의 높은 잠재성에 있습니다. 예를 들어, 계획 이상이 있는 에이전트의 계획 휴리스틱을 수정하여 효율성을 개선하는 경우, 이 의도된 1차 효과는 종종 에이전트 간 역학을 변경하여 예상치 못한 시스템적 실패를 촉발할 수 있습니다. 새로운 효율적인 에이전트가 중요한 공유 리소스를 독점하여 다른 에이전트의 **기아(starvation)**를 유발하고, 통신 및 출현적 이상으로 이어져 교착 상태나 자원 충돌을 일으킬 수 있습니다.
• 반복적인 해결 프로세스: 이러한 문제들로 인해, 이상 해결은 순환적이고 경험적인 프로세스여야 합니다. 어떤 수정(fix)도 광범위한 유효성 검증이 필요한 잠정적인 가설로 취급되어야 합니다. 개입 후, 시스템은 다중 턴(multi-turn) 관찰 기간을 필요로 하여 시스템 전체의 성능과 상호 작용 패턴을 모니터링해야 합니다. 해결은 개입, 시스템의 다중 턴 응답 관찰, 출현적 행동 분석, 안정적이고 원하는 상태가 달성될 때까지 수정하는 시스템적 튜닝의 반복적인 프로세스가 됩니다.

8.3 에이전트 시스템의 이상 해결 (Anomaly Resolution for Agent Systems)

복잡한 에이전트 시스템의 이상을 해결하기 위한 명확하고 실행 가능한 프레임워크를 제공하기 위해, 잠재적인 해결책을 두 가지 주요 범주로 나눕니다: 시스템 설계 기반 해결책과 프롬프트 최적화 기반 해결책입니다 [121, Table 8].

해결책 유형설명대상 이상 클래스

시스템	중복성 및 투표 (Redundancy & Voting)	추론, 행동, 작업 명세, 메모리
	가드레일 및 어설션 (Guardrails & Assertions)	행동, 통신, 보안, 메모리, 실행
	복구 및 롤백 (Recovery & Rollback)	환경 및 종료, 실행
	정책 및 전략 적응 (Policy & Strategy Adaptation)	추론, 계획, 작업 명세, 행동
프롬프트	자체 수정 및 성찰 (Self-Correction & Introspection)	추론, 계획, 작업 명세, 행동
	재명세 및 재프롬프트 (Re-specification & Re-prompting)	추론, 계획, 작업 명세, 행동

8.3.1 시스템 설계 기반 해결책 (System Design Driven Resolutions)

이러한 해결책들은 시스템 아키텍처에 통합되어야 하며 공식적인 엔지니어링을 필요로 합니다. 이는 강건한 프레임워크, 안전 메커니즘, 피드백 루프를 시스템 수준에 내장하여 안전하고 신뢰할 수 있는 운영을 보장하는 데 중점을 둡니다.

• 중복성 및 투표 (Redundancy & Voting):
  • 단일 에이전트 실행이나 출력에 의존하지 않고 다중 에이전트 또는 다중 실행을 병렬 또는 순차적으로 실행하여 견고성을 도입합니다.
  • 출력은 투표, 채점 또는 선택 메커니즘을 통해 집계됩니다.
  • 이는 여러 가설을 비교하여 가장 일관되거나 확신하는 것을 선택함으로써, 확률적 실패 모드 (예: 계획 불일치, 의미론적 표류)를 완화합니다.
  • 출현적 행동 이상, 인식적 불확실성, 또는 취약한 추론 경로를 해결하는 데 특히 유용하며, 병렬성이 자연스럽고 비용 효율적인 분산 에이전트 시스템에 잘 맞습니다.
• 가드레일 및 어설션 (Guardrails & Assertions):
  • 실행 전 또는 후에 에이전트 행동에 대한 제약 조건을 적용하는 사전 예방적 안전 장치 역할을 합니다.
  • 구문 제약 (예: JSON 스키마), 의미론적 유효성 검증 (예: 답변이 도구 결과를 참조해야 함), 행동 어설션 (예: 항상 최종 결정 출력)을 포함합니다.
  • 가드레일은 프롬프트 제약 조건, 사후 유효성 검사기, 또는 런타임 실행 샌드박스를 통해 구현될 수 있습니다.
  • 행동 수준 이상, 출력 형식 문제, 위험한 도구 실행을 해결하는 데 이상적입니다.
• 복구 및 롤백 (Recovery & Rollback):
  • 이상이 에이전트를 유효하지 않거나 복구 불가능한 상태로 만들 때, 이전 체크포인트로 되돌아가는 능력이 필수적입니다.
  • 에이전트의 메모리, 계획 스택 또는 실행 환경의 지속적인 스냅샷을 유지하고, 실패 감지 시 이를 복원하는 전략을 포함합니다.
  • 종료 이상, 연쇄적인 도구 실패, 또는 계획 막다른 골목을 처리하는 데 특히 유용합니다.
  • 효과적인 복구는 잘 구조화된 내부 상태 표현과 안정적인 상태 캡처 방법에 의존합니다.
• 정책 및 전략 적응 (Policy & Strategy Adaptation):
  • 단일 실패를 수정하는 것이 아니라, 에이전트의 행동을 관장하는 기저 전략을 조정함으로써 이상을 해결할 수 있습니다.
  • 관찰된 성능에 반응하여 에이전트의 계획 또는 학습 정책을 개선하는 것을 포함합니다.
  • 커리큘럼 학습 업데이트 또는 검증된 보상 기반 강화 학습 형태를 취하여 에이전트의 계획 및 추론 능력을 직접 향상시키거나, 행동 정책 전환을 통해 더 신뢰할 수 있는 외부 도구 및 정보를 제공할 수 있습니다.
  • 이 해결책은 구조적 결함을 다루고 장기적인 견고성과 일반화 능력을 향상시킵니다.

8.3.2 프롬프트 최적화 기반 해결책 (Prompt Optimization Driven Resolutions)

이러한 전략들은 에이전트의 기저 언어 모델과의 직접적인 상호 작용에 중점을 둡니다. 일반적으로 에이전트의 추론 루프 내에서 구현되며, 에이전트의 사고 과정과 행동을 안내하는 데 사용되는 프롬프트를 동적으로 생성, 개선 및 평가하는 것을 포함합니다.

• 자체 수정 및 성찰 (Self-Correction & Introspection):
  • 외부 개입 없이 모델 자체의 추론 능력을 활용하여 불일치, 환각 또는 유효하지 않은 행동을 탐지하고 수정을 시도합니다.
  • 시스템 프롬프트를 최적화하여 하위 질문 재요청, 유효하지 않은 계획 재생성, 자체 검증을 통한 이전 행동 평가와 같은 행동을 가능하게 합니다.
  • 추론 이상, 결함 있는 계획 실행, 또는 멀티 홉 추론 중 발생한 부정확한 가정을 해결하는 데 특히 효과적이며, 자율적이고 견고한 에이전트를 구축하기 위한 기초 전략입니다.
• 재명세 및 재프롬프트 (Re-specification & Re-prompting):
  • 대부분의 경우, 에이전트 실패는 모호하거나, 불충분하게 명세되거나, 충돌하는 작업 지침에서 비롯됩니다.
  • 이러한 경우, 최적의 해결책은 동일한 계획을 재시도하는 것이 아니라, 작업을 더 명확하고 구조화된 용어로 재명세하는 것입니다 (프롬프트 엔지니어링).
  • 이는 원본 프롬프트 재작성, 작업을 하위 목표로 분해, 또는 에이전트의 생성을 안내하기 위한 보조 제약 조건 도입을 포함할 수 있습니다.
  • 자동 프롬프트 최적화 방법도 제안되었는데, 이는 학습 기반 방법 (예: 경사 기반 방법 또는 강화 학습을 통해 프롬프트를 미세 조정)과 진화 기반 방법 (예: 돌연변이, 교차, 자연 선택과 같은 생물학적 원리에 영감을 받아 반복적으로 프롬프트를 개선)으로 나뉩니다.

고객님께서 요청하신 "9 Challenges and Future Directions of AgentOps (AgentOps의 도전 과제 및 미래 방향)"에 대한 해석입니다. 이 섹션은 AgentOps의 네 가지 핵심 단계인 모니터링, 이상 감지, 근본 원인 분석, 해결에 걸쳐 현재 직면한 도전 과제와 향후 연구 방향을 제시합니다.

9 AgentOps의 도전 과제 및 미래 방향 (Challenges and Future Directions of AgentOps)

9.1 모니터링 (Monitoring)

현재 에이전트 시스템의 모니터링은 두 가지 주요 도전에 직면해 있습니다.

1. 전통적인 모니터링 도구의 한계:
   • 현재의 전통적인 모니터링 도구는 주로 메트릭, 로그, 추적(traces)을 포착하는 데 한계가 있습니다.
   • 섹션 5에서 논의되었듯이, 모델 데이터와 체크포인트 데이터는 에이전트 시스템에서 매우 중요한 역할을 하지만, 이러한 데이터는 종종 기존의 관찰 가능성 방법의 범위를 벗어납니다.
2. 방대한 양의 데이터:
   • 관찰되는 데이터, 특히 모델 관련 데이터의 sheer volume(막대한 양)은 적절하게 관리되지 않을 경우 상당한 메모리 오버헤드를 유발할 수 있습니다.

핵심 미래 방향:

• 다양한 데이터 유형의 효율적인 관찰: 미래의 핵심 방향은 다양한 유형의 데이터를 규모에 맞게 효과적으로 관찰하는 동시에 효율적인 저장 및 리소스 활용을 보장할 수 있는 모니터링 솔루션을 개발하는 것입니다.

9.2 이상 감지 (Anomaly Detection)

현재 에이전트 시스템에서 발생하는 이상 현상은 본질적으로 다양합니다. 이는 심각한 도전 과제를 야기하는데, 바로 여러 유형의 이상을 동시에 식별할 수 있는 통합된 감지 알고리즘이 부족하다는 점입니다.

• 오버헤드 문제: 이상 유형별로 별도의 이상 감지 모델을 배포하는 것은 온라인 서비스에 상당한 오버헤드를 초래할 것입니다.

핵심 미래 방향:

• 통합되고 효율적인 알고리즘 설계: 보다 광범위한 스펙트럼의 이상을 통합된 방식으로 감지할 수 있는 더 가볍고 효율적인 알고리즘 설계를 탐색하는 것이 중요합니다. 이는 본질적으로 에이전트 시스템에 맞춰진 포괄적이고 확장 가능한 이상 감지 프레임워크를 개발하는 것을 의미합니다.

9.3 근본 원인 분석 (Root Cause Analysis, RCA)

섹션 7에서 확립된 바와 같이, 구조화된 RCA 프레임워크는 명확한 진단 경로를 제공하지만, 실제로는 인과적 귀속의 모호성이라는 중대한 도전에 직면합니다.

• 복합적인 원인: 단일 관찰된 이상 현상이 시스템, 모델, 오케스트레이션 계층 전반에 걸친 다수의 복잡하게 얽힌 근본 원인에서 비롯될 수 있으며, 이로 인해 실패의 진정한 근원을 분리하기 어렵습니다.
• 지연 및 오버헤드: 잠재적인 모든 원인에 대해 별도의 심층 분석을 배포하는 것은 상당한 진단 지연 및 계산 오버헤드를 초래할 것입니다.

핵심 미래 방향:

• 자동화되고 효율적인 인과 추론 기술: 복잡한 실패 시나리오를 통합된 방식으로 분리할 수 있는 더 자동화되고 효율적인 인과 추론 기술을 개발하는 것이 핵심입니다. 본질적으로, 이는 에이전트 시스템에 맞춰진 확장 가능하고 지능적인 근본 원인 분석 엔진을 만드는 것입니다.

9.4 해결 (Resolution)

AgentOps의 해결 단계가 직면한 주요 도전 과제는 LLM에 의해 구동되는 에이전트 시스템의 내재된 복잡성과 예측 불가능성에 있습니다.

• 비결정론적 특성: 전통적인 IT 시스템과 달리, 에이전트 시스템에서의 해결책은 에이전트 행동의 확률론적 특성과 복잡한 적응적 상호 작용 때문에 결정론적이고 고립된 수정에 의존할 수 없습니다.
• 2차 효과 및 반복적 교정: 단일 에이전트의 로컬 이상을 해결하는 것은 종종 예상치 못한 2차 효과, 연쇄적인 행동 변화, 그리고 시스템 불안정성으로 이어져, 반복적인 교정 및 다중 턴 유효성 검증을 필요로 합니다.

해결책의 요구 사항:

• 효과적인 해결책은 지속적인 모니터링과 개선을 필요로 하며, 시스템 수준 설계 (예: 중복성, 가드레일, 롤백 전략, 적응 정책)와 모델 수준 개입 (프롬프트 최적화 및 자체 수정 포함)의 조합을 활용해야 합니다.
• 이러한 반복적인 접근 방식은 이상이 의도하지 않은 부작용 없이 진정으로 해결되도록 보장하지만, 지속적인 관찰, 유효성 검증, 시스템적 튜닝을 필요로 하기 때문에 해결 프로세스를 상당히 복잡하게 만듭니다.