바쁜 분을 위한 3줄 요약. ① AI가 직접 쓰는 위키를 7주 동안 만들다가 접고, 가지고 있던 노트 창고에 검색을 붙였어요. ② 두 달 동안 검색은 5,957번 돌았는데, 찾아온 노트를 AI가 열어 본 비율을 잰 세 주 동안은 1.2%, 0%, 0%였고 그 뒤로는 측정 자체가 멈춰 있었어요. ③ 찾아오기가 공짜가 되니 찾아온 횟수가 쓴 횟수처럼 보였어요. 지식경영 표준이 요구하는 검토와 개선이 빠져 있었던 거죠.
자료를 붙여 주면 AI가 알아서 쓸 줄 알았어요
사내 문서에 AI 검색을 붙였는데, 답이 딱히 나아진 것 같지 않다는 이야기를 요즘 자주 들어요. 그런데 어디가 문제인지 물으면 대부분 답을 못 해요. 잴 방법이 없어서요.
저도 같은 자리에 있었어요. 강의 재료, 조사 기록, 실패 기록을 몇 년째 쌓아 두고 있었고, AI와 일할 때 이 자료를 알아서 꺼내 쓰게 하고 싶었어요. 방법은 두 가지를 차례로 해 봤어요.
첫 시도는 AI가 직접 쓰는 위키였어요
처음 고른 건 LLM Wiki라고 불리는 방식이에요. 원문 자료는 사람이 넣고 절대 고치지 않아요. 그 원문을 읽고 요약하고 개념끼리 묶은 위키 페이지는 AI가 쓰고 고쳐요. 사람이 정리하는 수고를 AI에게 넘기는 발상이죠.
4월 말부터 6월 중순까지 7주쯤 돌렸어요. 원문 21개에서 위키 페이지 39개가 나왔어요. 페이지는 잘 나왔어요. 읽어 보면 그럴듯했고요.
그리고 6월 22일에 접었어요. 위키가 나빠서라기보다, 이미 노트 창고가 따로 있는데 창고가 둘이 되니 AI가 어디를 먼저 봐야 하는지부터 정해야 했거든요. 창고를 하나로 합치기로 하면서 위키는 읽기 전용으로 얼렸어요.
돌이켜 보면 여기서 한 가지를 놓쳤어요. 위키 페이지가 39개 생겼다는 건 셌는데, 그 페이지가 실제로 어떤 일에 쓰였는지는 한 번도 안 셌어요.
검색을 붙였는데, 실제로는 돌지 않고 있었어요
두 번째는 흔히 RAG라고 부르는 방식이에요. 제가 요청을 하면 그 문장으로 노트 창고를 먼저 검색하고, 관련 노트 몇 개를 AI에게 같이 보여 주는 거죠. 이 글에서는 이렇게 노트를 찾아 붙이는 걸 ‘회수’라고 부를게요. 제 환경에서 회수가 AI에게 넘기는 건 찾은 건수와 노트 제목·위치 두어 개가 전부예요. 본문은 안 넘어가요. 그래서 AI가 쓸모 있겠다 싶으면 그 노트를 직접 열어야 하고, AI 도구는 파일을 열 때마다 기록을 남겨요. 회수된 노트가 이 기록에 실제로 열린 것으로 남은 경우를 ‘읽힘’이라고 부를게요.
붙였다고 생각했는데, 7월 중순에 기록을 열어 보니 이상했어요. 요청 540건이 기록돼 있었는데, 그중 475건은 7월 18일 전에 쌓인 기록이라 회수가 붙을 수 없는 상태였어요. 요청마다 검색을 자동으로 실행하는 설정이 이미 없어진 스크립트 파일을 부르고 있었고, 오류가 나도 조용히 넘어가게 짜여 있었어요. 붙어 있다고 믿은 기간 내내 실제로는 떨어져 있었던 거예요. 나머지 65건은 7월 18일에 고친 뒤의 기록이고요.
7월 18일에 다시 연결했어요. 그날부터 오늘까지 회수 기록이 5,957건 쌓였어요. 그중 1,250건은 검색은 했는데 맞는 노트가 하나도 없던 경우라, 실제로 뭔가를 찾아온 건 4,707건이에요.
찾아오기는 늘었고, 읽기는 그대로였어요
7월 19일, 연결 뒤 쌓인 작업 기록을 모아 처음 세어 보니 회수가 AI에게 보여진 65번 중 노트가 열린 건 1번이었어요. 1.5%쯤이죠. 이 65번은 앞의 요청 기록이 아니라 작업 기록에서 따로 센 숫자예요. 앞의 65건과 숫자가 같은데, 같은 표본인지는 확인하지 못했어요. 이후 주간 기록으로 다시 집계했을 때 그 주 값은 1.2%로 남았어요. 제목만 보고 넘어간 거죠. 저도 매번 확인하지 않았으니 몰랐고요.
그래서 세 가지를 바꿨어요. 아주 짧은 후속 요청에는 검색을 건너뛰게 해서 엉뚱한 문서가 덜 섞이게 했고, 창고를 한 번도 안 보고 결과물 파일을 쓰려 하면 쓰기를 멈추는 자동 검사를 달았고, 회수 건수와 따로 열린 건수를 주마다 세기 시작했어요. 다만 붙잡는 장치는 창고를 ‘검색했는지’만 보고 ‘열어 읽었는지’는 안 봐요. 그 장치가 실제로 몇 번 붙잡았는지도 아직 세지 못했어요.
결과는 반만 좋았어요. 아래 두 비율은 분모가 달라요. 앞의 것은 한 주 동안의 작업 기록(대화 한 번 단위) 중 회수가 한 번이라도 붙은 비율이고, 뒤의 것은 회수가 붙은 작업 기록 중 AI가 그 노트를 실제로 연 비율이에요.
회수가 붙은 작업은 두 배 넘게 늘었어요. 검색을 건너뛰는 조건을 넣었는데도 늘어난 건, 같은 무렵 검색 자체가 제대로 돌기 시작한 영향이 섞여 있어서예요. 어느 변경이 얼마만큼인지는 가려 보지 못했어요. 그런데 읽힘은 1.2%에서 0%로 내려갔고, 그다음 주도 0%였어요. 이 0%는 고장이 아니라 실제 측정값이에요. 그 주에도 작업 기록은 320건이 모였고 회수도 세어졌는데, 열린 게 없었던 거죠. 찾아오는 일은 더 부지런해졌고, 쓰는 일은 제자리였어요.
찾아오는 일은 더 부지런해졌고, 쓰는 일은 제자리였어요.
그리고 하나가 더 있었어요. 8월 둘째 주부터는 측정할 작업 기록 자체가 0건으로 찍혀요. 앞의 0%와는 달라요. 같은 기간에도 제 요청은 매주 멀쩡히 기록되고 있었는데, 그걸 모아 세는 단계만 비어 있었어요. 원인은 아직 안 찾았어요. 알게 된 건 오늘, 이 글에 넣을 숫자를 세다가였어요. 한 달 넘게 아무 경고 없이 멈춰 있었던 거죠. 처음에 검색이 안 돌던 일과 똑같은 모양이에요.
지식경영 표준은 쌓는 게 아니라 돌리는 걸 요구해요
표준은 이렇게 하라고 해요
지식경영에는 ISO 30401이라는 국제표준이 있어요. 2018년에 나왔고, 지금은 개정판이 진행 중이에요. 공개된 초록은 이 표준이 무엇을 다루는지 한 문장으로 적어 둬요. 조직에서 효과적인 지식경영 시스템을 수립하고, 실행하고, 유지하고, 검토하고, 개선하는 데 필요한 요구사항과 지침이라고요.
이 표준은 지식을 창고가 아니라 경영시스템으로 다뤄요. 그래서 동사가 모으고 저장하는 쪽이 아니라 유지하고 검토하고 개선하는 쪽으로 이어지고, 앞에는 ‘효과적인’이 붙어 있어요. 지식을 얼마나 가졌는지보다, 가진 지식이 제 역할을 하는지 계속 보고 고치라는 뜻으로 읽혀요. (조항별 세부 요구는 원문을 열람하지 못했어요. 여기서는 공개 초록이 말하는 범위까지만 적어요.)
사람이 받을 때는 이랬어요
사람이 문서고를 쓸 때는 검토 칸이 좀 느슨해도 티가 덜 났어요. 찾는 데 품이 들었거든요. 누가 굳이 문서를 찾아냈다면 대체로 읽었어요. 찾는 비용이 곧 읽을 이유였죠. 안 쓰이는 문서는 사람들이 알아서 안 찾았고, 그게 자연스러운 걸러내기가 됐어요.
AI 시대에는 이렇게 적용해야 해요
AI에게 넘기면 찾는 비용이 0이 돼요. 요청마다 자동으로 찾아오니까요. 그러면 ‘찾았다’는 기록이 끝없이 쌓이고, 그 기록이 ‘썼다’처럼 보여요. 제 경우 회수 5,957건이라는 숫자가 딱 그랬어요. 표준이 요구한 검토와 개선은, 찾아온 것이 실제로 읽혔는지를 따로 세지 않으면 시작조차 못 해요.
| 사람에게 넘길 때 | AI에게 넘길 때 | |
|---|---|---|
| 찾기 | 품이 들어서 필요할 때만 | 요청마다 자동, 비용 0 |
| 읽기 | 찾았으면 대체로 읽음 | 제목만 보고 넘기기 쉬움 |
| 안 쓰이는 문서 | 알아서 안 찾게 됨 | 계속 회수 목록에 섞여 들어옴 |
| 검토 | 담당자 감으로도 어느 정도 굴러감 | 읽힘을 세는 칸이 없으면 아무도 모름 |
| 측정이 멈추면 | 사람이 이상하다고 느낌 | 오류 없이 조용히 0이 됨 |
창고보다 창고에 넣는 방식이 막혀 있었던 것 같아요
7월에 창고 쪽도 따로 진단해 봤는데, 결론이 같은 데를 가리켰어요. 창고에는 노트가 728개 있었는데, 긴 결과 보고서에서 ‘다음에 꺼내 쓸 조각’을 따로 뽑아 둔 항목은 0개였어요. 여기서 조각은 보고서 전체가 아니라 교훈 하나, 판단 기준 하나처럼 제목만 봐도 쓸지 말지 알 수 있는 짧은 노트를 말해요. 막힌 건 긴 보고서를 작은 조각으로 줄여서 넣는 단계였어요. 보고서 통째로는 제목만 봐서는 쓸지 말지 판단이 안 서거든요. AI가 제목만 보고 넘긴 것도 이상한 일은 아니었던 거죠.
그 단계에 사람의 확인을 끼워 두는 설계도 있었어요. 그런데 저는 그 확인함을 열어 보지 않더라고요. 제가 안 할 규율에 기대는 확인 절차는 없는 것과 같았어요. 그래서 그 확인을 사람이 아니라 기계 검사가 하게 옮기기로 정했어요. 형식이 맞는지, 이미 있는 조각과 겹치는지를 기계가 보는 방식이에요. 그게 읽힘을 올리는지는 아직 재지 못했어요.
위키를 만들 때와 검색을 붙일 때, 저는 두 번 다 만든 것의 개수를 셌어요. 페이지 39개, 회수 5,957건이요. 두 번 다 그게 쓰였는지는 세지 않았고요. 이 글을 쓰려고 자료를 찾을 때도 회수가 떴는데, 1순위로 올라온 건 제가 한 작업이 아닌 다른 사람의 평가 보고서였어요. 제목만 보면 이 글에 딱 맞는 자료 같았어요. 이번에는 열어 봤기 때문에 알 수 있었어요.
이렇게 생각하면 돼요
RAG든 위키든, 붙였다면 회수 건수 옆에 열어서 읽은 건수를 한 칸 더 세 보시면 돼요. 방법은 단순해요. 검색이 돌려준 문서 목록을 남기고, AI 도구의 작업 기록에서 같은 문서를 열었는지 대조하면 돼요. 예를 들어 코딩 에이전트는 대화마다 기록 파일을 남기고, 그 안에 어떤 파일을 읽었는지가 도구 호출로 한 줄씩 적혀 있어요. 다만 사내 챗봇처럼 찾은 문서 조각을 처음부터 본문째 넣어 주는 방식이라면 ‘연다’는 행동이 없어요. 그때 조각을 넣었다는 로그는 회수 건수일 뿐이에요. 읽힘에 해당하는 칸은 ‘답변이 그 조각을 근거로 실제로 인용했는가’로 바꿔 세야 해요. 답변에 출처 표시를 켜고, 넣어 준 조각 중 출처로 붙은 게 몇 개인지 세는 식이죠. 코딩 에이전트든 사내 챗봇이든 대부분 어떤 파일이나 문서를 불러왔는지 기록을 남겨요. 그 칸이 0에 가깝다면 창고를 키우거나 검색을 바꾸기 전에, 찾아온 것이 왜 읽히지 않는지부터 보는 게 순서예요. 그리고 그 칸이 계속 숫자를 내고 있는지도 가끔 확인해야 해요. 제 경우엔 그 칸이 한 달 넘게 멈춰 있었어요.
남은 문제도 적어 둘게요. 활용 측정이 왜 멈췄는지는 아직 몰라요. 읽힘을 0%에서 끌어올린 방법도 아직 찾지 못했어요. 찾으면 그 결과로 다시 쓸게요.
같이 해 보고 싶다면
팀 문서에 AI 검색을 붙였는데 효과를 설명하기 어렵다면, 워크숍에서 회수와 활용을 따로 세는 칸부터 함께 만들어 봐요. 창고 크기가 아니라 읽힌 비율로 이야기하는 연습이에요.
제 작업 환경 한 곳의 기록을 2026-09-13에 다시 센 결과예요. 주별 활용률은 주당 요청 수백 건 규모의 한 사람 사례라 여럿이 쓰는 문서고에는 그대로 적용되지 않아요. ISO 30401은 공개 초록 범위까지만 인용했어요.