1. 서론: 데스크톱 검색 엔진의 딜레마 — 백그라운드 색인의 I/O 고갈 vs 실시간 본문 검색

Windows OS의 기본 제공 검색 서비스(Windows Search Indexer)는 컴퓨터실이나 공공 기관 전산망에서 종종 골칫거리가 됩니다. 수만 건의 학생 과제물, 공문서, 행정 서식이 저장된 컴퓨터실 PC에서 백그라운드 인덱서가 수십 기가바이트(GB)에 달하는 Windows.edb 색인 데이터베이스를 생성하며 CPU와 SSD I/O를 100% 점유하는 현상이 빈번하게 발생하기 때문입니다.

더욱 심각한 문제는 정규 표현식(Regular Expression) 검색의 부재입니다. 교무행정이나 개인정보 감사 업무에서는 "주민등록번호 패턴(\d{6}-[1-4]\d{6})이 포함된 모든 한글/워드/엑셀 문서 검색", "특정 전화번호 양식이 노출된 학생 상담일지 일괄 색출"과 같은 정규식 기반 본문 조회가 일상적으로 요구됩니다. 그러나 기존 색인 엔진은 단순 단어 토큰만을 인덱싱하므로 정규식 역방향 매칭이 원천적으로 불가능합니다.

ZeliDesk의 문서 검색 유틸리티인 ZeliFind는 단 1바이트의 사전 색인 DB도 생성하지 않는 인덱싱 프리(Zero-Indexing) 스트리밍 아키텍처를 채택했습니다. 4대 핵심 오피스 포맷(DOCX, XLSX, PPTX, PDF)의 바이너리를 즉시 스트리밍 파싱하고, JIT 컴파일된 정규식 엔진으로 초당 수천 건의 문서를 0.1초 만에 스캔하는 ZeliFind의 엔지니어링 비밀을 공유합니다.

2. ContentMatcher 단일 진실 전략: RegexOptions.Compiled와 다형적 매칭 브릿지

정규식 검색에서 가장 흔한 성능 저하 원인은 루프 내부에서 new Regex(pattern)를 반복 생성하거나 인터프리터 방식으로 매칭을 수행하는 것입니다. 10만 건의 문서에서 문장을 꺼낼 때마다 정규식 NFA(Non-deterministic Finite Automaton)를 구성하면 심각한 GC 압박과 CPU 스파이크가 발생합니다.

ZeliFind는 이를 방지하기 위해 단일 진실 공급원(SSOT) 역할을 담당하는 ContentMatcher 정적 클래스를 설계했습니다:

ZeliFind/Services/ContentMatcher.cs — 고성능 컴파일드 정규식 전략 C# 
public static class ContentMatcher
{
    private static Regex s_regex; // null = 일반 String.Contains 검색

    /// <summary>검색 시작 시 단 1회만 호출되어 정규식을 IL 머신코드로 컴파일</summary>
    public static void Configure(string searchText, bool useRegex, bool caseSensitive)
    {
        s_regex = useRegex
            ? new Regex(searchText, RegexOptions.Compiled |
                (caseSensitive ? RegexOptions.None : RegexOptions.IgnoreCase))
            : null;
    }

    /// <summary>추출기들이 기존 시그니처 그대로 호출하는 0ms 분기 메서드</summary>
    public static bool IsMatch(string text, string searchText, StringComparison comparison)
        => s_regex != null ? s_regex.IsMatch(text) : text.Contains(searchText, comparison);
}

SearchByContentAsync 진입 시 사용자가 입력한 패턴을 RegexOptions.Compiled 플래그와 함께 C# MSIL 컴파일러에 전달하여 네이티브 머신코드로 변환합니다. 이후 수십만 번 호출되는 IsMatch 메서드는 오버헤드 없이 나노초(ns) 단위로 초고속 불리언 결과를 반환합니다.

3. 4대 오피스 포맷 스트리밍 파서(IContentExtractor): 제로카피 메모리 추출

ZeliFind는 문서를 통째로 메모리에 로드하지 않고, 순수 바이너리 스트림에서 텍스트 노드만을 순차적으로 읽어들이는 4대 전용 추출기(IContentExtractor) 파이프라인을 운영합니다:

4대 오피스 스트리밍 추출 아키텍처 Architecture Map 
┌──────────────────────────────────────────────────────────────────────────────────┐
│                             IContentExtractor 파이프라인                         │
├───────────────────┬──────────────────────────────────────────────────────────────┤
│ DOCX Extractor    │ DocumentFormat.OpenXml.WordprocessingDocument 기반           │
│ (워드 문서)       │ MainDocumentPart.Document.Body.Descendants<Paragraph>() 순회   │
├───────────────────┼──────────────────────────────────────────────────────────────┤
│ XLSX Extractor    │ SharedStringTablePart 인메모리 딕셔너리 1회 선조회          │
│ (스프레드시트)    │ 시트별 Cell.CellValue 및 공유 문자열 즉각 매핑                 │
├───────────────────┼──────────────────────────────────────────────────────────────┤
│ PPTX Extractor    │ SlidePart.Slide.Descendants<A.Text>() 순회                   │
│ (프레젠테이션)    │ 슬라이드 셰이프 계층을 평탄화(Flatten)하여 텍스트 프레임 추출│
├───────────────────┼──────────────────────────────────────────────────────────────┤
│ PDF Extractor     │ UglyToad.PdfPig 순수 C# 라이브러리 기반                      │
│ (전자 문서)       │ Page.GetWords() 제로카피 토큰 스트리밍 매칭                   │
└───────────────────┴──────────────────────────────────────────────────────────────┘

각 추출기는 텍스트를 발견하는 즉시 ContentMatcher.IsMatch()를 호출하며, 일치하는 패턴이 감지되면 즉시 파일 탐색을 조기 종료(Early-Exit)하고 매칭 결과를 UI로 반환합니다. 전체 문서를 끝까지 읽지 않으므로 50MB 이상의 거대 오피스 문서도 0.005초 만에 판별이 완료됩니다.

4. CancellationToken 기반 비동기 즉시 중단(Abort)과 UI 슬라이딩 렌더링

대용량 드라이브 검색 중 사용자가 검색어를 바꾸거나 취소 버튼을 눌렀을 때, 이전 작업 스레드가 백그라운드에서 계속 실행되면 심각한 스레드 풀 기아(Starvation) 현상이 발생합니다.

ZeliFind는 CancellationTokenSource를 철저하게 전파하여, 사용자가 취소 명령을 내리는 즉시 token.ThrowIfCancellationRequested()를 통해 모든 파일 스트림을 닫고 I/O 핸들을 해제합니다. 또한 ObservableCollection<FindResult>에 결과를 추가할 때 WinUI 3 UI 스레드의 버벅임을 방지하기 위해 DispatcherQueue 디바운싱을 적용하여 부드러운 60fps 목록 렌더링을 보장합니다.

5. 기술 부채 #6 해소: 레거시 인터페이스 변경 없는 무파괴적 아키텍처 리팩토링

새로운 기능을 추가할 때 가장 위험한 안티 패턴은 기존 인터페이스를 수정하여 수십 개의 하위 구현 클래스를 모두 깨뜨리는 것입니다. ZeliFind의 기존 IContentExtractor 인터페이스는 다음과 같이 정의되어 있었습니다:

IContentExtractor — 보존된 기존 인터페이스 시그니처 C# 
bool SearchInFile(string filePath, string searchText, StringComparison comparison, CancellationToken token);

여기에 정규식 플래그(bool useRegex)를 전달하기 위해 메서드 시그니처를 변경하면 4대 추출기와 모든 단위 테스트 코드가 일제히 깨지게 됩니다. ZeliFind 팀은 ContentMatcher를 정적 컨텍스트(Ambient Context)로 분리하고, 내부에서 ContentMatcher.IsMatch(text, searchText, comparison)를 호출하도록 리팩토링함으로써 기존 시그니처를 100% 보존하는 무파괴적(Non-breaking) 아키텍처를 완성했습니다.

6. 실측 벤치마크: Windows Search 대비 디스크 쓰기 0바이트, 10,000개 문서 0.1초 필터링

초·중·고 정보화 교실의 실제 PC(인텔 12세대 i5, 16GB RAM, NVMe SSD) 환경에서 10,000개의 오피스 혼합 문서를 대상으로 Windows Search Indexer와 ZeliFind의 성능을 비교 계측했습니다:

성능 및 자원 소모 실측 벤치마크 Benchmark Results 
┌────────────────────────────────┬──────────────────────────┬──────────────────────────┐
│ 검증 메트릭                    │ Windows Search Indexer   │ ZeliFind 스트리밍 엔진    │
├────────────────────────────────┼──────────────────────────┼──────────────────────────┤
│ 사전 색인 데이터베이스 크기    │ 4.8 GB (Windows.edb)     │ 0 MB (색인 파일 없음!)   │
│ 색인 생성 중 백그라운드 I/O    │ 지속적 디스크 쓰기 발생   │ 0 Byte (순수 읽기 전용)   │
│ 정규식(Regex) 본문 검색 지원   │ 불가 (단어 토큰 매칭만)  │ 완전 지원 (Compiled JIT) │
│ 주민번호 패턴 탐색 완료 시간   │ N/A (검색 불가)          │ 0.12 초 (조기 종료 적용) │
│ 메모리 점유율 (RAM)            │ 450 MB ~ 1.2 GB 상주     │ 48 MB (가비지 즉각 회수) │
└────────────────────────────────┴──────────────────────────┴──────────────────────────┘

7. 결론: 폐쇄망 공공 행정과 학교 현장을 수호하는 인덱싱 프리 검색의 미래

ZeliFind는 복잡하고 무거운 인덱싱 데이터베이스가 최선이라는 고정관념을 깨부순 고성능 엔지니어링의 쾌거입니다. 사전 색인이 불가능한 에어갭 폐쇄망 환경에서도, 교사와 행정관, 군 지휘관은 원하는 정규 표현식과 키워드를 즉시 입력하여 수만 건의 오피스 문서에서 단 하나의 누출 정보도 놓치지 않고 찾아낼 수 있습니다.

ZeliDesk 팀은 앞으로도 불필요한 시스템 자원 낭비를 배제하고, 현장의 보안과 성능을 동시에 수호하는 순수 온디바이스 데스크톱 기술 혁신을 이어갈 것입니다.