llm-wiki v2로 마이그레이션

안녕하세요 hcun1004님~새소식통해서도 잠깐 언급드렸었는데 심화 버전 내용 적용 강의는 추후 업데이트 예정입니다. 빠른 시일 내에 준비해서 공지드릴 수 있도록 하겠습니다!

강의 자료가 어디에 있나요?

안녕하세요 두식님~수업노트 하단에 적어둔내용들이 조금 부족했던것 같습니다. 말씀주신 내용들 반영해서, 강의실내에서 다운로드받으실 수 있도록 업데이트해두었습니다.아래 공지 참고부탁드리며, 불편을 겪게 해드려 죄송합니다.https://inf.run/nPNxx개선안은 지금처럼 언제든지 남겨주시면 감사하겠습니다!

front matter 관련 질문

안녕하세요 박시콩님!front matter는 쉽게 말해 문서 맨 위에 붙는 "이 문서에 대한 설명표(라벨)" 라고 생각하시면 됩니다. 마크다운 파일 제일 위에 ---로 감싸서 적는 부분입니다.예를들어 아래처럼요! 본문이 "내용"이라면, front matter는 그 내용을 설명하는 메타데이터(데이터에 대한 데이터)입니다. --- title: 회의록 - 2026 Q2 기획 tags: [meeting, project-a] created: 2026-05-31 status: in-progress ---LLM/에이전트가 문서를 이해하는 단서가 됩니다. 이게 강의 맥락에서 핵심인데요. 본문을 다 읽지 않아도 front matter만 보고 "이 문서는 어떤 종류고, 언제 만들어졌고, 어떤 주제인지" 등등 빠르게 파악할 수 있습니다. ingest나 tag 같은 스킬이 문서를 정리하고 연결할 때 바로 이 front matter를 기준점으로 삼습니다!

오픈클로나 헤르메스 에이전트용으로 사용

안녕하세요 bmf230101님~ 좋은 부분 질문주셨습니다!LLM Wiki 자체가 결국 잘 구조화된 마크다운 지식베이스로 이뤄져있고 말씀하신 방식도 충분히 가능합니다. 그래서 사람이 참고하는 용도뿐 아니라, 에이전트가 참고하는 컨텍스트 소스로도 사용할 수 있는 구조입니다. 현재까지 촬영된 강의는 Wiki를 어떻게 만들고 활용하냐이고, 말씀주신 내용은 이것을 넘어 "Wiki를 에이전트 워크플로우에 어떻게 연결하느냐"로 한 단계 더 나아가는 주제입니다. 구체사례로는 온보딩이나 업무 매뉴얼 참조가 있습니다. Wiki에 회사 내부 프로세스, 용어집, 자주 쓰는 절차 같은 걸 문서로 정리해두고, 에이전트한테 "신규 요청 처리할 때 이 프로세스 문서들을 먼저 읽고 그 규칙대로 진행해줘"라고 연결하는 방식입니다.또한 반복 작업 자동화입니다. 예를 들어 "주간 보고서 작성"이나 "회의록 정리" 같은 반복 업무의 포맷,체크리스트,예시를 Wiki 문서로 만들어두고, 에이전트가 매번 그 가이드를 참조해서 같은 품질로 결과물을 뽑게 하는 거죠. 이부분은 강의에서도 나오긴했는데 요걸 나뿐만 아니라 조직차원에서 쓰게한다면 사내 프로세스로도 정립할 수 있습니다.혹은 컨텍스트 검색 소스로 활용할수있습니다. 태그로 잘 정리된 Wiki는 에이전트가 "이 작업에 필요한 배경 지식이 어디 있지?" 할 때 찾아오는 인덱스로써 활용을 해볼수있습니다. 매번 프롬프트에 모든 정보를 집어넣는대신에 에이전트가 필요할 때 관련 문서를 끌어와서 참고하게 하는 어떻게보면 RAG와 '비슷한' 패턴으로도사용할수있습니다.심화,확장 챕터에서 준비하고있는 내용과 연관이 되어있는데요, 추후 업데이트 챕터에서 따로 다뤄보도록 하겠습니다!

Antigravity, Codex로 제 마음대로 진행하면서

안녕하세요 임찬님 ~ 물론 cli 로 안하시고 desktop app으로도 진행가능합니다. 또한 claude가 아닌 다른 ai를 쓰더라도 llm wiki는 구축이 가능하긴하지만 (llm wiki의 개념은 특정 ai 도구에 한정되는것이 아니기때문) 강의는 claude code기준으로 제작이 되어있어서 요 부분은 참고해주시면 되겠습니다!

pdf도 raw에 가능한가요

안녕하세요 hcun님!이메일은 gmail api사용하셔서 cron등록하셔서 주기적으로 옵시디언쪽으로 떨구게 해볼수는 있구요, 혹은 zapier같은 도구들을 사용하는 방법도 있을거같아요~pdf관련은 제가 기존에 남겼던 답변도 한번 참고해주세요! https://inf.run/UfsnZ

raw 파일이 방대해질 경우

안녕하세요 정원님!수십개정도의 파일은 전혀 문제는 없습니다! 다만 이제 수백, 수천을 넘어갈때가 부하가 조금씩 커질텐데요,1) 방대한 raw 분류는 도메인별로 먼저 가르시는 방법을 먼저 추천드립니다! 예를들어, raw/competitor/, raw/market/, raw/campaign/2) 모든 raw가 영원히 있을 필요는 없습니다. 반감기같은 개념으로 예를들자면, 일시적 트윗 14일, 경쟁사 일상 동향 60일, 시장 리포트 180일 식으로 매월 cron을 통해 자동으로 볼트밖의 archive로 옮기게하는 방법도있습니다. 요런 심화내용들은 제가 곧 강의를 업데이트할 예정이니 조금 더 기다려주세요 🙏 그리고 수집하신 자료들의 신선도를 얼마나 유지할 필요가 있는지 고민해보시면 좋을것같습니다. 단순 일부참고를 하고 주요내용 1~2줄정도만 남기고 다 없어져도 되는내용인가? 그렇다면 정말로 삭제를 고려해보셔도 될것같아요.일단 제일 중요한것은 raw가 쌓이는것보다 wiki가 raw가 쌓이는것만큼 잘 정제가 되가고있느냐입니다. 실제 query를 했을때 원하는 결과가 잘 나오는지도 잘 점검해주세요!

여러기기에서 사용가능한지요?

안녕하세요 수현님 ~넵 당연히 가능합니다. 저도 유료로 싱크를 사용하고있습니다. 각 기기에서 클로드만 띄워두게 되면 공유하는 방식으로 사용이 가능합니다.다만 주의점은, 스케줄같은 자동작업을 양쪽에 걸어두게되면 같은 파일을 건드리면서 꼬일수가있습니다. 요부분만 주의하시면됩니다.추가적으로 유료 싱크말고도 git으로 관리하게되면 한쪽에서 푸시하면, 다른한쪽에서 작업하시기전에 pull한번 받으시고 나서 작업하는 방법도있습니다.

클리핑 이미지 자동 분류 관련

네 정원님! 질문은 계속 주셔도 괜찮습니다!강의에도 언급드렸긴했는데 클리핑하는경우 이미지는 외부 url로 딸려들어와서 실제 파일은 저장이 되지 않을거에요!_attachments에 파일떨어지는 동작을 확인하시려면 아무 이미지나, 스크린샷을 찍어서 마크다운 파일에 한번 올려보시면 확인이 가능하실겁니다!

raw, wiki 하위폴더 관련

네 정원님! 결론부터 말씀드리면 폴더 구조 똑같이 안 가져가셔도 전혀 문제없습니다.사실 이 부분 헷갈리시는 분들 꽤 많은데, 위키 폴더 구조는 정답이 있는 게 아니라 "내가 다루는 도메인이 어떤 성격이냐"에 따라 자연스럽게 달라집니다.그래서 정원님 도메인이 다르면 당연히 다른 폴더가 더 자연스러울 수 있어요. 그리고 ai는 결정적이지 않기때문에 같은 프롬프트를 던지더라도 폴더구조를 다르게 잡아버릴수도있습니다.몇 가지 예를 들어볼게요.인사관리 위키라면 → policies, employees, onboarding, evaluations, compensation마케팅 위키라면 → campaigns, channels, creative-assets개발팀 기술 위키라면 → architecture, postmortems, decisions(ADR)....이런 식으로 본인 업무에서 반복적으로 등장하는 "지식의 종류"를 폴더링 할 수도 있습니다. 정해진 답은 없습니다. 다만 강의에서 나온 폴더의 구성은 강의자료에서 언급드렸던 llm wiki의 정석적인 가이드에 따라 만들어진 것입니다. 진짜 중요한 건 폴더 이름이 아니라 큰 레이어 구조입니다. raw(가공 안 된 원본 자료) → wiki(정리된 지식) -> link (주기적 청소) 의 구조가 살아있다면그 안쪽은 본인 작업 흐름에 맞게 자유롭게 가져가시면 됩니다!