/review로 변경사항 점검하기

앱을 만든 Codex에게 “잘 만들었지?”라고 물으면 같은 시선으로 자기 결과를 다시 보게 돼요. 오늘은 작업 모드를 바꿉니다. /review는 변경사항을 읽는 전용 리뷰어를 시작하고, 우선순위가 있는 문제를 보고하되 작업 파일을 바로 고치지는 않습니다.

공식 코드 리뷰 안내에 따르면 IDE에서 /review로 기준 브랜치 비교나 커밋 전 변경사항 리뷰를 선택할 수 있어요. 이 명령은 현재 폴더가 Git 저장소일 때 나타납니다.

오늘 만들 것

아직 커밋하지 않은 할 일 앱 변경을 리뷰하고, 실제 문제만 골라 고친 뒤 Git 저장점을 만들어요. 최종 결과는 다음과 같습니다.

• 우선순위가 붙은 리뷰 결과
• 필요한 수정이 반영된 코드
• 깨끗한 TEST_REPORT.md
• Add task app with verified workflow 커밋

준비물

• Git 저장소인 first-page 폴더
• 4강의 TEST_REPORT.md
• 커밋하지 않은 할 일 앱 변경사항
• 약 30분

따라 하기

1. 리뷰 범위를 눈으로 확인하기

리뷰 패널은 Codex가 만든 파일만 보는 게 아니라 Git 저장소의 staged, unstaged, untracked 변경을 모두 볼 수 있어요. 먼저 상태를 확인합니다.

git status와 변경 파일 목록만 보여 줘. 아직 수정, 스테이징, 커밋하지 마.
이번 할 일 앱과 관계없는 변경이 있으면 따로 구분해 줘.

내가 따로 고치던 파일이 섞여 있다면 지금 저장하거나 제외하세요. 리뷰 범위가 깨끗해야 결과도 읽기 쉬워요.

2. /review 실행하기

Codex 작성창에 /review를 입력하고 Review uncommitted changes를 선택하세요. 메뉴가 두 개라면 기준 브랜치가 아니라 커밋 전 변경사항을 고르는 거예요.

사용자 지정 리뷰 지시를 입력할 수 있다면 이렇게 적으세요.

TASK_APP_BRIEF.md의 완료 조건과 TEST_REPORT.md를 기준으로 리뷰해 줘.
특히 데이터 유실, 사용자 입력 처리, 키보드 접근성, 모바일 회귀를 확인해.
스타일 취향은 지적하지 말고 실제 버그나 위험만 우선순위와 재현 근거를 붙여 보고해.

리뷰어는 변경사항을 고치지 않고 finding을 보고하는 것이 정상입니다. 결과가 없다고 무조건 완벽한 것도 아니고, 결과가 있다고 무조건 모두 고쳐야 하는 것도 아니에요.

3. finding의 근거부터 확인하기

리뷰 결과마다 세 가지를 봅니다.

1. 어느 파일의 어떤 동작인가
2. 사용자가 어떻게 문제를 재현하는가
3. 명세의 어떤 완료 조건을 어기는가

근거가 약하면 바로 수정하지 말고 물어보세요.

첫 번째 finding이 실제 사용자에게 생기는 과정을 단계별로 설명해 줘.
관련 코드 위치와 최소 재현 입력을 보여 주고, 추측인 부분은 구분해.
아직 수정하지 마.

설명이 명확하고 재현된다면 고칩니다. 취향 제안이거나 범위 밖 기능이라면 이번에는 넘길 수 있어요.

4. 선택한 문제만 고치고 재검증하기

재현된 P1과 P2 finding만 수정해 줘. 범위 밖 제안은 건드리지 마.
수정 후 관련 재현 절차와 TASK_APP_BRIEF.md 전체 완료 조건을 다시 확인하고,
TEST_REPORT.md를 최신 결과로 갱신해 줘.

수정 뒤 /review를 한 번 더 실행하세요. 새 finding이 없거나 남은 항목을 왜 받지 않았는지 설명할 수 있으면 리뷰 단계가 끝납니다.

5. diff를 읽고 저장점 만들기

Codex의 변경사항 패널이나 VS Code Source Control에서 파일별 diff를 훑으세요. 모든 코드를 해석하려 애쓰기보다 아래만 확인하면 됩니다.

• 명세에 없던 파일이 생기지 않았는가
• 기존 소개 페이지의 내용이 사라지지 않았는가
• API 키, 이메일 같은 개인정보가 들어가지 않았는가
• TEST_REPORT.md가 실제 확인 결과와 일치하는가

확인했다면 저장점을 만듭니다.

최종 git diff를 요약하고 민감한 값이 포함되지 않았는지 확인해 줘.
문제가 없으면 이번 할 일 앱 관련 변경만 스테이징해서
"Add task app with verified workflow" 메시지로 커밋해 줘.
푸시와 배포는 아직 하지 마.

막혔을 때

• /review가 보이지 않아요 — git status가 동작하는지 확인하세요. Git 저장소가 아니라면 입문 5강의 git init과 첫 커밋을 먼저 진행합니다.
• 리뷰 결과가 너무 많아요 — “P1·P2와 실제 재현 가능한 항목만 남기고 스타일 제안은 제외해”라고 좁히세요.
• 리뷰가 파일을 고쳤어요 — 일반 작업 요청이 섞였을 수 있어요. 변경사항을 확인하고 리뷰 결과와 수정 작업을 서로 다른 턴으로 분리하세요.
• 커밋에 엉뚱한 파일이 들어가요 — 전체 스테이징을 취소하고 이번 강의 파일만 다시 선택하게 하세요. 다른 사람의 변경은 임의로 되돌리지 않습니다.

마무리 체크

□ /review에서 커밋 전 변경사항을 선택했다
□ finding마다 재현 근거를 확인했다
□ 필요한 문제만 고치고 전체 검증을 다시 했다
□ 최종 diff에 비밀값과 범위 밖 파일이 없다
□ 할 일 앱 변경이 Git 커밋으로 저장됐다
□ 아직 원격 푸시와 배포는 하지 않았다

여기까지의 절차는 다음 프로젝트에서도 똑같이 반복돼요. 마지막 강에서는 이 출시 점검을 Skill로 포장해 한 번의 호출로 다시 쓸 수 있게 만듭니다.