AI 에이전트 성공 응답을 믿지 않는 프론트엔드 설계

AI 에이전트가 success라는 문자열을 돌려줬다고 해서 데이터가 한 번만 저장됐다는 뜻은 아니에요. 응답을 받은 뒤 화면이 다시 렌더링되거나, 사용자가 버튼을 2회 누르거나, 네트워크 재시도가 겹치면 같은 쓰기 요청이 반복될 수 있어요.

직접 만들어 보니 문제는 API 응답보다 화면 상태에서 먼저 드러났어요. 완료 토스트는 보이는데 목록에는 항목이 2개 생기거나, 로딩 버튼이 풀린 뒤 다시 클릭할 수 있는 흐름이었어요. AI 도구의 결과 문구를 신뢰 표시로만 쓰고, 실제 저장 상태는 별도로 다뤄야 했어요.

버튼 클릭→멱등키 생성 또는 재사용→쓰기 요청→저장 결과를 화면에 반영

성공 문자열은 화면 상태가 아니에요

프론트엔드에서는 쓰기 요청을 최소 3개 상태로 나누는 편이 이해하기 쉬워요.

• idle: 아직 요청하지 않은 상태
• pending: 요청을 보냈고 결과를 기다리는 상태
• completed 또는 failed: 서버가 확인 가능한 결과를 돌려준 상태

테스트해 보면 pending 상태에서 버튼을 비활성화하는 것만으로는 부족해요. 사용자가 새로고침할 수 있고, 요청 자체가 재전송될 수 있기 때문이에요. 그래서 요청 1건마다 멱등키 1개를 만들고, 재시도에는 같은 키를 다시 보내는 방식이 필요해요.

멱등키는 화면의 약속이기도 해요

적용해 봤더니 멱등키를 API 헤더나 요청 본문에 넣는 일보다, 키를 언제 새로 만들지 정하는 일이 더 중요했어요. 새로운 작성 시작에는 새 키를 만들고, 실패 후 재시도에는 기존 키를 유지해야 해요. 서버는 같은 키의 요청을 다시 받으면 이전 결과를 돌려주거나 중복 생성을 막아야 하고요.

돌려 보니 UX 문구도 달라졌어요. “저장 완료”를 먼저 보여주기보다 “저장 중”, “저장 결과를 확인하는 중”, “다시 시도”처럼 현재 상태를 드러내는 편이 혼란을 줄였어요. 실패 화면에는 재시도 버튼 1개와 취소 버튼 1개를 두면 다음 행동도 분명해져요.

• ✓성공 문구와 저장 확인 분리
• ✓재시도에는 동일 멱등키
• ✓화면은 3개 이상 상태로 표현

라이프케어로그의 플랜비(plan-b)처럼 회비나 출전 정보를 다루는 화면이라면, 같은 저장 요청이 중복되는 상황을 더 조심해야 해요. AI 에이전트가 작업을 끝냈다고 말하는 순간과 사용자가 화면에서 확인할 수 있는 순간은 같지 않을 수 있어요. 프론트엔드는 그 사이를 상태, 재시도, 멱등키로 연결하는 역할을 해요.