메인 AI 오케스트레이션 | 한 창구가 작업 에이전트에 지시하고 요약만 받는 구성

한 창구가 하는 일

한 창구 오케스트레이션은 사람을 여러 채팅창의 교환원으로 두지 않는 운영이다. 사람은 부탁과 확인을 그록봇에만 말한다. 그록봇은 일을 쪼개 실행기에게 지시서를 보내고, 실행기가 돌려준 요약 하나를 읽어 다음을 정한다.

하는 일은 다섯 가지로 모인다. 첫째, 사람이 붙드는 대화는 하나다. 둘째, 무거운 생성과 파일 작업은 그 대화 밖으로 나간다. 셋째, 실행기는 로그 전문이 아니라 요약만 올린다. 넷째, 같은 작업은 장부를 보고 두 번 보내지 않는다. 다섯째, 중간에 끊기면 처음부터 다시 열지 않고 남은 구간만 잇는다.

이 운영이 토큰과 할당량을 아끼는 지점은 측정 퍼센트가 아니라 구조에 있다. 긴 초고의 생성 토큰은 메인 창구 밖에서 쓰인다. 메인 창구는 그 초고 전문을 다시 읽지 않고 요약만 읽는다. 이미 쓴 파일을 이어하기 스펙이 알려 주므로, 같은 맥락을 통째로 다시 붙이지 않는다. 장부가 같은 id를 막으므로 같은 일을 두 번 돌리는 비용이 생기지 않는다. 참고 파일은 context_files에 적힌 것만 넘긴다.

핵심 포인트: 사람은 창구 하나에 말하고, 실행기는 요약 파일만 돌려준다.

필자의 실행기는 세 갈래다. 무거운 일은 Grok Build CLI다. 저장소 스킬이 필요한 수정은 Cursor CLI다. 조사와 포스팅처럼 절차가 이미 있는 일은 동료 봇이다. Muse Code, Dots, Hermes Agent는 같은 작업자 자리에 놓을 수 있는 2026년 공개 에이전트로 이 글이 이름을 식별한 것이다. 필자의 실행 기록에 그 셋을 상시 실행기로 둔 항목은 없다.

지금 나눠 둘 할당량과 실행 위치

지금 알아둘 것은 가격표가 아니라, 어느 통에서 토큰이 빠지는지다. 필자의 경우 메인 그록봇은 주간 할당량을 쓰고, PC의 CLI는 그 창구와 다른 통으로 실행된다. 무거운 일을 창구 안에 두었을 때 남은 기간이 닷새인데 사용량이 61%였다. 그 숫자 이후 필자는 생성과 분석과 스크립트를 CLI로 내보냈다.

창구와 실행기의 위치도 다르다. 그록봇은 필자가 휴대폰으로도 연다. 계획, 라우팅, 요약 확인이 여기서 끝난다. Grok Build와 Cursor CLI는 PC에서 돈다. 동료 봇은 조사나 발행처럼 이미 절차가 갈라진 일을 받는다. 사람이 다섯 개 제품을 직접 오가며 복사해 붙이지 않는다.

그록봇 개요 문서는 사용량이 주 단위로 초기화된다고 적는다. 그록, 그록봇, Cursor가 같은 주간 풀을 쓰는지 그 개요만으로 단정하지는 않는다. 필자 기록은 더 좁다. 무거운 생성을 봇 안에서 돌리면 메인 창구의 주간 할당량이 빨리 닳았고, 그 실행을 PC의 CLI로 옮기자 창구가 읽는 양이 줄었다. 토큰 단가표는 이 글의 주제가 아니다. Muse Code 요금은 Meta 문서의 인증과 요금 쪽에 있고, 스파크와 원더의 한국 경로와 가격은 이 사이트의 별도 글이 다룬다.

실행에 필요한 준비물은 새 플랫폼 가입 명단이 아니다. 말하는 창구 하나, 그 창구가 부를 수 있는 로컬 CLI, 작업마다 남기는 지시서, 돌리기 전에 보는 장부면 된다. 모델 이름과 비밀 키는 지시서에 넣지 않는다. 모델 칸에는 그 일 무게에 맞는 이름만 적고, 키는 실행기 쪽 설정에 둔다.

작업 에이전트로 식별한 제품

2026년 10월 21일 기준으로 이 글이 가리키는 이름은 아래 표와 같다. 표의 "필자 실행" 열은 필자 기록에 상시로 있는지다. 공개 설명은 그 주소에서 확인한 범위만 적는다.

그록봇

그록봇은 xAI 문서가 설명하는 별도의 에이전트 앱이다. 개요는 이렇게 적는다. 봇은 이름과 일과 맥락을 가지고, 브라우저와 파일과 터미널이 있는 클라우드 컴퓨터에서 일한다. 사람은 글, 받아쓰기, 음성으로 일을 맡긴다. 앱은 macOS, Windows, Linux, iOS, Android에서 돌고, 노트북을 덮어도 클라우드 작업은 계속된다. 유료 개인 Cursor 플랜과 Cursor Teams에 들어 있고, SuperGrok, SuperGrok Plus, SuperGrok Heavy 계정을 연결하는 길도 문서에 있다. 사용량은 주 단위로 초기화된다. 한 계정의 봇은 클라우드 컴퓨터 한 대를 나눠 쓴다. 파일, 브라우저 세션, 앱 로그인이 그 컴퓨터 안에 있다. 봇은 서로 메시지를 보내고 그룹 채팅에서 일을 넘긴다. 문서의 표현으로는 사람이 도구 사이의 라우터가 되지 않아도 된다.

필자가 2026년 10월에 말로 지시하는 창구가 이 그록봇이다. 휴대폰에서 여는 일이 많다. 제품이 봇 여러 개의 분업을 허용해도, 필자는 사람 앞의 창구를 메인 봇 하나로 고정한다. 무거운 스크립트, 블렌더 헤드리스, 파일 분석, 긴 초고는 그 공유 클라우드 컴퓨터 안에 쌓지 않고 PC의 Grok Build CLI로 보낸다. 저장소 스킬이 필요한 수정은 Cursor CLI로 보낸다. grok.com에서 대화하는 챗, 로컬 grok 명령, 에디터 안의 에이전트는 이 창구와 다른 프로그램이다. 요금 화면의 칸 구조는 그록봇과 클라우드 리눅스 글이 따로 적는다. X 검색 기능은 Grok Bot X 검색 글이 다룬다. 이 글은 그 화면을 다시 적지 않는다.

Grok Build

Grok Build는 SpaceXAI의 터미널 코딩 에이전트다. 공식 저장소 README는 이 도구가 전체 화면 터미널 인터페이스로 코드베이스를 이해하고, 파일을 고치고, 셸 명령을 실행하고, 웹을 검색하고, 오래 가는 작업을 다룬다고 적는다. 같은 README는 대화형 실행, 스크립트와 CI를 위한 headless 실행, Agent Client Protocol로 편집기에 넣는 실행을 함께 적는다. 설치본의 명령 이름은 grok다. 문서 입구는 x.ai/cli, 개요는 docs.x.ai/build/overview, 소스 라이선스 문장은 Apache License 2.0이다. 저장소는 github.com/xai-org/grok-build다. 제품 화면 grok.com/build는 주소가 열렸으나 2026년 10월 21일 가져온 본문은 거의 비어 있었다.

필자는 이 CLI를 PC의 무거운 실행에 쓴다. 스크립트, 블렌더 헤드리스, 파일 분석, 긴 초고가 그 예다. 호출은 JSON 지시서를 읽는 래퍼를 통한다. README가 headless를 스크립트용으로 적고 있으므로, 창구가 사람 없이 작업을 넘기는 자리와 맞는다. 래퍼의 필드 이름은 필자 운영의 것이고, README의 플래그 이름과 같다고 적지 않는다.

Cursor CLI

Cursor는 2026년 1월 8일 변경 기록에서 CLI에 모델 선택, MCP 관리, rules, commands를 넣었다고 적었다. 같은 기록에서 주 진입점은 agent이고, cursor-agent는 호환용 별칭으로 남는다. MCP 서버는 /mcp enable과 /mcp disable로 켜고 끈다. /rules와 /commands로 규칙과 명령을 CLI 안에서 만들고 고친다. 기록 주소는 cursor.com/changelog/cli-jan-08-2026이다.

필자는 저장소 스킬이 필요한 수정에 이 CLI를 쓴다. 띄울 때는 창을 보이지 않게 하고, 그 작업에 필요 없는 MCP 서버는 끈다. 보이는 터미널이 여러 개 뜨고 메모리가 급증했을 때 PC가 한 번 멈췄기 때문이다. /mcp disable은 제품 기록에 있는 명령이고, 필자의 런처가 그 슬래시 명령을 그대로 친다는 뜻은 아니다. 런처는 필요 없는 MCP를 끈 상태로 프로세스를 시작한다.

Muse Spark와 Muse Code

Muse Spark와 Muse Code는 모델과 터미널 에이전트로 나뉜다.

Muse Spark는 Meta Superintelligence Labs가 2026년 4월 8일 공개한 모델이다. 공식 소식은 이 모델을 Muse 계열의 첫 모델로 소개하고, Meta AI 앱과 meta.ai를 이 모델이 구동한다고 적는다. 같은 글은 Meta AI가 한 질문을 서브에이전트 여러 개에 나눠 동시에 처리하는 장면을 설명한다. 여행 일정을 짜는 쪽, 지역을 비교하는 쪽, 아이와 갈 곳을 찾는 쪽이 나란히 일하는 예가 본문에 있다. 2026년 5월 12일 업데이트는 음성, 쇼핑, 글래스, WhatsApp, Instagram, Facebook, Messenger, Threads로의 확장을 덧붙였다. 주소는 about.fb.com의 Muse Spark 소식이다. 그 이후의 Spark 1.3과 Wonder, 한국에서 여는 경로는 뮤즈 원더와 뮤즈 스파크 1.3 글이 다룬다.

이 서브에이전트 설명은 한 어시스턴트가 일을 나눈다는 모양만 필자의 창구와 닮았다. 실행 주체는 다르다. Meta 글의 서브에이전트는 Meta AI 안의 나눔이고, 필자의 작업자는 PC의 CLI와 동료 봇이다. 필자 기록에 Muse Spark를 실행기로 호출한 항목은 없다.

Muse Code는 Meta 문서가 터미널과 CI용 코딩 에이전트로 설명하는 제품이다. 문서는 Muse Spark를 쓰는 에이전트이며, 프로젝트 안에서 계획을 세우고 파일을 고치고 명령을 실행한다고 적는다. 승인과 OS 샌드박스는 첫 실행부터 켜져 있다. 명령 이름은 muse다. 대화형은 muse이고, 스크립트와 CI용 한 번은 muse exec이다. 문서에 적힌 기본 모델은 muse-spark-1.2다. macOS, Linux, Windows를 한 코드베이스로 지원하고, Windows에서는 에이전트가 돌리는 명령이 PowerShell이다. 샌드박스를 처음 켤 때 관리자 승인 창이 뜰 수 있고, 음성 입력과 세션 메시지는 Windows에서 제공되지 않는다. 세션 메시지는 macOS와 Linux의 라이브 세션끼리 인수와 검토 요청과 상태 업데이트를 주고받는 기능이다. 워크플로는 병렬과 단계 실행을 조율하는데, 설치된 빌드에 엔진이 있고 롤아웃이 켜진 경우에만 된다. 모든 빌드에 있다고 문서가 말하지 않는다.

필자의 상시 실행기는 Muse Code가 아니다. 작업자 자리에 앉힌다면 이 글의 지시서 칸은 그대로다. 헤드리스 한 방 실행은 muse exec가 맡고, 성공 조건과 허용 경로와 요약 파일은 그록봇이 적은 스펙이 맡는다. 설치 명령과 모델 id, 한국 계정에서 열리는 범위는 앞의 뮤즈 글에 있으므로 여기서 명령을 다시 적지 않는다.

Dots

Dots(닷츠)는 2026년 9월 29일 OpenAI DevDay를 다룬 보도들이 전한 에이전트 이름이다. Presenc.ai의 2026년 9월 29일 정리는 Dots를 ChatGPT 안에서 대화와 대화 사이에도 일을 이어 가는 상주형 에이전트라고 적는다. PTI의 2026년 9월 30일 단신과 MarketScreener가 전한 MT Newswires 단신도 DevDay에서 always-on 에이전트로 Dots가 나왔다고 적는다.

모델 이름과 클라우드 컴퓨터 제공 여부는 이차 글마다 문장이 같다 해도, 이번 검색 결과에는 openai.com의 발표 URL이 없었다. 그 두 세부 사양은 이 글에서 사실로 단정하지 않는다. 식별은 여기까지다. Dots는 사람 앞에서 상주하며 일을 이어 간다고 보도된 OpenAI 에이전트다. 필자 운영에서 그 자리는 그록봇이 맡고, Dots를 실행 장부에 올려 둔 기록은 없다. 창구를 둘로 늘리면 이 문서가 줄이려는 복사 비용이 다시 생긴다.

Hermes Agent와 Hermes 3

Hermes라는 이름도 두 개다. Hermes 3는 Nous Research의 언어 모델 페이지에 소개된 모델이다. 주소는 nousresearch.com/hermes3다. Hermes Agent는 그 페이지와 다른 소프트웨어다. 공식 문서는 Nous Research가 만든 자가 학습 에이전트라고 적는다. 경험을 스킬로 만들고, 쓰는 동안 그 스킬을 고치고, 세션을 넘어 기억을 남긴다. IDE에 묶인 코딩 보조도, 단일 API를 감싼 챗봇도 아니라고 같은 페이지가 선을 긋는다. 게이트웨이 하나로 Telegram, Discord, Slack, WhatsApp을 포함한 여러 메신저를 받고, 격리된 서브에이전트를 띄워 병렬 작업을 나눈다. 크론으로 예약을 돌리고, Bot Mode에서는 이름 있는 봇이 그룹 채팅과 멘션으로 협업한다. 저장소는 github.com/NousResearch/hermes-agent이고, 2026년 10월 21일 조직 페이지에서 Python과 MIT로 표시되어 있었다. 도입 순서와 게이트웨이는 Hermes Agent 도입 글이 따로 적는다.

같은 조직의 hermes-agent-self-evolution 저장소 설명은 스킬과 프롬프트와 코드를 진화적으로 고친다고 되어 있고, 설명문에 DSPy와 GEPA가 있다. 필자의 플레이북은 그 저장소를 실행하지 않는다. 필자는 실패한 허가와 보고 형식을 오케스트레이션 문서에 한 줄로 남긴다. Hermes 문서의 학습 루프는 에이전트가 스킬을 스스로 만드는 쪽이고, 필자 문장은 사람이 다음 지시서에 반영하는 쪽이다.

필자의 상시 실행 목록에는 Hermes Agent가 없다. 작업자 자리에 앉힌다면 메신저로 말하는 사람과 일을 수행하는 에이전트를 다시 섞지 않는다. 사람이 말하는 자리는 그록봇이고, Hermes는 지시서의 성공 조건과 허용 경로와 요약 파일만 돌려주는 실행기다. Hermes 자신의 서브에이전트는 그 실행기 안에서 끝나는 병렬이고, 그 병렬의 로그를 그록봇 대화에 다시 붙이지 않는다.

지시서에 적는 목표와 경계

지시서는 실행기가 추측으로 범위를 넓히지 못하게 하는 한 장이다. 필자의 래퍼가 읽는 칸은 id, goal, cwd, mode, output_dir, allowed_write_paths, context_files, success_criteria, allow_bash, model, effort, max_turns, timeout, web이다. goal 안에는 누가 부탁했는지, 무엇을 만들지, 왜 필요한지가 들어간다. 보고 형식은 별도 칸으로 요약 파일 하나를 지정한다.

이 칸이 토큰을 줄이는 방식은 단순하다. 성공 조건이 없으면 실행기가 관련 있어 보이는 파일을 계속 연다. 허용 경로가 없으면 저장소 밖까지 쓰기가 퍼진다. 참고 파일이 목록이 아니면 디스크 전체가 맥락 후보가 된다. 턴과 시간 상한은 한 작업이 창구의 다음 확인을 무기한 붙잡지 않게 한다. web을 끄면 그 작업은 이미 넘긴 파일 안에서 끝낸다.

허용 명령은 한 번 실패한 적 있다. 셸 프로그램 하나에 와일드카드를 허용하면 그 셸의 cmdlet까지 허용될 것으로 보였는데, 실제로는 그렇지 않았다. 그래서 필자의 allow_bash는 실행할 명령 문자열을 그대로 적는다. 넓은 허가 한 줄은 짧은 목록보다 사고가 났고, 짧은 목록이 재시도를 줄였다.

아래 JSON은 필자의 래퍼가 읽는 지시서 예시다. 경로와 모델 이름은 자리표시자이고 비밀은 들어 있지 않다.

{
  "id": "20261021-long-draft",
  "goal": {
    "who": "요청한 사람",
    "what": "지정한 폴더에 초고 파일과 요약 파일을 남긴다",
    "why": "메인 창구가 긴 생성을 직접 하지 않기 위해"
  },
  "cwd": "D:/work/repo",
  "mode": "draft",
  "output_dir": "D:/work/out/long-draft",
  "allowed_write_paths": ["D:/work/out/long-draft"],
  "context_files": ["D:/work/repo/NOTES.md"],
  "success_criteria": [
    "output_dir에 SUMMARY.md가 있다",
    "SUMMARY.md는 결과와 남은 일만 적는다"
  ],
  "allow_bash": [],
  "model": "일 무게에 맞는 모델 이름",
  "effort": "medium",
  "max_turns": 40,
  "timeout": "45m",
  "web": false,
  "report": "D:/work/out/long-draft/SUMMARY.md"
}

사람이 그록봇에 말하는 문장과 이 JSON은 역할이 다르다. 사람은 "이 노트로 초고를 쓰고 요약만 가져와"처럼 말한다. 그록봇이 그 문장을 위 칸으로 옮긴다. 실행기는 사람의 말투가 아니라 칸을 본다. 칸이 비어 있으면 실행기는 빈칸을 좋은 뜻으로 채우지 않고, 그록봇이 칸을 채운 뒤에야 출발한다.

일 무게에 따라 보내는 실행기

모든 일을 가장 강한 실행기에 보내지 않는다. 확인과 계획은 이미 사람이 붙어 있는 그록봇에서 끝나고, 생성 길이가 긴 일만 PC로 나간다. 필자가 쓰는 나눔은 다음 표다.

이 나눔의 기준은 벤치마크 점수가 아니다. 메인 창구의 할당량을 그 일이 얼마나 먹는지, PC가 그 일을 창 없이 견딜 수 있는지가 기준이다. 긴 초고는 창구 안에서 할당량을 빨리 썼다. 저장소 수정은 Cursor 쪽 스킬이 이미 있으므로 그 CLI가 맡는다. MCP를 켠 채 여러 창을 띄우면 메모리가 급증한 기록이 있으므로, 그 조합은 기본이 아니다.

병렬에도 상한을 숫자로 박아 두지는 않았다. 필자 문서에 "동시에 N개"라는 고정 숫자는 없다. 대신 실패한 조합이 있다. 보이는 터미널과 메모리 급증이 겹치면 PC가 멈춘다. 그래서 백그라운드 CLI는 창이 없고, 그 작업의 MCP는 꺼져 있다. 전체 렌더처럼 PC를 오래 붙잡는 공유 자원만 잠금으로 하나씩 돌린다. 그 밖의 작업은 서로 다른 출력 폴더에서 병렬이다.

Muse Spark의 공식 설명이 보여주는 서브에이전트는 한 제품 안의 병렬이다. 필자의 병렬은 프로세스 단위다. 출력 폴더가 겹치지 않을 때 나란히 두고, 같은 산출 파일을 두 프로세스가 쓰면 잠근다. Dots처럼 대화 사이에 일이 남는 에이전트를 두 번째 창구로 열면, 사람이 읽을 요약이 두 갈래가 된다. 필자 운영은 그 갈래를 만들지 않고 그록봇의 요약 하나로 모은다.

실행 장부와 이어하기 스펙

보내기 전에 그록봇은 실행 장부를 본다. 장부에는 작업 id, 상태, 시작 시각, 실행기, 출력 폴더가 있다. 같은 id가 이미 돌고 있거나 끝나 있으면 다시 보내지 않는다. 사람이 비슷한 말을 두 번째로 해도, 장부가 막으면 실행기는 침묵한다. 중복 실행은 할당량을 두 배로 쓰고 파일도 두 벌로 만든다.

작업이 중간에서 멈추면 필자는 같은 지시서를 다시 열지 않는다. 이어하기 스펙을 새로 적는다. 그 스펙에는 이전 id, 이미 끝난 항목, 이미 있는 파일, 남은 항목, 여전히 유효한 허용 경로가 들어간다. 실행기는 끝난 항목을 다시 생성하지 않고 남은 항목만 쓴다. 처음부터 다시 열면 이미 읽은 참고 파일과 이미 쓴 초고가 맥락으로 또 들어간다.

아래 JSON은 목차 파일만 생기고 본문이 남지 않은 뒤를 잇는 예시다. 앞의 지시서를 복붙한 뒤 문장 몇 개만 더한 형태가 아니다.

{
  "id": "20261021-long-draft-cont",
  "continues": "20261021-long-draft",
  "already_done": ["목차 파일을 썼다"],
  "files_already_written": ["D:/work/out/long-draft/OUTLINE.md"],
  "remaining": ["OUTLINE.md의 남은 절을 본문으로 쓴다", "SUMMARY.md를 남긴다"],
  "do_not_restart": true,
  "allowed_write_paths": ["D:/work/out/long-draft"],
  "success_criteria": ["SUMMARY.md가 있고 남은 일이 비어 있다"],
  "report": "D:/work/out/long-draft/SUMMARY.md"
}

장부와 이어하기가 같이 있을 때 메인 창구의 읽기 양은 한 줄로 줄일 수 있다. 그록봇은 "이 id는 목차까지 끝났고, 남은 것은 본문과 요약"이라는 문장만 잇는다. 이전 실행의 도구 로그를 대화에 다시 붙이지 않는다. 로그가 필요하면 출력 폴더에 있고, 창구는 그 경로가 존재한다는 사실만 안다.

허용 명령의 교훈도 장부 옆에 남긴다. 한 번 거부된 명령 문자열은 다음 스펙의 allow_bash에 그대로 올리기 전에, 그 명령이 정말 필요한지부터 스펙의 성공 조건과 맞춰 본다. 성공 조건이 파일이 생기는 것이면 셸은 비어 있어도 된다. 앞의 예시 JSON이 allow_bash를 빈 배열로 둔 이유가 그것이다.

요약만 올리는 보고

실행이 끝나면 메인 창구로 돌아오는 보고는 요약 파일 하나다. 확인이 그림으로 충분한 작업이면 이미지 하나다. 둘을 한꺼번에 길게 붙이지 않는다. 그록봇은 그 파일만 읽고, 사람이 휴대폰에서 보는 것도 그 요약이다.

요약에 들어가는 내용은 세 덩어리면 된다. 성공 조건 중 무엇이 충족됐는지, 출력 폴더에 무엇이 있는지, 사람이 다음에 말해야 할 판단이 있는지다. 시도한 명령의 전문, 읽은 파일의 전문, 실패한 추측의 나열은 요약이 아니다. 그것은 출력 폴더의 로그로 남고 창구에는 경로만 적힌다.

이 제한이 할당량에 닿는 이유는 메인 모델이 다시 읽는 토큰이 요약 길이로 고정되기 때문이다. 초고가 만 자여도 창구가 만 자를 다시 받지 않는다. 창구가 만 자를 다시 받으면, 무거운 일을 CLI로 보낸 이유가 사라진다. 필자 운영에서 이 계약은 실행기마다 같다. Grok Build도, Cursor CLI도, 동료 봇도 요약 하나만 올린다.

요약이 성공 조건을 빠뜨리면 그록봇은 일을 끝으로 처리하지 않는다. 이어하기 스펙에 "요약에 성공 조건 대조가 없다"를 남은 일로 적고, 본문 재생성을 시키지는 않는다. 보고 형식의 실패와 작업 자체의 실패를 같은 재시작으로 섞지 않는다.

잠금과 병렬 그리고 플레이북에 남기는 문장

잠금은 자주 쓰지 않는다. 필자가 잠그는 경우는 전체 렌더처럼 한 대가 오래 붙잡는 공유 자원이다. 출력 폴더가 다른 조사, 초고, 저장소 수정은 잠그지 않고 나란히 둔다. 잠금이 기본이 되면 창구가 아끼려던 대기 시간이 다시 길어진다. 잠금을 안 거는 기본값이 먼저이고, 예외만 잠근다.

병렬의 실제 한도는 문서의 정수가 아니라 PC가 멈춘 조합이다. 창이 보이는 CLI를 여러 개 띄우고 메모리가 급증하면 기계가 멈췄다. 그 뒤로 필자의 런처는 백그라운드와 무창을 기본으로 하고, 작업에 필요 없는 MCP 서버를 끈다. Cursor 변경 기록이 MCP를 끄는 명령을 제공한다는 사실과, 필자가 런처에서 서버를 끄고 시작한다는 사실은 서로 맞닿아 있지만 문장이 같지는 않다.

같은 실패가 반복되면 필자는 오케스트레이션 스킬 문서에 그 문장을 남긴다. 와일드카드 셸 허가가 cmdlet을 덮지 못한 일, 무창과 MCP 종료가 PC 정지를 피한 일, 요약은 파일 하나라는 계약이 그런 문장이다. 다음 지시서는 그 문장을 허용 명령과 보고 형식과 런처 옵션에 반영한다. 이것이 필자의 플레이북이다.

Nous Research의 self-evolution 저장소는 스킬과 프롬프트를 자동으로 고치는 쪽을 설명하고 있다. 필자의 플레이북은 그 저장소를 실행하지 않는다. 사람이 읽은 실패를 한 줄로 고정해 다음 스펙이 같은 실패를 다시 사지 않게 하는 문서다. 자동 최적화의 품질은 이 글의 확인 범위 밖이다.

한 번의 작업을 시간 순서로 보면 다음과 같다. 사람이 그록봇에 말한다. 그록봇이 장부에서 id를 찾는다. 없으면 지시서 칸을 채우고 일 무게로 실행기를 고른다. 런처가 창 없이 프로세스를 띄우고, 허용 경로 밖은 스펙이 막는다. 끝나면 요약 파일 하나만 그록봇이 읽는다. 중간에 끊기면 이어하기 스펙이 다음 id로 나간다. 새로 배운 실패는 플레이북에 한 줄 추가된다. 이 순서는 제품이 Muse Code이든 Hermes Agent이든, 작업자 자리에 앉히는 순간 같은 칸을 요구한다. 칸이 없는 에이전트는 필자 운영의 실행기가 아니다.

마무리

앞에서 다룬 한 창구 오케스트레이션의 핵심만 짧게 정리한다.

• 사람이 말하는 창구는 그록봇 하나이고, 계획과 요약 확인만 거기서 한다.
• 무거운 실행은 Grok Build CLI로 빼고, 저장소 스킬 작업은 MCP를 끈 Cursor CLI가 맡는다.
• Muse Spark는 Meta의 공식 모델이고, Muse Code와 Dots와 Hermes Agent는 공개 작업 에이전트로 식별만 했다.
• 지시서에는 목표, 입력, 성공 조건, 허용 경로, 보고 형식이 있다.
• 실행 전에 장부를 보고, 중단되면 처음부터 다시 열지 않는 이어하기 스펙을 쓴다.
• 보고는 요약 하나이고, 잠금은 전체 렌더처럼 무거운 공유 자원에만 건다.

「한 창구가 지시하고, 실행기는 요약만 돌려준다.」 필자는 같은 교훈이 반복되면 오케스트레이션 스킬 문서에 한 줄씩 남긴다. 그 문장이 다음 지시서의 허용 범위와 보고 형식을 줄인다.

출처와 링크

조사 기준일은 2026년 10월 21일이다. 운영 수치 61%와 닷새, 무창 실행, 잠금 범위, 지시서 칸은 필자의 2026년 10월 기록이다. 아래 링크는 제품 식별에 쓴 공개 주소다.

• Grok Bot 개요
• Muse Spark 공식 소식, Meta, 2026-04-08, 5월 12일 업데이트 포함
• Muse Code 문서
• Grok Build 소스 README, xai-org/grok-build
• Grok Build 문서 개요
• Grok Build 제품 입구
• Cursor CLI 변경 기록, 2026-01-08
• Hermes Agent 문서
• Hermes Agent 저장소, Nous Research
• Hermes Agent self-evolution 저장소
• Hermes 3 모델 페이지
• Dots 보도, Presenc.ai, 2026-09-29
• Dots 보도, PTI, 2026-09-30