2026. 7. 7.
AI가 고쳤다는데 화면이 그대로일 때, 저장·서버·포트를 확인하는 순서
AI 코딩 도구가 수정 완료라고 했는데 브라우저 화면이 그대로라면 다시 고쳐 달라고 하기 전에 저장, 개발 서버, 포트, 새로고침, 화면 비교를 순서대로 분리합니다.

AI 코딩 도구가 "수정했습니다"라고 답했는데 브라우저 화면이 그대로라면 바로 다음 수정 요청을 넣기 쉽습니다. 하지만 이 순간에 다시 맡기면 코드가 더 많이 바뀌고, 원래 문제와 확인 문제를 한꺼번에 섞어 버릴 수 있습니다. 먼저 해야 할 일은 AI를 믿거나 의심하는 판단이 아니라, 내가 보고 있는 화면이 최신 코드와 연결되어 있는지를 7분 안에 나누는 것입니다.
추가 수정을 요청하기 전에 저장된 변경 파일, 실행 중인 개발 서버, 브라우저 주소의 포트를 이 순서로 확인합니다. 원인을 좁힌 뒤에는 AI에게 코드 변경 범위를 제한하는 프롬프트처럼 증거와 수정 범위를 함께 전달할 수 있습니다.
developers.openai.com의 Codex CLI 문서는 Codex CLI를 선택한 디렉터리에서 코드를 읽고, 바꾸고, 실행할 수 있는 로컬 코딩 에이전트로 설명합니다. 즉 AI가 실제 파일을 바꿀 수는 있지만, 브라우저가 그 변경을 보고 있다는 뜻까지 자동으로 보장하지는 않습니다. nextjs.org 문서는 next dev가 개발 모드와 Hot Module Reloading을 제공한다고 설명하지만, 개발 서버가 다른 포트에서 돌거나 저장되지 않은 파일을 보고 있으면 화면은 그대로일 수 있습니다.
1분째에는 파일이 실제로 저장됐는지 봅니다
가장 먼저 확인할 것은 브라우저가 아닙니다. AI가 바꿨다고 말한 파일이 실제로 저장되어 있는지 봅니다. 에디터에 저장 표시가 남아 있거나, 작업 디렉터리에 변경이 없는 상태라면 화면이 바뀔 수 없습니다.
Git을 쓰는 프로젝트라면 아래 명령으로 바뀐 파일을 먼저 봅니다.
git diff --name-only
Git을 아직 쓰지 않는다면 에디터에서 AI가 고쳤다고 한 파일을 열고, 방금 바꾸기로 한 문구나 컴포넌트 이름이 들어갔는지 찾습니다. 예를 들어 버튼 색상을 바꾸라고 했는데 Button.tsx에 변화가 없으면 브라우저 새로고침은 의미가 없습니다.
이 단계의 기준은 단순합니다.
| 확인 | 판단 |
|---|---|
| 요청한 파일이 바뀌었다 | 다음 단계로 갑니다 |
| 엉뚱한 파일만 바뀌었다 | AI에게 먼저 파일 범위를 다시 묻습니다 |
| 변경 파일이 없다 | 저장 또는 적용이 안 된 상태로 봅니다 |
변경 파일이 보이지 않으면 브라우저를 계속 새로고침하지 않습니다. 이때는 AI에게 "어느 파일을 바꿨는지 먼저 말해 달라"고 물어야 합니다.
2분째에는 개발 서버가 그 파일을 다시 읽는지 봅니다
파일은 바뀌었는데 화면은 그대로라면 개발 서버를 봅니다. Next.js에서는 next dev가 개발 서버와 HMR을 담당합니다. 하지만 터미널이 꺼져 있거나, 에러 때문에 반영이 멈췄거나, 예전 서버를 보고 있으면 바뀐 파일이 화면까지 오지 않습니다.
터미널에서 아래 세 가지를 봅니다.
npm run dev또는next dev가 아직 실행 중인지- 파일 저장 직후 터미널에 컴파일 또는 에러 로그가 찍히는지
- 브라우저 주소의 포트와 터미널에 나온 포트가 같은지
터미널에 에러가 있다면 화면이 그대로인 것이 아니라 새 코드가 실패한 것입니다. 이때는 "다시 고쳐 줘"보다 아래처럼 묻는 편이 낫습니다.
브라우저 화면은 그대로입니다.
방금 저장한 뒤 dev 서버 로그에 아래 에러가 나왔습니다.
[에러 로그 붙여넣기]
코드를 더 바꾸기 전에 이 에러가 화면 반영을 막는지 먼저 설명해 주세요.
수정이 필요하면 바꿀 파일 1개와 확인 명령 1개만 제안해 주세요.
AI에게 로그를 주면 추측 범위가 줄어듭니다. 반대로 로그 없이 "화면이 안 바뀐다"고만 말하면 AI는 코드, 스타일, 라우팅, 캐시를 한꺼번에 건드릴 수 있습니다.
3분째에는 내가 보고 있는 포트가 맞는지 확인합니다
초보자에게 가장 자주 생기는 혼동은 포트입니다. 터미널에는 http://localhost:3001이 떠 있는데 브라우저는 http://localhost:3000을 보고 있을 수 있습니다. 또는 예전에 띄운 서버가 남아 있어서 새 서버가 다른 포트로 올라갈 수 있습니다.
터미널에 나온 주소를 그대로 복사해 브라우저에 붙여 넣습니다. 주소창을 손으로 고치지 말고, 터미널의 URL을 그대로 여는 것이 좋습니다.
터미널 URL: http://localhost:3001
브라우저 URL: http://localhost:3000
두 값이 다르면 코드 문제가 아닐 수 있습니다. 포트가 다르면 먼저 터미널 URL로 다시 엽니다. 이 한 번으로 문제가 끝나는 경우가 많습니다.
이미 여러 서버가 떠 있는지 헷갈린다면 지금 보고 있는 프로젝트 터미널만 남기고 나머지를 끄는 편이 안전합니다. Windows에서는 터미널 창이 여러 개 열려 있는지 보고, macOS나 Linux에서는 개발 서버가 실행 중인 탭을 확인합니다. 초보자 루틴에서는 포트 정리를 자동 명령으로 밀어붙이기보다, 먼저 눈으로 열린 터미널을 줄이는 것이 실수를 줄입니다.
5분째에는 브라우저 새로고침 문제를 분리합니다
파일도 바뀌었고, 개발 서버도 돌아가고, 포트도 맞는데 화면이 그대로라면 브라우저 새로고침을 봅니다. 일반 새로고침만으로 충분한 경우도 있지만, 폼 상태나 라우터 상태가 남아 있는 화면에서는 바뀐 부분을 못 보는 경우가 있습니다.
아래 순서로만 확인합니다.
| 순서 | 행동 | 목적 |
|---|---|---|
| 1 | 브라우저 새로고침 | 가장 가벼운 확인 |
| 2 | 새 탭에 같은 URL 열기 | 현재 탭 상태 분리 |
| 3 | 시크릿 창 또는 다른 브라우저 열기 | 확장 프로그램과 캐시 영향 분리 |
| 4 | 수정한 요소가 있는 정확한 페이지로 이동 | 다른 경로를 보고 있는 실수 제거 |
여기서 핵심은 모든 것을 동시에 하지 않는 것입니다. 한 번에 서버 재시작, 패키지 재설치, 코드 재수정을 같이 하면 어떤 행동이 효과가 있었는지 알 수 없습니다. 한 단계마다 화면이 바뀌었는지만 기록합니다.
7분째에는 스크린샷으로 AI에게 증거를 줍니다
마지막 단계는 "안 바뀌었어요"를 증거로 바꾸는 것입니다. playwright.dev 문서는 page.screenshot()으로 현재 페이지 스크린샷을 파일로 저장할 수 있다고 설명합니다. 또 Playwright Test는 스크린샷 비교 기능도 제공합니다. 초보자가 당장 테스트 코드를 짜지 않더라도, 이 원리는 그대로 쓸 수 있습니다. 현재 화면을 이미지나 캡처로 남기고, AI에게 무엇이 그대로인지 구체적으로 말하는 것입니다.
AI에게 다시 요청할 때는 아래 양식을 씁니다.
AI가 수정 완료라고 했지만 화면이 그대로입니다.
수정 요청:
[처음 요청한 내용]
확인한 것:
- 변경 파일: [git diff --name-only 결과 또는 파일명]
- dev 서버 URL: [터미널에 나온 URL]
- 브라우저 URL: [주소창 URL]
- 새로고침 확인: [새 탭 또는 시크릿 창 확인 여부]
- 현재 화면에서 그대로인 부분: [예: 버튼 색상, 문구, 레이아웃]
요청:
코드를 바로 더 바꾸지 말고, 화면이 그대로인 원인을
1. 저장/적용 문제
2. dev 서버 문제
3. 포트/브라우저 문제
4. 실제 코드 수정 문제
중 하나로 먼저 분류해 주세요.
그 다음 바꿀 파일 1개와 확인 명령 1개만 제안해 주세요.
이 프롬프트의 목적은 AI를 느리게 만드는 것이 아닙니다. 변경 범위를 줄이는 것입니다. Codex 같은 로컬 코딩 에이전트는 파일을 바꾸고 명령을 실행할 수 있으므로, 사용자가 증거를 작게 주면 다음 행동도 작아집니다.
오늘은 다시 고치기 전에 5가지만 체크합니다
화면이 그대로일 때 바로 코드 수정을 반복하면 문제는 더 커질 수 있습니다. 오늘 필요한 루틴은 다섯 가지입니다.
- 변경 파일이 실제로 있는지 봅니다.
- 개발 서버가 저장한 파일을 다시 읽는지 봅니다.
- 브라우저 포트가 터미널 포트와 같은지 봅니다.
- 새 탭이나 시크릿 창으로 브라우저 상태를 분리합니다.
- 현재 화면 증거를 남기고 AI에게 원인 분류부터 요청합니다.
이 다섯 가지를 지나도 화면이 그대로라면 그때는 실제 코드 수정이 틀렸을 가능성이 커집니다. 그 전까지는 "AI가 실패했다"보다 내가 최신 실행 화면을 보고 있는지를 먼저 확인하는 편이 안전합니다. 이 확인 순서의 목표는 모든 문제를 해결하는 것이 아니라, 다음 AI 요청이 엉뚱한 파일을 더 건드리지 않게 만드는 것입니다.
그다음에는 브라우저 콘솔 오류를 AI에게 전달하는 4줄 프롬프트로 실제 런타임 오류를 좁힙니다. 적용 중인 도구의 공식 문서와 최신 릴리스 노트를 마지막에 다시 확인한 뒤 한 번의 최소 수정만 요청합니다.
참고 출처
- OpenAI Developers, Codex CLI: https://developers.openai.com/codex/cli
- Next.js Docs, next CLI: https://nextjs.org/docs/pages/api-reference/cli/next
- Next.js Docs, App Router CLI: https://nextjs.org/docs/app/api-reference/cli
- Playwright Docs, Screenshots: https://playwright.dev/docs/screenshots
- Playwright Docs, Visual comparisons: https://playwright.dev/docs/test-snapshots
다음으로 읽을 기사
같은 흐름으로 이어 읽기 좋은 기사만 추려 보여줍니다.
첫 번째 댓글을 남겨보세요
여러분의 생각이 다른 독자에게 도움이 됩니다.
댓글 0
이 글을 읽은 독자들의 생각을 나눠보세요.