3단계 확장 학습 노트: LLM Wiki와 조직 지식 웹앱의 실제 설계
Deep Dive · RSS 자동화 성공담과 회사 문서 웹앱 구상에서 지식 시스템 설계 원칙을 뽑는다.
커리어해커 AI 네이티브 클럽의 31일 대화는 양은 적지만, 개인 지식관리와 조직 지식관리의 차이를 선명하게 보여준다. 초반에는 패스트캠퍼스 강의를 Codex나 GPT Pro Max로 따라갈 수 있는지, 강의 프롬프트 자료가 어디 있는지 같은 질문이 있었다. 저녁에는 현성님이 Obsidian에서 RSS 파일을 LLM Wiki raw 파일로 변형하고, 30분마다 3개씩 ingest해서 index시키는 워크플로를 성공시켰다고 공유했다. 이어 행복한 춘식이님은 기존에 Obsidian을 쓰고 있었지만 회사 자료까지 통합하려니 웹앱이 필요해졌다고 했다.
1단계 흐름으로 보면, 이 방의 핵심은 “도구를 따라 배우는 사람”에서 “자기 지식 시스템을 만드는 사람”으로 이동하는 장면이다. 누워있는 라이언님은 Claude 강의를 Codex/GPT Pro Max로 적용할 수 있는지 물었다. 이 질문은 매우 현실적이다. 강의는 특정 도구를 기준으로 찍히지만 수강자는 이미 다른 구독과 작업 환경을 갖고 있다. 이때 중요한 것은 명령어 이름을 그대로 따라하는 것이 아니라, 강의가 가르치는 작업 원리를 다른 도구에 옮길 수 있는지다. 프롬프트 자료 구조, 파일 수정 루프, 검증 방식, 작업 분해 방식이 같다면 Claude 중심 강의도 Codex로 상당 부분 이전 가능하다.
2단계 인사이트는 현성님의 사례에서 나온다. 현성님은 비개발자에 가깝다고 말하면서도 3일 동안 붙들고 RSS → raw 파일 → ingest → index 흐름을 만들었다. 이제 유튜브 영상, 기사, 팟캐스트를 올리기만 하면 Markdown 파일로 변형 가능하다고 했다. 이것은 단순 자동화 성공담이 아니다. 콘텐츠 제작자가 자신의 지식 공급망을 직접 만든 사례다. 콘텐츠 제작의 병목은 아이디어가 없어서가 아니라, 봤던 자료를 다시 찾고 엮고 자기 언어로 바꾸는 데 있다. RSS와 LLM Wiki 파이프라인은 외부 정보를 내 콘텐츠 재료로 바꾸는 장치다.
여기서 중요한 설계 원칙은 작은 배치다. 30분마다 3개씩 ingest한다는 방식은 매우 좋다. 자료를 한 번에 몰아넣으면 실패했을 때 어디서 깨졌는지 알기 어렵고, LLM 요약 품질도 흔들린다. 작은 배치는 실패 범위를 좁히고, 품질을 확인하고, 중복을 발견하고, 비용을 예측하기 쉽게 만든다. 지식 시스템은 처음부터 대규모로 만들기보다 작은 ingest 루프를 안정화하는 것이 좋다.
3단계 더 깊게 들어가면 행복한 춘식이님의 회사 문서 웹앱 이야기가 중요하다. 개인 Obsidian은 내가 쓰고 내가 고치면 된다. 하지만 회사 자료가 들어오면 문제가 완전히 달라진다. 누가 볼 수 있는지, 누가 수정할 수 있는지, 오래된 문서는 어떻게 표시할지, 같은 내용의 문서가 여러 개 있을 때 무엇을 기준으로 병합할지, 답변의 출처를 어떻게 보여줄지, 퇴사자나 부서 이동 후 문서 책임자는 어떻게 바뀌는지가 생긴다. 그래서 조직 지식 시스템은 검색창이 아니라 운영 체계다.
Hermes로 유지관리한다는 발상은 흥미롭다. 에이전트를 지식 시스템 운영자로 쓰려면 역할을 구체화해야 한다. 예를 들어 Hermes에게 매일 새 문서를 읽고 중복 후보를 찾게 할 수 있다. 오래된 문서에 “검토 필요” 표시를 붙이게 할 수 있다. 프로젝트명과 사람 이름을 엔티티로 추출하게 할 수 있다. 문서마다 요약, 소유자, 마지막 검토일, 관련 문서를 업데이트하게 할 수 있다. 하지만 최종 삭제나 정책 변경은 사람이 승인해야 한다. 에이전트는 편집자 보조자이지 조직의 진실을 단독으로 결정하는 존재가 아니다.
LLM Wiki 파이프라인을 직접 만든다면 단계는 이렇게 나누는 것이 좋다. 첫째, 수집 계층: RSS, 유튜브, 기사, 팟캐스트 URL을 모은다. 둘째, 원문 계층: HTML, transcript, metadata를 가능한 한 원본에 가깝게 저장한다. 셋째, 정규화 계층: Markdown으로 바꾸고 제목, 날짜, 출처, 저자, 태그를 붙인다. 넷째, 요약 계층: 짧은 요약, 긴 요약, 인용 가능한 핵심 문장을 만든다. 다섯째, 색인 계층: 검색과 RAG를 위해 chunk와 embedding을 만든다. 여섯째, 재가공 계층: 블로그, 영상 스크립트, 강의안, 사내 문서로 변환한다. 이 계층을 섞으면 나중에 품질 문제가 생겼을 때 고치기 어렵다.
강의 도구 호환성도 같은 관점이다. Claude 강의를 Codex로 따라갈 수 있는지 묻는다면, “명령어가 같나?”보다 “입력과 출력 계약이 같나?”를 봐야 한다. 강의가 요구사항을 파일로 저장하고, 단계별 계획을 만들고, 테스트를 돌리고, diff를 리뷰하는 방식이라면 Codex에서도 구현 가능하다. 반면 Claude 전용 MCP, Claude Code slash command, 특정 memory 구조에 강하게 의존한다면 그대로 옮기기 어렵다. 따라서 수강자는 강의 자료를 볼 때 도구 전용 문법과 일반 작업 원리를 구분해 표시해두는 것이 좋다.
이 방의 학습 결론은 분명하다. 개인 지식 시스템은 “자료를 모으는 자동화”에서 시작하지만, 오래 쓰려면 “운영 가능한 지식 구조”로 가야 한다. 조직 지식 시스템은 더더욱 그렇다. 검색이 잘되는 것만으로는 부족하다. 최신성, 책임자, 권한, 출처, 중복, 재검토가 있어야 한다. AI 에이전트는 이 운영을 도울 수 있지만, 운영 규칙이 없으면 오히려 더 많은 혼란을 빠르게 생산한다.
추가 워크북 1: 개인 LLM Wiki를 만들 때 가장 먼저 해야 할 일은 “무엇을 넣을지”보다 “왜 다시 꺼낼지”를 정하는 것이다. 콘텐츠 제작자라면 영상 스크립트, 쇼츠 아이디어, 뉴스레터 초안, 강의안으로 다시 꺼낼 수 있어야 한다. 회사원이라면 회의록, 정책 문서, 고객 이슈, 제품 결정 근거로 다시 꺼낼 수 있어야 한다. 목적이 다르면 chunk 크기, 태그, 요약 형식, 검색 UI가 달라진다. 목적 없이 자료를 많이 넣으면 두 번째 뇌가 아니라 두 번째 창고가 된다.
추가 워크북 2: RSS ingest는 좋은 시작점이지만, 원문 품질을 반드시 확인해야 한다. 기사 본문이 잘렸는지, 광고 문구가 섞였는지, 유튜브 transcript가 자동 자막이라 오류가 많은지, 팟캐스트 화자 구분이 되는지에 따라 요약 품질이 달라진다. LLM Wiki 파이프라인에는 원문 품질 점수를 넣는 것이 좋다. 예를 들어 source_quality를 high, medium, low로 두고, low 자료는 최종 콘텐츠에 바로 쓰지 않고 사람이 확인하게 한다. 이렇게 해야 자동화가 품질을 망치지 않는다.
추가 워크북 3: 30분마다 3개 ingest하는 방식은 운영적으로 매우 좋은 선택이다. 작은 배치는 실패 복구가 쉽고 비용 예측이 된다. 여기에 더해 queue 상태를 보이는 대시보드를 만들면 좋다. 대기 중, 처리 중, 실패, 검토 필요, 게시 가능 같은 상태를 나누면 LLM 자동화가 검은 상자가 되지 않는다. 비개발자에게도 이 상태 구분은 중요하다. “자동으로 됩니다”보다 “여기까지 자동이고 여기서 검토하세요”가 훨씬 오래 간다.
추가 워크북 4: 회사 자료 웹앱은 개인 지식관리와 완전히 다르다. 조직에서는 틀린 답변보다 출처 없는 답변이 더 위험하다. 따라서 검색 결과나 AI 답변에는 원문 링크, 문서 소유자, 마지막 수정일, 신뢰도, 관련 문서가 함께 나와야 한다. 오래된 문서를 최신 문서보다 위에 보여주면 사고가 난다. 같은 정책이 두 문서에 다르게 적혀 있으면 둘 중 하나를 폐기하거나 우선순위를 표시해야 한다. 이것은 UI 문제가 아니라 거버넌스 문제다.
추가 워크북 5: Hermes를 문서 유지관리자로 쓰려면 작업을 작게 쪼개야 한다. “우리 회사 문서를 관리해줘”는 너무 크다. 대신 “오늘 추가된 문서에서 제품명과 고객사명을 추출해줘”, “90일 넘게 수정 안 된 문서를 찾아줘”, “같은 제목의 문서를 후보로 묶어줘”, “이 답변의 근거 문서를 3개만 보여줘”처럼 시켜야 한다. 그리고 삭제, 병합, 정책 변경은 사람이 승인한다. 이 구조가 있으면 에이전트는 지식 운영 보조자가 되고, 구조가 없으면 잘못된 확신을 빠르게 퍼뜨리는 도구가 된다.
추가 워크북 6: 강의 도구 호환성은 수강자가 반드시 배워야 하는 메타 스킬이다. Claude 강의에서 배운 것을 Codex로 옮길 때는 화면과 명령어를 그대로 찾지 말고, 작업 단계를 추출한다. 요구사항 정리, 파일 탐색, 계획, 구현, 테스트, 리뷰, 배포 확인 중 어떤 단계인가. 그 단계가 Codex에서는 어떤 명령과 습관으로 대체되는가. 이렇게 보면 특정 도구 강의가 다른 도구에서도 살아난다. 반대로 이 구분을 못하면 도구 UI가 조금만 바뀌어도 학습이 무너진다.
추가 워크북 7: 개인 지식 시스템을 오래 쓰려면 “버리는 규칙”도 필요하다. 모든 자료를 영원히 저장하면 검색 품질이 떨어지고 요약 비용이 늘어난다. 6개월 동안 다시 쓰지 않은 자료, 출처가 불분명한 자료, 중복 요약, 이미 더 좋은 문서로 대체된 자료는 archive나 cold storage로 보내야 한다. LLM Wiki의 목표는 많이 저장하는 것이 아니라 다시 쓸 수 있는 지식을 유지하는 것이다.
추가 학습 질문: 이 대화를 내 업무에 옮긴다면 무엇을 먼저 바꿀 것인가. 첫째, 지금 내가 반복해서 설명하거나 복사해 붙이는 작업을 하나 고른다. 둘째, 그 작업의 입력과 출력 예시를 3개씩 모은다. 셋째, 실패 사례를 일부러 적는다. 넷째, AI가 처리할 부분과 사람이 승인할 부분을 나눈다. 다섯째, 다음 실행 때 결과가 좋아졌는지 확인할 기준을 만든다. 이 다섯 단계를 거치면 오픈채팅에서 본 도구와 링크가 단순 정보가 아니라 내 작업 시스템을 바꾸는 재료가 된다.
추가 학습 질문: 좋은 자동화와 나쁜 자동화의 차이는 무엇인가. 좋은 자동화는 사람이 보던 판단 기준을 숨기지 않고 드러낸다. 나쁜 자동화는 “AI가 알아서 했다”고 말하면서 근거와 실패 가능성을 감춘다. 좋은 자동화는 실패했을 때 어디서 깨졌는지 알 수 있다. 나쁜 자동화는 실패해도 원인을 찾을 수 없다. 좋은 자동화는 작은 단위로 다시 실행할 수 있다. 나쁜 자동화는 전체를 처음부터 다시 돌려야 한다. 따라서 AI 도구를 붙일 때는 성공 화면보다 실패 화면을 먼저 설계해야 한다.
추가 학습 질문: 커뮤니티 대화에서 사람을 어떻게 읽을 것인가. 링크를 많이 공유하는 사람은 레이더 역할을 한다. 실제 경험담을 말하는 사람은 운영 지식을 제공한다. 질문을 던지는 사람은 시장의 불편함을 드러낸다. 농담이나 실패담을 말하는 사람도 중요하다. 그 안에 모델의 실제 결함, 작업 환경의 마찰, 초보자가 막히는 지점이 들어 있기 때문이다. 리포트의 목표는 모든 발언을 동등하게 요약하는 것이 아니라, 이 역할들을 구분해 학습 가능한 신호로 바꾸는 것이다.
추가 학습 질문: 다음 날 같은 주제가 반복된다면 무엇을 추적할 것인가. MCP는 도구 연결에서 운영 안정성으로 가는지, LLM Wiki는 개인 지식관리에서 조직 지식관리로 가는지, Claude/Codex 환경 논의는 모델 성능에서 작업대 설계로 가는지, 콘텐츠 자동화는 생성에서 검수 파이프라인으로 가는지 추적한다. 하루치 리포트가 쌓이면 단순 뉴스 요약이 아니라 커뮤니티의 관심 이동 그래프가 된다.
커리어해커 AI 네이티브 클럽에 적용하면, 다음 관찰 포인트는 “비개발자의 자동화 성공 조건”이다. 현성님 사례처럼 3일을 붙잡고 끝내는 사람에게는 거대한 프레임워크보다 작은 성공 루프가 중요하다. 자료 하나가 들어와 Markdown이 되고, 검색되고, 콘텐츠 초안으로 나오는 전체 흐름을 눈으로 확인해야 한다. 이 방의 리포트는 앞으로 성공담을 단순 축하로 끝내지 말고, 어떤 시행착오를 거쳤고 어떤 구조가 재사용 가능한지 추출해야 한다.
추가 심화: 현성님의 RSS 자동화 사례를 콘텐츠 제작 워크플로로 바꾸면 다음과 같다. 매일 아침 RSS에서 후보 자료가 들어온다. 시스템은 원문을 저장하고, 제목·출처·날짜·저자·주요 키워드를 붙인다. 그 다음 짧은 요약과 긴 요약을 만든다. 짧은 요약은 훑어보기용이고, 긴 요약은 스크립트 재료다. 이후 제작자는 후보 자료 중 3개를 골라 “오늘의 주제”로 묶는다. LLM은 세 자료의 공통 질문, 충돌하는 주장, 추가 조사할 링크를 뽑는다. 이렇게 하면 자료 수집 자동화가 바로 콘텐츠 기획 자동화로 이어진다.
추가 심화: 회사 문서 웹앱을 만든다면 첫 화면은 검색창 하나로 충분하지 않다. 사용자는 “내가 지금 뭘 믿어도 되는지”를 알아야 한다. 그래서 문서 카드에는 제목, 요약, 소유자, 마지막 검토일, 신뢰 상태, 관련 프로젝트, 원문 링크가 있어야 한다. AI 답변에는 반드시 근거 문서가 붙어야 하고, 근거 문서가 오래되었으면 답변 상단에 경고가 떠야 한다. 사내 지식 시스템에서 가장 위험한 것은 답을 못 하는 것이 아니라 오래된 답을 자신 있게 하는 것이다.
추가 심화: 비개발자가 이런 시스템을 만들 때 가장 좋은 전략은 “완성 앱”보다 “운영 가능한 작은 루프”다. 첫 주에는 RSS 5개를 Markdown으로 바꾸는 것만 한다. 둘째 주에는 태그와 요약을 붙인다. 셋째 주에는 검색을 붙인다. 넷째 주에는 내가 만든 콘텐츠와 연결한다. 다섯째 주에는 회사 자료나 팀 문서로 확장한다. 이 순서가 중요한 이유는 각 단계마다 품질을 확인할 수 있기 때문이다. 처음부터 웹앱, 로그인, 권한, RAG, 그래프를 모두 넣으면 실패 원인을 찾기 어렵다.
추가 심화: 강의 프롬프트 자료를 찾는 질문도 그냥 운영 이슈가 아니다. 강의 상품은 영상만으로 완성되지 않는다. 프롬프트, 예제 파일, 체크리스트, 오류 대응 문서, 도구별 대체 명령이 함께 있어야 한다. Claude 강의를 Codex로 따라가려는 수강자가 있다면, 강의 제공자는 “Claude 전용”, “Codex에서 대체 가능”, “원리만 참고” 같은 표시를 해줄 수 있다. 이것이 있으면 강의 하나가 특정 도구 사용법을 넘어 AI 작업 방법론으로 확장된다.