Add internal NAS direct sync research docs

2026-03-13 18:17:02 +09:00 · 2026-03-13 18:17:02 +09:00 · 5f6cbccdc2
commit 5f6cbccdc2
parent 0fb0e597fb
5 changed files with 681 additions and 0 deletions
--- a/journey/README.md
+++ b/journey/README.md
@ -49,12 +49,16 @@
 - [goosefarminvesting 도메인 DNS전환후 HTTPS 인증서불일치 이슈](./troubleshooting/260311_goosefarminvesting_도메인_DNS전환후_https_인증서불일치_이슈.md)
 - [Gitea git credential helper 표준화](./troubleshooting/260309_gitea_git_credential_helper_표준화.md)
 - [23서버 워크스페이스 인프라 구조정리 이슈](./troubleshooting/260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
 - [내부 NAS -> 외부 NAS 경로 교정 및 Go 프로브 검증](./troubleshooting/260313_internal_nas_external_nas_route_fix_and_go_probe_verification.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 파일 동기화 아이디어](./ideas/260307_external_nas_companyx_sync_아이디어.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간 동기화 아이디어](./ideas/260312_external_nas_companyx_실시간동기화_아이디어.md)
 - [내부 NAS 직접 Go 동기화 아이디어](./ideas/260313_internal_nas_direct_go_sync_아이디어.md)
 - [컴퍼니엑스 직원용 모바일 파일 포털 아이디어](./ideas/260307_companyx_mobile_file_portal_아이디어.md)
 - [23장애시 24서버 임시진입면승격 아이디어](./ideas/260309_23장애시_24서버_임시진입면승격_아이디어.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](./research/260307_external_nas_companyx_sync_research.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./research/260312_external_nas_companyx_실시간동기화_리서치.md)
 - [외부 NAS 동기화 Go/Python/DSM 도구화 리서치](./research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md)
 - [내부 NAS 직접 Go 동기화 가능성 리서치](./research/260313_internal_nas_direct_go_sync_feasibility_research.md)
 - [External NAS -> Internal NAS Sync Probe](./research/260307_external_nas_to_internal_nas_sync_probe.md)
 - [컴퍼니엑스 직원용 모바일 파일 포털 리서치](./research/260307_companyx_mobile_file_portal_research.md)
 - [51123 구 IP 하드코딩 실행 경로와 런타임 SSOT 불일치 리서치](./research/260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md)
--- a/journey/ideas/260313_internal_nas_direct_go_sync_아이디어.md
+++ b/journey/ideas/260313_internal_nas_direct_go_sync_아이디어.md
@ -0,0 +1,156 @@
 ---
 tags: [infra, nas, companyx, sync, go, ideas]
 ---
 # 260313 내부 NAS 직접 Go 동기화 아이디어
 ## 상위 원칙
 - [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
 - [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
 - 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
 ## 관련 문서
 - [내부 NAS -> 외부 NAS 경로 교정 및 Go 프로브 검증](../troubleshooting/260313_internal_nas_external_nas_route_fix_and_go_probe_verification.md)
 - [외부 NAS 동기화 Go/Python/DSM 도구화 리서치](../research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](../research/260312_external_nas_companyx_실시간동기화_리서치.md)
 ## 문제 인식
 - 현재 Company X 동기화의 실행 주체는 23 서버다.
 - 하지만 외부 NAS 원격 조회, 내부 NAS 저장, 주기 실행 상태를 보면 실제 데이터 중심은 내부 NAS 쪽에 더 가깝다.
 - 이번 검증으로 내부 NAS에서 외부 DSM 응답과 정적 Go 프로브 실행까지 확인됐으므로, 이제는 `23 서버를 거치지 않고 내부 NAS가 직접 동기화 주체가 되는 구조`를 검토할 수 있다.
 - 지금 구조는 `외부 NAS 조회`와 `내부 NAS 저장` 사이에 23 서버가 중간 실행자로 끼어 있다.
 - 이 중간 실행자는 현재 동작하지만, 장기적으로 보면 데이터가 머무는 곳과 실행 주체가 갈라져 있어 책임 경계가 한 번 더 꺾인다.
 ## 현재상태 -> 기대상태
 ### 현재상태
 - 실행 주체:
  - 23 서버 `crontab`
 - 실행 파일:
  - `/home/admin/infra/scripts/bin/companyx_external_nas_sync.py`
  - `/home/admin/infra/scripts/bin/companyx_external_nas_sync_hierarchical.py`
  - 래퍼:
    - `companyx_external_nas_sync_fullscan_cron.sh`
    - `companyx_external_nas_sync_hierarchical_cron.sh`
 - 스케줄:
  - `*/30 * * * *` 계층형 동기화
  - `0 1 * * *` 하루 1회 전수조사
 - 락:
  - `/home/admin/.locks/companyx_external_nas_sync.lock`
 - 런로그:
  - `/mnt/hdd/logs/companyx/companyx_external_nas_sync_hierarchical.log`
  - `/mnt/hdd/logs/companyx/companyx_external_nas_sync_fullscan.log`
 - 상태/요약:
  - `/mnt/nas/workspace/.sync-logs/`
  - `/mnt/nas/workspace/.sync-logs-hierarchical/`
 - 저장 구조:
  - 외부 NAS DSM API 조회 -> 23 서버 실행 -> 내부 NAS `/mnt/nas/workspace/6.Company X` 저장
 - 구조 해석:
  - 외부 원본은 외부 NAS
  - 실제 저장 기준은 내부 NAS
  - 하지만 동기화 판단과 실행은 23 서버가 맡고 있다.
 ### 기대상태
 - 실행 주체:
  - 내부 NAS 자체 스케줄러 또는 내부 NAS cron
 - 실행 파일:
  - 내부 NAS에 배포한 Go 단일 바이너리
 - 스케줄:
  - 현재 23 서버와 같은 `30분 계층형 + 1일 1회 전수조사`
  - 또는 같은 의미의 내부 NAS 스케줄 구성
 - 락:
  - 내부 NAS 로컬 경로에서 단일 락 파일 관리
 - 런로그:
  - 내부 NAS 로컬 로그 경로에 기록
 - 상태/요약:
  - 내부 NAS 로컬 저장소 기준 경로에 기록
 - 저장 구조:
  - 외부 NAS DSM API 조회 -> 내부 NAS 직접 실행 -> 내부 NAS 로컬 저장소 기록
 - 23 서버 역할:
  - 문서화, 상태 확인, 원격 트리거, 결과 수집만 담당
 - 구조 해석:
  - 외부 원본은 여전히 외부 NAS
  - 저장 기준도 내부 NAS
  - 실행 판단과 기록도 내부 NAS가 직접 맡는다.
 ## 아이디어
 - 동기화 프로그램을 Go 단일 바이너리로 만들고, 이를 내부 NAS에서 직접 실행한다.
 - 외부 NAS는 DSM API로 읽고, 내부 NAS 로컬 저장소로 바로 기록한다.
 - 23 서버는 동기화 본체가 아니라:
  - 문서화
  - 결과 수집
  - 경보/상태 모니터링
  - 필요 시 원격 트리거
  역할로 줄인다.
 핵심 한 줄은 아래와 같다.
 - `저장 기준이 내부 NAS라면, 동기화 실행 주체도 내부 NAS로 맞추는 편이 더 자연스럽다.`
 ## 23 서버와 같은 설정으로 갈 수 있는가
 결론부터 말하면 `운영 의미는 거의 같게`, `구체 경로는 일부 다르게` 가져갈 수 있다.
 ### 그대로 가져갈 수 있는 것
 - `30분 계층형 + 새벽 1시 전수조사`의 이중 스케줄 구조
 - `단일 락 파일로 중복 실행 방지` 원칙
 - `실행 로그`와 `상태/요약 JSON`을 분리하는 방식
 - `mtime + size` 기반 증분 판정 방향
 - `계층형 캐시 + 전수조사 보정`이라는 운영 개념
 ### 이름은 같게 가져갈 수 있지만 경로는 바뀌는 것
 - 현재 23 서버 경로:
  - `/home/admin/infra/scripts/bin/...`
  - `/home/admin/.locks/...`
  - `/mnt/hdd/logs/companyx/...`
  - `/mnt/nas/workspace/.sync-logs...`
 - 내부 NAS 직접 실행 시:
  - NAS 로컬 실행 경로
  - NAS 로컬 락 경로
  - NAS 로컬 로그 경로
  - NAS 로컬 상태/요약 경로
  로 재정의해야 한다.
 ### 그대로 가져가면 안 되는 것
 - `/mnt/nas`를 실행 경로로 쓰는 방식
  - 현재 CIFS 마운트 경로 직접 실행은 `Permission denied`였다.
 - 23 서버의 `crontab` 자체
  - 내부 NAS에서는 DSM 작업 스케줄러 또는 NAS 측 cron에 맞춰 다시 정의해야 한다.
 - 23 서버의 `workspace-config` 파일 경로 하드코딩
  - 내부 NAS는 별도 런타임/시크릿 주입 방식이 필요하다.
 즉 이 아이디어는 `23 서버 설정을 그대로 복사`하는 것이 아니라, `운영 패턴은 동일하게 유지하고 실행 위치와 경로만 내부 NAS 기준으로 치환`하는 방향이 맞다.
 ## 기대 효과
 - 외부 NAS 조회와 내부 NAS 저장 사이에 23 서버를 중간 실행자로 두지 않아 구조가 단순해진다.
 - 저장 기준 장비와 실행 주체가 같아져서, 실패 위치와 운영 책임 경계가 더 직접적으로 보인다.
 - Go 단일 바이너리 기준으로 내부 NAS에 배포·교체하기 쉬운 구조를 만들 수 있다.
 - 23 서버 장애가 곧바로 동기화 주체 장애로 이어지지 않는 방향을 만들 수 있다.
 ## 검증이 필요한 이유
 - 현재는 `DSM 로그인 + 목록 조회`까지만 검증됐고, 실제 파일 다운로드/증분 판단/삭제 후보 기록 전체를 내부 NAS Go 바이너리로 옮긴 것은 아니다.
 - 내부 NAS DSM 6.2.4 환경에서 재부팅 후 기본 게이트웨이 교정이 유지되는지 아직 별도 검증이 없다.
 - 내부 NAS에서 장시간 동기화 프로세스를 어떤 방식으로 스케줄링하고, 로그를 어디에 남기고, 실패 시 누가 복구를 담당할지 운영안이 아직 열려 있다.
 ## 이 문서에서 빼야 하는 내용
 - 실행 순서, 배포 절차, 롤백 절차, 상태 파일 스키마 확정은 `plans`로 보낸다.
 - 실제 구현 코드, 빌드 명령, 배포 로그, 검증 결과는 `worklog` 또는 `troubleshooting`으로 보낸다.
 - 현재 Python 스크립트를 어떤 범위까지 유지할지, 병행 운영 기간을 둘지는 `plans`에서 정한다.
 ## 현재 판단
 - 이 아이디어는 `불가능한가` 단계는 이미 지났다.
 - 현재 남은 질문은 `내부 NAS 직접 실행이 더 자연스러운 구조인가`인데, 지금까지의 검증으로는 `그렇다` 쪽 근거가 더 강하다.
 - 따라서 이 문서의 핵심 제안은 아래 한 문장으로 닫을 수 있다.
 `Company X 외부 NAS 동기화는 장기적으로 23 서버 경유 구조보다 내부 NAS 직접 Go 실행 구조가 더 자연스럽다.`
--- a/journey/research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md
+++ b/journey/research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md
@ -0,0 +1,189 @@
 ---
 tags: [infra, nas, dsm, sync, go, python, research]
 ---
 # 260313 외부 NAS 동기화 Go/Python/DSM 도구화 리서치
 ## 상위 원칙
 - [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)
 ## 관련 문서
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](./260307_external_nas_companyx_sync_research.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./260312_external_nas_companyx_실시간동기화_리서치.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획](../plans/260311_external_nas_companyx_sync_운영계획.md)
 - [Company X 외부 NAS 동기화 스크립트 구현 및 대표 검증](../worklog/260311_companyx_external_nas_sync_스크립트구현_및_대표검증.md)
 - [Company X 30분주기 cron 적용 및 예측 검증](../worklog/260312_companyx_sync_30분주기_cron적용_및_예측검증.md)
 ## 목적
 - 사용자가 제공한 Gemini 대화 내용을 기준으로, `Go로 바꾸면 얼마나 빨라지는가`, `어디에 배포해야 하는가`, `DSM 로그인만 가능한 환경에서 어떤 방식이 맞는가`를 현재 검증 근거와 공식 문서 기준으로 다시 좁힙니다.
 - 이 문서는 구현 계획을 확정하는 문서가 아니라, 어떤 주장이 근거가 있고 어떤 주장이 과장인지 분리하는 `research` 문서입니다.
 ## 분류 판단
 - 이 주제는 `도구 선택 + 배포 위치 + DSM 접근 방식 + NAS 동기화 병목`을 다루므로 `infra/DOCS/journey/research`가 맞습니다.
 - 이유:
  - 외부 NAS -> 내부 NAS 동기화는 이미 `infra`가 SSOT입니다.
  - 아직 실행 방식을 확정하지 않았으므로 `plans`가 아닙니다.
  - 현재 장애 복구 기록이 아니라 선택지 검증이므로 `troubleshooting`도 아닙니다.
 ## 입력 질문
 1. 에이전트가 쓰는 CLI 도구는 어떤 형식이 적합한가
 2. 대량 PostgreSQL 쿼리, 유사도 검색, 파일 메타데이터 스캔은 Go가 Python보다 무조건 빠른가
 3. 현재 주기 실행 중인 외부 NAS 동기화 검사를 Go로 옮기면 어느 정도 이점이 생기는가
 4. 배포 위치는 내부 NAS 직접 실행이 맞는가, 중간 서버가 맞는가
 5. SSH가 아니라 DSM 로그인만 가능한 외부 NAS에서도 브라우저 없이 운영 가능한가
 ## Facts
 ### 1. 현재 운영 중인 외부 NAS 동기화 구조는 Python 스크립트 + DSM API pull 방식이다
 - 기존 리서치와 worklog 기준, 현재 검증된 경로는 `외부 NAS DSM API 조회/다운로드 -> 내부 NAS 저장`이다.
 - 외부 NAS에 대한 직접 SMB 마운트나 SSH 실행이 현재 운영 기준은 아니다.
 - 내부 NAS 쪽만 우리가 수정 가능하고, 외부 NAS는 읽기 위주 접근 제약이 있다.
 근거:
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](./260307_external_nas_companyx_sync_research.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./260312_external_nas_companyx_실시간동기화_리서치.md)
 ### 2. 현재 전체 병목은 Python 인터프리터보다 `원격 DSM API 재귀 조회 + 네트워크 전송` 쪽에 더 가깝다
 - 2026-03-12 실측 기준 전체 루트 전수 조회는 약 `23분대`로 추정됐다.
 - 같은 문서에서 루트 1회 조회는 약 `60ms`, 루트 + 1차 폴더 조회는 약 `0.98초`였다.
 - 즉 현재 구조에서 가장 큰 비용은 `전체 파일 트리를 원격으로 다시 훑는 것`이지, 프로세스 시작 몇백 ms 자체라고 보기 어렵다.
 - 따라서 `Go로 바꾸면 무조건 10배~100배` 같은 문장은 현재 검증 범위를 벗어난다.
 근거:
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./260312_external_nas_companyx_실시간동기화_리서치.md)
 ### 3. 변경 판정은 해시보다 `파일 크기 + 수정시각(stat)`이 훨씬 빠르다
 - 2026-03-12 표본 측정 기준 같은 파일 집합에서 `sha256`은 `stat`보다 평균 `666.4배` 느렸다.
 - 따라서 현재 운영 질문이 `변경 여부를 자주 판정해야 하는가`라면, 언어 선택 이전에 `판정 기준`을 먼저 최적화해야 한다.
 근거:
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./260312_external_nas_companyx_실시간동기화_리서치.md)
 ### 4. DSM 로그인만 가능한 환경에서도 브라우저 자동화가 필수는 아니다
 - Synology 공식 문서는 `DSM Login Web API`와 `File Station API`를 별도 가이드로 제공한다.
 - 즉 DSM 웹 화면을 사람이 브라우저로 여는 구조와, 프로그램이 HTTP 요청으로 로그인/파일 조회를 수행하는 구조는 분리 가능하다.
 - 현재 우리 운영 경로도 브라우저 자동화가 아니라 DSM API 기반 검증 쪽에 가깝다.
 공식 출처:
 - `DSM Login Web API Guide`
  - https://global.download.synology.com/download/Document/Software/DeveloperGuide/Os/DSM/All/enu/DSM_Login_Web_API_Guide_enu.pdf
 - `Synology File Station API Guide`
  - https://global.download.synology.com/download/Document/Software/DeveloperGuide/Package/FileStation/All/enu/Synology_File_Station_API_Guide.pdf
 ### 5. Python의 GIL은 `CPU-bound Python bytecode` 병렬성에 제약을 주지만, I/O 대기 중에는 다른 스레드가 진행될 수 있다
 - Python 공식 문서는 GIL이 Python objects 접근 전 필요하다고 설명한다.
 - 같은 문서에서 블로킹 I/O 동안에는 GIL이 해제된다고 설명한다.
 - 따라서 `Python은 동시에 실행하는 척만 한다`는 표현은 과장이다.
 - 지금 NAS 동기화처럼 원격 HTTP 요청과 파일 저장이 섞인 경로에서는, GIL만으로 전체 성능을 단정하면 안 된다.
 공식 출처:
 - https://docs.python.org/3/c-api/threads.html
 ### 6. Go 단일 바이너리 배포와 낮은 실행 오버헤드는 실제 장점이 맞다
 - Go는 정적 컴파일 바이너리 배포가 쉬워서, Python 런타임/패키지 의존성을 줄이기 좋다.
 - NAS나 경량 서버에 올릴 때 실행 환경 단순화와 시작 속도 이점이 있다.
 - 다만 이것이 곧바로 `원격 DSM API 기반 전체 동기화가 수십 배 빨라진다`는 뜻은 아니다.
 ### 7. 에이전트용 CLI 문서는 사람이 읽는 README보다 기계 친화적 스키마가 더 적합하다는 방향은 타당하다
 - 사용자가 제시한 Gemini 답변 중 `단일 바이너리 + 기계가 읽는 스킬/스펙 파일` 구상은 에이전트용 도구 설계 방향으로 타당하다.
 - 다만 현재 infra 운영에는 먼저 `도구 형식`보다 `어디서 실행하고 어떤 API를 쓰는지`가 선결 문제다.
 ## Interpretation
 ### 1. 이 문서는 `도구/언어 리서치`이면서 동시에 `인프라 리서치`다
 - 일반적인 Go vs Python 비교 문서라면 `orchestration_tools` 성격도 있지만,
 - 이번 케이스는 `외부 NAS`, `내부 NAS`, `DSM`, `주기 동기화`, `배포 위치`가 핵심이므로 `infra`가 1차 SSOT다.
 - 따라서 `이것도 리서치인가`에 대한 답은 `그렇다`, 다만 `인프라 리서치`가 더 정확하다.
 ### 2. 현재 기준으로는 `언어 전환`보다 `스캔 범위 축소`가 더 큰 효과를 낼 가능성이 높다
 - 이미 측정된 값만 봐도 전체 전수 조회와 상위 폴더 메타 확인 사이 격차가 매우 크다.
 - 따라서 현재 구조에서 먼저 풀어야 할 문제는:
  - 전체 트리 재귀 조회를 얼마나 줄일지
  - 어떤 폴더만 더 내려갈지
  - 해시 대신 어떤 증분 기준을 쓸지
 이다.
 - 이 최적화 없이 언어만 바꾸면 체감 개선은 제한적일 수 있다.
 ### 3. Go 전환의 가장 확실한 이점은 `배포 단순화`, `낮은 메모리`, `병렬 구조 표현`, `장기 데몬화`다
 - 현 구조를 Go로 옮기면 기대할 수 있는 현실적 이점은 아래에 가깝다.
  - 내부 NAS나 51123에서 단일 바이너리 실행
  - 장기 실행 프로세스/데몬 유지
  - 동시 HTTP 요청과 파일 쓰기 구조를 더 단순하게 관리
  - 실행 환경 의존성 감소
 - 반대로 `무조건 10배`, `무조건 50배`, `0.5초 완주` 같은 수치는 현재 근거로는 말할 수 없다.
 ### 4. PostgreSQL 대량 쿼리/유사도 검색도 `Go가 무조건 압승`이라고 쓰면 안 된다
 - DB 왕복, 인덱스, SQL 계획, 네트워크 지연이 지배적인 경우 언어 차이는 제한적일 수 있다.
 - Python도 `asyncpg`, NumPy, pgvector, DB-side similarity search를 쓰면 병목 위치가 달라진다.
 - 따라서 이 부분은 `CPU-bound 순수 Python 루프`와 `DB-bound/extension-bound 경로`를 분리해서 봐야 한다.
 - 지금 Gemini 답변처럼 `최소 10배 이상`으로 일반화하면 SSOT 문장으로는 부정확하다.
 ### 5. 배포 위치는 현재 제약상 `내부 NAS 또는 우리가 제어하는 서버`가 맞다
 - 외부 NAS는 수정 권한이 없고 읽기 중심이다.
 - 현재 검증된 구조도 `외부는 원격 조회`, `내부는 저장/관리`다.
 - 따라서 Go든 Python이든 실행 주체는 `내부 NAS` 또는 `51123 같은 제어 가능한 서버`가 자연스럽다.
 - 다만 `내부 NAS 직접 실행`이 항상 정답이라고 단정하기보다, 아래 조건을 비교해야 한다.
  - DSM API 세션 관리 위치
  - 내부 NAS에 배포/로그/재시작 관리가 쉬운가
  - 51123에서 이미 운영 중인 cron/log/문서 체계를 재사용하는 편이 나은가
 ### 6. `DSM 로그인만 가능 = 크롬 필요`는 틀린 해석이다
 - 현재 확인 범위에서는 DSM 웹 UI가 아니라 Web API를 직접 호출하는 편이 더 보수적이고 검증 가능하다.
 - 즉 로그인은 `브라우저 시뮬레이션`보다 `HTTP client + 세션 관리` 문제로 보는 것이 맞다.
 - 브라우저 자동화는 API가 막히거나 특정 UI 흐름 검증이 필요할 때의 예외 경로에 가깝다.
 ### 7. 에이전트용 도구 형식은 `단일 바이너리 + JSON 출력 + 명시적 오류코드`가 유리하다
 - 에이전트가 쓴다면 사람이 읽기 좋은 문장보다 아래가 중요하다.
  - 입력 플래그
  - 출력 JSON 스키마
  - 종료 코드
  - 재시도 가능 오류와 불가 오류 구분
 - 따라서 향후 Go 전환을 한다면, 문서 형식은 `README 장문`보다 `기계가 읽기 쉬운 계약 + 짧은 운영 설명` 조합이 맞다.
 ## Unresolved
 1. 현재 Python 구현에서 실제 CPU 시간과 I/O 시간을 분리 계측한 프로파일이 없다.
 2. `51123 실행`과 `내부 NAS 직접 실행` 중 어느 쪽이 운영상 더 나은지 아직 비교 실측이 없다.
 3. DSM API 병렬 호출을 어느 수준까지 올려도 외부 NAS가 안정적으로 버티는지 미측정이다.
 4. Go 프로토타입을 같은 데이터셋에 대해 돌린 A/B 실측이 없다.
 5. PostgreSQL 대량 쿼리/유사도 검색 항목은 현재 Company X NAS 동기화 경로와 다른 병목이므로 별도 리서치로 분리하는 편이 맞다.
 ## 결론
 - 이번 Gemini 대화는 `에이전트용 CLI 형식`, `DSM API 직접 사용`, `Go 단일 바이너리 배포` 같은 방향성에서는 참고 가치가 있다.
 - 하지만 `Go가 Python보다 무조건 10~100배 빠르다`는 식의 수치는 현재 infra 문서 기준으로 확정할 수 없다.
 - 지금 우선순위는 `언어 교체` 단독이 아니라 `계층형 메타 탐색`, `증분 기준 최적화`, `배포 위치 비교`, `A/B 프로토타입 실측`이다.
 ## 다음 단계 제안
 1. 현재 Python 스크립트에 `I/O 대기`, `DSM API 응답`, `로컬 파일 쓰기`, `메타 비교` 시간을 분리 계측한다.
 2. 같은 입력 집합으로 최소 기능 Go 프로토타입을 만들어 A/B 측정한다.
 3. 결과가 유의미하면 그때 `plans` 문서에서 `51123 실행` vs `내부 NAS 직접 실행`을 고정한다.
 ## 출처
 - Synology DSM Login Web API Guide
  - https://global.download.synology.com/download/Document/Software/DeveloperGuide/Os/DSM/All/enu/DSM_Login_Web_API_Guide_enu.pdf
 - Synology File Station API Guide
  - https://global.download.synology.com/download/Document/Software/DeveloperGuide/Package/FileStation/All/enu/Synology_File_Station_API_Guide.pdf
 - Python C API: Thread State and the Global Interpreter Lock
  - https://docs.python.org/3/c-api/threads.html
--- a/journey/research/260313_internal_nas_direct_go_sync_feasibility_research.md
+++ b/journey/research/260313_internal_nas_direct_go_sync_feasibility_research.md
@ -0,0 +1,203 @@
 ---
 tags: [infra, nas, companyx, sync, go, research]
 ---
 # 260313 내부 NAS 직접 Go 동기화 가능성 리서치
 ## 상위 원칙
 - [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)
 ## 관련 문서
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](./260307_external_nas_companyx_sync_research.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./260312_external_nas_companyx_실시간동기화_리서치.md)
 - [외부 NAS 동기화 Go/Python/DSM 도구화 리서치](./260313_external_nas_sync_go_python_dsm_tooling_리서치.md)
 - [내부 NAS -> 외부 NAS 경로 교정 및 Go 프로브 검증](../troubleshooting/260313_internal_nas_external_nas_route_fix_and_go_probe_verification.md)
 - [내부 NAS 직접 Go 동기화 아이디어](../ideas/260313_internal_nas_direct_go_sync_아이디어.md)
 ## 목적
 - 지금 풀려는 문제, 즉 `외부 NAS 조회 -> 내부 NAS 직접 실행/저장` 구조가 실제 운영 후보가 되는지 확인한다.
 - 이 문서는 아이디어를 확정하는 문서가 아니라, 현재 검증된 사실 기준으로 어디까지 말할 수 있는지 좁히는 `research` 문서다.
 - 특히 `내부 NAS가 직접 동기화 실행 주체가 되는 구조`가 infra SSOT의 역할 분리 원칙과 충돌하는지 함께 본다.
 ## 리서치 질문
 1. 현재 23 서버가 맡고 있는 Company X 동기화 역할을 내부 NAS가 기술적으로 대신할 수 있는가
 2. 내부 NAS 직접 실행은 infra SSOT의 `23은 진입과 제어, NAS는 보존과 복구` 원칙과 충돌하는가
 3. 23 서버 운영 패턴을 내부 NAS에서도 같은 의미로 재현할 수 있는가
 4. 지금 시점에서 이미 닫힌 질문과 아직 남아 있는 질문은 무엇인가
 ## Facts
 ### 1. 현재 운영 구조는 `23 서버 실행 -> 내부 NAS 저장`이다
 - 23 서버 `crontab`에는 아래 두 엔트리가 등록돼 있다.
  - `*/30 * * * * /home/admin/infra/scripts/bin/companyx_external_nas_sync_hierarchical_cron.sh`
  - `0 1 * * * /home/admin/infra/scripts/bin/companyx_external_nas_sync_fullscan_cron.sh`
 - 실제 실행 스크립트는 23 서버 `infra/scripts/bin/` 아래 Python 본체와 shell 래퍼로 구성돼 있다.
 - 상태/요약은 내부 NAS 마운트 경로인 `/mnt/nas/workspace/.sync-logs*`에 남고, 런로그는 23 서버 `/mnt/hdd/logs/companyx/`에 남는다.
 ### 2. 현재 동기화 원본 접근 방식은 DSM API pull이다
 - 외부 NAS에 대한 직접 SMB 접근은 현재 운영 경로가 아니다.
 - 현재 검증된 접근 경로는 `Synology DSM Login Web API + File Station API`다.
 - 이 경로는 브라우저 자동화가 아니라 HTTP 요청 기반 로그인/목록 조회/다운로드 방식이다.
 공식 출처:
 - https://global.download.synology.com/download/Document/Software/DeveloperGuide/Os/DSM/All/enu/DSM_Login_Web_API_Guide_enu.pdf
 - https://global.download.synology.com/download/Document/Software/DeveloperGuide/Package/FileStation/All/enu/Synology_File_Station_API_Guide.pdf
 ### 3. 내부 NAS는 외부 NAS DSM에 직접 접속할 수 있게 됐다
 - 최초 검증에서는 내부 NAS `192.168.0.101`에서 외부 NAS `sigongipc.synology.me:5001`로 접속 시 `no route to host`가 발생했다.
 - 확인 결과 내부 NAS는 기본 경로를 여전히 `192.168.219.1 dev eth0`로 잡고 있었고, `/etc/iproute2/config/default-gateway`도 `DEVICE="tun0"`로 남아 있었다.
 - 이 값을 `eth1` 기준으로 교정한 뒤, 내부 NAS에서 외부 DSM `HTTP/2 200` 응답과 Go 정적 프로브 실행까지 성공했다.
 근거:
 - [내부 NAS -> 외부 NAS 경로 교정 및 Go 프로브 검증](../troubleshooting/260313_internal_nas_external_nas_route_fix_and_go_probe_verification.md)
 ### 4. 내부 NAS에서 Go 정적 바이너리 자체는 실행 가능하다
 - 동적 빌드 바이너리는 `GLIBC_2.32`, `GLIBC_2.34` 미충족으로 실패했다.
 - `CGO_ENABLED=0` 정적 빌드 바이너리는 내부 NAS 홈 디렉터리에서 정상 실행됐다.
 - 실행 결과:
  - DSM 로그인 성공
  - `/6.Company X` 루트 목록 조회 성공
  - 대표 사진 폴더 목록 조회 성공
 즉 내부 NAS는 `Go 실행 불가 장비`가 아니라, `정적 바이너리 형태가 필요한 장비`로 보는 것이 맞다.
 ### 5. CIFS 마운트 경로는 실행 경로로 부적합하다
 - 23 서버의 `/mnt/nas`는 내부 NAS `//192.168.0.101/home`을 CIFS로 마운트한 경로다.
 - 해당 마운트는 `file_mode=0664`로 잡혀 있어, 여기에 복사한 바이너리는 `chmod +x` 이후에도 실행이 되지 않았다.
 - 실제 결과는 `Permission denied`였다.
 즉 `내부 NAS 직접 실행`을 하더라도 실행 파일은 NAS 로컬 경로에 둬야 하며, 23 서버의 `/mnt/nas` 경로를 실행 기준으로 보면 안 된다.
 ### 6. 23 서버 운영 패턴의 핵심 요소는 경로보다 구조에 있다
 현재 23 서버 운영의 핵심 요소:
 - 이중 스케줄
  - 30분 계층형 동기화
  - 새벽 1시 전수조사
 - 단일 락 파일로 중복 실행 방지
 - 런로그와 상태/요약 JSON 분리
 - `mtime + size` 기반 증분 판단
 - 계층형 캐시 + 일일 전수보정
 이 요소들은 23 서버에만 고유한 것이 아니라, 내부 NAS 직접 실행으로도 개념상 옮길 수 있다.
 ### 7. 다만 `23의 역할`과 `NAS의 역할`은 그대로 두면 긴장이 생긴다
 - infra SSOT는 `23은 진입과 제어, 24는 실행, NAS는 보존과 복구`를 기본 역할로 둔다.
 - 내부 NAS가 동기화 프로세스를 직접 돌리면, NAS가 일부 `실행` 역할을 맡게 된다.
 - 따라서 이 구조는 "NAS는 절대 실행하면 안 된다"는 금지선과는 다르지만, 최소한 `예외적 실행 역할`을 문서화하지 않으면 역할 경계가 흐려질 수 있다.
 ### 8. 23 서버 1분 벤치마크 기준, 외부 NAS `검토` 성격 작업에서는 Go가 Python보다 소폭 더 효율적이었다
 - 비교 대상:
  - Python: `companyx_external_nas_probe_benchmark.py`
  - Go: `companyx_external_nas_probe_benchmark_go`
 - 공통 작업:
  - DSM 로그인 1회
  - 루트 `/6.Company X` 목록 조회 1회
  - 대표 사진 폴더 목록 조회 1회
  - 이 3단계를 1사이클로 보고 23 서버에서 약 `60초` 동안 반복
 - 실행일:
  - `2026-03-13`
 - 공통 조건:
  - 동일 서버
  - 동일 외부 NAS
  - 동일 DSM API
  - 동일 경로
  - 다운로드 없이 `검토/목록 조회`만 수행
 실측값:
 | 항목 | Python | Go | 비교 |
 |---|---:|---:|---:|
 | 총 실행 시간 | `60.506초` | `60.745초` | 유사 |
 | 총 사이클 수 | `66` | `70` | Go `+6.1%` |
 | 분당 사이클 수 | `65.45` | `69.14` | Go `+5.6%` |
 | 평균 로그인 | `799.109ms` | `786.544ms` | Go `1.6%` 빠름 |
 | 평균 루트 목록 조회 | `58.155ms` | `38.795ms` | Go `33.3%` 빠름 |
 | 평균 대표 폴더 목록 조회 | `58.809ms` | `42.409ms` | Go `27.9%` 빠름 |
 해석에 필요한 사실:
 - 이 벤치마크는 `전체 동기화`가 아니라 `외부 NAS 상태 검토`에 가까운 작업이다.
 - 로그인 시간은 두 언어 차이가 작았고, 목록 조회는 Go 쪽이 더 빨랐다.
 - 결과적으로 1분 동안 처리한 총 사이클 수는 Go가 Python보다 약 `5~6%` 높았다.
 - 따라서 현재 23 서버 기준에서는 `검토/메타 조회 루프`에서 Go가 더 효율적이라고 말할 수는 있지만, `압도적 차이`라고 말할 수준은 아니다.
 ## Interpretation
 ### 1. 기술적으로는 이미 운영 후보다
 - 내부 NAS -> 외부 NAS 네트워크 경로가 열렸고,
 - 내부 NAS에서 Go 정적 바이너리 실행도 검증됐으며,
 - 외부 DSM 로그인/목록 조회가 끝까지 성공했기 때문에,
 현재 사실 범위에서는 `외부 NAS 조회 -> 내부 NAS 직접 실행/저장` 구조를 단순 아이디어가 아니라 `기술적으로 가능한 운영 후보`로 볼 수 있다.
 ### 2. 이 전환의 본질은 성능보다 책임 경계 재배치다
 - 기존 리서치 기준으로 현재 병목은 Python 언어 자체보다 `전체 DSM 트리 재조회`에 더 가깝다.
 - 따라서 내부 NAS 직접 Go 실행의 1차 가치는 "무조건 더 빠르다"가 아니라:
  - 저장 기준과 실행 주체를 맞추고
  - 중간 실행자 23 서버를 줄이며
  - 동기화 실패 위치를 더 직접적으로 만드는 것
  에 있다.
 - 이번 1분 벤치마크도 같은 결론을 지지한다.
  - Go가 더 효율적이긴 했지만, 개선 폭은 `검토 루프 기준 소폭 우위`에 가까웠다.
  - 따라서 이 전환을 `속도만으로 정당화`하는 것은 여전히 과장이다.
  - 다만 `짧은 주기 메타 조회`를 자주 수행해야 한다면 Go 쪽이 누적 효율 이점을 줄 가능성은 있다.
 ### 3. SSOT 원칙과의 충돌은 `절대 충돌`이 아니라 `예외 역할 문서화 필요`로 해석하는 편이 맞다
 - SSOT 원칙만 기계적으로 읽으면 NAS는 보존/복구 역할이므로 실행 주체가 되면 안 되는 것처럼 보일 수 있다.
 - 하지만 실제 운영 요구를 보면, 여기서 NAS는 "일반 애플리케이션 실행 노드"가 아니라 "자기 저장소를 외부 원본과 맞추는 최소 동기화 실행자" 역할을 맡는 것이다.
 - 이 정도 범위의 실행은 `보존과 복구를 위한 보조 실행`으로 해석할 수 있다.
 - 다만 이 해석은 자동으로 주어지는 것이 아니라, 이후 구조 문서나 계획 문서에서 예외 역할을 분명히 적어야 한다.
 ### 4. `23 서버와 같은 설정`은 `같은 경로 복제`가 아니라 `같은 운영 패턴 복제`로 보는 것이 정확하다
 - 23 서버와 완전히 같은 경로를 내부 NAS에 복제할 수는 없다.
 - 하지만 아래는 거의 같은 의미로 옮길 수 있다.
  - 30분 + 1일 1회 이중 스케줄
  - 락 파일
  - 로그/상태/요약 분리
  - 계층형 캐시
  - `mtime + size` 증분 기준
 따라서 질문은 "경로를 그대로 복사할 수 있느냐"보다 "운영 패턴을 내부 NAS 기준으로 치환할 수 있느냐"로 바꾸는 편이 맞다.
 ### 5. 지금 시점에서 가장 정확한 결론은 아래 한 문장이다
 `Company X 외부 NAS 동기화는 23 서버 경유 구조보다 내부 NAS 직접 Go 실행 구조가 더 자연스러운 운영 후보이며, 현재 근거로도 기술적 가능성은 이미 확인됐다.`
 ## Unresolved
 1. 내부 NAS에서 실제 전체 다운로드/증분/삭제 후보 기록까지 포함한 Go 구현은 아직 없다.
 2. 내부 NAS 로컬 로그 경로, 상태 경로, 락 경로를 어디로 둘지 아직 확정되지 않았다.
 3. 내부 NAS 재부팅 후 `eth1` 기본 게이트웨이 교정이 지속되는지 아직 장기 검증이 없다.
 4. DSM 작업 스케줄러와 NAS 측 cron 중 어떤 실행 방식이 더 적합한지 아직 미확정이다.
 5. 23 서버가 완전히 빠질지, 문서화/원격 트리거/관찰 경로로 일부 남을지 운영 경계가 아직 열려 있다.
 6. 1분 벤치마크는 `로그인 + 목록 조회`만 비교했으므로, 실제 다운로드/증분/삭제 후보 기록까지 포함한 end-to-end 차이는 아직 미측정이다.
 ## 결론
 - `외부 NAS 조회 -> 내부 NAS 직접 실행/저장`은 현재 기준으로 기술적 가능성이 검증된 구조다.
 - 이 구조의 핵심 가치는 속도 과장보다 `책임 경계 단순화`와 `저장 기준-실행 주체 일치`에 있다.
 - 다만 SSOT 원칙상 NAS의 기본 역할을 넘는 부분이 있으므로, 이후 문서에서는 `보존을 위한 최소 실행 예외`를 분명히 적어야 한다.
 ## 다음 단계 제안
 1. 내부 NAS 직접 Go 동기화의 경로/로그/락/스케줄러를 고정하는 계획 문서 작성
 2. 정적 Go 바이너리로 `계층형 동기화` 최소 구현 프로토타입 작성
 3. 재부팅 후 기본 게이트웨이와 외부 DSM 접속이 유지되는지 검증
--- a/journey/troubleshooting/260313_internal_nas_external_nas_route_fix_and_go_probe_verification.md
+++ b/journey/troubleshooting/260313_internal_nas_external_nas_route_fix_and_go_probe_verification.md
@ -0,0 +1,129 @@
 ---
 tags: [infra, nas, companyx, sync, go, troubleshooting]
 ---
 # 260313 내부 NAS -> 외부 NAS 경로 교정 및 Go 프로브 검증
 **상태**: 해결 및 종료
 ## 상위 원칙
 - [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)
 ## 관련 문서
 - [외부 NAS 동기화 Go/Python/DSM 도구화 리서치](../research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](../research/260312_external_nas_companyx_실시간동기화_리서치.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획](../plans/260311_external_nas_companyx_sync_운영계획.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간 동기화 아이디어](../ideas/260312_external_nas_companyx_실시간동기화_아이디어.md)
 ## 문제 정의
 - 내부 NAS `192.168.0.101`에서 외부 NAS `sigongipc.synology.me:5001`로 직접 접속하는 Go 프로브를 실행하자 `no route to host`가 발생했다.
 - 같은 외부 DSM 경로는 23 서버 `192.168.0.100`에서는 정상 응답했기 때문에, 문제는 외부 NAS 자체가 아니라 내부 NAS의 네트워크 경로 쪽에 있었다.
 - 이 상태에서는 `23 서버를 거치지 않고 내부 NAS가 직접 외부 NAS 동기화 주체가 되는 구조`를 검증할 수 없다.
 ## 재현 조건
 - 23 서버: `192.168.0.100`
 - 내부 NAS:
  - `eth0 = 192.168.219.51`
  - `eth1 = 192.168.0.101`
 - 외부 NAS 호스트: `sigongipc.synology.me`
 - 테스트 바이너리:
  - 동적 빌드: `companyx_external_nas_sync_probe_go`
  - 정적 빌드: `companyx_external_nas_sync_probe_go_static`
 ## 확인된 사실
 ### 1. 23 서버에서는 외부 DSM 접속이 정상이다
 - 23 서버에서 `getent hosts sigongipc.synology.me`는 `112.218.113.4`를 반환했다.
 - 같은 서버에서 `curl -Iks https://sigongipc.synology.me:5001`은 `HTTP/2 200`을 반환했다.
 - 즉 외부 NAS DNS와 외부 DSM 서비스 자체는 살아 있었다.
 ### 2. 내부 NAS의 현재 기본 경로는 내부망 기준과 어긋나 있었다
 - 내부 NAS 라우팅 테이블 확인 결과 기본 경로는 `default via 192.168.219.1 dev eth0 src 192.168.219.51`였다.
 - 같은 시각 `eth1`은 `192.168.0.101`로 살아 있었고, DHCP 정보에는 `GATEWAY=192.168.0.1`이 남아 있었다.
 - `ip route get 112.218.113.4`도 실제로 `via 192.168.219.1 dev eth0`를 가리켰다.
 - 즉 외부 NAS 트래픽이 현재 운영망이 아닌 구 경로 쪽으로 빠지고 있었다.
 ### 3. 내부 NAS 기본 게이트웨이 장치 설정에도 구 흔적이 남아 있었다
 - `/etc/iproute2/config/default-gateway` 값은 `DEVICE="tun0"`였다.
 - 이는 현재 실제 외부 경로로 써야 할 `eth1`과 맞지 않았다.
 - 내부 NAS는 DSM 6.2.4였고, `synonet`은 없었지만 `/usr/syno/bin/synogetkeyvalue`, `/usr/syno/bin/synosetkeyvalue`는 존재했다.
 ### 4. Go 바이너리 실행성은 네 가지로 나뉘었다
 1. 23 서버 로컬 실행
 - 정상 실행
 - DSM 로그인 및 두 폴더 목록 조회 성공
 2. `/mnt/nas` CIFS 마운트 경로 직접 실행
 - 실패
 - `Permission denied`
 - 마운트 옵션이 `file_mode=0664`라 실행 비트가 보존되지 않았다.
 3. 내부 NAS 홈 디렉터리에서 동적 빌드 바이너리 실행
 - 실패
 - `GLIBC_2.32`, `GLIBC_2.34` 미충족
 4. 내부 NAS 홈 디렉터리에서 정적 빌드 바이너리 실행
 - 바이너리 자체는 실행됨
 - 최초 실패 원인은 라이브러리가 아니라 외부 NAS 라우팅 문제였다.
 ## 실제 조치
 ### 1. Go 프로브 준비
 - 23 서버 `admin` 범위에 Go `1.26.1`을 설치했다.
 - 외부 DSM 로그인 및 File Station 목록 조회만 수행하는 최소 Go 프로브를 작성했다.
 - 내부 NAS 실행 호환성을 위해 `CGO_ENABLED=0` 정적 빌드도 함께 만들었다.
 ### 2. 내부 NAS 라이브 라우팅 교정
 - 우선 테스트용으로 `112.218.113.4`에 대한 호스트 라우트를 `192.168.0.1 dev eth1`로 교정했다.
 - 이후 DNS까지 같이 맞추기 위해 기본 경로 자체를 `default via 192.168.0.1 dev eth1`로 교체했다.
 ### 3. 기본 게이트웨이 설정 파일 교정
 - 백업:
  - `/etc/iproute2/config/default-gateway.bak_20260313`
 - 교정:
  - `/etc/iproute2/config/default-gateway`
  - `DEVICE="eth1"`
 - 적용 후 현재 라우트도 `112.218.113.4 via 192.168.0.1 dev eth1 src 192.168.0.101`으로 확인했다.
 ## 검증 결과
 ### 1. 내부 NAS에서 외부 DSM HTTPS 직접 응답 확인
 - `curl -Iks --connect-timeout 5 https://sigongipc.synology.me:5001`
 - 결과: `HTTP/2 200`
 ### 2. 내부 NAS에서 정적 Go 프로브 실행 성공
 내부 NAS 실행 결과:
 - 로그인:
  - `{"probe":"login","duration_ms":981,"host":"sigongipc.synology.me","binary":"companyx_external_nas_sync_probe_go_static"}`
 - 루트 목록:
  - `{"path":"/6.Company X","duration_ms":30,"total":16,"entries_returned":16,"body_bytes":3401}`
 - 대표 사진 폴더 목록:
  - `{"path":"/6.Company X/7. 사진/220308_X코스_5기 발표 사진","duration_ms":38,"total":20,"entries_returned":20,"body_bytes":5559}`
 즉 `내부 NAS -> 외부 NAS DSM 로그인 -> File Station 목록 조회` 경로가 실제로 닫혔다.
 ## 결론
 - 이번 이슈의 직접 원인은 내부 NAS가 외부 트래픽을 아직 `192.168.219.1 dev eth0` 구 경로로 보내고 있던 점이었다.
 - 기본 게이트웨이 장치를 `eth1`로 교정하고 라이브 라우트도 맞춘 뒤, 내부 NAS에서 외부 DSM 응답과 정적 Go 프로브 실행까지 확인했다.
 - 따라서 `23 서버를 거치지 않고 내부 NAS가 직접 Go 기반 동기화 주체가 되는 구조`는 네트워크 경로 기준으로는 현재 운영 후보로 볼 수 있다.
 ## 전후 관계 문서
 - 이전 해석: [260313_external_nas_sync_go_python_dsm_tooling_리서치.md](../research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md)
 - 다음 아이디어: [260313_internal_nas_direct_go_sync_아이디어.md](../ideas/260313_internal_nas_direct_go_sync_아이디어.md)