도메인 모델
갱신: 2026-08-01 (Action Item 1급 객체화 · Event Assistant 계열 분리 · 삭제 연쇄 범위) · 이전: 2026-07-27 계약 세부는 contracts/
- 워크스페이스가 멤버와 권한의 경계가 된다.
- 프로젝트가 여러 회의 기록을 묶는다.
- 노트에는 전사·요약·결정이 남는다.
- Action Item은 프로젝트 단위로 다시 모인다.
- Agent 세션은 가시성과 사용 범위를 따로 지킨다.
계층과 권한
| 행위 | ADMIN | MEMBER |
|---|---|---|
| 초대·멤버 관리 | ✅ | ❌ |
| 도구 연동 연결/해제 | ✅ | ❌ (상태 열람만) |
| 회의 시작·노트 생성 | ✅ | ✅ |
| 챗봇 통한 연동 도구 사용 | ✅ | ✅ (ADMIN의 연동 = 팀 사용 동의) |
역할 세분화·강퇴는 스코프 아웃 (2단계 부족 근거 확보 시 재검토).
회의(노트) 상태 머신
[*] → NOT_STARTED → IN_PROGRESS ⇄ PAUSED → ENDED(종료·요약 생성)
- 노트 생성은
NOT_STARTED다. 전사 세션 생성은NOT_STARTED/PAUSED를IN_PROGRESS로, 정상 종료·중단은IN_PROGRESS를PAUSED로 전이한다.ENDED는 최종 상태다. - 조작권은 최초 녹음 시작자 1인에게만 생긴다. 시작 전에는 멤버가
회의 시작할 수 있고, 시작 뒤에는 그 시작자만 중지·재개·회의 종료를 조작한다. 나머지는 뷰어다. - 시작·중지·재개는 전사 세션 start/stop 하나로 한다. 별도 meeting pause/resume 명령이나
meeting.paused실시간 이벤트는 두지 않는다.recording.started·recording.stopped를 받으면 노트·목록을 REST로 다시 읽어 늦은 이벤트와 다른 탭·기기의 조작에도 서버 상태로 수렴한다. IN_PROGRESS는 세션 생성 직후부터다. 다만 WebSocket 연결 전 READY 구간에는activeSessionStartedAt = null일 수 있으며, 이때는 아직 실제 녹음 중이 아니다.
시간과 화면 표기
| 값 | 뜻 | 화면 사용 |
|---|---|---|
meetingStartedAt | 최초 ACTIVE 전사 세션의 절대 시작 시각 | 7월 28일 오후 11:21 시작처럼 시작 시각만 표시 |
recordedDurationMs | 끝난 ACTIVE 세션들의 endedAt - startedAt 누적 | PAUSED·ENDED의 기록 시간 |
activeSessionStartedAt | 현재 ACTIVE 세션의 실제 시작 시각. READY·비활성 세션이면 null | IN_PROGRESS의 진행 중 구간 계산 |
- 현재 누적 기록 시간은 NOT_STARTED
0, IN_PROGRESSrecordedDurationMs + (now - activeSessionStartedAt), PAUSED·ENDEDrecordedDurationMs다.activeSessionStartedAt이 null인 READY는 기존recordedDurationMs를 그대로 보인다. now - meetingStartedAt은 쉬는 시간을 섞으므로 회의/기록 시간으로 표시하지 않는다. | 시나리오 | 상태 순서 | 시간 | |---|---|---| | 생성만 |NOT_STARTED| 시작 시각 없음, 누적 0 | | 시작 → 직접 종료 |NOT_STARTED → IN_PROGRESS → PAUSED → ENDED| 확인 한 번 안에서 마지막 활성 구간까지 누적 | | 시작 → 중지 → 종료 |NOT_STARTED → IN_PROGRESS → PAUSED → ENDED| 중지 시점 누적을 유지 | | 시작 → 중지 → 재개 → 중지 |NOT_STARTED → IN_PROGRESS → PAUSED → IN_PROGRESS → PAUSED| 두 활성 구간의 합, 중지 구간 제외 | | 중지/재개 반복 → 최종 종료 |IN_PROGRESS ⇄ PAUSED → ENDED| 모든 활성 구간만 합산하고 종료 뒤 고정 |- 워크스페이스 내 서로 다른 노트의 동시 녹음 허용, 같은 노트 이중 조작만 금지
- final 세그먼트는 확정 즉시 저장. 요약 3종(overview/actionItems/insights, markdown)은 종료 시 생성, 실패 시 재분석
챗봇 2종
| 항목 | 공유 챗봇 | 개인 챗봇 |
|---|---|---|
| 소속 | 노트 (1건당 1개, 영구 세션) | 사용자 글로벌 1개 |
| 가시성 | 노트 열람 가능한 전 멤버 | 본인만 |
| 쓰기 | IN_PROGRESS에만 (PAUSED·ENDED는 읽기 전용) | 항상 |
| 동시성 | 한 번에 한 명 — 서버 소유 입력 잠금, 대기 큐 없음 | — |
| 세션 | "새 대화" 없음 — 회의 기록의 일부 | 스코프 대상별 활성 세션(워크스페이스 1 + 노트당 1), "새로운 대화 시작"으로 교체 |
| 컨텍스트 | 해당 노트 전사(시점까지) + 요약 | 여는 위치가 결정: 워크스페이스=agentic 검색, 노트=통째 주입 |
| 스트림 | 입력자만 SSE, 관전자는 폴링(완성본+잠금 상태) | 본인 SSE |
시점 정렬: 전사 세그먼트·챗봇 메시지 모두 서버 타임스탬프 — 별도 앵커 없이 시간으로 조인 (아카이브 타임라인 뷰).
도구 실행·승인 모델
- 도구 정의에 조회/쓰기 메타데이터: 조회=자동, 쓰기=승인
- 승인 주체는 입력자 본인. 관전자에게는 대기 상태만
- 승인·실행 결과는
role=TOOL메시지(+toolEvent)로 채팅 기록 영속화 - 승인 대기 중 SSE keepalive. pendingApproval 존재 시 잠금 타임아웃 정지, 승인 타임아웃이 잠금 해제 트리거
- 외부 기록 명의는 연동 계정(ADMIN) — 실제 수행자는 채팅 기록으로 추적 (수용된 트레이드오프)
프로젝트 기억 도메인
2026-08-01 정체성 확정으로 이 도메인이 제품의 본체가 되었다. ActionItem은 MVP 2에 착수하고, Decision·Change는 MVP 3에 설계한다.
ActionItem 🔧 MVP 2 — 1급 객체로 승격
현재는 요약 3종의 markdown 문자열 안에 있다. 구조화 레코드로 바꾼다 — 명세: F8-1
| 필드 | 필수 | 비고 |
|---|---|---|
content | ✅ | |
assignee · dueDate | — | 추출 실패 시 null. 억지로 채우지 않는다 |
status | ✅ | proposed → confirmed / rejected → done |
evidence | 조건부 | 전사 세그먼트 FK + 타임스탬프. origin=ai면 필수 |
sourceNoteId | ✅ | |
origin | ✅ | ai / user |
- AI 추출물은 항상
proposed로만 저장된다. 어떤 경로로도 AI가confirmed를 쓸 수 없다 - 확정 권한: 회의 시작자 1인 + ADMIN(시작자 부재 시). 다른 멤버는 제안만
- 구조화 레코드가 원본이고 markdown은 렌더링 산출물이다
Decision · Change 📋 MVP 3 (방향만 고정)
스키마 설계 초안: decision-ontology.md (2026-08-04) — 시간축 필드(
supersedes·valid_from·valid_to), decision key 판정, conflict taxonomy 5종.
- Decision — 버전·번복 체인, 제안자/승인자, 원문 근거 발화 FK. 실무 관행(초과된 결정은
superseded표시 + 재검토일)과 정합하게 설계한다 - Change — 이전/이후, 사유
- 결정 번복은 예외가 아니라 정상 라이프사이클이다 (회의 유형 조사). 결정 로그의 위생 관리(아카이브·초과 표시·재검토일)가 기본 기능으로 요구된다
- 이것이 차별화 D1′의 대상이다 — 결정을 뽑는 것이 아니라 결정이 바뀐 뒤를 다루는 것
공통 규칙
- 상태 전이: 제안(proposed) → 확정(confirmed) → 외부 실행(executed). 각 전이가 감사 기록
- 저장 전략: 관계형(상태) + pgvector(의미 검색). 그래프 DB는 병목 입증 시
- 설계 원칙: 확인 부담 최소화 — 리서치 결론(구조화 비용이 성패를 가름)을 스키마·UX에 우선 반영
대화·개입 표면 — 세 계열 (2026-08-01 정리)
용어가 엉키지 않도록 축을 분리한다. 챗봇 2종은 누가 보는가로 나뉘고, Event Assistant는 누가 기동하는가가 다르다.
| 축 | 챗봇 (공유·개인) | Event Assistant |
|---|---|---|
| 기동 | 사용자가 묻는다 (pull) | Agent가 감지해 알린다 (push) |
| 대상 | 질문한 사람 또는 회의 참여자 전원 | 회의 흐름 자체 |
| 원칙 제약 | 원칙 4 (공유 기록은 회의 기록의 일부) | 원칙 6 (최소 개입) |
| 산출 | 답변 메시지 | 개입 이벤트 (화면 알림) |
| 단계 | ✅ MVP 1 | 📋 MVP 4 |
Event Assistant는 챗봇의 세 번째 종류가 아니라 별개 계열이다 (팀 판단). 페르소나형이 아니라 Event형이며, 개입 조건은 유형 무관 3종(C1 결론 없이 종료 · C2 담당자·기한 미지정 · C3 이전 결정 충돌)으로 한정한다 → FR-10
실시간 안건·결정 표시는 이 계열이 아니다. 화면에 누적되는 상태 표시(pull)이므로 원칙 6의 제약을 받지 않는다.
삭제와 연쇄 (2026-08-01 신설)
노트 삭제 시 무엇이 함께 지워지는가는 원칙 해석이 필요한 제품 판단이다. 상세 표: F1-3
| 대상 | 처리 | 근거 |
|---|---|---|
| 전사 세그먼트 · 요약 3종 · ActionItem | 함께 삭제 | 노트 파생물 |
| 공유 챗봇 기록 | 함께 삭제 | 원칙 4가 "회의 기록의 일부"로 규정 |
임베딩 (transcript_embeddings) | 함께 삭제 — 필수 | ⚠️ 이미 가동 중이다. 안 지우면 삭제한 회의 내용이 챗봇 답변에 나온다 |
| 개인 챗봇 세션 | 보존 (파생 메시지 처리는 미결) | 사용자 소유 |
| 외부 도구 이슈 | 삭제하지 않는다 | 외부 자산. 원칙 1이 금지하는 "승인 없는 외부 쓰기"에 삭제도 포함된다 |
변경 이력
| 날짜 | 변경 |
|---|---|
| 2026-07-25 | 최초 성문화 (기획 v2 + v2-draft 계약 + 검토 반영 사항 종합) |