파일 정리 방식은 파일 이름 기반이 아닌 의미론적(Semantic)이어야 하는 이유

검색 기능을 구현해 본 적이 있다면, 검색의 한계가 무엇을 인덱싱하느냐에 달려 있다는 것을 알 것입니다. 파일 이름을 인덱싱하면 그 한계는 인간의 명명 품질에 좌우됩니다. 콘텐츠를 인덱싱하면 그 한계는 파일 자체의 실제 가치입니다. 대부분의 '파일 관리' 시스템은 여전히 전자에 베팅하고 있습니다. 이 글은 후자에 베팅해야 하는 이유, 그리고 로컬 우선(local-first) 방식이 데모에서 보여주는 것보다 더 중요하다는 주장을 담고 있습니다. 제품 홍보는 없으며, 확인해 볼 만한 엔지니어링 차원만 다룹니다.

규모부터 시작합시다. IDC에 따르면 2024년 글로벌 데이터 규모는 약 149–180 ZB에 달하며, 이 중 80%–90%가 비정형(unstructured) 데이터입니다. 즉, 문서, 이미지, 이메일, 스프레드시트 같은 형태입니다. 비정형 데이터는 폴더가 가장 취약하게 처리하는 영역인데, 정렬할 스키마가 없기 때문입니다. 데이터 구조화가 어려울수록, 미리 설계된 트리에 단순히 저장되는 것이 아니라 콘텐츠 자체가 이해되어야 할 필요성이 커집니다.

다음은 검색(retrieval) 문제입니다. IDC는 또한 지식 노동자들이 필요한 정보를 찾는 데 하루 약 2.5시간을 소비한다고 추정하는데, 이는 근무 시간의 거의 30%에 해당합니다. 인덱스가 파일 이름일 경우, 이 2.5시간 중 상당 부분은 그 정보가 어디에 있는지보다 무엇이라고 불렸는지 추측하는 데 쓰입니다. 의미론적 검색(Semantic search)은 인덱스를 본문 텍스트로 이동시킵니다.

이름 붙일 가치가 있는 실패 모드: 본문 내용이 실제 고객 계약서인 제목이 "report"인 PDF 파일입니다. 파일 이름만 색인화하면 영원히 "보고서(reports)" 더미에 남게 됩니다. 내용을 색인화하면 계약서와 함께 분류되어야 합니다. 또는 OCR(광학 문자 인식) 없이 스캔을 수행할 수도 있습니다. 이 경우, 파일 이름만 검색으로는 단순히 이미지일 뿐이며 내부 텍스트는 보이지 않습니다. 파싱 깊이(parsing depth)가 실제 품질의 상한선을 결정하며, 대부분의 평가는 깨끗한 텍스트 파일만 테스트함으로써 이를 건너뜁니다.

검색 전략에 관해서는 순수 키워드 방식과 순수 벡터 방식 모두 반쪽짜리 해결책입니다. 실질적인 답은 하이브리드(hybrid) 방식입니다. 키워드는 정확히 일치하는 항목("송장 번호 4471")을 잡아내고, 벡터 방식은 모호한 항목("그 출장 영수증")을 포착합니다. 두 점수를 결합하여 순위를 매기면 어느 한쪽만 사용할 때보다 더 안정적인 재현율(recall)과 정밀도(precision)를 얻을 수 있습니다. 벡터 전용 빌드는 여전히 일부 쿼리에서 실패할 것이고, 키워드 전용 빌드는 의미를 읽어낼 수 없습니다. 하이브리드가 지루하지만 작동하는 타협점입니다.

프라이버시는 데모 시연에서 건너뛰는 부분입니다. IBM의 '2025년 데이터 유출 비용(Cost of a Data Breach)' 보고서에 따르면, 전 세계 평균은 사고당 444만 달러($4.44M)이며, 이 중 26%가 인적 오류로 발생했습니다. 이는 외부 공격보다 더 사소하고 흔한 원인입니다. 파일을 무작위 클라우드 도구에 "정리하기 위해" 넣는 순간, 보안 표면(surface)을 넓히게 됩니다. 로컬 우선(Local-first) 방식은 파싱, 인식 및 분류를 기기 자체에서 유지합니다. 파일이 장치를 벗어나지 않습니다. 계약서, 의료 기록, 재무 정보의 경우, 이는 매번 "빠름"보다 우수하며, 일부 구매자에게는 선택 사항이 아니라 준수(compliance)의 기본 요건입니다.

로컬 우선 방식이 독립적이라는 의미는 아닙니다. 로컬 측에서 파싱과 분류를 수행하고, 그 결과물인 태그, 그룹, 검색 가능한 색인은 일반 메타데이터 형태로 내보내기하여 공유할 수 있습니다. 팀원들은 클라우드로 전송된 원본 파일이 아닌 이 메타데이터를 검색합니다. 민감한 원본 자료는 제자리에 보존되며, 검색 가능한 계층만 이동하는 것입니다. 이 경계가 로컬 우선 방식을 협업과 준수라는 두 가지 측면 모두와 호환되게 만듭니다.

도구를 평가할 때는 기능 목록을 건너뛰고 대신 다음 차원들을 확인하십시오:

제가 팀에게 건네줄 실질적인 평가 체크리스트는 다음과 같습니다: 데모 세트가 아니라 본인의 지저분한 파일로 테스트를 진행하고; 복잡한 레이아웃의 PDF, 노이즈가 포함된 휴대폰 스캔 페이지, 그리고 'final_final2'와 같이 쓸모없는 제목을 가진 파일을 최소 하나씩 포함하며; 라벨링된 샘플에서 태그 정확도를 측정하고; 실제 '3월에 X 찾기' 같은 검색 쿼리에서 재현율(recall)을 측정하며; 사생활 보호가 주장된다면 어떤 경우에도 기기 외부로 데이터가 나가지 않는지 확인해야 합니다. 데모에서는 완벽하지만 노이즈 스캔에는 실패하는 도구는 준비되지 않은 것입니다.

다국어 지원은 데모가 보여주는 것보다 훨씬 중요합니다. 개인 및 팀 파일에는 중국어 PDF, 영어 계약서, 임베디드 텍스트가 포함된 스크린샷 등 여러 언어가 혼합되어 있습니다. 추출기가 실제 자료 더미에 있는 언어를 처리하는지 테스트해야 합니다. 영어에서는 뛰어나지만 중국어는 무시하는 도구는 많은 사용자에게 절반의 기능일 뿐이며, '파싱 깊이(parsing depth)' 항목 바로 그곳에 격차가 숨겨져 있습니다.

운영상의 참고 사항: 로컬 우선 방식은 항상 켜져 있는 클라우드 서비스를 유지할 필요가 없다는 의미이지만, 파싱 과정 자체는 로컬 컴퓨팅 자원을 소모합니다. 수백 개의 파일이라면 아무것도 아니지만, 수만 개에 달한다면 유휴 시간(idle window)에 첫 인덱스 패스를 실행해야 합니다. 그 이후에는 일일 증분 작업이 가볍습니다. 어떤 공급업체에게든 직접 물어보는 것이 좋습니다: 첫 인덱싱은 얼마나 무거운지, 그리고 안정 상태의 비용 구조는 어떠한지?

만능 해결책(silver bullet)은 없습니다. 하지만 차원들이 명확해지면 결정은 자연스럽게 이루어지고 — 여러분은 자신의 파일에 맞는 도구 대신 데모를 해결하는 도구를 구매하는 것을 멈추게 됩니다.

직접 구축하는 경우, 최소한의 참조 파이프라인은 다음과 같습니다: 파일별로 유형을 감지하고; 텍스트는 개체/키워드 추출기(entity/keyword extractor)로, 이미지는 OCR 후 추출기로, 표는 구조를 보존하는 파서(structure-preserving parser)로 라우팅합니다. 추출된 텍스트를 임베딩하고; 유사도에 따라 클러스터링한 다음; 태그를 방출합니다. 클러스터링 단계는 쉬운 편입니다. 시간이 많이 걸리는 곳은 추출기들이므로, 그에 맞춰 예산을 책정하고 깨끗한 텍스트 파일로 프로토타이핑하지 마십시오.

파싱 깊이(parse depth)의 벤치마킹은 별도의 과제입니다. 최소한 복잡 레이아웃 PDF 하나, 노이즈가 있는 휴대폰 스캔 페이지 하나, 비영어권 문서 하나, 그리고 "final_final2"와 같이 쓸모없는 제목을 가진 파일 하나를 포함하는 작은 코퍼스(corpus)를 구축하십시오. 각 후보 솔루션을 이 코퍼스에 실행하고 오직 두 가지 것만 측정하십시오: 수동으로 라벨링한 샘플에서의 태그 정확도(tag accuracy), 그리고 실제 "3월의 X 찾기"와 같은 쿼리에서의 재현율(recall)입니다. 공급업체 데모에서는 완벽하지만 노이즈가 있는 스캔본에서 실패하는 것은, UI가 아무리 좋아 보여도 준비되지 않은 것입니다. 위의 차원 테이블은 말 그대로 테스트 계획이며 — 각 행은 직접 실행할 수 있는 검사 항목에 해당합니다.

팀들이 건너뛰는 한 가지 지표: 정확도뿐만 아니라 태그 오탐지(tag false positives)입니다. 95%의 정확도를 보이지만 세금 문서에 잘못된 라벨을 붙이는 도구는, 낮은 중요도의 파일에 오류가 국한된 88%의 정확도를 보이는 도구보다 더 나쁩니다. 실수로 인한 비용은 파일 유형별로 가중치를 부여해야 합니다. 계약서를 잘못 분류하는 비용은 이모티콘(meme)을 잘못 분류하는 비용과 같지 않기 때문입니다. 테이블의 "출력(output)" 행이 바로 문제가 되는 부분입니다 — 잘못된 것을 자동 보관하면, 검색 문제를 신뢰 문제로 바꾼 것입니다. 민감한 데이터에 대해 자동 분류 경로를 신뢰하기 전에, 파일 유형별로 자체 라벨링 샘플에서 이를 측정하십시오.