누가 한가한지가 아니라 작업의 형태(Shape)에 따라 40개의 백로그 항목을 분류했을 때 발생한 변화

지난주 두 명의 Fortune 500 기업 경영진이 정상 회담 무대에 서서 한 가지 질문에 대해 상반된 답변을 내놓았습니다. AI 에이전트(AI agent)는 동료인가, 아니면 도구인가?

한 명은 자신의 에이전트에 이름을 붙이고 리뷰 회의에 참석시킵니다. 다른 한 명은 그들을 동료라고 부르지 않습니다. 저는 이 논쟁을 지켜보며, 제가 한참 전에 이미 그 명칭(noun)에 대해 신경 쓰는 것을 그만두었다는 사실을 깨달았습니다. 왜냐하면 그 명칭이 월요일에 제가 백로그(backlog)를 처리하는 방식을 단 한 번도 바꾸지 않았기 때문입니다.

그래서 제가 실제로 바꾼 것, 그리고 그 과정에서 문제가 발생한 부분에 대해 말씀드리겠습니다.

기존의 기본 방식: 누가 한가한지에 따라 분류하기

수년 동안 저의 계획 루프(planning loop)는 동일했습니다. 해야 할 일을 살펴보고, 누가 여유(capacity)가 있는지 확인한 뒤, 할당하는 것이었습니다. 단위는 언제나 사람이었습니다. "누가 한가한가"가 첫 번째 질문이었습니다.

루프에 에이전트가 등장했을 때, 저는 그저 용량 테이블(capacity table)에 또 다른 행으로 끼워 넣었을 뿐입니다. 질문은 동일했고, 이름만 하나 더 늘어난 셈이었습니다. 이것이 실질적인 "도구"로서의 답변입니다. 에이전트는 더 빠른 손일 뿐이며, 다음에 할 일에 에이전트를 지정하기만 하면 됩니다.

이 방식은 작동하다가 어느 순간 작동하지 않게 되었습니다. 에이전트는 사람이 범위를 제대로 설정(scope)해야 하는 작업을 기꺼이 가져가서 그럴듯한 결과물을 만들어냈고, 저는 두 단계 뒤에 가서야 그 그럴듯한 결과물이 잘못되었다는 것을 알게 되었습니다. 그 잘못된 것을 바로잡는 데 반나절을 허비해야 했습니다.

변화된 방식: 형태(Shape)에 따라 먼저 분류하기

저는 순서를 뒤집었습니다. 누가 한가한지 보기 전에, 백로그를 _형태(shape)_에 따라 분류합니다.

두 개의 버킷(bucket)이 있습니다. 사람 형태의 작업(Person-shaped work)은 판단력이 필요하고, 모호함 속에 존재하며, 취향이나 글로 적을 수 없는 관계에 의존합니다. 에이전트 형태의 작업(Agent-shaped work)은 정의되어 있고, 반복 가능하며, 게이트(gate, 검증 단계)를 둘 수 있습니다. 즉, 입력(input), 출력(output), 그리고 통과해야 할 검증 항목을 설명할 수 있는 작업입니다.

여기서 핵심적인 규율은 에이전트의 작업 범위를 채팅 프롬프트(chat prompt)가 아니라 계약자의 작업 명세서(SOW, Statement of Work)처럼 작성하는 것입니다.

# 에이전트 작업 범위 — 분위기(vibe)가 아닌 SOW처럼 정의됨
task: 업데이트된 OpenAPI 명세(spec)로부터 API 클라이언트 재생성
input:
...

만약 gate와 output을 깔끔하게 채울 수 없다면, 그것은 신호입니다. 이 작업은 아직 에이전트 형태가 아니라는 것입니다. 그것은 제가 단순히 내 업무 부담을 덜고 싶어서 잘못 분류하려 했던, 사람 형태의 작업입니다.

저는 이 과정을 약 40개의 백로그 항목 (backlog items)에 적용해 보았습니다. 기존의 "누가 한가한가"라는 기준에 따라 에이전트 (agent)에게 넘겼을 작업 중 약 3분의 1이 형태 (shape) 테스트를 통과하지 못했고, 다시 사람에게로 돌아갔습니다.

무엇이 깨졌는가

두 가지가 깨졌으며, 두 가지 모두 유익했습니다.

첫째, 어떤 업무가 "중요한가"에 대한 저의 감각이 깨졌습니다. 저는 자동화하기에는 너무나 결정적이라며 한 더미의 작업들을 지켜왔었습니다. 하지만 그중 절반은 제가 정서적으로 애착을 가졌던, 단지 정의된 작업일 뿐이었습니다. 그것들은 에이전트 버킷 (agent bucket)으로 깔끔하게 분류되었고 문제없이 실행되었습니다. 제가 그 작업들에 부여했던 상태 (status)는 작업이 아닌 저 자신에 관한 것이었습니다.

둘째 — 그리고 이 부분은 제가 과소평가했던 것인데 — 게이트 (gate)의 품질은 그것을 지켜보는 사람의 역량만큼만 유지됩니다. 에이전트를 팀 동료처럼 대하기 시작하면, 그 결과물을 덜 주의 깊게 검토하게 된다는 연구 결과가 있습니다. 대상을 이름 붙이는 행위가 경계심을 낮추는 것입니다. 따라서 "동료"라는 프레임워크 (framing)는 따뜻함이 아니라, 조용한 책임감의 누수 (accountability leak)입니다. 저는 에이전트가 "최근에 신뢰할 만했기 때문에" 통과되는 게이트를 무심코 승인(rubber-stamping)하고 있는 제 자신을 발견했습니다. 도구는 신뢰를 얻지 못합니다. 신뢰는 매 실행 (run)마다 수행되는 업무를 통해 얻어지는 것입니다.

이에 딱 맞는 오래된 격언이 있습니다: "지루한 것을 자동화하면, 인간은 그저 실패 모드 (failure modes)를 관리하게 된다." 이것은 인간의 업무가 격하되는 것이 아닙니다. 이제 실패 모드 자체가 업무입니다. 에이전트가 감당할 수 없는 부분을 관리하는 것이 남겨진 업무이며, 그것이 복리로 쌓여가는 업무입니다.

이것이 단순한 워크플로우 (workflow)의 문제가 아닌 커리어의 문제인 이유

자신의 에이전트들에게 이름을 붙여준 그 임원(exec)은 또한 가장 어려운 부분은 기술이 아니라 관리자 (managers)라고 말했습니다. 저는 그 말이 정확히 옳다고 생각하며, 이는 양면성을 가집니다.

만약 관리자가 병목 현상 (bottleneck)이라면, 관리자는 동시에 레버리지 (leverage)이기도 합니다. 앞으로 보상을 가져다줄 기술은 프롬프트 작성 (prompt-writing)이 아닙니다. 그 기술의 하한선은 계속 낮아지고 있습니다. 대신, 업무 더미를 보고 어떤 부분이 사람 형태 (person-shaped)인지, 그리고 어떤 부분을 범위 설정 (scope)하고 게이트 (gate)를 설정하여 실행하게 둘 수 있는지 빠르게 판단하는 오래된 기술이 중요해집니다. 이것이 바로 "제너럴리스트의 황금기 (golden age of the generalist)"의 에너지입니다. 전문화 비용 (specialization tax)이 낮아질 때, 판단력을 보유하면서 동시에 업무를 설계할 수 있는 사람이 승리합니다.

무대 위의 경영진들에게는 실무자가 없었기에, 그들은 레이블(label)을 두고 논쟁했습니다. 레이블은 결코 리더십의 문제가 아니었습니다. 문제는 업무(work)였습니다.

그래서 저는 여러분이 어디에 도달했는지 궁금합니다. 에이전트(agent)가 여러분의 루프(loop) 안에 있을 때, 여전히 누가 한가한지를 기준으로 계획을 세우시나요, 아니면 업무의 형태(shape)를 기준으로 먼저 분류하기 시작하셨나요? 그리고 게이트(gate)가 여러분에게 무언가를 통과시켜 놓은 지점은 어디인가요?