개인 맥락 보존을 위한 마크다운 위키 도입 배경
여기어때 유저혜택개발팀의 변자룡 엔지니어는 2026년 9월 10일 기술블로그를 통해, 개별 업무 히스토리와 의사결정 맥락을 반영구적으로 보존하기 위해 개인용 LLM 마크다운 위키를 구축해 2개월간 운영한 경험을 공유했다. 집에서 OpenClaw 같은 비서형 AI를 쓰며 이전 맥락을 이어가는 편의성을 체감했으나, 보안 정책상 사내 업무 데이터를 외부 에이전트에 연동할 수 없었고 전사 차원의 대규모 검색 시스템을 개인이 직접 세울 수도 없었던 한계에서 출발한 시도다.
기존에는 두 곳의 메모 앱에 걸쳐 900장이 넘는 노트를 누적해 두었으나, 개별 메모가 작성 당일의 단편적 맥락으로만 흩어져 있어 AI에게 질문해도 엉뚱한 노트를 근거로 드는 등 한계가 명확했다. 작성자는 문서 양 자체보다 문서 간에 연결된 링크 구조가 부재한 점을 원인으로 지목하고, 페이지 간 하이퍼링크를 핵심으로 삼는 마크다운 위키 구조로 전환을 결정했다. 900장의 기존 노트를 원본 디렉토리로 이관하는 데는 단 하루가 걸렸다.
카파시의 원안과 엔지니어링 실무 환경에 맞춘 아키텍처 개작
기본 뼈대는 인공지능 연구자 안드레이 카파시가 2026년 4월 제안한 'LLM 위키' 패턴을 따랐다. 카파시의 설계는 불변의 원본 보관소(raw/), LLM이 읽고 쓰는 정리본 위키(wiki/), 그리고 전체 색인(index.md) 및 작업 기록(log.md)으로 구성된다. 매 질문마다 원문을 새로 벡터 검색하는 무기억성 전통적 검색 증강 생성(RAG) 대신, LLM이 사전에 지식을 마크다운으로 컴파일해 축적하는 원리다. 그러나 이 원안은 내용이 시간에 따라 변하지 않는 학술 논문이나 아티클 정리를 상정한 모델이어서 실무 엔지니어링 환경에는 그대로 들어맞지 않았다.
이에 따라 작성자는 인간 가독성을 확보하기 위해 목차(MOC, Map of Content) 계층을 index.md 위에 얹었다. index.md는 LLM에게는 효율적인 진입점이지만 인간이 직관적으로 훑어보기에는 긴 표에 불과했기 때문이다. 도메인별(쿠폰, 포인트, B2B 등)로 분류된 MOC 페이지에 '해당 링크가 왜 중요한지'를 한 줄로 적고, 모든 페이지가 반드시 특정 MOC에서 도달 가능하도록 규칙을 강제하여 링크가 유실된 고아 페이지 생성을 사전에 방지했다.
'기억의 노화'를 방어하기 위해 추가된 3대 운영 규칙
실무 운영을 안정화하기 위해 도입된 규칙은 원본 불변성의 강화, 독립 처리 대장 분리, 그리고 코드베이스 우선 검증의 세 가지였다. 첫째, 원안의 '내용 수정 금지'를 넘어 '파일 이동 및 파일명 변경 전면 금지'로 원칙을 좁혔다. AI가 파일을 폴더 간에 임의로 재분류할 경우 기존 위키 링크와 출처 역추적이 깨지는 현상이 발생했기 때문에 잘못 들어온 파일조차 그대로 보존했다. 둘째, 매일 유입되는 업무 기록의 처리 상태를 원본 파일이 아닌 별도 대장 표(미처리 목록 및 완료 기록)로 격리해 중복 수집을 방지하고 프롬프트 토큰 낭비를 줄였다.
셋째이자 가장 핵심적인 규칙은 '위키보다 코드를 우선 믿는다'는 전제다. 논문과 달리 비즈니스 정책은 수시로 변경되고 코드는 매주 배포되므로 작성 시점에 박제된 위키의 기억은 필연적으로 낡아버린다. 따라서 작성자는 위키를 통해 '과거에 왜 그렇게 결정했는가'라는 맥락(Why)을 파악하되, 현재 시점의 실효성(What)은 실제 코드베이스로 즉각 검증하는 2단계 검증 체계를 정립했다. 위키가 틀릴 수 있음을 전제해야 역설적으로 위키를 과감하게 활용할 수 있다는 분석이다.
실제 장애 대응에서 검증된 위키의 분류 역량
이 체계는 2026년 8월 동일한 포인트 취소 API에서 발생한 세 차례의 연속 이슈 대응에서 실질적인 효용을 입증했다. 8월 12일 포인트 사용(17자리)과 취소(14자리) 간 주문번호 자릿수 불일치로 인한 분당 13건의 에러가 발생해 원인 체인과 대응 근거를 위키 분석 페이지로 남겼다. 이어 8월 19일 다른 부서로부터 같은 '사용내역이 없습니다' 에러가 보고되었을 때, AI는 과거 기록을 대조하여 '지난주 이슈와 달리 주문번호 자릿수는 정상'임을 밝혀냈고, 실제 원인이 취소 요청에 사용 타입을 오전송한 값 오류임을 빠르게 짚어냈다.
8월 20일 같은 API에서 커넥션 풀 고갈 알림이 발생했을 때도, 앞선 두 사례가 400 비즈니스 에러였던 것과 달리 이번엔 500 서버 장애임을 즉시 구별해 냈다. 담당자는 과거 오류의 재발을 의심하는 대신 곧바로 요청 추적 분석에 착수하여 수천 개 쿼리가 커넥션을 점유하던 N+1 문제를 발견할 수 있었다. 작성자는 위키가 정답을 직접 도출하기보다는 '과거와 같은 일인가, 다른 일인가'를 냉정하게 구분해 엔지니어의 인지적 편향을 교정해 주는 분류 도구로 기능했다고 설명했다.
운영 비용의 불균형과 수동 의존성이라는 구조적 한계
이러한 효용에도 불구하고 2개월간의 실무 운영 결과 시스템의 구조적 한계와 비용 불균형이 확인됐다. 900장의 기존 노트를 이관하는 것은 하루 만에 끝났지만, 두 달이 지난 시점에도 정리가 완료된 것은 445건에 불과했고 103건은 여전히 대기 상태로 남아 있었다. 신규 생성된 위키 페이지는 100여 장, 분석 페이지는 12장에 그쳐 '수집 비용은 극히 작으나 정리·컴파일 비용은 매우 크다'는 점이 입증됐다. 규칙 스키마 역시 운영 첫날에만 6회 수정되는 등 지속적인 조정이 요구됐다.
가장 치명적인 병목은 지식 수집의 수동 트리거 구조였다. 엔지니어가 명시적으로 '위키에 기록하라'고 프롬프트를 실행하지 않으면 기록되지 않았으며, 업무 부하가 높고 바쁜 날일수록 기록이 누락되는 인간 작업자 중심의 역설이 발생했다. 아울러 공개된 글에는 구체적인 LLM 모델 명칭(Claude나 GPT 계열 등)과 구동 클라이언트 세부 스펙, API 토큰 소비에 따른 정량적 비용 수치는 기재되지 않아 시스템 재현을 위해서는 이에 대한 후속 확인과 인프라 설계 검증이 필요하다.
출처
여기어때 기술블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
AI가 내 하루를 기억하게 하는 법 (1/2): 먼저, 기억할 곳을 만들었다 — 개인 LLM 위키 (새 창)
