AI가 내 하루를 기억하게 하는 법 (1/2): 먼저, 기억할 곳을 만들었다 — 개인 LLM 위키

2026년 9월 10일

글. 변자룡(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가 스스로 유지하는 것까지, 여기까지는 패턴 그대로입니다.

그런데 이 패턴은 원래 논문이나 아티클 같은 연구 자료를 쌓는 용도로 나온 겁니다. 제 위키에 들어오는 건 슬랙 스레드, 지라 티켓, 회의 메모처럼 매일 밀려드는 업무 기록이고, 묻는 사람도 AI만이 아니라 저 자신입니다. 그대로 옮겨 넣자 부족한 데가 하나둘 보이기 시작했습니다.

가장 먼저 부족했던 건 사람이 다닐 길 이었습니다. index는 전체 페이지를 한 줄씩 나열한 목록이라 AI에게는 좋은 진입점이지만, 사람이 훑기엔 그냥 긴 표입니다. 저도 매일 이 위키를 봐야 하는데 말이죠. 그래서 목차(MOC) 계층을 하나 얹었습니다. 홈에서 제가 담당하는 도메인(쿠폰·포인트·B2B...)으로, 도메인에서 개별 페이지로 내려가는 구조인데, 링크마다 "왜 중요한지" 한 줄을 붙이고, 모든 페이지는 어느 목차에서든 도달할 수 있어야 한다는 걸 규칙으로 박았습니다. 이 규칙 덕에 어디에도 연결되지 않은 고아 페이지가 생기는 걸 사후 검진이 아니라 생성 시점에 막게 됐고, 무엇보다 AI와 제가 같은 위키를 쓰게 됐습니다.

※ MOC(Map of Content): 옵시디언 같은 노트 도구 커뮤니티에서 쓰는 개념으로, 폴더 분류 대신 관련 페이지 링크를 모아 놓은 "목차 페이지"를 말합니다.

원본과 정리본을 가른 효용도, 연구 자료를 다룰 때보다 업무에서 더 컸습니다. 나누지 않으면 AI는 원본과 해석을 같은 무게로 읽습니다. 슬랙에서 누군가 "아마 이럴 거예요"라고 한 추측과, 제가 코드를 확인하고 적은 결론이 같은 폴더에 같은 형식으로 있으면, AI가 답할 때 어느 쪽을 근거로 삼았는지 저도 AI도 알 수 없게 됩니다. 원본은 그 시점에 오간 기록 그대로, 정리본은 그걸 소화해서 내린 지금의 결론으로 역할을 갈라 두면, 답이 이상할 때 어디를 고쳐야 할지 바로 보입니다. 결론이 낡은 거면 정리본을 고치고, 기록 자체가 잘못 들어온 거면 원본부터 다시 보면 되니까요.

제가 질문하면 AI가 답을 찾는 순서도 정해 뒀습니다. 위키를 먼저 훑고, 없으면 원본으로, 그리고 코드로 검증해서 답합니다. 답 중에 다음에도 쓸 만한 것(비교표, 흐름 분석, 디버깅 결론)은 분석 페이지로 남기게 했고요. 두 달 동안 이렇게 쌓인 페이지가 100장 남짓, 그중 분석 페이지가 12장입니다. 위키의 큰 틀: 원본(raw)은 그대로, 정리본은 따로, 목차(MOC)는 위에

패턴에 없던 규칙 세 개

구조에는 목차를 얹었다면, 운영에는 규칙을 얹어야 했습니다. 두 달을 돌아보면 중요한 건 세 개였고, 셋 다 결국 같은 질문에 대한 답입니다. AI의 기억을 얼마나 믿을 것인가.

원본은 건드리지 않는다

원안의 불변 원칙은 "수정 금지"까지입니다. 저는 만든 첫날 "이동과 이름 바꾸기도 금지"로 조여야 했습니다. AI가 정리를 하다 보면 잘못 들어간 파일을 올바른 폴더로 옮기고 싶어 하는데, 옮기는 순간 그 파일을 가리키던 링크와 출처 기록이 끊깁니다. 더 나쁜 건 끊긴 줄 모른 채 AI가 다른 파일을 근거로 답한다는 겁니다. 그래서 잘못 들어온 파일도 그대로 두고, "잘못 들어왔다"는 사실을 따로 적습니다. 출처가 흔들리면 기억을 믿을 수 없습니다.

상태는 원본이 아니라 대장에 적는다

연구 자료는 한 번 넣으면 끝이지만, 업무 소스는 매일 밀려들어서 "어디까지 정리했나"를 추적해야 합니다. 원안에는 이 추적이 없습니다. 그렇다고 처리 상태를 원본 파일 안에 표시하면 방금 세운 불변이 깨지죠. 그래서 상태는 별도의 대장(표 하나)에서만 관리합니다. 변하는 것을 변하지 않는 것에 섞지 않는 것, 그게 전부입니다. 대장은 나중에 "미처리 목록"과 "완료 기록" 둘로 다시 나눴는데, 미처리 목록이 길어져서 AI가 매번 전체를 읽는 비용이 커졌기 때문입니다. 덤도 있었습니다. 같은 소스를 두 번 수집하는 걸 막는 유일한 관문이 이 대장이 됐습니다.

위키보다 코드를 믿는다

카파시의 위키에서는 원문이 곧 진실입니다. 논문은 시간이 지나도 내용이 그대로니까요. 업무는 다릅니다. 정책은 바뀌고 코드는 매주 배포되는데, 위키는 쓰인 시점에 멈춰 있습니다. 그래서 위키로는 "왜 그랬는지"를 찾고, 코드로 "지금도 그런지"를 확인합니다. 이 규칙을 세운 건 위키가 틀릴 수 있어서가 아니라, 틀릴 수 있다고 전제해야 역설적으로 위키를 더 과감하게 쓸 수 있기 때문 입니다. 틀려도 코드에서 걸리니까요. 최근 사내 블로그의 "늙어버린 당신의 AI"에서 "기억도 늙는다"는 표현을 봤는데, 정확히 같은 문제입니다. 기억은 사실의 시점에 묶여 낡고, 그걸 막을 수는 없으니 낡았을 때 걸리는 장치를 두는 수밖에 없습니다.

비용도 말씀드려야 공정하겠죠. 이 규칙들은 만든 첫날에만 여섯 번 고쳤고, 두 달이 지난 지금도 손봅니다. 그리고 900장을 옮긴 뒤 정리가 끝난 건 445건, 아직 대기 중인 게 103건입니다. 모으는 비용은 작고, 정리하는 비용은 큽니다. 이 비용을 감수할 만한지는 다음 섹션이 답이 될 것 같습니다. 패턴에 없던 규칙 세 개, 결국 'AI의 기억을 얼마나 믿을 것인가'

기억이 작동한 순간 --- 같은 알림, 세 번

8월에 같은 포인트 취소 API에서 알림이 세 번 왔습니다. 이 세 번이 위키가 무엇을 해주는지 가장 잘 보여줬습니다.

8월 12일. 개발 환경 알림 채널에 "사용내역이 없습니다"라는 에러가 매분 13건씩 쌓였습니다. 추적해 보니 주문 쪽이 포인트 사용 은 17자리 주문번호로, 취소는 14자리 주문번호로 호출하고 있었습니다. 번호가 안 맞으니 취소할 사용 내역을 못 찾는 게 당연했고요. 원인 체인과 검증 근거, 교훈을 분석 페이지로 남겼습니다.

8월 19일. 다른 팀에서 같은 에러 메시지가 난다는 DM이 왔습니다. 저는 "어? 이거 지난번 그 주문번호 자릿수 문제 아냐?" 한마디만 AI에게 던졌습니다. 예전 같으면 이 한마디로는 안 됐을 겁니다. 지난번이 언제 어떤 장애였고 원인이 뭐였는지를 제가 다시 하나하나 입력해 줘야 대조가 가능했을 테니까요. 이번엔 AI가 알아서 위키에서 지난주 분석 페이지를 찾아 대조하고는 *"지난번과 다르다. 그때는 번호가 어긋났지만, 이번 요청은 번호가 맞다"*고 잘라 말했습니다. 같은 문제가 아니라면 새 원인이 있다는 뜻이죠. 로그와 코드를 따라가 보니 이번엔 사용 타입을 취소 요청에 그대로 보내고 있었습니다. 문의 주신 팀의 "사용 직후에 취소해서 커밋 전에 조회된 것 아닐까요?"라는 타이밍 추측도 자연스럽게 기각됐고요.

8월 20일. 이번엔 커넥션 풀 고갈 알림이었습니다. 알림이 또 같은 포인트 취소 API에서 왔길래 저는 내용을 자세히 보기도 전에 "또 그거 아냐?"부터 나왔습니다. 위키는 1분 만에 그 생각을 기각했습니다. 앞의 둘은 호출 파라미터가 어긋나 400으로 거절된 비즈니스 에러였는데, 이번엔 500, 서버가 응답을 못 하는 다른 증상이라고요. 덕분에 지난 이슈들을 다시 뒤지는 대신 바로 원인 확인을 위한 요청 추적(트레이스) 분석으로 넘어갔고, 요청 하나가 수천 개의 쿼리를 날리며 커넥션을 수 분씩 붙잡고 있는 N+1을 찾았습니다.

돌아보면 위키가 해준 건 정답이 아니라 구분이었습니다. "이건 지난번과 같은 일인가, 다른 일인가." 장애 대응에서 가장 먼저 필요한 판단이 이건데, 사람의 직감은 여기서 자주 틀립니다. 저만 해도 19일엔 같은 메시지를 보고 지난번과 같은 원인을 의심했고, 20일엔 또 같은 문제인 줄 알았으니까요. 위키는 그때마다 지난 기록과 대조해 "메시지는 같지만 원인이 다르다", "API는 같지만 증상이 다르다"라고 바로잡아 줬습니다.

단, 여기서도 기억은 낡았습니다. 8월 12일 페이지에는 "데이터 정리로 해소 완료"라고 적혀 있었는데, 19일에 그게 정말 반영된 상태인지는 다시 확인해야 했습니다. 위키보다 코드를 믿는 이유가 이겁니다. 같은 API에서 온 알림 세 번, 원인은 모두 달랐다

그런데, 오늘이 들어오지 않는다

여기까지 읽으시면 잘 돌아가는 것처럼 보이지만, 사실 이 한계는 위키를 만든 첫날 저녁에 이미 보였습니다. 위키는 제가 넣은 것만 기억합니다. 8월 12일 알림도 제가 "이거 위키에 넣어줘"라고 했기 때문에 들어갔습니다. 문제는 바쁜 날일수록 그 말을 안 하게 된다는 겁니다. 위키 이전에 오래 수기로 써 온 할 일 메모가 그랬습니다. 돌아보면 바쁜 날일수록 메모가 짧았고, 정작 가장 기억해야 할 날이 가장 비어 있었습니다.

기억할 곳은 만들었는데, 오늘이 그 안으로 저절로 들어오지는 않을 게 뻔했습니다. 그래서 위키를 만든 그날 저녁에, 아침에 할 일을 모으고 저녁에 하루를 정리해 그 기록이 자동으로 위키에 쌓이는 루프를 설계했습니다. 그 이야기는 2편에서 이어가겠습니다.

마치며

큰 시스템을 만든 게 아닙니다. 마크다운 폴더 세 개와 규칙 몇 줄, 그리고 링크를 아끼지 않는 습관이 전부입니다. 그래도 두 달 동안 "왜 그랬더라"를 묻는 횟수가 눈에 띄게 줄었고, 같은 알림을 세 번 다르게 볼 수 있었습니다.

매번 대화를 새로 시작할 때마다 같은 맥락을 처음부터 설명하는 게 불편하셨거나, AI가 지난달의 결정과 지난주의 장애를 기억해 주길 바라셨다면, 위키를 한번 시작해 보세요. 다만 패턴을 그대로 옮기는 데서 멈추지는 않으셨으면 합니다. 제가 목차를 얹고 규칙 세 개를 더했듯 본인 업무에 맞는 규칙을 하나씩 쌓아 가면, 어느새 내 기억을 가진 나만의 비서 같은 AI와 일하게 됩니다. 긴 글 읽어주셔서 감사합니다.

AI가 내 하루를 기억하게 하는 법 (1/2): 먼저, 기억할 곳을 만들었다 --- 개인 LLM 위키 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.