Flogi 1차 회의 — Pi 생태계와 Loom의 위치
기록 개요
- 파일 기준일: 2026년 8월 16일
- 녹음 메타데이터: 2026년 8월 17일
- 참석: 김희성, 홍용재, 김정현
- 성격: Pi와 주변 에이전트 생태계를 살펴보고 Loom이 어느 계층에서 가치를 만들지 정리한 1차 회의
회의 안건
- Pi의 최소 구조와 확장 방식
- Hermes의 메모리 패턴, Skill·Extension·Package의 차이
- tmux와 멀티에이전트 도구를 이용한 작업 가시성
- Loom을 Pi와 결합할 때 지켜야 할 경계
- 발표 전에 필요한 설치·실험 과제
각 사람의 의견
김희성
- Pi를 거대한 완제품이라기보다 최소한의 에이전트 실행부와 확장 생태계로 보았다.
- Skill, Extension, Package를 조합해 필요한 기능만 붙이는 구조가 Loom의 작은 기술 검증에 적합하다고 설명했다.
- Hermes의 메모리 방식과 여러 에이전트를 한 화면에서 관찰하는 도구를 함께 참고하면 상태와 작업 기록을 설계하는 데 도움이 된다고 했다.
- Loom은 Pi를 대체하기보다 Pi 생태계 안에서 강한 통제, 검증, 작업 대시보드를 제공하는 확장으로 먼저 시험해 보자고 제안했다.
홍용재
- Pi, Hermes, 멀티에이전트 도구, Loom을 서로 다른 계층으로 분리해 이해해야 한다고 보았다.
- 에이전트를 바꿀 때마다 사람이 작업 맥락을 다시 읽는 비용이 크며, 중앙 대시보드와 구조화된 상태가 그 복귀 비용을 낮출 수 있다고 강조했다.
- Loom의 차별점은 상태 머신과 검증 규칙을 통해 중요한 작업 흐름을 강제할 수 있다는 점이라고 설명했다.
- 기술을 모르는 사용자도 쓸 수 있으려면 복잡한 설정을 숨기고, 이미 검증된 흐름을 쉽게 선택할 수 있어야 한다고 했다.
김정현
- 처음 접하는 사람에게 Skill, Extension, Package가 어떻게 다른지 반복해서 확인했다.
- 여러 에이전트가 동시에 움직일 때 현재 상태를 볼 수 있는 UI가 이해에 큰 영향을 준다고 보았다.
- 로컬 자원과 실행 비용이 늘어나는 구조인지, 비개발자가 실제로 따라 할 수 있는지 확인이 필요하다고 했다.
논의와 결정
- Loom의 첫 위치를 Pi 생태계 위에서 동작하는 Extension 또는 Package 후보로 잡는다.
- Loom은 검증된 작업 템플릿, 상태, 강한 통제, 사람이 읽을 수 있는 작업 대시보드를 제공하는 방향으로 설명한다.
- Pi의 가벼운 구조를 해치지 않고 Loom이 실제로 추가하는 가치가 무엇인지 먼저 실험한다.
- 여러 도구를 한 번에 합치기 전에 각 도구의 장점과 책임을 직접 확인한다.
행동 항목
- 세 사람 모두 Loom 저장소와 관련 문서를 읽고 현재 구조를 파악한다.
- Pi를 설치해 Skill, Extension, Package의 실제 사용 흐름을 시험한다.
- Hermes의 메모리 구조와 멀티에이전트 화면 구성을 참고한다.
- 김정현의 환경에서도 설치와 사용이 가능한지 확인해 초심자 관점의 장애물을 수집한다.
- 실험 결과를 다음 발표 기획과 기술 제안에 반영한다.
남은 쟁점
- Loom이 장기적으로 독립 실행 환경이 될지, 다른 에이전트 위의 통제 계층이 될지는 정하지 않았다.
- 대시보드가 본질인지 표현 계층인지, 메모리와 상태의 최소 규격이 무엇인지 추가 검증이 필요하다.