소개: LLM Wiki 구축의 필요성
업무에서 검토·판단성 결과물이 꾸준히 쌓입니다. 사안마다 근거를 정리하고, 비슷한 케이스를 다시 찾아보고, 같은 판단을 또 반복하게 됩니다. 양은 늘어나는데 "예전에 비슷한 거 어떻게 봤었지?"가 점점 어려워져요. 키워드 검색만으로는 한계가 보였습니다.
LLM Wiki 스터디에 참여하면서, 이걸 계기로 두 가지를 같이 풀어보려고 합니다.
1. Hermes 프로파일을 역할별(리서치·라이터·리뷰어)로 쪼개기. 한 봇에 모든 시스템 프롬프트와 도구를 욱여넣지 않고, 작업 성격에 맞춰 분리합니다.
2. 제 업무 결과물을 LLM Wiki 형태로 정리해서 그 프로파일들이 참고하게 만들기. 본문은 익명화/추상화한 사본만 넣고, 검색·답변 가능한 형태로 구성합니다.
아직 결과물이 있는 단계가 아니라, 출발 시점의 고민과 1주차 계획을 솔직하게 적어둡니다. 결과는 4주차쯤 다시 정리할 예정이에요.
진행 방법: 역할별 프로파일과 자료 익명화
출발 환경
전제 조건은 한 단계 위 작업에서 이미 정리해뒀습니다. Hermes Agent를 사내 SSL MITM 환경에서 슬랙에 연결하는 부분(`hermes-agent[slack]` extra, launchd env 우회, 회사 CA 번들 경로) — 그 위에서 이번 주차는 "이 봇을 실제로 어떻게 쓸지"에 들어갑니다.
프로파일을 왜 역할별로 쪼개는가
처음엔 단일 프로파일에 시스템 프롬프트를 길게 박고, MCP 도구도 다 붙여놨습니다. 두 가지 문제가 있었어요.
도구가 100개를 넘어가니까 LLM이 매번 적절한 걸 못 고릅니다. 단순 요약 작업에도 굳이 시트 조회 도구를 들춰보는 식이었어요.
시스템 프롬프트가 자꾸 자기 모순. 리서치엔 "철저히 의심하고 출처 요구"가 좋은데, 라이팅엔 "거침없이 초안부터 뽑기"가 좋습니다. 한 프롬프트에 둘 다 넣으면 둘 다 어중간해져요.
그래서 1주차 후반에는 프로파일을 셋으로 쪼개기로 했습니다.
리서치 프로파일: 검색·법령·문서 도구만 노출. 시스템 프롬프트는 "출처 우선, 모르면 모른다고", 답변 톤도 조심스럽게.
라이터 프로파일: 노션·시트 쓰기 권한 위주. 톤은 초안 빠르게 → 사용자가 다듬는 흐름.
리뷰어 프로파일: 같은 자료를 다시 읽고 결함을 찾는 역할. 검색은 가능하지만 쓰기 도구는 제거. 시스템 프롬프트는 "동의보다 반론을 먼저".
장점이 두 개 보입니다. (1) 슬랙에서 @봇 멘션 한 번에 어떤 모드로 답할지 명확해집니다. (2) 시스템 프롬프트가 짧고 단단해지니까 일관성이 늘어날 거라고 기대하고 있어요. 이건 가설이라 4주차에 평가셋으로 확인할 생각입니다.
LLM Wiki에 넣을 자료 — 익명화가 핵심
제 업무 결과물은 그대로 넣을 수 없습니다. 1주차에 자료 범위를 정할 때 가장 신경 쓴 게 이 부분이에요.
원칙은 이렇게 잡았습니다.
사내 식별자(이름·팀·시스템 ID·내부 URL)는 자료 진입 단계에서 자리표시자로 치환합니다.
사안 본문은 "어떤 종류의 판단을 했는가"라는 추상화 레벨로 다듬습니다. 누가 의뢰했고 어디서 발생했는지보다, "이런 패턴엔 이렇게 봤다"가 위키의 자산입니다.
원본은 사내 시스템에 그대로 두고, 위키엔 추상화된 사본만 둡니다. 위키가 유출돼도 원본 식별이 어렵게요.
이 익명화 자체가 1주차의 가장 큰 작업이 될 것 같습니다. 자동화 파이프라인 일부도 같이 만들 예정이에요.
첫 MVP 범위
스터디 한 주차 안에 위키 전체를 만들 수는 없으니, 첫 MVP는 아주 작게 잡았습니다.
자료 30~50건만 골라서 익명화 → 노션 한 DB에 적재.
리서치 프로파일에서 그 DB만 참조하도록 MCP를 묶어둡니다.
평가셋으로 "제가 자주 받는 질문 10개"를 만들어두고, MVP 답변 품질을 사람 채점으로 확인.
이 정도면 위키의 가치가 있는지 없는지는 가른다고 봅니다. 임베딩/벡터DB 같은 본격 RAG는 평가셋이 자리 잡힌 다음 주차에 들어가려고요.
지금 가장 고민되는 부분 — 검색·리트리벌 인프라를 어디까지 갖출지
스터디 발표자료를 보다가 가장 머리에 남은 게 검색 인프라 선택 문제입니다. 처음엔 "벡터DB 깔고 RAG부터"가 정석인 줄 알았는데, 실제 단계별로 따져보니 그게 그렇게 간단하지가 않더군요.
지금 잠정적으로 잡은 단계별 가이드는 이렇습니다.
시작 단계(~100 페이지): 굳이 별도 인프라가 필요 없을 가능성이 큽니다.
index.md하나 잘 짜고grep+ Obsidian 검색이면 충분히 닿아요. 첫 MVP는 여기에 속한다고 봅니다.중간 단계(~수백 페이지): 가벼운 로컬 검색 엔진(`qmd` 같은 것) 정도면 충분히 견딜 거라고 추정합니다.
무거워진 단계: 그때 가서야 컨텍스트 DB급 인프라를 검토해도 늦지 않다는 결론에 가까워지고 있어요.
이 단계별 사고에 영향을 준 게 OpenViking이라는 오픈소스입니다. AI 에이전트 전용 컨텍스트 DB를 표방하는 프로젝트인데, 흥미로운 컨셉 세 가지가 들어 있어요.
`viking://` URI 스킴 + 파일시스템 패러다임 — flat DB가 아니라 계층 구조로 컨텍스트를 둡니다. 타입을 Resources(장기 지식·문서·코드) / Memory(에이전트 인지·학습 경험) / Skills(호출 가능 capabilities) 셋으로 나누는 게 인상적이었어요.
Progressive Loading (L0/L1/L2) — L0 Abstract(~100토큰)로 빠른 필터, L1 Overview(~2k토큰)로 navigation·리랭킹, L2 Detail로 on-demand. 위에서 적은 "도구 100개 넘으면 LLM이 못 고른다"는 문제의 직접적 해답에 가깝습니다.
Directory Recursive Retrieval — 단순 벡터 검색이 아니라, 고득점 디렉토리부터 좁혀가며 재귀 탐색합니다. 검색 경로가 시각화돼서 블랙박스가 덜한 것도 매력이에요.
다만 한 가지 분명히 해두고 싶은 건, OpenViking은 사내 표준 도구가 아니라 외부 오픈소스(Apache 2.0)라는 점입니다. 발표자료 슬라이드에 비중 있게 나와서 자칫 사내 디폴트처럼 읽힐 수 있는데, 실제로는 직접 설치·운영 부담이 따라오는 추가 인프라예요. 그래서 "사내에서 자연스럽게 채택하는 분위기"로 받아들이면 도입 결정 무게가 잘못 잡힙니다. 저도 1주차에 이걸 헷갈렸다가 메모를 따로 박아뒀어요.
결국 지금 제 잠정 결론은 — 첫 MVP는 노션 + 리서치 프로파일 조합으로 단순하게 시작하고, 자료가 무거워지는 시점에 OpenViking 같은 컨텍스트 DB를 별도 검토하자입니다. 단계 건너뛰는 욕심은 자제하려고요.
결과와 배운 점: LLM Wiki 구축의 성과와 과제
지금까지 확인한 점
단일 프로파일은 도구 폭이 커지면 빠르게 망가집니다. 역할별 분리가 단순해 보여도 실제 효과는 작지 않을 거라고 보고 있어요 — 그래도 평가 전까진 가설로 둡니다.
LLM Wiki는 도구 문제가 아니라 자료 추상화의 문제입니다. 위키를 어떻게 검색되게 만들지보다, 어떤 단위로 다시 쓸지를 먼저 풀어야 합니다.
검색 인프라는 자료 분량의 함수입니다. 시작부터 무거운 컨텍스트 DB를 깔면 운영 부담만 떠안고 효용은 안 나옵니다.
걱정거리
익명화 파이프라인이 새는 부분 없이 동작하는지 검증 비용이 비쌉니다. 셀프 리뷰만으론 부족할 것 같아 미니 체크리스트가 필요해요.
검색 품질 평가 — 평가셋이 부실하면 "느낌상 좋아진 것 같다"로 끝나기 쉽습니다. 1주차에 평가셋 초안을 같이 만들어두는 게 안전할 듯합니다.
OpenViking 같은 외부 인프라를 도입할 때, 사내 데이터를 어디까지 옮길 수 있는지(보안·계약·운영 책임)는 별도 검토가 필요합니다. 기술 컨셉 매력만 보고 의사결정하지 않으려고요.
다음 주에 할 것
리서치/라이터/리뷰어 프로파일 시스템 프롬프트 v0 작성, 사람 평가로 흔들어보기.
익명화 규칙 미니 SOP 1장.
평가셋 질문 10개 + 합격선 정의.
발표자료에서 인용되는 오픈소스/사내 인프라를 분류해서, "사내 표준"인지 "발표자가 자기 vault에 채택한 외부 도구"인지 한 장으로 정리.
스터디장님께 미리 묻고 싶은 게 한 가지 있습니다 — 평가셋을 너무 일찍 박으면 "그 평가셋에만 잘하는" 위키가 되지 않는지요. 1주차에 만든 평가셋을 4주차까지 그대로 쓰는 게 맞는지, 단계별로 갈아끼우는 게 맞는지가 아직 안 잡혀요.
