개념
왜 재현이 안 되는가
한 번 목격했는데 다시 시도해도 똑같이 안 생기는 버그는 실무에서 매우 흔하다. 그리고 이 레슨은 앞 레슨들이 모이는 자리다 — 숨은 변수(5), 순서와 동시성(6), 상태(8), 바깥(9)이 전부 재현을 어렵게 만드는 원인이기 때문이다.
원인은 대체로 다음 중 하나다.
- 레슨 5에서 배운 숨은 변수가 그때만 특정 값이었다 (예: 그 순간만 네트워크가 느렸다)
- 동시성 문제(race condition): 아주 좁은 타이밍에만 발생한다
- 이전 세션에서 남은 상태가 우연히 이번 세션에 영향을 줬다 (캐시, 이전에 열어둔 탭 등) — 레슨 8의 "보이지 않는 상태" 다
- 외부 서비스의 일시적 장애(레슨 9)
- 그 순간에만 많았던 부하 — 다른 사람들이 동시에 몰렸다
목록을 한 번 더 뒤집어 보면 공통점이 보인다. 넷 다 내가 통제하지 않는 무언가가 그 순간에만 특정 상태였다는 것이다. 그래서 같은 절차를 반복해도 그 상태가 안 돌아오면 재현되지 않는다.
여기에 자주 빠지는 다섯 번째가 있다. 내가 기억하는 절차가 틀렸다. 사람은 자기가 한 행동을 정확히 기억하지 못한다. 뒤로가기를 한 번 더 눌렀거나, 다른 탭에서 뭔가 했거나, 평소와 다른 순서로 눌렀을 수 있다. 그래서 "그대로 다시 했다" 는 말 자체가 대개 사실이 아니다.
이 다섯 번째가 중요한 이유는, 대응 방법이 완전히 다르기 때문이다. 앞의 넷은 조건을 찾아야 하고, 다섯 번째는 기록이 있으면 바로 해결된다.
그리고 재현이 안 되는 것과 "안 중요한 것" 은 전혀 다르다. 오히려 반대인 경우가 많다. 레슨 3에서 본 세 사례를 떠올려 보면 셋 다 조건이 좁아서 평소에는 안 나던 것이었다.
재현 확률이라는 관점
"재현된다 / 안 된다" 는 이분법이 실제와 안 맞는다. 현실은 확률이다.
| 재현률 | 어떻게 다루나 |
|---|---|
| 매번 | 일반 결함. 바로 리포트 |
| 절반쯤 | 타이밍이나 순서가 걸려 있다. 조건을 좁힌다 |
| 열 번에 한 번 | 숨은 변수가 여럿 겹친다. 반복 시도로 확률을 잰다 |
| 한 번 보고 못 봄 | 증거가 전부다. 패턴이 쌓이기를 기다린다 |
두 번째와 세 번째에서는 횟수를 세는 것 자체가 정보다. "20번 중 3번 발생" 은 "가끔 발생" 보다 훨씬 쓸모 있다. 개발자가 확률을 보고 원인을 좁힐 수 있기 때문이다 — 절반이면 둘 중 하나를 고르는 분기이고, 열 번에 한 번이면 더 드문 조건이다.
그래서 재현이 안 될 때 먼저 할 일은 포기가 아니라 세어 보는 것이다. 10번 더 해 보는 데 5분이면 되고, 그 5분이 "1회 목격" 을 "10회 중 2회 발생" 으로 바꾼다.
절대 무시하면 안 되는 이유
"어? 이상하네, 다시 해보니 안 되네"라며 넘어가고 싶은 유혹이 크다. 하지만 재현이 안 된다는 것이 결함이 없었다는 뜻은 아니다. 오히려 가장 심각한 실무 버그(동시성 문제, 메모리 누수, 경합 조건)일수록 재현이 어렵다 — 조건이 좁고 우연히 맞아떨어져야 하기 때문이다.
그리고 재현이 어려운 결함일수록 사용자에게는 더 자주 일어난다. 역설처럼 들리지만 이유가 있다 — 나는 혼자 한 번 쓰지만, 사용자는 수만 명이 동시에 다양한 환경에서 쓴다. 나에게 100번에 한 번인 것이 사용자 10만 명에게는 하루 1,000번이다.
이 계산을 리포트에 적으면 우선순위가 달라진다. "가끔 발생" 은 묻히지만 "10번에 1번이면 일 사용자 기준 하루 수천 건" 은 묻히지 않는다.
목격한 순간, 무엇을 해야 하는가
- 즉시 멈추고 증거부터 남긴다. 스크린샷, 콘솔 로그(레슨 4), 네트워크 로그, 정확한 시각을 캡처한다. 다음 행동을 하기 전에 먼저 증거부터다. 새로고침·뒤로가기는 그 전에 절대 누르지 않는다.
- 그 순간까지의 전체 맥락을 최대한 복원한다. 방금 한 행동뿐 아니라, 이 세션에서 그 전에 했던 모든 행동, 열려 있던 탭, 걸린 시간을 되짚어본다 — 숨은 변수(레슨 5)를 찾는 것과 같은 작업이다.
- "재현 안 됨"을 숨기지 않고 정직하게 보고한다. 결함 리포트에 "1회 목격, 재현 조건 불명, 증거 첨부"라고 명확히 적는다. 확신에 찬 것처럼 과장하지도, 무시하지도 않는다.
- 비슷한 보고가 또 있는지 찾아본다. 한 번은 우연일 수 있지만, 비슷한 재현 불가 보고가 여러 번 쌓이면 패턴이 보이기 시작한다 — 이건 모듈 6(결함 관리)에서 다룰 결함 이력 관리와 연결된다.
- 세어 본다. 증거를 다 챙긴 뒤 같은 절차를 10~20번 반복해 재현률을 만든다. "1회 목격" 과 "20회 중 3회" 는 다른 리포트다.
증거의 우선순위 — 30초 안에 챙길 것
"증거를 남겨라" 는 말은 쉽지만 그 순간에는 당황한다. 순서를 정해 두면 손이 먼저 움직인다. 위에서부터, 사라지기 쉬운 것부터다.
| 순서 | 챙길 것 | 왜 먼저인가 |
|---|---|---|
| 1 | 화면을 건드리지 않는다 | 새로고침하면 전부 사라진다 |
| 2 | 화면 캡처 | 가장 빨리 남길 수 있다 |
| 3 | 콘솔·네트워크 탭 캡처 | 다음 행동을 하면 덮인다 |
| 4 | 정확한 시각 | 로그를 찾을 유일한 열쇠 |
| 5 | 네트워크 기록 내려받기 | 요청·응답 전체가 담긴다(레슨 4) |
| 6 | 저장소·다른 화면 확인 | 데이터가 어떤 상태인지 |
1번이 가장 중요하고 가장 자주 어긴다. 이상한 것을 보면 반사적으로 새로고침하게 되는데, 그 순간 콘솔과 네트워크 기록이 전부 날아간다. 손을 떼는 것이 첫 동작이다.
그리고 이 목록은 세션 시작 루틴과 짝이다(레슨 4). 개발자 도구를 처음부터 열어 두고 기록 보존을 켜 뒀다면 3·5번이 이미 쌓여 있다. 안 열어 뒀으면 그 순간에는 아무것도 못 챙긴다.
재현이 안 되는 것 자체가 단서다
어떤 식으로 재현이 안 되는지가 원인의 방향을 알려 준다.
| 어떻게 안 되나 | 의심할 것 |
|---|---|
| 같은 계정에서는 다시 안 되는데 새 계정에서는 된다 | 한 번 생긴 상태가 남아 있다 |
| 다음 날 다시 하면 된다 | 시간·캐시·일일 한도 |
| 내 컴퓨터에서만 안 된다 | 브라우저 설정·확장 프로그램·저장된 값 |
| 빠르게 하면 되고 천천히 하면 안 된다 | 타이밍·동시성 |
| 아무 규칙도 안 보인다 | 외부 요인. 운영 기록을 봐야 한다 |
첫 줄이 특히 유용하다. 새 계정에서 재현되면 그 계정에만 생긴 상태가 원인이고, 반대로 새 계정에서는 안 되면 오래된 계정의 무언가가 조건이다. 둘 중 어느 쪽인지만 알아도 범위가 절반으로 준다.
그래서 재현 시도를 할 때는 환경을 하나씩 바꿔 가며 한다. 같은 계정 → 새 계정 → 다른 브라우저 → 다른 기기 순으로 해 보면, 어디서 달라지는지가 드러난다.
녹화는 이 레슨의 최고 도구
화면 녹화를 켜 두는 습관 하나가 이 레슨 전체를 바꾼다.
- 내가 뭘 했는지 정확히 돌려 볼 수 있다 — 위의 다섯 번째 원인 ("기억이 틀렸다")이 통째로 해결된다
- 잠깐 떴다 사라진 오류 문구를 느리게 돌려 읽을 수 있다
- 리포트에 그대로 첨부할 수 있다. 글보다 빠르다
- 시각이 함께 기록된다
비용도 거의 없다. 세션 시작할 때 켜고 끝나면 지우면 된다. 결함이 나온 세션의 녹화만 남긴다.
다만 녹화에 민감 정보가 담길 수 있다. 실제 고객 데이터가 보이는 화면이라면 공유 범위를 제한하거나 가린다. 시험 데이터로 하는 것이 원칙인 이유가 여기서도 통한다(레슨 5).
조건을 좁히는 방법
증거를 챙겼으면 포기하기 전에 30분만 더 써 볼 가치가 있다. 순서가 있다.
하나, 그대로 반복한다. 10~20번. 재현률을 잰다. 한 번이라도 다시 나면 그때부터는 훨씬 쉬워진다.
둘, 조건을 하나씩 더한다. 처음 목격했을 때와 지금의 차이를 떠올려 하나씩 맞춘다 — 그때는 다른 탭이 열려 있었나, 데이터가 더 많았나, 오래 켜 둔 상태였나(레슨 5의 일곱 묶음).
셋, 느리게 만든다. 타이밍 문제라면 통신을 느리게 하거나 데이터를 늘리면 창이 넓어져 재현률이 올라간다. 가장 잘 통하는 요령이다.
넷, 여러 번 동시에 한다. 동시성 문제라면 두 창에서 동시에 같은 동작을 하면 확률이 크게 오른다(레슨 6).
다섯, 데이터에서 찾는다. 내 손으로 못 만들면 이미 일어난 것들의 공통점을 본다. 운영 기록이나 문의 이력에서 같은 현상을 찾아 날짜· 계정·기기를 비교한다(레슨 5의 월말 정산 사례).
다섯 번째가 가장 확실하다. 이미 일어난 일에는 반드시 조건이 있었고, 그 조건은 데이터에 남아 있다.
개발자가 "재현 안 되는데요" 라고 할 때
가장 흔한 마찰 지점이다. 감정이 섞이기 쉬운데, 그 말은 대개 사실이다 — 개발자도 재현을 못 한 것이 맞다. 다툴 일이 아니라 다음 수를 제안할 일이다.
| 쓸 수 있는 수 | 말하는 법 |
|---|---|
| 재현률을 붙인다 | "20회 중 3회였습니다. 조건은 이렇습니다" |
| 서버 기록을 요청한다 | "14:32 전후 기록을 봐 주실 수 있을까요" |
| 운영 데이터를 찾는다 | "비슷한 현상이 운영에서 7건 있었습니다" |
| 환경을 맞춘다 | "제 환경은 이렇습니다. 같은 조건에서 해 보셨나요" |
| 함께 본다 | "같이 한 번 보시겠어요" — 가장 빠를 때가 많다 |
두 번째가 가장 효과적이다. 화면에서 재현이 안 돼도 서버 기록에는 그 순간이 남아 있다. 시각을 정확히 적어 둔 이유가 여기서 쓰인다.
마지막도 과소평가된다. 15분 같이 앉아 보면 내가 당연하게 하던 동작을 개발자가 발견하는 경우가 많다. 레슨 13의 짝 탐험이 이 상황에서 특히 효과적인 이유다.
그리고 닫히는 것을 막는 것이 목적이 아니다. 지금 못 고쳐도 괜찮다 — 검색 가능한 상태로 남겨 다음 보고와 연결되게 하는 것이 이 단계의 목표다.
실무에서 왜 필요한가
이 레슨의 내용은 탐험 밖에서 더 많이 쓰인다. 운영 중 들어오는 문의의 상당수가 "가끔 이래요" 형태이고, 그때 쓰는 방법이 똑같기 때문이다 — 증거를 모으고, 재현률을 재고, 조건을 좁히고, 쌓인 것에서 패턴을 찾는다.
팀은 재현이 안 되는 버그 리포트를 "사용자 실수"나 "일시적 착오"로 치부하고 덮어버리기 쉽다. 이게 실제로는 조용히 방치된 동시성 버그가 프로덕션에서 계속 사용자에게 영향을 주는 상황으로 이어질 수 있다. 목격 즉시 증거를 남기는 습관이 있는 QA는, 나중에 비슷한 보고가 쌓였을 때 팀이 그 패턴을 실제로 찾아낼 수 있는 기반을 만든다. "어차피 재현 안 되니까 소용없다"는 태도가 가장 위험하다.
반대로 이 능력이 있는 QA 는 팀에서 "그건 어떻게 알았어요" 를 듣는 사람이 된다. 재현 불가 결함을 조건까지 좁혀 낸 경험은 몇 번만 쌓여도 신뢰로 바뀌고, 그 신뢰가 다음 리포트를 더 빨리 처리되게 만든다.
언제 멈추나
조건을 좁히는 일은 끝이 없을 수 있다. 멈추는 기준을 정해 두지 않으면 하루가 간다.
- 30분 규칙 — 증거를 챙긴 뒤 30분 더 쓴다. 그 안에 실마리가 없으면 리포트를 쓰고 넘어간다
- 영향이 크면 더 쓴다 — 돈·개인정보·안전이 걸렸으면 시간을 더 쓸 가치가 있다. 판단 기준은 레슨 3의 우선순위와 같다
- 혼자 막히면 사람을 부른다 — 30분 혼자 보는 것보다 15분 같이 보는 편이 빠를 때가 많다
그리고 멈추더라도 차터에 남긴다. "이 현상, 조건 미상" 을 적어 두면 다음 세션의 출발점이 되고, 나중에 같은 것을 또 보면 바로 연결된다.
멈추는 것이 포기가 아니라는 점이 중요하다. 증거를 남기고, 숫자를 만들고, 검색 가능하게 기록한 뒤 멈추는 것은 다음 사람이 이어받을 수 있는 상태로 넘기는 것이다.
정직한 리포트의 모양
재현이 안 될 때 리포트를 안 쓰거나, 반대로 확신에 찬 척 쓰는 것이 둘 다 흔하다. 불확실한 것을 불확실하다고 적는 것이 정답이고, 그래도 쓸모 있는 리포트가 된다.
제목: [1회 목격·재현 불가] 결제 완료 직후 화면이 흰 화면으로 멈춤
발생: 2026-10-05 14:32 경 (정확한 시각: 네트워크 기록 참조)
재현: 20회 시도, 재현 안 됨
목격 당시 상황 (기억에 의존, 불확실)
- 장바구니 상품 12개, 쿠폰 1장 적용
- 결제 직전에 다른 탭에서 같은 계정으로 마이페이지를 열어 둠
- 통신이 느렸던 것 같음 (확실하지 않음)
증거
- 화면 캡처, 콘솔 캡처(TypeError 1건), 네트워크 기록 파일 첨부
- 저장소 확인: 주문은 정상 생성됨. **결제도 완료됨**
영향 추정
- 사용자는 결제가 실패한 줄 알고 다시 시도할 수 있음 → 중복 결제 위험
요청
- 같은 시각의 서버 기록 확인 부탁드립니다
- 비슷한 문의가 접수된 적 있는지 확인 중여기서 중요한 것이 셋이다.
하나, 제목에 "재현 불가" 를 적는다. 숨기면 개발자가 재현부터 시도하다 시간을 쓰고 "재현 안 됨" 으로 닫는다. 처음부터 알려 주면 다른 방법으로 접근한다.
둘, 확실한 것과 추측을 구분해 적는다. "통신이 느렸던 것 같음(확실하지 않음)" 처럼 적는다. 추측을 사실처럼 적으면 엉뚱한 곳을 파게 되고, 다음부터 그 리포트를 안 믿게 된다.
셋, 영향을 추정해 적는다. 재현이 안 되면 우선순위가 바닥으로 가기 쉬운데, "중복 결제 위험" 한 줄이 그 판단을 바꾼다.
그리고 요청 줄을 꼭 넣는다. 재현 불가 결함은 혼자 못 닫는다 — 서버 기록, 문의 이력, 다른 환경의 데이터가 필요하고, 그걸 가진 사람에게 부탁하는 것까지가 리포트의 일이다.
사례 — 세 건이 한 건이었다
누적 관리가 왜 필요한지 보여 주는 흐름이다. 석 달에 걸쳐 들어온 세 건이 사실 하나였다.
| 시점 | 보고 | 그때의 판정 |
|---|---|---|
| 3월 | "주문 목록이 가끔 안 뜬다" | 재현 안 됨. 닫힘 |
| 4월 | "결제하고 나면 가끔 멈춘다" | 재현 안 됨. 닫힘 |
| 5월 | "마이페이지가 느리다는 문의" | 성능 문제로 분류 |
셋 다 따로 처리됐고 셋 다 해결되지 않았다. 6월에 월 1회 모아 보기를 시작하면서 공통점이 보였다.
- 셋 다 주문 이력이 많은 계정에서 발생
- 셋 다 월초에 집중
- 셋 다 목록을 불러오는 화면
원인은 하나였다. 주문 이력이 일정 수를 넘으면 목록 조회가 급격히 느려지고, 월초에 정산 작업이 겹치면 시간 초과가 났다. 한 사람이 세 번 다 봤다면 바로 알았을 것이고, 따로따로 봤기 때문에 석 달이 걸렸다.
여기서 배울 것은 각 보고가 부실했다는 것이 아니다. 셋 다 정직하게 보고됐다. 문제는 연결되지 않았다는 것이고, 그것은 보고하는 사람이 아니라 쌓아 두는 방식의 문제다.
쌓여야 보이는 것들
한 건으로는 아무것도 못 한다. 세 건이 모이면 패턴이 된다. 그래서 재현 불가 결함은 개별 처리보다 누적 관리가 핵심이다.
| 할 일 | 왜 |
|---|---|
| 같은 이름표를 붙인다 | 나중에 모아 볼 수 있다 |
| 바로 닫지 않는다 | 닫으면 검색에서 사라진다 |
| 새 보고가 오면 기존 것에 붙인다 | 건수가 쌓여야 패턴이 보인다 |
| 주기적으로 모아 본다 | 월 1회면 충분하다 |
모아 볼 때는 공통점을 축으로 센다 — 같은 기기인가, 같은 시간대인가, 같은 기능인가, 같은 종류의 계정인가. 레슨 5의 일곱 묶음이 그대로 축이 된다.
실무에서 가장 흔한 실패는 "재현 안 됨" 으로 닫아 버리는 것이다. 닫히면 다음 사람이 같은 것을 보고해도 연결되지 않는다. 열어 두거나, 닫더라도 검색 가능한 상태로 남긴다(모듈 6).
채용시장에서의 위치
"가장 어려웠던 결함" 은 면접 단골 질문이고, 그 답으로 재현 불가 결함을 고르는 사람이 많다. 그런데 결말이 답의 질을 가른다.
- "결국 못 찾았습니다" — 흔하고 인상이 약하다
- "20번 돌려 재현률을 재고, 느린 통신에서 확률이 올라가는 걸 확인하고, 운영 기록에서 같은 현상 7건을 찾아 공통점을 짚었습니다" — 방법을 가진 사람이다
두 번째 답에는 이 레슨의 거의 전부가 들어 있다. 그리고 중요한 것은 결함을 끝내 못 고쳤더라도 이 답이 좋다는 점이다. 면접관이 보는 것은 결과가 아니라 막혔을 때 무엇을 하는가다.
또 자주 나오는 질문이 있다. "개발자가 재현 안 된다고 닫으면 어떻게 하시나요?" 여기서 감정이 아니라 증거와 숫자로 답하는 사람이 드물다. "재현률과 영향 추정을 붙여 다시 올렸고, 운영 기록 확인을 요청했습니다" 가 이 레슨이 가르치는 답이다(모듈 6 레슨 3).