재현 절차

들어오는 제보가 "안 돼요" 한 줄이던 시절이 있었습니다. 무엇이 어떻게 안 되는지가 없으니 받는 쪽이 할 수 있는 일은 되묻는 것뿐이고, 고객을 거쳐 답이 돌아오는 데 하루가 걸립니다. 그 하루 사이에 고객은 다른 방법을 찾거나 떠납니다.

되물어 받은 답으로도 화면이 나오지 않으면 그 뒤가 더 나빴습니다. 개발자가 자기 노트북에서 같은 순서를 밟아 봤는데 정상이면 "제 환경에서는 됩니다" 로 티켓이 닫힙니다. 문제가 사라진 것이 아니라 보이지 않는 곳으로 옮겨 간 것이고, 두 주 뒤에 같은 제보가 다시 들어옵니다.

원인이 섞이는 문제도 같이 붙었습니다. 결제가 안 된다는 문의 다섯 건이 한 티켓에 묶여 있는데, 실제로는 카드 한도, 브라우저 확장 프로그램, 우리 쪽 버그가 뒤섞여 있습니다. 순서를 적어 두면 다섯 건이 갈라지고, 갈라지면 우리가 고칠 것만 남습니다. 재현 절차는 그 갈라내는 일을 제보 단계에서 끝내는 기록입니다.

받는 사람이 되묻지 않으려면 여섯 가지가 있어야 합니다.

1. 환경입니다. 브라우저와 버전, 기기, 운영체제, 그리고 어떤 종류의 계정으로 로그인했는지를 적습니다. 무료 계정과 기업 계정에서 다르게 동작하는 기능이 많으니 계정 종류가 특히 자주 원인입니다.
2. 사전 조건입니다. 그 상태에 닿기까지 필요한 준비를 적습니다. "문서가 300개 이상인 계정" 처럼 데이터 양이 조건일 때가 흔하고, 이 줄이 없으면 받는 쪽은 새 계정으로 시도해 보고 정상이라고 판단합니다.
3. 번호를 매긴 조작입니다. 한 줄에 한 동작만 적습니다. "설정을 연다" 는 여러 경로가 있어서 부족하고, "오른쪽 위 계정 사진을 누른다" 처럼 눌린 자리를 적어야 같은 길을 밟습니다.
4. 기대한 결과입니다. 이 줄을 빼먹는 일이 가장 많습니다. 사용자가 무엇을 기대했는지가 없으면 받는 쪽은 지금 동작이 잘못됐다는 사실 자체를 판단할 수 없고, 의도한 동작을 버그로 고치는 일까지 생깁니다.
5. 실제 결과입니다. 오류 메시지는 요약하지 않고 원문 그대로 붙이고, 화면 캡처와 발생 시각을 함께 남깁니다. 시각이 있으면 서버 기록에서 그 구간만 열어 볼 수 있어서 원인 찾는 시간이 크게 줄어듭니다.
6. 재현율입니다. 다섯 번 시도해 몇 번 나왔는지 적습니다. 매번 나오는 것과 다섯 번에 한 번 나오는 것은 원인이 다른 종류이고, 간헐적이라는 사실 자체가 단서가 됩니다. 시간대나 동시 접속 수가 조건일 가능성이 먼저 올라옵니다.

여섯 줄이 다 채워져 있으면 받는 쪽은 읽고 바로 같은 화면을 띄웁니다. 하나라도 비면 그 자리에서 왕복이 한 번 생기고, 왕복 한 번은 대개 반나절입니다.

쓰는 사람은 문제를 겪은 쪽이고 읽는 사람은 고치는 쪽입니다. 둘 사이의 거리가 이 기록의 형태를 정합니다. 겪은 사람은 방금 본 화면을 알고 있어서 당연한 것을 적지 않고, 고치는 사람은 그 당연한 것을 모릅니다. 그래서 양식이 없으면 빠지는 줄이 매번 같습니다.

들어오는 길은 셋입니다. 고객 문의로 들어오면 수아가 받아 절차 형태로 옮겨 적고, 내부에서 발견하면 민서나 지현이 직접 적고, 자동 검사가 실패해서 잡히면 실패한 검사 자체가 절차 역할을 합니다. 세 번째가 가장 정확한데, 검사 코드가 곧 한 줄씩 적힌 조작 목록이기 때문입니다.

읽는 쪽은 고치기 전에 먼저 재현합니다. 화면이 나오면 그때부터 원인을 찾고, 나오지 않으면 빠진 줄을 물어 다시 받습니다. 이 순서를 지키는 이유는 재현하지 않고 고친 코드가 맞는지 확인할 방법이 없기 때문입니다.

결함이 서비스에 끼치는 영향의 크기를 심각도라 하는데, 그 값을 정하는 자리도 여기입니다. 재현율과 영향받는 사용자 범위가 판단 재료이고, 둘 다 위 여섯 줄에 들어 있습니다.

고친 뒤에도 이 기록이 한 번 더 쓰입니다. 브라우저를 실제로 띄워 사용자가 하는 대로 훑는 E2E 테스트의 시나리오로 그대로 옮겨 두면, 같은 문제가 다시 생겼을 때 사람이 아니라 기계가 먼저 잡습니다.

"재현 절차가 없어서 손을 못 댔어요. 계정 종류만 알려 주세요."

빠진 줄 하나 때문에 막혀 있다는 말입니다.

"다섯 번에 한 번 나옵니다. 매번 나오는 게 아니에요."

간헐적이라는 사실을 단서로 넘긴 것입니다.

"이건 기대한 결과가 안 적혀 있는데요. 원래 동작일 수도 있습니다."

버그인지 아닌지부터 판단이 안 된다는 지적입니다.

페이지덱은 제보 양식에 여섯 줄을 빈 칸으로 만들어 두었습니다. 빈 칸이 있으면 사람들이 채우고, 없으면 한 줄로 적어 보낸다는 것을 겪고 나서 바꿨습니다. 양식을 바꾼 뒤 첫 달에 왕복 횟수가 절반으로 줄었습니다.

한 번은 이 기록이 원인을 바로 가리킨 적도 있습니다. 문서 300개가 넘는 계정에서만 검색이 멈춘다는 절차가 들어왔고, 태오가 그 줄을 보고 목록을 한 번에 다 불러오는 코드를 바로 찾아냈습니다. 사전 조건이 적혀 있지 않았으면 새 계정으로 시도해 보고 정상이라고 답했을 건입니다.

길게 쓸수록 좋다고 보는 경우가 가장 많습니다. 정보가 많으면 도움이 될 것 같으니 화면 전체 설명과 그동안의 배경을 다 적습니다. 그런데 받는 쪽이 하는 일은 읽는 것이 아니라 같은 화면을 띄우는 것입니다. 스무 줄짜리 배경 설명 안에 조작 세 줄이 섞여 있으면 그 세 줄을 찾아내는 데 시간이 듭니다. 기준은 길이가 아니라 되묻지 않아도 되는지입니다. 여섯 항목이 각각 한두 줄이면 충분하고, 그보다 길어지면 대개 필요 없는 설명이 붙은 것입니다.

재현되지 않으면 버그가 아니라고 보는 시각도 자주 나옵니다. 확인할 수 없는 것을 고칠 수는 없으니 이 판단은 절반은 맞습니다. 하지만 재현 실패는 두 가지를 뜻할 수 있습니다. 문제가 없는 것과, 절차에 빠진 조건이 있는 것입니다. 시간대나 데이터 양이나 동시 접속처럼 적기 어려운 조건에서만 나오는 결함이 있고, 이런 것은 티켓을 닫으면 다시 들어옵니다. 같은 제보가 두 번 이상 들어오면 재현 실패를 이유로 닫지 않고, 서버 기록 쪽에서 그 시각을 찾아보는 쪽으로 방향을 바꿉니다.