Props Drilling을 줄이기 위해 예약 Context의 생명주기를 라우터에 둔 이유

직접 문제는 Props Drilling이었습니다

객실 선택부터 정보 입력과 예약 확인까지 여러 화면이 같은 예약 상태를 사용했습니다. 상위 컴포넌트가 상태를 소유한 채 아래로 내려주면서, 중간 컴포넌트는 값을 직접 사용하지 않아도 예약 상태와 setter를 props로 받아 다음 컴포넌트에 전달해야 했습니다.

질문은 전역 상태 도구를 무엇으로 바꿀지가 아니라 다음과 같았습니다.

예약 단계가 공유하는 상태의 소유 범위와 전달 경로를 어디에 둘 것인가?

Redux 대신 예약 라우터 범위의 Context를 선택했습니다

Redux도 대안으로 검토했습니다. 여러 route가 함께 쓰는 전역 상태를 중앙에서 관리해야 한다면 적합할 수 있지만, 당시 예약 상태는 하나의 예약 흐름 안에서 여러 단계가 함께 쓰는 값이었습니다. 기존 코드를 Redux store로 옮기는 전환 비용까지 고려해 이번 범위에는 도입하지 않았습니다.

예약 라우터에 ReservationProvider를 배치하고 그 아래 단계 화면들이 useReservation으로 필요한 상태를 직접 소비하게 했습니다. 그 결과 중간 컴포넌트가 사용하지 않는 props를 받아 재전달하는 구간을 줄였습니다.

변경 전: 상위 상태 소유자 → 중간 컴포넌트 → 예약 단계 화면
변경 후: 예약 라우터 ReservationProvider → useReservation을 사용하는 예약 단계 화면

Provider 위치가 상태의 생명주기를 정합니다

Provider를 예약 라우터에 두면 사용자가 예약 흐름에 들어올 때 상태가 만들어지고 그 흐름을 벗어날 때 함께 정리됩니다. App 전체가 아니라 실제로 상태를 공유하는 화면들의 공통 상위가 소유 범위가 됩니다.

이 선택의 결과는 중간 props 전달 감소와 예약 흐름에 맞춘 생명주기 경계입니다. Context를 사용했다는 사실만으로 예약 단계의 실행 순서를 강제하거나 다른 설계 문제까지 해결한 것은 아닙니다.

적용할 조건과 피해야 할 조건

서로 관련된 여러 화면이 한 route subtree 안에서 같은 클라이언트 상태를 공유하고, 그 흐름을 벗어날 때 상태도 끝나야 한다면 route-scoped Context를 적용할 수 있습니다.

반대로 관계없는 여러 route가 함께 써야 하는 전역 상태라면 더 넓은 소유 경계가 필요합니다. 최신 서버 응답이 기준인 데이터도 Context만으로 관리하기보다 서버 상태의 조회·동기화 방식을 별도로 정해야 합니다.

Hook은 사용 계약이지 권한 경계가 아닙니다

useReservation이 Provider 밖에서 오류를 내도록 한 것은 개발 중 잘못된 사용 위치를 빠르게 발견하기 위한 계약입니다. 이것을 상태 접근 권한을 통제하는 보안 경계로 볼 수는 없습니다.

Context는 성능을 자동으로 보장하지도 않습니다. 값의 구성과 변경 빈도, consumer 범위에 따라 렌더링 영향은 달라질 수 있으므로 필요하면 별도로 측정하고 Provider 또는 상태를 더 나눠야 합니다.