이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Agent는 일반 LLM 호출과 무엇이 다른가?
- agent를 운영 서비스에 붙일 때 어떤 위험이 생기는가?
- read-only agent와 write-capable agent는 어떻게 다르게 다뤄야 하는가?
개요
Agent는 모델이 목표를 달성하기 위해 계획하고, tool을 선택하고, 결과를 보고 다음 행동을 결정하는 구조다. LangGraph, AutoGen, CrewAI 같은 framework는 agent workflow를 구성하는 데 도움을 준다.
하지만 운영 서비스에서는 agent의 자율성을 제한하고 관측해야 한다.
Agent 구성 요소
- LLM
- system instruction
- tool catalog
- memory 또는 state
- planner
- executor
- evaluator
- trace recorder
이 중 tool과 state가 들어가면 일반 모델 호출보다 위험이 커진다.
위험
- 무한 loop
- 잘못된 tool 선택
- 권한 없는 tool 호출
- write tool 중복 실행
- token 비용 폭증
- tool result prompt injection
- trace 재현 어려움
코드로 이해하기
agent 실행 제한을 설정으로 둔다.
agent:
name: support-agent
max_steps: 6
max_tool_calls: 4
timeout_seconds: 30
max_cost_usd: 0.20
write_tools_require_approval: true이 제한은 기능 요구사항만큼 중요하다.
백엔드 설계 판단
- agent가 read-only인가 write 가능한가?
- tool별 권한은 사용자 권한과 연결되는가?
- agent가 실패하면 어떤 상태로 끝나는가?
- 중간 결과를 저장해야 하는가?
- 사람이 승인할 단계가 있는가?
장애 상황과 대응
agent가 같은 tool을 반복 호출하면 즉시 max step을 낮추고 trace를 확인한다. write tool 중복 실행이면 idempotency와 audit log를 먼저 본다.
인프라 협업 포인트
agent는 tool call fan-out을 만들 수 있다. 인프라팀과 max tool call, expected QPS, worker concurrency, trace volume을 공유한다.
실전 팁
- read-only agent부터 시작한다.
- write tool은 draft 생성과 approval로 나눈다.
- agent trace는 최종 답변보다 중요하다.
- agent framework 도입 전 workflow를 종이에 그린다.
위험 신호!
- max step이 없다.
- write tool에 idempotency가 없다.
- agent가 관리자 권한 tool을 가진다.
- tool call trace가 없다.
확인 질문
확인 질문
- agent가 일반 LLM 호출보다 위험한 이유는 무엇인가?
- 여러 step과 tool 호출을 통해 실제 외부 상태에 영향을 줄 수 있기 때문이다.
- read-only agent부터 시작하는 이유는 무엇인가?
- 정보 조회만으로 위험을 낮추고 agent 행동을 관찰할 수 있기 때문이다.