본문으로 건너뛰기

ADR-0008: 맥락은 회의 시작 시각에 얼리고, 본문이 아니라 리비전을 참조한다

  • Status: Proposed — 아직 팀이 승인하지 않았다. 결정 주체는 server 담당이고, 착수 시점은 사용자 흐름 §8의 3–5주차다
  • Date: 2026-08-12

Context​

사람이 쓴 맥락(워크스페이스 용어집 · 프로젝트 브리프 · 회의 전 안건)을 요약·채팅·회의 중 게이트에 넣기로 했다. 설계는 확장 판 사용자 흐름이 갖는다.

제약은 셋이다.

  1. 맥락은 회의보다 오래 산다. 프로젝트 브리프는 주 단위로 바뀌고 회의는 45분이다. 회의가 끝난 뒤에도 계속 고쳐진다.
  2. 재분석이 있다. 사용자가 「다시 분석」을 누를 수 있고, 워치독도 실패한 잡을 다시 돌린다.
  3. 요약을 검증해야 한다. 잘못된 요약이 나왔을 때 원인이 프롬프트인지 전사인지 맥락인지 갈라야 한다.

셋을 겹쳐 놓으면 문제가 하나로 모인다 — "이 회의는 무엇을 입력으로 받았나"에 답할 수 있어야 한다. 맥락을 현재 값으로 매번 읽으면 그 답이 시간에 따라 변한다.

Decision​

녹음이 시작되는 시각에 맥락 세 층의 리비전 ID를 노트에 박고, 그 회의의 모든 모델 호출은 그 리비전을 쓴다. 회의 도중이든 끝난 뒤든 맥락이 바뀌어도 그 회의의 입력은 안 바뀐다. 재분석도 같은 리비전을 쓴다.

맥락은 본문을 노트에 복사하지 않고 context_revisions 행을 참조한다. 그 테이블은 append-only이고 UPDATE·DELETE 하지 않는다.

박는 시점은 기능 플래그와 같다 — 회의 시작이 「이 회의의 입력을 확정하는 시각」이고, 거기 걸리는 것을 두 종류로 늘리되 장치는 하나만 만든다.

Alternatives​

대안왜 버렸나
현재 값을 매번 읽는다앞 20분과 뒤 25분의 게이트 판정 기준이 갈린다. 재분석이 다른 답을 내고 왜 바뀌었는지 답할 수 없다. 셋 중 제일 싸지만 세 제약을 전부 어긴다
본문을 노트에 통째로 복사한다얼리는 목적은 달성된다. 다만 회의당 최대 8KB이고 10만 규모면 월 440MB가 같은 문장의 복사본으로 쌓인다. 참조가 같은 일을 하고 저장량이 안 는다
리비전을 남기되 오래된 것은 지운다지운 리비전을 가리키던 회의가 고아가 된다. 「이 회의가 무엇을 받았나」를 못 답하게 되는 시점이 보존 기간과 같아지고, 그 시점이 언제인지 아무도 모른다
회의 종료 시각에 얼린다회의 중 게이트가 얼린 값을 못 쓴다. 그리고 종료 시각에 얼리면 회의 중에 맥락을 고칠 수 있게 되는데, 그게 첫 번째 대안과 같은 문제다

Consequences​

좋아진 것

  • 재분석이 결정적이다. 같은 노트를 몇 번 돌려도 입력이 같다.
  • 요약을 검증할 수 있다. note_contexts 세 행이 그 회의의 입력을 그대로 가리킨다.
  • 회의 중 프리픽스가 안 바뀌므로 prompt caching이 회의 전체에서 산다.
  • 저장량이 안 는다. 회의 55,000건이 같은 리비전 하나를 가리켜도 행 세 개씩이다.

감수한 것

  • 맥락 리비전을 영구 보관한다. 워크스페이스가 지워질 때만 같이 간다. 보존 기간 정책의 예외가 하나 는다(DA §6).
  • 오타를 고쳐도 이미 시작한 회의에는 안 반영된다. 사용자에게는 이게 버그로 보인다. 그래서 노트 화면이 「이 회의는 8/5자 맥락으로 정리했다」를 한 줄 적는다(IA §1).
  • scope_ref_id 에 FK를 못 건다. projects·notes 둘을 가리키는 다형 참조이고, 자식이 안 매달려서 nullable FK 둘로 푸는 값이 안 맞는다. 고아 정리를 앱이 진다(ERD §6).

뒤집히는 조건 — 사용자가 회의 중에 맥락을 고치는 것을 강하게 요구하고, 그 요구가 「입력이 회의 중간에 갈려도 된다」를 함께 받아들일 때. 그때는 리비전을 회의 중에 다시 박는 규칙이 필요하고, 게이트 판정 이력에 어느 리비전으로 판정했는지가 같이 남아야 한다.