프로젝트가 하나일 땐 에이전트 하나로 충분했다. 자동매매 봇, 콘텐츠 자동화, 게임, 문서 제작, AI 생성까지 늘어나자 그 하나가 무너졌다. 한 세션에서 매매 전략을 판단하다가 다음 순간 문서 조판을 고민하면, 어느 쪽도 깊게 못 판다. 그래서 한 명의 만능 에이전트를 버리고, 역할을 나눈 조직으로 재설계했다.
왜 만능 에이전트가 한계였나
만능 에이전트의 문제는 능력이 아니라 맥락 오염이었다. 크립토 매매의 리스크 감각과 전자책 문체 교정은 완전히 다른 판단 회로다. 한 컨텍스트에 둘을 섞으면 프롬프트가 길어지고, 도메인 지식이 서로를 밀어낸다. “이 전략이 우리 리스크 한도에 맞나"를 묻는 순간과 “이 표현이 자연스러운가"를 묻는 순간이 같은 머리에서 나오면 둘 다 얕아진다.
해법은 분업이었다. 다만 사람 조직처럼, 누가 무엇을 최종 판단하는지 경계를 코드로 못 박는 것이 핵심이었다.
총괄은 판단하지 않는다
맨 위에 총괄 에이전트를 뒀지만, 총괄은 도메인 판단을 하지 않는다. 순수 라우터다. 요청이 오면 “이건 어느 프로젝트 리드 소관인가"만 정해서 위임하고, 여러 프로젝트에 걸친 요청은 관련 리드에게 나눠 시킨 뒤 결과만 취합해 보고한다.
총괄이 매매 승인이나 고객 응대 문구를 직접 정하지 않는 이유는 명확하다. 총괄이 모든 도메인 지식을 다 아는 건 비효율이고, 한 곳에서 다 판단하면 처음의 맥락 오염으로 되돌아간다. 총괄의 유일한 전문성은 분류와 취합이다.
프로젝트 리드: 도메인 최종 판단권자
각 프로젝트에는 리드가 있다. 자동매매, 주식 검증, 증시 콘텐츠, 프리랜서 업무, 문서 제작, 게임 개발이 각자의 리드를 가진다. 리드는 그 도메인의 최종 판단권자다. 매매를 실행할지, 콘텐츠를 승인할지, 게임의 ‘재미’를 어떻게 조율할지는 전부 해당 리드가 정한다.
리드는 자기 밑의 팀원(또는 공유팀)을 호출해 일을 시킨다. 여기서 중요한 기술적 결정이 하나 있었다. 서브에이전트의 중첩 위임이다.
공유 기능팀: 재사용되는 역량
프로젝트마다 겹치는 일이 있다. 시장 리서치, 영상 제작, 업로드 인프라, 문서 작성 같은 것들이다. 이걸 프로젝트마다 새로 만들면 정의가 여러 곳으로 흩어진다. 그래서 공유 기능팀을 한 곳에만 정의하고, 여러 리드가 재사용한다.
경계는 신경 써서 그었다. 예를 들어 “정해진 스키마를 채우는 정형 수집"과 “답이 정해지지 않은 리서치"는 겉보기엔 같은 조사처럼 보이지만 다른 팀이다. 매일 도는 정형 작업은 프로젝트 고유 역할이, 일회성 탐색은 공유 리서치팀이 맡는다. 이 경계가 흐려지면 같은 일을 두 곳에서 하게 된다.
gatekeeper: 외부로 나가는 모든 것의 단일 관문
가장 중요한 노드는 gatekeeper다. 스케줄 등록, 배포, 외부 공개 업로드 — 되돌리기 어려운 모든 행위는 총괄이든 리드든 스스로 판단해서 진행할 수 없다. 반드시 gatekeeper에게 계획을 보여주고 승인받은 뒤에만 실행한다.
이 관문을 둔 이유는 사고 경험 때문이다. 검수 없이 자동 공개된 산출물이 문제가 된 적이 있었고, 그 뒤로 “외부로 나가는 것"과 “실제 돈이 오가는 것"은 반드시 별도 승인을 거치게 했다. gatekeeper는 승인만 하는 게 아니라, 각 에이전트가 자기 역할대로 실제로 일했는지 감사도 한다.
중첩 위임과 상속을 어떻게 켰나
이 조직이 실제로 돌려면 두 가지 기술 결정이 필요했다.
첫째, 중첩 위임이다. 총괄이 리드를 부르고, 리드가 다시 팀원을 부르는 2계층 위임은 기본적으로 꺼져 있다. 서브에이전트가 또 서브에이전트를 부르는 걸 막아두는 게 기본값이기 때문이다. 이걸 환경변수로 켜서 총괄→리드→팀원의 2계층을 허용했다. 이 값을 지우면 리드가 팀원을 못 부르고 혼자 처리하게 되므로, 조직이 조직으로 작동하려면 이 설정이 살아 있어야 한다.
둘째, 정의의 상속이다. 공유 기능팀을 프로젝트마다 복사하지 않는다. 상위 폴더 한 곳에 에이전트 정의를 두면, 하위의 모든 프로젝트가 경로를 거슬러 올라가며 그 정의를 자동으로 상속한다. 같은 이름을 하위에 다시 두면 작업 디렉토리에 가장 가까운 정의가 이긴다 — 특정 프로젝트에서만 공유팀 동작을 바꾸고 싶으면 그 프로젝트 폴더에 같은 이름으로 덮어쓰면 된다. 그래서 이름은 트리 전체에서 유일하게 유지한다. 심볼릭 링크도, 동기화 스크립트도 필요 없다.
이 두 가지가 없으면 조직도는 그림일 뿐이고, 실제로는 총괄 혼자 다 하는 원점으로 돌아간다.
완료를 어떻게 판정하나
분업만큼 중요한 게 판정이었다. 각 프로젝트는 “고쳐줘"라는 요청을 **“무엇이 참이면 고쳐진 것인가”**라는 검증 기준으로 바꾼 뒤, 그게 실제로 참이 될 때까지 반복한다. “아마 될 겁니다"로 끝내지 않는다. 검증에 실패했으면 실패했다고 그대로 보고한다. 추측으로 빈 값을 그럴듯하게 채우지 않고, 못 구한 건 “못 구했다"고 멈춘다. 이 규칙이 없으면 자동화는 조용히 틀린 결과를 쌓는다.
이 구조가 준 것
세 가지가 달라졌다. 첫째, 각 판단이 깊어졌다. 도메인 리드가 자기 영역만 보니 프롬프트가 짧고 정확해졌다. 둘째, 되돌리기 어려운 사고가 줄었다. gatekeeper라는 단일 관문이 공개·배포를 전부 걸러낸다. 셋째, 역량이 재사용됐다. 공유팀을 한 번 만들면 모든 프로젝트가 상속받는다.
무엇보다, 사람은 총괄하고만 대화하면 된다. 나머지 분업은 조직 안에서 알아서 흐른다. 이 블로그의 글도 그 조직의 산출물이다.
이 조직의 전체 구조
