AI 코딩 에이전트 오케스트레이션 실전기 — 세 대의 머신, 다섯 번의 실패와 해법

핵심 메시지

• 여러 에이전트를 동시에 돌리면 결국 사람의 주의력이 병목이 된다 — 한 사람이 스케줄러·기억·검토자 역할을 모두 떠안게 되기 때문이다.
• 에이전트를 평평한 더미가 아니라 CEO·VP·매니저·워커의 계층형 조직으로 구성하면, 각 층이 자기 몫의 맥락만 보고 사람은 최상단 결과만 검토하면 된다.
• 에이전트의 상태를 모델의 컨텍스트 창이 아니라 디스크의 파일에 두면, 창이 꽉 차거나 머신이 죽어도 작업이 살아남는다.
• 컨텍스트가 차면 요약(compact) 대신 초기화(reset) 후 핸드오프 파일을 다시 읽게 하는 편이 빠르고 통제 가능하다.
• 한 대에서 잘 돌던 구조도 여러 머신으로 확장하면 새로운 실패가 쏟아진다 — 결국 쿠버네티스가 이미 답한 문제들이었다.

쉽게 이해하기

발표자 카일(KRAFTON)은 매일 세 대의 머신에서 AI 코딩 에이전트 무리를 실제로 운영한다. 무거운 작업과 개인 프로젝트를 다루는 맥북 한 대, 그리고 항상 켜져 있는 헤드리스 리눅스 두 대다. 리눅스 A는 오래 걸리는 코딩 작업을, 리눅스 B는 짧게 끝나는 사이드 프로젝트를 맡고, 하나의 컨트롤 플레인이 이 전부를 묶는다. 데모용으로 만든 것이 아니라 매일 쓰는 실제 작업 환경이라는 점을 그는 강조한다.

문제는 머신이 아니라 사람에게서 먼저 터졌다. 터미널 창에 에이전트를 네다섯, 여섯 개 띄우자 그는 더 이상 에이전트를 '운영'하는 사람이 아니라, 누가 무엇을 할지 정하는 스케줄러이자 각 에이전트의 진행 상황을 기억하는 메모리이자 모든 결과를 확인하는 검토자가 되어 있었다. 한 사람이 세 역할을 여섯 맥락에 걸쳐 수행하는 구조는 확장되지 않았다.

그가 찾은 실마리는 '조직'이었다. 소수의 경영진이 수천 명 규모의 회사를 굴리는 방식처럼, 각 구성원이 자기 몫의 맥락만 보게 하는 것이다. 그래서 CEO·VP·매니저·워커라는 계층을 실제 엔티티 타입으로 만들었다. 맥락은 위에서 아래로 필요한 만큼만 흘러가고, 결과는 아래에서 위로 올라오며, 사람은 최상단에 도달한 것만 검토한다. 여섯 개의 맥락 대신 정확히 하나만 붙들면 되는 구조다.

상태 관리도 핵심이었다. 에이전트의 상태를 모델의 컨텍스트 창 안에 두는 대신, 각 엔티티에 디스크상의 작업 공간을 주고 미션·현재 상태·핸드오프 폴더를 파일로 남겼다. 창이 차면 요약해서 공간을 비우는 대신 아예 초기화하고, 스스로 써둔 핸드오프와 기록 파일을 다시 읽어 이어가게 했다. 덕분에 컨텍스트가 지워지거나 머신이 크래시 나도 작업은 사라지지 않는다. 여기에 리뷰 게이트웨이를 붙여, 어떤 층이든 행동하기 전 계획을 제출하고 승인될 때까지 멈추게 했다.

한 대에서 완벽하게 돌던 구조는 확장과 함께 다섯 가지로 무너졌다. 오케스트레이터가 위임 대신 스스로 일하고, 워커 창이 너무 많아 화면을 읽을 수 없게 되고, 메모리가 고갈되고, 자격증명이 엉뚱한 작업 공간에 묶이고, 노트북이 전원·네트워크를 잃으며 진행 중이던 작업이 통째로 날아갔다. 그는 이 모든 신호가 결국 '한 대로는 부족하다'와 '쿠버네티스가 이미 답한 문제'를 가리킨다는 결론에 도달한다.

주요 인사이트

• 에이전트를 늘릴 때 진짜 병목은 컴퓨팅이 아니라 사람의 주의력이다. 사람이 스케줄러·메모리·검토자를 겸하는 순간 확장은 멈춘다.
• 계층형 조직(CEO·VP·매니저·워커)은 은유가 아니라 각자 범위가 제한된 맥락과 승인 경계를 가진 실제 구조로 구현할 때 효과가 있다.
• 상태를 파일로 외부화하면 '컨텍스트 압축' 대신 '초기화 후 재로딩'이 가능해져, 무엇을 남길지 통제할 수 있고 크래시에도 복원된다.
• 여러 머신으로 확장할 때는 공유 디렉터리 충돌을 피하기 위해 머신별 디렉터리를 두고 공유 상태는 풀 리퀘스트로만 바꾸는 규율이 필요하다.
• 에이전트가 '무엇이 필요한지'만 선언하고 '어디서 도는지'는 스케줄러가 정하게 하는 방향은 결국 쿠버네티스가 풀어온 문제와 같다.

자주 묻는 질문

관련 AI 소식