요청당 인증 중복 호출을 요청 범위 캐싱으로 제거

한 요청 내에서 인증을 여러 번 확인하는 비효율을 React의 cache() 함수로 제거했다. safeAuth를 캐싱하면서 auth() 호출을 1회로 제한하는 작업이었다.

왜 auth() 중복 호출이 문제였나

사실 서버 컴포넌트나 API 라우트에서 사용자 인증을 확인할 때, 한 요청(request) 내에서 여러 곳에서 auth() 함수를 호출하는 경우가 흔하다. 예를 들어:

• 라우트 진입점에서 먼저 현재 사용자 확인
• 미들웨어 단계에서 다시 확인
• 비즈니스 로직 실행 전 재확인

각 호출이 데이터베이스나 외부 인증 서비스(예: 토큰 검증, 권한 조회)를 거친다면, 같은 정보를 반복해서 요청하는 셈이다. 특히 인증 흐름이 복잡할수록—세션 조회, 권한 테이블 참조, 토큰 유효성 검사 등을 거친다면—이 오버헤드는 눈에 띄게 쌓인다.

더 문제는 safeAuth 같은 래퍼 함수에서 매번 auth()를 호출할 때, 그걸 감싸는 상위 레이어도 여전히 자신의 캐시 전략 없이 호출한다는 점이다. 결국 요청 생명주기 동안 같은 정보를 여러 번 조회하는 것.

React cache()로 1회 호출 제한

// 개선 전: 매번 auth() 호출
export async function safeAuth() {
  return auth(); // 요청마다 여러 곳에서 호출되면 중복 발생
}

// 개선 후: cache()로 요청 범위 캐싱
export const safeAuth = cache(async () => {
  return auth();
});

React 서버 컴포넌트의 cache() 함수는 요청 범위(request scope) 캐싱을 제공한다. 즉:

• 한 요청 내에서 safeAuth()를 여러 번 호출해도
• 첫 호출 때만 auth()가 실행되고
• 나머지 호출들은 그 결과를 재사용

요청이 끝나면 캐시도 사라지므로, 다음 요청에서는 새로 auth()를 호출한다. 세션 정보가 바뀐 경우에도 즉시 반영된다.

효과와 설계 고민

이 최적화의 실질적 효과는 다음과 같다:

특히 한 요청이 여러 계층(라우터 → 미들웨어 → 컴포넌트 → 유틸)을 거칠 때 효과가 크다.

설계상 주의점:

• cache()는 요청 범위만 커버한다. 브라우저 캐시(long-lived)와는 다르다.
• 사용자 권한이 동적으로 바뀌는 시스템에서는 오래된 캐시가 문제가 될 수 있으니, 캐시 TTL이 정말 요청 내에만 제한되는지 확인해야 한다.
• 병렬 요청이나 레이스 컨디션 상황에서 캐시 결과가 의도와 다를 수 있으니, 테스트를 철저히 하자.

일반론: 인증 캐싱 패턴

이런 류의 최적화는 인증 시스템에서 자주 나타난다:

• 토큰 검증: JWT 복호화나 서명 검증은 비싸므로, 요청 범위 캐싱은 필수.
• 권한 조회: 사용자가 특정 리소스에 접근 가능한지 확인할 때, 여러 컴포넌트에서 확인하면 캐싱 없이는 반복.
• 세션 조회: 사용자 세션을 데이터베이스에서 매번 조회하면 병목.

그래서 대부분의 현대적 인증 라이브러리나 프레임워크는 기본적으로 요청 범위 캐싱을 지원한다. React 생태에서도 cache()가 바로 그 도구다.

회고

이 작업을 하면서 느낀 점은, 단순해 보이는 최적화가 얼마나 효과적인지 다시 한 번 확인했다는 것. safeAuth 자체는 auth() 래퍼일 뿐이지만, 그걸 cache() 1줄로 감싸는 것만으로 요청당 중복 호출을 완전히 제거할 수 있다.

또 한 가지는, 이런 최적화가 개발자 경험에도 도움이 된다는 점. 인증을 여러 곳에서 호출하려고 하는 개발자는 더 이상 "혹시 중복 호출이 될까?" 걱정할 필요가 없다. cache() 덕분에 자유롭게 필요한 곳마다 인증을 확인할 수 있다.

다음은 이런 패턴을 팀에 공유하고, 비슷하게 반복되는 외부 호출(DB 조회, API 콜)들을 찾아내 같은 식으로 최적화할 차례.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.