"내가 말한 거 다 했어?"
"이건 빠졌잖아. 다시 검토해줘."
"이것까지 해야지."

AI한테 일을 맡겼는데, 결과물 검토하는 게 또 일이 되죠.

이렇게 다시 짚게 될 일이라면, 프롬프트로 한 번 던지기보다 /goal로 걸어두는 편이 낫습니다.

여기서 말하는 /goal은 Claude Code와 Codex의 기능입니다. 켜는 법과 버전 조건은 맨 아래 적어뒀습니다.

왜 자꾸 제가 확인하게 되나

이유는 단순합니다. 모델은 "다 된 것처럼 보일 때" 멈춥니다.

에이전트가 답을 멈추는 순간이 곧 "끝났습니다"라는 선언입니다. 그런데 그 판단의 근거는 '실제로 다 됐는가'가 아니라 '다 된 것처럼 보이는가'입니다. 둘은 다릅니다.

Anthropic은 이 문제를 공식 문서에 적어두었죠.

Claude stops when the work looks done. ... "looks done" is the only signal available, and you become the verification loop.

(일이 다 된 것처럼 보이면 Claude는 멈춘다. … 다른 점검 수단이 없으면 "다 된 것처럼 보임"이 유일한 신호가 되고, 검증 루프는 당신이 떠맡게 된다.)

그래서 "끝났어?"는 사실 물어볼 필요가 없는 질문입니다. 멈췄다는 것 자체가 "끝났다"는 뜻이니까요.

진짜로 비어 있는 건 다른 질문입니다. 시킨 걸 빠짐없이 했나. 그게 사람한테 떨어집니다.

/goal이 진짜로 하는 일

/goal을 "목표를 걸어두는 명령"이라고만 보면 절반만 본 겁니다.

핵심은 완료 판정을 일한 모델 손에서 떼어내는 것입니다.

목표를 걸 때 그 프롬프트는 두 가지 역할을 동시에 합니다. 시작 지시이면서, 완료 기준이 됩니다. 무엇을 할지, 어떤 상태가 되면 끝인지를 같이 적어야 되죠.

/goal 이 초안을 발행 가능한 글로 다듬어줘. 제목·부제·리드·본문 흐름·결론을 정리하고, 확인되지 않은 내용은 단정하지 마. 마지막에 수정 요약과 추가 확인이 필요한 항목을 적어줘.

길어서 좋은 게 아닙니다. 끝이 보여서 좋은 겁니다.

Claude Code와 Codex는 '끝'을 다르게 확인합니다

같은 /goal이지만, Claude Code와 Codex가 완료를 확인하는 방식은 다릅니다. 이 차이를 알면 어디까지 믿을지 감이 잡힙니다.

Claude Code는 채점자를 갈아끼웁니다.

목표를 걸면, 매 턴이 끝날 때마다 다른 작은 모델(기본 Haiku)이 "조건이 충족됐나"를 따로 판정합니다. 아니라고 나오면 당신에게 제어를 돌려주는 대신 Claude가 다음 턴을 시작합니다. 문서의 표현 그대로, 완료는 일한 모델이 아니라 새 모델이 결정합니다.

completion is decided by a fresh model rather than the one doing the work

(완료는 일한 모델이 아니라 새로운 모델이 결정한다.)

Codex는 같은 모델에게 증거를 요구합니다.

Codex는 별도 모델을 두지 않습니다. 일한 모델 자신이 완료를 판정합니다. 대신 OpenAI는 매 턴 끝에 주입되는 지시문(저장소의 continuation.md)에 두 가지를 박아뒀습니다. 하나, 한 턴에 맞게 목표를 더 쉬운 일로 축소하지 마라. 둘, 완료를 입증되지 않은 것으로 취급하고 실제 상태와 대조해 확인하라.

같은 문제를 다른 길로 푼 겁니다. 한쪽은 채점자를 바꿨고, 한쪽은 채점자에게 증거를 요구했습니다.

왜 굳이 채점자를 떼어낼까

Anthropic은 /goal을 내놓기 전, 별도의 엔지니어링 글에서 이런 진단을 한 적이 있습니다. 에이전트에게 자기가 만든 결과물을 평가하라고 하면, 품질이 누가 봐도 평범한데 자신 있게 칭찬하는 경향이 있다는 겁니다. 그러면서 "일하는 모델과 판정하는 모델을 분리하는 것이 강력한 레버"라고 적었습니다.

그 글은 /goal을 직접 언급하지 않습니다. 그래서 "이게 /goal을 만든 이유"라고 단정할 수는 없습니다. 다만 같은 회사가 비슷한 시기에 내놓은 설계 사상을 나란히 놓고 보면, /goal의 별도 평가자는 그 사상을 제품으로 옮긴 것으로 생각됩니다.

Codex까지 같이 보면 더 흥미롭습니다. 두 회사가 같은 이름의 명령어 기능을 냈고, 둘 다 "모델은 자기가 끝냈는지를 스스로 잘 판정하지 못한다"는 같은 가정 위에 서 있는 것으로 보입니다. 한쪽은 채점자를 분리해서, 한쪽은 증거를 강요해서 그 가정을 다루죠.

이건 두 설계를 나란히 놓고 본 제 의견이지, 어느 쪽이 공식으로 선언한 문장은 아닙니다.

/goal 프롬프트 작성 기본 네 가지

저는 /goal 기능을 쓸 때 아래와 같이 쓰려고 노력합니다.

/goal [대상]을 [완료 상태]로 만들어줘. [하지 말 것 or 해야 할 것]은 지키고, 끝나면 [확인 방법]으로 검증해줘.
  1. 대상 — 무엇을 다룰지
  2. 완료 상태 — 어떤 상태가 되면 끝인지
  3. 제약 — 지킬 것(반드시 하거나 하지 말 것)
  4. 확인 방법 — 끝났음을 무엇으로 증명할지(테스트 결과, 명령 출력, 체크리스트 등)

특히 마지막이 자주 빠집니다. 그리고 이게 /goal의 핵심입니다.

"좋게 만들어줘"는 모호한 지시입니다. "발행 가능한 초안으로 만들고, 남은 확인 항목을 적어줘"는 완료 조건입니다.

Claude Code 문서도 좋은 조건의 요건을 셋으로 정리합니다. 하나의 측정 가능한 종료 상태(테스트 결과, 빌드 종료 코드, 빈 큐), 그걸 무엇으로 증명할지(npm test가 0으로 끝남, git status가 깨끗함), 지켜야 할 제약. 결국 같은 이야기입니다 — 끝을 숫자나 명령 출력으로 못 박을수록 좋습니다.

다른 일도 틀은 같습니다

코드를 맡길 때.

/goal 로그인 오류를 수정해줘. 관련 파일을 확인하고 최소 변경으로 고친 뒤, 기존 테스트를 돌려 통과 여부를 로그로 남겨줘. 원인과 수정 내용을 마지막에 짧게 정리해줘.

리뷰를 반영할 때.

/goal 이 PR의 리뷰 코멘트를 확인하고 반영해줘. 동의하기 어려운 코멘트는 바로 고치지 말고 이유를 적어줘. 수정 후 변경 요약과 확인한 테스트를 알려줘.

다만, 끝까지 맡겨도 남는 것

/goal은 만능이 아닙니다.

Claude Code의 평가자에는 분명한 제약이 있습니다. 그 모델은 도구를 실행하거나 파일을 직접 읽지 않습니다. 대화에 이미 드러난 것만 보고 판정합니다.

무슨 뜻이냐면 — Claude가 테스트를 실제로 돌리고 그 결과를 대화에 남기지 않으면, 평가자(다른 모델)는 "통과했다"는 말만 보고 통과로 판정할 수 있습니다. 완료 기준이 있다고 검증이 보장되는 게 아닙니다.

그래서 확인 방법은 모델의 자기 평가가 아니라 도구의 출력에 묶어야 합니다. "테스트했는지 확인해"가 아니라 "테스트를 돌리고 그 출력을 남겨"라고 적는 편이 낫습니다. 끝의 근거를 모델 바깥에 두는 겁니다.
앞의 코드 예제에서 '통과 여부를 로그로 남겨줘'가 바로 그 안전장치입니다.

완료의 근거는 그럴듯한 설명이 아니라 실행 결과에 둬야 합니다. /goal은 그걸 대신 해주지 않습니다. 다만 그렇게 쓰기 쉽게 만들어줍니다.

한 번 물을 일과 끝까지 맡길 일

모든 요청을 /goal로 걸 필요는 없습니다.

한 번 답을 받으면 끝나는 일 — 아이디어 뽑기, 문장 다듬기, 개념 설명, 선택지 비교 — 은 그냥 프롬프트가 낫습니다.

/goal은 큰일을 위한 명령입니다. 정확히는, 제가 중간에 다시 확인하고 싶어질 일을 위한 명령입니다.

맡기기 전에 저는 하나만 봅니다.

이거, 내가 중간에 또 확인할 것 같은가?

테스트가 통과했는지 물어볼 것 같다면. 남은 항목을 다시 물어볼 것 같다면. 그렇다면 처음부터 목표에 넣어두는 편이 낫습니다.

한 번 물을 일은 프롬프트로. 끝까지 맡길 일은 /goal로.

계속 상태를 지켜봐야 하는 일은 또 다릅니다. Claude Code의 /loop나 Codex의 Automations는 다른 글에서 따로 다뤄 보겠습니다.

준비 — 켜는 법과 버전

두 도구 모두 /goal이 바로 안 보일 수 있습니다. 해당 AI 도구의 프롬프트 창에서 이 기능이 켜져 있는지, 어떻게 쓰는지 직접 물어보는 것도 방법입니다.

참고한 문서