AI 시대의 프로덕트 매니저 09｜실행자에서 편성자로: 당신의 새 일은 agent 무리를 지휘하는 것

가장 일 잘하는 사람들이 요즘 어떻게 일하는지부터 봅시다.

그들은 여러 agent를 동시에 돌립니다——각 agent가 자기 맥락 창을 가지고, 자기가 맡은 한 덩어리, 자기 파일 범위를 가진 채 비동기로 돌아가고, 사람은 그 위에서 일을 쪼개고 나눠 준 뒤 잠시 후에 돌아와 검수합니다. 더 이상 하나의 AI가 한 문장씩 실시간으로 코드 고치는 걸 지켜보지 않습니다. Addy Osmani는 이 두 방식을 아주 또렷하게 갈라 놓습니다. 하나는 지휘자입니다. 하나의 agent를 데리고 실시간으로 일하니, 당신의 머리가 곧 천장입니다. 다른 하나는 편성자입니다. 손안에 agent 한 무리를 쥐고, 계획하고 나눠 주고 한참 뒤에 돌아와 점검하니, 산출량이 더 이상 당신 한 사람의 대역폭에 발목 잡히지 않습니다.

이건 프로덕트 매니저에게 좋은 소식입니다. 「편성」이야말로 바로 프로덕트 매니저의 본업이기 때문입니다——큰 목표 하나를 여러 작업으로 쪼개, 서로 다른 사람에게 나눠 주고, 각 덩어리의 경계를 지켜보다가, 마지막에 검수해 합치는 것. 다만 예전엔 사람을 편성했다면, 이제는 agent 한 무리가 더해졌을 뿐입니다. 기계적인 조율(진척 재촉, 요구사항 반복 설명, 포맷 맞추기)은 agent가 가져갔고, 편성의 판단력은 남았으며, 오히려 더 값져졌습니다. 아래는 그대로 따라 할 수 있는 네 가지 행동입니다.

1. 더 이상 하나의 agent를 처음부터 끝까지 붙잡지 마라

가장 흔한 낭비는, AI를 당신이 처음부터 끝까지 지켜봐야 하는 인턴처럼 다루는 것입니다. 한마디 던지고, 다 할 때까지 기다리고, 한 번 보고, 다시 다음 한마디를 던지는 식이죠. 당신의 주의력이 곧 그것의 상한이고, 한 번에 한 가지만 밀어붙일 수 있습니다.

편성자의 방식은 정반대입니다. 하나의 작업에서 서로 의존하지 않는 세 덩어리가 나온다면, 세 개의 agent를 동시에 열어 각자 한 덩어리씩 맡기고 병렬로 돌립니다. 「하나를 실시간으로 붙어 있기」에서 「잠시 후에 셋을 거두기」로 바뀌는 겁니다. 처음엔 익숙하지 않을 겁니다. 「한 걸음 한 걸음 내가 다 봐야 한다」는 집착을 내려놓아야 하니까요——하지만 바로 이 지점이 산출량이 몇 배로 뛰는 곳입니다.

2. 일을 경계가 겹치지 않는 병렬 덩어리로 쪼개라

편성의 첫째 공부는 일을 쪼개는 것입니다. 잘 쪼갰는지 아닌지가, 이 agent 무리가 당신을 돕는지 아니면 성가시게 하는지를 곧장 결정합니다.

병렬로 넘길 수 있는 한 덩어리는 두 가지를 만족해야 합니다. 서로 의존하지 않을 것(A가 B의 결과를 기다릴 필요가 없을 것), 그리고 경계가 겹치지 않을 것(두 agent가 동시에 같은 걸 고치며 부딪치지 않을 것). 예를 들어 어떤 기능 하나를 만들 때 「백엔드 API」「프런트엔드 페이지」「이 부분의 테스트」 세 덩어리로 쪼개 세 agent에게 나눠 줄 수 있습니다. 하지만 「먼저 데이터베이스를 설계하고, 그다음 그것에 의존하는 API를 쓴다」는 병렬로 할 수 없으니, 순서대로 이어서 해야 합니다. 쪼개기 전에 먼저 물어보십시오. 이 두 덩어리가 각자 독립적으로 끝까지 될 수 있나? 안 된다면, 억지로 병렬로 묶지 마십시오.

3. 덩어리마다 분명한 spec을 줘라

이것이 편성에서 가장 치명적인 한 고리이고, 05편에서 다룬 그 일이 여기서 증폭된 버전이기도 합니다. Addy Osmani는 직설적으로 말합니다. 모호한 지시 하나는 agent 한 무리의 실수로 증폭되고, 정확한 지시 하나는 agent 한 무리의 정확한 구현으로 증폭된다고.

하나의 agent를 데리고 있을 때 지시가 흐릿해 하나가 틀리면, 당신은 그 자리에서 고칠 수 있습니다. 하지만 다섯을 동시에 파견하면서 저마다 똑같이 흐릿한 지시를 쥐여 주면, 다섯 몫이 어긋나고, 당신이 돌아와 거둘 때는 다섯 몫을 다 뒤집어 다시 해야 합니다. 그러니 일을 파견하기 전에, 05편의 그 방법을 쓰십시오——형용사를 숫자로 바꾸고, 상태를 빠짐없이 적고, 경계와 「하지 않을 것」을 분명히 나열하고——그런 다음 하나씩 내보내십시오. 많이 파견할수록 spec의 정밀도는 배로 증폭됩니다. 옳은 방향으로든, 그른 방향으로든.

4. 당신의 일은 쪼개기, 검수, 그리고 엮기로 바뀐다

agent가 「그것을 만들어 내기」를 가져가고 나면, 당신 손에 남는 건 더 무거운 세 가지입니다. 시작에서 일을 옳게 쪼개고, 중간에 분명한 경계를 주고, 끝에서 여러 덩어리를 거둬 검수해 하나의 전체로 엮는 것.

여기서 가장 저지르기 쉬운 실수는, 손이 근질거려 어떤 agent가 원래 할 수 있는 일에 스스로 뛰어드는 것입니다——당신이 어느 한 덩어리의 구현 세부에 빠져드는 순간, 전체 판의 편성은 멈춰 섭니다. 편성자는 「위에」 머물러야 합니다. 각 덩어리가 되돌아온 게 맞는지 지켜보고(08편의 방법을 써서, 먼저 밑을 까게 하고 당신이 검수하고), 그것들을 하나로 이어 붙여 전체가 통하는지 봐야 합니다. 당신의 가치는 어느 한 덩어리를 손수 썼는지가 아니라, 이 agent 무리가 합쳐서 내놓은 것이 성립하는지로 판가름 납니다.

오늘 해볼 수 있는 한 가지. 당신이 막 하려던, 게다가 쪼갤 수 있는 작업을 하나 골라, 서로 의존하지 않는 두세 덩어리로 잘라 각각 agent를 열어 시켜 보십시오. 당신은 세 가지만 하십시오——쪼개기, spec 주기, 거두기. 「셋을 동시에 밀어붙이기」와 「하나씩 이어서 하기」가 어디서 다른지, 먼저 한 번 체감해 보십시오.

더 읽어보기

• Addy Osmani 《The future of agentic coding: conductors to orchestrators》(지휘자 vs 편성자, 정확한 spec의 배증 효과): https://addyosmani.com/blog/future-agentic-coding/
• 이 시리즈의 05편 요구사항을 분명히 말하지 못하면, AI가 당신 대신 멋대로 채워 넣는다 (spec의 정밀도)
• 이 시리즈의 08편 진짜 문제를 찾는 일은 AI가 대신해 주지 못한다 (검수 전에 먼저 밑을 까게 하기)