Claude Desktop 단독 vs 로컬 검색을 붙인 Claude Desktop — 정직한 비교
이런 비교는 대개 도구를 파는 것으로 끝납니다. 이 글은 그러지 않고 쓸모 있게 해보겠습니다 — 각 구성이 어디서 이기는지, 무엇을 대가로 치르는지, 그리고 믿을 만한 구성과 그럴듯한 구성을 가르는 시험 하나를 분명히 하는 방식으로.
실제로 존재하는 경계
Claude Desktop 단독은 당신의 파일 시스템에 접근할 수 없습니다. 이 말이 자주 모호하게 서술되므로 분명히 적습니다. 문서를 첨부하면 Claude 는 잘 읽습니다. 긴 대목을 붙여넣으면 그것으로 추론합니다. 할 수 없는 것은 찾아봐야 답할 수 있는 질문입니다 — Claude 쪽에는 찾아볼 수 있는 것이 없기 때문입니다.
그러니 실질적인 분기선은 "Claude 가 문서를 읽을 수 있나"가 아닙니다 — 잘 읽습니다. 어느 문서가 관련 있는지를 누가 정하는가입니다. 커넥터가 없으면 그건 언제나 당신이고, 미리, 손으로 해야 합니다.
Claude Desktop 단독이 실제로 더 나은 경우
이 부분을 공정하게 적는 것이 중요합니다. 커넥터가 공짜가 아니기 때문입니다.
- 어느 파일인지 이미 안다. 끌어다 놓으면 됩니다. 설정할 것도, 색인할 것도, 최신으로 유지할 소프트웨어도 없습니다. 여기서 커넥터는 아무것도 사주지 않습니다.
- 그 문서가 내 기기에 없다. 방금 받은 파일, 한 번 내려받은 것, 복사해 온 페이지 — 업로드는 즉시 되고 로컬 색인은 그것을 본 적이 없습니다.
- 한 번뿐인 작업. 어떤 자료를 한 번 만지고 다시 안 볼 거라면, 색인은 두 번 하지 않을 질문에 들이는 노력입니다.
- 무엇이 보이는지에 단단한 경계를 두고 싶다. 업로드에서는 비서가 당신이 건넨 것만 보고 그 밖은 못 봅니다. 이건 실제 성질이고, 어떤 자료에서는 이것이 결정적입니다.
커넥터가 가능성 자체를 바꾸는 지점
차이는 속도가 아닙니다. 애초에 물어볼 수 있는 질문의 종류입니다.
| 질문 | Claude Desktop 단독 | 로컬 검색을 붙이면 |
|---|---|---|
| "이 계약서 요약해줘." (파일 첨부) | 잘 됨 | 동일 |
| "책임 관련해서 뭐라고 합의했지?" (파일 미지정) | 불가 — 먼저 찾아야 함 | 검색해서 답함 |
| "회의 옮겨졌다고 누가 말했지?" | 불가 | 메일과 문서를 함께 검색 |
| "이 조항이 판본별로 어떻게 바뀌었지?" | 모든 판본을 올려야만 | 찾아서 순서대로 |
| "예전에 이런 프로젝트 해본 적 있나?" | 불가 | 자료 전체를 의미로 검색 |
패턴이 보입니다. 단독 구성이 실패하는 모든 행은 파일명을 미리 모르는 행입니다. 그게 차이의 전부이고, 공교롭게도 자기 과거 작업에 대한 실제 질문 대부분이 그 모양입니다.
대가
정직하게 셈하면, 이것들은 실재합니다.
- 설치. 애플리케이션을 깔고, 폴더를 고르고, JSON 설정 파일을 고칩니다. 잘 풀리면 10분, 경로가 틀리면 더.
- 색인. 첫 순회는 가진 양에 비례해 시간과 CPU 를 씁니다. 도는 동안에도 검색은 되지만 의미검색 쪽은 점진적으로 채워집니다.
- 디스크와 메모리. 색인은 공간을 차지하고, 의미검색 모델은 올라가 있는 동안 큽니다.
- 틀릴 수 있는 표면이 하나 늘어난다. 단독 구성에는 틀릴 검색이 없습니다. 붙이면 엉뚱한 것을 돌려줄 수 있는 부품이 생깁니다 — 그래서 아래 절이 위의 어느 항목보다 중요합니다.
달라지지 않는 것
이런 비교에서 과장되는 것이 둘 있으니 바람을 빼두겠습니다.
프라이버시는 나아지는 것이지 절대적인 것이 아닙니다. 검색하려고 파일을 올리지 않고 색인도 로컬에 남습니다. 그러나 비서가 근거로 삼는 대목은 여전히 모델로 갑니다 — 직접 붙여넣었을 때와 똑같이. 정직한 주장은 더 좁고 그래도 값집니다: 정작 중요한 문단을 찾겠다고 문서 전체를 건네지 않아도 된다는 것.
답은 여전히 당신 문서만큼만 좋습니다. 커넥터는 있는 것을 찾습니다. 그 결정이 구두로 이뤄지고 어디에도 안 적혔다면 어떤 검색으로도 나오지 않습니다 — 그리고 바로 거기가 비서가 그럴듯한 것으로 빈칸을 메울 가능성이 가장 높은 지점입니다.
어떤 기능보다 중요한 시험
둘 중 무엇을 믿기 전에, 당신 파일이 정말로 답하지 못하는 질문을 하나 던져보십시오.
좋은 구성은 못 찾았다고 말합니다. 나쁜 구성은 가장 가까운 것을 돌려주고, 비서는 맞을 때와 똑같이 자신 있는 어조로 그것을 서술합니다. 두 번째 실패가 검색이 아예 없는 것보다 나쁩니다. 보이지 않기 때문입니다 — 확인하지 않고서는 근거 있는 답과 자신 있게 지어낸 답을 구별할 수 없고, 모든 답을 확인할 거라면 애초에 비서가 필요하지 않았을 테니까요.
LocalSynapse 의 응답이 무엇을 뒤졌는지, 질의를 어떻게 읽었는지, 그리고 해석이 성립하지 않았을 때 성립하지 않았다고 — 그럴듯한 목록 대신 — 말하는 이유가 이것입니다. 언제나 무언가를 돌려주는 검색 도구는 비서에게 언제나 무언가를 말하도록 가르칩니다.
거친 판단 기준
- 질문이 이름 댈 수 있는 파일에서 시작한다 → 업로드로 충분합니다. 아무것도 더하지 마십시오.
- 질문이 기억은 나는데 위치를 모르는 사실에서 시작한다 → 커넥터가 존재하는 이유가 그 경우입니다.
- 수년치 작업이 쌓였고 그 안에서 계속 못 찾고 있다 → 가치는 AI 가 아니라, 사실상 잃어버렸던 자료를 의미로 검색할 수 있게 된다는 데 있습니다.
- 비서가 무엇을 볼 수 있는지 확실해야 한다 → 업로드는 구조적으로 그 확실성을 줍니다. 그대로 쓰십시오.
무엇을 고르시든 "찾을 것이 없는" 시험을 먼저 해보십시오. 질문 하나면 되고, 지금 보고 있는 것이 현실을 보고하는 도구인지 현실을 연기하는 도구인지 알려줍니다.