기록 메모. 이 글은 결과 파일이 늘면서 무엇을 Git에 남기고 무엇을 별도로 관리할지 판단해야 했던 단계에서 남겼다. 모든 것을 한 곳에 넣는 편보다, 변경 이력과 대용량 산출물의 역할을 구분하는 쪽을 선택했다.
로봇을 학습시키며 나온 파일은 전부 같은 방식으로 보관해도 될까? 코드와 설정은 자주 바뀌고, 데이터와 학습된 모델은 크기가 커지며 생성되는 속도도 다르다. 처음에는 한 저장소에 모두 넣으면 가장 안전할 것처럼 보였지만, 시간이 지날수록 무엇이 기준이고 무엇이 결과물인지 오히려 찾기 어려워졌다. 이 글은 파일을 나누어 둔 이유보다, 결과의 출처를 잃지 않기 위해 세운 기준을 기록한다.
Git은 모든 것을 담는 상자가 아니었다
Git은 코드와 문서가 언제 어떻게 바뀌었는지 되돌아볼 수 있게 해 주는 버전 관리 도구다. 그래서 처음에는 데이터와 학습된 모델까지 모두 Git에 넣는 방법을 떠올렸다. 하지만 큰 파일이 쌓이면 변경의 이유를 읽어야 하는 기록이 묻히고, 저장소의 흐름도 무거워진다. 나는 Git을 모든 파일의 창고가 아니라, “무엇을 왜 바꿨는가”를 남기는 곳으로 정하기로 했다.
코드와 설정에는 판단의 흔적을 남긴다
코드와 환경 설정, 평가 방법, 연구 노트는 서로 다른 파일처럼 보여도 한 번의 판단에서 같이 바뀌는 경우가 많다. 예를 들어 어떤 조건을 바꾸었다면, 그 조건이 무엇을 확인하기 위한 것이었는지와 어떤 결과를 기대했는지를 함께 따라갈 수 있어야 한다. 그래서 변경을 남길 때 파일 목록만 적는 방식은 피하고, 바꾼 이유와 확인 범위를 연결하려 한다. 이 기록이 있으면 몇 주 뒤에도 같은 상태로 돌아가거나, 다른 결과와 비교할 출발점을 만들 수 있다.
큰 산출물은 따로 두되, 이름만 남기지는 않는다
학습 데이터와 모델 가중치는 코드를 실행한 뒤 만들어지는 대용량 산출물이다. 이들을 버전 관리에 무조건 넣는 대신, 별도 공간에 두고 어떤 조건에서 만들어졌는지를 설명하는 기록을 남기는 쪽을 택했다. 단순한 파일명만 남기면 시간이 지나 어느 실험의 결과인지 알 수 없기 때문이다. 그래서 생성 조건, 관련된 코드 변경, 확인한 결과를 서로 연결해 두어야 한다.
분리의 목적은 숨기는 것이 아니라 다시 찾는 데 있다
데이터와 모델을 별도로 관리한다고 해서 프로젝트에서 떨어져 있는 것은 아니다. 오히려 어떤 결과가 어떤 입력과 어떤 설정에서 나왔는지 찾아갈 실마리가 더 중요해진다. 나는 대용량 파일의 복사본을 늘리기보다, 관련된 판단과 위치를 기록해 계보를 남기기로 했다. 이 방법은 한 번의 결과를 보관하는 데서 끝나지 않고, 나중에 의심이 생겼을 때 다시 검토할 수 있게 한다.
실험은 파일 다섯 개가 아니라 하나의 질문이다
실험 하나에는 코드, 설정, 입력, 결과, 해석이 함께 있다. 이 중 하나라도 빠지면 같은 결과를 다시 만들거나, 결과가 왜 달랐는지 설명하기 어렵다. 그래서 나는 파일별로 정리하는 데서 멈추지 않고, 한 질문을 확인한 단위로 이 요소들을 연결하려 한다. 좋은 보관은 파일을 잃지 않는 것보다 판단의 맥락을 잃지 않는 데 가깝다.
보관 규칙은 연구의 다음 선택을 돕는다
처음에는 파일 관리가 연구와 별개의 잡일처럼 느껴졌다. 하지만 결과의 출처를 바로 찾을 수 있으면, 다음에 바꿀 대상을 추측으로 고르지 않아도 된다. 오늘의 결론은 간단하다. Git에는 변한 이유를 남기고, 큰 산출물에는 그 결과가 어디에서 왔는지 돌아갈 수 있는 표지를 남겨야 한다.
다음에는 이 표지들을 바탕으로, 실험 한 번을 나중에도 다시 검토할 수 있는 기록 단위로 만드는 방법을 적어 보려 한다.