Flogi 4차 회의 — 발표 시연 구조와 역할 조정
기록 개요
- 기록일: 2026년 8월 24일
- 참석: 홍용재, 김희성, 김정현
- 원본 구성: 같은 날짜·같은 회차로 나뉜 2개 음성 기록을 한 회의로 통합
- 성격: 9월 발표 직전 각 결과물을 점검하고, 발표의 핵심 메시지·설명 순서·시연 책임을 잠근 4차 회의
회의 안건
- 지금까지 만든 발표 자료, Runtime, Viewer, OHAYO 진행 상황 확인
- Model, Agent, Harness, Loop를 설명하는 순서와 발표 시간
- 작은 Loop 시연과 OHAYO 결과물의 역할 분리
- Loom의 Job·Task 정보와 Viewer Node를 연결하는 방식
- 비개발 직군의 반복 업무 조사와 Domain Loop 과제
- Flogi 블로그의 발행 방식과 회의 기록 우선순위
- 담당자별 마감 작업과 후속 회의
각 사람의 의견
김희성
- 발표의 주인공은 Loom 제품이 아니라 사용자가 에이전트의 Workflow와 Loop를 설계하고 소유하는 방식이어야 한다고 강조했다.
- 문제와 하네스 흐름을 먼저 보여주고, 개념 설명 뒤에 실제 결과와 Viewer를 배치하는 구성을 제안했다.
- 자신이 준비한 전체 Context 설명은 약 30분을 기준으로 하되, 실제 발표에서는 20~25분 분량으로 준비해 전환 시간을 확보하자고 했다.
- 청중이 Workspace와 Context Window, Tool Call을 모르면 Loop 설명을 따라오기 어려우므로 Agent가 정해진 Workspace에서 Read, Write, Bash 같은 Tool을 실행하는 기본 구조를 분명히 설명해 달라고 요청했다.
- Node와 Edge로 구성된 Harness Viewer 템플릿을 제시하고, 실제 Runtime과 완전히 동일한 내부 추론을 재현하기보다 Task 생성·진행 상태를 사람이 이해할 수 있게 번역하는 화면으로 사용하자고 했다.
홍용재
- Model, Tool, Agent, Harness, Loop를 기술적으로 연결하고, Loom의 Job·Task 생성과 실행 기록을 Viewer가 읽을 수 있게 만들겠다고 했다.
- Job은 하나의 Loop 전체, Task는 그 Loop를 이루는 구성 요소로 보고, 실제 발표에서는 너무 원자적인 내부 동작 대신 Task 수준의 Node를 보여주는 편이 적절하다고 정리했다.
- 김정현이 사용할 Loom Job의 골격을 만들고, Listener가 활동 로그를 읽어 웹 화면에 Node와 요약 상태를 띄우는 기술 검증을 맡겠다고 했다.
- OHAYO 전체를 현장에서 다시 생성하려 하면 결과 변수를 통제하기 어려우므로, 작은 Loop의 작업 과정을 시연하고 이미 배포된 OHAYO는 실제 결과 사례로 분리하자고 했다.
- 먼저 Task 데이터가 Viewer에 맵핑되는지 검증한 뒤, 생성 과정과 실행 애니메이션을 어디까지 붙일지 결정하자고 했다.
김정현
- 대학생, 유치원·초등학교 교사, Shorts 제작자, 마케팅 실무자 등 주변 사례를 조사해 자료 수집, 반복 입력, 문서 정리, 제목·썸네일 제작, 레퍼런스 재구성 자동화 수요를 정리했다.
- 이 사례 가운데 하나 이상을 선택해 비개발자가 실제로 쓸 수 있는 Loop로 만들고, 결과가 한 번에 나오도록 Prompt와 반복 과정을 설계해 보겠다고 했다.
- 발표 시연에서는 자신이 CLI에 입력할 Prompt와 행동 순서, 각 단계에서 Viewer에 나타나야 할 Node와 최종 결과를 Script로 정리하기로 했다.
- 블로그에는 자동화 루틴을 소개하는 콘텐츠와 개발·실험 기록을 정기적으로 나누어 싣는 방안을 제안했고, UI 개선도 공부해 시안을 제시하겠다고 했다.
논의와 결정
발표의 중심
- 더 좋은 Agent를 소개하는 세션이 아니라, Agent가 어떻게 일할지를 사용자가 설계하는 방법을 보여준다.
- 설명 순서는 Model, Model과 Tool로 구성된 Agent, Agent가 일하는 Harness, Context·Skill·Hook·Workflow, Loop와 검증으로 잡는다.
- Workspace와 Context Window, 기본 Tool 실행 방식을 개념 구간에 포함한다.
세 가지 시연 요소의 경계
- 작은 Loop는 사용자가 작업 단계를 직접 설계할 수 있다는 개념 증명으로 사용한다.
- OHAYO는 실제 Workflow가 배포 가능한 서비스로 이어진 결과 사례로 사용하고 QR로 접근할 수 있게 한다.
- Loom은 복잡한 작업에서 State, Memory, Validation, Strong Control을 제공하는 확장 방향으로 소개한다.
- OHAYO 전체를 발표 중 다시 만들지 않고, 작은 과제의 실행 과정과 배포된 결과를 분리한다.
Runtime과 Viewer
- 하나의 Loom Job을 한 Loop로, 그 안의 Task를 약 10개 안팎의 이해하기 쉬운 단계로 단순화한다.
- 김정현의 Prompt로 Task를 만들고, 생성된 Task의 제목과 요약 상태를 Viewer Node로 표시한다.
- 실제 Agent의 내부 추론을 모두 보여주려 하지 않고, 사람이 확인 가능한 Task 생성·실행 기록과 결과를 화면에 나타낸다.
- 마지막 실행에서는 Listener가 활동 로그를 읽고 단계 진행을 애니메이션으로 보여주는 방식을 시험한다.
- 홍용재가 Job·Task 골격과 로그 연결을, 김희성이 Viewer 표현을, 김정현이 Prompt·행동 Script와 화면에 필요한 내용을 맡는다.
- 먼저 Task 생성 정보가 화면에 안정적으로 맵핑되는지 검증하고, 성공한 뒤 전체 실행 표현을 확장한다.
비개발 Domain Loop
- 김정현이 조사한 다섯 직군의 사례는 단순 설문 결과로 남기지 않고 실제 Loop 후보로 만든다.
- 다섯 사례를 모두 한 번에 완성할 필요는 없으며, 하나부터 시작해 어떤 Agent나 도구를 사용해도 반복 가능한 결과가 나오도록 구성한다.
- Pi와 Agent 사용법을 직접 익히는 과정까지 김정현의 역할 검증에 포함하고, 막히는 지점은 팀에 세부 질문으로 공유한다.
블로그 운영
- 개인별 작업 기록은 각자의 CLI에서 Agent에게 원본을 전달해 글로 만들고 발행한다.
- 기존 작성자와 태그 필터를 재사용하므로, 이 발행 방식을 위해 새 프론트엔드 기능을 먼저 추가하지 않는다.
- 현재 가장 먼저 쌓아야 할 콘텐츠는 회의 기록으로 본다.
- 자동화 루틴과 개발 리포트를 주기적으로 묶어 발행하는 안은 좋은 후보로 유지하되, 구체적인 요일과 자동 스케줄은 후속 구현에서 정한다.
발표 시간과 안정성
- 전체 세션은 약 90분을 기준으로 하고, 개념·맥락과 시연에 충분한 시간을 나눈다.
- 개별 설명은 실제 배정 시간보다 짧게 준비해 지연 여유를 둔다.
- 발표일은 9월 4일을 기준으로 준비한다.
행동 항목
- 김희성: 오프닝과 트렌드, HTML 발표 통합, Viewer와 Loop 시각화, 전체 전환 문장.
- 홍용재: Agent 기본 개념 설명, Loom Job·Task 골격, Listener와 Viewer 연결, 배포된 결과 화면.
- 김정현: Task 생성 Prompt와 시연 행동 Script, Viewer에 필요한 Node·결과 정의, 비개발자 Domain Loop 하나 이상, 블로그 UI 시안.
- 공동: 큰 설계를 한 번에 고정하지 않고, 작은 결과를 만든 뒤 Discord에서 짧게 확인하는 회의를 반복한다.
남은 쟁점
- Task 생성과 실행 상태 중 어떤 시점을 화면에 표시할지, Loom 내부 필드를 어떤 Node에 맵핑할지는 실제 연결 검증 뒤 확정한다.
- 개발자용 CLI와 비개발자용 간단한 UI를 분리할지, 모바일 앱·알림·길잡이 기능을 넣을지는 아이디어로만 논의했고 결정하지 않았다.
- Loom이 장기적으로 독립 Agent인지 범용 Runtime인지, Marketplace를 어떻게 운영할지도 발표 이후 검증 과제로 남겼다.