코딩 오류가 생겼을 때 변경 중단, 재현, 첫 로그 확인, 화면·네트워크·서버 구분, 가설 하나 검증, 정상 상태 복구 순서를 설명합니다.
코딩 오류 확인 순서는 수정을 멈추고 같은 오류를 재현한 뒤 첫 오류와 마지막 정상 지점을 찾는 데서 시작합니다.
연재 안내: 27편 전체 순서와 현재 공개된 글은 비개발자 바이브코딩 로드맵에서 확인할 수 있습니다.
코드 흐름을 찾기 어렵다면 먼저 AI 코드 읽는 법 5단계를 확인하세요.
한 줄 답변
코딩 오류가 생기면 새 코드를 계속 붙이지 말고 마지막 정상 상태와 오류 재현 순서를 먼저 기록해야 합니다. 그다음 첫 오류 메시지, 브라우저 화면, 네트워크 요청, 서버 로그를 차례로 확인하고 가설 하나만 시험합니다.
1. 손을 멈추고 현재 상태를 보존한다
당황해서 여러 파일을 동시에 바꾸면 원래 오류와 새 오류가 섞입니다. 실행 중인 화면, 터미널 로그, 마지막으로 바꾼 파일을 기록하고 가능하면 현재 변경분을 별도 브랜치(같은 프로젝트를 나눠 작업하는 갈래)나 임시 백업에 보존합니다.
비밀키와 개인정보가 화면이나 로그에 보인다면 스크린샷과 공유 전에 가립니다. 오류 해결을 위해 민감정보까지 AI 대화창에 붙여 넣을 필요는 없습니다.
2. 같은 오류를 다시 만든다
재현 순서는 디버깅의 출발점입니다. 다음 항목을 한 줄씩 적습니다.
- 어느 주소와 화면에서 시작했는가?
- 어떤 계정과 테스트 데이터를 사용했는가?
- 어떤 버튼을 어떤 순서로 눌렀는가?
- 기대한 결과와 실제 결과는 무엇인가?
- 항상 발생하는가, 특정 조건에서만 발생하는가?
“예약이 가끔 안 된다”보다 “로그아웃 상태에서 모바일 화면으로 과거 날짜를 선택하면 저장 버튼이 계속 로딩된다”가 원인을 훨씬 빨리 좁힙니다.
3. 첫 오류 메시지를 읽는다
긴 로그에서 마지막 줄만 보지 말고 처음 실패한 지점을 찾습니다. 오류 종류, 파일 이름, 줄 번호, 함수 이름, 읽지 못한 값이 핵심 단서입니다.
TypeError: Cannot read properties of undefined
at submitReservation (submit.js:42)이 메시지는 submit.js 42번째 줄의 함수가 아직 없는 값에서 속성을 읽으려 했다는 뜻입니다. 코드 전체를 교체하기 전에 그 함수로 전달되는 입력값을 확인해야 합니다.
4. 오류가 난 구역을 나눈다
웹앱은 화면, 네트워크, 서버, 데이터베이스(DB) 순서로 확인할 수 있습니다.
- 버튼 반응이 없다: 화면 이벤트와 브라우저 콘솔을 본다.
- 요청이 전송되지 않는다: 호출 함수와 네트워크 탭을 본다.
- 400 응답: 요청 데이터와 서버 검증을 본다.
- 401·403 응답: 로그인과 권한을 본다.
- 500 응답: 서버 로그와 DB 처리를 본다.
- 성공 응답인데 화면이 비어 있다: 응답 JSON과 화면 표시를 본다.
문제 구역을 절반으로만 줄여도 AI가 관련 없는 파일을 수정하는 일을 크게 줄일 수 있습니다.
5. 데이터가 지나가는 길에 표시를 남긴다
함수 진입 전과 후, API 호출 전과 응답 후에 임시 로그를 넣어 값이 어디까지 도착했는지 확인합니다. 다만 비밀번호, API 키, 인증 토큰, 개인정보 전체를 로그에 출력하지 않습니다. 필요한 항목의 존재 여부나 테스트용 ID만 확인합니다.
화면 로그는 정상인데 네트워크 요청이 없다면 호출 전 단계가 문제입니다. 요청은 성공했는데 서버 로그가 없다면 주소나 라우팅을 확인합니다. 관찰한 사실을 기준으로 다음 위치를 정합니다.
6. 가설 하나만 시험한다
“입력값 이름이 서로 다르다”는 가설을 세웠다면 해당 이름만 확인하고 수정합니다. 동시에 패키지 업데이트, 함수 분리, 디자인 변경까지 하지 않습니다. 수정 후 같은 재현 순서를 실행해 결과가 바뀌었는지 봅니다.
가설이 틀리면 원상복구하고 다음 가설로 넘어갑니다. 여러 변경을 한꺼번에 적용하면 무엇이 해결했는지 알 수 없고 새로운 회귀 오류가 남습니다.
7. 고쳤다면 연결 기능까지 다시 확인한다
예약 저장 오류를 고쳤다면 저장 성공만 보지 말고 목록 표시, 새로고침, 중복 방지, 권한 없는 접근도 확인합니다. 수정 내용, 원인, 테스트 결과를 커밋 메시지나 작업 기록에 남깁니다.
해결이 안 되고 변경이 계속 늘어난다면 마지막 정상 커밋으로 돌아가 더 작은 재현 예제를 만드는 편이 안전합니다.
AI에게 전달할 오류 보고서
마지막 정상 상태, 마지막 변경 파일, 재현 순서, 기대 결과, 실제 결과, 첫 오류 로그, 브라우저 네트워크 상태를 제공할 테니 코드를 바로 교체하지 말고 가능한 원인 세 개를 가능성 순으로 정리해줘. 첫 번째 원인을 확인할 최소 진단만 제안해줘.
디버깅은 정답 코드를 받는 일이 아니라 틀린 가능성을 하나씩 지우는 과정입니다.
해결 기록은 다음 오류의 검색어가 된다
오류를 고친 뒤 증상, 원인, 확인한 로그, 수정 파일, 재발 방지 테스트를 다섯 줄로 남기세요. “500 오류 해결”보다 “예약 저장 API가 빈 날짜를 처리하지 못해 500 발생, 서버 검증 추가”처럼 적습니다.
같은 증상이 다시 생기면 AI에게 전체 코드를 주기 전에 이 기록을 검색할 수 있습니다. 팀원이 없어도 과거의 판단을 이어받는 작은 운영 문서가 됩니다.
기록에는 실패했던 가설도 짧게 남기세요. 이미 확인한 원인을 다시 시험하는 시간을 줄이고, 비슷해 보이는 오류가 실제로는 다른 문제라는 사실도 구분할 수 있습니다. 해결 문서가 늘면 기능과 오류 유형별로 색인을 만들어 찾기 쉽게 관리합니다.
코딩 오류 확인 순서 최종 점검
코딩 오류 확인 순서는 재현 조건, 첫 오류 메시지, 직전 변경, 정상인 구간, 의심 구간을 기록하는 방식으로 고정하세요. 코딩 오류 확인 순서를 건너뛰고 AI 제안을 여러 개 적용하면 어떤 변경이 효과가 있었는지 알 수 없고 원래 오류까지 가려집니다.
문제를 절반씩 나눠 화면, 네트워크, 서버, DB 가운데 마지막 정상 지점을 찾은 뒤 한 번에 가설 하나만 시험하세요. 수정 후에는 같은 재현 절차와 주변 기능을 실행하고 결과를 기록해야 우연히 사라진 오류를 해결로 착각하지 않습니다.
오류 범위를 좁힌 뒤 기존 코드를 고칠지 새로 만들지 고민된다면 다음 글 코드 수정 판단: 고칠까 새로 만들까에서 테스트·숨은 업무 규칙·전환 비용을 비교하는 기준을 확인하세요.
바이브코딩 전체 순서 보기
바이브코딩 뜻, 하는법, 도구 선택, API 연결, 데이터베이스, 배포 흐름은 바이브코딩 가이드에서 이어서 볼 수 있습니다.
