개인 버전관리 (2023년 가을 버전)

일을 하든 개인 용무를 보든 일단 위키 문서를 만들거나 워드 문서를 만들거나 엑셀 워크시트나 발사믹 와이어프레임 파일을 만들면 항상 저장할 때마다 거의 모든 버전을 별도로 유지하는 환경을 사용합니다. 몇 년에 걸쳐 핵심 문서 작성 도구로써 사용하는 컨플루언스 위키는 저장(발행)할 때마다 버전을 생성하고 이 버전을 제한 없이 계속해서 유지해 줍니다. 어떤 문서는 한 문서를 완성하는데 수 백 번은 저장할 때도 있는데 그럴 때마다 수 백 개에 달하는 모든 버전을 별도로 보관해 긴 히스토리 목록을 만들곤 합니다. 이렇게 만들어진 히스토리 목록은 1년에 한 99% 정도는 쓸모 없지만 나머지 1%에 해당하는 사건이 일어날 때 시간을 거슬러 올라가 이전의 어느 한 버전에만 남아 있는 내용을 현재로 소환해 하마터면 곤란하게 되었을 상황을 아주 부드럽게 모면하도록 해 줍니다.

이전에 위키에 오래된 리비전에 의미가 있을까?를 통해 위키위키에서 모든 리비전을 보관하는 동작이 과연 의미가 있을지 생각해본 적이 있습니다. 물론 모든 리비전을 유지해 주면 방금 한 이야기처럼 일어날 가능성이 낮은 위기 상황을 마치 미리 준비했던 것처럼 유연하게 넘길 수 있기는 하지만 한 번 남은 히스토리는 어쩌면 그냥 계속해서 저장하고 편집하고를 반복하는 동안에 만들어지는 의미 없는 데이터가 될 가능성이 높습니다. 위키위키 기준으로 이 데이터의 대부분은 텍스트 기반으로 현대에 저장하기에 그렇게 큰 부담이 될 거라고 생각하지 않기는 하지만 매일 엄청나게 많은 사람들이 문서를 편집하고 저장하기를 반복하며 다시는 찾지 않을 리비전을 만들어내기를 반복하며 세월이 지나면 아무리 스토리지 가격이 낮아져도 결코 무시하기 쉽지 않은 용량이 될 겁니다. 또 지난번에도 이야기했듯 이렇게 쌓기만 해서는 나중에 히스토리가 필요해질 때 찾기도 쉽지 않아 히스토리를 포함한 검색이 필요할 수 있다는 이야기를 했었습니다.

한편 2023년 올 초에 개인 작업에서 만들어진 바이너리 파일 버전관리 방법 소개를 통해 개인 작업이나 회사 일을 할 때 문서 이외에 발생한 바이너리 파일의 버전을 관리하는 방법을 소개했습니다. 바이너리 파일 버전을 관리해야겠다는 요구사항을 가진 초창기에는 로컬에 Visual SVN Server를 설치해 사용했고 개인이 바이너리 파일 버전을 관리하고 브랜치를 만들어 여러 파일의 리비전을 한번에 관리하고 또 한 파일의 이전 히스토리를 탐색하는데 아무 문제가 없었습니다. 그런데 이 리파지토리를 다른 사람과 공유하려 하자 귀찮은 문제가 생깁니다. 실은 그냥 제 기계의 리파지토리에 접근할 수 있게 설정한 다음 공유 받을 사람이 리파지토리를 체크아웃 하도록 하면 끝이었지만 핵심 작업용 장비에 함부로 서버들을 열어 보안 문제를 일으킬 가능성을 올리고 싶지 않았습니다. 그래서 시간이 지나며 몇몇 시행착오를 겪은 끝에 지금은 빗버킷이라는 깃 기반의 서버를 제공하는 버전 관리 서비스를 사용하고 있고 여기까지가 지난번에 소개한 개인 버전 관리 방법입니다.

2023년 가을 현재 여기에 더해 두 가지 버전 관리 방법을 추가해 정말 웬만한 사고로는 파일을 잃지 않을 뿐 아니라 어지간한 문제가 발생해도 파일의 이전 버전을 현재로 소환해 귀찮은 일을 겪지 않도록 하고 있습니다. 오늘은 이 전체 체계를 소개하겠습니다.

일단 현재 바이너리 파일 버전 관리에 메인으로 사용하는 빗버킷 이야기부터 시작하면 무료로 가입하면 리파지토리 하나 당 4기가까지 사용할 수 있습니다. 4기가를 초과하면 리파지토리가 읽기 전용으로 바뀐다고 하는데 아직은 제한에 도달하지 않았고 만약 매뉴얼 대로라면 다른 리파지토리를 생성해서 다시 시작하면 되니 무료 사용 범위에서 큰 문제는 아니라고 생각합니다. 또 깃 기반이지만 LFS를 사용하지 않고서도 큰 파일을 그냥 올릴 수 있는데 이 특징은 깃이 원래 그런 건지 아니면 빗버킷의 특성인지는 잘 모르겠습니다. LFS 설정에 신경 끄고서도 그냥 몇 메가에서 몇 십 메가 정도 되는 큰 파일을 그냥 올릴 수 있어 편리합니다. 로컬에 Visual SVN Server를 사용하던 시대에 비해 좋아진 점은 파일 저장소가 원격에 있어 내 기계에 문제가 생겨도 안전하다는 것, 그리고 다른 사람에게 리파지토리를 공유하기 쉽다는 점입니다. 대신 무료 사용 범위 안에서는 용량에 제한이 있고 여태까지 깃으로부터 받아온 모든 저주를 똑같이 받고 있기는 합니다.

다음으로 파일 버전 관리에 윈도우 파일 히스토리를 적극적으로 사용하기 시작했습니다. 윈도우 파일 히스토리는 맥OS에 처음으로 타임머신이 소개되던 시대에는 없던 기능인데 타임머신 같은 멋진 인터페이스는 아니지만 비슷한 수준의 기능이 그리 머지 않은 시점에 윈도우에도 추가됐습니다. 한동안은 그 생김새가 해도해도 너무나도 못생겨서 관심을 갖지 않았는데 윈도우 10을 사용할 즈음 부터는 생김새가 어떻든 이 기능이 파일 변경사항을 모니터링해서 버전을 계속해서 쌓아주는 꽤 괜찮은 도구라는 사실을 깨달았습니다. 그래서 윈도우 파일 히스토리를 켜 놓고 백업 시간을 가장 짧은 ‘10분’으로 설정해 놓고 살고 있습니다. 이렇게 해 두면 파일 히스토리가 백그라운드에서 10분 간격으로 파일시스템을 모니터링 해 변경된 파일 이름에 타임스탬프를 붙여 지정한 장소에 복사합니다. 한 번 설정해 두면 그냥 조용히 실행될 뿐 사용하려고 마음 먹기 전까지는 이런 서비스가 구동되고 있다는 사실 자체를 잊어버릴 수 있습니다.

윈도우 파일 히스토리가 직접 빗버킷에 파일을 커밋하는데 비해 편안한 점은 따로 파일을 커밋하는 행동 자체를 할 필요가 없는 것입니다. 그냥 매 10분마다 파일에 변경사항이 있으면 복사본 하나를 생성할 뿐입니다. 그래서 빗버킷에 올라가 있는 파일의 이전 버전은 이 버전을 왜 커밋 했는지 함께 알 수 있는 대신 버전을 만들고 싶을 때마다 커밋을 반복해야 하는데 비해 윈도우 파일 히스토리는 그냥 시간 간격에 따라 아무 말 없이 복사되기 때문에 버전 각각의 의미를 알 수는 없지만 명시적인 커밋 없이도 그냥 파일 히스토리가 알아서 관리됩니다. 또 윈도우 인터페이스에 통합되어 있어 거창하게 무슨 프로그램을 실행하지 않아도 파일 등록정보 창을 열어 ‘이전 버전’ 탭으로 이동하면 이 파일의 이전 버전들이 모두 나타납니다. 히스토리를 유지할 스토리지 크기에 따라 오래된 히스토리를 삭제할 수 있는데 이 옵션을 굳이 켜지 않는다면 파일은 파일 히스토리를 처음 사용하기 시작한 날부터 현재까지 10분 단위로 저장된 모든 버전을 볼 수 있고 어떤 버전이든 현재로 다시 소환할 수 있습니다.

윈도우 파일 히스토리를 보조하는 다른 한 가지 방법은 드랍박스입니다. 오랜 세월이 흐르며 사고도 좀 있었고 현대에는 이와 비슷한 서비스가 사방에 널려 있기는 하지만 2023년 현대에도 여전히 여러 기계에 걸쳐 파일을 동기화하는데 이 정도로 신뢰할 수 있게 동작하는 서비스는 아직 없어 보입니다. 물론 초창기만큼 독보적인 수준은 아닙니다. 세월이 흐르며 여러 경쟁 서비스가 나타났고 금액 당 제공 용량이나 함께 제공하는 자잘한 서비스를 고려하면 현대에 드랍박스는 신뢰할 수 있게 동작하기는 하지만 저렴한 서비스라고 보기는 어렵습니다. 하지만 그래도 드랍박스를 유지하고 있는 이유는 나머지 드랍박스와 비슷한 모든 서비스들은 하나같이 윈도우와 맥을 함께 사용하는 환경에서 적어도 한 가지 이상의 환경에서 제대로 동작하지 않기 때문입니다.

가령 마이크로소프트에서 만든 원드라이브는 윈도우에서는 꽤 잘 동작하는 것 같아 보이고 여러 기계 사이에 빠른 동기화, 윈도우 인터페이스에 통합된 동작 같은 강력한 장점이 있지만 맥으로 넘어오면 흔히 아주 많은 파일에 동기화가 끝나지 않고 새 파일의 동기화가 늦어져 바로 다른 기계에서 파일을 열어 사용하려고 할 때 작업에 큰 차질을 일으키곤 했습니다. 또 애플에서 제공하는 아이클라우드 드라이브는 원드라이브 초창기 시절보다도 더 좋지 않은데 원드라이브는 적어도 윈도우 환경에서라도 제대로 돌아가는 모습을 보였다면 아이클라우드 드라이브는 맥에서조차 동기화를 영원히 끝내지 못하고 새로운 파일을 빨리 동기화하지 못하며 온라인 전용 파일을 요청하면 아주 오랫동안 기다려야 파일을 사용할 수 있는 등 문제가 많습니다. 게다가 맥에서도 잘 동작하지 않는 마당에 윈도우에서 역시 잘 동작하지 않는 것은 덤입니다. 또 구글 드라이브는 초창기에 그럭저럭 잘 동작했던 것 같지만 마지막으로 사용할 때 파일이 아주 많으면 아무렇지도 않게 몇몇 파일을 유실하기도 하고 또 동작 자체가 느려 계속해서 사용할 수가 없었습니다. 이런 상황을 겪은 끝에 끝까지 살아남아 신뢰할 수 있게 동작하는 프로그램은 여전히 드랍박스밖에 없습니다.

그런데 드랍박스도 시간이 흐르며 꽤 편리한 기능이 추가되어 단순한 파일 동기화 서비스라고만 보기는 쉽지 않습니다. 특히 드랍박스 백업은 윈도우 환경 기준으로 윈도우에서 제공하는 사용자 디렉토리, 문서나 음악, 그림 디렉토리 구조를 그대로 사용한다는 가정 하에 이 디렉토리를 드랍박스 위치와 관계 없이 별도로 동기화 해 드랍박스를 사용하는 기계에 따라 서로 다른 개인 파일을 알아서 백업해 줍니다. 백업 자체는 드랍박스 동작과 똑같습니다. 그저 새 파일이나 기존 파일의 변경을 순식간에 찾아내 빠르게 서버와 동기화 해 로컬에만 남아 있는 위험한 상태를 아주 빨리 벗어나게 해 줍니다. 이전에는 윈도우 파일시스템에 기반한 디렉토리 구조를 드랍박스 안에 넣으려면 귀찮은 작업을 거쳐야 했고 일단 이렇게 하면 드랍박스를 사용하는 여러 기계에 걸쳐 같은 파일을 사용해야만 했는데 드랍박스 백업이 생긴 다음부터는 기계에 따라 별다른 설정 없이 바로 사용자 디렉토리를 드랍박스에 넣을 수 있고 기계가 여러대 이더라도 서로 다른 파일을 사용할 수 있으며 서로 다른 기계의 파일을 빼오기도 편해졌습니다.

현대에 드랍박스의 가장 눈여겨볼 기능은 파일을 이렇게 쌓은 파일을 복원하는 기능입니다. 드랍박스는 표준 요금제 상 파일 히스토리를 30일까지 보관해 줍니다. 그리고 이 히스토리를 ‘Rewind’ 할 수 있는데 이 기능은 파일 단위 뿐 아니라 디렉토리 단위로도 동작해 실수로 원하지 않는 파일을 함께 옮기거나 삭제해 놓고 이 사실조차 모르고 있다가 나중에 낭패를 보거나 복구하려는 파일이 정확히 어디 있는지 모를 때 의미 있게 동작합니다. 히스토리에서 파일을 꺼내려 할 때 그 파일을 포함한 디렉토리를 선택한 다음 ‘Rewind’를 시작하면 이전에 선택한 범위에 일어난 상대적인 변화량을 그래프 모양으로 보여준 다음 이 안에서 시점을 선택할 수 있습니다. 가령 며칠 전 여러 파일을 삭제한 다음부터 삭제하면 안되는 파일이 사라진 것 같은 느낌이 든다면 이 그래프를 보고 언제쯤 파일을 삭제했는지, 혹은 여러 파일을 추가하거나 덮어썼는지 시점을 파악할 수 있습니다. 그리고 그 시점을 선택하면 이 때 변경된 파일 목록을 보여주고 아예 그 시점으로 상태를 되돌리거나 일부 파일만 꺼내올 수 있는데 윈도우 파일 히스토리와 비교해 변경이 일어난 파일 수를 시각화해서 보여주기 때문에 문제가 일어난 시점이 언제인지 추측하기 더 편합니다.

2023년 가을 현재 이렇게 세 가지 방법으로 작업하며 생기는 바이너리 파일을 관리하고 있습니다. 일단 로컬에서는 윈도우 파일 히스토리를 사용해 로컬에 시간 단위로 파일 버전을 남기고 있습니다. 일단 뭔가 잘못 저장했거나 덮어썼거나 삭제했다면 로컬에서 찾아볼 수 있으니 이 단계에서 문제를 찾을 수 있으면 빨리 해결할 수도 있습니다. 윈도우 파일 히스토리는 좀 투박하게 생겼지만 잘 동작하고 또 굉장히 단순해서 파일 역시 그냥 다른 드라이브에 파일 이름 뒤에 타임스탬프를 붙여 저장하고 있을 뿐이어서 만약 파일 히스토리 앱이 오동작하는 상황이 생기더라도 직접 스토리지를 열어 파일을 꺼낼 수 있습니다.

다음으로 빗버킷에 깃 기반으로 작업 파일을 적당한 시점마다 커밋 하고 있습니다. 대용량을 보관할 수는 없지만 그럴 일이 거의 없고 또 로컬 기반이 아니기 때문에 기계 고장 같은 문제에 대응할 수 있습니다. 또 각 버전마다 무슨 수정을 해서 커밋하는 건지 코멘트를 항상 남길 수밖에 없기 때문에 코멘트를 살펴보고 되돌리기를 원하는 버전을 쉽게 찾을 수 있게 해 줍니다. 다만 깃이 바이너리 파일에 일으키는 온갖 문제가 똑같이 일어나니 이런 문제에 민감하다면 그리 추천할 만한 방법은 아닙니다.

마지막으로 드랍박스와 드랍박스 백업을 사용해 윈도우의 기본 사용자 디렉토리 구조를 그대로 백업하고 있습니다. 드랍박스는 지금도 거의 유일하게 여러 기계 사이를 빠르게 동기화하고 새 파일이나 파일 변경사항을 빨리 다른 기계에 공유할 수 있으며 파일을 누락하는 등의 문제 없이 신뢰할 수 있게 동작합니다. 또 히스토리를 탐색하는 꽤 훌륭한 인터페이스를 제공해 실수가 언제쯤 일어났는지 어렵지 않게 알아낼 수 있습니다.

개인적으로는 미래로 갈수록 기계 로컬에 파일을 보관하는 사용 방식 자체가 서서히 줄어드는 추세가 올바르다고 생각합니다. 로컬 기계는 무거운 프로그램을 돌리거나 게임을 하거나 영상을 보는데는 적절하지만 미션 크리티컬한 파일을 보관하고 관리하고 히스토리를 유지하는데는 위험합니다. 로컬 기계는 언제든 고장날 수 있고 물리적으로 침범 당할 수도 있으며 부주의한 서드파티 프로그램으로 인한 보안 문제가 일어날 수도 있습니다. 그런 기계에 단독으로 미션 크리티컬한 파일을 두는 건 결코 안전하지 않습니다.

하지만 로컬에 파일을 두고 히스토리를 관리하면 일단 굉장히 빨리 히스토리를 탐색할 수 있기 때문에 로컬에 파일을 보관하는 서비스인 윈도우 파일 히스토리를 메인으로 드랍박스와 빗버킷을 병용해 만약에 대비하고 또 여러 가지 방법으로 히스토리를 저장해 작은 실수가 큰 문제를 일으키지 않도록 대응하고 있습니다. 모르긴 몰라도 이 세 가지 방법이 동시에 실패하지는 않을 거라고 생각합니다.