refactor: move gRPC_Based_Interface/ into docs/ and add new docs

docs/gRPC_Based_Interface/USECASES.md

@@ -25,7 +25,7 @@
 
 이 3-tier 사이를 관통하는 에이전트 간 통신은 같은 머신 위의 함수 호출이 아니라 **상이한 운영체제·언어·전력·연결성을 가진 원격 디바이스들 사이의 다중 홉 프로토콜** 이다. 본 연구는 엣지 AIoT 시나리오에서 gRPC가 어느 tier 사이에서 가장 효과적이고, 어느 tier에서는 별도 보완이 필요한지를 4대 사용 사례와 함께 분석한다.
 
-![Figure 1. 엣지 AIoT 3-tier 물리적 분산 구조 — 자원/네트워크/보안 강도 비교|739](fig1_three_tier.svg)
+![Figure 1. 엣지 AIoT 3-tier 물리적 분산 구조 — 자원/네트워크/보안 강도 비교|739](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/fig1_three_tier.svg)
 
 ---
 
@@ -48,7 +48,7 @@
 
 엣지 AIoT의 3-tier 분산 구조 위에서 동작하는 4대 대표 사용 사례는 다음과 같다. 각 사례는 **자신만의 디바이스 조합·통신 요구·제약**을 갖는다.
 
-![Figure 2. 엣지 AIoT 4대 사용 사례 콜라주 — Smart Factory, Smart Building, V2X, Healthcare](edge_aiot_usecases_overview.png)
+![Figure 2. 엣지 AIoT 4대 사용 사례 콜라주 — Smart Factory, Smart Building, V2X, Healthcare](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/edge_aiot_usecases_overview.png)
 
 ### 사례 ① 스마트 팩토리 (Industry 4.0)
 **배치**: T1(중앙 PM·품질분석·예지정비 에이전트) ↔ T2(엣지 컨트롤러, 라인별) ↔ T3(다수 AGV·협동로봇·CCTV·진동 센서).
@@ -60,7 +60,7 @@
 | T3 센서 ↔ T2 | 텔레메트리 다수 팬인 | 동시 10k 노드, 1Hz/노드 |
 | T3 로봇 ↔ T1 (직접) | OTA 펌웨어, 원격 진단 | 결함 내성 다운로드 |
 
-![Figure 3. 스마트 팩토리 — 3-tier vertical 협업, gRPC Bidi 합의 + MQTT fan-in](smart_factory_aiot.png)
+![Figure 3. 스마트 팩토리 — 3-tier vertical 협업, gRPC Bidi 합의 + MQTT fan-in](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/smart_factory_aiot.png)
 
 ### 사례 ② 스마트 빌딩 / 스마트 그리드 / 에너지
 **배치**: T1(빌딩 에너지 최적화·DR 에이전트) ↔ T2(빌딩별 또는 변전소별 엣지) ↔ T3(수만 개의 HVAC·조명·PV 인버터·스마트 미터).
@@ -69,7 +69,7 @@
 - **T2 ↔ T1**: 비-실시간 분석·명령下发, 4G/유선
 - **엣지-로컬 합의**: 빌딩 내 HVAC 협업(피크 절감), < 100ms 응답
 
-![Figure 4. 스마트 빌딩/에너지 — HVAC·PV·미터의 LoRa·MQTT·gRPC 혼합 통신](smart_building_energy.png)
+![Figure 4. 스마트 빌딩/에너지 — HVAC·PV·미터의 LoRa·MQTT·gRPC 혼합 통신](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/smart_building_energy.png)
 
 ### 사례 ③ 커넥티드 차량 / V2X
 **배치**: T1(클라우드 텔레매틱스·HD맵·원격 진단) ↔ T2(RSU·로드사이드 유닛·5G MEC) ↔ T3(차량 내 ECU·레이더·카메라).
@@ -85,7 +85,7 @@
 - **T2 ↔ T1**: 일간 업로드, 비실시간
 - **긴급 이벤트**: 부정맥·낙상 감지 시 < 1s T1 알림
 
-![Figure 5. 헬스케어/원격 모니터링 — 환자 웨어러블·병원 엣지·EHR 클라우드 워크플로우](healthcare_aiot.png)
+![Figure 5. 헬스케어/원격 모니터링 — 환자 웨어러블·병원 엣지·EHR 클라우드 워크플로우](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/healthcare_aiot.png)
 
 **공통 통신 요구 5가지**: ① 타입 안전 ② 단방향·양방향 스트리밍 ③ 단절·핸드오버 내성 ④ 디바이스 attestation ⑤ 광역 관측성. 단 4가지 사례는 **각각 다른 우선순위**를 가진다.
 
@@ -104,7 +104,7 @@
 
 **직렬화 포맷 정량 비교** (예시적 추정치)¹:
 
-![Figure 10. gRPC vs REST 정량 비교 — 페이로드 크기 및 CPU 파싱 시간|942](fig6_benchmark.svg)
+![Figure 10. gRPC vs REST 정량 비교 — 페이로드 크기 및 CPU 파싱 시간|942](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/fig6_benchmark.svg)
 
 ¹ Illustrative Estimates. 페이로드 복잡도·라이브러리 버전·런타임 구현에 따라 변동.
 
@@ -140,7 +140,7 @@
 | **Client Streaming** | T3 → T2 다수 센서 배치 업로드, OTA 펌웨어 청크 |
 | **Bidi Streaming** | T2↔T2 엣지 합의, T3↔T2 차량/로봇 실시간 협업 |
 
-![Figure 6. gRPC 4대 RPC 모드 — Unary / Server / Client / Bidi Streaming의 엣지 AIoT 매핑|942](fig3_rpc_modes.svg)
+![Figure 6. gRPC 4대 RPC 모드 — Unary / Server / Client / Bidi Streaming의 엣지 AIoT 매핑|942](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/fig3_rpc_modes.svg)
 
 ### 5.3 엣지 AIoT 환경에서의 약점과 보완 패턴
 
@@ -159,7 +159,7 @@
 
 본 절은 본 연구의 핵심 제안인 **2-tier 프로토콜 아키텍처** 를 제시한다. 단일 프로토콜이 아닌 **tier별 최적 프로토콜을 혼용**하고, T2 엣지 게이트웨이가 변환·집계·인증을 책임지는 구조다.
 
-![Figure 7. 2-tier 프로토콜 아키텍처 — T1↔T2 gRPC/QUIC, T2↔T3 MQTT/CoAP/C-V2X, T2 게이트웨이 6대 책임|933](fig2_two_tier_protocol.svg)
+![Figure 7. 2-tier 프로토콜 아키텍처 — T1↔T2 gRPC/QUIC, T2↔T3 MQTT/CoAP/C-V2X, T2 게이트웨이 6대 책임|933](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/fig2_two_tier_protocol.svg)
 
 ```
 ┌──────────────────────────────────────────────────────────────────┐
@@ -222,7 +222,7 @@ T1↔T2 무선 구간에서 송신 측 버퍼가 차면 `WINDOW_SIZE=0` 프레
 
 T3↔T2↔T1의 텔레메트리 스트리밍(사례 ①②④)이 중간에 끊기면, gRPC 서버는 **Resume Token**(마지막 전송 위치)을 발급한다. 클라이언트는 재연결 시 `Resume-Token` Metadata를 첨부해 이어받는다. 이 패턴은 gRPC Interceptor에 캡슐화되어 모바일·엣지·MCU의 일시 단절을 흡수한다.
 
-![Figure 8. Resume Token 시퀀스 — T3/T2 단절-재접속 시 스트리밍 위치 보존|942](fig5_resume_token.svg)
+![Figure 8. Resume Token 시퀀스 — T3/T2 단절-재접속 시 스트리밍 위치 보존|942](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/fig5_resume_token.svg)
 
 ### 7.4 명시적 Deadline
 T3 디바이스는 네트워크 품질을 신뢰할 수 없다. `ClientContext`에 `Deadline`을 인터셉터에서 강제 주입해 단절 시 무한 대기를 방지한다. 디바이스 클래스별 기본 deadline 정책을 다르게 적용한다(예: AGV V2V 50ms, IoT 텔레메트리 5s).
@@ -241,7 +241,7 @@ gRPC TLS 핸드셰이크 시 SAN의 SPIFFE ID를 즉시 확인해 비인가 디
 
 ### 8.2 2계층 통신 제어: Service Mesh + Interceptor
 
-![Figure 9. 2계층 통신 제어 — Service Mesh(인프라) + gRPC Interceptor(앱) 관심사 분리|942](fig4_two_layer_governance.svg)
+![Figure 9. 2계층 통신 제어 — Service Mesh(인프라) + gRPC Interceptor(앱) 관심사 분리|942](lab/canary_projects/multi-agent-paper/docs/gRPC_Based_Interface/figures/fig4_two_layer_governance.svg)
 
 | 계층 | 통제 항목 | 엣지 AIoT 적용 |
 |------|----------|----------------|

docs/herdr_manual/herdr_guide.md

@@ -0,0 +1,127 @@
+# Herdr 사용 가이드
+
+## 소개
+
+Herdr는 "코딩 에이전트를 위한 tmux"라고 볼 수 있는 터미널 워크스페이스 매니저(agent multiplexer)입니다. 여러 AI 코딩 에이전트(Claude Code, Codex 등)를 각각 실제 터미널 pane에서 실행하면서, 어떤 에이전트가 작업 중인지 / 입력을 기다리는지(blocked) / 끝났는지를 사이드바에서 한눈에 확인할 수 있고, detach해도 백그라운드에서 계속 실행됩니다. Rust로 작성된 로컬 바이너리이며 별도의 GUI 앱이나 클라우드 계정이 필요 없습니다.
+
+공식 사이트: [herdr.dev](https://herdr.dev)
+
+## 주요 사용사례
+
+- 여러 에이전트를 동시에 병렬로 실행하며 상태만 사이드바에서 훑어보기
+- SSH나 휴대폰으로 원격 접속해 백그라운드 세션에 이어 붙기 (detach/reattach)
+- 소켓 API/CLI로 스크립트나 다른 에이전트(오케스트레이터)가 에이전트에 명령을 넣고 결과를 읽어오는 자동화
+- 서버 재시작 후에도 에이전트 네이티브 세션을 복원해서 이어가기 (Claude Code, Codex 등 통합 시)
+- 하나의 워크스페이스(프로젝트) 안에서 여러 개의 서로 다른 workspace/session으로 완전히 격리된 작업 공간 운용
+
+## 개념 정리
+
+| 개념 | 설명 |
+|---|---|
+| Session | 지속되는 Herdr 서버 하나(런타임 인스턴스). `herdr`는 기본 세션에 붙고, `herdr --session <name>`으로 named session을 launch-or-attach 할 수 있음 |
+| Workspace | 세션 안의 최상위 프로젝트 컨테이너. 보통 repo/작업 단위로 하나씩 |
+| Tab | workspace 안의 레이아웃 |
+| Pane | 실제 터미널 하나 |
+| Agent | Herdr가 pane 안에서 인식하는 프로세스 (Claude Code, Codex 등). 상태: blocked/working/done/idle/unknown |
+| Channel | Herdr 바이너리 자체의 업데이트 트랙 (stable/preview) — session과 무관한 별개 개념 |
+
+## 주요 단축키
+
+prefix 키 기본값은 `ctrl+b`. `prefix+?`로 언제든 전체 목록 확인 가능.
+
+가장 먼저 배울 5가지:
+
+| 동작 | 키 |
+|---|---|
+| 새 탭 | `prefix+c` |
+| 좌우/상하 분할 | `prefix+v` / `prefix+minus` |
+| 패널 이동 | `prefix+h/j/k/l` |
+| 워크스페이스 탐색 | `prefix+w` |
+| detach (세션 유지) | `prefix+q` |
+
+추가 자주 쓰는 것:
+
+| 동작 | 키 |
+|---|---|
+| 패널 확대(zoom) | `prefix+z` |
+| 패널 닫기 | `prefix+x` |
+| 카피 모드 | `prefix+[` |
+| 다음/이전 탭 | `prefix+n` / `prefix+p` |
+| 새 워크스페이스 | `prefix+shift+n` |
+| 사이드바 토글 | `prefix+b` |
+
+마우스만으로도 클릭/드래그/우클릭 메뉴로 대부분 조작 가능 (mouse-native).
+
+## 실습: 세션 생성 → Claude 실행 → 소켓으로 프롬프트 전달 → 결과 확인
+
+### 1. 현재 디렉터리를 cwd로 하는 새 세션 `new_session` 생성
+
+```bash
+cd <현재 작업 디렉터리>
+herdr --session new_session
+```
+
+Herdr의 세션은 launch-or-attach 모델이라 이 한 줄로 세션이 없으면 생성하고 동시에 attach까지 됩니다.
+
+### 2. 생성된 세션에서 Claude 실행
+
+attach된 pane 안에서:
+
+```bash
+claude
+```
+
+(테스트용으로 권한 프롬프트를 건너뛰려면 `claude --dangerously-skip-permissions`. 신뢰된 환경에서만 사용 권장.)
+
+### 3. 다른 터미널에서 herdr 명령으로 프롬프트 전달 (직접 타이핑 아님)
+
+새 터미널에서 에이전트 목록과 pane_id 확인:
+
+```bash
+herdr --session new_session agent list
+herdr --session new_session agent get claude
+```
+
+텍스트 입력 + Enter 제출을 원자적으로 수행:
+
+```bash
+herdr --session new_session pane run <pane_id> "정렬 프로그램을 작성해줘"
+```
+
+### 4. Claude의 결과 화면 출력
+
+완료될 때까지 기다렸다가 읽기:
+
+```bash
+herdr --session new_session wait agent-status <pane_id> --status idle
+herdr --session new_session pane read <pane_id> --source recent --lines 150
+```
+
+현재 화면만 바로 보기:
+
+```bash
+herdr --session new_session pane read <pane_id> --source visible --lines 80
+```
+
+`--session new_session`을 매번 붙이는 대신 `export HERDR_SESSION=new_session`으로 환경변수를 설정하면 이후 명령에서 생략 가능합니다.
+
+## 참고: 다중 workspace 간 에이전트 제어
+
+Herdr의 소켓 API/CLI는 workspace 단위로 격리되지 않고 세션 전체가 하나의 소켓을 공유합니다. `pane_id`가 `w1:p1` 같은 전역 ID라서, 지금 어느 workspace에 있든 다른 workspace의 에이전트를 `agent send`, `agent read`, `wait agent-status`, `pane run` 등으로 그대로 제어할 수 있습니다.
+
+```bash
+herdr workspace create --cwd ~/project --label claude-test
+herdr workspace list                      # 방금 만든 workspace_id 확인
+herdr agent start claude-test --workspace <workspace_id> -- claude
+herdr agent send claude-test "테스트"
+herdr wait agent-status claude-test --status idle
+```
+
+## 출처
+
+- [herdr.dev/docs](https://herdr.dev/docs/)
+- [herdr.dev/docs/cli-reference](https://herdr.dev/docs/cli-reference/)
+- [herdr.dev/docs/socket-api](https://herdr.dev/docs/socket-api/)
+- [herdr.dev/docs/keyboard](https://herdr.dev/docs/keyboard/)
+- [herdr.dev/docs/agents](https://herdr.dev/docs/agents/)
+- [herdr.dev/docs/persistence-remote](https://herdr.dev/docs/persistence-remote/)

lib/make_slide_for_260724_seminar/SLIDE.md

@@ -51,9 +51,9 @@ marp: true
   "여기서 우회전하고 다음에서 멈추자"라는 인지적 판단과 주행 경로(추론)를 수립합니다.
 - **AI 에이전트(Agent)는 '자율주행 차량 시스템 전체' 입니다.**
   운전자의 판단을 가속 페달과 바퀴 회전(도구 실행)으로 바꾸며, 다음과 같은 독자적인 **시스템 수준의 판단**을 수행합니다:
-  - **안전 가드레일**: 운전자가 실수로 위험한 길(예: 시스템 파괴 명령)로 가려 할 때 비상 제동을 걸어 이를 원천 차단함
+  - **안전 가드레일**: 운전자가 실수로 시스템을 파괴하는 명령과 같이 위험한 길로 가려 할 때 비상 제동을 걸어 이를 원천 차단합니다.
-  - **예외 복구 및 통제**: 네트워크가 끊기거나 무한 루프에 빠지면 스스로 판단해 실행을 중단하고 우회 경로를 수립함
+  - **예외 복구 및 통제**: 네트워크 연결이 끊기거나 무한 루프에 빠지는 상황이 발생하면 스스로 판단하여 실행을 중단하고 우회 경로를 수립합니다.
-  - **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과(`PASS`/`NOT PASS`)를 수집하고 최종 집행을 판정함
+  - **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과를 수집하여 통과나 반려 여부를 결정하고 최종 집행을 판정합니다.
 
 ---
 
@@ -61,67 +61,148 @@ marp: true
 
 단순히 대화만 나누는 챗봇이 아니라, 진짜 제 역할을 하는 **자율형 AI 에이전트**가 되기 위해 소프트웨어 시스템 차원에서 반드시 제공해야 하는 4가지 핵심 기능입니다.
 
-- **목표를 쪼개고 계획하는 능력 (Planning)**
+1. **계획 및 추론 능력 (Planning)**
-  사람이 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 자가 성찰(Self-Reflection)을 통해 유연하게 계획을 수정합니다.
+2. **기억 및 상태 관리 능력 (Memory)**
-- **상태와 기억을 관리하는 능력 (Memory)**
+3. **도구 활용 및 실행 능력 (Tool Use & Action)**
-  현재 대화의 맥락을 잃지 않는 단기 기억은 물론, 과거의 경험과 방대한 지식을 데이터베이스로부터 필요할 때마다 영속적으로 꺼내어 쓰는 장기 기억을 조화롭게 다룹니다.
+4. **상호 통신 및 협업 능력 (Collaboration)**
-- **물리적 환경과 연결되는 능력 (Tool Use & Action)**
-  인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행용 격리 환경(Sandboxing) 등 컴퓨터 세상의 다양한 도구들을 안전하게 선택하고 직접 작동시킵니다.
-- **서로 소통하고 협업하는 능력 (Collaboration)**
-  다른 전문 분야를 가진 에이전트나 사용자 시스템과 표준화된 규격으로 메시지를 주고받으며 큰 단위의 작업을 나누어 분산 처리합니다.
 
 ---
 
-## 🚀 패러다임 쉬프트: Model eats the Scaffolding
+### 1. 계획 및 추론 능력 (Planning)
 
-현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 '시스템(Scaffolding)'이 수동으로 제어하던 기능들이 점점 AI '모델 내부'로 흡수되고 있다는 점입니다.
+사용자가 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 계획을 유연하게 수정하는 능력입니다.
 
-- **스스로 생각하는 모델의 등장 (Test-time Compute)**
+- **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
+- **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
+
+* **실제 예시**: 
+  에이전트에게 "블로그 기사 작성"을 요청하면, 스스로 **'키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사'** 순으로 계획을 세웁니다. 만약 맞춤법 검사 도중 치명적인 논리 오류를 발견하면, 본문 작성 단계로 스스로 되돌아가 계획을 수정하고 다시 쓰는 자가 성찰(Self-Reflection)을 거칩니다.
+
+---
+
+### 2. 기억 및 상태 관리 능력 (Memory)
+
+현재 나누는 대화의 즉각적인 흐름(단기 기억)뿐만 아니라, 과거의 경험과 누적된 지식(장기 기억)을 필요할 때마다 영속적으로 꺼내어 쓰는 능력입니다.
+
+- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
+- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
+
+* **실제 예시**: 
+  에이전트에게 "어제 작업하던 파이썬 소스코드의 오류를 이어서 수정해줘"라고 요청하는 경우입니다. 에이전트는 데이터베이스에 누적된 과거 대화 히스토리와, 벡터 DB에 저장되어 있는 소스코드의 예전 상태 정보를 동적으로 인출(Retrieval)해 와 대화 맥락을 끊김 없이 이어갑니다.
+
+---
+
+### 3. 도구 활용 및 실행 능력 (Tool Use & Action)
+
+인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행 등 컴퓨터 세상의 다양한 소프트웨어를 직접 연결하고 작동시키는 손과 발 역할을 의미합니다.
+
+* **실제 예시**: 
+  복잡한 나눗셈 연산을 해야 할 때 직접 계산기 도구를 호출해 오차 없이 연산하고, 최신 주식 시세를 알기 위해 증권사 API를 호출하며, 작성한 코드가 잘 돌아가는지 검증하기 위해 격리된 샌드박스 컴퓨터 환경(Docker)을 구동해 스크립트를 직접 실행합니다.
+
+---
+
+### 4. 상호 통신 및 협업 능력 (Collaboration)
+
+혼자서 모든 일을 처리하는 것이 아니라, 다른 역할을 가진 전문 에이전트나 사용자 시스템과 표준 규격으로 메시지를 주고받으며 큰 작업을 분산 처리하는 능력입니다.
+
+* **실제 예시**: 
+  "이 프로젝트의 보안 취약점 보고서를 작성해줘"라는 명령을 내렸을 때의 상황입니다. 보안 에이전트가 소스코드를 스캔해 취약점을 나열하면, 인프라 에이전트가 가상 머신 설정을 검토하고, 최종적으로 리뷰어 에이전트들이 보고서의 신뢰성을 상호 검증하여 하나의 완성된 산출물을 합작해 냅니다.
+
+---
+
+## 🚀 패러다임 전환: Model eats the Scaffolding (모델이 외부 시스템을 흡수하다)
+
+현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 제어 시스템(Scaffolding, 에이전트의 구동을 돕는 외부 뼈대 구조)이 수동으로 제어하던 기능들이 점점 AI 모델 내부로 흡수되고 있는 현상입니다.
+
+- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
+
+- **스스로 생각하는 모델의 등장 (Test-time Compute, 추론 시점 추가 연산)**
   최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들은 외부 시스템이 루프를 돌려주지 않아도, 모델 스스로 출력을 내보내기 전에 내부적으로 계획을 세우고(Planning) 스스로 오류를 성찰(Reflection)하는 과정을 완료합니다.
 - **인지와 집행의 명확한 역할 분담**
-  이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있으며, 외부의 **에이전트 인프라(Harness)**는 안전한 실행 환경(Sandboxing), 권한 통제, 상태 관리처럼 모델이 직접 할 수 없는 물리적 보호막 역할을 수행하는 방향으로 진화하고 있습니다.
+  이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있습니다. 반면 외부의 **에이전트 인프라(Harness, 에이전트 실행 및 도구 제어 장치)**는 안전한 실행 환경(Sandboxing, 격리 환경 실행), 권한 통제, 상태 관리처럼 모델이 직접 수행하기 어려운 물리적 보호막 역할을 담당하는 방향으로 진화하고 있습니다.
 - **차별화 요소(Alpha)의 이동**
-  단순히 계획을 짜는 루프를 코드로 구현하는 것의 가치는 줄어들고, 이제는 복잡한 인프라를 실시간으로 제어하고 서로 다른 규격을 가진 이종 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력이 되었습니다.
+  단순히 계획을 짜는 흐름을 코드로 구현하는 것의 가치는 점차 줄어들고 있습니다. 이제는 복잡한 인프라를 실시간으로 제어하고, 서로 다른 규격을 가진 다양한 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력으로 부상하고 있습니다.
 
 ---
 
 # 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
 
-## AI 모델(LLM) vs AI 에이전트
+성공적인 AI 에이전트 시스템을 구현하기 위해서는 단순히 모델에게 프롬프트를 입력하는 것을 넘어, **모델 제어**, **정보 연동**, **물리적 환경 연결**을 유기적으로 엮어내는 3가지 핵심 엔지니어링 기법이 필요합니다.
-AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
 
-LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
+1. **프롬프트 엔지니어링 (Prompt Engineering)**: 에이전트의 페르소나와 사고 방식(추론 가이드라인)을 규정하는 작업입니다.
-1. **Planning (계획 및 추론)**
+2. **컨텍스트 엔지니어링 (Context Engineering)**: 대화 흐름을 끊김 없이 보존하고 관련 데이터를 적시에 제공하는 정보 정리 작업입니다.
-   - **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
+3. **하네스 엔지니어링 (Harness Engineering)**: 격리된 환경에서 다양한 소프트웨어 도구를 안전하게 조작할 수 있는 물리적 손발을 달아주는 작업입니다.
-   - **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
-2. **Memory (기억 장치)**
-   - **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
-   - **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
 
-- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
+---
 
-## 3대 핵심 엔지니어링 기법
+### 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
-성공적인 AI 에이전트 구현을 위해서는 모델 제어, 정보 연동, 물리적 환경 연결을 최적화하는 3대 엔지니어링 기법이 필수적으로 수반되어야 합니다.
 
-- ### 프롬프트 엔지니어링 (Prompt Engineering)
+모델의 발전과 자체 추론 기능의 향상으로 예전만큼 미시적인 프롬프트 트릭에 집착할 필요는 줄어들고 있습니다. 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 뼈대**입니다. 구체적이고 명확한 작동 지침을 만들기 위해 프롬프트 작성 시 반드시 반영해야 할 3대 핵심 고려사항입니다.
-  에이전트에게 명확한 역할 페르소나와 추론 가이드라인을 설계하고, 효율적인 추론 경로를 유도하기 위해 프롬프트 구조와 예시(Few-shot)를 최적화하는 기법입니다.
-  - **역할 페르소나 설계**: 에이전트가 특정 전문 도메인 지식과 행동 양식을 고수할 수 있도록 페르소나를 규정
-  - **추론 가이드라인 설계**: ReAct와 같은 사고 단계를 정의하여 모델이 계획 단계를 건너뛰지 않고 순차적으로 사고하도록 제어
-  - **Few-shot 최적화**: 최적의 추론 경로 및 응답 포맷 예시를 프롬프트에 제공하여 응답 일관성을 극대화
 
-- ### 컨텍스트 엔지니어링 (Context Engineering)
+- **역할 및 페르소나 지시 (Role)**
-  대화 상태(State)와 흐름을 보존하며, 외부 데이터베이스나 기억(Memory) 장치로부터 필요한 정보를 적시에 모델의 컨텍스트 윈도우에 효율적으로 바인딩하고 공급하는 기술입니다. 단일 에이전트 관점에서는 제한된 컨텍스트 공간 내에서 정보 밀도를 극대화하는 설계가 핵심입니다.
+  에이전트에게 전문 도메인 지식과 행동 경계를 지정해 줍니다. (예: *"너는 주니어 개발자를 코칭하는 꼼꼼한 테크리더 에이전트다. 직접 고치지 말고 가이드라인만 제공해라."*)
-  - **대화 상태 및 흐름 보존**: 이전 턴의 작업 상태와 대화 맥락을 유실 없이 세션 전반에 유지
+- **구체적인 작업 예시 제공 (Few-shot)**
-  - **적시 동적 바인딩**: 외부 RAG 검색기나 메모리 캐시로부터 관련성이 가장 높은 데이터만을 선별하여 컨텍스트 윈도우에 결합
+  원하는 출력 형식이나 중간 추론 과정의 모범 예시를 제공하여, 에이전트의 답변 일관성과 가독성을 극대화합니다.
-  - **메모리 압축 및 정리**: 불필요한 과거 로그를 요약하거나 중요 상태 구조체 위주로 정제하여 토큰 윈도우 효율성 제고
+- **자가 검증 방법 제시 (Verification)**
+  에이전트 스스로 작업의 무결성을 점검하게 하거나, 외부 시스템이 실행 결과를 확인 및 통제할 수 있도록 정형화된 출력 규격(예: 최종 통과 시 `[VERDICT: PASS]` 명시 요구)을 정의해 줍니다.
 
-- ### 하네스 엔지니어링 (Harness Engineering)
+---
-  에이전트가 계산기, 웹 브라우저, 외부 API 및 파일 시스템 등의 물리적 도구(Tools/Tool Use)에 안전하고 유연하게 연결되어 명령을 실행할 수 있도록 연결 고리를 결합하는 도구 연동 인터페이스 기술입니다.
-  - **물리 인터페이스 결합**: LLM의 도구 호출 의도(Tool Call)를 가로채어 실제 운영체제나 네트워크 상의 실행 스크립트로 전달하고 실행 결과를 모델에 반환
-  - **보안 샌드박싱**: 임의 코드 실행이나 파일 훼손 방지를 위해 파일 시스템 격리 및 API 호출 권한 등의 안전 제어막 형성
-  - **도구 활용 (Tool Use)**: 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력
 
-  ![Screenshot 2026-06-25 at 9.39.07 pm](../../assets/images/Screenshot%202026-06-25%20at%209.39.07%20pm.png)
+### 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
+
+에이전트가 단번에 대답하지 않고 단계별로 계획을 세워 도구를 사용하도록 프롬프트 구조를 강제하는 기법입니다.
+
+```text
+[System Prompt]
+너는 복잡한 수식을 계산하는 수학 에이전트다. 다음 형식으로 사고해라:
+- Thought: 문제 해결을 위한 다음 행동 계획을 작성해라.
+- Action: 호출할 도구 이름과 인자값을 JSON으로 적어라. (예: Calculator)
+- Observation: 도구 실행 결과가 여기에 채워질 것이다.
+- Thought: 실행 결과를 바탕으로 성찰하고, 필요하면 다음 Action을 설계해라.
+```
+
+---
+
+### 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
+
+에이전트가 다루는 대화 맥락과 작업 상태(State)를 효율적으로 정제하고, 수많은 외부 정보 중 **지금 꼭 필요한 관련 데이터(RAG)**만을 선별하여 제한된 AI의 기억 공간(컨텍스트 윈도우)에 밀도 높게 채워 넣는 기술입니다.
+
+* **핵심 설계 요소**:
+  - **대화 상태 보존**: 이전 턴의 작업 결과를 유실 없이 보존
+  - **동적 바인딩**: 외부 RAG 검색기에서 관련도 높은 중요 데이터만 적시에 필터링하여 공급
+  - **메모리 압축**: 불필요한 과거 로그는 요약하고, 핵심 현재 상태 구조체만 유지해 토큰 낭비 방지
+* **에이전트 상태 보존 예시 (State JSON)**:
+  ```json
+  {
+    "task_id": "job_10294",
+    "current_working_directory": "/workspace/src",
+    "error_logs": ["SyntaxError: unexpected EOF while parsing at line 14"],
+    "completed_subtasks": ["1. 소스코드 로드 완료", "2. 오류 라인 식별"],
+    "next_action_required": "오류 라인 14의 괄호 닫힘 확인 및 수정 스크립트 작성"
+  }
+  ```
+
+---
+
+### 3️⃣ 하네스 엔지니어링 (Harness Engineering)
+
+에이전트가 파일 시스템 제어, 브라우저 조작, 외부 API 호출 등 컴퓨터 세상의 다양한 도구들을 안전하게 가동할 수 있도록 **물리적 인터페이스(연결 고리)**를 구성하는 기술입니다.
+
+* **핵심 설계 요소**:
+  - **도구 호출 가로채기(Intercepting)**: 모델이 내놓은 도구 호출 의도(JSON 등)를 감지하고, 실제 터미널이나 프로그램의 함수로 전달해 구동함
+  - **보안 샌드박싱 (Sandboxing)**: 에이전트가 악성 코드나 파괴적인 명령어를 무단 실행하지 않도록 격리된 가상 환경을 구축하고 권한을 통제함
+* **물리 인터페이스 도구 결합 예시**:
+  ```
+  [LLM의 출력] ──> "Action: execute_command, args: { cmd: 'ls -la' }"
+                          │ (하네스가 이를 가로챔)
+                          ▼
+  [하네스 제어기] ──> 격리된 Docker 샌드박스 내부에서 'ls -la' 실제 실행
+                          │ (실행 결과 가로챔)
+                          ▼
+  [LLM의 입력] <── "Observation: total 12\ndrwxr-xr-x 3 user..." (모델에 반환)
+  ```
+
+  ![Harness Diagram](../../assets/images/Screenshot%202026-06-25%20at%209.39.07%20pm.png)
 
 ---
 

lib/make_slide_for_260724_seminar/chapters/0_intro.md

@@ -1,9 +1,6 @@
 ---
-title: AI Multi-Agents 오케스트레이션 기술 동향 및 사례
-description: AI 에이전트의 핵심 기법부터 MCP/SKILL 확장, TMUX/crewAI/LangGraph 오케스트레이션 인프라, ACP/A2A 상호운용성 표준, AIoT/gRPC 동향까지 다루는 특강 발표자료용 문서입니다.
 marp: true
 ---
-<!-- NOTE: 이 문서의 동기화 사본이 paper_draft/SLIDE.md에 존재합니다. 이미지 상대경로는 루트 기준이므로 렌더링은 루트 SLIDE.md로 수행하세요. -->
 
 # AI Multi-Agents 오케스트레이션 기술 동향 및 사례
 ### 정적 AI 모델에서 자율적 AI 에이전트로의 패러다임 전환
@@ -51,9 +48,9 @@ marp: true
   "여기서 우회전하고 다음에서 멈추자"라는 인지적 판단과 주행 경로(추론)를 수립합니다.
 - **AI 에이전트(Agent)는 '자율주행 차량 시스템 전체' 입니다.**
   운전자의 판단을 가속 페달과 바퀴 회전(도구 실행)으로 바꾸며, 다음과 같은 독자적인 **시스템 수준의 판단**을 수행합니다:
-  - **안전 가드레일**: 운전자가 실수로 위험한 길(예: 시스템 파괴 명령)로 가려 할 때 비상 제동을 걸어 이를 원천 차단함
+  - **안전 가드레일**: 운전자가 실수로 시스템을 파괴하는 명령과 같이 위험한 길로 가려 할 때 비상 제동을 걸어 이를 원천 차단합니다.
-  - **예외 복구 및 통제**: 네트워크가 끊기거나 무한 루프에 빠지면 스스로 판단해 실행을 중단하고 우회 경로를 수립함
+  - **예외 복구 및 통제**: 네트워크 연결이 끊기거나 무한 루프에 빠지는 상황이 발생하면 스스로 판단하여 실행을 중단하고 우회 경로를 수립합니다.
-  - **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과(`PASS`/`NOT PASS`)를 수집하고 최종 집행을 판정함
+  - **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과를 수집하여 통과나 반려 여부를 결정하고 최종 집행을 판정합니다.
 
 ---
 
@@ -61,26 +58,66 @@ marp: true
 
 단순히 대화만 나누는 챗봇이 아니라, 진짜 제 역할을 하는 **자율형 AI 에이전트**가 되기 위해 소프트웨어 시스템 차원에서 반드시 제공해야 하는 4가지 핵심 기능입니다.
 
-- **목표를 쪼개고 계획하는 능력 (Planning)**
+1. **계획 및 추론 능력 (Planning)**
-  사람이 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 자가 성찰(Self-Reflection)을 통해 유연하게 계획을 수정합니다.
+2. **기억 및 상태 관리 능력 (Memory)**
-- **상태와 기억을 관리하는 능력 (Memory)**
+3. **도구 활용 및 실행 능력 (Tool Use & Action)**
-  현재 대화의 맥락을 잃지 않는 단기 기억은 물론, 과거의 경험과 방대한 지식을 데이터베이스로부터 필요할 때마다 영속적으로 꺼내어 쓰는 장기 기억을 조화롭게 다룹니다.
+4. **상호 통신 및 협업 능력 (Collaboration)**
-- **물리적 환경과 연결되는 능력 (Tool Use & Action)**
-  인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행용 격리 환경(Sandboxing) 등 컴퓨터 세상의 다양한 도구들을 안전하게 선택하고 직접 작동시킵니다.
-- **서로 소통하고 협업하는 능력 (Collaboration)**
-  다른 전문 분야를 가진 에이전트나 사용자 시스템과 표준화된 규격으로 메시지를 주고받으며 큰 단위의 작업을 나누어 분산 처리합니다.
 
 ---
 
-## 🚀 패러다임 쉬프트: Model eats the Scaffolding
+### 1. 계획 및 추론 능력 (Planning)
 
-현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 '시스템(Scaffolding)'이 수동으로 제어하던 기능들이 점점 AI '모델 내부'로 흡수되고 있다는 점입니다.
+사용자가 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 계획을 유연하게 수정하는 능력입니다.
 
-- **스스로 생각하는 모델의 등장 (Test-time Compute)**
+- **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
+- **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
+
+* **실제 예시**: 
+  에이전트에게 "블로그 기사 작성"을 요청하면, 스스로 **'키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사'** 순으로 계획을 세웁니다. 만약 맞춤법 검사 도중 치명적인 논리 오류를 발견하면, 본문 작성 단계로 스스로 되돌아가 계획을 수정하고 다시 쓰는 자가 성찰(Self-Reflection)을 거칩니다.
+
+---
+
+### 2. 기억 및 상태 관리 능력 (Memory)
+
+현재 나누는 대화의 즉각적인 흐름(단기 기억)뿐만 아니라, 과거의 경험과 누적된 지식(장기 기억)을 필요할 때마다 영속적으로 꺼내어 쓰는 능력입니다.
+
+- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
+- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
+
+* **실제 예시**: 
+  에이전트에게 "어제 작업하던 파이썬 소스코드의 오류를 이어서 수정해줘"라고 요청하는 경우입니다. 에이전트는 데이터베이스에 누적된 과거 대화 히스토리와, 벡터 DB에 저장되어 있는 소스코드의 예전 상태 정보를 동적으로 인출(Retrieval)해 와 대화 맥락을 끊김 없이 이어갑니다.
+
+---
+
+### 3. 도구 활용 및 실행 능력 (Tool Use & Action)
+
+인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행 등 컴퓨터 세상의 다양한 소프트웨어를 직접 연결하고 작동시키는 손과 발 역할을 의미합니다.
+
+* **실제 예시**: 
+  복잡한 나눗셈 연산을 해야 할 때 직접 계산기 도구를 호출해 오차 없이 연산하고, 최신 주식 시세를 알기 위해 증권사 API를 호출하며, 작성한 코드가 잘 돌아가는지 검증하기 위해 격리된 샌드박스 컴퓨터 환경(Docker)을 구동해 스크립트를 직접 실행합니다.
+
+---
+
+### 4. 상호 통신 및 협업 능력 (Collaboration)
+
+혼자서 모든 일을 처리하는 것이 아니라, 다른 역할을 가진 전문 에이전트나 사용자 시스템과 표준 규격으로 메시지를 주고받으며 큰 작업을 분산 처리하는 능력입니다.
+
+* **실제 예시**: 
+  "이 프로젝트의 보안 취약점 보고서를 작성해줘"라는 명령을 내렸을 때의 상황입니다. 보안 에이전트가 소스코드를 스캔해 취약점을 나열하면, 인프라 에이전트가 가상 머신 설정을 검토하고, 최종적으로 리뷰어 에이전트들이 보고서의 신뢰성을 상호 검증하여 하나의 완성된 산출물을 합작해 냅니다.
+
+---
+
+## 🚀 패러다임 전환: Model eats the Scaffolding (모델이 외부 시스템을 흡수하다)
+
+현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 제어 시스템(Scaffolding, 에이전트의 구동을 돕는 외부 뼈대 구조)이 수동으로 제어하던 기능들이 점점 AI 모델 내부로 흡수되고 있는 현상입니다.
+
+- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
+
+- **스스로 생각하는 모델의 등장 (Test-time Compute, 추론 시점 추가 연산)**
   최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들은 외부 시스템이 루프를 돌려주지 않아도, 모델 스스로 출력을 내보내기 전에 내부적으로 계획을 세우고(Planning) 스스로 오류를 성찰(Reflection)하는 과정을 완료합니다.
 - **인지와 집행의 명확한 역할 분담**
-  이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있으며, 외부의 **에이전트 인프라(Harness)**는 안전한 실행 환경(Sandboxing), 권한 통제, 상태 관리처럼 모델이 직접 할 수 없는 물리적 보호막 역할을 수행하는 방향으로 진화하고 있습니다.
+  이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있습니다. 반면 외부의 **에이전트 인프라(Harness, 에이전트 실행 및 도구 제어 장치)**는 안전한 실행 환경(Sandboxing, 격리 환경 실행), 권한 통제, 상태 관리처럼 모델이 직접 수행하기 어려운 물리적 보호막 역할을 담당하는 방향으로 진화하고 있습니다.
 - **차별화 요소(Alpha)의 이동**
-  단순히 계획을 짜는 루프를 코드로 구현하는 것의 가치는 줄어들고, 이제는 복잡한 인프라를 실시간으로 제어하고 서로 다른 규격을 가진 이종 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력이 되었습니다.
+  단순히 계획을 짜는 흐름을 코드로 구현하는 것의 가치는 점차 줄어들고 있습니다. 이제는 복잡한 인프라를 실시간으로 제어하고, 서로 다른 규격을 가진 다양한 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력으로 부상하고 있습니다.
 
 ---

lib/make_slide_for_260724_seminar/chapters/0_intro_script.md

@@ -7,7 +7,7 @@
 ### 🎴 Slide 1: 타이틀 (표지)
 * **슬라이드 제목**: AI Multi-Agents 오케스트레이션 기술 동향 및 사례 — 정적 AI 모델에서 자율적 AI 에이전트로의 패러다임 전환
 * **대본**:
-  > "안녕하세요, 여러분. 오늘 세미나 발표를 맡은 발표자입니다. 
+  > "안녕하세요, 여러분. 오늘 특강을 진행하게 된 ○○○입니다. 
   > 오늘 우리가 함께 나눌 주제는 **'AI Multi-Agents 오케스트레이션 기술 동향 및 사례'**입니다. 
   > 최근 AI 시장은 매우 빠르게 변하고 있습니다. 그중에서도 가장 눈에 띄는 변화가 바로, 단순히 대답만 하던 정적인 AI 모델이 스스로 알아서 일을 처리하는 '자율형 AI 에이전트'로 바뀌고 있다는 점입니다. 
   > 오늘 이 세미나를 통해 AI 에이전트가 무엇이고, 여러 에이전트가 어떻게 협업하는지 그 인프라와 최신 트렌드를 함께 살펴보겠습니다."
@@ -30,8 +30,8 @@
 * **대본**:
   > "말로만 들으면 두 개념이 잘 와닿지 않으실 텐데요. 쉬운 예시를 하나 들어보겠습니다. 
   > 청중 여러분 중 한 분이 AI에게 **'멀티 에이전트 관련 최신 연구 동향을 조사하고 보고서로 저장해줘'**라는 명령을 내렸다고 해봅시다. 
-  > 이때 **AI 모델(LLM)**은 자신의 머릿속, 즉 학습 데이터에 들어있는 기존 연구 목록을 꺼내서 텍스트로 친절하게 설명해 줍니다. 답변은 아주 훌륭하지만, 인터넷에서 최신 논문을 검색해 오거나 컴퓨터 디스크에 보고서 파일을 직접 저장하는 등의 '물리적인 행동'은 수행하지 못합니다. 
+  > 이때 **AI 모델(LLM)**은 자신의 머릿속, 즉 이미 학습된 데이터에 들어있는 기존 연구 목록을 꺼내 텍스트로 설명해 줍니다. 설명 자체는 훌륭하지만, 실시간으로 최신 논문을 인터넷에서 찾아오는 행동은 하지 못합니다. 당연히 보고서 파일을 여러분의 디스크에 직접 저장하는 물리적인 작업도 수행할 수 없습니다. 
-  > 반면 **AI 에이전트(Agent)**는 명령을 받자마자 스스로 필요한 일감들을 정리하고 직접 인터넷 검색을 개시합니다. 학술 API에 접속해 실시간으로 최신 논문을 검색하고, PDF 파일을 직접 다운로드해서 본문을 요약한 뒤, 최종 결과물 보고서 파일을 여러분의 디스크 폴더에 실제로 생성하고 저장까지 완료해 줍니다."
+  > 반면 **AI 에이전트(Agent)**는 명령을 받자마자 스스로 필요한 행동 단계들을 계획합니다. 이어서 학술 API에 접속해 최신 논문을 실시간으로 검색하고 관련 PDF 파일을 직접 다운로드합니다. 마지막으로 그 본문을 요약한 보고서 파일을 여러분의 컴퓨터 폴더에 실제로 만들고 저장까지 완수합니다."
 
 ---
 
@@ -52,26 +52,64 @@
   > 그래서 저는 이 둘을 **'운전자'와 '자율주행 차량'**으로 비유하곤 합니다. 
   > 여기서 **AI 모델**은 차에 타고 있는 **운전자(뇌)**입니다. '다음 교차로에서 우회전하고 멈추자'라는 고차원적인 인지 판단을 담당하죠. 
   > **AI 에이전트**는 운전자의 판단을 가속 페달과 바퀴 구동력으로 변환하는 **자율주행 차량 시스템 전체**입니다. 
-  > 특히 차량 시스템은 운전자가 실수로 절벽으로 돌진하려 할 때 자동으로 브레이크를 밟아 차단하는 **안전 가드레일** 역할이나, 통신이 끊겼을 때 스스로 갓길에 차를 대는 **예외 통제**, 그리고 여러 에이전트의 합의를 이끄는 **의사결정 통제** 같은 시스템 수준의 독자적인 판단을 수행합니다. 즉, 운전자 혼자서는 달릴 수 없으며, 차량 시스템이 있어야 비로소 목적지에 안전하게 도착할 수 있는 것입니다."
+  > 특히 차량 시스템은 운전자가 실수로 절벽으로 돌진하려 할 때 자동으로 브레이크를 밟아 차단하는 **안전 가드레일** 역할이나, 통신이 끊겼을 때 스스로 갓길에 차를 대는 **예외 통제**, 그리고 여러 에이전트의 합의를 이끄는 **합의 형성** 같은 시스템 수준의 독자적인 판단을 수행합니다. 즉, 운전자 혼자서는 달릴 수 없으며, 차량 시스템이 있어야 비로소 목적지에 안전하게 도착할 수 있는 것입니다."
 
 ---
 
-### 🎴 Slide 6: 🛠️ AI 에이전트가 갖춰야 할 4대 필수 기능
+### 🎴 Slide 6: 🛠️ AI 에이전트가 갖춰야 할 4대 필수 기능 (개요)
 * **슬라이드 제목**: AI 에이전트가 갖춰야 할 4대 필수 기능
 * **대본**:
-  > "그렇다면 단순한 대화형 앱이 아니라, 진짜 자율주행 차량 같은 온전한 'AI 에이전트'가 되기 위해 갖추어야 할 4대 필수 기능은 무엇일까요? 
+  > "그렇다면 단순한 대화형 앱이 아니라, 진짜 자율주행 차량 같은 온전한 'AI 에이전트'가 되기 위해 소프트웨어 시스템 차원에서 제공해야 할 4대 필수 기능은 무엇일까요?
-  > 첫째는 **목표를 쪼개고 계획하는 기능(Planning)**입니다. 최종 목표만 주어지면 실행 계획을 짜고 자가 성찰을 통해 계획을 수정해 나갑니다. 
+  > 첫 번째는 계획 및 추론(Planning), 두 번째는 기억 및 상태 관리(Memory), 세 번째는 도구 활용 및 실행(Tool Use & Action), 그리고 마지막 네 번째는 상호 통신 및 협업(Collaboration)입니다.
-  > 둘째는 **상태와 기억을 관리하는 기능(Memory)**입니다. 현재 대화의 단기 기억과 과거 경험이나 지식을 RAG로 불러오는 장기 기억을 결합해 다룹니다. 
+  > 이제 각각의 기능이 구체적으로 어떤 역할을 하고 어떤 식으로 작동하는지 실제 사례와 함께 하나씩 소개해 드리겠습니다."
-  > 셋째는 **물리적 환경과 연동되는 기능(Tool Use & Action)**으로, 인터넷, API, 파일 시스템 및 격리된 코드 실행 환경을 다루는 핵심 손발이 됩니다. 
-  > 마지막 넷째는 **서로 소통하고 협업하는 기능(Collaboration)**입니다. 이종 에이전트들이 통신 프로토콜을 통해 작업을 나누어 분산 처리하는 기반입니다."
 
 ---
 
-### 🎴 Slide 7: 🚀 패러다임 쉬프트: Model eats the Scaffolding
+### 🎴 Slide 6-1: 1. 계획 및 추론 능력 (Planning)
-* **슬라이드 제목**: 패러다임 쉬프트: Model eats the Scaffolding
+* **슬라이드 제목**: 1. 계획 및 추론 능력 (Planning)
 * **대본**:
-  > "마지막으로 에이전트 기술의 가장 핵심적인 트렌드인 **'Model eats the Scaffolding'** 즉, **모델이 에이전트 제어 시스템을 흡수하는 현상**에 대해 말씀드리겠습니다. 
+  > "첫 번째는 **계획 및 추론 능력**입니다. 최종 목표만 주면 스스로 실행 가능한 세부 단계를 쪼개고 설계하며, 실패 시 자가 성찰을 통해 유연하게 계획을 수정하는 기능입니다.
-  > 과거에는 에이전트 시스템 코드로 구현하던 계획(Planning)이나 자가 성찰(Reflection) 루프가, 최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들을 필두로 **AI 모델의 내부 가중치 추론 메커니즘**으로 녹아들어가고 있습니다. 
+  > 예를 들어, 에이전트에게 '블로그 기사 작성'을 요청해 보겠습니다. 
-  > 이에 따라 '인지와 계획'은 **AI 모델**이 전담하게 되고, 외부의 **에이전트 인프라(Harness)**는 샌드박싱 보안, 실행 권한 차단, 세션 보존 같은 '물리적 집행과 통제'에만 고도로 집중하는 방향으로 분리되고 있습니다. 
+  > 그러면 에이전트는 먼저 '키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사' 순으로 머릿속으로 로드맵을 그립니다. 
-  > 결국 단순히 계획 루프를 짜는 것의 차별적 가치는 점차 낮아지고 있으며, 복잡한 다중 에이전트 간의 조율과 고성능 인프라 제어가 새로운 경쟁력으로 떠오르고 있습니다. 
+  > 그러다 마지막 오탈자 검사 도중 치명적인 흐름 오류를 발견하면, 처음으로 돌아가는 게 아니라 본문 집필 단계로만 스스로 돌아가 내용을 고쳐 쓰는 영리함을 보입니다. 이것이 바로 인지적인 계획 능력입니다."
-  > 그럼 다음 챕터부터 이러한 에이전트 구현을 가능하게 하는 기술적 원리들을 하나씩 자세히 알아보겠습니다. 감사합니다."
+
+---
+
+### 🎴 Slide 6-2: 2. 기억 및 상태 관리 능력 (Memory)
+* **슬라이드 제목**: 2. 기억 및 상태 관리 능력 (Memory)
+* **대본**:
+  > "두 번째 필수 기능은 **기억 및 상태 관리 능력**입니다.
+  > 지금 막 나눈 대화 맥락을 기억하는 단기 기억과, 과거의 수많은 작업 이력이나 데이터베이스의 지식을 필요할 때마다 영구적으로 꺼내 쓰는 장기 기억을 결합해 다루는 능력입니다.
+  > 예컨대 '어제 짜던 파이썬 코드의 에러를 이어서 고쳐줘'라고 지시하는 상황이 그렇습니다. 
+  > 에이전트는 어제의 대화 로그와 소스코드의 직전 수정본을 장기 기억 데이터베이스(벡터 DB 등)에서 스스로 찾아내어 가져옵니다. 덕분에 우리는 끊김 없이 맥락을 유지하며 협업을 이어갈 수 있습니다."
+
+---
+
+### 🎴 Slide 6-3: 3. 도구 활용 및 실행 능력 (Tool Use & Action)
+* **슬라이드 제목**: 3. 도구 활용 및 실행 능력 (Tool Use & Action)
+* **대본**:
+  > "세 번째는 **도구 활용 및 실행 능력**입니다. 인터넷 검색, 외부 API 호출, 파일 제어 등 컴퓨터 세상의 다양한 도구들을 안전하게 연결하고 조작하는 '에이전트의 손과 발'입니다.
+  > 실제로 복잡한 나눗셈이나 곱셈이 필요하면 수학 도구(계산기)를 꺼내 오차 없이 정밀 연산합니다. 
+  > 또 최신 정보가 필요하면 실시간 API나 브라우저를 구동하고, 작성한 코드가 작동하는지 검사하기 위해 컴퓨터 안에 격리된 실행 환경인 Docker 컨테이너를 직접 띄워 스크립트를 자율 실행하기도 합니다."
+
+---
+
+### 🎴 Slide 6-4: 4. 상호 통신 및 협업 능력 (Collaboration)
+* **슬라이드 제목**: 4. 상호 통신 및 협업 능력 (Collaboration)
+* **대본**:
+  > "마지막 네 번째 기능은 **상호 통신 및 협업 능력**입니다. 
+  > 혼자 일하는 게 아니라 전문 분야가 다른 에이전트들이나 사용자 시스템과 표준 프로토콜로 소통하며 대형 프로젝트를 분산 처리하는 능력입니다.
+  > 가령 '보안 취약점 보고서를 작성해줘'라는 과업이 주어졌을 때를 상상해 보세요. 
+  > 코드를 전문으로 분석하는 보안 에이전트가 문제점을 뽑아내고, 클라우드 전문 에이전트가 가상 머신 보안을 검토합니다. 
+  > 그리고 최종적으로 리뷰어 에이전트들이 모여 보고서 내용을 교차 검증하고 합의하여 하나의 완벽한 최종 보고서를 완성해 냅니다."
+
+---
+
+### 🎴 Slide 7: 🚀 패러다임 전환: Model eats the Scaffolding
+* **슬라이드 제목**: 패러다임 전환: Model eats the Scaffolding
+* **대본**:
+  > "마지막으로 에이전트 기술의 가장 핵심적인 변화인 **'Model eats the Scaffolding'**에 대해 말씀드리겠습니다. 이는 모델이 에이전트 외부 제어 시스템을 흡수하는 현상을 뜻합니다. 
+  > 과거에는 에이전트를 작동시키기 위해 계획(Planning)이나 자가 성찰(Reflection) 루프를 외부 코드로 직접 구현해야 했습니다. 하지만 최근 출시된 제미나이 씽킹(Gemini Thinking)이나 오픈AI의 o1, o3 같은 모델들은 이러한 능력을 모델 자체의 내부 추론 과정으로 소화해 냅니다. 
+  > 이에 따라 고차원적인 논리 설계와 계획 수립은 **AI 모델**이 전담하는 형태로 빠르게 바뀌고 있습니다. 외부의 **에이전트 인프라(Harness, 에이전트 실행 제어 장치)**는 보안 샌드박싱(격리 환경 실행), 권한 차단, 세션 관리 같은 물리적 집행과 통제에 집중하는 구조로 이원화되고 있습니다. 
+  > 결과적으로 단순히 실행 루프를 만드는 구현 방식은 그 경쟁력을 잃어가고 있습니다. 대신 다중 에이전트들을 표준화된 프로토콜로 유기적으로 엮어내는 오케스트레이션과 인프라 제어 기술이 새로운 차별화 요소로 떠오르는 중입니다. 
+  > 그럼 바로 시작하겠습니다."

lib/make_slide_for_260724_seminar/chapters/1_engineering.md

@@ -4,40 +4,79 @@ marp: true
 
 # 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
 
-## AI 모델(LLM) vs AI 에이전트
+성공적인 AI 에이전트 시스템을 구현하기 위해서는 단순히 모델에게 프롬프트를 입력하는 것을 넘어, **모델 제어**, **정보 연동**, **물리적 환경 연결**을 유기적으로 엮어내는 3가지 핵심 엔지니어링 기법이 필요합니다.
-AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
 
-LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
+1. **프롬프트 엔지니어링 (Prompt Engineering)**: 에이전트의 페르소나와 사고 방식(추론 가이드라인)을 규정하는 작업입니다.
-1. **Planning (계획 및 추론)**
+2. **컨텍스트 엔지니어링 (Context Engineering)**: 대화 흐름을 끊김 없이 보존하고 관련 데이터를 적시에 제공하는 정보 정리 작업입니다.
-   - **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
+3. **하네스 엔지니어링 (Harness Engineering)**: 격리된 환경에서 다양한 소프트웨어 도구를 안전하게 조작할 수 있는 물리적 손발을 달아주는 작업입니다.
-   - **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
-2. **Memory (기억 장치)**
-   - **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
-   - **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
-
-- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
-
-## 3대 핵심 엔지니어링 기법
-성공적인 AI 에이전트 구현을 위해서는 모델 제어, 정보 연동, 물리적 환경 연결을 최적화하는 3대 엔지니어링 기법이 필수적으로 수반되어야 합니다.
-
-- ### 프롬프트 엔지니어링 (Prompt Engineering)
-  에이전트에게 명확한 역할 페르소나와 추론 가이드라인을 설계하고, 효율적인 추론 경로를 유도하기 위해 프롬프트 구조와 예시(Few-shot)를 최적화하는 기법입니다.
-  - **역할 페르소나 설계**: 에이전트가 특정 전문 도메인 지식과 행동 양식을 고수할 수 있도록 페르소나를 규정
-  - **추론 가이드라인 설계**: ReAct와 같은 사고 단계를 정의하여 모델이 계획 단계를 건너뛰지 않고 순차적으로 사고하도록 제어
-  - **Few-shot 최적화**: 최적의 추론 경로 및 응답 포맷 예시를 프롬프트에 제공하여 응답 일관성을 극대화
-
-- ### 컨텍스트 엔지니어링 (Context Engineering)
-  대화 상태(State)와 흐름을 보존하며, 외부 데이터베이스나 기억(Memory) 장치로부터 필요한 정보를 적시에 모델의 컨텍스트 윈도우에 효율적으로 바인딩하고 공급하는 기술입니다. 단일 에이전트 관점에서는 제한된 컨텍스트 공간 내에서 정보 밀도를 극대화하는 설계가 핵심입니다.
-  - **대화 상태 및 흐름 보존**: 이전 턴의 작업 상태와 대화 맥락을 유실 없이 세션 전반에 유지
-  - **적시 동적 바인딩**: 외부 RAG 검색기나 메모리 캐시로부터 관련성이 가장 높은 데이터만을 선별하여 컨텍스트 윈도우에 결합
-  - **메모리 압축 및 정리**: 불필요한 과거 로그를 요약하거나 중요 상태 구조체 위주로 정제하여 토큰 윈도우 효율성 제고
-
-- ### 하네스 엔지니어링 (Harness Engineering)
-  에이전트가 계산기, 웹 브라우저, 외부 API 및 파일 시스템 등의 물리적 도구(Tools/Tool Use)에 안전하고 유연하게 연결되어 명령을 실행할 수 있도록 연결 고리를 결합하는 도구 연동 인터페이스 기술입니다.
-  - **물리 인터페이스 결합**: LLM의 도구 호출 의도(Tool Call)를 가로채어 실제 운영체제나 네트워크 상의 실행 스크립트로 전달하고 실행 결과를 모델에 반환
-  - **보안 샌드박싱**: 임의 코드 실행이나 파일 훼손 방지를 위해 파일 시스템 격리 및 API 호출 권한 등의 안전 제어막 형성
-  - **도구 활용 (Tool Use)**: 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력
-
-  ![Screenshot 2026-06-25 at 9.39.07 pm](../../../assets/images/Screenshot%202026-06-25%20at%209.39.07%20pm.png)
 
 ---
+
+### 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
+
+모델의 발전과 자체 추론 기능의 향상으로 예전만큼 미시적인 프롬프트 트릭에 집착할 필요는 줄어들고 있습니다. 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 뼈대**입니다. 구체적이고 명확한 작동 지침을 만들기 위해 프롬프트 작성 시 반드시 반영해야 할 3대 핵심 고려사항입니다.
+
+- **역할 및 페르소나 지시 (Role)**
+  에이전트에게 전문 도메인 지식과 행동 경계를 지정해 줍니다. (예: *"너는 주니어 개발자를 코칭하는 꼼꼼한 테크리더 에이전트다. 직접 고치지 말고 가이드라인만 제공해라."*)
+- **구체적인 작업 예시 제공 (Few-shot)**
+  원하는 출력 형식이나 중간 추론 과정의 모범 예시를 제공하여, 에이전트의 답변 일관성과 가독성을 극대화합니다.
+- **자가 검증 방법 제시 (Verification)**
+  에이전트 스스로 작업의 무결성을 점검하게 하거나, 외부 시스템이 실행 결과를 확인 및 통제할 수 있도록 정형화된 출력 규격(예: 최종 통과 시 `[VERDICT: PASS]` 명시 요구)을 정의해 줍니다.
+
+---
+
+### 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
+
+에이전트가 단번에 대답하지 않고 단계별로 계획을 세워 도구를 사용하도록 프롬프트 구조를 강제하는 기법입니다.
+
+```text
+[System Prompt]
+너는 복잡한 수식을 계산하는 수학 에이전트다. 다음 형식으로 사고해라:
+- Thought: 문제 해결을 위한 다음 행동 계획을 작성해라.
+- Action: 호출할 도구 이름과 인자값을 JSON으로 적어라. (예: Calculator)
+- Observation: 도구 실행 결과가 여기에 채워질 것이다.
+- Thought: 실행 결과를 바탕으로 성찰하고, 필요하면 다음 Action을 설계해라.
+```
+
+---
+
+### 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
+
+에이전트가 다루는 대화 맥락과 작업 상태(State)를 효율적으로 정제하고, 수많은 외부 정보 중 **지금 꼭 필요한 관련 데이터(RAG)**만을 선별하여 제한된 AI의 기억 공간(컨텍스트 윈도우)에 밀도 높게 채워 넣는 기술입니다.
+
+* **핵심 설계 요소**:
+  - **대화 상태 보존**: 이전 턴의 작업 결과를 유실 없이 보존
+  - **동적 바인딩**: 외부 RAG 검색기에서 관련도 높은 중요 데이터만 적시에 필터링하여 공급
+  - **메모리 압축**: 불필요한 과거 로그는 요약하고, 핵심 현재 상태 구조체만 유지해 토큰 낭비 방지
+* **에이전트 상태 보존 예시 (State JSON)**:
+  ```json
+  {
+    "task_id": "job_10294",
+    "current_working_directory": "/workspace/src",
+    "error_logs": ["SyntaxError: unexpected EOF while parsing at line 14"],
+    "completed_subtasks": ["1. 소스코드 로드 완료", "2. 오류 라인 식별"],
+    "next_action_required": "오류 라인 14의 괄호 닫힘 확인 및 수정 스크립트 작성"
+  }
+  ```
+
+---
+
+### 3️⃣ 하네스 엔지니어링 (Harness Engineering)
+
+에이전트가 파일 시스템 제어, 브라우저 조작, 외부 API 호출 등 컴퓨터 세상의 다양한 도구들을 안전하게 가동할 수 있도록 **물리적 인터페이스(연결 고리)**를 구성하는 기술입니다.
+
+* **핵심 설계 요소**:
+  - **도구 호출 가로채기(Intercepting)**: 모델이 내놓은 도구 호출 의도(JSON 등)를 감지하고, 실제 터미널이나 프로그램의 함수로 전달해 구동함
+  - **보안 샌드박싱 (Sandboxing)**: 에이전트가 악성 코드나 파괴적인 명령어를 무단 실행하지 않도록 격리된 가상 환경을 구축하고 권한을 통제함
+* **물리 인터페이스 도구 결합 예시**:
+  ```
+  [LLM의 출력] ──> "Action: execute_command, args: { cmd: 'ls -la' }"
+                          │ (하네스가 이를 가로챔)
+                          ▼
+  [하네스 제어기] ──> 격리된 Docker 샌드박스 내부에서 'ls -la' 실제 실행
+                          │ (실행 결과 가로챔)
+                          ▼
+  [LLM의 입력] <── "Observation: total 12\ndrwxr-xr-x 3 user..." (모델에 반환)
+  ```
+
+  ![Harness Diagram](../../../assets/images/Screenshot%202026-06-25%20at%209.39.07%20pm.png)

lib/make_slide_for_260724_seminar/chapters/1_engineering_script.md

@@ -0,0 +1,64 @@
+# 🎙️ 특강 발표 대본 스크립트 — 1. Engineering
+
+본 문서는 `1_engineering.md` 슬라이드에 대응하는 발표용 대본 스크립트입니다. 청중의 이해를 돕기 위해 친절한 구어체 존댓말로 작성되었습니다.
+
+---
+
+### 🎴 Slide 1: 1장 타이틀 및 개요
+* **슬라이드 제목**: 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
+* **대본**:
+  > "그럼 이제 본격적으로 1장, **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**을 살펴보겠습니다. 
+  > 단순히 똑똑한 AI 모델을 가져온다고 해서 알아서 일하는 에이전트가 완성되지는 않습니다. 
+  > 모델을 정밀하게 제어하고, 실시간 대화 정보를 관리하며, 실제 물리적 환경에 연결하기 위해 세 가지 엔지니어링 분야가 유기적으로 작동해야 합니다. 
+  > 첫 번째는 머리를 세팅하는 **프롬프트 엔지니어링**, 두 번째는 기억을 구성하는 **컨텍스트 엔지니어링**, 세 번째는 실제 손발을 달아주는 **하네스 엔지니어링**입니다. 
+  > 각 기법이 구체적으로 어떤 의미를 가졌는지 실제 사례와 함께 짚어보겠습니다."
+
+---
+
+### 🎴 Slide 2: 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
+* **슬라이드 제목**: 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
+* **대본**:
+  > "첫 번째 기둥인 **프롬프트 엔지니어링**입니다. 
+  > 최근 AI 모델들이 비약적으로 발전하고 자체적인 추론 능력이 향상되면서, 예전만큼 단어나 기호 하나에 집착하는 미시적인 프롬프트 트릭의 가치는 줄어들고 있습니다. 
+  > 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 가장 중요한 뼈대**입니다. 에이전트 시스템을 설계할 때 프롬프트에 반드시 반영해야 하는 세 가지 고려사항이 있습니다. 
+  > 첫째는 **역할 및 페르소나 지시**입니다. 에이전트가 어떤 전문 지식 범위와 행동 규칙을 고수해야 하는지 경계를 지정해 주는 것입니다. 
+  > 둘째는 **구체적인 작업 예시 제공, 즉 Few-shot**입니다. 에이전트가 내놓는 답변이 예외 없이 일관된 양식과 톤을 유지하도록 모범 예시를 제공하는 것입니다. 
+  > 셋째는 **자가 검증 방법 제시**입니다. 에이전트 스스로 결과물을 검사하게 하거나, 외부 시스템이 실행 결과를 확인하고 안전하게 통제할 수 있도록 정형화된 출력 규격(예: 통과 시 `[VERDICT: PASS]` 명시 요구)을 심어두는 것입니다. 이 세 요소가 균형을 이루어야 비로소 신뢰할 수 있는 좋은 프롬프트가 완성됩니다."
+
+---
+
+### 🎴 Slide 2-1: 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
+* **슬라이드 제목**: 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
+* **대본**:
+  > "그렇다면 이 고려사항들이 반영된 실제 프롬프트 구조는 어떨까요? 
+  > 대표적인 기법이 바로 화면에 보이는 **ReAct(Reason + Action) 사고 방식**을 강제하는 템플릿입니다. 
+  > 우리는 에이전트에게 단순히 '문제를 풀어라' 하고 결과만 묻지 않습니다. 
+  > 대신 'Thought(문제를 풀기 위한 계획을 먼저 세우고) ➡️ Action(네가 직접 실행할 도구의 인자값을 JSON으로 적고) ➡️ Observation(도구의 실제 실행 결과를 눈으로 보고 분석해라)'이라는 단계적 생각의 길을 열어줍니다. 
+  > 이렇게 구조화된 사고 가이드를 프롬프트에 강제함으로써, AI가 섣불리 엉터리 답을 찍지 않고, 신중하게 도구를 실행하며 그 결과를 토대로 정답을 향해 차근차근 나아가게 제어할 수 있습니다."
+
+---
+
+### 🎴 Slide 3: 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
+* **슬라이드 제목**: 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
+* **대본**:
+  > "두 번째 기둥은 **컨텍스트 엔지니어링**입니다. 
+  > AI 모델의 기억 공간인 '컨텍스트 윈도우'는 무한하지 않고 비용이 듭니다. 
+  > 따라서 대화 흐름을 압축하여 유지하고, 수많은 소스코드나 문서 중에서 지금 당장 필요한 핵심 데이터만 적시에 필터링하여 꽂아주는 기술이 필수적입니다. 
+  > 슬라이드 오른쪽의 에이전트 상태 보존 예시를 보겠습니다. 
+  > 에이전트는 사용자와 주고받은 20번의 긴 대화 내용을 날것 그대로 모델에 던지지 않습니다. 
+  > 대신 현재 작업 ID가 무엇인지, 지금 작업 디렉터리는 어디인지, 발생한 에러 로그는 무엇인지, 그리고 이미 끝낸 작업과 다음에 할 일은 무엇인지 등을 JSON 형태의 구조화된 데이터 상태로 압축하고 요약하여 보존합니다. 
+  > 이렇게 상태를 효율적으로 캐싱하고 정제하여 모델에 알려줌으로써, 불필요한 비용을 줄이고 답변의 정확도를 극대화할 수 있습니다."
+
+---
+
+### 🎴 Slide 4: 3️⃣ 하네스 엔지니어링 (Harness Engineering)
+* **슬라이드 제목**: 3️⃣ 하네스 엔지니어링 (Harness Engineering)
+* **대본**:
+  > "마지막 세 번째는 에이전트에게 진짜 실행 능력을 부여하는 **하네스 엔지니어링**입니다. 
+  > 아무리 모델이 훌륭한 수정 계획을 세워도, 실제 디스크에 저장하거나 코드를 컴파일할 수 없다면 에이전트라고 부를 수 없습니다. 
+  > 하네스는 모델이 내린 판단을 감지해 실제 컴퓨터 명령어(ls, python3 run 등)로 변환해 실행하고, 그 실행 결과를 다시 모델에게 바인딩해 주는 인터페이스 인프라입니다. 
+  > 슬라이드의 다이어그램을 보시면 흐름이 잘 보입니다. 
+  > 모델이 'Action: 파일 목록을 보고 싶어'라고 텍스트로 내놓으면, 에이전트 하네스 시스템이 이를 가로채서(Intercept) 실제 격리된 컴퓨터 환경(Docker 샌드박스 등)에서 명령을 수행합니다. 
+  > 그리고 그 실행 결과를 다시 'Observation: 결과는 다음과 같아'라고 정형화해 모델의 눈앞에 가져다줍니다. 
+  > 또한, 모델이 혹시나 컴퓨터를 망가뜨릴 수 있는 명령을 내리지 못하도록 안전망(Sandboxing)을 씌워주는 것 역시 하네스 엔지니어링의 핵심 의무입니다. 
+  > 이 3대 기술이 완벽히 맞물렸을 때, 비로소 자율형 에이전트가 단독으로 기동할 수 있게 됩니다."

lib/make_slide_for_260724_seminar/implementation_plan.md

@@ -1,64 +1,71 @@
-# Implementation Plan — SLIDE.md 특강 자료 보완 (Rev.4 / Job 5874d3da)
+# Implementation Plan — 0_intro 구어체 검토·개선 루프 (Rev.2 / Job 0fa577fa)
 
-> **Rev.4 변경 요약 (Creator 이의제기 반영, Challenge Report 91a2e3e9)**
+> **Rev.2 변경 요약 (Creator 이의제기 반영, Challenge Report 58a51e54)**
-> Rev.3 Step 2의 "사본에만 안내 주석 추가 + 검증 기준 완화" 방식을 폐기하고 **대안 A(양쪽 파일에 완전히 동일한 공통 주석 삽입)**를 채택했다.
+> - **경로 정정**: 대상 파일 경로를 전부 저장소 루트 기준 전체 경로로 통일했다. Rev.1 §6의 축약 표기(`chapters/0_intro_script.md`)는 루트에 `chapters/`가 없어 자동화 탐색 시 File Not Found를 유발할 수 있었다.
-> - 근거 1 — 동기화 유실: 본 저장소의 동기화 원칙은 `cp SLIDE.md paper_draft/SLIDE.md` 단순 복사이므로, 사본에만 존재하는 주석은 다음 동기화에서 즉시 덮어씌워져 소실된다.
+> - **통합 덱 동기화 단계 신설**: 통합 발표 자료인 `lib/make_slide_for_260724_seminar/SLIDE.md`는 챕터 파일들을 합친 최종 산출물임을 확인했다(0장 내용 포함, 328줄). 챕터만 고치고 통합 덱을 "변경 금지"로 묶어두면 최종 발표 자료에 개선 전 문장이 방치되는 모순이 맞다. 이에 **루프 중에는 동결, 최종 PASS 직후 병합·재동기화**하는 Step 5를 신설하고 완료 기준을 갱신했다.
-> - 근거 2 — 검증 단순성: "주석 1줄 제외 동일" 기준은 단순 `diff`/hash 비교를 깨뜨려 커스텀 비교 로직을 강요한다. 공통 주석이면 100% 바이트 동일성이 유지되어 `diff -q` 한 줄로 검증이 끝난다.
+> - 어투 기준(§2)과 초기 발견 사항(§3)은 Rev.1과 동일하다.
-> - 이에 따라 Step 2와 완료 기준 2번을 갱신했다. 그 외 항목은 Rev.3과 동일하다.
 
-> **Rev.3 요지 (유지)**: 본 태스크의 주 목표는 이미 달성되어 리뷰까지 통과했다(Job 1cafc914, [VERDICT: PASS], 완료 기준 9/9 충족). 본 리비전은 재작업 계획이 아니라 **(A) 달성 상태의 기록**과 **(B) 리뷰에서 지적된 비차단 후속 조치 2건 + 마무리(커밋)**만을 범위로 한다. SLIDE.md 본문 구조에 대한 추가 변경은 계획하지 않으며, Worker는 아래 Step 1~3만 수행하면 된다.
+> 이전 태스크(SLIDE.md 5개 장 보완, ~Rev.4)는 커밋 4d6423e로 완결(이력은 git에 보존), 이후 덱이 `chapters/` 구조로 재편됨. 본 계획서는 새 태스크(0_intro 어투 검토 루프)를 다룬다.
 
-## 1. 목표 및 달성 현황
+## 1. 목표
 
-원 목표: `assets/slides/lecture_summary.md`의 흐름(5개 구성 항목)에 맞춘 `SLIDE.md` 보완.
+`lib/make_slide_for_260724_seminar/chapters/0_intro.md`(슬라이드 내용 구성 노트)와 `lib/make_slide_for_260724_seminar/chapters/0_intro_script.md`(발표 대본)를 검토하여, **발표자료 작성용 노트라는 목적에 맞게 쉽고 풀어쓴 구어체 문장**으로 다듬는다. Creator 수정 → Reviewer 판정 루프를 개선사항이 없을 때까지 반복하고, 최종 PASS 후 통합 덱에 병합한다.
 
-| 항목 | 상태 |
+## 2. 어투·품질 기준 (Definition of Done 체크리스트)
-|---|---|
-| 1. AI 에이전트 구현 3대 핵심 엔지니어링 기법 (프롬프트/컨텍스트/하네스) | ✅ 완료 (§1 신규 작성) |
-| 2. AI Agent 기능 확장: MCP & SKILL | ✅ 완료 (MCP §2 재배치 + Host-Client-Server/3대 요소 보강) |
-| 3. 멀티 에이전트 협업 체계/인프라 (TMUX·crewAI·LangGraph) | ✅ 완료 (TMUX 신규, What We Need?를 §3 마감 브릿지로 배치 — Challenge 91a08208 반영) |
-| 4. ACP, A2A 표준 | ✅ 완료 (표준 필요성 도입부 + 요구사항 1·2 콜백) |
-| 5. AIoT 및 gRPC 기술 동향 | ✅ 완료 (AIoT 도입부, 요구사항 4·5 콜백, 기술 동향 요약 신규) |
-| 최종 요약 슬라이드, marp title 갱신, paper_draft 동기화 | ✅ 완료 |
 
-리뷰(Job 1cafc914) 검증 완료: 5개 장 순서 일치, 콘텐츠 유실 없음, 사실관계 일치, 이미지 자산 13개 실존, 두 SLIDE.md 사본 동일.
+Reviewer는 아래 기준으로 판정한다:
 
-## 2. 잔여 작업 (Worker 지시사항)
+1. **구어체 일관성**: 노트는 풀어쓴 설명체(-입니다/-합니다), 대본은 친절한 구어체 존댓말로 통일. 딱딱한 개조식·번역투 문장 없음.
+2. **한 문장 한 호흡**: 지나치게 긴 문장(대략 80자 이상, 절 3개 이상 중첩)은 2문장 이상으로 분할.
+3. **용어 풀이**: 영어 전문용어(Scaffolding, Harness, Test-time Compute 등)는 첫 등장 시 한 줄 우리말 풀이를 동반. "쉬운 비유" 슬라이드에는 코드 표기(`PASS` 등) 같은 기술 용어 침투 금지.
+4. **슬라이드-대본 정합성**: 대본의 슬라이드 번호·제목·핵심 용어가 노트와 일치.
+5. **의미 보존**: 어투 개선 과정에서 기술적 사실이나 논지 왜곡 없음.
+6. **Surgical**: 루프 단계에서는 두 대상 파일 외 무변경 (통합 덱 병합은 Step 5에서만 허용).
 
-### Step 1 — `.gitignore`의 `scripts/` 패턴 수정 (리뷰 발견 1)
+## 3. 현황 진단 — 초기 발견 사항 (Creator 수정 목록)
-- 현재 `.gitignore`에 `scripts/` 패턴이 있으나 `scripts/notify_mattermost.py`는 직전 커밋(9e4f286)에서 의도적으로 추가된 **추적 파일**이다. 이 패턴은 이후 scripts/에 추가될 파일을 조용히 누락시킨다.
-- 조치: `.gitignore`에서 `scripts/` 행을 **삭제**한다. (특정 하위 산출물만 무시해야 할 필요가 확인되면 그때 구체 경로로 다시 추가)
 
-### Step 2 — 사본 안내 공통 주석 삽입 (리뷰 발견 2, Rev.4 개정)
+### `lib/make_slide_for_260724_seminar/chapters/0_intro.md`
-- 배경: `paper_draft/`에는 `assets/`가 없어 사본 위치 기준으로 이미지 상대경로가 해석되지 않는다(원본부터 존재하던 조건).
+- **F1 (구조·정합, 필수)**: 파일 상단의 레거시 front-matter(title/description)와 동기화 NOTE 주석은 구(舊) 루트 SLIDE.md 시절의 잔재로, **챕터 파일에서는 사실이 아니다**. 형제 챕터(`1_engineering.md`)와 동일하게 `marp: true`만 남기고 title/description/NOTE를 제거한다. ⚠️ 단, 이 제거는 **챕터 파일에만 해당**한다 — 통합 덱 `SLIDE.md`의 front-matter와 NOTE는 그 위치에서는 여전히 유효하므로(paper_draft 사본 실존 확인) Step 5 병합 시 보존해야 한다.
-- 조치 (**대안 A — 양쪽 공통 주석**):
+- **F2 (어투)**: `## 패러다임 쉬프트` 절의 2·3번 bullet처럼 한 문장에 절이 3개 이상 중첩된 장문이 있다. 기준 2에 따라 분할한다.
-  1. 루트 `SLIDE.md`의 front-matter 종료(`---`) 직후에 아래 HTML 주석 1줄을 삽입한다:
+- **F3 (용어)**: `Scaffolding`, `Test-time Compute`, `Harness`가 풀이 없이 등장 — 첫 등장 시 짧은 우리말 풀이를 추가. 🚗 비유 슬라이드의 "합의 형성" bullet에 있는 `` `PASS`/`NOT PASS` `` 코드 표기는 비유 톤과 어긋나므로 "통과/반려 판정을 모아 최종 결정을 내리는" 식의 풀어쓴 표현으로 교체.
-     `<!-- NOTE: 이 문서의 동기화 사본이 paper_draft/SLIDE.md에 존재합니다. 이미지 상대경로는 루트 기준이므로 렌더링은 루트 SLIDE.md로 수행하세요. -->`
+- **F4 (표기 통일)**: 제목의 "패러다임 쉬프트"는 외래어 표기법상 "시프트"이며, 같은 문서 앞부분에서는 "패러다임 전환"을 사용 중 — "패러다임 전환"으로 통일 권장(영문 부제 "Model eats the Scaffolding"은 유지).
-  2. 그 후 `cp SLIDE.md paper_draft/SLIDE.md`로 재동기화하여 두 파일의 **100% 바이트 동일성**을 유지한다.
-- 금지: 사본에만 다른 내용 추가, 심볼릭 링크, 이미지 경로 재작성. 동일성 검증은 예외 없이 `diff -q` 완전 일치 기준.
 
-### Step 3 — 커밋
+### `lib/make_slide_for_260724_seminar/chapters/0_intro_script.md`
-- 대상: `SLIDE.md`, `paper_draft/SLIDE.md`, `.gitignore`(Step 1 수정 포함), `.env.example`, `implementation_plan.md`. (`AGENTS.md`는 이번 태스크 산출물이 아니므로 커밋 대상에서 제외하고 보류)
+- **F5 (어색한 자기소개)**: Slide 1 대본 "오늘 세미나 발표를 맡은 발표자입니다"는 placeholder 티가 나는 어색한 문장 — "안녕하세요, 오늘 특강을 진행하게 된 ○○○입니다"처럼 자연스러운 인사로 수정(이름은 placeholder 허용).
-- 커밋 메시지(제안): `docs: restructure SLIDE.md lecture deck around 5-part outline with bridge structure`
+- **F6 (오해 소지 마무리)**: Slide 7 대본 말미의 "감사합니다"는 발표 전체가 끝난 듯한 인상을 준다. 인트로 챕터의 끝이므로 "그럼 바로 시작하겠습니다" 같은 전환 멘트로 교체.
-- 커밋 전 최종 확인: `git diff --stat`으로 의도한 파일만 스테이징되었는지 검토.
+- **F7 (호흡)**: Slide 3·7 대본에 3줄 이상 이어지는 장문이 있어 낭독 호흡이 길다 — 기준 2에 따라 문장 분할.
+- **F8 (정합성)**: Slide 5 대본의 "의사결정 통제"와 노트의 "합의 형성(Consensus)" 용어가 어긋난다 — 한쪽으로 통일(권장: 둘 다 "합의 형성" 계열, F3 수정과 연동).
 
-## 3. 완료 기준 (Reviewer 판정 기준)
+## 4. 작업 절차 (수정-리뷰 루프)
 
-1. `.gitignore`에 `scripts/` 패턴이 없다.
+1. **Creator**: §3의 F1~F8을 두 대상 파일에 반영한다. 목록 밖의 임의 개서(전면 재작성)는 금지 — 지적 항목 중심의 수술적 수정. 이 단계에서 통합 `SLIDE.md`는 건드리지 않는다.
-2. 루트 `SLIDE.md`와 `paper_draft/SLIDE.md` **양쪽 모두**에 동일한 사본 안내 주석이 있고, 두 파일이 `diff -q` 기준 완전히 동일하다.
+2. **Reviewer**: §2 체크리스트 6개 기준으로 두 파일을 재검토한다. 신규 발견 사항이 있으면 F-번호를 이어 붙여 목록화하고 `[VERDICT: NOT PASS]`로 반려한다.
-3. SLIDE.md 본문의 구조·내용은 리뷰 통과본(PASS 시점)에서 주석 1줄 삽입 외에 변경되지 않았다.
+3. 반려 시 Creator는 신규 목록만 반영하고 2로 돌아간다. **Reviewer가 신규 발견 없음으로 `[VERDICT: PASS]`를 내면 루프 종료 → Step 5로 진행.**
-4. 커밋이 존재하며 의도한 파일만 포함한다 (`AGENTS.md` 미포함).
 
-## 4. 대상 파일
+## 5. 최종 PASS 후 통합 덱 병합 (Rev.2 신설)
 
-- 수정: `.gitignore`, `SLIDE.md`(공통 주석 1줄), `paper_draft/SLIDE.md`(루트본 재복사)
+1. `lib/make_slide_for_260724_seminar/SLIDE.md`의 0장(인트로) 구간 — 첫 슬라이드(덱 제목)부터 `## 패러다임 …(Model eats the Scaffolding)` 절 끝(1장 시작 직전)까지 — 을 확정된 `chapters/0_intro.md` 내용으로 교체한다.
-- 커밋: 상기 + `.env.example`, `implementation_plan.md`
+   - 이때 통합 덱의 **front-matter(title/description/marp)와 NOTE 주석은 보존**한다 (챕터 파일에서 제거된 것과 무관하게 통합 덱 위치에서는 유효).
-- 변경 금지: `SLIDE.md` 본문 구조, `assets/slides/lecture_summary.md`
+   - 1~6장 구간은 바이트 단위로 무변경이어야 한다.
+2. `cp lib/make_slide_for_260724_seminar/SLIDE.md lib/make_slide_for_260724_seminar/paper_draft/SLIDE.md`로 재동기화하고 `diff -q`로 완전 일치를 확인한다.
+3. 커밋(제안 메시지: `docs: refine 0_intro chapter and script into plain conversational tone`). 커밋 대상: 두 챕터 파일 + 통합 `SLIDE.md` + `paper_draft/SLIDE.md` + 본 계획서.
 
-## 부록 — 이전 리비전 이력
+## 6. 완료 기준 (최종 판정)
 
-- Rev.1 (Job 19a175f2): 5개 장 재구성 8단계 계획 수립.
+1. §3의 F1~F8이 모두 반영되었거나, 반영하지 않은 항목에 대해 타당한 사유가 기록되어 있다.
-- Rev.2 (Job 174bd649): Creator 이의제기 수용 — What We Need?를 §3 마감 브릿지로 재배치, §4/§5 콜백 신설.
+2. §2 체크리스트 6개 기준을 모두 통과한다 (Reviewer PASS).
-- 구현 (Creator: agy) 및 리뷰 (Job 1cafc914): PASS, 비차단 발견 2건 → Rev.3 Step 1·2로 반영.
+3. 통합 `SLIDE.md`의 0장 구간이 확정본 `0_intro.md`와 내용 일치하고, front-matter/NOTE는 보존되었으며, 1~6장 구간은 무변경이다.
-- Rev.3 (Job a5a403e3): 잔여 작업 3단계 스코프 확정.
+4. `paper_draft/SLIDE.md`가 통합 `SLIDE.md`와 `diff -q` 완전 일치한다.
-- Rev.4 (Job 5874d3da): Creator 이의제기(91a2e3e9) 수용 — Step 2를 사본 단독 주석에서 양쪽 공통 주석(대안 A)으로 개정, 100% 동일성·단순 diff 검증 원칙 복원.
+5. `chapters/1_*.md` ~ `6_*.md` 및 그 외 파일은 변경되지 않았다.
+6. 루프 종료 커밋이 존재하며 의도한 파일만 포함한다.
+
+## 7. 대상 파일 (전부 저장소 루트 기준 경로)
+
+- 루프 중 수정: `lib/make_slide_for_260724_seminar/chapters/0_intro.md`, `lib/make_slide_for_260724_seminar/chapters/0_intro_script.md`
+- PASS 후 병합(Step 5에서만): `lib/make_slide_for_260724_seminar/SLIDE.md`, `lib/make_slide_for_260724_seminar/paper_draft/SLIDE.md`
+- 변경 금지: `lib/make_slide_for_260724_seminar/chapters/1_engineering.md` ~ `6_summary.md`, `lib/make_slide_for_260724_seminar/lecture_summary.md`
+
+## 부록 — 리비전 이력
+
+- Rev.1 (Job 69360718): DoD 6기준 + 초기 발견 F1~F8 + 수정-리뷰 루프 수립.
+- Rev.2 (Job 0fa577fa): Creator 이의제기(58a51e54) 수용 — 경로 전체 표기 통일, 최종 PASS 후 통합 덱 병합·재동기화 Step 5 신설, F1에 통합 덱 front-matter 보존 단서 추가.

lib/make_slide_for_260724_seminar/paper_draft/SLIDE.md

@@ -51,9 +51,9 @@ marp: true
   "여기서 우회전하고 다음에서 멈추자"라는 인지적 판단과 주행 경로(추론)를 수립합니다.
 - **AI 에이전트(Agent)는 '자율주행 차량 시스템 전체' 입니다.**
   운전자의 판단을 가속 페달과 바퀴 회전(도구 실행)으로 바꾸며, 다음과 같은 독자적인 **시스템 수준의 판단**을 수행합니다:
-  - **안전 가드레일**: 운전자가 실수로 위험한 길(예: 시스템 파괴 명령)로 가려 할 때 비상 제동을 걸어 이를 원천 차단함
+  - **안전 가드레일**: 운전자가 실수로 시스템을 파괴하는 명령과 같이 위험한 길로 가려 할 때 비상 제동을 걸어 이를 원천 차단합니다.
-  - **예외 복구 및 통제**: 네트워크가 끊기거나 무한 루프에 빠지면 스스로 판단해 실행을 중단하고 우회 경로를 수립함
+  - **예외 복구 및 통제**: 네트워크 연결이 끊기거나 무한 루프에 빠지는 상황이 발생하면 스스로 판단하여 실행을 중단하고 우회 경로를 수립합니다.
-  - **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과(`PASS`/`NOT PASS`)를 수집하고 최종 집행을 판정함
+  - **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과를 수집하여 통과나 반려 여부를 결정하고 최종 집행을 판정합니다.
 
 ---
 
@@ -61,67 +61,148 @@ marp: true
 
 단순히 대화만 나누는 챗봇이 아니라, 진짜 제 역할을 하는 **자율형 AI 에이전트**가 되기 위해 소프트웨어 시스템 차원에서 반드시 제공해야 하는 4가지 핵심 기능입니다.
 
-- **목표를 쪼개고 계획하는 능력 (Planning)**
+1. **계획 및 추론 능력 (Planning)**
-  사람이 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 자가 성찰(Self-Reflection)을 통해 유연하게 계획을 수정합니다.
+2. **기억 및 상태 관리 능력 (Memory)**
-- **상태와 기억을 관리하는 능력 (Memory)**
+3. **도구 활용 및 실행 능력 (Tool Use & Action)**
-  현재 대화의 맥락을 잃지 않는 단기 기억은 물론, 과거의 경험과 방대한 지식을 데이터베이스로부터 필요할 때마다 영속적으로 꺼내어 쓰는 장기 기억을 조화롭게 다룹니다.
+4. **상호 통신 및 협업 능력 (Collaboration)**
-- **물리적 환경과 연결되는 능력 (Tool Use & Action)**
-  인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행용 격리 환경(Sandboxing) 등 컴퓨터 세상의 다양한 도구들을 안전하게 선택하고 직접 작동시킵니다.
-- **서로 소통하고 협업하는 능력 (Collaboration)**
-  다른 전문 분야를 가진 에이전트나 사용자 시스템과 표준화된 규격으로 메시지를 주고받으며 큰 단위의 작업을 나누어 분산 처리합니다.
 
 ---
 
-## 🚀 패러다임 쉬프트: Model eats the Scaffolding
+### 1. 계획 및 추론 능력 (Planning)
 
-현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 '시스템(Scaffolding)'이 수동으로 제어하던 기능들이 점점 AI '모델 내부'로 흡수되고 있다는 점입니다.
+사용자가 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 계획을 유연하게 수정하는 능력입니다.
 
-- **스스로 생각하는 모델의 등장 (Test-time Compute)**
+- **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
+- **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
+
+* **실제 예시**: 
+  에이전트에게 "블로그 기사 작성"을 요청하면, 스스로 **'키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사'** 순으로 계획을 세웁니다. 만약 맞춤법 검사 도중 치명적인 논리 오류를 발견하면, 본문 작성 단계로 스스로 되돌아가 계획을 수정하고 다시 쓰는 자가 성찰(Self-Reflection)을 거칩니다.
+
+---
+
+### 2. 기억 및 상태 관리 능력 (Memory)
+
+현재 나누는 대화의 즉각적인 흐름(단기 기억)뿐만 아니라, 과거의 경험과 누적된 지식(장기 기억)을 필요할 때마다 영속적으로 꺼내어 쓰는 능력입니다.
+
+- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
+- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
+
+* **실제 예시**: 
+  에이전트에게 "어제 작업하던 파이썬 소스코드의 오류를 이어서 수정해줘"라고 요청하는 경우입니다. 에이전트는 데이터베이스에 누적된 과거 대화 히스토리와, 벡터 DB에 저장되어 있는 소스코드의 예전 상태 정보를 동적으로 인출(Retrieval)해 와 대화 맥락을 끊김 없이 이어갑니다.
+
+---
+
+### 3. 도구 활용 및 실행 능력 (Tool Use & Action)
+
+인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행 등 컴퓨터 세상의 다양한 소프트웨어를 직접 연결하고 작동시키는 손과 발 역할을 의미합니다.
+
+* **실제 예시**: 
+  복잡한 나눗셈 연산을 해야 할 때 직접 계산기 도구를 호출해 오차 없이 연산하고, 최신 주식 시세를 알기 위해 증권사 API를 호출하며, 작성한 코드가 잘 돌아가는지 검증하기 위해 격리된 샌드박스 컴퓨터 환경(Docker)을 구동해 스크립트를 직접 실행합니다.
+
+---
+
+### 4. 상호 통신 및 협업 능력 (Collaboration)
+
+혼자서 모든 일을 처리하는 것이 아니라, 다른 역할을 가진 전문 에이전트나 사용자 시스템과 표준 규격으로 메시지를 주고받으며 큰 작업을 분산 처리하는 능력입니다.
+
+* **실제 예시**: 
+  "이 프로젝트의 보안 취약점 보고서를 작성해줘"라는 명령을 내렸을 때의 상황입니다. 보안 에이전트가 소스코드를 스캔해 취약점을 나열하면, 인프라 에이전트가 가상 머신 설정을 검토하고, 최종적으로 리뷰어 에이전트들이 보고서의 신뢰성을 상호 검증하여 하나의 완성된 산출물을 합작해 냅니다.
+
+---
+
+## 🚀 패러다임 전환: Model eats the Scaffolding (모델이 외부 시스템을 흡수하다)
+
+현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 제어 시스템(Scaffolding, 에이전트의 구동을 돕는 외부 뼈대 구조)이 수동으로 제어하던 기능들이 점점 AI 모델 내부로 흡수되고 있는 현상입니다.
+
+- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
+
+- **스스로 생각하는 모델의 등장 (Test-time Compute, 추론 시점 추가 연산)**
   최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들은 외부 시스템이 루프를 돌려주지 않아도, 모델 스스로 출력을 내보내기 전에 내부적으로 계획을 세우고(Planning) 스스로 오류를 성찰(Reflection)하는 과정을 완료합니다.
 - **인지와 집행의 명확한 역할 분담**
-  이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있으며, 외부의 **에이전트 인프라(Harness)**는 안전한 실행 환경(Sandboxing), 권한 통제, 상태 관리처럼 모델이 직접 할 수 없는 물리적 보호막 역할을 수행하는 방향으로 진화하고 있습니다.
+  이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있습니다. 반면 외부의 **에이전트 인프라(Harness, 에이전트 실행 및 도구 제어 장치)**는 안전한 실행 환경(Sandboxing, 격리 환경 실행), 권한 통제, 상태 관리처럼 모델이 직접 수행하기 어려운 물리적 보호막 역할을 담당하는 방향으로 진화하고 있습니다.
 - **차별화 요소(Alpha)의 이동**
-  단순히 계획을 짜는 루프를 코드로 구현하는 것의 가치는 줄어들고, 이제는 복잡한 인프라를 실시간으로 제어하고 서로 다른 규격을 가진 이종 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력이 되었습니다.
+  단순히 계획을 짜는 흐름을 코드로 구현하는 것의 가치는 점차 줄어들고 있습니다. 이제는 복잡한 인프라를 실시간으로 제어하고, 서로 다른 규격을 가진 다양한 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력으로 부상하고 있습니다.
 
 ---
 
 # 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
 
-## AI 모델(LLM) vs AI 에이전트
+성공적인 AI 에이전트 시스템을 구현하기 위해서는 단순히 모델에게 프롬프트를 입력하는 것을 넘어, **모델 제어**, **정보 연동**, **물리적 환경 연결**을 유기적으로 엮어내는 3가지 핵심 엔지니어링 기법이 필요합니다.
-AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
 
-LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
+1. **프롬프트 엔지니어링 (Prompt Engineering)**: 에이전트의 페르소나와 사고 방식(추론 가이드라인)을 규정하는 작업입니다.
-1. **Planning (계획 및 추론)**
+2. **컨텍스트 엔지니어링 (Context Engineering)**: 대화 흐름을 끊김 없이 보존하고 관련 데이터를 적시에 제공하는 정보 정리 작업입니다.
-   - **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
+3. **하네스 엔지니어링 (Harness Engineering)**: 격리된 환경에서 다양한 소프트웨어 도구를 안전하게 조작할 수 있는 물리적 손발을 달아주는 작업입니다.
-   - **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
-2. **Memory (기억 장치)**
-   - **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
-   - **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
 
-- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
+---
 
-## 3대 핵심 엔지니어링 기법
+### 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
-성공적인 AI 에이전트 구현을 위해서는 모델 제어, 정보 연동, 물리적 환경 연결을 최적화하는 3대 엔지니어링 기법이 필수적으로 수반되어야 합니다.
 
-- ### 프롬프트 엔지니어링 (Prompt Engineering)
+모델의 발전과 자체 추론 기능의 향상으로 예전만큼 미시적인 프롬프트 트릭에 집착할 필요는 줄어들고 있습니다. 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 뼈대**입니다. 구체적이고 명확한 작동 지침을 만들기 위해 프롬프트 작성 시 반드시 반영해야 할 3대 핵심 고려사항입니다.
-  에이전트에게 명확한 역할 페르소나와 추론 가이드라인을 설계하고, 효율적인 추론 경로를 유도하기 위해 프롬프트 구조와 예시(Few-shot)를 최적화하는 기법입니다.
-  - **역할 페르소나 설계**: 에이전트가 특정 전문 도메인 지식과 행동 양식을 고수할 수 있도록 페르소나를 규정
-  - **추론 가이드라인 설계**: ReAct와 같은 사고 단계를 정의하여 모델이 계획 단계를 건너뛰지 않고 순차적으로 사고하도록 제어
-  - **Few-shot 최적화**: 최적의 추론 경로 및 응답 포맷 예시를 프롬프트에 제공하여 응답 일관성을 극대화
 
-- ### 컨텍스트 엔지니어링 (Context Engineering)
+- **역할 및 페르소나 지시 (Role)**
-  대화 상태(State)와 흐름을 보존하며, 외부 데이터베이스나 기억(Memory) 장치로부터 필요한 정보를 적시에 모델의 컨텍스트 윈도우에 효율적으로 바인딩하고 공급하는 기술입니다. 단일 에이전트 관점에서는 제한된 컨텍스트 공간 내에서 정보 밀도를 극대화하는 설계가 핵심입니다.
+  에이전트에게 전문 도메인 지식과 행동 경계를 지정해 줍니다. (예: *"너는 주니어 개발자를 코칭하는 꼼꼼한 테크리더 에이전트다. 직접 고치지 말고 가이드라인만 제공해라."*)
-  - **대화 상태 및 흐름 보존**: 이전 턴의 작업 상태와 대화 맥락을 유실 없이 세션 전반에 유지
+- **구체적인 작업 예시 제공 (Few-shot)**
-  - **적시 동적 바인딩**: 외부 RAG 검색기나 메모리 캐시로부터 관련성이 가장 높은 데이터만을 선별하여 컨텍스트 윈도우에 결합
+  원하는 출력 형식이나 중간 추론 과정의 모범 예시를 제공하여, 에이전트의 답변 일관성과 가독성을 극대화합니다.
-  - **메모리 압축 및 정리**: 불필요한 과거 로그를 요약하거나 중요 상태 구조체 위주로 정제하여 토큰 윈도우 효율성 제고
+- **자가 검증 방법 제시 (Verification)**
+  에이전트 스스로 작업의 무결성을 점검하게 하거나, 외부 시스템이 실행 결과를 확인 및 통제할 수 있도록 정형화된 출력 규격(예: 최종 통과 시 `[VERDICT: PASS]` 명시 요구)을 정의해 줍니다.
 
-- ### 하네스 엔지니어링 (Harness Engineering)
+---
-  에이전트가 계산기, 웹 브라우저, 외부 API 및 파일 시스템 등의 물리적 도구(Tools/Tool Use)에 안전하고 유연하게 연결되어 명령을 실행할 수 있도록 연결 고리를 결합하는 도구 연동 인터페이스 기술입니다.
-  - **물리 인터페이스 결합**: LLM의 도구 호출 의도(Tool Call)를 가로채어 실제 운영체제나 네트워크 상의 실행 스크립트로 전달하고 실행 결과를 모델에 반환
-  - **보안 샌드박싱**: 임의 코드 실행이나 파일 훼손 방지를 위해 파일 시스템 격리 및 API 호출 권한 등의 안전 제어막 형성
-  - **도구 활용 (Tool Use)**: 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력
 
-  ![Screenshot 2026-06-25 at 9.39.07 pm](../../assets/images/Screenshot%202026-06-25%20at%209.39.07%20pm.png)
+### 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
+
+에이전트가 단번에 대답하지 않고 단계별로 계획을 세워 도구를 사용하도록 프롬프트 구조를 강제하는 기법입니다.
+
+```text
+[System Prompt]
+너는 복잡한 수식을 계산하는 수학 에이전트다. 다음 형식으로 사고해라:
+- Thought: 문제 해결을 위한 다음 행동 계획을 작성해라.
+- Action: 호출할 도구 이름과 인자값을 JSON으로 적어라. (예: Calculator)
+- Observation: 도구 실행 결과가 여기에 채워질 것이다.
+- Thought: 실행 결과를 바탕으로 성찰하고, 필요하면 다음 Action을 설계해라.
+```
+
+---
+
+### 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
+
+에이전트가 다루는 대화 맥락과 작업 상태(State)를 효율적으로 정제하고, 수많은 외부 정보 중 **지금 꼭 필요한 관련 데이터(RAG)**만을 선별하여 제한된 AI의 기억 공간(컨텍스트 윈도우)에 밀도 높게 채워 넣는 기술입니다.
+
+* **핵심 설계 요소**:
+  - **대화 상태 보존**: 이전 턴의 작업 결과를 유실 없이 보존
+  - **동적 바인딩**: 외부 RAG 검색기에서 관련도 높은 중요 데이터만 적시에 필터링하여 공급
+  - **메모리 압축**: 불필요한 과거 로그는 요약하고, 핵심 현재 상태 구조체만 유지해 토큰 낭비 방지
+* **에이전트 상태 보존 예시 (State JSON)**:
+  ```json
+  {
+    "task_id": "job_10294",
+    "current_working_directory": "/workspace/src",
+    "error_logs": ["SyntaxError: unexpected EOF while parsing at line 14"],
+    "completed_subtasks": ["1. 소스코드 로드 완료", "2. 오류 라인 식별"],
+    "next_action_required": "오류 라인 14의 괄호 닫힘 확인 및 수정 스크립트 작성"
+  }
+  ```
+
+---
+
+### 3️⃣ 하네스 엔지니어링 (Harness Engineering)
+
+에이전트가 파일 시스템 제어, 브라우저 조작, 외부 API 호출 등 컴퓨터 세상의 다양한 도구들을 안전하게 가동할 수 있도록 **물리적 인터페이스(연결 고리)**를 구성하는 기술입니다.
+
+* **핵심 설계 요소**:
+  - **도구 호출 가로채기(Intercepting)**: 모델이 내놓은 도구 호출 의도(JSON 등)를 감지하고, 실제 터미널이나 프로그램의 함수로 전달해 구동함
+  - **보안 샌드박싱 (Sandboxing)**: 에이전트가 악성 코드나 파괴적인 명령어를 무단 실행하지 않도록 격리된 가상 환경을 구축하고 권한을 통제함
+* **물리 인터페이스 도구 결합 예시**:
+  ```
+  [LLM의 출력] ──> "Action: execute_command, args: { cmd: 'ls -la' }"
+                          │ (하네스가 이를 가로챔)
+                          ▼
+  [하네스 제어기] ──> 격리된 Docker 샌드박스 내부에서 'ls -la' 실제 실행
+                          │ (실행 결과 가로챔)
+                          ▼
+  [LLM의 입력] <── "Observation: total 12\ndrwxr-xr-x 3 user..." (모델에 반환)
+  ```
+
+  ![Harness Diagram](../../assets/images/Screenshot%202026-06-25%20at%209.39.07%20pm.png)
 
 ---