에이전트 채팅 — 워크스페이스
회의 밖에서 도는 채팅이 어떤 순서로 도는가?
범위 지정 · 맥락 조회 · 도구 승인 · 인스턴스가 갈리는 경우를 그린다.
회의 중 채팅과 무엇이 다른가 — 여기는 회의가 안 돌고 있어도 된다. 맥락이 실시간 전사가 아니라 이미 확정된 회의록들이고, 그래서 회의록을 만들고 고치는 도구를 쓸 수 있다.
1. 범위가 먼저다
채팅은 범위 없이 시작하지 않는다. 범위가 워크스페이스인지 회의록인지에 따라 읽는 맥락과 활성 채팅의 유일성이 갈린다.
⚠️ 사용자·범위마다 활성 채팅이 하나뿐이다. 스키마가 강제한다. 새 채팅을 열면 이전 것이 비활성이 된다.
2. 정상 흐름 — 질의와 응답
| 규칙 | 내용 |
|---|---|
| relay 는 변환하지 않는다 | realtime 이 토큰을 그대로 통과시킨다 |
| 맥락 조회는 ai → api | agentcontext 모듈이 그 표면이다. 화면이 없는 유일한 모듈 |
| 벡터 검색은 ai 가 자기 DB 에서 | 업무 데이터베이스와 조인하지 않는다 |
⚠️ 동시 스트림이 좁게 묶여 있다 — relay 가 블로킹 I/O 라 스트림 하나가 스레드 하나를 응답 끝까지 문다. 도구 왕복이 있는 턴은 분 단위로 늘어난다. 스트림별 자원 분리 · AI 오토스케일 · 큐를 프로세스 밖으로를 한 묶음으로 풀어야 한다.
3. 도구 승인 — 인스턴스가 갈리는 자리
이게 이 흐름에서 가장 깨지기 쉬운 곳이다. 승인 버튼을 누른 요청이 스트림을 들고 있지 않은 인스턴스로 갈 수 있다.
| 규칙 | 내용 |
|---|---|
| DB 가 정본, Pub/Sub 은 알림 | Pub/Sub 은 내구성이 없다. 발행 순간 장애면 버튼을 눌렀는데 아무 일도 안 일어난다 |
| 폴링이 보험이다 | 알림을 놓쳐도 짧은 폴링이 줍는다 |
| 승인 id 는 ai 가 발급 | 승인을 만든 쪽이 식별자를 갖는다 |
| 승인 대기 상한 300초 | 넘으면 만료 |
| 팬아웃 수단 | Redis Pub/Sub 인가 별도 브로커인가 — 아직 안 정했다 |
⚠️ 승인 요청이 뜬 채로 브라우저를 닫으면 어떻게 되는지 안 정했다. 300초 뒤 만료되지만, 그 사이에 다른 기기에서 열면 카드가 보이나가 정해진 적이 없다.
4. 채팅이 회의록을 만들고 고칠 때
이 범위의 채팅만 쓰기 도구를 갖는다.
| 무엇 | 상태 |
|---|---|
| 회의록 생성·수정 도구를 승인 뒤에 실행한다 | 그렇게 하기로 했다 |
| 외부 도구(Linear · GitHub) 실행 | 확정 |
| 어떤 도구가 승인을 요구하나 — 읽기는 그냥, 쓰기는 승인? | 미정 — 목록이 정해진 적이 없다 |