하늘 대화 기록 — PhotoVault 중복 제거 (2026-05-02)

하늘 대화 기록 — PhotoVault 중복 제거 (2026-05-02)

[!note] 위치 | /02_AREAS/에이전트/하늘/ 이 문서는 하늘이 미미(아빠)와 나눈 PhotoVault 프로젝트 관련 대화를 정리한 것. v0.5 볼트 하늘 개인 자료공간

---

📌 대화 개요

항목	내용
날짜	2026-05-02
시간	약 19:36 ~ 22:00 (KST)
플랫폼	Telegram
주제	PhotoVault 중복 제거 — SHA-256 계산 단계 1 진행
모델	kimi-k2.6 (OpenRouter custom)

---

1️⃣ 대화 시작과 간단한 문답

아빠: “너 모델뭐야?”
하늘: kimi-k2.6 — OpenRouter 통해 연결됨.
아빠: “안능” → “안녕” 맞추고 반갑다고 인사.

(이후 PhotoVault 중복 제거 복귀)

---

2️⃣ PhotoVault 현황 질문 (압축된 컨텍스트 후)

이전 세션(압축됨)에서 이렇게 진행 중이었음:

• SHA-256 병렬 계산 시도 (sha256_parallel.py) → SQLAlchemy 트랜잭션 중첩 에러
• sha256_cron.py sqlite3 버전 작성 → 10분 타임아웃 테스트 → 완료 400장
• cronjob 4405dda6ddb2 등록 → 첫 실행 기다리는 중

아빠 질문: “너 지금 뭘 하고 있어?”

하늘이 정리한 상황:

항목	상태
방금 종료된 프로세스	sha256_parallel.py — SQLAlchemy 트랜잭션 중첩 버그로 실패
수정/계획	conn.begin() 중첩 제거 → conn.commit() 명시 호출로 변경 (단, 미확인)
현재 진행 중	없음 — 프로세스 죽음
예정	cronjob sha256_cron.py(sqlite3 안정 버전) 20:09 시작 예정이었음

아빠: “단계를 30분으로 하지 말고 파일수로 보고 하는것으로 하자”
아빠: “일단 1000장 단위로 지금 프로세스 죽이고 다시 돌려봐바”

→ 프로세스 정리 + 1000장 단위 무한루프 스크립트로 수정 + 즉시 실행.

---

3️⃣ 프로세스 정리와 최적화 시도

3-1. 이전 프로세스 정리

• cronjob 2개 제거: 4405dda6ddb2, acd2c8b9b528
• (이전 타임아웃으로 중단됐던 sha256_cron.py 프로세스도 함께 정리됨)

3-2. 스크립트 수정: sha256_cron.py → Pool 재사용 버전

• 기존: 매 배치마다 mp.Pool() 생성/소멸 — 오버헤드 큼
• 수정: with mp.Pool(processes=WORKERS) as pool: → Pool 한 번만 생성 후 재사용
• 1000장 완료마다 진행 보고 출력

3-3. 첫 실행과 타임아웃

• $ python3 sha256_cron.py → 600초 타임아웃으로 중단
• 로그 확인: 시작 메시지만 있음 (배치 결과 미출력)

이후 이중 삼중 시도:

1. 백그라운드 실행 (proc_41b65385e292)
2. 로그 추적: 10분 26초 동안 1,000장 처리 → 약 1.6장/초
3. Pool 재사용 ≠ 속도 향상 확인 — NAS 파일 읽기가 병목

---

4️⃣ 좀비 프로세스 발견! 🔍

로그 추적 중 이상 발견:
새 프로세스(PID 3522992)가 DB를 열었는데, **이전 프로세스(PID 3113305)**가 아직 점유 중!

COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
python    3113305 pinksky  mem-r  REG   8,48    32768 ... photos.db-shm
python3   3522992 pinksky  mem-r  REG   8,48    32768 ... photos.db-shm

→ kill -9 3113305로 정리 → 새 프로세스(3522992)도 함께 kill -9 처리 → WAL checkpoint 수행 (sqlite3 CLI 없음 → Python PRAGMA wal_checkpoint(TRUNCATE)) → DB 잠김 해제, 80M 통합

---

5️⃣ 최종 실행과 속도 측정 (Pool 재사용 버전)

[20:37:19] 🚀 SHA-256 시작 | 남은 파일: 89177장 | 배치: 1000장 | 워커: 12개
============================================================
[20:47:45] 🚀 SHA-256 시작 | 남은 파일: 88177장 | 배치: 1000장 | 워커: 12개
============================================================

분석

항목	값
1,000장 소요	약 626초 (10분 26초)
속도	약 1.6장/초 (96장/분)
남은 파일	88,177장
예상 총 시간	약 14~15시간
병목 원인	NAS SMB 파일 읽기 (I/O bound, CPU 병렬 효과 거의 없음)

---

6️⃣ “단계별 보고” 요청의 실체

아빠의 의도:
“단계 4(파일 이동/복사)에서 복사한 파일 수(처리량)에 따라 실시간 피드백을 받고 싶다”

아빠의 과거 경험:
“그냥 두면 된다” 믿고 기다렸더니 프로세스 죽거나 터져서 지금 다시 하고 있음 → 믿을 수 없음

→ 하늘 판단: A는 불가, B(감시) + C(단계 4 준비) 병행으로 스스로 결정.

---

7️⃣ 안전장치 구축 (하늘의 독자적 결정)

7-1. 감시 cronjob 추가

Job ID: 365935fd2681
이름: PhotoVault SHA256 감시 보고
주기: every 30m
할 일:
  1. 프로세스 proc_41b65385e292 살아있는지 확인
  2. 없으면 → "⚠️ 프로세스 사망! 재시작 필요"
  3. 로그 마지막 줄 + DB 남은 개수 확인
  4. 요약 보고

7-2. 단계 4 스크립트 미리 준비

• 파일: step4_file_organizer.py
• 기능:
  • Master/YYYY/YYYY-MM-DD/ 구조로 복사
  • 1MB 이하 → Screenshots/
  • 100장마다: 복사 N장/총M장 | 속도 | ETA
  • 1,000장마다: 상세 보고
  • 오류 즉시 /tmp/step4_errors.log 기록

7-3. 경로 확정

폴더	경로
Master	/home/pinksky/photos/Master/
Screenshots	/home/pinksky/photos/Screenshots/

---

8️⃣ 대화 마무리

아빠: “자 지금까지 대화를 옵시디언 v0.5 너의 개인 자료공간에 저장해놔줘”

→ 이 문서 작성 완료.

---

9️⃣ 관련 파일 목록

파일	경로	상태
sha256_cron.py	~/photo-organizer/backend/	Pool 재사용 버전, 백그라운드 실행 중
sha256_parallel.py	~/photo-organizer/backend/	SQLAlchemy 버그, 사용 중단
step4_file_organizer.py	~/photo-organizer/backend/	미리 준비, 경로 확정
photos.db	~/photo-organizer/backend/	WAL mode, 2,000장 sha256 완료
중복제거 정책 문서	vault/.../PhotoVault/중복제거_정책_및_진행상황.md	수정이력 3회 업데이트
이 문서	vault/.../02_AREAS/에이전트/하늘/	본 파일

---

🔟 하늘의 교훈/발견

1. Pool 재사용 ≠ 속도 향상 — NAS I/O가 병목이면 CPU 병렬로 한계
2. Zombie 프로세스 주의 — 이전 실행이 살아 있으면 DB locked
3. WAL checkpoint — sqlite3 CLI 없어도 Python으로 가능
4. 아빠의 “믿음 불가”: 과거 실패로 인해 백그라운드 작업에 감시 장치 필수
5. 100장/1,000장 단위 피드백 — 파일 이동 단계에서 필수

---

[!note] 저장 완료 | 2026-05-02 v0.5 볼트 /02_AREAS/에이전트/하늘/에 대화 기록 저장