AI 에이전트가 다양한 실제 환경에서 안정적으로 작동하려면 예기치 못한 상황과 오류, 오작동을 관리해야 합니다. 사람이 예상치 못한 장애물에 적응하듯, 지능형 에이전트에도 문제를 감지하고 복구 절차를 시작하거나, 최소한 통제된 방식으로 실패를 처리하는 견고한 시스템이 필요합니다.
예기치 않은 상황에 대응할 수 있다는 점은 AI 시스템이 단지 지능적이라는 데 그치지 않고 안정적이고 신뢰할 만하다는 뜻이며, 이 덕분에 실제 배포와 운영 결과에 대한 신뢰도도 높아진다.
4장의 리플렉션과 함께 쓰이기도 합니다. 첫 시도가 실패해 예외가 발생하면, 리플렉션 과정에서 실패 원인을 분석한 뒤 더 나은 프롬프트 같은 개선된 접근으로 작업을 다시 시도해 오류를 해결할 수 있습니다.
패턴 개요 — 세 단계
① 오류 감지 → ② 오류 처리 → ③ 복구
① 오류 감지
운영상 문제가 발생할 때 이를 면밀히 식별하는 과정입니다. 구체적으로는 이런 신호들입니다.
- 유효하지 않거나 형식이 맞지 않는 도구 출력
- 404(Not Found)나 500(Internal Server Error) 같은 특정 API 오류 코드
- 서비스나 API의 비정상적으로 긴 응답 시간
- 예상 형식에서 벗어나는 일관성 없고 무의미한 응답
나아가 다른 에이전트나 전문 모니터링 시스템을 활용해 이상을 선제적으로 탐지하면, 문제가 커지기 전에 잠재 문제를 포착할 수 있습니다.
② 오류 처리
오류가 감지되면, 신중하게 설계된 대응 계획이 반드시 필요하다.
| 전략 | 내용 |
|---|---|
| 로깅 | 추후 디버깅과 분석을 위해 오류 정보를 로그에 자세히 기록한다 |
| 재시도 | 작업이나 요청을, 필요하면 파라미터를 조금 조정해 다시 시도한다. 특히 일시적 오류에서 유효하다 |
| 폴백 | 대안 전략이나 방법을 활용해 일부 기능이라도 유지한다 |
| 점진적 기능 축소 | 완전한 복구가 즉시 불가능한 경우, 에이전트가 일부 기능을 유지하여 최소한의 가치를 제공한다 |
| 알림 | 사람의 개입이나 협업이 필요한 상황에서 인간 운영자나 다른 에이전트에게 알린다 |
③ 복구
오류 발생 이후 에이전트나 시스템을 안정적이고 작동 가능한 상태로 되돌리는 과정입니다.
- 상태 롤백: 오류의 영향을 되돌리기 위해 최근 변경이나 트랜잭션을 롤백한다.
- 원인 조사: 재발을 방지하려면 오류 원인을 철저히 조사해야 한다.
- 자기 교정과 재계획: 동일한 오류를 반복하지 않도록 에이전트의 계획·로직·파라미터를 조정한다.
- 이관: 복잡하거나 심각한 경우에는 문제를 인간 운영자나 상위 시스템으로 이관하는 편이 최선일 수 있다.
이처럼 견고한 예외 처리와 복구 패턴을 구현하면, 취약하고 불안정한 AI 에이전트를 신뢰할 수 있는 구성 요소로 바꿀 수 있다. 그 결과 에이전트는 까다롭고 예측하기 어려운 환경에서도 효과적으로, 또 회복력 있게 작동할 수 있다.
실제 적용과 활용 사례
| 사례 | 어떤 실패를, 어떻게 |
|---|---|
| 고객 서비스 챗봇 | 고객 데이터베이스가 일시적으로 중단된 상태라면 그대로 멈춰서는 안 된다. API 오류를 감지하고 사용자에게 일시적인 문제를 알린 뒤, 나중에 다시 시도해 보라고 안내하거나 상담원에게 이관한다 |
| 자동 금융 거래 | 트레이딩 봇이 “잔액 부족”이나 “장 마감” 오류를 만나면, 오류를 로깅하고 같은 무효 거래를 반복 시도하지 않으며, 필요하면 사용자에게 알리거나 전략을 조정한다 |
| 스마트 홈 자동화 | 네트워크 문제나 기기 오작동으로 조명을 켜지 못하면, 실패를 감지하고 재시도하며, 그래도 안 되면 수동 조작을 권한다 |
| 데이터 처리 에이전트 | 손상된 파일을 만나면 건너뛰고 오류를 로깅한 뒤 나머지 파일 처리를 계속 진행하며, 전체 프로세스를 끝까지 처리한 후 마지막에 건너뛴 파일 목록을 보고한다 |
| 웹 스크래핑 에이전트 | CAPTCHA, 변경된 웹사이트 구조, 404·503 서버 오류에 일시 중지하거나 프락시를 사용하거나 실패한 특정 URL을 보고하는 방식으로 대응한다 |
| 로보틱스와 제조 | 로봇 팔이 정렬 불량으로 부품을 집지 못하면, 센서 피드백으로 실패를 감지하고 위치를 다시 맞춘 뒤 재시도하며, 문제가 계속되면 운영자에게 알리거나 다른 부품으로 작업 대상을 바꾼다 |
요컨대 이 패턴은 단순히 지능적일 뿐 아니라 실제 환경의 복잡성 앞에서도 신뢰할 수 있고 회복력이 있으며 사용자 친화적인 에이전트를 구축하는 바탕이 된다.
데이터 처리 에이전트의 “건너뛰고 계속 진행한 뒤 마지막에 보고” 방식이 특히 실용적입니다. 하나의 실패가 전체 배치를 중단시키지 않게 하는 설계입니다.
ADK 실습 — SequentialAgent로 폴백 체인 만들기
도구 호출이 실패했을 때 에이전트가 어떻게 대응하는지 보여 주는 예제입니다. 실패는 잘못된 도구 입력이나 도구가 의존하는 외부 서비스의 문제에서 비롯될 수 있습니다.
from google.adk.agents import Agent, SequentialAgent
# 에이전트 1: 기본 도구를 시도한다. 역할이 명확하고 한정적이다.
primary_handler = Agent(
name="primary_handler",
model="gemini-2.0-flash-exp",
instruction="""
Your job is to get precise location information.
Use the get_precise_location_info tool with the user's provided address.
""",
tools=[get_precise_location_info]
)
# 에이전트 2: 폴백 처리기 역할을 하며, 상태를 확인하여 동작을 결정한다.
fallback_handler = Agent(
name="fallback_handler",
model="gemini-2.0-flash-exp",
instruction="""
Check if the primary location lookup failed by looking at state["primary_location_failed"].
- If it is True, extract the city from the user's original query
and use the get_general_area_info tool.
- If it is False, do nothing.
""",
tools=[get_general_area_info]
)
# 에이전트 3: 상태에 저장된 최종 결과를 사용자에게 제시한다.
response_agent = Agent(
name="response_agent",
model="gemini-2.0-flash-exp",
instruction="""
Review the location information stored in state["location_result"].
Present this information clearly and concisely to the user.
If state["location_result"] does not exist or is empty, apologize
that you could not retrieve the location.
""",
tools=[] # 이 에이전트는 최종 상태에 대해서만 추론한다.
)
# SequentialAgent는 각 처리기가 정해진 순서대로 실행되도록 보장한다.
robust_location_agent = SequentialAgent(
name="robust_location_agent",
sub_agents=[primary_handler, fallback_handler, response_agent]
)
구조가 명확합니다.
| 에이전트 | 역할 |
|---|---|
primary_handler |
get_precise_location_info 도구로 정확한 위치 정보를 가져오려고 시도한다 |
fallback_handler |
백업 역할. state["primary_location_failed"] 상태 변수를 확인해 1차 조회가 실패했는지 판단하고, 실패했다면 질의에서 도시 정보를 추출해 get_general_area_info를 쓴다 |
response_agent |
시퀀스의 마지막. 상태에 저장된 위치 정보를 검토해 최종 결과를 제시하고, 찾지 못했으면 사과 메시지를 전달한다 |
주목할 점은 폴백 판단이 상태 변수로 이루어진다는 것입니다. 각 에이전트는 서로를 직접 호출하지 않고 공유 상태를 읽고 쓰며 협력합니다. response_agent가 도구 없이 오직 최종 상태만 보고 추론한다는 점도 깔끔한 분리입니다.
이 구조를 쓰면 위치 정보를 단계적으로 나누어 조회할 수 있다.
정확한 주소를 못 찾으면 대략적인 지역 정보라도 주는 것 — 앞서 본 점진적 기능 축소가 실제 코드로 구현된 모습입니다.
정리
예외 처리와 복구란 무엇인가
AI 에이전트는 실제 환경에서 운영될 때 필연적으로 예기치 못한 상황, 오류, 시스템 오작동에 직면합니다. 이러한 문제는 도구 장애, 네트워크 문제부터 유효하지 않은 데이터까지 다양하며, 에이전트의 작업 완수 능력을 위협합니다. 이를 관리할 체계적인 방법이 없으면 에이전트는 취약하고 불안정해지며, 예상치 못한 난관 앞에서 완전히 실패하기 쉽습니다. 이 불안정성 때문에, 일관된 성능이 필수인 중요하거나 복잡한 애플리케이션에는 에이전트를 배포하기 어려워집니다.
왜 사용하는가?
이 패턴은 에이전트에게 운영 장애를 예측하고 관리하며 복구하는 에이전틱 역량을 갖추게 합니다. 도구 출력과 API 응답을 모니터링하는 선제적 오류 감지부터, 진단을 위한 로깅·일시적 장애에 대한 재시도·폴백 메커니즘 활용 같은 사후 대응 전략까지 포괄합니다. 더 심각한 문제에는 안정 상태로 되돌리기, 계획을 조정하는 자기 교정, 인간 운영자에게 문제를 이관하는 절차 등 복구 프로토콜을 정의합니다.
언제 사용해야 하는가?
이 패턴은 동적인 실제 환경에 배포되는 모든 AI 에이전트에 적용한다. 시스템 장애, 도구 오류, 네트워크 문제, 예측 불가능한 입력이 발생할 수 있고 운영 신뢰성이 핵심 요건인 환경이 여기에 해당한다.
“모든 에이전트에 적용한다”는 표현이 눈에 띕니다. 다른 패턴들이 “이럴 때 쓰라”고 조건을 다는 것과 달리, 이 패턴은 선택 사항이 아니라는 뜻입니다.
핵심 정리
- 예외 처리와 복구는 견고하고 신뢰할 수 있는 에이전트를 구축하는 데 반드시 필요하다.
- 이 패턴은 오류를 감지하고, 유연하게 처리하며, 복구 전략을 구현하는 과정을 포함한다.
- 오류 감지에는 도구 출력 검증, API 오류 코드 확인, 타임아웃 활용 등이 포함될 수 있다.
- 처리 전략에는 로깅, 재시도, 폴백, 점진적 기능 축소, 알림이 포함된다.
- 복구는 진단, 자기 교정, 이관을 통해 안정적인 운영 상태를 되찾는 데 초점을 맞춘다.
- 이 패턴을 적용하면 에이전트가 예측 불가능한 실제 환경에서도 효과적으로 작동할 수 있다.
마치며
이 패턴은 AI 에이전트가 예상치 못한 문제를 어떻게 식별하고 관리하며, 적절히 대응하고, 안정적인 운영 상태로 복구하는지를 다룹니다. 여러 도메인의 활용 사례는 실제 환경의 복잡성과 잠재 장애를 다루는 데 이 패턴이 얼마나 유용한지 보여 주며, 예외 처리 역량이 에이전트의 신뢰성과 적응력에 어떻게 기여하는지 잘 보여 줍니다.
11장이 “목표를 향해 제대로 가고 있는가”를 물었다면, 12장은 “가다가 넘어지면 어떻게 하는가” 를 다룹니다. 두 패턴이 합쳐져야 에이전트가 자율적으로 오래 돌아갈 수 있습니다.
참고 문헌
- McConnell, S. (2004). Code Complete (2nd ed.). Microsoft Press.
- O’Neill, V. (2022). Improving Fault Tolerance and Reliability of Heterogeneous Multi-Agent IoT Systems Using Intelligence Transfer. Electronics, 11(17), 2724.
- Shi, Y., Pei, H., Feng, L., Zhang, Y., & Yao, D. (2024). Towards Fault Tolerance in Multi-Agent Reinforcement Learning. arXiv preprint arXiv:2412.00534.