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

- Node.js --expose-gc 메모리 누수 디버깅
- Electron contextIsolation + preload 보안 패턴
- Redis key 네이밍 컨벤션 (계층적 구조)
- ESM에서 __dirname 사용하기 (import.meta.url)
- Vite 모노레포 상위 디렉토리 접근 허용

Author: realcoding2003

_posts/2025-11-20-nodejs-expose-gc-memory-en.md

@@ -0,0 +1,42 @@
+---
+layout: post
+title: "Node.js --expose-gc for Memory Leak Debugging"
+date: 2025-11-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Node.js, memory, garbage collection, debugging, performance]
+author: "Kevin Park"
+lang: en
+excerpt: "Use Node.js --expose-gc flag to trigger manual GC and identify real memory leaks."
+---
+
+## Problem
+
+Long-running Node.js apps (MQTT clients, batch processors) show increasing memory usage. Hard to tell if GC is working properly or if there's a real leak.
+
+## Solution
+
+```bash
+# --expose-gc enables global.gc()
+node --expose-gc app.js
+
+# In Docker
+CMD ["node", "--expose-gc", "--max-old-space-size=512", "dist/index.js"]
+```
+
+```javascript
+function logMemory(label) {
+  if (global.gc) global.gc(); // force GC
+  const usage = process.memoryUsage();
+  console.log(`[${label}] Heap: ${Math.round(usage.heapUsed / 1024 / 1024)}MB / ${Math.round(usage.heapTotal / 1024 / 1024)}MB`);
+}
+
+logMemory('start');
+await processLargeData();
+logMemory('after');  // if heap doesn't shrink after GC → leak
+```
+
+## Key Points
+
+- If `heapUsed` keeps growing after `global.gc()`, it's a real memory leak — objects are referenced somewhere GC can't reach.
+- `--max-old-space-size=512` limits heap size so leaks trigger OOM errors faster, making them easier to catch.
+- Don't use `--expose-gc` in production. Manual GC impacts performance. Use it only for debugging.

_posts/2025-11-20-nodejs-expose-gc-memory-ja.md

@@ -0,0 +1,42 @@
+---
+layout: post
+title: "Node.js --expose-gcでメモリリークをデバッグする"
+date: 2025-11-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Node.js, memory, garbage collection, debugging, performance]
+author: "Kevin Park"
+lang: ja
+excerpt: "Node.jsで--expose-gcフラグを使って手動GCをトリガーし、メモリリークを特定する方法をご紹介します。"
+---
+
+## 問題
+
+長時間実行されるNode.jsアプリ（MQTTクライアント、バッチプロセッサなど）でメモリが増加し続けます。GCが正常に動作しているのか、本当にリークなのか区別がつきません。
+
+## 解決方法
+
+```bash
+# --expose-gcで実行するとglobal.gc()を呼び出せる
+node --expose-gc app.js
+
+# Dockerの場合
+CMD ["node", "--expose-gc", "--max-old-space-size=512", "dist/index.js"]
+```
+
+```javascript
+function logMemory(label) {
+  if (global.gc) global.gc(); // 手動GC実行
+  const usage = process.memoryUsage();
+  console.log(`[${label}] Heap: ${Math.round(usage.heapUsed / 1024 / 1024)}MB / ${Math.round(usage.heapTotal / 1024 / 1024)}MB`);
+}
+
+logMemory('開始');
+await processLargeData();
+logMemory('処理後');  // GC後もメモリが減らなければ → リーク
+```
+
+## ポイント
+
+- `global.gc()`を呼び出した後も`heapUsed`が増加し続ければ、本当のメモリリークです。GCが回収できないオブジェクトがどこかで参照されています。
+- `--max-old-space-size=512`でヒープサイズを制限すると、リークがある場合にOOMで早くクラッシュするため、問題を早期発見できます。
+- プロダクション環境では`--expose-gc`を使わないのが良いです。手動GCはパフォーマンスに影響します。デバッグ時のみ使用してください。

_posts/2025-11-20-nodejs-expose-gc-memory.md

@@ -0,0 +1,44 @@
+---
+layout: post
+title: "Node.js --expose-gc로 메모리 누수 디버깅하기"
+date: 2025-11-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Node.js, memory, garbage collection, debugging, performance]
+author: "Kevin Park"
+lang: ko
+excerpt: "Node.js에서 --expose-gc 플래그로 수동 GC를 트리거하고 메모리 누수를 찾는 방법."
+---
+
+## 문제
+
+장시간 실행되는 Node.js 앱(MQTT 클라이언트, 배치 프로세서 등)에서 메모리가 계속 올라간다. GC가 제대로 돌고 있는 건지, 진짜 누수인 건지 구분이 안 된다.
+
+## 해결
+
+```bash
+# --expose-gc로 실행하면 global.gc()를 호출할 수 있다
+node --expose-gc app.js
+
+# Docker에서
+CMD ["node", "--expose-gc", "--max-old-space-size=512", "dist/index.js"]
+```
+
+```javascript
+// 메모리 상태 확인 함수
+function logMemory(label) {
+  if (global.gc) global.gc(); // 수동 GC 실행
+  const usage = process.memoryUsage();
+  console.log(`[${label}] Heap: ${Math.round(usage.heapUsed / 1024 / 1024)}MB / ${Math.round(usage.heapTotal / 1024 / 1024)}MB`);
+}
+
+// 사용 예시
+logMemory('시작');
+await processLargeData();
+logMemory('처리 후');  // GC 후에도 메모리가 안 줄면 → 누수
+```
+
+## 핵심 포인트
+
+- `global.gc()`를 호출한 후에도 `heapUsed`가 계속 증가하면 진짜 메모리 누수다. GC가 회수할 수 없는 객체가 어딘가에 참조되고 있는 거다.
+- `--max-old-space-size=512`로 힙 크기를 제한하면, 누수가 있을 때 빨리 OOM으로 터져서 문제를 빨리 발견할 수 있다.
+- 프로덕션에서는 `--expose-gc`를 쓰지 않는 게 좋다. 수동 GC는 성능에 영향을 준다. 디버깅할 때만 쓰자.

_posts/2025-12-05-electron-context-isolation-preload-en.md

@@ -0,0 +1,50 @@
+---
+layout: post
+title: "Electron contextIsolation + Preload Security Pattern"
+date: 2025-12-05 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Electron, security, contextIsolation, preload, IPC]
+author: "Kevin Park"
+lang: en
+excerpt: "Secure your Electron app by using contextIsolation and preload scripts to restrict renderer access to Node.js."
+---
+
+## Problem
+
+With `nodeIntegration: true`, the renderer (webpage) can directly access the filesystem via `require('fs')`. If loading external URLs, this is a critical security risk.
+
+## Solution
+
+```javascript
+// main.js
+const mainWindow = new BrowserWindow({
+  webPreferences: {
+    preload: path.join(__dirname, 'preload.js'),
+    contextIsolation: true,   // separate renderer and Node.js contexts
+    nodeIntegration: false,   // block require in renderer
+  }
+});
+```
+
+```javascript
+// preload.js - bridge between main and renderer
+const { contextBridge, ipcRenderer } = require('electron');
+
+contextBridge.exposeInMainWorld('electronAPI', {
+  scanNetwork: () => ipcRenderer.invoke('scan-network'),
+  getVersion: () => ipcRenderer.invoke('get-version'),
+  onScanResult: (callback) =>
+    ipcRenderer.on('scan-result', (_, data) => callback(data)),
+});
+```
+
+```javascript
+// renderer.js - use in the webpage
+const results = await window.electronAPI.scanNetwork();
+```
+
+## Key Points
+
+- With `contextIsolation: true`, the preload script's globals and the renderer's globals are completely separate. Only functions exposed via `contextBridge.exposeInMainWorld` are accessible.
+- The renderer can only use what's defined in `window.electronAPI`. Dangerous access like `require('child_process')` is impossible.
+- `ipcRenderer.invoke` returns a Promise for bidirectional communication. Handle it in the main process with `ipcMain.handle`.

_posts/2025-12-05-electron-context-isolation-preload-ja.md

@@ -0,0 +1,50 @@
+---
+layout: post
+title: "Electron contextIsolation + preloadセキュリティパターン"
+date: 2025-12-05 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Electron, security, contextIsolation, preload, IPC]
+author: "Kevin Park"
+lang: ja
+excerpt: "ElectronでcontextIsolationとpreloadスクリプトを使い、レンダラープロセスのNode.jsアクセスを安全に制限する方法をご紹介します。"
+---
+
+## 問題
+
+Electronで`nodeIntegration: true`にすると、レンダラー（Webページ）から`require('fs')`でファイルシステムに直接アクセスできます。外部URLをロードする場合、深刻なセキュリティリスクになります。
+
+## 解決方法
+
+```javascript
+// main.js - メインプロセス
+const mainWindow = new BrowserWindow({
+  webPreferences: {
+    preload: path.join(__dirname, 'preload.js'),
+    contextIsolation: true,   // レンダラーとNode.jsコンテキストを分離
+    nodeIntegration: false,   // レンダラーでrequireをブロック
+  }
+});
+```
+
+```javascript
+// preload.js - ブリッジ役割
+const { contextBridge, ipcRenderer } = require('electron');
+
+contextBridge.exposeInMainWorld('electronAPI', {
+  scanNetwork: () => ipcRenderer.invoke('scan-network'),
+  getVersion: () => ipcRenderer.invoke('get-version'),
+  onScanResult: (callback) =>
+    ipcRenderer.on('scan-result', (_, data) => callback(data)),
+});
+```
+
+```javascript
+// renderer.js - Webページで使用
+const results = await window.electronAPI.scanNetwork();
+```
+
+## ポイント
+
+- `contextIsolation: true`にすると、preloadスクリプトのグローバルオブジェクトとレンダラーのグローバルオブジェクトが完全に分離されます。`contextBridge.exposeInMainWorld`で許可された関数のみが公開されます。
+- レンダラーでできるのは`window.electronAPI`に定義されたことだけです。`require('child_process')`のような危険なアクセスは不可能です。
+- `ipcRenderer.invoke`はPromiseを返す双方向通信です。メインプロセスで`ipcMain.handle`で受け取って処理します。

_posts/2025-12-05-electron-context-isolation-preload.md

@@ -0,0 +1,50 @@
+---
+layout: post
+title: "Electron contextIsolation + preload 보안 패턴"
+date: 2025-12-05 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Electron, security, contextIsolation, preload, IPC]
+author: "Kevin Park"
+lang: ko
+excerpt: "Electron에서 contextIsolation과 preload 스크립트로 렌더러 프로세스의 Node.js 접근을 안전하게 제한하는 방법."
+---
+
+## 문제
+
+Electron에서 `nodeIntegration: true`로 하면 렌더러(웹페이지)에서 `require('fs')`로 파일 시스템에 직접 접근할 수 있다. 외부 URL을 로드하는 경우 심각한 보안 위험이 된다.
+
+## 해결
+
+```javascript
+// main.js - 메인 프로세스
+const mainWindow = new BrowserWindow({
+  webPreferences: {
+    preload: path.join(__dirname, 'preload.js'),
+    contextIsolation: true,   // 렌더러와 Node.js 컨텍스트 분리
+    nodeIntegration: false,   // 렌더러에서 require 차단
+  }
+});
+```
+
+```javascript
+// preload.js - 브릿지 역할
+const { contextBridge, ipcRenderer } = require('electron');
+
+contextBridge.exposeInMainWorld('electronAPI', {
+  scanNetwork: () => ipcRenderer.invoke('scan-network'),
+  getVersion: () => ipcRenderer.invoke('get-version'),
+  onScanResult: (callback) =>
+    ipcRenderer.on('scan-result', (_, data) => callback(data)),
+});
+```
+
+```javascript
+// renderer.js - 웹페이지에서 사용
+const results = await window.electronAPI.scanNetwork();
+```
+
+## 핵심 포인트
+
+- `contextIsolation: true`면 preload 스크립트의 전역 객체와 렌더러의 전역 객체가 완전히 분리된다. `contextBridge.exposeInMainWorld`로 허용된 함수만 노출한다.
+- 렌더러에서 할 수 있는 건 오직 `window.electronAPI`에 정의된 것뿐이다. `require('child_process')` 같은 위험한 접근은 불가능하다.
+- `ipcRenderer.invoke`는 Promise를 반환하는 양방향 통신이다. 메인 프로세스에서 `ipcMain.handle`로 받아서 처리한다.

_posts/2025-12-20-redis-key-naming-convention-en.md

@@ -0,0 +1,40 @@
+---
+layout: post
+title: "Redis Key Naming Convention - Hierarchical Key Design"
+date: 2025-12-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Redis, naming convention, key design, TypeScript]
+author: "Kevin Park"
+lang: en
+excerpt: "Organize Redis keys with a hierarchical naming convention and TypeScript helper functions."
+---
+
+## Problem
+
+Redis keys like `"user_123_session"` and `"sess-user-123"` created inconsistently make it impossible to track what keys exist or search with `KEYS *`.
+
+## Solution
+
+```typescript
+const KEY_PREFIX = 'myapp';
+
+export const keys = {
+  conversation: (id: string) => `${KEY_PREFIX}:conv:${id}`,
+  conversationMessages: (id: string) => `${KEY_PREFIX}:conv:${id}:messages`,
+  userSettings: (id: string) => `${KEY_PREFIX}:settings:${id}`,
+  userSession: (id: string) => `${KEY_PREFIX}:session:${id}`,
+  allConversations: () => `${KEY_PREFIX}:conversations`,
+  monthlyIndex: (ym: string) => `${KEY_PREFIX}:conv:month:${ym}`,
+  cacheProduct: (id: string) => `${KEY_PREFIX}:cache:product:${id}`,
+};
+
+// Usage
+await redis.set(keys.conversation('abc123'), JSON.stringify(data));
+await redis.del(keys.userSession('user1'));
+```
+
+## Key Points
+
+- Colons (`:`) as hierarchy separators are the Redis community standard. GUI tools like RedisInsight display this structure as a tree.
+- Generating keys via functions eliminates typos and enables IDE autocompletion. String literals make future refactoring impossible.
+- A `KEY_PREFIX` allows multiple apps to coexist on the same Redis instance without key collisions.

_posts/2025-12-20-redis-key-naming-convention-ja.md

@@ -0,0 +1,40 @@
+---
+layout: post
+title: "Redisキーのネーミング規則 - 階層的構造で管理する"
+date: 2025-12-20 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Redis, naming convention, key design, TypeScript]
+author: "Kevin Park"
+lang: ja
+excerpt: "Redisキーを体系的に管理するネーミング規則とTypeScriptヘルパー関数パターンをご紹介します。"
+---
+
+## 問題
+
+Redisキーを`"user_123_session"`、`"sess-user-123"`のようにバラバラに作っていると、どんなキーがあるのか把握できず、`KEYS *`検索も困難です。
+
+## 解決方法
+
+```typescript
+const KEY_PREFIX = 'myapp';
+
+export const keys = {
+  conversation: (id: string) => `${KEY_PREFIX}:conv:${id}`,
+  conversationMessages: (id: string) => `${KEY_PREFIX}:conv:${id}:messages`,
+  userSettings: (id: string) => `${KEY_PREFIX}:settings:${id}`,
+  userSession: (id: string) => `${KEY_PREFIX}:session:${id}`,
+  allConversations: () => `${KEY_PREFIX}:conversations`,
+  monthlyIndex: (ym: string) => `${KEY_PREFIX}:conv:month:${ym}`,
+  cacheProduct: (id: string) => `${KEY_PREFIX}:cache:product:${id}`,
+};
+
+// 使用例
+await redis.set(keys.conversation('abc123'), JSON.stringify(data));
+await redis.del(keys.userSession('user1'));
+```
+
+## ポイント
+
+- コロン（`:`）で階層を区切るのがRedisコミュニティの標準です。RedisInsightなどのGUIツールがこの構造をツリー表示してくれます。
+- 関数でキーを生成するとタイプミスがなくなり、IDEの自動補完も効きます。文字列リテラルを直接使うと将来のリファクタリングが不可能になります。
+- プレフィックス（`KEY_PREFIX`）があれば、同じRedisインスタンスで複数のアプリがキー衝突なく共存できます。