refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조

에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

10_Wiki/Topics/Domain_Programming/Harness_Research_2026-05/LLM-as-judge.md

@@ -0,0 +1,27 @@
+# [[LLM-as-judge]]
+
+## 📌 Brief Summary
+LLM-as-judge는 인공지능 에이전트 하네스 환경에서 모델의 산출물이나 시스템의 동작을 평가하기 위해 대규모 언어 모델(LLM) 자체를 심사관(judge)으로 활용하는 추론적(Inferential) 제어 및 평가 방식이다 [1, 2]. 주로 AI 코드 리뷰, 의미론적 분석, 응답 품질의 지속적 샘플링 및 로그 이상 징후 탐지 등에 활용된다 [2, 3]. 이를 통해 인간 개발자가 모든 것을 검토하지 않고도 에이전트의 워크플로우를 테스트하고 신뢰할 수 있는 검증 루프를 구축할 수 있도록 돕는다 [1, 2].
+
+## 📖 Core Content
+* **추론적 피드백 센서로서의 역할:** 에이전트 하네스 내에서 LLM-as-judge는 의미론적 판단(Semantic judgment)이 필요한 문제를 다루는 '추론적 센서(Inferential sensor)'로 기능한다 [2, 4]. 린터(Linter)나 단위 테스트와 같이 빠르고 결정론적인 연산적(Computational) 센서와 달리, 문맥적 이해가 필요한 AI 코드 리뷰나 응답 품질 모니터링 등의 영역에서 에이전트의 상태를 감시하고 오류를 식별한다 [2, 3].
+* **평가 및 CI 파이프라인 통합:** 다양한 에이전트 프레임워크와 관측 도구들은 LLM-as-judge를 기본 평가 메커니즘으로 채택하고 있다. `promptfoo`, `Weights & Biases Weave`, `Mastra` 등의 도구는 LLM-as-judge를 내장하여 에이전트 산출물의 회귀 테스트를 CI(지속적 통합) 파이프라인에 직접 통합할 수 있도록 지원한다 [1, 5, 6].
+* **평가자 모델 역량에 대한 높은 의존성:** Red Hat의 평가 주도 개발(Eval-Driven Development) 사례 연구에 따르면, LLM-as-judge 역할을 수행하는 평가자 모델의 역량(Capability)은 평가의 정확도에 결정적인 영향을 미친다 [1]. 실제 실험에서 대형 모델(llama-3-3-70b)은 알려진 실패 사례를 모두 잡아낸 반면, 더 작은 모델들은 여러 실패 사례를 놓치는 한계를 보였다 [1]. 즉, 적절하고 강력한 모델을 평가자로 사용할 때만 시스템에 대한 실질적인 신뢰도를 높일 수 있다 [2].
+
+## ⚖️ Trade-offs & Caveats
+* **높은 비용 및 실행 지연:** LLM-as-judge는 GPU나 NPU 자원을 사용하기 때문에 전통적인 연산적 센서에 비해 실행 속도가 느리고 비용이 많이 든다 [2, 4]. 따라서 에이전트가 코드를 변경하는 모든 커밋(Commit)마다 LLM-as-judge를 실행하는 것은 경제적으로나 시간적으로 비효율적이다 [4].
+* **비결정성(Non-determinism)과 평가 피로:** 확률론적 모델에 기반하므로 평가 결과가 항상 100% 동일하게 보장되지 않는 비결정성을 띤다 [2, 4]. 
+* **설계적 제약:** 무분별한 LLM-as-judge의 사용은 막대한 평가 비용으로 인해 시스템 전체를 무너뜨릴 수 있으므로(eval cost collapse), 유의미한 리스크를 줄일 수 있는 핵심적인 위치에만 값비싼 검사를 추가하는 계층적 가드레일 설계가 필수적이다 [1].
+
+---
+*Last updated: 2026-05-05*
+
+## 🛠️ 적용 사례 (Applied in summary)
+
+<!-- CODE-GROUNDING:START -->
+### 🔎 코드베이스 근거 (자동 추출 — E:\Wiki 레포)
+**실제 구현/사용 위치:**
+- `connectai/src/retrieval/evalHarness.ts:9` — * 의도적으로 LLM 을 쓰지 않는다 (재현 가능 + 무료 + CI 가능). LLM-as-Judge 기반의
+
+_자동 생성: code_grounding.mjs · 재실행 시 갱신됨_
+<!-- CODE-GROUNDING:END -->