docs: finalize P-Reinforce wikification and cross-post topics to domain categories
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,58 @@
|
||||
# [[A2A (Agent-to-Agent Protocol)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
A2A(Agent-to-Agent Protocol)는 2025년 Google이 공개한 에이전트 간 통신 및 작업 위임을 위한 오픈 프로토콜이다. 단일 하네스(Harness) 내부의 도구 접근을 표준화하는 MCP와 달리, 서로 다른 하네스에 존재하는 에이전트 간의 원격 통신, 작업 위임, 상태 공유를 표준화한다. HTTPS와 Server-Sent Events(SSE)를 전송 계층으로 활용하여 에이전트 간의 장기 실행 작업을 스트리밍하고 통제 가능한 다중 에이전트 생태계를 구축하는 데 핵심적인 역할을 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **다중 에이전트 오케스트레이션(E-component) 표준화**: A2A는 에이전트 하네스의 실행 루프(E-component)에서 서브 에이전트나 외부 에이전트에게 작업을 위임하기 위한 표준 메커니즘을 제공한다. 위임하는 하네스는 대상 에이전트의 내부 구현 방식을 알 필요 없이 A2A의 작업 명세(Task specification)를 통해 작업을 전달할 수 있다.
|
||||
* **Agent Card를 통한 기능 탐색**: A2A는 에이전트가 다른 에이전트의 능력(Capabilities)과 통신 인터페이스를 동적으로 발견(Discovery)할 수 있도록 `Agent Cards`라는 개념을 지원한다. 이를 통해 에이전트들이 잘 알려진 URL(well-known URLs)을 통해 서로를 탐색하고 라우팅할 수 있다.
|
||||
* **상태 유지(Stateful) 및 비동기 스트리밍**: HTTP POST 및 SSE를 기반으로 작동하여 작업 진행 상황을 실시간으로 스트리밍한다. Task ID를 통해 상태를 유지하는(Stateful) 작업 관리를 기본적으로 지원하며, 연결이 끊긴 클라이언트나 작업에 대한 푸시 알림 기능도 제공한다.
|
||||
* **메시지와 아티팩트의 분리**: A2A 프로토콜은 채팅 메시지와 작업 아티팩트(Artifacts)를 명시적으로 분리하여, 위임된 작업의 결과가 단순한 텍스트 형태의 메시지가 아닌 구조화된 작업 아티팩트로 반환되도록 모델링한다.
|
||||
* **하네스 통합 및 MCP와의 보완적 관계**: A2A는 에이전트와 도구 간의 통신을 담당하는 MCP(Model Context Protocol)와 경쟁하지 않고 보완적인 프로토콜 스택을 형성한다. MCP가 하네스 내부의 도구 인터페이스(T-component)를 표준화한다면, A2A는 하네스 간, 혹은 에이전트 간의 작업 위임 및 조정 경계(E-component)를 표준화한다.
|
||||
* **인증 및 거버넌스**: OAuth 기반의 인증 모델과 HTTPS 강제화를 기본적으로 포함하여 다른 프로토콜보다 강력한 보안 및 신원(Identity) 관리 기능을 제공한다. 다중 에이전트 체인에서 하네스는 A2A 통신을 관찰 및 로깅하여 무한 위임 루프, 권한 우회, 그리고 예기치 않은 패턴을 차단할 수 있는 신뢰 경계(Trust Boundary)를 설정해야 한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **통신 지연 시간(Latency) 문제**: A2A의 HTTPS 및 SSE 전송 방식은 인터넷 규모의 조직 간 통신을 위해 설계되었기 때문에 로컬 도구 호출(예: MCP의 stdio 전송)에 비해 통신에 50~200ms 이상의 기본 지연 시간 오버헤드가 발생한다. 따라서 단일 하네스 내의 밀접하고 빠른 도구 실행 루프에는 부적합할 수 있다.
|
||||
* **보안 및 통합 경계 관리의 복잡성**: A2A는 하네스 간의 위임을 처리하므로 위임받는 하네스의 보안 컨텍스트, 상태 상속 정책, 평가 및 감사 책임 구조(Evaluation Accountability)를 명확히 정의해야 한다. A2A를 통한 위임이 기존 커넥터 정책이나 데이터 경계를 우회하는 데 악용되지 않도록 하네스 수준의 엄격한 거버넌스가 필수적이다.
|
||||
* **프로토콜 간 권한 변환의 부재**: 현재 A2A 작업을 통해 받은 권한 정보를 하네스 내부의 MCP 도구 권한(Permissions)으로 어떻게 변환할 것인지에 대한 표준화된 통합 사양이 아직 불명확하여, 배포자가 이 권한 매핑을 임시방편(ad-hoc)으로 직접 해결해야 하는 구조적 한계가 존재한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처 및 기반 기술]
|
||||
* [[MCP (Model Context Protocol)]]
|
||||
* 연결 이유: A2A가 하네스 외부의 에이전트 간(Agent-to-Agent) 통신을 담당한다면, MCP는 하네스 내부의 에이전트와 도구 간(Agent-to-Tool) 통신을 담당하여 함께 통합된 하네스 통신 스택을 이룬다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스 아키텍처 내에서 도구 제어(T-component)와 에이전트 위임(E-component) 사이의 구조적 역할 분담 및 상호작용.
|
||||
* [[E-component (Execution Loop)]]
|
||||
* 연결 이유: A2A 프로토콜은 에이전트의 실행 루프를 다중 에이전트로 확장할 때, 하네스의 E-component가 다중 에이전트 조정을 표준화하고 위임하는 통로 역할을 한다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트 간 통신이 단순한 API 호출을 넘어, 상태 머신 및 실행 루프의 제어 흐름(Control Flow)에 어떻게 안전하게 통합되는지 이해할 수 있다.
|
||||
* [[ACP (Agent Communication Protocol)]]
|
||||
* 연결 이유: IBM이 개발한 상위 수준의 의도(Intent) 통신 프로토콜로, 2025년에 A2A와 통합되어 에이전트 상호운용성 표준을 단일화했다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: "의도 전달(ACP) -> 작업 위임(A2A) -> 도구 실행(MCP)"으로 이어지는 다중 에이전트 시스템의 3계층 통신 추상화 모델.
|
||||
|
||||
#### [운영 및 거버넌스 프레임워크]
|
||||
* [[Zoned Governance Framework]]
|
||||
* 연결 이유: A2A를 통한 에이전트 간 위임 시 데이터 유출이나 권한 남용을 막기 위해 환경과 권한을 여러 존(Zone)으로 분리하고 제한하는 정책적 프레임워크가 요구된다.
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 높은 보안이 요구되는 에이전트가 낮은 권한의 에이전트를 호출하거나 그 반대의 상황이 발생할 때 요구되는 신뢰 경계(Trust Boundary) 설정 방법.
|
||||
|
||||
### Deeper Research Questions
|
||||
* A2A를 통해 전달된 원격 작업 위임 컨텍스트가 하네스 내부의 MCP 도구 권한(Permissions)으로 안전하게 매핑 및 변환되는 표준화된 구조는 어떻게 설계되어야 하는가?
|
||||
* HTTPS와 SSE를 사용하는 A2A의 높은 네트워크 지연 시간(50~200ms)을 완화하여, 에이전트 네트워크에서 실시간(Low-latency) 스트리밍 상호작용을 보장할 수 있는 대안적 전송 계층은 무엇인가?
|
||||
* 다중 하네스 배포 환경(Federated Multi-Harness Deployment)에서 A2A를 통한 에이전트 간 통신 중 발생할 수 있는 에이전트 간 프롬프트 인젝션(Cross-agent prompt injection) 공격을 하네스 계층에서 어떻게 탐지하고 격리하는가?
|
||||
* A2A 환경에서 다수의 에이전트가 공유 상태(Shared State)에 동시 접근할 때, 하네스 일관성(Consistency)과 충돌 해결을 관리하는 표준화된 S-component 인터페이스는 어떻게 구현될 수 있는가?
|
||||
* IETF draft-klrc-aiagent-auth와 같은 토큰 교환(Token Exchange) 사양은 A2A 기반의 에이전트 인증 및 권한 위임을 어떤 기술적 메커니즘을 통해 구현하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** CrewAI, Google ADK와 같은 오픈소스 에이전트 프레임워크에서 A2A 프로토콜을 도입하여 서로 다른 에이전트들이 Agent Card를 통해 상대방의 기능을 동적으로 검색하고 원격 작업을 위임하도록 구현할 수 있다.
|
||||
* **System Design:** 시스템 아키텍처 설계 시 프로토콜의 역할을 엄격히 분리하여, 로컬 도구 접근은 MCP로 처리하고 원격 에이전트 위임 및 비동기 작업 스트리밍은 A2A로 처리하는 모듈형 하네스 통신 스택을 구성한다.
|
||||
* **Operation / Maintenance:** A2A 호출 내역을 관찰(Observability)하고 로깅하여, 에이전트 간의 무한 위임 루프나 예기치 않은 우회 호출 패턴을 탐지하고 보안 거버넌스(Trust Boundaries)를 유지하는 감사(Audit) 인프라를 운영한다.
|
||||
|
||||
### Adjacent Topics
|
||||
* [[Multi-Agent Orchestration]]
|
||||
* 확장 방향: 다수의 에이전트를 조율하는 아키텍처 패턴(Hierarchical, Market-based, Role-Based 등)을 연구하여 A2A 통신이 실제 에이전트의 작업 분배 토폴로지와 어떻게 결합되는지 탐구한다.
|
||||
* [[Agent Identity Management]]
|
||||
* 확장 방향: 에이전트가 서로를 원격으로 호출할 때 필요한 식별 체계(Entra ID, OAuth2 토큰 위임 등)와 분산 시스템에서의 에이전트 인증 기술을 깊이 있게 확장하여 학습한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,46 @@
|
||||
# [[ACP (Agent Communication Protocol)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
ACP(Agent Communication Protocol)는 에이전트 간의 고수준 의도(High-level intent), 목표(Goals), 그리고 복잡한 협업 시퀀스를 정의하기 위해 설계된 통신 규약이다. 2025년 Google의 A2A(Agent-to-Agent Protocol)와 IBM의 기존 에이전트 프레임워크가 통합되면서 다중 에이전트 시스템의 상호운용성을 보장하는 핵심 표준으로 자리 잡았다. 단순한 데이터 전달을 넘어 에이전트 간의 '의도 파악'과 '동적 협상'을 가능하게 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **의도 기반 통신 추상화**: ACP는 메시지를 'Intent(의도)'와 'Action(행동)'으로 구조화한다. 이를 통해 에이전트는 상대방의 내부 로직을 알 필요 없이 "데이터 분석 보고서 작성 의도"와 같은 고수준의 목표를 공유하고 협업을 시작할 수 있다.
|
||||
* **A2A와의 통합 표준**: 초기에는 독립적인 프로토콜로 개발되었으나, 현재는 A2A의 작업 위임(Task Delegation) 메커니즘 위에서 작동하는 상위 계층 프레임워크 역할을 한다. "의도(ACP) -> 위임(A2A) -> 도구 실행(MCP)"으로 이어지는 3계층 통신 스택을 완성한다.
|
||||
* **동적 협상 및 재구성**: 에이전트가 제안된 작업에 대해 비용, 시간, 리소스 가용성을 바탕으로 역제안(Counter-proposal)을 하거나 거절할 수 있는 협상 인터페이스를 제공한다. 이는 동적인 멀티 에이전트 오케스트레이션을 가능하게 하는 핵심 요소이다.
|
||||
* **보안 및 신뢰 모델**: 에이전트 간의 신뢰 등급(Trust Level)을 정의하고, 높은 보안 등급의 작업 요청 시 추가적인 증명(Proof-of-capability)을 요구하는 거버넌스 기능을 포함한다.
|
||||
* **상태 추적 및 컨텍스트 공유**: 다중 에이전트 간의 대화 이력과 작업 상태를 공유 컨텍스트 윈도우(Shared Context Window) 형태로 관리하여, 협업 과정에서 발생하는 정보의 파편화를 방지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **추상화 오버헤드**: 고수준의 의도를 정의하고 해석하는 과정에서 단순 API 호출보다 더 많은 토큰과 추론 시간이 소모될 수 있다. 매우 단순한 작업에는 과도한 프로토콜 설계가 될 수 있다.
|
||||
* **의도 해석의 모호성**: LLM 기반 에이전트들이 서로의 의도를 해석할 때 미묘한 의미 차이(Semantic gap)로 인해 오해가 발생할 수 있으며, 이는 복잡한 협업 체인에서 예기치 않은 오류로 이어질 수 있다.
|
||||
* **구현 복잡성**: ACP를 완벽히 지원하기 위해서는 하네스 수준에서 복잡한 상태 머신과 협상 로직을 갖추어야 하므로, 초기 시스템 구축 비용이 높다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [통신 및 상호운용성]
|
||||
* [[A2A (Agent-to-Agent Protocol)]]
|
||||
* 연결 이유: ACP가 고수준의 협업 의도를 다룬다면, A2A는 실제 작업의 실행 위임과 데이터 스트리밍을 담당하는 하위 전송/실행 계층이다.
|
||||
* [[MCP (Model Context Protocol)]]
|
||||
* 연결 이유: 에이전트가 ACP를 통해 협업을 결정하고 A2A로 작업을 위임받은 후, 실제 시스템 도구를 호출할 때 사용하는 가장 하위의 도구 접근 표준이다.
|
||||
|
||||
#### [실행 및 거버넌스]
|
||||
* [[Multi-Agent Orchestration]]
|
||||
* 연결 이유: ACP는 다중 에이전트 환경에서 에이전트들이 스스로 역할을 분담하고 목표를 달성하기 위해 소통하는 '언어' 역할을 한다.
|
||||
* [[Agent Identity Management]]
|
||||
* 연결 이유: 안전한 ACP 통신을 위해서는 메시지를 보내는 에이전트의 신원과 권한을 명확히 검증할 수 있는 신뢰 기반의 인증 시스템이 선행되어야 한다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 서로 다른 모델(예: Claude vs GPT)을 사용하는 에이전트 간에 ACP Intent 명세의 의미적 일관성(Semantic Consistency)을 어떻게 보장할 수 있는가?
|
||||
* ACP의 협상 과정에서 발생할 수 있는 교착 상태(Deadlock)나 무한 루프를 방지하기 위해 하네스는 어떤 타임아웃 및 정책 게이트를 두어야 하는가?
|
||||
* 복잡한 의도를 전달할 때 발생하는 토큰 소모를 최적화하기 위해 ACP 메시지를 압축하거나 정형화된 스키마로 변환하는 가장 효율적인 방법은 무엇인가?
|
||||
* ACP 기반의 협업 시스템에서 특정 에이전트의 오작동이 전체 에이전트 체인의 목표를 하이재킹하는 것을 막기 위한 '협업 무결성 검증' 모델은 어떻게 설계되어야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 복잡한 소프트웨어 엔지니어링 프로젝트에서 기획 에이전트, 코딩 에이전트, 리뷰 에이전트가 ACP를 통해 작업의 우선순위를 협상하고 피드백을 주고받는 워크플로우를 구축한다.
|
||||
* **System Design:** 엔터프라이즈급 에이전트 플랫폼 설계 시, 외부 파트너사의 에이전트와 우리 시스템의 에이전트가 안전하게 협업할 수 있도록 ACP를 표준 인터페이스로 채택한다.
|
||||
* **Operation:** 에이전트 간의 ACP 메시지 로그를 분석하여 협업 병목 지점을 찾고, 에이전트들의 '협업 지능'을 개선하기 위한 강화 학습 데이터로 활용한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,36 @@
|
||||
# [[Adaptive Context Compaction (적응형 컨텍스트 압축)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Adaptive Context Compaction은 에이전트의 현재 작업 상태, 토큰 소모량, 그리고 모델의 성능 유지 능력을 실시간으로 평가하여, 컨텍스트 윈도우 내의 정보를 동적으로 압축하거나 제거하는 최적화 기술이다. 모든 정보를 동일하게 요약하는 대신, 작업에 결정적인 정보는 원본을 유지하고 부수적인 정보는 고도로 압축하는 '가변적 압축률'을 적용하는 것이 핵심이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **가변적 요약 (Variable-rate Summarization)**: 현재 진행 중인 작업(WTM)과 관련된 대화는 상세히 유지하고, 이미 완료된 단계나 단순 정보 탐색 로그는 한 문장으로 압축한다.
|
||||
* **증거 보존 정책 (Evidence Retention)**: 실제 읽은 파일 내용이나 실행 결과(Evidence Memory) 중 핵심 수치나 코드는 압축 대상에서 제외하여 정보의 구체성(Concreteness)을 유지한다.
|
||||
* **동적 슬라이딩 윈도우**: 단순히 오래된 순으로 삭제하는 것이 아니라, 작업의 인과 관계(Causal Chain)를 분석하여 중요도가 낮은 과거 블록을 선택적으로 폐기한다.
|
||||
* **의도 추출 (Intent Extraction)**: 대화 이력을 그대로 요약하기보다 "사용자가 A를 요청했고 에이전트가 B를 제안하여 최종적으로 C로 결정함"과 같이 의도와 결정 사항 중심으로 지식을 추출한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **추론 부하**: 압축 결정을 내리고 실제 압축을 수행하는 과정에서 모델의 지능을 사용하므로, 잦은 압축은 시스템 반응 속도를 늦출 수 있다.
|
||||
* **복구 불가능성**: 압축 과정에서 버려진 세부 정보가 나중에 필요해질 경우, 다시 원본을 조회하거나 재작성해야 하는 비용이 발생한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: 압축 기술은 컨텍스트 엔지니어링을 구현하는 핵심 수단이다.
|
||||
* [[Summary Drift]]
|
||||
* 연결 이유: 과도하거나 반복적인 압축은 정보의 왜곡을 초래할 수 있다.
|
||||
* [[Inference-Coupled Persistence]]
|
||||
* 연결 이유: 압축된 정보를 영구 저장소에 저장하여 향후 세션에서 재활용한다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 작업의 '중요도'를 모델이 판단하게 할 때, 편향이나 누락 없이 평가하게 만드는 가이드라인(Persona)은 무엇인가?
|
||||
* 압축 전후의 작업 성공률을 비교하여 최적의 압축 시점(Compression Trigger)을 결정하는 강화 학습 모델을 설계할 수 있는가?
|
||||
* 압축된 지식과 원본 지식 간의 계층적 구조를 만들어, 필요할 때만 원본을 불러오는 '페이징(Paging)' 시스템은 어떻게 구현하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 하네스의 C-component에서 토큰 사용량이 70%를 넘을 때 자동으로 '압축 에이전트'를 호출하여 이력을 정제한다.
|
||||
* **System Design:** 에이전트가 "이 부분은 나중에 다시 필요할 것 같아"라고 표시(Marking)한 컨텍스트 블록은 압축 우선순위에서 제외하는 태그 시스템을 구축한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,40 @@
|
||||
# [[Agent Identity Management (에이전트 신원 관리)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Agent Identity Management는 다중 에이전트 환경에서 각 에이전트의 고유한 신원(Identity), 역할(Persona), 그리고 부여된 권한(Authorization)을 정의하고 관리하는 시스템이다. 에이전트가 누구를 대리하여 작업하는지, 어떤 도구에 접근할 수 있는지, 그리고 행동에 대한 책임(Accountability)을 누구에게 물을 것인지를 명확히 하는 보안 및 거버넌스의 기초이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **신원 식별자 (Identifiers)**: 개별 에이전트에게 부여되는 고유 ID, 이름, 그리고 신원을 증명할 수 있는 토큰이나 인증서(SPIFFE ID, Entra Agent ID 등)를 관리한다.
|
||||
* **역제 및 페르소나 (Persona)**: 에이전트가 수행해야 할 직무(예: Planner, Researcher, Writer)와 그에 따른 태도, 지식 범위, 제약 사항을 정의한다. 이는 **'Agent Card'**라는 정형화된 명세로 표현되기도 한다.
|
||||
* **권한 위임 모델 (Authorization)**:
|
||||
* **사용자 대리 (On-behalf-of)**: 사용자의 권한을 에이전트가 위임받아 수행. (사용자별 데이터 격리 필요)
|
||||
* **서비스 계정 (Service Principal)**: 에이전트 전용 계정으로 시스템 자원에 접근.
|
||||
* **책임 추적성 (Accountability)**: 모든 행동, 결정, 도구 호출 기록에 에이전트 신원 메타데이터를 포함하여 불변의 감사 로그(Audit Log)를 생성한다.
|
||||
* **신원 기반 격리**: 에이전트 신원에 따라 컨텍스트 윈도우, 메모리 저장소, 네트워크 존(Zone)을 분리하여 정보 유출이나 상호 오염을 방지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **관리 복잡성**: 에이전트 수가 많아질수록 각각의 신원과 권한을 세밀하게 관리하는 운영 부담이 증가한다.
|
||||
* **신원 스푸핑 (Identity Spoofing)**: 악의적인 에이전트나 프롬프트 인젝션이 다른 에이전트의 신원을 도용하여 권한을 탈취할 위험이 있다.
|
||||
* **성능 저하**: 모든 도구 호출 시마다 신원을 검증하고 권한을 확인하는 과정에서 지연 시간이 발생할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: 하네스의 L-component가 실질적으로 신원 기반 정책을 집행한다.
|
||||
* [[Agent Card]]
|
||||
* 연결 이유: 에이전트의 신원과 능력을 외부로 노출하고 검색 가능하게 만드는 표준 규격이다.
|
||||
* [[Governance & Reliability]]
|
||||
* 연결 이유: 신원 관리는 신뢰할 수 있는 에이전트 시스템 구축의 필수 요건이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트 간 통신(A2A) 시, 호출하는 에이전트의 권한 범위를 호출받는 에이전트에게 안전하게 상속(Authorization Inheritance)하는 표준 프로토콜은 무엇인가?
|
||||
* 인간 사용자가 부재한 상황에서 에이전트가 자율적으로 내린 결정에 대한 '법적 신원(Legal Identity)'과 책임 소재는 어떻게 정의되는가?
|
||||
* 프롬프트 수준의 페르소나 설정과 시스템 수준의 신원 인증을 어떻게 기술적으로 결합하여 보안 무결성을 확보할 것인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** OAuth 2.0의 Client Credentials Flow나 OIDC를 활용하여 에이전트별 액세스 토큰을 발급하고 관리한다.
|
||||
* **System Design:** 에이전트 레지스트리(Agent Registry)를 구축하여, 사용자가 필요한 페르소나와 권한을 가진 에이전트를 검색하고 즉시 소환(Spawn)할 수 있는 아키텍처를 설계한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,42 @@
|
||||
# [[Agent Memory System (에이전트 메모리 시스템)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Agent Memory System은 에이전트가 런타임 중에 획득한 정보, 사용자의 선호도, 현재 작업의 상태, 그리고 과거의 성공/실패 경험을 체계적으로 저장하고 관리하는 다층 메모리 아키텍처이다. 메모리 시스템은 에이전트가 단기적인 문맥 유지(Context)를 넘어, 장기적인 학습과 성장을 가능하게 하는 핵심 지식 기반(Knowledge Base) 역할을 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **다층 메모리 구조 (Layered Memory)**:
|
||||
* **Short-Term Memory (STM)**: 현재 턴과 직전 요청의 핵심 제약사항을 유지. (RAM 역할)
|
||||
* **Working Task Memory (WTM)**: 활성화된 미션의 목표, 진행 단계, 추출된 증거를 관리.
|
||||
* **Long-Term Memory (LTM)**: 사용자 선호, 프로젝트 규칙, 반복되는 설계 철학을 영구 보존. (Disk 역할)
|
||||
* **Evidence Memory (EM)**: 실제 읽은 파일, 실행 로그 등 검증된 사실만을 격리 저장.
|
||||
* **워크플로우 메모리 (AWM)**: 개별 에이전트의 기억을 넘어, 여러 에이전트가 협업하는 워크플로우 전체의 상태와 결과물을 공유하고 동기화한다.
|
||||
* **추론 결합 지속성 (Inference-Coupled Persistence)**: 모델이 작업을 마친 후 스스로 성공 여부를 분석하고, 향후 재사용 가능한 '스킬'이나 '에피소드'로 요약하여 저장소에 기록한다.
|
||||
* **메모리 인덱싱 및 검색 (RAG)**: 방대한 메모리 중 현재 작업에 가장 관련성 높은 정보를 벡터 검색(Vector Search)이나 키워드 검색을 통해 컨텍스트에 주입한다.
|
||||
* **망각 및 정제 (Compaction)**: 오래되거나 가치가 낮은 정보를 삭제하거나 압축하여 메모리 블로트(Memory Bloat)를 방지하고 검색 효율을 높인다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **메모리 중독 (Memory Poisoning)**: 잘못된 정보나 악의적인 데이터가 메모리에 기록될 경우, 이후 모든 세션의 판단에 악영향을 미칠 수 있다.
|
||||
* **검색 노이즈**: 메모리가 너무 커지면 관련 없는 정보가 검색되어 모델의 컨텍스트를 오염시킬 수 있다.
|
||||
* **동기화 오버헤드**: 여러 에이전트나 세션 간에 메모리를 실시간으로 동기화하는 과정에서 성능 저하와 데이터 충돌이 발생할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Inference-Coupled Persistence]]
|
||||
* 연결 이유: 메모리를 생성하고 영구화하는 핵심 기전이다.
|
||||
* [[S-component (State Store)]]
|
||||
* 연결 이유: 메모리 시스템이 실제로 데이터를 저장하는 하네스의 구성 요소이다.
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: 저장된 메모리 중 어떤 정보를 컨텍스트에 넣을지 결정하는 전략이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 자신의 실수를 분석하여 '부정적 지식(Negative Knowledge)'을 메모리에 저장하고 이를 회피하는 로직은 어떻게 설계해야 하는가?
|
||||
* 메모리의 신뢰도(Confidence Score)를 실시간으로 업데이트하여, 시간이 지남에 따라 정보의 가중치를 조절하는 알고리즘은 무엇인가?
|
||||
* 메모리에 저장된 지식이 최신 프로젝트 상태와 충돌할 때(Obsolescence), 이를 자동으로 감지하고 폐기하는 메커니즘은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** VS Code 확장 프로그램에서 세션 종료 시 현재 작업의 핵심 결과를 `AgentMemoryState` 객체로 직렬화하여 로컬 파일에 저장하고, 재시작 시 이를 복구한다.
|
||||
* **System Design:** 에이전트 간 메모리 공유를 위해 중앙 집중형 벡터 DB를 구축하고, 각 에이전트가 공유된 지식 베이스 위에서 독립적으로 사고하도록 설계한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,44 @@
|
||||
# [[Agentic Orchestration (에이전트 오케스트레이션)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Agentic Orchestration은 복잡한 목표를 달성하기 위해 여러 전문화된 에이전트들의 실행 순서, 데이터 흐름, 역할 분담, 그리고 상호작용을 체계적으로 조율하고 관리하는 기술적 방법론이다. 단일 에이전트의 한계를 넘어, 에이전트 간의 협업 토폴로지(Topology)를 설계하고 실행 루프를 동기화하여 시스템 전체의 지능과 안정성을 극대화하는 것이 목적이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **주요 협업 패턴 (Orchestration Patterns)**:
|
||||
* **계층형 (Hierarchical)**: '관리자 에이전트'가 목표를 분해하고 여러 '서브 에이전트'에게 작업을 할당 및 검토하는 구조.
|
||||
* **순차형 (Sequential/Chain)**: 작업 결과가 다음 에이전트의 입력으로 전달되는 파이프라인 구조.
|
||||
* **협업형 (Joint Collaboration)**: 공용 칠판(Blackboard)이나 공유 메모리를 통해 여러 에이전트가 동시에 문제를 해결하는 구조.
|
||||
* **동적 라우팅 (Dynamic Routing)**: 작업의 성격에 따라 가장 적합한 에이전트에게 작업을 실시간으로 배정.
|
||||
* **조율 메커니즘 (Coordination)**:
|
||||
* **[[ACP (Agent Communication Protocol)]]**: 에이전트 간의 의도와 목표를 공유하는 표준 언어.
|
||||
* **[[A2A (Agent-to-Agent Protocol)]]**: 원격 하네스 간의 작업 위임 및 데이터 스트리밍 표준.
|
||||
* **Shared Context Window**: 여러 에이전트가 동일한 작업 맥락을 공유하고 업데이트하는 기술.
|
||||
* **상태 동기화 및 일관성**: 여러 에이전트가 동시에 공유 자원을 수정할 때 발생하는 충돌을 해결하고, 전체 워크플로우의 진행 상태(AWM)를 일관되게 유지한다.
|
||||
* **에러 전파 및 복구**: 특정 에이전트의 실패가 전체 시스템의 중단으로 이어지지 않도록 예외 처리와 재시도 전략을 오케스트레이션 계층에서 관리한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **오케스트레이션 Tax**: 에이전트 간 소통과 조율에 추가적인 토큰과 시간이 소모되어 단일 에이전트보다 느려질 수 있다.
|
||||
* **복잡한 디버깅**: 여러 에이전트의 상호작용 결과로 발생한 오류의 근본 원인(Root Cause)을 찾아내는 것이 매우 어렵다.
|
||||
* **메시지 폭발**: 에이전트 간 불필요한 소통이 늘어나면 시스템 부하가 급증하고 컨텍스트 부패가 가속화된다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: 개별 에이전트의 실행은 하네스가, 하네스 간의 연결은 오케스트레이션이 담당한다.
|
||||
* [[ACP (Agent Communication Protocol)]]
|
||||
* 연결 이유: 오케스트레이션의 성공을 위한 기술적 통신 기반이다.
|
||||
* [[Multi-Agent Coordination]]
|
||||
* 연결 이유: 오케스트레이션을 구현하기 위한 구체적인 협업 알고리즘이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트들이 스스로 최적의 협업 구조를 결정하고 재구성하는 '자기 조직화(Self-organizing)' 오케스트레이션은 가능한가?
|
||||
* 수백 개의 에이전트가 참여하는 대규모 에이전트 생태계에서 교착 상태(Deadlock)를 방지하기 위한 분산 제어 알고리즘은 무엇인가?
|
||||
* 오케스트레이션 과정에서 발생하는 에이전트 간의 '의견 충돌'을 논리적으로 해결하기 위한 중재(Arbitration) 모델은 어떻게 설계해야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** LangGraph의 StateGraph를 활용하여 에이전트 간의 상태 전이와 조건부 분기를 정의하고 관리한다.
|
||||
* **System Design:** 엔터프라이즈 환경에서 마이크로서비스 아키텍처(MSA)와 유사하게 에이전트를 독립적으로 배포하고, 이벤트 버스(Kafka 등)를 통해 조율하는 '에이전트 메시지 버스'를 구축한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,44 @@
|
||||
# [[Context Engineering (컨텍스트 엔지니어링)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Context Engineering은 LLM의 제한된 컨텍스트 윈도우를 효율적으로 관리하고, 에이전트의 작업 성능을 극대화하기 위해 입력 데이터(프롬프트, 외부 지식, 도구 출력 등)를 정교하게 설계, 압축, 우선순위화하는 기술적 방법론이다. 단순한 텍스트 작성을 넘어, 하네스(Harness) 계층에서 데이터의 흐름을 제어하고 모델의 주의력(Attention)을 핵심 정보에 집중시키는 시스템 수준의 최적화를 의미한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **프롬프트 엔지니어링과의 차이**: 프롬프트 엔지니어링이 개별 메시지의 '표현'에 집중한다면, 컨텍스트 엔지니어링은 전체 대화와 작업 세션의 '데이터 구조'와 '흐름'을 설계한다. 하네스의 C-component가 담당하는 핵심 영역이다.
|
||||
* **적응형 컨텍스트 압축 (Adaptive Compression)**: 작업의 중요도와 모델의 컨텍스트 한계에 따라 데이터를 동적으로 요약하거나 압축한다. 중요도가 낮은 과거 이력은 버리고, 핵심 결정 사항과 현재 상태(WTM)만을 보존한다.
|
||||
* **컨텍스트 부패 (Context Rot) 방지**: 대화가 길어질수록 모델의 추론 성능이 저하되는 현상을 막기 위해, 주기적으로 컨텍스트를 청소(Cleanup)하고 필수 정보만을 재구성(Re-summarization)한다.
|
||||
* **우선순위 기반 인젝션 (Priority Injection)**: 사용자 메시지, 확인된 증거(Evidence Memory), 장기 메모리(LTM) 순으로 정보의 우선순위를 설정하고, 가장 중요한 정보가 컨텍스트의 핵심 위치(주로 최하단)에 배치되도록 조정한다.
|
||||
* **아티팩트 오프로딩 (Artifact Offloading)**: 대규모 코드나 로그 데이터를 모델 컨텍스트에 직접 넣는 대신, 별도의 파일 시스템(Artifact Store)에 저장하고 모델에게는 해당 리소스의 요약본과 참조 ID만을 제공한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **정보 손실의 위험**: 압축이나 요약 과정에서 모델이 작업을 수행하는 데 필수적인 세부 정보(Nuance)가 누락될 수 있다.
|
||||
* **추론 지연 및 비용**: 컨텍스트를 요약하거나 재구성하는 과정 자체가 별도의 모델 호출을 필요로 하므로, 실시간성 저하와 토큰 비용 증가가 발생한다.
|
||||
* **요약 편향 (Summary Drift)**: 여러 번의 요약 과정을 거치면서 원본 데이터의 의도가 왜곡되거나 중요한 사실 관계가 변질될 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [하네스 아키텍처]
|
||||
* [[C-component (Context Manager)]]
|
||||
* 연결 이유: 컨텍스트 엔지니어링이 수행되는 실질적인 런타임 구성 요소이다.
|
||||
* [[S-component (State Store)]]
|
||||
* 연결 이유: 장기적인 상태를 저장하고, 필요할 때 컨텍스트로 불러오는 과정에서 긴밀하게 협업한다.
|
||||
|
||||
#### [성능 및 최적화]
|
||||
* [[Context Rot]]
|
||||
* 연결 이유: 컨텍스트 엔지니어링의 주요 목표 중 하나가 컨텍스트 부패를 방어하는 것이다.
|
||||
* [[Adaptive Context Compaction]]
|
||||
* 연결 이유: 컨텍스트 엔지니어링에서 사용하는 핵심 기술 중 하나이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 Attention 패턴을 실시간으로 분석하여, 어떤 정보를 컨텍스트에서 제거해도 성능 저하가 없는지 정량적으로 측정할 수 있는가?
|
||||
* 요약 편향(Summary Drift)을 방지하기 위해 원본 컨텍스트와 요약본 간의 의미적 유사성(Semantic Similarity)을 검증하는 자동화된 게이트는 어떻게 설계해야 하는가?
|
||||
* 다중 에이전트 환경에서 각 에이전트에게 필요한 최소한의 컨텍스트(Minimal Viable Context)를 동적으로 결정하는 최적화 알고리즘은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 롱-호라이즌(Long-horizon) 작업을 수행하는 에이전트에서 50턴 이상의 대화 이력을 3개 이내의 핵심 아티팩트 요약으로 압축하여 토큰 소모를 80% 절감한다.
|
||||
* **System Design:** 하네스 설계 시 C-component를 독립적인 모듈로 분리하여, 모델의 종류나 컨텍스트 윈도우 크기에 따라 서로 다른 압축 전략을 적용할 수 있게 한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,36 @@
|
||||
# [[Context Rot (컨텍스트 부패)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Context Rot(컨텍스트 부패)는 대화나 작업 세션이 길어짐에 따라 LLM의 컨텍스트 윈도우 내에 불필요한 정보, 중복된 로그, 모호한 지시사항이 누적되어 모델의 추론 정확도와 지시 준수 능력이 급격히 저하되는 현상을 의미한다. 에이전트가 이전의 제약 조건을 잊거나, 실제 확인되지 않은 사실을 가정하거나, 일반론적인 답변으로 흐르는 주요 원인이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **주의력 분산 (Attention Decay)**: 컨텍스트가 길어질수록 모델은 '중간 부분'의 정보보다 '처음과 끝'의 정보에 더 집중하는 경향(Lost in the Middle)이 있으며, 이는 복잡한 맥락 유지에 장애가 된다.
|
||||
* **노이즈 누적**: 도구의 대량 출력물(로그, 파일 내용), 모델의 반복적인 사고 과정(Thought), 불필요한 사담 등이 컨텍스트를 채우면서 실질적인 작업 목표가 희석된다.
|
||||
* **요약 편향 (Summary Drift)**: 컨텍스트 부패를 막기 위해 요약을 반복할 때, 매 회차마다 정보의 손실과 왜곡이 발생하여 결국 원본 의도와 다른 상태로 전이되는 현상이다.
|
||||
* **상태 불일치**: 메모리 시스템(STM, WTM)과 실제 컨텍스트 내의 정보가 동기화되지 않아 에이전트가 혼란을 겪는 상태이다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **비용과 성능의 충돌**: 컨텍스트 부패를 막기 위해 자주 정리(Cleanup)하면 모델 호출 횟수와 비용이 증가하고, 정리하지 않으면 추론 실패로 인한 재작업 비용이 발생한다.
|
||||
* **세부 정보의 손실**: 노이즈라고 판단하여 제거한 정보가 사실은 향후 작업의 결정적인 단서(Edge case)일 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: 컨텍스트 부패를 해결하기 위한 기술적 대응 체계이다.
|
||||
* [[Adaptive Context Compaction]]
|
||||
* 연결 이유: 부패된 컨텍스트를 정제하고 압축하는 구체적인 기법이다.
|
||||
* [[Summary Drift]]
|
||||
* 연결 이유: 컨텍스트 부패 해결 과정(요약)에서 발생하는 부작용이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델별로 컨텍스트 부패가 시작되는 임계점(Token Threshold)을 자동으로 탐지할 수 있는 지표는 무엇인가?
|
||||
* 컨텍스트 내에서 '핵심 결정 사항'과 '일시적 노이즈'를 구분하는 고성능 필터링 알고리즘은 어떻게 설계해야 하는가?
|
||||
* 부패된 컨텍스트를 복구하기 위해 원본 로그(Raw Evidence)를 다시 검색하여 주입하는 '리프레시 워크플로우'의 효율성은 어느 정도인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 에이전트가 20턴 이상 진행했을 때, 현재까지의 '확정된 사실'과 '남은 작업'만을 추출하여 컨텍스트를 전면 재구성(Refresh)한다.
|
||||
* **System Design:** 하네스 계층에서 컨텍스트 크기를 실시간 모니터링하여, 부패 임계치에 도달하기 전 자동 요약 훅(L-component)을 실행한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,40 @@
|
||||
# [[Foundational LLM Concepts (LLM 기초 개념)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Foundational LLM Concepts는 에이전틱 시스템의 두뇌 역할을 하는 대규모 언어 모델(LLM)의 본질적인 특성, 아키텍처적 한계, 그리고 에이전트 구축 시 고려해야 할 핵심 원리를 다룬다. 모델의 확률론적 특성과 컨텍스트 처리 방식에 대한 깊은 이해는 신뢰할 수 있는 에이전트 하네스를 설계하는 데 필수적인 기초 지식이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **LLM의 본질적 특성**:
|
||||
* **확률론적 생성 (Probabilistic Generation)**: 다음 단어를 확률에 기반하여 선택하므로 동일한 입력에도 결과가 달라질 수 있는 비결정성(Non-determinism)을 가짐.
|
||||
* **컨텍스트 윈도우 (Context Window)**: 한 번에 처리할 수 있는 정보의 양이 제한되어 있으며, 이를 초과하면 이전 정보를 망각하거나 성능이 저하됨.
|
||||
* **Long-context Models**: 백만 토큰 이상의 방대한 컨텍스트를 지원하는 최신 모델들(Gemini 1.5, GPT-4o 등)의 특성과 에이전틱 워크플로우에 미치는 영향.
|
||||
* **비결정성 (Non-determinism) 제어**: 확률적인 모델의 출력을 시스템적으로 통제하기 위해 온도(Temperature) 조절, Top-p 설정, 그리고 하네스 계층의 결정론적 검증 게이트를 활용하는 기법.
|
||||
* **토큰 경제학 (Token Economics)**: 입력과 출력 토큰의 비용과 추론 속도(Latency) 사이의 트레이드오프를 최적화하여 경제적인 시스템 구축.
|
||||
* **모델 정렬 (Alignment)**: 모델이 인간의 의도와 가치관에 부합하도록 학습(RLHF 등)된 정도와, 이것이 에이전트의 지시 준수 능력에 미치는 영향.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **추론 성능 vs 속도**: 모델의 크기가 커질수록 지능은 높아지지만 반응 속도는 느려지고 비용은 증가한다.
|
||||
* **컨텍스트 크기 vs 집중력**: 컨텍스트 윈도우가 커져도 모델이 중간에 위치한 정보에 소홀해지는 'Lost in the Middle' 현상은 여전히 존재할 수 있다.
|
||||
* **창의성 vs 신뢰성**: 모델의 자유도를 높이면 창의적인 해결책이 나오지만, 동시에 환각(Hallucination)과 오류의 위험도 함께 증가한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Reasoning & Planning]]
|
||||
* 연결 이유: LLM의 기초적인 추론 능력을 바탕으로 복잡한 계획 수립 능력이 구축된다.
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: LLM의 컨텍스트 윈도우 한계를 기술적으로 극복하기 위한 방법론이다.
|
||||
* [[Agentic AI Security]]
|
||||
* 연결 이유: LLM의 취약점(인젝션 등)을 방어하는 보안 체계와 직결된다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 '파라미터 지식'과 '컨텍스트 지식'이 에이전트의 최종 판단에서 각각 어느 정도의 비중을 차지하는지 정량적으로 측정할 수 있는가?
|
||||
* 특정 도메인(코딩, 법률, 의료)에 특화된 소형 모델(SLM)이 대형 모델(LLM)보다 에이전트 하네스 내부에서 더 효율적으로 작동할 수 있는 조건은 무엇인가?
|
||||
* 모델의 비결정성을 역으로 활용하여, 여러 번의 독립적인 추론을 수행하고 합의를 도출하는 '앙상블 추론'의 효과는 어떠한가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 작업의 난이도에 따라 저렴하고 빠른 모델(GPT-4o mini)과 강력하지만 비싼 모델(Claude 3.5 Sonnet)을 혼합하여 사용하는 하이브리드 모델 아키텍처를 설계한다.
|
||||
* **System Design:** 에이전트의 답변 일관성을 높이기 위해 `seed` 값을 고정하거나, 중요한 로직에서는 `temperature=0`으로 설정하여 결정론적 답변을 유도한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,38 @@
|
||||
# [[GraphRAG & Knowledge Graph Memory (지식 그래프 메모리)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
GraphRAG는 전통적인 벡터 기반 RAG의 한계를 극복하기 위해, 지식을 엔티티(Entity)와 그들 간의 관계(Relationship)로 이루어진 그래프 구조로 구축하고 탐색하는 진화된 검색 및 메모리 기술이다. 에이전트가 단편적인 정보를 찾는 것을 넘어, 복잡한 인과 관계, 도메인의 전체적인 맥락, 그리고 다단계(Multi-hop) 추론이 필요한 지식을 효과적으로 활용할 수 있게 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **벡터 RAG와의 차이**: 벡터 RAG가 '의미적 유사성'을 기반으로 조각난 텍스트를 찾는다면, GraphRAG는 '논리적 연결성'을 기반으로 지식의 망(Mesh)을 탐색한다.
|
||||
* **엔티티 및 관계 추출 (Indexing)**: 비정형 데이터(문서)로부터 핵심 개념(노드)과 그들 사이의 관계(엣지)를 추출하여 지식 그래프를 생성한다.
|
||||
* **커뮤니티 요약 (Community Summarization)**: 그래프 내의 밀접하게 연결된 노드 그룹(커뮤니티)을 식별하고, 각 그룹의 상위 맥락을 요약하여 대규모 데이터셋에 대한 하향식(Top-down) 이해를 제공한다.
|
||||
* **다단계 추론 (Multi-hop Retrieval)**: "A의 특징이 B에게 미치는 영향은?"과 같은 질문에 대해 A -> 연결고리 -> B로 이어지는 경로를 추적하여 답변의 근거를 마련한다.
|
||||
* **지식 그래프 메모리 (S-component)**: 에이전트의 작업 이력을 단순 로그가 아닌 그래프 구조로 기록함으로써, 과거의 결정이 현재 작업에 미치는 복잡한 영향력을 추적하기 용이하게 한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **구축 오버헤드**: 지식 그래프를 생성하고 유지하는 과정(ETL)에서 벡터 임베딩보다 훨씬 많은 추론 자원과 비용이 소모된다.
|
||||
* **복잡한 스키마 설계**: 도메인에 맞는 적절한 노드와 관계의 종류(Ontology)를 정의하는 과정에서 인간의 설계 역량이 요구될 수 있다.
|
||||
* **조회 지연**: 그래프 순회(Traversal)와 하이브리드 검색(Vector + Graph)을 수행하는 과정에서 답변 생성 시간이 길어질 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Retrieval-Augmented Generation (RAG)]]
|
||||
* 연결 이유: GraphRAG는 RAG 기술의 고급 진화 형태이다.
|
||||
* [[Agent Memory System]]
|
||||
* 연결 이유: 그래프 구조는 에이전트의 복잡한 상태와 지식을 저장하는 가장 강력한 S-component 구현 방식 중 하나이다.
|
||||
* [[Semantics & Ontology]]
|
||||
* 연결 이유: 그래프를 설계하고 해석하는 학문적/기술적 토대이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 실행 도중 지식 그래프에 새로운 노드와 관계를 실시간으로 추가할 때 발생하는 '지식 일관성' 문제를 어떻게 해결할 것인가?
|
||||
* 수백만 개의 노드를 가진 그래프에서 현재 질문과 가장 관련 있는 '서브그래프(Subgraph)'만을 효율적으로 추출하는 알고리즘은 무엇인가?
|
||||
* 자연어 질문을 그래프 쿼리(Cypher, Gremlin)로 변환하는 과정에서 발생하는 모호성을 최소화하는 프롬프트 전략은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** Neo4j나 PuppyGraph와 같은 그래프 DB를 활용하여 지식 베이스를 구축하고, 에이전트가 이를 쿼리할 수 있는 도구를 제공한다.
|
||||
* **System Design:** 대규모 소프트웨어 프로젝트 분석 시, 파일 간의 의존성, 함수 호출 관계, 클래스 계층 구조를 지식 그래프로 만들어 에이전트가 전체 구조를 파악하며 코딩하게 한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -1,28 +1,40 @@
|
||||
# [[Human-in-the-Loop (HITL)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Human-in-the-Loop(HITL)는 AI 에이전트의 자율적 실행 과정 중 특정 지점에서 인간의 개입(개입, 승인, 피드백, 중단)을 필수적으로 결합하여 시스템의 안전성, 정확성, 그리고 윤리적 적합성을 보장하는 운영 모델이다. 에이전트의 지능적 한계를 인간의 판단력으로 보완하고, 중대한 결정에 대한 책임을 명확히 하는 거버넌스의 핵심 장치이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **개입 유형 (Interaction Modes)**:
|
||||
* **Human-in-the-Loop**: 모든 중대 단계에서 인간의 명시적 승인(Approve)이 있어야 다음 단계로 진행.
|
||||
* **Human-on-the-Loop (HOTL)**: 에이전트가 자율적으로 실행되지만, 인간이 실시간으로 모니터링하며 필요할 때만 즉시 개입(Override)하거나 중단(Kill-switch).
|
||||
* **Human-out-of-the-Loop**: 인간의 개입 없이 완전히 자율적으로 실행. (저위험 반복 작업에 적용)
|
||||
* **승인 게이트 (Approval Gates)**: 파일 삭제, 금융 결제, 이메일 발송 등 외부 세계에 영구적인 영향을 끼치는 도구 호출 전에는 반드시 인간의 승인을 요구하도록 하네스 계층에서 강제한다.
|
||||
* **피드백 루프 (Feedback Loops)**: 작업 중간 결과물에 대해 인간이 "이 방향은 아니야", "수정해줘"와 같은 피드백을 주면 에이전트가 이를 컨텍스트에 반영하여 계획을 수정한다.
|
||||
* **승인 피로 (Approval Fatigue)**: 너무 잦은 승인 요청은 인간 관리자의 주의력을 떨어뜨려 위험한 명령을 무비판적으로 승인하게 만들 수 있다. 이를 방지하기 위해 **Progressive Disclosure**(필요할 때만 정보 노출) 기법을 사용한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **자율성과 통제의 충돌**: 인간의 개입이 많아질수록 시스템의 자동화 효율(Speed & Scalability)이 급격히 저하된다.
|
||||
* **병목 현상**: 인간 관리자의 가용성에 따라 에이전트의 전체 작업 속도가 결정되는 '인간 병목'이 발생한다.
|
||||
* **책임 전가**: 에이전트의 제안을 인간이 승인했을 때, 결과에 대한 책임을 누구에게 물을 것인지에 대한 법적/윤리적 모호함이 존재한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agentic Governance]]
|
||||
* 연결 이유: HITL은 거버넌스를 실현하는 가장 직접적인 기술적 수단이다.
|
||||
* [[L-component (Lifecycle Hooks)]]
|
||||
* 연결 이유: 하네스에서 승인 게이트와 피드백 인터페이스를 구현하는 계층이다.
|
||||
* [[Approval Fatigue]]
|
||||
* 연결 이유: HITL 운영 시 반드시 고려해야 할 사용자 경험(UX) 리스크이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 작업의 '위험도'를 에이전트가 스스로 판단하여 인간의 개입이 필요한 시점을 동적으로 결정하는 '신뢰도 기반 개입(Confidence-based HITL)'은 어떻게 설계하는가?
|
||||
* 인간의 피드백을 에이전트의 향후 행동에 영구적으로 반영하기 위한 '학습 데이터화' 프로세스는 어떻게 자동화할 수 있는가?
|
||||
* 가상 현실(VR)이나 증강 현실(AR) 환경에서 에이전트의 사고 과정을 직관적으로 시각화하여 인간이 더 빠르고 정확하게 개입하게 만드는 방법은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** VS Code 확장 프로그램에서 에이전트가 터미널 명령을 실행하기 전, 사용자에게 팝업을 띄워 명령어를 확인하고 수정할 수 있는 기회를 제공한다.
|
||||
* **System Design:** 에이전틱 고객 상담 시스템에서 AI가 답변을 작성하되, 최종 발송 전 상담원이 내용을 검수하고 수정할 수 있는 워크플로우를 구축한다.
|
||||
|
||||
---
|
||||
id: [[P-Reinforce]]-AI-HITL
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.99
|
||||
tags: [AI, HITL, AISafety, Collaboration]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Human-in-the-loop (HITL)]] (인간 개입형 시스템)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "AI의 자율성과 인간의 판단력이 만나는 가장 안전한 지점." AI가 100% 결정을 내리는 것이 아니라, 중요한 판단이나 모호한 상황에서 인간이 루프(Loop)에 개입하여 정확도를 높이고 윤리적 책임을 지는 구조다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Why HITL?**: AI는 확률에 기반하므로 '엣지 케이스'에서 치명적인 실수를 할 수 있다. 인간은 맥락과 도덕적 가치를 판단하여 이를 보완한다.
|
||||
- **Workflow**:
|
||||
- AI가 초안/예측 생성 -> 인간이 검토 및 수정(Verification) -> 수정된 데이터가 다시 AI 학습에 사용([[Active Learning]]).
|
||||
- **Core Benefit**:
|
||||
- **[[Reliability]]**: 실시간 사고 방지.
|
||||
- **Continuous Improvement**: 고품질 정답지(Ground Truth)를 인간이 제공하여 성능 가속화.
|
||||
- **Domain**: 의료 진단 보조, 자율주행 모니터링, 콘텐츠 모더레이션.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 인간이 루프에 끼어들면 시스템의 스케일링(속도)이 급격히 떨어진다. 이를 해결하기 위해 '모든 작업 감시'에서 '불확실성이 높은 작업만 호출'하는 방식으로 인간의 개입을 최적화하는 연구가 중요하다. 또한 인간 관리자도 피로로 인해 오판할 수 있음을 고려해야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Active-Learning , RLHF (인간 피드백 기반 강화학습)
|
||||
- [[Strategy]]: Red-Teaming
|
||||
*Last updated: 2026-05-01*
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
# [[Inference-Coupled Persistence (추론 결합 지속성)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Inference-Coupled Persistence는 에이전트가 단순히 작업 결과를 저장하는 것을 넘어, 작업이 끝난 후 모델의 추론(Inference) 능력을 활용하여 작업의 성공/실패 요인을 분석하고 향후 재사용 가능한 절차적 지식이나 에피소드 기억으로 요약하여 영구 저장소에 기록하는 기술이다. 이는 에이전트가 경험으로부터 스스로 학습하고 진화하게 만드는 자가 발전(Self-improvement)의 핵심 메커니즘이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **자가 분석 (Post-hoc Analysis)**: 작업 완료 후 에이전트는 "무엇이 성공했는가?", "어떤 장애물이 있었는가?", "다음에 이 작업을 한다면 무엇을 다르게 할 것인가?"를 스스로 질문하고 답을 생성한다.
|
||||
* **스킬 라이브러리 (Skill Synthesis)**: 특정 문제 해결 과정을 일반화된 '스킬'로 변환하여 저장한다. 예를 들어, 특정 라이브러리의 버그를 해결한 과정을 기록하여 다음에 유사한 상황에서 검색 가능하게 만든다.
|
||||
* **에피소드 기억 (Episodic Memory)**: 작업의 전체 궤적(Trajectory) 중 핵심적인 결정 순간과 그 이유를 추출하여 저장함으로써, 긴 대화 이력을 모두 보관할 필요 없이 핵심 맥락을 보존한다.
|
||||
* **쓰기 트리거 정책 (Write-trigger Policy)**: 모든 정보를 저장하면 노이즈가 발생하므로, 유의미한 발견이 있거나 작업이 완료된 시점에만 추론을 통한 저장을 실행한다.
|
||||
* **품질 게이트 (Quality-gate)**: 저장되기 전에 생성된 지식이 정확한지, 혹은 보안상 위험이 없는지 검증하는 단계를 거친다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **추론 비용**: 저장을 위해 추가적인 모델 호출이 필요하므로 토큰 소모와 시간이 발생한다.
|
||||
* **메모리 중독 (Memory Poisoning)**: 모델이 자신의 실패를 잘못 분석하거나 환각(Hallucination)을 지식으로 저장할 경우, 에이전트의 전체 지능이 오염될 수 있다.
|
||||
* **요약 편향 (Summary Drift)**: 여러 번의 분석과 요약을 거치면서 원본 경험의 중요한 디테일이 사라지고 왜곡될 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Memory System]]
|
||||
* 연결 이유: 추론 결합 지속성이 실질적으로 지식을 공급하는 대상 시스템이다.
|
||||
* [[S-component (State Store)]]
|
||||
* 연결 이유: 분석된 지식이 물리적으로 저장되는 하네스의 구성 요소이다.
|
||||
* [[Reflexion]]
|
||||
* 연결 이유: 작업 중 혹은 후에 스스로를 돌아보고 개선하는 유사한 추론 패턴이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 자기 분석 결과가 정확한지 확인하기 위해, 별도의 '평가자 에이전트(Evaluator Agent)'를 통한 교차 검증은 어느 정도의 비용 효율성을 갖는가?
|
||||
* 수백 개의 성공/실패 에피소드 중 현재 작업에 가장 큰 영감을 줄 수 있는 '유사 사례'를 검색하기 위한 고차원 임베딩 전략은 무엇인가?
|
||||
* 학습된 지식이 시간이 지나 프로젝트 사양 변경으로 인해 틀린 정보가 되었을 때(Obsolescence), 이를 자동으로 폐기하거나 수정하는 트리거는 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 코딩 작업 후 "이 프로젝트의 빌드 에러 해결법"이라는 문서를 자동으로 생성하여 `10_Wiki/00_Raw`에 저장하고, 다음에 빌드 에러 발생 시 이를 먼저 검색하도록 한다.
|
||||
* **System Design:** 하네스의 L-component에 `onTaskComplete` 훅을 설정하여, 작업 성공 시 자동으로 'Experience Synthesis' 프롬프트를 실행하도록 설계한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,49 @@
|
||||
# [[MCP (Model Context Protocol)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
MCP(Model Context Protocol)는 에이전트(또는 LLM)와 외부 도구/데이터 소스 간의 통신을 표준화하기 위해 설계된 오픈 프로토콜이다. 에이전트 하네스 내부의 도구 인터페이스(T-component)를 표준화하여, 에이전트가 다양한 시스템(파일, DB, API 등)과 일관된 방식으로 상호작용할 수 있게 한다. 로컬 프로세스 간 통신(stdio)과 원격 통신(SSE/HTTP)을 모두 지원하며, 에이전트의 기능을 동적으로 확장하는 핵심 인프라 역할을 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **에이전트-도구(Agent-to-Tool) 인터페이스 표준화**: MCP는 에이전트가 사용할 수 있는 도구의 목록, 각 도구의 입력 스키마, 그리고 실행 결과를 주고받는 형식을 정의한다. 이를 통해 특정 에이전트 프레임워크에 종속되지 않는 독립적인 도구 서버(MCP Server)를 구축할 수 있다.
|
||||
* **유연한 전송 계층 (stdio & SSE)**:
|
||||
* **stdio**: 로컬 환경에서 에이전트 프로세스와 도구 서버 프로세스 간의 가장 빠른 통신 방식(지연 시간 2~15ms).
|
||||
* **SSE/HTTP**: 클라우드나 원격 서버에 배포된 도구와 통신할 때 사용하며, 실시간 결과 스트리밍을 지원한다.
|
||||
* **리소스와 템플릿 시스템**: 단순한 도구 호출뿐만 아니라, 텍스트 데이터나 정적 파일을 에이전트에게 제공하는 'Resources' 기능과, 정형화된 프롬프트를 관리하는 'Prompts' 기능을 포함한다.
|
||||
* **상호운용성 및 확장성**: MCP를 지원하는 모든 클라이언트는 어떤 MCP 서버와도 즉시 연결될 수 있다. 이는 에이전트 개발자가 매번 새로운 API를 연동하는 대신, 표준화된 MCP 서버를 선택하여 기능을 확장할 수 있게 한다.
|
||||
* **보안 및 샌드박싱**: MCP는 도구 실행 권한을 클라이언트(하네스) 계층에서 제어하도록 설계되었다. 사용자의 승인 없이 민감한 도구가 실행되는 것을 방지하기 위해 런타임 승인 게이트와 결합되어 작동한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **거버넌스 공백**: MCP 자체에는 세분화된 권한 관리나 세션 상태 유지 기능이 부족하다. 따라서 에이전트 하네스(L-component) 수준에서 이를 보완하는 추가적인 보안 레이어가 필수적이다.
|
||||
* **간접 프롬프트 인젝션**: 신뢰할 수 없는 외부 MCP 서버의 데이터를 모델에 직접 주입할 경우, 데이터에 숨겨진 악의적 명령이 에이전트를 하이재킹할 위험이 존재한다.
|
||||
* **인프라 오버헤드**: 표준을 준수하기 위해 RPC 서버를 구축하고 유지해야 하므로, 아주 단순한 스크립트 기반 도구에 비해 초기 구현 비용과 관리 복잡성이 발생한다.
|
||||
* **지연 시간**: 원격 SSE 방식을 사용할 경우 로컬 stdio 방식보다 통신 지연이 발생하며, 이는 에이전트의 전체 실행 루프 성능에 영향을 줄 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처 및 통신 표준]
|
||||
* [[A2A (Agent-to-Agent Protocol)]]
|
||||
* 연결 이유: MCP가 에이전트-도구 간의 소통을 맡는다면, A2A는 에이전트-에이전트 간의 위임과 협업을 맡는 상위 계층 프로토콜이다.
|
||||
* [[Tool Registry (T-component)]]
|
||||
* 연결 이유: 에이전트 하네스 구조에서 MCP가 직접적으로 구현하고 표준화하는 핵심 구성 요소이다.
|
||||
|
||||
#### [보안 및 운영]
|
||||
* [[Lifecycle Hooks (L-component)]]
|
||||
* 연결 이유: MCP 통신의 보안 공백(권한 제어, 데이터 필터링)을 런타임에 보완하고 정책을 강제하는 하네스의 구성 요소이다.
|
||||
* [[Excessive Agency]]
|
||||
* 연결 이유: MCP를 통해 에이전트에게 강력한 외부 도구 접근 권한을 부여할 때 발생할 수 있는 주요 보안 리스크이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* MCP 서버로부터 전달된 데이터가 악성 명령을 포함하고 있는지(간접 프롬프트 인젝션)를 실시간으로 탐지하기 위해 하네스 계층은 어떤 검증 모델을 갖추어야 하는가?
|
||||
* A2A를 통한 타 에이전트의 작업 요청 권한을 로컬 MCP 도구 실행 권한으로 안전하게 매핑하고 변환하는 표준화된 권한 모델은 무엇인가?
|
||||
* 로컬 stdio 방식의 성능 이점을 유지하면서도 원격 SSE 방식의 확장성을 결합한 하이브리드 MCP 아키텍처는 어떻게 설계할 수 있는가?
|
||||
* MCP 리소스가 LLM의 컨텍스트 윈도우를 초과할 때, 하네스 계층에서 이를 요약하거나 'Artifact Store'로 오프로딩하는 최적의 전략은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** Claude Desktop이나 Cursor와 같은 에이전틱 IDE에 SQLite, GitHub API, 로컬 파일 편집 기능을 갖춘 MCP 서버를 연동하여 개발 자동화를 구현한다.
|
||||
* **System Design:** 에이전트 시스템 설계 시 모든 외부 통합을 MCP 서버로 모듈화하여, 하네스 코드 변경 없이도 도구를 동적으로 교체하거나 추가할 수 있는 구조를 만든다.
|
||||
* **Operation:** 프로덕션 환경에서 MCP 서버의 호출 내역을 로깅하고, 특정 도구의 남용이나 비정상적인 데이터 유출 패턴을 모니터링한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,43 @@
|
||||
# [[Prompt Engineering (프롬프트 엔지니어링)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Prompt Engineering은 LLM으로부터 원하는 출력 결과물(코드, 텍스트, 사고 과정 등)을 얻어내기 위해 입력값(프롬프트)을 정교하게 설계, 작성, 최적화하는 기술적 기법이다. 에이전틱 시스템에서는 모델에게 구체적인 역할(Persona)을 부여하고, 사용할 도구의 명세를 전달하며, 사고의 단계(Chain-of-Thought)를 유도하는 핵심 인터페이스 역할을 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **주요 기법 (Prompting Techniques)**:
|
||||
* **[[Chain-of-Thought]] (CoT)**: "단계별로 생각해보자"와 같은 문구를 통해 모델의 추론 정확도를 향상.
|
||||
* **Few-shot Prompting**: 질문과 답변의 예시(Exemplars)를 프롬프트에 포함하여 모델이 패턴을 학습하게 함.
|
||||
* **Role-play (Persona)**: 에이전트에게 "너는 시니어 코딩 전문가야"와 같이 명확한 신원과 태도를 부여.
|
||||
* **Delimiters**: XML 태그나 특수 문자를 사용하여 지시사항, 데이터, 예시를 명확히 구분.
|
||||
* **프롬프트 인젝션 방어 (Security)**:
|
||||
* **Direct Prompt Injection**: 사용자가 "이전 명령은 무시하고..."와 같이 모델의 시스템 프롬프트를 무력화하려는 공격에 대비한 방어 구문 배치.
|
||||
* **Sandwich Defense**: 사용자 입력을 시스템 지침 사이에 끼워 넣어 모델이 마지막까지 지침을 따르도록 유도.
|
||||
* **구조화된 출력 (Structured Output)**: 모델이 JSON, XML, Mermaid 등 기계가 읽을 수 있는 형식으로 답변하도록 스키마를 정의하고 예시를 제공.
|
||||
* **프롬프트 최적화 (Optimization)**: 토큰 사용량을 줄이면서 성능을 유지하기 위해 프롬프트를 압축하거나, 모델별로 최적화된 프롬프트 템플릿을 관리.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **모델 종속성**: 특정 모델에 최적화된 프롬프트가 다른 모델에서는 오작동하거나 성능이 떨어질 수 있다.
|
||||
* **프롬프트 부풀림 (Prompt Bloat)**: 너무 많은 지시사항을 넣으면 모델이 중요한 명령을 놓치거나(Lost in the middle) 추론 비용이 증가한다.
|
||||
* **비결정성**: 동일한 프롬프트라도 실행 시점마다 결과가 달라질 수 있어 안정성 확보가 어렵다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: 프롬프트 엔지니어링이 개별 메시지에 집중한다면, 컨텍스트 엔지니어링은 전체 세션의 데이터 흐름을 설계한다.
|
||||
* [[Reasoning & Planning]]
|
||||
* 연결 이유: 프롬프트 기법(CoT 등)을 통해 에이전트의 사고 능력을 실질적으로 끌어올린다.
|
||||
* [[Agent Identity Management]]
|
||||
* 연결 이유: 에이전트의 페르소나와 역할을 정의하는 주요 수단이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 Attention 패턴을 분석하여, 프롬프트 내에서 모델이 가장 중요하게 여기는 위치(Anchor)를 자동으로 찾아내는 기술은 무엇인가?
|
||||
* 수천 개의 프롬프트 변형 중 가장 성능이 좋은 것을 자동으로 골라내는 '프롬프트 A/B 테스팅'과 '자동 최적화(DSPy 등)'의 효과는 어떠한가?
|
||||
* 인간이 이해하기 어려운 '잠재적 토큰(Latent tokens)'을 활용하여 모델의 성능을 극한으로 끌어올리는 기법은 가능한가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 시스템 프롬프트 파일을 `.md` 형식으로 관리하고, 런타임에 사용자 입력과 결합하여 모델에게 전달한다.
|
||||
* **System Design:** 모델 종류에 따라 최적화된 프롬프트를 자동으로 선택하여 적용하는 'Prompt Router'를 구축한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,42 @@
|
||||
# [[Reasoning & Planning (추론 및 계획)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Reasoning & Planning은 에이전트가 복잡한 문제를 해결하기 위해 목표를 분석하고, 세부 단계를 설계하며, 실행 과정에서 발생하는 오류를 수정해나가는 고차원 사고 프로세스이다. 단순히 다음 단어를 예측하는 수준을 넘어, 논리적 인과 관계를 추론하고 미래의 상황을 시뮬레이션하여 최적의 경로를 찾아가는 에이전트 지능의 핵심 구성 요소이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **주요 추론 기법**:
|
||||
* **[[Chain-of-Thought]] (CoT)**: 복잡한 문제를 중간 단계의 논리적 흐름으로 나누어 사고하게 하여 추론 정확도를 높이는 기법.
|
||||
* **[[Reflexion]]**: 자신의 행동 결과를 평가하고 실패 원인을 분석하여 다음 시도에 반영하는 자기 비판 루프.
|
||||
* **Generate-and-Check**: 여러 대안을 생성한 후, 검증 모델이나 도구를 통해 최적의 안을 선택하는 방식.
|
||||
* **계획 수립 프레임워크**:
|
||||
* **PEV (Plan-Execute-Verify) 루프**: 실행 전 계획을 세우고, 실행 후 반드시 검증 단계를 거치는 결정론적 워크플로우.
|
||||
* **Hierarchical Planning**: 거시적 목표(Goal)를 미시적 작업(Sub-tasks)으로 계층적으로 분해하여 관리.
|
||||
* **Test-Time Scaling (TTS)**: 모델의 파라미터를 늘리는 대신, 추론 시점에 더 많은 생각(Tokens of thought)이나 시뮬레이션을 수행하여 지능을 확장하는 전략. (예: OpenAI o1 시리즈)
|
||||
* **Plan Alignment**: 에이전트의 계획이 사용자의 의도 및 시스템의 제약 사항과 일치하는지 실시간으로 확인하고 조정하는 과정.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **추론 비용과 지연 시간**: 더 깊게 생각할수록(Multi-step reasoning) 답변 생성 시간이 길어지고 토큰 비용이 급증한다.
|
||||
* **계획의 경직성**: 사전에 너무 상세한 계획을 세우면 실행 환경의 동적인 변화에 유연하게 대처하지 못할 수 있다.
|
||||
* **논리적 오류 (Hallucination)**: 추론 단계가 길어질수록 중간 단계의 작은 오류가 증폭되어 전혀 엉뚱한 결론에 도달할 위험이 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: 하네스의 E-component가 추론 루프를 물리적으로 제어한다.
|
||||
* [[Self-verification]]
|
||||
* 연결 이유: 계획이 성공했는지 판단하기 위한 필수적인 파트너 기술이다.
|
||||
* [[Agentic Orchestration]]
|
||||
* 연결 이유: 여러 에이전트 간의 계획을 통합하고 조율하는 상위 개념이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 작업의 난이도를 실시간으로 평가하여 추론에 투입할 '생각의 양(Compute budget)'을 동적으로 결정하는 최적화 알고리즘은 무엇인가?
|
||||
* 추론 과정에서 생성된 '중간 사고 과정(Hidden thoughts)'을 사용자에게 어느 정도까지 공개하는 것이 투명성과 효율성 측면에서 유리한가?
|
||||
* 계획 수립 단계에서 발생할 수 있는 '부정적 사이드 이펙트'를 사전에 시뮬레이션하여 회피하는 'Safety-aware Planning'은 어떻게 구현하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 에이전트에게 "생각의 단계(Steps of thought)"를 명시적으로 출력하게 하고, 각 단계가 끝날 때마다 하네스가 논리적 일관성을 체크한다.
|
||||
* **System Design:** 복잡한 코딩 작업 시, 전체 구조를 설계하는 'Architect 에이전트'와 세부 코드를 짜는 'Coder 에이전트'로 역할을 나누어 계획의 품질을 높인다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,43 @@
|
||||
# [[Retrieval-Augmented Generation (RAG)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
RAG(Retrieval-Augmented Generation)는 모델 내부의 파라미터 지식에만 의존하지 않고, 외부 데이터베이스나 문서 저장소에서 현재 질문과 관련된 정보를 실시간으로 검색하여 컨텍스트에 주입함으로써 답변의 정확성과 최신성을 높이는 기술이다. 에이전틱 시스템에서는 단순한 지식 조회를 넘어, 에이전트가 스스로 무엇을 검색할지 결정하고 검색 결과를 바탕으로 다음 행동을 계획하는 능동적 도구로 활용된다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **RAG의 3단계 프로세스**:
|
||||
* **Retrieval (검색)**: 사용자의 질문을 벡터로 변환하여 유사한 문서를 찾거나, 키워드 검색을 수행.
|
||||
* **Augmentation (보강)**: 검색된 결과 중 가장 관련성 높은 조각을 골라 시스템 프롬프트나 컨텍스트에 삽입.
|
||||
* **Generation (생성)**: 보강된 정보를 바탕으로 모델이 최종 답변을 생성.
|
||||
* **에이전틱 RAG (Agentic RAG)**:
|
||||
* **Self-querying**: 에이전트가 검색어 자체를 최적화하거나 여러 번의 검색을 수행.
|
||||
* **Corrective RAG**: 검색 결과가 부적절할 경우 검색 전략을 수정하거나 외부 웹 검색으로 전환.
|
||||
* **Multi-hop Retrieval**: 복잡한 질문을 여러 단계로 나누어 순차적으로 검색하고 통합.
|
||||
* **벡터 데이터베이스 (Vector DB)**: 텍스트의 의미적 유사성을 고차원 벡터 공간에서 계산하여 검색하는 핵심 저장소.
|
||||
* **시맨틱 검색 (Semantic Search)**: 단순한 키워드 매칭이 아닌 문장의 맥락과 의미를 이해하여 가장 가까운 정보를 찾는 방식.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **컨텍스트 오염**: 검색된 정보에 노이즈가 섞여 있거나 관련 없는 정보가 포함될 경우 모델의 답변 품질이 오히려 저하될 수 있다.
|
||||
* **지연 시간**: 외부 저장소 검색과 벡터 변환 과정에서 오버헤드가 발생하여 답변 속도가 느려진다.
|
||||
* **검색의 한계**: 벡터 검색은 단어 간의 복잡한 논리적 관계나 구조적 지식을 파악하는 데 한계가 있다. (이를 위해 [[GraphRAG]]가 도입됨)
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Memory System]]
|
||||
* 연결 이유: RAG는 에이전트의 메모리 중 '외부 지식'과 '장기 이력'을 불러오는 실질적인 메커니즘이다.
|
||||
* [[GraphRAG & Knowledge Graph Memory]]
|
||||
* 연결 이유: 단순 벡터 검색의 한계를 극복하기 위해 관계형 지식을 활용하는 진화된 RAG 형태이다.
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: 검색된 방대한 결과 중 어떤 것을 컨텍스트에 넣을지 결정하는 전략이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 컨텍스트 윈도우가 무한히 커진다면(Long-context), 여전히 RAG가 필요한가? (Compute Economics 관점의 분석)
|
||||
* 검색된 정보가 모델의 내부 지식과 충돌할 때, 모델이 '외부 근거'를 우선시하게 만드는 최적의 프롬프트 가중치 조절 방법은 무엇인가?
|
||||
* 수백만 개의 문서 중 '최신성'과 '정확성'을 동시에 만족하는 정보를 순위화(Re-ranking)하는 하이브리드 알고리즘은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** LangChain의 `VectorStoreRetriever`를 사용하여 에이전트에게 지식 베이스 검색 도구를 부여한다.
|
||||
* **System Design:** 검색 결과의 품질을 높이기 위해 사용자 질문을 확장(Query Expansion)하거나, 검색된 문서를 다시 순위화(Re-ranking)하는 파이프라인을 구축한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
Reference in New Issue
Block a user