크롬 개발자 도구로 API 오류를 확인하려면 Network에서 요청을 기록한 뒤 Status와 응답 내용을 함께 살펴보면 된다. 로그인하거나 화면을 이동할 때 기록이 사라진다면 Preserve log를 먼저 켜는 것이 출발점이다. 오류를 재현하고 실패 요청을 찾은 다음, 필요한 기록만 HAR 파일로 정리하면 원인 분석과 담당자 전달까지 이어갈 수 있다.
📌 핵심 요약
- Preserve log 활성화 → 오류 재발생 → 실패 요청의 Headers·Response 확인 순서로 진행한다.
- HTTP 오류 응답, CORS 차단, 연결 실패는 구분해서 분석한다.
- HAR (sanitized)도 URL 쿼리와 요청·응답 본문의 개인정보를 별도로 점검해야 한다.
1. Network 기록 설정으로 로그인·화면 이동 요청 보존하기
Network는 브라우저가 주고받는 요청과 응답을 확인하는 개발자 도구 패널이다. 이미 지나간 통신을 소급해 복구하는 도구는 아니므로, 문제가 발생하는 동작을 실행하기 전에 열어야 한다. Chrome 공식 문서는 DevTools가 열린 동안 요청을 기록하며, Preserve log로 페이지 이동 전후의 기록을 유지할 수 있다고 설명한다.
- 개발자 도구 열기: Windows에서는 Ctrl + Shift + I, macOS에서는 Command + Option + I를 누르고 Network 탭을 선택한다.
- 기록 상태 확인: 녹화 버튼이 기록 중인지 확인한다. 중지된 상태라면 버튼을 눌러 기록을 시작한다.
- Preserve log 활성화: 로그인 리디렉션이나 새 페이지 이동이 포함된다면 오류 재현 전에 체크한다.
- 기존 기록 정리: Clear로 이전 요청을 지운 뒤 문제가 발생하는 동작을 한 번 수행한다.
- 오류 직후 기록 확인: 실패 화면이 나타난 시점의 요청부터 확인하고, 필요한 증거를 확보할 때까지 기록을 지우지 않는다.
로그인 버튼을 누른 뒤 인증 페이지를 거쳐 원래 서비스로 돌아오는 과정에서는 여러 요청이 이어진다. 마지막 화면에 보이는 실패만 확인하면 앞선 인증 요청이나 리디렉션을 놓치기 쉽다. Preserve log는 이 흐름을 연결해서 보는 데 도움이 된다.
출처: Google Chrome for Developers, Network features reference의 요청 기록 및 페이지 이동 시 기록 보존 안내.
1. Network 기록 설정으로 로그인·화면 이동 요청 보존하기
2. Fetch/XHR와 Status로 API 실패 요청 좁히기
요청이 많다면 Fetch/XHR 필터로 시작하면 API 통신을 찾기 수월하다. 이름 검색창에는 요청 경로나 기능과 관련된 문자열을 입력한다. 다만 로그인 페이지 이동이나 문서 응답이 원인일 수 있으므로, 관련 요청이 보이지 않으면 All로 돌아가 필터를 해제한다.
Status는 원인을 확정하는 답이라기보다 다음 확인 지점을 알려주는 단서다. 숫자 상태 코드뿐 아니라 CORS error, (failed), 연결 오류 메시지가 나타날 수 있다. 빨간색 요청만 찾기보다 오류가 발생한 시간과 요청 경로를 함께 맞추는 편이 정확하다.
| 표시·상태 코드 | 해석과 다음 확인 지점 |
|---|---|
| 200 | HTTP 요청은 성공했다. Response가 기대한 데이터인지, 애플리케이션 오류가 본문에 담겼는지 확인한다. |
| 401·403 | 인증 정보 유무와 접근 권한을 점검한다. 정확한 거부 사유는 응답 본문과 서비스 정책을 함께 확인한다. |
| 404 | 요청한 리소스를 찾지 못한 응답이다. 경로, 배포 환경, 리소스 식별자를 확인한다. |
| 500·502·503 | 서버나 중간 게이트웨이의 오류 가능성을 조사한다. 응답 메시지와 서버 로그를 연결해야 발생 지점을 좁힐 수 있다. |
| CORS error·(failed) | 응답 접근 제한 또는 통신 실패 가능성이 있다. Console의 상세 메시지와 Network의 연결 오류를 함께 확인한다. |
실무 분석에서는 HTTP 성공과 화면 기능의 성공을 나누어 판단하는 것이 중요하다. 예를 들어 목록 API가 200을 반환해도 본문이 로그인 HTML이거나 예상과 다른 JSON 구조라면 화면은 정상적으로 동작하지 않을 수 있다. 상태 코드만 캡처하는 것보다 응답 형식까지 확인해야 전달할 정보가 명확해진다.
2. Fetch/XHR와 Status로 API 실패 요청 좁히기 바로가기
3. Headers·Payload·Response로 API 오류 원인 확인하기
분석의 기본 흐름은 Preserve log 활성화 → 오류 재발생 → 실패 요청의 Headers·Response 확인이다. 해당 요청을 클릭한 뒤 요청 주소와 메서드, 보낸 값, 받은 내용을 순서대로 살펴본다. 응답을 받지 못한 연결 실패에서는 Response가 비어 있을 수 있다.
Headers: 어디에 어떤 방식으로 요청했는지 확인
General에서 Request URL, Request Method, Status Code를 먼저 확인한다. 개발 환경에서 운영 API로 잘못 연결되거나, 서버가 기대하는 메서드와 다르면 같은 기능도 실패할 수 있다. Request Headers와 Response Headers에서는 Content-Type, 인증 관련 정보, CORS 관련 헤더를 확인하되 토큰 값을 그대로 복사해 공유하지 않는다.
Payload: 실제로 전송된 입력값 확인
Payload에서는 쿼리 매개변수, 폼 데이터, 요청 본문 등 실제 전송 내용을 살펴본다. 화면에 입력한 값과 전송된 값이 같은지, 필수 필드가 빠지거나 자료형이 달라지지 않았는지가 핵심이다. 빈 문자열과 누락된 필드가 서로 다르게 처리되는지도 API 명세와 대조한다.
Response: 오류 메시지와 반환 형식 확인
Response에서 서버가 보낸 원문을 확인하고, Preview가 제공되면 구조를 읽기 쉽게 살펴본다. 오류 코드, 필드별 검증 메시지, 추적용 요청 식별자가 있다면 담당자가 확인할 단서로 정리한다. 응답에 이메일이나 주문 정보가 들어 있다면 화면 캡처에도 개인정보가 포함될 수 있다.
원인 분석의 효율을 높이려면 정상 요청과 실패 요청을 같은 항목으로 대조하는 편이 좋다. 주소와 메서드는 같은데 Payload만 다르다면 입력값 검증을, 응답은 정상인데 화면만 멈춘다면 Console의 자바스크립트 오류를 추가로 살펴볼 근거가 된다. 이는 원인을 단정하는 규칙이 아니라 조사 순서를 정하는 기준이다.
3. Headers·Payload·Response로 API 오류 원… 신청하기
4. CORS 오류와 DNS·TLS 연결 실패 구분하기
CORS 메시지가 보인다고 곧바로 허용 헤더 설정 문제로 결론 내리기는 어렵다. 2026년 1월 15일 수정된 MDN 문서는 CORS request did not succeed가 네트워크나 프로토콜 수준의 연결 실패일 수 있다고 설명한다. DNS 해석 실패, 시간 초과, 연결 거부, TLS 핸드셰이크 오류를 Network에서 확인하도록 안내한다.
- DNS 관련 오류: API 호스트 이름과 현재 네트워크의 이름 해석 상태를 확인한다.
- 연결 거부·시간 초과: 서버 실행 여부, 포트, 방화벽 및 네트워크 경로를 점검한다.
- TLS·인증서 오류: 인증서 유효성과 HTTPS 연결 상태를 확인한다.
- CORS 정책 관련 메시지: 요청 Origin과 서버의 허용 정책을 대조하고, 사전 요청이 있다면 OPTIONS 응답도 확인한다.
확장 프로그램이 요청을 차단하거나 HTTPS 페이지에서 HTTP 자원을 호출하는 상황도 확인 대상이다. 확장 프로그램을 비활성화한 환경과 비교하면 브라우저 환경의 영향을 좁히는 데 도움이 된다. 보안 기능을 끄는 방식으로 해결하기보다 실제 연결 실패와 서버 정책을 구분해야 한다.
출처: MDN, Reason: CORS request did not succeed, 2026년 1월 15일 수정 문서.
5. HAR 파일 내보내기와 sanitized 공유 전 개인정보 점검
HAR는 HTTP 요청과 응답 등 통신 기록을 담는 파일 형식이다. 오류가 발생한 순서와 통신 내용을 전달할 때 유용하지만, 저장된 정보의 범위를 확인한 뒤 공유해야 한다. 2026년에도 중요한 기준은 파일 이름에 sanitized가 붙었는지뿐 아니라 실제 내용에 무엇이 남아 있는지다.
- 오류를 재현한 뒤 필요한 요청이 기록되어 있는지 확인한다.
- 요청 목록에서 우클릭하고 Copy → Save all [listed] as HAR (sanitized)를 선택한다. 상단의 Export HAR (sanitized) 내보내기 버튼을 사용할 수도 있다.
- 필터가 적용되어 있다면 내보내기 대상이 필요한 요청을 포함하는지 확인한다. 로그인 전후 흐름이 중요하다면 관련 요청이 빠지지 않도록 범위를 조정한다.
- 저장한 파일을 로컬 텍스트 편집기 등에서 열어 개인정보와 비밀값을 점검하고, 정리한 사본을 공유한다.
Chrome 공식 문서에 따르면 기본 정제 HAR는 Cookie, Set-Cookie, Authorization 헤더를 제외한다. 다만 이 처리가 파일 전체의 개인정보 제거를 보장하지는 않는다. URL 쿼리의 이메일·토큰, 요청 본문의 폼 입력값, 응답 본문의 계정 정보와 서비스가 사용하는 별도 인증 헤더를 확인해야 한다.
Google Cloud도 HAR에 브라우저 쿠키와 폼 입력 정보가 포함될 수 있다고 경고하며, 텍스트 편집기나 정제 도구로 민감정보를 삭제하도록 안내한다. 문자열 검색만으로는 인코딩되거나 다른 필드에 들어간 값을 놓칠 수 있으므로 요청과 응답 구조도 함께 확인한다. 정제 후에는 JSON 형식이 유지되는지, 분석에 필요한 상태 코드와 요청 순서가 남아 있는지도 살펴본다.
출처: Google Chrome for Developers, Network features reference의 HAR 내보내기 안내; Google Cloud, Capture browser trace information의 민감정보 주의사항.
6. API 오류 전달 체크리스트로 재현 가능한 기록 만들기
담당자가 필요한 것은 요청이 많이 담긴 파일보다 어떤 동작에서 무엇이 실패했는지 설명하는 기록이다. HAR와 함께 발생 시간, 재현 순서, 기대한 결과와 실제 결과를 짧게 정리하면 서버 로그와 대조하기 쉬워진다. 시간대까지 적으면 서로 다른 지역의 운영 환경에서도 혼동을 줄일 수 있다.
- 발생 날짜·시간·시간대와 Chrome 버전을 기록한다.
- 오류가 발생하는 화면과 클릭·입력 순서를 정리한다.
- 실패 요청의 경로, 메서드, Status 및 오류 메시지를 남긴다.
- 가능하면 응답의 요청 식별자를 함께 전달한다.
- HAR의 URL, 헤더, 요청·응답 본문을 검토하고 공유 대상과 전달 경로를 확인한다.
우선 Network를 열고 Preserve log를 켠 상태에서 오류를 한 번 재현하는 것으로 시작하면 된다. 이후 Headers와 Response로 확인한 사실을 정리하고, 개인정보를 점검한 HAR를 필요한 범위로 전달한다. 이 순서를 지키면 사라진 요청을 다시 찾는 수고와 불필요한 민감정보 공유를 함께 줄일 수 있다.