/goal 은 기능이 아닙니다. 그것은 프리미티브입니다.
HTTP 는 프리미티브입니다. JSON 은 프리미티브입니다. /goal 은 코딩 에이전트를 위한 프리미티브가 되고 있습니다.
몇 주 전, OpenAI 의 Codex CLI 가 /goal 을 추가하여 코딩 워커에게 정의된 완료 상태를 가진 작업을 부여하는 방법을 제공했습니다. Claude Code 도 이번 주에 추가했습니다.
Hermes Agent 는 제가 Mac Mini 에서 실행하여 코딩 워커 간의 작업을 조정하는 오케스트레이터로, /goal 이 한동안 내장되어 있었습니다.
그래서 저는 이제 빌더, 리뷰어, 오케스트레이터가 모두 동일한 명령 형식을 받아들이지만, 그 외에는 아무것도 공유하지 않습니다.
당신이 /goal 을 단지 더 멋진 프롬프트로만 보았다면, 그것이 무엇을 바꾸는지 놓친 것입니다.
/goal 이 실제로 무엇인가
일반 프롬프트는 에이전트에게 다음 응답을 요청합니다. 당신은 돌아온 내용을 읽고, 올바른지 판단한 후, 에이전트를 다음 단계로 밀어 넣습니다. 당신은 매 턴마다 조종하고 있습니다.
/goal 은 이를 뒤집습니다. 당신은 '완료'가 어떻게 보이는지 적고, 한 번 제출하면 에이전트가 그 상태에 도달할 때까지 작업합니다. 실제 예시입니다:
1/goal SPEC.md 에 설명된 앱을 빌드하세요. 완료는 테스트 통과, 빌드 통과, README 정확성, git status 에 관련 프로젝트 파일만 표시됨을 의미합니다.
목표는 달성되거나, 일시 중지되거나, 차단되거나, 지워지거나, 예산이 소진될 때까지 활성 상태를 유지합니다.
이는 일반적인 원샷 명령 안에 'goal'이라는 단어를 넣는 것과는 다릅니다. codex exec 'goal: build the app'이라고 작성하면 여전히 레이블이 있는 프롬프트입니다. 진정한 프리미티브는 대화형 워커 세션 안에 있습니다. CLI 를 실행하고, /goal 을 제출한 후, 자리를 떠납니다.
전환은 프롬프팅(당신이 운전)에서 할당(당신이 정의한 목표를 향해 에이전트가 운전)으로의 변화입니다.
GIF
현재 /goal 을 사용하는 세 가지 도구
/goal 을 받아들이는 세 가지 도구는 모두 같은 종류가 아니므로, 구체적으로 살펴볼 가치가 있습니다.
Codex 는 OpenAI 의 코딩 CLI 입니다. 특히 명확한 사양이 주어졌을 때 구현에 강점이 있습니다. /goal 은 그 사양을 전달하는 방법입니다.
Claude Code 는 Anthropic 의 코딩 CLI 입니다. 반대 방향, 즉 올바르게 보이는 코드에서 무엇이 잘못되었는지 찾는 데 강점이 있습니다. 사양 준수, 안전 문제, 오류 상태, 보안 허점 등입니다. /goal 은 코드를 가리키며 리뷰를 요청하는 방법입니다.
Hermes Agent 는 완전히 다른 종류의 도구입니다. 코딩 워커가 아니라, 위의 두 도구와 같은 코딩 워커 간의 작업을 조정하는 오케스트레이터입니다. /goal 은 Hermes 가 작업에 적합한 도구에 작업을 넘기는 방법이자, 제가 Hermes 에게 원하는 바를 처음에 알리는 방법이기도 합니다.
중요한 것은 그들 중 하나가 /goal 을 출시했다는 것이 아닙니다. 세 개의 다른 팀이 동일한 프리미티브에 수렴했다는 점이며, 그 수렴이 이들을 조합 가능하게 만듭니다.
GIF
설정하기
Hermes 를 실행하는 Mac Mini 에 Codex 와 Claude Code 가 처음 필요했을 때, 직접 설치하지 않았습니다. Hermes 에게 두 도구를 설치하고 로그인해 달라는 메시지를 보냈습니다. 나머지는 Hermes 가 처리했습니다.
이제 그게 워크플로입니다. 설치 명령을 입력하지 않습니다. 설정은 또 다른 목표일 뿐입니다.
아직 오케스트레이터를 실행하고 있지 않다면, Codex 와 Claude Code 의 설치 페이지를 따라가는 것이 충분히 쉽습니다. 하지만 일단 오케스트레이터를 갖추면, 다른 도구를 수동으로 설정해서는 안 됩니다. 오케스트레이터를 두는 요점은 기계적인 작업이 더 이상 당신의 일이 아니라는 것입니다.
Hermes 가 /goal 위에 추가하는 것
원시 /goal 은 그 자체로 유용합니다. 하지만 조정 문제를 남깁니다.
Codex 가 한 터미널에서 실행되고 Claude Code 가 다른 터미널에서 실행 중이라면, 어떤 프로세스가 무엇을 하고 있는지 기억해야 합니다. 로그를 확인해야 합니다. 리뷰 결과를 한 도구에서 다른 도구로 수동으로 전달해야 합니다.
Hermes 는 이러한 분리된 실행을 워크플로로 전환합니다:
- Hermes 에게 메시지를 보냅니다 (제 경우에는 휴대폰의 Telegram 을 통해).
- Hermes 가 Kanban 보드에 목표 카드를 생성합니다.
- Hermes 가 각 카드에 적합한 워커를 선택합니다.
- 워커가 백그라운드에서 목표를 실행합니다.
- 카드는 프로세스 ID, PID, 저장소 및 완료 기준을 저장합니다.
- 빌드가 준비되면 Hermes 가 저장소를 리뷰어에게 전달합니다.
- 리뷰가 차단되면 Hermes 가 결과를 수정 목표로 다시 보냅니다.
- Hermes 가 파일 시스템, 테스트, 빌드 및 git 상태를 검사하여 최종 출력을 검증합니다.
보드는 오케스트레이터가 그 위에 있을 때 /goal 이 되는 것입니다. 모든 목표에는 카드가 있고, 모든 카드에는 상태가 있으며, 모든 인계는 흔적을 남깁니다. 터미널을 뒤지는 대신, 휴대폰에서 작업이 열을 가로질러 이동하는 것을 지켜봅니다.
세 가지 역할
도구는 변합니다. 역할은 변하지 않습니다.
Orchestrator. 제어 루프를 소유합니다. 작업 분해, 워커 선택, Kanban 카드, 백그라운드 프로세스, 종속성, 최종 검증, 사용자 대상 요약입니다. 제 설정에서는 Hermes 입니다.
Builder. 사양을 받아 작동하는 코드를 생성합니다. 구현이 이 역할이 해결하는 병목 지점입니다. Codex 가 여기서 강한 편입니다.
Reviewer. 빌더가 생성한 것을 읽고 문제점을 찾습니다. 정확성이 병목 지점입니다. Claude Code 가 여기서 강한 편입니다.
실제 실행, 처음부터 끝까지
Hermes 에이전트에게 다음 목표를 주었습니다:
1/goal 나에 대한 X 언급을 찾고 문제가 터지면 알림을 보내는 CLI 도구를 빌드하세요.
Hermes 는 요청을 6개의 카드로 분할했습니다.
Shubham Saboo
@Saboo_Shubham_
·
Codex /goal 이 빌드합니다.
Claude Code /goal 이 리뷰하고 개선합니다.
Hermes /goal 이 오케스트레이션과 인계를 관리합니다.
모두 단일 Kanban 보드에서 추적되며 에이전트는 루프에서 계속 실행됩니다.
58
61
852
카드 1: 사양. Hermes 가 SPEC.md 자체를 작성하여 스택, 저장소 경로, 읽기 전용 제약 조건, 모의 모드 요구 사항, 테스트 및 검증 명령을 캡처했습니다. PM 역할이 소유합니다.
카드 2: Codex 빌드. Codex 가 SPEC.md 에 대해 /goal 을 실행했습니다. 프로젝트 파일을 생성하고, UI 와 백엔드를 구현하고, 테스트를 추가하고, 앱을 통과 상태로 만들었습니다. 약 15분이 걸렸습니다. 완료되면 npm test 가 통과하고, npm run build 가 통과했으며, git status 에는 관련 새 파일만 표시되었습니다.
카드 3: Claude Code 리뷰. Claude Code 가 Codex 가 빌드한 것을 리뷰하기 위해 /goal 을 실행했습니다. 사양 준수, 읽기 전용 안전성, API 키 처리, 오류 상태, 테스트, UI 유용성, 버그 및 보안 문제를 확인했습니다. 결과: 통과, 차단 문제 없음.
카드 4: Codex 수정 루프. 리뷰가 통과되었으므로 건너뛰었습니다. 건너뛰어도 카드는 여전히 중요합니다. Hermes 가 조건부 작업을 모델링할 수 있음을 보여줍니다. Claude Code 가 차단했다면 Hermes 가 결과를 새 /goal 로 Codex 에게 전달했을 것입니다.
카드 5: Claude Code 최종 검증. 같은 이유로 건너뛰었습니다.
카드 6: Hermes 최종 요약. 로컬 경로에서 작동하는 앱, UI 와 API 모두 모의 모드에서 검증됨. Codex 가 /goal 로 빌드하고, Claude Code 가 /goal 로 리뷰하여 통과를 반환했습니다.
이 모든 것이 하나의 메시지에서 나왔습니다. 세 가지 다른 도구가 실제 작업을 수행했지만, 저는 Hermes 에게만 말했습니다.
검증 규칙
Hermes 는 Codex 의 자체 보고를 절대 신뢰하지 않았습니다. Codex 가 빌드 완료를 표시한 후, Hermes 가 직접 명령을 실행했습니다:
1npm test # 17개의 테스트 통과2npm run build # vite 빌드 통과
검증자는 /goal 을 약속 대신 계약으로 만드는 것입니다. 워커의 자체 보고를 최종으로 신뢰하지 마세요. 검증자를 신뢰하세요.
코딩 에이전트는 자신감이 넘칩니다. 빌드를 실행하지 않았는데 빌드가 통과했다고 말할 것입니다. 실행되지 않은 테스트를 작성하고 테스트가 통과했다고 말할 것입니다. 검증자가 그 간극을 메웁니다.
검증 없이 /goal 은 단지 더 멋진 프롬프트일 뿐입니다. 검증을 통해 그것은 계약이 됩니다.
GIF
여러 목표 실행하기
여러 /goal 을 병렬로 실행할 수 있지만, 먼저 고려하지 않고 여러 코딩 워커를 동일한 파일에 지정할 수는 없습니다.
제 기본값은 저장소당 하나의 주요 빌더입니다. 병렬 처리를 원한다면 명확한 경계를 넘어 추가합니다. 다른 저장소, 다른 브랜치, git worktree, 별도 패키지, 문서와 코드, 테스트와 구현 등 두 워커가 서로 간섭할 수 없는 곳이면 어디든 가능합니다.
나쁜 패턴은 세 명의 워커가 모두 동일한 저장소의 동일한 파일을 편집하는 것입니다. 충돌, 부분 덮어쓰기, 한 워커가 조용히 다른 워커의 작업을 취소하는 상황이 발생합니다.
더 나은 패턴은 특정 파일에 대해 한 번에 한 명의 작성자만 있는 것입니다. 빌더가 쓰고, 리뷰어는 읽기만 하며, 수정 목표는 수정 범위에 머뭅니다. 또는 세 가지 경쟁 접근 방식에 대해 세 개의 worktree 에서 세 명의 빌더를 실행하고 오케스트레이터가 가장 좋은 것을 선택하도록 합니다.
보드가 이를 실용적으로 만듭니다. 보드가 없으면 병렬 백그라운드 워커는 터미널 혼란이 됩니다.
저에게 바뀌는 점
여기서 유용한 프레임은 '백그라운드에서 에이전트를 실행할 수 있다'는 것이 아닙니다.
하나의 메시지가 세 가지 다른 코딩 도구를 거치는 파이프라인이 되고, 전체 과정이 하나의 보드에서 이동하는 것을 지켜보는 것입니다.
더 이상 터미널에 앉아 하나의 에이전트가 끝나기를 기다리지 않고, 보이는 상태로 작업 큐를 관리하기 시작합니다.
Codex 와 Claude Code 가 각각 자신만의 작업 인계 형식을 발명했다면, 어떤 오케스트레이터도 그들 사이를 라우팅할 수 없었을 것입니다. 보드는 인상적이지만, 프리미티브가 보드를 훨씬 더 유용하게 만듭니다.
워커는 바뀔 수 있지만, 프리미티브는 동일하게 유지됩니다. /goal 을 채택하는 다음 코딩 도구는 제가 아무것도 변경하지 않고 이 파이프라인에 합류할 것입니다. 그저 작업을 그쪽으로 라우팅하면 됩니다.
그것이 좋은 프리미티브가 하는 일입니다.
Hermes, OpenClaw, Claude Code, Codex 및 기타 24/7 에이전트 팀에 대한 더 많은 멋진 팁과 흥미로운 아이디어를 원하신다면.
팔로우 → @Saboo_Shubham_
