안녕하세요, 백엔드 엔지니어 이정기입니다.
지난 CTO쌤 글에서 AI-Native 전환의 세 가지 방향 중 하나로 '지식 접근 비용을 최소화하는 것'이 언급됐습니다.
이번 글에서는 사내 지식 저장소를 만들면서 무엇을 고민했고, 어떤 결정을 왜 그렇게 내렸는지 공유하고자 합니다.
"그거 어디 있죠?"에 드는 비용
기능 하나를 만지기 전에 기존 정책부터 확인해야 할 때가 있습니다. 저희가 실제로 겪고 있는 일은 이렇습니다. 먼저 노션을 검색합니다. 오래전에 작성된 기획서가 나옵니다. 문서에는 언제 쓰였는지만 적혀 있지, 지금도 유효한지는 적혀 있지 않습니다. 슬랙을 검색합니다. 논의 스레드는 남아 있는데 결론이 없습니다. 지라를 봐도 티켓은 닫혀 있고 왜 그렇게 결정됐는지는 적혀 있지 않습니다. 결국 담당자에게 물어보게 되는데, 돌아오는 답은 대체로 "그건 코드를 봐야 알 수 있어요"였습니다. 그래서 코드를 열고, 문서에 적힌 내용이 맞는지 역으로 검증합니다.
그리고 반대로 누가 저에게 물어오면, 저도 똑같이 그렇게 답하고 있었습니다.
물론 이렇게 알아낸 내용을 그냥 넘기지는 않습니다. 대개 슬랙 스레드에 정리해서 남겨둡니다. 문제는 그 기록이 스레드 안에 갇힌다는 점입니다. 한 달쯤 지나면 그런 스레드가 있었다는 사실 자체를 기억하는 사람만 다시 찾아갈 수 있고, 나머지는 처음부터 다시 확인하게 됩니다. 한 건씩 보면 대수롭지 않을 수 있지만 인원 수만큼 반복되면 꽤 큰 비용이라고 생각합니다.
문제는 문서의 양이 아니었습니다
이런 과정을 반복하다 보니, 저희에게 문서가 부족한 게 아니라는 걸 알게 됐습니다. 노션과 슬랙에 남아 있는 기획서와 정책서는 충분히 많았습니다. 문제는 찾아지지 않는다는 쪽이었습니다. 왜 안 찾아지는지 따져보니 두 가지였습니다.
첫 번째는 문서의 위치가 사람의 기억에 의존한다는 점입니다. 검색은 단어를 알아야 쓸 수 있는데, 그 문서를 뭐라고 불렀는지 모르면 검색창은 쓸모가 없습니다. 결국 "어디 있는지 아는 사람"을 찾게 되고, 문서를 찾는 데 또 시간을 쓰게 됩니다.
두 번째는 찾은 문서가 최신인지 신뢰할 수 없다는 점입니다. 확신이 없으면 결국 코드를 열어보게 되고, 그러면 문서를 찾은 의미가 없어집니다. 문서를 쓰는 사람 입장에서 보면 이해가 되는 일이기도 합니다. 코드를 고치고 배포한 다음, 다시 문서 도구를 열어 수동으로 해당 페이지를 찾아 고쳐야 합니다. 규칙이 무너지는 건 대개 지키는 비용이 너무 커서라고 생각합니다.
AI를 통해 일하는 것이 자연스러워진 지금, 정작 문서를 찾는 일에는 AI를 활용하지 못하고 있습니다. 만약 지식이 한곳에 모여 있다면 AI에게 그곳만 읽고 판단해서 답을 달라고 할 수 있는데, 지금은 그 '한곳'이 없습니다. 그래서 이 문제부터 풀기로 했습니다.
사람이 쓰는 위키를 포기했습니다
문서를 잘 쓰자는 이야기는 전에도 나왔습니다. 그때마다 오래가지 못했는데, 앞에서 말씀드린 갱신 비용 때문이라고 생각합니다. 그래서 이번에는 전제를 바꿔보기로 했습니다. 사람이 위키를 쓰지 않는 것입니다. Karpathy가 정리한 LLM Knowledge Base 패턴을 참고했습니다. 사람은 원본 자료만 넣어두고, LLM이 그걸 읽어서 구조화된 위키를 만들고 유지하는 방식입니다. 회의록이든 기획서든 코드 변경 내역이든 일단 던져 넣으면, 분류하고 핵심을 뽑아 문서로 만드는 일은 LLM이 합니다.
사람에게 남는 일은 무엇을 넣을지 고르는 것입니다. 정해진 폴더에 자료를 넣으면 그다음은 AI가 합니다.
그러면 AI가 만든 문서가 맞는지는 누가 확인하느냐는 질문이 남습니다. 처음에는 사람이 검수하는 단계가 있어야 하나 생각했지만, 결국 그게 앞에서 말씀드린 갱신 비용과 같은 문제가 된다고 봤습니다. 그래서 검증도 사람이 아니라 파이프라인이 하도록 만들었습니다.
이제 어디에 어떻게 저장할지가 남았습니다. 저희가 고른 건 마크다운과 Git이었습니다. 마크다운 파일은 AI가 별도 연동 없이 그냥 읽습니다. Git에 올려두면 누가 언제 무엇을 바꿨는지 커밋 이력에 남고, 잘못되면 되돌릴 수 있습니다. 나중에 문서 도구를 갈아타더라도 지식은 그대로 남는다는 점도 좋았습니다. 열람은 Obsidian을 사용하기로 했습니다. 마크다운을 보기 좋게 열어주고 문서 간 연결을 그래프로 보여줘서, md 파일로 쌓인 문서를 보기에 적합했습니다.
정리하면 저장은 Git, 열람은 Obsidian, 작성은 AI입니다.
폴더를 어떻게 나눌 것인가
저장소를 만들고 나니 폴더를 어떻게 나눌지가 다음 질문이었습니다. 팀별로 나눌지, 주제별로 나눌지 고민했습니다.
그런데 이야기하다 보니 이 고민 자체가 예전 방식이라는 걸 알게 됐습니다. 이 저장소는 사람이 폴더를 열어가며 찾는 곳이 아닙니다. 문서를 쓰는 것도 AI고, 읽는 것도 AI입니다. 사람은 궁금한 걸 AI에게 물어보고, AI가 위키에서 찾아 답해줄 뿐입니다.
폴더 구조는 사람이 파일을 쉽게 찾기 위한 것입니다. 찾는 주체가 AI라면, 사람이 미리 정해둔 구조가 오히려 제약이 될 수도 있겠다고 생각했습니다. 그래서 분류도 AI에게 맡겼습니다. 폴더 트리를 미리 짜두는 대신, 같은 주제끼리 알아서 묶으라고 지시했습니다. 새 자료가 들어오면 AI가 기존 인덱스를 먼저 읽고, 기존 문서에 붙일지 새로 만들지를 판단합니다.
몇 달 돌려보니 사람이면 짓지 않았을 이름들이 나왔습니다. 한국어 도메인 용어를 그대로 직역한 파일명 같은 것들인데, 보기엔 어색해도 검색으로는 정확히 잡힙니다.
넣는 방법은 하나여야 합니다
자료를 넣는 경로가 여러 개면 결국 아무도 넣지 않는다고 봤습니다. 그래서 입구를 하나로 만들었습니다. 정해진 폴더에 파일을 넣고 명령 한 줄을 실행하면 끝입니다.
그다음은 AI가 합니다. 자료가 어떤 종류인지 판단하고, 기존 위키에 같은 주제가 있는지 확인해서 새로 만들거나 기존 문서에 붙입니다. 인덱스와 작업 로그를 갱신하고, 처리가 끝난 원본은 보관함으로 옮깁니다. 폴더 구조를 외울 필요가 없다는 점이 중요했습니다. 자료를 넣으려고 폴더 구조를 먼저 익혀야 한다면 판단 비용이 또 들기 때문입니다.
또한 이 저장소는 개발자만 쓰는 곳이 아니라는 점도 고려해야 했습니다. Git을 저장소로 골랐으니 원래대로라면 Push와 Pull을 직접 해야 합니다. Git을 안 써본 사람에게는 이게 하나의 허들이 더 생기는 일입니다. 그래서 동기화는 5분마다 자동으로 돌게 해뒀습니다. 명령 한 줄만 실행하면 나머지는 알아서 처리되니, Git이 뒤에서 돌아가고 있다는 걸 몰라도 쓸 수 있습니다.
규칙은 두 개만 강하게 걸었습니다.
첫 번째는 원본을 수정하지 않는 것입니다. AI는 원본을 읽기만 하고, 처리가 끝나면 지우지 않고 보관함으로 옮깁니다. 위키에 적힌 내용의 근거가 무엇인지 원본까지 되짚을 수 있어야 하니까요.
두 번째는 모순을 덮어쓰지 않는 것입니다. 새 자료가 기존 위키와 충돌하면 갈아치우는 대신 양쪽을 다 남기고 충돌 표시를 붙입니다. 문서끼리 내용이 어긋난다는 건 AI가 판단할 문제가 아니라 사람이 확인해야 할 지점이라고 봤습니다. 덮어쓰기를 허용하면 그 지점이 그냥 사라지고, 자동으로 갱신되는 시스템에서 조용히 사라진 건 아무도 발견하지 못하기 때문입니다.
누구나 물어볼 수 있게 만들기
저장소를 채우고 나니 어떻게 물어보게 할지가 남았습니다. 아무리 잘 쌓아둬도 접근하기 어려우면 결국 안 쓰게 될 거라 생각했습니다. 그래서 사내 메신저인 슬랙에 봇을 만들었습니다. 원하는 채팅창에서 멘션해서 물어보면 되니, 따로 무언가를 설치하거나 배울 필요가 없습니다. 챗봇의 이름은 팀 투표로 "윌슨"이 됐습니다. 매일 말을 걸어야 하는 상대라면 친숙한 편이 낫다고 생각했습니다.
윌슨은 저장소를 뒤져 답하고, 답 아래에 근거로 삼은 문서를 함께 붙입니다. 다만 문서가 점점 많아지면 검색 속도가 문제 될 것 같았습니다. 그래서 QMD를 활용해 저장소 전체를 벡터화해 인덱싱해뒀습니다. 문서가 많아져도 물어봤을 때 빠르게 찾아줄 수 있도록 하기 위해서입니다.
"학생앱 구독 정책이 언제 어떻게 정해졌는지 찾아줘"라고 물어봤습니다. 윌슨은 그 문서가 코드에서 추출된 시점과 원본이 보관함 어디에 남아 있는지, 어떤 코드 파일이 인용됐는지까지 알려줬습니다.
코드는 매일 바뀌는데 위키는 안 바뀝니다
여기까지 만들고 나서도 문제가 하나 남아 있었습니다. 저장소는 사람이 자료를 넣을 때만 갱신된다는 점입니다. 서비스 저장소는 매일 바뀝니다. API가 추가되고, 스키마가 바뀌고, 정책이 코드에 먼저 반영됩니다. 그런데 위키는 누군가 시간을 내서 정리해 넣어야만 따라옵니다. 이대로 두면 앞에서 말씀드린 갱신 비용 문제가 그대로 반복될 것 같았습니다.
그래서 갱신 비용을 사람에게서 떼어냈습니다. 매일 새벽에 전날 올라온 PR을 모아 요약을 만들고, 앞에서 만든 정리 절차를 그대로 거쳐 위키에 반영합니다. 마지막에 커밋하고 푸시하는 것까지 자동으로 돌아갑니다.
사람이 개입하는 부분은 없습니다. 아침에 저장소를 열면 어제 나간 변경이 이미 위키에 반영돼 있습니다. 코드를 고친 사람이 문서를 따로 고치지 않아도 됩니다. 요약에 코드 본문은 넣지 않기로 했습니다. 위키는 왜 그렇게 했는지와 무엇이 바뀌었는지를 적어두는 곳이지 코드 사본이 아니라고 봤습니다. 그래서 변경 내용 설명과 API·스키마 변경, 원본 PR 링크만 담습니다. 코드가 필요하면 링크를 타고 가면 됩니다.
지금까지 위키에 반영된 갱신 기록을 보면 사람이 넣은 것이 109건, 파이프라인이 넣은 것이 1,684건입니다. 갱신의 94%가 사람 손을 거치지 않은 셈입니다.
무엇이 달라졌나
가장 크게 달라진 건 물어볼 곳이 생겼다는 점입니다. 예전에는 노션과 슬랙과 지라를 차례로 뒤지고 결국 사람에게 물어봤는데, 지금은 윌슨에게 묻고 답과 함께 근거 문서를 받습니다. 물론 아직 문서가 없어서 답을 못 받는 경우도 있습니다. 그럴 때는 자료를 새로 넣거나, 코드를 고치면 다음 날 PR을 기준으로 문서가 만들어집니다. 한 번 비어 있던 자리는 그렇게 채워지고 다시 비지 않습니다. 이 과정이 반복되다 보면 정책 하나 확인하는 비용은 결국 0에 수렴할 거라고 생각합니다.
근거를 함께 주는 건 문서 구조에 박혀 있습니다. 위키 문서마다 어떤 원본에서 나왔는지, 어느 실행이 언제 건드렸는지가 기록돼 있어서 답변에서 원본까지 되짚을 수 있습니다. AI 답변의 성격도 달라졌습니다. 저장소를 붙이기 전에는 AI가 그럴듯하게 지어내는 경우도 많았습니다. 하지만 지금은 답이 문서 범위 안에서 나오고 출처를 함께 볼 수 있으니, 지어낸 건지 아닌지를 판별할 수 있습니다.
아직 못 한 것들
기획과 디자인, 일하는 방식에 대한 지식이 아직 얇습니다. 서비스 관련 문서가 300개를 넘는 동안 디자인과 기획 문서는 손에 꼽습니다. 자동 파이프라인이 코드 저장소만 보고 있기 때문입니다. 코드에서 나오는 지식은 알아서 쌓이는데, 나머지는 여전히 사람이 자료를 넣어야만 쌓입니다. 앞에서 오래 못 간다고 말씀드린 그 구조가 절반에는 그대로 남아 있는 셈입니다.
검색 품질도 측정하지 못하고 있습니다. 답변이 좋아졌다는 건 써보면서 느끼는데, 숫자로 말할 방법이 없습니다. 자주 묻는 질문의 정답 세트를 만들어 비교하는 게 다음 과제라고 보고 있습니다. 다음으로 보고 있는 건 같은 파이프라인에 코드 외의 입력을 붙이는 일입니다. 이슈 트래커나 디자인 도구의 변경도 같은 방식으로 흘러들게 하면, 지금 개발 지식에서 일어나는 일이 나머지 영역에서도 일어날 거라고 기대하고 있습니다.
마치며
돌아보면 진짜 문제는 자료가 없다는 게 아니었습니다. 자료는 이미 충분했지만 찾아 쓸 수 있는 형태가 아니었습니다. 그래서 저희가 한 일도 새로 무언가를 쌓는 쪽보다는, 이미 있던 자료를 다루기 좋은 형태로 옮기는 쪽에 가까웠습니다. 더 어려웠던 건 그렇게 옮겨둔 것이 계속 현실을 따라가게 만드는 일이었습니다. 문서를 잘 쓰자는 이야기가 오래 못 가는 이유도 결국 여기에 있다고 생각합니다. 처음에는 다들 열심히 넣지만, 갱신 비용을 누군가 계속 부담해야 하는 구조라면 언젠가는 멈춥니다. 그래서 저희가 만든 것도 문서 창고보다는 갱신 파이프라인에 가깝습니다.
AI로 일하는 것이 점점 당연해지면서, 어떻게 하면 더 효율적으로 일할 수 있을지 고민할 기회가 이번에 있었습니다. 이번에는 그 대상이 문서였는데, 만들면서 알게 된 건 AI에게 일을 시키는 것보다 AI가 일할 수 있는 상태를 만들어두는 쪽이 훨씬 오래 간다는 점이었습니다.
프리윌린 안에는 아직 그런 상태로 정리되지 않은 일이 많습니다. 사람이 계속 붙어 있어야 돌아가는 일을 찾아 떼어내는 것, 그게 앞으로도 계속해야 할 일이라고 생각합니다.
