LLM이 말아주는 나만의 지식 창고
Automotive embedded knowledge base using LLM
서론
한 학기 동안 차량용 임베디드 SW 교육을 들으면서 배운 내용을 기록하다 보니, 어느새 강의 노트가 산더미처럼 쌓이고 말았다. 나중에 다시 찾아볼 수 있도록 정리해 보려고 했는데, 한 땀 한 땀 손수 정리하자니 시간이 너무 오래 걸리는 데다가, 강의 순서대로 정리하다 보니 개념끼리 얽힌 관계도 잘 드러나지 않는 것 같았다.
사실 굳이 정리하지 않아도, 궁금할 때마다 AI에게 물어보면 그만이다. 실제로 꽤 잘 알려 주기도 한다. 문제는 그 답을 매번 의심해야 한다는 것이다. 그럴듯하게 틀린 답을 걸러 내려면 결국 출처를 다시 뒤져야 했다. 필요할 때 바로 찾아볼 수 있고, 믿을 수 있는 레퍼런스가 있으면 좋겠다 싶었다.
그러던 중 Andrej Karpathy1가 제시한 LLM wiki라는 개념을 접하게 되었다. 사람이 소스를 고르고 방향을 잡아 주면, 개념별 위키 페이지로 정리하는 일은 LLM이 맡는다는 것이다. 새로운 소스가 들어오면 관련 페이지를 수정하고, 링크를 정리하고, 모순을 찾는 것까지 LLM의 몫이다. 질문할 때마다 소스를 다시 뒤지는 RAG와 달리, 한 번 정리해 둔 지식을 계속 고쳐 쓰며 쌓아 간다.
Karpathy는 사람이 위키를 버리는 이유로 유지보수 부담을 꼽는데, LLM wiki는 바로 그 부담을 LLM에게 떠넘긴다. 다만 LLM이 쓴 내용이 맞는지 확인하는 장치는 따로 없다. 사람이 업데이트를 읽어보고, LLM이 가끔 위키를 점검해 페이지 사이의 모순이나 낡은 주장을 찾는 정도다.
그렇다면 과연 유지보수를 LLM에게 맡겨도, 믿고 찾아볼 수 있는 기술 지식 위키를 만들 수 있을까? 궁금하던 차에 직접 해 보기로 했다. 기술 지식을 다루는 위키라면 내용의 신뢰성과 정합성이 생명이다. 그래서 목표를 이렇게 잡았다. LLM이 쓰되, 모든 주장을 공개 출처로 검증하는 위키.
참고하면 좋은 사이트: LLM-Wiki - LLM을 활용하여 개인 지식저장소 구축 하기 | GeekNews
위키 구축
오픈소스 탐색
먼저 LLM wiki를 구현한 오픈소스를 찾아보다가, 옵시디언과 호환되면서 스타도 많이 받은 claude-obsidian이 눈에 띄었다. 옵시디언은 기본 기능과 플러그인으로 여러 편의 기능을 제공하는데, 그중에서도 그래프 뷰가 개념 사이의 관계를 한눈에 보여 준다는 점이 끌렸다.
직접 써 보니 대체로 무난했지만, 아무래도 범용 도구인 만큼 세부적인 요구사항까지 만족시켜 주지는 못했다. 어차피 AI 덕분에 구현 부담도 크게 줄어든 마당이니, 내 입맛에 맞춘 개인용 위키를 만들기로 했다.
콘텐츠 파이프라인
인제스트 단계에서 초안을 쓰면 페이지마다 주장 검증 에이전트가 붙고, 미검증으로 남은 주장은 재조사에서 한 번 더 조사한다. 게시한 뒤에는 린트가 여러 페이지를 함께 읽으며 페이지 사이의 모순, 중복, 죽은 출처 링크 등을 찾고, Reader Testing으로 외부 독자 관점에서 페이지를 읽어보며 가독성 등을 점검한다.
사이트 엔진은 그래프 뷰, 위키링크, 태그 등을 기본으로 지원하는 Quartz를 선택했다.
주장 검증
위키 페이지의 모든 주장은 fresh context 에이전트가 공개 출처로 뒷받침되는지 검증한다.
검색으로 사실을 확인하는 LLM이 사람(crowdsourced)과 판정이 엇갈린 사례에서 더 자주 옳았다는 연구가 있고,2 검증 질문에 초안과 독립적으로 답하게 하자 환각이 줄었다는 연구 결과도 있다.3
여기서 문제는 ‘어떤 출처를 신뢰할 수 있는가’이다. 주장의 종류에 따라 아래와 같이 정했다.
| 주장 | 예 | 출처 |
|---|---|---|
| 규범 | ISO 11898-1이 비트 타이밍을 어떻게 정의하는가 | 표준·규제 원문, 발행기관의 공개 자료 |
| 동작 | CAN 컨트롤러가 오류 카운터를 어떻게 다루는가 | 위 + 반도체 제조사 문서 |
| 배경 | 누가 언제 만들었고 뭐라고 부르는가 | 발행기관 자료, 원 저자·연구소의 기록 |
| 이론 | RM 스케줄링의 이용률 상한 | 원 논문 |
기준은 하나였다. 권위 있고, 독자가 직접 확인할 수 있는가. 그래서 Wayback 스냅샷과 ISO 표준의 공개 미리 보기는 인정하고, 출처가 불분명한 미러는 제외했다. 유료 표준에 의존하는 주장을 아예 쓰지 않는 방법도 있었지만, 그러면 기능 안전과 사이버보안 주제가 거의 비어 버린다. 그래서 발행기관이 공개한 범위까지라도 인용하기로 했다.
하네스 구성
위키 콘텐츠의 품질을 고르게 유지하려면 사전에 합의된 규칙, 즉 하네스가 필요하다. (앞서 소개한 콘텐츠 파이프라인, 주장 검증 절차도 모두 하네스의 일부분이다.)
하네스 엔지니어링은 에이전트가 똑같은 실수를 반복하지 않도록 지침, 도구, 검사를 고치는 일을 말한다.4 하네스를 작업 방향을 유도하는 가이드(지침, 문서)와 작업 결과를 관찰하는 센서(테스트, 린터, 리뷰)로 나누기도 한다.5
기계적으로 판정되는 규칙은 스크립트가, 읽어보고 판단해야 하는 규칙은 에이전트가 맡았다. 표기 규약과 도해 규약의 규칙 149개 중 스크립트로 판정하는 건 46개(31%)이고, 나머지는 에이전트가 판정한다. 틈틈이 작업 기록을 돌아보며 반복된 실수나 고칠 점을 찾고, 피드백을 통해 스킬과 규칙을 고쳐 나간다.
프로젝트 회고
한 달여 동안 PR만 300개 넘게 병합됐고, Æ wiki는 대략 페이지 400개, 도해 500개, 참고문헌 1,800개, 본문 인용 8,000곳이 됐다. 전체 PR 중 콘텐츠 PR은 40% 정도였고, 나머지는 스킬, 규칙, 검사기, 사이트를 고친 PR이었다.
절차의 효용성
주장 검증 에이전트는 인제스트 단계에서 미검증 주장 1,045개의 게시를 보류했다. 그중 603개(58%)는 재조사를 거쳐 전부 또는 일부 게시됐는데, 사유별로 차이가 컸다.
| 미검증 사유 | 재조사로 게시 |
|---|---|
| 출처와 어긋남 | 10/10 (100%) |
| 접근 실패 | 110/119 (92%) |
| 신뢰할 만한 출처 없음 | 110/155 (71%) |
| 출처 없음 | 238/379 (63%) |
| 유료 출처 (비공개 부분) | 135/382 (35%) |
Reader Testing은 처음에 수율이 낮았다. 주장을 고쳐야 한다고 분류된 356건을 다시 걸러 보니 실제로 고칠 만한 건 47건(13%)이었다. 나머지는 대부분 바람 수준이었다(#537). 분류 기준을 고친 뒤로는 PR 8개에서 800건 남짓을 출처와 대조해 수정했다. 의미를 바꾸지 않는 단순 가독성 개선도 1,000건 넘게 반영했다.
피드백이 하네스에 끼친 영향
처음엔 실수가 나올 때마다 무작정 규칙을 추가했다. 그러자 인제스트 스킬은 첫 2주 사이에 몸집(낱말 수)이 6배로 불었다. 그래서 방향을 바꿨다. 작업 기록에서 두 번 이상 반복되거나 아무 검사에도 걸리지 않고 지나간 실수만 골라냈고, 규칙을 추가하기 전에 기존 규칙으로 충분한지, 스크립트로 옮길 수 있는지부터 따졌다. 규칙을 덜어내는 단계도 넣었다.
피드백을 거듭함에 따라, 인제스트 PR에서 리뷰가 잡아낸 규칙 위반 수가 PR당 4.5개(중간값)에서 2.5개, 1개로 줄었다. 다만 표본이 작고, 에이전트가 덜 틀린 게 아니라 스크립트가 미리 걸러 준 덕일 수도 있기 때문에, 안정됐다고 하기는 아직 이르다.
그래도 작업 기록을 다시 들여다보는 일은 꽤 쓸모가 있었다. CI 실행 기록을 단계별로 나눠 보니 테스트에서 같은 검사를 반복하던 부분이 드러나, 이를 걷어내 검사기 테스트 시간을 125초에서 11초로 줄였다(#327).
지속 가능성
문제는 규칙이 피드백 방향을 바꾼 뒤에도 계속 불어난다는 점이다. 운영 문서는 총 5,500단어 남짓에서 어느새 55,000단어를 넘겼다.
규칙이 많아지자 규칙을 읽고도 지키지 않는 일이 생기기 시작했고, 여러 서브에이전트가 같은 문서를 저마다 읽느라 토큰 비용도 늘었다. 지금은 문서를 더 작은 단위로 분리하여 역할에 따라 필요한 문서만 읽게 바꿨다. 결국 이 위키를 계속 운영할 수 있느냐는 규칙을 얼마나 검사로 옮기고 덜어낼 수 있느냐에 달려 있는 것 같다.
후기
그래서, 믿고 찾아볼 수 있는 기술 지식 위키가 만들어졌을까?
어느 정도는 그렇다. 각 주장을 공개 출처와 대조하여 게시하니, 적어도 해당 내용을 출처까지 따라가 확인할 수 있다. 아무래도 검증 정확도가 100%일 순 없으니, 게시한 뒤에도 재조사, 린트, Reader Testing 같은 절차를 두어 거듭 다시 보게 했다. 다만 위키가 얼마나 쓸만한지는 정량적으로 나타낼 수 없었다. 품질 기준을 무엇으로 삼을 수 있을까?
사람이 할 일이 줄지는 않았다. 하는 일이 바뀌었을 뿐이다. LLM이 콘텐츠를 작성하는 수고를 덜어 준 대신, 내 일은 운영 규칙을 정하고, 에이전트가 올려 보내는 무수한 판단 요청에 답하는 쪽으로 옮겨 갔다. 물론 이건 에이전트로 작업하는 모든 프로젝트에 적용되는 말이긴 하다.
아직 손봐야 할 부분이 이곳저곳 보이지만, 한번에 다 고치려 하기보다는 꾸준히 위키를 운영하면서 점진적으로 개선해 나가고 싶다.
참고 자료
각주
OpenAI 창립 멤버이자 테슬라에서 오토파일럿 AI를 이끌었다. ↩︎
J. Wei et al., “Long-form factuality in large language models,” in Proc. NeurIPS, 2024. [Online]. ↩︎
S. Dhuliawala et al., “Chain-of-Verification Reduces Hallucination in Large Language Models,” in Findings of ACL, 2024, pp. 3563–3578. [Online]. ↩︎
M. Hashimoto, “My AI Adoption Journey,” Feb. 5, 2026. [Online]. ↩︎
B. Böckeler, “Harness engineering for coding agent users,” martinfowler.com, Apr. 2, 2026. [Online]. ↩︎