Codex /goal vs Claude Code /goal: 긴 코딩 작업은 어느 목표 루프에 맡길까?

Codex /goal과 Claude Code /goal은 모두 에이전트가 하나의 목표를 향해 계속 작업하게 만드는 기능처럼 보입니다. 하지만 실무에서 중요한 질문은 “어느 모델이 더 좋은가”가 아니라 “이 긴 코딩 작업의 루프를 누가 소유해야 하는가”입니다. 목표가 측정 가능하고, 검증 명령이 있으며, 권한과 중지 규칙이 정해져 있을 때만 goal loop가 안전하게 작동합니다.

작업이 이미 Codex 스레드, CLI 또는 로컬 Codex 흐름 안에 있고 결과가 테스트, typecheck, lint, snapshot 또는 reviewable diff로 증명될 수 있다면 Codex /goal을 고려할 수 있습니다. 작업이 Claude Code 세션 안에 있고 local steering, trusted workspace, permission mode가 중요하며 완료 조건이 세션에 노출된 증거로 판단될 수 있다면 Claude Code /goal이 더 자연스럽습니다. 요구가 바뀌거나, UI 판단이 필요하거나, production data와 secret이 걸려 있거나, abort rule이 없다면 둘 다 사용하지 않는 편이 낫습니다.

네 가지 경로부터 고르기

Codex goal, Claude Code goal, 일반 안내 세션, CI scheduler를 고르는 네 가지 경로 보드.

경로	사용할 때	시작 전 증거	중지 규칙
Codex `/goal`	Codex 안에서 범위가 좁은 저장소 작업을 처리하고 reviewable diff를 받아야 할 때.	테스트, lint, typecheck, snapshot 또는 diff inspection.	목표가 바뀌거나 diff가 넓어지거나 검증이 반복 실패하면 pause/clear.
Claude Code `/goal`	Claude Code 세션에서 권한 모드와 로컬 작업 흐름을 계속 보면서 진행해야 할 때.	evaluator가 세션의 tool output과 파일 변경을 보고 판단 가능해야 함.	완료 조건이 모호해지면 clear하거나 목표를 다시 작성.
일반 안내 세션	요구, 설계, UI 품질, 장애 분석이 중간에 바뀔 때.	발견 후마다 사람이 다음 결정을 내려야 함.	자동 반복을 걸지 않고 plan/chat 흐름 유지.
CI / scheduler	반복, 시간, 외부 트리거, 로그, 재시도가 핵심일 때.	workflow, cron, queue가 자체 상태와 실패 경로를 가짐.	자동화가 반복을 소유하고 agent는 workflow를 수정.

이 표는 승자를 정하기 위한 표가 아닙니다. goal loop는 완료가 증명될 수 있을 때만 유용합니다. “대시보드를 더 좋게”, “마이그레이션을 알아서 정리”, “전체적으로 개선” 같은 말은 완료 조건이 아닙니다. 그런 요청을 목표로 걸면 에이전트는 너무 일찍 멈추거나, 사람이 멈춰야 할 시점을 지나 계속 작업할 수 있습니다.

한국어권의 관련 설명에서는 Claude Code와 Codex의 철학, 속도, 로컬 이해도, 클라우드 작업, 예산 제어가 자주 섞입니다. 하지만 /goal을 실제로 쓸 때는 기능 비교보다 작업 계약이 먼저입니다. 목표는 무엇이 완료인지, 권한은 어떤 행동이 가능한지, 테스트는 무엇을 증명하는지, 리뷰는 병합해도 되는지를 나눠야 합니다.

/goal이 실제로 바꾸는 것

OpenAI Codex slash command 문서에서 Codex /goal은 확인 시점 기준 experimental command이며 goals feature flag와 연결되어 있습니다. 명령으로는 /goal <objective>, /goal, /goal pause, /goal resume, /goal clear가 확인됩니다. 따라서 모든 Codex 표면에서 동일하게 안정된 상시 기능이라고 쓰면 안 됩니다.

Claude Code의 /goal은 completion condition을 중심으로 설명됩니다. Claude Code가 여러 턴을 계속 진행하고, 각 턴 뒤에 evaluator가 세션에 드러난 증거를 보고 조건 충족 여부를 판단합니다. 이 구조에서는 목표가 평가 가능한 문장이어야 합니다. 실행하지 않은 테스트, 보이지 않는 파일 상태, 사람이 속으로만 알고 있는 기준은 좋은 완료 조건이 아닙니다.

공통점은 목표를 향해 계속한다는 점입니다. 차이는 실행 표면입니다. Codex는 app, IDE, CLI, cloud task처럼 route가 달라질 수 있고, 각 route의 저장소 접근, sandbox, 리뷰 경로가 다릅니다. Claude Code는 session, trusted workspace, permission mode, tool evidence가 핵심입니다. 그래서 선택은 브랜드가 아니라 현재 작업의 소유자와 증거 구조로 해야 합니다.

섞으면 안 되는 다섯 가지

판단 항목	Codex /goal	Claude Code /goal	의미
사용 가능성	확인한 문서에서는 experimental이며 goals flag가 필요합니다.	지원 버전과 trusted workspace가 필요합니다.	현재 owner source를 확인해야 합니다.
작업 표면	app, IDE, CLI, cloud route마다 경계가 다릅니다.	Claude Code session과 permission mode가 중심입니다.	목표가 다른 route의 권한을 가정하면 안 됩니다.
완료 증거	proof command나 reviewable diff가 강합니다.	evaluator는 세션에 보이는 증거를 봅니다.	증거가 흐리면 완료 판단도 흐립니다.
권한	sandbox나 command approval을 바꾸지 않습니다.	permission modes는 별도입니다.	loop는 승인 장치가 아닙니다.
사용량	긴 작업은 allowance를 더 쓸 수 있습니다.	subscription과 API-key route도 별도입니다.	실행 전 active route를 확인합니다.

특히 Claude Code에서는 plan mode, 승인 요청, edit 허용, auto mode의 차이를 목표가 대신 선택하지 않습니다. Codex에서도 branch, setup command, sandbox, review path는 사람이 정해야 합니다. goal loop는 경계를 만들어 주는 기능이 아니라, 사람이 작성한 경계를 오래 실행하는 기능입니다.

시작 전 목표 계약

장시간 coding agent 작업을 안전하게 시작하기 위한 목표 계약 체크리스트.

항목	충분한 목표	너무 모호한 목표
완료 상태	“packages/billing의 date parsing regression을 고쳐 해당 테스트가 통과한다.”	“billing을 정리한다.”
검증 명령	“`pnpm test packages/billing -- date`가 통과한다.”	“잘 되는지 확인한다.”
범위 경계	“parser, fixture, regression test만 수정한다.”	“필요하면 무엇이든 바꾼다.”
권한 모드	“코드 수정은 가능하지만 destructive shell command는 묻는다.”	“알아서 모두 처리한다.”
사용량 점검	“검증 명령이 두 번 실패하면 중지하고 보고한다.”	“될 때까지 계속한다.”
중지 규칙	“원인이 date parsing 밖이면 멈춘다.”	“판단해서 해결한다.”

좋은 목표는 prompt보다 acceptance contract에 가깝습니다. 짧아도 끝 상태, 증거, 범위, 중지 조건을 포함해야 합니다.

hljs text
Goal: In Codex CLI, update only checkout discount tests and rounding helper so pnpm test packages/checkout -- discount passes. Stop if payment provider code must change.

hljs text
Goal: In Claude Code, fix heading anchors in docs/api/authentication.md; the goal is complete when docs lint passes. Ask before editing outside docs/api/.

두 예시는 reviewer가 성공과 초과 변경을 구분할 수 있게 합니다. 반대로 proof command 없이 “더 좋게”라고만 쓰면, 에이전트가 많이 일하더라도 사람이 받아들일 기준이 없습니다.

/goal이 대신하지 않는 것

완료 조건과 권한, 테스트, 리뷰, 예산, 비밀정보를 분리한 경계도.

/goal은 권한 승인을 대신하지 않습니다. Claude Code가 어떤 행동 전에 승인을 요구하는 모드라면, goal이 있다고 해서 자동 승인되는 것이 아닙니다. Codex의 sandbox와 repo access도 goal로 확장되지 않습니다.

/goal은 테스트를 대신하지 않습니다. 완료 조건에 “tests pass”를 넣을 수는 있지만, 실제 테스트는 실행되어야 하고 결과가 관련 있어야 합니다. 좁은 테스트 하나가 통과해도 production risk가 사라지는 것은 아닙니다.

/goal은 코드 리뷰를 대신하지 않습니다. goal loop가 만든 diff는 여전히 사람이 읽어야 합니다. 변경 파일, 이유, 검증 명령, 스코프 밖 편집을 확인하고, 계약 밖의 리팩터링은 거부해야 합니다.

/goal은 비용 제한 장치가 아닙니다. 명확한 목표가 낭비 턴을 줄일 수는 있지만, 긴 작업은 더 많은 allowance를 쓸 수 있습니다. Codex와 Claude Code의 plan, API key, cloud route, subscription allocation은 현재 화면에서 확인해야 합니다.

/goal은 secret이나 production data를 보호하지 않습니다. 고객 데이터, live credential, billing migration, 되돌리기 어려운 production operation은 runbook, staging, backup, approval chain 안에서 다뤄야 합니다.

일반 세션이나 CI가 더 나은 경우

일반 안내 세션은 탐색하면서 목표가 바뀌는 작업에 맞습니다. 아키텍처 결정, UI 품질, 장애 분석, migration planning은 발견 후 사람이 다시 결정해야 합니다. goal loop는 그 결정 지점을 지나쳐 계속할 수 있습니다.

CI, scheduler, queue, repository automation은 반복과 시간이 핵심일 때 맞습니다. nightly dependency audit, 문서 검사, 배포 후 검증은 자체 로그, 재시도, 알림, 소유자를 가져야 합니다. coding agent는 workflow를 작성할 수 있지만 workflow 자체가 되어서는 안 됩니다.

전체적으로 Claude Code와 Codex 중 무엇을 채택할지 묻는 단계라면 /ko/posts/codex-vs-claude-code를 먼저 보는 편이 낫습니다. Claude의 subscription과 API billing 경계는 /ko/posts/claude-api-pricing-vs-subscription가 따로 다룹니다. 여기서는 /goal 작업 소유자만 다룹니다.

실무 목표 패턴

테스트 수정 목표

hljs text
Goal: Fix auth/session-expiry without changing public API behavior. Complete only when pnpm test auth/session-expiry passes and the diff touches only session expiry code and tests.

실패 범위와 검증 명령이 좁기 때문에 goal loop에 적합합니다.

범위가 있는 리팩터링

hljs text
Goal: Rename internal legacyToken helper to sessionToken inside packages/auth only. Complete when typecheck passes and no file outside packages/auth changes.

현재 작업이 Codex diff 중심이면 Codex에, Claude Code 로컬 세션과 권한 모드가 중요하면 Claude Code에 더 자연스럽습니다.

문서 일관성 목표

hljs text
Goal: Update three OAuth setup pages so each includes the same redirect URI warning and docs lint passes. Stop if product behavior must change.

출력과 중지 조건이 제한되어 있어 문서 작업에 적합합니다.

나쁜 목표: 넓은 개선

hljs text
Goal: Make the dashboard better.

완료 조건이 아닙니다. 먼저 일반 세션에서 문제 목록을 만들고 empty state, keyboard focus, loading error처럼 작은 목표로 쪼개야 합니다.

나쁜 목표: production risk

hljs text
Goal: Fix the production billing migration and keep going until it works.

이것은 runbook, backup, staging, approval이 필요한 영역입니다. goal loop가 소유할 작업이 아닙니다.

FAQ

Codex /goal과 Claude Code /goal은 같은 기능인가요?

아닙니다. 둘 다 completion condition을 향해 계속 작업한다는 아이디어를 공유하지만, Codex는 experimental slash command와 feature flag 문맥이고 Claude Code는 session 안의 completion condition과 evaluator evidence 문맥입니다.

무엇을 먼저 써야 하나요?

Codex 안에서 bounded diff와 proof command가 명확하면 Codex /goal입니다. Claude Code 안에서 local steering과 permission mode가 중요하면 Claude Code /goal입니다. 목표가 모호하거나 위험하면 둘 다 쓰지 말고 먼저 계획합니다.

/goal이 shell command나 edit을 승인하나요?

아니요. goal completion과 permission approval은 별도입니다. Claude Code permission modes와 Codex sandbox, repo access, review settings를 따로 확인해야 합니다.

/goal이 비용을 줄이나요?

보장할 수 없습니다. 목표가 명확하면 불필요한 턴을 줄일 수 있지만 긴 작업은 더 많은 사용량을 만들 수 있습니다. 현재 계정과 route를 확인하세요.

좋은 goal에는 무엇이 필요하나요?

측정 가능한 완료 상태, 검증 명령 또는 review artifact, 좁은 scope, 알려진 permission mode, 사용량 점검, abort rule이 필요합니다.

CI나 scheduler가 더 나은 때는 언제인가요?

작업이 반복적이거나 시간 기반이거나 외부 트리거와 로그, 재시도, 알림이 필요할 때입니다. agent는 workflow를 수정하고, workflow가 반복을 소유합니다.