코덱스 변경 사항 검토하기: 완료 메시지 다음에 볼 것

‘이번 수정 검토해 줘’만으로는 범위가 모호할 수 있어요. 아직 커밋하지 않은 변경인지, 특정 커밋인지, 기준 브랜치와의 차이인지 알려 주세요. 리뷰 화면에는 Codex뿐 아니라 사용자가 직접 수정한 내용도 함께 나타날 수 있어요.

예를 들어 오늘 수정한 오류만 확인하려는데 브랜치 전체를 비교하면 지난주 기능까지 포함될 수 있어요. 먼저 변경 파일 목록을 보고 기대한 범위와 맞는지 확인해 주세요.

Git 프로젝트의 리뷰 화면에서 추가·삭제된 줄을 확인해요. 파일 이름만 보지 말고 요청과 상관없는 변경이 섞였는지, 원래 있던 조건이 사라졌는지 살펴보세요. 문구 수정이라면 숫자, 링크, 날짜가 함께 바뀌지 않았는지도 확인해요.

코드가 익숙하지 않다면 ‘이 파일의 변경 전후 동작을 실제 입력 예시로 설명해 줘’라고 요청해 보세요. ‘검증 로직 개선’보다 ‘빈 제목을 보내면 저장하지 않고 안내를 보여 준다’처럼 사용자가 보는 차이를 설명받는 편이 좋아요.

Codex 입력창에 /review를 입력하고 기준 브랜치 비교나 커밋하지 않은 변경 등 원하는 범위를 골라요. Git 프로젝트에서 사용할 수 있으며, 리뷰는 변경점을 읽고 문제를 보고하는 과정이에요. 지적을 받았다고 수정까지 끝난 것은 아니에요.

추가 요청 예시: ‘이번 변경에서 검색어가 빈 경우, 한글인 경우, 결과가 없는 경우를 중심으로 리뷰해 주세요. 실제로 잘못 동작하는 경로가 있으면 파일 위치와 재현 조건, 사용자에게 생기는 문제를 설명해 주세요.’

표현 취향과 오류를 구분해서 보세요. 팀의 명시된 규칙이 없는 이름 취향보다 데이터 누락이나 기존 동작이 깨지는 문제를 먼저 확인하면 수정 순서를 정하기 쉬워요.

테스트는 정해 둔 입력과 기대 결과를 확인해요. 어떤 검사를 실행했는지와 실패한 검사가 있는지 결과를 받아 보세요. ‘문제없음’만 적혀 있다면 실행한 명령과 확인한 범위를 구체적으로 물어보면 돼요.

화면을 바꿨다면 직접 열어 글자 잘림, 클릭, 좁은 화면에서의 배치를 확인해요. 검색 기능 예시라면 정상 검색만 하지 말고 빈 입력과 결과 없음도 살펴보세요. 통과한 검사에 포함되지 않은 동작이 무엇인지 아는 것도 검토의 일부예요.

문제가 생기는 조건과 기대한 결과를 함께 적어요. ‘검색이 이상해’보다 ‘검색어를 지우면 이전 결과가 남아요. 빈 입력에서는 전체 목록을 보여 주세요’가 확인하기 쉬워요. 해당 줄에 피드백을 남길 수 있다면 문제 위치도 함께 전달해 주세요.

수정 요청 예시: ‘리뷰에서 찾은 빈 검색어 처리 문제를 고쳐 주세요. 기존 한글 검색 결과는 유지해 주세요. 수정 후에는 빈 입력과 한글 입력 두 경우를 확인하고 변경한 파일을 알려 주세요.’

수정 뒤에는 그 문제와 영향을 받을 가까운 동작을 다시 확인해요. 처음 리뷰를 통과한 상태와 나중에 수정한 상태는 다른 코드이므로, 이전 통과 기록만으로 마무리하지는 않아요.

문제, 변경 후 동작, 확인한 방법을 짧게 남겨요. 검사를 실행하지 못했다면 이유와 아직 확인하지 않은 범위도 적어 주세요. 다른 사람이 같은 작업을 검토할 때 출발점이 돼요.

완료 기록 예시: ‘빈 검색어에서 전체 목록이 보이도록 수정했어요. 빈 입력·한글 입력·결과 없음 테스트를 통과했고, 모바일 화면에서 검색창과 안내 문구를 확인했어요.’ 실제로 확인한 것만 기록해 주세요.

커밋, 원격 저장소로 올리기, 배포는 각각 별도 행동이에요. 검토가 끝난 범위를 확인한 뒤 진행하고, 이미 있던 다른 사람의 변경이 함께 들어가지 않는지 살펴보세요.