---
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 실행 구조가 더 자연스럽다.`