클로드로 에이전트를 여러 개 띄우는 일은 비개발자도 충분히 할 수 있습니다. 도구는 이미 우리가 굳이 속을 다 알지 못해도 쓸 수 있을 만큼 친절해졌으니까요. 예전엔 터미널 화면의 검은 바탕만 보아도 막막했지만, 이제는 명령어 한 줄을 외우지 못해도 직관적인 화면이 그 자리를 대신합니다. 하지만 진짜 관건은 단순히 기술적으로 화면을 여러 개 띄울 수 있느냐가 아니었습니다. 멀티 에이전트 시대의 진짜 병목은 코딩 지식이 아니라 일을 쪼개서 적재적소에 맡기고 그 결과를 하나로 합치는 기획력이었습니다. 도구가 다 마련된 지금 남은 것은 누구를 어디에 앉힐지 아는 통찰이고, 그것은 개발이라기보다는 기획의 영역이었습니다. 코딩은 여전히 제게 버거운 약점이지만 이 작업만큼은 코딩이 아니라 기획이기에 해볼 만하다는 생각이 들었습니다.
멀티 에이전트라는 말부터 짚어보면 인공지능 하나가 처음부터 끝까지 모든 것을 혼자 처리하는 대신 역할을 나누어 여러 개를 동시에 굴리는 구성을 뜻합니다. 검색창에 claude 여러 개 띄우는 법을 찾아보던 분들이라면 식당 주방의 풍경에 비유할 때 그 그림을 가장 선명하게 그리실 수 있을 것입니다. 손님이 몰리는 점심시간에 주방장 한 명이 주문, 요리, 서빙을 다 하면 식당은 마비됩니다. 홀 담당과 조리 담당을 따로 두어야 전체 속도가 빨라집니다. 이 주방장이 바로 우리가 마주하는 메인 대화이고 홀 담당과 조리 담당에 해당하는 것이 서브에이전트입니다. 메인 대화가 거대한 업무를 쪼개 서브에이전트들에게 지시를 내리면 이들은 자신만의 독립된 공간에서 문서 조사나 파일 탐색 같은 과정을 묵묵히 처리하고 잘 정리된 결론만 메인 대화로 돌려줍니다.
비개발자가 실제로 코딩 없이 어디까지 도달할 수 있는지 그 경계를 살펴보면 생각보다 많은 것이 열려 있습니다. 대화창 안에서 서브에이전트를 곧바로 부르는 가장 쉬운 단계는 복잡한 코딩 지식 없이도 이 세 가지를 각자 나누어서 찾아봐 달라는 일상적인 지시 하나면 충분합니다. 거기서 더 나아가 에이전트 뷰 화면을 이용하면, 독립된 작업 여러 개를 백그라운드에 던져두고 한 화면에서 진행 상태를 지켜볼 수 있습니다. 요즘은 데스크톱 병렬 세션 기능이 도입되어, 터미널 창 없이도 일반 화면에 여러 세션을 나란히 띄우고 다른 업무를 지시하는 일이 무리 없이 매끄럽게 돌아갑니다. 하지만 에이전트 팀 구성 영역으로 넘어가면 다루어야 할 문제의 차원이 완전히 달라집니다. 여러 에이전트가 공통의 작업 목록을 공유하며 서로 필요한 메시지를 주고받게 만들거나 에이전트들이 같은 파일을 동시에 건드려 충돌하지 않도록 워크트리 기반의 격리된 작업 공간을 나누어주는 일은 단순한 설정이 아닙니다. 이것은 마치 새로운 부서를 조직하고 업무 프로세스의 규칙을 바닥부터 설계하는 기획 업무에 가깝습니다. 더욱이 세션을 여러 개 동시에 돌리게 되면 토큰 사용량도 급격히 늘어나기 때문에 요금제 한도라는 현실적인 벽도 함께 신경 써야만 합니다.
이러한 구성이 제 업무 일상에서 구체적으로 무엇을 대신해주고 있는지 돌아보면 이 구조가 왜 코딩이 아니라 철저히 기획의 힘으로 돌아가는지 아주 분명해집니다. 원고 한 편을 작성했을 때, 예전의 저는 오탈자 확인, 사실관계 재검색, 제목 후보 도출 같은 요청을 순서대로 하나씩 묻고 기다려야만 했습니다. 하지만 지금은 그 세 가지 독립적인 검토 작업을 각기 다른 에이전트에게 한 번에 병렬로 던져둡니다. 세 명의 검토자에게 원고를 동시에 나누어준 것과 같습니다. 각자의 방에서 일한 결과를 정리된 형태로 받아보기만 하면 됩니다. 기획 쪽 업무에서도 상황은 마찬가지입니다. 새로운 기능을 서비스에 도입하려 검토할 때 유력한 경쟁 서비스 세 곳의 해결 방식을 조사하고 다른 업계의 비슷한 사례를 살펴보고 예상되는 리스크를 목록으로 뽑는 일은 언제나 저 혼자서 순서대로 야근하며 매달려야 했던 고독한 몫이었습니다. 이제는 이 작업들을 각각 역할이 부여된 다른 에이전트에게 한꺼번에 맡겨버립니다. 셋이 동시에 각자의 방에서 치열하게 웹을 뒤지고 찾아보고 정리한 요약 리포트가 돌아오면 저녁 한 나절을 다 쓰던 고단한 일이 지시 한 번과 결과를 추리는 아주 짧은 시간으로 확연히 줄어듭니다. 이는 제가 복잡한 코드를 훌륭하게 짜서가 아닙니다. 어떤 일을 어떻게 쪼개서 누구에게 병렬로 맡길지 명확하게 기획했기 때문에 얻을 수 있는 결과입니다.
제 개인적인 작업 환경을 구성한 방식도 바로 이 연장선에 놓여 있습니다. 제 맥미니에는 역할이 다른 에이전트 몇 개가 터미널 화면에 상주해 있습니다. 외부에서 텔레그램으로 지시를 보내면 알아서 해당 담당 에이전트에게 전달되어 작업을 수행하는 구조를 굴려보고 있습니다. 겉보기엔 복잡해 보여도, 결국 역할 분담과 병렬 처리라는 기본 기능을 조합해 놓은 것에 불과합니다. 제가 굳이 자리에 꼿꼿이 앉아 까만 터미널을 열지 않아도 잘 기획된 업무 프로세스만 머릿속에 있다면 밖에서도 충분히 여러 에이전트를 유기적으로 조율할 수 있다는 것을 매일 체험하고 있습니다.
다만 에이전트의 숫자가 무한정 늘어난다고 해서 최종적인 일의 품질이 저절로 완벽해지는 것은 결코 아닙니다. 여러 방에서 쏟아져 나온 산출물을 늘어놓고 꼼꼼히 읽어보며 실제 우리 상황에 무엇을 쓸지 고르고 판단하는 것은 여전히 고스란히 제 몫으로 남아 있습니다. 오히려 일을 빠르고 훌륭하게 대신 해주는 에이전트가 많아질수록 그들의 다양한 결과물을 충돌 없이 통합하고 서비스의 방향성을 다듬는 기획자의 시간은 이전보다 훨씬 더 밀도 있고 예리하게 요구되기도 합니다. 도구가 눈부시게 발달해 모든 것을 순식간에 대신해줄 것 같은 환상을 주지만 정작 일을 쪼개서 시키고 그 최종 결과에 책임을 지는 일은 여전히 외롭고 무거운 사람의 숙제로 남는다는 사실을 배웁니다.
에이전트에게 일을 쪼개 맡기는 것도 결국 '내 말이 왜 안 통하지'라는 오래된 문제로 돌아옵니다. 사람에게든 AI에게든, 일을 맡기는 언어를 먼저 다룬 책을 써두었습니다.