사용자 흐름 — HeyMoa
갱신일 2026-08-12 · 기준: 세 저장소 워킹트리 + IA · SA · 도메인 모델 이 문서가 갖는 것: 회의 하나가 시작되기 전부터 끝난 뒤까지 사용자가 실제로 하는 일과, 그 각 지점에서 시스템이 아는 것. 여기 없는 것: 화면 트리(IA) · 모듈 배치(AA) · 프로토콜(SA) · 도메인 규칙(도메인 모델).
네 축(IA·AA·SA·CA)은 구조를 세로로 자른다. 이 문서는 시간으로 가로로 자른다. 같은 시스템을 두 방향에서 보면 어느 한쪽에서만 보이는 구멍이 있다 — 이 문서가 여는 것이 그 구멍이다.
1. 회의 하나가 지나가는 길
세 구간의 무게가 다르다. 회의 중과 회의 후는 코드가 두껍고 회의 전은 거의 비어 있다. 그리고 점선이 지금 제품의 모양을 결정한다 — 회의 하나가 그 안에서 닫힌다.
| 구간 | 시스템이 아는 것 | 코드가 있는 곳 |
|---|---|---|
| 회의 전 | 제목 · 참여자 이름 · 어느 프로젝트인가 | note · project |
| 회의 중 | 발화 텍스트 · 시각 · 누가 시작했나 | transcription · agentchat |
| 회의 후 | 요약 3종 · 대화 기록 · 외부 이슈 링크 | analysis · agentchat · integration |
2. 회의 전 — 제목 하나가 전부다
노트 허브의 새 회의 만들기 로 노트가 하나 생긴다. 상태는 NOT_STARTED 이고, 그때 채울 수 있는 칸은 제목과 참여자뿐이다.
| 사용자가 하는 일 | 저장되는 것 | 누가 할 수 있나 |
|---|---|---|
| 노트 만들기 | notes 행 하나 (NOT_STARTED) | MEMBER 이상 |
| 프로젝트에 넣기 | notes.project_id | 만드는 사람 |
| 참여자 적기 | note_participants | 노트를 볼 수 있는 사람 |
| 사람 초대하기 | workspace_invitations + SES 메일 | ADMIN만 |
| Linear · GitHub 연결 | tool_connections (암호화) | ADMIN만 |
참여자는 이름표이지 접근 제어가 아니다. 열람 경계는 워크스페이스 멤버십이 진다 — 참여자 목록에 없어도 같은 워크스페이스면 노트를 연다.
프로젝트는 URL에 없다. 사이드바와 목록의 그룹핑 축으로만 존재하고, 노트는 워크스페이스 안에서 유일하게 식별된다 (IA §3).
여기서 무슨 일이 안 일어나나
이 구간에는 AI가 없다. 노트를 만드는 순간부터 녹음 버튼을 누르는 순간까지 LLM 호출이 한 번도 없고, 회의 내용에 대해 시스템이 가진 사전 지식은 사용자가 친 제목 문자열 하나다.
| 없는 것 | 그래서 |
|---|---|
| 안건 · 배경 · 읽고 올 자료 | 요약 프롬프트에 회의의 목적이 안 들어간다 |
| 프로젝트 설명 · 팀 용어 | 고유명사와 약어가 전사·요약에서 매번 새로 등장한다 |
| 지난 회의에서 넘어온 것 | 이전 결정·미완 액션 아이템을 화면이 먼저 보여주지 않는다 |
| 일정 · 예약 | 노트 생성 시각과 회의 시각이 같다고 가정한다 |
3. 회의 중 — 여기가 제일 두껍다
| 사용자가 하는 일 | 규칙 |
|---|---|
| 녹음 시작 · 중지 · 재개 · 종료 | 최초 시작자 1인만. 나머지는 뷰어이고 버튼이 화면에 없다 |
| 전사 보기 | 뷰어도 실시간으로 본다. 노트 토픽 팬아웃 |
| 공유 챗봇에 묻기 | IN_PROGRESS 에만 쓸 수 있다. 한 번에 한 명 — 서버 소유 입력 잠금, 대기 큐 없음 |
| 도구 쓰기 승인 | 그 메시지를 넣은 본인만. 관전자에게는 대기 상태만 보인다 |
이 구간에 개인 챗봇은 없다. 노트 side 면에서는 숨긴다 — 화면당 입력 가능한 챗봇은 항상 하나다 (IA §5).
회의 중에 시스템이 못 하는 것 셋
| 무엇 | 왜 |
|---|---|
| 누가 말했는지 모른다 | ElevenLabs가 화자 분리를 제공하지 않고, transcript_segments 에 speaker 칼럼 자체가 없다 (APP-233) |
| 누가 보고 있는지 모른다 | presence를 만들지 않았다. 오프라인 회의에서 아바타 3개는 「3명이 회의 중」으로 읽히는데 실제로는 8명이 앉아 있다 |
| 먼저 말을 걸지 않는다 | 개입은 전부 pull이다. 사용자가 공유 챗봇에 물어야 답이 온다 |
세 번째가 설계다. Event Assistant(push 계열)는 MVP 4로 잡혀 있고 개입 조건도 3종으로 미리 좁혀 뒀다 (도메인 모델 § 대화·개입 표면).
4. 회의 후 — 한 방에 정리하고 끝낸다
회의 종료 하나가 상태를 ENDED 로 옮기고 분석 잡을 만든다. 사용자가 누르는 버튼은 그 하나뿐이고 나머지는 서버가 한다.
| 시각 | 일어나는 일 | 사용자에게 보이는 것 |
|---|---|---|
| T+0 | analysis_job INSERT · ai로 push · 202 | 요약 보기 로 라벨이 바뀐다 |
| T+수십초 | ai가 섹션 3종을 병렬 생성 · 임베딩 적재 | 아무것도 없다. web이 3초 폴링 중 |
| 도착 | callback → meeting_items 영속화 | 요약 탭에 OVERVIEW · ACTION_ITEM · DECISION |
| 그 뒤 | 개인 챗봇(노트 스코프)으로 갈아탄다 | 공유 챗봇은 읽기 전용 아카이브 |
| 사용자가 하는 일 | 어디로 나가나 |
|---|---|
| 요약 읽기 | — |
| 개인 챗봇에 묻기 | 노트 스코프면 전사 통째 주입, 워크스페이스 스코프면 검색 |
| Linear · GitHub 이슈로 내보내기 | 챗봇의 쓰기 도구 → 승인 → 외부 기록. 명의는 연동 계정(ADMIN) |
| 다시 분석 | 실패한 잡을 사람이 되돌린다 |
회의 후에 끊어져 있는 것 둘
| # | 무엇 | 지금 |
|---|---|---|
| ① | 요약 문장이 어느 발화에서 나왔는지 이어지지 않는다 | server가 세그먼트 ID를 갖고도 ai로 넘길 때 버렸다. 근거 구조는 설계 완료(APP-391), 구현 전 |
| ② | 화면을 닫은 사람은 요약이 끝난 것을 영영 모른다 | 완료 push 채널이 없다. web 3초 폴링이 유일하고, 폴링은 화면이 떠 있을 때만 돈다 |
①이 열려 있는 것 ①이다. 요약을 믿을 수 있게 만드는 고리가 이것 하나뿐인데 아직 없다.
5. 다음 회의로 넘어가는 것 — 없다
이 문서를 따로 쓴 이유가 여기다. 세로로 자르면 안 보이고 시간으로 자르면 바로 보인다.
노트들은 나란히 놓여 있을 뿐 서로를 모른다. 회의를 가로지르는 경로는 개인 챗봇의 워크스페이스 스코프 검색 하나이고, 그것도 사용자가 정확히 물었을 때만 작동한다.
| 이어질 수 있었던 것 | 왜 안 이어지나 |
|---|---|
| 결정 | meeting_items 의 markdown 문자열이다. 이전 결정과 대조할 키가 없다 |
| 액션 아이템 | 같은 문자열 안에 있다. 프로젝트 단위로 모으려면 파싱해야 한다 — 그래서 「할 일」 탭(S17)이 아직 없다 |
| 반복되는 용어·고유명사 | 매 회의 처음부터 다시 등장한다. 전사 오인식도 매번 새로 난다 |
| 회의의 목적 | 애초에 어디에도 안 적혀 있다 (§2) |
여기서 세 가지가 한 뿌리로 모인다. 회의 전이 비어 있는 것, 회의 후 산출물이 문자열인 것, 회의끼리 안 이어지는 것은 각각의 결함이 아니라 같은 빈칸의 세 얼굴이다 — 회의 바깥에 사는 데이터가 없다.
그 빈칸을 채우는 설계가 확장 판 사용자 흐름이다. 맥락을 사람이 넣는 것으로 시작해 회의 산출물이 그 자리를 채우게 만드는 것이 방향이고, ActionItem 1급 객체화와 Decision 시간축은 도메인 모델이 MVP 2·3으로 잡아 뒀다.
6. 세 구간을 어느 문서가 갖나
이 문서는 무엇이 일어나는가만 갖는다. 각 지점의 상세는 아래가 정본이다.
| 구간 | 화면 | 모듈 | 경계 | 데이터 |
|---|---|---|---|---|
| 회의 전 | IA §1.2 | AA §1.1 | — | ERD §4 |
| 회의 중 | IA §1.4 | AA §4 | SA §5 | DA |
| 회의 후 | IA §1.3 | AA §6 | SA §6·§7 | DA |
7. 설계 전제
- 회의 하나가 단위다. 지금 모든 저장·권한·삭제 사슬이
notes를 지난다. 회의를 넘는 축을 만들려면 이 전제부터 건드려야 한다. - 조작권은 1인이다. 시작한 사람만 중지·재개·종료한다. 뷰어에게는 버튼을 안 보인다 — 403은 최후 방어선이지 UX가 아니다.
- 개입은 pull 이다. 시스템이 먼저 말을 걸지 않는다. push 계열은 별도 축으로 미뤄 뒀고 조건도 미리 좁혀 뒀다.
- 회의 전에는 LLM을 안 부른다. 지금은 부를 재료가 없어서이지 결정이 아니다 — 재료가 생기면 이 줄은 없어진다.
8. 미확인
| 무엇 | 지금 아는 것 |
|---|---|
| 회의 전 구간의 사용자 문제 | 온보딩·초대 흐름은 구현돼 있는데 어떤 문제를 푸는지 문서에 없다 (IA §7 ⑤) |
| 노트를 미리 만드는 비율 | 재지 않았다. 「회의 시작 직전에 만든다」와 「전날 만들어 둔다」의 비율이 회의 전 기능의 값을 정한다 |
| 회의 하나의 평균 길이·발화 수 | 전사 길이 상한을 정한 적이 없고 실제 전사가 몇 토큰인지 측정한 적도 없다 |
| 요약 도착까지 걸리는 시간 | 계측이 Langfuse에 있으나 사용자 체감 기준으로 정리한 적이 없다. 3초 폴링의 값어치가 여기서 갈린다 |
| 회의 후 재방문율 | 요약을 한 번 읽고 끝인지 다시 여는지 모른다. 회의를 넘는 축의 우선순위가 여기서 갈린다 |