기록 메모. 이 글은 프로젝트가 커질수록 메모·코드·실험 결과가 서로 다른 시간축으로 흩어진다는 문제에서 출발했다. 각 도구를 만능 도구로 쓰기보다 지식, 변경, 검토, 구현의 책임을 나눴다.
프로젝트가 커질수록 파일은 늘어나는데, 왜 다음에 해야 할 일은 더 찾기 어려워질까? 처음에는 폴더를 잘 나누고 메모를 남기면 충분할 것이라 생각했다. 하지만 논문에서 생긴 질문, 시뮬레이션에서 발견한 문제, 학습 결과를 보고 바꾼 판단은 서로 다른 속도로 쌓였다. 이 글은 그래서 단순한 저장 공간이 아니라 연구의 흐름을 담는 워크스페이스를 만들게 된 이유를 기록한다.
문제는 자료의 양보다 연결의 부재였다
논문 노트와 코드, 실험 결과를 한곳에 모으는 방법은 단순해 보인다. 그러나 무엇이 어떤 변경으로 이어졌는지를 표시하지 않으면, 한곳에 모인 자료도 결국 찾기 어려운 더미가 된다. 나는 모든 것을 같은 형식으로 정리하는 방식을 버리고, 자료의 역할에 따라 층을 나누기로 했다. 중요한 것은 정리의 모양이 아니라, 한 질문이 다음 행동으로 이어지는 경로였다.
지식과 구현을 분리한 이유
논문과 개념은 읽고 연결하면서 천천히 바뀌는 지식에 가깝다. 반면 시뮬레이션 환경과 학습 코드는 실행과 수정이 반복되는 구현 자산이다. 둘을 같은 방식으로 다루면, 한쪽을 고칠 때 다른 쪽의 맥락까지 흐려질 수 있었다. 그래서 연구 노트는 지식층으로, 시뮬레이션과 학습 코드는 구현층으로 나누고, 둘 사이를 기록과 링크로 연결했다.
데이터와 모델을 코드와 같은 방식으로 다루지 않았다
학습 데이터와 모델 가중치는 코드보다 크고, 같은 파일을 여러 번 복사하면 무엇이 기준인지 금방 헷갈린다. 모든 파일을 버전 관리 도구에 넣는 선택지도 있었지만, 변경의 이유를 읽어야 하는 저장소가 큰 산출물에 묻힐 수 있다고 봤다. 그래서 코드와 설정, 문서는 변경 이력을 남기고, 데이터와 모델은 생성 조건과 위치를 설명하는 메타데이터를 남기는 방식으로 나눴다. 이 구분 덕분에 파일을 많이 보관하는 것보다 어떤 결과가 어디에서 나왔는지를 따라가는 데 집중할 수 있었다.
작업 공간은 완성된 설계도가 아니었다
처음부터 지금의 구조를 정확히 알고 만든 것은 아니다. 실제로 작업하다 보면 어떤 폴더가 자주 섞이는지, 어떤 기록을 찾기 어려운지가 드러났고 그때마다 구조를 고쳤다. 완벽한 분류를 기다리는 대신, 현재의 작업 흐름을 방해하는 마찰을 기준으로 바꾸는 쪽을 택했다. 그래서 이 워크스페이스의 구조도 정답이라기보다 지금까지의 판단이 남긴 임시 지도다.
정리의 목적은 다음 판단을 빨리 하는 데 있다
워크스페이스를 만든 목적은 폴더를 보기 좋게 정렬하는 데 있지 않다. 논문을 읽다가 생긴 질문이 시뮬레이션과 학습의 어떤 선택으로 이어져야 하는지, 실험 결과가 다시 어느 노트를 고쳐야 하는지 알기 위해서다. 오늘의 결론은 간단하다. 좋은 작업 공간은 자료를 많이 담는 곳이 아니라, 다음 판단의 출발점을 잃지 않게 하는 곳이다.
다음에는 이 구조가 실제 작업을 거치며 왜 바뀌었는지, 현재의 구성도와 함께 정리하려 한다.