OpenAI의 Codex CLI 0.128.0에 /goal이 추가됐다. 표면적으로는 새 슬래시 명령 하나지만, 실제 변화는 더 크다. 이제 Codex는 한 번 답하고 끝나는 도우미라기보다, 목표를 붙잡고 계속 일하는 루프형 작업자로 움직이기 시작했다.12
왜 지금 이게 중요할까. 터미널 AI 도구를 볼 때 기준이 바뀌기 때문이다. 예전엔 "프롬프트를 얼마나 잘 치느냐"가 핵심이었다면, 이제는 "어떤 목표를 맡길 것인지, 어디까지 권한을 줄 것인지, 언제 멈추게 할 것인지"가 더 중요해진다.
/goal이 바꾼 것: 요청 처리에서 목표 지속으로
확인된 사실부터 보자. 0.128.0 릴리스에는 persisted /goal workflows가 들어갔다. 앱 서버 API, 런타임 continuation, 그리고 TUI에서 생성·일시정지·재개·삭제를 다루는 제어까지 포함된다.1 Simon Willison이 짚었듯 이 기능은 예산이 소진되거나 목표를 달성했다고 판단할 때까지 반복 실행하는 구조에 가깝다.2
이 차이는 작지 않다.
기존 CLI 에이전트 사용법은 대체로 "이 파일 고쳐줘", "테스트 추가해줘" 같은 단발성 요청 중심이었다. 반면 /goal은 "이 버그를 재현하고, 원인을 찾고, 테스트까지 통과시켜라"처럼 더 넓은 작업 단위를 유지하게 만든다. 게다가 중간에 끊겨도 다시 이어갈 수 있다.1
실무적으로는 세 가지가 달라진다.
첫째, 작업의 단위가 커진다. 프롬프트 한 번이 아니라 작은 업무 묶음 하나를 맡기는 방식이 된다.
둘째, 평가 기준도 달라진다. "답변이 그럴듯한가"보다 "목표를 달성했는가, 중간 판단이 합리적이었는가"를 보게 된다.
셋째, 운영 감각이 필요해진다. 이런 도구는 이제 자동완성보다 인턴이나 주니어 오퍼레이터에 가깝다. 시키는 일은 하지만, 범위와 종료 조건을 명확히 안 주면 엉뚱한 데서 시간을 쓸 수 있다.
이런 일엔 잘 맞고, 이런 일엔 아직 과하다
그렇다고 /goal이 모든 개발 업무에 바로 맞는 건 아니다.
잘 맞는 쪽은 반복적이고 검증 가능한 일이다. 예를 들면 재현 가능한 버그 추적, 여러 파일에 걸친 기계적 리팩터링, 깨진 테스트 복구, 저장소 탐색 후 관련 파일 묶어내기 같은 일이다. 이런 작업은 중간에 명령 실행, 파일 수정, 테스트 재실행이 이어지기 때문에 루프형 에이전트의 장점이 살아난다.
반대로 애매한 요구사항이 섞인 아키텍처 변경, 제품 의도가 불명확한 기능 수정, 보안 민감 영역 수정은 아직 사람의 밀착 조종이 더 낫다. 목표를 오래 붙잡는 에이전트일수록, 애초에 목표 정의가 모호하면 잘못된 방향으로 성실하게 달려갈 위험도 커진다.
여기서 반론도 가능하다. "어차피 좋은 에이전트면 알아서 판단해야 하는 것 아닌가?" 하지만 이번 릴리스 노트를 보면 OpenAI도 방향을 다르게 잡고 있다. --full-auto는 deprecated 처리하고, 대신 명시적 permission profile과 trust flow 쪽으로 유도하고 있다.1 즉, 핵심은 무제한 자율성이 아니라 관리 가능한 자율성이라는 뜻이다.
성공을 가르는 건 /goal보다 권한·샌드박스·예산이다
이번 버전에서 더 실무적인 부분은 오히려 화려하지 않은 항목들이다. 내장 기본값이 있는 permission profiles, 샌드박스 CLI 프로필 선택, cwd 제어, 활성 프로필 메타데이터가 확장됐다.1 업데이트 명령(codex update)이나 키맵 설정보다, 이런 제어 계층이 장기 실행 에이전트에는 더 중요하다.
이유는 간단하다. 목표 기반 루프가 길어질수록 실패 비용도 커진다.
권한은 blast radius를 정한다. 어디까지 읽고 쓰고 실행할 수 있는지.
샌드박스는 경계선을 정한다. 실수했을 때 피해가 작업 디렉터리 안에 머무는지.
토큰 예산은 비용과 집착 시간을 정한다. 목표를 못 풀고 같은 주변을 맴돌 때 어디서 끊을지.
그래서 도입 판단도 기능 데모보다 운영 규칙에서 시작해야 한다. 개인 개발자라면 "이 워크스페이스에서만 쓰기 가능, 테스트 명령만 허용, 예산 상한 설정" 정도가 기본선이다. 팀이라면 여기에 저장소별 프로필, 네트워크 허용 범위, 리뷰 전 병합 금지 같은 룰이 붙어야 한다.
지금 도입한다면, 전체 프로세스 말고 한 가지 워크플로만 맡겨라
Codex CLI 0.128.0은 분명 흥미로운 릴리스다. 하지만 이걸 "이제 AI가 내 개발을 대신한다"는 신호로 읽으면 과장이다. 더 정확한 해석은 이렇다. 터미널 AI가 이제 짧은 응답 도구에서, 제한된 목표를 들고 반복 실행하는 작업자로 넘어가기 시작했다.
그래서 도입도 작게 해야 한다. 하나의 좁은 업무를 고른다. 예를 들어 "깨진 테스트 5개 복구"처럼 측정 가능한 목표를 준다. 권한 프로필을 최소로 잡고, 토큰 예산 상한을 둔다. 결과물은 반드시 사람이 리뷰한다. 그다음에만 더 넓은 역할을 허용한다.
지금 이 업데이트를 가장 주의 깊게 봐야 하는 사람은 AI 코딩 도구를 이미 쓰고 있지만, 아직도 프롬프트 품질 중심으로만 평가하는 개발자와 팀 리드다. 0.128.0의 진짜 질문은 새 명령이 편한가가 아니다. 당신의 개발 환경이 이제 "에이전트를 어떻게 관리할 것인가"를 물을 준비가 되어 있느냐는 쪽에 가깝다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.