sungbin1015 · Jun 9, 2026 · Jun 9, 2026 · Jun 9, 2026 · Jun 9, 2026
diff --git a/.github/workflows/pr-build.yml b/.github/workflows/pr-build.yml
@@ -29,7 +29,7 @@ jobs:
       - name: Checkout docs/ from main (콘텐츠는 main에서 관리됨)
         run: |
           git fetch origin main
-          git checkout origin/main -- docs/ docs_en/ static/img/
+          git checkout origin/main -- docs/ blog/ static/img/
 
       - name: Setup Node.js
         uses: actions/setup-node@v4

diff --git a/docs/poc/.notion-sync.json b/docs/poc/.notion-sync.json
@@ -29,8 +29,8 @@
   },
   "373e15b4-0359-8150-88f3-eedc5ebd727b": {
     "file": "docs/poc/vision-bench/2편-추론-파라미터-튜닝-qwen3-omni-6초-클립-분석-ofat-스윕.md",
-    "last_edited": "2026-06-09T05:29:00.000Z",
-    "content_hash": "fbd70bd2bb243e97476c43dd2a895ac9a471638774369fdafaa27ea3022c8700",
+    "last_edited": "2026-06-09T05:42:00.000Z",
+    "content_hash": "131ff06a6a90cae1d11307440580d880fa02bb2d5d36e57e831389d42fd67f61",
     "order": 3,
     "parent_id": "vision-bench"
   },

diff --git a/docs/poc/vision-bench/2편-추론-파라미터-튜닝-qwen3-omni-6초-클립-분석-ofat-스윕.md b/docs/poc/vision-bench/2편-추론-파라미터-튜닝-qwen3-omni-6초-클립-분석-ofat-스윕.md
@@ -144,35 +144,23 @@ SceneMaker 프로젝트에서 **대사(STT)분석은 WhisperX의** 별도 모듈
 
 ### 3.3. 측정 지표
 
-각 설정마다 70개 출력에서 아래 지표를 집계한다. 모두 **정답지 없이 출력만으로** 계산되는 순응·형태 지표다.
+1편에서 식별된 네 가지 품질저하 패턴(**조기 종료·붕괴·반복·추론 시간 편차** )을 **정답지 없이 출력만으로** 탐지·정량화하기 위해, 각 설정의 70개 출력에서 아래 지표를 집계한다. 각 지표는 위 이상현상 중 하나 이상을 겨냥하며, 모두 단일 패스(n=70)로 안정적으로 잡히는 순응·형태 지표다.
 
 | **지표** | **정의** | **무엇을 보나** |
 | --- | --- | --- |
 | `ok` | 스키마 통과(파싱·검증 성공) 레코드 수 (/70) | 형식 순응 |
-| `lat_p50` / `lat_p95` | 클립당 추론 시간(ms)의 중앙값 · 95퍼센타일 | 추론 지연 · 시간 편차(Latency Jitter) |
+| `lat_p50` / `lat_p95` /`lat_avg` | 클립당 추론 시간(ms)의 중앙값 · 95백분위수 · 평균 | 추론 지연 · 시간 편차 |
 | `items` | 배열 필드별 평균 항목 수 (`objects` ·`ocr` ·`actions` ·`bgm` ·`sfx` ) | 정보량 |
 | `purity` | 한글 / (한글 + 라틴) 문자 비율 (1.0에 가까울수록 순수 한글) | 언어 순도(이종문자 오염) |
 | `repeat` | 항목 중복·토큰 루프가 발생한 레코드 수 (/70) | 반복 |
 
-이 지표들은 **모든 출력에 존재** 하므로 n=70 단일 패스로 안정적으로 집계된다. 다만 degeneration(붕괴)은 드물게 터지는 희귀사건이라 *빈도* 자체가 배치 동시성 jitter 에 흔들리므로, 본 단계에서는 **참고용 카운트로만** 보고 결론으로 삼지 않는다.
+측정한 이상현상은 **처방이 갈린다.** 반복 중 정규화하면 똑같아지는 exact-중복은 후처리(dedup)로 **무손실 제거** 할 수 있지만, 토큰 루프·이종문자 붕괴는 후처리로 복원할 수 없어 **생성 단계(파라미터)에서 막아야** 한다. 이 구분이 뒤의 파라미터 효과·결론 절에서 "무엇을 파라미터로 풀고 무엇을 후처리로 푸나"를 가른다. 단 **붕괴 빈도** 자체는 드물게 터지는 희귀사건이라 배치 동시성 jitter 에 흔들려, 본 단계에서는 참고용 카운트로만 보고 결론으로 삼지 않는다.
 
-## 4. 세 가지 실패 양상
-
-1절에서 예고한 출력 이상은 세 가지로 분류된다. **셋 다 정답지 없이 탐지 가능** 하다 — 그래서 1단계에서 다룰 수 있다.
-
-| **양상** | **실제 출력 예 (70샘플에서)** | **탐지 방법** |
-| --- | --- | --- |
-| **반복** | `audio: ["(대사)아","(대사)아","(대사)아"]` · `actions: ["무장"×9]` | 정규화 후 exact-중복 · 토큰 루프 |
-| **파편화** | 한 나레이션이 `"…결론적으로"` · `"…울산지검"` · `"…의정부지검"` 세 조각으로 쪼개짐 | (정성 — 자동 탐지 어려움) |
-| **degeneration(붕괴)** | `시гля … Arial TTF … Ginseng` — 이종문자 블록 · 미완 JSON | 이종문자 비율 · 미완 JSON · `finish_reason=length` |
-
-세 양상은 **처방이 갈린다.** 반복 중 정규화하면 똑같아지는 exact-중복은 후처리(dedup)로 **무손실 제거** 할 수 있지만, 파편화·토큰 루프·이종문자는 후처리로 복원할 수 없어 **생성 단계(파라미터)에서 막아야** 한다. 이 구분이 뒤에서 "무엇을 파라미터로 풀고 무엇을 후처리로 푸나"를 가른다.
-
-## 5. 파라미터별 효과
+## 4. 파라미터별 효과
 
 표의 약어 — `obj/act/aud` = objects/actions/audio 평균 항목 수, `purity` = 한글 / (한글+라틴), `repeat` = 항목 중복·토큰 루프 레코드 수(/70), `comp_p50` = completion 토큰 중앙값.
 
-### 5.1. temperature — 낮을수록 가장 깨끗
+### 4.1. temperature — 낮을수록 가장 깨끗
 
 | **temp** | **ok** | **comp_p50** | **obj/act/aud** | **purity** | **repeat** |
 | --- | --- | --- | --- | --- | --- |
@@ -183,7 +171,7 @@ SceneMaker 프로젝트에서 **대사(STT)분석은 WhisperX의** 별도 모듈
 
 온도를 올릴수록 고장 *방식* 이 달라진다. temp 0.7 에서는 중증 반복(`무장` ×9 류 배열 도배, 잉여 항목 63개)이, temp 1.0 에서는 이종문자 word-salad(`시гля` ·`Arial TTF` )가 터지며 한글 순도가 **0.79** 로 무너진다. **0.0\~0.3 이 가장 깨끗** 하다. 흔한 "temp 를 올려 안정화" 처방과 정반대다 — 짧은 guided-JSON 출력에서는 greedy(temp=0)가 가장 안정적이다.
 
-### 5.2. frequency / repetition penalty — 반복의 레버, 단 항목도 같이 깎임
+### 4.2. frequency / repetition penalty — 반복의 레버, 단 항목도 같이 깎임
 
 | **설정** | **obj/act/aud** | **repeat** | **비고** |
 | --- | --- | --- | --- |
@@ -194,24 +182,24 @@ SceneMaker 프로젝트에서 **대사(STT)분석은 WhisperX의** 별도 모듈
 | rep 1.1 | 6.3 / 3.8 / 3.6 | 6 | freq 와 유사 거동 |
 | rep 1.3 | 4.7 / 3.3 / **1.3** | 1 | audio 급감 |
 
-페널티는 반복을 직접 줄인다. freq 0→0.5 만으로 반복 레코드가 18→6 으로 줄고 실패도 0 이며, 흩어진 나레이션 조각을 **한 문장으로 복원** 하기까지 한다. 단 대가가 있다 — 페널티를 올릴수록 항목 개수가 함께 줄어, freq 2.0·rep 1.3 에서는 audio 가 절반 이하(4.7→1.6 / 1.3)로 급감한다. **이 개수 감소가 "잉여 제거(좋음)"인지 "진짜 정보 삭제(나쁨)"인지는 정답지 없이 판정할 수 없다** — 6·7절의 핵심 쟁점이다.
+페널티는 반복을 직접 줄인다. freq 0→0.5 만으로 반복 레코드가 18→6 으로 줄고 실패도 0 이며, 흩어진 나레이션 조각을 **한 문장으로 복원** 하기까지 한다. 단 대가가 있다 — 페널티를 올릴수록 항목 개수가 함께 줄어, freq 2.0·rep 1.3 에서는 audio 가 절반 이하(4.7→1.6 / 1.3)로 급감한다. **이 개수 감소가 "잉여 제거(좋음)"인지 "진짜 정보 삭제(나쁨)"인지는 정답지 없이 판정할 수 없다** — 5·6절의 핵심 쟁점이다.
 
-### 5.3. top_k / top_p / fps — 반복엔 거의 무관
+### 4.3. top_k / top_p / fps — 반복엔 거의 무관
 
 - **top_k / top_p** (temp=0.7 anchor): 후보를 조이면 반복이 *약간* 준다(17→14, 19→15). 결정적이지 않다.
 - **fps** (0.5 / 1.0 / 2.0): 반복 레코드가 16에서 21 사이로, fps 변화와 **무관** 하다. fps 는 비전 디테일·토큰량의 축이라 순응이 아니라 *정확도* (다음 단계) 관점에서 봐야 한다.
 
-## 6. 핵심 발견
+## 5. 핵심 발견
 
 1. **반복은 흔하다 — 기본 설정에서 약 26%(18/70)** 가 항목 중복이다. 주로 `audio` (반복 배경음·짧은 추임새 `아` /`그렇죠` )와 `actions` 에서 나타나며, temperature·top_k·top_p·fps 로는 거의 줄지 않는다(평탄).
-2. **온도대별 고장 방식이 다르다** (5.1): temp 0.7 = 중증 반복, temp 1.0 = 이종문자 발생. **저온(≤0.3)이 가장 깨끗** 하다.
+2. **온도대별 고장 방식이 다르다** (4.1): temp 0.7 = 중증 반복, temp 1.0 = 이종문자 발생. **저온(≤0.3)이 가장 깨끗** 하다.
 3. **frequency / repetition penalty 가 반복의 진짜 레버다** (temperature·top_k 와 대조). freq 0→0.5 만으로 반복 18→6 + 실패 0, 게다가 **숨기는 게 아니라 실제로 고친다** — 파편화된 나레이션 세 조각을 온전한 한 문장으로 복원한다.
 4. **단, 페널티** ***크기*** **는 1단계에서 정하지 않는다 (정직성의 핵심).** 페널티를 올리면 항목 개수가 줄지만, **개수 감소가 "잉여 제거(좋음)"인지 "진짜 정보 삭제(나쁨)"인지 정답지 없이 구분할 수 없다.** 실제로 한 사례(뉴스 클립)는 페널티가 *파편을 합쳐* 개수가 준 것이라 방향이 정반대였다. recall 을 볼 신호가 없으므로 최적 크기는 다음 단계(Gemini 목적함수)로 넘긴다 — 이는 한계가 아니라 **측정 가능한 것만 결론짓는다는 원칙** 이다.
 5. **명백한 exact-중복은 dedup 으로 해결한다 (페널티 불필요).** 정규화 중복 제거는 정의상 정보 손실 0 — 반복 레코드는 18→**4** (잔존은 파편화·토큰 루프)로 줄지만 unique 항목 수는 7.5→7.4 로 거의 불변이다. 즉 **반복의 대부분은 페널티로 recall 을 깎지 않고도 후처리로 없앨 수 있다.**
 
-## 7. 결론
+## 6. 결론
 
-### 7.1. 파라미터 leverage 순위·방향
+### 6.1. 파라미터 leverage 순위·방향
 
 dedup 적용 후 **잔존 순응위반** (이종문자·degeneration·토큰 루프 등 dedup 으로 못 잡는 것) 기준으로 파라미터 leverage 를 산정했다. `clean%` = 위반 0 레코드 비율.
 
@@ -222,7 +210,7 @@ dedup 적용 후 **잔존 순응위반** (이종문자·degeneration·토큰 루
 | 3 | top_k / top_p | 89\~94% (작음) | 미미 | 후순위 |
 | 3 | fps | 90\~94% (순응 무관) | 콘텐츠 디테일 축 | → 다음 단계 (정확도) |
 
-### 7.2. 잠정 입력 파라미터
+### 6.2. 잠정 입력 파라미터
 
 위 분석으로 정한, **품질 목적함수(다음 단계) 이전의 baseline** 이다.
 
@@ -245,7 +233,7 @@ dedup 적용 후 **잔존 순응위반** (이종문자·degeneration·토큰 루
 - ⚠️ **다음 단계** (상위 모델 정답지 필요): 페널티 *크기* · fps · 전반적 품질(완전·정확)
 :::
 
-### 7.3. 다음 단계 핸드오프
+### 6.3. 다음 단계 핸드오프
 
 품질 목적함수(Gemini 정답지)를 세운 뒤, 1단계가 좁혀 준 탐색만 수행한다.
 

diff --git a/docusaurus.config.ts b/docusaurus.config.ts
@@ -14,7 +14,9 @@ const config: Config = {
   // Future flags, see https://docusaurus.io/docs/api/docusaurus-config#future
   future: {
     v4: true,
-    faster: false, // 네이티브 바이너리(Rspack/SWC/lightningcss)가 이 환경에서 SIGBUS 발생
+    // Rspack/SWC/Lightning CSS 기반 가속 빌드 — Docusaurus 3.10 stable.
+    // 로컬 서버 환경에서는 네이티브 바이너리 SIGBUS가 보고된 적 있어, 필요 시 false로 롤백.
+    faster: true,
   },
 
   markdown: {