Claude Code · Codex 자동 코딩, 어디까지 맡겨도 되나

AI에게 코딩을 얼마나 맡겨도 되는가. 기능이 있는지가 아니라 지금 실제로 어디까지 믿고 맡겨도 되는지를 정리했습니다.

공식 문서를 먼저 읽고, 사용자 버그 리포트는 GitHub 이슈 번호를 하나씩 조회해 실재 여부와 현재 상태(열림/닫힘)까지 확인했습니다. 확인이 안 된 주장은 뺐습니다.

기준일: 2026년 8월 19일

결론부터

장시간 자동 코딩: Claude Code와 Codex 모두 /goal이 핵심입니다. 양쪽 다 실제 기능이고, 실전에 써도 됩니다.
지금도 조심해야 할 것: Codex의 codex exec가 CI 같은 non-TTY 환경에서 멈추는 문제, 예약 실행이 트리거되지 않는 문제, 장시간 작업이 수렴하지 않고 계속 커지는 문제 — 이 셋은 아직 열려 있는 이슈입니다.
반면 이미 해결된 것: 한때 많이 언급되던 Goal 무한루프·토큰 소진, Claude Code Auto mode 오탐, Routines 정지 문제는 모두 닫힌 이슈입니다. 오래된 글을 근거로 판단하면 틀립니다.
가장 안전한 구조: 전용 브랜치/worktree → Goal → 테스트·린트·빌드로 완료 판정 → PR → 사람 승인.
완전 자동 merge·배포: 아직 권하기 어렵습니다. 자동 수정까지만 하고 CI와 사람 승인으로 닫는 편이 안전합니다.

1. Claude Code의 /goal — 생각보다 정교합니다

공식 문서를 보면 /goal은 단순한 "될 때까지 반복"이 아닙니다. 완료 조건을 걸어두면 매 턴이 끝날 때마다 별도의 작은 모델(기본 Haiku)이 대화 내용을 읽고 조건 충족 여부를 판정합니다.

/goal test/auth 의 모든 테스트가 통과하고 lint 가 깨끗할 것

판정 결과는 세 가지입니다.

아직 아님 — 판정 이유를 다음 턴의 지침으로 삼아 계속 작업합니다.
충족 — 목표를 지우고 달성으로 기록합니다.
불가능 — 조건을 영원히 만족할 수 없다고 판단되면 스스로 중단합니다.

여기서 중요한 설계가 하나 있습니다. 평가자는 도구를 쓰지 않습니다. 파일을 직접 열어보지도, 명령을 실행하지도 않고, 오직 Claude가 대화에 드러낸 내용만 보고 판단합니다. 그래서 완료 조건은 Claude의 출력으로 증명할 수 있는 형태로 써야 합니다. "테스트가 통과한다"가 좋은 조건인 이유는 Claude가 테스트를 돌리면 그 결과가 대화에 남기 때문입니다.

한때의 약점은 대부분 정리됐습니다

"Goal 안에서 컨텍스트 압축이 조용히 실패해 수동 개입이 필요하다"는 버그 리포트(claude-code#58373)가 있었습니다. 지금은 닫힌 이슈이고, 현재 문서에는 이 상황이 아예 규정된 동작으로 들어가 있습니다.

인증 실패, 크레딧 소진, 자동 압축으로도 해결되지 않는 컨텍스트 초과, 모델 사용 불가 — 이 네 가지는 목표를 자동으로 해제하고 원인을 알려줍니다. 반대로 레이트 리밋이나 서버 과부하 같은 일시적 오류에서는 목표를 그대로 유지합니다. 조용히 멈추는 게 아니라 어느 쪽인지 알려주는 구조로 바뀐 셈입니다.

백그라운드 작업 처리도 들어왔습니다. 서브에이전트나 백그라운드 셸이 아직 돌고 있으면 그 턴의 평가를 건너뛰고, 대기가 30분을 넘기면 Claude에게 "그 작업들 상태 좀 확인해라"라고 시킵니다.

실전 판단

완료 조건은 테스트·빌드처럼 판정 가능한 것으로 씁니다.
무한정 도는 게 걱정되면 조건 안에 또는 20턴 후 중단 같은 절을 넣습니다. 문서가 권하는 방법입니다.
목표 턴을 사람 없이 돌리려면 auto mode와 함께 씁니다. 둘은 층이 다릅니다 — auto mode는 턴 안의 도구 승인을, /goal은 턴 자체의 반복을 자동화합니다.

2. Codex의 /goal — 강력하지만 브레이크가 필요합니다

Codex에도 /goal이 있습니다(0.128.0 이상). 설정·일시중지·재개·해제를 지원하고, 여러 턴에 걸쳐 목표를 유지합니다.

한때 이 기능에는 보고가 많았습니다. 한 시간쯤 뒤 Thinking 상태로 멈춤(#24595), 압축 실패 후 Goal blocked(#28177), 무한 루프(#22158), 목표 완료 전에 중단(#22884), 그리고 반복 재시도로 5시간치 토큰을 다 써버린 사례(#23003)까지.

확인해보니 이 이슈들은 전부 닫혀 있습니다. 지금 Codex Goal을 "비용 폭탄" 취급하는 글을 본다면, 이미 수정된 시기의 이야기일 가능성이 큽니다.

다만 아직 열려 있는 이슈가 하나 있습니다. 장시간 작업이 수렴하지 않고 일을 스스로 계속 확장하는 문제(#35892)입니다. 이건 버그라기보다 성격에 가깝고, 프롬프트로 관리해야 합니다.

실전 판단

Goal은 "큰일을 한 번에 던지는 기능"이 아니라 완료 조건이 분명한 작업을 오래 추적하는 기능으로 보는 편이 맞습니다.
완료 조건과 함께 중단 조건을 반드시 넣습니다. "같은 실패가 3회 반복되면 멈추고 보고" 같은 식입니다.
단계마다 커밋을 남겨 되돌릴 지점을 만들어 둡니다.

3. 예약 실행 — 양쪽 다 실재하지만 성격이 다릅니다

Claude Code Routines

리서치 프리뷰입니다. 프롬프트·저장소·커넥터를 묶어 저장해두고 Anthropic 클라우드에서 자동 실행합니다. 노트북을 닫아도 돕니다.

트리거가 세 종류입니다.

스케줄 — 매시간·매일·주간, 또는 특정 시각에 한 번
API — 전용 엔드포인트에 POST 하면 즉시 실행. 모니터링 알림이나 배포 파이프라인에 연결할 수 있습니다
GitHub — PR이나 릴리스 이벤트에 반응

CLI에서는 /schedule로 만듭니다. 한 루틴에 여러 트리거를 동시에 붙일 수 있습니다.

예전에 보고됐던 문제 — MCP 도구 스키마를 불러오다 사람 응답을 기다리며 멈춤(#50312), claude.ai 커넥터를 루틴에서 못 씀(#52586) — 은 둘 다 닫힌 이슈입니다. 현재 문서는 커넥터를 기본으로 포함하고, 필요 없는 것은 빼라고 안내합니다.

대신 공식 문서가 직접 경고하는 함정이 하나 있습니다. 실행 목록의 초록색 상태는 "세션이 인프라 오류 없이 끝났다"는 뜻이지, 작업이 성공했다는 뜻이 아닙니다. 네트워크 차단, 커넥터 누락, 작업 자체의 실패는 전부 상태 표시가 아니라 로그 안에 있습니다.

Codex Scheduled tasks

반복 작업을 로컬 프로젝트, 전용 백그라운드 worktree, 또는 클라우드에서 돌립니다. worktree 모드는 예약 작업의 변경사항을 진행 중인 내 작업과 분리해줍니다.

로컬 파일을 다뤄야 한다면 컴퓨터를 켜두고 앱을 실행 상태로 유지해야 합니다. 클라우드 실행은 업로드한 파일과 연결된 도구는 쓸 수 있지만 내 컴퓨터 폴더에는 접근하지 못합니다.

여기는 아직 열린 이슈가 있습니다. cron 자동화가 트리거되지 않는다는 보고(#28444)가 열려 있는 상태입니다. 핵심 운영 업무에 바로 넣기 전에, 며칠간 정말 정시에 실행됐는지 로그로 확인하는 편이 안전합니다.

4. codex exec — 여기가 지금 가장 조심할 곳입니다

자동화 스크립트나 CI에서 Codex를 부를 때 쓰는 명령입니다. 실제 활용 사례도 많습니다.

그런데 non-TTY 환경에서 무한 대기하는 문제가 세 건 모두 열려 있습니다.

이슈	증상
#20919	stdin이 non-TTY 파이프일 때 무한 대기
#27019	'Reading additional input from stdin...' 에서 멈춤
#31376	SSE 스트림 시작 전에 응답 헤더 단계에서 무한 대기

공통점은 터미널에서는 잘 되는데 headless 실행에서 멈춘다는 것입니다. 로컬에서 테스트하고 CI에 넣으면 그때 처음 터집니다.

실전 판단: CI에 넣기 전에 실제 서버와 동일한 non-TTY 환경에서 스모크 테스트를 돌리고, 반드시 타임아웃을 겁니다. 이건 선택이 아니라 필수입니다.

5. 지금 무엇이 가장 안정적인가

등급	추천	이유
A	Goal + 명확한 완료 조건	양쪽 제품의 핵심 기능이고, 관련 버그가 대부분 정리됐습니다
A	테스트·린트·빌드를 완료 조건으로 사용	AI의 자기 평가보다 외부 검증이 안정적입니다
A	AI 전용 worktree	사람 작업과 격리되고, 되돌리기와 diff 검토가 쉽습니다
A	PR까지만 자동화	자동 코딩의 이득은 유지하면서 merge 사고를 막습니다
B	Routines / Scheduled tasks	유용하지만 트리거가 실제로 도는지 며칠 지켜본 뒤 확대합니다
B	codex exec 기반 CI	강력하지만 headless 멈춤 대비가 필요합니다 (열린 이슈)
C	무제한 Goal + 운영 환경 직접 수정	잘못된 변경의 피해가 큽니다
C	AI 자동 merge·배포	사람 승인 게이트를 남기는 편이 안전합니다

6. 권장 구조

요구사항
   ↓
명확한 완료 조건 (SPEC)
   ↓
AI 전용 worktree
   ↓
/goal 실행
   ↓
구현 → 테스트 → 실패 → 수정
   ↓
lint / build / E2E
   ↓
별도 에이전트 또는 다른 모델로 리뷰
   ↓
PR 생성
   ↓
CI
   ↓
사람 승인 후 merge

AI가 "완료했습니다"라고 말하는 것을 완료 조건으로 두지 않습니다. 테스트 통과, 빌드 성공, HTTP 응답, 스크린샷 비교처럼 밖에서 판정할 수 있는 증거를 조건으로 넣습니다.
핵심 원칙

Claude Code의 /goal 평가자가 도구를 쓰지 않고 대화 내용만 본다는 설계는, 이 원칙을 제품이 강제하는 형태이기도 합니다. 증거가 대화에 남지 않으면 평가 자체가 불가능하니까요.

7. 목표 작성 템플릿

목표
관리자 회원관리 기능을 완성한다.

맥락
- 기존 프로젝트 구조와 API 규칙을 유지한다.
- 관련 경로: src/admin, src/users

제약
- DB 스키마 변경 금지
- 불필요한 의존성 추가 금지
- main 직접 push 금지
- 기존 API 호환 유지

완료 조건
- 회원 목록 / 검색 / 상세 / 차단이 실제로 동작한다.
- 새 기능에 대한 테스트가 있다.
- npm test 성공
- npm run lint 성공
- npm run build 성공
- 실패 상태에서는 완료로 판단하지 않는다.

중단 조건
- 같은 실패가 3회 반복되면 중단하고 원인을 보고한다.
- 아키텍처 변경이 필요하면 구현하지 말고 중단한다.
- 운영 크리덴셜이 필요하면 중단한다.

산출물
- 변경 파일
- 테스트 결과
- 남은 위험
- 다음 사람이 확인할 항목

8. 어느 쪽을 쓸까

Claude Code — 사람이 옆에 있으면서 큰 기능을 만들어가는 개발에 잘 맞습니다. 계획 → auto mode → /goal → PR 흐름이 자연스럽습니다.
Codex — worktree 병렬 작업, 클라우드 위임, 스크립트 자동화를 함께 구성하려면 매력적입니다. 다만 codex exec에는 타임아웃과 로그 감시를 반드시 붙입니다.
둘 다 — 구현자와 검수자를 분리할 수 있습니다. 한쪽이 구현하고 다른 쪽이 리뷰하는 구성이 실제로 유용합니다.

확인한 자료

공식 문서는 직접 읽었고, 사용자 보고는 GitHub 이슈 번호를 조회해 실재 여부와 현재 상태를 확인했습니다. 아래 이슈 상태는 2026년 8월 19일 기준입니다.

공식 문서 — Claude Code: /goal, Routines, Auto mode, 스케줄 작업
공식 문서 — Codex: Using Goals in Codex, Scheduled tasks
아직 열린 이슈 — codex#20919, #27019, #31376 (codex exec non-TTY 멈춤), codex#28444 (cron 미실행), codex#35892 (장시간 작업 발산)
닫힌 이슈 — claude-code#58373, #60004, #50312, #52586, #30463, #18980 / codex#24595, #28177, #22158, #22884, #23003, #23159

덧붙이면, 인용문의 URL도 확인 과정에서 정리했습니다. Claude Code 문서는 docs.anthropic.com에서 code.claude.com으로, Codex 자동화 문서는 developers.openai.com에서 learn.chatgpt.com으로 옮겨졌습니다. 옛 주소도 리다이렉트로 열리지만, 인용할 때는 현재 주소를 쓰는 편이 낫습니다.