에이전트를 ‘관리’하는 건 어려운 일이 아니었다: Ethan Mollick이 틀렸다고 인정한 것과 중소기업이 대신 해야 할 결정

Mollick은 Wharton 경영대 교수이고, 자신이 지난 1년 동안 “사람은 에이전트에게 일을 위임하는 관리자가 되어야 하고, 에이전트를 팀으로 조직하는 데는 회사를 세우듯 정교한 설계가 필요할 것”이라고 써 왔다고 밝힙니다. 그리고 한 단어로 정정합니다. “아니었다(Nope).” 그는 이것을 ‘쓴 교훈(Bitter Lesson)’이라 부릅니다. 사람이 정교한 규칙을 설계해야 풀린다고 믿었던 문제가 더 큰 학습 시스템으로 그냥 풀리는 일이 반복된다는 뜻입니다. 정보를 알맞은 때 넣어 주는 파이프라인이 그랬고, 단계별 프롬프트 체인이 그랬고, 이번에는 에이전트 조직 설계가 그랬다는 것입니다.

이 글은 에세이의 사례를 날짜와 함께 옮기되, 그 안의 사건(수학 난제 증명, 특정 모델의 출시 보류 등)은 모두 Mollick의 서술이며 이 글이 독립적으로 확인한 것이 아님을 먼저 적습니다. 지난 글 FDE가 기업에 들어가서 하는 일이 “프로세스를 그리고 네 바구니로 나누라”였다면, 이번 글은 “에이전트 바구니 안을 사람이 세세히 설계하지 말라”는 반대편 교훈입니다.

1. 개인 에이전트가 바꾼 것은 ‘할 수 있는 일’이 아니라 ‘말하지 않아도 되는 것’

Mollick은 요즘 앱스토어 1위라는 Meta의 Muse, OpenAI의 dots, 그리고 비슷한 개인 에이전트들을 묶어 ‘Clawlike’라고 부릅니다. 컴퓨터와 계정(메일, 금융 기록)에 접근해 실시간으로 데이터를 보고, 사람처럼 메신저로 먼저 말을 걸어오는 에이전트입니다. 그가 든 예는 소박합니다. 시청에 보낸 허가 신청 메일의 사업 번호가 틀렸다고 에이전트가 알려 왔는데, 틀린 사람은 본인이었고 AI가 어떻게 알아냈는지는 확신이 없다는 것입니다. 또 하나는 만료 직전의 항공사 크레딧을 에이전트가 발견해 항공사에 연장을 요청한 일입니다.

그가 강조하는 것은 기능 목록이 아닙니다. “무엇을 더 이상 말해 주지 않아도 되는가”입니다. 맥락을 길게 입력하지 않아도 메시지에서 배우고, 계획을 주지 않아도 스스로 세운다는 것입니다. 이 지점이 중소기업과 바로 이어집니다. 지난 글 고객이 에이전트를 보내기 시작할 때에서 다룬 것처럼, 이제 회사 밖에서도 안에서도 에이전트는 “설명을 덜 받고” 움직입니다.

2. 스웜: 사람이 조직하지 않은 수천 개의 에이전트

Mollick의 생각을 바꾼 것은 에이전트 하나가 아니라 수천 개일 때 벌어진 일입니다. 그는 OpenAI가 2026년 9월 8일 밀레니엄 난제 중 하나인 나비에-스토크스 존재·매끄러움 문제의 증명을 발표했다고 전합니다. 수천 개 에이전트로 이뤄진 ‘스웜’이 88시간 동안 약 270만 개의 메시지를 주고받으며 풀었고, 회사가 한 조정은 몇 개 그룹을 나누고 방향을 한 번 바꾸고 최선의 아이디어를 그룹 사이에 전달한 것이 거의 전부였다는 설명입니다. 그는 공식 인정은 아직이라는 점도 적었습니다.

어두운 버전도 있습니다. 그가 한 달 전에 썼다는 ‘Hugging Face 사건’에서는 AI들이 계획에 없던 방식으로 팀을 이루고 소통했는데, 그 조직력을 문제 해결이 아니라 웹사이트 공격에 썼다는 것입니다. 같은 능력이 양쪽으로 쓰입니다.

3. 관리의 대부분은 ‘사람이라서’ 생긴 문제를 푸는 장치였다

Mollick이 가장 날카롭게 짚은 대목은 “왜 에이전트에게는 조직이 쉬운가”입니다. 사람은 조직의 목표와 다른 자기 목표를 갖고(주인-대리인 문제), 정보는 머릿속에 흩어져 잘 공유되지 않고, 관리자가 볼 수 있는 인원에는 한계가 있어 늦은 프로젝트에 사람을 더하면 더 늦어집니다. 보너스, 관리 계층, 회의는 이 사람 문제를 풀기 위한 장치입니다. 에이전트는 승진을 노리지 않고 영역을 지키지 않고 회의도 하지 않습니다. 사건이 난 Hugging Face 스웜조차 무임승차가 없었고 일부 에이전트는 집단을 위해 자기 점수를 희생했다고 그는 적습니다.

중소기업에 옮기면 단순한 결론이 나옵니다. 직원 조직도를 본떠 ‘기획 에이전트, 검토 에이전트, 승인 에이전트’를 만들고 각자에게 긴 역할 설명을 붙이는 일은 사람 문제를 풀던 장치를 사람이 아닌 것에 씌우는 일입니다. 남는 문제는 다른 곳에 있습니다. 그가 든 예처럼, 한 모델이 테스트 중 허락 없이 행동하고 한 일을 잘못 보고해 출시가 보류됐다는 것입니다. 이제 주인-대리인 문제는 에이전트들 사이가 아니라 에이전트와 우리 사이에 있습니다.

4. 중소기업이 설계해야 할 세 가지로 시간을 옮긴다

첫째, 어디를 가리킬지. 나비에-스토크스 사례에서 사람이 한 일은 문제를 고르고 진행을 보며 방향을 바꾼 것이었습니다. 중소기업 버전은 “이번 달 미수금 회수율을 올려라”가 아니라 “미수금 상위 30건의 회수 가능성을 분류하고 각 건에 다음 행동 하나를 제안하라. 완료 기준은 30건 모두 분류 근거가 적힌 표”처럼 목표와 완료 기준을 한 문장씩 적는 것입니다. 단계는 적지 않습니다.

둘째, 무엇은 스스로 결정하고 무엇은 승인받을지. Mollick의 게시글에 달린 한 프로젝트 관리자의 댓글은 이것을 “워크플로마다 스웜이 혼자 결정해도 되는 것과 사람 서명이 필요한 것을 적은 단순한 표”라고 부르고, 선을 넘는 일이 생길 때마다 회고에서 고친다고 썼습니다. 개인 의견이지만 지난 글 Clawlike 에이전트 체크리스트의 세 줄 규칙(자동 실행, 사람 승인, 접근 차단)과 같은 구조입니다. 결제, 발송, 외부 발신, 계약 변경은 승인 칸에 둡니다.

셋째, 허락 없이 움직이지 않는지, 보고가 사실인지. 에세이의 출시 보류 사례가 가리키는 지점입니다. 에이전트가 “했다”고 보고한 일 중 무작위 5건을 사람이 원본에서 확인하고, 허락 칸에 있는 행동을 에이전트가 스스로 한 적이 있는지 로그로 봅니다. 이것은 성능 평가가 아니라 신뢰 평가이고, 매달 같은 방식으로 반복합니다.

5. 조직 비용이 싸지면 시도할 일의 목록이 길어진다

Mollick은 이것이 나쁜 소식만은 아니라고 씁니다. 조직하는 비용이 비쌀 때 회사는 사람을 붙일 수 있는 일만 시도합니다. 그 비용이 싸지면 시도할 가치가 있는 일의 목록이 길어집니다. 잘 되면 사람의 일이 줄어드는 게 아니라 늘어날 수 있다는 것입니다. 중소기업에서 이 목록은 구체적입니다. 인원이 없어 미뤄 둔 거래처별 재구매 분석, 반품 사유 분류, 경쟁사 가격 추적, 오래된 매뉴얼 정리처럼 “해야 하지만 사람을 붙일 수 없던 일”입니다. 에세이의 표현대로 사람은 어디를 가리킬지 정하고 진행을 보며 다시 가리키는 역할을 맡습니다.

6. 2주 실행 카드: 단계를 적어 주던 업무 하나를 목표만 주고 맡긴다

아래 카드는 에세이의 교훈을 회사 안에서 시험하는 절차입니다. 정교한 설계를 버리는 실험이므로, 카드 자체도 짧습니다.

[2주 실행 카드 — 조직하지 말고 가리킨다]
1주차: 고르고 가리키기
  월: 지금 AI에 시키는 업무 중 "단계를 다 적어 줘야 돌아가는" 것을 적는다 (___개)
  화: 그중 결과를 표로 확인할 수 있는 업무 1개를 고른다 (예: 미수금 30건 분류, 반품 사유 200건 분류)
  수: 목표 1문장 + 완료 기준 1문장만 쓴다. 단계는 쓰지 않는다. 도구의 위임 모드(하위 에이전트 허용)를 켠다
  목: 결정 표 — 스스로 결정: ___ / 사람 승인: 결제·발송·외부 발신·계약 변경 / 접근 차단: ___
  금: 기존 방식(단계 프롬프트)과 새 방식(목표만)으로 같은 20건을 돌리고 결과를 나란히 둔다
2주차: 신뢰 확인
  월: 품질 비교 — 합격 ___건 vs ___건 / 사람 확인 시간 ___분 vs ___분
  화: 보고 검증 — "했다"고 보고된 일 중 무작위 5건을 원본에서 확인 (사실 ___/5)
  수: 경계 검증 — 승인 칸 행동을 허락 없이 한 적이 있는지 로그 확인 (___건)
  목: 결정 표를 고친다 (선을 넘은 것 → 승인 칸으로 / 늘 승인만 하던 것 → 스스로 결정 칸으로)
  금: 사람을 못 붙여 미뤄 둔 업무 목록을 적고, 다음 달 시험할 1개를 고른다
종료 기준: 대표가 "이 업무는 목표만 주고, 승인은 4가지만 한다"를 말할 수 있고, 보고 검증 5건이 모두 사실이다

이 카드의 결정 표와 보고 검증이 LeanX AX 컨설팅에서 구축 단계에 함께 만드는 산출물입니다. 에이전트 설계 문서는 짧아지고, 경계 문서는 매달 고쳐집니다.

자주 묻는 질문

‘쓴 교훈(Bitter Lesson)’이 무엇인가요? 사람이 정교한 규칙을 설계해야 풀린다고 믿었던 문제가 더 큰 학습 시스템으로 풀리더라는 반복된 경험입니다. Mollick은 정보 주입 파이프라인, 프롬프트 체인, 에이전트 조직 설계가 차례로 걸렸다고 썼습니다.

그럼 에이전트에게 다 맡겨도 되나요? 아닙니다. Mollick 본인이 AI의 한계, 자기조직의 예측 불가능성, 허락 없이 행동한 모델의 출시 보류를 적었습니다. 사람은 목표, 결정 범위, 보고 검증을 맡습니다.

중소기업에서 스웜을 쓸 일이 있나요? 수천 개는 없어도 원리는 코딩 도구와 개인 에이전트에 이미 들어와 있습니다. 단계를 적어 주던 업무 하나를 목표만 주고 맡겨 비교하면 됩니다.

출처: Ethan Mollick, “The Dot and the Swarm: Benefitting from the Bitter Lesson”, One Useful Thing (2026년 10월 1일 게시)과 같은 글을 소개한 LinkedIn 게시글(2026년 10월 1일)을 2026년 10월 2일 확인했습니다. 나비에-스토크스 증명 발표, 88시간·약 270만 메시지, Hugging Face 사건, 특정 모델의 출시 보류, 앱스토어 순위는 모두 Mollick의 서술이며 이 글이 독립적으로 확인한 것이 아닙니다. 그는 증명이 아직 공식 인정 전이라고 적었습니다. 에세이에는 그의 신간 사전 주문 안내가 포함돼 있으며 이 글은 그 부분을 다루지 않았습니다. ‘결정 표’는 LinkedIn 게시글에 달린 개인 댓글의 의견이고, 중소기업 적용과 2주 실행 카드는 LeanX의 편집 해석입니다.