디지털 서재

입력 2025.10.22. 20:32 · 수정 2025.12.01. 11:01 · 라이선스
라이선스

여기 파일 탐색기가 로드됩니다. 탐색기가 오래도록 보이지 않는다면 페이지를 새로고침해보세요.

어릴 때 TV를 보다 보면 종종 자료화면으로 교수가 인터뷰하는 모습을 볼 수 있었다. 뉴스에서 "날이 추워지니 따뜻한 물을 많이 마셔 호흡기 질환을 예방하세요."라든가, 스펀지에서 "네 사실입니다. 소설 <죠스>는 우리나라에 처음 소개될 때 <아가리>라는 이름으로 들어왔습니다."처럼 이 대답을 꼭 교수한테까지 가서 들어야만 했을까 싶은 경우가 많았지만, 제작진은 답변뿐만 아니라 교수라는 자리가 뒷받침하는 그 답변에 대한 신빙성까지 인터뷰를 통해서 보여주고 싶었던 것이리라. 교수들의 배경에 있던 책이 가득찬 서재는 그 신빙성을 한층 높여주었다. 그 서재를 보면서 나는 '나도 어른이 되면 저런 서재를 가지게 될까?' 하는 생각을 어렴풋이 했던 것 같다.

그로부터 약 20년 후. 나는 어른은 됐지만 여전히 그런 서재는 가지고 있지 않다. 책 몇 권과 직접 인쇄한 몇 개의 종이 뭉치가 연구실 내 자리에 있는 자료의 전부다. 이렇게 단촐한 사무 공간의 구성은 연구자로서의 내 경력이 짧아서만은 아니다. 우리 학교에서만 15년을 보내신 나의 지도교수님께서도 과거 방송에서 보던 교수들의 서재에 비하면 비교적 적은 수의 책을 책장에 두고 계신다.

사무 공간의 간소화에 더 큰 역할을 한 것은 오히려 자료의 디지털화인 것 같다. 현대의 우리는 태반의 자료를 컴퓨터로 다룬다. 지금 쓰는 이 글도 그렇듯 나는 디스플레이와 키보드로 읽고 쓰는 일이 종이와 펜으로 그러는 일보다 월등히 많다. 여러분도 높은 확률로 그럴 것이다.

드라이브에 쌓여가는 자료의 양이 점차 많아지면서, 이들을 지속 가능하게 관리하기 위한 체계가 꼭 필요했다. 이 체계는 내 개인 컴퓨터가 생긴 고등학교 즈음부터 시작해 계속 발전되어왔고 이제 상당히 안정적인 상태에 수렴해있다.

현대에 지식 노동을 주 업으로 삼고 있는 사람이라면 거의 모두가 이런 나름의 체계를 가지고 있을거라 생각한다. 그러나 그런 나와 타인의 체계를 서로 들여다볼 기회는 많지 않다. 과거의 서재는 그 물리적인 존재가 거추장스럽긴 했지만 한편으로는 내 지난 노력을 보여주는 증거(교수님들 배경에 있던 책들), 또 남의 노력으로부터 우연히 배우는 기회(어 이건 무슨 책이야?)가 되기도 했다. 서재의 디지털화는 우리로부터 이런 낭만을 많이 앗아갔다.

그래서 나는 차라리 내 디지털 서재를 능동적으로 소개하는 글을 쓰기로 했다. 이 글 상단에 있는 파일탐색기는 실제 내 아카이브 구조를 여러분이 직접 탐색해볼 수 있도록 구현한 것이고, 이어지는 내용은 그중 언급할만한 요소들을 설명한 것이다. 글 중 등장하는 이런 표현은 그 아카이브 속의 구체적인 디렉토리/파일의 이름 혹은 경로를 뜻한다. ~는 내 홈 디렉토리(Macintosh HD/Users/gunheeyi)를 나타내는 축약어이다.

디렉토리

아카이브를 이루는 디렉토리(폴더) 중 주요한 것들.

~/iCloud Drive

자료들은 몇 가지의 예외를 제외하고는 모두 iCloud에 저장된다. 나는 현재 네 대의 컴퓨터를 두고 위치/용도별로 바꾸어가면서 쓰는데, 이들과 태블릿, 휴대폰을 포함 모든 기기에서 연속적으로 작업하기 위해서는 클라우드의 사용이 필수적이다. 이전에 Windows PC + Galaxy 폰 조합을 쓰던 시절에는 Google Drive를 잘 사용했지만 애플 생태계로 넘어오면서 자료와 사진까지를 전부 iCloud로 옮겼다. 데스크톱/모바일 환경을 가리지 않고 모두 운영체제에 빌트인되어 별도의 설치 과정 없이도 잘 작동한다는 점이 가장 마음에 든다.

앞서 언급한 클라우드 동기화의 예외로는 먼저 웹으로부터 다운로드하는 파일들이 있다. ~/Downloads에 저장되는 이 파일들은 내용 확인 후에 장기 보관할 필요가 있을 경우 iCloud 아래 디렉토리로 옮겨지고, 그렇지 않을 경우 즉각적으로 혹은 주기적인 다운로드 폴더 정리 시 삭제된다.

또 하나의 예외는 이후 설명할 dev 디렉토리의 자료들이다.

~/iCloud Drive/yearly

yearly는 iCloud에서 가장 큰 비중을 차지하는 디렉토리이다. 시간순으로 정리 가능한 거의 모든 자료가 여기 있다. 이름에서 알 수 있듯 바로 아래 구조로 2025와 같은 연도가 이어진다. 자료의 분야별 구분은 각 연도 디렉토리 아래에서 이루어진다. 예를 들어 2024 아래에는 선보엔젤파트너스(진학 전 다니던 회사), kaist(연구 및 코스웍), founders(연초 활동한 창업학회), freelancing(개발용역), misc(miscellaneous = 기타 잡다한 자료) 등의 하위 구조가 이어진다. 연도가 아닌 분야를 가장 큰 분류로 두는 design choice도 물론 가능했겠다. 하지만 언제-무엇을 한다는 순서로 생각하는 것이 내게는 더 자연스러웠고, 어떤 해에 내가 하고 있는/있던 일을 한눈에 볼 수 있다는 점이 좋아 나는 연도별로 분류하는 편을 택했다.

한 분야의 자료지만 기간의 중간에 해가 바뀌는 경우가 있다. 이 경우 다음 해에 이어지는 기간이 길지 않다면 그냥 주 연도인 첫 해에 모든 자료를 넣어버린다. 3월부터 다음해 2월까지의 학년도(academic year), 첫 해 여름에 시작해 이듬해 1월에 마무리한 개발용역 등이 이에 포함된다. 여러 해에 유의미하게 걸친 자료의 경우 불가피하게 여러 연도 아래 같은 이름의 디렉토리를 둔다.

~/iCloud Drive/yearly/future

yearly 아래 future 디렉토리를 만든 것은 가장 최근의 변화 중 하나다. 시간상 미래에 일어날 예정이지만 그 시기가 아직 불분명한(분명한 것은 future가 아닌 구체적인 연도 아래 바로 담긴다) 일들에 관한 자료가 여기 위치한다. 구체적인 예로는 결혼, 육아, 박사후연구원, 취업, 가보지 않은 여행 등이 있다. 아직 일어나지 않은 일이니 과거 기록 대신 위시리스트나 그때 가서 유용할 꿀팁, 지원 제도 등이 주를 이룬다.

future가 생긴 이상 yearly를 chronological로 바꾸는 게 더 정확한 표현이려나?

~/iCloud Drive/resources

남겨두어야 하지만 시간에 구애받지는 않는 자료들은 resources에 담긴다. 책, 좋아하는 예술 작품, 악보, 연락처, 소프트웨어, 운영체제 및 프로그램 환경 설정, 배경화면 이미지, 폰트, 문서 템플릿 등이 모두 여기에 속한다.

~/iCloud Drive/tunnel

tunnel은 기기 간 자료 이동에 사용된다. 클라우드의 다른 디렉토리들은 자료를 "구름" 위에 올려두고 언제든지 내려받아 쓸 수 있게 한다면, tunnel은 말그대로 지상에 존재하는 기기들 사이에 자료를 빠르게 공유할 수 있는 터널 역할을 하는 것이다. 그래서 자료는 이동하는 잠시 동안만 여기에 있다가 존속할 다른 위치로 곧 옮겨진다. 이 디렉토리도 내가 소유한 기기 개수가 급격히 늘어난 최근에야 비로소 만들어졌다. 간결하면서도 뜻을 완벽히 전달하는 tunnel이라는 이름을 짓고 혼자 좀 뿌듯해했다.

~/dev

dev는 내 연구, 코스웍, 사이드프로젝트, 개발용역, 본 사이트 등을 위한 코드베이스를 모두 담고 있는 디렉토리다. dev가 iCloud Drive 밖에 있는 것은, 이러한 소스코드들은 보통 iCloud와 같은 범용 클라우드 서비스가 아닌 "버전 관리 시스템"이라는 다른 소프트웨어(Version Control System, VCS)로 관리되기 때문이다.

당신이 코드를 작성하는 개발자라고 상상해보자. 만일 당신이 새로 작성한 코드가 어딘가 오작동을 일으켰다면 멀쩡히 돌아가던 마지막 버전으로 롤백할 수 있는 기능이 아주 유용할 것이다. 또 각 버전에 추가/변경된 내용을 단어별로 들여다보거나, 여러 명의 병렬 작업으로 분기된 결과물을 검토 후 자동으로 합칠 수 있다면 더욱 좋을 것이다. 일반 클라우드 서비스에서는 불가능한 이러한 기능들을 담은 소프트웨어가 바로 VCS다. 코드베이스의 백업 및 동기화도 VCS로 가능하다.

게다가 코드베이스는 일반적인 클라우드로 동기화해서는 안 될 특성도 가지고 있다. 코드베이스에 속한 라이브러리(= 누군가가 이미 작성해놓아서 그대로 가져다 쓰기만 하면 되는 코드 "밀키트") 중에는 그 안에 몇 백, 몇 천 개의 개별 파일을 담고 있는 것들이 있어서, 라이브러리 몇 개 갖다 쓰다보면 프로젝트에 속한 파일이 몇 만 개를 어렵지 않게 넘긴다. 이렇게 많은 수의 파일은 각각의 크기가 크지 않더라도 동기화 서비스에 대단한 부하로 작용한다. VCS에 익숙치 않던 주니어 개발자 시절에는 어수룩하게 코드베이스를 Google Drive에 두었다가 드라이브 클라이언트가 맛이 가서 곤란을 겪은 적이 있다. VCS에서는 이런 요주의 파일들을 한번에 동기화 대상에서 제외해놓을 수 있다.

명명법

각 디렉토리/파일들은 다음 규칙에 따라 명명한다.

kebab-case

디렉토리와 파일들은 기본적으로 영문 kebab case를 따라 이름을 붙인다.

이 선택은 순전히 컴퓨터공학적 관점에서의 편리함에 따른 것이다.

① 이름에 포함된 한글은 코드/명령어를 입력하는 도중 한글 ↔ 영문을 오가야 하는 번거로움을 낳고, 인코딩 때문에 문제를 일으킬 수도 있다.
② 영문 대소문자의 혼용은 서로 다른 이름을 같은 것으로 혼동하게끔 만들 수 있다.
③ 공백은 자칫 컴퓨터가 경로를 하나가 아닌 여러 개의 문자열로 혼동하게끔 만들 수 있다. 예를 들어 do something.py라는 파일을 Python으로 실행하고자 할 때 이름을 따옴표로 감싸지 않고 python do something.py라고 명령한다면, 컴퓨터는 해당 파일을 정상적으로 실행하는 대신에 "do 파일은 없는데요? something.py는 또 무슨 소리죠?"라고 반항할 수 있다.

영문 kebab case는 이 모든 문제로부터 자유롭다. 공백을 대체하는 문자(-)를 입력할 때 shift를 누르지 않아도 되므로 snake case(_)보다도 약간 더 편리하다. 단순 띄어쓰기가 아닌 맥락의 분리가 필요한 경우 의도적으로 _를 쓸 때도 있기는 하다.

영문자와 숫자, - 및 _를 제외한 문자들은 어떤 부작용을 일으킬지 모르므로 사용을 최대한 지양한다.

버전

같은 문서의 각기 다른 버전은 난 다음과 같이 이름 붙인다:
① 작업이 $n$% 완료되었을 경우 버전은 v$n$
② 완성본 및 준완성본의 버전은 각각 vF (final), vSF (semi-final)
예를 들어 한국항공우주학회 2025 춘계학술대회에 제출할 논문의 반 정도 완성된 안, 그리고 준완성본의 파일명은 각각 KSAS2025S-manuscript-v50.docx와 KSAS2025S-manuscript-vSF.docx. 이 방식은 사실 우리 교수님의 그것을 그대로 따른 것인데, 당신께서는 어떻게 한다고 말씀하시거나 나보고 따르라고 하신 건 아니다. 그냥 교수님께서 보내시는 파일을 보다 보니 패턴을 알게 되었는데 아주 괜찮아보여서 그대로 베꼈다.ㅎ

순서

같은 디렉토리 아래 디렉토리/파일들은 기본적으로는 순서를 따로 두지 않고, 그렇게 하는 것이 아주 편리할 때만 제한적으로 $n$- 접두사를 부여한다. 앞선 춘계학술대회를 다시 예로 들면 그 진행 단계에 따라 0-ref(제출한 연구에 참고한 자료), 1-manuscript(제출한 논문), 2-registration(참가 등록, 숙박 및 출장비 청구), 3-schedule(학회 일정), 4-presentation(발표) 등의 하위구조를 두었다.

번호 붙이기의 경우 나와는 다른 지인들의 방식을 볼 기회도 몇 번 있었다. 모든 디렉토리에 서두에 한 자리 번호를 부여해 n-Enter-n-Enter-...(키보드로 왼손 오른손 왼손 오른손... 처음 볼 때 무슨 피아노 치는 줄 알았다)만 누르면 원하는 경로로 빠르게 이동할 수 있도록 한 이가 있는가 하면, 각 자리의 숫자가 곧 각 단계에서의 순서를 의미하는, 정해진 자릿수의 번호를 부여하여 그 번호만 알면 해당 경로로 바로 이동할 수 있는 시스템을 구축한 사람도 있었다. 예를 들어 세 단계의 깊이로 이루어진 아카이브에서, 첫번째 대분류, 두번째 중분류에 해당하는 디렉토리의 번호는 120.

나는 모든 구조에 번호를 붙이고, 또한 순서 상 중간에 새로운 디렉토리를 만들기 위해 이어지는 모든 번호를 미는 과정이 개인적으로 번거롭게 느껴졌다. 또 경로를 되도록이면 간결하게 유지하고 싶었기 때문에 전역 번호 붙이기를 채택하지 않았다. 물론 앞선 지인들의 방식보다는 특정 경로를 찾아 들어가는 데에 더 긴 시간이 걸린다는 단점은 있다.

여담

이 글을 쓰면서 위에 첨부했던 유튜브 알고리즘에 등장한 영상을 포함, 폴더 정리에 관한 자료를 좀 찾아봤다. 개인적인 꿀팁도, PARA method 같이 아예 각잡고 정립해놓은 이론도 있었다. 여기에는 마치 내가 글쓴이와 합의한 것마냥 이미 똑같이 하고 있는 것들이 있는가 하면, 새로 배울 점도 있었고, 전혀 동의할 수 없는 것들도 있었다.

같은 컴퓨터를 가지고도 각자가 하는 일은 모두 다르고, 개인의 취향도 전부 상이하다. 따라서 많은 사례를 참고하되 맹목적인 수용보다는 자신의 상황에 맞게 일부를 수용해나가며, 본인에게 가장 적합한 체계를 정립해나가는 것이 중요하겠다. 라는 당연한 말과 함께, 이 글이 그러한 과정에 도움이 되기를 바라며 글을 마친다.