Pi를 6개월 사용한 뒤의 설정 — Eero Alvar

URL: https://www.youtube.com/watch?v=iKwPaB5TUdI
날짜: 2026-08-25
채널: Eero Alvar
길이: 19분 08초
설정 저장소: https://github.com/amosblomqvist/pi-config
관련 학습 시스템: https://github.com/amosblomqvist/learn
자막 기준: 영어 자동 자막 전체 검토 후 한국어 번역

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코딩 에이전트를 오래 사용할수록 중요한 것은 기능을 많이 붙이는 일이 아니라, 에이전트 간 통신·관찰 가능성·메모리·행동 지시를 세밀하게 설계해 인간과 에이전트가 함께 작업하기 좋은 운영 환경을 만드는 일이다.==

• 이전 Pi 설정 영상 이후 4개월 동안 대부분의 구성이 바뀌었지만, Bash Guard·질문 도구·커스텀 헤더·웹 도구는 살아남았다.
• 동기식 서브에이전트보다 비동기·상호작용형 서브에이전트가 훨씬 유용하며, 에이전트가 질문을 위로 올리고 작업이 끝난 뒤 오케스트레이터를 깨우는 계층형 통신이 핵심이다.
• 관찰 메모리(observational memory)는 메시지를 관찰 단위로 쪼개 단기·장기·작업 메모리로 분리하고, 요약의 요약이 누적되는 정보 손실을 줄인다.
• 프롬프트 스니펫(prompt snippets)은 항상 노출되는 시스템 지침과 자동 활성화되는 무거운 스킬 사이의 중간 계층으로, 상황별 행동 지시를 사용자가 직접 조합하게 한다.

Eero Alvar는 자신의 전역 .pi 디렉터리를 열어 6개월 동안 실제로 남은 확장과 새로 만든 확장을 하나씩 시연한다. 단순한 기능 소개가 아니라, 각 기능이 에이전트의 자율성·관찰 가능성·컨텍스트 관리·사용자 통제에 어떤 영향을 주는지 보여주는 운영 경험 보고서다.

1. 6개월 뒤에도 살아남은 기본 확장

1.1. Bash Guard와 사용자 질문 도구

1. Bash Guard

   1. Bash Guard는 이전 설정에서 살아남은 확장이다.
   2. 이번에 추가한 변경은 세션마다 끌 수 있는 기능이다.
   3. 화자는 보통 매 세션을 시작할 때 Bash Guard를 끄는 것이 첫 번째 행동이라고 말한다.

2. Ask User Question 도구

   1. AI가 사용자에게 질문을 보내는 기본 기능은 이전과 같다.
   2. 새로 추가한 기능은 UI 팝업을 표시하는 다른 확장과 통신할 수 있게 한 것이다.
   3. 여러 확장이 동시에 팝업을 띄울 때 서로의 UI를 덮어쓰지 않도록 조정한다.
   4. 에이전트의 질문과 다른 확장의 UI 상태가 충돌하지 않게 만드는 작은 통합 계층이다.

1.2. 커스텀 헤더와 웹 도구

1. 커스텀 헤더

   1. 큰 대문자 Pi가 표시되는 커스텀 헤더는 그대로 남아 있다.
   2. 사용자는 현재 어떤 Pi 세션 안에 있는지 시각적으로 바로 확인할 수 있다.

2. 웹 도구

   1. 웹 도구도 이전과 동일하게 유지됐다.
   2. 이 네 가지 확장(Bash Guard, 사용자 질문 도구, 커스텀 헤더, 웹 도구)은 이전 Pi 설정 영상에서 다뤘으며, 지금까지도 실제로 사용할 가치가 있었다.
   3. 반면 나머지 구성은 거의 전부 새로 바뀌었다.

2. Interactive Subagents: 비동기 에이전트 오케스트레이션

이번 설정에서 가장 큰 변화는 기존 동기식 서브에이전트를 상호작용형·비동기 서브에이전트로 교체한 것이다.

2.1. 동기식에서 비동기식으로

1. 기존 구현의 위치

   1. 기존 동기식 서브에이전트도 여전히 좋은 도구다.
   2. 특히 앱이나 제품 안에 에이전트 기능을 통합할 때 사용하기 쉽다.
   3. 하지만 개인 코딩 환경에서 작업을 계속 지시하고 관찰하는 목적에는 새 비동기 방식이 훨씬 낫다고 평가한다.

2. 즉시 반환되는 스폰 호출

   1. 사용자가 간단한 데모 작업으로 scout 에이전트를 생성한다.
   2. 확장은 Tmux를 요구한다. 서브에이전트가 멀티플렉서의 별도 패널에서 실행되기 때문이다.
   3. 스폰 도구 호출은 즉시 반환되고, 에이전트 세션은 백그라운드에서 계속 실행된다.
   4. 사용자는 자신의 메인 세션을 멈추지 않고 실행 중인 여러 세션을 살펴보거나 후속 메시지를 보낼 수 있다.

3. 사람과 에이전트, 에이전트와 에이전트의 상호작용

   1. 사용자는 각 서브에이전트에 후속 지시를 보낼 수 있다.
   2. 오케스트레이터도 서브에이전트 세션에 후속 메시지를 보낼 수 있다.
   3. 서브에이전트끼리도 메시지를 주고받을 수 있다.
   4. 작업이 끝나면 완료된 서브에이전트가 오케스트레이터를 자동으로 깨운다.

2.2. Ask Question으로 에이전트 간 불확실성 전달

1. 하위 에이전트가 상위 에이전트에 질문한다

   1. 서브에이전트에는 ask question 도구가 있다.
   2. scout가 작업 중 구현 세부사항을 모르면 부모 에이전트에게 질문을 보낸다.
   3. 질문은 UI에 표시되고, 오케스트레이터와 마스터 에이전트를 깨운다.
   4. 상위 에이전트가 답변을 보내면 메시지가 즉시 하위 세션에 전달된다.

2. 에이전트는 구현 세부사항을 추측하면 안 된다

   1. 화자는 에이전트가 구현 세부사항을 추측해서는 안 된다고 강조한다.
   2. 모르는 정보가 있으면 질문하거나, 질문을 위로 올릴 수 있는 통신 방법이 필요하다.
   3. 이 기능은 단순한 질의 도구가 아니라 에이전트가 불확실성을 숨기지 않게 하는 안전장치다.

3. 질문이 있는 세션은 멈춰서 기다린다

   1. 질문을 보낸 scout 세션은 종료되지 않고 대기 상태로 남는다.
   2. 답변을 받으면 작업을 마저 수행한 뒤 세션이 닫힌다.
   3. worker는 scout의 결과를 요약하고, master는 worker의 요약을 받아 다음 작업으로 진행한다.

2.3. Master → Worker → Scout 계층

1. 체인 오브 커맨드 데모

   1. master가 worker를 생성한다.
   2. worker는 scout를 생성한다.
   3. scout가 명확화가 필요한 상황을 만난다.
   4. scout는 worker에게 질문하고, worker는 그 질문을 master 세션으로 올린다.

2. 질문의 상향 에스컬레이션

   1. 실제 상황이라면 worker가 직접 답할 수도 있다.
   2. 데모에서는 계층형 위임을 보여주기 위해 worker가 질문을 master로 에스컬레이션한다.
   3. 이 구조는 여러 단계의 에이전트 작업에서 질문의 책임과 맥락을 위로 전달하는 방법을 보여준다.

3. 확장 구현의 출처와 단순화

   1. 이 확장은 Daniel Grosser의 interactive sub-agents 구현을 포크한 것이다.
   2. Eero Alvar는 에이전트 경험을 단순화하는 데 초점을 맞췄다.
   3. 스폰 도구의 스키마를 줄여 사용자가 신경 쓸 항목을 적게 만들었다.
   4. 인터럽트와 재개를 별도의 복잡한 흐름이 아니라 하나의 sub-agent message 도구로 통합했다.

2.4. 세션 재개·조종·종료

1. 이름 기반 세션 재개

   1. 처음 생성한 scout 세션을 다시 재개하는 데모를 진행한다.
   2. 에이전트에 이름을 붙이는 이유는 메시지를 이름으로 보내기 위해서다.
   3. 재개(resume)와 조종(steer)은 같은 도구로 수행된다.

2. 별도 done 도구를 없앴다

   1. 원래 구현은 서브에이전트가 작업을 끝내면 별도의 done 도구를 호출해야 했다.
   2. 이 방식은 신뢰성이 떨어졌다. 에이전트가 너무 일찍 done을 호출하거나, 아예 호출하지 않는 문제가 있었다.
   3. 현재 구현에서는 에이전트가 토큰 생성을 멈추고, 사용자 응답이나 자기 하위 에이전트의 완료를 기다리는 중이 아니라면 세션이 종료된다.
   4. 마지막 메시지가 반환되므로 별도의 종료 호출이 필요 없다.

3. Tmux 중심의 구현

   1. 원래 구현은 여러 종류의 멀티플렉서를 지원한다.
   2. 화자의 구현은 자신이 실제로 Tmux만 사용하기 때문에 Tmux에 집중한다.

2.5. Riemann 가설과 관찰 가능성

1. 7개 서브에이전트 생성

   1. 다음 데모에서 master에게 Riemann 가설을 풀어 보라고 지시한다.
   2. 작업이 느리게 진행되지만, 곧 7개의 서브에이전트가 생성된다.
   3. 패널의 자동 균형(auto-balancing) 기능도 추가되어 실행 중인 세션이 화면에 고르게 배치된다.

2. 가시적인 관찰 가능성

   1. 이전 영상에서도 observability를 이야기했지만, 이번에는 훨씬 더 높은 수준이라고 말한다.
   2. 실제 에이전트 세션이 화면 바로 앞에 보인다.
   3. 어떤 에이전트가 무엇을 하고 있는지, 어느 단계에서 멈췄는지, 질문을 기다리는지 직접 확인할 수 있다.

3. 에이전트의 농담

   1. 에이전트는 “Riemann 가설이 참이라고 주장한다. 증명은 다음 세션으로 미룬다”는 식의 답을 출력한다.
   2. 화자는 이를 완전한 엄밀성을 시도한 결과라며 코미디언 같다고 농담한다.

3. Browser 확장: 에이전트에게 눈과 손을 주기

3.1. Playwright 기반 헤드리스 브라우저

1. 웹 개발을 위한 브라우저

   1. Browser 확장은 Pi가 Playwright로 구동되는 헤드리스 브라우저를 사용하게 한다.
   2. 웹 개발 작업에는 매우 중요한 확장이라고 평가한다.
   3. 페이지 이동, JavaScript 실행, 스크린샷, 콘솔 확인, 클릭과 테스트 같은 작업을 에이전트가 수행할 수 있다.

2. 컨텍스트 비용

   1. 이 확장은 에이전트에게 8개의 도구를 등록한다.
   2. 8개 도구가 컨텍스트의 의미 있는 공간을 차지한다.
   3. 화자는 컨텍스트 부풀리기를 최소화하고 싶어서 Browser 확장을 기본적으로 비활성화했다.
   4. 필요할 때 browser on 명령으로 켜는 방식이다.

3.2. 간단한 브라우저 테스트와 모델의 한계

1. example.com 테스트

   1. 확장을 켜지 않은 상태에서 브라우저 도구를 테스트한다.
   2. example.com으로 이동하고 JavaScript를 실행하고 스크린샷을 찍는다.
   3. 하지만 사용한 GLM 모델은 눈이 없다는 사실을 잊은 것처럼, 촬영한 이미지를 직접 볼 수 없었다.

2. 브라우저를 사용해야 하는 실제 사례

   1. 화자는 테스트할 만한 더 좋은 사례를 찾는다.
   2. 화면에는 고장 난 웹 앱이 나타난다.
   3. 문제를 진단하고 수정하고 검증하기에 적절한 상황이다.

3.3. 고장 난 웹 앱 디버깅

1. 진단

   1. browser on으로 브라우저 기능을 활성화한다.
   2. 에이전트가 사이트로 이동한다.
   3. 스크린샷을 확인하고 브라우저 콘솔을 읽는다.
   4. 콘솔과 화면을 통해 버그를 찾는다.

2. 수정과 검증

   1. 에이전트가 사이트의 기능을 클릭해 실제로 동작하는지 확인한다.
   2. 여러 스크린샷을 찍으며 상태를 비교한다.
   3. 전체 사이트를 모두 고칠 필요는 없지만, 문제가 된 흐름은 정상 작동하는 것으로 보인다.
   4. 에이전트는 수정 후에도 계속 테스트하고 검증한다.

4. Dictate 확장: 음성으로 에이전트 조종하기

4.1. Pi 내부의 최소 Whisper 흐름

1. 영상 전체에서 사용한 확장

   1. 화자는 영상 내내 Dictate 확장을 사용했다고 말한다.
   2. 음성을 텍스트로 바꾸는 speech-to-text 기능이다.

2. 구현 방식

   1. Pi 안에 최소한의 Whisper 흐름을 넣은 형태다.
   2. 자세한 설명은 이미 별도의 영상에서 다뤘기 때문에 이 영상에서는 더 깊이 들어가지 않는다.
   3. 음성 입력을 빠르게 텍스트 지시로 바꿔 코딩 에이전트와 상호작용하는 것이 목적이다.

5. Observational Memory: 세션을 오래 유지하는 메모리 구조

화자는 Maestra의 observational memory에서 아이디어를 얻어 자신만의 구현을 만들었다. 이미 Pi를 위한 직접적인 구현도 있지만, 자신만의 버전을 만들었고 원본보다 나빠졌을 가능성도 농담처럼 인정한다.

5.1. 요약이 아니라 관찰 단위로 저장하기

1. 메시지 히스토리의 청크화

   1. 전체 메시지 히스토리를 여러 청크로 나눈다.
   2. 각 청크는 observer 에이전트에게 전달된다.
   3. observer는 청크를 작고 구체적인 관찰(observation) 목록으로 압축한다.

2. 관찰은 메모리의 원자 단위다

   1. 관찰 목록이 에이전트 메모리의 원자적 단위로 기능한다.
   2. 압축 결과는 자유로운 장문 요약이 아니라 결정론적인 관찰 목록이다.
   3. 같은 내용을 요약하고 그 요약을 다시 요약하는 구조가 아니다.

3. 요약의 요약 문제를 피한다

   1. 전통적인 LLM 컨텍스트 압축은 이전 요약을 다시 요약하는 방식으로 누적될 수 있다.
   2. 이 과정에서는 정보가 계속 뭉개지고, 무엇이 언제 있었는지와 세부 내용이 손실될 수 있다.
   3. 관찰 단위를 유지하면 압축 사이클을 거쳐도 관찰이 쉽게 변질되거나 사라지지 않는다.

5.2. 무한히 이어질 수 있는 세션을 위한 계층

1. 관찰 풀이 가득 찼을 때

   1. 시스템은 잠재적으로 영원히 이어질 수 있는 세션을 염두에 두고 설계됐다.
   2. 관찰 풀이 가득 차면 가장 오래된 관찰을 주제별 Markdown 파일로 통합한다.
   3. 컨텍스트 압축 블록의 맨 위에는 메모리 파일의 인덱스가 놓인다.

2. 세 종류의 메모리

   1. 주제별 Markdown 메모리 파일은 에이전트의 장기 메모리(long-term memory)다.
   2. 아직 파일로 통합되지 않은 관찰 목록은 단기 메모리(short-term memory)다.
   3. 현재 대화의 메시지 히스토리와 압축 꼬리(compaction tail)는 작업 메모리(working memory)다.

3. 메모리 인덱스와 Journey 블록

   1. 메모리 인덱스는 주제별로 어떤 기억 파일을 찾아야 하는지 알려준다.
   2. 컨텍스트 맨 위에는 세션의 방향을 잡아 주는 Journey 블록이 있다.
   3. Journey 블록은 consolidator 에이전트가 만들고 수정한다.
   4. 엄격한 토큰 상한이 있어 지나치게 커지지 않고 최소한의 세션 방향만 유지한다.

5.3. OM 데모와 상태 계기판

1. 활성화와 게이지

   1. /OM 명령으로 observational memory를 활성화한다.
   2. 화면 아래에 여러 게이지가 표시된다.
   3. 첫 번째 게이지는 다음 observer가 생성될 때까지 얼마나 남았는지 보여준다.
   4. 두 번째 게이지는 관찰이 메모리 파일로 통합될 때까지 얼마나 남았는지 보여준다.
   5. X는 context를 뜻하며 다음 컨텍스트 압축까지 남은 정도를 표시한다.

2. 10,000 토큰 단위

   1. 약 10,000토큰이 채워질 때마다 새로운 observer가 생성된다.
   2. 상태 명령을 실행하면 전체 세션의 타임라인이 표시된다.
   3. 각각의 블록은 대략 10,000토큰인 하나의 관찰 청크를 나타낸다.

3. 타임라인의 색상

   1. 가장 밝은 색은 이미 메모리 파일로 통합된 내용이다.
   2. 회색은 관찰됐지만 아직 파일로 통합되지 않은 내용이다.
   3. 가장 어두운 색은 아직 관찰되지 않은 내용이다.
   4. 세로선은 컨텍스트 압축이 일어난 지점을 나타낸다.
   5. 따라서 전체 세션과 메모리 시스템의 현재 상태를 한눈에 볼 수 있다.

4. 세션 중간의 결정론적 압축

   1. 화자는 압축과 통합이 실제로 일어나도록 추가 프롬프트를 보낸다.
   2. Bash Guard도 끈다.
   3. 압축은 세션 턴 중간에 즉시 수행된다.
   4. 에이전트는 압축을 기다리며 멈추지 않고 곧바로 세션을 계속한다.

5. Observer와 Consolidator의 실행

   1. observer 에이전트가 실행되고 14개의 관찰을 만든다.
   2. 관찰은 매우 조밀하게 정보를 담고 있으며 모두 타임스탬프가 붙어 있다.
   3. 타임스탬프 덕분에 에이전트는 각각의 기억이 세션의 언제 발생했는지 알 수 있다.
   4. consolidator는 85개의 관찰을 주제별 메모리 문서로 통합한다.
   5. 상태를 다시 확인하면 최신 압축과 메모리 풀이 앞으로 이동한 것이 보인다.

6. Prompt Snippets: 시스템 프롬프트와 스킬 사이의 중간 계층

6.1. 반복되는 행동 지시의 세 가지 저장 방식

1. 시스템 프롬프트와 AGENTS.md

   1. 시스템 프롬프트나 AGENTS.md에 있는 지침은 항상 존재한다.
   2. 하지만 행동은 상황에 따라 달라지므로 모든 지침을 항상 넣는 것은 비효율적일 수 있다.
   3. 또 이 지침은 보이지 않는다. 실제로 어떤 지시가 들어 있는지 확인하려면 파일이나 시스템 프롬프트를 직접 열어야 한다.

2. Skills

   1. 스킬은 상황 의존적이라는 장점이 있다.
   2. 하지만 보통 여러 종류의 에이전트 행동을 한꺼번에 인코딩하기 때문에 다소 덩어리가 크다.
   3. 에이전트가 기본적으로 스스로 활성화하는 방식도 화자가 선호하지 않는 부분이다.
   4. 사용자가 에이전트의 행동을 직접 통제하고 싶기 때문이다.

3. 중간 지대의 부재

   1. 시스템 프롬프트·AGENTS.md는 항상 존재하지만 보이지 않는다.
   2. 스킬은 상황별이지만 크고 자동 활성화될 수 있다.
   3. 화자는 이 둘 사이에 사용자가 직접 조합할 수 있는 가벼운 지시 계층이 필요하다고 판단했다.

6.2. 작고 조합 가능한 Markdown 지시

1. Prompt snippet의 정의

   1. 프롬프트 스니펫은 매우 작고 독립적인 행동 지시다.
   2. 각각을 필요할 때 조합해서 프롬프트에 추가한다.
   3. 반복적으로 쓰이지만 상황에 따라 선택할 수 있다.

2. 메뉴와 미리보기

   1. Alt + S를 누르면 프롬프트 스니펫 메뉴가 열린다.
   2. Tab으로 스니펫을 미리 볼 수 있다.
   3. 현재 프롬프트에 무엇이 추가되거나 앞에 붙는지 즉시 확인할 수 있다.

3. 앞에 붙이기와 뒤에 붙이기

   1. 선택한 스니펫은 프롬프트 앞에 붙이거나 뒤에 덧붙인다.
   2. 예를 들어 ask questions와 verify, don't assume 두 지시를 선택해 추가할 수 있다.
   3. 메시지를 보낼 때마다 해당 지시가 실제 프롬프트에 포함된다.

4. 파일 기반 편집

   1. 스니펫은 폴더 안의 Markdown 파일로 관리한다.
   2. 각 파일의 순서를 지정할 수도 있다.
   3. 사용자가 현재 상황에 필요한 행동 규칙만 골라 조립할 수 있다.

6.3. 실제 사용 예시와 도출 과정

1. 반복 지시를 메시지에 직접 넣는 비용

   1. “질문하라”, “추측하지 말고 검증하라” 같은 지시를 매번 손으로 입력하는 것은 불필요한 정신적 비용이다.
   2. 이런 지시를 시스템 프롬프트나 AGENTS.md에 넣으면 항상 노출되지만 상황별로 끄기 어렵다.
   3. 스니펫은 지시가 실제 사용자 메시지에 들어가므로 에이전트에게 더 강하게 느껴질 수 있다.

2. 큰 프롬프트의 예시

   1. build app처럼 큰 작업 프롬프트를 작성한다.
   2. 여기에 orchestrator mode, ask questions, delegate exploration 스니펫을 붙인다.
   3. 전송 직전에 어떤 지시가 로드됐는지 확인할 수 있다.

3. 분석 세션 스킬에서 얻은 지시

   1. 화자는 analyze session 스킬을 사용해 여러 달 동안 다양한 프로젝트에서 반복해 쓴 문장을 찾았다.
   2. 이 스킬은 Pi 세션을 빠르게 파싱하고 검색하는 몇 개의 Python 스크립트로 구성돼 있다.
   3. 반복 사용된 행동 지시를 추출한 뒤, 현재의 프롬프트 스니펫으로 정리했다.

7. Skills 구성

7.1. 적은 수의 목적별 스킬

1. 이전 영상에서 이어진 스킬

   1. 현재 스킬 수는 많지 않다.
   2. 두 개는 이전 Pi 설정 영상에서 소개한 PDF reader와 YouTube transcript 스킬이다.

2. Web debug 스킬

   1. 브라우저 확장을 위한 web debug 스킬도 있다.
   2. 이 스킬은 앞에서 시연한 브라우저 확장을 활용해 웹을 디버깅하는 방법을 정의한다.
   3. 브라우저 도구를 켜고 스크린샷·콘솔·클릭·검증을 조합하는 흐름을 재사용할 수 있게 한다.

3. 스킬에 대한 태도

   1. 화자는 모든 행동을 하나의 거대한 스킬에 넣기보다, 실제로 반복되는 워크플로우만 작게 분리한다.
   2. Prompt snippets와 결합하면 큰 스킬을 자동으로 활성화하지 않고도 필요한 행동을 선택할 수 있다.

8. 학습 시스템 공개

8.1. 이전 영상의 학습 시스템과 연결

1. 높은 수요

   1. 이전 영상에서 보여준 AI 학습 시스템에 대한 요청이 매우 많았다고 말한다.
   2. 그래서 Pi 설정의 나머지 구성과 함께 학습 시스템도 공개하려고 했다.

2. 두 가지 사용 방식

   1. 영상에서 사용한 정확한 설정을 그대로 맞추려면 다른 확장 기능 일부도 함께 필요하다.
   2. 빠르게 시험해 보고 싶다면 서브에이전트 같은 부가 구성 없이 학습 시스템만 사용할 수도 있다.
   3. 자신의 환경에 맞게 아이디어를 복사하고, 어떤 부분이 잘 작동하는지 실험해 보라고 권한다.

8.2. 커뮤니티 피드백과 다음 단계

1. 사용자의 아이디어를 다시 개발에 반영한다

   1. 화자는 시청자의 댓글과 메시지를 많이 읽고 있다.
   2. 그 안에 놀라운 아이디어와 새로운 관점이 많다고 말한다.
   3. 피드백을 바탕으로 Pi 설정과 학습 시스템을 계속 발전시킬 계획이다.

2. 마무리

   1. 영상을 보고 설정을 시험해 보고, 자신의 워크플로우에 맞춰 조정하라고 권한다.
   2. 다음 영상을 예고하며 응원해 준 사람들에게 감사를 전한다.

주요 발언 모음

“에이전트는 구현 세부사항을 절대 추측해서는 안 됩니다. 명확히 할 방법이 있어야 합니다.”

“질문이 걸려 있는 세션은 닫히지 않고 답변을 기다립니다.”

“실제로 세션이 눈앞에 보이는 것보다 더 큰 관찰 가능성은 없습니다.”

“요약의 요약이 되는 방식은 좋지 않습니다.”

“관찰은 단기 메모리이고, 메모리 파일은 장기 메모리이며, 실제 메시지 히스토리는 작업 메모리입니다.”

“나는 에이전트를 통제하고 싶습니다.”

“프롬프트 스니펫은 내가 원했던 이상적인 중간 지대입니다.”

“복사한 아이디어를 자신의 워크플로우에 맞춰 보고, 무엇이 작동하는지 확인해 보세요.”

핵심 데이터 & 수치

• 6개월: 이번 Pi 설정을 실제로 사용한 기간.
• 약 4개월: 이전 Pi 설정 영상 이후 경과한 기간. 그 사이 거의 모든 구성이 바뀌었다.
• Tmux: 비동기 서브에이전트를 멀티플렉서 패널에서 실행하기 위해 필요한 환경.
• 7개: Riemann 가설 데모에서 생성된 서브에이전트 수.
• 8개 도구: Browser 확장이 에이전트에 등록하는 도구 수. 컨텍스트 부풀림을 이유로 기본 비활성화했다.
• 10,000토큰: Observational memory에서 observer가 새로 생성되는 대략적인 단위이자 상태 타임라인의 한 블록 크기.
• 14개 관찰: 데모 중 observer 에이전트가 생성한 관찰 수.
• 85개 관찰: consolidator 에이전트가 메모리 문서로 통합한 관찰 수.
• 3개 메모리 계층: 장기 메모리(주제별 Markdown), 단기 메모리(관찰 목록), 작업 메모리(현재 메시지 히스토리).

결론 및 시사점

1. 비동기 에이전트가 작업 흐름을 바꾼다: 메인 세션을 멈추지 않고 여러 에이전트를 실행하고, 필요할 때 개입하고, 완료 시 자동으로 결과를 받을 수 있다.
2. 질문 전파는 자율성의 핵심이다: 하위 에이전트가 모르는 것을 추측하지 않고 상위 계층으로 올리게 해야 에이전트 군집이 안전하게 동작한다.
3. 관찰 가능성은 기능이 아니라 운영 기반이다: 실제 세션·패널·상태·대기 이유가 보여야 사용자가 에이전트 군집을 신뢰하고 조종할 수 있다.
4. 메모리에는 시간 계층이 필요하다: 모든 대화를 하나의 요약으로 뭉개지 말고, 현재 작업·최근 관찰·주제별 장기 기록을 분리한다.
5. 결정론적 관찰은 요약 누적 손실을 줄인다: 관찰 목록과 타임스탬프를 보존하면 “요약의 요약”으로 인한 정보 손실을 줄일 수 있다.
6. 도구는 필요할 때만 컨텍스트에 넣는다: 브라우저 도구처럼 유용하지만 많은 토큰을 차지하는 기능은 기본 비활성화하고 명시적으로 켠다.
7. 프롬프트 스니펫은 사용자 통제 계층이다: 항상 존재하는 시스템 지침과 자동 활성화되는 큰 스킬 사이에서, 사용자가 상황별 행동을 직접 선택한다.
8. 반복 문장을 데이터로 채굴한다: 실제 세션 로그를 검색하면 어떤 지시가 반복적으로 필요한지 발견할 수 있고, 그것을 스니펫으로 재사용할 수 있다.
9. 확장은 작은 목적 단위로 유지한다: PDF·YouTube·웹 디버깅처럼 명확한 워크플로우만 스킬로 분리하면 시스템을 관리하기 쉽다.
10. 설정의 가치는 복제보다 적응에 있다: 공개된 Pi 설정을 그대로 복사하는 것보다 자신의 워크플로우에 맞춰 어떤 기능을 켜고 끌지 실험하는 것이 중요하다.