검색 요청의 순서 뒤집힘 막기, 작은 재현 예제로 좁혀 가기
빠르게 입력한 검색어의 응답보다 이전 검색어의 응답이 늦게 도착할 수 있다. 변수를 줄이는 순서를 중심으로 작은 예제와 확인 기준을 정리합니다.
빠르게 입력한 검색어의 응답보다 이전 검색어의 응답이 늦게 도착할 수 있다.
화면이나 실행 결과가 예상과 다를 때 전체 시스템을 한꺼번에 설명하려 하면 단서가 흐려진다. 관련 없는 의존성을 덜어 내고 조건을 하나씩 바꾸면 어느 가정이 깨졌는지 볼 수 있다. 이번에는 원인을 단정하기 전에 비교 가능한 최소 예제를 만드는 과정을 정리한다.
변수를 줄이는 순서
새 요청을 시작할 때 이전 요청을 취소하고, 요청의 완료 순서가 화면의 최신 상태를 결정하지 않도록 한다. 취소와 실제 네트워크 오류는 구분해 처리한다.
이번에 확인할 질문: 한 가지 조건만 바꾸었을 때 관찰 결과도 함께 바뀌는가?
작게 확인하는 예제
다음 예제는 핵심 조건을 드러내기 위한 출발점이다. 서비스의 전체 구현을 대신하지 않으므로 실제 입력 범위와 실패 처리 규칙을 함께 읽어야 한다.
let previous;
async function search(query) {
previous?.abort();
const controller = new AbortController();
previous = controller;
const response = await fetch(`/api/search?q=${encodeURIComponent(query)}`,
{ signal: controller.signal });
if (!response.ok) throw new Error('검색 요청 실패');
return response.json();
}
첫 요청은 늦게, 두 번째 요청은 빨리 응답하도록 만들어 최신 검색어의 결과가 유지되는지 확인한다.
놓치기 쉬운 조건
요청 취소는 서버에서 이미 시작한 작업까지 반드시 취소한다는 뜻이 아니다. 호출부에서는 AbortError를 사용자에게 보일 실패로 취급하지 않도록 한다.
| 확인할 부분 | 살펴볼 내용 |
|---|---|
| 기준 동작 | 첫 요청은 늦게, 두 번째 요청은 빨리 응답하도록 만들어 최신 검색어의 결과가 유지되는지 확인한다. |
| 비교 조건 | 입력과 실행 순서를 고정하고 한 번에 한 조건만 바꾼다. |
| 적용 범위 | 예제가 생략한 의존성과 실제 서비스의 제약을 구분한다. |
다음 변경에 적용할 순서
- 문제가 드러나는 입력과 순서를 먼저 고정한다.
- 의존성이나 옵션을 하나씩 제거하고 같은 결과가 남는지 확인한다.
- 원인을 설명하는 가장 작은 차이를 회귀 확인 항목으로 남긴다.
재현 예제의 목적은 짧은 코드를 자랑하는 데 있지 않다. 설명에 필요한 조건을 남기는 것이 목적이다. 실제 경로로 돌아왔을 때도 같은 원인과 해결책이 성립하는지 마지막으로 확인해야 재현 과정이 유용한 기록이 된다.
이 이야기가 도움이 되었나요?