고객 서비스용 지식 기반: FAQ가 부족한 이유

간단 요약: 고객 서비스를 위한 지식 기반은 회사에서 검토한 고객 질문에 대한 답변을 한 번 작성하여 도움말 센터(help centre), 채팅, 양식, 받은 편지함, 고객 포털 등 모든 채널에서 사용하는 것입니다. FAQ는 한 페이지에 있는 짧은 답변 목록입니다. 지식 기반은 소유자, 검토, 버전, 그리고 공개 및 내부 콘텐츠에 대한 권한을 가지며 측정됩니다. 이것이 일관된 답변과 우연에 의한 답변의 차이점입니다.

업데이트: 2026년 10월 3일

온라인 소매업체나 매주 수백 건의 티켓을 처리하는 서비스 회사의 고객 서비스를 운영하는 사람이라면 이 패턴을 알고 있습니다. 배송, 반품, 인보이스에 대한 동일한 질문이 매일 돌아오고, 답변은 누가 그 티켓을 맡느냐에 따라 달라집니다. 사이트의 FAQ가 이를 해결해야 하지만, 질문은 계속해서 들어옵니다. FAQ와 지식 기반의 차이는 크기가 아닙니다. 그것은 지식이 어떻게 소유되고, 검토되며, 사용되는지입니다.

고객 서비스용 지식 기반이란 무엇인가?

지식 기반은 고객이 실제로 묻는 질문에 대한 수집되고, 검토되고, 검색 가능한 답변들의 집합이며, 한 번 작성되어 에이전트(agent), 도움말 센터 또는 AI 등 모든 사람이 사용합니다. 각 문서는 하나의 질문에 답하며, 소유자, 버전, 그리고 누가 볼 수 있는지에 대한 결정 사항을 가집니다.

지식 기반과 제품 문서화(product documentation)를 구분하는 것은 시작점입니다. 문서화는 제품에서 시작됩니다: 이 반품 포털이 어떻게 작동하는가와 같습니다. 지식 기반은 질문에서 시작합니다:

주당 300건의 티켓을 처리하는 소매업체의 경우, 제한된 수의 질문이 보통 대부분의 문의량을 차지합니다. '제 소포는 어디에 있나요?'라는 기사는 추적(tracking) 방법, 소포 이동이 멈췄을 때 발생하는 일, 고객이 조치를 취하기 전에 얼마나 기다려야 하는지, 그리고 상담원이 약속할 수 있는 내용 등을 다룹니다. 마지막 부분은 내부용입니다. 나머지는 공개용입니다.

따라서 문서 아카이브가 지식 기반(knowledge base)은 아닙니다. 만약 같은 질문에 대한 세 가지 다른 답변이 있다면, 아무도 어떤 것이 적용되는지 알지 못하며, 동일한 자료로 작동하는 AI는 오류를 더 빠르게 확산시킵니다.

FAQ만으로는 충분하지 않은 이유

FAQ가 충분한 경우는 질문이 적고, 답변이 짧으며, 웹페이지에서 그것들만을 사용하는 경우입니다. Nielsen Norman Group은 잘 만들어진 FAQ도 방문자에게 실질적인 가치를 제공하지만, 그 가치는 유지되고 사람들이 실제로 묻는 것을 반영하는지에 달려 있다고 지적합니다. 바로 이 지점에서 문의량이 증가할 때 문제가 발생합니다.

문제는 형식이 아니라 그것을 둘러싼 구조의 부족입니다. 이는 자가 학습(self-learning) FAQ에도 적용되며, Supportifier와 Humany 비교에서 보여주듯이 그렇습니다. FAQ는 일반적으로 질문별 소유자가 없고, 무엇이 변경되었는지에 대한 기록도 없으며, 고객이 볼 수 있는 내용과 상담원이 알아야 하는 내용을 구분하지 못하고, 한 곳에 존재합니다. 반품 정책이 변경되면 FAQ가 업데이트될 수는 있지만, 이메일 템플릿, 챗봇의 자료, 그리고 상담원 개인의 메모는 그 변화를 따라가지 못합니다.

지식 기반은 무엇으로 구성되나요?

작동하는 지식 기반(knowledge base)은 여섯 가지 부분으로 이루어져 있으며, 이 부분이 바로 FAQ가 갖지 못한 요소들입니다.

1. 각 기사는 하나의 질문에 답합니다. 제목은 고객이 묻는 질문이며, 답변이 먼저 오고 그 뒤에 단계와 예외 사항이 옵니다. 또한 해당 기사에서는 답변의 근거가 되는 규칙이나 출처를 명시하여 확인할 수 있습니다.
2. 소유자(Owners). 모든 기사 또는 주제 영역에는 내용의 정확성을 책임지는 담당자가 있습니다. 반품 관련 내용은 반품을 잘 아는 사람이, 송장 질문은 재무 부서가 소유합니다.
3. 검토(Review). 작성자 외 다른 사람이 읽지 않으면 어떤 기사도 게시되지 않으며, 모든 기사는 다음 검토 날짜를 가지고 있습니다.
4. 버전(Versions). 무엇이, 언제, 누구에 의해 변경되었는지 확인할 수 있으며, 문제가 생겼을 때 이전으로 돌아갈 수도 있습니다. 또한 "3월에 고객에게 뭐라고 말했었지?"라는 질문에 답할 수 있게 해줍니다.
5. 권한(Permissions). 공개 콘텐츠는 모든 사람에게 보입니다. 우수 거래 한도(goodwill limits), 에스컬레이션 경로(escalation paths) 및 예외 처리 방법과 같은 내부 콘텐츠는 팀원만 볼 수 있습니다. 일부 기사는 로그인한 고객이나 특정 계약에만 적용될 수도 있습니다.
6. 측정(Measurement). 어떤 기사가 읽혔는지, 어떤 검색이 아무것도 반환하지 못했는지, 그리고 기사가 존재함에도 불구하고 계속해서 질문이 들어오는지를 파악합니다. 마지막 경우는 '지식 격차(knowledge gap)'라고 불리는데, 승인된 답변 없이 반복되는 질문이나 작동하지 않는 답변을 가진 질문입니다. 이를 찾는 방법은 지식 격차에 대한 기사에서 설명합니다.

지식 기반(Knowledge Base)에 포함되지 않아야 할 것은 무엇인가요?

고객 자체의 데이터는 지식 기반에 속하지 않습니다. 청구서가 어떻게 결제되는지 설명할 수는 있지만, 이 고객의 청구서가 이미 결제되었는지 여부는 알 수 없습니다. 그러한 최신 정보는 적절한 권한을 가진 연결을 통해 비즈니스 시스템에서 가져와 일반 규칙과 분리하여 보관되어야 합니다.

따라서 공개된 아티클에는 실제 고객과 연결될 수 있는 예시가 절대 포함되어서는 안 됩니다. 그리고 팀이 예외를 평가하는 방법에 대한 내부 지침이라 하더라도, 같은 지식 기반에 있다는 이유만으로 고객 답변이 되는 것은 아니며, 권한(permissions)이 무엇을 보여줄지 결정합니다.

도움말 센터, 채팅, 폼, 받은 편지함, 고객 포털에서 동일한 지식이 어떻게 사용되나요?

지식 기반의 목적은 하나의 답변을 작성하여 고객이 어떤 채널을 선택하든 표시되는 것입니다. 각 채널은 동일한 아티클로 다른 작업을 수행합니다.

• **도움말 센터(help centre)**는 공개된 아티클을 보여주며, 고객뿐만 아니라 Google과 AI 어시스턴트가 검색할 수 있습니다. 아티클이 어떻게 발견되는지는 도움말 센터 및 검색에 관한 아티클에서 설명합니다.
• **채팅(chat)**은 승인된 아티클의 답변을 제공하며, 답변이 없는 경우 추측하는 대신 담당자에게 연결합니다.
• **폼(form)**은 고객이 티켓을 제출하기 전에 예상되는 답변을 보여줍니다. 이로 인해 일부 티켓은 아예 전송될 필요가 없어집니다.
• **받은 편지함(inbox)**은 고객이 보지 못하는 내부 부분까지 포함하여, 아티클 기반으로 작성된 초안을 담당자에게 제공합니다.
• **고객 포털(customer portal)**은 아티클과 주문 및 계약 같은 고객 자체의 데이터를 결합하여, 특정 소포에 대해

이것이 바로 Supportifier 플랫폼이 구축되는 방식입니다. 하나의 지식 기반(knowledge base)과 다섯 개의 인터페이스를 통해, 온보딩 과정에서 자료를 구조화하고 팀이 검토합니다. 콘텐츠에 대한 책임은 여전히 귀하에게 있으며, 이 원칙은 어떤 도구를 사용하든 동일하게 적용됩니다. 업계가 주목하는 것은 지식 노동(knowledge work) 자체가 하나의 역할로 자리 잡고 있다는 점입니다. 2026년 2월 가트너 설문조사에 따르면, 고객 서비스 리더의 91%가 AI를 구현해야 한다는 경영진의 압박을 받고 있으며, 58%는 AI와 셀프서비스(self-service) 모두 정확하고 최신 콘텐츠에 의존하기 때문에 상담원들을 지식 관리 전문가로 역량 강화할 계획입니다.

Salesforce의 여섯 번째 '서비스 현황 보고서(State of Service report)'에서도 비슷한 그림이 나타납니다. 이 보고서는 서비스 조직들이 AI를 사용하여 요약, 제안 답변 및 지식 문서를 생성하는 방식을 설명합니다. AI는 결코 자신이 답을 얻는 자료보다 더 나을 수 없습니다.

기존 자료로 어떻게 시작할까요?

이미 대부분의 콘텐츠를 가지고 있지만, 그것들은 여기저기 흩어져 있습니다. 이메일 템플릿, 티케팅 시스템의 매크로, 내부 문서, 제품 페이지, 그리고 무엇보다 지난 12개월간의 티켓에 존재합니다. 할 일은 처음부터 작성하는 것이 아니라, 수집하고, 선택하고, 재작성하는 것입니다.

티켓 기록(ticket history)이 가장 좋은 출발점입니다. 왜냐하면 고객들이 실제로 어떤 질문을 하는지, 그들의 언어로 보여주기 때문입니다. 지난 몇 달간의 티켓들을 시스템 카테고리가 아닌 질문별로 그룹화하고 개수를 세어보세요. 먼저 해당 티켓들이 이 목적에 사용될 수 있는지 확인하고, 공개되는 답변은 일반적인 내용으로 만드세요. 목록은 예상보다 짧을 것이며, 그 상단 부분이 바로 첫 번째 지식 기반이 됩니다. 지식 분석(knowledge analysis) 기능은 더 큰 범위의 자료에 대해 이러한 작업을 체계적으로 수행합니다.

답변이 달라지는 지점(그리고 거의 항상 그렇듯이)에서는 기사를 작성하는 사람이 아니라 해당 주제를 아는 전문가가 무엇이 적용되는지 결정해야 합니다. 그런 다음 초안을 실제 고객 질문에 테스트해 보세요.

콘텐츠를 재작성할 때 가장 중요한 규칙은 다음과 같습니다. 최고의 상담원이 고객에게 답변하듯이 답변을 작성하고, 상담원은 알아야 하지만 고객에게 보여서는 안 되는 내용은 내부 섹션에 넣는 것입니다. 이렇게 하면 모든 사람이 동일한 기사를 사용할 수 있습니다.

FAQ 페이지는 여전히 좋은 공개 진입점 역할을 할 수 있습니다. 이는 고객에게 지식 기반의 답변 중 일부를 보여줍니다.

무엇을 해야 하는가

이것은 아무것도 구매하지 않고 이번 주에 수행할 수 있습니다.

1. 티켓 시스템 또는 받은 편지함에서 최근 500개의 티켓을 가져옵니다.
2. 각 티켓에 질문의 내용(예: "택배는 어디에 있나요", "주문 취소", "청구서가 틀렸습니다")을 평이한 단어로 태그합니다.
3. 개수를 셉니다. 가장 많은 양의 상위 10개 질문을 선택합니다.
4. 각 질문에 대해 이미 제공했던 최고의 답변을 찾습니다. 이는 발송된 메일에 있습니다.
5. 질문당 하나의 기사를 작성합니다. 제목은 질문으로 하고, 먼저 답변을 제시하고, 그 뒤에 예외 사항을 추가하며, 팀을 위한 내부 섹션을 만듭니다.
6. 각 기사에 담당자를 지정하고 다음 검토 날짜를 설정합니다.
7. 각 기사별로 공개할 부분과 내부용 부분을 결정합니다.
8. 공개되는 부분은 도움말 센터에 게시하고, 이메일 템플릿을 기사 텍스트로 교체하여 모든 채널에서 답변이 동일하게 유지되도록 합니다.
9. 30일 후에 후속 조치를 취합니다. 질문이 여전히 들어오는지, 그리고 고객들이 답장에서 무엇을 말하는지 확인합니다.

그 후 채팅이나 받은 편지함에서 지식을 사용하고 싶다면, 하나의 사용 사례부터 시작하세요. 팀이 자주 답변하는 질문을 워크스루(아래 예약)로 가져오는 것을 주저하지 마세요.

일반적인 질문

지식 기반(knowledge base)과 도움말 센터(help centre)는 같은 것인가요?

아닙니다. 헬프 센터(help centre)는 고객이 기사를 읽는 공개 웹사이트입니다. 지식 기반(knowledge base)은 그 뒤에 있는 콘텐츠와 구조를 의미하며, 고객이 절대 볼 수 없는 내부 자료까지 포함합니다. 헬프 센터는 채팅(chat), 양식(forms), 받은 편지함(inbox), 고객 포털(customer portal) 등 여러 표면 중 하나에서 지식 기반을 활용하는 것입니다. 회사는 공개 헬프 센터 없이도 지식 기반을 가질 수 있지만, 좋은 방식으로서는 그 반대의 경우는 거의 없습니다.

시작하려면 몇 개의 기사가 필요할까요?

생각보다 적습니다. 티켓(ticket) 처리량의 가장 큰 비중을 차지하는 열 개에서 스무 개의 질문으로 시작하여 이를 제대로 작성하세요. 정확하고, 소유하며, 검토된 답변을 가진 작은 지식 기반이 아무도 관리하지 않는 백 개의 기사보다 더 많은 도움이 됩니다. 그 이후에는 기사가 존재함에도 불구하고 여전히 들어오는 질문들을 보면서 확장해 나가세요.

누가 지식 기반을 소유해야 할까요?