현장에서 에이전트 PoC가 멈추는 지점은 비슷하다. 첫 주에는 답이 나온다. 둘째 주에는 예외가 쌓인다. 셋째 주에는 같은 실수가 반복된다. 이때 팀은 프롬프트를 더 길게 쓴다. 그러나 길어진 프롬프트는 운영 지식이 아니라 응급 처방이다.
에이전트가 일하는 조직에서는 실패가 자산이다. 단, 실패가 채팅 로그로만 남으면 아무것도 바뀌지 않는다. 실패를 분류하고, 원인을 찾고, 다음 실행의 프롬프트와 메모리에 반영하는 폐쇄 루프가 있어야 한다.
실패 로그는 대화 기록이 아니라 개선 재료다
자기개선 루프의 출발점은 “무엇이 실패했는가”를 기계와 사람이 함께 읽을 수 있게 남기는 것이다. LangChain은 2026년 에이전트 평가 체크리스트에서 실제 trace를 모아 도메인 전문가와 실패 원인을 분류하라고 권한다. 분류 항목도 프롬프트 문제, 도구 설계 문제, 모델 한계, 도구 실패, 데이터 공백처럼 조치 가능한 단위여야 한다. (langchain.com)
실패 로그에는 최소한 다섯 가지가 들어간다.
- 사용자 의도와 기대 결과
- 실제 결과와 어긋난 지점
- 호출한 도구, 인자, 반환값
- 사용한 프롬프트·메모리·retrieval 버전
- 사람이 남긴 교정 또는 재현 조건
이 정도가 없으면 “환각이 있었다”는 말만 남는다. 그 말로는 아무 프롬프트도 고칠 수 없다.
갱신 대상은 프롬프트와 메모리로 나눠야 한다
에이전트가 실패에서 배웠다고 말하려면 어디가 바뀌었는지 보여야 한다. OpenAI의 2026년 사내 data agent 사례는 corrections나 특정 데이터 질문의 nuance를 memory로 저장해 다음 답변의 출발선을 높인다고 설명한다. 동시에 지속적으로 변하는 에이전트에는 평가 루프가 없으면 회귀가 보이지 않는다고 못박는다. (openai.com)
| 실패 원인 | 갱신 위치 | 예시 조치 |
|---|---|---|
| 지시가 모호함 | 프롬프트 | 판단 기준, 금지 조건, 종료 조건 추가 |
| 반복되는 업무 규칙 | 메모리 | 고객별 예외, 데이터 필터, 용어 정의 저장 |
| 도구 사용 오류 | 도구 스키마 | 인자명, 예시, validation 강화 |
| 검색 문서 오류 | retrieval 계층 | 문서 버전, 출처 우선순위, 폐기 규칙 수정 |
프롬프트는 행동 규칙이다. 메모리는 업무 맥락이다. 둘을 섞으면 위험해진다. “다음부터 이 고객은 이 기준으로 계산한다”는 메모리다. “계산 근거를 제시하지 못하면 답하지 말라”는 프롬프트다.
자기개선은 에이전트가 마음대로 자신을 고치는 기능이 아니다. 실패를 근거로 제한된 변경을 제안하고, 검증 후 승격하는 운영 절차다.
메모리 쓰기는 반드시 문을 통과해야 한다
메모리는 강력하지만 위험하다. Microsoft는 2026년 6월 agentic memory safety 문서에서 persistent memory가 일시적 위협을 지속적 위협으로 바꾼다고 설명한다. hallucination도 저장되면 반복되고, prompt injection도 memory에 들어가면 다음 세션까지 영향을 준다. (learn.microsoft.com)
따라서 실패 기반 자기개선 루프에는 write gate가 필요하다.
- 에이전트는 변경안을 직접 반영하지 않고 제안한다.
- 제안은 출처, 실패 trace, 영향 범위를 포함한다.
- domain owner가 승인하거나 반려한다.
- 승인된 변경은 eval dataset에 추가된다.
- 배포 후 회귀가 보이면 즉시 rollback한다.
2026년 7월 발표된 memory prompt injection 연구도 persistent memory가 prompt injection의 threat model을 바꾼다고 지적한다. 유용한 적응을 포기할 필요는 없다. 대신 memory update 자체를 보호해야 한다. (arxiv.org)
운영 루프가 없으면 자기개선은 표류한다
최근 연구는 실패한 trajectory를 버리지 않고 진단·수정·검증에 쓰는 failure-driven self-improvement를 다룬다. 핵심은 실패를 데이터로 바꾸는 것이다. (arxiv.org) Anthropic도 Claude Code의 hooks가 main context 밖에서 이벤트 기반 handler를 실행할 수 있다고 설명한다. 이런 harness는 실패 수집, 사전 차단, compaction 전 백업 같은 운영 루프를 붙이는 지점이 된다. (claude.com)
AX Ops에서 우리는 자기개선 루프를 기능 목록으로 보지 않는다. 로그 스키마, 실패 taxonomy, 변경 승인권자, eval 기준, 배포·롤백 경로를 한 장의 운영 설계로 묶는다. 에이전트가 똑똑해지는 순간은 모델 교체 때가 아니다. 같은 실패를 두 번 하지 않도록 조직이 루프를 닫을 때다.
자기개선 에이전트를 만들려면 먼저 실패 로그가 어디에 쌓이고, 누가 읽고, 무엇을 바꿀지 정해야 한다. 이 설계부터 시작하려면 AX Ops 방법론 →
참고
- OpenAI, “Inside OpenAI’s in-house data agent”, 2026. https://openai.com/index/inside-our-in-house-data-agent/
- LangChain, “Agent Evaluation Readiness Checklist”, 2026. https://www.langchain.com/blog/agent-evaluation-readiness-checklist
- LangChain, “Improve agent quality with Insights Agent and Multi-turn Evals, now in LangSmith”, 2025. https://www.langchain.com/blog/insights-agent-multiturn-evals-langsmith
- Microsoft Learn, “Manage memory safety in agentic systems”, 2026. https://learn.microsoft.com/en-us/security/zero-trust/sfi/manage-agentic-memory-safety
- Anthropic, “Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents”, 2026. https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more
- arXiv, “Learning from Failure: Inference-Time Self-Improvement for Computer-Use Agents”, 2026. https://arxiv.org/abs/2606.31270
- arXiv, “Bad Memory: Evaluating Prompt Injection Risks from Memory in Agentic Systems”, 2026. https://arxiv.org/abs/2607.14611
