目錄
2026년 8월 r/Notion에는 눈여겨볼 만한 제품 요청이 하나 올라왔습니다. Notion 페이지 안에 직접 넣을 수 있는 AI 검색 요소를 제공해 Workspace Search를 사용할 때마다 전역 검색 화면에서 다시 시작하지 않게 해 달라는 요청입니다. 이런 요구가 처음 나온 것은 아닙니다. 과거에도 공식 Search Bar를 페이지 안에 삽입할 수 있게 해 달라는 의견이 있었고, 이제 Notion AI가 Workspace의 질문에 답하고 Connected Apps까지 검색할 수 있게 되면서 요구가 한 단계 더 나아갔습니다. Enterprise Search에서 이미 특정 Page, Teamspace 또는 Source로 검색 범위를 제한할 수 있다면, 이 Scope 자체를 프로젝트 페이지에 고정해서 검색 진입점도 업무 Context와 함께 남겨 둘 수 없느냐는 것입니다.
같은 날 r/Notion에서는 생성형 AI에 여전히 안정적인 장기 Knowledge Layer가 부족하다는 불만도 나왔습니다. 이미 만들어 둔 지식을 자연스럽게 계속 활용하기 어렵고, Private Knowledge를 완전히 연결하기 힘들며, 매번 Context를 다시 정리해야 하고, 이전에 이야기했던 내용을 시간이 지나면 다시 찾아야 한다는 내용입니다. 같은 글이 r/ChatGPT에도 올라갔기 때문에 정확하게 말하면 두 명의 Notion 사용자가 각각 같은 문제를 제기한 것이 아니라 한 사용자가 같은 문제를 여러 AI 커뮤니티에 공유한 사례입니다. 이 논의들을 함께 보면 실제로 부딪히는 것은 「모델의 기억력이 충분한가」라는 문제보다 Context를 누가 관리하는가에 가깝습니다. 생산성 도구에서는 AI가 모든 것을 영원히 기억할 필요가 없습니다. 작업을 시작할 때마다 이 질문은 어느 자료를 검색해야 하는지 알 수만 있어도, 이른바 「기억 문제」의 상당 부분은 Retrieval 단계에서 먼저 해결할 수 있습니다.
Notion Enterprise Search는 현재 어디까지 할 수 있을까?
검색 범위는 이미 특정 Page나 Teamspace까지 줄일 수 있다
Notion Enterprise Search는 현재 Business와 Enterprise 요금제에서 제공되며 주요 진입점은 Home에 있습니다. Notion Workspace뿐 아니라 연결된 Slack, Google Drive, Microsoft Teams, Jira 등의 소스를 검색할 수 있고 Web Search도 추가할 수 있습니다. Workspace나 Connected Apps의 자료를 활용해 답변할 경우 출처도 함께 제공해 원본 정보를 다시 확인할 수 있습니다.
이제 전체 Workspace만 한 번에 검색해야 하는 것도 아닙니다. 사용자는 특정 Page나 Person을 Context로 추가할 수 있고 Page, Teamspace와 Person을 지정할 수도 있습니다. Sources에서는 Workspace나 특정 Connected App만 남길 수 있으며, Workspace 안에서도 검색 범위를 특정 Page 또는 Teamspace까지 더 좁힐 수 있습니다.
모델 역시 현재 OpenAI의 GPT, Anthropic의 Claude와 Google의 Gemini 사이에서 선택할 수 있습니다. 다만 모델마다 사용할 수 있는 Data Sources가 완전히 같지는 않기 때문에 모델 이름만 보고 동일한 검색 기능을 제공한다고 가정해서는 안 됩니다.
이 점을 보면 커뮤니티가 실제로 원하는 것은 「검색 범위를 제한하는 기능」 자체가 아닙니다. 이미 설정한 검색 범위를 특정 페이지의 고정된 인터페이스로 저장해 두는 기능에 가깝습니다. 현재는 Enterprise Search를 시작할 때마다 Context나 Scope를 다시 지정해야 합니다. 한 프로젝트가 장기간 Project Brief, Decision Log, Meeting Notes와 관련 문서만 반복해서 확인한다면 이 설정 전체를 프로젝트 첫 화면에 그대로 남겨 두고 싶은 요구가 생기는 것이 자연스럽습니다.
Notion에는 이미 AI Block이 있지만 아직 대화형 검색창은 아니다
AI Block은 이미 페이지 안에 넣을 수 있고 Context도 지정할 수 있다
「임베드형 AI 검색」을 이야기할 때 현재 Notion에 이미 /AI Block이 있다는 사실은 쉽게 빠집니다. AI Block은 Page 안에 직접 삽입할 수 있고 현재 Page의 내용만 처리하는 것도 아닙니다. 생성할 때 Prompt를 설정하고 Workspace 또는 Connected Apps의 Context와 Search Sources를 지정할 수 있습니다. 설정이 끝난 뒤 Generate를 누르면 현재 데이터를 기반으로 결과가 생성되고, 나중에 최신 상태로 갱신할 때 다시 Generate할 수 있습니다.
예를 들어 Project 홈에 AI Block을 하나 두고 요구사항 문서, Decision Log와 Meeting Notes를 바탕으로 아직 확정되지 않은 의사결정, 진행 위험과 다음 단계를 정리하도록 고정할 수 있습니다. 모든 프로젝트에서 비슷한 요구가 있다면 AI Block을 Database Template에 넣어 새 Project Page가 만들어질 때 동일한 Prompt와 Context 구조를 자동으로 포함하도록 만들 수도 있습니다.
이 정도면 이미 「AI가 페이지를 따라다닌다」는 구조에 상당히 가깝습니다. 하지만 커뮤니티가 원하는 기능과는 여전히 차이가 있습니다. AI Block은 「고정된 질문＋고정된 데이터 소스＋필요할 때 수동 재생성」에 가깝습니다. 각 Viewer가 페이지에서 서로 다른 질문을 입력하고, 후속 질문을 계속하면서도 검색 Scope는 미리 정해져 있는 Enterprise Search Widget과는 다릅니다.
즉, Notion은 이미 이 요구의 절반 정도를 구현했다고 볼 수 있습니다. Context를 고정하는 것은 가능하지만, 그 고정된 Context 안에서 자유롭게 질문할 수 있는 Query Interface가 아직 없습니다.
‘검색 범위가 페이지를 따라다니는 방식’은 왜 매번 전역 검색에서 시작하는 것보다 편할까?
Scope는 Retrieval 품질에 영향을 주지만 작을수록 무조건 좋은 것은 아니다
Retrieval-Augmented Generation 구조에서는 답변 품질을 모델 성능만 결정하지 않습니다. 그 앞단의 Retrieval이 어떤 자료를 찾아오는지도 중요합니다.
예를 들어 회사 Workspace에 5년간 Project Pages가 쌓였고 같은 프로젝트 이름을 여러 번 재사용했다고 해 보겠습니다. 전체 데이터를 대상으로 「이 프로젝트의 납기일은 언제야?」라고 질문하면 과거 버전의 요구사항, 예전 프로젝트 또는 이름이 비슷한 문서까지 후보에 들어올 수 있습니다. 반면 검색창 자체가 현재 Project Page에 있고 기본 Context가 올바른 프로젝트를 가리키도록 설정돼 있다면 이런 관련 없는 자료가 Retrieval에 포함될 가능성을 줄일 수 있습니다.
그렇다고 검색 Scope가 좁을수록 답변이 항상 정확해지는 것은 아닙니다. 실제 정답이 회사 공통 Policy, 다른 Teamspace 또는 특정 Slack 결정에 있을 수도 있습니다. Scope를 지나치게 좁히면 필요한 증거까지 함께 제외할 수 있습니다.
더 적절한 방법은 Scope를 Intent의 일부로 이해하는 것입니다. 「이 고객이 마지막으로 무엇을 승인했는가」를 묻는다면 Client Page가 자연스러운 출발점입니다. 하지만 「회사의 현재 공통 가격 정책은 무엇인가」를 묻는다면 특정 프로젝트만 검색해서는 안 됩니다.
그래서 Page형 AI Search의 진짜 가치는 검색 범위를 항상 최소로 만드는 데 있는 것이 아닙니다. 가장 자주 사용하는 Context를 미리 설정해 두어 사용자가 질문할 때마다 현재 무슨 일을 하고 있는지 다시 설명하지 않아도 된다는 점에 있습니다.
‘영구 기억’은 모델이 직접 기억하는 방식만 있는 것이 아니라 Knowledge Layer로도 해결할 수 있다
Storage·Retrieval·Memory는 서로 다른 문제다
8월 20일의 논의에서는 여러 문제가 한꺼번에 섞여 있었습니다. AI에 Permanent Storage가 부족하고, Private Knowledge를 자연스럽게 연결하기 어렵고, 기억했다가도 다시 잊고, Chat 사이에 완전한 Cross-chat Memory가 없으며, 매번 Context를 만들고 Chat을 저장하고 이전 정보를 다시 찾는 과정이 번거롭다는 불만입니다.
이런 사용 경험은 충분히 이해할 수 있지만 시스템 설계 관점에서는 Storage, Retrieval과 Memory라는 세 가지 서로 다른 문제가 섞여 있습니다.
Storage는 데이터가 실제로 저장돼 있는지를 다룹니다. Retrieval은 필요할 때 올바른 자료를 다시 찾아올 수 있는지를 다룹니다. Memory는 모델이 대화가 달라진 뒤에도 이전 Interaction과 Preference를 유지할 수 있는지를 의미합니다.
Notion이 비교적 강한 부분은 앞의 두 층입니다. Page, Database, Files와 Connected Apps 자체가 Knowledge Storage가 되고, Enterprise Search가 Retrieval을 담당하며, 그 위의 모델이 찾아낸 Context를 읽어 답변을 구성합니다.
이런 구조라면 모델에게 「작년 회의를 영원히 기억해」라고 요구할 필요가 없습니다. 작년 회의 기록이 여전히 존재하고 오늘 필요할 때 정확하게 다시 찾을 수 있으면 됩니다.
Project Page에 고정할 수 있는 AI Search Widget이 개선할 부분도 바로 여기에 있습니다. 모델에 영구 기억을 추가하는 것이 아니라 Retrieval의 진입점을 실제 작업이 이루어지는 위치에 남겨 두는 것입니다.
권한은 임베드형 AI 검색에서 실제로 해결해야 할 문제지만 Notion이 아직 만들지 않은 이유라고 단정할 수는 없다
Enterprise Search는 이미 현재 검색자의 권한을 기준으로 결과를 필터링한다
AI Search Block을 만든 사람이 A, B, C 세 문서를 모두 볼 수 있지만 다른 Viewer는 B만 볼 수 있다고 가정하면 중요한 제품 설계 문제가 생깁니다. 검색 결과는 Block을 만든 사람의 권한을 따라야 할까요, 아니면 현재 Viewer의 권한을 따라야 할까요?
다만 이런 문제를 근거로 「Notion이 Embedded Search를 아직 만들지 않은 이유는 권한이 너무 복잡해서다」라고 추론해서는 안 됩니다.
현재 Enterprise Search 자체가 이미 Permission-aware Retrieval을 제공합니다. 검색 결과는 현재 검색자가 Notion과 Connected Apps에서 가지고 있는 Access Rights를 기준으로 필터링됩니다. 사용자가 원래 볼 수 없는 콘텐츠가 Enterprise Search를 사용했다는 이유만으로 새롭게 노출되지는 않습니다.
앞으로 Interactive Page Search Widget이 실제로 나온다면 각 Query를 현재 Viewer의 권한을 기준으로 다시 실행하는 방식이 더 자연스럽습니다. 같은 Widget이더라도 사용자마다 볼 수 있는 정보가 다른 것은 Permission-aware Search에서는 정상적인 결과입니다.
오히려 현재 AI Block에서 더 주의할 부분이 있습니다. AI Block이 한 번 생성한 텍스트는 이미 Page Content가 됩니다. Block을 만든 사람이 자신만 볼 수 있는 민감한 자료를 기반으로 요약문을 생성한 뒤 그 Page를 원본 자료 권한이 없는 사람에게 공유한다면, 이미 생성된 텍스트 자체가 함께 공유됩니다. 원본 문서의 Permission이 다르다고 해서 생성된 문장이 자동으로 사라지는 것은 아닙니다.
따라서 회사 환경에서 고정 AI Block을 사용할 때는 생성된 결과 역시 일반 Page Content처럼 검토해야 합니다. 원본 자료에 Permission이 있다고 해서 AI가 생성한 결과까지 동일한 권한을 자동으로 상속한다고 생각하면 안 됩니다.
비용은 제품 설계에 영향을 줄 수 있지만 페이지에 임베드됐다고 해서 열 때마다 AI를 다시 실행해야 하는 것은 아니다
또 다른 흔한 추론은 50개의 Project Pages에 AI Search Widget을 넣으면 누군가 페이지를 열 때마다 모델 호출이 발생해 비용이 급격히 증가할 것이라는 생각입니다.
하지만 Embedded Search가 반드시 그런 방식으로 작동해야 하는 것은 아닙니다. 검색창은 사용자가 실제로 질문을 입력했을 때만 실행되도록 만들 수 있습니다. 현재 Enterprise Search와 같은 방식입니다.
기존 AI Block도 이미 이 점을 보여 줍니다. Page를 열 때마다 자동으로 다시 계산되는 것이 아니라 사용자가 Generate를 눌렀을 때 결과가 갱신됩니다.
따라서 「페이지에 임베드됨＝Page Load마다 AI 사용량이 발생함」을 전제 조건으로 둘 수는 없습니다. 향후 Interactive Search Block이 실제로 출시된다면 Cache, Usage Allowance, Concurrency와 Viewer별 Query History를 별도로 설계해야 할 수는 있습니다. 하지만 Notion은 이런 비용 문제가 현재 기능 부재의 이유라고 공개적으로 밝힌 적이 없기 때문에 제품이 없는 이유까지 대신 추측할 필요는 없습니다.
Workspace가 커질수록 AI 검색은 반드시 나빠질까?
문제는 데이터가 많다는 사실보다 어떤 자료가 Current이고 Authoritative한지 불분명한 경우가 많다는 데 있다
같은 주 r/Notion에는 「시스템을 계속 확장하는 문제」와 관련된 몇 가지 논의도 있었습니다. 보조 사례로 사용할 수는 있지만 「Page가 많을수록 AI가 반드시 부정확해진다」는 결론으로 연결하면 안 됩니다.
Notion을 6년 동안 사용한 한 사용자는 Writing, Tasks, Inventories, Finances 거의 전부를 Notion에 보관했고 새로운 Structures를 계속 만드는 과정도 오랫동안 즐겼지만, 최근 자신의 Notion 사용 방식을 다시 생각하고 있다고 말했습니다. 다만 그 글에는 Privacy, Local-first와 Generative AI 중심 제품 방향에 대한 우려도 함께 들어 있었기 때문에 단순히 「시스템이 너무 커져서 사용하기 어려워졌다」는 사례로 축약하기는 어렵습니다.
또 다른 Habit Tracker 글에서는 작성자가 주말 내내 Tracker를 만들고 11일만 사용한 뒤 더 이상 열지 않았습니다. 하지만 댓글에는 자신의 Tracker를 2년 또는 5년 동안 계속 사용하고 있다는 사람도 있었습니다. 한 사용자의 포기 사례만으로 Habit Tracking 자체가 오래 유지될 수 없는 구조라고 결론 내릴 수는 없습니다.
더 적절한 결론은 구조가 장기적으로 유지될 수 있는지는 실제 요구와 유지보수 비용에 달려 있다는 것입니다.
AI Search와의 연결도 「데이터가 많을수록 Noise가 많아진다」는 식으로 설명할 필요는 없습니다. 대규모 Knowledge Base도 충분히 잘 작동할 수 있습니다. 진짜 문제가 되는 경우는 같은 내용의 여러 버전이 동시에 존재하는데 Current Status, Owner, Date 또는 Source of Truth가 명확하지 않을 때입니다. 이런 환경에서는 사람도 Retrieval System도 어떤 자료가 현재 기준인지 판단하기 어려워집니다.
작은 Notion Database는 왜 이해하기 쉬운 경우가 많을까?
공통점은 ‘작을수록 좋다’가 아니라 무엇을 위한 시스템인지 쉽게 설명할 수 있다는 것이다
이번 주 한 대학 신입생은 원래 Excel에서 TikTok Creator Accounts를 수집하며 작은 연구를 진행하다가 Notion으로 옮긴 뒤 정보를 정리하고 다시 찾기가 더 쉬워졌다고 공유했습니다. 댓글에서는 Database를 매우 복잡하게 만들 수도 있지만 실제 요구가 생기기 전에 모든 기능을 미리 만들 필요는 없다는 의견도 나왔습니다.
차량 관리 Tracker도 Scope가 명확한 또 다른 사례입니다. 작성자는 커뮤니티 의견을 반영해 「마지막 Tire Rotation 이후 몇 마일을 주행했는가」 같은 필드를 추가했지만 전체 시스템은 계속 Service Log, Insurance, Warranty, Fuel, Reminders와 TCO 등 차량 관리라는 한 가지 문제 안에 머물렀습니다. 모든 생활을 관리하는 대형 Dashboard로 계속 확장된 것은 아닙니다.
또 다른 사용자는 가족의 암 치료 정보를 Notion에 정리했습니다. Appointment, Medical Reports, Treatment Progress와 의사에게 물어볼 질문 등이 포함됐습니다. 이 사용자는 과거에는 Notion 시스템을 지나치게 복잡하게 만든 경험이 있었지만, 이번에는 해결해야 할 문제가 매우 명확했기 때문에 어떤 정보를 실제로 남겨야 하는지 더 쉽게 판단할 수 있었다고 설명했습니다.
이 사례들이 보여 주는 것은 「Database는 반드시 작아야 한다」가 아닙니다. 각 Database가 어떤 문제를 처리하는지 빠르게 설명할 수 있어야 한다는 점입니다.
용도가 명확할수록 나중에 사람이 직접 데이터를 찾기도 쉽고 AI에게 어디를 검색해야 하는지 알려 주기도 쉬워집니다.
아직 Interactive AI Search Widget이 없다면 지금은 어떻게 사용할 수 있을까?
일회성 질문은 Enterprise Search에서 Scope를 좁혀 사용한다
「이 프로젝트에서 마지막으로 확정된 납기일은 언제인가」처럼 일회성 질문이라면 가장 직접적인 방법은 Enterprise Search에서 Scope를 현재 Project Page나 Teamspace로 좁힌 뒤 Query하는 것입니다.
Notion은 이미 이 정도 수준의 검색 범위를 지원하기 때문에 매번 전체 Workspace, 모든 Connected Apps와 Web을 동시에 검색할 필요는 없습니다.
이 방식은 Prompt에 「Project A만 봐 줘」라고 적는 것보다도 더 명확합니다. Scope 자체가 Search Interface에 포함되기 때문입니다.
반복적으로 묻는 질문은 AI Block으로 만든다
매주 거의 같은 질문을 반복한다면 새로운 Search Widget을 기다릴 필요는 없습니다.
예를 들어 현재 프로젝트에서 해결되지 않은 Decisions를 정리하거나, Owner가 없는 Action Items를 찾거나, 최근 몇 차례 Client Meeting의 결론을 정리하는 작업이라면 Project Template 안에 AI Block을 넣을 수 있습니다.
필요한 Pages 또는 Connected Sources를 Context로 지정하고 Prompt를 미리 작성한 뒤 업데이트가 필요할 때 Generate를 누르면 됩니다.
별도의 Prompt 목록을 다른 페이지에 보관하는 것보다 실제 Embedded AI에 더 가깝습니다. Prompt, Context와 Output이 모두 일이 일어나는 같은 Page에 남기 때문입니다.
Project 홈에 명확한 Context 진입점을 만들되 모든 자료를 한 페이지에 복사할 필요는 없다
Project Page에 Project Context 영역을 고정해서 현재 유효한 Brief, Decision Log, Deliverables, Meeting Notes와 핵심 Database Views를 한곳에서 확인할 수 있게 만들 수 있습니다.
목적은 모든 자료를 다시 복사하는 것이 아닙니다. 이 Project에서 지금 참고해야 하는 자료가 무엇인지를 명시하는 것입니다.
이렇게 하면 AI뿐 아니라 사람도 실제 Source of Truth를 찾기 쉬워지고 Enterprise Search나 AI Block도 해당 Page를 기준으로 Context를 만들기 쉬워집니다.
오래된 자료는 최근 사용 여부만으로 삭제하지 말고 상태부터 표시한다
3개월 동안 열지 않았다고 해서 데이터가 무효가 된 것은 아닙니다. Decision Records, 법률 문서, 연구 자료와 과거 Project는 평소에는 거의 사용하지 않더라도 필요한 순간에는 중요한 가치가 있을 수 있습니다.
따라서 「최근에 사용했는가」만 기준으로 대규모 삭제를 하는 것은 AI Search 개선의 일반적인 방법이 아닙니다.
더 안전한 방법은 Current, Archived, Superseded 같은 Status를 만들어 오래된 버전이 어떤 새 문서로 대체됐는지 명확하게 표시하는 것입니다. 필요한 경우 Archive로 옮기고 Page Title 역시 자료의 내용을 알 수 있도록 작성하는 편이 좋습니다.
Retrieval에서는 「이 문서가 무엇인지」「아직 유효한지」「어느 버전이 공식 자료인지」를 구분할 수 있는 정보가 Workspace를 무조건 적은 Page만 남도록 정리하는 것보다 더 중요할 수 있습니다.
임베드형 AI 검색에서 실제로 부족한 것은 Scope를 저장할 수 있는 자유로운 Query Interface다
현재 Notion에는 이미 세 가지 주요 조각이 있습니다.
Enterprise Search는 Workspace, Connected Apps와 Web을 검색할 수 있고 Scope를 특정 Page나 Teamspace까지 줄일 수 있습니다. AI Block은 Page 안에 직접 존재하면서 Prompt와 Context를 저장하고 Generate를 눌러 결과를 업데이트할 수 있습니다. Notion Agent는 Workspace Context 안에서 더 나아가 콘텐츠를 생성하고 수정할 수 있습니다.
현재 공식 제품 문서에서 아직 확인할 수 없는 것은 앞의 두 기능을 그대로 결합한 형태입니다. 즉 Project Page 안에 직접 삽입되고, Scope는 미리 설정돼 있지만 각 사용자가 서로 다른 질문을 자유롭게 입력하고 후속 질문까지 계속할 수 있는 Enterprise Search Block입니다.
그래서 커뮤니티의 요청은 겉으로 보면 단순히 「검색창 하나 더 만들어 달라」는 말처럼 보이지만 실제 요구는 상당히 합리적입니다. 새로운 모델이 더 필요한 것도 아니고 Ask AI 버튼을 또 하나 추가해 달라는 것도 아닙니다. Context를 Page와 함께 저장해서 매번 질문하기 전에 지금 무슨 일을 하고 있는지 다시 지정하지 않게 해 달라는 요구입니다.
공식적으로 이런 Widget이 나오기 전까지는 반복 질문을 AI Block에 맡기고, 일회성 질문은 Enterprise Search를 사용하면서, Workspace에서는 Current, Archived, Owner, Date와 Source of Truth를 명확하게 표시하는 방식이 가장 현실적입니다.
모델이 반년 전에 나눴던 대화를 영원히 기억하는지는 사용자가 직접 통제하기 어렵습니다. 하지만 오늘 이 질문의 답을 어느 자료에서 찾아야 하는지는 미리 정해 둘 수 있습니다.
자주 묻는 질문 FAQ
현재 공식적으로 Enterprise Search와 동일한 형태로 Page 안에 삽입하고, 각 사용자가 미리 설정된 Scope 안에서 자유롭게 다른 질문을 입력할 수 있는 검색 Widget은 확인되지 않습니다. 다만 Notion에는 이미 AI Block이 있어 Page 안에서 Prompt, Context와 Search Sources를 미리 지정하고 사용자가 Generate를 눌러 결과를 업데이트할 수 있습니다. 따라서 「페이지 안에 Context 기반 AI 기능이 전혀 없다」고 말하는 것도 정확하지 않습니다. 현재 부족한 것은 자유롭게 질문할 수 있는 Interactive Search Interface에 가깝습니다.
AI Block은 반복적으로 사용하는 고정 질문에 더 적합합니다. 예를 들어 매번 프로젝트 위험, 아직 확정되지 않은 의사결정이나 Meeting Summary를 정리한다면 Prompt와 Context를 미리 설정해 두고 필요할 때 다시 Generate할 수 있습니다. Enterprise Search는 일회성 질문에 더 적합하며 사용자가 매번 다른 질문을 입력하고 필요에 따라 Scope를 바꿀 수 있습니다. 간단하게 말하면 AI Block은 고정 Template에 가깝고 Enterprise Search는 자유로운 검색에 가깝습니다.
가능합니다. Enterprise Search에서는 특정 Page, Person이나 Teamspace를 Context로 추가할 수 있고 Sources도 조정할 수 있어 검색 범위를 Workspace의 특정 영역이나 Connected App으로 줄일 수 있습니다. 따라서 「검색 범위를 제한하는 기능」 자체가 없는 것은 아닙니다. 커뮤니티가 원하는 것은 이 Scope 설정을 특정 Page에 고정해 매번 다시 설정하지 않아도 되는 방식입니다.
아닙니다. Scope를 좁히면 3년 전 같은 이름의 Project 같은 관련 없는 문서가 Retrieval에 들어오는 가능성을 줄일 수 있습니다. 하지만 실제로 필요한 정보가 회사 공통 Policy, 다른 Teamspace나 Slack에 있다면 Scope가 지나치게 좁을 때 필요한 근거를 놓칠 수 있습니다. Scope는 작을수록 좋은 것이 아니라 질문에 맞게 설정하는 것이 중요합니다.
반드시 그렇지는 않습니다. 데이터 양 자체보다 같은 내용의 여러 버전이 있는데 어떤 것이 현재 유효한지 표시되지 않은 경우가 더 큰 문제가 될 수 있습니다. Owner, Date, Status와 Source of Truth가 명확하다면 대규모 Knowledge Base도 충분히 효과적으로 검색할 수 있습니다.
단순히 얼마나 오래 열지 않았는지를 기준으로 삭제하는 것은 권장하기 어렵습니다. 과거 의사결정 기록, 연구 자료, 계약이나 이전 프로젝트는 평소 사용 빈도가 낮아도 나중에 중요할 수 있습니다. 대신 오래된 콘텐츠를 Archived 또는 Superseded로 표시하고 현재 유효한 버전을 명확하게 연결하는 편이 사람과 AI 모두에게 더 유용합니다.