---
tags: [infra, nas, companyx, sync, research]
---

# 260312 Company X 장시간 동기화 상태 미기록 종료 리서치

**상태**: 종료 (2026-03-12 상태 기록 강화 후 전체 재개 실행 완주 확인)

## 상위 원칙
- [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)

## 관련 문서
- [Company X 장시간 동기화 상태 미기록 종료 이슈](../troubleshooting/260312_companyx_sync_장시간동기화_상태미기록종료_이슈.md)
- [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획](../plans/260311_external_nas_companyx_sync_운영계획.md)

## 목적

- 장시간 전체 동기화가 상태 파일과 실패 로그 없이 종료된 원인을 사실 기준으로 좁히고, 다음 복구 계획에서 무엇을 먼저 고쳐야 하는지 정리한다.

## Facts

1. 대표 경로 기준 스크립트 동작 자체는 정상이다.
- 대표 폴더 20개 파일 동기화와 재실행 `skipped=20`이 확인됐다.

2. 전체 트리 장시간 실행에서는 실제 데이터 누적이 있었다.
- 내부 경로 `/mnt/nas/workspace/6.Company X`가 `283G` 수준까지 증가했다.
- 즉 전체 실행이 시작 직후 실패한 것은 아니다.

3. 2026-03-12 보강 후에는 실행 메타데이터가 남는다.
- `/mnt/nas/workspace/.sync-logs/companyx_sync_state.json`
- `/mnt/nas/workspace/.sync-logs/companyx_tmp_inventory_20260312.jsonl`
- 대표 경로에서는 `companyx_sync_summary_20260312_121529.json`도 생성됐다.

4. 임시 파일은 남아 있다.
- 최신 흔적 예시는 `tmp3fe5jpym` `393,216,000B`, `tmpjrz40eiq` `0B`다.
- 임시 파일이 남았다는 것은 최소 일부 다운로드가 `os.replace` 이전에 끊겼다는 뜻이다.

5. 직접 실패 원인 로그는 없다.
- 현재 기준 `companyx_external_nas_sync.py` 프로세스는 없고, 상태 파일/실패 로그도 없어 내부 예외와 외부 종료를 구분할 직접 근거가 없다.

6. 코드 구조를 2026-03-12에 보강했다.
- 상태 파일은 시작 시, 다운로드 성공 시, 스캔 진행 중 주기적으로 기록된다.
- 임시 파일 목록은 실행 시작 전에 별도 JSONL로 남긴다.
- 요약 파일은 대표 경로 검증에서 실제 생성됐다.
- `SIGINT`, `SIGTERM`, `SIGHUP`에서도 상태와 요약을 남기도록 신호 처리를 추가했다.

7. 현재까지 가장 유력한 원인 후보는 `외부 중단 또는 세션 기반 종료`다.
- 직접 실패 로그가 없고, 상태 파일도 전혀 없으며, 장시간 데이터 누적 후 프로세스만 사라졌다.
- 이 패턴은 `초기 즉시 실패`보다 `장시간 실행 중 외부 종료` 쪽과 더 잘 맞는다.
- 다만 이것도 확정이 아니라 상대적으로 유력한 해석이다.

## Interpretation

1. 지금 닫힌 질문
- 아이디어 자체가 가능한가: 예
- 스크립트 기본 동작이 가능한가: 예
- 전체 트리 동기화가 장시간 실제 다운로드를 수행했는가: 예

2. 지금 안 닫힌 질문
- 왜 종료됐는가
- 다음 실행이 어디서부터 재개돼야 하는가
- 임시 파일을 어떻게 처리해야 운영적으로 안전한가

3. 가장 큰 구조 결함
- 스크립트가 `finished_at`과 상태 파일을 마지막에만 쓰는 구조라, 장시간 실행 중단 시 실행 흔적이 거의 남지 않는다.
- 즉 현재 문제의 핵심은 `동기화 알고리즘`보다 `중간 상태 기록 부재`다.

4. 지금 우선순위는 종료 원인 확정보다 재개 가능성 확보다.
- 종료 원인을 100% 확정하지 못해도, 상태 파일을 중간에 남기게 바꾸면 같은 종류의 불확실성을 크게 줄일 수 있다.
- 따라서 다음 단계는 포렌식보다 `상태 기록 강화 + 재개 실행 검증`이 맞다.

## Unresolved

1. 종료 원인 확정
- 외부 중단, 세션 중단, 네트워크 실패, 원격 응답 문제 중 무엇인지 미확정

2. 임시 파일 처리 기준
- 그대로 재시도할지, 먼저 분리 보관할지, 삭제 후보로 볼지 미확정

3. 상태 기록 주기
- 파일 단위, 디렉터리 단위, 주기적 flush 중 무엇이 적절한지 미확정

4. 실행 요약 파일 형식
- 콘솔 출력 외에 별도 `summary json` 파일을 남길지 아직 미확정

## 현재 결론

- 이 문제는 기존 아이디어의 반박 근거가 아니라, 실행 안정성 보강이 필요한 별도 주제였고 2026-03-12 기준 핵심 결함인 `상태 미기록`은 해결됐다.
- 전체 재개 실행은 `downloaded=18481`, `skipped=34352`, `failed=0`, `files_seen=52833`, `finished_at=2026-03-12T13:59:01+09:00`로 종료돼 이 리서치 주제는 닫혔다.
- 현재 남은 것은 별도 troubleshooting/research가 아니라, 원래 Company X 동기화 아이디어와 운영계획의 종료 상태를 문서상 완료로 정리하는 일뿐이다.