{intro}

<Spacing size="lg" />
## 발단 - 서버 사이드에서 인증 로직 구현하기
 
사건의 발단은 서버 사이드에서 인증 로직을 구현하면서 시작되었습니다. 프로젝트를 마무리하며 코드를 살펴보았을 때 데이터를 클라이언트에서 불러오는 경우가 많았기에 SSR을 위해 서버 사이드에서 데이터를 불러오도록 코드 수정 작업을 시작했습니다. 원래 인증 로직은 보안을 위해 서버에서 HttpOnly 쿠키로 토큰을 세팅하고 클라이언트에서 요청을 보낼 때 credentials : "include" 옵션을 주어 자동으로 쿠키가 전달될 수 있게 처리해 두었습니다. 그러나 넥스트 서버에서는 브라우저에 저장된 쿠키에 접근할 수 없었기 때문에 요청 헤더에 포함된 쿠키에 접근하여 토큰 값을 가져오는 방향으로 작업을 진행했습니다.
 
```tsx
// util/auth.ts
import { cookies } from "next/headers";

export const getToken = async () => {
 const cookie = await cookies();
 return cookie.get("token")?.value ?? null;
};

```
 
넥스트 요청 헤더에 포함된 쿠키에서 토큰을 가져온 후
 
```tsx
// AuthGuard
import { redirect } from "next/navigation";
import path from "@/constants/path";
import { getAuthServer } from "@/api/server/auth";
import { getToken } from "@/util/auth";

const AuthGuard = async ({ children }: { children: React.ReactNode }) => {
 try {
 const token = await getToken();
 await getAuthServer({
 headers: { Authorization: `Bearer ${token}` },
 });
 return <>{children}</>;
 } catch (error) {
 if (error instanceof Error) {
 console.error(error);
 redirect(path.login);
 }
 }
};

export default AuthGuard;
```
 
토큰을 Authorization 헤더에 추가하여 사용자 인증 정보를 불러옵니다.
이때 사용자 인증 정보가 없다면 로그인 페이지로 리다이렉션 시킵니다.
 
## 전개 - 토큰을 찾을 수 없음
 
작업을 완료한 후 코드를 배포하니 큰 문제가 생겼습니다. 로그인 해도 계속 로그인 페이지로 리다이렉트되는 문제였습니다. 로컬에서는 로그인 후 쿠키에 저장된 토큰을 통해 유저 정보를 가져오는 것이 정상적으로 처리되었기에 의문이었습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741223110/25.accessing-cookies-on-the-next-server/jc39whldxenpx6xwwhc3.jpg" alt="쿠키가 저장되어 있음" width="585" height="45" caption="쿠키는 저장되어 있는데 어째서...?"/>
 
분명 브라우저에 토큰이 저장되어 있는데 토큰이 존재하지 않는다는 에러가 계속 발생했습니다.
 
이 과정에서 온갖 키워드로 구글링하고 챗지피티한테 호통치고 (~~미래를 위한 호감작 실패~~ 🥲) 로컬 환경과 배포 환경을 비교해 보며 결국 에러의 원인을 찾아냈습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/tfkxmdshotnsi5hmsoqd.jpg" alt="로컬에서의 요청" width="672" height="336" caption="로컬에서 요청이 갈 때는 토큰이 포함됨"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/gpekxbffzz1axlq9gml1.jpg" alt="배포 도메인에서의 요청" width="697" height="292" caption="뭐야, 내 쿠키 돌려줘요"/>
 
배포 환경에서는 넥스트 서버로 요청이 갈 때 리퀘스트 헤더에 쿠키가 포함되지 않았던 것입니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/hvtbfuxz5x1eyoiaxfhq.jpg" alt="배포 환경의 쿠키 도메인" width="585" height="57" caption="쿠키의 도메인이 서버 도메인으로 지정되어 있음"/>
 
이유는 쿠키의 도메인 때문이었습니다. 도메인은 쿠키를 전달받을 서버를 지정하는 속성으로 따로 지정하지 않으면 쿠키를 세팅한 서버의 도메인이 자동으로 지정됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/ik52gcgdldqjfqudaaja.jpg" alt="로컬 쿠키 도메인" width="585" height="62" caption="로컬은 넥스트 서버와 API 서버가 동일한 도메인을 가짐"/>
 
로컬 환경에서는 넥스트 서버와 API 서버가 동일한 localhost 도메인이기 때문에 넥스트 서버로 API 서버에서 세팅한 쿠키가 전달될 수 있었지만
배포 환경에서는 넥스트 서버와 API 서버의 도메인이 다르다 보니 넥스트 서버 요청에 쿠키가 같이 전달되지 않았던 것이죠 🥲
 
## 위기 - 도메인 세팅 실패
 
원인을 알았으니 쉽게 해결할 수 있을거라고 생각했습니다. 

"도메인을 넥스트 서버 도메인으로 하면 해결되겠다!"라고 생각했던 것이죠.
바로 API 서버에서 쿠키를 세팅할 때 도메인에 넥스트 서버 도메인을 지정하고 배포를 진행했습니다.
 
```ts
export const setToken = (res: Response, token: string) => {
 const options = {
 maxAge: Number(env.jwt.expiredSec) * 1000,
 httpOnly: true,
 sameSite: "none" as "none",
 secure: true,
 domain: env.client.host, // 도메인 설정
 };
 res.cookie("token", token, options);
};
```
 
그리고 로그인을 진행하니 이제는 토큰 쿠키조차 세팅되지 않는 이슈가 발생했습니다 😱 서브 도메인이 아닌 완전히 다른 도메인을 설정하는 것은 보안상의 이유로 허용되지 않기 때문이었습니다. 이때쯤부터 "이거 내가 해결 가능한 이슈인가?" 하는 불안감이 엄습했습니다.
 
## 절정 - 쿠키 세팅을 넥스트에 위임
 
SSR을 포기하고 클라이언트에서 인증 로직을 구현할지, 아니면 도메인을 구입해서 넥스트 서버와 백엔드 서버 도메인을 일치시킬지 고민하던 차에 해결 방법을 찾게 되었습니다.
 
- [Next.js x Express: Using HTTP-Only Cookie, JWT, and Refresh Token for API Secure Authentication and Protect Next Route Pages.](https://medium.com/@adimuhamadfirmansyah/next-js-x-express-using-http-only-cookie-jwt-and-refresh-token-for-api-secure-authentication-and-b7ee46ac4da3)
- [서로 다른 도메인에서 쿠키 사용하기](https://velog.io/@jojeon4515/%EC%84%9C%EB%A1%9C-%EB%8B%A4%EB%A5%B8-%EB%8F%84%EB%A9%94%EC%9D%B8%EC%97%90%EC%84%9C-%EC%BF%A0%ED%82%A4-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-React-Express#-express-%EC%BF%A0%ED%82%A4-%EC%98%B5%EC%85%98-domain)
 
구글 망령이 되어 돌아다니던 중 만나게 된 귀인들의 블로그.. 
 
 바로 API 서버에서 토큰을 생성하여 전달하면 넥스트 서버에서 쿠키를 세팅하는 방법이었습니다. 이러면 쿠키 도메인이 넥스트 도메인으로 지정되어 넥스트 서버에서 쿠키에 접근이 가능해집니다! 다만 클라이언트에서 API 서버로 요청을 보내는 경우 쿠키가 포함되지 않는 이슈가 발생하니 클라이언트에서 요청을 보낼 때 넥스트 서버를 거치게 한 후 미들웨어에서 토큰을 추출하여 Authorization 헤더에 토큰을 추가해 API 서버로 보내는 방법으로 문제를 해결하게 되었습니다. 
 
- [미들웨어 코드](https://github.com/ysisys0202/chak_client/blob/main/src/middleware.ts)
- [로그인 후 쿠키 세팅 코드](https://github.com/ysisys0202/chak_client/tree/main/src/app/api/auth/login)
 
## 결말 - 이슈 해결 🎉 거기에 찝찝함을 곁들인..
 
위 방법을 적용하니 배포 환경에서도 인증 처리가 정상적으로 동작했습니다. 
일단 문제가 해결되어 한숨 돌렸지만 넥스트 API에서 쿠키를 세팅하게 되면서 클라이언트 로직과 API 로직의 경계가 흐려진 것 같아 살짝 찝찝한 마음이 듭니다. 게다가 모든 API 요청이 넥스트를 한 번 거치게 되어 성능에 영향을 미치지 않을지 우려되기도 합니다.
 
## 포스팅을 마무리하며
 
이번 포스트에서는 API 서버와 도메인이 다른 넥스트 서버에서 쿠키에 접근하는 방법에 대해 알아보았습니다. 이번 에러를 해결하며 네트워크 지식의 부족함을 많이 느꼈고 공부의 필요성을 절실히 느끼게 된 것 같습니다. 올해 목표에 네트워크 공부를 슬쩍 추가하며 이번 포스트를 마무리하겠습니다 👋👋👋 
 
## 참고 자료
- [Next.js x Express: Using HTTP-Only Cookie, JWT, and Refresh Token for API Secure Authentication and Protect Next Route Pages.](https://medium.com/@adimuhamadfirmansyah/next-js-x-express-using-http-only-cookie-jwt-and-refresh-token-for-api-secure-authentication-and-b7ee46ac4da3)
- [서로 다른 도메인에서 쿠키 사용하기](https://velog.io/@jojeon4515/%EC%84%9C%EB%A1%9C-%EB%8B%A4%EB%A5%B8-%EB%8F%84%EB%A9%94%EC%9D%B8%EC%97%90%EC%84%9C-%EC%BF%A0%ED%82%A4-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-React-Express#-express-%EC%BF%A0%ED%82%A4-%EC%98%B5%EC%85%98-domain)

넥스트 서버 사이드에서 쿠키에 접근하기

{intro}
<Spacing size="lg" />
## 문제 발생
 
새로 작업한 프로젝트를 배포하고 보니 라우팅 반응 속도가 느려지는 현상이 발견되었습니다. 이는 이동할 페이지를 생성하기 위해 데이터를 불러오고 HTML을 렌더링하는 만큼 시간이 소요되기 때문이었습니다. 이를 개선하기 위해 넥스트에서 지원하는 스트리밍을 적용하게 되었습니다.
 
## 넥스트 SSR의 한계
 
넥스트의 스트리밍을 알아보기에 앞서 라우팅 반응 속도가 느려진 이유에 대해 알아보겠습니다.
 
넥스트의 SSR(Server Side Rendering)은 다음과 같은 단계로 진행됩니다.
 
1. API 서버로부터 페이지를 구성하는 데 필요한 모든 데이터를 가져옵니다.
2. 넥스트 서버는 가져온 데이터로 HTML을 렌더링합니다.
3. 만들어진 HTML과 CSS, 자바스크립트를 클라이언트에 전송합니다.
4. 클라이언트는 전달받은 HTML과 CSS로 화면을 렌더링합니다. 이때는 아직 자바스크립트가 적용되지 않아 상호 작용이 되지 않는 정적 UI입니다.
5. 마지막으로 React가 정적 UI에 자바스크립트를 연결하는 하이드레이션 과정을 거쳐 마침내 상호 작용이 가능한 UI가 됩니다.
 
이때 넥스트는 페이지를 렌더링하는 데 필요한 모든 데이터를 받아오고 HTML이 모두 준비되어야 페이지가 이동시키게 됩니다. 즉 링크를 클릭해도 페이지가 렌더링 되는 시간만큼 반응에 딜레이가 생기게 됩니다. 이는 사용자 경험을 크게 저하시키는 요인으로 이를 해결하기 위해 넥스트의 스트리밍을 적용할 수 있습니다.
 
## 스트리밍이란?
 
일단 스트리밍이라는 단어에 대해 알아보겠습니다. 일상적으로 많이 사용하는 용어지만 막상 그 뜻을 온전히 알고 쓰진 않았던 것 같습니다.
스트리밍은 큰 데이터를 작은 조각으로 나누어 물이 흐르듯 순서대로 전달하고 처리하는 과정을 의미합니다. 흔히 유튜브나 음원 사이트에서 비디오나 오디오 데이터를 작은 단위로 나누어 제공할 때 사용하곤 합니다. 그렇다면 넥스트의 스트리밍은 무엇일까요? (드디어 본론!)
 
## 넥스트의 스트리밍
 
넥스트의 스트리밍은 페이지의 HTML을 작은 조각으로 나누어 준비되는 순서대로 클라이언트에 전송하는 것을 의미합니다. 따라서 스트리밍을 적용하면 앞서 언급한 라우팅 속도가 느려지는 현상을 개선할 수 있습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741144198/24.next-streaming/sbaoxao6netonmlby3oz.avif" alt="넥스트의 스트리밍" width={1600*0.4} height={785 *0.4} caption="넥스트의 스트리밍, 페이지를 구성하는 HTML 작은 조각 나누어 클라이언트에 전송"/>
 
링크를 클릭했을 때 아무런 반응도 없다가 몇초후에 화면이 이동하는 것이 아니라 일단 페이지가 이동하고 먼저 준비된 UI을 보여줄 수 있으니 페이지 초기 로드 속도가 단축되고 사용자 경험도 개선할 수 있게 됩니다.
 
## 넥스트에서 스트리밍 적용하기
 
넥스트에서 스트리밍을 적용하기 위해서는 클라이언트에서 요청이 발생할 때 동적으로 생성되는 페이지여야 합니다. 이미 정적으로 빌드된 페이지라면 스트리밍이 필요하지 않을 테니까요.
 
그럼 이제 넥스트에서 스트리밍을 적용하는 두 가지 방법에 대하여 알아보겠습니다.
 
### 1. loading 페이지 추가하기
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741144198/24.next-streaming/fh58byejiay7zihrbjqs.avif" alt="loading 페이지" width={1600*0.4} height={785 *0.4} caption="Suspense 컴포넌트 적용."/>
 
첫 번째로는 loading 페이지를 추가하는 것입니다. 스트리밍을 적용할 페이지 파일과 동일한 경로에 loading.tsx 파일을 생성하고 해당 파일 내에서 로딩 시에 보여줄 fallback 컴포넌트를 내보내면 됩니다.
 
### 2. Suspense 컴포넌트 사용하기
 
페이지 단위가 아닌 컴포넌트 단위로 로딩 UI를 보여주고 싶다면 리액트에서 제공하는 Suspense 컴포넌트를 사용하면 됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741144198/24.next-streaming/ss5ildcma1wunkxmzwqj.avif" alt="loading 페이지" width={1600*0.4} height={785 *0.4} caption="Suspense 컴포넌트 적용."/>
 
데이터를 페칭하는 컴포넌트를 Suspense로 감싸고 로딩 시 보여줄 fallback 컴포넌트를 전달하면 됩니다. Suspense는 페이지 단위의 로딩 UI보다 디테일하게 로딩 UI를 제공할 수 있다는 장점이 있습니다. 보통 스켈레톤 UI를 제공하여 어떤 UI가 렌더링 될지 사용자에게 예측할 수 있게 합니다. 
 
```tsx
<Suspense fallback={<Loading />}> 
 <SomeComponent />
</Suspense>
```
 
이렇게 SomeComponent를 감싸면 SomeComponent가 렌더링 될 동안 Loading UI가 노출됩니다.
 
#### (개선) HOC로 재사용성 높이기
 
이때 저는 부모 컴포넌트에서 Suspense로 감싸기보다 Suspense로 감싸질 컴포넌트 파일 안에서 로딩 UI를 같이 관리하고 싶었습니다.
따라서 Suspense를 적용할 컴포넌트 파일에서 withSuspense HOC를 내보내도록 작업했습니다.
HOC는 High Order Component의 약자로 컴포넌트를 인자로 받아 새로운 컴포넌트를 반환하는 함수입니다. 각각의 컴포넌트에 공통 로직을 적용할 때 유용하게 사용할 수 있습니다. 더 자세한 내용이 알고 싶으시다면 [이 포스트](/posts/React/HOC-사용해서-재사용성-높이기)를 확인해 주세요.
 
```tsx
// withSuspense HOC
import { ComponentType, ReactNode, Suspense } from "react";

const withSuspense = <Props extends object>(
 Component: ComponentType<Props>,
 fallback: ReactNode
) => {
 const ContainerComponent: React.FC<Props> = ({
 suspenseKey,
 ...props
 }) => (
 <Suspense fallback={fallback}>
 <Component {...(props as Props)} />
 </Suspense>
 );

 ContainerComponent.displayName = `withSuspense(${
 Component.displayName || Component.name || "Component"
 })`;

 return ContainerComponent;
};

export default withSuspense;

```
 
```tsx
// SomeComponent
const SomeLoading = () => {
 return <div>loading...</div>
}

const SomeComponent = () => {
 return <div>some...</div>
}

export default withSuspense(SomeComponent, <SomeLoading />);
```
 
#### (최종) 쿼리 파라미터로 데이터를 새로 불러오는 경우 대응하기
 
Suspense 컴포넌트는 기본적으로 데이터를 한 번 불러온 후에는 로딩 완료 상태를 유지합니다. 이때 문제가 되는 점은 필터나 페이징같이 쿼리 파라미터를 사용하여 API 호출을 하는 경우 Suspense가 로딩 완료 상태를 유지하고 있기 때문에 fallback UI를 노출하지 않는다는 점입니다. 따라서 처음과 똑같이 상호 작용 속도 이슈가 발생합니다. 이 문제를 해결하기 위해서 새로 데이터를 불러올 때 Suspense에 키값을 변경하여 강제로 리렌더링해주야 합니다.
 
키값을 전달하기 위해 withSuspense를 수정해 주었습니다.
 
```tsx
import { ComponentType, ReactNode, Suspense } from "react";

const withSuspense = <Props extends object>(
 Component: ComponentType<Props>,
 fallback: ReactNode
) => {
 const ContainerComponent: React.FC<Props & { suspenseKey?: string }> = ({
 suspenseKey, // Props 타입에 suspenseKey 추가
 ...props
 }) => (
 <Suspense key={suspenseKey} fallback={fallback}> 
 {/* suspenseKey 전달*/}
 <Component {...(props as Props)} />
 </Suspense>
 );

 ContainerComponent.displayName = `withSuspense(${
 Component.displayName || Component.name || "Component"
 })`;

 return ContainerComponent;
};

export default withSuspense;

```
 
```tsx
const SomeLoading = () => {
 return <div>loading...</div>
}

const SomeComponent = () => {
 return <div>some...</div>
}

export default withSuspense(
 SomeComponent,
 <SomeLoading />
);
```
 
```tsx
const ParentComponent = ()=>{
 return <SomeComponent suspenseKey={queryParams.id}/>
}

```
 
## 포스팅을 마무리하며
 
이번 포스트에서 넥스트 SSR의 한계점과 이를 개선하기 위한 스트리밍에 대해 알아보았습니다. HTML이 모두 렌더링 되기 전에 로딩 UI를 먼저 노출시켜 사용자 경험을 향상 시킬 수 있었던 것 같습니다. 그럼 이번 포스트는 여기서 마무리하겠습니다 👋👋
 
## 참고 자료
 
- [넥스트 스트리밍 공식 문서](https://nextjs.org/docs/app/getting-started/fetching-data#streaming).
- [리액트 Suspense 공식 문서](https://ko.react.dev/reference/react/Suspense#resetting-suspense-boundaries-on-navigation)

.css-y59011{position:relative;}.css-y59011::after{content:"";position:absolute;right:0;bottom:0;width:0;height:2px;background-color:var(--color-secondary);-webkit-transition:width 200ms ease-in-out;transition:width 200ms ease-in-out;} 넥스트 서버 사이드에서 쿠키에 접근하기

스트리밍 적용해서 라우팅 속도 개선하기

넥스트 서버 사이드에서 쿠키에 접근하기