기록 메모. 이 글은 처음 만든 폴더 구조가 실제 작업을 거치며 바뀐 이유를 남긴 기록이다. 처음부터 완벽한 구조를 설계하기보다, 반복해서 막히는 지점을 기준으로 구조를 바꾸는 편을 택했다.
처음 만든 작업 공간은 왜 시간이 지나면 꼭 다시 손봐야 할까? 나는 처음에 연구 노트, 시뮬레이션, 학습 코드를 나누면 정리가 끝날 것이라 생각했다. 하지만 실제로 작업을 시작하니 폴더 이름보다 “지금 이 질문은 어디에 남겨야 하는가”가 더 자주 문제를 만들었다. 이 글은 현재 구조를 자랑하기보다, 구조가 바뀌어야 했던 순간들을 기록한다.
처음에는 분류를 먼저 만들었다
프로젝트 초반에는 자료가 섞이지 않게 하는 일이 가장 중요해 보였다. 그래서 논문과 개념은 연구 노트에, 시뮬레이션 환경은 별도 공간에, 학습 코드는 또 다른 공간에 두었다. 한곳에 전부 넣는 방식은 시작은 빠르지만, 나중에 무엇이 지식이고 무엇이 실행 자산인지 구분하기 어렵다고 판단했다. 이 첫 분리는 필요한 출발점이었지만, 작업의 흐름까지 설명해 주지는 못했다.
문제는 폴더 사이에서 생겼다
논문을 읽다가 생긴 질문이 시뮬레이션 설정으로 이어지고, 짧은 실행에서 얻은 관찰이 다시 기록의 수정으로 이어지는 순간이 많았다. 그런데 각 폴더가 잘 나뉘어 있어도, 그 사이를 건너간 이유가 남지 않으면 다음에 같은 판단을 재현하기 어려웠다. 나는 폴더를 더 잘게 쪼개는 대신, 변경이 생길 때 연결되는 기록을 남기는 쪽을 선택했다. 구조를 바꾼 이유가 폴더 안이 아니라 폴더와 폴더 사이에 있었기 때문이다.
결과 파일이 늘면서 기준을 다시 세웠다
학습과 평가를 반복하면 코드보다 큰 결과 파일과 모델이 빠르게 쌓인다. 이 산출물을 모두 코드와 함께 다루면 변경 이력을 읽기 어려워지고, 반대로 아무 설명 없이 따로 두면 어느 결과가 어떤 작업에서 나왔는지 잃게 된다. 그래서 코드·설정·문서는 변경의 흐름을 남기고, 데이터와 모델은 조건과 위치를 설명하는 기록을 남기는 방식으로 나눴다. 이 선택은 파일을 줄이기 위한 것이 아니라, 나중에 결과의 출처를 확인할 수 있게 하려는 것이었다.
이론 지도는 나중에 붙인 표지가 아니었다
구현이 늘면서 “왜 이 요소가 필요한가”를 코드만 보고 다시 이해하는 시간이 길어졌다. 긴 설명서를 매번 새로 쓰는 방법도 있었지만, 구현과 분리된 문서는 곧 낡을 가능성이 컸다. 그래서 논문, 실험, 환경 구성의 관계를 한 장의 이론 지도로 계속 갱신하기로 했다. 이것은 정답을 모아 둔 문서가 아니라, 다음 변경이 어디에 영향을 주는지 찾아가는 기준점이 되었다.
바뀌지 않는 것은 구조가 아니라 원칙이었다
현재의 폴더 구성도 앞으로 다시 바뀔 수 있다. 다만 어떤 변경도 질문에서 시작해 실행으로 가고, 결과가 다시 기록으로 돌아오는 흐름을 끊지 않아야 한다는 기준은 남겼다. 오늘의 결론은 간단하다. 작업 공간은 처음 완성하는 설계도가 아니라, 실제 작업이 남긴 문제를 해결하며 고쳐 가는 도구다.
다음에는 지금의 구조를 폴더 목록이 아니라 하나의 질문이 이동하는 흐름으로 설명해 보려 한다.