
Next.js CSP nonce 적용 시 정적 렌더링과 캐시가 바뀌는 이유
Next.js에서 CSP nonce를 적용하면 요청마다 고유한 nonce 값을 생성해야 하므로 빌드 시점에 HTML을 미리 만드는 정적 렌더링(Static Rendering)이 불가능해지고, 동적 렌더링(Dynamic Rendering)으로 전환되면서 캐시 전략도 함께 변경된다.
이어서 읽기
Next.js에서 CSP nonce를 적용하면 요청마다 고유한 nonce 값을 생성해야 하므로 빌드 시점에 HTML을 미리 만드는 정적 렌더링(Static Rendering)이 불가능해지고, 동적 렌더링(Dynamic Rendering)으로 전환되면서 캐시 전략도 함께 변경된다.
이어서 읽기
Next.js의 use cache 지시자와 cacheLife 함수를 사용하면 함수나 컴포넌트의 캐시 수명을 명시적으로 제어할 수 있다. use cache로 캐싱 대상을 지정하고, cacheLife로 재검증 주기와 만료 시간을 설정하는 것이 핵심이다.

서버를 거치지 않고 브라우저에서 Cloudflare R2로 파일을 직접 업로드하려면 백엔드에서 Presigned URL을 생성해 클라이언트에 전달하고, 클라이언트는 해당 URL로 PUT 요청을 보내면 된다. 이 방식은 서버 대역폭을 절약하고 업로드 속도를 높이며, URL에 만료 시간과

GitHub Actions에서 재사용 가능한 워크플로(Reusable Workflow)와 Composite Action은 모두 반복되는 CI/CD 로직을 재사용하기 위한 메커니즘이며, 선택 기준은 호출 위치(워크플로 레벨 vs 스텝 레벨)와 필요한 제어 범위(Job 단위 vs Step

GitHub Actions에서 AWS, Azure, GCP 같은 클라우드에 배포할 때 Access Key나 Service Account 키를 Repository Secret에 저장하는 방식은 보안 위험이 크다. 키가 유출되면 공격자가 클라우드 리소스를 자유롭게 조작할 수 있고, 키 교체

Next.js는 빌드 시점에 NEXTPUBLIC 접두사가 붙은 환경 변수만 클라이언트 번들에 포함시켜 브라우저에 노출하고, 접두사가 없는 변수는 서버 환경에서만 접근 가능하도록 분리합니다.

현재 Next.js App Router의 Route Handler는 기본적으로 캐시되지 않습니다. GET 응답을 정적으로 캐시하려면 export const dynamic = 'force-static'처럼 명시적으로 선택해야 합니다. 이때 export const dynamic = 'for