오늘의 AI 글: Codex Goal 모드가 바꾸는 일의 단위

왜 이 글인가

오늘 고른 글은 OpenAI Codex의 Goal 모드를 단순한 신기능 소개가 아니라 “일을 에이전트에게 어떻게 맡겨야 하는가”라는 관점에서 다룬다. 최근 코딩 에이전트의 경쟁은 답변 품질이나 코드 한 조각 생성 능력을 넘어, 여러 시간 동안 스스로 계획하고, 수정하고, 테스트하고, 막히면 증거를 남기는 지속형 작업 능력으로 이동하고 있다. 이 변화의 핵심은 모델이 더 똑똑해졌다는 말보다 조금 더 구체적이다. 이제 사용자가 던지는 요청의 단위가 “이 함수 고쳐줘”에서 “이 목표가 충족될 때까지 반복해줘”로 바뀌고 있다.

이 글이 특히 읽을 가치가 있는 이유는 Goal 모드의 장점을 과장된 자동화 구호로만 말하지 않기 때문이다. 원문은 Codex가 장시간 루프를 돌 수 있다는 사실보다, 그 루프가 성공하려면 목표가 측정 가능해야 하고, 검증 표면이 있어야 하며, 실패했을 때 멈추거나 보고할 기준이 있어야 한다는 점을 반복해서 강조한다. 즉 좋은 코딩 에이전트 사용법의 중심은 “프롬프트를 멋지게 쓰는 법”이 아니라 “완료 조건을 엔지니어링하는 법”으로 옮겨간다.

Claude Code, Codex, OpenClaw 같은 도구를 이미 써본 개발자라면 이 주제가 더 현실적으로 느껴질 것이다. 에이전트는 짧은 수정에는 꽤 능숙하지만, 큰 리팩터링이나 테스트가 꼬인 버그 수정에서는 종종 길을 잃는다. 그때 문제는 모델이 코드를 전혀 모른다는 데 있지 않다. 더 자주 생기는 문제는 완료 기준이 흐릿하고, 테스트가 느리거나 불안정하며, 어떤 변경은 해도 되고 어떤 변경은 금지되는지가 명확하지 않다는 데 있다. Goal 모드는 이 문제를 더 잘 드러낸다. 목표가 선명하면 에이전트는 오래 일할 수 있지만, 목표가 흐리면 오래 헤맨다.

또 하나 중요한 점은 이 글이 Goal 모드를 개발 작업에만 가두지 않는다는 것이다. 성능 튜닝, 기능 구현, 마이그레이션, flaky test 수정, 문서 포맷 변환, 연구 재현까지 다양한 사례를 묶어서 보여준다. 공통점은 코드냐 문서냐가 아니라 “검증 가능한 산출물”이 있느냐이다. 테스트가 통과한다, p95 지연 시간이 기준 아래로 내려간다, 체크리스트 200개가 모두 만족된다, 재현 가능한 주장과 막힌 주장이 분리된다. 이런 식으로 작업을 계량화할 수 있다면 에이전트에게 맡길 수 있는 범위가 생각보다 넓어진다.

마지막으로 이 글은 2026년의 개발자에게 꽤 불편하지만 유용한 메시지를 던진다. 에이전트 시대에 개발자의 역할은 줄어드는 것이 아니라 앞단으로 이동한다. 직접 모든 파일을 고치는 시간은 줄 수 있다. 대신 어떤 목표를 세울지, 어떤 테스트를 신뢰할지, 어떤 범위에서는 자동 수정을 허용할지, 결과를 어떻게 리뷰할지 정하는 일이 더 중요해진다. 손으로 코드를 치는 능력만큼이나 작업을 에이전트가 이해할 수 있는 계약으로 바꾸는 능력이 중요해지는 셈이다.

핵심 요약

• 원문의 핵심은 Codex Goal 모드가 단발성 응답을 지속형 작업 루프로 바꾼다는 것이다. 일반 프롬프트가 “질문 하나에 답 하나”라면, Goal은 목표를 세우고, 계획하고, 파일을 고치고, 테스트하고, 결과를 기준과 비교한 뒤 다시 반복하는 구조다. 중요한 차이는 모델이 스스로 완료를 주장하는 것이 아니라, 사용자가 정한 성공 조건을 향해 증거 기반으로 움직인다는 점이다.

• Goal 모드는 “알아서 잘 해줘”라는 요청과 잘 맞지 않는다. 오히려 반대다. 목표가 명확하고, 수치나 체크리스트로 표현되며, 검증 방법이 빠를수록 잘 작동한다. 예를 들어 “성능을 개선해줘”는 약한 목표다. 반면 “체크아웃 벤치마크의 p95 지연 시간을 120ms 아래로 낮추고, 기존 correctness suite는 모두 통과시켜라”는 훨씬 강한 목표다. 무엇이 성공이고 무엇이 회귀인지가 분명하기 때문이다.

• 원문은 Goal 설계의 세 요소를 반복해서 보여준다. 첫째, 달성해야 할 결과가 있어야 한다. 둘째, 결과를 확인할 검증 표면이 있어야 한다. 셋째, 깨뜨리면 안 되는 제약이 있어야 한다. 이 세 가지가 있으면 에이전트는 작업 중간에 방향을 잃을 가능성이 줄어든다. 반대로 하나라도 빠지면 작업은 “끝났는지 모르지만 뭔가 많이 한 상태”가 되기 쉽다.

• Goal 모드가 잘 맞는 작업은 대체로 반복과 검증이 필요한 일이다. 복잡한 기능 구현, 성능 최적화, 대규모 리팩터링, 라이브러리 마이그레이션, 실패 테스트 수정, 문서 빌드 오류 해결 등이 대표적이다. 이런 일은 사람이 해도 여러 번 시도하고 확인해야 한다. 에이전트에게 루프를 맡길 수 있다면 인간은 중간 반복보다 목표와 리뷰에 집중할 수 있다.

• 흥미로운 점은 문서 작업도 Goal 모드의 대상이 될 수 있다는 것이다. 원문에는 논문 포맷을 다른 학회 양식으로 바꾸는 사례가 나온다. 사용자는 수백 개 규칙을 체크리스트로 제공했고, Codex는 그 항목을 하나씩 만족시키는 방향으로 문서를 수정했다. 여기서 검증 표면은 테스트 코드가 아니라 체크리스트와 빌드 가능성이다. 즉 에이전트 자동화의 본질은 “코드를 잘 아는가”보다 “작업을 검증 가능한 규칙으로 바꿀 수 있는가”에 가깝다.

• 원문에서 가장 실무적인 교훈은 긴 자율 실행의 성패가 실행 중이 아니라 실행 전 준비에서 갈린다는 점이다. 좋은 SPEC.md, 명확한 done_when 조건, 빠른 테스트, 작은 샘플 데이터, 실패 시 남길 로그가 준비되어 있으면 에이전트는 오래 달릴 수 있다. 준비가 부족하면 Goal 모드는 생산성 도구가 아니라 비싼 자동 삽질 루프가 된다.

• Goal 모드는 인간 리뷰를 없애지 않는다. 오히려 리뷰 대상을 바꾼다. 사람이 매번 에러 로그를 따라가며 수정하는 대신, 에이전트가 남긴 변경 내역, 테스트 결과, 벤치마크, 막힌 지점을 검토한다. 따라서 브랜치 격리, 커밋 단위, 로그 파일, 재현 가능한 명령어가 중요해진다. 자율 실행은 무감독 배포가 아니라 더 구조화된 위임이다.

• 원문은 자동화 이득의 예로 여러 커뮤니티 사례를 소개하지만, 그 숫자 자체보다 패턴이 중요하다. 밤새 backlog 일부를 구현하거나, 여러 시간 동안 테스트 실패를 좁히거나, 형식 규칙을 반복 적용하는 작업은 모두 “명확한 입력 목록 + 반복 가능한 검증 + 제한된 변경 범위”라는 공통 구조를 가진다. 이 구조를 만들 수 없는 일은 아직 인간의 판단이 더 많이 필요하다.

• 결론적으로 Goal 모드는 코딩 에이전트가 더 오래 일하게 만드는 기능이지만, 진짜 변화는 개발자가 일을 더 엄밀하게 정의하게 만든다는 데 있다. 앞으로 좋은 개발 워크플로는 프롬프트 모음이 아니라 목표 템플릿, 테스트 계약, 체크리스트, 중단 조건, 리뷰 절차의 조합이 될 가능성이 크다.

원문의 논지를 단계별로 풀어보기

첫 번째 단계는 Goal 모드를 일반 채팅 프롬프트와 구분하는 것이다. 일반적인 코딩 도우미 사용에서는 사용자가 “이 버그를 고쳐줘”라고 말하고, 모델이 한 번 분석한 뒤 수정안을 제시한다. 물론 도구를 가진 에이전트라면 파일을 읽고 테스트를 돌릴 수도 있다. 그러나 기본 구조는 여전히 한 번의 요청과 한 번의 응답에 가깝다. Goal 모드는 여기에서 한 단계 더 나아가 “목표가 충족될 때까지 계속 시도하는 루프”를 만든다. 모델은 계획을 세우고, 코드를 고치고, 검증하고, 실패하면 다시 고친다. 이때 중요한 것은 루프 자체가 아니라 루프의 종료 조건이다. 종료 조건이 없으면 지속성은 장점이 아니라 위험이 된다.

두 번째 단계는 좋은 목표와 나쁜 목표를 나누는 기준이다. “성능을 높여라”, “코드를 정리해라”, “테스트를 안정화해라” 같은 목표는 인간에게는 대충 의미가 통하지만 에이전트에게는 너무 넓다. 어디까지 해야 충분한지, 어떤 수정을 금지해야 하는지, 결과를 어떻게 확인해야 하는지가 빠져 있기 때문이다. 원문은 강한 Goal이 결과, 검증, 제약을 함께 가진다고 설명한다. “런타임을 20% 줄이되 유닛 테스트와 통합 테스트는 모두 통과해야 한다”는 목표는 숫자와 안전장치를 동시에 준다. “p95 지연 시간을 120ms 아래로 낮추되 correctness suite는 녹색이어야 한다”는 식의 목표도 마찬가지다. 에이전트가 멈출 수 있는 선을 그어주는 것이 핵심이다.

세 번째 단계는 피드백 루프를 짧게 만드는 것이다. 에이전트가 좋은 목표를 받았더라도 검증에 40분이 걸리면 반복 속도가 느려지고 비용도 커진다. 사람도 마찬가지다. 테스트 한 번에 오래 걸리면 가설을 빨리 검증하지 못한다. Goal 모드에서는 이 문제가 더 커진다. 에이전트가 여러 번 시도해야 하므로, 빠른 단위 테스트, 축소된 벤치마크, 작은 샘플 데이터, 캐시된 환경이 중요해진다. 원문이 말하는 “tight feedback loop”는 멋진 표현이 아니라 실전의 비용 절감 장치다. 에이전트에게 긴 작업을 맡기고 싶다면 먼저 빠르게 실패하고 빠르게 확인할 수 있는 길을 깔아야 한다.

네 번째 단계는 작업 유형별로 Goal이 어떻게 쓰이는지 보는 것이다. 복잡한 기능 구현에서는 BACKLOG.md나 SPEC.md 같은 명시적 목록이 중요하다. 에이전트는 목록을 따라 기능을 구현하고, 각 변경을 테스트하며, 완료된 항목과 남은 항목을 기록할 수 있다. 성능 튜닝에서는 수치 목표와 벤치마크가 중심이 된다. 에이전트는 병목을 찾고, 변경하고, 측정하며, 기준에 도달할 때까지 반복한다. 리팩터링과 마이그레이션에서는 타입체크, 린트, 빌드, 테스트가 검증 표면이 된다. 이 경우 “모든 파일을 TypeScript strict 모드로 전환하고 any를 남기지 말 것”처럼 컴파일러가 판단할 수 있는 조건이 좋다.

다섯 번째 단계는 버그 수정과 flaky test에서 Goal 모드가 특히 강해질 수 있다는 점이다. 실패 테스트를 고치는 일은 원인 가설을 세우고, 작은 수정을 하고, 다시 돌리고, 로그를 읽는 반복으로 이루어진다. 사람에게는 지루하고 시간이 많이 드는 루프다. 에이전트에게는 상대적으로 잘 맞는 루프다. 단, 목표가 “테스트 좀 고쳐줘”이면 위험하다. 테스트를 무력화하거나 의미 없는 대기 시간을 늘리는 방식으로 통과시킬 수 있기 때문이다. 좋은 Goal은 “공개 API를 바꾸지 말고, 특정 테스트 네 개를 통과시키며, 테스트의 의도를 약화하지 말 것”처럼 성공과 금지를 함께 둬야 한다.

여섯 번째 단계는 문서와 연구 작업까지 범위를 넓히는 것이다. 원문에서 인상적인 사례는 학회 논문 포맷 변환이다. 기술적 내용을 바꾸지 말고 형식 규칙만 맞추라는 목표를 주고, 별도의 체크리스트를 제공하면 에이전트는 각 항목을 확인하며 문서를 고칠 수 있다. 이 사례가 중요한 이유는 Goal 모드가 코드 생성 도구가 아니라 “검증 가능한 산출물을 향한 반복 엔진”이라는 점을 보여주기 때문이다. 연구 재현도 비슷하다. 완벽히 재현 가능한 주장과 데이터 부족으로 막힌 주장을 분리해 보고하도록 목표를 세우면, 에이전트는 무리하게 결론을 꾸며내기보다 증거와 한계를 나누는 작업을 할 수 있다.

일곱 번째 단계는 자율 실행의 환상을 걷어내는 것이다. 원문에 소개된 성공 사례들은 모두 사람이 사전에 상당한 구조를 제공했다. 어떤 개발자는 긴 done_when 조건을 준비했고, 어떤 사례에서는 여러 항목의 체크리스트가 제공됐다. 어떤 작업은 SPEC.md를 먼저 정교하게 다듬은 뒤 Goal을 실행했다. 이 말은 에이전트가 마법처럼 요구사항을 알아서 읽고 완성한다는 뜻이 아니다. 오히려 인간이 요구사항을 더 명확한 계약으로 바꿨기 때문에 에이전트가 오래 일할 수 있었다는 뜻이다. 자동화의 출발점은 무책임한 위임이 아니라 더 정교한 위임 문서다.

여덟 번째 단계는 완료 보고를 증거 기반으로 만드는 것이다. Goal 모드의 좋은 사용은 “제가 끝냈습니다”라는 말에서 멈추지 않는다. 어떤 테스트를 실행했는지, 어떤 벤치마크 수치가 나왔는지, 어떤 항목은 완료했고 어떤 항목은 막혔는지 남겨야 한다. 이 감사 가능성이 없으면 장시간 실행은 신뢰하기 어렵다. 에이전트가 파일을 많이 고쳤다고 해서 좋은 결과라는 보장은 없다. 반대로 변경이 적더라도 목표 조건을 명확히 만족하고 로그가 남아 있으면 리뷰하기 쉽다. 따라서 Goal 실행의 산출물은 코드뿐 아니라 실행 기록이어야 한다.

아홉 번째 단계는 실패 조건을 설계하는 것이다. 많은 사람이 자동화 목표를 세울 때 성공 조건만 쓴다. 하지만 실무에서는 언제 멈춰야 하는지도 중요하다. 테스트 환경이 깨졌는지, 의존성 설치가 막혔는지, 목표 수치가 현실적으로 불가능한지, 권한이 필요한지 구분해야 한다. 좋은 Goal은 “막히면 무엇을 보고할지”까지 포함한다. 예를 들어 “벤치마크를 실행할 수 없으면 원인을 기록하고 임의로 성공을 선언하지 말 것” 같은 문장은 작지만 중요하다. 에이전트의 가장 위험한 실패는 실패 자체가 아니라 실패를 성공처럼 포장하는 것이다.

마지막 단계는 Goal 모드를 팀 워크플로로 받아들이는 것이다. 개인이 한 번 신기하게 써보는 기능으로 끝내면 효과가 제한적이다. 반복적으로 쓸 목표 템플릿을 만들고, 작업 유형별로 필요한 검증 명령을 정리하고, 에이전트가 남길 로그 형식을 통일하고, 브랜치와 PR 리뷰 규칙을 마련해야 한다. 그러면 Goal 모드는 “AI가 가끔 도와주는 도구”에서 “반복 가능한 작업 실행자”로 바뀐다. 이 변화는 개발팀의 운영 방식까지 건드린다. 잘 정의된 일은 더 많이 자동화되고, 잘 정의되지 않은 일은 여전히 인간의 설계와 판단을 요구한다.

일반 독자에게 중요한 포인트

• AI 에이전트의 발전은 단순히 더 자연스러운 대화로 끝나지 않는다. 이제 중요한 질문은 “AI가 답을 잘하나?”가 아니라 “AI에게 일을 맡겼을 때 완료 기준을 지키며 끝까지 갈 수 있나?”다. Goal 모드는 이 질문을 정면으로 다룬다.

• 자동화가 강해질수록 인간의 역할은 사라지기보다 앞단으로 이동한다. 무엇을 해야 하는지, 어느 정도면 충분한지, 무엇은 하면 안 되는지 정의하는 일이 더 중요해진다. 좋은 지시는 친절한 문장이 아니라 검증 가능한 계약에 가깝다.

• “AI가 알아서 해준다”는 말은 대체로 위험하다. 알아서 하게 만들려면 먼저 기준을 줘야 한다. 테스트, 체크리스트, 수치 목표, 금지 조건, 중단 조건이 있어야 한다. 기준 없는 자율성은 생산성이 아니라 불확실성이다.

• 이 원칙은 개발 밖에서도 통한다. 보고서 작성, 문서 정리, 리서치, 번역, 데이터 정리도 검증 가능한 체크리스트가 있으면 에이전트에게 더 잘 맡길 수 있다. “좋게 정리해줘”보다 “다섯 항목을 포함하고, 출처를 붙이고, 중복을 제거하고, 마지막에 미확인 사항을 분리해줘”가 훨씬 강하다.

• 에이전트 시대의 실무 역량은 질문 능력보다 작업 설계 능력에 가까워질 가능성이 크다. 복잡한 일을 작은 검증 단위로 나누고, 완료 조건을 명확히 쓰고, 결과를 리뷰할 수 있게 만드는 사람이 AI 도구를 더 잘 활용한다.

적용 아이디어

• 긴 코딩 작업을 맡기기 전에 SPEC.md나 GOAL.md를 먼저 만든다. 목표, 배경, 변경 허용 범위, 금지 사항, 완료 조건, 실행할 테스트 명령을 한 파일에 적는다. 에이전트에게 바로 코딩을 시키기보다 이 파일을 먼저 검토하게 하는 편이 안전하다.

• 목표 문장은 결과, 검증, 제약을 한 세트로 쓴다. 예를 들어 “검색 페이지를 빠르게 해줘” 대신 “검색 페이지의 p95 렌더 시간을 로컬 벤치마크 기준 300ms 이하로 낮추고, 기존 E2E 테스트와 접근성 체크는 모두 통과시켜라”처럼 쓴다.

• 테스트 루프를 짧게 만든다. 전체 CI가 30분 걸린다면 에이전트가 매번 전체 CI만 돌리게 하지 말고, 관련 단위 테스트, 축소 벤치마크, 특정 패키지 빌드 명령을 알려준다. 마지막 검증에는 전체 CI를 쓰되, 중간 반복은 빠르게 만든다.

• 체크리스트를 적극적으로 사용한다. 기능 구현이라면 요구사항 체크리스트, 문서 작업이라면 형식 체크리스트, 마이그레이션이라면 파일 범위와 금지 패턴 체크리스트를 만든다. 에이전트가 각 항목의 상태를 업데이트하게 하면 진행 상황을 리뷰하기 쉬워진다.

• 자율 실행은 반드시 별도 브랜치에서 한다. 에이전트가 오래 작업할수록 변경 범위가 커질 수 있다. 브랜치, 커밋 단위, 테스트 로그가 분리되어 있어야 되돌리기 쉽다. 직접 main에 큰 변경을 쌓게 하는 것은 별로 좋은 배짱이 아니다. 그냥 사고 초대장이다.

• “무엇을 하지 말아야 하는지”를 명시한다. 성능 개선 중 public API 변경 금지, 테스트 통과를 위한 assertion 삭제 금지, 문서 변환 중 기술 내용 변경 금지, 마이그레이션 중 특정 디렉터리 제외 같은 제약이 필요하다. 에이전트는 목표를 달성하려고 하므로 우회로를 막아야 한다.

• 실패 보고 형식을 정한다. 목표를 달성하지 못하면 “어디에서 막혔는지, 어떤 시도를 했는지, 마지막으로 통과한 검증은 무엇인지, 사람이 결정해야 할 사항은 무엇인지”를 남기게 한다. 실패도 잘 기록되면 다음 실행의 입력이 된다.

• 작은 목표부터 반복한다. 처음부터 “전체 앱을 현대화해라” 같은 목표를 주기보다 “인증 모듈의 테스트 실패 3개를 고쳐라”, “이 패키지 하나를 새 API로 마이그레이션해라”처럼 닫힌 범위를 선택한다. Goal 모드는 넓은 자유보다 좁은 성공 조건에서 먼저 빛난다.

읽기 우선순위

이 글은 Codex나 Claude Code 같은 코딩 에이전트를 이미 실무에 써보고 있고, 이제 더 긴 작업을 맡겨보고 싶은 개발자에게 우선 추천한다. 특히 “에이전트가 짧은 수정은 잘하는데 큰 작업에서는 자꾸 산만해진다”고 느꼈다면 원문을 읽어볼 가치가 크다. 문제의 절반은 모델 성능이 아니라 목표 정의와 검증 루프에 있을 가능성이 높다.

시간이 없다면 원문 전체를 다 읽기보다 Goal 작성 방식과 사례 부분을 먼저 보면 된다. 핵심은 기능 이름이 아니라 패턴이다. 명확한 목표, 빠른 검증, 감사 가능한 로그, 제약 조건, 실패 시 보고. 이 다섯 가지를 갖춘 작업은 에이전트에게 점점 더 잘 위임할 수 있다.

반대로 아직 코딩 에이전트를 거의 쓰지 않는 독자라면 원문을 최신 도구 소개라기보다 미래의 업무 설계 힌트로 읽으면 좋다. 앞으로 AI 도구를 잘 쓰는 사람은 “AI에게 많이 시키는 사람”이 아니라 “AI가 끝낼 수 있는 형태로 일을 재정의하는 사람”에 가까워질 것이다. Goal 모드는 그 방향을 꽤 선명하게 보여준다.