AI 에이전트를 잘 쓰려면 프롬프트를 잘 써야 한다고 생각하는 분이 많습니다. 그런데 8개의 에이전트 팀을 2개월간 직접 운영한 Unwind AI 발행인 Shubham Saboo는 정반대의 결론을 내렸습니다. 성과를 가르는 건 기술 역량이 아니라 관리 역량이라는 것입니다.

Unwind AI 뉴스레터에 발행된 이 글은 저자가 직접 에이전트 팀을 운영하며 겪은 실수와 그로부터 발견한 패턴을 담고 있습니다. 그리고 에이전트를 가장 잘 관리할 수 있는 직군이 바로 PM이라는 주장으로 이어집니다.
출처: Best AI PMs in 2026 Will Be Agent Managers – Unwind AI
에이전트를 망치는 3가지 관리 실수
저자가 2개월간 에이전트 팀을 운영하며 발견한 실수들은 신입 관리자들이 사람 팀에서 반복하는 실수와 거의 동일합니다.
첫째, 과잉 명세화. 리서치 에이전트 Dwight에게 처음에는 “이 5개 소스를 이 순서대로 검색하고, 이 템플릿으로 결과를 작성하라”는 식의 세세한 지침을 줬습니다. 결과물은 딱딱하고 중요한 내용을 놓쳤습니다. 지침을 절차 대신 원칙으로 바꿨습니다. “개발자가 오늘 당장 쓸 수 있는 도구만 다뤄라. 모든 주장을 검증하라. 기업 홍보성 뉴스는 건너뛰어라.” 이것만으로 출력 품질이 즉시 올라갔습니다.
둘째, 너무 이른 포기. Dwight는 초기 2주 동안 읽을 만한 기사 7개를 추려야 할 때 47개를 넘겼습니다. 대부분의 사람은 이 시점에 에이전트를 포기합니다. 저자는 버텼고, 나쁜 결과물 하나하나를 교정 데이터로 쌓았습니다. 2주 후 단 하나의 규칙을 메모리에 저장했습니다. “독자가 오늘 당장 뭔가를 할 수 없다면 건너뛰어라.” 그 한 문장이 47개를 7개로 만들었습니다.
셋째, 모든 에이전트를 같은 방식으로 관리하기. 리서치 에이전트에게는 엄격한 제약이 필요합니다. 반면 콘텐츠 에이전트에게는 창의적 자유가 필요합니다. 리서치 에이전트의 관리 방식을 콘텐츠 에이전트에게 그대로 적용하면, 문법적으로는 맞지만 읽고 싶지 않은 글이 나옵니다.
교정이 쌓이는 구조
저자의 에이전트 팀이 작동하는 방식은 이렇습니다. 각 에이전트는 세션이 시작될 때 정체성, 역할, 원칙, 운영 지침이 담긴 파일 묶음을 불러옵니다. 저자가 에이전트 결과물을 검토하다 패턴을 발견하면 피드백을 줍니다. 에이전트는 그 교정을 자신의 파일에 직접 반영합니다. 다음 세션부터 그 수정이 자동으로 적용됩니다.
여기에 공유 레이어가 있습니다. 한 에이전트에게 “항상 출처 링크를 포함하라”고 하면, 그 교정이 모든 에이전트가 읽는 공유 피드백 로그에 기록됩니다. 한 번의 교정이 팀 전체로 전파됩니다. 저자는 이를 “프롬프팅이 아니라 관리”라고 부릅니다.
결과는 복리처럼 쌓입니다. 1일 차에는 모든 것을 수정합니다. 10일 차에는 엣지 케이스만 수정합니다. 30일 차에는 90%는 바로 쓸 수 있는 결과물이 나옵니다. 이 곡선은 신입 직원 온보딩과 동일합니다. 첫 달은 손해, 둘째 달은 본전, 셋째 달부터 독립적으로 돌아갑니다.
PM이 이미 갖고 있는 역량
저자가 PM을 에이전트 관리의 최적 직군으로 꼽는 이유는 분명합니다. PM은 자신이 만들지 않은 결과물을 검토하고, 다음에도 통하는 피드백을 주고, “이게 출시할 만한 수준인가”를 판단하는 일을 커리어 내내 해왔기 때문입니다.
에이전트 관리에서 요구되는 역량을 PM의 언어로 옮기면 이렇습니다. 문제 정의가 에이전트 역할 설계가 되고, 컨텍스트 관리가 파일 엔지니어링이 되고, 이해관계자 조율이 에이전트 간 작업 순서 관리가 됩니다. 그리고 피드백은 영구적으로 쌓입니다. 같은 피드백을 두 번 줄 필요가 없습니다.
저자는 에이전트 운영의 진화를 세 단계로 구분합니다. 에이전트를 도구로 쓰는 1단계, 에이전트 팀이 본인 대신 만들어주는 2단계, 에이전트가 다른 에이전트를 관리하는 3단계. 각 단계에서 병목은 모델 성능이 아니라 그 위에 얹힌 관리 레이어입니다. 저자 자신의 에이전트 팀이 실제로 어떻게 돌아가는지 더 궁금하다면 원문에서 직접 확인할 수 있습니다.

답글 남기기