01"분명 어딘가 있는데"
이런 장면, 익숙하실 겁니다.
- 신입이 묻습니다. "이 고객사 예전에 어떤 이슈 있었나요?" 아무도 정확히 답하지 못하고, 결국 "예전에 담당했던 ○○ 프로한테 물어봐"로 끝납니다.
- 제안서를 쓰려는데 작년에 비슷한 걸 만든 기억이 납니다. 검색창에 회사명을 넣으니 결과 47건. 열어보니 다 회의록입니다.
- 옆 팀이 두 달 걸려 만든 분석 자료를 우리 팀이 처음부터 다시 만듭니다. 있는 줄 몰랐기 때문입니다.
- 문서 정리를 위해 카테고리 체계를 다시 짭니다. 3개월 뒤 아무도 그 규칙대로 저장하지 않습니다.
- 퇴사자의 폴더는 열어봤자 파일명이
최종_최종_v3_수정입니다.
회사에 위키가 없어서 생긴 문제가 아닙니다. 다섯 장면 모두 위키가 있는 회사에서 벌어집니다.
02원인은 저장이 아니라 검색 방식
기존 위키 도구는 훌륭한 저장소입니다. 실패하는 지점은 저장이 아니라 꺼내 쓰기이고, 그 원인은 구조적입니다.
첫째, 키워드가 정확히 일치해야 합니다. 문서에 "이탈 방어"라고 적혀 있으면 "고객 이탈 막기"로는 안 나옵니다. 찾는 사람은 문제를 말로 표현하는데, 검색은 저장할 때 쓴 단어를 요구합니다. 이 간극이 검색 실패의 대부분입니다.
둘째, 결과가 답이 아니라 목록입니다. 47건이 나오면 사용자는 3~4개를 열어보고 포기합니다. "관련 있을지도 모르는 문서 목록"은 문제를 해결한 게 아니라 문제를 사용자에게 넘긴 것입니다.
셋째, 정리 비용을 사람이 냅니다. 카테고리 분류, 태그, 링크는 전부 수동입니다. 그리고 정리의 이득은 미래의 누군가가 가져가고, 비용은 지금 쓰는 사람이 냅니다. 이 비대칭이 있는 한 체계는 반드시 무너집니다.
넷째, 정작 중요한 정보는 문서가 아니라 대화에 있습니다. 결정의 이유, 실패의 맥락, "그때 그거 왜 안 했더라"는 메신저와 회의에 흩어져 있고 위키에는 결과만 남습니다.
03패러다임이 바뀌는 지점
| 기존 사내 위키 | AI 지식 베이스 | |
|---|---|---|
| 검색 방식 | 정확한 키워드가 일치해야 함 | 질문의 의도와 맥락을 이해 |
| 결과 형태 | 관련 문서 링크 목록 — 직접 다 읽어야 함 | 여러 문서를 종합해 직접 답변, 근거 링크 첨부 |
| 관리 공수 | 카테고리·태그 수동 관리 | 문서에서 엔티티를 자동 추출해 연결 |
| 입력 형태 | 정제된 문서만 | 업무일지·메신저·PDF 등 비정형 포함 |
차이는 편의성이 아니라 성공률입니다. 검색이 실패하면 사용자는 두 번째 시도를 하지 않습니다. 한 번 "안 나오네"를 경험한 사람은 다음부터 옆자리에 물어보고, 그렇게 위키는 조용히 죽습니다.
04오해 하나: 위키를 버리라는 얘기가 아닙니다
AI 지식 베이스는 위키의 대체재가 아니라 활용 계층입니다. 정제된 규정·매뉴얼은 여전히 위키에 있어야 하고, 잘 정리된 문서일수록 AI 답변의 품질도 올라갑니다.
바뀌는 것은 사용자가 만나는 접점입니다. 사용자는 폴더 트리를 탐색하는 대신 질문하고, 시스템은 흩어진 문서에서 근거를 모아 답합니다. 저장은 그대로 두고 꺼내는 방식만 바꾸는 것입니다.
다만 하나는 반드시 따라와야 합니다. 매일의 업무 기록이 쌓이지 않으면 AI도 답할 게 없습니다. 정제된 문서는 회사의 10%고, 나머지 90%는 그날그날의 진행 상황과 판단인데 이건 대부분 어디에도 남지 않습니다. 그래서 좋은 사내 AI는 검색 기능이 아니라 기록 습관의 설계에서 출발합니다.
05컴키의 접근
컴키는 순서를 뒤집었습니다. 문서를 잘 정리시키는 대신, 매일 5분이면 끝나는 업무 기록을 먼저 만들고 그 기록을 AI가 구조화합니다.
- 직원은 구조화된 4개 필드(맥락·트러블·액션·결과)에 오늘 한 일을 남깁니다. 음성 입력과 AI 초안으로 백지에서 시작하지 않습니다.
- 시스템이 고객사·제품 같은 엔티티를 자동으로 추출해 연결합니다. 사람이 태그를 달지 않습니다.
- 질문하면 사내 기록을 근거로 답하고, 답변마다 근거 문서를
[1][2]로 인용합니다. 근거가 없으면 "모른다"고 답합니다. - 고객사·제품·직원·팀 단위 위키 문서가 자동으로 생성되어, 탐색하고 싶은 사람에게는 정리된 문서를 제공합니다.