Slack·Notion·메일을 먹는 AI 지식 대시보드 설계법

Slack 대화와 Notion 문서, 메일, Google Drive 자료를 AI에 연결하면 정말 더 똑똑해질까. 강의 판매자용 SaaS에서 중요한 질문은 연결 가능 여부가 아니다. 데이터가 언제 들어왔는지, 어떤 답에 쓰였는지, 어디서 막혔는지를 어떻게 보여주느냐가 핵심이다.

지식 대시보드는 챗봇보다 데이터 상태를 먼저 보여줘야 한다

2026년 9월 현재 Claude와 Notion 같은 제품은 이미 업무 도구용 커넥터를 제공한다. Anthropic 문서에 따르면 Claude 커넥터의 접근 범위는 연결된 서비스와 설정된 권한에 따라 달라진다. Notion도 Slack과 Google Drive 등을 검색 범위에 넣는 AI 커넥터를 제공한다.

범용 검색창만 만든다면 기존 제품과 차이가 작다. 교육 SaaS가 보여줘야 할 첫 화면은 답변창보다 데이터 파이프라인이다. 소스별 인증 상태와 허용된 폴더와 채널, 마지막 동기화 시각, 처리 대기량, 실패 건수, 삭제 반영 여부가 필요하다.

문서 수와 임베딩 조각 수만 크게 표시하면 AI가 좋아졌다는 착시를 만든다. 실제 품질은 최신 자료가 검색됐는지, 답변에 출처가 붙었는지, 근거가 부족할 때 답변을 멈췄는지로 판단해야 한다. 대시보드에는 출처 포함률과 답변 보류율, 사용자 평가, 자주 검색되지만 자료가 없는 질문을 함께 넣는 편이 낫다.

Slack·Notion·Gmail·Drive는 서로 다른 방식으로 동기화한다

네 서비스를 하나의 수집기로 처리하면 운영 단계에서 문제가 생긴다. Slack은 스레드와 채널 권한을 보존해야 한다. 공식 문서가 밝힌 API 호출 제한도 앱 유형과 메서드에 따라 다르다. 전체 대화를 매번 다시 읽는 방식은 적합하지 않다.

Notion 내부 통합은 명시적으로 공유된 페이지와 데이터베이스만 읽는다. 페이지 변경은 webhook으로 받을 수 있다. Google Drive도 변경 알림을 제공하지만 알림 본문에 파일 내용이 들어오지는 않는다. 알림을 받은 뒤 Drive API로 최신 상태를 다시 가져와야 한다.

Gmail은 historyId 이후의 변경을 조회하는 History API를 제공한다. 오래된 ID가 무효가 되면 전체 동기화가 다시 필요할 수 있다. 각 커넥터에는 초기 수집과 증분 수집, 삭제 처리, 토큰 갱신, 재시도 큐가 따로 있어야 한다.

써본 사람들 사이에서는 여러 도구를 한 번에 검색하는 효용이 크다는 반응이 있다. 반면 Slack 스레드의 잡음과 오래된 문서가 섞이면 답변 품질이 빠르게 떨어진다는 불만도 나온다. 연결 개수보다 정리 규칙과 최신성 표시가 중요하다는 이야기다.

Claude Code로 최소 제품을 만드는 순서

작은 팀이라면 Next.js와 Postgres 조합으로 시작할 수 있다. 벡터 검색에는 pgvector나 별도 벡터 데이터베이스를 쓴다. 핵심 테이블은 documents, chunks, sync_runs, retrieval_logs, feedback, learning_events 정도로 나눈다.

documents에는 tenant_id, source, source_id, title, uri, updated_at, checksum, acl을 저장한다. 원문을 일정 크기로 나눈 결과와 임베딩은 chunks에 넣는다. 검색할 때는 유사도뿐 아니라 tenant_id와 접근 권한도 필터에 반드시 포함한다.

Claude Code 프로젝트에는 src/connectors, src/pipeline, app/dashboard, db/migrations를 먼저 만든다. CLAUDE.md에는 테넌트 간 데이터 분리, 커넥터 기본값은 읽기 전용, 출처 없는 답변 금지, 동기화 작업의 재실행 가능성을 규칙으로 적는다.

구현은 Google Drive 하나로 시작하는 편이 안전하다. OAuth 연결 뒤 파일 메타데이터를 수집하고 변경 알림을 받아 갱신한다. 이어 문서 정규화, 청크 생성, 임베딩 저장, 검색 API, 출처가 포함된 답변 화면을 순서대로 붙인다.

다음 커넥터는 같은 인터페이스를 구현하게 한다. 입력은 원본 API 응답이고 출력은 통일된 Document 객체다. Claude Code에는 “Notion 응답을 기존 Document 스키마로 변환하고 삭제 이벤트 테스트를 추가하라”처럼 입력과 산출물을 함께 지시해야 한다.

교육 데이터는 업무 지식과 분리해야 한다

강의 자료와 운영 메일은 AI가 답변할 지식이다. 수강생의 문제 풀이와 진도, 피드백은 학습 기록이다. 두 종류를 같은 벡터 저장소에 무작정 섞으면 개인별 성과와 일반 안내문이 함께 검색될 수 있다.

학습 활동은 별도 이벤트로 저장하는 편이 낫다. xAPI는 학습 경험을 행위자·행동·대상 구조의 statement로 기록해 LRS에 보관하는 방식을 정의한다. 예를 들어 강의 시청, 퀴즈 제출, 피드백 확인을 이벤트로 남길 수 있다.

교사용 화면은 낮은 점수 자체보다 개입할 근거를 제공해야 한다. 반복해서 틀린 개념과 최근 활동 변화, 제공한 보충 자료, 이후 결과를 한 흐름으로 보여주는 방식이다. 외부 참고 사례에서도 대시보드는 진단 뒤 다른 문제와 피드백을 적용한 다음 반응을 계속 관찰하는 도구로 다뤄졌다.

커뮤니티 논의에서는 이런 화면을 강의에 활용했을 때 차별화된 후기와 후속 강의 요청에 도움이 됐다는 경험담이 나왔다. 다만 대시보드가 학습 효과를 자동으로 증명하지는 않는다. 어떤 조치를 했고 이후 지표가 어떻게 달라졌는지 함께 남겨야 설득력이 생긴다.

판매 가능한 기능은 ‘AI의 성장’이 아니라 추적 가능한 개선이다

강의 판매자가 원하는 것은 거대한 사내 검색 시스템이 아니다. 지난 기수에서 질문이 몰린 구간과 답변 근거가 부족한 주제, 업데이트가 필요한 교안, 개인 지원이 필요한 수강생을 빠르게 찾는 화면이 더 직접적이다.

대시보드는 질문을 강의 차시와 개념별로 묶고 답변에 사용된 원문을 연결해야 한다. 운영자는 지식 공백을 확인한 뒤 교안을 고쳐 다시 동기화할 수 있다. 다음 기수에서는 같은 질문이 줄었는지 비교한다.

내부 업무 검색만 필요하다면 Claude나 Notion의 기존 커넥터가 빠른 선택이다. 고객별 데이터 격리와 학습 이벤트, 콘텐츠 개선 이력, 브랜드 화면이 상품의 중심이라면 직접 구축할 이유가 생긴다. 이 시장에서 팔리는 것은 AI가 지식을 가졌다는 선언이 아니다. 어떤 데이터로 어떤 답을 만들었는지 보여주는 운영 능력이다.