정보 구조 (IA)
⚠︎ 지난 판 — 2026-07-26. 현재 판은 여기다. 이 문서는 그때의 기록이고 고치지 않는다.
갱신일 2026-07-26 · 기준:
web@87e0834·server@bf192cc· 도메인 규칙은pm/2-product/domain-model.md가 정본 이 문서는 사용자가 보는 정보의 계층과 그 안에서의 이동만 소유한다. 화면 구현은../web/README.md, 권한 규칙의 원본은 도메인 모델이다.
확인한 사실
계층은 셋, URL은 둘
| 계층 | 무엇 | URL |
|---|---|---|
| workspace | 초대·멤버·도구 연동·권한의 경계 | /w/{workspaceId} |
| project | 노트를 묶는 단위 | 없음 — 사이드바와 노트 패널의 그룹핑 축으로만 쓴다 |
| note | 회의 1건. 전사·요약·챗봇이 여기 붙는다 | /w/{workspaceId}/notes/{noteId} |
라우트 전부는 app/에 있다 — 위 둘에 랜딩 /, 정적 /privacy·/terms, OAuth 복귀 /auth/callback이 더해진 전부다.
챗봇 2종은 탐색 위치가 다르다
| 개인 챗봇 | 공유 챗봇 | |
|---|---|---|
| 어디서 열리나 | 워크스페이스 셸의 오버레이(workspace-app-shell.tsx의 PersonalChatProvider) | 노트 화면의 패널(shared-chat-panel.tsx) |
| 소속 | 사용자 글로벌 1개 | 노트 1건당 1개, 영구 세션 |
| 보는 사람 | 본인만 | 노트를 열 수 있는 전 멤버 |
| 쓰기 | 항상 | 회의가 ACTIVE일 때만. 이후는 읽기 전용 아카이브 |
| 동시성 | — | 한 번에 한 명(서버가 입력 잠금을 소유, 대기 큐 없음) |
| 컨텍스트를 정하는 것 | 여는 위치 — 워크스페이스에서 열면 검색, 노트에서 열면 그 노트를 통째로 | 그 노트의 전사와 요약 |
여는 위치가 곧 스코프다. 다만 scope(workspace|note)만으로는 공유 챗봇과 노트 스코프 개인 챗봇이 갈리지 않는다 — 둘 다 scope=note로 온다. 그래서 계약은 chatKind를 함께 보내도록 정했고, ai는 (chatKind, scope) 조합으로 agent profile 3종을 고른다.
다만 조사 커밋(server@bf192cc)의 server는 이 필드를 보내지 않는다(APP-172). 계약이 정한 것과 지금 흐르는 요청이 다르므로, 이 문서는 "공유 챗이 어느 profile로 간다"를 단정하지 않는다. 정합은 MVP2로 이월돼 pm/2-product/open-issues.md가 원장을 갖는다.
상태가 화면을 가른다
| 축 | 값 | 화면에서 무엇이 달라지나 |
|---|---|---|
| 회의 상태 | IN_PROGRESS ⇄ PAUSED → ENDED | ACTIVE 판정(IN_PROGRESS && meetingStartedBy != null)이 공유 챗봇 쓰기와 녹음 컨트롤을 연다 |
| 조작권 | 시작자 1인 | 나머지 멤버는 뷰어다. 중지·재개·종료 버튼이 없다 |
| 역할 | ADMIN · MEMBER | 초대·도구 연동은 ADMIN만. MEMBER는 연동 상태 열람과 챗봇을 통한 도구 사용까지 |
| 분석 결과 | 없음 → 있음 | 회의 종료 뒤 요약 3종이 노트에 붙는다. web은 폴링으로 도착을 안다 |
설계 전제
- project를 URL에 올리지 않았다. 노트는 워크스페이스 안에서 유일하게 식별되고, project는 보기 좋게 묶는 축이다. project별 화면이 생기면 그때 경로를 판다.
- 개인 챗봇은 화면이 아니라 오버레이다. 어느 노트를 보고 있든 따라다녀야 해서 라우트로 만들지 않았다. 대신 여는 위치가 스코프를 정한다.
- 공유 챗봇은 회의 기록의 일부다. "새 대화" 개념이 없고 노트와 수명을 같이 한다. 회의가 끝나면 아카이브로 굳는다.
- 전사와 챗봇 메시지는 서버 타임스탬프 하나로 정렬한다. 별도 앵커를 두지 않아서 아카이브 타임라인이 시간으로 조인된다.
미확인
| 무엇 | 지금 아는 것 | 어디를 봐야 하나 |
|---|---|---|
| 알림의 도착 방식 | server에 push 채널이 없고 GET /v1/notifications 폴링만 확인했다 | web의 폴링 주기 설정 |
| 분석 완료를 web이 아는 경로 | 설계 스펙은 STOMP push를 적었지만 실제 구현은 refetchInterval 폴링이다 | pm/2-product/open-issues.md — 스펙 정정 또는 push 구현 중 택일 |
공유 챗봇 chatKind 정합 (APP-172) | MVP1 → MVP2 이월로 등재돼 있다 | 같은 원장 |
| project가 늘어날 여지 | 도메인에는 1급 개념이고 API도 있다 | 화면 요구가 생길 때 IA를 다시 본다 |