흩어진 사내 지식을 AI가 답할 수 있게 만들기
이한승 - 카카오엔터테인먼트
출발점: “이거 혹시 아시는 분 계실까요?”
- 회사에서 일하다 보면 자주 하게 되는 질문
- 이 코드는 왜 이렇게 됐는지, 이 결정은 왜 이렇게 내려졌는지
- 문서도 있고, 메신저 대화도 있고, 코드도 있고, 기록은 다 남아 있음
- 그런데 보통은 쉬운 길을 찾음 - 아는 동료에게 물어보기
- 그 동료가 해주던 일 = 여기저기 흩어진 기록을 모아 하나의 맥락을 설명해 주는 것
- 어떤 문서와 논의를 거쳐 어떤 결정이 됐고, 그게 어떤 의미였는지
- 사내 지식베이스는 이 질문에서 출발 - 흩어진 기록에서 답을 찾을 수 있게
- AI가 기록을 활용하려면 누가 남긴 기록인지, 어떤 업무와 관련된 기록인지 구분할 수 있어야 함
- 발표 구성
- 연결: 사람과 문서를 어떻게 구별하고 연결했는지
- 사용하기 위한 조건: 누구에게 보여줄 수 있는지, 언제까지 유효한지
- 실제 활용과 확장: 업무 질문에 답하는 사례, 스킬 활용, 다른 업무로의 확장
1. 연결
흩어진 원본
- 사내에서 목적별로 여러 시스템을 씀
- 컨플루언스: 문서 / 회의록, 지라: 작업 기록
- 슬랙 / 아지트: 논의
- 그룹웨어 등 사내 시스템: 조직 / 직원 정보
- 코드 저장소 등
- 형태가 다른 정보를 AI가 바로 파악할 수는 없음 -> AI가 함께 쓸 수 있게 정의하는 과정 필요
- AI용 문서를 따로 만들지 않음
- 원본은 원래 쓰던 곳에서 그대로 수정하고, 가져와서 처리
- 어떤 문서 / 대화에서 가져왔는지 출처를 함께 남김 -> 답변을 보고 원본을 확인할 수 있게
파이프라인
- 각 시스템에서 수집 -> 수집 데이터 검사 (민감 정보 마스킹 등) -> 공통 모델로 통합 -> 저장
- 질문이 들어오면 여러 방식으로 조회하고 종합해서 답변
- 원본이 바뀌면 그 변화를 놓치지 않고 따라가게 함
작성자 ≠ 담당자
- 공통 모델로 통합 = 문서 형식만 맞춘다는 의미가 아님
- 회의록을 내가 썼어도 실제 그 업무 담당자는 다른 사람일 수 있음
- 누가 썼는지와 누구에게 물어봐야 하는지는 다른 의미
- 회의록을 썼다는 이유로 AI가 나를 담당자로 지목하면 곤란
- “작성했다”를 “담당한다”로 해석하지 않도록 관계를 구분해야 했음
온톨로지 모델
- 직원 / 조직 / 문서처럼 서로 다른 대상과, 대상 사이의 관계를 공통으로 정의
- 대상: 직원, 조직, 문서 등 + 속성 (수정 시간, 상태 등)
- 관계: 직원 -소속-> 조직, 직원 -작성-> 문서 등, 방향과 의미를 하나씩 정의
- 예: 컨플루언스 회의록은 철수가 작성, 실제 논의는 슬랙 스레드에서 다른 사람들이 남김 -> 이 연결이 모두 남음
- “우리 팀이 작성한 기록 찾아줘”
- 질문자의 소속 팀 확인 -> 그 팀이 작성한 기록 탐색
- 팀 이름이 없어도 팀원이 작성한 기록일 수 있음
- 반대로 다른 팀이 우리 팀을 언급한 기록은 우리 팀이 작성한 게 아님
- 팀 이름 검색만으로는 구분 불가 -> 조직 / 직원 정보를 써서 문서 / 메시지와 연결
구조화할 것과 하지 않을 것
- 직원 소속, 문서 작성자: 시스템에 정의된 값 -> 바로 연결
- 왜 이 방식을 선택했는지, 왜 기존안을 반대했는지: 당시 문서 / 논의를 읽어야 함
- 회의록 하나에도 검토안, 최종 결정, 개인 의견이 섞여 있음
- 전부 구조화하면 뭐가 검토안이고 최종 결정인지 판단해야 하고, 결정이 바뀌면 저장된 정보를 다 고쳐야 함
- -> 이런 질문은 필요한 문서 / 논의를 찾아 읽고 답하게 함
- 처음부터 다 구조화하지 않고, 원본이 바뀌었을 때 쉽게 반영할 수 있는 것부터 모델에 넣음
계정 매핑
- 시스템마다 같은 직원의 계정 / 표기가 다름
- 이름만 보고 같은 사람으로 보면 안 됨 - 동명이인 (발표자 팀에도 같은 이름이 두 명, 팀장님과 바로 뒷자리 동료)
- 시스템별 계정을 직원 단위로 매핑 -> 계정이 다른 같은 직원의 기록을 함께 찾을 수 있음
2. 사용하기 위한 조건
- 연결한 정보를 누가 볼 수 있는지, 원본이 바뀌면 어떻게 반영할지
권한
- 수집할 수 있는 자료 ≠ 질문자에게 보여줄 수 있는 자료
- 같은 팀 직원 A, B - 제한 문서는 A에게만 공개
- “우리 팀 문서 보여줘”가 전부 읽어도 된다는 의미는 아님
- 수집할 때 누가 읽을 수 있는지 권한 정보(ACL)를 함께 가져옴
- 질문이 오면 직원 정보로 질문자 확인 -> 문서 ACL과 대조 -> 읽을 수 있는 내용만 답변에 사용
- 원문을 추가로 가져올 때도 동일, 권한을 확인 못 하거나 권한 없는 문서는 가져오지 않음
- 같은 질문이어도 A는 더 자세한 답변, B는 제한 문서가 빠진 답변을 받음
변경 반영
- 원본 시스템에서 내용 / 공개 범위가 바뀌었는데 지식베이스에 반영이 안 되면 예전 권한으로 판단하게 됨
- 조직 이동한 직원도 예전 조직 기준으로 판단되는 문제
- 본문만이 아니라 소속, 권한 같은 정보도 변경을 꾸준히 따라가게 함
- 삭제된 문서는 검색 결과 / 답변에 쓰지 않고, 지식베이스 안에서도 그대로 반영
출처
- 실제 업무에 쓰려면 AI가 정리한 내용만이 아니라 어떤 기록을 보고 한 얘기인지 출처를 보여줘야 함
- 참고한 문서 / 대화를 직접 확인할 수 있게 링크 제공
3. 활용과 확장
사례 1: 결정 배경 찾기
- “우리 팀 슬랙에서 얘기했던 검색 방식은 왜 지금처럼 고친 거야?”
- 실제로는 이렇게 예쁘게 안 물어봄, 발표용으로 친절하게
- 당시 논의를 바탕으로 검토한 방법과 실제 적용한 내용을 정리하고 출처도 보여줌
- 이어서 관련 PR을 물어보면, 실제 담당자는 다른 사람이었다는 것과 PR까지 찾아줌
- 기억나는 문제에서 시작해서 당시 논의, 필요한 변경까지 따라갈 수 있음
사례 2: 다음 업무로 이어가기
- 진행 상황 / 남은 일 정리 -> 팀에 공유 -> 회의 일정 잡기 -> 관련 문서 작성 -> 슬랙 메시지 발송
- 자료 찾기부터 문서 정리, 동료 공유, 회의 준비까지 한 대화 안에서 이어짐
평소 쓰는 도구에서
- 지식베이스 화면에서만 쓸 수 있으면 아쉬움 - 작업하다 창을 옮겨야 함
- Claude Code, Codex 같은 도구에서 바로 사내 지식베이스를 쓸 수 있게 만듦
- 개발 중이나 문서 작성 중에 필요한 사례 / 자료를 바로 찾음
- 사용하는 도구가 달라도 같은 검색 / 조회 도구와 같은 권한 정책을 그대로 사용
- 만든 도구를 마켓플레이스로 공유 -> 각 도메인, 비개발 조직에서도 사용
- 도구 공유를 시작하면서 활용이 빠르게 확장됨
다른 업무로 확장
- 지식베이스를 확장하는 것 = AI가 도울 수 있는 업무를 넓히는 것
- 예: “이 IP의 해외 캠페인, 무엇을 더 확인해야 할까?”
- 관련 업무 기록, 성과 데이터, 계약 조건부터 진행 상태까지 필요
- 작품과 성과가 어떤 기준으로 집계됐는지, 어떤 조건이 적용되는지 업무에 맞게 정리돼 있어야 함
- 온톨로지 모델을 회사의 다른 업무 / 도메인에도 적용 중
- 조회로 끝나지 않고, 확인한 내용을 AI와 함께 검토하고 승인까지 이어지는 흐름을 보고 있음
정리
- 흩어진 사내 지식을 AI가 답하게 만든다 = 무엇을, 누구에게, 언제까지 보여줄지 정하는 일
- 무엇을 어떤 의미로 연결할지: 온톨로지
- 누구에게 보여줄지: 직원 정보와 권한(ACL)으로 판단
- 언제까지 유효한지: 원본의 연결과 상태 변경을 꾸준히 추적