댓글 전송 버튼이 멈출 때: fetch 오류 처리와 중복 제출 방지하기

👤 인스피

조회 수 8

2. fetch는 HTTP 오류를 별도로 확인해야 합니다

fetch로 응답을 받았다고 200번대라는 뜻은 아닙니다. 404나 500 응답도 HTTP 응답 객체로 받을 수 있으므로 response.ok 또는 status를 확인합니다. 네트워크 문제로 응답 자체를 받지 못한 상황과 구분해야 사용자에게 다음 행동을 안내할 수 있습니다.

그다음 본문 형식을 확인합니다. API가 JSON을 기대하지만 프록시 오류 페이지가 HTML로 오면 response.json에서 예외가 생길 수 있습니다. 서버 에러 원문이나 전체 HTML을 사용자에게 그대로 노출하지 말고, 화면에는 필요한 안내를 제공하고 진단 기록에는 상태와 요청 식별자를 남깁니다.

3. 일관된 서버 응답 계약이 먼저입니다

정상 응답에는 success 같은 판정 값을 명시하고 오류 응답은 적절한 상태 코드와 예측 가능한 형식을 사용하도록 설계합니다. 이미 사용 중인 API라면 클라이언트가 어떤 형태를 기대하는지 확인하세요. 서버와 브라우저를 다른 시점에 배포하면 과도기적인 형식 차이도 발생할 수 있습니다.

아래 예제는 JSON Content-Type과 success가 true인 경우를 성공으로 봅니다. 이 규칙은 이 글의 학습용 계약입니다. 모든 API에 적용되는 표준 응답 구조는 아닙니다. 본인의 서버가 다른 이름과 자료형을 사용한다면 그 계약에 맞춰 검사를 조정해야 합니다.

4. 버튼 비활성화는 finally에서 복구합니다

전송 중 버튼을 비활성화하고 처리가 끝나면 finally에서 복구하는 패턴을 사용할 수 있습니다. 오류가 나도 이 경로가 실행되므로 버튼이 영구적으로 멈추는 상황을 줄입니다. 동시에 진행 중인 요청을 표시하는 플래그를 두면 연속 클릭으로 같은 작업이 두 번 시작되는 것을 줄일 수 있습니다.

브라우저 버튼 제어만으로 서버의 중복 저장을 완전히 막는 것은 아닙니다. 탭 두 개, 재전송, 네트워크 중간 실패 같은 상황은 서버에서도 고려해야 합니다. 댓글·결제·포인트처럼 상태가 바뀌는 작업에서는 식별 키나 중복 검사 등 서버 정책을 별도로 설계합니다. 아래 예제는 서버 멱등성을 구현하지 않습니다.

5. 작은 예제로 실패 유형을 분리합니다

readApiResult 함수는 응답을 검토하는 순수한 부분입니다. 이 부분을 먼저 검사하면 화면 이벤트와 서버 상태가 섞이지 않습니다. 이어서 버튼 상태를 관리하는 함수에서 기존 폼 전송을 연결합니다. 요청 주소와 입력 값은 프로그램 밖에서 명시적으로 전달하게 하면 잘못된 기본 주소로 전송하는 실수를 줄일 수 있습니다.

로그인 쿠키와 CSRF 토큰을 쓰는 서비스에서는 해당 계약도 유지해야 합니다. 예제에 인증 값을 직접 적지 마세요. cross-origin 요청을 쓰는 서비스라면 쿠키, CORS, origin 관계를 별도로 점검합니다. 오류를 없애기 위해 no-cors를 붙이는 방법은 응답을 읽을 수 없게 만들어 진단 목적과 맞지 않을 수 있습니다.

6. 실패 후 사용자에게 보여 줄 내용

전송 실패를 조용히 삼키면 사용자는 여러 번 누를 수 있습니다. 입력 내용을 보존하고 성공이 확인됐을 때만 초기화하는 편이 좋습니다. 실패 안내에는 재시도 가능 여부를 적고, 요청 제한인 경우 서비스의 대기 정책을 반영합니다. 모든 실패에서 즉시 자동 재시도하는 설계는 피하세요.

응답을 받지 못했더라도 서버에는 저장됐을 수 있습니다. 성공·실패를 모르는 상태를 단순 실패와 구분할 필요가 있습니다. 중요한 작업에서는 조회로 결과를 확인하거나 서버 식별자를 사용하는 방법을 검토합니다. 개발자 도구의 요청과 서버 기록을 대조하고 UI만 정상으로 보이는지 확인하지 마세요.

7. 예상하지 못한 응답을 위한 테스트 목록

정상 응답 하나만 확인하지 말고 실패 유형을 나누어 시험합니다. HTTP 오류, 정상 코드지만 잘못된 본문, success가 false인 데이터와 연결 거절을 따로 준비하세요. 각 경우에 버튼이 복구되는지, 작성 내용이 유지되는지, 사용자 안내가 한 번만 표시되는지 확인합니다. 화면 이벤트 자체는 실제 브라우저에서도 별도로 검사해야 합니다.

전송 중 두 번 클릭하는 경우와 다른 버튼을 누르는 경우를 구분합니다. 예제의 sending 플래그는 해당 기능의 요청을 하나로 제한하는 구조입니다. 여러 독립 폼을 동시에 사용할 화면이라면 하나의 전역 플래그가 다른 기능까지 막을 수 있으므로 폼 단위 상태를 설계하세요. 예제의 범위를 이해한 뒤 확장하는 편이 좋습니다.

서버가 오래 응답하지 않는 상황에는 기다리는 안내와 취소 정책이 필요할 수 있습니다. 사용자가 화면을 떠날 때 요청을 취소할지, 결과 확인을 이어갈지 결정하세요. 요청을 취소했다고 서버 작업까지 취소됐다고 단정할 수는 없습니다. 특히 상태를 바꾸는 작업에서는 후속 조회와 작업 식별자 설계를 함께 검토합니다.

에러 기록은 사용자 화면과 개발자 로그를 구분합니다. 화면에는 알기 쉬운 안내를 제공하고 로그에는 상태 코드와 실패 단계 등 재현에 필요한 정보를 남깁니다. 서버가 보낸 스택 추적이나 인증 값을 그대로 표시하지 마세요. 공통 오류 형식을 사용하는 API라면 클라이언트도 그 구조를 따르도록 맞춥니다.

배포 후에는 새 JavaScript가 실제 로드됐는지도 확인합니다. 브라우저 캐시에 이전 파일이 남으면 코드를 고쳤는데 같은 증상이 보일 수 있습니다. 파일 버전과 요청 경로를 대조하고 정상·실패 테스트를 한 번씩 반복하세요. 테스트가 통과한 범위만 기록하면 HTML 화면, 네트워크 정책과 서버 저장 동작의 미확인 영역을 분명히 알 수 있습니다.

8. 따라 하는 예제

명령과 코드는 학습용입니다. 설명에 표시된 실행 환경을 구분하고 새 시험 폴더 또는 모의 입력으로 시작하세요.

예제 코드

async function readApiResult(response) {
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  const type = response.headers.get('content-type') || '';
  if (!type.toLowerCase().includes('application/json')) {
    throw new Error('JSON 응답이 아닙니다');
  }
  const data = await response.json();
  if (!data || data.success !== true) {
    throw new Error('작업 성공을 확인하지 못했습니다');
  }
  return data;
}

let sending = false;
async function submitWithState(button, requestFactory) {
  if (sending) return;
  sending = true;
  button.disabled = true;
  try {
    return await readApiResult(await requestFactory());
  } finally {
    sending = false;
    button.disabled = false;
  }
}
// 호출 예: 기존 submit 처리 안에서 catch로 사용자 안내를 표시하세요.
// await submitWithState(button, () => fetch(url, existingRequestOptions));

9. 검증 결과와 해석

확인 항목	결과 또는 검증 범위
200 + 올바른 JSON	성공 데이터 반환
500 응답	HTTP 오류로 구분
200 + HTML	JSON 형식 오류로 구분
200 + 잘못된 JSON	파싱 실패
연결 실패	예외 전달 · 버튼 복구
동시 두 호출	전송 함수 한 번 호출