Intro
Next.js에서 Edge, Node.js, 클라이언트를 적절히 분리하는 일을 감으로만 해왔다. 문서 인증 파이프라인을 붙이면서 서버 리소스가 확 튀는 걸 보고, Next.js가 말하는 Fluid Computing 개념을 제대로 정리해야겠다고 마음먹었다. 결국 요청의 성격에 따라 런타임을 유연하게 바꾸는 전략을 정립해, CPU를 태우는 작업과 즉시 응답이 필요한 화면을 공존시켰다.
Fluid Computing 이해
Fluid Computing은 에지와 서버, 클라이언트를 상황에 맞춰 섞어 쓰는 Next.js 접근법이라고 이해했다. 라우트마다 runtime과 dynamic을 선언해 어느 쪽 리소스를 쓸지 명확히 적었다. 서버 전용 유틸은 Node.js 전용 라우트로 밀어 넣고, 화면은 가능하면 스트리밍이나 CSR로 가볍게 돌렸다.
AWS KMS, pdf-lib 같은 네이티브 의존성이 있는 API는 export const runtime = 'nodejs';로 명시해 Edge 배포에서 자연스럽게 제외했다. 사용자 프로필, 혜택 페이지 같이 자주 변하는 데이터는 export const dynamic = 'force-dynamic';으로 선언해 ISR로 잘못 묶이는 일을 막았다. 이미지 에셋이나 공지 페이지는 기본 정적 빌드에 맡겼다. 필요하면 revalidate 값을 추가해 캐시를 조절했다.
구현 흐름
API 라우트를 전수 조사해 어떤 의존성이 있는지 확인했다. OCR, AI 비교, 자동 승인 라우트는 모두 Node.js 런타임이 필요하다는 걸 확인하고 설정을 넣었다. 모바일 전용 페이지들은 src/app/(mobile) 아래에 있으면서도 서버 컴포넌트로 작성되어 있다. 이 부분을 force-dynamic으로 바꿔 실시간 데이터를 확실히 전달하도록 했다. Next 이미지 최적화는 CDN에서 가져오는 자원을 다루므로 remotePatterns를 등록했다. 덕분에 Fluid Computing 흐름이 끊기지 않고, 에지 캐시와 서버 렌더링이 자연스럽게 이어졌다.
겪은 이슈
처음에는 Edge로 돌려도 되겠지 싶어 OCR 라우트의 런타임을 명시하지 않았는데, 배포 후 pdf-lib가 fs를 찾지 못한다는 오류를 쏟아냈다. 이때 Fluid Computing 글을 찾아보며 “요청별 런타임을 정해두라”는 조언을 확인했다. 또 한 번은 리드 타임을 줄이겠다며 모든 페이지를 정적으로 만들어버렸더니, 관리자가 데이터를 갱신해도 반영이 늦었다. 이후 force-dynamic과 revalidate를 적절히 섞는 패턴을 정리했다. 무엇보다 중요한 건 팀 규범을 세우는 일이었다. PR 템플릿에 “새 라우트의 runtime/dynamic 전략”이라는 체크박스를 넣어, 모두가 같은 원칙을 공유하도록 했다.
결과
이제는 서버 무거운 작업이 특히 필요한 엔드포인트만 Node.js 런타임으로 묶여 있어, 엣지 캐시가 필요한 페이지는 자유롭게 배포된다. Fluid Computing이라는 이름을 붙이니 팀 동료와 대화도 쉬워졌다. “이건 플루이드하게 Node로 보내자” 같은 말이 농담처럼 오가지만, 실제로는 큰 사고를 방지하는 암묵지로 작동한다.