에이전트 루프를 측정하지 못하면 개선할 수도 없다

AI 회의에서 제일 쉬운 이야기는 결과물 품질이다.

"이번 답변은 더 자연스럽네요."

"새 모델이 확실히 똑똑해 보입니다."

"프롬프트를 조금 바꿨더니 톤이 좋아졌어요."

다 맞는 말일 수 있다. 그런데 회의 끝에 누군가 이렇게 물으면 분위기가 달라진다.

"그래서 이번 주에 무엇이 실제로 나아졌나요?"

많은 에이전트 프로젝트가 여기서 흐려진다. 창업자는 멋진 데모를 보여준다. PM은 최신 출력이 더 좋아 보인다고 말한다. 그로스 운영자는 아웃바운드 초안 시간이 줄었다고 말한다. 다만 애매한 케이스는 여전히 사람이 고친다. 엔지니어는 프롬프트, 입력, 도구, 리뷰 기준이 한 번에 바뀌어서 실패를 재현하기 어렵다고 말한다.

각자 진실을 말하고 있는데도, 팀은 방향을 잡지 못한다.

대부분의 팀은 생성 품질에 과하게 집중한다. 눈에 보이기 때문이다. 답변을 읽을 수 있고, 두 버전을 나란히 놓고 비교할 수 있고, 문장 톤이나 자신감에 대해 토론할 수 있다.

반대로 운영 지표는 덜 화려하다. 이 루프가 안정적인가. 인수인계가 되는가. 실패가 기록되는가. 지난 실행이 다음 실행을 더 낫게 만들었는가. 하지만 에이전트가 제품 업무, 그로스 캠페인, 고객지원, 리서치 요약, 내부 문서에 닿기 시작했다면 바로 그 지표가 실력을 만든다.

주간 에이전트 운영 스코어카드는 복잡한 문제에 대한 단순한 장치다.

제품, 그로스, 엔지니어링이 매주 같은 운영 신호를 보고 같은 언어로 이야기하게 만드는 것.

거창한 벤치마크가 아니다. 40페이지짜리 대시보드도 아니다. 반복 가능한 한 장짜리 스코어카드면 충분하다.

에이전트 루프 전체를 봐야 한다

에이전트 루프는 요청에서 검토된 결과물까지 이어지는 전체 경로다.

캠페인 워크플로라면 고객 노트 수집, 브리프 초안, 주장 검토, 카피 변형, 리뷰 전달, 발행, 결과 기록까지가 루프다. 제품 워크플로라면 사용자 피드백 요약, 테마 묶기, 근거 연결, 로드맵 옵션 초안, 사람의 판단이 필요한 지점 표시까지가 루프다.

모델의 답변은 그중 한 부분일 뿐이다.

팀이 통제력을 잃는 곳은 보통 나머지 부분이다.

• 입력 형식이 매번 다르다.
• 작업 정의가 조용히 바뀐다.
• 리뷰어마다 기준이 다르다.
• 실패를 사람이 몰래 고치고 기록하지 않는다.
• 도구 오류를 제품 신호가 아니라 일회성 불편으로 넘긴다.
• 프롬프트 수정, 모델 변경, 워크플로 변경 중 무엇이 개선을 만들었는지 모른다.

그래서 "결과물이 좋아졌다"만으로는 부족하다. 무엇보다 좋아졌나? 어떤 입력에서? 어떤 작업 기준으로? 사람이 얼마나 고쳤나? 리뷰 시간은 줄었나, 늘었나?

이 질문에 답하지 못하면 개선 루프가 아니다. 좋은 사례 모음에 가깝다.

너무 늦게 측정하는 것들

AI 팀은 종종 에이전트가 꽤 그럴듯해진 뒤에야 측정을 붙인다. 아직 워크플로가 바뀌는 중인데 굳이 지표를 만들 필요가 있나 싶다.

오히려 바뀌는 중이기 때문에 필요하다.

스코어카드가 없으면 모든 변화가 이야기로 남는다. 모델이 좋아졌다. 프롬프트가 나빠졌다. 예시가 도움이 됐다. 이번 주 리뷰어가 더 엄격했다. 입력이 더 지저분했다. 다 사실일 수 있다. 하지만 무엇이 결과를 만든 건지 알 수 없다.

처음부터 완벽한 지표는 필요 없다. 대화가 덜 흐릿해지면 된다.

우선 사람이 매주 실제로 모을 수 있는 운영 지표부터 시작하자.

1. 완료된 실행 수. 워크플로가 끝까지 몇 번 돌았나?

2. 리뷰 통과율. 큰 수정 없이 통과한 출력은 몇 퍼센트인가?

3. 개입률. 정상 리뷰 지점에 도달하기 전에 사람이 끼어든 경우는 얼마나 많았나?

4. 수정 시간. 통과한 결과물도 평균적으로 얼마나 손봐야 했나?

5. 실패 분류. 가장 많이 실패한 이유는 무엇인가? 맥락 부족, 약한 추론, 근거 없는 주장, 포맷 문제, 도구 오류, 정책 불일치, 불명확한 작업 정의 중 어디인가?

6. 근거 연결. 출력이 주장을 할 때 원문이나 워크플로 맥락으로 돌아갈 수 있었나?

7. 변경 메모. 이번 주에 무엇이 바뀌었나? 프롬프트, 예시, 도구, 모델, 정책, 라우팅, 리뷰 루브릭, 입력 소스 중 무엇인가?

이 일곱 줄이면 주간 리뷰가 훨씬 쓸모 있어진다.

질문도 건강해진다. "어떤 모델이 제일 좋지?"에서 "지금 루프의 병목은 어디지?"로 옮겨간다.

가끔 답은 모델이다. 하지만 생각보다 자주, 그렇지 않다.

예시: 고객지원 티켓 분류

고객지원 팀이 에이전트로 인바운드 티켓을 분류한다고 해보자.

데모는 좋아 보인다. 에이전트가 티켓을 읽고, 카테고리를 정하고, 짧은 요약을 쓰고, 다음 액션을 제안한다. 매니저는 깔끔한 예시 다섯 개를 보고 말한다. "이거 시간 줄이겠네요."

실제 첫 주는 더 지저분하다.

어떤 고객은 긴 로그를 붙여 넣는다. 어떤 고객은 화난 한 문장만 보낸다. 어떤 티켓은 결제, 버그, 해지 의도가 한 메시지에 섞여 있다. 에이전트는 입력이 애매해서 카테고리를 틀리기도 하고, 카테고리는 맞췄지만 고객의 긴급함을 요약에서 지워 버리기도 한다. 지원 리드는 결과를 고치지만, 그 수정은 큐 도구 안에 남고 에이전트를 개선하는 팀에게 전달되지 않는다.

스코어카드가 없으면 주간 대화는 감상에 가까워진다.

"쉬운 티켓에서는 도움 됐어요."

"아직 리뷰를 많이 해야 해요."

"새 프롬프트가 더 나은 것 같아요."

"팀이 아직 믿지는 못해요."

모두 필요한 관찰이다. 하지만 우선순위를 정하기에는 부족하다.

같은 워크플로를 스코어카드로 보면 달라진다.

• 완료 실행 420건.
• 1차 리뷰 통과율 61%.
• 리뷰 전 사람 개입 18%.
• 통과한 출력도 평균 수정 시간 90초.
• 가장 큰 실패 분류는 복합 의도 티켓.
• 주문 번호 근거 연결은 강하지만 정책 문구 근거 연결은 약함.
• 이번 주 변경: 예시 3개 추가, 카테고리 목록 축소, 모델 변경 없음.

이제 제품, 고객지원, 엔지니어링, 그로스가 같은 화면을 본다.

제품은 복합 의도 티켓을 따로 다뤄야 한다는 것을 본다. 고객지원은 리뷰 기준을 더 명확히 정할 수 있다. 엔지니어링은 도구 접근이나 라우팅을 바꿔야 하는지 판단할 수 있다. 그로스는 어려운 케이스에서 루프가 검증되기 전까지 "에이전트 기반 고객지원 자동화" 같은 표현을 조심할 수 있다.

스코어카드가 에이전트를 바로 똑똑하게 만들지는 않는다. 대신 개선이 가능해진다.

주간 리뷰는 짧고 반복 가능해야 한다

좋은 스코어카드는 지루할 만큼 단순해야 오래 간다.

매주 30분이면 충분하다. 워크플로 담당자, 기술 담당자, 비즈니스 결과를 이해하는 사람을 한 명씩 앉힌다. 고객에게 영향을 주는 루프라면 고객 리스크에 가장 가까운 사람도 포함한다.

아젠다는 매주 같게 둔다.

1. 숫자를 먼저 읽는다. 아직 해석하지 않는다. 실행 수, 통과율, 개입률, 수정 시간, 주요 실패 분류만 본다.

2. 예시 세 개를 본다. 좋은 출력 하나, 애매한 출력 하나, 실패 하나. 반드시 원본 입력을 같이 둔다.

3. 병목을 하나 고른다. 입력 품질, 작업 정의, 도구 접근, 리뷰 기준, 정책, 모델 행동, 인수인계 중 어디인가?

4. 변경은 하나만 선택한다. 다음 주에 의미 있는 변화 하나를 준다. 다섯 가지를 한꺼번에 바꾸고 배웠다고 말하지 않는다.

5. 가설을 쓴다. "복합 의도 라우트를 추가하면 결제와 버그가 섞인 티켓의 개입률이 내려갈 것이다." 이런 문장이 중요하다.

6. 이상한 사례를 남긴다. 노이즈가 아니다. 팀이 배우는 재료다.

이 리듬이 생기면 에이전트 개선은 취향 토론에서 운영 루틴으로 바뀐다.

임원에게도 더 좋은 신호를 준다. 쉬운 케이스에서 92% 통과하지만 엣지 케이스마다 사람이 끼어드는 워크플로와, 현재 통과율은 70%지만 실패 분류가 매주 줄어드는 워크플로는 다르다. 후자가 더 오래가는 역량에 가까울 수 있다.

단순한 운영 지표가 모델 과열보다 강하다

모델 변경을 추적하는 것이 잘못은 아니다. Cursor의 에이전트 커스터마이징 가이드나 공개 cookbook 같은 자료만 봐도, 팀들이 고립된 채팅을 넘어 더 구조화된 워크플로로 이동하고 있다는 흐름은 분명하다. 모델, 도구, 규칙, 실행 맥락은 모두 중요하다.

다만 주간 스코어카드는 팀이 진짜 일을 보게 만든다.

수정 시간이 높은 이유가 작업 정의의 애매함이라면, 모델 업그레이드는 더 자신감 있는 애매함을 만들 수 있다. 근거 연결이 약한 이유가 소스가 붙지 않기 때문이라면, 좋은 프롬프트만으로는 빈틈을 막기 어렵다. 프롬프트와 리뷰 루브릭을 동시에 바꾼 뒤 통과율이 떨어졌다면, 생각보다 배운 것이 적을 수 있다.

운영 지표는 혁신을 막는 장치가 아니다. 혁신이 안개처럼 흩어지지 않게 잡아 주는 장치다.

목표는 에이전트가 완벽하다는 것을 증명하는 게 아니다. 다음에 무엇을 고칠지 아는 것이다.

이번 주에 할 일

이미 중요한 에이전트 워크플로 하나를 고르자. 제일 화려한 데모 말고, 누군가 의존하거나 불평하거나 몰래 손으로 고치는 것.

한 장짜리 주간 스코어카드를 만든다.

1. 워크플로 이름과 담당자를 정한다.
2. 작업을 한 문장으로 정의한다.
3. 대표 입력 다섯 개를 저장한다.
4. 실행 수, 통과율, 개입률, 수정 시간을 기록한다.
5. 모든 실패에 분류 태그를 붙인다.
6. 모든 워크플로 변경을 평범한 말로 적는다.
7. 매주 예시 세 개를 리뷰한다.

2주만 지나도, 한 달 동안 모델 이야기만 한 팀보다 더 많은 것을 알게 된다.

프롬프트가 문제일 수도 있다. 입력 계약이 깨졌을 수도 있다. 리뷰어들이 "좋다"의 기준에 합의하지 못했을 수도 있다. 에이전트가 더 많이 하는 게 아니라 덜 해야 한다는 결론이 나올 수도 있다.

어떤 발견이든 쓸모 있다. 추측보다 낫다.

Elevate는 어디에 있나

Elevate는 AI 작업이 검토 가능하고, 반복 가능하고, 개선하기 쉬운 운영 습관이 되도록 돕고 있다.

출발점은 Prompt Studio다. 프롬프트 작업을 개인의 시행착오가 아니라 팀의 공유된 운영 방식으로 바꾸기 위한 공간이다. 목적은 프로세스를 잔뜩 늘리는 것이 아니다. 버전을 비교하고, 유용한 예시를 가까이 두고, 정책과 작업을 분리하고, 지난 실행이 다음 실행을 더 똑똑하게 만들도록 돕는 것이다.

에이전트 루프가 중요하다면 매주 측정하자.

대시보드가 멋져 보여서가 아니다. 자기 루프를 볼 수 있는 팀만 그 루프를 개선할 수 있기 때문이다.

대기명단에 참여하기 ->