I Run a Fleet of AI Agents Across Three Machines. Here's What Broke. - Kyle Jaejun Lee, KRAFTON

한 줄 핵심

AI 코딩 에이전트를 여러 머신에서 운영하려면 모델 자체보다 컨텍스트, 상태, 승인 흐름, 자원 배치 같은 오케스트레이션 설계가 더 중요하다는 점을 실제 실패 사례로 보여준다.

시간별 요약

1. 0:00
   세 대의 머신을 하나의 제어면으로 묶어 AI 코딩 에이전트를 매일 운영하며, 처음에는 사람이 여러 에이전트의 스케줄러·기억·리뷰어 역할까지 떠안게 되면서 한계가 바로 드러난다. 이 문제를 계기로 에이전트를 평평한 묶음이 아니라 CEO, VP, manager, worker 구조의 조직으로 재설계한다.
2. 2:02
   에이전트 상태를 모델의 context window 안에 두지 않고 디스크의 workspace 파일로 분리해 mission, current status, handoff를 저장한다. context가 찼을 때는 compact 대신 reset으로 다시 읽게 하여, 컨텍스트가 지워지거나 머신이 재시작돼도 작업이 이어지도록 만든다.
3. 3:01
   계층별 계획이 실제 실행으로 이어지기 전에 review gateway에서 승인하도록 막고, 승인 직후 hook이 자동으로 작업을 재개하게 해 정렬 문제를 줄인다. 이 게이트웨이 자체도 에이전트가 만들면서, 에이전트 운영 도구를 에이전트가 다시 구축하는 구조가 된다.
4. 4:02
   단일 머신 운영은 곧 병목으로 무너진다. 오케스트레이터가 직접 일을 해버리거나, tmux pane이 지나치게 작아지고, 메모리가 고갈되고, credentials가 워크스페이스와 엉키며, MacBook이 잠들거나 재부팅되면 진행 중인 작업이 전부 사라진다.
5. 6:00
   해결책은 작업을 머신별로 분산하는 것이었다. MacBook은 무거운 코딩과 개인 프로젝트, Linux A는 장기 작업, Linux B는 단기 프로젝트를 맡고, Git과 SSH를 통해 context를 넘기며, 공유 상태는 pull request로만 바뀌게 분리한다. 남은 문제는 멀티 머신 일관성, 로컬 도구 추상화, 안전한 비밀정보 전달, 자원 관리이며, 최종적으로는 Kubernetes 위에 오케스트레이션 계층을 얹는 방향으로 향한다.

실무 인사이트

• 에이전트 운영의 핵심은 프롬프트보다 상태를 어디에 저장하고 어떻게 복구할지이며, 파일 기반 handoff와 reset 전략이 장기 실행 안정성을 크게 높인다.
• 사람이 여러 에이전트의 기억과 판단을 직접 떠안으면 곧 병목이 되므로, 승인 게이트와 계층형 위임으로 인간 개입 지점을 최소화해야 한다.
• 멀티 머신 운영에서는 작업 분산보다도 일관성, credentials 격리, 도구 추상화가 먼저 해결돼야 하며, 인프라 표준을 재사용하는 편이 더 현실적이다.