AX LABS
← 블로그 사례 기록

첫 에이전트는 운영에서 깨졌다

배포보다 어려운 것은 책임 설계였다

AX LABS 6분 읽기

첫 사내 에이전트를 배포하면 처음 며칠은 분위기가 좋다. 누군가는 문서 초안을 빨리 만들고, 누군가는 회의록을 정리하고, 누군가는 검색 시간을 줄였다고 말한다. 그런데 운영일지가 쌓이면 다른 장면이 보인다. 잘 쓰는 사람만 계속 쓰고, 애매한 요청은 사람에게 되돌아오고, 실패한 답변은 조용히 복사되지 않는다. 문제는 모델 성능이 아니었다. 우리가 배포를 운영으로 착각한 것이 문제였다.

우리는 사용자를 너무 넓게 잡았다

첫 설계에서 우리는 “전 직원이 쓰는 범용 에이전트”를 상상했다. 틀렸다. 범용은 친절해 보이지만 책임이 흐려진다. 사용자마다 기대하는 산출물, 참조해야 할 문서, 금지해야 할 행동이 다르다.

첫 90일이 보여준 것은 단순했다. 에이전트는 조직도 단위가 아니라 업무 단위로 배포해야 한다. 같은 팀 안에서도 리서치, 보고서 초안, 고객 미팅 준비, 내부 규정 확인은 서로 다른 제품이다.

우리가 믿은 것 실제로 필요했던 것
하나의 챗봇이 여러 일을 처리한다 업무별 에이전트가 좁은 책임을 가진다
사용자가 알아서 좋은 프롬프트를 쓴다 입력 양식과 예시가 행동을 만든다
만족도 피드백이면 충분하다 실패 유형 로그가 다음 개선을 정한다

에이전트의 첫 실패는 답변 오류가 아니라, 어떤 일을 맡겼는지 조직이 합의하지 않은 상태에서 시작된다.

정확도보다 에스컬레이션이 먼저였다

우리는 초기에 정확도 평가표를 먼저 만들었다. 그것도 틀렸다. 현장 사용자는 에이전트가 가끔 틀린다는 사실을 이미 안다. 더 큰 문제는 틀렸을 때 무엇이 일어나는지 모른다는 점이다.

사내 에이전트에는 세 가지 경계가 먼저 필요했다.

  • 확정 답변을 해도 되는 질문
  • 근거를 붙여 초안만 내야 하는 질문
  • 사람에게 넘겨야 하는 질문

이 경계가 없으면 에이전트는 편한 업무만 남기고, 위험한 업무는 그림자처럼 현장에 떠넘긴다. Anthropic은 멀티 에이전트 시스템을 제품화하며 조정, 평가, 신뢰성을 핵심 난제로 제시했다. 이 표현은 현장감이 있다. 에이전트는 혼자 똑똑하면 끝나는 도구가 아니라, 실패했을 때 멈추고 넘기는 운영체계다. (anthropic.com)

에이전트는 모델이 아니라 하네스였다

우리가 가장 크게 고친 부분은 프롬프트가 아니었다. context, memory, tool, permission, log, human review를 묶는 하네스였다.

OpenAI의 Responses API는 대화 상태, tool 호출, file search, web search, computer use, function calling을 한 인터페이스로 다룬다. 공식 문서의 방향은 명확하다. 에이전트 운영의 중심이 “질문에 답하는 모델”에서 “외부 시스템과 안전하게 연결되는 실행 구조”로 이동했다. (platform.openai.com) Anthropic도 Claude Agent SDK를 Claude Code의 agent harness에서 출발한 빌딩 블록으로 설명한다. hooks, subagents, MCP 연동은 모델 교체보다 운영 설계에 가까운 주제다. (anthropic.com)

그래서 다음 배포부터는 모델 비교표보다 운영 표준을 먼저 쓴다. 어떤 문서를 context로 넣을지, memory를 어디까지 허용할지, 어떤 tool은 승인 후 실행할지, 어떤 로그를 남길지부터 정한다. 이것이 AX Ops에서 말하는 배포 이후 설계다.

참고: 다음 90일은 운영 설계로 간다

이번 회고의 결론은 짧다. 첫 사내 에이전트는 기술 검증이 아니라 운영 검증이었다. 잘못된 가정은 세 가지였다. 사용자를 넓게 잡았고, 정확도를 먼저 보았고, 하네스를 늦게 설계했다.

다음 90일의 질문은 바뀐다. “더 좋은 모델을 붙일까”가 아니다. “이 에이전트가 어떤 업무를 맡고, 어디서 멈추며, 누가 책임지고, 어떤 로그로 개선되는가”다.

참고 자료:

사내 에이전트를 실험에서 운영으로 넘기려면 배포 계획이 아니라 AX Ops가 필요하다: AX Ops 방법론 →