AI타임스에서 “오픈AI 버전 랄프 루프”라는 표현으로 Codex CLI의 새 기능을 다뤘다. 제목만 보면 조금 과장된 뉴스처럼 보일 수 있는데, 공식 자료를 다시 확인해보니 그냥 가볍게 넘길 업데이트는 아니었다.
OpenAI가 2026년 4월 30일 공개한 Codex CLI 0.128.0에는 persisted /goal workflows가 들어갔다. 쉽게 말하면 Codex에게 “이번 답변에서 이거 해줘”라고 말하는 대신, 스레드에 목표를 걸어두고 그 목표를 이어서 추적하게 만드는 기능이다.
이건 자동완성 기능이 조금 좋아진 정도가 아니다. AI 코딩 도구가 점점 “대화형 도우미”에서 “작업을 계속 붙잡는 에이전트” 쪽으로 이동하고 있다는 신호에 가깝다.
공식 자료로 확인한 내용
먼저 버전부터 확인했다.
2026년 5월 3일 기준 NPM의 @openai/codex 최신 안정 버전은 0.128.0이고, GitHub 릴리스 태그는 rust-v0.128.0이다. GitHub 릴리스의 공개 시각은 2026년 4월 30일 16:40:28 UTC로 확인된다.
OpenAI Codex changelog의 0.128.0 항목은 새 기능으로 이렇게 정리한다.
- persisted
/goalworkflows 추가 - app-server API 추가
- 모델 도구 추가
- runtime continuation 추가
- TUI에서 create, pause, resume, clear 조작 추가
NPM에는 안정 채널 latest가 0.128.0으로 올라와 있고, 별도로 alpha 채널에는 0.129.0-alpha.2가 보인다. 그러니 지금 일반 사용자가 업데이트해서 보는 기준은 0.128.0으로 보는 게 맞다.
npm install -g @openai/codex@0.128.0
또 OpenAI 공식 CLI 문서는 Codex CLI를 “로컬 터미널에서 실행되는 코딩 에이전트”로 설명한다. 로컬 디렉터리의 코드를 읽고, 수정하고, 명령을 실행할 수 있는 도구라는 점도 그대로다. /goal은 이 흐름 위에 “작업 목표를 지속시키는 레이어”가 하나 더 붙은 셈이다.
/goal은 정확히 무엇을 하나
소스까지 보면 기능의 윤곽이 더 분명하다.
Codex의 app-server에는 thread/goal/set, thread/goal/get, thread/goal/clear API가 추가되어 있다. 목표는 스레드에 하나씩 저장되고, 새 objective를 넣으면 기존 목표를 대체하면서 사용량 집계를 다시 시작한다. 같은 목표라면 status나 token budget을 업데이트할 수 있다.
TUI 쪽에서는 사용자가 이런 식으로 목표를 설정한다.
/goal improve benchmark coverage
이미 목표가 있으면 교체할지 묻고, /goal pause, /goal resume, /goal clear 같은 제어도 들어간다. 화면 하단에는 목표 진행 상태가 표시된다. 소스의 footer 문구를 보면 active 상태에서는 “Pursuing goal”로 표현된다.
흥미로운 부분은 모델에게도 goal 관련 도구가 노출된다는 점이다. get_goal, create_goal, update_goal 도구가 있고, update_goal은 목표가 실제로 끝났을 때 complete로 표시하는 용도로 제한되어 있다. 즉 “목표를 세우고, 계속 확인하고, 끝났을 때 완료 처리하는” 루프가 제품 구조 안으로 들어왔다.
“랄프 루프”라는 표현을 어떻게 봐야 하나
기사 제목의 “랄프 루프”는 공식 기능명이라기보다는, 이 구조를 설명하기 위한 별칭에 가깝다. 공식 문서와 릴리스 노트에서 확인되는 이름은 Goals, persisted /goal workflows, runtime continuation 쪽이다.
다만 표현 자체가 가리키는 방향은 꽤 정확하다. 기존 AI 코딩 도구는 보통 이런 흐름이었다.
요청 → 답변 또는 수정 → 사용자가 다시 지시 → 다음 수정
/goal이 들어오면 흐름이 조금 달라진다.
목표 설정 → 현재 상태 확인 → 다음 행동 선택 → 검증 → 부족하면 계속 진행 → 완료 판단
물론 이게 곧바로 “혼자 알아서 모든 개발을 끝내는 AI”라는 뜻은 아니다. 공식 소스에서도 목표 기능은 experimental feature로 잡혀 있고, 기본값은 비활성화되어 있다. 과장해서 받아들이면 안 된다.
그래도 방향은 분명하다. 앞으로 코딩 에이전트는 사용자가 매번 다음 명령을 넣어주는 방식보다, 사용자가 목표와 종료 조건을 주고 에이전트가 중간 과정을 이어가는 방식으로 더 많이 설계될 가능성이 크다.
개발자가 체감할 만한 변화
내가 보기에는 이 기능이 바로 빛나는 작업이 따로 있다. 짧은 함수 하나를 고치는 일보다, 여러 번 확인하고 되돌아봐야 하는 일에서 의미가 크다.
예를 들면 이런 작업이다.
- 테스트 커버리지를 특정 수준까지 올리기
- 린트 오류를 줄이되 동작은 바꾸지 않기
- 오래된 API 호출을 새 API로 점진적으로 옮기기
- 문서와 코드가 서로 어긋난 부분을 계속 찾아 고치기
- flaky test를 재현하고 원인 후보를 좁히기
이런 작업은 한 번의 프롬프트로 끝나기 어렵다. 중간에 테스트가 깨지고, 생각보다 관련 파일이 많고, 일부 수정은 되돌려야 할 수도 있다. 그래서 지금까지는 사용자가 계속 옆에서 “다음엔 이거 봐”, “테스트 다시 돌려”, “아니 그 파일 말고 여기도 봐”라고 붙잡아줘야 했다.
/goal은 그 babysitting 비용을 줄이려는 시도다. 사용자가 세부 절차를 계속 입력하기보다, 목표를 걸어두고 Codex가 다음 행동을 선택하게 만든다.
그래도 조심해야 할 지점
이 기능은 편해 보이지만, 위험도 같이 커진다. 목표를 오래 붙잡는다는 건 그만큼 파일을 더 많이 읽고, 더 많이 고치고, 더 많은 명령을 실행할 수 있다는 뜻이기 때문이다.
그래서 /goal을 쓸 때는 목표를 넓게 던지는 것보다 경계를 같이 주는 편이 낫다.
/goal 로그인 실패 원인을 찾아 고친다. 인증 로직의 공개 API는 바꾸지 말고, 수정 후 관련 테스트와 빌드를 실행한다.
이 정도면 목표, 금지선, 검증 기준이 같이 들어간다.
반대로 이런 요청은 위험하다.
/goal 이 프로젝트를 알아서 개선해줘
너무 넓다. Codex가 뭔가를 하긴 하겠지만, 사용자가 원하는 결과와 멀어질 가능성이 크다. 에이전트가 자율적으로 움직일수록 “무엇을 하면 안 되는지”가 더 중요해진다.
내가 실제로 쓴다면 이렇게 쓸 것 같다
나는 /goal을 큰 기능 개발보다는 반복 검증이 필요한 작업에 먼저 붙일 것 같다.
/goal Astro 블로그의 콘텐츠 품질 오류를 줄인다. 새 글은 건드리지 말고, 기존 글의 frontmatter 오류와 깨진 이미지 경로만 찾아 수정한다. 수정 후 npm run check:content와 npm run build를 통과시킨다.
또는 이런 식이다.
/goal 최근 실패한 테스트를 재현하고 원인을 좁힌다. 프로덕션 코드는 최소 변경으로만 수정하고, 실패 로그와 수정 근거를 마지막에 남긴다.
이런 요청은 Codex가 오래 붙잡을수록 가치가 생긴다. 단순히 코드를 생성하는 게 아니라, 확인하고, 고치고, 다시 확인하는 흐름이 필요하기 때문이다.
이 업데이트가 말해주는 방향
Codex CLI 0.128.0의 /goal은 아직 실험 기능이다. 그래서 “이제 개발자가 필요 없다” 같은 식으로 읽으면 틀렸다. 오히려 반대에 가깝다. 목표를 잘 쪼개고, 권한을 적절히 제한하고, 완료 기준을 분명히 주는 개발자의 역할이 더 중요해진다.
다만 한 가지는 확실해 보인다.
AI 코딩 도구의 경쟁은 이제 “누가 코드를 더 그럴듯하게 쓰나”에서 “누가 작업을 더 오래, 더 안전하게, 더 검증 가능하게 이어가나”로 옮겨가고 있다.
/goal은 그 변화를 꽤 노골적으로 보여주는 기능이다. 아직은 실험적이지만, 코딩 에이전트를 자주 쓰는 사람이라면 그냥 뉴스 하나로 넘기기보다 실제 워크플로에 어떻게 끼워 넣을지 생각해볼 만하다.
참고한 자료
'개발자 정보' 카테고리의 다른 글
| Codex CLI를 로컬 개발 루틴에 넣기 전 정해야 할 운영 기준 (0) | 2026.05.06 |
|---|---|
| 리튬 배터리팩을 직접 만질 때 먼저 봐야 하는 것들 (0) | 2026.05.05 |
| 라즈베리파이5 AI Kit와 AI HAT+ 2, 로컬 LLM과 비전 AI는 어디까지 될까 (1) | 2026.05.03 |
| N150 미니PC는 2026년에 아직 살 만한가 (0) | 2026.05.02 |
| GPT-5.5 실전 프롬프트 가이드: 개발자가 바로 쓰는 요청 방식 (0) | 2026.05.01 |