AI 회의록, 요약만으로는 부족해요 — 온톨로지 기반 회의 지식 관리가 필요한 이유
매주 수요일 오전, 지난주와 똑같은 이야기를 반복하는 회의에 앉아 계신 적 있나요? 분명 회의록은 남겼는데, 정작 "그때 왜 그렇게 결정했더라?"라는 질문에는 아무도 답하지 못합니다. 회의록 자동화 도구가 이렇게 많아졌는데도 왜 이런 일이 반복될까요?
답은 간단해요. 대부분의 AI 회의록 도구는 회의를 '문서'로 남기지만, 팀에게 정말 필요한 것은 회의에서 나온 지식을 '연결된 구조'로 쌓는 일이기 때문입니다. 이 글에서는 그 구조의 핵심인 온톨로지(Ontology)가 어디서 시작된 개념인지, 팔란티어(Palantir)는 왜 온톨로지 하나로 기업 AI 시장을 뒤흔들었는지, 그리고 왜 '회의'가 온톨로지를 쌓기에 가장 좋은 원료인지 차근차근 짚어볼게요.
요약만으로는 부족한 이유
음성 인식과 LLM의 발전 덕분에 이제 회의를 녹음하면 전사(스크립트)와 요약은 몇 분 만에 나옵니다. 문제는 그다음이에요. 요약된 회의록은 대부분 이렇게 흘러갑니다.
노션이나 드라이브 어딘가에 저장되고, 다시 열어보는 사람은 거의 없어요.
지난달 회의에서 나온 결정과 이번 주 회의의 논의가 서로 연결되지 않아요.
"이 프로젝트 관련해서 우리가 어떤 결정을 해왔지?"라고 물으면, 결국 사람이 문서 여러 개를 뒤져야 해요.
즉, 회의록이 쌓일수록 정보는 늘어나는데 지식은 늘어나지 않는 상태가 됩니다. 문서 하나하나는 잘 정리되어 있어도, 문서들 사이의 관계 — 어떤 결정이 어떤 논의에서 나왔고, 누가 어떤 업무를 맡았고, 그것이 어떤 프로젝트와 이어지는지 — 는 어디에도 기록되지 않기 때문이에요.
온톨로지, 어디서 시작된 개념일까요?
철학에서 출발했어요: "존재하는 것들을 분류하는 학문"
온톨로지의 뿌리는 2,300년 전으로 거슬러 올라갑니다. 아리스토텔레스는 『범주론(Categories)』에서 세상에 존재하는 모든 것을 실체·양·질·관계 같은 범주로 분류하려 했어요. "세상에는 어떤 종류의 것들이 존재하고, 그것들은 서로 어떤 관계를 맺는가"라는 질문 — 이것이 존재론, 즉 온톨로지의 출발점입니다. 'Ontology'라는 단어 자체는 그리스어 ontos(존재)와 logos(학문)를 합쳐 17세기 초 철학자들이 만들었어요.
AI 연구가 이 단어를 데려왔어요
이 철학 용어가 컴퓨터과학으로 넘어온 것은 1980~90년대 인공지능의 지식 표현(Knowledge Representation) 연구에서였습니다. "컴퓨터가 추론하려면 세계에 대한 지식을 어떤 구조로 담아야 하는가"라는 문제가 결국 아리스토텔레스의 질문과 같았거든요. 1993년 스탠퍼드의 톰 그루버(Tom Gruber)가 남긴 정의가 지금까지도 표준처럼 쓰입니다.
"온톨로지란 개념화에 대한 명시적 명세(explicit specification of a conceptualization)다." — Tom Gruber, 1993
풀어서 말하면, 어떤 도메인에 존재하는 개체(entity)의 종류와 속성(property), 그리고 개체들 사이의 관계(relation)를 컴퓨터가 이해할 수 있는 형태로 명시적으로 적어둔 설계도예요. 참고로 그루버는 훗날 애플 Siri의 공동 창업자가 됩니다. 음성 비서의 뿌리에도 온톨로지가 있는 셈이죠.
시맨틱 웹과 구글 지식 그래프로 대중화됐어요
2001년 웹의 아버지 팀 버너스리는 '시맨틱 웹(Semantic Web)' 비전을 발표하면서, 웹 문서를 기계가 이해하는 개체와 관계의 그물망으로 만들자고 제안했어요. 그 표준으로 RDF와 OWL(Web Ontology Language) 같은 언어가 만들어졌고요. 그리고 2012년 구글이 지식 그래프(Knowledge Graph)를 공개하며 유명한 슬로건을 내겁니다 — "Things, not strings." 검색어를 문자열이 아니라 '세상에 존재하는 것'으로 이해하겠다는 선언이었죠. 오늘날 검색 결과 오른쪽에 뜨는 인물·기업 정보 카드가 바로 그 결과물이에요.
2012년 구글이 지식 그래프를 발표하며 공개한 실제 검색 화면. '마리 퀴리'가 문자열이 아닌 개체로 이해되기 시작한 순간이에요. (출처: Google 공식 블로그)
정리하면 온톨로지는 철학의 질문에서 태어나 AI의 지식 표현으로 넘어왔고, 웹과 검색을 거치며 "데이터를 개체와 관계의 그래프로 구조화하는 방법론"으로 자리잡았습니다.
팔란티어: 온톨로지를 비즈니스의 언어로 만든 회사
온톨로지가 기업 세계에서 진짜 돈이 되는 개념이라는 것을 증명한 회사가 팔란티어(Palantir)입니다. 회사 이름부터 『반지의 제왕』에 나오는 '멀리 보는 돌(팔란티르)'에서 따왔어요. 흩어진 것을 하나로 꿰어 보이게 한다는 뜻이죠.
고담(Gotham): 파편을 객체로 꿰다
팔란티어의 첫 제품 고담은 정보기관을 위해 만들어졌습니다. 통화 기록, 금융 거래, 위치 데이터처럼 서로 형식이 다른 파편 데이터를 사람·장소·사건·조직이라는 '객체'와 그 사이의 '관계'로 변환해 하나의 그래프 위에 올렸어요. 팔란티어는 이를 '다이내믹 온톨로지(dynamic ontology)'라고 불렀습니다. 분석가가 테이블과 로그를 뒤지는 대신, "이 인물은 이 계좌와 연결되어 있고, 이 계좌는 이 사건과 연결되어 있다"는 식으로 세계 자체를 탐색하게 만든 거예요.
파운드리(Foundry): 조직의 디지털 트윈
이 접근을 민간 기업으로 가져온 것이 파운드리입니다. 파운드리의 심장은 온톨로지 레이어예요. ERP, CRM, 센서 데이터 같은 원천 데이터를 '주문', '공장', '고객', '배송' 같은 비즈니스 객체(Object)와 속성, 연결(Link), 그리고 실행 가능한 액션(Action)으로 매핑해 조직 전체의 디지털 트윈을 만듭니다. 핵심은 이것이 단순한 데이터 모델이 아니라 의사결정 모델이라는 점이에요. "재고가 부족하면 어떤 주문을 조정할 수 있는가"까지 온톨로지 위에서 표현되거든요.
팔란티어가 공개한 온톨로지 시스템 공식 다이어그램. 기업 데이터·로직·액션 레이어 위에 인간+AI 에이전트 팀이 올라서는 구조예요. (출처: Palantir Foundry 공식 문서)
AIP: LLM 시대, 온톨로지가 병목을 풀다
2023년 팔란티어가 내놓은 AIP(Artificial Intelligence Platform)는 LLM을 이 온톨로지에 접지(grounding)시킵니다. LLM이 기업 데이터를 통째로 삼키는 대신, 온톨로지라는 정확한 세계 모델 위에서 질문에 답하고 액션을 실행하게 한 거예요. 환각(hallucination)은 줄고, 답변은 실제 업무 객체와 연결되죠. 생성형 AI 열풍 속에서 팔란티어가 "우리는 이미 기업의 세계 모델을 갖고 있다"며 가장 큰 수혜자가 된 배경이 바로 이 온톨로지 레이어입니다.
팔란티어가 증명한 교훈은 분명해요. 기업 AI의 병목은 모델이 아니라, 조직의 현실을 담은 온톨로지가 있느냐 없느냐라는 것.
그런데 팔란티어 방식에는 비싼 전제가 있어요
팔란티어의 온톨로지는 기본적으로 위에서 아래로(top-down) 구축됩니다. 포워드 디플로이드 엔지니어가 고객사에 상주하며 시스템을 분석하고, 객체와 관계를 설계하고, 데이터 파이프라인을 연결하죠. 훌륭하지만 수억~수십억 원 규모의 프로젝트이고, 대상도 이미 정형 데이터가 풍부한 대기업·정부기관이에요.
그리고 이 방식에도 남는 공백이 있습니다. ERP와 CRM에는 결과가 기록되지만, "왜 그렇게 하기로 했는지"라는 이유와 맥락은 시스템 어디에도 남지 않아요. 그 이유가 언어화되는 유일한 현장이 바로 회의입니다.
왜 '회의'가 온톨로지의 가장 좋은 원료일까요?
Micky가 온톨로지의 밑바탕 재료로 회의 데이터에 주목하는 근거는 네 가지예요.
회의는 의사결정의 1차 현장이에요. 문서는 결정의 결과물이지만, 회의에는 결정의 원인 — 어떤 대안이 있었고, 무엇을 우려했고, 왜 그 길을 골랐는지 — 이 통째로 담겨 있어요. 팔란티어가 "데이터가 아니라 결정을 담아야 한다"고 말한 바로 그것이, 회의에서는 가공 전 상태로 흘러나옵니다.
구조가 이미 내장돼 있어요. 회의에는 참석자(사람), 시간, 안건(주제), 발언(주장·근거), 결론(결정), 할 일(액션 아이템)이라는 뼈대가 원래부터 있습니다. 온톨로지의 개체·관계 스키마와 거의 1:1로 대응해요. 화자 분리와 전사가 정확하다면, 개체 추출의 절반은 이미 끝난 셈이에요.
암묵지가 언어로 나오는 유일한 순간이에요. 팀원 머릿속에만 있던 판단 기준과 도메인 지식은 문서로는 잘 안 적히지만, 회의에서는 말로 튀어나옵니다. 회의를 구조화한다는 건 조직의 암묵지를 형식지로 바꾸는 일이에요.
스스로 갱신되는 데이터예요. 온톨로지의 고질병은 '만들고 나서 낡는 것'인데, 회의는 매주 반복되죠. 회의를 원료로 쓰면 그래프가 조직의 리듬에 맞춰 자동으로 최신화됩니다.
정리하면 이렇게 대비할 수 있어요. 팔란티어는 대기업의 정형 데이터를 전문가가 위에서 아래로 모델링하고, Micky는 모든 팀이 이미 하고 있는 회의에서 아래에서 위로 온톨로지를 자동으로 길러냅니다. 컨설팅 없이, 팀은 그냥 회의만 하면 돼요.
평면적인 회의록 vs 온톨로지 기반 지식 그래프
1. 검색: "찾는 것"에서 "질문하는 것"으로
평면적인 회의록에서는 키워드 검색밖에 할 수 없어요. "가격 정책"을 검색하면 그 단어가 들어간 문서 목록이 나올 뿐이죠. 반면 지식 그래프에서는 이렇게 물을 수 있습니다.
"가격 정책에 대해 우리 팀이 내린 결정을 시간순으로 보여줘."
"이 결정이 바뀐 이유가 논의된 회의는 언제였지?"
"지금 진행 중인 액션 아이템 중 담당자가 없는 건 뭐야?"
개체와 관계가 구조화되어 있기 때문에, 단순 검색이 아니라 추론이 가능한 질의가 되는 거예요.
2. 맥락: 회의가 쌓일수록 똑똑해집니다
평면 문서는 100개가 쌓여도 서로 남남이에요. 하지만 온톨로지 기반이라면 새 회의가 열릴 때마다 기존 그래프에 연결됩니다. 오늘 회의에서 "지난번에 말한 그 건"이라는 말이 나오면, 그래프 위에서는 그것이 정확히 어떤 결정을 가리키는지 특정할 수 있어요.
3. 산출물: 요약을 넘어 결과물로
구조화된 지식이 있으면 회의 내용을 다양한 형태로 변환할 수 있어요. 논의 구조를 알고 있으니 마인드맵으로 그릴 수 있고, 결정과 액션 아이템을 알고 있으니 Slack 공유 메시지나 Notion 문서로 정리할 수 있고, 논리 흐름을 알고 있으니 발표 자료 초안까지 만들 수 있죠. 저희는 이것을 Meeting-to-X라고 불러요. 회의(Meeting)가 끝나는 즉시 필요한 결과물(X)이 완성되는 경험입니다.
Micky가 온톨로지의 좋은 밑바탕인 이유
AI 미팅 어시스턴트 Micky(미키)는 처음부터 이 구조를 전제로 설계했습니다.
입력이 온톨로지 친화적이에요. 실시간 전사와 화자 분리는 단순 편의 기능이 아니라, '누가(개체) 언제(시간) 무엇을(주장·결정)'이라는 그래프의 원자 단위를 만드는 공정이에요.
산출물이 다시 그래프로 돌아와요. Meeting-to-X로 만들어진 마인드맵·프레젠테이션·랜딩페이지도 그 회의의 노드에 연결됩니다. 산출물이 흩어지지 않고 지식의 일부로 축적돼요.
MCP로 그래프가 도구를 넘나들어요. Slack·Notion 연동을 통해 결정과 할 일이 팀이 이미 쓰는 도구로 흘러가고, 그 연결 자체가 다시 관계로 기록됩니다.
맥락이 쌓이면 팀 에이전트가 만들어져요. 팔란티어 AIP가 온톨로지 위에 LLM을 올려 기업용 AI를 완성했듯, Micky는 회의로 길러진 팀 온톨로지 위에 에이전트를 올립니다. 매번 배경 설명부터 다시 해야 하는 범용 챗봇과 달리, 우리 팀의 히스토리를 아는 에이전트가 자동으로 자라나요.
핵심은 순서예요. 에이전트를 먼저 만들고 데이터를 붓는 것이 아니라, 회의라는 가장 밀도 높은 맥락을 온톨로지로 쌓다 보면 에이전트가 자연스럽게 만들어지는 구조입니다.
자주 묻는 질문
Q. 온톨로지 구축은 원래 비싸고 오래 걸리는 작업 아닌가요?
맞아요. 전통적으로는 온톨로지 엔지니어가 스키마를 설계하고 데이터를 수작업으로 매핑해야 했고, 팔란티어 방식도 전문 인력이 상주하는 고비용 프로젝트예요. 하지만 LLM이 등장하면서 개체·관계 추출이 자동화 가능해졌습니다. Micky는 이 추출을 회의 파이프라인에 내장해, 팀이 회의만 해도 그래프가 자라도록 만들고 있어요.
Q. 팔란티어 같은 온톨로지를 우리 같은 작은 팀이 가질 수 있나요?
목적이 다를 뿐 원리는 같아요. 팔란티어가 ERP·CRM 데이터를 객체화한다면, Micky는 회의라는 모든 팀이 가진 공통 자산을 객체화합니다. 시스템 통합 프로젝트 없이도, 몇 주치 회의만 쌓이면 팀의 의사결정 그래프가 형태를 갖추기 시작해요.
Q. 일반 회의록 앱과 결과물이 얼마나 다른가요?
첫 회의에서는 큰 차이가 없을 수 있어요. 차이는 회의가 10번, 50번 쌓였을 때 벌어집니다. 평면 회의록은 문서 50개가 되지만, 온톨로지 기반에서는 팀의 의사결정 히스토리를 관통하는 하나의 지식 그래프가 되거든요.
Q. 회의 데이터는 안전하게 관리되나요?
회의 데이터는 팀의 가장 민감한 자산이에요. Micky는 워크스페이스 단위 격리 저장을 기본으로 하고, 팀의 데이터가 다른 조직의 모델 학습에 쓰이지 않도록 설계하고 있습니다.
회의는 끝나도, 지식은 계속 일하게 하세요
아리스토텔레스의 분류에서 시작해 그루버의 정의를 거쳐 팔란티어의 온톨로지 레이어까지 — 이 오래된 아이디어가 말해주는 것은 하나예요. AI의 힘은 모델이 아니라, 세계를 담은 구조에서 나온다는 것. 그리고 팀에게 그 세계가 가장 생생하게 흐르는 곳은 회의실입니다.
회의가 끝나는 즉시 필요한 결과물이 완성되는 경험, 그리고 회의가 쌓일수록 똑똑해지는 우리 팀만의 에이전트가 궁금하시다면 Micky 베타 테스터로 함께해 주세요.