[LLM Wiki 10] 회의록 LLM Wiki 구현 로드맵

회의록 LLM Wiki 구현 로드맵

회의록 LLM Wiki 구현 단계

회의록 LLM Wiki는 처음부터 거대한 시스템으로 만들면 실패하기 쉽다. 먼저 작은 샘플로 카드 구조, 스키마, 검색 품질을 검증하고, 그다음 qmd, Dataview, Graph Index로 확장하는 것이 좋다.

전체 로드맵

구현 순서는 위 로드맵처럼 샘플, 스키마, 검색, 운영 점검, 그래프 확장 순서로 잡을 수 있다.

처음부터 모든 단계를 만들 필요는 없다. 중요한 것은 1단계부터 3단계까지 작게 성공하는 것이다.

1단계: 회의록 20개에서 50개 샘플 준비

처음부터 수천 개 회의록을 넣지 않는다. 대표성이 있는 회의록 20개에서 50개를 고른다.

내부 제품 회의
고객 미팅
기술 설계 회의
프로젝트 sync
월간 리뷰

이 샘플로 스키마와 검색 품질을 검증한다. 작은 데이터에서 구조가 흔들리면 큰 데이터에서는 더 크게 흔들린다.

2단계: 기본 카드 타입 만들기

처음에는 다섯 가지 카드만 사용한다.

Meeting
Decision
Action
Project
Topic

확장 카드는 나중에 추가한다.

Customer
Person
Risk
OpenQuestion
MonthlySummary

먼저 회의록 하나가 Meeting, Decision, Action, Project, Topic 카드로 안정적으로 분해되는지 확인한다.

3단계: Schema와 Template 작성

최소 스키마는 다음 정도면 충분하다.

schemas/common.md
schemas/meeting.md
schemas/decision.md
schemas/action.md
schemas/project.md
schemas/topic.md

common schema에는 전체 규칙을 둔다.

원본은 수정하지 않는다.
모든 카드는 source를 가진다.
불확실하면 unknown으로 둔다.
원문에 없는 결정을 만들지 않는다.
사람 평가를 쓰지 않는다.

qmd의 search, vsearch, query 모드

4단계: qmd 검색 세팅

Wiki 카드가 생겼다면 qmd로 검색을 붙인다.

그다음 테스트 질문을 던진다.

가격 부담이 나온 고객 미팅 찾아줘
SSO 때문에 막힌 고객콜 요약해줘
6월 가격정책 관련 결정 찾아줘
Jay가 맡은 open action 보여줘

검색 결과가 기대한 카드로 이어지는지 본다.

5단계: 한국어 embedding 테스트

한국어 회의록이라면 embedding 모델을 반드시 테스트해야 한다.

가격 부담
예산 문제
도입 비용이 높다
budget concern
too expensive
cost blocker

기본 모델이 한국어와 영어 혼합 표현을 잘 연결하지 못하면 다국어 embedding을 고려한다.

6단계: Dataview로 상태 점검

Action과 Decision은 검색보다 상태 점검이 중요하다.

open action 목록
due date 지난 action
source 없는 decision
owner 없는 action
project와 연결되지 않은 meeting

이런 표가 있어야 wiki가 실제 업무 상태판처럼 동작한다.

7단계: Monthly Summary 만들기

회의록 Wiki의 가치는 요약이 누적될 때 커진다. 월간 요약 카드를 만든다.

wiki/monthly/2026-06.md

포맷은 다음과 같다.

Executive Summary
Meetings Covered
Major Decisions
Open Actions
Completed Actions
Open Questions
Project Updates
Risks / Blockers
Follow-ups for Next Month

Graph RAG에서 관계를 정의하고 추출하는 흐름

8단계: Graph Index 확장

처음에는 markdown 링크만으로 충분하다. 나중에는 이 링크와 frontmatter에서 graph index를 뽑을 수 있다.

Graph Index가 생기면 다음 질문에 강해진다.

이 결정은 어떤 이전 결정을 대체했어?
Jay가 맡은 open action 중 Project A 관련 것만 보여줘.
이 프로젝트에 영향을 준 decision 전체 보여줘.

9단계: 평가 질문 세트 만들기

검색과 요약은 감으로 튜닝하면 안 된다. 작은 평가셋을 만들어야 한다.

6월 가격 관련 고객 미팅 찾아줘
Jay가 담당자인 open action 보여줘
SSO 때문에 막힌 고객콜 요약해줘
가격정책 결정이 어떻게 바뀌었어?
Project A의 현재 상태 요약해줘
이전 결정과 충돌하는 최근 회의가 있어?

10단계: 권한, 민감정보, audit log

회의록은 민감하다. 개인용이라도 visibility와 sensitivity는 넣는 것이 좋다.

visibility: private
sensitivity: confidential
contains_pii: true
allowed_groups: [leadership]

팀 시스템이라면 검색 전에 권한 필터가 적용되어야 한다.

회의록 LLM Wiki는 한 번에 완성하는 제품이 아니다. 작은 markdown 지식베이스에서 시작해 검색, 상태 관리, 관계 탐색으로 확장하는 시스템이다.