Ethan Mollick(emollick)이 최근 실험 결과를 공유했습니다. AI 에이전트에게 3시간 6분짜리 복잡한 지식 작업을 맡겼더니 약 80%를 자율적으로 처리했다는 내용입니다.

처음엔 AI가 좋아졌다는 이야기로 읽힙니다. 저는 이 숫자에서 다른 것을 봤습니다.

80%에서 무슨 일이 생긴 걸까요

에이전트가 80%에서 멈춘 이유는 두 가지입니다.

첫째, 모델이 스스로 “완료”라고 판단할 기준이 없었습니다. 에이전트는 전진하려면 무엇이 완성된 상태인지를 알아야 합니다. “초안을 작성한다”가 목표라면 초안이 나오는 순간 완료입니다. “검토 가능한 초안을 작성한다”가 목표라면 검토자가 읽을 수 있는 형식, 근거 레퍼런스, 자기진단 체크까지 포함됩니다.

둘째, 에이전트는 80% 지점에서 스스로 불확실하다는 것을 인식했습니다. 최근 연구에서 확인된 것처럼, 모델은 내부적으로 낮은 확신도를 가지면서도 출력에서 이를 드러내지 않는 경향이 있습니다. 에이전트가 멈춘 건 능력이 없어서가 아니라 다음 단계로 넘어가기 위한 승인 신호가 설계되지 않았기 때문입니다.

이건 기술 문제가 아닙니다. 설계 문제입니다.

PM이 빠뜨린 것: 완료 기준

저는 PM으로 20년 일하면서 이 패턴을 반복해서 봐왔습니다.

기능 명세서는 씁니다. 유저 스토리도 씁니다. 그런데 “이 작업이 완료됐다는 것을 어떻게 확인하는가”를 명시하는 PM은 드뭅니다. 사람 개발자라면 코드 리뷰와 QA 과정에서 누군가가 채워줬습니다. 에이전트에게는 그 과정이 없습니다.

에이전트 시대 PM KPI의 이동은 여기서 시작됩니다.

  • 기존 KPI: 기능을 제 기한에 냈는가
  • 새 KPI: 긴 자율 작업이 끝까지 완료될 설계를 했는가

이 두 질문은 겉으로 비슷해 보이지만, 설계에서 완전히 다른 출력물을 요구합니다.

완료 기준 설계: 3가지 패턴

100 Agents 운영을 통해 확인한 에이전트 장기 작업의 완료 기준 설계 패턴 세 가지입니다.

1. Evidence 정의

에이전트가 “됐다”고 말하려면 무엇을 남겨야 하는가를 명시합니다. 단순 결과물이 아니라 검증 가능한 아티팩트를 요구합니다. “보고서를 작성했다”가 아니라 “보고서 + 핵심 주장 3개 + 각 주장의 출처 링크”처럼 완료 증거를 구체화합니다.

2. Handoff Point 명시

사람이 개입해야 하는 지점을 미리 설계합니다. “외부 API를 호출하기 직전”, “최종 발송 직전”, “예산 초과 가능성을 감지했을 때” 같은 조건으로 인계 지점을 정의합니다. 에이전트가 스스로 결정하게 두는 범위와 사람이 확인해야 하는 범위를 사전에 경계로 그어두는 겁니다.

3. 자기진단 루프

에이전트가 완료를 선언하기 전에 스스로 체크리스트를 실행하도록 설계합니다. “초기 목표에서 벗어나지 않았는가”, “추가 확인이 필요한 가정이 있는가”, “사용자에게 물어봐야 할 것이 있는가”를 반드시 거치게 합니다.

이 세 가지는 에이전트를 더 똑똑하게 만드는 것이 아닙니다. 에이전트가 멈추지 말아야 할 곳에서 멈추지 않도록, 그리고 멈춰야 할 곳에서 반드시 멈추도록 경계를 설계하는 작업입니다.

PM의 산출물이 바뀐다

emollick의 3시간 6분 실험이 시사하는 것은 하나입니다.

에이전트 시대 PM의 1차 산출물은 기능 명세서에서 실행 계약서로 이동합니다. 무엇을 만드는가뿐만 아니라, 어떻게 완료됐다고 판단하는가, 어디서 사람이 개입하는가, 어떤 증거를 남겨야 하는가를 명시하는 문서입니다.

AI가 3시간짜리 작업을 80%까지 자율 처리하는 시대가 됐습니다. 나머지 20%를 누가 설계하느냐가 PM 차별화의 새 축이 되고 있습니다.

당신의 팀에서 가장 최근에 에이전트에게 맡긴 작업의 완료 기준은 어떻게 정의돼 있습니까?