WorkBuddy와 텐센트 러샹으로 지식베이스 활용하기

이것은 창허(苍何)의 600번째 오리지널 글입니다!

안녕하세요, 저는 창허입니다.

저는 지난달에 제가 WorkBuddy + Codex로 개인 지식 베이스를 구축한 방법을 공유한 적이 있습니다.

많은 분들의 호응을 받았고, 적지 않은 분들이 댓글로 자신의 구축 실천 사례와 고민을 공유해 주셨습니다.

그중 어떤 분은 제가 했던 방식의 지식 베이스 구축이 팀 사용도 지원하느냐고 물으셨습니다.

개인 지식 베이스는 자신의 습관을 중심으로 구축하면 됩니다. 하지만 팀 시나리오나 기업 시나리오로 가면 자료가 여러 곳에 흩어져 있을 때 어떻게 취합할지, 버전이 일치하지 않으면 어느 것을 믿어야 할지, 어떤 내용을 누구에게, 어떤 Agent에게 읽게 할 수 있는지도 고려해야 합니다.

그래서 저는 팀 사용에 적합한 지식 베이스를 찾아보았고, 텐센트 러샹(腾讯乐享)도 제가 쓰고 있는 WorkBuddy에 연동할 수 있다는 것을 발견했습니다. 마침 정리해야 할 자료가 있는 프로젝트가 있어서 그것으로 시험해 보았습니다.

프로젝트를 처음 시작할 때는 일단 기능부터 만들자는 생각만 했고, 문서는 나중에 쓰려고 했는데 계속 미루게 되었습니다.

최근 WeSight를 유지보수하면서 바로 그런 느낌을 받았습니다. 기능이 점점 많아질수록 페이지 하나를 고치거나 문제 하나를 찾으려 해도 먼저 코드를 뒤지고 자료를 찾아야 합니다. AI에게 시켜도 처음부터 다시 검색해야 합니다.

WeSight는 제가 만들고 있는 오픈소스 데스크톱 AI Agent 프로젝트로, Claude Code, Codex 등의 코딩 Agent를 하나의 시각화된 워크벤치에 넣는 것입니다.

제 이 프로젝트는 이미 제품 정의, 기술 아키텍처, 디자인 소재, 사용자 피드백을 동시에 포함하고 있습니다. 기업에 놓으면 이런 자료들은 제품, 연구개발, 고객지원, 영업 등 여러 부서에 흩어지게 됩니다.

통일된 지식 출처가 없으면 서로 다른 Agent가 각자 정보의 일부만 가져오기 쉽고, 심지어 이미 만료된 버전을 계속 인용하기도 합니다.

이 기간 동안 저는 텐센트 러샹으로 이 프로젝트의 자료를 정리해 보았습니다. 러샹은 Agent를 위한 기업용 AI 지식 베이스 한 세트로, 저는 기술 문서, 디자인 소재, 사용자 피드백을 넣은 다음 Agent가 이 자료들을 가지고 계속 일하게 했습니다.

이번에는 러샹이 하나의 프로젝트 지식을 받아들여, Agent가 이해할 수 있는 구조로 가공하고, 그 출처와 상태를 지속적으로 관리하며, 권한에 따라 WorkBuddy의 실제 작업에 적용할 수 있는지 검증해 보고 싶었습니다.

먼저 WorkBuddy에서 러샹 지식 베이스를 연동해, 로컬 프로젝트를 정리하게 했습니다.

요구 사항은 아주 직접적이었고, 러샹의 Agent가 자율적으로 라이브러리를 만들고 분류 정리를 진행했습니다.

●●●제 프로젝트 WeSight를 위해 프로젝트 문서 한 부를 정리해서 러샹 지식 베이스에 동기화해 주세요. 이 프로젝트를 분류별로 정리해야 합니다.

정리가 끝나니 모두 다섯 개의 라이브러리로 나뉘었습니다: 제품과 비즈니스, 기술과 엔지니어링, 디자인과 규범, 운영과 성장, 그리고 팀 규범과 신입 매뉴얼.

비즈니스 용도에 따라 분류한 후, 각종 프로젝트 자료는 명확한 소속을 갖게 되었습니다. 주로 저 혼자 유지보수하더라도 통일된 구조에 따라 문서를 찾고, 보충하고, 갱신할 수 있습니다.

예를 들어 기술 라이브러리에 있는 이 개발 가이드는 아키텍처 설명과 자주 쓰는 명령어를 한데 정리했고, 내용이 리포지터리의 어느 파일에서 왔는지도 표기했습니다. 확인할 때는 원문을 다시 보면 됩니다.

제가 더 마음에 들었던 것은, 이전에 반복적으로 조정했던 그 인터페이스 스크린샷들도 함께 담겼다는 점입니다. 오른쪽에는 이미지 내용에 대한 설명도 있습니다.

다음에 페이지를 어떻게 바꿀지 논의할 때 이 자료들을 바로 인용할 수 있습니다. 그렇지 않으면 "예전에 봤던 그 버전"을 찾는 것만으로도 한참을 뒤져야 할 때가 있습니다.

여기까지 오니 프로젝트 안의 텍스트와 이미지가 공통의 입구를 갖게 되었고, 분류, 출처, 설명도 보완되었습니다. 이제 Agent가 다시 조회하더라도 적어도 시작할 곳이 생겼습니다.

프로젝트 자료 정리가 끝났지만, 매일 증가하는 또 한 가지 종류의 내용이 있습니다: 사용자 피드백입니다.

사람들은 그룹에서 문제를 이야기하고, 누군가는 버그를 신고하고, 누군가는 제안을 합니다. 같은 일이 며칠 뒤에 다시 언급되기도 합니다. 개발을 배치할 때가 되면 채팅 기록을 다시 뒤지는 것이 꽤 힘듭니다.

그래서 저는 WorkBuddy에 자동화 작업을 하나 구성했습니다: 매일 제품 그룹의 피드백을 수집해 러샹의 운영과 성장 라이브러리에 기록하고, 저녁 8시에 저에게 보고합니다.

이 흐름에서 WorkBuddy는 정기 실행, 도구 간 데이터 수집, 결과 생성을 담당하고; 러샹은 팀 지식 저장, 자료 간의 관계와 권한 유지, 그리고 다음 작업에 신뢰할 수 있는 컨텍스트를 제공하는 것을 담당합니다.

●●●당신은 기업 위챗(企业微信) 그룹의 제품 사용 피드백을 전문적으로 수집하는 Agent입니다. 수집한 문제를 러샹의 운영과 성장 라이브러리에 축적하고, 지식 정리를 잘 해두며, 매일 저녁 8시에 저에게 보고하세요.

여기서 WorkBuddy는 정기 실행을 담당하고, 러샹은 정리된 자료를 보관합니다. 작업에는 지식 베이스를 연동해야 하고, 기업 위챗 접근도 미리 설정해야 합니다. 어떤 기록을 읽을 수 있는지는 계정 권한에 달려 있습니다.

아래의 것들이 바로 날짜별로 남겨진 기록입니다.

팀과 기업이 함께 사용할 때는 자료의 접근 경계도 주의해야 합니다. Agent가 러샹 지식을 호출할 때는 현재 사용자의 지식 권한 제약을 받습니다; 서로 다른 구성원이 같은 작업을 시작해도 호출할 수 있는 자료 범위가 다를 수 있습니다. 이것이 제가 늘 가졌던痛点(페인 포인트)와 걱정을 해결해 주었습니다.

피드백을 받아들인 뒤, 저는 한 걸음 더 나아가 시험해 보았습니다.

사용자가 "쓸 수 없다"고 하는 것이, 이미 알려진 문제인지, 아니면 한 번도 겪지 못한 새로운 문제인지? 개발 문서에서 이미 분석한 적이 있다면 처음부터 다시 확인하는 것은 아깝습니다.

그래서 저는 Agent에게 두 곳을 동시에 조회하게 했습니다: 운영 라이브러리의 사용자 피드백, 그리고 기술 라이브러리의 아키텍처 설명과 알려진 문제입니다.

프롬프트에서는 사용자 원문을 남기고, 대응하는 기술 문서를 찾아 문서명을 쓰며; 기록을 찾지 못한 것은 '검증 대기'로 표시하라고 특히 강조했습니다.

전체 프롬프트는 글 말미에 두었습니다. 먼저 이 결과를 보겠습니다.

예를 들어 이 두 가지 피드백 중, 하나는 기록을 찾아볼 수 있고, 다른 하나는 재현해야 합니다.

하나는 "IM 수동 중지 후 새 메시지가 표시되지 않거나 지연이 높음"입니다. 보고서는 《07 IM 채널 대화 중지 후 메시지 상태 이상 분석》을 찾아냈고, 개발 라이브러리에 기록이 있어 뒷받침되는 문제로 표시했습니다. 이어서 이 문서를 따라 이전에 어디까지 분석했는지 볼 수 있습니다.

다른 하나는 Apple Silicon 기기에서 0.9.3 버전 최초 실행 시 흰 화면이 나타나는 것입니다. 이 항목은 "개발 라이브러리에 기록 없음, 재현 필요"로 표시되었습니다.

여기까지 보면, 적어도 다음에 각각 무엇을 해야 할지 알 수 있습니다: 하나는 기존 분석을 먼저 확인하고, 다른 하나는 먼저 재현 방법을 찾는 것입니다. 또한 노이즈 정보를 따로 분류해 주어 제가 계속 필터링하기 편했습니다.

이것은 문제를 길게 나열하는 것보다 제가 다음 처리를 하기에 더 편리합니다. 진짜 원인을 제대로 찾았는지, 수정이 효과를 볼 수 있는지는 나중에 검증해야 합니다.

제가 이해하는 지식 거버넌스는 대략 이런 세부 사항들에 구현됩니다: 어느 문장에 출처가 있는지, 어느 결론이 아직 확인되지 않았는지, 어떤 자료를 계속 보충해야 하는지. 이것들을 명확히 구분해야 이후의 Agent가 비교적 명확한 근거를 가질 수 있습니다.

앞의 IM 메시지 이상 건은 사용자 피드백과 하나의 과거 분석을 연결합니다. 이런 연결이 남을 수 있다면, 다음에 비슷한 문제를 만났을 때 관련 자료를 따라 찾을 수 있습니다.

러샹의 지식 그래프도 같은思路(사고방식)입니다: 먼저 기계가 자료 간의 연관을 정리하고, 그다음 업무에 익숙한 사람이 확인합니다.

프로젝트는 계속 바뀌고, 문서도 따라 갱신되어야 합니다. 예를 들어 Bug가 이미 수정되었는데 라이브러리에는 아직 "미해결"로 적혀 있으면, 다음에 조회할 때 오판하기 쉽습니다.

저는 러샹이 LLM Wiki를 통해 흩어진 원본 자료를 AI가 이해하고 호출하기에 더 적합한 Wiki로 재구성하는 것을 탐색하고 있음을 발견했습니다; 프로젝트 내용이 변할 때는 나아가 신구 지식 간의 차이를 식별하고 갱신 제안을 하여, 지식이 계속 프로젝트 진행을 따라갈 수 있게 합니다.

저는 WeSight 프로젝트의 관련 자료를 선택해 러샹의 LLM Wiki에 구축을 맡겼습니다. 그것은 기존 문서에서 주제와 관계를 추출한 뒤, 서로 연관된 Wiki 페이지 한 세트로 다시 정리합니다. 얼마 후, 제가 본 결과는 다음과 같습니다

저는 많은 LLM wiki를 체험해 보았습니다. 러샹과 workbuddy의 결합은 "문서 반감기" 문제를 해결할 수 있고, 폐쇄 루프의 지식 환류와 유지보수 메커니즘을 갖추고 있습니다. 프로젝트는 영원히 반복 발전하고, 지식 베이스의 가장 큰痛点(페인 포인트)는 영원히 "쓰는 순간 낡아진다"는 것입니다. 쓸만한 시스템은 반드시 우리가 앞서 언급한 순찰 메커니즘 같은 것을 갖추어야 합니다—코드와 업무 변화를 감지하고, 사람에게 대조 확인을 안내하거나, Agent가 검증한 뒤 최신 결과를 다시 라이브러리에 역기록할 수 있어야 합니다. 스스로 갱신할 수 있는 지식 베이스라야 장기적인 생명력을 가질 수 있습니다. 마침 러샹은 이 방면에서 매우 기발한 아이디어가 있습니다.

앞의 보고서는 개발 배치를 보조하는 데 쓸 수 있습니다. 더 나아가, 지식 베이스에 연동된 코딩 Agent가 자료를 찾고, 문제 재현을 시도하고, 검증된 결과를 다시 기록하게 할 수 있습니다. 이 흐름은 더 계속 발전시킬 여지가 있습니다.

여기서는 실제 개발을 하나 예로 들어 보겠습니다.

팀이 커뮤니티 피드백을 받았습니다: "Windows 클라이언트가 특정 시스템 환경에서 간헐적으로 흰 화면/충돌이 발생한다". 예전에는 개발할 때 원인을 찾기 위해 과거 PR, 위챗 그룹 채팅 기록, 아키텍처 문서를 여기저기 뒤져야 해서 매우 시간이 많이 들었습니다.

●●●우리는 Windows 플랫폼에서 간헐적 충돌 문제를 겪었습니다. 현재 러샹 지식 베이스에 축적된 Electron 아키텍처, Windows 플랫폼 적응 문서, 그리고 과거 Issue 기록을 결합하여, 충돌을 일으킬 수 있는 원인을 조사하고 최소 재현 절차를 제시해 주세요.

Agent가 조사思路(사고방식)와 재현 코드를 출력

완전한 조사 보고서(대략적으로 왜 충돌하는지, 그리고 충돌의 원인이 무엇인지 설명하는 내용.)

문제 재현과 수정 결과가 검증된 후, Agent는 결론을 지식 갱신 제안으로 정리할 수 있습니다; 확인을 거친 뒤 다시 러샹에 역기록하여 다음 조사에 근거를 제공합니다.

이어서 저는 또 라이브러리 안의 자료로 로드쇼 PPT를 하나 만들어 보았습니다.

제품 소개, 기술 자료, 인터페이스 스크린샷이 모두 라이브러리에 있으니, 이것으로 초안을 하나 만들게 하면 되겠다고 생각했습니다:

●●●저희 이 제품을 가지고 로드쇼를 하려고 합니다. 지식 베이스 안의 내용을 결합해서, 제품의 핵심 하이라이트를 부각한 PPT를 만들어 주세요.

실행 과정을 보면, 그것은 먼저 제품 포지셔닝, 기술 아키텍처, 기능 특성 등의 자료를 찾았습니다.

아래는 그중 두 페이지입니다. 표지에는 WeSight의 제품 포지셔닝을 사용했고, 기능 페이지에는 대화 인터페이스와 실시간 작업 영역을 함께 배치했습니다.

솔직히 말하면, 러샹 LLM Wiki 방식으로 만든 로드쇼 PPT는 Agent의 조회가 더 정확해졌음을 발견했고, 효과가 제가 이전에 만든 것보다 훨씬 좋았습니다.

이번에 이래저래 해 보면서 가장 유용했던 것은 역시 피드백 검증 단계였습니다. 이미 분석이 있는 것은 문서를 따라 계속 조회할 수 있고; 아직 기록되지 않은 것은 먼저 남겨두고 조사하면 됩니다.

자료 정리에도 초기 비용이 들고, 생성된 결과도 직접 봐야 합니다. 하지만 프로젝트를 반복해서 수정하고 사용자 피드백을 처리하는 저 같은 사람에게는, 이런 기록들을 먼저 남겨두면 나중에 확실히 편리합니다.

여러분과 팀도 채팅 기록과 기술 문서 사이를 자주 오가며 무언가를 찾는다면, 이 흐름을 참고할 수 있습니다. 먼저 짧은 기간의 피드백과 대응 문서를 가지고 한 번 시험해 보고, 그것이 찾아낸 근거가 맞는지 본 다음, 더 많은 업무에 쓸지 결정하면 됩니다.

전체 프롬프트는 아래에 두었습니다, 자신의 프로젝트에 맞게 고치면 됩니다.

아래는 이번에 사용한 전체 피드백 분석 프롬프트입니다. 재사용할 때는 프로젝트명, 지식 베이스명, 문서명을 자신의 실제 내용으로 바꾸고, Agent가 상응하는 접근 권한을 갖추었는지 확인하세요.

●●●# Role당신은 선임 제품 전문가(CPO) 겸 애자일 연구개발 책임자로, 실제 사용자 피드백에서 사용자 심리를 통찰하고 기술 개발 문서와 결합해 교차 검증 및 근본 원인 확인을 잘합니다. # Task【운영과 성장 라이브러리】의 WeSight 프로젝트 사용자 채팅 기록을 완전히 불러와 분석하고, 동시에 【기술과 엔지니어링 라이브러리】(특히 "05 알려진 문제와 성능 검증" 및 관련 기술 아키텍처/인터페이스 문서를 중점 대조)를 교차 라이브러리 검색하세요. 엄밀한 사용자 심리 분석 프레임워크에 따라 요구를 추출하고, 개발 라이브러리 지식과 교차 확인하여, 최종적으로 실행 지침의 의미를 갖춘 분석 보고서 한 부를 생성하세요. # AnalysisCriteria(분류 및 판정 기준)문제를 분류할 때 다음 논리에 따라 엄격히 구분하세요:1. 【긴급 조사】(P0/Blocking): 사용자 핵심 경로 사용을 방해하거나, 고빈도 불만, 데이터 이상 또는 보안 위험을 초래하는 경우, Bug로 확인되었는지 여부와 무관하게 기술이 즉시介入(개입)하여 조사·위치 파악해야 합니다.2. 【결함 Bug】: 기존 기능 성능이 설계 기대와 불일치, 콘솔 오류, 인터페이스 이상, 프런트엔드 표시 오류, 또는 개발 라이브러리에 이미 "알려진 결함/수정 대기"로 명확히 기록된 문제.3. 【경험 최적화】: 기능 자체는 사용 가능하나, 인터랙션 경로가 번거롭거나, 로딩 지연이 높거나, 문구가 모호하거나, 사용자 인지 습관에 맞지 않는 개선 항목.4. 【신규 요구】: 사용자가 기대하지만 현재 제품이 전혀 커버하지 못하는 능력, 비즈니스 시나리오 확장 또는 새로운 통합 형태. # StrictGroundingRules(엄밀성 및 출처 추적 제약)- **사실 근거 원칙** : 반드시 사용자의 원문 조각을 "원본 피드백 증거"로 항목별 추출해야 하며, 요약하거나 허구로 만들면 안 됩니다.- **교차 검증 요구** : 각 문제는 【기술과 엔지니어링 라이브러리】에서 대응 기록을 찾았는지 명확히 해야 합니다:- 개발 라이브러리에서 확인된 경우: 대응 문서명, 알려진 원인 또는 현재 상태를 명시합니다.- 개발 라이브러리에 기록되지 않은 경우: "개발 라이브러리 미수록/기술 검증 대기"로 표시하고, 가능한 조사 방향을 제시하며, 명확히 "가정"으로 표시해야 하고, 확인된 원인으로 취급하면 안 됩니다.- **사용자 심리 추출** : "사용자가 무엇을 말했는지"만 기록하는 것이 아니라, "사용자의 근본 기대와 좌절감의 원천이 무엇인지"(예: 실시간성에 대한 불안감, 설정 장벽에 대한 거부감 등)를 더 추출해야 합니다. # OutputFormat다음 세 부분에 따라 엄격히 보고서를 출력하세요: ## 一、사용자 심리와 페인 포인트 전경 통찰1. **핵심 심리 특징** : 현재 사용자의 제품에 대한 전반적 기대와 인지 편차를 요약합니다(2-3가지).2. **고빈도 좌절감 집중 지점** : 사용자가 어느 단계에서 이탈하거나 불만을 가장 많이 표출하는지. ## 二、문제 검증과 분류 처리 매트릭스 표| 우선순위 | 분류 | 문제 설명 | 사용자 근본 심리/좌절 근원 | 운영 라이브러리 원문 증거 | 개발 라이브러리 검증 결론 (문서/상태)| 제안 처리 방안/조사 방향 ||:---|:---|:---|:---|:---|:---|:---||P0/P1/P2| 긴급 조사/Bug/최적화/신규 요구 |...|...|"...사용자 원문..."| 【입증됨】문서명+원인 / 【미기록】조사 필요 |...| ## 三、최근 스프린트(Sprint) 행동 제안- 즉시 조사(Top3):- 빠른 출시 최적화 항목(QuickWins):- 제품 기획 풀(Backlog 후보):

창허(苍何)

Java 개발/기술 리더 @앤트 그룹(蚂蚁集团)

315

글

246k

조회수

571

팬