환경과 재현 단계 수집

문의 접수의 목표는 같은 장면을 만드는 것입니다

사용자가 “로그인이 안 됩니다”라고 하면 비밀번호 오류, 세션 만료, 권한 거부, 응답 미수신을 모두 떠올릴 수 있습니다. 지원 담당이 먼저 해결책을 고르면 사용자는 여러 조치를 반복하고 원래 증거는 사라집니다. 접수의 목표는 원인을 맞히는 것이 아니라 사용자와 개발자가 같은 실패 장면을 볼 수 있게 만드는 것입니다. 행사 신청 프로젝트에서는 어느 화면에서 무엇을 눌렀고 어떤 상태를 기대했는지부터 묻습니다. 신입 담당자는 결론보다 기록의 빈칸을 줄이는 데 집중합니다.

이번 모듈의 자료와 실행 방식

미션 starter를 별도 연습 폴더에 풉니다. Python 3 표준 라이브러리와 bash만 사용합니다. 앞 단계의 metrics.json과 근거 파일은 보존하고 support.json을 새로 작성합니다. 제공 문의와 FAQ 확인은 provided-fiction인 가상 자료입니다. 실제 고객의 문의나 운영 해결률로 발표하지 않습니다. 로컬 레슨의 replay.sh는 함수형 모의 API를 호출하며 서버를 띄우거나 외부 통신을 하지 않습니다. 브라우저 Python 실습은 표준 입력 JSON을 읽습니다. 문서 과업은 자동 구조 검사와 동료의 판단 검토를 나누어 진행합니다.

기대 결과를 사용자의 목적에 연결합니다

“잘 되어야 합니다”는 서로 다른 결과를 상상하게 만듭니다. 신청자는 제출 뒤 접수가 되었는지와 참가가 확정되었는지를 구분하고 싶어 합니다. 기대 결과는 “본인 신청 내역에서 접수 상태를 보고 아직 참가 미확정임을 알 수 있다”처럼 관찰할 수 있게 씁니다. 실제 결과에는 화면에 나온 문구를 필요한 부분만 옮깁니다. 버튼이 반응하지 않았다는 말과 응답 확인 불가 문구가 보였다는 말은 다른 증거입니다. 사용자 표현은 인용으로, 담당자의 해석은 별도 가설로 둡니다.

순서가 있는 질문을 합니다

처음 화면, 로그인 여부, 누른 행동, 결과 순으로 한 가지씩 묻습니다. “인터넷 문제였나요?”는 원인을 답에 넣어 사용자를 유도합니다. 대신 “신청 버튼을 누른 뒤 화면에는 어떤 문구가 나왔나요?”라고 묻습니다. 같은 일을 몇 번 했는지와 재시도 전에 내역을 확인했는지도 확인합니다. 이미 재시도했다면 그 사실을 기록하고 첫 시도와 혼합하지 않습니다. 사용자가 모르는 정보는 모른다고 남기며 개발팀이 알아낼 내부 상태를 사용자에게 요구하지 않습니다.

환경은 범위를 비교하는 정보입니다

운영체제와 브라우저 종류·버전, 화면 또는 앱 버전, 계정 역할을 필요한 범위로 수집합니다. 특정 브라우저에서만 발생했는지 비교하려면 “모바일”보다 종류·버전이 유용합니다. 다만 종류가 같다고 원인도 같다고 단정하지 않습니다. 이번 fixture의 모의 브라우저 1.0은 연습용 값입니다. 실무에서는 사용자가 화면에서 확인한 실제 값을 기록하고 확인하지 못한 버전은 미확인으로 둡니다. 주민번호나 개인 기기의 전체 설정은 신청 상태 조회 문의의 재현에 필요하지 않습니다.

시각에는 시간대와 근거를 붙입니다

발생 시각은 2026-10-09T10:00:00+09:00처럼 시간대를 포함합니다. 사용자가 기억한 시각인지 화면에 표시된 시각인지도 적습니다. “방금”이라는 표현은 전달되는 동안 의미가 달라집니다. 정확히 모르면 “한국 시각 오전 10시 전후, 사용자 기억”처럼 범위를 남깁니다. 요청 번호가 있다면 그 번호와 오류 코드를 함께 기록해 내부 로그 검색의 단서를 만듭니다. 번호가 화면에 없으면 null로 남기고 임의 번호를 생성해 서버 요청인 것처럼 쓰지 않습니다.

행동 단계와 처리 결과는 분리합니다

재현 단계는 “본인 계정으로 로그인한다, 신청 내역을 연다, 해당 행사 상태를 확인한다”처럼 순서대로 씁니다. “오류를 해결한다”는 단계가 아니라 목표입니다. 계정 역할이나 세션 만료 같은 전제는 환경 칸에 두고 사람이 누른 행동은 단계 칸에 둡니다. 신청 데이터를 만들기 위해 실제 타인의 계정으로 들어가지 않습니다. 연습용 가명 계정을 사용하고 실제 접근 권한 확인은 승인된 내부 담당자에게 요청합니다. 단계 끝에 기대와 실제를 나란히 쓰면 재현 여부를 판단하기 쉽습니다.

증거를 최소 범위로 받습니다

스크린샷은 오류 영역만 잘라 별도 사본을 만들고 이름·연락처·신청 식별자·주소의 쿼리를 가립니다. 쿠키, 비밀번호, 인증 토큰, 일회용 인증값은 받지 않습니다. 개발자 도구의 전체 요청 복사에는 인증 헤더가 섞일 수 있어 신입 담당자가 사용자에게 무작정 복사를 요구하지 않습니다. 필요한 것은 시각, 행동, 오류 코드, 요청 번호 같은 허용 필드입니다. 가림 처리 후에도 파일명과 화면 주변에 개인 정보가 남았는지 확인합니다. 원본을 공개 이슈에 붙인 뒤 지우는 방식은 수집을 줄이는 방식이 아닙니다.

사실과 가설에 다른 이름을 붙입니다

SUP01의 사실은 모의 응답에 SESSION_EXPIRED가 있다는 것입니다. 실제 서비스도 같은 원인이라는 설명은 아직 가설입니다. 모의 API가 재현되었다고 사용자 환경 전체를 검증한 것은 아닙니다. support.json의 fact와 hypothesis를 나누어 쓰면 개발팀이 확인된 범위와 추가 조사할 범위를 구분할 수 있습니다. 요청 번호가 없는 시간 초과 사례에서는 저장 여부를 미확인으로 남깁니다. 증거가 없다는 이유로 실패라고 쓰거나 해결된 것처럼 답변하지 않습니다.

정보가 부족해도 다음 행동을 안내합니다

기술 정보를 모두 받을 때까지 사용자에게 아무 안내도 하지 않으면 문의가 길어집니다. 확인된 영향과 다음 질문을 짧게 안내합니다. 예를 들어 “접수 여부가 아직 확인되지 않았습니다. 중복 제출 전에 본인 신청 내역에 해당 행사가 있는지 확인해 주세요”라고 말합니다. 내역 조회도 실패하면 시각·코드와 함께 담당자에게 이관합니다. 답변의 목표는 사용자를 진정시키는 문구만 만드는 것이 아니라 현재 불확실성을 줄일 다음 행동을 정하는 것입니다. 해결 예정 시각은 근거 없이 약속하지 않습니다.

기록의 접근과 보관도 결정 사항입니다

앞 모듈 access-policy.json에는 내부 담당자 열람과 문의 종료 후 14일 삭제라는 연습 제안이 있습니다. 실제 보관 정책이 확정되었다고 바꾸지 않습니다. 첨부 파일, 내보내기, 복사한 메모에도 같은 검토가 필요한지 담당자와 확인합니다. 이번 제출물은 가명 자료만 쓰고 이전 정책의 proposed 상태를 보존합니다. 지원 기록은 도움이 되는 증거이지만 오래 쌓아 두는 것이 항상 좋은 것은 아닙니다. 누가 어떤 목적에 필요한지를 문서에 남겨 다음 담당자가 판단하게 합니다.

접수 완료를 검토하는 방법

동료에게 문의 기록만 주고 첫 화면, 행동 순서, 기대와 실제 결과를 말해 보게 합니다. 설명이 달라지면 빠진 전제나 모호한 문구를 보완합니다. 가명 증거 ID를 따라가 같은 응답을 찾는지도 확인합니다. 자동 검사는 필수 필드와 참조를 확인하지만 질문의 중립성이나 캡처의 실제 가림 품질까지 판단하지 못합니다. JSON 검사에서 FAIL ticket: environment가 나오면 원인 추정 문장보다 fixture의 환경과 제출 필드를 먼저 비교합니다. 형식 오류와 판단 오류를 구분하면 수정 순서가 분명해집니다.