적립 요청이 성공해도 문의가 끝나지 않았을 때

사용자가 광고 미션을 끝냈는데 리워드를 받지 못했다고 문의했습니다. 최근 적립 기록이 있어도 반복 참여에서는 이번 회차의 결과가 아닐 수 있습니다. 운영자는 이번 문의의 근거를 확인하고 적립을 요청한 뒤, 그 상태가 실제 조회에 반영됐는지 알아야 했습니다.

저는 2024년 12월부터 광고 운영 대시보드의 문의 화면, TypeScript API client와 화면용 서버인 BFF의 조회·처리 경로를 맡았습니다. 서버 담당자는 참여·적립 서비스와 응답을 준비했고, 제품 담당자는 운영자의 판단 순서와 출시 범위를 검토했습니다.

한 문의의 근거부터 처리까지 연결하다

상세 화면에는 문의·사용자·캠페인의 식별 정보와 시점, 미션 상태, 이벤트 이력, 처리 이력을 연결했습니다. 자료를 많이 보여주는 것보다 모두 같은 문의를 설명하는지가 중요했습니다. 운영자는 어떤 참여인지 확인하고, 해당 미션의 적립 여부와 처리 가능 여부를 읽은 뒤 적립·완료를 실행할 수 있어야 했습니다.

반복 참여의 복수 이벤트 문맥과 완료 처리자 등 응답만으로 판단하기 어려운 부분은 서버 담당자와 맞췄습니다. 첫 출시는 한 문의의 근거 확인부터 처리까지로 범위를 좁히고, 다른 캠페인 즉시 적용과 완료 취소는 후속으로 나눴습니다. 2025년 1월 14일 운영에 출시했고, 제품 담당자의 실제 CS 처리에서 화면의 편의성을 확인했습니다.

서버가 받았다고 운영 화면도 완료된 것은 아니었다

출시 뒤 실사용에서는 적립 요청 API가 성공해도 화면이 읽는 미션 상태에는 이전 값이 남는 시간차가 드러났습니다. 즉시 완료라고 안내하면 운영자는 아직 반영되지 않은 문의를 끝난 것으로 읽을 수 있었습니다.

저는 요청 수락과 조회로 확인한 상태 반영을 나눴습니다. 요청이 성공하면 미션별로 '확인 중'을 보여주고 1초 간격으로 상태를 다시 읽었습니다. 이전 상태에서 변화가 있거나 적립 완료가 조회되면 확인을 끝냈습니다.

정해둔 재조회 상한에 도달하거나 조회가 실패하면 완료라고 단정하지 않고 추가 확인이 필요하다고 알렸습니다. 상세 화면을 떠날 때는 재조회 타이머와 이벤트 감시도 정리했습니다.

이 변경은 1월 23일 배포했고 페이지 진입을 확인했습니다. 조회로 상태 변화를 확인하는 것은 운영자가 다음 행동을 정할 근거입니다. 지급·정산의 최종 확정은 서버의 책임으로 남습니다. 실제 운영 처리 시간이나 오판 감소율은 확인된 성과로 제시할 수 없습니다.

5월에는 완료·반려 뒤 다음 미처리 문의로 이동하는 흐름을 더했습니다. 현재 처리가 성공한 뒤 다음 문의를 따로 조회했고, 다음 조회가 실패해도 이미 끝난 처리를 실패로 바꾸지 않았습니다. 새 상세 조회가 실패하면 이전 문의의 사용자·캠페인·처리 정보도 비웠습니다. 요청의 성공과 뒤따르는 조회 결과를 분리한다는 원칙을 반복 업무에도 적용한 것입니다.

이 사례의 핵심은 운영 화면에서 API 성공을 업무 완료로 번역하지 않은 것입니다. 운영자가 확인할 근거와 처리 결과를 연결하되, 조회로 확인할 수 없는 경우도 분명히 남겼습니다.