NAS 를 세 번 뒤집어 골랐습니다 — 급을 정한 건 인원이 아니라 읽기 경로였습니다

사내 문서 지식그래프 검색 도구가 개발자 개인 노트북에서 돌고 있었습니다. 고객사가 이 시스템을 자기 사무실로 옮기기로 하면서 서버와 NAS 를 사야 했습니다. 문서함은 클라우드 드라이브의 공유 폴더였는데, 그 드라이브가 외부 연결 API 를 닫아 데스크톱 앱만 유일한 창구였습니다.

그 입구에서 사고가 이어졌습니다. 스케줄러 아래에서 돌면 OS 권한에 걸려 폴더를 못 읽었습니다. 디스크가 차자 앱이 문서함 전체를 자리표시자로 비워 34GB 를 다시 받았습니다. 재부팅 뒤에는 앱 자체가 안 떴습니다. 「문서를 NAS 로 관리하면 어떨까」는 그 자리에서 나온 말입니다.

처음 답은 4베이 상위 모델인 Synology DS925+ 였습니다. 「여유를 사 두자」는 구성이었는데, 고객사 대표가 값을 보고 되물어 상위 모델의 2.5분의 1 값인 2베이 기본 모델 DS225+ 로 내렸습니다. 여기까지는 값을 깎은 것이지 기준을 세운 것이 아니었습니다.

사람이 하는 일마다 어느 장비를 치는지 적어 봤습니다

두 모델의 차이를 설명하려다, 사람이 하는 일마다 실제로 어느 장비를 건드리는지 표로 적었습니다.

검색과 원본 열기가 서버에서 끝납니다. 직원이 지금의 두세 배로 늘어도 느는 것은 서버 쪽 부하이지 NAS 부하가 아닙니다. 인원이 NAS 를 정하지 않는다는 문장은 이 표에서 나왔습니다.

밤 스캔이 매일 폴더를 나열하는 것은 파일 변경 이벤트가 네트워크 마운트를 넘어오지 않기 때문입니다. 그래서 스캐너는 작년·올해 폴더 약 4,700건을 매일 나열하고, 파일마다 크기와 수정시각만 봅니다. 상태 파일과 같으면 넘어가고, 다르면 그때만 내용 해시를 계산해 엔진으로 보냅니다. 전체가 2분입니다.

이 모델은 외부 로그를 Pull 로 받을 때 쓴 것과 같습니다.

스펙표의 숫자는 정의를 읽어야 했습니다

그다음 질문은 「DS225+ 와 DS925+ 의 차이가 뭐냐」였습니다. 같은 DSM(시놀로지 운영체제)을 쓰고 기능 목록도 같습니다. 다른 것은 하드웨어 급이고, 그 급이 소프트웨어 상한을 정합니다. 후보를 셋으로 좁혀 사양을 나란히 놓았습니다.

이 표의 숫자 셋은 정의를 읽어야 합니다.

FSCT 5 는 「5명까지」가 아닙니다. Microsoft File Server Capacity Tool(파일서버 트래픽을 녹화해 돌리는 벤치마크)이 가상 사용자 N 명을 쉬지 않고 돌릴 때 버티는 N 입니다. 접속 제한이 아니라 동시 부하 지표이고, 벤치의 사용자 한 명은 실제 직원보다 훨씬 무겁습니다

Drive 파일 상한은 NAS 전체가 아니라 Drive 라는 동기화 기능 하나의 상한입니다. 문서함 72,560개 중 57,548개가 한 사업 폴더의 프로그램 소스 트리였습니다. 그것을 Drive 밖 아카이브 폴더로 옮기면 관리 대상이 약 19,700개로 줄어 기본 모델의 10만 개 안에 듭니다

최대 RAM 은 시놀로지가 아니라 CPU 가 정합니다. J4125 는 인텔 사양상 8GB 가 끝이고(시놀로지는 2GB 온보드에 4GB 슬롯 하나를 붙여 6GB 로 잡았습니다), Ryzen 임베디드는 32GB 까지 갑니다

같은 값의 두 모델도 여기서 갈렸습니다. DS425+ 는 파일 상한은 50만 개지만 CPU 와 최대 RAM(6GB)이 DS225+ 와 같고 베이만 넷이라 「용량」 축을 사는 것입니다. DS725neo+ 는 베이는 둘인데 최대 RAM 32GB 에 FSCT 30 이라 「여유」 축을 사는 것입니다. 우리 문서함은 113GB 에 연 15~25GB 씩 늘어 용량 축은 한참 남습니다. 걸릴 수 있는 축은 여유 쪽뿐이었습니다.

미러는 백업이 아니고, 시세가 설계를 바꿨습니다

디스크 구성에서 두 번 걸렸습니다. 첫째는 「베이 하나는 본편, 하나는 백업이 맞느냐」는 질문이었습니다. 아닙니다. 두 장을 꽂으면 둘 다 본편이고 그것이 미러입니다. 둘째 베이를 백업 자리로 쓰면 디스크 하나가 고장 나도 멈추고, NAS 자체가 고장 나면 백업까지 같이 잃습니다. 스냅샷도 같은 디스크 안에 있어 디스크와 함께 사라집니다. 세 층이 각자 다른 사고를 막습니다.

스냅샷 — 사람의 실수와 랜섬웨어를 막습니다. 디스크 안에 있어 랜섬이 못 건드리지만, 디스크 고장에는 소용없습니다

미러 — 디스크 고장을 막습니다. 상자가 고장 나면 같이 잃습니다

상자 밖 사본 — USB 외장 HDD 는 상자 고장을 막습니다. 꽂혀 있는 외장은 랜섬이 같이 암호화하므로, 랜섬은 선 밖 오프사이트 사본이 막습니다

둘째는 시세였습니다. 2026년 낸드 값이 급등해 2.5인치 SATA SSD 2TB 한 장이 1TB 두 장보다 약 20% 비쌌습니다. NVMe 는 같은 용량 SATA 의 절반 값이었지만 시놀로지는 M.2 슬롯에 자사 SSD 만 허용해 그 길이 막혀 있었습니다. SATA SSD 의 순차 속도(약 560MB/s)가 2.5GbE 상한(약 280MB/s)을 이미 넘습니다. NAS 에서 SSD 가 주는 것은 속도가 아니라 작은 파일 수천 개를 훑는 응답성과 무소음입니다.

그래서 2TB 한 장으로 시작하고 둘째 베이는 비워 두기로 했습니다. 나중에 한 장을 더 꽂으면 SHR(시놀로지의 유연한 RAID 구성)이 미러로 전환합니다. 디스크가 고장 나면 복원할 때까지 멈추는 것을 감수한 선택입니다.

세 번 뒤집힌 끝에 중간 모델로 올라왔습니다

마지막 반전은 RAM 이었습니다. DS225+ 는 기본 2GB 인데, 스냅샷과 Drive 에 서버 백업(ABB)까지 같은 상자에서 돌리면 2GB 로는 빠듯해 어차피 4GB 를 사서 꽂아야 합니다. 그 값을 더하면 DS725neo+ 와의 실제 차이는 SSD 2TB 한 장 값의 3분의 1 정도로 줄어듭니다. 그 차이로 「사용 방식이 바뀔 때 걸릴 상한 둘」이 없어집니다. 문서함을 NAS 에서 직접 열게 되거나 Drive 로 소스까지 동기화하게 되면 FSCT 5 와 파일 상한 10만 개가 먼저 걸릴 텐데, 그 두 벽이 30 과 50만 개로 올라갑니다.

처음 답이 「여유를 사 두자」였다면 마지막 답은 「어느 여유가 진짜 걸리나」를 센 결과입니다. 이 세 번의 뒤집힘이 결정 과정입니다.

입구를 옮기는 이전 자체는 재색인이 0건입니다. 스캐너의 상태 열쇠가 절대경로가 아니라 「사업 폴더 + 상대경로」이고 문서 id 가 내용 해시라, 루트를 NAS 로 바꿔도 같은 파일은 같은 문서입니다. 전량 복사와 대조를 마친 뒤 루트를 바꾸는 순서만 지키면 됩니다. 절대경로를 열쇠로 썼다면 5,700건을 다시 넣어야 했을 겁니다.

문서 id 를 내용에서 뽑아 재색인을 멱등하게 만든 과정은 앞 글에 있습니다.

의사결정자용 체크리스트

검색과 원본 열기가 어디서 끝나는지 먼저 그립니다. 서버에서 끝나면 NAS 는 저장과 밤 스캔만 받습니다

스펙표의 동시 사용자 수와 파일 상한은 정의를 읽습니다

값을 올릴 때 용량 축인지 여유 축인지 구분합니다

둘째 베이를 백업 자리로 쓰지 않습니다. 랜섬용 사본은 선 밖에 둡니다

부품 시세를 그날 확인합니다. 「한 장 vs 두 장」 판단이 뒤집힙니다

마무리

이 글의 전제는 NAS 가 입구이고 읽기가 서버에서 끝난다는 것입니다. 디자인·영상 원본을 NAS 에서 직접 편집하는 회사나 NAS 안에서 VM 을 돌릴 회사는 FSCT 와 네트워크 급이 먼저입니다. 문서함이 곧 매출인 회사라면 처음부터 미러가 맞습니다. 가격 비율은 2026년 9월 시세 기준입니다.