윈도우 사용자입니다.

안녕하세요 kwangtwo3님! 윈도우 이슈는 강의노트에 일부 보강을 해두긴했는데요, 혹시 어느부분에서 막혔는지 구체적으로 말씀주실 수 있으실까요? 수강에 어려운점이 있다면 team.pragdev@gmail.com 로 말씀주시면 제가 해결드릴 수 있는 점들은 도움바로 드릴 수 있도록 하겠습니다!

엔터프라이즈 환경에서의 Obsidian 활용 아키텍처 전략

안녕하세요 대박단백질님~기업차원의 도입을 고려하고 계시군요. 결론부터 말씀드리면, 저는 옵시디언을 전사 도입하는 방향 자체를 권하지 않습니다. 옵시디언은 어디까지나 개인 단위의 지식 도구고, 말씀하신 rbac이나 데이터 파편화 문제는 옵시디언 위에 뭔가를 얹어서 해결될 성격이 아니라고 생각합니다.범용 챗봇이 아니라 사내 데이터소스를 물고 있는 에이전트를 직접 구현을 하고 rbac도 단순 문서단위가 아닌 검색레이어를 별도로 구축하여 운용해야합니다. 문서들도 임베딩할수있는 vectordb류를 사용을하고 도메인전문가와 개발자들이 협업하여 중앙저장소를 구축을 하구요.위내용은 단순 개인지식관리의 옵시디언을 넘어서는 내용이라 일단은 요정도로 답변드릴 수 있을것같습니다!

클로드 스킬 관련

안녕하세요 참다랑이님!넵 옵시디언 sync를 하시면 볼트내 모든 파일들이 다 싱킹이 될것이기때문에 .claude파일들도 같이 들어가게 될겁니다. .claude내의 skill 폴더들이 같이 동기화될거기때문에 모두 사용가능하실거구요, 혹여나 user scope 로 스킬을 만드신경우에는 루트경로에 skill들이 저장이 되어있을거라 같이 안딸려올텐데요, 요부분만 project scope로 옮겨달라고 클로드에게 요청하시면 옮겨줄겁니다. 참고로 sync를 하지않고 git으로 관리를하셔서 github private으로 운영을 하셔도 동일한 효과를 얻으실 수 있을겁니다! 저는 이력관리차원에서 대부분 github으로 운영을 하고있습니다.

입력을 쉽게하는 방법이 궁금합니다.

안녕하세요 을지로봇님!raw 폴더는 완성해서 넣는 곳이 아니라 '일단 던져 놓는' 곳입니다. 형식이 지저분해도, 문장이 반토막이어도 괜찮습니다. 정제는 나중에 /ingest가 하니까요.1) 모바일에서 웹 자료를 넣을 때Web Clipper는 모바일에서도 되긴 하는데 조건이 있을겁니다. Safari나 Firefox, 크롬등에서 브라우저 자체가 확장을 허용하지 않는경우가 있어서 Web Clipper를 설치할 수 없을수있습니다. 그래서 단순히 링크만 복사해서 넣어놨다가 나중에 ingest시에 그 링크를 참조해서 실제 본문을 긁어서 가져오는 방식을 사용해야될수도있을거같네요!2) 모바일에서 떠오른 생각을 그냥 텍스트로 넣을 때Obsidian 모바일 앱에 vault만 연결돼 있으면, 커스텀 툴바나 커맨드 팔레트에 "raw에 새 노트 생성"을 등록해두고 한두 번 탭으로 바로 적으실 수 있을거같습니다.3) 음성 메모를 raw로 넣을 때오디오 파일 자체를 raw에 그냥 넣어두는 방법이 제일 간단할거같은데요, 단축어로 음성 녹음 → vault의 raw 폴더에 저장, 나중에 pc에서 정리하는 흐름이 됩니다. 혹은 넣는순간 바로 텍스트로 바꾸는 방법이 있을것같습니다. (모바일 실시간 전사), 전 ios를 사용중인데 내장된 기본앱에서 녹음을 하고 바로 버튼하나 누르면 전사하는 기능이 있긴하더라고요. 요걸로 바로 텍스트 복사해서 던져놓으면 될것같습니다.저도 이 부분은 좋은 조합을 찾는 중이라, 혹시 직접 만들어보신 흐름이 있으면 공유해주시면 감사하겠습니다.오늘도 평안한 하루 보내세요. 좋은 질문 감사합니다 :)

tag 스킬의 필요성

안녕하세요 을지로봇님! 좋은 질문 감사합니다 :)말씀하신 대로 강의에서 소개한 Obsidian Clipping으로 클리핑하면 tag가 함께 저장되기 때문에, 그런 경우엔 보통 따로 전처리할 필요가 없습니다.다만 raw는 말 그대로 정말 "raw한" 데이터라서, 다양한 소스를 그대로 넣게 됩니다. 저 같은 경우엔 PDF 내용을 복사해서 넣거나, 각종 메신저방에서 오간 내용을 복붙해서 넣는 경우도 많은데요. 이런 자료들은 대부분 일회성이라 제가 직접 손으로 복붙해서 넣게 됩니다. 그리고 이렇게 수동으로 넣을 때는 tag를 달기가 어렵습니다.(몇가지 활용한 예시를 말씀드리면 회의록을 던지거나, 챗봇과의 대화기록, 손으로쓴 아이디어나 대략 메모해뒀던 내용들의 조각, 이메일, 특정 채팅방의 대화기록 등등 다양합니다)넣는 시점에 tag를 일일이 수동으로 달려면 시간도 오래 걸리고, 자료마다 "이건 무슨 태그를 달지?" 하는 판단을 한 번씩 거쳐야 하거든요. 그래서 이럴 때는 일단 raw에 다 쏟아 넣은 뒤에, tag 스킬로 raw 단계의 태깅 작업을 먼저 한 번에 처리해 주는 겁니다.이렇게 미리 태깅을 해두면 두 가지 이점이 있습니다. 첫째, 나중에 wiki로 ingest할 때 분류와 정리가 훨씬 깔끔하게 됩니다. 둘째, "태깅"과 "ingestion"이라는 작업을 분리해서 각 세션이 하나의 작업에만 집중할 수 있게 됩니다.한 세션에 작업을 집중시키는 게 중요한 이유는 결국 wiki ingestion의 품질 때문입니다. 우리가 query를 던지면 그 답은 wiki 안에서 만들어지기 때문에, wiki의 품질을 최상으로 유지하는 게 핵심이거든요. 태깅이 어수선하게 섞인 상태로 한꺼번에 ingest하는 것보다, raw 단계에서 미리 정돈해두고 ingest에만 집중하는 쪽이 결과물의 품질을 훨씬 높여줍니다.정리하면, Clipping처럼 tag가 자동으로 딸려오는 자료는 전처리가 필요 없지만, 직접 복붙해서 넣는 raw 자료의 경우 tag 스킬로 한 번 정돈해주면 ingestion 품질과 작업 효율이 모두 올라간다고 보시면 되겠습니다.혹시 질문이 해결되지않았다면 다시 말씀주시구요!

5강때 초보가 겪었던 어려움 공유 (극복완료)

안녕하세요 eunice lim님!아이고 첫 설치에서 난항을 겪으셨군요 😭 윈도우환경에서의 고충을 제가 생각을 못했던거같습니다. 위 게시글은 윈도우를 사용하시는 다른 수강생분들에게도 도움이 될만한 내용이라고 생각되어 강의내 참고자료로 링크해두겠습니다. 같이 학습하시는 분들께 도움을 주셔서 감사드리며 team.pragdev@gmail.com 으로 메일하나 보내주세요. 소정의 보답을 드리도록 하겠습니다.

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와 '비슷한' 패턴으로도사용할수있습니다.심화,확장 챕터에서 준비하고있는 내용과 연관이 되어있는데요, 추후 업데이트 챕터에서 따로 다뤄보도록 하겠습니다!