오류 재현 절차 작성법, 환경·행동·결과를 분리해 기록하기

기준일 2026-10-21 · AZET 운영팀 작성

이 글은 AZET 운영팀의 오류 기록 작성에 관한 참고용 설명입니다. 아래 승인 문서 사례는 가상으로 구성했으며, 실제 고객의 오류 기록이나 AZET 제품의 동작을 나타내지 않습니다.

“저장하면 내용이 사라집니다.” 이 문장으로 불편은 알 수 있지만 같은 현상을 확인하기는 어렵습니다. 새 문서인지 기존 문서인지, 어느 칸을 바꿨는지, 저장 직후인지 다시 열었을 때인지가 빠져 있기 때문입니다. 재현 절차는 다른 사람이 같은 출발점에서 같은 행동을 따라갈 수 있도록 쓰는 기록입니다.

환경과 출발 상태를 함께 적습니다

앱이나 브라우저의 이름과 버전, 운영체제는 환경 항목에 적습니다. 여기에 사용자 역할, 문서 상태, 필요한 사전 데이터처럼 작업의 출발 조건을 더합니다. 모든 설정을 나열하기보다 증상이 나타난 조건을 먼저 기록하고 미확인 부분은 추측해 채우지 않습니다.

공유할 문서는 테스트용 값으로 구성합니다. 실제 거래처 이름을 지워도 현상이 나타나는지 확인하면 불필요한 자료 노출을 줄일 수 있습니다. 민감한 원본에서만 증상이 나타나더라도 공개 기록에 원본을 붙이지 말고 제한된 확인 방법을 담당자와 정합니다.

행동 하나마다 순서 번호를 붙입니다

다음은 승인 대기 문서의 메모 저장을 확인하는 가상 기록입니다. 화면 이름도 예시이며, 실제 작성에서는 관찰한 메뉴와 버튼의 표시를 옮겨 적습니다.

구분	기록 예시
준비 상태	편집 권한으로 접속, 승인 대기인 테스트 문서 열기
단계 1	메모 칸에 ‘검토 자료 추가’ 입력
단계 2	저장 버튼을 한 번 누름
단계 3	문서 목록으로 이동한 뒤 같은 문서를 다시 엶
기대 결과	다시 연 문서에 입력한 메모가 남아 있음
관찰 결과	메모 칸이 비어 있고 오류 문구는 보이지 않음

‘수정하고 저장한 다음 확인’처럼 여러 행동을 묶으면 어디서 결과가 달라졌는지 찾기 어렵습니다. 버튼을 여러 번 눌렀거나 중간에 화면을 새로 열었다면 그 행동도 순서에 넣습니다. 다만 문제와 무관한 탐색 과정을 정리할 때는 해당 단계를 빼도 현상이 유지되는지 확인합니다.

기대와 관찰 사이에 원인 추측을 넣지 않습니다

기대 결과는 무엇을 근거로 예상했는지 덧붙이면 좋습니다. 화면 설명이나 업무 규칙을 참고했는지, 단순히 그렇게 예상했는지 구분합니다. 기대가 제품의 의도와 다를 수 있으므로 예상 자체를 확정 사양처럼 쓰지 않습니다.

관찰 결과에는 보인 상태를 적습니다. ‘서버가 메모를 삭제함’은 원인을 포함한 해석이고, ‘다시 열었을 때 입력칸이 비어 있음’은 눈으로 확인한 내용입니다. 원인 후보가 있다면 별도 메모로 떼어 두고 재현 사실과 섞지 않습니다.

항상 나타나지 않는 오류는 시도 횟수와 발생 횟수, 달라진 조건을 남깁니다. 확인하지 않은 반복 횟수를 적지 않고, 재현하지 못한 시도도 함께 기록합니다. 환경을 하나 바꿨다면 앞선 결과를 덮어쓰지 말고 별도 시도로 구분해야 비교할 수 있습니다.

마지막으로 동료가 절차만 읽고 시작할 수 있는지 살핍니다. 중간에 설명을 보탰다면 빠진 조건을 본문에 추가합니다. 실제 발송이나 거래를 반복해야 하는 재현은 테스트 환경을 마련한 뒤 진행합니다.

자주 묻는 질문(FAQ)

Q1. 영상만 전달해도 충분한가요? 영상은 행동을 보여 주지만 환경과 기대 결과를 대신하지는 못합니다. 짧은 단계 목록과 증상이 보이는 시점을 함께 남깁니다.

Q2. 한 번만 발생한 오류도 기록하나요? 기록할 수 있습니다. 단발 관찰임을 표시하고, 재시도 여부와 기억이 불확실한 부분을 구분하면 후속 확인에 도움이 됩니다.

AZET 관련 안내는 azet.io에서 확인하세요.