API 호출 순서가 조회 방향이 되어버렸다 — 순차 호출 3개를 파라미터 하나로 바꾼 이야기

관련 프로젝트: CRS 어드민 상품마감·요금재고 화면 재설계

같은 화면을 2024년에 한 번 설계하고, 2025년에 다시 설계했다. 다시 손댄 이유는 기능이 부족해서가 아니라, 호출 순서 자체가 사용자가 못 바꾸는 제약이 돼 있었기 때문이다.

문제 — 순서가 곧 방향이 됐다

상품마감·요금재고 화면은 3개 API를 순차로 호출하는 구조였다. 문제는 이 "순차"가 단순한 로딩 단계가 아니라, 호출 순서 자체가 조회 방향을 결정하고 있었다는 것이다.

첫 API가 응답하면 그 결과의 첫 값이 자동으로 선택된다. 그 선택값을 기준으로 다음 API가 호출된다. 이 과정이 반복되면서, 사용자가 원래 보고 싶었던 조회 방향과 무관하게 첫 단계의 자동 선택이 이후 단계 전체를 가둬버렸다. "반대 방향으로 훑어보고 싶다"는 요구가 있어도, 구조 자체가 한쪽 방향만 허용했다.

접근 — 순서를 없애고 파라미터로 바꾼다

해법은 API를 더 최적화하는 게 아니라, 애초에 순차 호출 구조 자체를 없애는 것이었다. 3개로 나뉘어 있던 호출을 단일 API로 합치고, 조회 방향을 파라미터로 받도록 재설계했다.

// 개념 스케치 — 순차 호출 vs 방향 파라미터 (실제 구현 아님)
// before: 호출 순서가 곧 방향
const a = await fetchStep1();
const b = await fetchStep2(a.firstItem);   // a의 자동 선택값에 종속
const c = await fetchStep3(b.firstItem);   // b에 다시 종속

// after: 방향을 파라미터로 직접 전달
const result = await fetchInventory({ direction: "forward" | "backward" });

호출이 하나로 줄어든 건 부가 효과였다. 진짜 바뀐 건 "어느 방향을 볼지"를 이전 단계의 자동 선택이 아니라 사용자의 요청이 직접 결정하게 됐다는 점이다. 순서에 갇혀 있던 조회 방향이 파라미터 하나로 노출되면서, 원하는 방향으로 바로 조회할 수 있게 됐다.

덤으로 찾은 것 — 판매마감 토글의 벌크 반전

같은 화면을 손보던 중, 판매마감 저장 로직이 현재 상태의 반대값을 저장하는 토글 방식이라는 걸 확인했다. 객실을 하나씩 선택하면 문제없이 동작하지만, 여러 객실을 벌크로 선택하면 각 객실의 현재 상태가 서로 달라 반전 결과가 뒤섞였다.

토글은 "지금 상태를 보고 반대로 바꾼다"는 전제가 성립해야 안전하다. 벌크 처리는 그 전제가 깨지는 대표적인 상황이었다. 확정값을 직접 지정하는 방식으로 바꿔 이 결함도 함께 정리했다.

정리

같은 화면을 두 번 설계하게 된 이유는 처음 설계가 "동작은 하지만 방향이 갇혀 있는" 구조였기 때문이다. API를 몇 개 쓰느냐보다, 그 호출 순서가 사용자가 통제할 수 없는 제약으로 굳어지지 않았는지가 먼저 물어야 할 질문이었다.