내 연구 프로젝트 코드에 추상화를 더할수록 성능이 예상보다 많이 떨어지는 문제가 있어서, 주요 변화사항이 있었던 커밋들을 모아 4가지 버전의 tag를 만들어두고 각각의 성능 비교를 하려고 하였다. 처음에는 그냥 이미 clone된 로컬 저장소에서 git checkout으로 tag를 변경해가며 성능 측정(perf record) 후 나중에 trace data만 모아서 보려고 했다. 근데 생각해보니 실행파일이 다른 버전으로 바뀌어버리면 perf로 기록한 trace data가 참조하는 symbol과 소스코드가 죄다 바뀌어버리는 문제가 생기는 거였다.

그래서 나는 실행파일들을 버전마다 백업해두고 trace data를 보여주는 perf report 명령에서 어떻게 하면 올바른 실행파일을 참조할 수 있게 할까 고민하던 중, 지나가는 말로 연구실 후배 녀석한테 혹시 그런 방법이 있나 물어보니 돌아오는 대답 왈 '그냥 각 버전별로 새로 clone 뜨는 게 symbol이나 소스코드 참조 꼬이는 것도 막고 깔끔하지 않을까요?' 였다. 다시 생각해보니 그거 clone 몇번 더 한다고 하드디스크 용량이 모자라는 것도 아니고, 한 저장소만 사용했을 때 실행파일을 백업해서 symbol을 어찌저찌 참조할 수 있게 한다손 치더라도 perf annotate 기능을 사용할 때 볼 소스코드까지 맞추기는 어려우니 당연히 그렇게 하면 아주 쉽게 해결되는 문제였다.

매우 간단한 일상의 대화였지만, 문득 '내가 이만큼 생각이 벌써 굳었구나' 하는 생각도 들었다. 왠지 한 컴퓨터에는 각 프로젝트별로 하나의 working directory만 깔끔하게 있고 그거 하나만으로 뭔가 다 해야 할 것만 같은 강박관념이랄까? 사실 이미 음악관리를 아이튠즈에게 맡긴 이후로 더 이상 mp3 파일들이 하드디스크 어디 있는지¹, 사본이 여러 개 있든지 말든지 신경도 안 쓰기 시작했는데 소스코드도 마찬가지인 거다. mercurial이나 git 같은 분산형 저장소들은 원래 처음 나왔을 당시부터 이런 방식을 더 자연스러운 패턴으로 튜토리얼에서 소개하기도 했었다. 언제나 열린 마음으로 새로운 도구와 그에 맞는 새로운 방법들을 받아들일 자세가 필요하고, 그걸 의식적으로도 노력하는 게 필요하겠구나 싶다.