크롬 DevTools로 증거 수집하기: Network·Console·Elements와 재현 가능한 리포트

개념

같은 현상, 두 개의 리포트

QA가 같은 버그를 발견했다. 리포트가 두 가지로 나온다.

A: "주문하기 버튼을 눌렀는데 아무 반응이 없어요."

B: "주문하기 클릭 시 POST /api/orders 가 500 을 반환합니다. 응답 본문은 {"error":"COUPON_EXPIRED"} 이고, 화면에는 아무 메시지도 표시되지 않습니다. 콘솔에 Uncaught TypeError: Cannot read properties of null (reading 'message') 가 함께 찍힙니다. HAR 첨부했습니다."

두 리포트의 차이는 관찰력이 아니라 도구 다. B를 쓴 사람은 특별히 더 꼼꼼한 게 아니라, 브라우저 개발자도구를 열어봤을 뿐이다.

레슨 2에서 HTTP를, 레슨 1에서 코드 읽기를 배웠다. 이 레슨은 그 지식을 실제 화면에서 확인하는 도구 를 다룬다. 그리고 다음 레슨(레슨 10)에서 "개발자도구로 안 되는 것들"을 위해 Charles·Wireshark로 넘어간다 — 그 전에 되는 것부터 제대로 하자는 것이 이 레슨이다.

여는 방법: F12 또는 Ctrl+Shift+I(맥은 Cmd+Option+I). 특정 요소를 바로 보려면 그 요소에서 우클릭 → 검사.

QA가 실제로 쓰는 패널

패널이 많지만 QA가 쓰는 것은 정해져 있다.

Network와 Console 둘만 익혀도 결함 리포트의 질이 달라진다. 나머지는 필요할 때 하나씩 늘리면 된다.

UI는 크롬 버전마다 조금씩 바뀐다. 최근 버전에는 AI 지원 패널이나 자동화 연동(DevTools MCP 서버 — 모듈 18a 레슨 4의 그 MCP다) 같은 것도 들어와 있다. 패널 위치를 외우기보다 "무엇을 보고 싶은가"로 찾는 습관 이 오래 간다.

Network 탭 — 여기가 본진이다

버그를 만나면 가장 먼저 열 곳이다. 먼저 켜두어야 할 설정 두 개 가 있다.

로그인 → 리다이렉트 흐름을 볼 때 Preserve log를 안 켜두면 로그인 요청이 화면 전환과 함께 사라진다. 처음 열 때 두 개를 켜는 것을 습관으로 만들어두면 같은 재현을 두 번 하지 않아도 된다.

요청 목록에서 읽을 것들

필터를 쓰면 훨씬 빨라진다.

Fetch/XHR 버튼      API 호출만 남긴다 — QA가 가장 자주 쓴다
status-code:500     상태 코드로 필터
method:POST         메서드로 필터
-domain:*.google.com  특정 도메인 제외 (앞의 - 는 제외)
larger-than:1M      1MB 넘는 응답만 — 성능 문제 찾을 때

요청 하나를 클릭하면 상세가 열린다. QA가 볼 탭은 넷이다.

• Headers — 요청 URL, 메서드, 상태 코드, 요청·응답 헤더. 인증 토큰이 실려 나갔는지 여기서 확인한다(레슨 3)
• Payload — 우리가 보낸 값. "내가 입력한 값이 실제로 이렇게 전달됐나" 를 확인하는 자리
• Response / Preview — 서버가 준 값. Preview는 JSON을 접었다 펼 수 있어 읽기 편하다
• Timing — 어디서 시간을 썼는지(대기·다운로드 등)

결함 원인을 가르는 질문은 대개 이 순서로 풀린다.

① 요청이 아예 안 나갔다      → 프런트엔드 문제 (이벤트·검증에서 막힘)
② 요청은 나갔는데 4xx        → 요청 값이 잘못됨 (Payload를 본다)
③ 요청은 맞는데 5xx          → 서버 문제 (개발자에게 넘길 근거 확보)
④ 200인데 화면이 이상        → 프런트엔드 렌더링 문제 (Console을 본다)

이 네 갈래를 구분하는 것만으로 리포트의 가치가 완전히 달라진다. "안 돼요"가 아니라 "요청 자체가 안 나갑니다" 또는 "서버가 500을 줍니다"가 되고, 그러면 담당자가 바로 정해진다.

네트워크 조건 바꿔보기

Network 탭에서 쓰로틀링(Throttling) 으로 느린 네트워크를 흉내낼 수 있다. Fast 4G, Slow 4G, Offline 같은 프리셋이 있고 직접 만들 수도 있다.

QA에게 이게 중요한 이유는, 개발자는 대부분 빠른 회선에서 개발하기 때문 이다. 느린 환경에서만 드러나는 결함이 있다.

Offline 모드 도 유용하다. 오프라인일 때 적절한 안내가 뜨는지, 복구되면 자동으로 재시도하는지 확인한다.

HAR — 네트워크 기록을 통째로 넘기기

HAR(HTTP Archive) 은 Network 탭의 기록 전체를 파일로 저장한 것이다. 요청 목록에서 우클릭 → Save all as HAR 로 내보낸다.

개발자에게 이 파일을 주면 재현 없이도 무엇이 오갔는지 그대로 볼 수 있다. 재현이 어려운 결함일수록 값이 크다. 모듈 5(레슨 12)에서 다룬 "재현 불가능한 버그"에 대한 대응 수단이기도 하다.

⚠️ HAR에는 인증 토큰·쿠키·개인정보가 그대로 들어 있다. 외부에 공유할 때는 민감 정보 제거 옵션(Sanitized 형태)을 쓰거나, 필요한 요청만 골라 내보낸다. 모듈 18b(레슨 9)에서 다룬 원칙이 여기에도 적용된다 — 로그를 붙여 넣기 전에 무엇이 들어 있는지 본다. 특히 HAR을 AI에 그대로 붙여 넣는 것은 위험하다.

Console — 화면에 안 보이는 실패가 찍히는 곳

화면은 멀쩡한데 기능이 안 되는 경우, 원인이 여기 있는 경우가 많다.

Uncaught TypeError: Cannot read properties of null (reading 'message')
    at showError (order.js:142:18)
    at handleSubmit (order.js:88:5)

레슨 1에서 배운 스택 트레이스 읽기가 여기서 쓰인다. 아래에서 위로 읽으면 호출 순서이고, order.js:142 가 실제로 터진 지점이다.

QA가 콘솔에서 챙길 것들이다.

Console에 에러가 있는데 화면에는 아무 표시가 없다 — 이건 그 자체로 결함이다. 사용자는 무슨 일이 일어났는지 알 수 없기 때문이다.

콘솔에서 값을 직접 확인할 수도 있다. 자동화 로케이터를 검증할 때 특히 유용하다.

// 이 선택자로 요소가 몇 개 잡히나 (자동화 로케이터 검증)
document.querySelectorAll('[data-testid="order-btn"]').length
 
// 마지막으로 검사한 요소
$0
 
// jQuery 스타일 단축 선택자 (DevTools 내장)
$$('.product-card').length

두 번째 줄이 실무에서 값을 한다. 모듈 13(레슨 3)에서 배운 안정적인 로케이터를 만들 때, 정말 유일하게 잡히는지 를 여기서 즉시 확인할 수 있다. 1이 아니면 그 로케이터는 불안정하다.

Elements — DOM과 화면의 실제 상태

Elements 패널은 지금 화면에 그려진 실제 DOM 을 보여준다. 원본 HTML이 아니라 자바스크립트가 조작한 이후의 상태다.

QA가 쓰는 방법 셋이다.

1) 로케이터 후보 찾기. 요소를 우클릭 → Copy → Copy selector / Copy XPath. 다만 복사한 선택자를 그대로 자동화에 쓰면 안 된다 — div > div:nth-child(3) > span 같은 형태라 구조가 조금만 바뀌어도 깨진다. data-testid 같은 안정적인 속성이 있는지 먼저 본다.

2) 값을 바꿔 즉석 테스트. DOM을 직접 편집해 긴 텍스트·특수문자를 넣어보면 레이아웃이 깨지는지 바로 보인다. 실제 데이터를 만들지 않고도 경계값을 확인할 수 있다.

3) 접근성 확인. 요소를 선택하면 접근성 트리와 이름(name)·역할(role)이 보이고, 색상 대비도 표시된다. 모듈 16(레슨 7)의 WCAG 점검을 여기서 초벌로 할 수 있다.

기기 에뮬레이션(Toggle device toolbar, Ctrl+Shift+M)도 알아두자. 화면 크기·터치·기기 픽셀 비율을 흉내낸다. 다만 한계가 분명하다 — 실제 기기의 브라우저 엔진·성능·제스처와는 다르다. 모듈 17에서 다루는 모바일 테스트를 대체하지 못하고, 1차 확인용 이다.

Application — 로그인 상태와 저장된 값

레슨 3에서 배운 세션·토큰이 실제로 어디에 저장되는지 보는 곳이다.

마지막 줄이 실무에서 자주 쓰인다. "신규 사용자 상태"를 재현하려고 매번 계정을 새로 만들 필요 없이, 사이트 데이터를 지우면 상당수의 초기 상태가 재현된다.

쿠키의 HttpOnly 속성 확인도 QA의 점검 항목이다 — 인증 쿠키에 이 속성이 없으면 자바스크립트로 읽을 수 있고, 그건 모듈 16(레슨 5)에서 배운 취약점 경로가 된다.

Lighthouse와 Performance — 비기능 초벌 점검

Lighthouse 는 버튼 한 번으로 성능·접근성·SEO·모범사례를 진단해 점수와 개선 항목을 준다. 모듈 16(레슨 4)에서 배운 Core Web Vitals가 여기서 측정된다.

주의할 점 — Lighthouse 점수는 실행할 때마다 흔들린다. 네트워크· CPU 상태에 영향을 받기 때문이다. 점수 하나로 판정하지 말고 추세와 개선 항목 목록을 본다. 모듈 14(레슨 7)에서 SLI를 다룰 때 한 이야기와 같다 — 합성 측정과 실사용자 측정은 다르다.

Performance 패널은 더 깊다. 녹화 후 어느 스크립트가 얼마나 오래 실행됐는지, 긴 작업(long task)이 어디 있는지 보여준다. QA가 여기까지 갈 필요는 대개 없지만, "이 화면이 느리다"를 개발자에게 넘길 때 녹화 파일을 함께 주면 대화가 빨라진다.

증거를 남기는 법 — 리포트에 무엇을 첨부하나

DevTools를 여는 목적은 결국 재현 가능한 리포트 다. 모듈 6(레슨 2)에서 배운 좋은 결함 리포트에 이 레슨의 도구가 더하는 것들이다.

마지막 줄을 빠뜨리면 개발자가 재현하지 못한다. "Slow 4G에서만 재현됩니다"는 결정적인 정보다.

그리고 첨부 전에 확인할 것 하나 — 민감 정보. 스크린샷에 토큰이, HAR에 개인정보가 들어 있을 수 있다. 이슈 트래커는 대개 팀 전체가 보고, 때로는 협력사도 본다.

개발자와 통하는 언어

이 레슨의 도구들이 만드는 실질적 변화는 리포트의 문장 이다.

오른쪽 문장들은 담당자를 특정한다. 400이면 요청을 보내는 쪽, 500이면 서버, 404 리소스면 배포·정적 파일. 모듈 6(레슨 3)에서 배운 비난 없는 소통과도 맞는다 — 사람을 지목하는 대신 사실을 제시 하기 때문이다.

실무에서 왜 필요한가

DevTools는 QA가 가장 자주 쓰게 되는 도구인데, 정작 체계적으로 배우는 경우가 드물다. 대개 "Network 탭에서 빨간 줄 찾기" 정도로 쓰다가 멈춘다. Preserve log 하나만 켜둬도 같은 재현을 두 번 하지 않아도 된다는 것을 아는 사람과 모르는 사람의 하루가 다르다.

그리고 이 도구는 QA의 위치를 바꾼다. "안 됩니다"만 전달하는 사람과 "이 요청이 이 응답을 줍니다"를 전달하는 사람은 개발팀에서 받는 대우가 다르다. 후자는 원인 범위를 좁혀주기 때문에 실제로 팀의 시간을 아낀다.

기초 도구라고 넘기기 쉽지만, 뒤에 오는 것들의 전제이기도 하다. 자동화 로케이터 검증(모듈 13), 성능 초벌 점검(모듈 16), API 요청 확인(모듈 12)이 전부 이 화면에서 시작한다. 다음 레슨(레슨 10)의 Charles·Wireshark는 여기서 안 되는 것 을 위한 도구이므로, 여기가 먼저다.

실습 과제

과제 1 — 네 갈래로 원인 가르기 (20분)

아무 웹 서비스에서 다음을 각각 재현하고, 본문의 네 갈래 중 어디에 해당하는지 판정한다.

각 경우에 어떤 화면을 캡처해 첨부할 것인지 도 적는다.

과제 2 — 쓰로틀링으로 결함 찾기 (20분)

익숙한 서비스에서 Slow 4G 로 설정하고 다음을 시도한다.

1. 제출 버튼을 응답 오기 전에 두 번 이상 눌러본다 → 중복 요청이 가나?
2. 로딩 중 상태 표시가 있는가?
3. 중간에 Offline 으로 바꿔본다 → 어떤 안내가 뜨나?
4. 다시 온라인으로 → 자동 복구되나, 새로고침해야 하나?

발견한 것을 결함 리포트 형태로 하나 작성한다. 네트워크 조건을 반드시 명시 한다.

과제 3 — 로케이터 후보 검증하기 (15분)

임의의 웹 페이지에서 버튼이나 입력창을 하나 고르고, 세 가지 방법으로 선택자를 만든 뒤 콘솔에서 검증한다.

document.querySelectorAll('여기에 선택자').length   // 1이어야 좋다

개수가 1이 아닌 선택자는 자동화에서 쓰면 안 된다. 이유를 한 줄로 적는다.

과제 4 — 증거 세트 만들기 (20분)

실제 결함(또는 의도적으로 만든 상황) 하나에 대해 완전한 증거 세트를 만든다.

• 실패 요청의 Headers·Response 캡처
• 콘솔 에러 전문(있다면)
• HAR 파일 (민감 정보 확인 후)
• 재현 절차와 네트워크 조건
• 기대 결과 / 실제 결과

만든 뒤 스스로 검증한다 — 이것만 받은 개발자가 재현 없이 원인을 좁힐 수 있는가?

자가 체크리스트

• QA가 주로 쓰는 DevTools 패널과 각각의 용도를 말할 수 있다
• Preserve log와 Disable cache를 왜 먼저 켜는지 설명할 수 있다
• Network 목록에서 Status·Size·Time이 각각 무엇을 말하는지 안다
• Fetch/XHR 필터와 status-code: 같은 필터를 쓸 수 있다
• 요청 상세의 Headers·Payload·Response·Timing을 구분해서 볼 수 있다
• 결함 원인을 네 갈래(요청 없음·4xx·5xx·200인데 이상)로 가를 수 있다
• 쓰로틀링으로만 재현되는 결함 유형을 세 가지 이상 들 수 있다
• HAR이 무엇이고 언제 첨부하는지, 그리고 무엇을 조심해야 하는지 안다
• 콘솔 에러의 스택 트레이스를 읽고 어디서 터졌는지 짚을 수 있다
• "콘솔에 에러가 있는데 화면에 표시가 없는 것"이 왜 결함인지 설명할 수 있다
• 콘솔에서 선택자의 매칭 개수를 확인해 로케이터를 검증할 수 있다
• Copy selector로 복사한 선택자를 자동화에 그대로 쓰면 안 되는 이유를 안다
• Application 패널에서 쿠키 속성과 저장된 토큰을 확인할 수 있다
• Clear site data로 초기 상태를 재현할 수 있다
• Lighthouse 점수를 단독 판정에 쓰면 안 되는 이유를 설명할 수 있다
• 기기 에뮬레이션의 한계를 알고, 실기기 테스트를 대체하지 않는다는 것을 안다
• 결함 리포트에 첨부할 증거 종류를 상황에 맞게 고를 수 있다

흔한 실수

• Preserve log를 안 켜고 재현한다. 페이지가 넘어가면서 결정적인 요청이 사라지고, 같은 재현을 다시 하게 된다.
• 요청이 안 나간 것과 실패한 것을 구분하지 않는다. 담당자가 잘못 정해지고 왕복이 시작된다.
• 콘솔을 안 본다. 화면은 멀쩡한데 기능이 안 되는 경우의 원인이 대개 여기 있다.
• Copy selector 결과를 자동화에 그대로 쓴다. 구조가 조금만 바뀌어도 깨진다.
• 선택자가 여러 개를 잡는지 확인하지 않는다. 플래키 자동화의 흔한 원인이다.
• HAR을 확인 없이 공유한다. 토큰·쿠키·개인정보가 그대로 들어 있다. AI에 붙여 넣는 것은 특히 위험하다.
• 빠른 회선에서만 테스트한다. 중복 제출·타임아웃 미처리는 느린 환경에서만 드러난다.
• 네트워크 조건을 리포트에 안 적는다. 개발자가 재현하지 못한다.
• 기기 에뮬레이션을 실기기 테스트로 여긴다. 엔진·성능·제스처가 다르다.
• Lighthouse 점수 하나로 성능을 판정한다. 실행마다 흔들린다. 추세와 항목을 본다.
• 패널 위치를 외운다. UI는 버전마다 바뀐다. "무엇을 보고 싶은가"로 찾는다.

참고 자료

• Chrome DevTools 공식 문서 — 패널별 상세 사용법
• Network 패널 레퍼런스 — 필터 문법과 열 설명
• 네트워크 조건 흉내내기 — 쓰로틀링 설정
• DevTools 콘솔 유틸리티 API — $0, $$() 등
• What's new in DevTools — 버전별 변경 사항
• Lighthouse 문서 — 진단 항목과 해석