||
글. 변자룡(Jr)/유저혜택개발팀
안녕하세요. 여기어때 유저혜택개발팀 제이알입니다.
요즘 업무에 AI를 활용하지 않는 분은 없을 거라 생각합니다. 다만 사용하는 방식은 다들 제각각이겠죠. 제 경우를 말씀드리면, 집에서는 OpenClaw 같은 개인 비서형 AI를 쓰고 있습니다. 어제 뭘 찾아봤는지, 지난주에 뭘 결정했는지를 기억하고 있다가 오늘 대화에 자연스럽게 끌어오는 게 편합니다.
회사에서도 같은 걸 하고 싶었습니다. 그런데 업무 데이터를 외부 에이전트에 붙이는 건 당연히 안 되는 일이었고, 그렇다고 사내 지식 검색 시스템을 직접 세우자니 그건 개인이 쓰려고 만들 규모가 아니었습니다. 사내엔 이미 그 문제를 조직 규모로 풀고 있는 팀이 있기도 하고요.
한참 고민하다 깨달은 건 제가 풀고 싶은 문제가 그보다 훨씬 작다는 것이었습니다. 회사 전체의 지식이 아니라 제 기억이었습니다. 제가 지난달에 왜 그렇게 결정했는지, 오늘 온 장애 알림이 지난주 것과 같은 건지 다른 건지, 이런 걸 AI가 저 대신 기억해 주길 바랐던 겁니다. 이렇게 문제를 좁히고 나니 거창한 시스템 없이도 개인이 해볼 만한 크기가 됐습니다.
그래서 두 달 전 마크다운 위키를 만들었습니다. 지금은 “이 알림, 전에 비슷한 거 있었어?”라고 물으면 AI가 지난번 분석 페이지를 먼저 꺼내 놓고 “같은 메시지지만 원인이 다르다”고 말해 줍니다. 그동안 AI의 기억이란 세션이 살아 있는 동안만, 길어야 메모리 파일 몇 장 수준이라 대화가 끝나면 함께 사라졌는데, 위키를 저장소로 두면서 세션이 끝나도 남고 계속 쌓이는 반영구적인 기억이 됐습니다. 집에서 쓰던 비서형 AI가 부러웠던 바로 그 지점이 회사 안에서 제 업무 데이터로 채워진 셈이죠. 이 글에서는 이 위키를 운영하며 얻은 이점과, 그간 이루지 못했던 편의가 어떻게 채워졌는지 공유하고자 합니다. (위키 구조 자체는 뒤에서 소개할 안드레이 카파시의 LLM 위키 패턴을 따랐으니 구축 절차보다는 운영하며 배운 것 위주로 쓰겠습니다.)
메모는 쌓이고, 위키는 이어진다
왜 하필 위키였는지부터 말씀드려야겠네요. 처음 떠올린 건 위키가 아니라 이미 쓰던 메모 앱이었습니다. 두 군데 메모 앱에 몇 년간 쌓인 노트가 900장이 넘었으니 여기에 AI를 붙이면 그 세월만큼 오랜 기억을 가진 AI가 되지 않을까 생각했던 거죠. 그런데 AI에게 “이 장애, 전에 비슷한 거 있었어?”라고 물으면 그럴듯한 답을 만들어내긴 하는데, 근거로 든 노트를 열어보면 다른 이야기였습니다.
문제는 노트의 양이 아니라 노트 사이에 길이 없다는 것이었습니다. 각 노트는 그날의 맥락으로만 쓰여 있어서, 그 노트가 어느 도메인의 어느 정책에 대한 것인지는 AI도 저도 다시 읽어봐야 알 수 있었습니다. 2025년 3월의 장애 메모와 올해 4월의 회의록이 같은 정책 이야기라는 걸 아는 사람은 저뿐이었고, 그마저도 기억이 흐릿했습니다.
위키로 바꾼 건 그래서였습니다. 위키는 페이지보다 링크가 중요한 구조입니다. “이 장애는 [[이 정책]] 때문에 생겼고, [[저 분석]]과 같은 원인이다"라고 적어두면 AI는 그 링크를 따라 걷기만 하면 됩니다. AI에게 필요한 건 문서의 양이 아니라 문서 사이의 길이었습니다.
900장의 노트를 전부 옮기는 데는 하루면 충분했습니다. 그걸 위키 페이지로 정리하는 건 두 달이 지난 지금도 진행 중입니다. 뒤에서 다시 말씀드리겠지만, 옮기는 비용은 작고 정리하는 비용은 큽니다.
메모 더미에는 없던 것, 문서 사이의 길큰 틀 — 원본은 그대로, 정리본은 따로, 목차는 위에
구조부터 말씀드리면, 뼈대는 제가 고안한 게 아닙니다. 카파시의 LLM 위키 패턴을 따랐습니다. 원본(raw)은 불변으로 보관하고 AI는 읽기만 한다, 위키는 AI가 쓰고 고치는 정리본이다, 그리고 이 모든 규칙은 스키마 문서 하나에 적어 AI가 매번 읽게 한다. 전체 페이지 목록(index)과 작업 이력(log)을 AI가 스스로 유지하는 것까지, 여기까지는 패턴 그대로입니다.
그런데 이 패턴은 원래 논문이나 아티클 같은 연구 자료를


