루트만 봐서는 어느 게 현행인지 알 수 없었습니다
저장소 루트를 열면 build.sh, build2.sh, build3.sh가 나란히 있었습니다. 세 개 중 지금 돌아가는 게 무엇인지, 파일 이름만으로는 알 수 없었습니다. 그 옆에 narration.txt와 narration.srt가 있고, subs/ 아래에는 s1.txt부터 s5.txt, 그리고 footer.txt가 있었습니다. preview 산출물과 assets, 렌더된 mp4도 같은 층에 있었습니다.
같은 루트에 현행 파이프라인도 있었습니다. engine/, docs/, apps.json, hook/, channel/. 살아 있는 것과 죽은 것이 한 화면에 섞여 있는 상태였습니다.
이건 흔히 "나중에 정리하면 되는 일"로 분류됩니다. 동작에 지장이 없으니까요. 실제로 지장은 없었습니다. 빌드는 돌았고 배포도 됐습니다.
그런데 당신 저장소 루트에 있는 파일 중, 지금 파이프라인이 실제로 읽는 건 몇 개입니까?
루트의 쓰레기는 오히려 안전한 쪽이었습니다
build2.sh가 위험하지 않은 이유는 단순합니다. 이름 자체가 이미 의심스럽기 때문입니다. 누구도 build3.sh를 보고 "이게 표준 진입점이겠지"라고 생각하지 않습니다. 눈에 보이는 잡동사니는 사람이 알아서 피해 갑니다.
실제로 걸린 건 다른 곳이었습니다. v1 실험의 테스트 JSON 한 개가 engine/ 안에 있었습니다. 현행 파이프라인 디렉터리 안입니다. 언더스코어로 시작하는 테스트 픽스처 이름이라, 그 디렉터리를 처음 보는 입장에서는 현행 엔진의 테스트 데이터로 읽힙니다. 루트의 세 개짜리 빌드 스크립트는 경고음을 내지만, 올바른 디렉터리 안에 들어앉은 죽은 파일은 아무 소리도 내지 않습니다.
정리의 대상이 "루트가 지저분하다"에서 "현행 디렉터리의 신뢰도가 깨져 있다"로 바뀌는 순간이었습니다.
값싼 수정이 없었던 지점
파일을 옮기는 건 1분입니다. 어떤 파일이 죽었는지 판정하는 게 일입니다.
subs/s3.txt가 죽었다는 걸 확인하려면, 현행 파이프라인의 어느 코드도 그 경로를 읽지 않는다는 걸 확인해야 합니다. 여섯 개 자막 조각, 두 개 내레이션 파일, 세 개 빌드 스크립트, 그리고 preview·assets·mp4까지 각각에 대해 같은 질문을 반복해야 합니다. 이건 자동화되지 않습니다. grep으로 참조를 찾을 수는 있지만, 참조가 없다는 사실이 곧 죽었다는 증거는 아닙니다. 손으로 부르던 스크립트는 코드 어디에도 참조가 없습니다.
당신이라면 지우시겠습니까, 옮기시겠습니까?
옮기되, 히스토리는 붙여서
git mv로 legacy/ 아래에 넣었습니다. rm 대신 mv를 쓴 이유는 되돌리는 비용 때문입니다. 판정이 틀렸을 때, 삭제는 복구 작업이 되고 이동은 경로 한 줄 되돌리기가 됩니다. 루트에서 옮긴 것들은 legacy/build.sh, legacy/narration.srt 식으로, subs/는 legacy/subs/ 통째로, engine/에 있던 v1 테스트 JSON은 legacy/로 갔습니다.
현행 파이프라인은 손대지 않았습니다. engine/, docs/, apps.json, hook/, channel/은 루트에 그대로 뒀습니다. 정리의 목적이 "보기 좋게"가 아니라 "루트에 남은 것 = 현행"이라는 규칙 하나를 세우는 것이었기 때문입니다.
그리고 docs/JOURNAL.md에 한 줄 남겼습니다. 이 커밋의 코드 변경은 사실상 0줄이고, 추가된 건 그 한 줄뿐입니다. 3개월 뒤에 legacy/를 보고 "이게 왜 여기 있지"라고 물을 사람은 저 자신입니다.
자가진단 체크리스트
- 현행 파이프라인 디렉터리 안에, 현행이 아닌 파일이 들어 있지 않습니까? 루트의 잡동사니보다 이쪽이 먼저입니다.
- 같은 역할의 파일이 숫자 접미사로 여러 개 있습니까? (
build2,build3) 있다면, 어느 게 진짜인지 파일 이름 말고 무엇으로 판별합니까? - 아카이브를
rm이 아니라mv로 했습니까? 판정이 틀렸을 때 되돌리는 비용이 얼마인지 계산해 보셨습니까?
솔직한 부분
이건 문제를 푼 게 아니라 미룬 커밋입니다. legacy/가 언제 실제로 지워질지에 대한 계획은 없습니다. 그리고 옮긴 파일들이 정말 전부 죽었는지, 옮긴 뒤에 파이프라인을 끝까지 돌려 확인했다는 기록은 남기지 않았습니다. 판정의 상당 부분은 파일 이름과 기억에 의존했습니다.
커밋 메시지에는 preview·assets·mp4도 아카이브했다고 적었지만, diff 통계에 잡힌 건 13개 파일입니다. 나머지는 애초에 git이 추적하지 않던 산출물이었던 것으로 보입니다. "보인다"고 쓰는 이유는 그 시점에 확인하지 않았기 때문입니다. 추적되지 않는 파일은 이런 정리에서 조용히 빠지고, 다음에 루트를 열었을 때 다시 거기 있습니다.