docs(blog): 검색 유입용 기술 팁 포스트 1차 배치 (5개, 3개 언어)

- JavaScript UTC 한국시간(KST) 변환 함수
- Next.js Prisma 싱글톤 패턴 (핫리로드 연결 누수 해결)
- Docker 멀티스테이지 빌드 Next.js 최적화
- Docker Compose YAML 앵커(&)로 반복 설정 제거
- Node.js Redis 싱글톤 연결 + 지수 백오프 재연결

Author: realcoding2003

_posts/2025-01-10-javascript-utc-korea-time-conversion-en.md

@@ -0,0 +1,47 @@
+---
+layout: post
+title: "JavaScript UTC to KST Conversion - 3 Utility Functions for Production"
+date: 2025-01-10 09:00:00 +0900
+categories: [Development, Tips]
+tags: [JavaScript, UTC, KST, timezone, Date]
+author: "Kevin Park"
+lang: en
+excerpt: "Convert between UTC and Korean Standard Time (KST) in JavaScript without external libraries."
+---
+
+## Problem
+
+Your backend stores timestamps in UTC, but the frontend needs to display Korean time (KST, UTC+9). `toLocaleString` behavior varies across browsers, so manual conversion is safer.
+
+## Solution
+
+```javascript
+// 1. Korea date string → UTC date
+function toUtcDate(koreaDateStr) {
+  const date = new Date(koreaDateStr + 'T00:00:00+09:00');
+  return date.toISOString().split('T')[0];
+}
+
+// 2. UTC timestamp → Korea date
+function toKoreaDate(utcTimestamp) {
+  const date = new Date(utcTimestamp);
+  if (isNaN(date.getTime())) return '';
+  const koreaTime = new Date(date.getTime() + 9 * 60 * 60 * 1000);
+  return koreaTime.toISOString().split('T')[0];
+}
+
+// 3. UTC date range for a single Korea day (for API queries)
+function getUtcDateRange(koreaDateStr) {
+  const startUtc = toUtcDate(koreaDateStr);
+  const nextDay = new Date(koreaDateStr + 'T00:00:00+09:00');
+  nextDay.setDate(nextDay.getDate() + 1);
+  const endUtc = toUtcDate(nextDay.toISOString().split('T')[0]);
+  return [startUtc, endUtc];
+}
+```
+
+## Key Points
+
+- Midnight in Korea (00:00 KST) is 15:00 UTC the previous day. When querying by date, you need a 2-day UTC range to avoid missing data.
+- Appending `+09:00` offset directly during parsing eliminates the need for timezone libraries.
+- Adding `9 * 60 * 60 * 1000` (32,400,000ms) is simple and works perfectly for Korea since it doesn't observe DST.

_posts/2025-01-10-javascript-utc-korea-time-conversion-ja.md

@@ -0,0 +1,47 @@
+---
+layout: post
+title: "JavaScript UTC・韓国時間(KST)変換 - 実務で使える3つの関数"
+date: 2025-01-10 09:00:00 +0900
+categories: [Development, Tips]
+tags: [JavaScript, UTC, KST, timezone, Date]
+author: "Kevin Park"
+lang: ja
+excerpt: "JavaScriptでUTCと韓国標準時(KST)を外部ライブラリなしで変換する方法をご紹介します。"
+---
+
+## 問題
+
+バックエンドはUTCで保存しているのに、フロントエンドでは韓国時間で表示しなければなりません。`toLocaleString`はブラウザによって結果が異なる場合があるため、直接変換する方が安全です。
+
+## 解決方法
+
+```javascript
+// 1. 韓国日付文字列 → UTC日付
+function toUtcDate(koreaDateStr) {
+  const date = new Date(koreaDateStr + 'T00:00:00+09:00');
+  return date.toISOString().split('T')[0];
+}
+
+// 2. UTCタイムスタンプ → 韓国日付
+function toKoreaDate(utcTimestamp) {
+  const date = new Date(utcTimestamp);
+  if (isNaN(date.getTime())) return '';
+  const koreaTime = new Date(date.getTime() + 9 * 60 * 60 * 1000);
+  return koreaTime.toISOString().split('T')[0];
+}
+
+// 3. 韓国の1日分のUTC範囲（APIクエリ用）
+function getUtcDateRange(koreaDateStr) {
+  const startUtc = toUtcDate(koreaDateStr);
+  const nextDay = new Date(koreaDateStr + 'T00:00:00+09:00');
+  nextDay.setDate(nextDay.getDate() + 1);
+  const endUtc = toUtcDate(nextDay.toISOString().split('T')[0]);
+  return [startUtc, endUtc];
+}
+```
+
+## ポイント
+
+- 韓国の深夜0時（00:00 KST）は前日の15:00 UTCです。日付基準でクエリする際は、UTCの範囲を2日分に設定しないとデータが欠落します。
+- パース時に`+09:00`オフセットを直接付与することで、タイムゾーンライブラリなしでも正確に変換できます。
+- `9 * 60 * 60 * 1000`（32,400,000ms）を加算する方法は、サマータイムのない韓国では完璧に動作します。

_posts/2025-01-10-javascript-utc-korea-time-conversion.md

@@ -0,0 +1,47 @@
+---
+layout: post
+title: "JavaScript UTC 한국시간(KST) 변환 - 실무에서 자주 쓰는 3가지 함수"
+date: 2025-01-10 09:00:00 +0900
+categories: [Development, Tips]
+tags: [JavaScript, UTC, KST, timezone, Date]
+author: "Kevin Park"
+lang: ko
+excerpt: "JavaScript에서 UTC와 한국시간(KST) 사이를 변환하는 실무 코드. toLocaleString 없이 직접 변환하는 방법."
+---
+
+## 문제
+
+백엔드는 UTC로 저장하는데, 프론트엔드에서는 한국시간으로 보여줘야 한다. `toLocaleString`은 브라우저마다 결과가 다를 수 있어서 직접 변환하는 게 안전하다.
+
+## 해결
+
+```javascript
+// 1. 한국 날짜 문자열 → UTC 날짜
+function toUtcDate(koreaDateStr) {
+  const date = new Date(koreaDateStr + 'T00:00:00+09:00');
+  return date.toISOString().split('T')[0];
+}
+
+// 2. UTC 타임스탬프 → 한국 날짜
+function toKoreaDate(utcTimestamp) {
+  const date = new Date(utcTimestamp);
+  if (isNaN(date.getTime())) return '';
+  const koreaTime = new Date(date.getTime() + 9 * 60 * 60 * 1000);
+  return koreaTime.toISOString().split('T')[0];
+}
+
+// 3. 한국 날짜 하루의 UTC 범위 (API 조회용)
+function getUtcDateRange(koreaDateStr) {
+  const startUtc = toUtcDate(koreaDateStr);
+  const nextDay = new Date(koreaDateStr + 'T00:00:00+09:00');
+  nextDay.setDate(nextDay.getDate() + 1);
+  const endUtc = toUtcDate(nextDay.toISOString().split('T')[0]);
+  return [startUtc, endUtc];
+}
+```
+
+## 핵심 포인트
+
+- 한국 자정(00:00 KST)은 전날 15:00 UTC다. 그래서 날짜 기준 조회할 때 UTC 범위를 2일치로 잡아야 데이터가 빠지지 않는다.
+- `+09:00` 오프셋을 직접 붙여서 파싱하면 타임존 라이브러리 없이도 정확하게 변환된다.
+- `9 * 60 * 60 * 1000` (32,400,000ms)를 더하는 건 단순하지만 서머타임이 없는 한국에서는 완벽하게 동작한다.

_posts/2025-01-20-nextjs-prisma-singleton-pattern-en.md

@@ -0,0 +1,37 @@
+---
+layout: post
+title: "Next.js Prisma Singleton Pattern - Fix Hot Reload Connection Leaks"
+date: 2025-01-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Next.js, Prisma, singleton, database, TypeScript]
+author: "Kevin Park"
+lang: en
+excerpt: "Fix Prisma client connection leaks during Next.js hot reload with a simple singleton pattern."
+---
+
+## Problem
+
+In Next.js dev mode, every file save triggers a hot reload that creates a new `PrismaClient()` instance. Database connections pile up until you hit a `Too many connections` error.
+
+## Solution
+
+```typescript
+// lib/prisma.ts
+import { PrismaClient } from '@prisma/client'
+
+const globalForPrisma = globalThis as unknown as {
+  prisma: PrismaClient | undefined
+}
+
+const prisma = globalForPrisma.prisma ?? new PrismaClient()
+
+if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma
+
+export default prisma
+```
+
+## Key Points
+
+- `globalThis` survives hot reloads. Storing the Prisma instance here ensures the existing connection is reused when modules are re-evaluated.
+- In production, modules load only once, so storing on `globalThis` is unnecessary. The `NODE_ENV !== 'production'` guard handles this.
+- Five lines of code prevent dozens of zombie database connections during development.

_posts/2025-01-20-nextjs-prisma-singleton-pattern-ja.md

@@ -0,0 +1,37 @@
+---
+layout: post
+title: "Next.jsでPrismaシングルトンパターン - ホットリロードの接続リークを解決"
+date: 2025-01-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Next.js, Prisma, singleton, database, TypeScript]
+author: "Kevin Park"
+lang: ja
+excerpt: "Next.jsの開発モードでPrismaクライアントの接続が増え続ける問題をシングルトンパターンで解決する方法をご紹介します。"
+---
+
+## 問題
+
+Next.jsの開発モードでファイルを修正するたびにホットリロードが発生し、`new PrismaClient()`が毎回新しく実行されます。その結果、DB接続が蓄積され、`Too many connections`エラーが発生します。
+
+## 解決方法
+
+```typescript
+// lib/prisma.ts
+import { PrismaClient } from '@prisma/client'
+
+const globalForPrisma = globalThis as unknown as {
+  prisma: PrismaClient | undefined
+}
+
+const prisma = globalForPrisma.prisma ?? new PrismaClient()
+
+if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma
+
+export default prisma
+```
+
+## ポイント
+
+- `globalThis`はホットリロードしても初期化されません。ここにPrismaインスタンスを保存しておけば、ファイルが再読み込みされても既存の接続を再利用できます。
+- 本番環境ではモジュールは一度だけ読み込まれるため、`globalThis`への保存は不要です。そのため`NODE_ENV !== 'production'`の条件を付けています。
+- たった5行のコードで、開発中にDB接続が数十個も溜まるのを防ぐことができます。

_posts/2025-01-20-nextjs-prisma-singleton-pattern.md

@@ -0,0 +1,37 @@
+---
+layout: post
+title: "Next.js에서 Prisma 싱글톤 패턴 - 핫리로드 연결 누수 해결"
+date: 2025-01-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Next.js, Prisma, singleton, database, TypeScript]
+author: "Kevin Park"
+lang: ko
+excerpt: "Next.js 개발 모드에서 Prisma 클라이언트 연결이 계속 쌓이는 문제를 싱글톤 패턴으로 해결하는 방법."
+---
+
+## 문제
+
+Next.js 개발 모드에서 파일을 수정할 때마다 핫리로드가 발생하면서 `new PrismaClient()`가 매번 새로 실행된다. 결과적으로 DB 연결이 계속 쌓여서 `Too many connections` 에러가 터진다.
+
+## 해결
+
+```typescript
+// lib/prisma.ts
+import { PrismaClient } from '@prisma/client'
+
+const globalForPrisma = globalThis as unknown as {
+  prisma: PrismaClient | undefined
+}
+
+const prisma = globalForPrisma.prisma ?? new PrismaClient()
+
+if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma
+
+export default prisma
+```
+
+## 핵심 포인트
+
+- `globalThis`는 핫리로드를 해도 초기화되지 않는다. 여기에 Prisma 인스턴스를 저장해두면 파일이 다시 로드되어도 기존 연결을 재사용한다.
+- 프로덕션에서는 모듈이 한 번만 로드되니까 `globalThis`에 저장할 필요가 없다. 그래서 `NODE_ENV !== 'production'` 조건을 건다.
+- 이 패턴 5줄이면 끝나는데, 이걸 안 하면 개발할 때 DB 연결이 수십 개씩 쌓이는 걸 보게 된다.

_posts/2025-03-10-docker-multistage-build-nextjs-en.md

@@ -0,0 +1,52 @@
+---
+layout: post
+title: "Docker Multi-Stage Build for Next.js - Optimize Image Size"
+date: 2025-03-10 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Docker, Next.js, multi-stage build, optimization]
+author: "Kevin Park"
+lang: en
+excerpt: "Reduce Next.js Docker image from 1GB to under 200MB with a 3-stage Dockerfile."
+---
+
+## Problem
+
+A naive Docker build for Next.js includes the entire `node_modules` directory, resulting in images over 1GB. DevDependencies bloat it even further.
+
+## Solution
+
+```dockerfile
+# Stage 1: Install dependencies
+FROM node:22-alpine AS deps
+WORKDIR /app
+RUN apk add --no-cache libc6-compat
+COPY package.json package-lock.json* ./
+RUN npm ci
+
+# Stage 2: Build
+FROM node:22-alpine AS builder
+WORKDIR /app
+COPY --from=deps /app/node_modules ./node_modules
+COPY . .
+ENV NEXT_TELEMETRY_DISABLED=1
+RUN npm run build
+
+# Stage 3: Run (minimal image)
+FROM node:22-alpine AS runner
+WORKDIR /app
+ENV NODE_ENV=production
+RUN addgroup --system --gid 1001 nodejs
+RUN adduser --system --uid 1001 nextjs
+COPY --from=builder --chown=nextjs:nodejs /app/public ./public
+COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
+COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
+USER nextjs
+EXPOSE 3000
+CMD ["node", "server.js"]
+```
+
+## Key Points
+
+- Set `output: 'standalone'` in `next.config.js` to generate `.next/standalone`. Without this, stage 3 won't work.
+- The 3-stage split (`deps` → `builder` → `runner`) ensures only production-necessary files end up in the final image.
+- Creating a non-root user with `adduser` is a security baseline. Even if the container is compromised, there's no root access.

_posts/2025-03-10-docker-multistage-build-nextjs-ja.md

@@ -0,0 +1,52 @@
+---
+layout: post
+title: "Dockerマルチステージビルドで Next.js イメージを最適化する"
+date: 2025-03-10 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Docker, Next.js, multi-stage build, optimization]
+author: "Kevin Park"
+lang: ja
+excerpt: "Dockerマルチステージビルドで Next.js イメージを1GBから200MB以下に削減する実践的なDockerfileをご紹介します。"
+---
+
+## 問題
+
+Next.jsをそのままDockerでビルドすると、`node_modules`全体が含まれてイメージが1GBを超えてしまいます。devDependenciesまで含まれるため、当然の結果です。
+
+## 解決方法
+
+```dockerfile
+# Stage 1: 依存関係のインストール
+FROM node:22-alpine AS deps
+WORKDIR /app
+RUN apk add --no-cache libc6-compat
+COPY package.json package-lock.json* ./
+RUN npm ci
+
+# Stage 2: ビルド
+FROM node:22-alpine AS builder
+WORKDIR /app
+COPY --from=deps /app/node_modules ./node_modules
+COPY . .
+ENV NEXT_TELEMETRY_DISABLED=1
+RUN npm run build
+
+# Stage 3: 実行（最小イメージ）
+FROM node:22-alpine AS runner
+WORKDIR /app
+ENV NODE_ENV=production
+RUN addgroup --system --gid 1001 nodejs
+RUN adduser --system --uid 1001 nextjs
+COPY --from=builder --chown=nextjs:nodejs /app/public ./public
+COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
+COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
+USER nextjs
+EXPOSE 3000
+CMD ["node", "server.js"]
+```
+
+## ポイント
+
+- `next.config.js`に`output: 'standalone'`を設定しないと、`.next/standalone`が生成されません。Stage 3が機能するための前提条件です。
+- `deps` → `builder` → `runner`の3段階に分けることで、最終イメージには実行に必要なファイルのみが含まれます。
+- `adduser`で非rootユーザーを作成して実行するのはセキュリティの基本です。コンテナが侵害されてもroot権限はありません。