docs(blog): 13차 배치 팁 포스트 5개 추가 (3개 언어)

Author: realcoding2003

_posts/2026-03-15-git-bisect-find-bug-binary-search-en.md

@@ -0,0 +1,64 @@
+---
+layout: post
+title: "git bisect - Find the Bug-Introducing Commit with Binary Search"
+date: 2026-03-15 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Git, git bisect, Debugging, Binary Search]
+author: "Kevin Park"
+lang: en
+excerpt: "Use git bisect to quickly find the exact commit that introduced a bug using binary search."
+---
+
+## Problem
+
+A bug appeared at some point, but with hundreds of commits to check, going through them one by one was impossible. All I knew was "it worked last week."
+
+## Solution
+
+`git bisect` uses binary search to find the commit that introduced a bug. Even 1024 commits only need 10 checks.
+
+```bash
+# Start bisect
+git bisect start
+
+# Mark current state (has bug) as bad
+git bisect bad
+
+# Mark a known working commit as good
+git bisect good abc1234
+```
+
+Git checks out a commit in the middle. Test it and report the result.
+
+```bash
+# If this commit has the bug
+git bisect bad
+
+# If this commit works fine
+git bisect good
+
+# Repeat until it finds the culprit
+# "abc5678 is the first bad commit"
+```
+
+With a test script, you can fully automate the process.
+
+```bash
+# Exit code 0 = good, non-zero = bad
+git bisect run npm test
+
+# Or use a custom script
+git bisect run ./check-bug.sh
+```
+
+When done, return to your original branch.
+
+```bash
+git bisect reset
+```
+
+## Key Points
+
+- For N commits, you need at most log2(N) checks. 1000 commits? Just 10 checks
+- `git bisect run` automates the entire process — hands-free bug hunting
+- If you hit a commit that doesn't build, use `git bisect skip` to skip it

_posts/2026-03-15-git-bisect-find-bug-binary-search-ja.md

@@ -0,0 +1,64 @@
+---
+layout: post
+title: "git bisectでバグの原因コミットを特定する - 二分探索デバッグ"
+date: 2026-03-15 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Git, git bisect, Debugging, Binary Search]
+author: "Kevin Park"
+lang: ja
+excerpt: "git bisectを使って、バグを導入したコミットを二分探索で素早く特定する方法をご紹介します。"
+---
+
+## 問題
+
+ある時点からバグが発生しましたが、コミットが数百件あり、一つずつ確認するのは不可能でした。「先週までは動いていたのに...」と繰り返すばかりでした。
+
+## 解決方法
+
+`git bisect`は二分探索でバグを導入したコミットを見つけてくれます。1024個のコミットでも10回の確認で済みます。
+
+```bash
+# bisectを開始
+git bisect start
+
+# 現在の状態（バグあり）をbadとしてマーク
+git bisect bad
+
+# バグがなかった時点をgoodとしてマーク
+git bisect good abc1234
+```
+
+gitが中間のコミットにチェックアウトしてくれます。テストして結果を報告します。
+
+```bash
+# このコミットにバグがある場合
+git bisect bad
+
+# このコミットにバグがない場合
+git bisect good
+
+# 繰り返すと原因コミットを特定してくれます
+# "abc5678 is the first bad commit"
+```
+
+テストスクリプトがあれば完全自動化も可能です。
+
+```bash
+# スクリプトの終了コード0ならgood、それ以外ならbad
+git bisect run npm test
+
+# または特定のスクリプトを指定
+git bisect run ./check-bug.sh
+```
+
+終了したら元のブランチに戻ります。
+
+```bash
+git bisect reset
+```
+
+## ポイント
+
+- コミット数がN個なら最大log2(N)回の確認で済みます。1000コミットでも10回で十分です
+- `git bisect run`でテストを自動化すれば、完全に手放しで原因を特定できます
+- bisect中にビルドできないコミットに当たった場合は`git bisect skip`でスキップできます

_posts/2026-03-15-git-bisect-find-bug-binary-search.md

@@ -0,0 +1,64 @@
+---
+layout: post
+title: "git bisect로 버그 원인 커밋 찾기 - 이진 탐색 디버깅"
+date: 2026-03-15 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Git, git bisect, Debugging, Binary Search]
+author: "Kevin Park"
+lang: ko
+excerpt: "git bisect를 사용해 버그를 만든 커밋을 이진 탐색으로 빠르게 찾는 방법을 정리한다."
+---
+
+## 문제
+
+어느 시점부터 버그가 생겼는데 커밋이 수백 개라 하나씩 확인하는 건 불가능했다. "분명 지난주까지는 됐는데..."라는 말만 반복하고 있었다.
+
+## 해결
+
+`git bisect`는 이진 탐색으로 버그를 만든 커밋을 찾아준다. 1024개 커밋도 10번만 확인하면 된다.
+
+```bash
+# bisect 시작
+git bisect start
+
+# 현재(버그 있음)를 bad로 표시
+git bisect bad
+
+# 버그 없던 시점을 good으로 표시
+git bisect good abc1234
+```
+
+이제 git이 중간 커밋으로 체크아웃해준다. 테스트하고 결과를 알려주면 된다.
+
+```bash
+# 이 커밋에서 버그가 있으면
+git bisect bad
+
+# 이 커밋에서 버그가 없으면
+git bisect good
+
+# 반복하면 원인 커밋을 찾아준다
+# "abc5678 is the first bad commit"
+```
+
+테스트 스크립트가 있으면 완전 자동화도 가능하다.
+
+```bash
+# 스크립트 종료코드 0이면 good, 아니면 bad
+git bisect run npm test
+
+# 또는 특정 스크립트
+git bisect run ./check-bug.sh
+```
+
+끝나면 원래 브랜치로 돌아간다.
+
+```bash
+git bisect reset
+```
+
+## 핵심 포인트
+
+- 커밋 수가 N개면 최대 log2(N)번만 확인하면 된다. 1000개 커밋도 10번이면 충분하다
+- `git bisect run`으로 테스트를 자동화하면 아예 손 안 대고 원인을 찾을 수 있다
+- bisect 중에 빌드가 안 되는 커밋을 만나면 `git bisect skip`으로 건너뛸 수 있다

_posts/2026-03-16-postgresql-jsonb-query-index-gin-en.md

@@ -0,0 +1,63 @@
+---
+layout: post
+title: "PostgreSQL JSONB Query Optimization with GIN Index"
+date: 2026-03-16 09:00:00 +0900
+categories: [Development, Tips]
+tags: [PostgreSQL, JSONB, GIN Index, Database]
+author: "Kevin Park"
+lang: en
+excerpt: "Speed up PostgreSQL JSONB queries by adding a GIN index for fast key-value lookups inside JSON data."
+---
+
+## Problem
+
+Stored user settings in a JSONB column, but querying by specific keys triggers a full table scan.
+
+```sql
+-- metadata column is JSONB
+SELECT * FROM users
+WHERE metadata->>'role' = 'admin';
+-- Seq Scan... slow
+```
+
+## Solution
+
+A GIN index enables indexed lookups inside JSONB data.
+
+```sql
+-- Create GIN index
+CREATE INDEX idx_users_metadata ON users USING GIN (metadata);
+
+-- Use @> containment operator (uses GIN index)
+SELECT * FROM users
+WHERE metadata @> '{"role": "admin"}';
+```
+
+If you only query specific keys, an expression index is more efficient.
+
+```sql
+-- B-tree index on a specific path
+CREATE INDEX idx_users_role ON users ((metadata->>'role'));
+
+-- This query now uses the index
+SELECT * FROM users
+WHERE metadata->>'role' = 'admin';
+```
+
+Nested JSON is accessible via path operators.
+
+```sql
+-- Access nested keys
+SELECT * FROM users
+WHERE metadata #>> '{address,city}' = 'Seoul';
+
+-- jsonpath also works (PostgreSQL 12+)
+SELECT * FROM users
+WHERE metadata @? '$.tags[*] ? (@ == "vip")';
+```
+
+## Key Points
+
+- Use the `@>` containment operator to leverage GIN indexes. The `->>` operator requires an expression index instead
+- GIN indexes slow down writes — best suited for read-heavy tables
+- Always use JSONB over JSON. JSONB stores data in binary format, making searches significantly faster

_posts/2026-03-16-postgresql-jsonb-query-index-gin-ja.md

@@ -0,0 +1,63 @@
+---
+layout: post
+title: "PostgreSQL JSONBクエリ最適化 - GINインデックスで高速検索"
+date: 2026-03-16 09:00:00 +0900
+categories: [Development, Tips]
+tags: [PostgreSQL, JSONB, GIN Index, Database]
+author: "Kevin Park"
+lang: ja
+excerpt: "PostgreSQLのJSONBカラムにGINインデックスを設定し、JSONデータを高速に検索する方法をご紹介します。"
+---
+
+## 問題
+
+ユーザー設定をJSONBカラムに保存しましたが、特定のキーで検索するとフルスキャンが走って遅くなりました。
+
+```sql
+-- metadataカラムがJSONBのテーブル
+SELECT * FROM users
+WHERE metadata->>'role' = 'admin';
+-- Seq Scan... 遅い
+```
+
+## 解決方法
+
+GINインデックスを作成すると、JSONB内部のキー・値検索がインデックスを利用できます。
+
+```sql
+-- GINインデックスを作成
+CREATE INDEX idx_users_metadata ON users USING GIN (metadata);
+
+-- @>演算子で検索（GINインデックスを使用）
+SELECT * FROM users
+WHERE metadata @> '{"role": "admin"}';
+```
+
+特定のキーだけを頻繁に検索する場合は、Expressionインデックスがより効率的です。
+
+```sql
+-- 特定パスにB-treeインデックス
+CREATE INDEX idx_users_role ON users ((metadata->>'role'));
+
+-- このクエリがインデックスを利用するようになります
+SELECT * FROM users
+WHERE metadata->>'role' = 'admin';
+```
+
+ネストされたJSONもパス演算子でアクセスできます。
+
+```sql
+-- ネストされたキーへのアクセス
+SELECT * FROM users
+WHERE metadata #>> '{address,city}' = 'Seoul';
+
+-- jsonpathも使用可能（PostgreSQL 12以降）
+SELECT * FROM users
+WHERE metadata @? '$.tags[*] ? (@ == "vip")';
+```
+
+## ポイント
+
+- `@>`包含演算子を使うことでGINインデックスが利用されます。`->>`演算子にはGINではなくExpressionインデックスが必要です
+- GINインデックスは書き込みが遅くなるトレードオフがあります。読み取り中心のテーブルに適しています
+- JSONBはバイナリ形式で保存されるため、JSONより検索が高速です。カラム型はJSONではなくJSONBを使いましょう

_posts/2026-03-16-postgresql-jsonb-query-index-gin.md

@@ -0,0 +1,63 @@
+---
+layout: post
+title: "PostgreSQL JSONB 쿼리 최적화 - GIN 인덱스로 빠르게 검색하기"
+date: 2026-03-16 09:00:00 +0900
+categories: [Development, Tips]
+tags: [PostgreSQL, JSONB, GIN Index, Database]
+author: "Kevin Park"
+lang: ko
+excerpt: "PostgreSQL JSONB 컬럼에 GIN 인덱스를 걸어 JSON 데이터를 빠르게 검색하는 방법을 정리한다."
+---
+
+## 문제
+
+사용자 설정을 JSONB 컬럼에 저장했는데, 특정 키로 검색하면 풀 스캔을 때려서 느렸다.
+
+```sql
+-- metadata 컬럼이 JSONB인 테이블
+SELECT * FROM users
+WHERE metadata->>'role' = 'admin';
+-- Seq Scan... 느리다
+```
+
+## 해결
+
+GIN 인덱스를 걸면 JSONB 내부 키/값 검색이 인덱스를 탄다.
+
+```sql
+-- GIN 인덱스 생성
+CREATE INDEX idx_users_metadata ON users USING GIN (metadata);
+
+-- @> 연산자로 검색 (GIN 인덱스 사용)
+SELECT * FROM users
+WHERE metadata @> '{"role": "admin"}';
+```
+
+특정 키만 자주 검색한다면 Expression 인덱스가 더 효율적이다.
+
+```sql
+-- 특정 경로에 B-tree 인덱스
+CREATE INDEX idx_users_role ON users ((metadata->>'role'));
+
+-- 이제 이 쿼리가 인덱스를 탄다
+SELECT * FROM users
+WHERE metadata->>'role' = 'admin';
+```
+
+중첩된 JSON도 경로 연산자로 접근 가능하다.
+
+```sql
+-- 중첩 키 접근
+SELECT * FROM users
+WHERE metadata #>> '{address,city}' = 'Seoul';
+
+-- jsonpath도 사용 가능 (PostgreSQL 12+)
+SELECT * FROM users
+WHERE metadata @? '$.tags[*] ? (@ == "vip")';
+```
+
+## 핵심 포인트
+
+- `@>` 포함 연산자를 써야 GIN 인덱스를 탄다. `->>` 연산자는 GIN이 아니라 Expression 인덱스가 필요하다
+- GIN 인덱스는 쓰기가 느려지는 트레이드오프가 있다. 읽기 위주 테이블에 적합하다
+- JSONB는 바이너리 저장이라 JSON보다 검색이 빠르다. 컬럼 타입을 JSON이 아닌 JSONB로 쓰자