팀의 지식 베이스를 Slack, Feishu, DingTalk에 연결하는 방법 (2026)

질문과 답변이 서로 다른 애플리케이션에 존재합니다

이것이 문제의 전부이며, 매우 흔한 일입니다. 질문은 채팅 클라이언트에서 이루어지는 사회적 행위입니다. 반면 문서를 찾아보는 것은 브라우저 탭에서 이루어지는 고독한 행위입니다. 동료에게 물어보는 데는 메시지 한 통이면 되지만, 위키를 확인하려면 컨텍스트 스위칭(맥락 전환), 검색, 그리고 아무것도 찾지 못할 위험을 감수해야 합니다.

문서는 페이지를 보여줄 뿐, 질문에 답하지 않습니다

아무리 잘 관리된 지식 베이스라도 결국 문서를 반환합니다. 독자는 페이지를 훑어보고, 해당 단락을 찾고, 그것이 여전히 유효한지 판단한 다음, 눈앞의 상황에 맞는 답변으로 직접 해석해내야 합니다.

이 단계는 계획 단계에서는 보이지 않지만 실제로는 엄청난 비용이 들며, "그거 문서에 있어요"라는 말과 매달 똑같은 질문이 올라오는 현상이 아주 자연스럽게 공존하는 이유이기도 합니다. 정보는 존재하지만, 답변으로 조립되지 않은 상태입니다. 검색(Retrieval)과 메모리(Memory)는 서로 다른 작업이며, 이 차이점은 RAG가 메모리가 아닌 이유에서 자세히 다루고 있습니다.

채팅 플랫폼의 검색 범위는 해당 플랫폼 내부로 제한됩니다

Slack은 이 분야에 투자해 왔으며, 문서화된 범위 내에서 잘 작동합니다. Slack의 표현을 빌리자면, AI 기능은 "워크스페이스의 지식을 기반으로" 합니다. 답변은 "검색 결과를 일일이 뒤지는 대신 Slack의 관련 정보를 기반으로" 하며, "답변의 바탕이 된 소스 메시지나 파일을 참조하는 인용구도 포함"됩니다.

지식이 다른 곳에 있을 때 중요한 두 가지 제약 사항이 있습니다. 첫째는 요금제에 따른 가용성입니다. 자동 검색 필터는 Pro 요금제 이상부터 제공되며, 검색 답변 기능은 Business+ 및 Enterprise+ 요금제에서 제공됩니다. 둘째는 검색 대상이 사용자가 접근할 수 있는 콘텐츠로 제한된다는 점입니다. "AI가 생성한 답변에는 귀하가 액세스할 수 있는 정보(공개 채널의 메시지 및 기타 콘텐츠, 귀하가 속한 비공개 채널 및 다이렉트 메시지 등)만 포함됩니다."

외부 정보에 접근하는 것은 별개의 기능입니다. "Enterprise+ 요금제를 사용하는 경우, 조직 소유자 또는 관리자가 엔터프라이즈 검색을 활성화하여 Google Drive, GitHub 등 다른 소스의 콘텐츠와 정보를 검색 결과에 포함할 수 있습니다." 이는 합리적인 설계이지만, 동시에 왜 여러분의 채팅 앱 어시스턴트가 문서 시스템에 있는 런북(runbook)을 인용하지 못하는지에 대한 이유이기도 합니다.

채팅으로 공유되는 자료는 가장 맥락이 풍부하지만 가장 지속성이 낮습니다

대부분의 워크스페이스에서 가장 유용한 자료들은 채팅창에 업로드됩니다. 에러 스크킨샷, 서명된 PDF, 누군가 자정에 새로 만든 스프레드시트 등이 그렇습니다. Slack은 이러한 파일들을 동일한 이력 보존 기간 내에 포함합니다. "파일에는 클립, PDF, 문서, 이미지, 스크린샷, 오디오 및 비디오 파일 등이 포함됩니다." 무료 버전의 경우 "지난 90일 동안의 메시지와 파일만 보고 검색할 수 있으며", "1년 이상 된" 데이터는 삭제됩니다.

결국 팀 지식의 가장 풍부한 레이어가 가장 영속성이 낮은 곳에 머물게 되며, 어떤 위키 업데이트도 이를 포착하지 못합니다. 붙여넣은 스크린샷을 문서라고 생각하는 사람은 아무도 없기 때문입니다.

모두의 개인 어시스턴트는 개인적인 컨텍스트만 가집니다

사람들이 임시방편으로 선택하는 방법은 개인 AI 구독 서비스를 이용하는 것입니다. 배경 정보를 복사해 붙여넣고 답변을 얻는 방식이죠. 이는 한 사람에게 단 한 번만 작동합니다. 컨텍스트가 개인 계정에만 머물기 때문에 공유 공간에는 아무것도 쌓이지 않습니다. 이러한 단절은 지식 근로자를 위한 도구 간 메모리에서, 그리고 조직 규모에서의 문제는 엔터프라이즈 AI의 망각에서 설명하고 있습니다.

모든 채널에 핸드북 링크 고정하기. 비용은 들지 않지만, 결국 컨텍스트 스위칭으로 끝납니다. 고정된 메시지는 아무도 관리하지 않는 목록이 되기 십상입니다.

#handbook 또는 공지 채널 운영하기. 지식 베이스를 피드 형태로 바꾸는 것이지만, 피드는 게시된 당일에 온라인 상태였던 사람들만 한 번 읽고 지나치게 됩니다.

채팅 이력 검색 봇 도입하기. 유용하지만 채팅 범위로 제한됩니다. 한 번도 게시된 적 없는 문서의 내용에는 답할 수 없습니다.

모든 팀원에게 개인 AI 구독권 구매해주기. 개인의 업무 처리량은 늘려주지만, 팀의 지식은 제자리에 머물게 합니다. 지원(Support) 팀이 이를 뼈저리게 느끼며, 이 패턴은 어시스턴트가 지원 티켓을 잊어버릴 때에서 다루고 있습니다.

지식 담당자 지정하기. 때로는 올바른 방법일 수 있지만, 문제를 해결하기보다는 한 사람의 일정에 실패 요인을 집중시키는 결과를 낳기도 합니다.

관점을 전환해야 합니다. 사람들을 지식 베이스로 이동시키려 하지 말고, 지식 베이스를 그룹 채팅방으로 가져오세요. 구체적으로는 범용 모델의 일반적인 지식이 아닌, 지정된 메모리 본문에서 답변하고 각 대화 내용을 다시 동일한 위치에 기록하는 채널 내 봇을 의미합니다.

이 후반부 작업이 단순한 채팅 인터페이스의 검색창과 이 방식을 구분 짓는 핵심입니다. MemoryLake의 IM 연결에서는 대화 내용이 메모리가 되므로, 누군가 일정을 잡고 억지로 문서를 작성하는 대신 팀원들이 실제로 던지는 질문을 통해 말뭉치(corpus)가 성장합니다. 설정은 3단계로 진행되며, 플랫폼 간의 차이점은 모두 2단계에 있습니다.

1단계: IM 연결 추가

콘솔에서 MemoryLake → Workspaces를 열고, 메모리를 노출할 워크스페이스를 연 다음, IM 탭으로 전환하여 플랫폼을 선택합니다. 시작하기 전에 두 가지 전제 조건이 있습니다. 일반 멤버는 "연동을 보거나 변경할 수 없으므로" 팀의 소유자(owner) 또는 관리자(admin) 역할이 필요하며, 워크스페이스에 최소 하나 이상의 프로젝트와 여기에 연결된 에이전트가 있어야 합니다.

2단계: 앱 자격 증명 입력

각 플랫폼은 서로 다른 자격 증명 쌍을 발급하며, 승인 절차도 다릅니다. 이 부분은 미리 계획을 세워두는 것이 좋습니다.

시간을 크게 단축할 수 있는 두 가지 팁이 있습니다. Slack에서는 매니페스트(manifest)를 통해 앱을 생성하면 권한 범위(scopes), 이벤트 구독, DM 진입점, Socket Mode를 한 번에 구성할 수 있습니다. 이후 권한 범위나 이벤트를 변경하는 경우 Reinstall to Workspace(워크스페이스에 재설치)를 해야만 변경 사항이 적용됩니다. DingTalk에는 선택 사항인 세 번째 필드인 AI card template ID가 있습니다. 이 필드를 비워두면 답변당 하나의 메시지가 전송되고, 설정하면 글자 단위의 스트리밍이 지원됩니다.

요청을 진행하기 전에 주의해야 할 명칭 관련 함정이 있습니다. "Feishu와 Lark는 서로 다른 플랫폼입니다." Feishu는 중국 내수용 버전이고 Lark는 글로벌 버전입니다. 계정과 앱은 서로 연동되지 않으며, 특정 배포가 어떤 플랫폼과 통신할지는 연동별 선택이 아닌 배포 수준의 설정입니다. 잘못된 콘솔에서 앱이 생성되지 않도록 시작하기 전에 관리자와 확인하세요.

3단계: 생성 및 연결

채팅 측에서 메시지에 답변할 에이전트를 선택한 다음, 메모리 범위를 설정합니다. 봇이 정보를 검색하고 기록할 필수 읽기-쓰기(read-write) 프로젝트 하나와, 검색은 가능하지만 기록은 할 수 없는 읽기 전용(read-only) 프로젝트를 원하는 만큼 지정할 수 있습니다.

이 설정을 중요한 보안 결정으로 취급해야 합니다. 문서에서도 명시하고 있듯이 "읽기-쓰기 프로젝트는 권한 부여 결정"입니다. 봇에 접근할 수 있는 모든 사람이 해당 프로젝트에 기록할 수 있고 이미 기록된 내용을 읽을 수 있기 때문입니다. 민감한 자료가 포함된 프로젝트가 아니라, 팀과 공유하려는 프로젝트를 지정하세요. 그런 다음 연동을 생성하고 카드가 Connected(연결됨)로 표시되는지 확인합니다.

솔직히 말씀드리는 세 가지 제한 사항이 있습니다. 첫째, 봇은 채팅 이력을 읽지 않습니다. 모든 플랫폼에서 자신을 언급(멘션)한 메시지만 수신하므로, 채널이나 그룹 내의 다른 대화는 볼 수 없습니다. 둘째, 연결한 프로젝트를 기반으로 답변하므로, 첫 주의 답변 품질은 여러분이 업로드한 자료의 품질에 좌우됩니다. 셋째, 이는 컨텍스트 제공 도구일 뿐 강제 수단이 아닙니다. 반드시 준수해야 하는 사항이 있다면 메모리 레이어가 아닌 정책이나 검증 프로세스를 통해 보장해야 합니다.

작동 방식은 첫날부터 팀원들을 놀라게 할 정도로 플랫폼마다 다릅니다.

봇 호출하기. 그룹 채팅에서는 세 플랫폼 모두 @멘션이 필요합니다. 멘션되지 않은 메시지는 봇에게 전달되지 않습니다. DM의 경우 다릅니다. Slack에서는 사이드바의 앱 아래에서 앱을 찾아 @멘션 없이 질문할 수 있고, Feishu DM은 앱의 가용성 범위에 따라 제어되며, DingTalk 연동은 그룹 사용을 중심으로 문서화되어 있습니다.

답변이 표시되는 위치. Slack은 질문 아래 스레드로 답변을 달아 복잡한 채널의 가독성을 유지합니다. Feishu는 질문 메시지를 인용하고 질문자를 @멘션하여 답변하므로, 대화가 빠른 그룹방에서도 답변을 놓치지 않게 해줍니다.

답변 스트리밍 방식. Feishu는 단어 단위로 스트리밍합니다. Slack은 동일한 메시지를 세그먼트 단위로 수정하면서 스트리밍하므로 (수정됨) 표시가 나타나며, 처음 약 12초가 지나면 새로고침 속도가 느려집니다. DingTalk은 AI card template ID를 제공하지 않는 한 답변당 하나의 메시지를 보냅니다.

파일 또는 스크린샷 전송. Slack은 파일과 멘션이 하나의 메시지에 포함되어야 합니다. "채널에 파일만 단독으로 올리면(멘션 없이) 봇에게 전달되지 않습니다. Slack이 이를 전송하지 않기 때문입니다." Feishu에서 그룹 문서를 처리하는 공식적인 방법은 파일을 게시한 다음, 해당 메시지에 답장으로 봇을 @멘션하는 것입니다. DingTalk은 @봇 멘션, 텍스트, 이미지를 하나의 서식 있는 텍스트(rich-text) 메시지로 수신합니다.

컨텍스트 유지 기간. Slack 채널은 스레드별로 만료 시간 없이 유지되므로, 하루 뒤에 동일한 스레드로 돌아와도 계속 작동합니다. Feishu와 DingTalk 그룹은 주제(topic) 범위로 제한됩니다. 8분 동안 대화가 없으면 다음 질문은 새로운 주제로 시작되며, 파일이나 스크린샷을 전송한 직후에는 이 대기 시간이 30분으로 늘어나 동일한 이미지에 대한 후속 질문이 원활하게 이어지도록 합니다.

대화 초기화. Feishu와 DingTalk에서는 /new를 전송합니다. Slack에서는 슬래시 없이 new만 입력해야 합니다. 클라이언트가 /로 시작하는 모든 입력을 슬래시 명령어로 가로채기 때문입니다. 따라서 DM에서는 단독으로 new를 입력하거나, 스레드 내에서는 @봇 new를 입력해야 합니다.

허용되는 사용자. 액세스 권한은 별도의 허용 목록이 아니라 채팅 플랫폼 측에서 결정됩니다. 외부 조직의 Slack Connect 사용자는 자동으로 무시되며, 할당량이 소모되거나 메모리에 기록되지 않습니다. DingTalk은 소속 조직의 구성원이 보낸 메시지만 처리합니다. Feishu의 경우, DM은 앱의 가용성 범위를 따르고 그룹은 그룹 멤버십을 따릅니다.

그룹 내 프라이버시. 세 플랫폼 모두 대화 컨텍스트는 개인별로 관리됩니다. 동일한 그룹이나 스레드 내에서도 한 사람의 대화 내용이 다른 사람에게 노출되지 않습니다. 다만 프로젝트 메모리는 공유되며, 이것이 바로 지식 베이스를 연결하는 목적이기도 합니다.

모든 자료가 아닌 특정 프로젝트만 연결하세요. 팀이 공동으로 알아야 할 범위로 제한된 하나의 프로젝트로 시작하고, 봇이 인용할 수는 있지만 수정할 수는 없는 자료는 읽기 전용 프로젝트로 추가하세요.

문서 라이브러리가 아니라 이미 답변하고 있는 질문들로 시작하세요. 자주 묻는 20개의 질문과 그 답변 및 이유를 등록하는 것이 200페이지의 문서를 올리는 것보다 낫습니다. 세부 사항이 바뀌더라도 그 판단 이유는 그대로 유지되기 때문입니다.

항목당 하나의 주장만 작성하세요. 짧고 독립적인 항목이 깔끔하게 검색됩니다. 긴 문서는 전체가 반환되어 독자에게 다시 정보를 추출하는 부담을 주게 되며, 이는 기존 위키가 가졌던 실패를 반복하는 결과를 낳습니다.

실제로 주로 사용하는 플랫폼을 선택하세요. 질문이 다른 곳으로 들어온다면 연동은 아무런 의미가 없습니다. DingTalk을 사용하는 회사에서 완벽한 Slack 설정은 아무 쓸모가 없습니다.

출시일에 구성원들에게 두 가지 규칙을 안내하세요. 스레드 답장을 포함하여 매번 봇을 언급(멘션)해야 하며, 파일은 멘션과 동일한 메시지에 첨부해야 합니다. "봇이 나를 무시한다"는 보고의 거의 대부분은 이 두 가지 규칙을 지키지 않아 발생합니다.

Feishu나 DingTalk에서는 먼저 관리자에게 문의하세요. 두 플랫폼 모두 게시 및 권한 검토가 필요하므로, 월요일에 요청을 제출했다고 해서 월요일에 바로 봇이 실행되는 것은 아닙니다. Slack은 오후 한나절 만에 스스로 완료할 수 있습니다.

판단은 사람의 몫으로 남겨두세요. 봇은 팀이 이미 정립해 둔 내용을 반환할 뿐입니다. 아무도 문서화하지 않은 상황에서 어떻게 대처할지는 여전히 인간의 결정 영역입니다. 이 경계는 AI 메모리의 실제 정의에서 명확히 다루고 있습니다.

지식 베이스는 작성하는 시점이 아니라 사용하는 시점에 실패합니다. 질문은 동료들이 있는 그룹 채팅방에서 이루어지지만, 문서는 사람들에게 그 창을 벗어나 검색하고 스스로 답변을 조립할 것을 요구합니다. 채팅 플랫폼들이 이 격차를 일부 좁혔습니다. 예를 들어 Slack의 AI 답변은 해당 기능이 포함된 요금제에서 각 사용자가 액세스할 수 있는 Slack 콘텐츠를 대상으로 잘 작동합니다. 하지만 메시지가 아닌 문서에 존재하는 지식은 외부 소스에 접근할 수 있는 등급의 요금제를 사용하지 않는 한 그 범위에서 벗어납니다.

지식 베이스를 @멘션 뒤에 배치하면 컨텍스트 스위칭과 답변 조립 단계가 동시에 사라집니다. 또한 각 대화 내용을 다시 기록함으로써, 억지로 문서를 작성하는 대신 실제 질문을 통해 말뭉치가 성장하게 됩니다. 설정은 간단하며, 계획해야 할 부분은 행정적인 절차입니다. Feishu나 DingTalk에서 누가 앱을 승인할 수 있는지, 그리고 봇에 접근할 수 있는 모든 사람에게 어떤 프로젝트를 공개할지 결정하세요. 이 두 가지만 올바르게 설정하면, 위키는 더 이상 사람들에게 읽으라고 강요해야 하는 대상이 아니게 될 것입니다.