그 메일은 기억납니다. 봄에 고객사 담당자가 서명된 업무 범위 문서를 첨부해서 보낸 메일입니다. 그런데 어디로 왔을까요? 개인 사서함, 공유 projects@ 사서함, 아니면 아직 연결해 둔 예전 주소였을까요?
결국 세 곳에서 따로 검색하고, 매번 조건을 조금씩 바꿉니다. 나중에는 고객에게 문서를 다시 보내 달라고 하는 편이 쉬워 보입니다.
문제는 저장 위치를 잊었다는 데만 있지 않습니다. 많은 클라이언트가 메일 검색을 현재 열려 있는 폴더로 제한합니다. 오래된 메일을 찾기에는 너무 좁은 범위인 경우가 많습니다. 적절한 검색 범위, 계정 전체를 검색하는 원리, 흐릿한 기억을 구체적인 조건으로 바꾸는 연산자를 살펴보겠습니다.
현재 폴더만으로는 부족한 이유
사서함이 큰 파일 하나였고 검색할 때마다 하드디스크에서 전체를 읽어야 했던 시절에는 한 폴더만 검색할 이유가 있었습니다. 범위를 줄이면 대기 시간이 크게 달라질 수 있었기 때문입니다.
지금은 인덱스와 서버 기능이 중요한 역할을 하지만, 많은 클라이언트에는 기존 동작이 남아 있습니다. 결과가 없으면 메일 자체가 없다고 생각하기 쉽습니다. 사실은 받은편지함을 보고 있고, 메일은 여덟 달 전에 보관 처리됐을 수도 있습니다. 검색이 대부분의 메일을 알림 없이 제외한다면 빈 결과가 메일이 없다는 증거는 아닙니다.
덜 눈에 띄는 경우도 있습니다. Clients/Acme/Invoices를 Clients 아래에 두는 식으로 폴더를 구성했다면, 클라이언트가 Clients 자체만 검색할 때 한두 단계 아래의 메일은 찾지 못합니다. 선택한 폴더는 하위 폴더를 묶는 역할만 할 수도 있습니다.
한 사서함 안의 세 가지 검색 범위
한 사서함에는 세 가지 유용한 검색 범위가 있습니다. 가운데 범위는 폴더 트리를 유지하는 사람에게 특히 편리하지만, 모든 클라이언트가 제공하지는 않습니다.
| 범위 | 검색 위치 | 사용할 상황 |
|---|---|---|
| 이 폴더 | 선택한 폴더만 | 위치를 알고 있고 흔한 단어의 검색 범위를 좁힐 때 |
| 이 폴더와 하위 폴더 | 선택한 폴더와 그 아래의 모든 폴더 | Clients/Acme 아래 전체를 확인할 때 |
| 모든 폴더 | 보관함, 보낸편지함, 휴지통을 포함한 접근 가능한 모든 폴더 | 메일 저장 위치를 기억하지 못할 때 |
하위 폴더를 포함하지 않으면 폴더 트리에서 프로젝트의 전체 대화를 찾을 수 없습니다. 보낸편지함도 중요합니다. 계약에 관한 대화에서 필요한 메일은 본인이 쓴 것일 수도 있습니다.
모든 계정 검색하기
앞의 범위는 여전히 한 사서함 안에 한정됩니다. 하지만 많은 사람은 개인 메일 외에 팀 공유 사서함과 다른 서비스의 연결된 계정도 사용합니다.
계정 전체 검색은 접근 가능한 각 원본에 같은 조건을 실행한 뒤, 결과를 최신순으로 모으고 출처 사서함을 표시합니다. 모든 사서함의 받은편지함만 검색하거나 모든 사서함의 모든 폴더를 검색할 수 있습니다. 전자는 새 메일 확인에, 후자는 위치를 모르는 메일을 찾는 데 적합합니다.
검색 대상은 미리 모아 둔 복사본이 아니라 원래 사서함입니다. 공유 사서함은 저장된 서버에서 검색하고, 연결된 Gmail 계정에는 IMAP SEARCH 명령을 보냅니다. 사전 로컬 동기화는 필요하지 않지만, 최근 메일의 표시 여부는 서버와 인덱스에 달려 있습니다. 삼십 초 전에 도착한 메일이 반드시 즉시 나타나는 것은 아닙니다.
검색 작동 원리
서로 독립적인 열두 대가량의 IMAP 서버에서 결과를 모으는 일은 생각보다 복잡합니다. 이런 어려움이 검색 설계를 설명해 줍니다.
검색어를 서버용 조건으로 바꿉니다. 입력을 분석해 각 서버에 IMAP SEARCH 명령으로 보냅니다. 서버가 검색하고 일치하는 메일의 식별자를 반환합니다. 전체 내용을 내려받은 다음 휴대폰에서 걸러 낼 필요가 없어, 40 GB 사서함에서 특히 유용합니다.
본문 검색에는 인덱스가 도움이 됩니다. 서버가 메일 내용을 직접 훑을 수도 있지만, 큰 사서함에서는 느리고 제한 시간을 넘길 수 있습니다. 전문 검색 인덱스는 속도를 높일 수 있지만 일정한 응답 시간을 보장하지 않습니다. 연결된 계정은 서비스 구현에 의존합니다. Gmail과 Fastmail은 자체 검색 체계를 사용하고, 작은 자체 운영 서버에는 인덱스가 없을 수도 있습니다.
원본은 병렬로 검색합니다. 열 개 사서함을 순서대로 검색하면 열 번의 대기 시간이 누적됩니다. 요청을 동시에 보내고, 도착한 결과부터 모읍니다.
느린 원본에는 제한 시간이 있습니다. 서비스가 제때 응답하지 않으면 건너뛰고 명시적으로 안내합니다. 끝없이 기다리는 대신 아홉 곳의 결과와 열 번째에 관한 알림을 받을 수 있습니다. 이 경우 목록은 불완전하므로 제외된 계정에서 다시 검색해야 합니다.
결과는 수신 시간순으로 합칩니다. 각 서버는 자기 결과만 알기 때문에 공통 목록에는 메일의 내부 날짜를 사용합니다. 이 구현에는 서버 간 공통 관련도 점수가 없습니다. 내부 날짜는 헤더의 날짜와 다를 수 있으며, 가져오기 후에는 특히 주의해야 합니다.
검색 연산자
연산자가 없는 단어는 보낸 사람, 제목, 본문에서 검색됩니다. 연산자는 범위를 좁히며 함께 사용할 수 있습니다. 추가한 조건은 나머지 조건과 AND로 연결됩니다.
| 연산자 | 확인 항목 | 예시 |
|---|---|---|
from: | 보낸 사람 주소 또는 표시 이름 | from:anna@acme.com |
to: | 받는 사람 주소 | to:billing@ |
subject: | 제목만 | subject:invoice |
has:attachment | 파일이 첨부된 메일 | has:attachment |
is:unread | 읽지 않은 메일 | is:unread |
is:starred | 별표나 플래그가 있는 메일 | is:starred |
after: | 지정한 날짜 당일과 이후, 형식은 YYYY-MM-DD | after:2026-04-01 |
before: | 지정한 날짜 이전, 형식은 YYYY-MM-DD | before:2026-07-01 |
larger: | 지정한 크기보다 큰 메일 | larger:10M |
smaller: | 지정한 크기보다 작은 메일 | smaller:200K |
기억할 점은 두 가지입니다. 여러 단어로 된 값에는 따옴표가 필요합니다. subject:"quarterly report"는 제목에서 구문을 검색하고, subject:quarterly report는 제목에서 quarterly를, 메일 전체에서 report를 찾습니다. 정확한 일치 방식은 서버에도 달려 있습니다. 여기서 크기 연산자의 단위 없는 숫자는 메가바이트를 뜻합니다. larger:5는 5 MB입니다. 예전 해석은 킬로바이트였고, 5 KB 기준은 너무 많은 메일을 통과시켜 필터가 작동하지 않는 것처럼 보였습니다.
문법을 외우기 싫다면 검색창 옆 필터 아이콘을 눌러 같은 조건을 양식으로 지정할 수 있습니다.
메일을 찾는 실용적인 검색 예시
분명히 받은 첨부파일.
from:acme has:attachment after:2026-03-01 before:2026-06-01보낸 사람, 첨부파일, 봄철 기간을 지정합니다. 모든 계정과 폴더에서 실행하면 목록을 줄일 수 있지만, 원하는 메일의 위치는 일치 건수에 달려 있습니다.
저장 용량을 차지하는 메일.
larger:20M모든 폴더의 큰 메일을 최신순으로 표시합니다. 공간 사용을 파악하는 데 도움이 됩니다. 필요한 첨부파일은 삭제 전에 저장하세요. 용량을 확보하려면 휴지통을 비우거나 서버에서 영구 삭제해야 할 수 있습니다.
고객에게 약속한 내용.
to:client@example.com after:2026-06-01모든 사서함의 보낸편지함을 검색하면 본인 쪽 대화를 확인할 수 있습니다. 공유 사서함의 답장도 그곳에 저장돼 있고 접근할 수 있다면 포함됩니다.
여기서 열지 않은 것뿐 아니라 실제로 읽지 않은 메일.
is:unread after:2026-07-01모든 사서함에서 서버가 읽지 않음으로 표시한 메일을 찾습니다. 유용한 기준이지만, 그 표시만으로 아직 처리하지 않은 메일이라고 단정할 수는 없습니다.
일부만 기억나는 대화.
subject:"statement of work" larger:100K제목의 구문과 최소 크기로 범위를 줄입니다. 큰 메일이라는 사실이 필요한 첨부파일의 존재를 증명하지는 않습니다. 찾은 파일을 확인하세요.
서버 검색과 로컬 검색
일부 데스크톱 클라이언트는 로컬 복사본을 검색합니다. 빠를 수도 있지만 세 가지 제약이 있습니다. 서버 검색도 지원하는 클라이언트가 있습니다.
로컬 검색은 내려받은 데이터만 봅니다. 캐시가 최근 몇 달 또는 오래된 메일의 헤더만 보관한다면 빈 목록은 데이터 부족 때문일 수 있습니다. 휴대폰의 캐시는 더 작을 수 있습니다. 해당 기기에 설정하지 않은 사서함도 로컬 검색에 포함되지 않습니다.
서버 검색은 기기 캐시로 제한되지 않고 메일 저장 위치에서 실행됩니다. 다만 전체를 찾을 수 있는지는 검색 범위, 접근 가능한 폴더, 권한, 인덱스에 달려 있습니다. 같은 조건이면 기기들은 같은 원본을 조회하지만, 메일 변경과 일시적 장애로 결과가 달라질 수도 있습니다.
제약과 차이점
외부 계정의 검색 품질은 서비스에 달려 있습니다. 각 원격 서버가 IMAP SEARCH를 받고 응답을 결정합니다. Gmail의 단어 분리와 부분 일치는 TrekMail과 다르게 작동할 수 있습니다.
첨부파일 내용은 검색하지 않습니다. has:attachment는 파일이 있는 메일을 찾습니다. 이 검색은 PDF 내부 텍스트를 인덱싱하지 않으며, 별도 문서 검색이 필요합니다.
순서는 관련도가 아니라 시간순입니다. 서버 간 공통 점수는 없습니다. 원하는 메일이 맨 위에 나타나기를 기다리기보다 연산자로 범위를 좁히세요.
원본 수에는 상한이 있습니다. 통합 목록은 최대 25개 사서함을 동시에 다룹니다. 그보다 많으면 특정 사서함에서 검색하는 편이 실용적입니다. 응답 시간은 서버와 조건에 달려 있습니다.
휴지통도 포함합니다. 영구 삭제되지 않았다면 최근 삭제한 메일을 찾을 수 있습니다. 각 결과의 폴더 표시가 위치를 알려 줍니다.
자주 묻는 질문
공유 사서함도 검색하나요?
네. 접근 가능한 공유 사서함을 개인 사서함과 함께 조회하고 결과에 원본을 표시합니다. 읽기 권한이 없는 사서함과 폴더는 제외됩니다.
연결된 외부 계정도 검색할 수 있나요?
네. IMAP으로 조회하고 서비스 표시와 함께 같은 목록에 결과를 보여 줍니다. 유효한 인증 정보와 폴더 접근 권한이 필요합니다.
검색하려고 내 메일을 다른 곳에 보내나요?
조건을 IMAP SEARCH로 바꿔 이미 메일을 보관하는 서버에서 실행합니다. 내용을 제삼자 검색 인덱스로 복사하지 않습니다. 다만 클라이언트가 결과를 표시하는 데 필요한 데이터는 전송될 수 있습니다.
왜 웹 화면이 데스크톱 클라이언트보다 더 많이 찾나요?
클라이언트는 불완전한 로컬 캐시를 검색하고 웹은 서버를 조회하기 때문일 수 있습니다. 범위, 접근 가능한 폴더, 인덱스도 비교하세요. 모든 데스크톱 클라이언트가 로컬 검색만 사용하는 것은 아닙니다.
연산자를 입력하지 않고 날짜로 검색할 수 있나요?
네. 검색창 옆 필터 패널에는 날짜, 보낸 사람, 받는 사람 필드와 읽지 않음, 별표, 첨부파일 조건이 있습니다. 같은 검색 조건을 만듭니다.
왜 일치 정도가 아니라 날짜순으로 표시하나요?
결과가 독립적인 서버에서 오므로 공통 관련도 점수가 없습니다. 이 구현은 내부 날짜로 합칩니다. 연산자를 사용해 목록을 줄이세요.
스팸 폴더도 검색하나요?
모든 폴더 범위에는 접근 가능한 스팸 폴더도 포함됩니다. 필터가 메일을 잘못 옮겼다면 검색으로 확인할 수 있습니다. 찾았다면 메일이 스팸으로 분류되는 이유도 살펴보세요.
