여럿이면 빠르다는 상식

이 책에서 가장 길게 이야기하고 싶은 고정관념이 이것입니다. 멀티 에이전트를 쓰면 일의 능률이 오를 것이라는 믿음입니다. 너무 당연해서 의심하기 어렵지만, 뚜껑을 열어 보면 그렇지 않은 경우가 많았습니다.

1. 왜 우리는 그렇게 믿을까

이 믿음은 우리가 사람과 일하며 얻은 경험에서 옵니다. 혼자 하면 열흘 걸릴 일도 다섯 명이 나누면 이틀이면 끝날 것 같습니다. 회사는 일을 나누어 맡기는 방식으로 돌아가고, 큰 프로젝트일수록 사람을 더 붙입니다. 그러니 AI도 여럿이 나누어 맡으면 더 빨리, 더 잘할 것이라고 생각하는 것은 자연스럽습니다.

여기에 화면이 주는 인상이 더해집니다. 에이전트 하나가 일하는 화면보다 여러 에이전트가 동시에 돌아가는 화면이 훨씬 바빠 보입니다. 기획 담당 에이전트가 일을 나누고, 개발 담당 에이전트 여럿이 동시에 코드를 쓰고, 검토 담당 에이전트가 결과를 확인하는 구조는 그림으로 그려 놓으면 잘 짜인 회사 조직도처럼 보입니다.

도구도 이 방향으로 움직였습니다. 하위 에이전트를 부르는 기능, 여러 세션을 동시에 띄우는 기능, 에이전트끼리 팀을 이루게 하는 기능이 차례로 나왔습니다. 많은 개발자가 여기에 열광했습니다. 에이전트를 몇 개씩 동시에 돌렸다는 자랑이 쏟아졌습니다.

2. 사람의 분업에도 숨은 비용이 있었다

그런데 사람의 분업을 다시 떠올려 보면, 그것도 공짜가 아니었습니다.

소프트웨어 공학에는 오래된 말이 있습니다. 프레더릭 브룩스(Frederick Brooks)는 1975년 『맨먼스 미신』(The Mythical Man-Month)에서 "늦어진 소프트웨어 프로젝트에 인력을 더하면 더 늦어진다"고 했습니다.[5] 사람이 늘어나면 새로 온 사람에게 사정을 설명하는 시간과, 사람들 사이에서 의견을 맞추는 시간이 함께 늘어나기 때문입니다. 일을 나누는 것보다 나눈 일을 다시 맞추는 데 더 많은 비용이 드는 경우가 있다는 뜻입니다.

사람의 조직은 이 비용을 줄이려고 많은 장치를 씁니다. 회의를 하고, 문서를 쓰고, 같은 사무실에서 오가며 말로 다 하지 못한 사정을 공유합니다. 무엇보다 함께 일한 시간이 쌓이며 생긴 공통의 감각이 있습니다. 설명하지 않아도 "우리 회사라면 이렇게 하겠지" 하고 아는 것들입니다.

3. 에이전트는 건네받은 것만 안다

에이전트를 나누면 이 장치가 대부분 사라집니다. 하위 에이전트는 자신을 부른 에이전트가 건네준 글만 가지고 일을 시작합니다. 함께 일한 시간도, 오가며 들은 사정도 없습니다. 건네받은 지시가 짧으면 짧은 만큼만 압니다.

그리고 일을 마친 하위 에이전트는 결과를 요약해서 돌려줍니다. 부른 쪽은 그 요약만 봅니다. 하위 에이전트가 일하며 무엇을 고민했고 무엇을 건너뛰었는지는 요약에 다 담기지 않습니다.

일을 한 번 나눌 때마다 맥락은 두 번 줄어듭니다. 건넬 때 한 번, 돌려받을 때 한 번입니다. 4장에서 맥락을 줄이는 일의 위험을 따로 이야기하겠지만, 멀티 에이전트는 구조 자체가 맥락을 계속 줄였다 늘였다 하는 방식입니다.

많은 유튜버가 이 문제를 다룬 영상을 올렸고, 단일 에이전트와 멀티 에이전트를 같은 일에 붙여 보는 실험도 여럿 나왔습니다. 결론은 대체로 비슷했습니다. 아주 단순한 일이 아니더라도, 웬만큼 복잡한 일은 그냥 에이전트 하나에게 맡기는 편이 낫다는 것입니다. 저도 공감합니다. 다음 절에서는 일을 나눌 때 실제로 무엇이 새는지 조금 더 들여다보겠습니다.