AI 에이전트 오케스트레이션 메소드원칙

ft. 나만의 현실적인 원칙.

지난 1화의 예고대로, 6일 만에 상용화 레벨을 뽑아낸 진짜 방법론을 이야기해 보려 한다. 비개발자인 내가 4개의 AI 3대장들을 병렬로 굴려 차력쇼를 완성한 비결은 완벽한 자동화가 아니었다. 핵심은 세 개의 톱니바퀴였다. 각 AI의 관심사를 철저히 한정하는 '역할 부여', 그 역할을 흔들림 없는 텍스트로 박아 넣는 '구조화와 문서화(명확성)', 그리고 이를 바탕으로 다음 AI에게 바통을 넘기는 '핸드오프(Handoff)'. 이 세 가지는 각각 독립된 축이면서도 완벽하게 동시에 맞물려 돌아갔다. 지금부터 내가 카오스 속에서 찾은 이 'AI 에이전트 오케스트레이션'의 원칙을 공유해보려 한다.

재밌는 건, 바이브 코딩 방법론이 쏟아지는 현재 시점, 이 씬의 최전선에 있는 진짜 개발자들조차 오케스트레이션 방식이 극명하게 갈린다는 거다. 오픈클로(OpenClaw) 개발자인 스타인버거(Steinberger)는 5-10개의 에이전트를 띄워놓고 대화하듯 코드를 보지도 않으며 방목하는 방식을 즐긴다. 테스트와 디버깅도 오직 AI만으로 이루어진다. 반면, 클로드 코드를 이끄는 리드 개발자 보리스 체르니(Boris Cherny)는 4-7개의 에이전트 사이에서 역할을 나누어 릴레이로 사용하며, 테스트는 AI로 한 번, 사람이 한 번 두 번에 걸쳐 확인하고 있다. 완벽한 카오스다. 씬의 정점이 갈려있으니 당연히 시장에는 정답이 없고, 여러 방향으로의 선택지가 열려 있었다. 하지만 최소한 실제 개발 경력보다 바이브 코딩을 한 경력이 더 많아진 내가 6일 만에 상용화 레벨의 프로덕트를 통제하기 위해 믿고 갈 수 있는 확실한 답은 후자와 아주 유사했다.

첫 번째 축 : 역할 지정이 아닌 '관심사의 한정'

오케스트레이션의 첫 번째 축은 단순한 역할 부여를 넘어, 에이전트들의 '관심사를 철저히 한정'시키는 것이다. 마법 같은 AI 하나가 다 알아서 해줄 거라 기대하면 프로젝트는 산으로 간다.

AI에게 특정 과업을 시켰을 때 관심사를 좁혀주지 않으면, 이 녀석들은 부지런하게 프로젝트 전체의 소스 코드를 뒤적거린다. 과업과 상관없는 멀쩡한 지점까지 의심하고 뜯어고치려 드는데, 이는 귀중한 컨텍스트(Context) 용량의 엄청난 낭비일 뿐만 아니라, 다른 에이전트가 작업 중인 영역을 건드려 치명적인 충돌과 오류를 유발한다.

따라서 나는 AI 3대장과 구글 AI스튜디오에게 철저한 바운더리를 쳐주었다. 먼저 구글 AI 스튜디오는 철저히 '디자이너'로만 썼다. 기초 프로토타입을 바탕으로 5번의 피드백과 수정을 거쳐 최종 UI 레퍼런스를 뽑아내는 데 집중시켰다. 그리고 1번부터 5번까지의 레퍼런스에서 좋은 건 다 뽑아다가 사용했다. 이 레퍼런스 위에서 프론트엔드의 디자인적 개발은 안티그래비티 환경에서 제미나이 프로에게 전담시켜 코드를 직접 보며 작업하게 했다. 가장 똑똑한 클로드 코드(Opus)는 메인 개발자로서 서버와 데이터 파이프라인 등 가장 난이도 높은 백엔드에만 관심사를 한정시켰다. 그리고 이 모든 과정의 중개 에이전트이자 보조 개발자로 범용성이 가장 뛰어난 코덱스(Codex)를 이용해 멀티 디버깅과 깃 리모콘 역할을 주었다. 에이전트가 자신의 바운더리를 넘어서지 못하게 철저히 한계를 긋는 것. 이것은 많은 것을 아껴준다.

두 번째 축 : 문서화와 컨텍스트 통제

두 번째 축은 '문서화'다. 1화에서 짧게 언급했듯, 나는 초창기 윈드서프와 클로드를 병행하며 이미 문서화의 중요성을 체감한 바 있다.

원래 코딩 씬에서 문서화는 계륵 같은 존재였다. 결과물을 내는 게 곧 그 사람의 연봉이자 효율인 세계에서, 문서화에 시간을 쏟는 건 비효율로 여겨져 늘 뒷순위로 밀려났다. 한 개발자가 오래 엉덩이를 붙이고 일한다면 굳이 필요 없다는 핑계도 한몫했을 것이다. 과거에도 분명 필요했지만, 타협할 수 있는 영역이었다.

하지만 바이브 코딩 시대에 문서화는 더 이상 선택이 아니다. 필수적인 생존 도구다. 역할을 새롭게 부여받은 에이전트는 앞선 작업의 맥락(Context)이 담긴 문서가 없으면 방향을 잃고, 새로운 길을 개척한다. 놀랍고 대단하지만 기존의 방향성과 멀어질 수도 있는 여지는 달갑지가 않다.

이를 해결하기 위해 나는 가장 비싼 요금제를 쓰고 있던 코덱스를 나의 '문서화 매니저'로 임명했다. 맥(Mac)에서 코덱스 앱을 띄워놓고, 내가 선택해야 할 수많은 구조적 지점들과 다음 에이전트에게 넘겨야 할 요청서의 대부분을 코덱스와 논의하며 명확한 텍스트로 정리했다.

또한, 각각의 푸시 지점처럼 프로그램에서 하나씩 큰 단계를 지날 때마다 중요하게 결정사항이 깊어지거나 변경된 지점을 정리하였고, 그다음 작업의 계획서를 초안을 기반으로 수정 보충해서 또 다른 새로운 문서로 존재하게 했다. 기존의 기록도 남겨두었다. 그리고 각각의 에이전트가 자신이 한 과업들을 기록하도록 에이전트 파일도 만들어서 관리했다.

아이러니하게도 개발자의 효율을 저하시키던 문서화 작업이, 이제는 AI의 속도를 만나 순식간에 해결되고 있다. 가장 번거로웠던 문서화가, 현재 4개의 에이전트를 통제하는 오케스트레이션의 가장 중요하고도 강력한 무기가 되었다. 혹여라도 문서화를 두려워하는 개발자가 있다면 지금 시기엔 도태될 수도 있지 않을까 싶다. 또한 새롭게 바이브코딩을 하려 한다면 명확하게 문서를 관리할 마음의 준비를 해야 한다고 생각한다.

세 번째 축 : 안전하게 바통을 넘겨주는 '핸드오프'

세 번째 축이자, 앞선 두 축(관심사 한정, 문서화)이 갖추어져야만 비로소 폭발력을 가지는 것이 바로 '핸드오프(Handoff)'다. 나는 핸드오프라는 단어를 긱뉴스에서 보면서 이 글의 소재로 가져왔는데, 그에 앞서 이미 그 단어를 사용하는 다른 분야를 알고 있다. 바로 농구인데, 농구에서 가까운 팀에게 패스를 던지는 것이 아닌 손에서 떠나보내듯 주는 것을 핸드오프 패스라고 한다. 중간에 공을 빼앗기거나 궤도가 어긋날 위험을 원천 차단하는 것이다. 앞으로 설명할 내용도 이와 정확히 같다. 또한 보이는 것처럼 받아갈 팀원은 패스를 받으면서 나갈 준비를 한다.

관심사가 철저히 한정된 에이전트가 작업 도중 자신의 바운더리를 넘어 다른 영역을 터치해야 할 일이 생기면 어떡할까? 프론트엔드 기능을 맡은 에이전트가 백엔드를 건드려야 할 때, 나는 절대 직접 수정하지 못하게 차단했다. 대신 반드시 서로에게 건넬 '요청서'를 제작하게 만들었다. 이 요청서가 바로 손에서 손으로 안전하게 건네야 할 농구공이었다.

지휘자인 나는 철저한 검수자였다. 에이전트가 쓴 요청서에 구멍은 없는지, 명확히 정해지지 않아 헷갈릴 요소는 없는지 크로스 체크했다. 내가 이해하기 어려운 지점은 코덱스를 붙잡고 깊게 물어보며 파고들었다. 그렇게 완벽히 검증된 요청서만이 다음 과업을 맡은 에이전트에게 바통(핸드오프)으로 전달되었다.

나의 역할은 코드를 짜는 데에 있지 않았다. 보안, 인증, 전체 구조 설계, 미감 마무리 등 인간의 통제가 필수적인 곳에 미리 "이 지점을 만나면 나를 호출하라"는 안내를 달아두고 호출이 있으면 개입했다. 클로드가 복잡한 인증 로직을 짜다 컨텍스트 용량이 꽉 차 뻗어버렸을 때, 재빠르게 코덱스를 투입해 빈틈을 보완하며 바통을 넘긴 것도 이 구조 덕분이었다. 여기에서 하나 정말 놀라운 점이 있다. 만약 이 안전한 핸드오프 패스가 없었다면 4개의 AI는 코트 위에서 서로 부딪히며 공을 놓치고 말았을 것이다. 자신의 구역을 지키고 정확한 타이밍에 다음 사람의 손에 공을 넘겨주는 이 감각은, 비단 모니터 안에서만 통용되는 이야기가 아니었다.

(또한 내가 필수적이라고 생각했던 지점을 누군가는 자동화를 할 수도 있다.)

AI를 잘 쓰는 법과 '나'를 잘 쓰는 법

6일간의 작업이 끝나고, 평소 좋아하던 『혼자 회의』라는 책을 다시 펼쳤다. 벌써 열 번째 읽는 책이었다. 그런데 이번엔 한 구절이 유독 낯설고 신기하게 다가왔다.

"모든 해야 할 일을 한꺼번에 생각하지 말고, 자신에게 부여된 역할마다 일을 분리해서 생각해야 한다."

열 번을 넘게 보며 지나쳤던 문장인데, 지난 6일간 모니터 앞에서 벌였던 일들과 겹쳐 보였다. 내가 4개의 AI를 통제했던 그 방식이, 내 삶의 역할을 분리하는 방식과 정확히 같았기 때문이다.

내 삶도 여러 개의 에이전트(역할)로 나뉘어 있다. 생존과 매출을 고민하는 '사업가', 다이소에서 시급을 받으며 몰입할 시간을 확보하려는 '알바 직원', 동시에 거의 정규직에 가깝게 일을 하고 있는 도서관에서의 '콜리' 가족에서의 '오빠', 그리고 '연인'으로서의 나.

코딩할 때 프론트엔드의 컨텍스트를 백엔드에 섞으면 에러가 나듯, 삶도 마찬가지다. 다이소 알바의 육체적 피로도를 사업가의 책상 위로 끌고 오면 그날의 업무 블록은 무너진다. 반대로 사업가로서 겪는 불안과 책임을 연인 관계나 가족에게 끌고 가면 예를 들어 영업에서 거절당한 걸 연인과 데이트할 때 생각하고 있으면 관계 자체가 망가진다.

각각의 순간에는 오직 그 역할에 맞는 '제한된 관심사'에 집중해야 한다. 한 역할이 끝나고 다음 역할로 넘어갈 때는, 이전의 감정을 완벽히 갈무리하고 바통을 넘기는 안전한 '핸드오프'가 필요하다.

철저하게 역할을 분리할 것. 서로의 바운더리를 침범하지 않게 할 것.

모두가 분명히 삶에서 여러 역할이 있다. 그 역할마다에서 어떻게 스위치를 잘하는지가 정말 중요한데, 에이전트끼리도 그게 정말 중요했다.

*사실 이 깨달음을 얻는 순간의 영상이 있다 ㅋㅋㅋ 궁금하다면 놀러 오시길.

https://youtube.com/shorts/tjrihjcTnVw?si=praRoUTYLjbMKfEq

마무리

오해하지 않았으면 한다. 이건 정답이 아닐 수도 있다. 나는 지금 이 방식을 선택한 거다. 지금의 방식과 상반되게 언젠가 단 하나의 에이전트가 여러 에이전트를 동시에 컨트롤하며 내 의도를 완벽히 읽어내고 처음부터 끝까지 알아서 코드를 짜주는 '완전 자동화'의 시대가 어쩌면 지금일 수도 있고, 미래엔 더 확정적으로 올 것이라고 믿는다. 더 나아가, 창업가로서 극도로 리소스를 아끼기 위해 그 방식을 적극적으로 취하는 것은 매우 현명한 전략이기 때문에 나의 정석이 당신에게 안맞으면 과감히 지나가도 좋다.

하지만 지금, 이 카오스의 시기에 내가 굳이 '역할을 부여하고, 문서화하며, 핸드오프를 통제하는' 지휘자의 길을 택한 이유는 명확하다.

이 지독한 지휘의 과정이 훗날 완전 자동화 시대를 지배할 '근육'이 되기 때문이다. 실리콘밸리에서 만난 제미나이 PM의 말처럼, AI는 더 많이 사용하는 사람이 더 잘 쓰게 된다. 더 많은 시도와 실험을 반복하며 각 에이전트들의 한계를 쪼개보고 치열하게 바통 터치를 통제해 본 사람만이, 훗날 알아서 다 해주는 AI가 쥐어졌을 때 '무엇을, 어떻게 시킬지' 정확히 아는 진짜 마스터가 될 수 있다.

결국 이 6일간의 차력쇼는 나에게 코딩의 결과물뿐만 아니라, AI 시대를 마주하는 거대한 태도를 남겼다.

누군가는 이 과정을 보고 내게 묻는다. 바이브 코딩을 어떻게 공부해야 하냐고. 어떤 프롬프트부터 배워야 하냐고. 다음 3화에서는 그 질문에 대한 나의 단호한 대답을 이야기하려 한다. 단언컨대, 바이브 코딩은 교재로 '배우는' 것이 아니다.

그리고 더 나아가, 코딩이라는 장벽이 어느 정도 해결된 문제(Solved Problem)가 되어가는 지금, 창업가로서 코딩은 한정된 리소스를 어떻게 최적화해야 할지 고민해야만 하는 분야고, 나는 어떻게 리소스를 어디에 쏟아부을 것인지에 대한 앞으로의 실전적 계획(4화에서)까지 차근차근 풀어내고자 한다.