혼자서 AI 함대를 운영한다는 것 — 처음부터 만드는 대신 조립하기로 했습니다

처음엔 이걸 만들어야 할 시스템이라고 생각했습니다. 여러 대의 기계를 묶어 AI에게 일을 시키는 지휘 계층 — 큐가 있고, 워커가 있고, 상태를 주고받는 데몬이 있어야 할 것 같았습니다. 그렇게 며칠 설계를 붙들고 있다가, 문득 이상하다는 생각이 들었습니다.

제가 매일 쓰던 코딩 에이전트는 이미 기억(세션이 끝나도 남는 메모리)도, 재사용 절차(반복 작업을 접어둔 스킬)도, 자동 트리거(특정 상황에 스스로 발동하는 훅)도, 예약 실행(정해진 시각에 도는 스케줄)도, 하위 일꾼(잘게 쪼갠 서브에이전트)도, 외부 도구 연결까지도 전부 갖고 있었습니다. 필요한 부품은 다 손에 있었습니다. 없던 건 그것들을 하나의 루프로 엮는 얇은 지휘선 하나뿐이었습니다.

그래서 문제를 다시 정의했습니다. 이건 처음부터 만드는 문제가 아니라 조립하는 문제였습니다. 그 순간부터 코드는 극적으로 줄었고, 시스템은 오히려 훨씬 튼튼해졌습니다.

왜 '만들기'가 아니라 '조립'인가

혼자 운영하는 시스템에서 가장 무서운 건 부품 수입니다. 데몬(상주하며 계속 도는 백그라운드 프로세스) 하나를 세우면 그 데몬이 죽었을 때를 감시할 무언가가 필요하고, 그걸 감시할 또 무언가가 필요해집니다. 감시자의 감시자 — 이 사슬은 1인 운영자를 조용히 갉아먹습니다.

조립으로 방향을 틀자 이 사슬이 통째로 사라졌습니다. 오케스트레이터와 워커는 HTTP로 대화하지 않습니다. 상주 데몬도, 소켓도, 인증 토큰도 없습니다. 대신 파일로만 주고받습니다. 태스크를 파일로 던지고, 결과를 파일로 회수합니다.

투박해 보이지만, 실제로 돌려보니 이 '파일 기반 단순 통합'이 가장 견고했습니다. 프로세스가 죽어도 파일은 남습니다. 재부팅해도 상태는 디스크에 있습니다. 이건 2편에서 다룬 이야기 — 마크다운이 곧 기억이다 — 의 연장선입니다. 기억을 파일에 두었더니, 지휘 통신마저 파일이 가장 안전한 매체였습니다.

원칙 — 혼자 굴리는 시스템에서 안 죽는 부품은, 애초에 살아 있을 필요가 없는 부품이다.

강점대로 역할을 나눈다

함대라고 거창하게 불렀지만, 실체는 홈서버 몇 대입니다. 중요한 건 대수가 아니라, 각 기계에 강점대로 역할을 준 것입니다.

기계	강점	맡긴 역할
데스크톱	화면·손이 붙어 있음	콘솔·지식 허브·모든 결과의 최종 종착지
작은 리눅스 보드	24시간 조용히 켜져 있음	오케스트레이터 + 1차 워커풀 + 라이브 봇 호스트
힘센 저장서버	힘은 세지만 다른 일도 함	조건부(부하 낮을 때만) 빌드 워커 겸 배포 타겟

이 세 대를 원격 백본으로 묶어, 같은 방 안에 있는 것처럼 다룹니다. IP를 외우거나 포트를 하드코딩하는 배선을 걷어내니, 어느 기계에 태스크를 보내는지가 코드가 아니라 판단의 문제가 됐습니다.

라우팅 규칙은 하나로 수렴했습니다. 정본(원본 소스)이 어디 있느냐가 모든 걸 정한다. 정본이 어느 기계에 있으면 워커도 거기서 코드를 쓰고, 배포 경로도 거기서 뻗습니다. 정본 → 워커(작성) → 배포 타겟 — 이 한 줄이 "이 일을 어디서 시키지?"라는 질문을 매번 없애줬습니다.

워커는 '쓰기'만 한다 — 이 글의 심장

여기서부터가 이 시스템에서 가장 중요한 규칙입니다. 그리고 1편에서 예고한 게이트의 실체이기도 합니다.

워커는 코드를 작성만 합니다. 그게 전부입니다.

커밋도, 푸시도, 재시작도, 데이터베이스 쓰기도, 실제 배포도, 무중단 전환도 — 워커는 그중 어느 것도 하지 않습니다. 전부 사람이나 오케스트레이터의 게이트를 한 번 거칩니다. 특히 남의 돈이나 데이터가 걸린 프로덕션에서 사람 없는 완전 자동은 금지입니다. 예외 없이.

이유는 단순합니다. AI 워커는 지치지 않고, 그래서 틀려도 지치지 않고 틀립니다. 초안을 쓰는 일과 그 초안을 세상에 반영하는 일 사이에는, 되돌릴 수 있느냐 없느냐의 절벽이 있습니다. 작성은 언제든 버릴 수 있지만, 배포는 되돌리는 데 대가가 듭니다. 그 절벽 위에 사람 손을 얹는 게 게이트입니다.

그리고 오케스트레이터 자신은 얇아야 합니다. 이게 1편에서 말한 위임의 역설의 마지막 회수입니다 — 지휘층이 얇을수록 오래 갑니다. 언젠가 오케스트레이터가 워커의 결과가 마음에 안 든다고 스스로 코드를 고치기 시작한 적이 있는데, 그 순간부터 하네스가 자기 발을 씹기 시작했습니다. 지휘자가 악기를 잡으면 오케스트라가 무너집니다.

한 가지 더. 상위 모델과 하위 모델을 나눠 쓰는 패턴은 확실히 효과가 있었습니다. 설계·판단은 힘센 모델 한 번, 반복 실행은 가벼운 모델 여러 번. 다만 여러 세션을 무작정 병렬로 켜는 건 대체로 손해였습니다. 격리 없이 나란히 돌리면 서로의 작업 트리를 밟습니다. 병렬은 자원과 격리를 먼저 설계했을 때만 이득입니다 — 그래서 모든 워커는 스냅샷 격리(각자 별도 사본에서만 손대게 만드는 방식)를 전제로만 돕니다.

반드시 챙길 함정

여기 적는 건 전부 실제로 당한 것들입니다. 조립이 쉬웠던 만큼, 조립된 시스템이 물어뜯을 때는 예상 밖의 방향에서 옵니다.

⚠️ split-brain(한 몸이 둘로 쪼개지는 사고) — 은퇴시킨 옛 사본을 절대 부팅하지 마세요. 봇 호스트를 새 기계로 옮긴 뒤, 옛 기계를 실수로 한 번 켠 적이 있습니다. 그러자 같은 봇이 두 곳에서 동시에 살아나 모든 메시지에 두 번씩 응답했습니다. 죽었다고 믿은 인스턴스가 살아 있으면, 시스템은 조용히 둘로 쪼개집니다. 은퇴 = 전원 차단이 아니라 부팅 금지로 못 박으세요.

★ 자기-커밋 오판 — 태스크 스펙에 '커밋까지'라고 쓰지 마세요. 한번은 태스크 지시에 "작업하고 커밋해줘"라고 무심코 적었습니다. 워커가 시키는 대로 스스로 커밋을 했고, 그 순간 하네스는 작업 트리에 변경이 없다고 판단해 — 워커가 이미 커밋으로 치웠으니까 — 브랜치를 '빈 작업'으로 간주하고 지워버렸습니다. 몇 시간짜리 결과가 dangling 커밋(어디에도 연결 안 된 채 떠도는 커밋)으로 사라질 뻔했습니다. 복구는 됐지만, 교훈은 명확합니다. 커밋은 워커의 몫이 아니라 하네스의 몫입니다. 스펙에 그 문구를 넣는 순간 경계가 무너집니다.

라이브 트리 옆에서 격리 없이 작업한 대가도 치렀습니다. 돌아가는 봇의 라이브 소스 바로 옆에서, 스냅샷 없이 여러 워커를 붙였다가 라이브 트리가 오염된 적이 있습니다. 병렬 워커가 서로의 추적되지 않은 파일을 지우면서 라이브가 크래시 루프에 빠졌습니다. 워커는 언제나 격리된 사본 안에서만 손을 대야 합니다.

가장 얼얼했던 건 탐색 한 줄이었습니다. grep -r / 한 줄로 작은 서버 한 대가 통째로 멈춘 적이 있습니다. 커널 가상 파일까지 훑느라 I/O가 포화됐고, 원격 접속이 먹통이 되어 결국 재부팅밖에 답이 없었습니다. 탐색에는 항상 구체 경로 + 깊이 제한 + 타임아웃을 물려서 워커에게 상속시키세요. 자유로운 탐색권은 자유로운 자해권이기도 합니다.

한 가지 더 얹자면, 편의로 남겨둔 설정 백업 파일이 평문 시크릿을 흘린 적도 있습니다. 조립은 부품을 빠르게 붙이는 만큼, 붙인 자리마다 무엇이 새는지 따로 감사해야 합니다.

정리

이 시리즈는 결국 한 채의 집을 짓는 이야기였습니다. 네 개의 층이 있었습니다.

층	편	하는 일
원칙	1편	위임·역할 분리·정보 흐름·자원 배분 — 나 대신 일할 구조의 뼈대
기억	2편	파일에 적힌 지식 — 세션이 끝나도 잊지 않게
절차	3편	두 번 하면 스킬로 — 반복을 접어 재사용 가능하게
오케스트레이션	4편	위 셋을 하나의 루프로 지휘 — 얇은 지휘선과 게이트

만들지 말고 조립하세요. 이미 가진 부품을 하나의 루프로 엮는 순간, 코드는 줄고 시스템은 튼튼해집니다. 그다음은 경계입니다 — 워커는 쓰기만, 배포는 게이트로. 되돌릴 수 없는 일 앞에는 언제나 손을 얹으세요. 마지막은 자제입니다. 지휘층은 얇게. 오케스트레이터가 악기를 잡는 순간 오케스트라는 무너집니다.

혼자서 함대를 운영한다는 건, 제가 만능이 된다는 뜻이 아니었습니다. 제가 자리를 비워도 각 기계가 제 강점대로 일하고, 위험한 문턱마다 저를 기다려주는 구조를 세우는 일이었습니다. 1편의 하네스 엔지니어링이 발상이었다면, 이 4편은 그 발상이 실제로 돌아가는 모습입니다. 절차를 어떻게 접었는지 궁금하다면 두 번 하면 스킬로 만든다로 돌아가 보셔도 좋습니다.

---

네 편을 다 쓰고 나서 깨달았습니다. 저는 더 똑똑한 AI를 기다린 게 아니라, 제가 없어도 무너지지 않는 집 한 채를 지은 것이었습니다 — 그리고 그 집의 마지막 못은, 언제나 제가 직접 박아야 하는 게이트였습니다.