Codex 대화 되감기와 파일 복구: 프롬프트 수정부터 변경 취소까지

Codex 대화 되감기는 대화 기록만 되돌립니다. 이미 수정된 파일까지 이전 상태로 복구해 주지는 않아요. 그래서 되감기 전에 지금 하려는 일이 '이전 프롬프트 수정'인지 '잘못 수정한 코드 복구'인지부터 나눠 보시길 권합니다. 코드를 되돌리는 게 목적이라면 파일 변경 취소를 따로 진행해야 합니다.

근거는 공식 App Server 문서에 있습니다. 문서에 따르면 thread/revert는 지정한 턴과 그 이후의 대화 기록을 제거하지만 로컬 파일은 변경하지 않아요. 턴은 대화가 한 차례 오가는 단위를 말합니다. 그래서 화면에서는 요청을 취소한 것처럼 대화가 정리돼도, 그 요청으로 바뀐 코드는 디스크에 그대로 남아 있을 수 있습니다.

지난 대화를 다시 열었는데 왜 코드는 그대로일까

/resume은 저장된 대화를 다시 여는 명령입니다. 당시 나눈 설명과 작업 맥락은 이어지지만, 파일까지 그 시점으로 돌려놓지는 않아요. 재개한 작업에서 파일을 읽는 기준은 현재 작업 트리, 곧 지금 디스크에 있는 파일 상태입니다. 대화에 남아 있는 과거 코드와 실제 파일 내용이 어긋날 수 있는 이유가 여기에 있어요.

흔히 헷갈리는 지점이 하나 더 있습니다. 대화 API의 thread/revert와 앱 리뷰 패널의 변경 취소는 다루는 대상이 다릅니다. thread/revert는 대화 기록을, 변경 취소는 작업 파일의 변경을 다뤄요. thread/revert 사양은 영속적으로 저장되고 페이지 단위로 조회되는 대화 기록에 적용되고, 임시 대화나 기존 방식의 기록은 지원 대상에서 빠져 있습니다. 그러니 이 API 설명만 보고 앱이나 IDE에 보이는 모든 Revert 버튼의 동작을 판단하지 않는 편이 안전합니다.

프롬프트를 고칠지, 파일 변경을 되돌릴지

원본 대화를 남겨 둔 채 다른 접근을 시도하고 싶다면 /fork부터 고르시길 권합니다. 저장된 대화를 이어 가는 /resume과 달리, /fork는 원본 기록을 유지한 채 새 대화로 복제해요. 다만 대화를 분기하는 것과 파일 작업 공간을 분리하는 것은 별개입니다. 파일도 따로 두고 싶다면 제공되는 작업 공간 선택 옵션을 확인해 보세요.

이전 프롬프트를 편집하려면 CLI 입력창을 비운 상태에서 Esc를 두 번 누릅니다. 이 단축키를 쓰는 것과 원본 대화가 보존되는지는 따로 봐야 해요. CLI 명령어 문서는 해당 지점에서 대화를 분기한다고 설명합니다. 반면 2026년 9월 22일 공개된 CLI 0.156.0 변경 기록에는 스레드 식별자와 설정을 유지하며 현재 대화를 되돌리는 동작이 명시돼 있어요. 설치한 버전이 실제로 어떻게 처리하는지 확인해 두시고, 원본 보존이 중요하다면 편집 전에 명시적으로 /fork를 쓰는 쪽이 낫습니다.

코드를 되돌릴 때는 취소 버튼을 누르기 전에 현재 diff, 즉 파일의 변경 내역부터 보세요.

Git 저장소를 쓰는 앱의 리뷰 패널에는 Codex가 만든 수정뿐 아니라 사용자가 직접 만들고 아직 커밋하지 않은 변경도 함께 표시됩니다. 필요한 수정까지 지워 버리지 않으려면 아래 순서로 취소 범위를 좁혀 가는 게 좋아요.

1. 현재 diff의 비교 범위를 확인하고, 유지해야 할 사용자 수정이 섞여 있는지 살펴봅니다.
2. 되돌릴 부분을 파일 또는 hunk 단위로 골라 취소합니다. hunk는 diff에서 한 덩어리로 묶여 표시되는 변경 단위예요.
3. 취소한 뒤에는 Codex에 현재 파일을 다시 읽고 남은 변경을 확인하도록 요청하고 나서 작업을 이어 갑니다.

전체 변경 취소도 지원하지만, 문제가 일부 수정에만 있다면 파일이나 hunk 단위부터 손대는 편이 맞습니다. 대화까지 되감았다면 이 부분을 더 신경 써야 해요. 과거 대화의 설명과 현재 코드가 서로 맞지 않을 수 있기 때문입니다. 다시 요청하기 전에 현재 파일 상태부터 읽히라고 권하는 것도 그래서입니다.