Pool로 스크린샷 자동 인덱싱 — Raycast, Spotlight 비교

목차

스크린샷 폴더에 이미지 3,412장이 쌓여 있었고 그중 다시 들여다본 건 50장도 안 된다. Pool을 도입해 그 폴더를 검색 가능한 라이브러리로 바꿨고, Raycast 확장과 Spotlight으로도 같은 작업을 시도해 항목별로 비교한 결과를 정리한다.

5년차 입장에서 새 도구는 보수적으로 본다. 잘 돌아가는 워크플로우는 잘 안 건드린다. 다만 스크린샷 폴더는 잘 돌아가는 게 아니라 그냥 방치된 거였다. 디자인 시안, 에러 화면, 채팅 캡처, 영수증, 회의 화이트보드까지 한 폴더에 다 들어가 있다. 검색이 안 되니 자료를 다시 쓸 일이 생겨도 찾는 데 시간이 더 걸린다.

게다가, 이 글은 Pool 단독 리뷰가 아니라 후보 3종의 항목별 비교다. 주관적 의견은 마지막 섹션에서만 꺼낸다.

스크린샷 폴더가 자료가 아닌 이유

그런데, OS 기본 동작은 파일명에 타임스탬프만 박는다. Screen Shot 2026-04-18 at 11.23.47.png 같은 이름이다. 시간순 정렬 외에는 어떤 정보도 없다. 무엇을 찍었는지, 왜 찍었는지, 어디서 다시 쓸 건지 메타데이터가 0이다.

결국, 이게 누적되면 폴더 크기는 늘어나는데 가치는 줄어든다. 필자의 경우 23개월치 폴더가 4.2GB였고 파일 수는 3,412장이었다. 디스크 비용은 사소하지만 인지 비용이 크다. "그때 그 502 에러 메시지 어디 있더라" 같은 검색을 하려고 해도 파일명으로는 불가능하다. 결국 macOS Finder의 미리보기 스크롤로 눈으로 훑는 게 가장 빠르다. 5분 이상 걸리는 작업이 된다.

해결 방향은 세 가지로 좁혀진다. 첫째 스크린샷을 안 찍는 것. 둘째 찍을 때마다 수동 태깅하는 것. 셋째 이미 쌓인 것까지 자동으로 인덱싱하는 것. 첫째는 비현실적이고 둘째는 작심삼일이다. 세 번째 방향에서 Pool, Raycast 확장, Spotlight 셋을 후보로 올렸다.

비교 기준 — 다섯 항목으로 좁혔다

한편, 평가 기준은 단순하다. 도구를 도입했을 때 운영 비용이 얼마나 줄어드는가. 이 관점에서 다섯 가지로 좁혔다.

  1. 설치와 초기 설정 시간 — 기존 폴더 백필 포함
  2. 검색 방식 — 키워드 매칭이냐 의미 기반이냐
  3. 자연어 질의 정확도 — "지난주 그 502 에러" 같은 모호한 질의 처리
  4. 비용 — 라이선스, API 호출, 디스크
  5. 프라이버시 — 이미지가 외부로 나가는지 여부

또한, 벤치마크 데이터셋은 23개월치 폴더에서 무작위 200장을 샘플링했다. 카테고리 비율은 코드 화면 38%, 디자인 시안 19%, 채팅 캡처 23%, 기타 20%로 실제 분포와 맞췄다. 질의 10개는 미리 정해두고 세 도구에 동일하게 입력했다.

후보 3종 — 무엇을 하는 도구인가

Pool

예를 들어, 스크린샷을 자동으로 OCR + 임베딩 처리해서 검색 가능한 라이브러리로 만드는 도구다. 2026년 6월 기준 macOS 위주로 알려져 있고, 로컬 모델과 클라우드 모델을 선택할 수 있는 구조로 보인다. 백그라운드에서 신규 스크린샷을 감지해 인덱싱하는 방식이고, 검색은 자연어 질의를 받아서 임베딩 유사도로 정렬한다.

Raycast + 스크린샷 확장

Raycast는 이미 익숙한 런처고, 커뮤니티 확장 중에 스크린샷 검색이 존재한다. OCR은 macOS Vision 프레임워크를 그대로 쓴다. LLM은 호출하지 않는다. 키워드 매칭 위주라 정확한 토큰이 들어간 이미지에서는 강하다.

Spotlight + 수동 태깅

OS 기본 도구다. 파일 태그를 수동으로 붙이고 Spotlight에서 검색한다. 추가 설치가 없는 만큼 가장 가볍지만, 사람의 손이 들어간다. macOS Sequoia 이후 Visual Look Up이 이미지 내 텍스트 일부를 잡아주긴 한다.

항목별 비교

전체 비교는 한 번만 표로 정리한다.

항목 Pool Raycast 확장 Spotlight
초기 설정 DMG 설치 + 폴더 지정 + 백필 (필자 환경 약 18분) 확장 설치 1분, 백필 미지원 0분 (이미 켜져 있음)
OCR 엔진 자체 + Vision 선택 Vision (Apple) Vision (자동)
의미 기반 검색 임베딩 기반 지원 키워드만 키워드만
자연어 질의 "노란색 경고창" 가능 텍스트 토큰만 텍스트 토큰만
신규 인덱싱 자동 감지 검색 시 캐시 자동
비용 로컬 무료 / 클라우드는 별도 무료 무료
프라이버시 모델 선택에 따라 다름 전부 로컬 전부 로컬

표 한 줄로 끝나지 않는 항목은 따로 풀어서 본다.

초기 설정과 백필

가장 큰 차이는 백필이다. Pool은 기존 폴더를 한 번 훑어서 전체 인덱싱한다. 필자 환경(M2 MacBook Pro, 3,412장)에서 18분이 걸렸다. 클라우드 모델로 돌리면 더 짧지만 그만큼 데이터가 외부로 나간다.

Raycast 확장은 백필을 안 한다. 검색할 때마다 폴더를 스캔하고 OCR을 그때 돌린다. 처음 검색은 5초 이상 걸리고 캐시가 쌓이면 빨라지는 구조다. 폴더가 작을 때는 문제없지만 3천 장 단위에서는 첫 검색이 답답하다.

Spotlight는 OS가 알아서 인덱싱한다. 추가 작업이 없다는 게 장점인데, 인덱싱 내용 자체가 파일명과 일부 메타데이터로 한정된다. 이미지 안의 텍스트는 OS 버전에 따라 잡히기도 하고 안 잡히기도 한다.

검색 방식의 차이

그래서, Raycast 확장과 Spotlight는 둘 다 키워드 매칭이다. 이미지에서 추출한 텍스트와 질의어를 토큰 단위로 비교한다. "502" 같은 정확한 토큰은 잘 잡지만 "에러 박스" 같은 추상적 표현은 못 잡는다.

Pool은 임베딩 기반이다. 이미지 임베딩과 질의 임베딩을 비교해서 유사도 상위를 반환한다. "노란색 경고창"처럼 시각 단서가 강한 질의에서 차이가 크게 벌어진다.

기술적으로 보면 검색 비용 구조가 다르다. 키워드 매칭은 인덱스 한 번 만들면 검색이 거의 무료다. 임베딩은 질의마다 한 번 인코딩을 해야 해서 미미하지만 비용이 든다. 로컬 모델 기준으로는 무시할 수준이다.

같은 질의 10개로 정확도 테스트

예를 들어, 샘플 200장에서 10개 질의를 돌렸다. 질의 예시는 이렇다.

  • "지난주 502 에러 스크린샷"
  • "노란색 배경 경고창"
  • "PR 리뷰 코멘트 중에 typo 지적한 거"
  • "회의 화이트보드에서 ERD 그린 사진"
  • "Cursor 자동완성 후보 목록"

한편, Top-3 정확도(원하는 이미지가 상위 3개 안에 포함된 비율)로 측정했다.

물론, :::stats Pool: 73% Raycast 확장: 41% Spotlight: 18% :::

그러나, Pool이 의미 기반 질의에서 강했다. "노란색 배경 경고창"처럼 텍스트가 적고 시각 단서가 큰 경우는 Raycast와 Spotlight가 거의 못 잡았다. 반대로 "ERROR_CODE_502_GATEWAY" 같은 정확한 토큰 질의에서는 셋 다 비슷하게 잘 찾았다.

흥미로운 건 정확도 차이가 카테고리에 따라 갈렸다는 점이다. 코드 스크린샷처럼 OCR이 잘 먹는 영역에서는 Raycast도 충분했다. 디자인 시안이나 화이트보드처럼 텍스트가 적은 영역에서 격차가 벌어졌다. 도구의 우열을 단정하기 전에, 본인 폴더의 카테고리 분포를 먼저 봐야 한다는 뜻이다.

비용과 프라이버시

따라서, 라이선스 비용만 보면 Spotlight가 0원이라 압도적이다. 다만 실제 비용은 사람 시간이다. 필자의 경우 스크린샷에서 뭔가 찾는 데 평균 4분이 걸렸다. Pool 도입 후 체감상 45초 정도로 줄었다. 주 5회 검색을 가정하면 월 1시간 회수된다.

결국, Pool 클라우드 모델은 호출당 과금이고, 로컬 모델은 무료다. 인덱싱이 한 번 끝나면 검색 자체는 가벼워서 로컬 모델로도 충분하다는 게 1주일 운영 결과다.

예를 들어, 프라이버시는 회사 노트북에 깔 거면 1순위 기준이다. Spotlight와 Raycast 확장은 전부 로컬에서 돈다. 이미지가 외부로 나가지 않는다. Pool은 모델 선택에 따라 다르다. 로컬 모델을 고르면 디바이스를 떠나지 않는다. 클라우드 모델은 OCR이나 임베딩 단계에서 이미지 또는 텍스트가 외부로 전송된다. 사내 자료를 다루는 환경이라면 기본값을 로컬로 잠그는 게 안전하다.

운영하면서 드러난 한계

따라서, Pool의 의미 기반 검색이 만능은 아니다. "그 회의 끝나고 찍은 것"처럼 시간 외 맥락이 들어가는 질의는 못 잡는다. 임베딩이 시간 정보를 모르기 때문이다. 이건 워크플로우 차원에서 보완해야 한다. 폴더를 월별로 나누거나 캡처 시 캡션을 자동으로 붙이는 식이다.

물론, OCR 신뢰도도 폰트 따라 갈린다. 디자인 시안에서 자주 쓰는 가는 헤어라인 폰트는 잘 못 읽었다. Vision 기반인 Raycast와 Pool 둘 다 같은 약점이 있다. 이 부분은 어느 도구를 골라도 비슷한 한계로 남는다.

결국, 백그라운드 인덱싱이 배터리에 영향을 주는 점도 있다. 노트북 뚜껑을 닫은 상태에서는 일시 중지하도록 설정하는 게 낫다. 필자는 AC 어댑터 연결 시에만 인덱싱이 돌도록 옵션을 잡았다.

결론 — 환경에 따라 답이 갈린다

객관적 비교는 표와 벤치마크로 끝났다. 여기서부터는 의견이다.

물론, 코드 스크린샷이 대부분이고 사내 자료 비중이 큰 환경이면 Raycast 확장이 합리적이다. 무료, 로컬, 의존성 없음의 3박자가 맞는다. Spotlight는 OS 업데이트로 점점 좋아지고 있어서 정말 가볍게 쓸 거면 그것만으로도 충분하다.

게다가, 디자인 자료나 화이트보드, 시각 단서가 강한 이미지가 많은 환경이면 Pool의 의미 기반 검색이 효과가 크다. 디자인 비중이 19%에 불과한 필자 폴더에서도 Top-3 정확도 차이가 32%p였다. 비중이 더 큰 환경이면 격차는 더 벌어질 거다.

당장 실행할 수 있는 액션 세 가지다. 첫째 본인 스크린샷 폴더에서 카테고리 분포를 한 번 세본다. 둘째 코드/텍스트 위주면 Raycast 확장부터 깐다. 셋째 디자인/화이트보드 위주면 Pool 로컬 모델로 백필을 돌려본다.

다음에는 Pool에 MCP 연동을 붙여서 Claude에서 직접 스크린샷을 질의하는 워크플로우를 시도해볼 생각이다.

관련 글