문의 100건을 한 번에 바꿨는데, 몇 건만 실패하면?

“실패한 건 다시 누르면 되죠”에서 확인할 게 있어

문의 100건의 담당자를 한 번에 바꾸는 화면을 만들어보자. 결과는 90건 성공, 7건 실패, 3건은 아직 확인이 안 된 상황이야. 이때 ‘일부 실패했습니다. 다시 시도해 주세요’만 보여주면 운영자는 뭘 다시 눌러야 할까. 100건 전체인지, 나머지 10건인지부터 헷갈려.

요청을 받으면 먼저 ‘일괄 변경 버튼을 추가한다’를 ‘완료된 건을 건드리지 않고 남은 건을 확인해서 이어 처리한다’로 다시 적어. 이번 예제의 범위는 문의 담당자 변경이야. 삭제, 환불, 고객 메시지 발송은 빼고 시작해. 같은 재시도라는 이름을 써도 되돌릴 수 있는 범위와 영향이 다르거든.

성공 기준도 버튼이 잘 눌리는지로 잡으면 안 돼. 선택한 100건의 결과가 빠짐없이 남고, 완료된 건이 재실행 대상에 섞이지 않고, 확인 중인 건을 실패로 처리하지 않아야 해. 이 세 가지를 안건 접수서에 먼저 남겨.

작업이 끝났다는 것과 100건이 다 바뀌었다는 건 달라

공개된 Zendesk 문서를 보면 일괄 수정은 전체 작업 상태와 항목별 결과를 나눠 제공해. 이 구조를 보고 확인할 질문이 생겨. 우리 화면이 ‘작업 종료’ 하나만 받아서 전체 성공이라고 표시하는 건 아닌지, 개별 문의의 결과까지 연결할 수 있는지부터 봐야 해. 출처 링크는 글 끝에 모아뒀어.

운영 담당자에게는 실패 직후 어떤 화면을 보고 다음에 무엇을 누르는지 물어봐. 개발 담당자에게는 접수 응답, 항목별 처리 결과, 결과 조회 방식, 현재 담당자와 변경 기록을 구분해서 보여달라고 해. 이 자료가 없으면 화면 문구를 정해도 실제로 표시할 근거가 없어.

확인표에는 ‘필요한 자료 / 현재 제공 여부 / 확인한 사람 / 없는 경우 결정할 일’을 남겨. 특히 결과를 못 받았다는 사실만으로 변경이 안 됐다고 결론 내리면 안 돼. 아래 숫자는 설계를 설명하기 위한 가상 조건이야.

처음 떠올린 전체 재시도는 여기서 바꿔

가장 간단한 안은 100건을 다시 보내는 거야. 화면은 쉽지만 완료된 90건까지 다시 건드려. 그 사이 다른 사람이 담당자를 바꿨다면 이전 요청으로 덮어쓸 수도 있어. 같은 값을 다시 쓰는 경우에도 알림이나 변경 이력이 또 생기는지는 별도로 확인해야 해.

두 번째 안은 실패 7건과 확인 중 3건을 묶어서 다시 보내는 거야. 이것도 확인 중 3건에 이미 반영된 변경이 있는지 설명하지 못해. 그래서 이번 안건은 항목별 결과를 남기고, 실패가 확인된 건만 조건을 다시 확인하는 방식으로 잡아.

대신 이 안은 결과 저장, 조회 화면, 상태 갱신이 필요해. 담당자 변경만 먼저 적용하고, 한 번 선택하는 최대 건수와 조회 간격은 운영량·서버 제한을 확인한 뒤 결정할 거야. 결정 기록에는 선택한 안과 이유뿐 아니라 추가 구현 범위도 같이 적어. ‘안전하게 재시도’ 한 줄이면 다음 사람이 다시 물어보게 돼.

실패 7건도 버튼 하나로 묶으면 안 돼

가상 실패 7건은 일시적인 처리 문제 3건, 권한 문제 2건, 다른 사람이 먼저 수정한 충돌 2건으로 나눠볼게. 여기서 실패는 담당자 변경이 반영되지 않았다고 확인된 경우야. 응답 지연이나 연결 끊김만 관측했다면 확인 중으로 둬.

다시 실행하기 직전에는 지금도 변경 권한이 있는지, 해당 문의가 변경 가능한 상태인지, 처음 확인한 뒤 담당자나 업무 조건이 바뀌지 않았는지를 서버에서 다시 검사해야 해. 화면에서 버튼을 꺼두는 것만으로 처리 조건이 보장되지는 않아.

충돌이 나면 최신 담당자와 내가 바꾸려던 담당자를 함께 보여줘. 최신 내용을 읽었다는 이유만으로 곧바로 덮어쓰지 말고 변경 의도를 다시 확인해. 이 선택은 설계서의 ‘충돌 이후 재확인’과 QA의 ‘다른 사람이 먼저 변경’에 같은 문장으로 연결해.

확인 중 3건은 기존 작업의 결과부터 찾아

요청을 보냈는데 응답을 못 받았다면 기존 작업을 찾을 수 있는 참조값으로 결과를 조회해. 현재 담당자가 목표 값과 같아졌다는 것만으로 내 요청이 성공했다고 기록하면 안 돼. 다른 사람이 바꿨을 수도 있으니까, 요청과 항목별 처리 기록이 연결되는지 봐야 해.

연결된 성공 기록이 확인되면 완료로 옮기고, 미반영이 확인되면 실패 원인에 따라 다음 행동을 정해. 조회가 계속 안 되면 확인 중인 상태와 마지막 확인 시각을 유지하고 운영 확인으로 넘겨. 확인 기한, 담당 팀, 알림 기준은 출시 전에 정할 정책이야. ‘일정 시간이 지났으니 실패’라는 추정을 코드에 넣지 않아.

외부 조회 기록을 영구 보관소처럼 쓰는 것도 확인해야 해. Zendesk의 작업 상태 조회 가능 기간은 생성 뒤 하루야. 우리 서비스가 작업 이력을 얼마나 보관할지는 별도 결정이고, 외부 기록이 없어지기 전에 필요한 처리 근거를 확보할 수 있어야 해. 원문 전체나 고객 개인정보를 무작정 복제하자는 뜻은 아니야. 담당자 식별값, 요청 범위, 처리 결과 등 필요한 항목과 접근 권한·보관 기간을 정해.

화면은 합계부터 보여주고 다음 행동을 나눠

결과 화면 위에는 선택 100건, 변경 완료 90건, 실패 7건, 확인 중 3건을 같은 기준으로 보여줘. 필터를 눌러 7건만 보더라도 전체 요청의 합계는 남겨. 결과 화면을 닫거나 새로고침해도 작업 내역에서 같은 요청을 다시 열 수 있게 하고, 아직 처리 중이면 마지막 확인 시각을 표시해.

상세 행에는 문의 식별값, 변경 전후 담당자, 현재 확인 상태, 원인, 다음 행동이 필요해. 문의 본문은 이 화면의 판단에 꼭 필요할 때만 권한 범위 안에서 열어. 실패를 선택하면 실행 가능한 건만 선택할 수 있게 하고, 조건이 달라진 항목은 제외 이유를 보여줘.

‘다시 시도’ 버튼을 누르면 전체 100건을 보내는 게 아니라 화면에서 다시 확인한 대상과 변경 내용을 보여주는 확인 단계로 넘어가. 여기서 실행하면 새 요청을 만들고 이전 요청과 연결해. 예전 실패 기록을 지워서 처음부터 성공한 것처럼 보이게 만들지는 않아.

기획서와 설계서는 이 부분에서 이어져야 해

기획서에는 왜 전체 재실행을 버렸는지, 담당자 변경까지 어디를 이번 범위로 잡았는지, 무엇이 되면 완료인지 써. 설계서에는 선택한 안을 화면·조건·문구·기록으로 풀어. 같은 내용을 두 번 길게 쓰기보다는 ‘항목별 복구 기준’이라는 이름으로 서로 연결해.

개발 전달 시에는 요청을 보냈다는 기록과 서버가 반영했다는 기록을 구분해달라고 해. 같은 요청을 연달아 눌렀을 때 서버가 중복을 어떻게 식별하고 기존 결과를 돌려주는지도 합의해야 해. 식별값 하나를 만들었다고 중복 처리가 저절로 막히는 건 아니야. 저장 범위, 유효 기간, 요청 내용이 달라졌을 때의 처리까지 정해야 해.

출시 전까지 미정인 항목은 숨기지 말고 담당 역할과 결정 시점을 써. 보관 기간·최대 건수·조회 실패 알림 기준이 정해지지 않았으면 그 기능을 포함한 운영 검수는 끝난 게 아니야.

AI에는 문서 전체를 맡기기 전에 빠진 조건부터 찾아달라고 해

이 안건에서 AI에 맡길 일은 상태표와 문구 사이의 빠진 조건을 찾는 거야. 문의 원문이나 내부 정책을 통째로 넣지 말고, 가상 건수와 확정한 처리 조건, 아직 모르는 항목을 나눠 줘. 아래는 그대로 바꿔 쓸 수 있는 예시 질문이야.

답을 받으면 ‘이 문장이 어떤 조건을 근거로 나왔는지’를 상태표와 맞춰봐. 만약 확인 중 3건을 실패로 합쳤다면 ‘그 세 건은 미반영이 확인되지 않았어. 재실행 대상에서 빼고 결과 조회 경로를 다시 써줘’라고 범위를 좁혀 수정시켜. 이것도 예상 오류에 대한 수정 지시 예시야.

채택할 때는 원래 상태표, AI가 제안한 변경, 채택하거나 제외한 이유, 반영한 설계 항목을 남겨. AI가 정해준 보관 기간이나 재시도 횟수는 확인할 정책 후보로 옮기고, 실제 운영 조건처럼 쓰지 않아. 결과물은 개발자가 구현하고 QA가 확인할 수 있는 문장이어야 해.

가상 문의 담당자 변경을 검토해줘. 100건 중 90건은 성공 확인, 7건은 미반영 확인, 3건은 결과 불명이야. 실패 7건은 일시 문제 3건·권한 문제 2건·수정 충돌 2건이야. 성공은 재실행에서 제외하고, 결과 불명은 기존 요청 결과를 조회해. 실패도 현재 권한·업무 조건·변경 버전을 다시 확인해야 해.
상태별 화면 문구, 사용자 행동, 서버 확인, 저장할 기록을 표로 대조해줘. 서로 충돌하거나 빠진 조건은 근거와 함께 별도로 적어줘. 확인되지 않은 API 기능·조회 간격·보관 기간·성과 수치는 만들지 말고 확인할 질문으로 남겨줘.

QA는 실패 문구보다 다시 눌렀을 때를 봐

검수 자료는 입력 조건, 사용자의 행동, 화면 기대값, 저장 기록 기대값을 한 묶음으로 만들어. ‘부분 실패 문구 표시’만 보면 완료된 건이 뒤에서 다시 처리되는 문제를 놓쳐. 변경 요청 수와 항목별 실행 기록까지 확인해야 해.

이번에 제공하는 예제 검증은 건수 분리와 재실행 대상 선정 규칙을 확인하는 범위야. 실제 고객센터 시스템에 연결해서 요청을 보낸 테스트는 아니야. 출시 검수에서는 같은 문의를 다른 운영자가 수정하는 상황, 응답 유실, 새로고침, 권한 변경을 실제 테스트 환경에서 재현해야 해.

확인 중이 남아 있는데 완료로 닫히거나, 기존에 성공한 항목이 다시 실행되거나, 최신 담당자를 확인 없이 덮어쓰면 출시를 멈춰. 오류를 고친 뒤에는 설계서의 조건과 같은 QA 항목을 함께 갱신해.

다음 사람에게는 이 묶음을 넘겨

전달할 자료는 안건과 범위, 대안을 고른 이유, 상태·문구·동작표, 요청·결과 기록 기준, QA 조건, 미정 항목이야. 파일 이름만 나열하지 말고 ‘무엇을 보면 어떤 결정을 알 수 있는지’를 연결해서 넘겨. 문의 담당자 일괄 변경이라는 같은 안건 이름을 문서마다 유지하면 찾기도 쉬워.

운영 인계에서는 작업 내역에서 미해결 요청을 찾고, 확인 중인 항목의 근거를 보고, 권한 있는 담당자에게 넘기는 순서까지 직접 따라가 봐. 새로운 요청으로 재실행한 뒤에도 이전 결과와 연결되는지 확인해야 해. 아래 전달안을 복사해서 시스템에 맞는 미정 항목을 채우면 돼.

안건: 문의 담당자 일괄 변경의 부분 결과 복구
범위: 담당자 변경만. 삭제·환불·고객 발송 제외.
입력: 선택100 / 완료90 / 실패7 / 확인 중3. 실패=미반영 확인.
결정: 전체 재실행 없음. 성공 제외. 불명은 원 요청 결과 조회.
재실행: 실패 원인 해소와 현재 권한·업무 조건·버전 재확인 후 대상/변경 내용 확인. 새 요청을 원 요청에 연결.
화면: 전체 합계 유지, 상태 필터, 제외 이유, 최신/예정 담당자, 마지막 확인 시각, 작업 내역 재진입.
기록: 요청 범위·행위자·항목 결과·변경 전후·원 요청과 재요청 연결. 문의 본문은 기본 수집하지 않음.
출시 전 결정: 최대 건수 / 조회 간격 / 중복 식별 범위·기간 / 결과 보관·접근 권한 / 미해결 결과 확인 기한·담당·알림.
QA 중단 조건: 성공 재실행, 불명 임의 실패 처리, 재확인 없는 충돌 덮어쓰기.
적용 전: 실제 테스트 환경의 통합 검수와 담당 역할 확인 필요.

출처와 예제 조건

위키렙AI가 공개 API 문서를 참고해 구성한 기획 예제야. 100건과 실패 원인별 수는 가상 입력이고, 실제 서비스 적용·AI 대화 실행·운영 개선 성과는 주장하지 않아. 영어·중국어는 같은 한국어 안건의 현지화야. 문서 확인일: 2026-09-25.

Zendesk — Job Statuses

Zendesk — Protecting against ticket update collisions