[P-Reinforce] Wikify Legacy Migration, Core Agent Protocols, Engineering Principles, and Git Workflows

2026-05-01 09:35:56 +09:00
parent 8083f59e40
commit e5c33f24f6
53 changed files with 1049 additions and 1739 deletions
@@ -0,0 +1,41 @@
+---
+id: b3c4d5e6-f7a8-4b9c-0d1e-2f3a4b5c6d7e
+category: "[[10_Wiki/Topics/AI]]"
+confidence_score: 0.97
+tags: [a2a, agent, protocol, multi-agent, communication, infrastructure]
+last_reinforced: 2026-05-01
+github_commit: "wikification-a2a"
+---
+
+# [[Agent-to-Agent (A2A)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> A2A는 서로 다른 하네스나 원격지에 위치한 에이전트들이 작업을 위임하고 상태를 공유하며 협업할 수 있도록 돕는 상호운용성 네트워크 표준 프로토콜이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. A2A의 정의 및 목적
+- **에이전트 간 통신망**: 단일 하네스를 넘어 분산된 에이전트 생태계를 연결한다.
+- **작업 위임(Delegation)**: 상위 오케스트레이터 에이전트가 특정 도메인 전문가 에이전트에게 하위 작업을 맡기고 결과를 회수하는 과정을 규격화한다.
+
+### 2. 주요 메커니즘
+- **메시지 라우팅**: 요청-응답(Request-Response) 및 이벤트 발행-구독(Pub-Sub) 모델을 통해 에이전트 간 정보를 교환한다.
+- **컨텍스트 전파**: 작업을 위임할 때 필요한 최소한의 문맥(Context)과 권한(Authorization)을 안전하게 전달한다.
+- **역할 정의**: 송신자(Requester)와 수신자(Worker) 간의 인터페이스 및 책임 범위를 명시한다.
+
+### 3. MCP와의 관계
+- **수평적/수직적 확장**: MCP가 '에이전트-도구' 간의 수직적 통합을 담당한다면, A2A는 '에이전트-에이전트' 간의 수평적 협업을 담당하여 완전한 통신 스택을 형성한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **보안 경계**: 원격 에이전트 호출 시 신뢰할 수 없는 데이터가 주입될 위험이 있으며, 교차 인증 및 데이터 검증 계층이 필수적이다.
+- **오케스트레이션 복잡성**: 에이전트가 많아질수록 통신 지연과 상태 불일치 문제가 발생하며, 이를 관리하기 위한 분산 시스템 수준의 설계가 요구된다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/AI]]
+- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Agentic Software Engineering]]
+- **Raw Source**: [[00_Raw/Agent-to-Agent (A2A)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Agent-to-Agent (A2A) Protocol"`
+3. Push: `git push origin main`
@@ -0,0 +1,42 @@
+---
+id: a2b3c4d5-e6f7-4a8b-9c0d-1e2f3a4b5c6d
+category: "[[10_Wiki/Topics/AI]]"
+confidence_score: 0.98
+tags: [aci, agent, interface, llm, infrastructure, harness]
+last_reinforced: 2026-05-01
+github_commit: "wikification-aci"
+---
+
+# [[Agent-Computer Interface (ACI)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> ACI는 인간 중심의 UI를 넘어, LLM 에이전트가 컴퓨터 시스템(OS, 파일, 도구)을 효율적으로 조작할 수 있도록 최적화된 추상화 인터페이스이며, 에이전트의 관찰(Observation) 및 행동(Action) 공간의 품질을 결정하는 핵심 설계 요소이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. ACI의 정의 및 필요성
+- **모델을 위한 인터페이스**: 인간에게는 시각적 UI(GUI)가 필요하지만, 에이전트에게는 구조화된 데이터(JSON, XML)나 간결한 텍스트 출력이 더 효율적이다.
+- **인지 부하 감소**: 불필요한 시각적 노이즈를 제거하고 에이전트가 행동의 결과와 시스템 상태를 정확히 파악할 수 있도록 정보를 재구성한다.
+
+### 2. ACI 설계 원칙
+- **구조적 명확성**: 도구의 인자 스키마(Schema)와 반환값 형식을 엄격하게 정의하여 모델의 파싱 오류를 줄인다.
+- **에러 피드백의 풍부함**: 단순한 실패 메시지가 아닌, 모델이 다음 행동을 수정할 수 있는 구체적인 힌트(예: "파일이 없습니다. 현재 경로의 파일 목록은 다음과 같습니다...")를 제공한다.
+- **상태의 가시성**: 현재 작업 디렉토리, 샌드박스 상태, 환경 변수 등 에이전트가 추론에 필요한 문맥을 명시적으로 노출한다.
+
+### 3. 하네스 내에서의 역할
+- **입출력 래퍼**: 하네스는 컴퓨터의 원시 출력을 ACI 표준에 맞춰 가공하여 모델에게 전달하며, 모델의 자연어 요청을 시스템 명령어로 변환한다.
+- **인터페이스 최적화**: 특정 모델의 특성(예: 긴 JSON에 강함, 특정 태그 형식 선호)에 맞춰 ACI를 튜닝하여 작업 성공률(Pass@1)을 높인다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **추상화 vs 제어권**: 인터페이스를 너무 고수준으로 추상화하면 에이전트의 세밀한 제어가 불가능해지고, 너무 저수준(예: raw byte stream)으로 두면 인지 부하가 급증한다.
+- **범용 표준의 부재**: 각 하네스마다 ACI 설계가 상이하여 에이전트의 행동 패턴이 특정 인터페이스에 고착화(Coupling)되는 현상이 발생한다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/AI]]
+- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Context Engineering]]
+- **Raw Source**: [[00_Raw/Agent-Computer Interfaces (ACI)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Agent-Computer Interface (ACI) Design Principle"`
+3. Push: `git push origin main`
@@ -0,0 +1,41 @@
+---
+id: d5e6f7a8-b9c0-4d1e-2f3a-4b5c6d7e8f9a
+category: "[[10_Wiki/Topics/AI]]"
+confidence_score: 0.99
+tags: [context, engineering, llm, optimization, token-management, agent]
+last_reinforced: 2026-05-01
+github_commit: "wikification-context-engineering"
+---
+
+# [[Context Engineering]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 컨텍스트 엔지니어링은 프롬프트 작성을 넘어, 에이전트의 제한된 인지 자원(Context Window)을 최적화하기 위해 정보를 필터링, 압축, 우선순위화하여 모델의 추론 충실도를 극대화하는 정교한 데이터 관리 기법이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 프롬프트에서 컨텍스트로의 진화
+- **정적에서 동적으로**: 고정된 지시문(Prompt) 작성에서, 런타임 상황에 맞춰 필요한 정보만 선별하여 주입하는 동적 관리로 패러다임이 전환되었다.
+- **인지 부하 제어**: 모델이 모든 정보를 보게 하는 대신, 현재 작업에 결정적인 정보(Salient Information)만 노출하여 추론의 정확도를 높인다.
+
+### 2. 핵심 기술 및 전략
+- **선택적 주입 (Selective Injection)**: RAG 등을 활용하여 방대한 데이터 중 관련성 높은 하위 집합만 컨텍스트에 포함시킨다.
+- **적응형 압축 (Adaptive Compaction)**: 과거 대화나 작업 이력을 요약(Summary)하거나 중요도가 낮은 토큰을 제거하여 공간을 확보한다.
+- **우선순위화 (Prioritization)**: 시스템 지시어, 최근 도구 결과, 장기 기억 등을 레이어별로 관리하고 중요도에 따라 배치 순서를 조정한다.
+
+### 3. 하네스의 C-컴포넌트
+- 하네스는 모델이 인지할 수 있는 '창(Window)'을 관리하는 역할을 수행하며, 컨텍스트 엔지니어링은 이 창 내부를 채우는 정책(Policy)과 알고리즘을 담당한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **컨텍스트 부패 (Context Rot)**: 정보를 너무 많이 유지하면 주의 분산(Attention Dilution)이 발생하고, 너무 적게 유지하면 정보 상실로 인한 추론 오류가 발생한다.
+- **토큰 경제성**: 긴 컨텍스트 모델이 등장했음에도 불구하고, 연산 비용과 지연 시간 때문에 여전히 효율적인 컨텍스트 관리는 필수적인 최적화 영역이다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/AI]]
+- **Related**: [[Agent Harness]], [[RAG (Retrieval-Augmented Generation)]], [[Agent State Store]]
+- **Raw Source**: [[00_Raw/Context Engineering]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Context Engineering Strategies"`
+3. Push: `git push origin main`
@@ -0,0 +1,45 @@
+---
+id: a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.99
+tags: [engineering-principles, solid, dry, kiss, yagni, clean-code, software-engineering]
+last_reinforced: 2026-05-01
+github_commit: "wikification-engineering-principles"
+---
+
+# [[Engineering Principles (SOLID, DRY, KISS, YAGNI)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 소프트웨어 엔지니어링의 핵심 원칙들은 코드의 복잡성을 통제하고 유지보수성을 극대화하기 위한 도구이며, 특히 SOLID와 DRY/KISS/YAGNI는 '단순함'과 '유연함' 사이의 최적의 균형점을 찾기 위한 지침이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. SOLID 원칙 (Object-Oriented Design)
+- **SRP (단일 책임 원칙)**: 하나의 모듈/컴포넌트는 오직 하나의 책임(변경 이유)만 가져야 한다. React에서는 거대한 컴포넌트를 기능별로 쪼개는 핵심 근거가 된다.
+- **OCP (개방-폐쇄 원칙)**: 확장에는 열려 있고 수정에는 닫혀 있어야 한다. 컴포넌트 합성을 통해 기존 코드를 건드리지 않고 기능을 확장한다.
+- **LSP (리스코프 치환 원칙)**: 자식 클래스(또는 서브 컴포넌트)는 부모의 역할을 온전히 수행할 수 있어야 한다.
+- **ISP (인터페이스 분리 원칙)**: 사용하지 않는 인터페이스(Props)에 의존하지 않도록 잘게 쪼갠다.
+- **DIP (의존성 역전 원칙)**: 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춘다.
+
+### 2. Pragmatic Principles (DRY, KISS, YAGNI)
+- **DRY (Don't Repeat Yourself)**: 지식의 중복을 피한다. 반복되는 로직은 커스텀 훅이나 유틸리티로 추출한다.
+- **KISS (Keep It Simple, Stupid)**: 단순함이 궁극의 정교함이다. 과도한 추상화보다 직관적인 코드를 우선한다.
+- **YAGNI (You Aren't Gonna Need It)**: 실제로 필요하기 전까지는 기능을 미리 구현하지 않는다. 미래를 대비한 오버엔지니어링을 경계한다.
+
+### 3. Clean Code 실무
+- **가독성 우선**: 코드는 컴퓨터가 읽기 위함이 아니라 사람이 읽기 위해 작성된다. 명확한 변수명과 함수 크기 조절이 필수적이다.
+- **단위 테스트 가능성**: 원칙을 준수한 코드는 자연스럽게 테스트하기 쉬운(Testable) 구조가 된다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **DRY vs KISS**: 중복을 제거하기 위한 무리한 추상화는 코드를 더 이해하기 어렵게 만든다. '세 번 반복될 때까지 기다리기(Rule of Three)'가 좋은 절충안이다.
+- **YAGNI vs 확장성**: 미래를 무시하는 것과 유연한 구조를 설계하는 것은 다르다. YAGNI는 '기능'에 대한 것이고, SOLID는 '구조'에 대한 것이다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Legacy React Migration & Refactoring Standard]], [[Custom Hooks]], [[Feature-Sliced Design]]
+- **Raw Source**: [[00_Raw/DRY]], [[00_Raw/KISS]], [[00_Raw/YAGNI]], [[00_Raw/Single Responsibility Principle]], [[00_Raw/Clean Code and SOLID Principles]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Core Engineering Principles (SOLID, DRY, KISS, YAGNI)"`
+3. Push: `git push origin main`
@@ -0,0 +1,43 @@
+---
+id: b2c3d4e5-f6a7-4b8c-9d0e-1f2a3b4c5d6e
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.98
+tags: [git, workflow, branching, github-flow, git-flow, trunk-based-development, devops]
+last_reinforced: 2026-05-01
+github_commit: "wikification-git-workflow"
+---
+
+# [[Modern Git Workflows & Branching Strategies]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 효율적인 Git 워크플로우는 팀의 규모와 릴리즈 주기에 맞춰 선택되어야 하며, Trunk-based Development와 짧은 생명주기의 Feature Branch를 통해 지속적 통합(CI)의 가치를 실현하는 데 목적이 있다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 주요 전략별 특징
+- **Git Flow**: 정기적인 릴리즈 주기가 있는 대규모 프로젝트에 적합. `master`, `develop`, `feature`, `release`, `hotfix` 브랜치를 엄격히 관리한다.
+- **GitHub Flow**: 지속적 배포(CD)에 최적화된 단순한 모델. `main` 브랜치와 짧은 수명의 `feature` 브랜치만 사용하며, PR을 통해 상시 배포한다.
+- **Trunk-based Development**: 모든 개발자가 하루에도 여러 번 `main`에 직접 병합하는 방식. 충돌을 최소화하고 피드백 루프를 극대화한다.
+
+### 2. 협업 및 품질 관리
+- **Pull Request (PR)**: 코드 리뷰를 위한 필수 관문. 변경 사항의 의도를 설명하고 자동화된 테스트를 통과해야 병합된다.
+- **Conventional Commits**: `feat:`, `fix:`, `refactor:` 등 규격화된 접두사를 사용하여 커밋 메시지의 가독성을 높이고 릴리즈 노트를 자동화한다.
+- **Atomic Commits**: 하나의 커밋은 하나의 논리적 변경만 담아야 한다. 이는 롤백과 디버깅(bisect)을 용이하게 한다.
+
+### 3. 프론트엔드 팀을 위한 전략
+- **짧은 생명주기**: 브랜치가 며칠씩 유지되는 것을 지양하고, 가능한 빠르게 `main`에 통합하여 'Merge Hell'을 방지한다.
+- **Feature Flags**: 대규모 기능을 개발할 때 코드는 병합하되 런타임에 기능을 비활성화하여 Trunk-based 방식을 지원한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **복잡도 vs 제어**: Git Flow는 안전하지만 브랜치 관리 비용이 크며, GitHub Flow는 빠르지만 대규모 팀의 릴리즈 관리가 난해할 수 있다.
+- **Merge vs Rebase**: Rebase는 깨끗한 히스토리를 제공하지만 강제 푸시(force push) 위험이 있고, Merge는 보수적이지만 히스토리가 복잡해질 수 있다. 팀의 컨벤션 합의가 중요하다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Engineering Principles (SOLID, DRY, KISS, YAGNI)]], [[CI-CD Pipeline Integration]]
+- **Raw Source**: [[00_Raw/Git Flow]], [[00_Raw/Git Workflow]], [[00_Raw/GitHub Flow]], [[00_Raw/Branching Strategies]], [[00_Raw/Trunk-based Development]], [[00_Raw/Atomic Commits]], [[00_Raw/Pull Request (PR)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Modern Git Workflows and Branching Strategies"`
+3. Push: `git push origin main`
@@ -0,0 +1,47 @@
+---
+id: 7f8e9d2c-b1a3-4e5f-a0b2-c1d2e3f4a5b6
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.98
+tags: [react, legacy, migration, refactoring, incremental-migration, architecture, frontend]
+last_reinforced: 2026-05-01
+github_commit: "wikification-legacy-react"
+---
+
+# [[Legacy React Migration & Refactoring Standard]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 레거시 React 코드베이스의 현대화는 '전면 재작성(Rewrite)'이 아닌 '점진적 리팩토링(Incremental Refactor)'을 원칙으로 하며, 테스트 안전망 구축, 커스텀 훅을 통한 로직 분리, 그리고 FSD 아키텍처 도입을 통해 기술 부채를 체계적으로 해결하는 과정이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 리팩토링의 황금률: Refactor, Do Not Rewrite
+- **안전망 선구축**: 코드 수정 전 유닛 테스트 및 시각적 회귀 테스트(Storybook, Chromatic 등)를 통해 기존 기능의 무결성을 보장한다.
+- **점진적 마이그레이션**: 시스템 전체를 한 번에 바꾸는 대신, 알림이나 작은 기능 단위의 스토어부터 하나씩 최신 상태(Zustand, TanStack Query 등)로 전환한다.
+
+### 2. 컴포넌트 및 언어의 현대화
+- **함수형 전환**: 클래스형 컴포넌트를 함수형 컴포넌트와 훅(Hooks) 기반으로 전환하며, 불필요한 `useEffect` 안티패턴을 제거한다.
+- **TypeScript 도입**: 정적 타이핑을 통해 코드의 예측 가능성을 높이며, 파일 단위로 점진적으로 적용한다.
+- **관심사 분리**: 비대한 컴포넌트(300줄 이상)에서 비즈니스 로직을 **커스텀 훅**으로 추출하여 UI와 로직을 분리한다.
+
+### 3. 상태 관리 및 아키텍처 개편
+- **상태 분할**: 서버 데이터(TanStack Query), 전역 클라이언트 상태(Zustand), URL 상태 등으로 목적에 맞게 파편화하여 관리한다.
+- **FSD 아키텍처 도입**: 기술적 파일 유형(Type-based) 구조에서 비즈니스 도메인 중심의 **Feature-Sliced Design**으로 개편하여 모듈 간 결합도를 낮추고 응집도를 높인다.
+
+### 4. 코드 거버넌스 및 표준화
+- **네이밍 규칙**: `kebab-case`(파일명/폴더명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 등 운영체제 및 팀 협업 표준을 수립한다.
+- **자동화**: ESLint, Prettier, Husky를 활용하여 커밋 시점에 아키텍처 경계 위반 및 포맷팅을 자동으로 검사한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **추상화의 함정 (DRY vs KISS)**: 중복 제거를 위한 과도한 추상화는 오히려 코드를 블랙박스화하여 디버깅을 어렵게 한다. '세 번 반복될 때까지 기다리기(Rule of Three)' 원칙을 준수해야 한다.
+- **과도기적 복잡성**: 점진적 마이그레이션 중에는 레거시와 신규 상태 관리 시스템이 공존하여 일시적으로 구조가 복잡해질 수 있음을 인지하고 마이그레이션 로드맵을 명확히 해야 한다.
+- **초기 오버헤드**: FSD 등의 엄격한 구조는 소규모 프로젝트에서는 과도한 설계(Overkill)가 될 수 있으므로 프로젝트 규모에 맞춰 유연하게 적용한다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Feature-Sliced Design]], [[TanStack Query]], [[Zustand]], [[Unit Testing]], [[SOLID Principles]]
+- **Raw Source**: [[00_Raw/레거시 React 코드베이스 마이그레이션]], [[00_Raw/Incremental Migration]], [[00_Raw/Legacy React Codebase Modernization]], [[00_Raw/Legacy React Codebase Refactoring]], [[00_Raw/React Codebase Refactoring]], [[00_Raw/프론트엔드 리팩토링 및 코드 유지보수]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Legacy React Migration & Refactoring Standard"`
+3. Push: `git push origin main`
@@ -0,0 +1,41 @@
+---
+id: e6f7a8b9-c0d1-4e2f-3a4b-5c6d7e8f9a0b
+category: "[[10_Wiki/Topics/AI]]"
+confidence_score: 0.99
+tags: [pev-loop, execution, verification, agent, harness, reliability]
+last_reinforced: 2026-05-01
+github_commit: "wikification-pev-loop"
+---
+
+# [[Plan-Execute-Verify (PEV) Loop]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> PEV 루프는 에이전트가 즉흥적으로 행동하는 것을 방지하기 위해 계획, 제한된 실행, 엄격한 검증의 3단계를 강제하여 자율 시스템의 신뢰성과 아키텍처 일관성을 보장하는 핵심 실행 패턴이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 3단계 실행 파이프라인
+- **Plan (계획)**: 문제를 명시적으로 분해하고 수용 기준(Acceptance Criteria)을 포함한 상세 계획을 수립한다. 이는 추론의 비결정성 문제를 줄이는 역할을 한다.
+- **Execute (실행)**: 수립된 계획의 범위 내에서만 도구를 호출한다. 실행 전 게이트(Pre-execution gates)가 개입하여 인자 유효성 및 권한을 실시간으로 통제한다.
+- **Verify (검증)**: 단순 성공 여부를 넘어 계획과의 일치성(Plan Alignment)을 평가한다. 실패 시 구체적인 에러 피드백을 추론 루프로 돌려보내 자가 수정을 유도한다.
+
+### 2. 하네스 게이트 (Harness Gates)
+- **Pre-execution gates**: 도구 호출 전 작업 공간 및 권한을 확인하여 범위를 벗어난 행동을 원천 차단한다.
+- **Post-execution verification**: 린터, 테스트 러너, 아키텍처 규칙 검사 등을 통해 결과물의 품질을 보증한다.
+
+### 3. 신뢰성 중심 설계
+- '일단 해보고 확인하기(Generate-and-Check)' 방식의 한계를 극복하고, 하네스 계층에서 결정론적 규칙을 강제함으로써 엔터프라이즈 급의 안정성을 확보한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **지연 시간 오버헤드**: 단계를 강제함에 따라 간단한 작업에서도 처리 시간이 증가하며 토큰 소모량이 늘어난다.
+- **검증 로직의 복잡성**: 단순히 코드가 실행되는지를 넘어 아키텍처 규칙 준수 여부를 판단하는 '계획 일치성' 검증 로직 구현에 높은 기술적 난이도가 따른다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/AI]]
+- **Related**: [[Agent Harness]], [[Pre-execution gates]], [[Plan alignment]], [[Generate-and-Check]]
+- **Raw Source**: [[00_Raw/Plan-Execute-Verify (PEV) Loop]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Plan-Execute-Verify (PEV) Loop Architecture"`
+3. Push: `git push origin main`