[LLM Wiki 1] 회의록은 왜 검색만으로 부족한가

회의록은 처음에는 단순한 기록처럼 보인다. 누가 참석했고, 어떤 이야기를 했고, 다음에 무엇을 하기로 했는지 적어두면 충분해 보인다. 문제는 시간이 지나면서 시작된다. 회의록이 10개일 때는 기억으로 버틸 수 있지만, 100개, 1,000개가 되면 회의록은 더 이상 기억을 도와주는 도구가 아니라 찾아야 하는 짐이 된다.

검색창에 단어를 넣으면 문서는 찾을 수 있다. 하지만 실제로 알고 싶은 것은 보통 문서 위치가 아니다.

• 지난번에 무엇을 결정했지?
• 왜 그렇게 결정했지?
• 누가 그 일을 맡았지?
• 그 액션은 아직 열려 있나?
• 이 프로젝트는 지금 어디까지 왔지?
• 예전 결정과 지금 말이 충돌하지 않나?

이 질문들은 단순 키워드 검색으로는 잘 풀리지 않는다. 회의록 속 정보가 문장으로 흩어져 있기 때문이다. 어떤 결정은 한 회의에서 시작되고, 다음 고객 미팅에서 반박을 받고, 그다음 제품 회의에서 바뀐다. 액션 아이템은 회의록 안에 묻히고, 프로젝트 상태는 여러 회의에 나뉘어 남는다.

회의록 저장과 회의 지식은 다르다

일반적인 회의록 저장 방식은 날짜별 회의록 파일을 쌓아두는 것이다. 위 도식의 왼쪽처럼 이 구조에서는 각 회의록이 독립된 파일이다. 검색은 가능하지만, 회의 사이의 관계는 시스템 안에 명시적으로 남지 않는다.

회의 지식 시스템이 되려면 구조가 달라져야 한다.

회의록을 그대로 쌓는 것이 아니라, 회의록에서 나온 결정, 액션, 프로젝트 변화, 반복되는 주제를 분리해서 관리해야 한다.

일반 RAG는 무엇을 해결하고, 무엇을 해결하지 못하나

RAG는 Retrieval-Augmented Generation의 줄임말이다. 쉽게 말하면 LLM이 외부 문서를 검색해서 읽고 답하게 하는 방식이다.

회의록에 RAG를 붙이면 분명 좋아진다. 예를 들어 “SSO 관련 회의 찾아줘”라고 물으면 관련 회의록 조각을 찾을 수 있다. “가격정책 논의 요약해줘”라고 하면 검색된 문서를 바탕으로 요약할 수 있다.

하지만 일반 RAG에는 한계가 있다. 질문할 때마다 원본 문서에서 다시 찾고, 다시 조합하고, 다시 요약한다.

이전에 잘 정리한 결론이 지식베이스에 구조적으로 쌓이지 않는다.

예를 들어 다음 흐름을 생각해보자.

• 6월 3일 회의: seat-based pricing 검토
• 6월 10일 고객콜: seat 수와 실제 사용량이 맞지 않는 문제 제기
• 6월 17일 회의: hybrid pricing 검토
• 6월 27일 회의: usage-based pricing 우선 검토로 변경

일반 RAG는 이 문서들을 관련 조각으로 찾을 수는 있다. 하지만 “가격정책 결정이 어떻게 변해왔는가”라는 계보를 시스템 안에 지속적으로 저장하지는 않는다. 질문할 때마다 LLM이 다시 조합해야 한다.

회의록에서 정말 중요한 정보

회의록에서 중요한 것은 모든 문장이 아니다. 핵심은 결정, 결정 이유, 액션, 열린 질문, 리스크, 프로젝트 업데이트, 반복 주제, 출처다. 위 도식처럼 이 정보들은 나중에 다시 물어볼 수 있는 업무 단위로 남아야 한다.

회의록 시스템은 이 정보들을 안정적으로 추출하고, 서로 연결해야 한다. 그래야 “회의록 검색”을 넘어 “회의 지식베이스”가 된다.

우리가 원하는 시스템의 모습

목표는 이런 시스템이다.

사용자는 파일명을 기억할 필요가 없다. “6월에 가격 때문에 막힌 고객 미팅 요약해줘”, “Jay가 맡은 미완료 액션 보여줘”, “Enterprise Pricing 지금 상태가 뭐야”처럼 물으면 된다.

시스템은 먼저 질문을 해석하고, 관련 회의와 카드를 찾고, 결정과 액션의 관계를 연결한 뒤, 출처가 있는 답변을 만들어야 한다.

회의록은 저장만 해서는 지식이 되지 않는다. 결정과 액션, 프로젝트 흐름을 분리하고 연결해야 한다.