AI에게 "그 메일 좀 찾아줘"라고 부탁했는데 아무것도 나오지 않았을 때, 그것은 메일이 없는 것일까, 아니면 AI가 찾지 못하고 있는 것일까. 이 두 가지를 구분하지 못한 채 사용하고 있는 사람이 많다고 생각합니다. 저도 그랬습니다.

Claude에는 Gmail과 Google Calendar를 직접 읽게 하는 기능 (Connector)이 있습니다. 공식 도움말에는 "메일과 캘린더를 검색할 수 있습니다"라고만 적혀 있습니다. 정작 중요한 어디까지 가능한지는 적혀 있지 않습니다. 반년 전의 메일도 도달할까요? "견적"이라고 입력했을 때 "견적서"를 찾아낼 수 있을까요? 스레드 중간에 결론이 뒤집혔다면, 어느 쪽을 답할까요?

이 부분을 모르면 AI에게 맡길 업무의 범위를 정할 수 없습니다. 너무 많이 맡기면 놓치는 부분을 알아차릴 수 없고, 너무 적게 맡기면 직접 전부 읽어야 하는 상황이 됩니다.

그래서, 자신의 수신함에 테스트 데이터를 74통 심어둔 뒤 질문하는 방법으로 측정했습니다 (2026-07-24 실측). 정답을 알고 있는 상태를 먼저 만들어 두면, AI가 "찾은 것"뿐만 아니라 "놓친 것"까지 셀 수 있습니다.

결론부터 말씀드립니다. 10문제 중 9문제 정답. 틀린 것은 단 1개였으며, 그것은 "첨부파일의 내용"이었습니다. 착수 전 저의 예상은 "기간의 벽 때문에 틀릴 것이다", "표기 불일치로 틀릴 것이다", "스레드의 결론을 오해할 것이다"였으나, 세 가지 모두 빗나갔습니다.

그리고 틀린 한 문제에는, 이 기사에서 가장 쓰고 싶었던 뒷이야기가 있습니다. 읽지 못했을 때, AI가 무엇을 했는가입니다.

측정 방법: 수신함에 "정답을 알고 있는 메일"을 심기

방법은 간단합니다. AI에게 묻기 전에 스스로 정답을 만들어 둡니다.

검증용 Gmail 계정에 스크립트로 메일 74통을 삽입했습니다. 내역은 정답 확인의 대상이 되는 타겟 14통과, 그 14통을 묻히게 만들기 위한 더미(Dummy) 60통입니다. 캘린더에는 21건의 일정을 넣었습니다. 바늘을 찾게 하려면 먼저 짚더미를 쌓아두어야 합니다.

여기서 예상치 못했던 점이 하나 있습니다. "이 계정은 비어 있을 것"이라고 생각하고 열었더니, 기존 메일이 약 1,190통 있었습니다. 각종 서비스의 알림류입니다. 실험에 방해가 될까 잠시 생각했지만, 반대였습니다. 직접 쌓은 60통의 더미보다, 실제 1,190통이 훨씬 현실적인 탐색 부하입니다. 결과적으로 "실제 수신함에서 어떻게 동작할까"에 가까운 조건이 되었습니다.

심어둔 타겟은 다음과 같은 구성입니다.

검증 조건도 갖추었습니다.

환경: claude.ai (Pro), 모델 Sonnet 5, 사고의 깊이 (effort) 최대, Web 검색은 OFF -
실행일: 2026-07-24 -
질문마다 새로운 채팅을 열기 (이전 답변의 영향을 없애기 위해) - 준비부터 실험까지
반나절 이상 간격을 두기 (검색 인덱스 반영을 기다리기 위해) - 판정은 미리 기계 생성해 둔 정답 대장과 대조

검증 1: 2년 전 메일까지 도달하는가 — 6/6

먼저, 실무에서 가장 곤란한 "어디까지 거슬러 올라갈 수 있는가"부터 시작합니다.

츠구미 대장 통합에 관한 메일을 기간 제한 없이 모두 찾아주세요. 발견된 모든 메일의 제목과 수신일을 목록으로 만들어 주세요.

결과는 6통 중 6통. 2024년 7월의 킥오프부터 2026년 7월의 최종 확인까지, 제목과 수신일을 표로 만들어 반환했습니다.

흥미로웠던 점은, 묻지 않은 검색 과정을 스스로 설명해 왔다는 것입니다.

제목에 "츠구미 대장 통합"을 포함하는 완전 일치 검색 외에도, 발신자·키워드 단독·전체 폴더 (스팸/휴지통 포함)에서도 횡단 검색을 수행했으나 모두 동일한 결과가 나왔으므로, 이것으로 망라할 수 있다고 판단된다는 내용입니다.

제목뿐만 아니라 발신자로도 다시 확인하고, 스팸과 휴지통까지 살펴보았습니다. "6건을 찾았습니다"로 끝내지 않고 "이 6건이 전부라고 생각하는 근거"를 덧붙인 것입니다. 망라성을 묻는 질문에 대해 이것은 올바른 답변 방식입니다.

다만, 여기서 측정할 수 있었던 것은 "2년 전까지는 도달한다"까지입니다. 그보다 더 오래된 메일은 심어두지 않았으므로, 3년 전이나 5년 전 메일이 도달할지는 알 수 없습니다.

검증 2: "견적"으로 "견적서"를 찾아낼 수 있는가 — 정답

일본어 검색에서 가장 많이 실수하는 부분이 표기 불일치(表記ゆれ)입니다. 제목은 「御見積書のご送付につきまして(견적서 송부의 건)」이고, 질문은 「見積もり(견적)」입니다.

하루카제 상사로부터 견적 메일이 왔을 것입니다. 찾아서 금액을 알려주세요.

한 번에 특정하여, 328,900엔이라고 정답을 맞혔습니다. 「御見積書」라는 송리 가나(送り仮名)나 경어 접두사도 다른 표기를 의미로 흡수해낸 것입니다.

답변에 이르는 과정을 보면, AI는 첫 번째 키워드에서 포기하지 않고 표현을 바꾸어 다시 검색을 시도합니다. 제목의 문자열을 그대로 찾아가는 검색과는 이 점이 다릅니다.

나아가 이 답변에는 다음 검증을 위한 복선이 포함되어 있었습니다.

본문에는 금액 이외의 내역(품목, 수량 등)이 기재되어 있지 않으며,

첨부 파일의 유무도 이 정보만으로는 확인할 수 없습니다.

묻지도 않았는데 「첨부에 대해서는 알 수 없다」고 신고합니다. 이 한 문장이 다음 단계에서 결정적인 역할을 합니다.

검증 3: 유일한 사각지대 — 첨부 파일의 내용물

본론입니다. 본문에는 금액을 쓰지 않고, 첨부된 xlsx 파일 안에만 4,872,000엔을 넣은 메일을 준비했습니다.

사쿠라다 창고의 개보수 비용은 총액이 얼마입니까? 수신 메일에서 조사해 주세요.

대답하지 못했습니다. 이것이 10개 문항 중 유일하게 실패한 질문입니다.

하지만, 여기서부터가 핵심입니다. AI는 금액을 추측하지 않았습니다.

Gmail 첨부 파일의 내용을 직접 다운로드하거나 압축을 푸는 도구가 없어서 (본문과 메타데이터는 읽을 수 있어도, 첨부 바이너리 자체는 취득할 수 없음), Google Drive 내부도 찾아보았지만 동일한 파일은 발견되지 않았습니다.

수행한 작업을 순서대로 보면 다음과 같습니다.

• 해당 메일을 특정함 (발신자, 제목, 수신일, 본문까지 정확함)
• 본문에 금액이 없음을 확인함
• 동일한 파일이 Google Drive에 있는지 찾아봄 (이는 지시하지 않았음) - 어디에도 없다는 것을 알게 된 시점에서 「읽을 수 없다」고 말함
• 「Gmail에서 직접 열기」, 「이 채팅에 업로드하기」라는 두 가지 대안을 제시함

실무에서 정말 무서운 것은, 읽지 못하면서도 그럴싸한 숫자를 내놓는 동작입니다. 「메일의 문맥으로 추정하면 500만 엔 전후로 보입니다」라고 적힌다면, 받는 쪽에서는 알아차릴 수 없습니다. 그런 일은 일어나지 않았습니다.

참고로, 이것은 숨겨진 결함을 발견한 이야기가 아닙니다. AI 스스로가 「첨부 바이너리를 취득하는 도구가 없다」고 설명하고 있듯이, 애초에 읽을 수 있는 수단이 마련되어 있지 않다는 설계상의 범위 문제입니다.

가치가 있는 점은 「읽을 수 없는 영역이 실무에서 어떻게 나타나는가」를 구체적으로 알게 되었다는 것입니다. 견적서, 청구서, 사양서와 같이 본체가 첨부 파일에 있는 업무는 커넥터(Connector)에만 맡길 수 없습니다.

검증 4: 번복되는 스레드에서 어디를 결론으로 볼 것인가 — 정답

3통의 주고받은 메일을 준비했습니다. 1통째에 A안과 B안을 제시, 2통째에 「A안은 유지보수 업체(Vendor)의 지속이 어렵다」는 정보가 들어오고, 3통째에 드디어 결론이 나옵니다. 결론은 마지막 메일에만 있습니다.

히바리 회의실 예약 시스템 교체 건에 대해, 최종적으로 어떤 결론이 났습니까? 도입 시기도 알려주세요.

B안 (클라우드 이전)으로 확정, 9월 도입, 9/28 심야 전환 — 모두 정답이었습니다.

게다가 3통의 흐름을 날짜가 포함된 표로 만들어, 「누가 언제 무엇을 말했는지」를 재현하고 있습니다. 1통째에 적힌 A안을 결론으로 착각하는 일은 없었습니다.

답변의 마무리도 실무적입니다.

이후의 새로운 메일은 이 스레드에서 발견되지 않으므로, 7/15 시점의 내용이 최신 결론입니다.

「언제 시점의 결론인지」를 명시하고 있습니다. 스레드의 다음 내용이 있을 수 있다는 전제로 답하고 있다는 뜻입니다.

검증 5: 미대응 항목만 나열하고, 대응 완료 항목은 제외하는가 — 정답

여기는 함정을 설치했습니다. 기한이 정해진 메일을 2통 준비하고, 한쪽에는 본인의 답장을 붙여 두었습니다.

• 코스모스 감사법인: 기한 7/31, 답장 없음 → 나열하는 것이 정답
• 스미레 설비 점검: 기한 7/25, 7/12에 제출 완료된 답장 있음 → 나열하면 오탐(False Positive)

수신함을 확인하여, 답변 기한이나 제출 기한이 설정되어 있음에도 아직 대응하지 않은 메일이 있다면 나열해 주세요. 대응이 완료된 것은 제외해 주세요.

코스모스 감사 1건만을 나열하고, 스미레는 제외했습니다. 게다가 제외 이유까지 적고 있습니다.

스미레 설비 점검 「보고서 제출 요청 (기한 7/25)」 → 수신 당일 (7/12)에 제출 완료된 답장 있음

이것은 검색만으로는 해결할 수 없습니다. 기한이 있는 메일을 찾기 → 각각에 대해 자신의 답장이 있는지 확인하기 → 답장이 없는 것만 남기기라는 절차가 필요합니다. 답장 유무까지 확인한 결과로서, 정확히 1건으로 압축되었습니다.

또한 기존 메일 1,190통 중에서도 AI는 자발적으로 1건(기한이 3개월 전에 만료된 제품 공지 메일)을 찾아내어, "이것은 제품 측의 공지이므로 대상 외로 판단했으나 만약을 위해 언급한다"라고 부연 설명을 덧붙였습니다. 판단하여 제외한 것을 말없이 버리지 않고 보고하는 행동입니다.

검증 6: 캘린더는 5개 질문 모두 정답

캘린더는 5개의 질문을 한꺼번에 던졌습니다. 심어둔 21건의 일정에는 각각 함정이 있습니다.

① 향후 2주간의 일정 (종일 일정 포함)

정답은 7건. 7건 모두 일치했습니다. 이 중에는 두 가지 함정이 있습니다.

종일 일정(카와세미 재고 조사 데이) — 시간 정보가 포함된 일정과 섞여 있어도 놓치지 않는가 -
자정 너머(요타카 야간 유지보수, 23:30 시작·익일 00:30 종료) — 어느 날짜에 배치할 것인가

자정 너머 일정은 「8/2 (일) ~ 8/3 (월) 23:30-00:30」과 같이, 날짜를 넘어간다는 사실까지 포함하여 정확하게 표시했습니다.

② 다음 달 월요일 일정

이것이 가장 어려운 질문입니다. 「츠구미 정례 회의」는 매주 월요일 반복 일정으로 등록되어 있습니다. 캘린더 데이터상 반복 일정은 「매주 월요일에 26회」라는 규칙이 한 줄 있을 뿐, 개별 날짜는 실체로서 존재하지 않습니다.

답변은 8/3, 8/10, 8/17, 8/24, 8/31의 5회 모두를 정확하게 전개하였으며, 나아가 같은 월요일에 포함되어 있던 단발성 일정 2건(온라인 스터디·방재 훈련)도 찾아냈습니다. 규칙을 미래의 날짜로 전개할 수 있다는 뜻입니다.

③ 회의 준비물

「인증 토큰 HB-2291」이라는 정보를 일정의 설명란에만 적어 두었습니다. 제목에도 장소에도 적지 않았습니다.

정확하게 대답했습니다. 설명란까지 읽고 있습니다.

④ 2028년 일정 / ⑤ 작년 일정

2년 후의 일정 (2028/07/22)과 1년 전의 일정 (2025/07/23)을 모두 일시까지 정확하게 찾아냈습니다. 미래와 과거를 통틀어 적어도 2년의 사정거리를 가집니다.

사각지대 맵: 6개 축으로 측정하여 떨어진 것은 1개

서두에 썼듯이 제 예상은 빗나갔습니다. "기간의 벽에 막힌다", "표기 불일치로 막힌다", "스레드의 결론을 오해한다" —— 이 중 어느 것도 일어나지 않았습니다.

실무에 어떻게 적용할 것인가

이 결과에서 도출할 수 있는 결론은 명확합니다.

맡겨도 좋은 업무

• 과거의 주고받은 내용을 시계열로 정리하기 (2년 전까지 도달)
• "그 건 어떻게 됐지?"의 결론을 추적하기 (스레드의 최종 판단을 포착 가능)
• 기한이 있는 미대응 건을 찾아내기 (대응 완료된 건을 제외 가능)
• 일정 확인 전반 (반복·종일·먼 미래 포함)

맡길 수 없는 업무

• 첨부 파일의 내용이 답이 되는 질문. 견적서·청구서·사양서·설계서가 이에 해당합니다.

그리고 운용상 가장 중요한 것은, 첨부가 포함된 질문을 했을 때의 답변을 의심하지 않아도 된다는 사실을 알게 된 것입니다. 읽을 수 없을 때는 읽을 수 없다고 말합니다. 따라서 "첨부는 읽을 수 없을 텐데 숫자가 답변으로 돌아왔다"면, 본문 쪽에 적혀 있었을 가능성이 높다고 판단할 수 있습니다.

또 하나, 이번 결과는 1개 계정·1일·1개 모델에서의 실측입니다. 수신함의 규모나 언어, 모델이 바뀌면 결과는 달라질 수 있습니다. 그대로 일반화할 수는 없습니다.

자신의 수신함에서 테스트하려면

같은 일을 테스트 데이터를 따로 준비하지 않고도 어느 정도 할 수 있습니다. 자신이 답을 알고 있는 메일을 사용하면 되기 때문입니다.

• 반년 이상 전의, 자신이 내용을 기억하고 있는 메일을 하나 고른다
• 그 메일에 대해 위의 6가지 유형으로 질문해 본다 (기간·표기 불일치·첨부·스레드·감사·캘린더)
• 정답 확인은 자신의 기억과 실제 메일로 한다

이번에 사용한 프롬프트는 그대로 유용할 수 있습니다. 고유명사만 교체해 주세요.

① ○○에 관한 메일을 기간을 제한하지 말고 모두 찾아주세요.
찾은 모든 메일의 제목과 수신일을 목록으로 만들어 주세요.
② ○○로부터 견적 메일이 왔을 것입니다. 찾아서 금액을 알려주세요.
...

⑤는 단독으로도 사용할 수 있습니다. 기한이 정해진 답장을 하지 않은 메일을 찾아내는 것은 실험을 떠나 일반적인 상황에서도 유용했습니다.

마치며

"어디까지 읽을 수 있을지 모르니 맡길 수 없다"라는 상태는, 측정하면 끝납니다. 이번에 소요된 시간은 준비용 스크립트를 작성하는 데 몇 시간, 실험 자체는 30분 정도였습니다.

AI에게 일을 맡길 때 가장 효과적인 것은 고도의 프롬프트 (Prompt)가 아니라, 맡길 범위의 선을 어디에 그을 것인가를 스스로 확인해 두는 것이라고 생각합니다. 선을 그을 수 있다면, 그 안쪽은 안심하고 맡길 수 있습니다.

같은 발상으로 "AI에게 설계서 리뷰를 어디까지 맡길 수 있는가"를 측정한 실험도 있습니다. 실제 설계서에 결함을 심어두고 검출률을 측정한 결과, 요청 방식에 따라 0%에서 86%까지 변했습니다. 그때 만든 프롬프트 (Prompt) 세트는 note에 정리해 두었습니다.

• Zenn: "이 설계서, 리뷰해 줘"라고 부탁했을 때 검출률 0%였던 건
• note (유료): "이 설계서, 리뷰해 줘"를 졸업하는 실전 패키지

Discussion