[P-Reinforce] Cleanup wikified files in 00_Raw (RAG, Harness, MCP, State Store, Agentic SE)
This commit is contained in:
Antigravity Agent
@@ -1,84 +0,0 @@
|
||||
# [[Agent Harness]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
**AI 에이전트 하네스(Agent Harness)**는 대규모 언어 모델(LLM)을 감싸서 외부 세계와 상호작용할 수 있도록 통제하고 지원하는 소프트웨어 인프라스트럭처이자 런타임 제어 계층입니다. 단순히 모델을 호출하는 것을 넘어 실행 루프, 도구 관리, 컨텍스트 유지, 상태 관리, 보안 및 평가 기능을 통합하여 에이전트가 장기적이고 복잡한 작업을 자율적이고 신뢰성 있게 수행하도록 돕습니다. 모델이 논리적 추론을 담당하는 '두뇌'라면, 하네스는 모델이 환경과 소통하고 안전한 제약 내에서 행동하도록 돕는 '신체 및 환경 인프라'로 기능하며, 최근 AI 개발의 초점이 프롬프트 최적화에서 하네스 설계(Harness Engineering)로 이동하고 있습니다.
|
||||
|
||||
## 📖 Core Content
|
||||
소스 데이터에 따르면, 신뢰할 수 있는 에이전트 시스템을 구축하기 위해 에이전트 하네스는 다음과 같은 핵심 역할을 수행합니다.
|
||||
|
||||
- **하네스의 공식적 정의 (The 6-Component Framework)**
|
||||
연구 및 산업계에서는 에이전트 하네스를 **H = (E, T, C, S, L, V)**의 6가지 런타임 거버넌스 구성 요소로 정의합니다.
|
||||
- **E (Execution Loop, 실행 루프):** 관찰-생각-행동(observe-think-act) 주기를 오케스트레이션하며 다중 턴의 실행 흐름, 에러 복구 및 종료 조건을 제어합니다.
|
||||
- **T (Tool Registry, 도구 레지스트리):** 에이전트가 외부 세계에 개입할 수 있도록 타입이 지정되고 검증된 도구 카탈로그(API, 파일 제어 등)를 유지하고 도구 호출을 라우팅/모니터링합니다.
|
||||
- **C (Context Manager, 컨텍스트 관리자):** 컨텍스트 윈도우로 들어가는 정보를 필터링하고 우선순위를 정하며, 메모리 압축(Compaction) 및 검색 전략을 관리합니다.
|
||||
- **S (State Store, 상태 저장소):** 에이전트의 실행 턴(Turn) 및 세션 간의 작업 관련 상태를 영속적으로 저장하고 부분적 실패 시 복구를 지원합니다.
|
||||
- **L (Lifecycle Hooks, 수명주기 훅):** 인증, 로깅, 정책 시행 및 관찰을 위해 에이전트 호출 전후를 가로채는(Intercept) 제어 지점입니다.
|
||||
- **V (Evaluation Interface, 평가 인터페이스):** 벤치마크 및 오프라인 분석을 위해 실행 궤적(Trajectory), 중간 상태, 성공 신호를 표준화된 형태로 캡처합니다.
|
||||
|
||||
- **하네스 엔지니어링 패러다임의 진화**
|
||||
AI 엔지니어링은 '프롬프트 엔지니어링(2022-2024)'에서 모델이 보는 정보를 관리하는 '컨텍스트 엔지니어링(2025)'을 거쳐, 에이전트의 전체 실행 환경 및 제어 인프라를 설계하는 **'하네스 엔지니어링(2026)'**으로 진화했습니다. 현재 선도적인 AI 시스템의 신뢰성은 모델의 지능(Model Capability)만으로 결정되지 않으며, 모델과 하네스가 결합된 품질이 성능의 상한을 결정합니다.
|
||||
|
||||
- **보안 및 런타임 제어 메커니즘**
|
||||
하네스는 본질적으로 불확실성을 가진 LLM의 출력을 결정론적(Deterministic) 환경에서 제어합니다. 이를 위해 **샌드박싱(Sandboxing)**을 통해 코드 실행 환경을 논리적/물리적으로 격리하고, 에이전트의 '과도한 권한(Excessive Agency)'과 '간접 프롬프트 인젝션(Indirect Prompt Injection)'과 같은 보안 위협을 수명주기 훅(L) 및 도구 승인 파이프라인(Human-in-the-loop)을 통해 방어합니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
- **도구 접근성(Capability) vs 보안 및 격리(Security):**
|
||||
에이전트 하네스에 폭넓은 도구(네트워크, 파일시스템 쓰기 등)를 제공하면 유용성은 극대화되지만, 동시에 간접 프롬프트 인젝션이나 예기치 않은 시스템 파괴와 같은 공격 표면이 급증합니다. 반면, 엄격한 마이크로VM 샌드박싱이나 권한 최소화 원칙을 강제하면 보안성은 높아지지만, 에이전트의 작업 지연 시간(Latency)이 증가하고 운영 인프라의 복잡성이 커지는 반대 급부가 발생합니다.
|
||||
- **컨텍스트 유지(Retention) vs 비용 및 부패(Context Rot):**
|
||||
긴 작업 세션 동안 모든 실행 기록과 도구 결과를 컨텍스트에 유지하면 모델의 장기적 추론에 유리해 보이지만, 실제로는 컨텍스트 윈도우 희석 현상(Attention Dilution)과 기하급수적인 토큰 비용 증가를 유발하는 **'컨텍스트 부패(Context Rot)'**가 발생합니다. 반대로 메모리 압축(Compaction)이나 부분 요약을 공격적으로 수행하면, 이후 에이전트가 작업을 재개할 때 필수적인 세부 정보나 데이터 출처(Provenance)를 상실할 위험이 존재합니다.
|
||||
- **다중 에이전트 오케스트레이션(Multi-Agent) 오버헤드:**
|
||||
역할이 분리된 여러 하위 에이전트(Subagents)를 하네스로 연결(Orchestrator-Worker 패턴 등)하면 병렬 처리와 컨텍스트 격리에 매우 유리합니다. 그러나, 에이전트 간의 통신(메시지 라우팅), 상태 공유 일관성, 권한 위임 관리 등 분산 시스템 수준의 복잡성이 추가되며, 단일 에이전트 구성보다 토큰 소비량이 최대 15배 이상 증가할 수 있어 비용 대비 효율성을 철저히 계산해야 합니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
- [[Model Context Protocol (MCP)]]
|
||||
- 연결 이유: 하네스의 도구 레지스트리(T-component)가 외부 데이터 소스 및 도구와 통신할 때 사용하는 Anthropic 주도의 표준 개방형 프로토콜입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 어떻게 모델과 종속성을 분리하여 수많은 API와 엔터프라이즈 도구를 안전하고 규격화된 방식(JSON-RPC 기반)으로 탐색하고 실행하는지 구체적으로 이해할 수 있습니다.
|
||||
|
||||
- [[Agent-to-Agent Protocol (A2A)]]
|
||||
- 연결 이유: MCP가 '에이전트-도구' 간의 연결을 담당한다면, A2A는 다중 에이전트 하네스에서 '에이전트-에이전트' 간의 작업 위임 및 원격 통신을 표준화하는 Google 주도의 프로토콜입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스의 실행 루프(E-component)가 단일 컨텍스트를 넘어 외부 또는 원격의 특화 에이전트들에게 하위 작업을 어떻게 오케스트레이션하는지 파악할 수 있습니다.
|
||||
|
||||
- [[Context Engineering]]
|
||||
- 연결 이유: 프롬프트 엔지니어링의 다음 단계로, 하네스가 에이전트의 컨텍스트 윈도우에 진입하는 정보를 필터링, 압축, 우선순위화하는(C-component) 핵심 설계 철학입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 긴 시간 실행되는 작업에서 발생하는 '컨텍스트 부패'를 방지하고, 검색 증강(RAG)과 가상 페이징(Virtual Paging)을 통해 토큰 비용을 어떻게 억제하는지 알 수 있습니다.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
- [[Sandboxing (MicroVMs/Containers)]]
|
||||
- 연결 이유: 하네스 내부에서 에이전트가 생성한 코드나 도구 호출을 격리된 상태로 실행하게 만드는 인프라 기술입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트의 자율적 실행이 호스트 시스템을 파괴하거나 보안을 침해하지 않도록 방어하는 실행 계층(Docker, E2B 등)의 중요성을 확인할 수 있습니다.
|
||||
|
||||
- [[Plan-Execute-Verify (PEV) Loop]]
|
||||
- 연결 이유: 하네스 내부에서 에이전트의 작업을 통제하는 핵심 실행 파이프라인 패턴입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트가 단순히 생성하고 확인(Generate-and-check)하는 것을 넘어, 하네스가 어떻게 명시적인 계획 단계와 실행, 그리고 자동화된 검증(Verification) 사이에 하드 게이트(Hard gates)를 두어 신뢰성을 높이는지 이해할 수 있습니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
- 다중 에이전트 하네스(Multi-Agent Harness) 아키텍처에서 에이전트 간 공유 상태(Shared State)의 일관성을 유지하고, 손상된 에이전트(Byzantine fault)로 인한 연쇄 오류(Cascade failure)를 분산 시스템 수준에서 어떻게 방어할 수 있는가?
|
||||
- '컨텍스트 부패(Context Rot)' 문제를 해결하기 위해 하네스의 컨텍스트 관리자(C-component)가 수행하는 '적응형 압축(Adaptive Context Compaction)' 기법은 실제 토큰 비용 절감 및 정보 손실률 측면에서 검색 증강(RAG)과 비교하여 어떠한 정량적 트레이드오프를 갖는가?
|
||||
- MCP(Model Context Protocol)를 T-component에 적용하고 A2A(Agent-to-Agent)를 E-component에 적용하는 이중 프로토콜 스택 아키텍처에서, 두 프로토콜 간의 교차 인증(Authentication) 및 보안 경계는 어떻게 설계되어야 하는가?
|
||||
- 하네스 내부에서 실행되는 샌드박싱 환경(예: MicroVM 기반 코드 실행)과 외부 API를 직접 호출하는 방식 중, 복잡한 데이터 변환 및 검증 과제에서 에이전트 성능(Pass@1)과 지연 시간(Latency)에 각각 어떤 영향을 미치는가?
|
||||
- '하네스-모델 결합(Harness-Model Coupling)' 현상, 즉 특정 모델이 특정 하네스 생태계(예: Native SDK)에서만 월등한 성능을 발휘하는 현상을 객관적으로 측정하고 평가하기 위한 교차 하네스 벤치마크(Cross-Harness Evaluation)의 표준화 조건은 무엇인가?
|
||||
- 코드 기반의 결정론적 하네스와 비교하여, 자연어로 제어 규칙을 명세하는 '자연어 기반 에이전트 하네스(Natural-Language Agent Harnesses, NLAH)'는 이식성과 형식적 검증(Formal Verification) 측면에서 시스템 신뢰성을 어떻게 보장할 수 있는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** LangGraph, CrewAI, AutoGen 등의 프레임워크나 OpenClaw, DeepAgents 같은 풀스택 하네스 환경을 구현할 때, 도구 레지스트리 설정, 파일 시스템 상태 연결, 메모리 저장소 연동 등을 실제 코드로 구현하고 통합하는 과정에 적용됩니다.
|
||||
- **System Design:** 소프트웨어 아키텍트는 AI 기반 애플리케이션 설계 시, 단순히 프롬프트를 개선하는 것에 의존하지 않고 E, T, C, S, L, V의 6대 컴포넌트를 기반으로 런타임 제어, 상태 영속성, 멀티 에이전트 오케스트레이션 토폴로지 등 전체 인프라 스트럭처의 거시적 구조를 기획합니다.
|
||||
- **Operation / Maintenance:** 프로덕션 환경에서는 AgentOps, Langfuse와 같은 도구를 통해 L-component와 V-component를 모니터링하며 세션 토큰 비용, 실행 궤적(Trace), 무한 루프, 컨텍스트 상태를 실시간으로 추적하고 사후 디버깅 및 감사(Auditing)를 수행합니다.
|
||||
- **Learning Path:** LLM 프롬프트 작성과 RAG(검색 증강 생성)에 익숙해진 엔지니어가 에이전트의 안정성을 확보하기 위해 필수적으로 학습해야 하는 상위 단계입니다. 운영체제(OS)의 커널과 스케줄러를 이해하듯 AI 에이전트의 통제 환경 구축을 학습하는 경로입니다.
|
||||
- **My Project Relevance:** 현재 자율적으로 동작하는 코딩 에이전트나 비즈니스 자동화 봇을 개발 중이라면, 모델의 오류로 인한 시스템 파괴를 막는 샌드박싱 적용, MCP를 통한 확장성 높은 사내 API 연동, 그리고 휴먼-인-더-루프(HITL) 기반의 승인 게이트웨이 도입 등 프로젝트의 신뢰성과 기업 보안 컴플라이언스를 확보하는 데 직결됩니다.
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[LLM Evaluation Frameworks]]
|
||||
- 확장 방향: 단순히 하네스 인프라를 구축하는 것을 넘어, SWE-bench, HAL, AgencyBench 등 하네스 내부에서 에이전트의 복잡한 실행 궤적(Trajectory)을 객관적이고 재현 가능하게 평가하고 측정하는 벤치마킹 방법론으로의 확장.
|
||||
- [[Agentic Cybersecurity]]
|
||||
- 확장 방향: 간접 프롬프트 인젝션 방어, 메모리 포이즈닝 방지, 최소 권한 원칙 기반의 도구 접근 제어 등 자율적 에이전트가 초래할 수 있는 새로운 형태의 사이버 보안 위협과 방어 아키텍처(예: OpenClaw PRISM, OAP) 연구로의 확장.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -1,64 +0,0 @@
|
||||
# [[Agent State Store]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Agent State Store(S-component)는 에이전트 하네스(Agent Harness) 아키텍처의 6대 핵심 구성 요소 중 하나로, 에이전트의 다중 턴(multi-turn) 및 세션 간 상태 지속성을 관리하는 시스템이다 [1, 2]. 이는 작업 관련 상태를 저장하여 실행 루프가 부분적인 실패(partial failures)로부터 복구할 수 있도록 지원한다 [2, 3]. 단순한 단기 로그 저장을 넘어, 에이전트가 경험을 추상화하여 절차적·에피소드적 지식으로 저장하고 후속 작업에 안전하게 활용할 수 있도록 통제하는 인프라 역할을 수행한다 [4-6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **역할과 기능:** 상태 저장소는 모델의 제한된 컨텍스트 윈도우를 넘어 에이전트가 장기적인 작업을 수행할 수 있도록 지원하는 기반이다 [5, 6]. 이는 초기 LLM 에이전트 프레임워크(예: AutoGPT, BabyAGI)들이 다중 단계 작업 중단을 겪을 때 발생하던 '상태 상실(state loss)' 문제를 방지하는 필수적인 런타임 거버넌스(runtime governance)이다 [7, 8].
|
||||
* **메모리 계층 및 구조:** 현대 하네스는 작업 메모리(working memory), 에피소드 메모리(episodic memory), 시맨틱 메모리(semantic memory), 절차적 메모리(procedural memory) 등의 형태로 상태를 관리한다 [9-11]. 예를 들어 Voyager의 스킬 라이브러리처럼 재사용 가능한 절차적 능력을 저장하거나, Reflexion처럼 실패한 실행 추적에서 얻은 자기 비판(self-critiques)을 에피소드 버퍼에 저장하여 자가 개선을 돕는다 [4, 12-14].
|
||||
* **파일 시스템 및 아티팩트(Artifact) 저장:** 프로덕션급 하네스 시스템(예: DeepAgents)에서는 파일 시스템이나 가상 아티팩트 저장소를 기본 작업 메모리 기판(working-memory substrate)으로 취급한다 [15, 16]. 대규모 도구 출력값이나 중간 작업 결과물을 프롬프트 컨텍스트에서 제외하여 아티팩트로 오프로드(offload)하고, 다중 에이전트 간의 상태를 공유하거나 복구하는 데 활용한다 [15, 16].
|
||||
* **추론 결합 지속성(Inference-Coupled Persistence):** S-component에 기록되는 내용은 종종 모델의 추론을 통해 생성된 능동적 결과물(예: 자기 반성 평가, 유도된 워크플로 스킬 등)이다 [17, 18]. 이로 인해 하네스는 저장 방식 메커니즘뿐만 아니라, 오염되거나 잘못된 지식이 영구 저장소에 기록되지 않도록 저장 내용의 품질(quality)도 직접 관리해야 하는 의무를 지닌다 [17, 18].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **메모리 오염(Memory Poisoning) 및 보안 취약점:** 에이전트가 영구 저장소(S-component)에 콘텐츠를 기록할 권한을 가질 때, 공격자가 악의적인 프롬프트나 잘못된 신념을 주입하면 세션 경계를 넘어 지속되는 치명적인 보안 벡터가 형성된다 [19-22]. 이를 방지하려면 L-component(Lifecycle Hooks)를 통해 쓰기 시점에 엄격한 데이터 검증이 이루어져야 하지만, 현재 대부분의 프로덕션 하네스는 이를 제대로 구현하지 못하고 있다 [20, 23, 24].
|
||||
* **메모리 팽창(Memory Bloat)과 검색 품질 저하:** 장기 실행 에이전트의 경우, 관련성이 떨어지는 정보가 S-component에 무분별하게 축적되면 향후 검색 시 신호 대비 잡음비(signal-to-noise ratio)가 하락한다 [25, 26]. Ebbinghaus 망각 곡선이나 적절한 스케줄링 정책에 의한 요약 및 축출(eviction)이 없으면 '컨텍스트 부패(Context Rot)'가 발생하여 토큰 비용이 비선형적으로 증가하고 추론 능력이 저하된다 [27-30].
|
||||
* **표준화된 인터페이스의 부재 및 다중 에이전트 일관성 문제:** MCP(Model Context Protocol)를 통해 도구(T-component) 인터페이스가 표준화되는 추세와 달리, S-component는 각 하네스마다 독립적으로 재구현되어 이식성(portability)이 없다 [31, 32]. 이로 인해 다중 에이전트 환경에서 원자적 문서 전달(atomic document handoffs), 에이전트 레지스트리 가용성, 동시 쓰기로 인한 상태 충돌 해결 등의 일관성(Consistency) 보장이 매우 취약하다 [33-36].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
- [[Execution Loop (E-component)]]
|
||||
- 연결 이유: 상태 전이와 루프 제어를 담당하는 E-component는 각 단계마다 상태를 S-component에 언제 기록(commit)할지 결정하며, 실행 오류 시 S-component로부터 복구 상태를 읽어온다 [1, 37].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스의 상태 전이(State Transition) 의미론과 부분적 실패 복구(Rollback/Recovery) 메커니즘.
|
||||
- [[Context Manager (C-component)]]
|
||||
- 연결 이유: S-component에 저장된 대규모 장기 상태나 과거 추적 데이터 중에서 모델에 지금 당장 필요한 정보만 필터링하여 컨텍스트 윈도우에 주입(Injection)하는 정책을 관장한다 [1, 38, 39].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메모리 검색 지연 시간 문제 및 컨텍스트 압축(Compaction)과 상태 보존 간의 데이터 파이프라인.
|
||||
- [[Lifecycle Hooks (L-component)]]
|
||||
- 연결 이유: S-component의 쓰기 경계(Write boundary)에서 악의적 콘텐츠나 신뢰할 수 없는 데이터가 저장되지 않도록 검증하고, 접근 제어를 시행하는 정책 적용 계층이다 [1, 20].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 관리에서의 보안 격리(Security Isolation) 및 메모리 오염 방지 전략.
|
||||
|
||||
#### [관계 유형 B (구현/활용 도구)]
|
||||
- [[Filesystem/Artifact Store]]
|
||||
- 연결 이유: 많은 현대 하네스 시스템(예: DeepAgents)이 토큰 예산을 지키기 위해 대용량 도구 출력이나 작업 이력을 컨텍스트에 직접 넣는 대신, 파일 시스템이나 가상 아티팩트 저장소를 S-component 기판으로 사용한다 [15, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컨텍스트 오버플로우 관리 및 오프보딩(Offloading)을 통한 복구 가능성 확보.
|
||||
- [[Agent Workflow Memory (AWM)]]
|
||||
- 연결 이유: 단순히 과거의 사건(Episodic)을 저장하는 것을 넘어, 완료된 작업 궤적에서 재사용 가능한 워크플로 추상화를 유도하여 저장하는 발전된 절차적 상태 저장(Procedural memory) 형태이다 [27, 40, 41].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 장기 실행 에이전트의 워크플로 최적화 및 지속적 학습(Continual learning).
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
- 에이전트가 S-component에 데이터를 쓸 때, 악의적인 프롬프트 주입이나 데이터 유출을 유도하는 '메모리 오염(Memory Poisoning)'을 방지하기 위해 L-hook 수준에서 어떤 검증 구조를 설계해야 하는가?
|
||||
- 다중 에이전트 앙상블에서 공유 상태(Shared State)에 대한 동시 쓰기(Concurrent writes)가 발생할 때, S-component는 분산 시스템의 어떤 일관성 모델(Consistency model, 예: 선형가능성)을 채택해야 충돌을 방지할 수 있는가?
|
||||
- 모델의 추론 과정을 거쳐 메모리가 생성되는 '추론 결합 지속성(Inference-Coupled Persistence)' 구조에서, 모델의 오류나 환각이 절차적/에피소드적 영구 저장소에 전이되지 않도록 보장하는 품질 게이트(Quality-gate)는 어떻게 구성해야 하는가?
|
||||
- MCP(Model Context Protocol)가 도구(Tool) 통합을 표준화한 것처럼, S-component의 상태 유지 및 메모리 관리 API를 표준화하여 여러 프레임워크 간에 에이전트 메모리를 이식(Portability)할 수 있는 방안은 무엇인가?
|
||||
- 100만 개 이상의 토큰을 처리하는 거대 컨텍스트 창 모델 환경에서, S-component의 역할은 단순한 '정보 보존 및 압축'에서 '주목도 스케줄링(Attention/Salience Scheduling)'으로 어떻게 진화해야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** 코딩 에이전트나 연구 에이전트를 개발할 때, 메모리 내 상태(in-memory state)에 의존하지 않고 JSONL 파일 로그, SQLite 기반 데이터베이스 또는 Git 분기(branch)를 활용하여 작업 이력을 체크포인트 단위로 영구 기록하는 기능을 구현한다.
|
||||
- **System Design:** 장기 실행 작업 도중 런타임 오류, 네트워크 타임아웃, 예기치 않은 컨테이너 종료가 발생하더라도, S-component에 저장된 세션 상태를 복원(Wake & Resume)하여 처음부터 다시 시작하지 않도록 하는 내결함성(Fault-tolerance) 아키텍처를 설계한다.
|
||||
- **Operation / Maintenance:** 프로덕션 환경에서 에이전트가 지속 작동함에 따라 불필요하게 쌓이는 '좀비 메모리'를 방지하기 위해, Ebbinghaus 망각 곡선이나 최신성(Recency)/관련성(Relevance)에 기반한 메모리 요약 및 축출(Eviction) 파이프라인을 운영한다.
|
||||
- **Learning Path:** 단순 챗봇의 대화 컨텍스트 유지(Conversation History)를 넘어서서, 에이전트 운영 체제(Agent OS) 모델에서 제안하는 가상 메모리 페이징(Virtual Paging) 메커니즘과 영구 저장소 구조 설계론을 학습한다.
|
||||
- **My Project Relevance:** 복잡한 다중 단계 목표를 수행하는 에이전트 시스템 도입 시, 토큰 초과로 인한 '컨텍스트 부패(Context Rot)' 문제를 선제적으로 해결하고 모델의 이전 결정 논리를 안전하게 저장·재참조할 수 있는 인프라 레이어를 구축하는 데 직접적으로 적용할 수 있다.
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Vector Database / Semantic Search]]
|
||||
- 확장 방향: S-component에 누적된 방대한 상태 로그나 에피소드 중, 현재 직면한 문제 해결에 가장 관련성이 높은 과거 경험(메모리)을 빠르고 의미론적으로 검색하여 컨텍스트에 주입하는 기술로 확장.
|
||||
- [[Model Context Protocol (MCP)]]
|
||||
- 확장 방향: 외부 도구 및 시스템과의 연결을 표준화하는 MCP의 발전 양상을 참고하여, 향후 분산 하네스 간의 S-component 상태 상속 및 권한 전파 프로토콜의 표준화 논의로 확장.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -1,63 +0,0 @@
|
||||
# [[Agentic Software Engineering]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전틱 소프트웨어 엔지니어링(Agentic Software Engineering)은 개발자가 직접 코드를 작성하는 역할에서 코드를 자율적으로 작성하는 AI 에이전트를 오케스트레이션하고 방향을 설정하는 역할로 진화하는 소프트웨어 개발 패러다임입니다 [1-3]. 이 환경에서 대형 언어 모델(LLM)은 단일 응답을 생성하는 것을 넘어 자율적으로 계획을 세우고 코드를 디버깅하며 소프트웨어 시스템을 구축하는 에이전트로 작동합니다 [4, 5]. 이러한 에이전트가 환각이나 탈선 없이 신뢰성 있게 작업을 수행할 수 있도록 실행 환경, 도구 제어, 메모리, 안전장치 등을 제공하는 '에이전트 하네스 엔지니어링(Agent Harness Engineering)'이 이 패러다임의 핵심 인프라 기반을 형성합니다 [6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **개발자 역할의 변화 (From Implementer to Orchestrator)**: 2026년 이후 소프트웨어 개발의 핵심은 코드를 작성하는 것(syntax)에서 AI 에이전트가 안전하게 코드를 작성할 수 있도록 아키텍처와 제어 시스템을 설계하는 것으로 변화했습니다 [1-3]. 인간은 고차원적인 시스템 아키텍처 설계와 결과물 검증 및 전략적 방향 지시에 집중하고, 에이전트는 반복적이고 전술적인 구현을 담당합니다 [1, 2].
|
||||
* **에이전트 하네스의 필수성 (The Necessity of Agent Harnesses)**: LLM 자체는 상태(State)를 유지하거나 코드를 실행하거나 외부 API를 호출할 수 없는 단순한 확률적 추론 엔진에 불과합니다 [6, 9, 10]. 이를 자율적인 코딩 에이전트로 변환하려면 실행 루프(E), 도구 레지스트리(T), 컨텍스트 관리자(C), 상태 저장소(S), 수명주기 훅(L), 평가 인터페이스(V) 등 6가지 거버넌스 구성 요소를 제공하는 '하네스(Harness)' 인프라가 필수적입니다 [7, 8, 11, 12].
|
||||
* **다중 에이전트 및 PEV 루프 (Multi-agent & PEV Loop)**: 복잡한 코드 작성 작업은 계획(Plan), 실행(Execute), 검증(Verify)으로 역할을 분리하는 PEV 루프나 다중 에이전트 오케스트레이션(Orchestrator-worker 패턴 등)을 통해 관리됩니다 [13-15]. 이를 통해 에이전트는 환각이나 작업 이탈 없이 명시적인 계획과 린터(Linter), CI 검사와 같은 기계적인 승인 절차 내에서만 작업을 수행합니다 [13, 14, 16].
|
||||
* **실행 환경 및 샌드박스 (Execution Environments & Sandboxing)**: 코딩 에이전트는 컨테이너나 마이크로 VM과 같은 격리된 샌드박스 환경에서 파일 읽기/쓰기, 셸 명령어 실행, LSP(Language Server Protocol)를 통한 시맨틱 코드 분석 등의 도구를 사용합니다 [17-19]. 또한, 리소스 소모가 큰 물리적 Docker 환경 대신, LLM을 활용하여 코드 실행 결과를 시뮬레이션하고 검증하는 'SWE-World'와 같은 도커 프리(Docker-Free) 가상 하네스 환경도 에이전트 훈련 및 평가에 적극 활용되고 있습니다 [20-22].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
* **자율성(Capability)과 격리/보안(Security/Isolation) 간의 트레이드오프**: 코딩 에이전트가 현실적인 엔지니어링 문제를 해결하려면 셸 명령어 실행이나 파일 시스템 접근과 같은 광범위한 도구 권한이 필요하지만, 이는 간접 프롬프트 인젝션(Indirect Prompt Injection)이나 샌드박스 탈출과 같은 심각한 시스템 보안 취약점을 발생시킵니다 [23, 24]. 반대로 강력한 보안 및 격리 조치(예: 엄격한 마이크로 VM 환경 적용)를 강제하면 에이전트의 지연 시간과 운영 비용이 크게 증가하여 완벽한 파레토 최적점(Pareto-optimal point)을 찾기 어렵습니다 [23, 24].
|
||||
* **컨텍스트 보존(Context Retention)과 컴퓨팅 경제성(Compute Economics)의 상충**: 장기 실행 에이전트(Long-running agents)가 과거의 코드 수정 내역과 도구 실행 결과를 모두 컨텍스트 윈도우에 보존하도록 하면 토큰 소비량이 기하급수적으로 늘어나 '컨텍스트 부패(Context rot)'가 발생하며 추론 능력이 희석됩니다 [25-27]. 반대로 토큰 최적화를 위해 컨텍스트를 너무 공격적으로 요약(Compaction)하거나 삭제하면 에이전트가 이전의 결정 맥락이나 중요한 코드 레퍼런스를 상실하는 정보 손실의 부작용이 발생합니다 [28, 29].
|
||||
* **하네스-모델 결합(Harness-Model Coupling) 편향성**: 에이전트 시스템의 실제 신뢰성이나 코드 벤치마크 평가 점수는 모델 단독의 지능이 아니라 모델과 하네스 간의 상호작용 품질에 의해 크게 좌우됩니다 [30, 31]. 동일한 성능의 모델이라도 하네스의 환경 설정, 에러 메시지 래핑 방식, 도구 제공 설계가 미흡할 경우 작업에 실패할 확률이 매우 높으며, 이는 평가 과정에서 모델 자체의 능력 부족으로 오인될 위험이 존재합니다 [32, 33].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처 및 인프라 기반 기술)]
|
||||
- [[Agent Execution Harness]]
|
||||
- 연결 이유: 텍스트를 출력하는 언어 모델을 자율적으로 행동하는 에이전트로 변환하는 핵심 런타임 제어 인프라이기 때문입니다 [11, 12, 34].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 보존, 실행 루프 관리, 컨텍스트 제어, 보안 강제 등 하네스의 6대 거버넌스가 모델 성능과 신뢰성을 어떻게 결정짓는지 파악할 수 있습니다 [11, 12, 35].
|
||||
- [[Model Context Protocol (MCP)]]
|
||||
- 연결 이유: 에이전트 하네스가 외부 데이터베이스, 파일 시스템, 서드파티 애플리케이션 등 외부 도구와 통신하는 방식을 표준화하는 개방형 프로토콜이기 때문입니다 [36-38].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: AI가 외부 시스템과 툴을 호출하는 복잡한 권한 및 도구 레지스트리 관리 구조를 상호 운용 가능한 형태로 단순화하는 통합 원리를 이해할 수 있습니다 [39, 40].
|
||||
|
||||
#### [관계 유형 B (실행 제어 및 평가 아키텍처 패턴)]
|
||||
- [[Plan-Execute-Verify (PEV) Loop]]
|
||||
- 연결 이유: 코딩 에이전트가 단일 프롬프트가 아닌 구조화된 계획 수립, 제한된 실행, 엄격한 코드 검증을 거치도록 강제하는 핵심 하네스 소프트웨어 패턴이기 때문입니다 [13, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 코드를 생성하고 확인하는(Generate-and-check) 방식의 한계를 극복하고, 자동화된 피드백 루프를 통해 에이전트의 실패를 복구하는 메커니즘을 배울 수 있습니다 [14].
|
||||
- [[SWE-World]]
|
||||
- 연결 이유: 리소스가 많이 소모되는 무거운 물리적 Docker 실행 환경 대신, LLM 모델을 활용하여 코드 탐색 및 유닛 테스트 실행 결과를 시뮬레이션하는 도커 프리(Docker-Free) 에이전트 훈련 프레임워크이기 때문입니다 [20, 22].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비용과 인프라의 한계로 인해 대규모 에이전트 강화학습(RL)이나 평가가 어려웠던 문제를, 가상 피드백 시뮬레이션을 통해 확장성 있게 해결하는 방법을 이해할 수 있습니다 [22, 41].
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
- 대규모 다중 에이전트(Multi-agent) 시스템 환경에서 에이전트 간의 공유 상태(Shared state) 일관성을 유지하고, 한 에이전트의 결함이나 오류가 다른 에이전트로 연쇄 전파(Cascading failures)되는 것을 방지하기 위한 하네스 계층의 격리 아키텍처는 어떻게 설계되어야 하는가? [42-44]
|
||||
- 100만 토큰 이상의 초장기 문맥(Ultra-long-context) LLM이 등장했음에도 불구하고, 컨텍스트 압축(Compaction)과 정보의 현저성(Salience) 관리가 여전히 에이전트 하네스 설계에서 가장 중요한 제약 조건이자 필수 엔지니어링 영역으로 작용하는 실증적 원리는 무엇인가? [45, 46]
|
||||
- 소프트웨어 엔지니어링 에이전트를 위한 코드 실행 샌드박스에서 성능(지연 시간 최소화 및 캐시 최적화)과 보안(마이크로VM 수준의 커널 접근 제어 등) 간의 극단적인 트레이드오프를 가장 효율적으로 해결할 수 있는 런타임 인프라 구성 방안은 무엇인가? [23, 24]
|
||||
- SWE-bench와 같은 코드 해결 벤치마크 평가 시, 모델 자체의 지능적 추론 능력과 하네스의 물리적 환경(실행 환면 래핑, 도구 스키마 최적화 등)이 성능 결과에 미치는 영향을 정량적으로 완전히 분리하여 측정할 수 있는 표준화된 방법론은 무엇인가? [32, 33]
|
||||
- 런타임에 동적으로 새로운 도구를 탐색하고 호출할 수 있는 MCP(Model Context Protocol) 환경에서, 예상치 못한 도구 권한의 조합(Capability escalation)으로 발생하는 간접 프롬프트 인젝션 등의 보안 취약점을 사전에 차단하기 위한 하네스 수준의 권한 제어 모델은 어떻게 구축해야 하는가? [47, 48]
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** 개발자가 명령줄(CLI) 인터페이스나 IDE에 통합된 에이전트 환경(예: OpenDev)을 구축하여, 자율 코딩 에이전트가 격리된 샌드박스 내에서 파일 편집, 구조적 린팅, 테스트 실행을 안전하게 반복하도록 구현합니다 [49, 50].
|
||||
- **System Design:** 소프트웨어 개발 시 기획을 담당하는 Planner 에이전트, 코드를 구현하는 Generator 에이전트, 통합 테스트 및 검증을 수행하는 Evaluator 에이전트로 역할을 철저히 분리한 다중 에이전트 오케스트레이션 파이프라인 아키텍처를 설계합니다 [51-53].
|
||||
- **Operation / Maintenance:** LangSmith, AgentOps 등의 전문 옵저버빌리티(Observability) 및 평가 도구를 적용하여 런타임 환경에서 장기간 실행되는 에이전트의 컨텍스트 초과 상태, 도구 호출 실패율, 루프 중단 지점 등을 투명하게 모니터링하고 추적합니다 [54, 55].
|
||||
- **Learning Path:** 단순한 일회성 프롬프트 튜닝(Prompt Engineering)에서 벗어나, 에이전트가 문맥을 유지하도록 돕는 컨텍스트 엔지니어링(Context Engineering)과, 최종적으로 린터 강제, 메모리 지속성 등을 통합해 에이전트를 통제하는 하네스 엔지니어링(Harness Engineering)으로 기술 스택과 학습 패러다임을 진화시킵니다 [56, 57].
|
||||
- **My Project Relevance:** 소스에 관련 정보가 부족합니다. (개인의 특정 프로젝트나 사적 맥락에 연관된 내용은 제공된 소스 데이터 내에 기술되어 있지 않습니다).
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Retrieval-Augmented Generation (RAG)]]
|
||||
- 확장 방향: RAG는 단순히 정적인 문서에서 텍스트를 검색하여 모델에 지식을 주입하는 수동적인 방식이었다면, 이를 넘어 에이전트가 코드베이스 구조를 파악하고 여러 검색 도구를 거쳐 동적으로 정보를 직접 획득해나가는 'Agentic Search(에이전트적 탐색)' 및 연속적 지식 통합 아키텍처로 확장할 수 있습니다 [58-60].
|
||||
- [[Agent-to-Agent (A2A) Protocol]]
|
||||
- 확장 방향: MCP가 개별 에이전트와 외부 도구/데이터 간의 연결을 돕는 표준이라면, A2A 프로토콜은 서로 다른 하네스에 속하거나 원격으로 분산된 다수의 에이전트 인스턴스 간에 작업을 위임하고 상태를 동기화하며 통신하기 위한 상호운용성 네트워크 표준 기술로 확장할 수 있습니다 [37, 61].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -1,78 +0,0 @@
|
||||
# [[Model Context Protocol (MCP)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Model Context Protocol(MCP)은 2024년 11월 Anthropic이 도입한 오픈 소스 표준 프로토콜로, LLM 기반 AI 시스템이 외부 데이터 소스, 도구, 시스템과 통합되는 방식을 표준화합니다[1]. 이 프로토콜은 AI 애플리케이션의 "USB-C 포트" 역할을 하여, 각 시스템마다 맞춤형 커넥터를 구축해야 했던 기존의 "N×M" 데이터 통합 문제를 해결합니다[2-4]. 에이전트 하네스 엔지니어링 관점에서 MCP는 하네스의 도구 레지스트리(T-컴포넌트)를 외부 상호운용성 계층으로 분리하여, 맞춤형 통합 코드 없이도 에이전트가 동적으로 도구를 검색하고 실행할 수 있는 표준 인프라를 제공합니다[5-7].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **아키텍처 및 구성 요소**
|
||||
MCP는 명확한 클라이언트-서버 아키텍처를 따릅니다[8].
|
||||
* **MCP Host:** AI 애플리케이션(예: Claude Code, IDE) 자체로, LLM이 포함되어 있으며 여러 MCP 클라이언트를 관리합니다[9, 10].
|
||||
* **MCP Client:** Host 내부에 위치하여 LLM의 요청을 MCP 서버가 이해할 수 있게 번역하고 통신을 유지합니다[9, 10].
|
||||
* **MCP Server:** 로컬 또는 원격으로 실행되며, LLM에게 컨텍스트와 데이터, 도구 기능을 제공하는 외부 서비스입니다[11, 12].
|
||||
이들은 JSON-RPC 2.0을 전송 계층으로 사용하여 통신하며, 로컬 환경에서는 표준 입출력(stdio)을, 원격 환경에서는 Server-Sent Events(SSE)를 포함한 Streamable HTTP를 사용합니다[12-14].
|
||||
|
||||
* **에이전트 하네스에서의 역할 (T-컴포넌트 표준화)**
|
||||
MCP는 에이전트 하네스 설계에서 중대한 아키텍처적 전환을 의미합니다. 기존 하네스 내부의 사유 데이터 구조였던 도구 레지스트리를 표준화된 상호운용 계층으로 대체합니다[6, 15]. 하네스는 MCP 클라이언트로 작동하고 도구 제공자는 MCP 서버로 작동함으로써, 하네스는 개별 도구의 구현 세부 사항에 결합(coupling)되지 않고 도구의 발견(capability negotiation), 스키마 검증, 호출(dispatch)을 표준화된 방식으로 거버넌스할 수 있습니다[5, 7].
|
||||
|
||||
* **기본 기능 (Primitives)**
|
||||
MCP는 서버가 클라이언트에게 제공할 수 있는 세 가지 핵심 프리미티브를 정의합니다[16, 17].
|
||||
1. **Tools (도구):** AI가 외부 시스템에서 조치를 취할 수 있는 실행 가능한 함수 (예: 파일 조작, API 호출).
|
||||
2. **Resources (리소스):** AI 애플리케이션에 컨텍스트를 제공하는 데이터 소스.
|
||||
3. **Prompts (프롬프트):** LLM과의 상호작용을 구조화하는 재사용 가능한 템플릿.
|
||||
반대로 클라이언트 측에서도 서버가 호스트 LLM을 사용하거나(Sampling), 사용자 입력을 요청(Elicitation)하거나, 디버깅 메시지를 로깅(Logging)할 수 있는 프리미티브를 제공합니다[18].
|
||||
|
||||
* **A2A(Agent-to-Agent) 프로토콜과의 상호 보완성**
|
||||
MCP는 도구 통합(Agent-to-Tool)에 최적화되어 하네스의 T-컴포넌트 경계를 담당합니다. 반면 Google이 개발한 A2A 프로토콜은 하네스 간의 에이전트 위임 및 오케스트레이션(E-컴포넌트)을 담당합니다[5, 7, 19, 20]. 두 프로토콜은 경쟁 관계가 아닌 보완적 계층으로 작용하여 완전한 형태의 에이전트 통신 스택을 형성합니다[5, 7].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
* **네임스페이스 충돌 및 도구 스푸핑(Spoofing) 위협**
|
||||
MCP 사양에는 현재 강력한 네임스페이스 격리 기능이 없습니다. 이로 인해 서로 다른 제공자의 동일한 이름을 가진 도구가 기존의 신뢰할 수 있는 도구를 소리 없이 덮어쓰는(shadowing) 스푸핑 공격 성공률이 100%에 달한다는 분석 결과가 있습니다. 하네스가 MCP를 채택할 때는 프로토콜 수준에서 해결할 수 없는 이 취약점을 하네스 자체의 보안 계층(L-컴포넌트)에서 네임스페이스 격리를 통해 보완해야 합니다[21-23].
|
||||
* **보안 경계 및 '간접 프롬프트 인젝션' 위험**
|
||||
MCP를 통해 접근할 수 있는 도구의 출력을 신뢰할 수 있는 것으로 기본 가정해서는 안 됩니다[24, 25]. 악의적인 웹페이지나 외부 데이터를 읽어올 때 숨겨진 지시어가 포함되어 에이전트의 목표를 하이재킹하는 '간접 프롬프트 인젝션' 공격의 주요 표적이 될 수 있습니다[26, 27]. 하네스는 도구 출력이 LLM 컨텍스트에 주입되기 전에 반드시 출력을 검증해야 합니다.
|
||||
* **무상태(Stateless) 세션 및 권한 부여의 한계 (2026년 기준)**
|
||||
MCP는 서버 인증을 위해 OAuth를 지원하지만, 현재 도구 호출 전반에 걸친 상태 저장 세션(Stateful Session) 관리나, 특정 도구 접근에 대한 세밀한 단위의 권한 부여(authorization) 계층이 프로토콜 내에 표준화되어 있지 않습니다[28, 29]. 또한 원격 배포를 위한 Streamable HTTP 사용 시 상태 기반 헤더가 로드 밸런서와 충돌하는 등 세션 관리의 복잡성이 증가하는 제약이 있습니다[14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
* `[[Agent Harness]]`
|
||||
* 연결 이유: MCP 클라이언트를 탑재하여 도구와 에이전트(LLM) 사이의 통신을 실질적으로 제어하고 상태를 유지하는 핵심 런타임 인프라.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP가 제공하는 도구를 에이전트가 남용하지 않도록 제어하는 실행 루프(E-컴포넌트)와 라이프사이클 훅(L-컴포넌트) 등 전반적인 거버넌스 메커니즘 [5, 30, 31].
|
||||
* `[[A2A (Agent-to-Agent)]]`
|
||||
* 연결 이유: MCP가 도구/데이터를 위한 인터페이스라면, A2A는 에이전트 간의 작업 위임 및 오케스트레이션을 위한 프로토콜로 MCP와 통신 스택을 구성함.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 하네스를 넘어 멀티 에이전트 환경에서 에이전트가 다른 하네스의 에이전트를 호출할 때 사용되는 프로토콜 설계 및 비대칭적 역할 모델 [5, 7, 19, 20, 32-35].
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
* `[[JSON-RPC 2.0]]`
|
||||
* 연결 이유: MCP의 데이터 계층에서 클라이언트-서버 간 메시지 구조와 통신 의미(semantics)를 정의하는 기본 기반 프로토콜.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 동기적 응답과 비동기적 알림(Notifications)이 MCP 데이터 전송에서 어떻게 처리되는지 [12, 13, 36, 37].
|
||||
* `[[Agent Skills (Anthropic)]]`
|
||||
* 연결 이유: MCP가 개별 원자적(atomic) 도구 실행을 처리한다면, Agent Skills는 다단계 도구 워크플로우를 포장하는 표준.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP의 저수준(low-level) 통합을 기반으로 하네스의 L-컴포넌트(라이프사이클) 수준에서 도구들을 어떻게 구성하고 휴대 가능한 형태로 배포하는지 [38-41].
|
||||
|
||||
### Deeper Research Questions
|
||||
* MCP와 같은 표준화된 도구 통합 프로토콜 환경에서, 상이한 신뢰 수준을 가진 여러 MCP 서버가 반환하는 데이터를 컨텍스트 윈도우 내에서 안전하게 격리하고 검증할 수 있는 하네스 레벨의 보안 메커니즘은 무엇인가?
|
||||
* 무상태(stateless)를 기본으로 하는 MCP 서버의 도구 호출 결과물들을 에이전트가 여러 턴에 걸쳐 기억하도록 만들기 위해, 하네스의 상태 저장소(S-컴포넌트)와 MCP를 어떻게 결합해야 하는가?
|
||||
* 네임스페이스 충돌을 악용한 MCP의 도구 스푸핑(Tool spoofing) 취약점을 해결하기 위해 에이전트 하네스는 도구 레지스트리 단계에서 어떤 추가적인 식별 및 서명 검증 과정을 거쳐야 하는가?
|
||||
* MCP(Agent-to-Tool)와 A2A(Agent-to-Agent) 사이의 통합 경계에서, A2A를 통해 전달받은 작업 권한(Authorization) 정보를 MCP 서버의 도구 실행 권한으로 어떻게 안전하게 변환하여 매핑할 것인가?
|
||||
* 로컬 통신(stdio)과 원격 통신(Streamable HTTP) 사이에서, 에이전트 하네스의 도구 실행 지연 시간(latency) 차이가 LLM의 의사 결정 및 계획 루프(E-컴포넌트) 성능에 어떤 영향을 미치는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 애플리케이션 개발 시, 각 벤더별(API마다) 맞춤형 커넥터를 일일이 작성할 필요 없이, 표준화된 JSON-RPC 기반의 단일 MCP 클라이언트만 구현하면 Google Calendar, Notion 등 다양한 외부 서버와 즉시 연동할 수 있습니다 [4, 42, 43].
|
||||
* **System Design:** 에이전트 시스템을 설계할 때 도구와 데이터의 목록을 하네스 내부에 정적으로 유지하지 않고, 런타임에 외부 MCP 서버로부터 동적으로 발견(Discovery)하고 스키마를 렌더링하도록 분리하여 확장성과 모델 불가지론(agnostic)을 확보합니다 [5, 6].
|
||||
* **Operation / Maintenance:** 새로운 데이터 저장소나 API 도구가 추가될 때 핵심 에이전트 코드를 재배포할 필요 없이 독립적인 MCP 서버만 배포 및 연결하면 되므로 인프라 관리의 오버헤드가 크게 줄어듭니다 [6, 44].
|
||||
* **Learning Path:** 단순한 함수 호출(Function Calling)에서부터 특정 도메인 RAG, 대규모 API 통합(ToolLLM)을 거쳐 최종적으로 개방형 표준 프로토콜(MCP)로 도구 레지스트리 인프라가 진화하는 과정을 학습하는 지표가 됩니다 [45].
|
||||
* **My Project Relevance:** 소스에 관련 정보가 부족합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* `[[RAG (Retrieval-Augmented Generation)]]`
|
||||
* 확장 방향: 단순한 문맥 검색 및 텍스트 증강을 목표로 하는 수동적 RAG 시스템에서 나아가, MCP를 통한 외부 시스템 내 작업 '실행(Execution)' 및 양방향 상호작용으로 확장하는 방법론의 비교 연구 [46-50].
|
||||
* `[[Agent-Computer Interface (ACI)]]`
|
||||
* 확장 방향: 도구 및 터미널 환경에 접근하는 언어 모델을 위해 인터페이스(오류 메시지 처리, 상태 표현, 반환 형식)를 하네스가 어떻게 최적화해야 하는지를 다루는 설계 원칙 [51, 52].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -1,56 +0,0 @@
|
||||
# [[RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
RAG(Retrieval-Augmented Generation)는 AI 모델이 텍스트를 생성하기 전에 신뢰할 수 있는 외부 지식 기반이나 데이터 소스에서 관련 정보를 검색하여 프롬프트를 증강하는 기술입니다. 에이전트 시스템에서는 환각(hallucination)을 크게 줄이고 답변을 사실적 정보로 보강하는 역할을 합니다. 현대의 에이전트 하네스 엔지니어링(Agent Harness Engineering) 맥락에서는 RAG가 단순한 전처리 단계를 넘어, 에이전트가 자율적으로 필요할 때 정보를 점진적으로 가져오는 동적인 도구 호출(Tool Call) 및 컨텍스트 관리 전략으로 진화하고 있습니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **수동적 검색에서 자율적 도구 호출로의 진화 (Agentic RAG):**
|
||||
과거의 RAG는 사용자 쿼리를 기반으로 문서 전체를 한 번에 주입하는 정보 검색 컴포넌트에 가까웠습니다. 그러나 에이전트 환경(예: A-RAG)에서는 RAG를 하네스 도구 설계 문제로 재구성합니다. 검색된 문서를 파이프라인 시작 시점에 일괄 주입하는 대신, 하네스는 키워드 검색, 의미론적 검색, 청크 읽기 등의 검색 도구를 에이전트에게 노출하여, 에이전트가 각 추론 단계에서 필요한 정보만 점진적이고 능동적으로 가져오도록 설계합니다.
|
||||
* **검색 증강 컨텍스트 관리 (Retrieval-Augmented Context Management):**
|
||||
장기 실행(Long-horizon) 에이전트를 위한 지배적인 컨텍스트 관리 접근법입니다. 하네스는 에이전트의 전체 상호작용 기록을 요약하여 발생할 수 있는 정보 손실을 방지하기 위해, 모든 상호작용을 저장하고 각 단계에서 관련된 하위 집합(subset)만을 검색해 컨텍스트 윈도우에 주입합니다. 하네스는 문서의 단순 저장을 넘어 압축 및 추출 과정을 분리하는 파이프라인(예: Haystack 프레임워크 등)을 통해 에이전트의 인지 부하를 줄입니다.
|
||||
* **그래프 구조와의 결합 (GraphRAG):**
|
||||
기본적인 RAG(Baseline RAG)는 여러 정보 조각의 공통 속성을 가로질러 점들을 연결해야 하는 복잡한 질문에 답하거나, 대규모 데이터에서 요약된 의미론적 개념을 전체적으로 이해하는 데 한계를 보입니다. 이를 해결하기 위해 최신 하네스 설계에서는 의미론적 회상(Semantic recall)을 위한 벡터 검색과 관계 추론을 위한 그래프 탐색(Graph traversal), 그리고 진실 데이터를 위한 구조화된 쿼리(SQL/API)를 결합하여 사용합니다.
|
||||
* **MCP와의 상호 보완적 역할:**
|
||||
RAG가 정보의 '수동적 검색(Passive Retrieval)'을 통해 텍스트 생성 전 사실적 정확성을 높이는 데 주력한다면, MCP(Model Context Protocol)는 에이전트가 외부 시스템에서 작업을 '실행(Action)'하고 동적으로 양방향 상호작용을 할 수 있도록 하는 표준입니다. 하네스는 이 두 가지를 결합하여 정보 검색과 작업 실행 능력을 모두 갖춘 에이전트 인프라를 구축합니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **검색 지연 시간의 누적 (Retrieval Latency Injection):** 장기 실행 작업의 경우 매 단계마다 모델 추론 전 저장된 기록에 대한 검색 쿼리가 필요합니다. 대규모 벡터 데이터베이스의 콜드 스타트나 시맨틱 검색 지연 시간이 선형적으로 누적되면 전체 작업 시간에 심각한 오버헤드를 발생시킵니다. 하네스는 인덱스 예열(pre-warming)이나 중복 쿼리 방지 캐싱을 통해 이를 관리해야 합니다.
|
||||
* **적대적 콘텐츠에 의한 검색 게임화 (Retrieval Gaming by Adversarial Content):** 에이전트의 저장소에 외부 콘텐츠가 주입될 수 있는 경우, 공격자는 향후 검색 쿼리와 의미론적 유사성을 극대화하도록 조작된 콘텐츠를 삽입할 수 있습니다. 이는 에이전트의 결정적인 작업 순간에 악의적 지시문이 최우선으로 검색되게 만듭니다. 이를 방지하려면 하네스는 의미론적 유사성뿐만 아니라 정보 출처(Provenance)의 신뢰도에 따른 가중치를 부여해야 합니다.
|
||||
* **토큰 비용 절감 vs 검색 품질 분산 (Token Cost vs Retrieval Variance):** 초장기 컨텍스트(Ultra-long-context) 모델에 모든 데이터를 그대로 주입하는 방식은 충실도(Fidelity)는 높으나 막대한 토큰 비용이 발생합니다. 반면 RAG는 토큰 비용을 크게 줄이는 대신 쿼리 공식화(Query formulation)와 검색 알고리즘의 품질에 에이전트의 성능이 극도로 의존하게 되는 위험을 안고 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: RAG는 에이전트의 제한된 컨텍스트 윈도우에 필요한 정보만을 선별하여 주입하기 위한 핵심적인 컨텍스트 엔지니어링 전략입니다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 에이전트의 토큰 예산을 어떻게 관리하고, 무분별한 컨텍스트 부패(Context Rot)를 막기 위해 검색된 데이터를 언제 어떻게 주입하는지 이해할 수 있습니다.
|
||||
* [[Agentic Search]]
|
||||
* 연결 이유: 고정된 RAG 파이프라인에서 벗어나, 에이전트가 직접 다단계 검색을 계획하고 실행하는 능동적 검색 과정입니다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: RAG가 단순 전처리 과정이 아니라, 에이전트 하네스의 실행 루프(Execution Loop) 내에서 도구 호출(Tool Call) 형태로 통합되는 방식을 파악할 수 있습니다.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
* [[Model Context Protocol (MCP)]]
|
||||
* 연결 이유: RAG가 주로 지식 기반에서 데이터를 '검색'하는 목적이라면, MCP는 에이전트가 외부 시스템과 데이터를 주고받거나 '작업을 수행'하기 위한 양방향 프로토콜 통신 표준입니다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트 하네스에서 정보 검색(RAG)과 외부 환경에 대한 시스템 통합/실행(MCP)이 각각 어떤 경계를 가지고 상호작용하는지 명확히 구분할 수 있습니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 자체적으로 생성한 장기 상호작용 기록을 RAG로 검색할 때, 하네스는 모델의 현재 정보 요구를 정확히 반영하기 위해 쿼리 공식화(Query Formulation)를 모델에 위임할 것인가, 아니면 자체적인 정책으로 제어할 것인가?
|
||||
* 악의적인 데이터가 검색을 통해 에이전트의 컨텍스트 윈도우에 주입되는 '검색 게임화(Retrieval Gaming)'를 방어하기 위해, 하네스는 출처 기반(Provenance-weighted) 검색 아키텍처를 어떻게 구현해야 하는가?
|
||||
* 수백만 토큰의 컨텍스트 윈도우를 지원하는 모델(Long-context models)의 등장 상황에서, RAG 기반 하네스는 검색 지연 시간 오버헤드와 장문 컨텍스트 직접 주입의 컴퓨팅 비용 간의 트레이드오프를 어떻게 최적화해야 하는가?
|
||||
* 검색(Retrieval) 행위가 에이전트의 추론 흐름을 방해하지 않고 독립적으로 작동하도록 서브 에이전트(Subagent)에게 RAG 역할을 위임하는 오케스트레이션 설계는 시스템 안정성에 어떠한 영향을 미치는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 방대한 문서 저장소나 지식 기반 위에서 작동하는 에이전트를 구축할 때, Haystack과 같은 데이터 파이프라인 프레임워크나 벡터 데이터베이스를 하네스의 RAG 컴포넌트로 통합하여 구축합니다.
|
||||
* **System Design:** 에이전트의 실행 루프 내에서, RAG를 정적인 파이프라인이 아닌 키워드 검색, 의미론적 검색 도구 등의 집합으로 추상화하여 모델이 필요에 맞게 능동적으로 도구(Tool)를 호출하도록 설계합니다.
|
||||
* **Operation / Maintenance:** 운영 환경에서는 RAG 검색 시 발생하는 지연 시간(Latency)이 전체 에이전트 작업 시간에 미치는 영향을 모니터링하고, 검색 인덱스 예열(Pre-warming) 및 검색 결과 캐싱 최적화를 지속적으로 관리해야 합니다.
|
||||
* **Learning Path:** 기본 RAG 파이프라인 메커니즘 학습 ➔ 지식 그래프를 활용한 GraphRAG 접근법 이해 ➔ 에이전트가 스스로 검색을 제어하는 에이전틱 RAG(Agentic RAG) 설계 패턴으로의 확장.
|
||||
* **My Project Relevance:** 엔터프라이즈 사내 지식 기반 챗봇이나 복잡한 코드베이스를 탐색하는 자율 코딩 에이전트(Autonomous Coding Agent)를 설계할 때, 장기 메모리 소실을 막고 정확한 참조 데이터를 제공하기 위해 하네스 층위에 RAG 메커니즘을 내재화하는 데 핵심적으로 활용됩니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* [[GraphRAG]]
|
||||
* 확장 방향: 단순한 벡터 유사도 검색의 한계를 극복하고, 복잡한 문서 간의 관계를 매핑하여 다단계(Multi-hop) 추론을 가능하게 하는 지식 그래프 기반의 검색 증강 모델로 이해를 확장합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
Vendored
+1
-1
@@ -17,6 +17,6 @@
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.06831015277537619,
|
||||
"scale": 0.05827063129609155,
|
||||
"close": false
|
||||
}
|
||||
+3
-3
@@ -181,6 +181,9 @@
|
||||
},
|
||||
"active": "e84fb23982481828",
|
||||
"lastOpenFiles": [
|
||||
"Development/Agentic_Software_Engineering.md",
|
||||
"AI/Agent_State_Store.md",
|
||||
"Risk-Management.md",
|
||||
"확산 모델 (Diffusion Models).md",
|
||||
"확산 모델 (Diffusion Model).md",
|
||||
"해부학적 오류 디버깅 워크플로우.md",
|
||||
@@ -204,9 +207,6 @@
|
||||
"자연어 프롬프트(Natural Language Prompt).md",
|
||||
"인페인팅 및 아웃페인팅 (Inpainting and Outpainting).md",
|
||||
"인페인팅 및 드래프트 모드(Inpainting and Draft Mode).md",
|
||||
"인페인팅 (Inpainting-Vary Region).md",
|
||||
"인페인팅 (Inpainting).md",
|
||||
"인-이미지 텍스트(In-Image Text).md",
|
||||
"sessions/2026-04-30T07-07",
|
||||
"sessions",
|
||||
"company_state.json",
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: b4c2a1d3-e4f5-4a6b-8c7d-9e1b2c3d4f5a
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agent, harness, infrastructure, runtime, governance, ai]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-harness"
|
||||
---
|
||||
|
||||
# [[Agent Harness]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전트 하네스는 모델(두뇌)을 감싸 외부 세계와 안전하고 영속적으로 소통하게 만드는 '신체 및 환경 인프라'로, 프롬프트 엔지니어링을 넘어 시스템의 신뢰성과 성능 상한을 결정하는 핵심 제어 계층이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 하네스의 6대 구성 요소 (The 6-Component Framework)
|
||||
- **E (Execution Loop)**: 관찰-생각-행동 주기를 오케스트레이션하며 에러 복구 및 종료 조건을 제어한다.
|
||||
- **T (Tool Registry)**: 검증된 도구 카탈로그(API, 파일 제어 등)를 유지하고 호출을 라우팅한다.
|
||||
- **C (Context Manager)**: 정보 필터링, 우선순위화, 메모리 압축 전략을 관리한다.
|
||||
- **S (State Store)**: 실행 턴 및 세션 간의 상태를 영속적으로 저장하고 복구를 지원한다.
|
||||
- **L (Lifecycle Hooks)**: 인증, 로깅, 정책 시행을 위해 실행 전후를 가로채는 제어 지점이다.
|
||||
- **V (Evaluation Interface)**: 실행 궤적(Trajectory)과 성공 신호를 표준화된 형태로 캡처하여 분석한다.
|
||||
|
||||
### 2. 엔지니어링 패러다임의 진화
|
||||
- 프롬프트(2023) -> 컨텍스트(2025) -> **하네스 엔지니어링(2026)**으로 초점이 이동했다. 시스템의 품질은 이제 모델의 지능과 하네스의 제어 능력이 결합된 총합으로 결정된다.
|
||||
|
||||
### 3. 보안 및 런타임 제어
|
||||
- **샌드박싱**: 코드 실행 환경을 물리적으로 격리하여 호스트 시스템을 보호한다.
|
||||
- **거버넌스**: 도구 승인 파이프라인(HITL)을 통해 과도한 권한 행사를 방지하고 인젝션 공격을 차단한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **보안 vs 유용성**: 강력한 격리(MicroVM 등)는 안전하지만 지연 시간을 늘리고 복잡성을 높인다.
|
||||
- **메모리 유지 vs 컨텍스트 부패**: 모든 정보를 유지하면 추론에 유리하나 토큰 비용 급증과 주의 집중 분산(Attention Dilution) 문제가 발생한다.
|
||||
- **멀티 에이전트 오케스트레이션**: 역할 분리는 효율적이나 에이전트 간 통신 오버헤드와 일관성 관리 비용이 기하급수적으로 증가한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Model Context Protocol (MCP)]], [[Context Engineering]], [[Plan-Execute-Verify (PEV) Loop]], [[Sandboxing]]
|
||||
- **Raw Source**: [[00_Raw/Agent Harness]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agent Harness Infrastructure"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: e5f4a3b2-c1d0-4e8b-9a7d-2b3c4d5e6f7a
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [agent, memory, state-store, persistence, harness, ai]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-state-store"
|
||||
---
|
||||
|
||||
# [[Agent State Store]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Agent State Store(S-component)는 에이전트의 다중 턴 및 세션 간 상태 지속성을 관리하여 실행 중단 시 복구를 지원하고, 경험을 추상화된 지식으로 보존하는 런타임 거버넌스 인프라이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 역할 및 메모리 계층
|
||||
- **상태 보존**: 작업 중 발생할 수 있는 '상태 상실'을 방지하고 내결함성(Fault-tolerance)을 제공한다.
|
||||
- **메모리 분류**: 작업 메모리(Working), 에피소드 메모리(Episodic), 시맨틱 메모리(Semantic), 절차적 메모리(Procedural) 등으로 계층화하여 관리한다.
|
||||
|
||||
### 2. 아티팩트 기반 저장
|
||||
- **컨텍스트 오프로드**: 대용량 도구 출력이나 작업 결과물을 프롬프트 컨텍스트에서 제외하고 파일 시스템이나 가상 아티팩트 저장소에 저장하여 토큰 비용을 최적화한다.
|
||||
|
||||
### 3. 추론 결합 지속성 (Inference-Coupled Persistence)
|
||||
- **능동적 지식 저장**: 모델이 생성한 자기 반성 평가나 워크플로 스킬 등을 저장소에 기록하며, 하네스는 저장되는 지식의 품질을 관리하는 게이트 역할을 수행한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **메모리 오염 (Poisoning)**: 악의적 프롬프트가 영구 저장소에 기록될 경우 세션 경계를 넘는 보안 취약점이 발생하므로 수명주기 훅(L-hook)에서의 검증이 필수적이다.
|
||||
- **메모리 팽창 (Bloat)**: 무분별한 정보 축적은 검색 품질 저하와 '컨텍스트 부패'를 유발하며, 망각 곡선이나 요약 정책을 통한 관리가 필요하다.
|
||||
- **표준화 부재**: MCP와 달리 상태 저장소 인터페이스는 파편화되어 있어 에이전트 간 메모리 이식성이 낮다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Execution Loop (E-component)]], [[Context Manager (C-component)]], [[Lifecycle Hooks (L-component)]], [[Agent Workflow Memory (AWM)]]
|
||||
- **Raw Source**: [[00_Raw/Agent State Store]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agent State Store (S-component)"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: c3d2e1f4-a5b6-4c7d-8e9f-1a2b3c4d5e6f
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [mcp, protocol, ai, infrastructure, tools, integration]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-mcp"
|
||||
---
|
||||
|
||||
# [[Model Context Protocol (MCP)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> MCP는 AI 애플리케이션의 'USB-C 포트'로서, 에이전트 하네스와 외부 데이터/도구 간의 연결 방식을 표준화하여 N×M의 파편화된 통합 문제를 해결하는 오픈 소스 상호운용성 프로토콜이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 클라이언트-서버 아키텍처
|
||||
- **MCP Host**: LLM을 포함한 주 애플리케이션(IDE, 챗봇 등).
|
||||
- **MCP Client**: Host 내부에서 서버와 통신하며 모델의 요청을 번역한다.
|
||||
- **MCP Server**: 데이터, 도구, 컨텍스트를 제공하는 독립적 서비스.
|
||||
- **통신 계층**: JSON-RPC 2.0 기반으로 로컬(stdio) 및 원격(SSE/HTTP) 환경을 지원한다.
|
||||
|
||||
### 2. 핵심 프리미티브 (Core Primitives)
|
||||
- **Tools**: 에이전트가 외부 세계에서 실행하는 함수 (API 호출 등).
|
||||
- **Resources**: 에이전트에게 정보를 제공하는 데이터 소스.
|
||||
- **Prompts**: 상호작용을 구조화하는 재사용 가능한 템플릿.
|
||||
|
||||
### 3. 하네스 설계에서의 의의
|
||||
- **T-컴포넌트의 표준화**: 하네스의 도구 레지스트리를 표준 프로토콜 계층으로 분리하여, 모델과 도구 구현 간의 결합도를 낮추고 동적인 도구 발견을 가능하게 한다.
|
||||
- **A2A와의 보완성**: MCP가 '도구/데이터 연결'을 담당한다면, A2A는 하네스 간 '에이전트 위임'을 담당하여 완전한 에이전트 통신 스택을 이룬다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **보안 취약점 (Spoofing)**: 네임스페이스 격리가 부재하여 동일 이름의 도구가 신뢰할 수 있는 도구를 덮어쓰는 공격에 취약하며, 하네스 레벨의 검증이 필수적이다.
|
||||
- **간접 인젝션 위험**: 도구 출력물에 숨겨진 악의적 지시어가 포함될 수 있으므로, 하네스 주입 전 출력 검증이 필요하다.
|
||||
- **세션 관리의 한계**: 현재 상태 저장 세션이나 세밀한 권한 부여(RBAC) 표준이 미비하여 구현 시 추가적인 거버넌스 계층이 요구된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Agent Harness]], [[A2A (Agent-to-Agent)]], [[JSON-RPC 2.0]], [[Agent Skills (Anthropic)]]
|
||||
- **Raw Source**: [[00_Raw/Model Context Protocol (MCP)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Model Context Protocol (MCP) Standard"`
|
||||
3. Push: `git push origin main`
|
||||
+31
-18
@@ -1,31 +1,44 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-RAGG-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
id: d7f2e1b4-c3a5-4e8b-9d2f-1c6b4a2d3e4f
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, rag, llm, knowledge-injection, hallucination-mitigation, vector-db]
|
||||
last_reinforced: 2026-04-20
|
||||
tags: [rag, ai, retrieval, context, agent, infrastructure]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-rag"
|
||||
---
|
||||
|
||||
# [[RAG]]
|
||||
# [[RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "AI의 '오픈북 테스트': 모델이 학습하지 않은 최신 데이터나 회사 기밀 지식을 검색기(Retriever)가 실시간으로 찾아와서 질문과 함께 던져줌으로써, 환각(Hallucination) 없이 가장 정확하고 근거 있는 답변을 내놓게 만드는 LLM 시대의 핵심 지식 보조 장치."
|
||||
> RAG는 AI 모델의 정보 생성 전 사실적 근거를 외부 데이터에서 검색하여 주입함으로써 환각을 억제하며, 현대 에이전틱 시스템에서는 모델이 자율적으로 도구를 호출하여 필요한 정보를 점진적으로 확보하는 '능동적 지식 확장' 전략으로 진화했다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
검색 증강 생성(RAG)은 외부 지식 베이스에서 관련 정보를 검색하여 LLM의 출력을 보강하는 아키텍처입니다.
|
||||
|
||||
1. **3단계 프로세스**:
|
||||
* **Retrieve**: 질문과 유사한 지식 조각을 벡터 DB 등에서 찾아옴. (LSH와 연결 가능)
|
||||
* **Augment**: 찾아온 지식(Context)을 원래의 질문 앞에 붙임. ([[Prompt-Engineering]] 활용)
|
||||
* **Generate**: 풍부해진 맥락을 바탕으로 LLM이 최종 답변 생성. ([[Large Language Models (LLM)]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 모델을 매번 재학습([[Fine-tuning]])하지 않고도 새로운 지식을 즉시 주입 가능하며, 답변의 출처를 명시할 수 있어 신뢰도를 극대화하기 때문임. ([[Explainable-AI (XAI)]]와 연결)
|
||||
### 1. 에이전틱 RAG (Agentic RAG)의 부상
|
||||
- **수동적 검색에서 자율 호출로**: 단순히 사용자 쿼리 시점에 문서를 일괄 주입하는 방식에서 벗어나, 에이전트가 추론 과정 중 필요 시 검색 도구(Keyword, Semantic, SQL 등)를 직접 호출하여 정보를 가져온다.
|
||||
- **점진적 컨텍스트 보강**: 에이전트는 각 단계에서 필요한 최소한의 정보만 가져옴으로써 인지 부하를 줄이고 추론의 정확도를 높인다.
|
||||
|
||||
### 2. 검색 증강 컨텍스트 관리
|
||||
- **장기 메모리 구현**: 에이전트의 상호작용 기록 전체를 저장하고, 현재 작업과 연관된 하위 집합(Subset)만을 검색해 컨텍스트 윈도우에 주입함으로써 장기 실행 작업의 일관성을 유지한다.
|
||||
- **압축 및 추출**: Haystack 등 프레임워크를 통해 검색된 정보의 압축 및 핵심 추출 과정을 거쳐 모델에 전달한다.
|
||||
|
||||
### 3. GraphRAG: 지식 그래프와의 결합
|
||||
- **관계 기반 추론**: 벡터 검색의 한계인 다단계(Multi-hop) 질문이나 전체적인 요약 문제를 해결하기 위해, 문서 간의 관계를 매핑한 지식 그래프와 결합하여 고도화된 의미론적 회상을 구현한다.
|
||||
|
||||
### 4. MCP와의 상호작용
|
||||
- **지식 검색 vs 작업 실행**: RAG가 정보의 '수동적/능동적 검색'을 통한 사실성 확보에 주력한다면, MCP는 에이전트가 외부 시스템에서 작업을 '실행'하고 소통하는 표준을 제공하여 상호 보완한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순히 키워드로 검색했으나, 현대 정책은 의미적 유사성 정책을 계산하는 '시맨틱 검색 정책'과 여러 지식을 엮어 추론하는 '고급 RAG 정책(Graph RAG 등)'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 시스템인 P-Reinforce 또한 Obsidian에 저장된 600개의 정제된 지식 정책들을 RAG의 소스 정책으로 활용하여, 대표님의 질문에 가장 정확한 답 정책을 내놓기 위한 준비 정책을 하는 것임.
|
||||
- **지연 시간 오버헤드**: 매 단계 검색 쿼리가 추가됨에 따라 전체 실행 시간이 선형적으로 증가하며, 이는 하네스 차원의 인덱스 예열 및 캐싱으로 최적화해야 한다.
|
||||
- **검색 게임화 (Adversarial RAG)**: 외부 데이터에 조작된 유사 콘텐츠가 섞여 있을 경우 에이전트가 악의적 지시문을 최우선으로 검색할 위험이 있으며, 출처 기반 가중치 부여가 필수적이다.
|
||||
- **긴 컨텍스트 모델과의 경합**: 초장기 컨텍스트 모델이 등장함에 따라 모든 데이터를 직접 주입하는 방식과 RAG 검색 방식 사이의 비용-성능 균형점이 변화하고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Large Language Models (LLM)]], [[Prompt-Engineering]], [[Explainable-AI (XAI)]], [[Knowledge synthesis]], Vector-Database
|
||||
- **Modern Tech/Tools**: LangChain, [[LlamaIndex]], Pinecone, FAISS, GraphRAG.
|
||||
---
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Context Engineering]], [[Agentic Search]], [[GraphRAG]], [[Model Context Protocol (MCP)]]
|
||||
- **Raw Source**: [[00_Raw/RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify RAG (Retrieval-Augmented Generation)"`
|
||||
3. Push: `git push origin main`
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
id: f6a5b4c3-d2e1-4f0a-9b8c-7d6e5f4a3b2c
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agentic-se, software-engineering, ai-agent, harness, automation, development]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-agentic-se"
|
||||
---
|
||||
|
||||
# [[Agentic Software Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전틱 소프트웨어 엔지니어링은 개발자가 구현자(Implementer)에서 자율적으로 계획·코딩·디버깅하는 에이전트를 조율하는 오케스트레이터(Orchestrator)로 진화하는 패러다임이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 개발 패러다임의 전환
|
||||
- **오케스트레이션**: 인간은 시스템 아키텍처 설계와 전략적 방향 지시에 집중하고, 에이전트는 하네스 제어 하에 전술적 구현을 담당한다.
|
||||
- **PEV 루프 (Plan-Execute-Verify)**: 계획, 실행, 검증의 단계를 명시적으로 분리하여 에이전트의 작업 신뢰성을 확보한다.
|
||||
|
||||
### 2. 에이전트 하네스 인프라
|
||||
- **런타임 거버넌스**: 모델을 자율 에이전트로 변환하기 위해 실행 루프(E), 도구(T), 컨텍스트(C), 상태(S), 수명주기(L), 평가(V)를 제공하는 하네스가 필수적이다.
|
||||
- **격리된 실행**: 샌드박스(MicroVM/Container) 내에서 파일 시스템 접근, 명령어 실행, 시맨틱 분석을 안전하게 수행한다.
|
||||
|
||||
### 3. 가상 피드백 (SWE-World)
|
||||
- **효율적 학습**: 무거운 물리적 환경 대신 시뮬레이션된 피드백을 활용하여 에이전트의 강화학습 및 평가 효율을 극대화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **자율성 vs 보안**: 셸 접근 등 강력한 도구는 유용하지만 인젝션 및 샌드박스 탈출 위험을 동반하므로 Pareto 최적점을 찾는 설계가 필요하다.
|
||||
- **컨텍스트 경제성**: 장기 작업 기록 보존은 추론에 유리하나 토큰 비용 급증과 '컨텍스트 부패'를 유발하므로 적응형 압축이 요구된다.
|
||||
- **하네스 편향성**: 에이전트의 성능 지표는 모델 지능뿐만 아니라 하네스의 도구 설계 및 에러 처리 방식에 크게 좌우된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Plan-Execute-Verify (PEV) Loop]], [[SWE-World]]
|
||||
- **Raw Source**: [[00_Raw/Agentic Software Engineering]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agentic Software Engineering Paradigm"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: b4c2a1d3-e4f5-4a6b-8c7d-9e1b2c3d4f5a
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agent, harness, infrastructure, runtime, governance, ai]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-harness"
|
||||
---
|
||||
|
||||
# [[Agent Harness]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전트 하네스는 모델(두뇌)을 감싸 외부 세계와 안전하고 영속적으로 소통하게 만드는 '신체 및 환경 인프라'로, 프롬프트 엔지니어링을 넘어 시스템의 신뢰성과 성능 상한을 결정하는 핵심 제어 계층이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 하네스의 6대 구성 요소 (The 6-Component Framework)
|
||||
- **E (Execution Loop)**: 관찰-생각-행동 주기를 오케스트레이션하며 에러 복구 및 종료 조건을 제어한다.
|
||||
- **T (Tool Registry)**: 검증된 도구 카탈로그(API, 파일 제어 등)를 유지하고 호출을 라우팅한다.
|
||||
- **C (Context Manager)**: 정보 필터링, 우선순위화, 메모리 압축 전략을 관리한다.
|
||||
- **S (State Store)**: 실행 턴 및 세션 간의 상태를 영속적으로 저장하고 복구를 지원한다.
|
||||
- **L (Lifecycle Hooks)**: 인증, 로깅, 정책 시행을 위해 실행 전후를 가로채는 제어 지점이다.
|
||||
- **V (Evaluation Interface)**: 실행 궤적(Trajectory)과 성공 신호를 표준화된 형태로 캡처하여 분석한다.
|
||||
|
||||
### 2. 엔지니어링 패러다임의 진화
|
||||
- 프롬프트(2023) -> 컨텍스트(2025) -> **하네스 엔지니어링(2026)**으로 초점이 이동했다. 시스템의 품질은 이제 모델의 지능과 하네스의 제어 능력이 결합된 총합으로 결정된다.
|
||||
|
||||
### 3. 보안 및 런타임 제어
|
||||
- **샌드박싱**: 코드 실행 환경을 물리적으로 격리하여 호스트 시스템을 보호한다.
|
||||
- **거버넌스**: 도구 승인 파이프라인(HITL)을 통해 과도한 권한 행사를 방지하고 인젝션 공격을 차단한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **보안 vs 유용성**: 강력한 격리(MicroVM 등)는 안전하지만 지연 시간을 늘리고 복잡성을 높인다.
|
||||
- **메모리 유지 vs 컨텍스트 부패**: 모든 정보를 유지하면 추론에 유리하나 토큰 비용 급증과 주의 집중 분산(Attention Dilution) 문제가 발생한다.
|
||||
- **멀티 에이전트 오케스트레이션**: 역할 분리는 효율적이나 에이전트 간 통신 오버헤드와 일관성 관리 비용이 기하급수적으로 증가한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Model Context Protocol (MCP)]], [[Context Engineering]], [[Plan-Execute-Verify (PEV) Loop]], [[Sandboxing]]
|
||||
- **Raw Source**: [[00_Raw/Agent Harness]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agent Harness Infrastructure"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: e5f4a3b2-c1d0-4e8b-9a7d-2b3c4d5e6f7a
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [agent, memory, state-store, persistence, harness, ai]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-state-store"
|
||||
---
|
||||
|
||||
# [[Agent State Store]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Agent State Store(S-component)는 에이전트의 다중 턴 및 세션 간 상태 지속성을 관리하여 실행 중단 시 복구를 지원하고, 경험을 추상화된 지식으로 보존하는 런타임 거버넌스 인프라이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 역할 및 메모리 계층
|
||||
- **상태 보존**: 작업 중 발생할 수 있는 '상태 상실'을 방지하고 내결함성(Fault-tolerance)을 제공한다.
|
||||
- **메모리 분류**: 작업 메모리(Working), 에피소드 메모리(Episodic), 시맨틱 메모리(Semantic), 절차적 메모리(Procedural) 등으로 계층화하여 관리한다.
|
||||
|
||||
### 2. 아티팩트 기반 저장
|
||||
- **컨텍스트 오프로드**: 대용량 도구 출력이나 작업 결과물을 프롬프트 컨텍스트에서 제외하고 파일 시스템이나 가상 아티팩트 저장소에 저장하여 토큰 비용을 최적화한다.
|
||||
|
||||
### 3. 추론 결합 지속성 (Inference-Coupled Persistence)
|
||||
- **능동적 지식 저장**: 모델이 생성한 자기 반성 평가나 워크플로 스킬 등을 저장소에 기록하며, 하네스는 저장되는 지식의 품질을 관리하는 게이트 역할을 수행한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **메모리 오염 (Poisoning)**: 악의적 프롬프트가 영구 저장소에 기록될 경우 세션 경계를 넘는 보안 취약점이 발생하므로 수명주기 훅(L-hook)에서의 검증이 필수적이다.
|
||||
- **메모리 팽창 (Bloat)**: 무분별한 정보 축적은 검색 품질 저하와 '컨텍스트 부패'를 유발하며, 망각 곡선이나 요약 정책을 통한 관리가 필요하다.
|
||||
- **표준화 부재**: MCP와 달리 상태 저장소 인터페이스는 파편화되어 있어 에이전트 간 메모리 이식성이 낮다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Execution Loop (E-component)]], [[Context Manager (C-component)]], [[Lifecycle Hooks (L-component)]], [[Agent Workflow Memory (AWM)]]
|
||||
- **Raw Source**: [[00_Raw/Agent State Store]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agent State Store (S-component)"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
id: f6a5b4c3-d2e1-4f0a-9b8c-7d6e5f4a3b2c
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agentic-se, software-engineering, ai-agent, harness, automation, development]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-agentic-se"
|
||||
---
|
||||
|
||||
# [[Agentic Software Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전틱 소프트웨어 엔지니어링은 개발자가 구현자(Implementer)에서 자율적으로 계획·코딩·디버깅하는 에이전트를 조율하는 오케스트레이터(Orchestrator)로 진화하는 패러다임이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 개발 패러다임의 전환
|
||||
- **오케스트레이션**: 인간은 시스템 아키텍처 설계와 전략적 방향 지시에 집중하고, 에이전트는 하네스 제어 하에 전술적 구현을 담당한다.
|
||||
- **PEV 루프 (Plan-Execute-Verify)**: 계획, 실행, 검증의 단계를 명시적으로 분리하여 에이전트의 작업 신뢰성을 확보한다.
|
||||
|
||||
### 2. 에이전트 하네스 인프라
|
||||
- **런타임 거버넌스**: 모델을 자율 에이전트로 변환하기 위해 실행 루프(E), 도구(T), 컨텍스트(C), 상태(S), 수명주기(L), 평가(V)를 제공하는 하네스가 필수적이다.
|
||||
- **격리된 실행**: 샌드박스(MicroVM/Container) 내에서 파일 시스템 접근, 명령어 실행, 시맨틱 분석을 안전하게 수행한다.
|
||||
|
||||
### 3. 가상 피드백 (SWE-World)
|
||||
- **효율적 학습**: 무거운 물리적 환경 대신 시뮬레이션된 피드백을 활용하여 에이전트의 강화학습 및 평가 효율을 극대화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **자율성 vs 보안**: 셸 접근 등 강력한 도구는 유용하지만 인젝션 및 샌드박스 탈출 위험을 동반하므로 Pareto 최적점을 찾는 설계가 필요하다.
|
||||
- **컨텍스트 경제성**: 장기 작업 기록 보존은 추론에 유리하나 토큰 비용 급증과 '컨텍스트 부패'를 유발하므로 적응형 압축이 요구된다.
|
||||
- **하네스 편향성**: 에이전트의 성능 지표는 모델 지능뿐만 아니라 하네스의 도구 설계 및 에러 처리 방식에 크게 좌우된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Plan-Execute-Verify (PEV) Loop]], [[SWE-World]]
|
||||
- **Raw Source**: [[00_Raw/Agentic Software Engineering]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agentic Software Engineering Paradigm"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: c3d2e1f4-a5b6-4c7d-8e9f-1a2b3c4d5e6f
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [mcp, protocol, ai, infrastructure, tools, integration]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-mcp"
|
||||
---
|
||||
|
||||
# [[Model Context Protocol (MCP)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> MCP는 AI 애플리케이션의 'USB-C 포트'로서, 에이전트 하네스와 외부 데이터/도구 간의 연결 방식을 표준화하여 N×M의 파편화된 통합 문제를 해결하는 오픈 소스 상호운용성 프로토콜이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 클라이언트-서버 아키텍처
|
||||
- **MCP Host**: LLM을 포함한 주 애플리케이션(IDE, 챗봇 등).
|
||||
- **MCP Client**: Host 내부에서 서버와 통신하며 모델의 요청을 번역한다.
|
||||
- **MCP Server**: 데이터, 도구, 컨텍스트를 제공하는 독립적 서비스.
|
||||
- **통신 계층**: JSON-RPC 2.0 기반으로 로컬(stdio) 및 원격(SSE/HTTP) 환경을 지원한다.
|
||||
|
||||
### 2. 핵심 프리미티브 (Core Primitives)
|
||||
- **Tools**: 에이전트가 외부 세계에서 실행하는 함수 (API 호출 등).
|
||||
- **Resources**: 에이전트에게 정보를 제공하는 데이터 소스.
|
||||
- **Prompts**: 상호작용을 구조화하는 재사용 가능한 템플릿.
|
||||
|
||||
### 3. 하네스 설계에서의 의의
|
||||
- **T-컴포넌트의 표준화**: 하네스의 도구 레지스트리를 표준 프로토콜 계층으로 분리하여, 모델과 도구 구현 간의 결합도를 낮추고 동적인 도구 발견을 가능하게 한다.
|
||||
- **A2A와의 보완성**: MCP가 '도구/데이터 연결'을 담당한다면, A2A는 하네스 간 '에이전트 위임'을 담당하여 완전한 에이전트 통신 스택을 이룬다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **보안 취약점 (Spoofing)**: 네임스페이스 격리가 부재하여 동일 이름의 도구가 신뢰할 수 있는 도구를 덮어쓰는 공격에 취약하며, 하네스 레벨의 검증이 필수적이다.
|
||||
- **간접 인젝션 위험**: 도구 출력물에 숨겨진 악의적 지시어가 포함될 수 있으므로, 하네스 주입 전 출력 검증이 필요하다.
|
||||
- **세션 관리의 한계**: 현재 상태 저장 세션이나 세밀한 권한 부여(RBAC) 표준이 미비하여 구현 시 추가적인 거버넌스 계층이 요구된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Agent Harness]], [[A2A (Agent-to-Agent)]], [[JSON-RPC 2.0]], [[Agent Skills (Anthropic)]]
|
||||
- **Raw Source**: [[00_Raw/Model Context Protocol (MCP)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Model Context Protocol (MCP) Standard"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
id: d7f2e1b4-c3a5-4e8b-9d2f-1c6b4a2d3e4f
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.98
|
||||
tags: [rag, ai, retrieval, context, agent, infrastructure]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-rag"
|
||||
---
|
||||
|
||||
# [[RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> RAG는 AI 모델의 정보 생성 전 사실적 근거를 외부 데이터에서 검색하여 주입함으로써 환각을 억제하며, 현대 에이전틱 시스템에서는 모델이 자율적으로 도구를 호출하여 필요한 정보를 점진적으로 확보하는 '능동적 지식 확장' 전략으로 진화했다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 에이전틱 RAG (Agentic RAG)의 부상
|
||||
- **수동적 검색에서 자율 호출로**: 단순히 사용자 쿼리 시점에 문서를 일괄 주입하는 방식에서 벗어나, 에이전트가 추론 과정 중 필요 시 검색 도구(Keyword, Semantic, SQL 등)를 직접 호출하여 정보를 가져온다.
|
||||
- **점진적 컨텍스트 보강**: 에이전트는 각 단계에서 필요한 최소한의 정보만 가져옴으로써 인지 부하를 줄이고 추론의 정확도를 높인다.
|
||||
|
||||
### 2. 검색 증강 컨텍스트 관리
|
||||
- **장기 메모리 구현**: 에이전트의 상호작용 기록 전체를 저장하고, 현재 작업과 연관된 하위 집합(Subset)만을 검색해 컨텍스트 윈도우에 주입함으로써 장기 실행 작업의 일관성을 유지한다.
|
||||
- **압축 및 추출**: Haystack 등 프레임워크를 통해 검색된 정보의 압축 및 핵심 추출 과정을 거쳐 모델에 전달한다.
|
||||
|
||||
### 3. GraphRAG: 지식 그래프와의 결합
|
||||
- **관계 기반 추론**: 벡터 검색의 한계인 다단계(Multi-hop) 질문이나 전체적인 요약 문제를 해결하기 위해, 문서 간의 관계를 매핑한 지식 그래프와 결합하여 고도화된 의미론적 회상을 구현한다.
|
||||
|
||||
### 4. MCP와의 상호작용
|
||||
- **지식 검색 vs 작업 실행**: RAG가 정보의 '수동적/능동적 검색'을 통한 사실성 확보에 주력한다면, MCP는 에이전트가 외부 시스템에서 작업을 '실행'하고 소통하는 표준을 제공하여 상호 보완한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **지연 시간 오버헤드**: 매 단계 검색 쿼리가 추가됨에 따라 전체 실행 시간이 선형적으로 증가하며, 이는 하네스 차원의 인덱스 예열 및 캐싱으로 최적화해야 한다.
|
||||
- **검색 게임화 (Adversarial RAG)**: 외부 데이터에 조작된 유사 콘텐츠가 섞여 있을 경우 에이전트가 악의적 지시문을 최우선으로 검색할 위험이 있으며, 출처 기반 가중치 부여가 필수적이다.
|
||||
- **긴 컨텍스트 모델과의 경합**: 초장기 컨텍스트 모델이 등장함에 따라 모든 데이터를 직접 주입하는 방식과 RAG 검색 방식 사이의 비용-성능 균형점이 변화하고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Context Engineering]], [[Agentic Search]], [[GraphRAG]], [[Model Context Protocol (MCP)]]
|
||||
- **Raw Source**: [[00_Raw/RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify RAG (Retrieval-Augmented Generation)"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: b4c2a1d3-e4f5-4a6b-8c7d-9e1b2c3d4f5a
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agent, harness, infrastructure, runtime, governance, ai]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-harness"
|
||||
---
|
||||
|
||||
# [[Agent Harness]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전트 하네스는 모델(두뇌)을 감싸 외부 세계와 안전하고 영속적으로 소통하게 만드는 '신체 및 환경 인프라'로, 프롬프트 엔지니어링을 넘어 시스템의 신뢰성과 성능 상한을 결정하는 핵심 제어 계층이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 하네스의 6대 구성 요소 (The 6-Component Framework)
|
||||
- **E (Execution Loop)**: 관찰-생각-행동 주기를 오케스트레이션하며 에러 복구 및 종료 조건을 제어한다.
|
||||
- **T (Tool Registry)**: 검증된 도구 카탈로그(API, 파일 제어 등)를 유지하고 호출을 라우팅한다.
|
||||
- **C (Context Manager)**: 정보 필터링, 우선순위화, 메모리 압축 전략을 관리한다.
|
||||
- **S (State Store)**: 실행 턴 및 세션 간의 상태를 영속적으로 저장하고 복구를 지원한다.
|
||||
- **L (Lifecycle Hooks)**: 인증, 로깅, 정책 시행을 위해 실행 전후를 가로채는 제어 지점이다.
|
||||
- **V (Evaluation Interface)**: 실행 궤적(Trajectory)과 성공 신호를 표준화된 형태로 캡처하여 분석한다.
|
||||
|
||||
### 2. 엔지니어링 패러다임의 진화
|
||||
- 프롬프트(2023) -> 컨텍스트(2025) -> **하네스 엔지니어링(2026)**으로 초점이 이동했다. 시스템의 품질은 이제 모델의 지능과 하네스의 제어 능력이 결합된 총합으로 결정된다.
|
||||
|
||||
### 3. 보안 및 런타임 제어
|
||||
- **샌드박싱**: 코드 실행 환경을 물리적으로 격리하여 호스트 시스템을 보호한다.
|
||||
- **거버넌스**: 도구 승인 파이프라인(HITL)을 통해 과도한 권한 행사를 방지하고 인젝션 공격을 차단한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **보안 vs 유용성**: 강력한 격리(MicroVM 등)는 안전하지만 지연 시간을 늘리고 복잡성을 높인다.
|
||||
- **메모리 유지 vs 컨텍스트 부패**: 모든 정보를 유지하면 추론에 유리하나 토큰 비용 급증과 주의 집중 분산(Attention Dilution) 문제가 발생한다.
|
||||
- **멀티 에이전트 오케스트레이션**: 역할 분리는 효율적이나 에이전트 간 통신 오버헤드와 일관성 관리 비용이 기하급수적으로 증가한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Model Context Protocol (MCP)]], [[Context Engineering]], [[Plan-Execute-Verify (PEV) Loop]], [[Sandboxing]]
|
||||
- **Raw Source**: [[00_Raw/Agent Harness]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agent Harness Infrastructure"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: e5f4a3b2-c1d0-4e8b-9a7d-2b3c4d5e6f7a
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [agent, memory, state-store, persistence, harness, ai]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-state-store"
|
||||
---
|
||||
|
||||
# [[Agent State Store]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Agent State Store(S-component)는 에이전트의 다중 턴 및 세션 간 상태 지속성을 관리하여 실행 중단 시 복구를 지원하고, 경험을 추상화된 지식으로 보존하는 런타임 거버넌스 인프라이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 역할 및 메모리 계층
|
||||
- **상태 보존**: 작업 중 발생할 수 있는 '상태 상실'을 방지하고 내결함성(Fault-tolerance)을 제공한다.
|
||||
- **메모리 분류**: 작업 메모리(Working), 에피소드 메모리(Episodic), 시맨틱 메모리(Semantic), 절차적 메모리(Procedural) 등으로 계층화하여 관리한다.
|
||||
|
||||
### 2. 아티팩트 기반 저장
|
||||
- **컨텍스트 오프로드**: 대용량 도구 출력이나 작업 결과물을 프롬프트 컨텍스트에서 제외하고 파일 시스템이나 가상 아티팩트 저장소에 저장하여 토큰 비용을 최적화한다.
|
||||
|
||||
### 3. 추론 결합 지속성 (Inference-Coupled Persistence)
|
||||
- **능동적 지식 저장**: 모델이 생성한 자기 반성 평가나 워크플로 스킬 등을 저장소에 기록하며, 하네스는 저장되는 지식의 품질을 관리하는 게이트 역할을 수행한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **메모리 오염 (Poisoning)**: 악의적 프롬프트가 영구 저장소에 기록될 경우 세션 경계를 넘는 보안 취약점이 발생하므로 수명주기 훅(L-hook)에서의 검증이 필수적이다.
|
||||
- **메모리 팽창 (Bloat)**: 무분별한 정보 축적은 검색 품질 저하와 '컨텍스트 부패'를 유발하며, 망각 곡선이나 요약 정책을 통한 관리가 필요하다.
|
||||
- **표준화 부재**: MCP와 달리 상태 저장소 인터페이스는 파편화되어 있어 에이전트 간 메모리 이식성이 낮다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Execution Loop (E-component)]], [[Context Manager (C-component)]], [[Lifecycle Hooks (L-component)]], [[Agent Workflow Memory (AWM)]]
|
||||
- **Raw Source**: [[00_Raw/Agent State Store]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agent State Store (S-component)"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
id: f6a5b4c3-d2e1-4f0a-9b8c-7d6e5f4a3b2c
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agentic-se, software-engineering, ai-agent, harness, automation, development]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-agentic-se"
|
||||
---
|
||||
|
||||
# [[Agentic Software Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전틱 소프트웨어 엔지니어링은 개발자가 구현자(Implementer)에서 자율적으로 계획·코딩·디버깅하는 에이전트를 조율하는 오케스트레이터(Orchestrator)로 진화하는 패러다임이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 개발 패러다임의 전환
|
||||
- **오케스트레이션**: 인간은 시스템 아키텍처 설계와 전략적 방향 지시에 집중하고, 에이전트는 하네스 제어 하에 전술적 구현을 담당한다.
|
||||
- **PEV 루프 (Plan-Execute-Verify)**: 계획, 실행, 검증의 단계를 명시적으로 분리하여 에이전트의 작업 신뢰성을 확보한다.
|
||||
|
||||
### 2. 에이전트 하네스 인프라
|
||||
- **런타임 거버넌스**: 모델을 자율 에이전트로 변환하기 위해 실행 루프(E), 도구(T), 컨텍스트(C), 상태(S), 수명주기(L), 평가(V)를 제공하는 하네스가 필수적이다.
|
||||
- **격리된 실행**: 샌드박스(MicroVM/Container) 내에서 파일 시스템 접근, 명령어 실행, 시맨틱 분석을 안전하게 수행한다.
|
||||
|
||||
### 3. 가상 피드백 (SWE-World)
|
||||
- **효율적 학습**: 무거운 물리적 환경 대신 시뮬레이션된 피드백을 활용하여 에이전트의 강화학습 및 평가 효율을 극대화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **자율성 vs 보안**: 셸 접근 등 강력한 도구는 유용하지만 인젝션 및 샌드박스 탈출 위험을 동반하므로 Pareto 최적점을 찾는 설계가 필요하다.
|
||||
- **컨텍스트 경제성**: 장기 작업 기록 보존은 추론에 유리하나 토큰 비용 급증과 '컨텍스트 부패'를 유발하므로 적응형 압축이 요구된다.
|
||||
- **하네스 편향성**: 에이전트의 성능 지표는 모델 지능뿐만 아니라 하네스의 도구 설계 및 에러 처리 방식에 크게 좌우된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Plan-Execute-Verify (PEV) Loop]], [[SWE-World]]
|
||||
- **Raw Source**: [[00_Raw/Agentic Software Engineering]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agentic Software Engineering Paradigm"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: c3d2e1f4-a5b6-4c7d-8e9f-1a2b3c4d5e6f
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [mcp, protocol, ai, infrastructure, tools, integration]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-mcp"
|
||||
---
|
||||
|
||||
# [[Model Context Protocol (MCP)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> MCP는 AI 애플리케이션의 'USB-C 포트'로서, 에이전트 하네스와 외부 데이터/도구 간의 연결 방식을 표준화하여 N×M의 파편화된 통합 문제를 해결하는 오픈 소스 상호운용성 프로토콜이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 클라이언트-서버 아키텍처
|
||||
- **MCP Host**: LLM을 포함한 주 애플리케이션(IDE, 챗봇 등).
|
||||
- **MCP Client**: Host 내부에서 서버와 통신하며 모델의 요청을 번역한다.
|
||||
- **MCP Server**: 데이터, 도구, 컨텍스트를 제공하는 독립적 서비스.
|
||||
- **통신 계층**: JSON-RPC 2.0 기반으로 로컬(stdio) 및 원격(SSE/HTTP) 환경을 지원한다.
|
||||
|
||||
### 2. 핵심 프리미티브 (Core Primitives)
|
||||
- **Tools**: 에이전트가 외부 세계에서 실행하는 함수 (API 호출 등).
|
||||
- **Resources**: 에이전트에게 정보를 제공하는 데이터 소스.
|
||||
- **Prompts**: 상호작용을 구조화하는 재사용 가능한 템플릿.
|
||||
|
||||
### 3. 하네스 설계에서의 의의
|
||||
- **T-컴포넌트의 표준화**: 하네스의 도구 레지스트리를 표준 프로토콜 계층으로 분리하여, 모델과 도구 구현 간의 결합도를 낮추고 동적인 도구 발견을 가능하게 한다.
|
||||
- **A2A와의 보완성**: MCP가 '도구/데이터 연결'을 담당한다면, A2A는 하네스 간 '에이전트 위임'을 담당하여 완전한 에이전트 통신 스택을 이룬다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **보안 취약점 (Spoofing)**: 네임스페이스 격리가 부재하여 동일 이름의 도구가 신뢰할 수 있는 도구를 덮어쓰는 공격에 취약하며, 하네스 레벨의 검증이 필수적이다.
|
||||
- **간접 인젝션 위험**: 도구 출력물에 숨겨진 악의적 지시어가 포함될 수 있으므로, 하네스 주입 전 출력 검증이 필요하다.
|
||||
- **세션 관리의 한계**: 현재 상태 저장 세션이나 세밀한 권한 부여(RBAC) 표준이 미비하여 구현 시 추가적인 거버넌스 계층이 요구된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Agent Harness]], [[A2A (Agent-to-Agent)]], [[JSON-RPC 2.0]], [[Agent Skills (Anthropic)]]
|
||||
- **Raw Source**: [[00_Raw/Model Context Protocol (MCP)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Model Context Protocol (MCP) Standard"`
|
||||
3. Push: `git push origin main`
|
||||
+31
-18
@@ -1,31 +1,44 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-RAGG-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
id: d7f2e1b4-c3a5-4e8b-9d2f-1c6b4a2d3e4f
|
||||
category: "[[10_Wiki/Topics/AI]]"
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, rag, llm, knowledge-injection, hallucination-mitigation, vector-db]
|
||||
last_reinforced: 2026-04-20
|
||||
tags: [rag, ai, retrieval, context, agent, infrastructure]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-rag"
|
||||
---
|
||||
|
||||
# [[RAG]]
|
||||
# [[RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "AI의 '오픈북 테스트': 모델이 학습하지 않은 최신 데이터나 회사 기밀 지식을 검색기(Retriever)가 실시간으로 찾아와서 질문과 함께 던져줌으로써, 환각(Hallucination) 없이 가장 정확하고 근거 있는 답변을 내놓게 만드는 LLM 시대의 핵심 지식 보조 장치."
|
||||
> RAG는 AI 모델의 정보 생성 전 사실적 근거를 외부 데이터에서 검색하여 주입함으로써 환각을 억제하며, 현대 에이전틱 시스템에서는 모델이 자율적으로 도구를 호출하여 필요한 정보를 점진적으로 확보하는 '능동적 지식 확장' 전략으로 진화했다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
검색 증강 생성(RAG)은 외부 지식 베이스에서 관련 정보를 검색하여 LLM의 출력을 보강하는 아키텍처입니다.
|
||||
|
||||
1. **3단계 프로세스**:
|
||||
* **Retrieve**: 질문과 유사한 지식 조각을 벡터 DB 등에서 찾아옴. (LSH와 연결 가능)
|
||||
* **Augment**: 찾아온 지식(Context)을 원래의 질문 앞에 붙임. (Prompt-Engineering 활용)
|
||||
* **Generate**: 풍부해진 맥락을 바탕으로 LLM이 최종 답변 생성. (Large Language Models (LLM)와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 모델을 매번 재학습(Fine-tuning)하지 않고도 새로운 지식을 즉시 주입 가능하며, 답변의 출처를 명시할 수 있어 신뢰도를 극대화하기 때문임. (Explainable-AI (XAI)와 연결)
|
||||
### 1. 에이전틱 RAG (Agentic RAG)의 부상
|
||||
- **수동적 검색에서 자율 호출로**: 단순히 사용자 쿼리 시점에 문서를 일괄 주입하는 방식에서 벗어나, 에이전트가 추론 과정 중 필요 시 검색 도구(Keyword, Semantic, SQL 등)를 직접 호출하여 정보를 가져온다.
|
||||
- **점진적 컨텍스트 보강**: 에이전트는 각 단계에서 필요한 최소한의 정보만 가져옴으로써 인지 부하를 줄이고 추론의 정확도를 높인다.
|
||||
|
||||
### 2. 검색 증강 컨텍스트 관리
|
||||
- **장기 메모리 구현**: 에이전트의 상호작용 기록 전체를 저장하고, 현재 작업과 연관된 하위 집합(Subset)만을 검색해 컨텍스트 윈도우에 주입함으로써 장기 실행 작업의 일관성을 유지한다.
|
||||
- **압축 및 추출**: Haystack 등 프레임워크를 통해 검색된 정보의 압축 및 핵심 추출 과정을 거쳐 모델에 전달한다.
|
||||
|
||||
### 3. GraphRAG: 지식 그래프와의 결합
|
||||
- **관계 기반 추론**: 벡터 검색의 한계인 다단계(Multi-hop) 질문이나 전체적인 요약 문제를 해결하기 위해, 문서 간의 관계를 매핑한 지식 그래프와 결합하여 고도화된 의미론적 회상을 구현한다.
|
||||
|
||||
### 4. MCP와의 상호작용
|
||||
- **지식 검색 vs 작업 실행**: RAG가 정보의 '수동적/능동적 검색'을 통한 사실성 확보에 주력한다면, MCP는 에이전트가 외부 시스템에서 작업을 '실행'하고 소통하는 표준을 제공하여 상호 보완한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순히 키워드로 검색했으나, 현대 정책은 의미적 유사성 정책을 계산하는 '시맨틱 검색 정책'과 여러 지식을 엮어 추론하는 '고급 RAG 정책(Graph RAG 등)'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 시스템인 P-Reinforce 또한 Obsidian에 저장된 600개의 정제된 지식 정책들을 RAG의 소스 정책으로 활용하여, 대표님의 질문에 가장 정확한 답 정책을 내놓기 위한 준비 정책을 하는 것임.
|
||||
- **지연 시간 오버헤드**: 매 단계 검색 쿼리가 추가됨에 따라 전체 실행 시간이 선형적으로 증가하며, 이는 하네스 차원의 인덱스 예열 및 캐싱으로 최적화해야 한다.
|
||||
- **검색 게임화 (Adversarial RAG)**: 외부 데이터에 조작된 유사 콘텐츠가 섞여 있을 경우 에이전트가 악의적 지시문을 최우선으로 검색할 위험이 있으며, 출처 기반 가중치 부여가 필수적이다.
|
||||
- **긴 컨텍스트 모델과의 경합**: 초장기 컨텍스트 모델이 등장함에 따라 모든 데이터를 직접 주입하는 방식과 RAG 검색 방식 사이의 비용-성능 균형점이 변화하고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Large Language Models (LLM)]], [[Prompt-Engineering]], [[Explainable-AI (XAI)]], [[Knowledge synthesis]], Vector-Database
|
||||
- **Modern Tech/Tools**: LangChain, LlamaIndex, Pinecone, FAISS, GraphRAG.
|
||||
---
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
- **Related**: [[Context Engineering]], [[Agentic Search]], [[GraphRAG]], [[Model Context Protocol (MCP)]]
|
||||
- **Raw Source**: [[00_Raw/RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify RAG (Retrieval-Augmented Generation)"`
|
||||
3. Push: `git push origin main`
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
id: f6a5b4c3-d2e1-4f0a-9b8c-7d6e5f4a3b2c
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.99
|
||||
tags: [agentic-se, software-engineering, ai-agent, harness, automation, development]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-agentic-se"
|
||||
---
|
||||
|
||||
# [[Agentic Software Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전틱 소프트웨어 엔지니어링은 개발자가 구현자(Implementer)에서 자율적으로 계획·코딩·디버깅하는 에이전트를 조율하는 오케스트레이터(Orchestrator)로 진화하는 패러다임이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 개발 패러다임의 전환
|
||||
- **오케스트레이션**: 인간은 시스템 아키텍처 설계와 전략적 방향 지시에 집중하고, 에이전트는 하네스 제어 하에 전술적 구현을 담당한다.
|
||||
- **PEV 루프 (Plan-Execute-Verify)**: 계획, 실행, 검증의 단계를 명시적으로 분리하여 에이전트의 작업 신뢰성을 확보한다.
|
||||
|
||||
### 2. 에이전트 하네스 인프라
|
||||
- **런타임 거버넌스**: 모델을 자율 에이전트로 변환하기 위해 실행 루프(E), 도구(T), 컨텍스트(C), 상태(S), 수명주기(L), 평가(V)를 제공하는 하네스가 필수적이다.
|
||||
- **격리된 실행**: 샌드박스(MicroVM/Container) 내에서 파일 시스템 접근, 명령어 실행, 시맨틱 분석을 안전하게 수행한다.
|
||||
|
||||
### 3. 가상 피드백 (SWE-World)
|
||||
- **효율적 학습**: 무거운 물리적 환경 대신 시뮬레이션된 피드백을 활용하여 에이전트의 강화학습 및 평가 효율을 극대화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **자율성 vs 보안**: 셸 접근 등 강력한 도구는 유용하지만 인젝션 및 샌드박스 탈출 위험을 동반하므로 Pareto 최적점을 찾는 설계가 필요하다.
|
||||
- **컨텍스트 경제성**: 장기 작업 기록 보존은 추론에 유리하나 토큰 비용 급증과 '컨텍스트 부패'를 유발하므로 적응형 압축이 요구된다.
|
||||
- **하네스 편향성**: 에이전트의 성능 지표는 모델 지능뿐만 아니라 하네스의 도구 설계 및 에러 처리 방식에 크게 좌우된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Plan-Execute-Verify (PEV) Loop]], [[SWE-World]]
|
||||
- **Raw Source**: [[00_Raw/Agentic Software Engineering]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agentic Software Engineering Paradigm"`
|
||||
3. Push: `git push origin main`
|
||||
Reference in New Issue
Block a user