홈 서버를 검색하기 쉽게 만드는 명명 규칙은 무엇인가요?

홈 서버는 파일, 폴더, 장치, 서비스가 검색 전에 예측 가능한 이름을 사용할 때 검색 가능성을 유지합니다. 목표는 모든 세부 정보를 파일 이름에 인코딩하는 것이 아니라 유사한 데이터가 생성될 때마다 같은 단어, 필드 순서, 구분자, 날짜, 버전 라벨을 사용하는 것입니다.

서버가 커질수록 이것은 더 중요해집니다. 일관성 없는 이름은 Finder나 파일 탐색기뿐 아니라 백업 검토, 스크립트 유지 관리, 미디어 라이브러리 스캔, 자체 호스팅 서비스 식별을 어렵게 만듭니다. 실용적인 명명 시스템은 Windows, macOS, Linux, SMB 공유, 명령줄 도구, 웹 애플리케이션 전반에서 작동해야 합니다.

검색 가능한 이름은 상세화되기 전에 예측 가능해야 합니다

다음과 같은 파일 이름 scan004.pdf 기술적으로는 작동하지만 검색 도구와 사용자에게 거의 맥락을 제공하지 않습니다. 관련 없는 10개의 필드를 포함한 이름은 반대 문제를 일으킬 수 있습니다: 읽기 어렵고 불필요하게 긴 경로를 만듭니다.

더 나은 방법은 각 데이터 유형에 대해 소수의 필드를 정의하는 것입니다. 문서는 날짜, 주제, 문서 유형, 버전을 사용할 수 있습니다. 사진은 이벤트 날짜, 이벤트 이름, 순번을 사용할 수 있습니다. 서버 구성 내보내기는 서비스 이름, 구성 유형, 백업 날짜를 사용할 수 있습니다.

예를 들어:

2026-07-15_home-insurance_invoice_v02.pdf
2026-07-15_family-reunion_photo-001.jpg
paperless_config_2026-07-15.tar.gz

모든 파일에 모든 필드가 필요한 것은 아닙니다. 중요한 것은 같은 범주에 속한 파일이 같은 순서와 어휘를 따르는 것입니다.

같은 종류의 데이터에는 같은 단어를 사용하세요

같은 개념이 다음과 같이 설명되면 검색이 신뢰할 수 없게 됩니다 invoice, bill, inv, 그리고 statement 명확한 구분 없이. 한 용어로 검색하면 컬렉션의 일부만 반환됩니다.

반복되는 파일 유형에 대해 작은 통제된 어휘를 만드세요. 가정에서는 다음과 같은 용어를 표준화할 수 있습니다:

invoice
receipt
contract
manual
statement
photo
video
backup
config

모든 사람과 애플리케이션이 이해할 때만 약어를 사용하세요. 홈 서버는 보통 원래 제작자만 기억하는 압축된 코드보다 읽기 쉬운 이름에서 더 많은 이점을 얻습니다.

하나의 대소문자 및 구분자 스타일을 선택하세요

같은 프로젝트가 여러 형태로 쉽게 나타날 수 있습니다:

Project Alpha
project_alpha
PROJECT-ALPHA
projectAlpha

이러한 변형은 필터링, 셸 명령, 정규 표현식, 수동 탐색을 덜 예측 가능하게 만듭니다. 공백은 최신 시스템에서 지원되지만 명령줄 도구에서는 종종 인용이 필요하고 URL에서는 인코딩됩니다. 가장 안전한 규칙은 공백이 금지된 것이 아니라 한 가지 형식을 일관되게 사용하는 것입니다.

혼합된 가정 환경에 실용적인 기본값은 일반 단어 사이에 하이픈을 넣은 소문자 텍스트입니다. 구분이 필요할 때는 밑줄로 더 큰 필드를 구분할 수 있습니다:

2026-07-15_project-alpha_invoice_v02.pdf

보수적인 크로스 플랫폼 파일 이름 규칙은 간단한 영숫자 이름과 일관된 구분 기호를 선호합니다. 구두점, 공백 및 스크립트 문자는 운영 체제, 파일 시스템 및 자동화 도구에 따라 다르게 해석될 수 있기 때문입니다.

이름	검색 및 유지 관리 효과
New Document 4.pdf	유용한 주제, 날짜 또는 문서 유형 없음
HOME TAX FINAL.pdf	일관성 없는 대소문자 및 불명확한 버전 상태
tax-final-final-2.pdf	정렬 가능한 버전 기록 없음
2026-04-15_tax-return_v03.pdf	날짜, 주제 및 버전이 예측 가능함
project-alpha_notes.md	읽기 쉽고 자동화에 적합

시간이 주요 검색 필드일 때 ISO 날짜 사용

날짜는 영수증, 계약서, 회의록, 백업, 내보내기, 사진 및 사용자가 일반적으로 연도나 월별로 검색하는 기타 파일에 유용합니다.

형식 YYYY-MM-DD 가장 큰 시간 단위를 먼저 배치하고 고정 폭의 월과 일을 사용합니다. 즉, 일반 텍스트 정렬도 연대순 정렬을 생성합니다. 검색 시 2026-07 파일 시스템 생성 날짜에 의존하지 않고 2026년 7월과 관련된 파일을 반환합니다.

ISO 스타일 YYYY-MM-DD 접두사를 사용하면 날짜 기반 파일을 연대순으로 정렬할 수 있으며, 지역에 따라 다르게 해석될 수 있는 07-04-2026 같은 모호한 형식을 피할 수 있습니다.

날짜는 모든 파일에 기계적으로 추가해서는 안 됩니다. 이벤트, 발행, 촬영, 출판 또는 백업 날짜가 검색에 중요할 때 사용하세요. 소프트웨어 매뉴얼이나 장기 참조 파일은 제품명이나 주제명으로 시작하는 것이 더 유용할 수 있습니다.

날짜가 나타내는 의미 정의

파일에는 생성 날짜, 송장 날짜, 스캔 날짜, 다운로드 날짜, 사진 촬영 날짜 또는 NAS에 추가된 날짜 등 여러 가능한 날짜가 있을 수 있습니다.

다른 사람이 서로 다른 해석을 선택하면 파일 이름이 일관되어 보이지만 서로 다른 정보를 나타낼 수 있습니다. 각 카테고리에 대한 날짜 의미를 정의하세요. 영수증은 거래 날짜, 사진은 촬영 날짜, 회의록은 회의 날짜를 사용할 수 있습니다.

파일 시스템 타임스탬프에만 의존하지 마세요. 파일 복사, 복원, 추출 또는 편집 시 생성 및 수정 메타데이터가 변경될 수 있습니다. 이름 안에 의미 있는 날짜는 마이그레이션 중에도 안정적으로 유지될 수 있습니다.

순서대로 정렬해야 하는 숫자는 0으로 채우기

텍스트 정렬은 다음을 배치할 수 있습니다 part-10 이전 part-2 문자는 왼쪽에서 오른쪽으로 비교되기 때문입니다. 동일한 문제는 스캔 배치, 사진 시퀀스, 에피소드, 디스크 이미지, 번호가 매겨진 프로젝트 내보내기에서도 나타납니다.

예상 수집 크기를 기준으로 고정 너비를 사용하세요:

part-001
part-002
part-010
part-100

12개월 보고서에는 두 자리 숫자가 충분할 수 있습니다. 사진 가져오기, 스캔 페이지, 자동 생성 미디어에는 세 자리 또는 네 자리 숫자가 더 안전합니다. 일관된 자리수 채우기는 파일 탐색기와 스크립트 모두 예상 순서를 생성할 수 있게 합니다.

“Final”을 반복하는 대신 버전 번호를 사용하세요

다음과 같은 파일 이름 proposal-final.pdf 다른 수정본이 필요해지면 더 이상 유용하지 않습니다. 이로 인해 다음과 같은 이름이 생깁니다. final-2, final-revised, 그리고 final-really-final.

파일이 개발 중일 때는 정렬 가능한 버전 라벨을 사용하세요:

proposal_v01.docx
proposal_v02.docx
proposal_v03-approved.pdf

선택적 상태 단어는 정의된 의미가 있어야 합니다. 다음과 같은 용어가 있습니다. draft, review, approved, 그리고 signed “최종”의 여러 해석보다 더 유용합니다. 복잡한 프로젝트에는 모든 수정본을 파일 이름 접미사로만 저장하지 말고 애플리케이션 기록이나 버전 관리를 사용하세요.

다른 클라이언트에서 실패하는 문자를 피하세요

Linux 서버는 나중에 Windows에서 편집하기 어렵거나, 아카이브에서 추출하거나, 다른 플랫폼과 동기화하거나, 애플리케이션으로 처리하기 어려운 이름을 허용할 수 있습니다. 서버 파일 시스템은 경로의 한 부분일 뿐입니다.

광범위한 호환성을 위해 일반 파일 및 폴더 이름에서 다음 문자를 피하세요:

\ / : * ? " < > |

마침표나 공백으로 끝나는 이름도 피하세요. Windows 호환 시스템은 다음과 같은 장치 스타일 이름을 예약합니다. CON, PRN, AUX, NUL, COM1, 그리고 LPT1파일 확장자가 추가된 형태를 포함하여.

Windows 사용자가 파일에 접근할 수 있도록 하려면 NAS 자체가 허용하더라도 제한된 문자, 끝 공백, 끝 마침표, 예약된 Windows 파일 이름을 준수해야 합니다.

파일을 구분할 때 대소문자만 사용하지 마세요

Linux 파일 시스템은 일반적으로 report.pdf 및 Report.pdf 서로 다른 파일로 간주됩니다. Windows와 많은 macOS 설정은 이러한 이름을 동등하게 처리할 수 있습니다.

두 파일이 대소문자를 구분하지 않는 대상에 들어가면 하나가 다른 하나를 덮어쓰거나 복사에 실패하거나 자동으로 이름이 변경될 수 있습니다. 검색 결과도 클라이언트마다 다를 수 있습니다.

대문자만 사용하는 대신 다른 설명 용어를 사용하세요:

report-summary.pdf
report-appendix.pdf

소문자만 사용하는 규칙은 이 위험을 줄이고 셸 명령과 스크립트를 예측하기 쉽게 만듭니다.

파일 이름뿐만 아니라 전체 경로를 제어하세요

간결한 파일 이름도 깊게 중첩된 여러 폴더 아래에 있으면 실패할 수 있습니다. 경로 길이에는 공유 이름, 모든 상위 폴더, 파일 이름, 때로는 클라이언트 측 마운트 접두사가 포함됩니다.

모든 단계에서 같은 맥락을 반복하지 마세요. 다음 위치에 저장된 파일:

/documents/finance/2026/invoices/

다음과 같은 이름은 필요하지 않습니다:

documents-finance-2026-invoices-electricity-invoice-march.pdf

더 짧은 이름도 폴더 밖에서 이해할 수 있습니다:

2026-03_electricity_invoice.pdf

폴더 계층은 넓은 맥락을 제공하고 파일 이름은 복사, 다운로드 또는 다른 곳에 첨부해도 유지되어야 하는 세부 정보를 담도록 하세요.

안정적인 범주를 중심으로 최상위 폴더를 만드세요

최상위 폴더는 한 프로젝트나 한 해가 끝난 후에도 사라지지 않을 범주를 나타내야 합니다. 루트 구조를 자주 재설계하면 북마크, 백업 작업, 컨테이너, 동기화 클라이언트, 미디어 애플리케이션에서 사용하는 경로가 변경됩니다.

간단한 홈 서버는 다음과 같이 시작할 수 있습니다:

documents/
photos/
media/
projects/
shared/
archive/
backups/

연도, 사람, 프로젝트, 이벤트는 이 범주 아래에 나타날 수 있습니다. 계층 구조는 충분히 깊어야 맥락을 제공하지만, 사용자가 파일을 찾기 위해 10단계 이상 기억해야 할 정도로 깊지 않아야 합니다.

폴더 구조는 권한과 백업 정책도 반영해야 합니다. 민감한 문서, 공유 가족 파일, 교체 가능한 미디어, 애플리케이션 데이터는 이름 규칙이 비슷해도 접근 규칙과 백업 빈도가 다를 수 있습니다.

호스트 이름은 역할이 명확하게 드러나도록 지정하세요

예를 들어 server, ubuntu, new-pc, 그리고 box2 홈 랩에 장치가 하나 있을 때는 이해할 수 있지만, 백업 서버, 도커 호스트, NAS, 하이퍼바이저, 여러 소형 컴퓨터를 추가하면 모호해집니다.

호스트 이름 형식은 역할, 위치, 아키텍처 또는 시퀀스와 같은 안정적인 필드를 결합할 수 있습니다:

nas-home-01
docker-home-01
backup-office-01
proxmox-lab-01

형식은 모든 필드를 포함할 필요가 없습니다. 작은 실험실은 rpi5-01과 같은 하드웨어 계열과 번호를 사용할 수 있고, 서비스 중심 환경은 역할 기반 이름이 유리할 수 있습니다. 유용한 원칙은 호스트 이름을 일상 관리에 충분히 짧고 장치를 식별할 만큼 의미 있게 유지하는 것입니다.

객체	유용한 예	덜 유용한 예
NAS 호스트	nas-home-01	newserver
도커 호스트	docker-lab-01	ubuntu-box
백업 호스트	backup-home-01	old-nas
미디어 서비스	media.home.example.com	192.168.1.50:8096
문서 서비스	docs.home.example.com	server2:8000
모니터링 서비스	status.home.example.com	dashboard-new

호스트 이름에 임시 하드웨어 세부 정보를 넣지 마세요

서버가 메모리를 추가하거나 IP 주소를 변경하거나 디스크를 교체하거나 운영 체제를 업그레이드할 때도 호스트 이름은 유용해야 합니다. 예를 들어 ubuntu-22, nas-8tb, 그리고 server-192-168-1-50 일상적인 변경 후 부정확해질 수 있습니다.

역할 및 위치와 같은 안정적인 속성을 선호하세요. 시퀀스 번호를 사용하면 기존 장치 이름을 모두 바꾸지 않고도 환경을 확장할 수 있습니다.

기계가 역할을 완전히 변경하면 이름 변경을 문서화하고 DNS, SSH 구성, 모니터링, 백업 작업, 인증서 및 애플리케이션 참조를 함께 업데이트하세요. 의존성을 확인하지 않고 프로덕션 호스트 이름을 무심코 변경하는 것은 피하세요.

호스트 이름과 서비스 이름을 분리하세요

서비스를 실행하는 기계와 사용자가 그 서비스에 접근하기 위해 사용하는 이름은 다른 개념입니다. 미디어 애플리케이션은 현재 docker-home-01, 하지만 사용자는 어떤 기기나 포트가 호스팅하는지 알 필요가 없어야 합니다.

다음과 같은 서비스 지향 DNS 이름을 사용하세요:

media.home.example.com
photos.home.example.com
docs.home.example.com
status.home.example.com

로컬 DNS 또는 리버스 프록시가 해당 이름을 올바른 호스트로 안내할 수 있습니다. 서비스가 다른 기기로 이동할 때는 DNS 또는 프록시 경로만 변경하면 됩니다. 즐겨찾기, 모바일 앱 및 가정 내 지침은 그대로 유지할 수 있습니다.

실제로 소유한 내부 네임스페이스를 사용하세요

내부 최상위 도메인을 임의로 만들거나 등록되지 않은 도메인을 사용하는 것은 유혹적일 수 있습니다. 그러나 이름이 공개적으로 할당되거나 장치가 쿼리를 외부로 보내거나 DNS 검증 동작이 변경되면 미래에 충돌이 발생할 수 있습니다.

더 강력한 설계는 다음과 같이 소유한 도메인의 하위 도메인을 사용하는 것입니다:

home.example.com
internal.example.com

ISC는 내부 네임스페이스를 소유하지 않거나 현재 존재하지 않는 도메인 아래에 구축하는 대신 소유한 등록 도메인 아래에 사설 DNS 이름을 배치할 것을 권장합니다. 이는 충돌 위험을 줄이고 네임스페이스에 명확한 관리 소유자를 부여합니다.

도메인은 모든 내부 서비스가 공개적으로 접근 가능할 필요는 없습니다. 내부 DNS는 홈 리졸버를 사용하는 장치에만 사설 주소를 반환할 수 있으며, 공개 DNS 영역은 별도로 유지됩니다.

원시 IP 주소를 기반으로 한 영구 즐겨찾기는 피하세요

IP 주소는 네트워크 목적지를 식별하지만 서비스가 무엇을 하는지는 알리지 않습니다. 라우터 교체, DHCP 임대 변경 또는 서비스가 다른 호스트로 이동할 때 주소가 변경될 수도 있습니다.

예를 들어 즐겨찾기 http://192.168.1.50:8096 모든 사용자가 주소와 포트 둘 다를 기억해야 합니다. 예를 들어 서비스 이름은 media.home.example.com 의미를 유지하며 클라이언트 구성을 변경하지 않고도 리디렉션할 수 있습니다.

안정적인 주소 지정이 필요한 경우 DHCP 예약 또는 고정 할당을 사용하되, 일반적인 접근 및 관리를 위해 해당 주소 위에 DNS 이름을 배치하세요.

애플리케이션별 라이브러리는 자체 명명 규칙이 필요합니다

일반적인 규칙은 문서에는 잘 작동할 수 있지만 미디어 라이브러리에서는 실패할 수 있습니다. Plex, Jellyfin, 음악 관리자, 사진 시스템, 전자책 서버 및 문서 관리 애플리케이션은 제목, 연도, 시즌, 에피소드 번호, 저자 또는 판을 추출하기 위해 이름을 분석할 수 있습니다.

이 데이터셋의 경우 애플리케이션에서 요구하는 명명 패턴을 따르세요. TV 에피소드는 다음과 같은 형식이 필요할 수 있습니다. Show Name - S01E03.ext서버의 나머지 부분이 소문자 하이픈 이름을 사용하더라도,

애플리케이션 호환성이 보편적인 명명 스타일보다 우선합니다. 중요한 규칙은 각 관리 라이브러리 내에서 일관성을 유지하고 의도된 예외를 문서화하는 것입니다.

파일 이름은 OCR이나 전체 텍스트 인덱싱을 대체할 수 없습니다.

설명적인 파일 이름은 보험 증권을 찾는 데 도움이 될 수 있지만, 스캔한 PDF 내부의 모든 단락을 검색 가능하게 만들 수는 없습니다. 문서가 페이지 이미지로만 구성된 경우 계정 용어나 조항을 검색해도 찾을 수 없습니다.

스캔한 문서에 OCR과 파일 내용을 인덱싱하는 검색 시스템을 사용하세요. 문서 관리 도구는 발신자, 문서 유형, 태그, 날짜 및 사용자 지정 메타데이터도 추가할 수 있습니다.

명명과 인덱싱은 다른 문제를 해결합니다. 파일 이름은 안정적인 식별자와 가시적 맥락을 제공하며, OCR과 전체 텍스트 인덱싱은 파일 내부 정보를 검색합니다.

민감한 정보는 파일 이름에 포함하지 마세요.

파일 이름은 백업 보고서, 동기화 로그, 알림, 브라우저 기록, 애플리케이션 데이터베이스, 공유 링크, 명령 출력 및 스크린샷에 나타날 수 있습니다. 파일 내용보다 더 널리 노출되는 경우가 많습니다.

파일 이름에 비밀번호, 복구 키, 전체 은행 계좌 번호, 신분증 번호, 의료 정보 또는 인증 토큰을 넣지 마세요. 불필요한 개인 정보를 노출하지 않으면서 문서를 구분할 수 있을 만큼의 충분한 맥락을 사용하세요.

민감한 메타데이터는 파일 이름 대신 적절히 보호된 문서 시스템이나 암호화된 파일에 저장하세요.

대량 이름 변경 전에 명명 방식을 테스트하세요.

대규모 NAS 라이브러리 이름 변경은 미디어 데이터베이스, 재생 목록, 바로 가기, 심볼릭 링크, 스크립트, Docker 바인드 마운트, 동기화 작업 및 백업 기록을 손상시킬 수 있습니다. 파일 이름이 깔끔해도 이를 사용하는 애플리케이션이 파일을 찾지 못하면 소용없습니다.

작고 대표적인 폴더부터 시작하세요. Windows, macOS, Linux, SMB, 백업 소프트웨어, 검색 도구 및 디렉터리를 스캔하는 모든 애플리케이션에서 새 형식을 테스트하세요.

기존 이름과 새 이름의 매핑을 유지한 후 일괄적으로 이전하세요. 먼저 스냅샷이나 백업을 하고, 증분 백업 또는 동기화 소프트웨어가 모든 이름 변경을 예상치 못한 삭제 및 전체 재업로드로 해석하지 않는지 확인하세요.

사람들이 실제로 따를 수 있는 명명 체크리스트를 사용하세요.

명명 규칙은 다른 가족 구성원이 긴 참고 자료 없이도 사용할 수 있을 만큼 간단해야 합니다. 아무도 따르지 않는 복잡한 분류법은 짧고 실용적인 규칙보다 더 많은 불일치를 초래합니다.

유용한 시작 체크리스트는 다음과 같습니다:

• 소문자와 구분자 스타일을 사용하세요.
• 각 데이터 유형 내에서 필드 순서를 일관되게 유지하세요.
• 안정적이고 설명적인 키워드를 사용하세요.
• 사용하세요 YYYY-MM-DD 날짜가 검색을 주도할 때.
• 시퀀스 번호에 0을 채우세요.
• 플랫폼 간 제한된 문자와 예약된 이름을 피하세요.
• 반복되는 “최종” 라벨 대신 정렬 가능한 버전을 사용하세요.
• 전체 경로를 적절히 짧게 유지하세요.
• 안정적인 역할이나 하드웨어 계열별로 호스트 이름을 지정하세요.
• DNS를 통해 기능별로 서비스를 이름 지정하세요.
• 애플리케이션별 미디어 및 문서 규칙을 따르세요.
• 파일 이름 검색만으로 충분하지 않을 때는 OCR과 인덱싱을 사용하세요.

규칙을 먼저 새 데이터에 적용하세요. 이전 아카이브는 명확한 검색 또는 호환성 이점이 있을 때 점진적으로 이전할 수 있습니다.

최종 요약

검색 가능한 홈 서버는 복잡한 파일 이름이 필요하지 않습니다. 예측 가능한 파일 이름이 필요합니다. 일관된 키워드, 대소문자, 구분자, 필드 순서, 날짜 형식, 시퀀스 번호 및 버전을 사용하여 사람과 소프트웨어 모두 유사한 항목 이름을 예상할 수 있도록 하세요.

Windows, macOS, Linux, SMB, 아카이브 및 동기화 도구 전반에서 파일 및 폴더 이름을 이식 가능하게 유지하세요. 서버 이름은 짧고 의미 있는 식별자로 지정하고, 사용자가 원시 IP 주소와 포트를 기억하지 않도록 안정적인 DNS 이름을 서비스에 부여하세요.

좋은 이름 지정은 정렬, 필터링, 백업 검토, 스크립트 및 일상 탐색을 개선합니다. 그러나 OCR, 전체 텍스트 인덱싱, 태그 또는 애플리케이션 메타데이터를 대체하지는 않습니다. 가장 검색하기 좋은 홈 서버는 간단한 이름 지정 표준과 저장하는 데이터에 적합한 인덱싱 도구를 결합한 것입니다.

자주 묻는 질문(FAQ)

홈 서버 파일 이름에 공백을 사용할까요, 하이픈을 사용할까요?

현대 파일 시스템에서는 공백이 작동하지만, 하이픈은 URL, 셸 명령, 구성 파일 및 스크립트에서 사용하기 더 쉽습니다. 가장 중요한 규칙은 한 가지 스타일을 선택하고 일관되게 사용하는 것입니다.

모든 파일 이름이 날짜로 시작해야 하나요?

아니요. 영수증, 회의록, 사진, 내보내기, 백업 등 사용자가 파일을 검색하거나 정렬하는 주요 방법이 시간일 경우 날짜 접두사를 사용하세요. 주제 기반 참조 파일은 주제로 시작할 때 더 명확할 수 있습니다.

왜 시퀀스 번호에 앞에 오는 0을 포함해야 하나요?

앞에 오는 0은 텍스트 정렬을 숫자 순서와 일치시키는 데 도움이 됩니다. 예를 들어 001, 002, 그리고 010 올바르게 정렬되며 1, 2, 그리고 10 포함하지 않아도 됩니다.

서버 호스트 이름에 IP 주소를 포함해야 하나요?

보통 그렇지 않습니다. IP 주소는 변경될 수 있지만, 호스트 이름은 안정적인 장치 역할이나 정체성을 나타내야 합니다. DNS, DHCP 예약 또는 호스트 구성을 사용하여 이름을 현재 주소에 매핑하세요.

좋은 파일 이름이 검색 애플리케이션의 필요성을 없애나요?

아니요. 파일 이름은 가시적인 메타데이터로 검색을 개선하지만, 스캔한 PDF, 문서, 메시지 및 기타 콘텐츠가 풍부한 파일 내부를 검색하려면 OCR과 전체 텍스트 인덱싱이 필요합니다.