클로드 코드 vs 코덱스 Goal, 실제 프로젝트에 돌려보니 달랐습니다

클로드 코드 vs 코덱스 Goal 모드 완벽 비교: 실사용 후기와 실무 검증까지

요즘 AI 코딩 도구를 쓰다 보면 /goal이라는 명령어를 자주 보게 됩니다. 예전처럼 “이 코드 고쳐줘”, “이 함수 만들어줘”라고 한 번씩 지시하는 방식이 아니라, 목표와 완료 조건을 주면 AI가 여러 단계를 스스로 이어가며 작업하는 방식입니다. 코덱스 goal과 클로드 코드 goal이 주목받는 이유도 여기에 있습니다.

간단히 말해 /goal은 AI 코딩 에이전트에게 “이 상태가 될 때까지 계속 작업해줘”라고 맡기는 기능에 가깝습니다. 테스트가 통과할 때까지 버그를 고치거나, 특정 조건을 만족할 때까지 리팩토링을 이어가거나, 프로젝트 구조를 분석해 문서로 정리하게 만들 수 있습니다. 그래서 개발자들 사이에서는 “이제 AI에게 어느 정도까지 맡길 수 있나?”라는 질문이 자연스럽게 나오고 있습니다.

하지만 /goal을 잘 쓰려면 단순히 명령어를 아는 것만으로는 부족합니다. 목표를 어떻게 써야 하는지, 완료 조건을 어디까지 구체화해야 하는지, 어떤 작업은 맡겨도 되고 어떤 작업은 사람이 반드시 검증해야 하는지까지 함께 알아야 합니다. 특히 실제 프로젝트에서는 코드만 보고 판단하기 어려운 운영 브랜치, 배포 상태, 인수인계 문서, UAT 결과 같은 맥락도 중요합니다.

그래서 저희는 단순히 코덱스 goal과 클로드 goal의 기능을 비교하는 데서 멈추지 않았습니다. 실제 외주 개발 프로젝트를 가지고 두 도구를 동시에 돌려봤고, 같은 조건으로 PM 인수인계 문서를 만들어달라고 요청했습니다. 여기서 한 단계 더 나아가, 실제 담당자가 작성한 인수인계 문서와 AI가 만든 결과물을 다시 비교했습니다.

이 글은 코덱스 goal과 클로드 goal이 무엇인지부터, 실제 프로젝트에서 어디까지 믿고 써도 되는지까지 확인한 검증형 후기입니다. 두 AI가 무엇을 잘 맞췄는지, 어디서 그럴듯하게 틀렸는지, 실무에서 쓰려면 어떤 검증 절차가 필요한지까지 정리했습니다. 또한 /goal을 잘 쓰기 위해 목표·완료 조건·제약 조건·출력 형식·검증 기준을 어떻게 잡아야 하는지도 실제 프롬프트를 바탕으로 다룹니다.

이 글을 읽으면 아래와 같은 차별화 인사이트를 얻어갈 수 있습니다.

• 코덱스 goal과 클로드 goal의 개념과 사용법을 실무 관점에서 정리했습니다.
• 실제 실무 프로젝트 코드베이스로 두 도구를 동시에 테스트했습니다.
• 두 AI가 만든 PM 인수인계 문서를 실제 담당자 인수인계 문서와 비교했습니다.

그래서 이 글은 “어떤 도구가 더 좋은가”를 단순 비교하는 글이 아닙니다. 코덱스 goal과 클로드 goal을 잘 쓰려면 어떻게 프롬프트를 짜야 하는지, 실무 프로젝트 분석에 어디까지 맡길 수 있는지, 그리고 어디서부터 사람이 검증해야 하는지 현실적인 기준을 제시하는 글입니다.

코덱스 goal 공식 문서 바로가기

1. AI 코딩 에이전트의 패러다임 시프트, /goal 명령어란?

AI 코딩 도구를 쓰는 방식은 이제 단순한 자동완성이나 코드 조각 생성에 머물지 않습니다. 과거에는 개발자가 “이 함수 고쳐줘”, “이 테스트 만들어줘”처럼 하나의 요청을 던지고, 결과를 확인한 뒤 다시 지시하는 흐름이 일반적이었습니다. 반면 최근의 AI 코딩 에이전트는 하나의 작업 목표를 받은 뒤, 코드를 읽고 수정하고 테스트하며 여러 단계의 작업을 스스로 이어갑니다.

그 중심에 있는 기능이 바로 코덱스 goal과 클로드 코드 goal입니다. OpenAI Codex와 Anthropic Claude Code는 모두 /goal 명령어를 통해 “이 조건이 충족될 때까지 계속 작업하라”는 목표를 설정할 수 있습니다. 개발자는 해야 할 일과 완료 기준을 제시하고, AI 에이전트는 그 기준을 향해 반복적으로 코드를 수정합니다.

다만 한 가지는 분명히 짚고 시작하는 편이 좋습니다. /goal은 “알아서 잘 해주는 버튼”이 아니라, 사람이 정의한 목표를 오래 밀고 가는 실행 루프에 가깝습니다. 목표가 모호하면 오래 헤매고, 완료 조건이 분명하면 꽤 긴 작업도 안정적으로 이어갈 수 있습니다.

좋은 goal은 모호한 요청이 아니라 작은 작업 계약서에 가깝습니다. “정리해줘”, “개선해줘”, “최적화해줘”처럼 해석의 여지가 큰 표현만으로는 충분하지 않습니다. AI 에이전트가 오래 실행될수록 작은 오해도 큰 변경으로 이어질 수 있기 때문입니다.

/goal billing 모듈의 날짜 파싱 버그를 수정하고, pnpm test packages/billing 명령이 exit 0으로 통과할 때까지 계속 작업해줘. parser, fixture, regression test 파일 외에는 수정하지 마.

코덱스 goal이든 클로드 goal이든 핵심은 비슷합니다. 목표, 완료 조건, 검증 명령어, 수정 범위, 중단 조건을 함께 줘야 합니다. 이 다섯 가지가 빠지면 /goal은 생산성을 높이는 기능이 아니라, 잘못된 방향으로 오래 달리는 자동화가 될 수 있습니다.

• 목표: 무엇을 달성해야 하는가?
• 완료 조건: 어떤 상태가 되면 끝인가?
• 검증 명령어: 무엇을 실행해서 완료를 증명할 것인가?
• 수정 범위: 어디까지 바꿔도 되는가?
• 중단 조건: 언제 멈추고 사람에게 보고해야 하는가?

이제 AI 코딩 에이전트의 핵심은 “무엇을 물어볼 것인가”보다 “어떤 목표와 완료 조건을 줄 것인가”에 가까워졌습니다. 개발자의 역할이 사라지는 것이 아니라, 반복 실행과 검증 과정을 더 잘 위임할 수 있게 바뀌는 것입니다.

클로드 코드 goal 공식 문서 바로가기

2. 코덱스 goal과 클로드 goal의 기본 차이

겉으로 보면 두 도구는 비슷합니다. 둘 다 /goal을 입력하면 사용자의 추가 지시 없이 여러 턴에 걸쳐 작업을 이어갑니다. 하지만 실제 사용감과 강점은 꽤 다릅니다.

Codex goal은 비교적 긴 작업을 맡겨두는 흐름에 잘 맞습니다. 명확한 성공 조건과 검증 루프가 있는 마이그레이션, 리팩토링, 테스트 기반 수정, SDK 교체 같은 작업에서 강점이 드러납니다. 일을 맡기고 결과를 기다리는 쪽에 가깝다고 볼 수 있습니다.

Claude Code goal은 터미널 안에서 함께 일하는 페어 프로그래머에 가깝습니다. /goal 외에도 /plan, /permissions, /context, /compact, /diff, /review 같은 명령어와 함께 쓰이며, 작업 중간에 방향을 조정하거나 권한을 바꾸고 컨텍스트를 관리하기 좋습니다. 자동화 도구라기보다, 개발자가 자신의 워크플로우에 맞춰 운용하는 에이전트 플랫폼처럼 느껴진다는 평가가 많습니다.

정리하면 Codex는 검증 가능한 장기 실행에, Claude Code는 조정 가능한 탐색과 문서화에 더 강합니다. 어느 쪽이 무조건 우월하다고 보기보다, 작업의 성격에 따라 역할을 나누는 편이 현실적입니다.

3. 우리가 직접 돌려본 코덱스 goal vs 클로드 goal 후기: 실제 인수인계 문서와 비교해보니

실제로 어떤 프롬프트를 넣었나

Claude Code(좌)와 Codex(우)에 같은 /goal 명령어를 실행한 화면

이번 테스트에서는 단순히 코드 저장소만 넣고 “분석해줘”라고 요청하지 않았습니다. 기획 문서, 개발 문서, 설정 파일, 코드베이스 등 프로젝트 이해에 필요한 GitHub 내용을 최대한 함께 넣고, 두 도구에 같은 /goal 프롬프트를 실행했습니다. 목적은 개발자 관점의 코드 리뷰가 아니라, PM이 실제 인수인계 때 받아야 할 프로젝트 분석 문서를 만드는 것이었습니다.

프롬프트에서 가장 중요하게 둔 기준은 세 가지였습니다. 첫째, 코드와 파일에서 확인 가능한 사실만 확정할 것. 둘째, 확인되지 않은 내용은 “확인 필요”로 분리할 것. 셋째, 그럴듯한 백로그나 일정을 임의로 만들지 말 것. 즉 AI가 멋대로 추정하지 않고, PM 의사결정에 필요한 정보만 근거 중심으로 정리하도록 제한했습니다.

실제로 사용한 프롬프트 구조는 아래와 같습니다.

/goal (프로젝트 문서들)
이 프로젝트를 PM 관점에서 분석해줘.

목표:
- 현재 코드베이스와 설정 파일만 기준으로 프로젝트의 현재 상태를 파악해줘.
- 개발 세부 구현보다 PM이 알아야 할 프로젝트 구조, 주요 기능, 진행 상태, 리스크, 확인 필요 사항을 중심으로 정리해줘.
- 코드와 파일에서 확인 가능한 사실만 기반으로 작성하고, 확실하지 않은 내용은 “확인 필요”로 분리해줘.
- 담당자나 개발팀에게 추가로 물어봐야 할 질문 목록을 만들어줘.

완료 조건:
- 프로젝트가 어떤 서비스/제품인지 한눈에 이해할 수 있게 요약할 것
- 주요 기능과 화면/도메인 흐름을 PM 관점에서 정리할 것
- 현재 구현되어 있는 것으로 보이는 기능과 미완성/확인 필요한 기능을 분리할 것
- 실행, 테스트, 빌드, 배포와 관련된 단서를 PM이 이해할 수 있는 수준으로 정리할 것
- 환경변수, 외부 API, DB, 인증, 결제, 알림, 파일 업로드 등 운영 리스크가 될 수 있는 요소를 정리할 것
- 일정/범위/운영/품질 관점에서 리스크를 정리할 것
- 각 판단에는 가능한 한 근거 파일 경로나 코드 위치를 함께 남길 것

제약 조건:
- 어떤 파일도 수정하지 말 것
- 개발 구현을 과하게 상세히 설명하지 말고 PM 의사결정에 필요한 수준으로 요약할 것
- 확인되지 않은 비즈니스 목적, 고객 요구사항, 우선순위를 추측하지 말 것
- 코드에서 확인되지 않는 내용은 반드시 “확인 필요”로 표시할 것
- 그럴듯한 백로그나 일정 계획을 임의로 만들지 말 것

출력 형식:
- 프로젝트 한 줄 요약
- PM 관점 프로젝트 개요
- 주요 기능/화면/도메인 흐름
- 구현된 것으로 보이는 범위
- 미완성 또는 확인이 필요한 범위
- 실행 / 테스트 / 빌드 / 배포 관련 단서
- 외부 의존성 및 운영 리스크
- 품질 리스크
- 일정·범위 관리 관점 리스크
- 담당자에게 반드시 물어봐야 할 질문
- 담당자에게 가능하면 확인하면 좋은 질문
- 근거가 약한 추정 목록

마지막 요약:
- PM이 지금 바로 이해해도 되는 내용
- 담당자 확인 전까지 확정하면 안 되는 내용
- 인수인계 문서에서 반드시 확인해야 할 내용

이 프롬프트를 넣은 이유는 코덱스 goal과 클로드 goal의 “코딩 능력”이 아니라, PM 인수인계 문서 생성 능력을 비교하기 위해서였습니다. 그래서 코드 수정이나 리팩토링은 아예 금지했고, 대신 프로젝트 구조·기능 범위·운영 리스크·확인 질문을 얼마나 잘 뽑는지에 집중했습니다.

이 방식으로 돌려보니 두 도구의 차이가 더 선명하게 보였습니다. 같은 입력과 같은 목표를 줬는데도, 코덱스는 코드 근거와 파일 위치를 더 촘촘히 남겼고, 클로드는 PM이 읽기 좋은 보고서 구조와 리스크 정리에 더 강했습니다. 즉 이번 테스트는 단순한 사용 후기가 아니라, 같은 조건에서 두 AI가 PM 문서를 어떻게 다르게 만드는지 비교한 실험에 가까웠습니다.

Claude Code(좌)가 정리한 문서와 Codex(우)가 정리한 문서

같은 요청을 줬을 때, 두 AI는 큰 방향은 비슷하게 봤습니다

먼저 코덱스 goal과 클로드 goal은 큰 판단에서는 꽤 비슷한 결론을 냈습니다. 백엔드는 비교적 성숙한 ERP성 API로 봤고, SQL Server와 저장프로시저 의존성이 큰 운영 리스크라는 점도 함께 짚었습니다. 배포 파이프라인, CORS, 로그인, 외부 연동 범위처럼 PM이 인수인계 단계에서 확인해야 할 항목도 비슷하게 나왔습니다.

특히 두 도구 모두 “어느 프론트엔드가 진짜 운영 대상인가?”라는 질문을 중요하게 봤습니다. 프로젝트 안에 프론트엔드가 2개 있었고, 각각의 성숙도와 역할이 다르게 보였기 때문입니다. 실제 인수인계에서도 이 질문은 매우 중요한 포인트였습니다.

작업 시간도 크게 차이 나지는 않았습니다. 워킹 시간을 포함해 클로드 코드는 약 4분, 코덱스는 약 3분 42초 정도 걸렸습니다. 체감상 속도 차이는 거의 없었고, 결과물의 차이는 시간보다 정리 방식과 판단 표현 방식에서 더 뚜렷하게 드러났습니다.

다만 두 도구가 비슷한 결론에 도달했다고 해서, 그 결론이 곧 정답이라는 뜻은 아니었습니다. 두 AI 모두 주어진 코드 스냅샷을 기준으로 판단했고, 그 안에서 확인 가능한 사실을 바탕으로 보고서를 만들었습니다. 이 전제 때문에 뒤에서 중요한 차이가 드러났습니다.

정리하면, 코덱스 goal과 클로드 goal은 코드에서 드러나는 구조와 리스크를 꽤 잘 읽었습니다. 하지만 그것이 곧 실제 운영 상태를 정확히 맞췄다는 의미는 아니었습니다.

Codex /goal 의 plan 실행 화면

코덱스 goal은 계획을 세우고 코드 근거를 촘촘하게 잡았습니다

코덱스 goal을 돌려보면서 눈에 띄었던 점은, 먼저 plan을 세우고 그 단계에 맞춰 작업을 진행한다는 점이었습니다. 실제 실행 화면에서도 프로젝트 루트와 핵심 설정 파일 파악, 백엔드와 프론트엔드 구조 수집, 실행·배포·운영 의존성 정리, PM 관점 최종 분석 작성 같은 단계가 plan 형태로 보였습니다. 사용자가 보기에도 지금 AI가 어떤 순서로 분석을 진행하는지 확인할 수 있었습니다.

결과물은 PM 인수인계 문서를 요청했음에도, 엔지니어가 코드 근거를 따라가며 작성한 분석 보고서에 가까웠습니다. 파일 경로와 라인 번호를 비교적 촘촘하게 남겼고, 어떤 판단이 어떤 코드에서 나왔는지 확인하기 좋았습니다. PM이 바로 읽기에는 조금 건조했지만, 개발자와 함께 검증하기에는 유리한 형태였습니다.

예를 들어 거래내역 메뉴의 URL 불일치, BI 어댑터에 남아 있는 NotImplementedError, 테스트 파일 수와 라우트 수, API integration 파일 수처럼 코드베이스의 구체적인 단서를 잘 잡았습니다. 이런 정보는 단순히 “운영 가능해 보인다”는 판단보다 훨씬 실무적입니다. 실제 인수 과정에서는 이런 근거가 있어야 담당자에게 확인하거나 개발자 리뷰로 넘길 수 있습니다.

코덱스 goal의 장점은 “이 말의 근거가 코드 어디에 있는가?”를 확인하기 좋다는 점이었습니다. 반대로 약점도 분명했습니다. 같은 내용이어도 표보다는 줄글 중심으로 정리하는 경향이 있어, PM이나 비개발 이해관계자에게 바로 공유하려면 한 번 더 가공하는 편이 좋았습니다.

코덱스 goal 결과물에서 특히 좋았던 부분은 다음과 같습니다.

• 분석 전에 plan을 세우고 진행 과정을 보여주는 방식
• 파일 경로와 라인 번호 중심의 근거 제시
• URL 불일치, 미구현 예외 처리 같은 코드 레벨 단서 포착
• 테스트 파일 수, 라우트 수, API integration 파일 수 등 정량 정보 정리
• “확정”과 “확인 필요”를 비교적 조심스럽게 나누는 태도

즉 코덱스 goal은 PM 문서의 초안을 만들 때도 문서 자체의 완성도보다 검증 가능성을 높이는 데 더 강했습니다. 인수인계 문서를 바로 예쁘게 만들기보다는, 실제 코드 근거를 확보하는 용도로 쓰기 좋았습니다.

같은 내용을 표로 정리한 Claude Code(좌)와 줄글로 나타낸 Codex(우)

클로드 goal은 같은 내용을 표와 보고서 형태로 더 읽기 쉽게 정리했습니다

반면 클로드 goal 결과물은 같은 요청을 더 보고서답게 풀어냈습니다. 프로젝트별 역할과 성숙도를 표로 정리했고, 리스크와 확인 질문을 PM이 읽기 쉬운 구조로 묶었습니다. 같은 내용이어도 코덱스가 줄글 중심으로 설명했다면, 클로드는 표와 항목 구분을 적극적으로 사용해 스캔하기 쉬운 문서로 만들어줬습니다.

예를 들어 실행·테스트·빌드·배포 단서를 비교표로 정리하거나, 외부 의존성과 운영 리스크를 영역·확인된 사실·리스크로 나눠 보여주는 식이었습니다. DB, 인증, 외부 API, 캐시, 결제·알림·파일 업로드, CORS/CDN, 배포 인프라, 라이선스 같은 요소를 한눈에 비교할 수 있어 PM 입장에서는 훨씬 빠르게 읽혔습니다.

또한 .git 부재로 커밋 이력과 작업 속도를 추정할 수 없다는 점, 저장프로시저 원본 확보가 필요하다는 점, 라이선스나 운영 장애 기록 같은 인수 리스크를 더 적극적으로 드러냈습니다. 이런 내용은 실제 인수인계 미팅에서 바로 질문으로 바꾸기 좋습니다. PM이 보기에는 코덱스보다 클로드 결과물이 더 빠르게 읽히고, 문서화하기도 쉬웠습니다.

클로드 goal의 장점은 코드 분석 결과를 의사결정 가능한 문서 구조로 바꿔준다는 점이었습니다. 다만 이 장점은 동시에 주의점이 되기도 했습니다. 문서가 잘 정리되어 있을수록 독자는 더 쉽게 믿게 되는데, 틀린 판단도 그만큼 단정적으로 보일 수 있기 때문입니다.

클로드 goal 결과물에서 특히 좋았던 부분은 다음과 같습니다.

• 프로젝트별 역할과 성숙도를 한눈에 볼 수 있는 표 구성
• 실행·테스트·빌드·배포 단서를 비교표로 정리하는 방식
• 운영 리스크, 라이선스, 저장프로시저, 배포 파이프라인 같은 PM 관점 정리
• 담당자에게 반드시 물어봐야 할 질문 목록 구성
• 코드 분석 결과를 일정·범위 리스크로 해석하는 방식

하지만 클로드 goal은 코덱스보다 더 단정적인 표현을 쓰는 경향이 있었습니다. 이번 테스트에서는 이 점이 꽤 중요했습니다. 실제 인수인계 문서와 비교했을 때, 클로드가 정리한 구조는 좋았지만 핵심 오판도 더 강하게 못 박혀 보였기 때문입니다.

그런데 실제 인수인계 문서와 비교하니, 가장 중요한 판단이 달랐습니다

두 AI 결과물만 놓고 보면 둘 다 꽤 설득력 있어 보였습니다. 하지만 실제 담당자가 작성한 인수인계 문서와 비교하자 가장 중요한 차이가 드러났습니다. 두 AI 모두 Next.js 프론트엔드를 mock 인증과 데모 데이터가 남아 있는 초기 상태로 봤고, 주문 전용 React 프론트엔드를 더 성숙한 운영 대상처럼 판단했습니다.

그런데 실제 인수인계 기준에서는 이 판단이 거의 반대였습니다. Next.js 프론트엔드가 실제 운영 중인 ERP 본체였고, 주문 전용 React 프론트엔드는 이번 인수인계 범위에서 제외된 별도 트랙이었습니다. 즉 두 AI가 “어느 프론트엔드가 진짜냐”는 질문 자체는 잘 던졌지만, 그 질문의 답은 실제 운영 기준과 다르게 잡은 것입니다.

이 차이는 단순한 AI 오판이라기보다, 입력 데이터의 문제에 가까웠습니다. AI에게 주어진 코드 스냅샷은 실제 운영 브랜치가 아니라 낡은 main 브랜치 기준이었습니다. AI가 받은 파일 안에서는 Next.js 프론트엔드가 데모처럼 보이는 것이 맞았지만, 실제 운영본은 같은 저장소의 다른 브랜치와 배포본에 있었습니다.

이 지점이 실무적으로 가장 중요합니다. AI가 코드를 못 읽은 것이 아니라, 받은 코드가 실제 운영 상태를 대표하지 않았던 겁니다. 그래서 AI 결과물을 그대로 믿었다면 프로젝트 우선순위를 정반대로 잡을 위험이 있었습니다.

AI가 잘한 부분과 못한 부분은 분명히 나뉘었습니다

이번 비교를 통해 코덱스 goal과 클로드 goal이 잘하는 일과 못하는 일이 꽤 선명하게 나뉘었습니다. 두 도구 모두 코드에서 직접 드러나는 구조, 기술 스택, 의존성, 리스크 단서는 잘 잡았습니다. 특히 백엔드 성격, SQL Server와 저장프로시저 리스크, staging 배포 흐름, CORS와 로그인 리스크는 실제 인수인계 문서와도 꽤 잘 맞았습니다.

반대로 코드만으로 알 수 없는 운영 맥락에는 약했습니다. 어떤 브랜치가 현재 운영본인지, 실제 배포 URL이 무엇인지, UAT evidence가 어디까지 쌓였는지, 담당자가 어떤 범위를 인수 대상으로 보는지는 코드 스냅샷만으로 복원하기 어렵습니다. 이 정보는 실제 인수인계 문서나 배포 기록, 담당자 확인이 있어야 알 수 있습니다.

결론적으로 AI는 “코드에서 보이는 사실”에는 강했지만, “현재 운영의 진실”에는 별도 근거가 필요했습니다. 이 차이를 이해하지 못하면 /goal 결과물을 과신하게 됩니다. 반대로 이 한계를 알고 쓰면, AI는 인수인계 초안과 질문 목록을 만드는 데 꽤 강력한 도구가 됩니다.

이번 테스트에서 AI가 잘한 부분은 다음과 같습니다.

• 백엔드 구조와 주요 도메인 파악
• SQL Server, 저장프로시저, Redis, CORS 같은 운영 리스크 도출
• 배포 파이프라인과 프로덕션 여부 확인 필요성 제기
• 담당자에게 물어봐야 할 질문 목록 정리
• 코드에서 보이는 미완성·불명확 영역 분리

반면 AI가 놓치거나 잘못 판단한 부분은 다음과 같습니다.

• 실제 운영 브랜치와 낡은 스냅샷의 차이
• 어떤 프론트엔드가 실제 인수 범위인지에 대한 판단
• UAT evidence, 배포 run, 커밋 단위 추적 같은 검증 체계
• 담당자 문서에서 이미 닫힌 이슈와 아직 남은 이슈의 구분
• 코드상 mock처럼 보이는 부분이 실제 운영본에서는 이미 해결됐을 가능성

이 차이를 보면 /goal을 실무 프로젝트 분석에 어떻게 써야 하는지도 보입니다. AI에게 최종 판단을 맡기기보다, AI가 뽑아낸 리스크와 질문을 바탕으로 실제 문서와 운영 정보를 대조하는 흐름이 필요합니다.

그래서 실무에서 쓸 때는 이렇게 쓰는 게 좋습니다

이번 테스트에서 얻은 가장 현실적인 결론은, 코덱스 goal과 클로드 goal을 “최종 보고서 작성자”로 쓰면 위험하다는 점입니다. 대신 “빠르게 초안을 만들고, 사람이 검증할 질문을 뽑아주는 도구”로 쓰면 훨씬 유용합니다. 특히 외주 개발 인수인계처럼 정보가 흩어져 있고, 코드와 실제 운영 상태가 다를 수 있는 상황에서는 이 차이가 중요합니다.

실무에서는 먼저 코덱스 goal과 클로드 goal에 같은 프로젝트를 넣고, PM 인수인계 초안을 각각 만들어보는 방식이 좋습니다. 그다음 두 결과물에서 공통으로 나온 리스크를 우선 확인하고, 서로 다르게 본 항목은 담당자에게 질문으로 넘깁니다. 마지막으로 실제 인수인계 문서, 운영 URL, 배포 브랜치, HEAD 커밋, UAT evidence와 대조해 최종 판단을 내려야 합니다.

즉 /goal을 잘 쓰는 방법은 AI에게 더 많은 판단을 맡기는 것이 아니라, AI가 만든 초안을 더 잘 검증하는 구조를 만드는 것입니다. 코덱스 goal은 코드 근거를 확보하는 데 쓰고, 클로드 goal은 PM이 읽기 좋은 구조를 잡는 데 쓰면 좋습니다. 그리고 실제 담당자 문서로 두 결과물을 검증하면, 인수인계 리스크를 훨씬 빠르게 정리할 수 있습니다.

실제로 적용한다면 다음 순서가 가장 안전합니다.

• 코덱스 goal과 클로드 goal에 같은 PM 인수인계 요청을 넣습니다.
• 코덱스 결과물에서 코드 근거, 파일 경로, 구체 결함을 뽑습니다.
• 클로드 결과물에서 성숙도 표, 리스크, 담당자 질문 목록을 뽑습니다.
• 실제 담당자 인수인계 문서와 대조해 맞은 부분과 틀린 부분을 분리합니다.
• 운영 URL, 브랜치, HEAD 커밋, 배포 기록, UAT evidence로 최종 확인합니다.

이번 실사용 후기의 결론은 “코덱스냐 클로드냐”가 아니라, 둘을 어떻게 검증 흐름 안에 넣을 것인가였습니다. 코덱스 goal은 정밀한 코드 근거를 찾는 데 강했고, 클로드 goal은 PM용 보고서 구조를 만드는 데 강했습니다. 하지만 실제 인수인계에서는 두 AI 모두 최신 운영 맥락이 없으면 핵심 판단을 틀릴 수 있었습니다.

따라서 프로젝트 인수인계에 /goal을 쓰려면 코드만 넣고 끝내면 안 됩니다. 최신 브랜치, 운영 배포본, 실제 담당자 문서, UAT evidence를 함께 제공해야 합니다. 그렇게 해야 코덱스 goal과 클로드 goal이 단순한 자동 코딩 기능을 넘어, 실무 프로젝트 분석과 외주 개발 인수인계에 쓸 수 있는 도구가 됩니다.

4. 코덱스 goal·클로드 goal 실사용 후기: 개발자들은 어떻게 평가했을까?

Codex /goal과 Claude Code /goal, 공식 소개 영상이나 기능 설명만으로는 이 두 도구가 실제 개발 흐름에서 무엇을 바꾸는지 충분히 전달되기 어렵습니다. 어떤 조건에서 잘 작동하고, 어디서 무너지는지는 직접 써본 사람들의 기록에서 훨씬 선명하게 드러납니다. 그래서 Reddit, 개발 블로그, 기술 커뮤니티에 남겨진 실사용 후기들을 바탕으로, 개발자들이 실제로 무엇을 높게 평가했고 어디서 한계를 느꼈는지 정리해 보았습니다.

전체적인 반응은 생각보다 일관됩니다. Codex /goal은 “이걸 완성해두고 자도 되겠다”는 믿음을 처음 줬다는 평가가 많고, Claude Code /goal은 “내가 이미 이해하고 있는 작업을 빠르게 밀어붙이는 데 최적”이라는 반응이 주를 이룹니다. 그러나 양쪽 모두 공통으로 강조하는 것은 하나입니다. /goal의 성패는 모델 선택이 아니라 ‘완료’를 얼마나 구체적으로 정의하느냐에 달려 있다는 것입니다.

후기 1. 잠든 사이 드라이버 프로젝트를 혼자 진행했다는, 14시간 자율 실행 후기

14시간 overnight 자율 실행을 직접 경험한 a16z 개발자 후기 바로가기

a16z 제너럴 파트너 Andrew Chen은 eGPU·Mac 디바이스 드라이버 프로젝트에 Codex /goal을 걸어두고 잠들었습니다. 14시간 후 확인했을 때 Codex는 여전히 진행 중이었고, 그는 그동안 단 한 번도 개입하지 않았습니다. 그는 이 경험에 대해 “토큰 사용량을 1만 배 늘릴 것은 분명하다”고 인정하면서도, 그만한 가치가 있다고 평가했습니다.

이 사례를 분석한 MindStudio 블로그는 /goal이 단순 에이전트와 다른 이유를 명확히 짚습니다. 기존 코딩 세션은 “프롬프트 → 응답 → 리뷰 → 다시 프롬프트”의 반응형 구조인 반면, /goal은 계획·실행·관찰·재계획을 자율적으로 반복하는 Ralph Loop를 구현한다는 것입니다.

/goal 사용 전에 별도 AI에게 프롬프트를 대신 생성하게 하라는 조언도 인상적입니다. Alex Finn의 테스트에 따르면, “내가 직접 손으로 쓴 /goal 프롬프트는 어떤 것도 충분하지 않았다. 결과물이 평범한 프롬프트와 별 차이가 없었다”는 것입니다. 해결책은 다른 AI에게 프로젝트 컨텍스트를 주고, 적합한 /goal 프롬프트 세 가지를 만들어달라고 요청한 뒤 그중 하나를 쓰는 방식이었습니다.

한 문장 요약: Codex /goal은 잠든 사이 에이전트를 대신 일하게 하는 첫 경험을 제공했지만, 프롬프트 품질이 결과를 결정한다는 것이 핵심이었습니다.

리스크: 목표가 모호하면 에이전트는 멈추지 않고 잘못된 방향으로 14시간을 달립니다. ‘완료’의 기준이 없는 /goal은 자신감 있는 표류로 끝날 수 있습니다.

후기 2. 18개 기능 목표 중 14개를 혼자 완성했다는, 18시간 방치 실험 후기

18시간 자리를 비우고 돌아왔을 때의 결과를 정리한 실험 후기 바로가기

한 개발자는 Codex /goal에 피처 목록 18개를 넘기고 18시간 동안 자리를 완전히 비웠습니다. 돌아왔을 때 18개 중 14개가 완성되어 있었습니다. 그는 이 경험의 핵심이 /goal이 “목표를 데이터베이스의 row처럼 다룬다”는 점에 있다고 설명했습니다. 모델이 status = done을 향해 스스로 드라이브한다는 구조가 기존 에이전트와 근본적으로 다르다는 것입니다.

실제 OpenAI의 Dominik Kundel도 LinkedIn을 통해 “100시간 이상 단일 goal로 복잡한 마이그레이션을 처리한 사례를 여러 차례 목격했다”고 밝히며, 코드 마이그레이션·퍼포먼스 개선·아키텍처 리디자인에 특히 강력하다고 공개했습니다.

한 문장 요약: 명확한 완료 기준이 있는 피처 목록이라면, Codex /goal은 방치한 18시간 동안 스스로 상당 부분을 완성할 수 있습니다.

리스크: 완성된 4개는 왜 실패했는지가 중요합니다. 테스트 게이트가 없다면 에이전트는 완료됐다고 성급히 선언할 수 있으며, 검증 없이 diff를 그대로 믿는 것은 위험합니다.

후기 3. 아침마다 커피 마시는 사이 PR 2~3개가 완성된다는, 실무 적용 워크플로우 후기

WorkOS 소속 개발자가 Codex를 하루 루틴에 녹인 방식을 정리한 블로그 바로가기

WorkOS Applied AI 팀의 개발자 Zack Proser는 Codex 1년 사용 후기에서 자신의 아침 루틴을 이렇게 묘사했습니다. “코딩 세션을 시작하기 전에 Codex에 4~5개의 유지보수 태스크를 배치한다. 커피를 마시고 메시지를 확인하고 돌아오면 보통 2~3개의 완성된 PR이 기다리고 있다.” 태스크 성공률은 2025년 초 40~60%에서 2026년 3월 기준 85~90%로 올랐습니다.

그가 Codex에 넘기는 작업은 “이미 패턴이 잡혀 있고, 사람이 직접 하기엔 지루하며, 완료 기준이 명확한 것들”입니다. TypeScript 에러 수정, 웹훅 엔드포인트 업데이트, React 에러 바운더리 추가 같은 유형이 여기에 해당합니다. 복잡한 아키텍처 문제는 Cursor나 Claude Code로 전환합니다. 그는 이 패턴을 ‘Two-tier approach’로 정의했습니다.

한 문장 요약: Codex /goal은 매일 반복되는 유지보수 태스크를 백그라운드에서 처리하는 루틴으로 정착시킬 때 가장 실질적인 효과를 냅니다.

리스크: 이 워크플로우는 이미 패턴이 확립된 성숙한 코드베이스에서 작동합니다. 구조가 불분명하거나 레거시가 복잡하게 얽힌 프로젝트에서는 성공률이 크게 떨어질 수 있습니다.

후기 4. Claude로 계획, Codex로 코딩이 최선이라는, 두 도구 병행 워크플로우 후기

Codex 웹 제품 런칭에 참여한 개발자가 두 도구를 병행 사용하는 방식을 정리한 글 바로가기

Codex 웹 제품 런칭에 참여하고 이후 Claude Code를 집중적으로 사용해 온 Calvin French-Owen은 2026년 2월 기준 자신의 워크플로우를 공개했습니다. 그의 결론은 명확합니다. “Claude Code로 시작해서 계획을 세우고 코드베이스를 탐색한 다음, 실제 코딩 단계에서 Codex로 전환한다.”

Claude의 Opus 모델은 컨텍스트 윈도우를 효율적으로 나눠 서브에이전트를 병렬로 돌리고, 사람이 미처 언급하지 못한 부분을 짚어주는 창의성이 있습니다. 반면 Codex는 코드 정확성에서 압도적이라고 평가했습니다. 그가 얻은 가장 실용적인 인사이트는 코딩 에이전트 선택 기준이 ‘모델 성능’이 아니라 ‘지금 내가 얼마나 개입할 수 있는가’라는 점입니다.

한 문장 요약: 가장 실무적인 워크플로우는 Claude Code로 맥락을 잡고 Codex로 코드를 생산하는 분업이며, 두 도구 중 하나를 고르는 것보다 이 조합이 훨씬 효과적이었습니다.

리스크: 두 도구를 병행하면 비용이 커집니다. Claude와 ChatGPT/Codex를 동시에 유지하는 것이 현실적인지 먼저 따져봐야 합니다.

후기 5. 9시간 27분 동안 45개 커밋과 14,259줄을 혼자 생성한 Claude Code /goal 세션 후기

9시간 자율 /goal 세션을 어떻게 설계하고 무엇을 얻었는지 공유한 Reddit 후기 바로가기

Reddit r/Anthropic에 올라온 이 글에서 사용자는 Claude Code /goal 명령어 4개를 체인으로 연결해 9시간 27분의 자율 세션을 진행했습니다. 결과는 45개 커밋, 14,259줄의 코드 생성이었습니다. 이 세션이 작동한 이유는 Claude Code /goal의 내부 구조에 있습니다.

2026년 5월 11일 출시된 v2.1.139부터 /goal은 조건을 설정하면 각 턴 종료 후 보조 평가 모델이 조건 충족 여부를 판단하고, 미충족 시 자동으로 다음 턴을 시작하는 방식으로 작동합니다. 조건 검사는 빠르고 저렴한 모델이 담당해 비용 부담을 최소화하면서도 루프를 유지합니다. 사용자가 아무것도 하지 않아도 Claude가 스스로 다른 접근법을 시도하고, 새로운 에러를 처리하고, 테스트를 반복합니다.

한 문장 요약: Claude Code /goal은 검증 가능한 완료 조건을 설정하면 수 시간 동안 스스로 작업을 이어가며, 9시간에 45커밋이라는 구체적인 결과로 그 가능성이 입증됐습니다.

리스크: Claude Code /goal은 터미널 세션이 종료되면 루프도 중단됩니다. Codex /goal과 달리 세션 기반이므로, 진짜 overnight 실행을 원한다면 터미널을 닫지 않는 별도 환경 설정이 필요합니다.

후기 6. “/goal의 핵심은 기능이 아니라 done을 어떻게 정의하느냐”라는, 냉정한 실패 분석 후기

goal 기능을 써본 뒤 ‘완료 정의’의 중요성을 짚은 Reddit 토론 바로가기

Reddit r/ClaudeCode에서 많은 공감을 받은 이 스레드의 핵심은 직설적입니다. “헤드라인은 goal 명령어가 아니다. 핵심은 done을 어떻게 정의하느냐다.” C++/JUCE 기반 DAW 프로젝트에서 “초 단위 스케줄링을 비트 단위로 전환”하는 goal을 실행한 한 사용자는, 두 번째 compaction 이후 Codex가 이전 방식을 따라 beatToSeconds 변환 함수를 반대로 구현하는 문제를 경험했습니다.

그는 “명확한 테스트 게이트 없이는 장기 태스크를 믿기 어렵다”고 결론지었습니다. 커뮤니티는 이 글을 계기로 잘 구성된 goal의 요소에 대해 공감대를 형성했습니다. 완료 상태, 검증 명령어, 범위 경계, 권한 모드, 사용량 체크, 중단 규칙이 모두 포함되어야 에이전트가 올바르게 작동한다는 것입니다.

한 문장 요약: /goal은 “될 때까지 알아서 해줘”가 아니라, 사람이 검증 가능한 완료 기준을 먼저 설계해야 효과가 나오는 도구입니다.

리스크: 테스트 게이트 없이 장기 세션을 돌리면, 에이전트는 잘못된 방향으로 수 시간을 달린 뒤 완료됐다고 선언할 수 있습니다. diff 리뷰는 선택이 아닌 필수입니다.

후기 7. “코드를 잘 쓰는 주니어, 아키텍처는 없는 엔지니어”라는, 8개월 실무 사용 후기

10년 경력 시니어 엔지니어가 Claude Code 8개월 사용 후 솔직하게 정리한 Reddit 후기 바로가기

Reddit r/ExperiencedDevs에서 10년 경력의 빅테크 시니어 엔지니어는 Claude Code를 약 8개월 사용한 뒤의 평가를 이렇게 요약했습니다. Claude는 뛰어난 코더에 가깝지만, 아키텍처 비전이나 비즈니스 컨텍스트, 그리고 코드를 쓰는 이유까지 갖춘 엔지니어로 보기는 어렵다는 취지였습니다.

이 평가는 Claude Code /goal을 사용하는 방식에도 그대로 연결됩니다. 세부 구현 작업, 보일러플레이트 생성, 리팩토링, 테스트 작성처럼 “무엇을 해야 하는지”가 이미 정해진 작업에서는 탁월합니다. 하지만 시스템 설계나 기술 선택처럼 판단이 필요한 영역에 /goal을 맡기면, 에이전트는 자신 있게 틀린 방향을 향해 달릴 수 있습니다.

한 문장 요약: Claude Code는 내가 이미 이해하고 있는 작업을 빠르게 실행하는 데 탁월하지만, 무엇을 만들어야 하는지 판단하는 역할은 여전히 사람의 몫입니다.

리스크: /goal 설정만 하면 알아서 좋은 결과를 낸다는 기대는 실망으로 이어질 수 있습니다. 고위험 도메인, 설계 단계, 비즈니스 컨텍스트가 복잡한 영역은 에이전트에게 완전 위임하기 전에 반드시 사람이 계획을 먼저 검증해야 합니다.

정리: 후기 7개가 공통으로 말하는 원칙

이 일곱 가지 후기를 묶어보면 한 가지 패턴이 반복됩니다. Codex와 Claude Code 모두, /goal을 가장 잘 쓴 사람들은 도구에 기대를 낮추는 대신 완료 기준을 높였습니다. 14시간 자율 실행을 경험한 Andrew Chen도, 9시간 45커밋을 만든 Reddit 사용자도, 아침마다 PR을 받는 Zack Proser도 공통적으로 먼저 한 일은 “이 작업이 끝났다는 것을 어떻게 확인할 것인가”를 구체화하는 것이었습니다.

반대로 실패한 사례들의 공통점은 하나입니다. 테스트 게이트 없이, 범위 경계 없이, 그냥 “알아서 해줘”를 입력한 것입니다. 결국 /goal은 자율성을 높인 도구가 아니라, 사람의 판단을 앞당기게 만드는 도구에 가깝습니다. 무엇이 완료인지를 명확히 정의하는 작업 자체가, 개발에서 가장 어렵고 가장 가치 있는 단계이기 때문입니다.

5. 후기에서 공통으로 드러난 /goal 활용 원칙

사람들의 후기와 저희 실무 테스트를 함께 보면, 코덱스 goal과 클로드 goal을 잘 쓰는 방식은 생각보다 비슷합니다. 도구는 다르지만 성공한 사례들은 대부분 시작 전에 목표와 완료 기준을 분명히 정했습니다. 반대로 실패한 사례들은 범위가 넓고, 검증 기준이 약하고, 사람이 어디서 개입해야 하는지 정해두지 않았다는 공통점이 있었습니다.

즉 /goal은 자율성을 높여주는 기능이지만, 사람의 판단을 없애주는 기능은 아닙니다. 오히려 사람이 먼저 “무엇이 완료인지”를 더 정확히 정의해야 효과가 납니다. 목표가 선명할수록 에이전트는 오래 달려도 덜 흔들리고, 목표가 흐릴수록 더 그럴듯하게 엉뚱한 방향으로 갑니다.

장시간 goal 실행에서 특히 중요한 요소는 다음과 같습니다.

• 완료 상태를 테스트, 빌드, 화면 동작처럼 검증 가능한 기준으로 정의한다.
• 수정 가능한 파일과 건드리면 안 되는 영역을 함께 적는다.
• 같은 오류가 반복될 때 멈추는 중단 조건을 둔다.
• 각 단계마다 통과한 검증과 남은 작업을 요약하게 한다.
• 최종 결과는 반드시 사람이 diff, 테스트 결과, 실행 화면으로 확인한다.

이 기준은 Claude Code goal에도, Codex goal에도 똑같이 적용됩니다. Codex가 더 오래 달릴 수 있다고 해서 검증이 덜 필요한 것은 아니고, Claude Code가 더 대화형이라고 해서 설계를 맡겨도 되는 것도 아닙니다. 두 도구 모두 사람의 목표 설정이 부정확하면 그 부정확함을 더 빠르고 길게 실행할 뿐입니다.

장시간 실행에서는 외부 기준 문서가 필요합니다

긴 세션에서는 컨텍스트가 커지고, 요약과 재탐색이 반복되면서 비용이 커질 수 있습니다. 또한 처음의 목표보다 눈앞의 하위 작업에 몰입하면서 방향이 흐려질 수도 있습니다. 이 문제는 Codex goal과 Claude Code goal 모두에서 발생할 수 있습니다.

이런 문제를 줄이려면 프롬프트 한 줄보다 외부 기준 문서를 함께 쓰는 편이 더 안정적입니다. 프로젝트 루트에 GOAL.md, PLAN.md, ACCEPTANCE_CRITERIA.md 같은 파일을 만들어두고, 목표·완료 조건·수정 범위·중단 조건을 고정해두면 장시간 실행에서도 방향이 덜 흔들립니다.

예를 들어 다음처럼 기준 문서를 만들어둘 수 있습니다.

# GOAL.md

## Objective
결제 내역 페이지를 새 디자인 시스템으로 마이그레이션한다.

## Done Condition
- `/billing/history` 화면이 기존 기능을 유지한다.
- `pnpm test packages/billing` 통과
- `pnpm lint packages/billing` 통과
- 기존 API 응답 형식 변경 금지

## Scope
- 수정 가능: billing UI components, storybook, test fixture
- 수정 금지: payment API, DB schema, auth middleware

## Stop Rule
- 테스트가 2회 연속 실패하면 멈추고 원인을 요약한다.
- API 변경이 필요하다고 판단되면 직접 수정하지 말고 보고한다.

이후 Claude Code나 Codex에는 이 파일을 기준으로 작업하라고 지시하면 됩니다.

/goal GOAL.md의 Done Condition이 모두 충족될 때까지 작업해줘. 각 턴마다 어떤 조건이 충족됐고 남은 조건이 무엇인지 요약해줘.

이 방식은 특히 장시간 작업에서 효과가 있습니다. 에이전트가 대화 흐름 중 일부를 잊거나 목표를 좁게 해석하더라도, 기준 문서가 다시 방향을 잡아주는 역할을 하기 때문입니다. 비용과 컨텍스트 드리프트를 완전히 없애지는 못하지만, 적어도 “처음에 무엇을 하려 했는지”를 계속 붙잡아둘 수 있습니다.

정리하면 /goal을 잘 쓰는 핵심은 도구를 오래 돌리는 것이 아니라, 오래 돌려도 안전한 구조를 만드는 데 있습니다. Codex goal이든 Claude Code goal이든, 좋은 결과는 좋은 완료 조건에서 시작됩니다. 장시간 goal 실행에서는 프롬프트의 길이보다 완료 기준의 선명함이 더 중요합니다.

6. AI 에이전트 200% 활용을 위한 병행 워크플로우

실무에서는 “Codex냐 Claude Code냐”보다 “어떤 작업에 어떤 도구를 쓸 것인가”가 더 중요합니다. 실제 고급 사용자들은 한 가지 도구만 고집하기보다, 각 도구의 강점을 나눠 쓰는 하이브리드 워크플로우를 구성하는 경우가 많습니다. 이 접근이 더 현실적이고, 리스크도 줄일 수 있습니다.

Codex는 영속형 장기 실행과 검증 기반 작업에, Claude Code는 정식 기능으로 다듬어진 조정·탐색에 무게가 실려 있습니다. 따라서 계획을 세우는 단계와 실행하는 단계를 분리하면 두 도구의 장점을 함께 가져갈 수 있습니다. AI 개발 자동화의 성패는 도구 선택보다 작업 분배에서 갈리는 경우가 많습니다.

패턴 A: Claude로 계획을 짜고, Codex로 실행한다

가장 실용적인 조합 중 하나는 Claude Code로 먼저 코드베이스를 탐색하고, Codex로 실행을 맡기는 방식입니다. Claude Code에게 구조를 분석하게 하고, 변경 계획과 리스크를 정리시킨 뒤, 그 내용을 PLAN.md와 ACCEPTANCE_CRITERIA.md에 남깁니다. 이후 Codex goal에 이 계획을 실행하도록 맡기면 됩니다.

이 방식은 역할 분리가 명확합니다. Claude Code는 “왜 이렇게 되어 있는지”, “어떤 순서로 바꾸는 게 안전한지”, “리스크는 무엇인지”를 함께 검토하는 데 좋습니다. Codex는 계획이 명확해진 뒤 테스트를 돌리고, 실패를 고치고, 다시 검증하는 반복 실행에 잘 맞습니다.

Claude Code로 방향을 잡고 Codex로 영속형 반복 실행을 맡기는 방식은 현재 가장 현실적인 하이브리드 패턴 중 하나입니다.

패턴 B: 단순 유지보수는 Codex, 복잡한 설계는 사람이 함께 본다

두 번째 방식은 작업 난이도별로 도구를 나누는 것입니다. 반복적이고 검증 가능한 작업은 Codex에 배치하고, 설계 판단이 필요한 작업은 Claude Code나 Cursor에서 사람이 함께 잡고 가는 흐름입니다.

Codex에게 맡기기 좋은 작업은 다음과 같습니다.

• 오래된 import 경로 변경
• 린트 오류 일괄 수정
• 테스트 깨진 파일 복구
• 문서와 코드 예제 동기화
• 단순 버전 업그레이드

반대로 사람이 적극적으로 개입해야 하는 작업도 있습니다.

• 신규 도메인 설계
• 결제·권한·보안 로직
• 데이터 모델 변경
• 성능 병목의 근본 원인 분석
• 제품 요구사항이 애매한 기능

이 구조를 적용하면 아침에 Codex에 유지보수 작업을 여러 개 배치해두고, 개발자는 Claude Code나 Cursor에서 더 복잡한 설계 문제를 다룰 수 있습니다. 핵심은 모든 일을 AI에게 맡기는 것이 아니라, AI가 맡아도 되는 일을 정확히 분리하는 것입니다.

패턴 C: 프로젝트 인수인계는 “AI 초안 + 실제 문서 검증”으로 본다

이번 테스트 이후 추가하고 싶은 패턴이 하나 더 있습니다. 외주 개발 프로젝트를 인수하거나 기존 프로젝트 상태를 빠르게 파악해야 할 때는, 코덱스 goal과 클로드 goal을 “최종 판단자”로 쓰기보다 “초안 생성자”로 쓰는 편이 안전합니다.

먼저 두 도구에 같은 조건으로 PM 인수인계 문서를 만들게 합니다. 그다음 실제 담당자 문서, 최신 브랜치, 운영 배포 URL, UAT evidence와 대조합니다. 이때 AI가 맞춘 부분은 문서화하고, 틀린 부분은 왜 틀렸는지 기록하면 프로젝트 리스크를 훨씬 빠르게 정리할 수 있습니다.

인수인계 상황에서 /goal의 진짜 가치는 정답을 바로 내는 데 있지 않고, 사람이 확인해야 할 질문을 빠르게 뽑아내는 데 있습니다. 특히 “진짜 운영 대상은 어느 저장소인가?”, “현재 배포본은 어떤 브랜치인가?”, “테스트나 UAT evidence가 있는가?” 같은 질문은 코드만 보고 놓치기 쉽습니다. AI가 만든 질문 목록을 담당자 미팅의 체크리스트로 쓰면 실무적으로 꽤 유용합니다.

7. 실패 없는 /goal 실행을 위한 6가지 작성 원칙

코덱스 goal 모드 사용법과 클로드 goal 사용법의 핵심은 크게 다르지 않습니다. 중요한 것은 프롬프트를 멋지게 쓰는 일이 아니라, 작업의 성공 조건을 분명하게 설계하는 일입니다. /goal은 단순 요청이 아니라 작은 실행 계약서처럼 작성해야 합니다.

1) 완료 상태를 숫자나 명령 결과로 정의합니다

나쁜 예시는 다음과 같습니다.

/goal 코드 품질을 개선해줘.

이 요청은 방향이 너무 넓습니다. 좋은 예시는 완료 상태가 명확합니다.

/goal src/components/Button.tsx의 variant 분기를 정리하고, pnpm test Button.test.tsx와 pnpm lint가 모두 exit 0으로 통과할 때까지 작업해줘.

“개선”이 아니라 어떤 명령이 통과하면 끝인지 적어야 합니다. 그래야 AI도 작업의 끝을 판단할 수 있습니다.

2) 검증 명령어를 반드시 넣습니다

AI가 “완료했습니다”라고 말하는 것은 검증이 아닙니다. 테스트, 린트, 타입체크, 빌드 결과처럼 다시 실행 가능한 명령이 있어야 합니다. 작업이 클수록 좁은 테스트부터 시작하고, 마지막에 전체 검증을 돌리는 흐름이 안전합니다.

pnpm test
pnpm lint
pnpm typecheck
pnpm build
pytest tests/billing -q
npm run e2e -- --project=chromium

Proof Command는 goal 모드에서 가장 중요한 안전장치입니다.

3) 수정 가능한 파일과 금지 영역을 나눕니다

모호한 범위는 예상 밖의 변경을 부릅니다. 다음과 같은 요청은 위험합니다.

/goal 필요한 파일을 알아서 수정해줘.

더 안전한 방식은 수정 가능 영역과 금지 영역을 함께 지정하는 것입니다.

수정 가능: packages/billing/src, packages/billing/test
수정 금지: packages/auth, database/migrations, public API schema

AI 에이전트는 문제를 해결하기 위해 예상보다 넓은 범위를 건드릴 수 있습니다. 그래서 “어디까지 해도 되는지”뿐 아니라 “어디부터는 안 되는지”를 함께 알려줘야 합니다.

4) 긴 작업은 중간 보고 기준을 둡니다

장기 goal에서는 중간 체크포인트가 필요합니다. 에이전트가 지금 무엇을 바꿨는지, 무엇을 통과했는지, 어떤 문제가 남았는지 확인할 수 있어야 합니다. 이 과정은 단순한 보고가 아니라 목표 상실을 막는 장치입니다.

각 체크포인트마다 다음을 요약해줘.
1. 변경한 파일
2. 통과한 검증 명령어
3. 아직 실패하는 항목
4. 다음 턴에서 할 일

5) 실패 반복 시 멈추게 합니다

AI가 같은 문제를 계속 고치려 들면 비용과 리스크가 커집니다. 특히 긴 goal에서는 실패 반복을 방치하지 않는 것이 중요합니다. 다음처럼 중단 기준을 명확히 넣는 편이 좋습니다.

동일한 proof command가 2회 연속 실패하면 더 이상 수정하지 말고, 실패 원인과 필요한 사람의 결정을 요약해줘.

이 조건 하나만으로도 폭주하는 에이전트를 상당 부분 막을 수 있습니다.

6) 목표 밖 문제를 발견하면 보고하게 합니다

작업 중 예상보다 큰 문제가 드러날 수 있습니다. 이때 AI가 마음대로 아키텍처나 데이터 구조를 바꾸면 위험합니다. 중요한 의사결정은 사람이 맡고, AI는 보고하도록 설계해야 합니다.

작업 중 DB schema 변경, public API 변경, 인증 정책 변경이 필요하다고 판단되면 직접 수정하지 말고 멈춘 뒤 제안서만 작성해줘.

좋은 goal은 AI에게 더 많은 자유를 주는 문장이 아니라, 안전하게 움직일 수 있는 경계를 정해주는 문장입니다.

8. 복사해서 쓰는 /goal 프롬프트 템플릿

아래 템플릿은 Codex goal과 Claude Code goal 모두에 사용할 수 있습니다. 핵심은 목표, 완료 조건, 검증 명령어, 수정 범위, 중단 조건을 한 번에 적는 것입니다. 프로젝트에 맞게 디렉터리명과 명령어만 바꿔 사용해도 충분합니다.

/goal [목표]를 완료해줘.

Objective:
- [무엇을 달성해야 하는지 한 문장으로 설명]

Done Condition:
- [검증 가능한 완료 조건 1]
- [검증 가능한 완료 조건 2]
- [검증 가능한 완료 조건 3]

Proof Commands:
- [예: pnpm test packages/billing]
- [예: pnpm lint packages/billing]
- [예: pnpm typecheck]

Scope:
- 수정 가능: [파일/디렉터리]
- 수정 금지: [파일/디렉터리/정책/API/DB]

Working Rules:
- 기존 public API는 변경하지 마.
- 테스트를 통과시키기 위해 테스트 자체를 약화하지 마.
- 변경 범위를 최소화해.
- 각 체크포인트마다 변경 내용, 검증 결과, 남은 작업을 요약해.

Stop Rules:
- 같은 proof command가 2회 연속 실패하면 멈추고 원인을 요약해.
- 목표 달성에 DB schema/API/인증 정책 변경이 필요하면 직접 수정하지 말고 보고해.
- 목표 범위를 벗어난 리팩토링은 하지 마.

PM 인수인계 문서용 /goal 프롬프트 예시

실제 프로젝트 분석이나 외주 개발 인수인계에 /goal을 쓰려면, 코드 수정용 프롬프트와는 조금 다르게 써야 합니다. 이때는 “고쳐줘”가 아니라 “현재 상태를 판단하고, 근거와 확인 질문을 정리해줘”에 가깝게 요청하는 편이 좋습니다.

/goal 이 프로젝트를 PM 인수인계 관점에서 분석해줘.

Objective:
- 외주 개발사가 프로젝트를 인수받는 상황을 가정하고,
현재 코드베이스의 성숙도, 운영 가능성, 미완성 범위, 리스크, 담당자에게 확인할 질문을 정리한다.

분석 기준:
- 코드와 설정 파일에서 확인 가능한 사실만 확정한다.
- 확인되지 않은 비즈니스 목적, 우선순위, 일정은 추정하지 않는다.
- 운영 브랜치, 배포 URL, 담당자 문서가 없으면 “확인 필요”로 분리한다.

Output:
- 프로젝트 한 줄 요약
- 구성 저장소별 역할과 성숙도
- 구현된 범위
- 미완성 또는 확인이 필요한 범위
- 실행/테스트/빌드/배포 단서
- 외부 의존성 및 운영 리스크
- PM이 반드시 물어봐야 할 질문
- 근거가 약한 추정 목록

Stop Rules:
- 코드에서 확인되지 않는 내용을 확정하지 마.
- 운영 대상 저장소나 브랜치가 불명확하면 단정하지 말고 질문으로 남겨.
- 최종 요약에는 “확정 가능한 내용”과 “담당자 확인이 필요한 내용”을 분리해.

이 프롬프트는 코덱스 goal과 클로드 goal 모두에 사용할 수 있습니다. 다만 이번 실험에서 확인했듯이, 실제 인수인계에 쓰려면 여기에 최신 브랜치, 운영 URL, 배포 커밋, 담당자 문서까지 함께 넣는 것이 좋습니다.

9. 결론: 코덱스 goal과 클로드 goal, 무엇을 선택해야 할까?

그렇다면 클로드 코드 goal과 코덱스 goal 중 무엇을 선택해야 할까요. 답은 프로젝트의 성격에 따라 달라집니다. 두 도구는 같은 문제를 다른 방식으로 해결하며, 각각 강한 지점과 약한 지점이 분명합니다.

Codex goal은 영속형 장기 실행과 테스트로 완료 여부를 명확히 판단할 수 있는 작업에 잘 맞는다는 평가가 많습니다. 긴 마이그레이션이나 리팩토링, 백엔드 중심 수정, SDK 교체, 대량 파일 수정처럼 결과를 검증하기 쉬운 작업이 대표적입니다. 반면 Claude Code goal은 프론트엔드 작업, 코드베이스 탐색, 문서화, 대화형 조정에서 자연스럽게 느껴진다는 평이 많습니다.

이번에 실제 프로젝트를 돌려본 결과까지 합치면 기준은 조금 더 선명해집니다. 코드 근거를 촘촘히 보고 싶다면 코덱스 goal이 유리했고, PM이 읽기 좋은 문서 구조를 빠르게 만들고 싶다면 클로드 goal이 더 편했습니다. 하지만 실제 인수인계나 프로젝트 상태 판단에서는 둘 중 하나만 믿기보다, 실제 담당자 문서와 함께 검증하는 과정이 반드시 필요했습니다.

Codex goal은 다음 상황에서 좋은 선택이 될 수 있습니다.

• 테스트로 완료 여부를 명확히 판단할 수 있다.
• 장기 마이그레이션이나 리팩토링을 맡기고 싶다.
• 백엔드, 인프라, SDK 교체, 대량 수정 작업이 많다.
• 코드 근거와 파일 단위 확인을 중요하게 본다.

Claude Code goal은 다음 상황에서 더 잘 맞습니다.

• 프론트엔드/UI 작업이 많다.
• 터미널에서 직접 조정하며 작업하고 싶다.
• 코드베이스 탐색과 계획 수립이 중요하다.
• PM이나 이해관계자가 읽기 좋은 문서가 필요하다.

결국 AI 코딩 에이전트의 핵심은 개발자를 대체하는 것이 아니라, 반복 실행과 초기 분석을 맡길 수 있는 구조를 만드는 데 있습니다. /goal 시대의 개발자는 코드를 덜 쓰는 사람이 아니라, 좋은 목표와 완료 조건을 설계하고 AI의 결과를 검증하는 사람에 가까워지고 있습니다.

자주 묻는 질문 FAQ

Q1. 코덱스 goal과 클로드 코드 goal 중 뭐가 더 좋나요?

명확한 테스트와 완료 조건이 있는 장기 작업은 Codex goal이 유리하다는 평가가 많습니다. 반면 프론트엔드 작업, 코드베이스 탐색, 대화형 조정이 필요한 작업은 Claude Code goal이 더 편할 수 있습니다. 다만 절대적인 우열이라기보다 작업의 성격에 맞춰 선택하는 것이 좋습니다.

Q2. /goal을 쓰면 정말 개발자가 없어도 되나요?

그렇지는 않습니다. /goal은 반복 실행을 자동화해주는 기능이지, 아키텍처 판단이나 제품 의사결정을 대신하는 기능은 아닙니다. 특히 보안, 결제, 권한, 데이터베이스 변경은 사람이 반드시 리뷰해야 합니다.

Q3. 클로드 goal 프롬프트에서 가장 중요한 것은 무엇인가요?

가장 중요한 것은 완료 조건입니다. “좋게 만들어줘”가 아니라 어떤 명령이 통과하면 끝인지, 어떤 파일은 수정하면 안 되는지, 몇 번 실패하면 멈출지를 적어야 합니다. 검증 결과가 대화에 분명히 남도록 설계하는 것도 중요합니다.

Q4. 코덱스 14시간, 클로드 9시간 같은 실제 사례를 믿어도 되나요?

이런 구체적 수치는 대부분 개인 블로그·커뮤니티 후기에서 나온 사례입니다. 인상적인 참고 자료로는 볼 수 있지만, 모든 프로젝트에 그대로 적용된다고 보기는 어렵습니다. 중요한 것은 실행 시간보다 목표, 범위, 테스트 게이트, 사람의 리뷰가 있었는지입니다.

Q5. AI 코딩 에이전트 비교에서 가장 중요한 기준은 무엇인가요?

모델 성능만 보면 판단이 어렵습니다. 더 중요한 기준은 작업 유형입니다. 영속형 마이그레이션과 백엔드 자동화는 Codex, 프론트엔드와 탐색적 개발은 Claude Code가 유리하다는 평가가 많지만, 실무에서는 두 도구를 병행하는 하이브리드 워크플로우가 가장 안정적입니다.

Q6. 코덱스 goal이나 클로드 goal로 PM 인수인계 문서를 만들어도 되나요?

초안으로는 충분히 활용할 수 있습니다. 실제 프로젝트를 넣어보니 두 도구 모두 백엔드 구조, 저장프로시저 리스크, 배포 확인 필요성, 운영 대상 프론트엔드 확인 질문 같은 핵심 포인트를 잘 잡았습니다. 다만 실제 운영 브랜치, 배포 URL, 담당자 인수인계 문서, UAT evidence가 없으면 중요한 판단을 틀릴 수 있습니다.

Q7. 프로젝트 인수인계에 /goal을 쓸 때 가장 먼저 준비해야 할 것은 무엇인가요?

코드 저장소만 던져주는 것보다 최신 운영 기준을 함께 주는 것이 중요합니다. 최소한 현재 운영 URL, 배포 브랜치, HEAD 커밋, 실제 담당자 인수인계 문서, 테스트 또는 UAT evidence, 남은 작업 목록을 함께 제공하는 편이 좋습니다. 그래야 AI가 낡은 스냅샷을 기준으로 그럴듯하지만 틀린 결론을 내는 일을 줄일 수 있습니다.

AI 코딩 외주를 실무에 적용하려면, 검증 가능한 개발팀과 시작하세요!

코덱스 goal과 클로드 goal처럼 AI 코딩 에이전트를 잘 쓰면 개발 속도는 분명히 빨라집니다. 하지만 이번 테스트에서 봤듯이, 중요한 것은 단순히 AI를 쓰는 것이 아니라 AI가 만든 결과를 어떤 기준으로 검증하고, 실무 프로세스 안에 어떻게 녹이느냐입니다. 리트머스는 AI·바이브코딩 기반 실전 외주개발에 강점을 가진 팀으로, 빠른 개발 속도뿐 아니라 기획 정리, 요구사항 검증, 코드 리뷰, 보안 리스크 점검까지 함께 설계합니다. 우리 프로젝트가 바이브코딩 외주에 적합한지 검토해드립니다.

그런데 여기서 한 가지가 더 남습니다. 코덱스 goal과 클로드 goal의 차이를 이해했다면, 다음 단계에서는 “그럼 실제로 Codex CLI를 어떻게 설치하고, 어떤 커맨드와 설정으로 운영해야 할까?”라는 질문이 생깁니다.

코덱스 CLI 완벽 가이드: 설치 방법부터 커맨드·스킬·AGENTS.md까지 총정리

이 글에서는 Codex CLI 설치 방법부터 주요 커맨드, 스킬 활용, AGENTS.md 설정까지 실무에 필요한 기본기를 정리했습니다. 이번 글이 코덱스 goal과 클로드 goal을 비교하고 실무 적용 기준을 잡는 글이었다면, 이 글은 실제로 Codex를 세팅하고 프로젝트에 적용하는 다음 단계 가이드로 함께 읽기 좋습니다.

AI 코딩 에이전트를 실무 프로젝트에 어떻게 적용할 수 있을지 고민 중이라면, 무료 견적 상담을 통해 우리 프로젝트가 어디까지 가능한지 확인해 보세요!