Claude 가 내 파일을 읽을 수 있게 되면 실제로 무엇을 물어볼 수 있나
로컬 검색 도구를 Claude 에 붙이면 물어볼 만한 것의 성격이 달라집니다. 처음에는 계속 파일 이름을 대게 됩니다 — 그동안의 모든 검색 도구가 그걸 요구했으니까요. 그러지 않아도 된다는 걸 알아차리는 데 몇 번의 대화가 걸립니다.
아래 다섯 시나리오가 대부분의 질문이 취하는 모양을 덮습니다. 마지막 하나는 찾을 것이 없는 경우인데, 그게 나머지 넷을 믿을 수 있는지를 결정합니다.
시나리오 1 — 열어보지 않은 계약서에 대한 질문
상황: 상대방이 책임 조항을 물어봅니다. 몇 달 전 여러 판본에 걸쳐 협상했고, 결과는 대략 기억나지만 정확히는 아닙니다.
입력:
공급계약에서 책임 관련해서 결국 어떻게 합의했지? 우리가 뭔가 반대했던 걸로 기억하는데.
일어나는 일: Claude 가 파일명이 아니라 의미로 검색합니다. 초안들과 그 주변 메일 스레드를 가져오는데, 각각에서 여러 대목이 함께 옵니다 — 제목만이 아니라 조항과 그것을 둘러싼 논쟁이 보일 만큼. 그리고 결과를 답하면서 각 부분이 어느 파일에서 나왔는지 밝힙니다.
파일명 검색보다 나은 이유: 당신은 파일명을 몰랐습니다. 내용에 관한 사실을 알았을 뿐입니다. 키워드 검색이라면 문서에 쓰인 정확한 표현을 짐작해야 하는데, 정작 중요한 초안에는 "책임"이 아니라 "손해배상의 제한"이라고 적혀 있을 수 있습니다.
시나리오 2 — 어렴풋이 기억나는 메일
상황: 누군가 일정 변경을 알려왔습니다. 읽은 건 기억나는데 누가 보냈는지, 언제인지는 모릅니다.
입력:
검토 회의가 옮겨졌다고 누가 알려줬는데, 그 메일 찾아서 새 날짜랑 보낸 사람 알려줘.
일어나는 일: 메일이 문서와 함께 색인되므로 검색은 한 번입니다. 결과는 제목·발신자·시각으로 자기를 밝힙니다 — 메일 내보내기가 디스크에 실제로 남기는 알아볼 수 없는 파일명이 아니라. 여러 메시지가 걸리면 Claude 가 회신 사슬을 따라가 가장 마지막 것을 찾을 수 있습니다.
이렇게 해서 피하는 실패: 나중에 뒤집힌 스레드 초반 메시지로 답하는 것. 히트가 아니라 스레드를 가져오는 것이 답을 믿을 만하게 만듭니다.
시나리오 3 — 스프레드시트 속 숫자
상황: 몇 달 열어보지 않은 통합문서에서 수치 하나가 필요합니다.
입력:
2분기 예산 파일에서 외주비를 얼마로 잡았지? 어느 시트 어느 셀인지도 알려줘.
일어나는 일: 스프레드시트를 텍스트 덩어리로 납작하게 만들지 않고 구조로 읽으므로 셀 좌표·시트 이름·병합 범위가 살아 있습니다. Claude 가 값과 그 값이 어디 있는지를 함께 말할 수 있고, 그래서 답을 검증할 수 있습니다.
알아두실 것: 날짜로 저장된 값은 날짜로 돌아옵니다. 스프레드시트가 내부에 갖고 있는 원시 일련번호가 아니라요. 사소해 보이지만, AI 가 마감일이 1900년이라고 자신 있게 말하기 전까지만 그렇습니다.
시나리오 4 — 시간에 따라 무엇이 바뀌었나
상황: 문서가 여러 판을 거쳤고, 무엇이 움직였는지 알아야 합니다.
입력:
이 계약서 판본들에서 대금 지급 조건이 어떻게 바뀌었는지 오래된 것부터 순서대로 보여줘.
일어나는 일: 같은 문서의 판본들이 이름만 비슷한 남남이 아니라 서로 관련된 것으로 인식됩니다. Claude 가 순서대로 늘어놓고 사이에 무엇이 달라졌는지 서술하며, 각 판본을 인용합니다.
도움이 되는 한 수: 순서를 명시적으로 요구하는 것. "오래된 것부터"라는 값싼 한마디가 매치 더미를 이야기로 바꿉니다.
시나리오 5 — 찾을 것이 없을 때
사람들이 건너뛰는 시나리오이고, 나머지 넷을 믿을 수 있는지를 결정하는 시나리오입니다.
입력:
외주 인력 비용 정산 정책 찾아줘.
그런 문서가 없다면: 응답이 무엇을 뒤졌고 질의를 어떻게 읽었으며 일치하는 것이 없다고 말합니다 — 가장 가까운 것을 돌려주고 Claude 가 그것을 정책인 양 서술하게 두는 대신에요. 질의는 해석됐지만 결과가 없었다면 그렇게 말하고, 질의 자체가 성립하지 않았다면(예: 모든 낱말이 불용어였다면) 그것도 그럴듯한 목록 대신 사실대로 말합니다.
이게 어떤 성공 사례보다 중요한 이유: 언제나 무언가를 돌려주는 검색 도구는 AI 에게 언제나 무언가를 말하도록 가르칩니다. 보이지 않는 실패가 비싼 실패입니다.
실망스러운 결과 대부분을 고치는 한 수
첫 시도가 얄팍하게 돌아온다면 — 파일은 많은데 각각 한 문장씩이고 정작 답이 없다면 — 대개 원인은 커넥터에게 답하라가 아니라 찾아라를 시킨 것입니다. 둘은 필요한 재료의 양이 다릅니다. 찾기는 문서를 많이 짧게, 답하기는 적게 길게 원합니다.
특별한 문법은 필요 없습니다. 원하는 것을 말하면 됩니다.
파일 목록만 주지 말고 읽어서 질문에 답해줘.
저희 시험 질의 묶음에서 두 방식의 차이는 결과당 문서 내용 약 176자 대 약 1,850자였습니다 — 티저와 한 페이지의 차이입니다. 대개 그것이 "뭔가 찾긴 했네"와 "답을 해줬네" 사이의 간격입니다.
엉뚱한 종류가 나올 때 방향 잡기
검색은 잘 됐는데 섞인 비율이 틀린 경우가 있습니다 — 사내 문서를 원했는데 메일이 주로 나왔다든가, 그 반대라든가. 응답에는 걸지 않은 축들이 실제 건수와 함께 실립니다. 예를 들어 문서 11건, 메일 9건. 애매함이 조용히 해소되는 대신 눈에 보입니다.
그러면 어느 쪽인지만 말하면 됩니다.
메일만, 그리고 올해 것만.
Claude 가 그 제약으로 다시 부릅니다. 갈림을 드러내는 이유는 둘 중 누구도 추측하지 않아도 되게 하기 위해서입니다 — 커넥터는 찾은 것의 모양을 보고하고, 고르는 것은 당신입니다.
기기에 남는 것
"로컬"이라는 말이 느슨하게 쓰이므로 정확히 적겠습니다. 색인과 검색은 당신 컴퓨터에서 돕니다 — 검색하려고 파일을 어딘가에 올리지 않습니다. 오가는 것은 대화입니다. 당신의 질문과, Claude 가 근거로 삼기로 고른 대목들이 모델로 갑니다. 당신이 직접 붙여넣었을 때와 똑같습니다. 중요한 차이는 이제 어느 파일을 붙여넣어야 하는지 알 필요가 없다는 것입니다.