Codex의 진짜 변화, 이미지는 첨부가 아니라 작업 루프다

AI 코딩에서 스크린샷은 자주 애매한 존재가 된다.

처음에는 분명 도움이 된다. 화면을 보여주고 “여기 버튼 간격 이상해”라고 말하면 에이전트가 꽤 그럴듯하게 고친다. 그런데 다음 턴부터 문제가 생긴다. “방금 그 이미지”, “아까 그 화면”, “수정 전 상태” 같은 말이 대화 안에서 흐려진다.

그래서 이번 OpenAI Codex CLI 릴리즈에서 내가 주목한 건 거창한 이미지 성능 발표가 아니다. 최근 0.138 업데이트에서 Codex CLI는 로컬 이미지 첨부와 standalone image generation 결과의 저장 경로를 모델이 볼 수 있게 바꿨다.

내가 보기엔 이 변화의 핵심은 단순하다. 이미지를 한 번 보고 버리는 첨부파일에서, 다시 참조할 수 있는 작업 기준으로 바꾸는 것이다.

릴리스 노트의 문장은 짧다.

Local image attachments and standalone image generations now expose their saved file paths to the model.

이 말은 “Codex가 이미지를 갑자기 더 똑똑하게 본다”는 뜻이 아니다. 로컬 이미지 첨부와 생성 이미지 결과가 어디에 저장됐는지, 그 파일 경로를 작업 맥락 안에서 모델이 볼 수 있게 됐다는 뜻이다. 작아 보이지만, 실제 워크플로우에서는 이 차이가 꽤 크다.

이미지가 경로를 갖는 순간, 그 이미지는 대화 속 임시 자료가 아니라 프로젝트 안의 artifact가 된다. 코드는 Git에 남고, 테스트는 CI 로그에 남고, 문서는 README에 남는다. 이제 스크린샷도 그 루프 안에 들어올 수 있다.

진짜 변화는 이미지 인식이 아니라 참조점이다

이번 업데이트를 과장해서 읽으면 안 된다. 이미지 판독 정확도가 올라갔다거나, 이미지 생성 품질이 개선됐다는 발표가 아니다. 핵심은 더 실무적이다.

에이전트가 “이미지 하나를 봤다”에서 멈추지 않고, “프로젝트 안의 이 파일을 기준으로 봤다”에 가까워진다.

예를 들어 로그인 화면 스크린샷을 첨부했다고 하자. 예전에는 대화가 길어질수록 기준이 흐려졌다.

아까 첨부한 로그인 화면 기준으로 다시 맞춰줘.

사람은 대충 알아듣지만, 에이전트 작업에서는 이 말이 약하다. 어떤 이미지인지, 프로젝트 안에 남아 있는지, 다음 세션에서도 다시 볼 수 있는지 불명확하다.

반대로 파일 경로가 있으면 말이 달라진다.

assets/visual-feedback/2026-06-09-login-before.png를 기준으로
현재 로그인 화면의 버튼 간격과 에러 메시지 위치를 맞춰줘.
수정 후 변경한 컴포넌트와 CSS 파일을 요약해줘.

이제 스크린샷은 “참고 이미지”가 아니라 수정 기준이 된다. 나는 이 지점이 중요하다고 본다.

스크린샷을 다운로드 폴더에 버려두면 루프가 끊긴다

AI 코딩에서 삽질이 생기는 지점은 프롬프트가 짧아서만이 아니다. 작업 기준이 프로젝트 밖에 흩어질 때도 많이 끊긴다.

스크린샷은 다운로드 폴더에 있고, 수정 내용은 코드에 있고, 피드백은 디스코드나 메신저에 있고, 최종 판단은 사람 머릿속에 남아 있다. 이 상태에서 에이전트에게 “아까처럼 고쳐줘”라고 하면 매번 다시 설명해야 한다.

그래서 나는 비주얼 피드백을 이렇게 봐야 한다고 생각한다.

나쁜 루프:
스크린샷 첨부 → 대충 수정 → 다시 설명 → 또 수정

좋은 루프:
기준 이미지 저장 → 경로로 지시 → 코드 수정 → after 이미지 저장 → 다시 비교 → 문서 기록

핵심은 이미지 자체가 아니다. 이미지가 코드, 테스트, 문서와 같은 작업 단위 안에 남는 것이다.

내가 쓴다면 visual-feedback 폴더부터 만든다

Codex CLI 0.138을 쓸 때 내가 먼저 만들 구조는 복잡하지 않다.

project/
  assets/
    visual-feedback/
      2026-06-09-login-before.png
      2026-06-09-login-after-01.png
      2026-06-09-login-after-02.png
  docs/
    visual-feedback.md

먼저 버전을 확인한다.

codex --version

0.138.0 이상인지 확인한 뒤, 프로젝트 안에 스크린샷을 저장할 폴더를 만든다.

mkdir -p assets/visual-feedback docs

파일명은 대충 짓지 않는 편이 좋다. 날짜, 화면, 상태가 들어가야 다음에 다시 봐도 의미가 남는다.

2026-06-09-login-before.png
2026-06-09-login-after-01.png
2026-06-09-login-after-02.png

여기서 `before`와 `after`가 중요하다. AI에게 “이쁘게 고쳐줘”라고 말하는 것보다, 기준 이미지와 결과 이미지를 비교하게 만드는 쪽이 훨씬 안정적이다.

프롬프트는 길게 쓰는 게 아니라 기준을 고정해야 한다

이 기능을 제대로 쓰려면 프롬프트도 조금 달라져야 한다. 감상평을 부탁하는 식이면 효과가 작다.

내가 넣는 최소 기준은 네 가지다.

1. 기준 이미지 경로
2. 현재 결과 이미지 경로
3. 수정해야 할 코드 범위
4. 변경 후 기록할 문서 위치

예시는 이렇게 쓸 수 있다.

기준 이미지: assets/visual-feedback/2026-06-09-login-before.png
현재 결과: assets/visual-feedback/2026-06-09-login-after-01.png
수정 범위: src/components/LoginForm.tsx, src/styles/login.css
기록 위치: docs/visual-feedback.md

두 이미지를 비교해서 레이아웃 차이를 줄여줘.
특히 입력창 간격, 버튼 정렬, 에러 메시지 위치를 봐줘.
수정 후 실행해야 할 테스트 명령도 같이 알려줘.

이렇게 쓰면 Codex가 해야 할 일이 더 명확해진다. 이미지를 보는 일, 코드를 고치는 일, 검증을 남기는 일이 한 작업으로 묶인다.

수정 후에는 after 이미지를 다시 저장하고, 다시 비교한다.

assets/visual-feedback/2026-06-09-login-before.png와
assets/visual-feedback/2026-06-09-login-after-01.png를 비교해서
아직 남은 UI 차이를 정리해줘.

코드로 바로 고칠 수 있는 항목은 수정하고,
디자인 의사결정이 필요한 항목은 docs/visual-feedback.md에 질문으로 남겨줘.

이게 내가 말하는 비주얼 피드백 루프다. 한 번 보고 끝나는 이미지 첨부가 아니라, 기준 이미지와 결과 이미지를 계속 물려가며 줄이는 방식이다.

생성 이미지도 “만들었다”에서 끝나면 아깝다

Codex CLI 0.138의 변경에는 standalone image generation 결과의 저장 경로 hint도 포함된다. 이것도 핵심은 생성 품질이 아니다. 재사용성이다.

예를 들어 README에 넣을 구조도, 블로그 본문 이미지, empty state 일러스트를 생성했다고 하자. 생성된 이미지가 대화 안에서만 소비되면 한 번 쓰고 사라진다. 하지만 파일 경로가 작업 맥락에 들어오면 다음 작업으로 이어진다.

방금 생성된 이미지 파일 경로를 기준으로
README.md에 이미지 삽입 섹션을 작성해줘.
alt text를 추가하고,
docs/assets.md에 사용 목적과 생성 날짜를 기록해줘.

또는 이렇게도 가능하다.

생성된 이미지의 저장 경로를 기준으로
블로그 본문에서 사용할 캡션 3개를 제안해줘.
파일명도 글 slug에 맞게 바꾸는 명령을 제안해줘.

여기서도 중요한 건 “AI가 이미지를 만들 수 있다”가 아니다. 만든 이미지가 문서, 코드, 블로그, PR 설명으로 이어질 수 있느냐다.

조심할 점은 분명히 있다

경로가 보인다고 해서 모든 문제가 해결되는 건 아니다. 여기서 선을 잘못 넘으면 또 다른 삽질이 생긴다.

첫째, 경로가 모델에 보인다는 것과 파일 접근 권한이 있다는 것은 다르다. 실제 접근 가능 범위는 Codex CLI 설정, sandbox 정책, 작업 디렉터리, 권한에 따라 달라질 수 있다.

둘째, 이미지 이해 성능을 보장하지 않는다. 경로 연결성이 좋아진 것이지, UI 차이를 항상 정확히 판독한다는 뜻은 아니다. 중요한 화면은 사람이 마지막에 봐야 하고, 가능하면 스냅샷 테스트나 E2E 테스트로 보강해야 한다.

셋째, 민감한 스크린샷은 조심해야 한다. 관리자 화면, 고객 정보, 토큰, 이메일 주소, 내부 경로가 들어간 이미지를 그대로 첨부하면 보안 문제가 된다. 필요하면 마스킹한 이미지를 따로 만들어야 한다.

넷째, standalone image generation은 계정, 모델, 정책, 실행 환경에 따라 안 보일 수 있다. 기능이 없으면 억지로 생성 이미지 루프부터 만들 필요 없다. 기존 스크린샷 첨부 기반 루프부터 잡는 게 더 현실적이다.

이번 릴리즈에서 가져가야 할 습관

이번 Codex CLI 0.138 릴리즈의 핵심은 “Codex CLI가 이미지를 지원한다”가 아니다. 이미지는 이미 여러 도구에서 볼 수 있다.

내가 가져가야 할 습관은 이거다.

이미지를 대화에 붙이지 말고, 프로젝트에 남겨라.
그리고 그 경로를 기준으로 AI에게 일을 시켜라.

앞으로 AI 코딩 워크플로우에서 중요한 건 프롬프트 한 줄이 아니라 작업 기준을 얼마나 안정적으로 남기느냐다. 코드만 artifact가 아니다. 스크린샷, 생성 이미지, 에러 캡처, before/after 비교 이미지도 전부 artifact다.

Codex CLI 0.138은 그 방향을 보여주는 작은 신호다. 이미지를 한 번 쓰고 버리지 말고, 파일 경로로 묶어서 다음 수정과 다음 비교까지 살아남게 만드는 것. 이 습관 하나만 잡아도 UI 수정, 문서화, PR 설명에서 반복 삽질이 꽤 줄어든다.

참고자료

• OpenAI Codex CLI 0.138.0 Release Notes — 로컬 이미지 첨부와 standalone image generation 저장 경로 노출 문구
• PR #25944: Expose local image paths to models — 로컬 이미지 첨부 source path 노출 변경
• PR #25947: Add saved image path hint to standalone image generation — 생성 이미지 저장 경로 hint 추가
• OpenAI Codex README — Codex CLI와 로컬 코딩 에이전트 배경
• OpenAI Codex CLI Documentation — Codex CLI 공식 문서