AI 에이전트 100개 운영 노하우: 에이전트 우선 UX와 이벤트 기반 실행, 평가 체계 만들기

핵심 메시지

• 모델이 계속 좋아지고 값이 싸지면서 지능 자체는 더 이상 병목이 아니며, 병목은 만든 에이전트를 클라우드에서 안정적으로 굴리는 인프라로 옮겨 갔다.
• UX 디자이너가 사람만 생각하는 사이 다음 사용자는 에이전트가 됐다. 화면에 있는 모든 기능을 API나 MCP 같은 에이전트 친화적 인터페이스로도 쓸 수 있어야 한다.
• 채팅은 여러 모달리티 중 하나일 뿐이며, 대부분의 에이전트는 사람이 말을 걸어야 움직이는 대신 이벤트에 반응해 배경에서 돌아가야 한다.
• 가장 큰 실수는 평가 없이 에이전트를 손보며 시간을 쓴 것이었다. 오프라인 평가셋에서 시작해 실제 운영 데이터로 확인하고, 그 데이터를 다시 평가셋으로 되돌리는 순환이 필요하다.
• 에이전트판 '쓰라린 교훈'은 새로 나온 모델을 빠르게 갈아 끼울 수 있는 일반적인 방법이 결국 이긴다는 것이다.

쉽게 이해하기

이 발표는 관측 도구 회사 데이터독에서 AI 에이전트 팀을 꾸린 경험에서 출발한다. 회사가 먼저 만든 것은 문제가 생기면 스스로 원인을 조사하는 SRE 에이전트, 발견한 오류를 코드로 고치는 개발 에이전트, 의심스러운 보안 신호를 사람 대신 들여다보는 보안 분석 에이전트 세 가지다. 발표자는 지난해만 해도 '기업 에이전트의 30% 미만만 제대로 동작한다'는 이야기가 돌았지만, 올해는 실제로 운영에 올려 시간을 아끼는 회사가 눈에 띄게 늘었다고 말한다.

첫 번째 교훈은 사용자 경험을 다시 정의하라는 것이다. 디자이너는 여전히 사람만 염두에 두고 화면을 다듬지만, 앞으로의 사용자 상당수는 자동화된 에이전트다. 문서를 마크다운으로 제공하고 LLMs.txt를 두는 정도는 지금 당장 할 수 있는 일이며, 나아가 화면에서 할 수 있는 모든 기능을 목록으로 훑어 브라우저 없이도 접근 가능한지 점검해야 한다. 발표자는 이를 과거의 '베조스 API 명령'에 빗대어, 팀마다 기능을 에이전트가 쓸 수 있는 인터페이스로 열어야 한다고 표현한다.

두 번째는 반응형이 아니라 능동형으로 만들라는 것이다. 개발자가 매일 쓰는 코딩 에이전트를 빼면, 대부분의 에이전트는 사람이 명령할 때가 아니라 사건이 발생할 때 스스로 깨어나야 한다. 배경에서 오래 도는 에이전트는 반드시 실패하고 시간 초과를 겪으므로 중단 지점부터 이어서 재개하는 내구성 있는 실행 기반이 필요하고, 권한이 새어 나가지 않도록 샌드박스에 가둬야 한다.

세 번째이자 가장 강조된 것은 평가다. 초기에는 잘 도는 것처럼 보이는 에이전트를 만들어 놓고 평가 기준 없이 도구를 붙였다 뗐다 하며 시간을 흘려보냈다고 한다. 권하는 순서는 작더라도 실제 사용자 행동을 대표하고 반복 실행이 가능한 오프라인 평가셋을 먼저 만들고, 운영 중 쌓이는 관측 데이터로 실제 환경에서의 품질을 확인한 뒤, 그 트레이스에 좋았는지 나빴는지와 어떤 도구를 썼어야 했는지를 주석으로 달아 다시 평가셋으로 되돌리는 것이다.

나머지 교훈은 협업과 유연성, 그리고 앞으로의 방향이다. 동료가 만든 에이전트의 도구와 스킬을 볼 수 없으면 배울 수 없으므로 팀 단위로 공유하고 조합할 수 있는 허브가 필요하고, 사람이 중간에 개입해 교정하는 흐름도 설계에 넣어야 한다. 모델과 프레임워크는 서로 앞서거니 뒤서거니 하므로 한쪽에 묶이지 말고 자체 평가셋으로 빠르게 갈아 끼우되, 모델이 바뀌어도 축적한 지식이 남도록 메모리를 따로 관리하라는 조언이 이어진다. 전망으로는 일하면서 배우는 강화학습, 제품을 본뜬 합성 환경, 며칠씩 도는 장시간 에이전트, 에이전트 권한 위임, 컴퓨터 조작과 음성, 그때그때 만들어지는 생성형 UI가 꼽혔다.

주요 인사이트

• '에이전트가 내 서비스를 쓸 수 있는가'는 이제 접근성 점검 항목처럼 다뤄야 한다. 사람 손으로만 되는 기능이 남아 있으면 그 기능은 자동화에서 통째로 빠진다.
• 발표자는 팀에게 직접 에이전트를 통해 업무를 처리해 보라고 시킨다. 사람이 손으로 하면서 고객은 에이전트로 쓸 것이라고 가정하면 실제 경험이 어떤지 알 수 없기 때문이다.
• 평가를 나중으로 미루면 개선인지 퇴보인지 모른 채 튜닝하게 된다. 평가 설계는 에이전트를 바꾸기 전에 먼저 정해 두는 것이 비용이 가장 적게 든다.
• 모델을 고정하면 편하지만, 특정 작업에서 최고인 모델과 일반 지표에서 최고인 모델은 다르다. 모델 교체를 전제로 설계하고 자체 평가셋으로 판단하는 편이 안전하다.
• 모델이 바뀌어도 남는 자산은 축적된 맥락이다. 사용자와 팀의 상호작용에서 의미 있는 지식을 뽑아내고 오래된 맥락은 정리하는 별도의 계층이 필요하다.

자주 묻는 질문

관련 AI 소식