diff --git a/journey/README.md b/journey/README.md
index 6a77101..49061fa 100644
--- a/journey/README.md
+++ b/journey/README.md
@@ -63,6 +63,7 @@
 - [24서버 실서비스 운영전환 계획](./plans/260309_24서버_실서비스운영전환_계획.md)
 - [24 자동배포 0초 종료 runtime SSOT 복구 계획](./plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md)
 - [23서버 워크스페이스 SSOT 구조전환 계획](./plans/260309_23서버_워크스페이스_SSOT_구조전환_계획.md)
+- [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획](./plans/260311_external_nas_companyx_sync_운영계획.md)
 - [24서버 ONNX 모델 NAS 백업 정리](./worklog/260309_24서버_onnx모델_nas백업_정리.md)
 - [23제어면 gateway workspace-config 단일화](./worklog/260309_23제어면_gateway_workspace_config_단일화.md)
 - [51123 구IP active runtime 제거 1차](./worklog/260309_51123_구IP_active_runtime_제거_1차.md)
@@ -70,3 +71,4 @@
 - [23 gateway MONITOR_URL 24 monitor 교정 및 실도메인 전수검증](./worklog/260310_23gateway_monitor_url_24monitor_교정_및_실도메인_전수검증.md)
 - [24전환 배포대상과 ingress 24IP 교정 1차](./worklog/260309_24전환_배포대상과_ingress_24IP_교정_1차.md)
 - [24서버 NAS 마운트 복원 및 ONNX 백업 실행](./worklog/260309_24서버_nas마운트복원_onnx백업실행.md)
+- [Company X 외부 NAS 동기화 스크립트 구현 및 대표 검증](./worklog/260311_companyx_external_nas_sync_스크립트구현_및_대표검증.md)
diff --git a/journey/ideas/260307_external_nas_companyx_sync_아이디어.md b/journey/ideas/260307_external_nas_companyx_sync_아이디어.md
index 4bddc7b..bd82a29 100644
--- a/journey/ideas/260307_external_nas_companyx_sync_아이디어.md
+++ b/journey/ideas/260307_external_nas_companyx_sync_아이디어.md
@@ -7,58 +7,35 @@ tags: [nas, companyx, sync, ideas]
 - [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
 - [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
 
-## 목적
+## 문제 인식
 
-- 컴퍼니엑스 외부 NAS의 파일을 우리 내부 NAS로 안정적으로 가져오는 운영 방안을 정리한다.
-- 실시간 미러링이 아니라, 운영 가능한 단방향 동기화 구조를 먼저 정한다.
+- 서버가 외부 NAS를 직접 읽는 구조는 연결 안정성, 보안, 운영 복잡도 측면에서 부담이 크다.
+- 서버가 파일 처리까지 맡는 환경에서 외부 저장소 연결 이슈가 바로 런타임 이슈로 번지지 않게 분리할 필요가 있다.
 
-## 현재 확인된 사실
+## 아이디어
 
-- 외부 NAS는 `sigongipc.synology.me:5000/5001`의 Synology DSM 경로로 접근 가능하다.
-- 외부 SMB 직접 접근은 타임아웃으로 막혀 있다.
-- 파일 1건 다운로드 후 내부 NAS 저장과 SHA256 일치가 확인됐다.
-- 내부 NAS는 `192.168.0.101`이며 51123의 `/mnt/nas`로 실마운트되어 있다.
+- 외부 NAS의 파일을 먼저 내부 NAS로 단방향 동기화한다.
+- 동기화 대상은 외부 NAS `/6.Company X` 아래 전체 파일이며, 내부 NAS 대상 경로는 `/mnt/nas/workspace/6.Company X`로 본다.
+- 서버는 외부 NAS를 직접 읽지 않고, 내부 NAS만 읽는다.
+- 역할을 `외부 NAS = 외부 원본`, `내부 NAS = 내부 저장소`, `서버 = 처리`로 나눈다.
 
-## 가능한 방식
+## 기대 효과
 
-### 1. 주기 배치 동기화
+- 서버 쪽 파일 접근 경로를 내부 NAS 하나로 단순화할 수 있다.
+- 외부 NAS 연결 문제를 서버 런타임 문제와 분리할 수 있다.
+- 저장과 연산의 책임을 나눠 운영 구조를 더 설명 가능하게 만들 수 있다.
 
-- 일정 주기마다 외부 NAS 목록을 조회하고 새 파일만 내부 NAS로 내려받는다.
-- 장점: 구현이 단순하고 운영 리스크가 낮다.
-- 단점: 실시간은 아니다.
+## 검증이 필요한 이유
 
-### 2. 폴더 단위 스냅샷 동기화
+- 실제로 어떤 동기화 방식이 가장 운영 가능한지는 아직 확정되지 않았다.
+- 동기화 주기, 대상 범위, 실패 복구, 무결성 검증 기준은 근거 수집이 더 필요하다.
+- 이 아이디어가 실제 운영 구조로 적합한지는 별도 리서치와 실측으로 검증해야 한다.
 
-- 컴퍼니엑스의 핵심 폴더만 골라 정해진 시각에 통째로 동기화한다.
-- 장점: 우선순위 관리가 쉽다.
-- 단점: 큰 폴더는 시간이 오래 걸릴 수 있다.
+## SSOT 원칙상 이 문서에서 빼야 하는 내용
 
-### 3. 매니페스트 기반 증분 동기화
-
-- 외부 NAS 파일 목록, 크기, 수정시각, 해시를 기록한 매니페스트를 내부에 두고 변경분만 반영한다.
-- 장점: 중복 다운로드를 줄일 수 있다.
-- 단점: 구현과 검증이 더 복잡하다.
-
-## 권장 방향
-
-- 1차는 `주기 배치 동기화`로 시작한다.
-- 구조가 안정되면 `매니페스트 기반 증분 동기화`로 확장한다.
-- 초기에 중요한 것은 속도보다 설명 가능성과 재현 가능성이다.
-
-## 현재 실측을 반영한 운영 아이디어
-
-- 문서/엑셀/PDF 위주 경로는 `5분~10분 간격 증분 동기화` 후보로 볼 수 있다.
-- 사진처럼 파일 수가 많은 폴더는 낮 시간 `15분~30분 간격 증분`, 야간 `1회 전체 스캔`이 더 안전하다.
-- 초기 운영은 “핵심 폴더 우선 동기화 + 야간 전체 점검” 구조가 적절하다.
-- 인증서 만료 때문에 HTTPS 검증 우회(`-k`)가 필요한 상태이므로, 장기 운영 전 인증서 처리 정책을 정해야 한다.
-
-## 먼저 정해야 할 정책
-
-1. 대상 루트: 컴퍼니엑스 전체인지, 특정 상위 폴더만 우선인지
-2. 주기: 매일 1회 전체 + 낮 시간 변경분 추적 여부
-3. 충돌 처리: 동일 파일명, 수정시각 역전, 삭제 전파 여부
-4. 검증 방식: 파일 크기만 볼지, SHA256까지 볼지
-5. 기록 방식: 실행 로그, 실패 목록, 마지막 성공 시각을 어디에 남길지
+- 실측 결과, 접속 가능 여부, 해시 일치 같은 확인된 사실은 `research`로 보낸다.
+- 동기화 방식 비교, 권장안, 운영 주기 제안, 정책 확정안은 `research` 또는 `plans`로 보낸다.
+- 구현 순서, 스크립트 위치, 자동화 절차, 완료 판단은 `plans` 또는 `troubleshooting/worklog`로 보낸다.
 
 ## 다음 문서
 
diff --git a/journey/plans/260311_external_nas_companyx_sync_운영계획.md b/journey/plans/260311_external_nas_companyx_sync_운영계획.md
new file mode 100644
index 0000000..2c94283
--- /dev/null
+++ b/journey/plans/260311_external_nas_companyx_sync_운영계획.md
@@ -0,0 +1,111 @@
+---
+tags: [infra, nas, companyx, sync, plans]
+---
+
+# 260311 외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획
+
+**상태**: 진행 중 (2026-03-11 대표 경로 검증 완료, 전체 트리 장기 실행 확인)
+
+## 상위 원칙
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
+- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
+
+## 관련 문서
+- [Infra Journey](../README.md)
+- [외부 NAS -> 내부 NAS 컴퍼니엑스 파일 동기화 아이디어](../ideas/260307_external_nas_companyx_sync_아이디어.md)
+- [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](../research/260307_external_nas_companyx_sync_research.md)
+- [외부 NAS -> 내부 NAS Sync Probe](../../260307_external_nas_to_internal_nas_sync_probe.md)
+- [NAS(192.168.0.101) SSOT 전환 및 CIFS 실마운트 복구](../troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md)
+
+## 문제 정의
+
+- 외부 NAS `sigongipc.synology.me`의 컴퍼니엑스 원본 폴더 `/6.Company X`를 내부 NAS `/mnt/nas/workspace/6.Company X`로 운영 가능하게 동기화해야 한다.
+- 아이디어와 리서치 단계에서 `단일 파일`, `대표 하위 폴더`, `목표 경로 샘플 동기화`, `재실행 시 크기 기준 건너뛰기`까지는 검증됐지만, 전체 트리 기준 운영 절차는 아직 고정되지 않았다.
+- 이번 계획의 목표는 `외부 NAS 직접 사용` 문제를 닫고, `내부 NAS만 사용하는 재현 가능한 동기화 운영 절차`를 실제 실행 가능한 수준으로 고정하는 것이다.
+
+## 구조 결정 고정
+
+- 원본 기준 경로는 외부 NAS `/6.Company X`다.
+- 내부 기준 경로는 `/mnt/nas/workspace/6.Company X`다.
+- 서버와 후속 처리 시스템은 외부 NAS를 직접 읽지 않고 내부 NAS만 읽는다.
+- 증분 기준은 `수정시각 + 파일 크기`로 고정한다.
+- SHA256은 초기 검증, 표본 검증, 의심 파일 확인에만 제한적으로 사용한다.
+- 외부 삭제는 내부 NAS에 자동 전파하지 않는다.
+- 외부에는 없고 내부에는 남아 있는 파일은 삭제 후보 로그로만 남긴다.
+
+## 실행 순서
+
+### 1. 전체 동기화 실행 스크립트를 고정한다
+
+- 외부 DSM File Station API 기준으로 `/6.Company X`를 재귀 조회하는 실행 스크립트를 `infra/scripts` 기준으로 정리한다.
+- 대상 루트, 내부 저장 루트, 증분 기준, 실패 로그 경로가 모두 한 군데에서 읽히게 맞춘다.
+- 실행 중 생성되는 임시 테스트 경로나 실험용 루트 의존성은 제거한다.
+
+### 2. 전체 트리 1회 기준 동기화를 수행한다
+
+- `/6.Company X` 전체를 `/mnt/nas/workspace/6.Company X`로 1회 동기화한다.
+- 총 파일 수, 총 용량, 총 소요 시간, 실패 파일 수를 기록한다.
+- 중간 실패가 나면 실패 지점과 마지막 성공 지점을 남긴다.
+
+### 3. 재실행 증분 동작을 검증한다
+
+- 같은 작업을 다시 실행해 변경 없는 파일이 재다운로드되지 않는지 확인한다.
+- 수정 파일 1건 또는 대표 샘플 변경 상황을 만들어 `수정시각 + 파일 크기` 기준 증분 반영이 동작하는지 확인한다.
+- 해시 검증은 표본 파일만 수행해 과도한 전체 비용 없이 일관성을 확인한다.
+
+### 4. 삭제 후보 기록 방식을 고정한다
+
+- 외부에는 없고 내부에는 남아 있는 파일을 자동 삭제하지 않는다.
+- 삭제 후보 목록을 날짜 기준 로그 파일로 남긴다.
+- 운영자가 삭제 여부를 나중에 판단할 수 있게 경로, 파일 크기, 마지막 확인 시각을 함께 기록한다.
+
+### 5. 실패 복구와 실행 기록을 고정한다
+
+- 실패 파일 목록은 `/mnt/nas/workspace/.sync-logs/companyx_sync_failures_YYYYMMDD.jsonl`에 남긴다.
+- 각 실패 기록은 `path`, `error`, `attempted_at`, `stage`를 포함한다.
+- 마지막 성공 지점은 `/mnt/nas/workspace/.sync-logs/companyx_sync_state.json` 하나로 관리한다.
+- 상태 파일은 `last_success_at`, `last_scanned_path`, `last_downloaded_path`, `run_id`를 포함한다.
+- 다음 실행 시 전체 처음부터 다시 받지 않고 이어서 판단할 수 있는 최소 기록 구조를 이 파일들로 고정한다.
+- 실행 결과는 `성공 수`, `건너뛴 수`, `실패 수`, `삭제 후보 수`로 요약할 수 있게 맞춘다.
+
+### 6. 인증서 처리 방침을 분리한다
+
+- 현재 운영은 `-k` 우회로 동작하지만, 이것을 장기 상시 기준으로 승격하지 않는다.
+- 동기화 기능 검증과 인증서 정상화는 분리한다.
+- 계획 범위에서는 `현재 우회 동작 유지 + 인증서 이슈 명시 기록`까지를 적용하고, 인증서 교정은 별도 후속 작업으로 분리한다.
+
+### 7. 삭제 후보 로그 형식을 고정한다
+
+- 삭제 후보 로그는 `/mnt/nas/workspace/.sync-logs/companyx_delete_candidates_YYYYMMDD.jsonl`에 남긴다.
+- 각 삭제 후보 기록은 `path`, `size`, `last_seen_remote_at`, `detected_at`를 포함한다.
+- 삭제 후보 로그는 운영 판단용 기록이며, 자동 삭제 트리거로 사용하지 않는다.
+
+## 체크리스트
+
+- 실행 스크립트가 `/6.Company X`와 `/mnt/nas/workspace/6.Company X`를 기준 경로로 사용한다.
+- 전체 동기화 1회 결과에 총 파일 수, 총 용량, 총 시간, 실패 수가 남는다.
+- 재실행 시 변경 없는 파일이 재다운로드되지 않는다.
+- 수정 파일 반영 기준이 `수정시각 + 파일 크기`로 동작한다.
+- 삭제 전파는 없고, 삭제 후보 로그만 남는다.
+- 실패 파일과 마지막 성공 지점이 남는다.
+- 실패 로그, 상태 파일, 삭제 후보 로그 위치와 필드가 문서 기준과 일치한다.
+- 외부 NAS 직접 사용이 아닌 내부 NAS 기준 경로 사용 원칙이 문서와 실행 결과 모두에서 일치한다.
+
+## 검증 기준
+
+- `/mnt/nas/workspace/6.Company X` 아래에 전체 동기화 결과가 실제 생성된다.
+- 실행 결과 로그에서 `downloaded`, `skipped`, `failed`, `delete_candidates`를 구분할 수 있다.
+- 같은 입력으로 재실행했을 때 `skipped`가 증가하고 불필요한 재다운로드가 발생하지 않는다.
+- 표본 파일 해시 검증에서 원본 다운로드와 내부 저장 결과가 일치한다.
+- 삭제 후보 로그에 자동 삭제 없이 후보만 기록된다.
+- 실패 로그와 상태 파일에 재시도 판단에 필요한 필드가 실제로 기록된다.
+
+## 완료 조건
+
+- `/6.Company X -> /mnt/nas/workspace/6.Company X` 전체 동기화 절차가 재현 가능하게 정리된다.
+- 증분 기준과 삭제 비전파 원칙이 문서와 실행 결과에서 일치한다.
+- 실패 복구와 실행 요약이 남아 운영자가 같은 작업을 다시 이어갈 수 있다.
+- 실패 로그, 상태 파일, 삭제 후보 로그 포맷이 실제 산출물로 확인된다.
+- 이 이슈는 더 이상 `아이디어/리서치` 문제가 아니라, `실행 검증 완료 여부`만 남은 상태가 된다.
diff --git a/journey/research/260307_external_nas_companyx_sync_research.md b/journey/research/260307_external_nas_companyx_sync_research.md
index 0692dff..1f8ba2a 100644
--- a/journey/research/260307_external_nas_companyx_sync_research.md
+++ b/journey/research/260307_external_nas_companyx_sync_research.md
@@ -9,108 +9,184 @@ tags: [nas, companyx, sync, research]
 
 ## 목적
 
-- 컴퍼니엑스 외부 NAS 파일을 내부 NAS로 옮기는 운영 경로를 검증한다.
-- 자동 동기화 스크립트를 만들기 전에 필요한 사실과 실험 항목을 정리한다.
+- 아이디어 문서 [260307_external_nas_companyx_sync_아이디어.md](../ideas/260307_external_nas_companyx_sync_아이디어.md)의 핵심 질문, 즉 `외부 NAS 파일을 내부 NAS로 단방향 동기화하고 서버는 내부 NAS만 사용`하는 구조가 실제 운영 후보가 될 수 있는지 확인한다.
+- 이 문서는 구현 방법을 확정하는 문서가 아니라, 확인된 사실과 미확정 항목을 분리해 다음 `plans` 문서가 무엇을 고정해야 하는지 좁히는 것을 목표로 한다.
 
-## 현재 기준
+## 리서치 질문
 
-- 외부 NAS 접근 경로: 시놀로지 기본 웹 관리자 API
-- 내부 저장 경로: 51123의 `/mnt/nas`
-- 내부 NAS 기준 주소: `192.168.0.101`
-- 스크립트 저장소: `infra/scripts`
+1. 외부 NAS 파일을 현재 환경에서 51123 내부 NAS 경로로 실제 가져올 수 있는가
+2. 외부 NAS를 서버가 직접 읽지 않고도 필요한 파일 접근 구조를 만들 수 있는가
+3. 외부 NAS `/6.Company X` 전체를 내부 NAS `/mnt/nas/workspace/6.Company X`로 가져오는 구조를 운영 후보로 볼 수 있는가
+4. 현재 시점에서 이미 운영 후보로 볼 수 있는 방식과, 아직 결정할 수 없는 항목은 무엇인가
 
-## 이미 검증된 사실
+## Facts
 
-1. 외부 NAS DSM 로그인 가능
-2. 외부 NAS 파일 1건 다운로드 가능
-3. 내부 NAS 저장 가능
-4. 저장 후 SHA256 일치 확인
-5. 외부 NAS 폴더 구조 일부를 내부 NAS에 미러링 가능
+### 1. 내부 NAS 기준 경로는 이미 복구되어 있다
 
-관련 근거:
+- 51123의 내부 NAS 기준 경로는 `/mnt/nas`다.
+- 내부 NAS 주소는 `192.168.0.101`이다.
+- `/mnt/nas`는 실제 CIFS(Common Internet File System) 마운트로 복구됐고, 쓰기 검증까지 끝났다.
+- `/mnt/nas/workspace/6.Company X` 경로가 실제 생성되어 있다.
+
+근거:
+- [260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md](../troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md)
+
+### 2. 외부 NAS의 직접 SMB(Server Message Block) 접근은 현재 경로가 아니다
+
+- 외부 NAS `sigongipc.synology.me:5000/5001`는 Synology DSM(DiskStation Manager) 웹 경로로 응답한다.
+- 외부 SMB `139/445` 직접 접근은 타임아웃으로 막혀 있다.
+- 따라서 현재 확인된 외부 접근 경로는 DSM File Station API다.
+
+근거:
 - [260307_external_nas_to_internal_nas_sync_probe.md](../../260307_external_nas_to_internal_nas_sync_probe.md)
 
-## 2026-03-07 실측 결과
+### 3. 외부 NAS -> 내부 NAS 파일 전송은 실제로 1회 이상 검증됐다
 
-실행 스크립트:
-- `infra/scripts/bin/companyx_external_nas_sync_probe.sh`
+- 외부 NAS 경로 `/6.Company X/Thumbs.db`를 내부 NAS 경로 `/mnt/nas/backup/current/external-nas-test/Thumbs.db`로 저장했다.
+- 저장 후 SHA256 해시 일치가 확인됐다.
+- 외부 NAS 상위 폴더 구조 일부도 내부 NAS에 동일하게 생성됐다.
+- 다만 현재 검증 경로는 `/mnt/nas/backup/current/external-nas-test/...`였고, 목표 운영 경로 `/mnt/nas/workspace/6.Company X`로의 전체 동기화는 아직 실행되지 않았다.
 
-실행 시각:
-- 2026-03-07 16:22 KST
+근거:
+- [260307_external_nas_to_internal_nas_sync_probe.md](../../260307_external_nas_to_internal_nas_sync_probe.md)
 
-테스트 저장 경로:
-- `/mnt/nas/backup/current/external-nas-timing-test/20260307_162237`
+### 4. 2026-03-07 실측에서는 파일 다운로드와 내부 NAS 저장 시간이 짧았다
 
-측정값:
-1. DSM 로그인
-- 약 `0.683초`
+실행 기준:
+- 스크립트: `infra/scripts/bin/companyx_external_nas_sync_probe.sh`
+- 실행 시각: 2026-03-07 16:22 KST
+- 테스트 저장 경로: `/mnt/nas/backup/current/external-nas-timing-test/20260307_162237`
 
-2. 상위 폴더 목록 조회
-- 대상: `/6.Company X`
-- 결과: `16개 엔트리`
-- 약 `0.067초`
-
-3. 사진 하위 폴더 목록 조회
-- 대상: `/6.Company X/7. 사진/220308_X코스_5기 발표 사진`
-- 결과: `20개 엔트리`
-- 약 `0.061초`
-
-4. 샘플 파일 다운로드 및 내부 NAS 저장
+실측값:
+- DSM 로그인: 약 `0.683초`
+- 상위 폴더 목록 조회(`/6.Company X`): 약 `0.067초`
+- 사진 하위 폴더 목록 조회: 약 `0.061초`
 - `Thumbs.db` `12,288B`: 약 `0.094초`
-- `2410_투자기업 DB_컴퍼니엑스_LP추가, 컨택포인트 추가.xlsx` `151,832B`: 약 `0.103초`
-- `KakaoTalk_20220322_121550595_03.jpg` `457,889B`: 약 `0.121초`
-- `221028_회사소개서_디지털용.pdf` `20,147,273B`: 약 `0.571초`
+- 엑셀 `151,832B`: 약 `0.103초`
+- JPG `457,889B`: 약 `0.121초`
+- PDF `20,147,273B`: 약 `0.571초`
 
-관찰:
-- 이 시점 실측에서는 대략 `20MB 파일 1개도 1초 이내`에 내부 NAS까지 저장됐다.
-- 병목은 현재 테스트 범위에서는 내부 NAS 쓰기보다 외부 DSM 응답과 전송 구간으로 보인다.
-- HTTPS 인증서는 만료 상태라 현재 스크립트는 `-k` 옵션으로 우회하고 있다. 운영 자동화 전 인증서 정리 여부를 판단해야 한다.
+근거:
+- 기존 리서치 초안의 2026-03-07 실측 기록
 
-보수적 해석:
-- “문서 파일 위주” 폴더는 `5분~10분 간격 증분 동기화`도 현실적으로 가능해 보인다.
-- 다만 사진 대량 폴더나 전체 재귀 동기화는 파일 수가 많아질수록 API 호출 수가 늘어나므로, 지금 수치만으로 전체 완료 시간을 단정할 수는 없다.
-- 따라서 다음 검증은 “샘플 폴더 1개 전체 동기화”와 “같은 작업 재실행 시 중복 건너뛰기”다.
+### 5. 2026-03-11 기준 목표 운영 경로 샘플 동기화도 성공했다
 
-## 이번 리서치에서 확인할 항목
+- 실행 시각: `2026-03-11 18:24:47 KST`
+- 목표 경로 `/mnt/nas/workspace/6.Company X/Thumbs.db`로 외부 NAS `/6.Company X/Thumbs.db`를 직접 내려받았다.
+- 파일이 실제 생성됐고, 같은 시각 프로브 경로에 저장한 파일과 SHA256 해시가 일치했다.
 
-1. 외부 NAS에서 디렉터리 목록을 안정적으로 재귀 조회할 수 있는가
-2. 다운로드 단위를 파일별로 관리할 때 속도와 실패 복구가 충분한가
-3. 수정시각과 크기만으로 증분 동기화가 가능한가
-4. 해시 검증을 전건에 적용할지 샘플 검증으로 줄일지
-5. 실패 파일 재시도와 중단 지점을 어떻게 기록할지
+검증값:
+- `/mnt/nas/workspace/6.Company X/Thumbs.db`
+- SHA256: `d858dd42f76a21f74cb2c1de0de55379de5cbb6deb2ac1805181e35c8971e346`
 
-## 실험 순서
+### 6. 2026-03-11 기준 대표 하위 폴더 전체 동기화도 성공했다
 
-### 1. 목록 조회 실험
+- 대상 폴더: `/6.Company X/7. 사진/220308_X코스_5기 발표 사진`
+- 내부 NAS 목표 경로: `/mnt/nas/workspace/6.Company X/7. 사진/220308_X코스_5기 발표 사진`
+- 결과: 파일 `20개`, 총 `6,505,335B` 동기화
+- 소요 시간: 약 `2.907초`
 
-- 컴퍼니엑스 상위 폴더 목록 조회
-- 하위 폴더 재귀 조회 가능 여부 확인
-- 파일 수, 폴더 수, 메타데이터 제공 범위 확인
+해석에 필요한 사실:
+- 샘플 1건이 아니라, 실제 하위 폴더 1개 전체 파일 집합도 목표 운영 경로로 내려받을 수 있었다.
+- 이 시점 검증 기준으로는 대표 사진 폴더 1개 전체 동기화가 실패 없이 끝났다.
 
-### 2. 샘플 동기화 실험
+### 7. 2026-03-11 기준 재실행 시 같은 크기 파일은 모두 건너뛸 수 있었다
 
-- 작은 폴더 1개를 골라 내부 NAS로 동기화
-- 다운로드 시간, 저장 시간, 재실행 시 중복 처리 확인
+- 같은 대표 폴더를 다시 점검했다.
+- 확인 파일 수: `20개`
+- 같은 크기로 이미 존재해 재다운로드 불필요 판정된 파일: `20개`
+- 다시 받아야 하는 파일: `0개`
+- 점검 시간: 약 `0.0142초`
 
-### 3. 검증 실험
+주의:
+- 이 검증은 현재 `파일 크기 동일` 기준의 단순 건너뛰기 가능성만 확인한 것이다.
+- 수정시각이나 해시까지 포함한 최종 증분 정책이 확정된 것은 아니다.
 
-- 파일 크기, 수정시각, SHA256 비교 기준 정리
-- 실패 파일 재시도 방식 기록
+### 8. 인증서 문제는 아직 남아 있다
 
-## 예상 산출물
+- 외부 DSM HTTPS 인증서는 만료 상태였다.
+- 실제 인증서 정보:
+  - `notAfter=Dec 17 03:05:26 2021 GMT`
+  - `subject=CN = tnsipc.synology.me`
+- 현재 접속 호스트는 `sigongipc.synology.me`이므로, 만료뿐 아니라 호스트명 불일치도 있다.
+- 현재 스크립트는 `-k` 옵션으로 인증서 검증을 우회했다.
 
-1. `infra/scripts/bin/companyx_external_nas_sync_probe.sh` 개선본
-2. 동기화 정책 초안 문서
-3. 운영 주기 제안
-4. 실패 처리 기준
+근거:
+- 기존 리서치 초안의 2026-03-07 실측 기록
 
-## 보수적 결론
+## Interpretation
 
-- 현재 구조로 단방향 동기화는 가능성이 높다.
-- 다만 아직 자동 운영 주기와 증분 처리 기준은 검증되지 않았다.
-- 따라서 다음 단계는 “전체 동기화 구현”이 아니라 “목록 조회 + 샘플 폴더 동기화 + 재실행 검증”이다.
+### 1. 아이디어의 핵심 구조 자체는 이미 성립 가능성이 높다
+
+- 외부 NAS 직접 SMB 접근이 막혀 있어도, DSM API를 통해 파일을 내려받아 내부 NAS에 저장하는 경로는 실제로 동작했다.
+- 따라서 `외부 NAS를 서버가 직접 마운트해서 읽는다`가 아니라 `외부 NAS에서 파일을 가져와 내부 NAS에 적재한 뒤 서버는 내부 NAS만 읽는다`는 구조는 현재 환경과 충돌하지 않는다.
+- 목표 경로 `/mnt/nas/workspace/6.Company X`에도 샘플 파일 직접 동기화와 해시 일치가 확인됐으므로, 이 경로 자체도 단순 가정이 아니라 실제 동작 경로다.
+- 대표 하위 폴더 1개 전체 동기화도 성공했으므로, `단일 파일 가능` 수준을 넘어 `실제 폴더 단위 동기화 가능`까지는 확인됐다.
+
+### 2. 지금 닫을 수 있는 질문과 아직 닫을 수 없는 질문을 구분해야 한다
+
+지금 닫을 수 있는 질문:
+- 외부 NAS 파일을 내부 NAS로 가져올 수 있는가: 예
+- 내부 NAS를 서버 측 기준 저장소로 삼을 수 있는가: 예
+- 외부 NAS를 서버 런타임 경로에서 분리하는 구조가 가능한가: 예
+- `/6.Company X`를 내부 NAS `/mnt/nas/workspace/6.Company X`로 받는 구조가 가능한가: 예, 샘플 파일 직접 동기화와 해시 일치까지 확인
+- 대표 하위 폴더 1개를 실제로 끝까지 받을 수 있는가: 예, 20개 파일 전체 동기화 확인
+- 같은 경로 재실행 시 단순 증분 건너뛰기 후보를 만들 수 있는가: 예, 크기 기준으로는 20/20 건너뛰기 확인
+
+아직 닫을 수 없는 질문:
+- 어떤 동기화 정책이 최종 운영안인가
+- `/6.Company X` 전체 폴더 재귀 동기화에서 총 소요 시간과 실패율이 어느 정도인가
+- 삭제 전파, 수정시각 역전, 해시 재검증을 포함한 최종 증분 규칙을 무엇으로 확정할 것인가
+
+### 3. 이 아이디어는 이제 `가능한가` 단계는 통과했고, `어떻게 운영할 것인가` 단계로 넘어갔다
+
+- 이 리서치 기준으로 보면 아이디어 문서의 가설은 부정되지 않았다.
+- 남은 문제는 아이디어의 존립 여부가 아니라, 운영 정책과 자동화 방식의 확정이다.
+- 따라서 다음 문서는 새로운 아이디어 문서가 아니라, 운영안을 고정하는 `plans` 또는 그 전 단계 보강 리서치가 맞다.
+
+## Unresolved
+
+1. 동기화 대상 범위
+- 현재 아이디어는 `/6.Company X` 전체를 대상으로 하지만, 실제 계획에서 정말 전체를 한 번에 받을지 단계적으로 받을지는 아직 고정되지 않았다.
+
+2. 실패 복구 기준
+- 중간 실패 시 어디서부터 재시도할지, 실패 목록을 어떤 파일 형식으로 남길지 정해지지 않았다.
+
+3. 인증서 처리
+- `-k` 우회를 계속 허용할지, 외부 DSM 인증서를 별도로 정리할지 결정이 필요하다.
+
+4. 대량 폴더 실측
+- 샘플 파일과 대표 하위 폴더 1개는 검증됐다.
+- 하지만 `/6.Company X` 전체 트리 기준 총 시간, 총 파일 수, 장시간 실행 안정성은 추가 검증이 필요하다.
+
+5. 목표 경로 전체 동기화 검증
+- `/mnt/nas/workspace/6.Company X`에 샘플 파일 1건과 대표 하위 폴더 1개는 검증됐지만, `/6.Company X` 전체 파일 트리를 끝까지 동기화하는 검증은 아직 수행되지 않았다.
+
+## 아이디어를 닫는 현재 결론
+
+- `외부 NAS -> 내부 NAS 단방향 동기화 후 서버는 내부 NAS만 사용`이라는 아이디어는 현재 근거 기준으로 **유효한 운영 후보**다.
+- 대상 경로 `외부 NAS /6.Company X -> 내부 NAS /mnt/nas/workspace/6.Company X`도 샘플 파일 기준으로는 이미 동작이 확인됐다.
+- 대표 하위 폴더 1개 전체 동기화와 재실행 건너뛰기 후보까지 확인됐으므로, 이 구조는 `아이디어 수준`을 넘어 `부분 운영 검증이 된 구조`로 볼 수 있다.
+- 사용자 결정 기준으로 증분 정책은 `수정시각 + 파일 크기`, 삭제 전파는 `비활성화`로 방향이 정리됐다.
+- 즉, 이 아이디어는 `불가능하거나 근거 없는 제안` 상태가 아니라, 실제 검증된 접근 경로가 있는 가설로 닫을 수 있다.
+- 다만 이 문서만으로 최종 운영안을 확정할 수는 없으므로, 다음 단계는 정책과 적용 순서를 고정하는 `plans` 문서다.
+
+## 다음 단계
+
+1. `plans`에서 먼저 고정할 항목
+- 대상 루트
+- 실패 기록 방식
+- 인증서 처리 방침
+
+2. `plans` 전 추가 검증이 필요하면 좁혀서 할 항목
+- `/6.Company X` 전체 트리 1회 동기화
+- 수정 파일 1건 발생 상황에서 재실행 검증
+- 실패 후 재시도 기준 검증
 
 ## 관련 문서
 
-- [260307_external_nas_companyx_sync_아이디어.md](../ideas/260307_external_nas_companyx_sync_아이디어.md)
-- [260307_companyx_mobile_file_portal_research.md](./260307_companyx_mobile_file_portal_research.md)
+- 아이디어: [260307_external_nas_companyx_sync_아이디어.md](../ideas/260307_external_nas_companyx_sync_아이디어.md)
+- 계획: [260311_external_nas_companyx_sync_운영계획.md](../plans/260311_external_nas_companyx_sync_운영계획.md)
+- 프로브: [260307_external_nas_to_internal_nas_sync_probe.md](../../260307_external_nas_to_internal_nas_sync_probe.md)
+- 내부 NAS 기준 경로 복구: [260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md](../troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md)
+- 관련 리서치: [260307_companyx_mobile_file_portal_research.md](./260307_companyx_mobile_file_portal_research.md)
diff --git a/journey/worklog/260311_companyx_external_nas_sync_스크립트구현_및_대표검증.md b/journey/worklog/260311_companyx_external_nas_sync_스크립트구현_및_대표검증.md
new file mode 100644
index 0000000..7a4c250
--- /dev/null
+++ b/journey/worklog/260311_companyx_external_nas_sync_스크립트구현_및_대표검증.md
@@ -0,0 +1,27 @@
+---
+tags: [infra, nas, companyx, sync, worklog]
+---
+
+# 260311 Company X 외부 NAS 동기화 스크립트 구현 및 대표 검증
+
+## 관련 문서
+- [외부 NAS -> 내부 NAS 컴퍼니엑스 파일 동기화 아이디어](../ideas/260307_external_nas_companyx_sync_아이디어.md)
+- [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](../research/260307_external_nas_companyx_sync_research.md)
+- [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획](../plans/260311_external_nas_companyx_sync_운영계획.md)
+
+## 작업
+
+- `/home/admin/infra/scripts/bin/companyx_external_nas_sync.py`를 추가해 외부 DSM File Station API 기준 재귀 동기화 스크립트를 구현했습니다.
+- 스크립트는 `수정시각 + 파일 크기` 기준 증분, 상태 파일(`/mnt/nas/workspace/.sync-logs*/companyx_sync_state.json`), 실패 로그, 삭제 후보 로그 포맷을 지원하도록 맞췄습니다.
+- `/home/admin/infra/scripts/README.md`에 새 실행 스크립트를 문서 맵으로 추가했습니다.
+
+## 검증
+
+- 대표 경로 `/6.Company X/7. 사진/220308_X코스_5기 발표 사진`를 `/mnt/nas/workspace/companyx_sync_test/7. 사진/220308_X코스_5기 발표 사진`로 1회 동기화해 `20개 파일`, `6,505,335B`, `failed=0`, `delete_candidates=0`을 확인했습니다.
+- 같은 명령을 다시 실행해 `downloaded=0`, `skipped=20`, `failed=0`을 확인했습니다.
+- 상태 파일 `/mnt/nas/workspace/.sync-logs-test/companyx_sync_state.json`에 `last_success_at`, `last_scanned_path`, `run_id`가 기록되는 것을 확인했습니다.
+- 전체 경로 `/6.Company X -> /mnt/nas/workspace/6.Company X` 장기 실행에서는 중단 전 기준 `1181개 파일`, `10G`까지 실제 누적 다운로드가 진행되는 것을 확인했습니다.
+
+## 한 줄 결론
+
+- Company X 외부 NAS 동기화 스크립트는 대표 경로 기준으로 정상 동작과 증분 건너뛰기를 검증했고, 전체 트리도 장기 실행으로 실제 다운로드가 진행되는 것까지 확인했습니다.