문제를 구체적으로 남기기
누가 작성한 코드든 실제 실행 조건에서 확인해야 합니다. AI가 개발에 참여했다면 원인을 찾는 데 도움을 받을 수 있지만, 관찰한 증상을 충분히 구체적으로 전달해야 합니다.
예를 들어 내 컴퓨터에서는 수량 10, 단가 12, 배송비 8을 넣으면 128이 나오는데, 배포된 페이지에서는 계산을 눌러도 결과가 없다고 해봅시다. 주소, 브라우저, 조작 단계, 발생 시간, 화면 안내를 기록하고 현재 버전을 보관하세요. 오류 화면과 로그에서는 먼저 비밀 키와 개인정보를 지웁니다.
1단계: 같은 순서로 다시 실행하기
문제가 계속 재현되는지 확인합니다. 새 브라우저 창에서 같은 입력을 넣어보세요. 계정이 필요하면 사용한 테스트 계정의 역할만 기록하고 로그인 정보는 공개하지 않습니다.
어디서부터 달라지는지 구분하세요. 페이지가 열리지 않는지, 버튼이 반응하지 않는지, 요청이 실패하는지, 요청은 성공했는데 결과가 틀리는지에 따라 볼 곳이 달라집니다.
2단계: 증상에 맞춰 범위 좁히기
| 증상 | 먼저 확인할 곳 |
|---|---|
| 첫 화면은 열리지만 특정 주소에서 새로고침하면 실패함 | 페이지 라우팅과 호스팅 설정 |
| 화면은 보이지만 버튼을 눌러도 결과가 없음 | 브라우저 오류, 요청 상태, 버튼 동작 |
| 내 컴퓨터의 요청은 성공하고 배포 후에는 실패함 | 운영 API 주소, 환경 설정, 접근 조건 |
| 저장한 뒤 다시 열면 데이터가 사라짐 | 실제 저장 여부와 운영 저장소 설정 |
| 서로 다른 계정에 같은 자료가 보임 | 서버의 로그인 신원 확인과 조회 범위 |
이는 점검 방향이며, 원인이 확인됐다는 뜻은 아닙니다. 실제 기록으로 판단해야 합니다. 브라우저 개발자 도구의 콘솔과 네트워크에서 화면 오류와 요청 상태를 보고, 서버가 있다면 같은 시간대의 서버 로그도 확인하세요.
3단계: 로컬과 운영 환경 비교하기
AI에 이 프로젝트의 의존성, 실행 명령, 설정 이름, API, 데이터 출처를 정리하게 하고 운영 환경과 비교합니다. 설정이 있는지, 형식이 맞는지만 확인하고 비밀 키를 대화에 붙여 넣지 마세요.
최근 변경도 살펴봅니다. 한 번에 근거가 있는 원인 하나를 다루고 수정 기록을 남기세요. 운영 중 사용에 영향이 있다면 먼저 작동이 확인된 버전을 복원한 뒤 복사본에서 점검할 수 있습니다. 데이터를 바꾸는 수정은 백업과 복구 방법부터 확인합니다.
4단계: 수정 후 원래 입력으로 돌아가기
오류 메시지가 없어졌다고 끝내지 마세요. 처음의 조작을 다시 실행해 실제 결과가 예상과 같은지 확인합니다. 이어서 비슷한 기능, 다른 입력, 새로고침 후 재시도, 실패 안내를 시험하세요. 계정이 있다면 역할을 바꿔 각각 확인합니다.
다른 계정의 자료에 접근할 수 있었다면 관련 조회 경로를 모두 점검해야 합니다. 이 사이트의 가상 학습 예제는 이런 시험을 설계하는 방법을 보여줍니다. 실제 시험을 통과한 운영 시스템을 제공하는 사례는 아닙니다.
마지막으로 문제 해결 기록 남기기
증상, 확인된 원인, 수정 내용, 재시험 결과, 남은 문제를 적습니다. 업그레이드, 이전, 기능 추가 때 다시 확인할 근거가 됩니다. 배포 전체 점검에는 체크리스트를 활용하세요.
자주 묻는 질문
내 컴퓨터에서는 되는데 배포 후에는 왜 안 되나요?
오류를 AI에 붙여 넣고 바로 다시 작성하게 해도 되나요?
다른 계정으로 바꿨더니 남의 자료가 보이면 어떻게 하나요?
이어 읽기
- 아이디어에서 쓸 수 있는 도구까지 — 실행, 확인, 버전 관리 이어가기
- 배포 전 체크리스트 — 프로젝트에 맞는 점검 항목 보완하기
- 가상 고객 자료 페이지 — 로그인 신원과 조회 범위 이해하기
