들어가며
부서마다 파일 서버가 늘어날수록 “그 자료가 어디에 있는지” 아무도 알 수 없게 됩니다. Windows 검색은 공유 폴더 단위로만 동작해서 서버가 여러 대면 가로지를 수 없고, NAS의 전문 검색 기능도 장비를 넘어가면 쓸 수 없습니다.
이 문제를 푸는 방법 중 하나가 파일 서버 앞에 전문 검색 서버를 두는 것입니다. 이 페이지에서는 오픈소스 전문 검색 서버인 Fess를 그 자리에 놓기 전에 확인해 두어야 할 점을 정리합니다.
대상 독자
사내 파일 서버나 NAS 검색에 어려움을 겪고 있는 분
전문 검색 도입을 검토 중이며 오픈소스로 해결할 수 있는지 알고 싶은 분
기존 접근 권한을 건드리지 않고 검색을 도입하고 싶은 분
Fess는 Apache License 2.0으로 공개되어 있으며 라이선스 비용이 들지 않습니다.
어디에 있는 파일을 검색할 수 있는가
Fess의 파일 크롤링은 다음 프로토콜을 지원합니다. 설정은 관리 화면의 [크롤러] > [파일 시스템]에서 크롤링 시작 URL로 지정합니다.
활성화된 프로토콜은 설정값 crawler.file.protocols로 관리되며, 기본값은 file,smb,smb1,ftp,s3,gcs입니다.
Windows 파일 공유를 검색할 때는 보통 smb를 사용합니다. smb1은 SMB1만 지원하는 오래된 NAS나 프린트 서버를 위해 남겨 둔 것으로, SMB1은 보안상의 이유로 Windows에서도 기본 비활성화되어 있으므로 새로 선택할 대상은 아닙니다.
기존 접근 권한을 그대로 이어받는다
파일 서버에 검색을 도입할 때 가장 큰 걱정은 “보여서는 안 되는 문서가 검색 결과에 나오는 것”입니다. 인사나 회계 공유 폴더가 전 직원의 검색 결과에 뜬다면, 순위가 아무리 좋아도 그 검색 시스템은 쓸 수 없습니다.
Fess는 이를 파일 서버 쪽 접근 권한을 그대로 검색에 가져오는방식으로 해결합니다.
동작 방식
크롤링할 때 Fess는 각 파일의 ACL(접근 제어 목록)을 읽습니다
허용되거나 거부된 계정과 그룹을 그 문서의 “롤”로 기록합니다
검색할 때 로그인한 사용자가 가진 롤과 대조하여 권한이 있는 문서만 돌려줍니다
허용과 거부가 모두 처리되며, 내부적으로는 (allow) 와 (deny) 접두사로 구분됩니다. ACL에서 롤을 가져오는 동작은 기본적으로 활성화되어 있습니다.
먼저 확인해야 할 전제
이 구조가 끝까지 동작하려면 검색하는 쪽 사용자에게도 같은 롤이 있어야 합니다. 문서에는 “이 그룹이면 읽을 수 있다”고 기록되어 있으므로, 검색하는 사용자가 자신의 소속 그룹을 Fess에 전달하지 못하면 대조할 대상이 없습니다.
따라서 권한을 이어받은 검색을 하려면 Active Directory나 LDAP 연동이 전제가 됩니다. 파일 서버 인증에 쓰는 디렉터리를 Fess 로그인에도 그대로 사용하는 구성입니다.
반대로 전 직원이 같은 범위를 봐도 되는 공유 폴더만 대상으로 한다면 이 연동은 필수가 아닙니다. 도입 범위를 정할 때 갈리는 지점입니다.
어떤 파일 형식의 내용까지 읽을 수 있는가
Fess는 Apache Tika를 이용해 파일 내용에서 텍스트를 추출합니다. 파일 이름뿐 아니라 본문이 검색 대상이 되므로 “제목이 기억나지 않는 자료”도 찾을 수 있습니다.
주요 지원 형식은 다음과 같습니다.
MS Office(doc, xls, ppt, docx, xlsx, pptx 등)
PDF
텍스트, HTML, XML
리치 텍스트(rtf)
소스 코드(js, c, h, java 등)
압축 파일(gz, tar, zip 등. 압축을 풀어 내용도 대상이 됩니다)
전체 목록은 검색 대상 파일 을 참조하세요.
스캔 문서나 이미지로만 된 PDF처럼 애초에 텍스트를 포함하지 않는 파일은 이 방식으로 내용을 읽을 수 없습니다. OCR이 필요한 경우인지는 대상 폴더의 실제 내용을 먼저 확인해 두기를 권합니다.
구성과 규모
Fess는 검색 인덱스 저장에 OpenSearch를 사용합니다. 규모가 작다면 Fess와 OpenSearch를 같은 서버에 함께 두는 구성으로도 동작하며, 대상 파일이 늘어나면 OpenSearch를 클러스터로 분리할 수 있습니다.
규모를 산정할 때는 파일 수만이 아니라 다음 항목을 확인하면 정확도가 올라갑니다.
대상 폴더의 총 용량과 그중 텍스트를 포함한 파일의 비율
갱신 빈도(매일 바뀌는지, 한 달에 몇 번인지). 크롤링 간격 설계에 영향을 줍니다
파일 하나당 크기. 지나치게 큰 파일은 크롤링 대상에서 제외하는 설정이 가능합니다
도입 흐름
먼저 실행해 본다 — 빠른 구축 가이드 의 순서로 Fess를 기동합니다. Docker Compose를 쓰면 몇 분 만에 검색할 수 있는 상태가 됩니다
크롤링 설정을 만든다 — 관리 화면의 [크롤러] > [파일 시스템]에서 대상 URL과 크롤링 간격을 등록합니다
인증 정보를 설정한다 — 공유 폴더에 접근할 계정을 [크롤러] > [파일 인증]에 등록합니다
권한과 라벨을 설계한다 — 부서별 좁히기가 필요하면 라벨을, 권한에 따른 노출 제어가 필요하면 롤을 설정합니다
순서를 따라 구축하는 예는 제4회 흩어진 파일을 일원 검색 에서 다룹니다. 여러 파일 서버와 사내 웹 사이트를 하나의 검색창에서 찾을 수 있게 하는 데까지 전 과정을 설명합니다.
정리
Fess는 파일 서버(SMB/CIFS, FTP, 로컬, S3, GCS)를 전문 검색 대상으로 삼을 수 있는 오픈소스 검색 서버입니다
SMB로 크롤링한 파일은 ACL에 기록된 접근 권한이 그대로 검색 결과 노출 제어에 사용되며, 이 동작은 기본적으로 활성화되어 있습니다
권한을 이어받은 검색을 하려면 Active Directory나 LDAP 연동이 전제가 됩니다
Apache Tika를 통해 Office 문서나 PDF의 본문까지 검색 대상이 됩니다
작게 시작해서 대상이 늘어나면 OpenSearch를 클러스터로 확장할 수 있습니다