지식 베이스 만드는 법: 문서, 검색, 권한, AI 답변

지식 베이스는 답을 찾을 수 있는 검색 가능한 자료실입니다. 무언가를 하는 방법, 무언가를 고치는 방법, 규정이 무엇인지에 대한 답이 들어 있습니다. 이것을 만들려면 몇 개의 분명한 카테고리로 묶인 문서, 작성자가 실제로 쓸 편집기, 사람들이 실제로 입력하는 단어로 알맞은 문서를 찾아주는 검색, 그리고 누가 무엇을 읽을 수 있는지에 대한 결정이 필요합니다. 공개 대상인지, 로그인한 고객인지, 직원만인지를 정해야 합니다. AI 앱 빌더는 짧은 작업 세션만으로 구조, 편집기, 검색을 만들어 낼 수 있습니다. 지식 베이스를 쓸모 있게 만드는 것은 글쓰기와 지속적인 관리이므로, 첫날부터 쉬운 편집과 오래된 문서를 찾아내는 기능을 염두에 두고 설계하세요.

먼저 대상을 정하세요

같은 기능이라도 매우 다른 사이트에 쓰입니다.

• 공개 도움말 센터 — 고객과 잠재 고객을 위한 것입니다. 빨라야 하고, 검색 엔진이 색인할 수 있어야 하며, 고객의 언어로 쓰여야 합니다.
• 고객 전용 문서 — 로그인 뒤에 있으며, 유료 고객이나 파트너를 위한 것입니다.
• 내부 지식 베이스 — 직원을 위한 정책, 프로세스, 사용 방법입니다. 반드시 비공개여야 하며, 디자인보다 검색과 최신성이 더 중요합니다.

한 사이트에 공개 문서와 내부 문서를 섞어 두는 것이 대부분의 정보 유출이 일어나는 지점입니다. 둘 다 필요하다면 문서마다 공개 범위를 분명히 설정하거나, 사이트를 두 개로 나누세요.

앱에 필요한 것

데이터

두 필드가 많은 일을 합니다. 담당자(누가 이 문서를 정확하게 유지하는지)와 마지막 검토 일시(누가 마지막으로 여전히 사실임을 확인했는지)입니다. 이 둘을 함께 쓰면 6개월 동안 아무도 확인하지 않은 문서를 목록으로 뽑아 볼 수 있습니다.

페이지

• 독자용: 검색과 카테고리가 있는 홈, 카테고리 페이지, 목차와 관련 문서, "도움이 되었나요?" 질문이 있는 문서 페이지.
• 편집자용: 필터(초안, 오래된 문서, 평점이 낮은 문서)가 있는 문서 목록, 미리보기가 있는 편집기, 수정 기록.
• 관리자용: 카테고리, 사용자와 역할, 결과가 없었던 검색에 대한 보고서.

권한

독자는 볼 수 있도록 허용된 게시 문서만 봅니다. 편집자는 문서를 만들고 수정하며, 경우에 따라 특정 카테고리로 제한됩니다. 관리자는 게시, 보관, 사용자 관리를 합니다. 내부 지식 베이스라면 모든 사람이 로그인해야 하고, 공개 도움말 센터라면 작성자만 로그인하면 됩니다.

결정 사항과 트레이드오프

편집기: 마크다운 또는 리치 텍스트

마크다운은 빠르고 이식성이 좋으며 버전 기록과 잘 맞지만, 일부 작성자는 어색하게 느낍니다. 제목, 목록, 이미지, 강조 상자, 코드 블록이 있는 리치 텍스트 편집기는 익숙하게 느껴집니다. 무엇을 고르든, 나중에 내보낼 수 있는 형식으로 내용을 저장하세요.

검색

제목, 요약, 본문을 검색하고 제목 일치를 더 높은 순위에 두는 기본적인 데이터베이스 텍스트 검색이면 문서가 수백 개일 때는 충분합니다. 그보다 많거나, 오타와 동의어가 중요하다면("invoice"와 "bill") 제대로 된 전문 검색이나 호스팅형 검색 서비스를 사용하세요. 검색 추가 가이드에서 선택지를 살펴봅니다. 결과가 없었던 검색어는 모두 기록하세요. 무료로 얻는, 써야 할 문서 목록입니다.

AI 답변

문서에서 답을 주는 "질문하기" 상자는 이제 흔합니다. 관련성 높은 단락을 찾아서, 그 단락만을 근거로 답하도록 언어 모델에 요청하는 방식으로 작동합니다. RAG가 무엇인지를 참고하세요. 항상 출처 문서를 보여 주고, "모르겠습니다"라는 답을 허용하며, 문서에 있는 오래된 내용은 자신 있게 그대로 반복된다는 점을 기억하세요. 문서가 잘 정리된 뒤에 만들고, 그 전에는 만들지 마세요.

버전 관리와 검토

누가 무엇을 바꿨는지 보고 되돌릴 수 있도록 수정 기록을 남기세요. 규제가 걸린 내용(인사 정책, 안전 절차)이라면 변경이 게시되기 전에 승인 단계를 추가하세요.

효과가 있는 첫 프롬프트

Parcelly를 위한 공개 도움말 센터를 만들어 줘. Parcelly는 작은 온라인 쇼핑몰을 위한 배송 라벨 앱이야. 홈페이지에는 큰 검색창과 여섯 개의 카테고리(시작하기, 라벨 인쇄, 운송사, 청구, 반품, 문제 해결)가 있어야 해. 문서에는 제목, 요약, 이미지와 강조 상자가 있는 마크다운 본문, 카테고리, 태그, 상태(초안, 게시됨, 보관됨), 담당자, 마지막 검토 날짜가 있어야 해. 문서 페이지에는 목차, 관련 문서, "도움이 되었나요?"라는 예/아니요 질문과 선택적 댓글 입력란이 보여야 해. 검색은 제목, 요약, 본문을 대상으로 하고 제목 일치를 먼저 보여 주며, 모든 검색어와 결과 유무를 기록해. 편집 영역(로그인 필요, 역할은 편집자와 관리자)에서는 초안, 180일 동안 검토되지 않은 문서, 도움이 되었다는 점수가 낮은 문서를 목록으로 보여 주고, 수정 기록을 유지해. 각 문서는 검색 엔진을 위해 고유한 페이지 제목과 메타 설명을 가져야 해. 깔끔하고 차분하며 읽기 쉬운 디자인으로, 모바일을 우선으로 만들어 줘.

구축 단계

1. 무엇이든 만들기 전에 실제 고객지원 질문을 바탕으로 처음 문서 20~30개의 목록을 작성하세요. 이 목록이 카테고리를 정합니다.
2. 사이트를 생성하고 휴대폰에서 읽기 편한지 확인하세요. 줄 길이, 제목, 이미지를 봅니다.
3. 편집기와 역할. 작성자는 개발자에게 묻지 않고도 문서를 추가하고 고칠 수 있어야 합니다.
4. 검색을 만든 다음, 오타를 포함해 고객이 실제로 쓰는 단어로 테스트하세요.
5. 피드백과 검색 로깅.
6. 담당자와 마지막 검토 일시를 기준으로 한 오래된 문서 보고서.
7. 공개 사이트를 위한 SEO 기본 설정: 고유한 제목과 설명, 깔끔한 URL, 사이트맵. AI로 만든 웹사이트의 SEO를 참고하세요.
8. 제품과 고객지원 답변에 링크를 연결한 다음, 결과 없음 로그를 매주 확인하세요.
9. 내용이 탄탄해지면 AI 답변을 추가하세요.

흔한 실수

• 독자가 하려는 일이 아니라 부서별로 구성하기.
• 다섯 가지 작업을 다루는 긴 문서. 문서 하나에 작업 하나만 두고, 제목에 무엇을 해결하는지 쓰세요.
• 문서마다 담당자가 없음. 아무도 내용을 갱신하지 않고, 첫 번째 틀린 답변 이후 신뢰가 떨어집니다.
• 공개 문서에 내부 메모 넣기. 공개 범위를 따로 설정하고, 게시하기 전에 검토하세요.
• 제목만 검색하는 검색. 독자는 문서 이름이 아니라 증상을 입력합니다.
• 대체 텍스트나 설명 없는 스크린샷. 금방 낡아지므로, 단계를 글로도 함께 설명하세요.

기성 제품이 더 나은 경우

팀이 이미 문서나 위키 도구를 쓰고 있다면, 그곳의 내부 지식 베이스가 보통 가장 부담이 적은 길입니다. Notion vs Confluence 비교에서 흔한 두 가지 선택지를 다룹니다. 헬프데스크 제품을 쓰고 있다면, 기본 제공되는 도움말 센터가 문서를 티켓과 연결하고 고객에게 문서를 추천해 주는데, 이를 그대로 재현하기는 어렵습니다. 코드와 함께 두는 개발자 문서에는 문서 사이트 생성기가 이상적입니다.

자체 구조나 권한이 필요할 때(클라이언트별, 위치별, 역할별 문서), 별도 사이트가 아니라 제품 안에 지식 베이스를 두고 싶을 때, 위키가 강제하지 못하는 검토와 승인 단계가 필요할 때, 또는 다른 구독 없이 내 콘텐츠 위에서 AI 답변을 원할 때 직접 만드세요. 이것은 맞춤형 헬프데스크와 자연스럽게 함께 쓰입니다.

Mythex로 만들기

Mythex에서는 채팅으로 지식 베이스를 설명하면 라이브 미리보기에서 만들어집니다. 문서, 수정 기록, 피드백은 에이전트가 필요할 때 추가하는 Postgres 데이터베이스에 저장되고, 이미지는 프로젝트의 파일 저장소에 들어갑니다. 편집자 로그인은 직접 고르는 인증 방식을 사용합니다. Mythex에는 기본 제공되는 최종 사용자 로그인이 없기 때문입니다. AI 답변에는 프로젝트 시크릿으로 저장한 자신의 AI 제공업체 API 키를 사용하며, 사용량은 Mythex 크레딧이 아니라 제공업체 계정에 청구됩니다(AI 레시피). 새 Mythex 앱은 기본적으로 클라이언트에서 렌더링되는 React 싱글 페이지 앱이며, 이는 검색 엔진에 약합니다. 따라서 공개 도움말 센터라면 정적 호스팅에 적합하거나 Next.js처럼 서버에서 렌더링되는 설정을 요청하세요(SEO 레시피).

시작 프롬프트는 제품 지식 허브 또는 팀 문서 앱 템플릿으로 시도해 보세요.

자주 묻는 질문