AI 오류 보고서 프롬프트: 재현 단계·기대 결과·실제 결과를 나누기

문제가 생긴 조건을 관찰 사실로 기록합니다

가상 문제는 모바일 화면에서 날짜를 선택한 뒤 다음 버튼을 눌렀는데 입력 내용이 사라지는 상황입니다. 기기 유형, 브라우저, 접속 경로, 로그인 여부, 시도 시각을 가능한 범위에서 적습니다. 개인정보나 인증 정보는 빼고 오류 화면에도 민감한 값이 남지 않게 확인하세요.

“서버가 느려서 초기화된다”는 원인 추측입니다. 실제로 확인한 것은 버튼을 누른 뒤 어떤 값이 사라졌는지입니다. 화면 멈춤, 입력 초기화, 오류 메시지는 서로 다른 현상이므로 따로 적습니다. 원인을 몰라도 재현 단계와 실제 결과가 분명하면 조사에 유용한 보고서가 됩니다.

한 단계에는 하나의 조작만 씁니다

“예약하고 다음으로 간다”보다 “예약 페이지 열기, 날짜 선택, 인원 입력, 다음 버튼 한 번 누르기”로 나눕니다. 같은 문제가 항상 생기는지 일부 시도에서만 생기는지도 기록합니다. 여러 번 눌렀을 때와 한 번 눌렀을 때 결과가 다르면 그 차이가 중요한 단서가 될 수 있습니다.

기대 결과는 사용자가 생각하는 바람보다 제품의 확인된 동작 기준을 써야 합니다. 기준이 없으면 “사용자가 기대한 결과”라고 표시합니다. 예를 들어 다음 단계에서 선택한 날짜가 유지될 것으로 기대했다는 설명은 가능하지만 설계상 반드시 그래야 한다고 단정하려면 사양을 확인해야 합니다.

오류 메모 구조화용 복사 프롬프트

AI에게 로그나 코드를 주지 않았는데 원인을 확정하게 하지 마세요. 불명확한 정보는 추가 확인 질문으로 남기고, 재현 확인을 직접 한 것처럼 표현하지 않도록 합니다.

아래 가상 사용자 메모를 개발팀에 보낼 오류 보고서로 정리하세요. 직접 재현한 것처럼 쓰지 않습니다.
구성: 짧은 제목 / 관찰 환경 / 재현 단계 / 기대 결과 / 실제 결과 / 발생 빈도 / 첨부 증거 목록 / 추가 확인 질문.
메모: 모바일 예약 폼에서 날짜를 고르고 인원 2명을 입력한 뒤 다음 버튼을 눌렀더니 날짜가 비었다. 브라우저 버전과 반복 여부는 아직 확인하지 않았다.
확인되지 않은 환경과 원인은 추정하지 마세요. 서버 오류·네트워크 오류 같은 가설은 관찰 사실과 분리합니다. 개인정보·인증정보를 보고서에 넣지 않도록 검토하세요.

좋은 제목은 위치와 동작과 결과를 담습니다

“예약 오류”보다 “모바일 예약 폼에서 다음 버튼 선택 후 날짜 입력값이 사라짐”이 문제를 구분하기 쉽습니다. 제목에 원인으로 추정한 기술 용어를 넣을 필요는 없습니다. 같은 화면의 다른 오류와 구별할 정도의 범위가 있으면 됩니다.

본문의 실제 결과도 “안 됨”으로 끝내지 않습니다. 날짜가 비었는지, 인원은 남았는지, 오류 문구가 있었는지 적습니다. 화면 녹화가 있다면 문제 발생 구간을 짧게 표시하고 파일을 열 수 있는지 확인합니다. 영상에 다른 고객 정보가 보이면 가린 사본을 사용하거나 필요한 부분만 별도로 제공합니다.

재현 여부와 영향도를 나눠 평가합니다

매번 발생하는 작은 표시 오류와 드물지만 예약이 중복되는 오류는 우선순위가 다를 수 있습니다. 빈도만으로 중요도를 정하지 말고 어떤 사용자가 어떤 작업을 완료하지 못하는지 적습니다. 데이터 손실이나 중복 처리처럼 영향이 큰 의심은 담당자가 확인할 수 있도록 구체적인 관찰을 남깁니다.

다만 실제로 확인하지 않은 피해를 부풀리지 않습니다. “날짜 입력이 사라졌다”는 관찰만으로 모든 예약 데이터가 삭제됐다고 보고하면 조사 방향이 틀어질 수 있습니다. 확인 범위와 미확인 범위를 나누고 필요한 경우 담당자가 안전한 시험 환경에서 추가 확인하도록 합니다.

재현되지 않는 경우도 결과로 남깁니다

동료의 기기에서는 같은 오류가 나타나지 않을 수 있습니다. 이를 곧바로 사용자의 착오로 결론내리지 말고 환경 차이를 기록하세요. 가상 사례에서 한 기기는 모바일 브라우저, 다른 기기는 데스크톱 브라우저였다면 비교 조건이 같지 않습니다. 로그인 여부, 입력한 날짜, 접속한 경로도 차이를 만들 수 있으므로 확인된 항목만 대조합니다.

추가 시험을 할 때는 실제 예약이나 결제가 발생하지 않는 승인된 환경을 사용해야 합니다. 오류를 확인하려고 여러 번 전송해 중복 작업을 만들지 않도록 담당자의 절차를 따르세요. 보고서에는 “어떤 조건에서 재현됨”, “어떤 조건에서 재현되지 않음”을 함께 남깁니다. AI가 원인 후보를 제시해도 그것은 조사 방향일 뿐 확인된 원인이 아닙니다. 환경 비교에서 얻은 새 사실을 보고서에 추가하고 미확인 칸을 무리하게 채우지 않습니다.

수정 뒤에는 같은 단계와 관련 흐름을 확인합니다

오류가 수정됐다는 안내를 받으면 처음 보고한 환경과 단계로 결과를 다시 확인합니다. 날짜가 유지되는지뿐 아니라 인원 입력과 다음 단계 이동도 정상인지 살핍니다. 재현되지 않는다고 무조건 완치라고 표현하기보다 확인한 환경과 시도를 기록하세요. 다른 조건에서는 별도 문제가 있을 수 있습니다.

보고서에는 최초 상태, 확인한 수정 버전, 재검증 결과를 남깁니다. AI는 이 기록을 정리할 수 있지만 실제로 버튼을 눌러 확인하지 않았다면 검증 완료라고 쓰면 안 됩니다. 오류 보고의 가치는 기술 용어의 많고 적음보다 다른 사람이 같은 조건을 따라가며 현상을 확인할 수 있는지에 있습니다.