회의 기본 정보
- 기록 유형: 프로젝트 회의
- 일자: 2026-08-28
- 참여자: 김희성, 홍용재, 김정현
- 목적: Pi와 Loom의 역할을 기능 목록이 아닌 소유 권한과 상태의 차이로 정리하고, 외부 실행 계층과 완료 검증 구조의 설계 방향을 검토하기 위해
- 원본: 26-08-28_loom_설계_이해.txt
한눈에 보는 요약
- Pi는 작업을 어떻게 수행할지에 관한 execution procedure authority, Loom은 프로젝트의 workflow authority를 소유한다는 작업 가설을 맞췄다.
- 외부 하네스의 실행 성공과 Loom 태스크의 완료는 다르며, Loom acceptance gate가 최종 완료 조건을 판단해야 한다.
- direct agent, Pi, script/CLI, external harness, nested loop 중 실행 방식을 고르는 execution binding 계층을 제안했다.
- execution binding의 필요성과 사용자 직접 선택 범위는 확정하지 않고 설계 문서를 함께 검토하기로 했다.
- 기존 Loom 코어를 유지하면서 템플릿·마켓플레이스로 확장하는 방향과 Orca 등 기존 도구 대비 제품 가치를 추가 검토하기로 했다.
논의 배경
Pi를 직접 사용한 뒤 Loom 저장소를 다시 보면서 두 시스템을 기능 차이로 비교하기보다 무엇을 정본으로 소유하는지로 구분할 필요가 생겼다. 홍용재가 준비한 설계 문서를 바탕으로 실행 계층, 완료 검증, 재사용과 제품 방향을 검토했다.
안건별 상세 기록
안건 1. Pi와 Loom이 소유하는 권한 구분
문제 또는 질문
두 시스템의 차이를 어떤 정본과 authority를 소유하는지로 어떻게 설명할 것인가?
사람별 의견
- 홍용재: Pi는 루프·스킬·도구·에이전트·실행 절차처럼 일을 어떻게 수행할지를 소유하고, Loom은 Job·Task·상태·메모리·결정·의존성·이력·완료 조건을 소유한다고 정리했다. — 둘 다 비슷한 기능을 구현할 수 있으므로 기능 목록보다 시스템의 정본이 무엇인지가 더 정확한 구분이라고 봤다.
- 김희성: Pi는 기본적으로 비어 있는 그릇이고 Loom 확장도 얹을 수 있으며, Loom은 태스크 앞뒤의 컨텍스트와 검증을 강하게 통제한다고 설명했다. — Pi가 Loom을 대체하기보다 서로 다른 계층을 담당한다는 관점에 동의했다.
검토한 선택지
- Pi가 Loom을 대체
- Loom이 실행 절차까지 모두 소유
- Pi의 execution authority와 Loom의 workflow authority를 구분
결론
Pi는 execution procedure authority, Loom은 workflow authority를 소유한다는 구분을 현재의 작업 가설로 사용한다.
상태: 잠정 합의
안건 2. Execution binding 계층 제안
문제 또는 질문
Loom 태스크가 실제 실행 방식을 어떻게 선택하고 외부 하네스에 연결할 것인가?
사람별 의견
- 홍용재: 태스크와 실행기 사이에 execution binding을 두고 direct agent, Pi, script/CLI, external harness, nested loop 등의 방식을 선택하게 하자고 제안했다. — 태스크의 목적과 완료 조건은 Loom에 남기면서 실제 수행 방법을 외부 실행기로 열어두기 위해서다.
- 김희성: 사용자 선택은 human-in-the-loop 오케스트레이션으로 이해할 수 있지만, 실제 사용에서는 오케스트레이터가 자동 선택하는 흐름도 필요하다고 봤다. — 태스크마다 사용자가 실행기를 일일이 선택하면 부담이 커질 수 있기 때문이다.
검토한 선택지
- 사용자가 실행기를 직접 선택
- 스킬·오케스트레이터가 자동 선택
- 기존 direct agent 방식만 유지
결론
Execution binding은 확장 후보로 유지하되, 사용자 직접 선택과 자동 오케스트레이션의 경계는 설계 문서를 검토한 뒤 결정한다.
상태: 잠정 합의
안건 3. 외부 실행 성공과 Loom 완료 판정 분리
문제 또는 질문
외부 실행기가 성공했을 때 Loom 태스크를 언제 완료로 인정할 것인가?
사람별 의견
- 홍용재: 외부 실행기가 success를 반환해도 커밋·배포·사용자 승인·스모크 테스트 등 태스크 계약을 충족하지 못하면 Loom은 done으로 처리하면 안 된다고 정리했다. — 실행 성공은 작업 절차의 성공일 뿐 프로젝트 차원의 완료 조건과는 다르기 때문이다.
- 김희성: 이 구분이 Loom이 처음부터 강하게 통제하려던 앞뒤 컨텍스트와 검증의 역할을 정확히 설명한다고 동의했다. — 실행 계층을 외부로 열어도 최종 acceptance 권한은 Loom에 남아야 하기 때문이다.
검토한 선택지
- 외부 실행 성공을 즉시 done으로 처리
- Execution report를 Loom acceptance gate가 다시 검증
결론
외부 실행 결과는 report와 artifact로 정규화하고, Loom acceptance gate가 태스크 계약을 검증한 뒤 최종 완료를 판정한다.
상태: 확정
안건 4. 제품 방향과 템플릿·마켓플레이스 확장
문제 또는 질문
Loom을 어떤 제품 위치와 재사용 단위로 확장할 것인가?
사람별 의견
- 홍용재: 워크플로우 템플릿과 task execution definition을 나누고, 노드·루프·스킬·검증 규칙·정책 팩을 마켓플레이스로 공유하는 구조를 제안했다. — 기존 Loom 코어를 유지하면서 외부 실행 방법과 검증된 재사용 단위를 열기 위해서다.
- 김희성: 워크플로우 관리 자체는 Orca 같은 기존 도구가 강하므로, Loom은 CLI와 무거운 워크플로우 도구 사이의 가벼운 계층이라는 가치가 더 선명해야 한다고 피드백했다. — 이미 잘 해결된 문제를 반복하기보다 개발자가 CLI에서 시작해 워크플로우를 소유·공유하는 지점을 차별화해야 하기 때문이다.
검토한 선택지
- 범용 워크플로우 도구 강화
- CLI와 워크플로우 도구 사이의 가벼운 계층
- 템플릿·마켓플레이스 중심 확장
결론
기존 Loom 코어는 유지하되 제품 위치, execution binding의 필요성, 마켓플레이스 범위는 추가 자료를 함께 읽고 재검토한다.
상태: 미결정
결정 사항
| 상태 | 결정 내용 | 결정 이유 |
|---|---|---|
| 잠정 합의 | Pi의 execution procedure authority와 Loom의 workflow authority를 구분하는 관점을 작업 가설로 사용한다. | 기능 목록보다 각 시스템이 소유하는 정본과 상태를 기준으로 설명하는 편이 정확하기 때문이다. |
| 확정 | 외부 실행 성공과 Loom 태스크 완료를 분리하고, Loom acceptance gate가 최종 완료를 판정한다. | 실행 성공만으로 태스크 계약의 커밋·배포·승인·검증 조건이 충족됐다고 볼 수 없기 때문이다. |
| 잠정 합의 | Execution binding은 확장 후보로 유지하되 사용자 선택과 자동화 방식은 추가 검토한다. | 구조는 이해했지만 필요성과 사용성에 대한 질문이 남아 있기 때문이다. |
| 잠정 합의 | 기존 Loom 코어를 갈아엎지 않고 외부 실행기와 재사용 템플릿을 연결하는 확장 방향을 검토한다. | 현재 구조가 실행 계층을 추가할 수 있게 분리돼 있지만 제품 차별화는 더 검증해야 하기 때문이다. |
행동 항목
| 담당자 | 할 일 | 결과물 | 기한 | 상태 |
|---|---|---|---|---|
| 홍용재 | Execution binding, acceptance gate, 재사용 템플릿과 마켓플레이스 구조를 담은 설계 자료를 공유한다. | 상세 설계 문서 | 회의 후 | 예정 |
| 홍용재 | 설계 문서의 Wiki 계층과 일반 사용자·개발자용 확장 범위 설명을 보강한다. | 보강된 설계 문서 | 미정 | 예정 |
| 김희성 | 공유된 설계 문서를 읽고 execution binding의 필요성, 자동 선택 구조, 제품 방향에 대한 피드백을 정리한다. | 설계 피드백 | 미정 | 예정 |
| 김희성 | Orca의 워크플로우 구조를 설명하는 참고 영상을 공유한다. | Orca 참고 자료 | 미정 | 예정 |
미결 사항과 위험 요소
- Execution binding을 별도 제품 계층으로 둘 필요가 충분한지
- 사용자가 실행기를 직접 선택하는 범위와 오케스트레이터가 자동 선택하는 범위를 어떻게 나눌지
- Orca 등 기존 워크플로우 도구와 비교한 Loom의 명확한 제품 가치가 무엇인지
- 노드·루프·스킬·검증 규칙·정책 팩 중 무엇을 마켓플레이스의 핵심 재사용 단위로 삼을지
- Wiki와 Hermes 메모리를 어떤 방식으로 연결할지
원본 및 검증 메모
- 원본 파일:
26-08-28_loom_설계_이해.txt - 입력 방식: 텍스트 원본 직접 정리
- 기록 분류 근거: Pi와 Loom이 소유하는 권한과 상태의 차이, execution binding, 완료 검증 게이트, 템플릿·마켓플레이스 확장 방향을 검토한 설계 회의였다.
- 분류 신뢰도: 96%
확인이 필요한 내용
Clova 전사의 참석자 1은 김희성, 참석자 2는 홍용재로 대화 중 직접 호명과 Loom 개발 맥락을 근거로 매핑했다.
참석자 3은 김정현으로 보이며 직접 발화가 있으나 실질적인 안건 의견은 없어 사람별 의견에는 넣지 않았다.
처리 시작 시 파일명은 26 08 29였지만 사용자가 8월 28일 연속 회의로 지정했고, 현재 파일명도 26-08-28_loom_설계_이해.txt로 정리되어 발행일을 2026-08-28로 확정했다.
Room/룸, 파이, 헤르메스, 오르카, 하니스 등의 음차는 Loom, Pi, Hermes, Orca, 하네스로 정규화했다.
Execution binding과 제품 방향은 회의에서 확정하지 않고 설계 문서 검토 후 다시 논의하기로 했다.
본문에서 제외한 잡담·중복 내용: 2건 (로컬 structured.json에서만 검토)