Codex 변경 사항 검토하기: diff와 실행 결과를 함께 확인

Codex가 기능을 고치고 “수정 완료”라고 알려 주었을 때, 가장 먼저 볼 것은 실제 파일의 차이입니다. 결과 요약은 변경 목적을 이해하는 데 도움이 되지만 무엇이 추가되고 사라졌는지는 diff에서 확인해야 합니다. 파일이 몇 개 바뀌었는지, 원래 문제와 관계없는 코드도 바뀌었는지, 확인한 테스트가 어느 범위를 다루는지 함께 읽으면 결과를 받아들이기 쉽습니다. 이 글은 코드 리뷰를 맡기는 일반적인 요청보다 실제 변경을 인수하는 순간의 확인 순서에 초점을 맞춥니다.

비교 대상이 무엇인지 먼저 확인하기

diff는 두 상태의 차이입니다. 작업 폴더와 스테이징 영역을 비교할 수도 있고, 두 커밋이나 브랜치를 비교할 수도 있습니다. 같은 “변경 보기” 화면이어도 기준이 달라지면 나타나는 파일이 달라집니다. OpenAI의 공식 리뷰 안내에서는 리뷰 화면이 저장소의 현재 변경 상태를 반영하며, Codex 외의 변경도 포함될 수 있다고 설명합니다. 따라서 화면에 보이는 파일을 모두 이번 AI 작업의 결과라고 단정하지 않습니다. 어떤 기준 상태와 현재 상태를 비교하는지 먼저 읽어야 합니다.

터미널을 사용하는 경우 Git의 읽기 전용 명령으로 범위를 나눠 볼 수 있습니다. 설명용으로 git diff는 아직 스테이징되지 않은 변경을, git diff --staged는 스테이징된 변경을 확인하는 데 사용합니다. git diff HEAD는 마지막 커밋을 기준으로 작업 폴더의 추적된 변경을 볼 때 사용할 수 있습니다. 이 글의 명령은 개인 저장소에서 실행한 결과가 아니라 확인 방법을 설명하는 예시입니다. 새로 만든 추적되지 않은 파일은 별도로 상태 목록을 확인해야 한다는 점도 기억하세요.

파일 목록에서 예상 범위와 비교하기

설명용 업무가 “설정 화면의 옵션 저장 오류 수정”이라고 가정해 봅시다. 설정 화면, 저장 함수, 관련 테스트가 바뀌는 것은 자연스럽습니다. 반면 로그인 권한 설정, 전체 스타일 파일, 패키지 버전까지 바뀌었다면 변경 이유를 확인해야 합니다. 관련 없는 파일이 포함되었다고 해서 무조건 잘못된 것은 아닙니다. 원래 문제를 해결하기 위해 공통 함수가 바뀌었을 수 있습니다. 다만 관계를 설명할 수 있어야 검토 범위를 정할 수 있습니다.

파일 이름만으로 역할을 판단하지 말고 변경 목적을 적어 달라고 요청합니다. “각 변경 파일을 문제 해결에 직접 필요한 변경, 검증용 변경, 그 밖의 변경으로 분류하고 이유를 알려 줘”라고 쓸 수 있습니다. 단순 서식 정리가 많은 경우에는 실제 동작을 바꾸는 줄이 묻힐 수 있습니다. 기능 수정과 서식 변경을 분리할 수 있는지 확인하면 다음 검토가 쉬워집니다. 사용자가 이미 수정한 파일은 그 목적을 읽고 이번 결과와 함께 대조해야 합니다.

확인할 변화	읽을 질문	필요한 검증
조건문 수정	새 조건이 어떤 입력을 다르게 처리하나	정상·빈값·경계 입력 비교
함수 이름 변경	호출하는 다른 파일도 바뀌었나	호출 지점과 빌드 확인
기본값 변경	기존 사용자 설정에 영향을 주나	저장된 자료와 새 자료 비교
패키지 변경	이 수정에 필요한 변경인가	호환성·설치·잠금 파일 확인
테스트 추가	원래 오류를 실제로 재현하나	수정 전 실패와 수정 후 결과 확인

빨간 줄과 초록 줄을 함께 읽기

추가된 코드만 보면 이전에 보장하던 동작이 사라졌는지 알기 어렵습니다. 삭제된 줄의 역할과 새 줄이 그 역할을 어떻게 이어받는지 함께 읽어야 합니다. diff의 문맥 줄은 바뀌지 않은 주변 코드를 보여 줍니다. 문맥이 충분하지 않으면 원본 파일과 해당 함수 전체를 열어 읽으세요. 조건문을 한 줄 바꿨더라도 그 앞에서 값이 변환되거나 그 뒤에서 예외 처리가 이루어질 수 있습니다. 변경 줄의 개수는 영향 범위를 대신하지 않습니다.

예를 들어 가상의 JavaScript 코드에서 if (!value)를 값이 없을 때의 기본값 처리로 사용했다고 합시다. 이 조건은 false나 0도 기본값으로 처리할 수 있습니다. 이를 null과 undefined만 확인하는 조건으로 바꾸면 false와 0은 보존됩니다. 이 변경이 좋은지는 실제 요구사항에 달려 있습니다. “꺼짐”을 뜻하는 false를 사용자가 선택할 수 있다면 보존이 필요할 수 있지만, 빈 문자열도 없는 값으로 취급해야 한다면 추가 조건을 논의해야 합니다. 코드가 짧아졌다는 이유만으로 맞다고 판단하지 않습니다.

입력별 전후 결과 표 만들기

변경된 조건을 검토할 때는 정상값 하나만 넣는 것보다 서로 다른 입력을 나눠 보는 편이 좋습니다. 가상의 옵션 저장 코드에서는 true, false, 0, 빈 문자열, null, undefined가 무엇을 뜻하는지 정합니다. 이 표는 실제 제품에서 사용한 값이 아니라 검토 방법을 설명하는 예시입니다. 값의 의미를 먼저 정해야 이전 코드와 새 코드의 결과 중 어느 쪽이 요구사항에 맞는지 판단할 수 있습니다. 자료형이 다르면 같은 화면 값도 다른 조건을 통과할 수 있습니다.

예시 입력	업무상 의미 예시	검토할 조건
false	사용자가 기능을 끔	기본값으로 덮지 않고 보존하는지
0	허용되는 최소 수량	없는 값과 구분하는지
빈 문자열	사용자가 값을 비움	빈값 허용 여부가 정의되었는지
null	명시적으로 값이 없음	기본값 또는 오류 처리가 맞는지
undefined	필드가 제공되지 않음	누락 필드의 정책과 맞는지

테스트 통과의 범위 읽기

모든 검사가 통과했다는 문장을 보면 어떤 검사를 어떤 상태에서 실행했는지 확인합니다. 설치 단계가 실패해 테스트가 시작되지 않았다면 테스트 실패와 구분해야 합니다. 관련 단위 테스트만 통과한 상태와 전체 앱을 실제 화면에서 확인한 상태도 다릅니다. 검증 결과에는 실행 명령, 검사 대상, 성공과 실패, 실행하지 못한 항목을 나눠 달라고 요청합니다. 오래된 결과를 마지막 수정 뒤의 결과처럼 받아들이지 않도록 검사 시점도 확인하세요.

새 테스트가 코드의 현재 구현만 반복하고 있는지 보는 것도 도움이 됩니다. 잘못된 동작을 그대로 기대값으로 적으면 테스트가 통과해도 원래 문제가 해결되지 않습니다. 설명용 저장 오류라면 사용자에게 보이는 결과를 기준으로 “옵션을 끈 뒤 다시 읽어도 false가 유지”되는지를 확인해야 합니다. 수정 전 코드에서 같은 사례가 실패하는지 확인할 수 있다면 회귀 검증의 근거가 더 분명해집니다. 다만 실제로 수정 전 상태를 실행하지 않았다면 그런 결과를 보고서에 만들어 넣지 않습니다.

구체적인 후속 요청 쓰기

전체 결과가 마음에 들지 않는다고만 말하기보다 확인한 줄과 영향을 적습니다. “옵션 값을 읽는 조건에서 빈 문자열 정책이 아직 설명되지 않았다. 현재 입력 정의를 확인하고 false와 0을 보존하는 의도를 유지한 채 빈 문자열 처리만 정리해 줘. 로그인이나 패키지 버전은 바꾸지 마. 관련 입력 표와 검증 결과를 다시 남겨 줘”처럼 쓸 수 있습니다. 이 요청은 새로운 기능을 넓게 맡기는 대신 남은 판단을 좁힙니다.

Codex의 검토 결과에도 추정과 실제 재현을 구분하도록 요청하세요. “발생할 수 있음”이라는 지적은 도달 가능한 조건이 있는지 확인해야 합니다. 실제로 문제가 되는 입력과 호출 경로를 설명할 수 있으면 수정 판단이 쉬워집니다. 반대로 코드 스타일 선호만 다른 지적은 현재 오류 해결과 분리할 수 있습니다. 검토가 끝나면 후속 수정의 diff를 다시 읽고, 처음의 문제와 연결되지 않은 변경이 추가되지 않았는지 확인합니다.

바이너리·생성 파일이 바뀐 경우

이미지나 문서 같은 바이너리 파일은 텍스트 diff만으로 내용을 충분히 확인하기 어렵습니다. 실제 파일을 열어 크기, 레이아웃, 내용이 의도대로 바뀌었는지 봅니다. 잠금 파일이나 자동 생성 파일은 원본 설정과 생성 과정을 함께 확인해야 합니다. 바뀐 줄이 많다는 이유로 모두 무시하지도, 줄이 많다는 이유로 전부 위험하다고 판단하지도 않습니다. 변경이 어떤 명령이나 원본 설정에서 나왔는지 연결하면 검토 대상이 정리됩니다.

파일 이름 변경이나 이동도 확인해야 합니다. 같은 내용의 파일이 옮겨졌더라도 상대 경로나 import 경로가 영향을 받을 수 있습니다. 문서 링크, 테스트 경로, 배포 설정에서 예전 위치를 참조하는지 점검합니다. AI에게 “파일 이동은 내용 변경과 분리해서 설명하고, 이전 경로를 참조하는 곳을 확인해 달라”고 요청할 수 있습니다. 이동 뒤 동작을 확인하지 않았다면 단순히 파일이 존재하는 것만으로 완료라고 쓰지 않습니다.

결과를 받아들이기 전 마지막 점검

최종적으로는 원래 문제의 재현이 사라졌는지, 유지해야 하는 동작이 남았는지, 실제 변경 파일과 결과 요약이 일치하는지 확인합니다. 커밋이나 배포 같은 다음 단계로 넘어가기 전에 검증하지 못한 항목도 읽습니다. “검토 완료”는 모든 가능한 결함이 없다는 보장이 아니라 정한 범위의 결과를 확인했다는 뜻으로 기록합니다. 코드 변경을 받아들이는 판단에는 diff, 입력 사례, 실행 결과가 서로 연결되어 있어야 합니다.

diff가 너무 길면 어떻게 하나요? 파일별 목적을 정리하고 실제 동작을 바꾸는 부분부터 읽습니다. 필요하면 서식 변경을 분리해 달라고 요청하세요. AI가 만든 변경만 보이면 충분한가요? 사용자 변경과 공통 코드가 함께 작동하므로 현재 저장소 상태도 확인해야 합니다. 검사가 통과했는데 화면이 다르면 무엇을 보나요? 검사한 환경과 실제 화면의 설정·자료·빌드가 같은지 비교한 뒤 빠진 재현 조건을 추가하세요.

공식 자료와 작성 기준

• OpenAI 코드 리뷰 안내
• Git 공식 git-diff 안내

AI를 활용해 작성한 정보형 원고입니다. 공식 문서는 2026년 10월 3일 확인했으며, 아래 예시는 설명을 위해 구성했습니다. 실제 개인 프로젝트의 실행 성과나 실측값을 뜻하지 않습니다. 발행 전 바뀐 제품 안내를 다시 확인합니다.

Codex 변경 사항 검토하기

1. 비교 기준 확인

→

2. 파일별 목적 정리

→

3. 삭제·추가 줄 함께 읽기

→

4. 입력별 변화 확인

→

5. 검사 결과 대조

설명을 위한 자체 제작 흐름도이며 실제 제품 화면이나 측정 결과가 아닙니다.