WEB-FE-02 · 사용자 동작과 화면 상태

사용자는 버튼 하나를 누르지만 프론트엔드는 입력을 읽고, 요청을 시작하고, 응답을 기다린 뒤 결과를 표시합니다. 이 과정을 하나의 성공 상태로만 만들면 느린 요청, 빈 데이터와 오류가 모두 멈춘 화면처럼 보입니다.

예를 들어 영업부 9월 외주비를 선택했을 때 결과가 없는 경우와 서버 연결이 끊긴 경우는 다릅니다. 전자는 “해당 조건의 전표가 없습니다”, 후자는 “조회에 실패했습니다. 다시 시도하세요”로 보여야 합니다. 사용자는 문구를 보고 다음 행동을 결정합니다.

입력에서 화면 갱신까지

사용자 동작 처리
사용자 입력
→ 클릭 또는 제출 이벤트
→ 프론트엔드 입력 확인
→ 로딩 표시
→ API 요청
→ 응답 확인
→ 데이터 또는 오류 표시

브라우저 검사는 필수값 누락을 바로 알려 사용자 경험을 개선합니다. 하지만 브라우저 요청은 수정해서 보낼 수 있으므로 같은 조건을 백엔드에서도 다시 검증해야 합니다.

구분해야 하는 화면 상태

상태화면에 보여 줄 내용구분하는 이유
초기아직 실행하지 않았다는 안내결과가 0건이라는 뜻과 다름
로딩요청을 처리 중이라는 표시와 중복 실행 방지멈춘 화면으로 오해하지 않게 함
성공받은 데이터와 완료된 작업실제 응답으로 성공을 확인
빈 결과정상 조회했지만 표시할 데이터가 없음오류나 로딩과 다름
오류실패한 작업과 다시 시도 방법이전 성공 데이터를 새 결과처럼 보이지 않게 함

오류가 발생했다고 화면 전체를 지울 필요는 없습니다. 기존에 성공한 데이터와 지금 실패한 요청을 구분하고, 실패한 동작만 다시 시도할 수 있게 합니다.

중복 실행과 오래된 응답

저장 버튼을 여러 번 누르면 같은 요청이 반복될 수 있습니다. 프론트엔드는 처리 중 버튼을 잠시 비활성화할 수 있지만, 네트워크 재시도나 다른 화면에서 같은 요청이 올 수 있으므로 중복 저장 방지는 백엔드에서도 처리합니다.

검색 조건을 빠르게 바꾸면 먼저 보낸 요청이 나중에 도착할 수도 있습니다. 현재 조건과 맞지 않는 오래된 응답으로 화면을 덮어쓰지 않는지 확인합니다. 복잡한 상태 관리 도구를 먼저 추가하기보다 현재 컴포넌트의 상태와 요청 흐름을 분명히 하는 것이 우선입니다.

동작을 확인하는 질문

  1. 어떤 사용자 행동이 요청을 시작하는가?
  2. 요청 중 같은 행동을 다시 하면 어떻게 되는가?
  3. 0건과 오류가 서로 다른 문구로 표시되는가?
  4. 실패한 뒤 다시 시도하면 최신 결과로 복구되는가?
  5. 성공하지 않았는데 완료 상태를 먼저 표시하지 않는가?

1-04 · 검토 현황과 사례 근거 연결하기에서 로딩·API 오류·다시 시도를 실제 결과와 구분합니다.

공식 근거