본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 28. 15:02

Codex와 Claude Code의 /goal 명령 실무 적용

요약

OpenAI Codex와 Anthropic Claude Code가 출시한 '/goal' 명령의 차이점과 실무 적용 사례를 분석합니다. 이 명령은 에이전트가 사용자의 개입 없이 설정된 완료 조건이 충족될 때까지 스스로 작업을 지속하게 합니다.

핵심 포인트

  • Codex는 로컬 저장 방식을 통해 작업의 연속성을 보장함
  • Claude Code는 소형 모델을 감독관으로 활용해 비용 효율적으로 목표 달성을 확인함
  • 인간의 개입(Human-in-the-loop)을 최소화하여 반복적인 디버깅과 스크래핑 자동화 가능

/goal은 OpenAI Codex CLI (4월 30일)와 Anthropic Claude Code (5월 12일)가 불과 11일 간격으로 출시한 새로운 명령입니다.

아이디어는 간단합니다. 완료 조건(completion condition)을 부여하면, 해당 조건이 충족될 때까지 스스로 계속 실행됩니다.

/goal이 나오기 전에는 AI 코딩 에이전트(AI coding agents)가 매 턴마다 멈춰서 사용자가 Enter 키를 누르기를 기다려야 했습니다. 프롬프트에 "X까지 계속 진행해"라고 말하더라도 여전히 일시 중지되었습니다. /goal은 이를 해결하기 위한 방안입니다.

두 구현 방식의 차이점

Codex는 작업을 로컬(locally)에 저장합니다. 노트북을 닫거나 재부팅하더라도 작업이 유지되며, /goal resume으로 재개할 수 있습니다. 제어 기능으로는 생성(create), 일시 중지(pause), 재개(resume), 삭제(clear)가 있습니다. 앱 서버(app-server) 상에서 유지되는 워크플로(workflow) 방식입니다.

Claude Code는 다른 경로를 택합니다. 더 저렴한 소형 모델(기본적으로 Haiku)이 감독관(supervisor) 역할을 수행합니다. 매 턴이 끝날 때마다 감독관이 트랜스크립트(transcript)를 읽고 한 가지 질문에 답합니다: "목표가 달성되었는가?" 만약 아니라면 계속 진행하고, 그렇다면 중단하고 제어권을 돌려줍니다. 토큰(Token) 관점에서 감독관은 별도로 비용이 청구되며 메인 모델의 예산을 소모하지 않습니다.

동일한 문제에 대한 두 가지 경로 — 에이전트가 스스로 완료 여부를 결정하게 만드는 것입니다.

세 가지 전/후 시나리오

1. 데이터 스크래핑(data scrape) 실행

이전: 세 개의 브랜드에서 제품을 스크래핑하도록 요청합니다. 브랜드 1을 마치고 멈춰서 "계속할까요?"라고 묻습니다. 사용자가 계속을 누릅니다. 브랜드 2를 마치고 다시 멈춥니다. 브랜드 3은 성공률 92%에서 종료되며, 실패한 부분은 수동으로 재시도해야 합니다. 저녁 내내 Enter 키만 누르고 있게 됩니다.

이후: "세 브랜드 모두 스크래핑해줘. 실패 시 3번 자동 재시도하고, 95% 미만은 완료로 치지 마."라고 말합니다. 노트북을 닫고 밥을 먹으러 갑니다. 돌아와 보니: 첫 번째 시도는 92%였지만, 스스로 한 번 재시도하여 96%를 달성하고 완료되었습니다.

차이점은 "95%를 완료로 간주한다"는 것입니다. /goal은 이 결정을 사용자가 아닌 에이전트의 판단으로 전환합니다.

2. Mac 앱 패키징

이전: 빌드(Build)가 실패하면, 구글링을 하고, 2014년 Stack Overflow 스레드를 찾아 적용해보고, 새로운 에러가 나면 다시 구글링하고, 다시 시도합니다. 20회 이상의 라운드가 반복됩니다. 새벽 2시가 되었는데도 여전히 키보드 앞에 앉아 있습니다.

이후: "빌드 스크립트가 배포 가능한 패키지를 생성하도록 하세요. 실패하면 에러를 직접 읽고, 해결 방법을 검색한 뒤, 배포될 때까지 재시도하세요." 노트북을 닫고 잠을 잡니다. 아침: 4번의 라운드 동안 각각 다른 문제를 진단하고 수정합니다. 패키지 빌드 완료.

/goal 명령은 "에러 읽기 → 검색 → 패치 → 재실행"으로 이어지는 인간의 루프 (human loop)를 삼켜버립니다.

3. 출장 중 서버 다운

이전: 출장 중에 서버가 다운됩니다. 휴대폰 연결이 안 되어 수정 사항을 푸시(push)할 수 없고, 스스로 복구되기를 바라며 10분마다 모니터링 페이지를 새로고침합니다.

이후: 노트북을 열고 "서버에 원격 접속해서 왜 다운되었는지 파악하고, 수정하고, 엔드포인트(endpoint)가 복구되었는지 확인해"라고 말합니다. 그리고 출장을 계속합니다. 집에 돌아오면 이미 완료되어 있습니다.

에이전트는 로그인하고, 로그를 읽고, 원인 파일을 찾아 삭제한 뒤, 재시작하고, 검증까지 마쳤습니다. 그리고 메모를 남겼습니다: "이런 종류의 파일이 다시 유입되지 않도록 하세요."

이것은 과거에 오직 인간만이 할 수 있었던 작업이었습니다.

이것이 중요한 이유

엔지니어링 관점에서 /goal은 어렵지 않습니다. Codex는 상태 머신 (state machine)에 저장 공간을 더한 것이며, Claude Code는 보조적인 LLM 호출 (secondary LLM call)입니다.

하지만 이것은 지난 2년 동안 그 어떤 AI 코딩 에이전트도 해결하지 못한 문제를 해결합니다:

메인 모델은 자신이 일을 끝냈는지 알 수 없습니다.

모델은 코드를 작성하는 데에만 초점을 맞추고(zoomed in) 있습니다. "완료"를 위해서는 시야를 넓히는 것(zoom out)이 필요합니다. Anthropic의 방식 — Haiku가 시야를 넓히게 하는 방식 — 은 아름다운 분업입니다.

같은 주에 Anthropic은 /loop, /batch, /background 기능도 출시했습니다. /loop는 N번 실행됩니다. /batch는 작업을 병렬화(parallelize)합니다. /background는 백그라운드에서 실행됩니다. 이 세 가지 모두 여전히 "언제 멈출 것인가"는 사용자에게 맡깁니다. 오직 /goal만이 그 권한을 에이전트에게 넘깁니다.

중단 비트 (stop bit)를 넘겨주는 것이 진정한 패러다임의 전환입니다.

개발자가 고민해야 할 점

/goal은 당신의 노력을 프로세스를 미세 관리(micromanaging)하는 것에서 목표를 정의하는 것으로 옮겨줍니다.

목표에 작성해야 할 네 가지 요소:

  • 중단 조건 (Stop condition) — 무엇을 "완료"로 간주할 것인가
  • 검증 (Verification) — 완료되었음을 어떻게 증명할 것인가
  • 건드려서는 안 될 경계 (Untouchable boundaries) — 무엇을 변경하지 말아야 하는가
  • 성공 지표 (Success metric) — 수치화할 것 (예: 성공률 ≥95%)

모호한 프롬프트는 한 번의 턴 (turn)을 낭비하지만, 모호한 목표는 6시간을 낭비할 수 있습니다.

하지만 명확한 목표는 에이전트 (agent)가 사용자의 개입 없이 8시간 동안 스스로 실행될 수 있게 합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0