개인 위키 프로젝트

“역사를 잊은 민족에게 미래는 없다” 라는 말이 있다. 사실 이 말의 출처는 불분명하다.¹ 하지만 이 말의 속 뜻이 “역사적 기록을 보존하고, 그것으로부터 교훈을 얻고 실수를 반복하지 않는 것이 중요하다” 라면 나는 그 말에 동의한다. 그건 국가 단위에서 뿐만 아니라 개인에게도 마찬가지다. 아주 잘 하고 있지는 못하지만, 그래도 시간과 자원이 허락하는 한 생활의 모든 부분에 있어서 문서화를 잘 하려고 노력하는 편이다. 체계적인 문서화가 어렵다면 단편적인 정보(이메일, 노트, 녹취록 등)라도 남기려고 한다.

사실, 어떤 기술적 문제를 해결하는 절차를 적어놓은 기록이거나, 실험 결과와 도출해낸 결론에 대한 기록과 같은 것은 GitHub, StackOverflow, Wikipedia 등 전 세계 사람들이 볼 수 있는 곳에 공개할 수 있고, 실제로 그렇게 하고 있다. 다만, 일기장이나 각종 사건사고 기록과 같이 인터넷에 공개하기 어려운 기록들도 가지고 있기 때문에 이 둘은 명확하게 구분해서 관리할 필요가 있다.

지금까지 비공개 기록들은 에버노트, 구글 독스, 드랍박스와 같은 서비스를 이용해서 관리해왔었다. 하지만 “이런 종류의 기록은 이곳에 보관해야 한다” 와 같은 체계적인 기준이 잡혀있지 않고, 오랜 기간 이런저런 서비스를 전전하다보니 기록이 파편화됨에 따라 관리하기가 점점 어려워졌다.² 이렇게 하면 필요한 문서를 찾기 위해서 검색을 하려고 했을 때 여러 서비스에 다 검색을 하게 되는 경우가 생긴다.

그럼 어떤 이유로 한가지 서비스에 만족하기 못하고 여러 서비스를 기웃거리게 되었는지 간단하게(?) 정리해보자.

여러가지 노트 서비스/앱 특징 분석

Evernote

학교 수업을 들으며 노트를 작성하기도 하고, 여행중 기록을 남기기 위해 사용했다.

장점

• Web, iOS, Android, Windows Phone, Mac OS X, Windows 등 다양한 플랫폼을 지원한다.
• 텍스트 뿐만 아니라 이미지, 동영상, 음성 녹음 등을 보관하기 편리하다. 특히 드래그앤드랍으로 이미지를 붙여넣고 다시 원본을 꺼내오는 작업이 수월하다.
• 통신이 되지 않을 때 (비행중이거나, 로밍이나 심카드 없이 외국 여행 중) 노트를 작성하기 편리하다.
• 검색 퀄리티가 나쁘지 않다. 한국어 검색 결과는 영어에 비해서는 질이 떨어지긴 하지만, 그래도 아주 못 쓸 정도는 아니다.

단점

• (여러 장비에서 같은 문서를 다르게 수정했을 경우) 충돌 풀기 기능이 어설프다.
  • Three-way merge와 같은 방법을 사용해서 충돌을 풀 수 있는 경우에도 충돌을 자동으로 풀지 않고, 분기된 문서를 모두 보존해서 사용자가 수동으로 충돌을 풀게 만든다.
• Markdown, RST 처럼 시맨틱 정보가 보장되는 포맷을 사용할 수 없다. WYSIWYG 에디터를 사용해야 한다.
  • 위 문제는 에버노트를 백엔드로 사용하는 Markdown 에디터인 Marxico를 이용해서 해결할 수 있다. Marxico 자체는 매우 훌륭하다.
• 스타일이 지원되지 않는다. 헤더 1, 헤더 2, 본문, 코드 등과 같은 시맨틱 스타일 지정 없이 글꼴 변경만으로 표현해야 한다. 만약 6개월 전에는 헤더 3을 bold Arial 14pt로 표기 했었지만, 오늘부터 헤더 3의 스타일을 bold Helvetica 12pt로 변경하고 싶다면 예전 노트를 샅샅히 뒤져서 예전 글꼴로 되어있던 부분을 새로운 글꼴로 변경해주어야 한다. 이 부분은 진짜 치명적인 단점이다. 다른 기능이 훌륭해서 돈을 내고 사용할까 고민했었지만, 결국 에버노트 자체를 사용하지 않기로 결심하게 된 결정적인 이유가 바로 이 부분이다.

참고 1

Markdown이라는 것을 처음 들어보는 독자들을 위해서 약간의 첨언을 하자면, 문서의 시맨틱을 표현할 수 있는 마크업 언어이다. 예를 들면, 우리가 워드프로세스에서 특정 텍스트를 선택해서 글꼴을 변경하듯이 “이 부분은 이탤릭 글꼴로 보여야 한다”를 정의하는 것이 아니라, 이 부분의 의미는 *구문 강조*이다를 정의하는 포맷이다. *구문 강조*가 어떻게 보여야 하는지는 별도의 스타일시트를 통해서 정의한다. 잘 정의된 기본값을 그대로 사용해도 좋고, 필요한 경우에 스타일을 재정의(override) 할 수 있다.

구문 강조 뿐만이 아니라 헤더, 하이퍼링크, 이미지, 불릿 포인트(bullet points), 인용, 코드 블럭, 테이블, 각주(footnotes) 등 문서를 작성하는데 필요한 여러가지 요소를 표현할 수 있다.

그 덕분에 문서를 작성할 때에는 “어떻게 보일 것인가” 대신 “무슨 의미인가”에만 집중하면 된다. 번거롭게 마우스로 손을 옮길 필요도 없다. 어떻게 보일 것인지에 대해서는 글의 내용과 분리해서 생각할 수 있고, 일괄적으로 변경하기 용이하다. 또한, 각 구성 요소의 의미가 그대로 보존되기 때문에 텍스트를 처리하는 프로그램을 작성하기 훨씬 용이하다. 내용을 복사 & 붙여넣기 하다가 무언가 틀어질 염려도 없다.

Markdown을 모든 기능을 설명하는 것은 이 글의 범주를 벗어나는 일이기 때문에 더 자세한 내용은 이 페이지를 참고하면 좋을 것 같다.

참고 2

지금 여러분이 읽고 있는 이 글도 Markdown으로 작성되었다.

Google Docs

강력한 검색 기능에 이끌려 상당수의 기록을 여기에 남겼다. 대학원 시절 작성했던 클래스 노트의 상당수가 여기에 저장되어있다.

장점

• 에버노트와 다르게 스타일 지정은 된다.
• 구글 제품 답게 검색 성능은 타의 추종을 불허한다.
  • 우리가 구글 웹 검색에서 기대하는 세계 최고의 검색 엔진을 내 개인 문서를 검색하는데 사용할 수 있다.
  • 텍스트로 입력하지 않은 내용도 검색해준다. 예를 들어서, ‘pizza’로 검색을 할 경우 피자가 들어간 이미지를 보여준다.
• 여러명이 실시간으로 문서를 공동 편집할 때 매우 편리하다.
• 매우 똑똑한 리비전 관리를 해준다.
• Docs, Spreadsheet 등 네이티브하게 지원되는 포맷을 사용할 경우 용량 할당량(quota)을 잡아먹지 않는다. 이론적으로는 무제한 용량처럼 사용할 수 있다.
• 크롬 확장 기능을 설치하면 오프라인 상태로도 사용 가능하다.
• 구글 아이디를 사용하는만큼 MFA(Multi-Factor Authentication)를 사용할 수 있다.
• 문서 편집 도구인 독스(Docs) 뿐만 아니라 스프레드시트, 프리젠테이션, 폼(Form), 드로잉(Drawing) 등 매우 다양한 오피스 제품군을 사용할 수 있다.

단점

• 시맨틱이 보장되는 문서 포맷은 지원되지 않는다. 이건 StackEdit과 같은 도구를 통해 해결할 수 있다.
• 문서에 붙여넣은 이미지를 원본 그대로 꺼내는 작업이 매우 까다롭다.
  • 이미지 복사는 구글 문서 안에서만 유효하다.
  • 이미지를 바깥 세계로 가지고 나가려면 화면을 캡쳐하거나, 브라우저의 디버깅 도구를 사용하거나, 문서를 .zip으로 내보내기 해서 꺼내야 한다.
• UI가 전반적으로 무언가 굼뜬 느낌이 있다.
  • 따라서 간단한 메모를 작성하기에는 적합하지 않을 수도 있다.
  • Docs를 사용하다보면 Visual Studio Code 또는 Vim 같은 텍스트 에디터를 띄워서 빠르고 가볍게 문서를 편집할 수 있는 환경이 그리워진다.

Dropbox

파일 관리와 공유에 대해서는 아마 절대 강자가 아닐까 한다. 한때에는 Dropbox와 비슷한 기능을 하면서 BitTorrent 프로토콜을 사용하는 Resilio (그 당시 이름은 BitTorrent Sync)를 사용하기도 했었지만, 리비전 관리 기능이나 다른 사람과 파일을 공유하고 불특정 다수에게 파일을 배포할 때 만큼은 Dropbox보다 편리한 도구를 보지 못했다.

장점

• 텍스트 문서 뿐만 아니라 모든 파일에 대한 리비전 관리가 용이하다.
• Markdown 형식으로 작성된 파일을 .md 확장자를 붙여서 노트, 문서처럼 관리했는데, 다른 그 어떤 에디터, 웹 인터페이스, 모바일 앱과 비교해도 Visual Studio Code로 글을 작성할 때의 경험이 제일 훌륭했다.

단점

• Unicode encoding conflict
• Dropbox가 실행되는 환경의 파일과 디렉토리 구조를 그대로 따라가야 하다보니 하나의 문서가 여러개의 디렉토리에 속한것 처럼 보이게 만들 수 없다. Gmail에서는 태그를 이용해서 이런 방식으로 메시지를 정리하고 열람할 수 있게 해준다. Dropbox가 지원하는 모든 운영체제에서는 하나의 파일이 단 하나의 부모 디렉토리를 가진다.
• 검색 경험이 운영체제에 따라 달라질 수 있다.
• 모바일에서 문서를 바로 작성하기에는 불편하다.
  • 사실 이건 Dropbox가 노트 앱이 아니라, 파일을 쉽게 관리하고 공유할 수 있도록 만드는 것이 본래의 목적이기 때문에 Dropbox의 단점이라고 이야기 할 수는 없다.
  • 드랍박스에서 만든 문서 작성 도구인 Paper는 모바일에서도 쓰기 편리하다. 하지만 에버노트와 구글 독스가 가진 단점 몇 가지를 가지고 있다.

Google Keep

원래는 간단한 기록을 남기기 위해 Trello를 사용했었지만, 구글에서 비슷한 제품을 만들었다고 해서 한번 써봤다.

장점

• 모바일에서 사용하기에 괜찮다.
• 구글 제품 답게 검색 성능이 좋고 협업 기능이 갖추어져있다.
• Google Docs와 연동된다. Keep에서 간단하게 메모해놓은 것을 나중에 정식으로 문서로 작성하기 편리하게 되어있다.

단점

• 긴 문서를 작성하기에 적합한 도구는 아니다.
• 메모의 체계적인 분류가 어렵다. 메모 분류를 위해 지원하는 기능은 각 메모에 색깔을 부여할 수 있는 정도이다.
• 시맨틱이 보존되는 포맷을 사용할 수 없다.

Trello

첫 직장에서 쓰게 되었는데, 제공하는 기능이 꽤 마음에 들어서 아직까지도 잘 사용하고 있다.

장점

• 시맨틱이 보존되는 포맷을 사용할 수 있다. (Markdown)
• 모바일에서 사용하기에 괜찮다.
• 협업 기능을 제공한다.

단점

• Keep과 마찬가지로 길이가 긴 문서를 관리하기 편하지는 않다.
  • 사실 이건 제품 자체의 단점이라기보다는 ‘종합적인 기록 관리 도구로서’ 사용하기에 부족한 점이다.
• 한국어 검색 기능이 부족하다.
  • 단순하게 띄어쓰기를 기준으로 구분해서 인덱싱 하는 듯. 예를 들어서, ‘농림’으로 검색하면 “옥수수가 남미 지역 가뭄으로 인해 6.0% 뛰면서 농림수산품이 0.2% 상승했다.” 와 같은 문장을 포함한 기록이 검색되지 않는다.

위키(Wiki)

그러다가 문득 이런 생각이 들었다.

“위키피디아처럼 나의 모든 기록을 위키 형태로 관리하는건 어떨까?”

위키야말로 내가 원하는 거의 모든 조건을 만족하는 문서 관리 방법이 아닐까 한다.

• 시맨틱이 보존되는 형식의 문서 작성
• 뷰어와 에디터의 분리
• 검색
• 리비전 관리
• 멀티미디어 첨부

그래서 여러가지 위키 서비스와 설치형 제품들을 알아보았지만, 딱히 “이거다!” 하는 느낌을 주는건 찾지 못했다. 새로운 위키 서비스를 발견해서 테스트 목적으로 문서 몇 개를 만들다보면 무언가 중요한게 하나씩 빠져있는 느낌을 받았다. 예를 들면, 어떤 서비스는 클립보드에 있는 이미지를 붙여넣는 기능이 지원되지 않고 이미지 파일을 올려야 한다거나, 다른 서비스에서는 WYSIWYG 에디터만 제공하기 때문에 시맨틱이 보존되는 문서를 작성하기 어려웠다. 그럴 때마다 금방 포기하고 다시 구글 독스로 돌아갔었다.

그렇게 여러가지 위키 서비스를 조금씩 기웃거리다가, 얼마 전에 회사에서 아주 잘 사용하고 있는 깃랩(GitLab)이 떠올랐다. 깃랩은 사실 위키 서비스라기보다는 소스코드 버전 관리, 이슈 트래커, 위키 등을 합쳐놓은 소프트웨어 프로젝트 관리 도구이다. 하지만 꽤 괜찮은 위키 기능이 제공되기 때문에 위키 기능만 사용하는 것도 어쩌면 괜찮은 방법이 아닐까 하는 생각이 들었다. (왜 진작 이 생각을 하지 못했지!)

깃랩(GitLab)

깃랩은 크게 두 가지 형태로 사용할 수 있는데, 서비스형과 설치형이다. 서비스형은 깃랩에서 호스팅 해주는 서비스를 사용하는 것이고 (SaaS), 설치형은 사용자가 직접 본인의 서버에 깃랩 소프트웨어를 설치해서 사용하는 것이다. 깃랩에서 호스트 해주는 서비스를 이용하면 서버 운영에 대한 아무런 고민을 하지 않을 수 있어서 좋지만, 이왕 깃랩을 도입하는 김에 위에서 언급했던 서비스들을 사용하면서 항상 마음 한켠에 부담으로 자리잡았던 사생활 보호 문제와 기록에 대한 소유권 문제를 해결하고 싶다는 생각이 들었다. 누군가가 나의 데이터를 보관해준다면, 특히 무료로 보관해준다면 어떤 식으로든 대가를 치르게 되어있다.

설치형 깃랩을 사용해보기로 마음 먹었다. 하지만 처음부터 깃랩 서버를 구축하기보다는 도커 이미지를 받아서 운영을 해본 후 별 문제가 없을 때 본격적으로 깃랩 서버를 구축하는 것도 괜찮겠다 싶어서 일단 도커 이미지를 받았다.

docker get gitlab/gitlab-ee

그리고 나서 다음과 같이 실행하면 된다. 처음 서비스를 띄우는데 의외로 오래 걸린다. 1분 정도 걸린 듯.

docker run --detach \
    --hostname localhost \
    --publish 8443:443 --publish 8080:80 --publish 2222:22 \
    --name gitlab \
    --restart always \
    --volume $HOME/gitlab/config:/etc/gitlab \
    --volume $HOME/gitlab/logs:/var/log/gitlab \
    --volume $HOME/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ee:latest

이런식으로 깃랩 서비스를 운영하는 한, 홈 디렉토리에 있는 gitlab 디렉토리만 잘 보관하면 모든 데이터가 안전하게 보관된다.

무엇을 기록하는가?

도커를 이용해서 깃랩 서비스를 띄운 다음 여러가지 기록들을 위키에 기록하기 시작했다. 2주 정도 꾸준히 작성하다보니 어느새 이런 대략적인 문서의 분류들이 생겼다.

지금은 413건의 문서가 있지만, 앞으로 계속 늘어날 예정이다. 여행하면서 기록한 내용들, 각종 사건사고 기록, 문득 떠오른 앱/서비스 아이디어들, 사람들에 대한 기록 등 수많은 종류의 기록이 있다. 특히 예전에 작성된 일기를 모두 위키로 옮겨온다면 문서 수가 몇배로 늘어날 것이다.

살다보면 이런저런 일을 겪기 마련인데, 그때마다 일의 진행상황을 기록해두면 나중에 비슷한 일이 생겼을 때 참고하기 좋다.

임대차 계약을 갱신하면서 생긴 문제와 해결 과정을 기록해두기도 하고,

면접 질문에 제대로 답하지 못했던 일도 기록해놓으면 언젠가 다 쓸모가 있다.

마음에 드는 기능 1: Drag & Drop

이미지를 비롯한 파일을 첨부하고자 할 때 이렇게 파일을 편집창으로 끌어다 놓으면 알아서 업로드가 되고,

이렇게 자동으로 마크업이 완성된다. 매우 편리한 기능이다.

마음에 드는 기능 2: 하이퍼링크

위키로 문서를 작성할 때의 큰 장점 중 하나는 바로 위키 페이지간 상호 링크가 가능하다는 점이 아닐까 한다. 예를 들어서, 어떤 문서를 작성하다가 비트코인에 대한 이야기가 나오면 예전에 작성해둔 ‘비트코인’ 항목으로 링크를 걸 수 있다. 물론 외부 링크도 가능하다. 웹을 웹답게 사용할 수 있어서 좋다.

마음에 드는 기능 3: Wiki as a Git repository

그리고 깃랩에서는 위키를 Git 저장소 형태로 제공해준다. 다시 말해서 깃랩에서 제공하는 웹 에디터를 사용하지 않고, 원하는 에디터를 사용해서 자유롭게 위키를 편집할 수 있다는 뜻이다. 또한, 통신이 되지 않거나 위키 서버에 접속할 수 없을 때에도 위키 문서를 수정해 두었다가 나중에 위키 서버에 접속할 수 있게 되었을 때 변경된 내용을 푸시할 수 있다.

아직 결정하지 못한 문제들

지금은 베타 테스트 느낌으로 발을 반 쯤만 담구어서 사용하고 있는데, 본격적으로 사용하려면 결정하고 해결해야 할 문제들이 남아있다.

기존 기록 가져오기

일기장 같은 경우 수백건의 기록이 구글 독스에 저장되어있는데, 이것을 하나씩 손으로 옮기기는 어려울 것 같으니 자동으로 가져올 수 있는 스크립트를 작성해야 할 것 같다.

외부 접속과 HTTPS

지금은 특정 호스트에서만 접속할 수 있고, 외부 세계(인터넷)와는 (거의) 단절되어있다. 이건 장점이자 단점인데, 장점은 여러가지 보안 문제에 대해서 비교적 안전하다는 것이고, 단점은 이동중이거나 다른 환경에 있을 때 접속할 수 없다는 점이다.

만약 외부 세계에서 연결할 수 있도록 만들고자 한다면 HTTPS를 필수적으로 사용해야 할 것이다. Self-signed 인증서를 이용해서 암호화된 연결을 제공할 수도 있고³, Cloudflare와 같은 서비스를 이용해서 프록시에서 암호화된 연결을 제공하는 방법도 있다. 다만, 후자의 경우 Cloudflare의 프록시 서버와 나의 위키 서버 간에는 평문 통신을 하게 되므로 전자와 같은 방법이 더 나을 것이라고 생각한다.

백업

호스트 되는 서비스를 이용한다면 특별히 백업에 신경쓸 필요가 없겠지만, 직접 서버를 운영하는만큼 백업에 특별히 주의를 기울여야 한다. 명령어를 잘못 치거나, 깃랩 서버가 보관된 장소에 불이 나거나, 천재지변 또는 외계인의 침략과 같은 이유로 십몇년간의 기록이 순식간에 사라져버린다면 그것만큼 허무한 일도 없을 것이다. 주기적으로, 그리고 최소 두 개 이상의 지리적으로 분리된 저장소에 자동으로 백업을 하는 정책을 수립해야 한다. gitlab 디렉토리를 암호화 해서 AWS Glacier 버지니아 리전에 백업하고, Azure 독일 리전에도 백업해 놓는다면 아주 적은 비용으로 안전하게 데이터를 보관할 수 있을 것이다.⁴

모바일에서의 작성

웹 인터페이스를 이용하는만큼 모바일 웹브라우저로 모든 기능을 사용할 수 있기는 하다. 다만, 깃랩 자체가 모바일에서 문서를 적극적으로 작성하는 부분에 있어서 편의성을 고려하고 만든 것이 아니라 본격적인 문서 작성을 하려면 데스크탑의 도움이 필요하다. 아니, 그 이 전에 작은 모바일 기기에서 사소하지 않은 문서 작성을 하는 것이 가능한 일(possibility)이기는 하지만, 적절한 일(plausability)인지는 조금 더 고민을 해 보아야 할 것 같다.

당분간은 모바일에서 Google Keep 또는 Trello를 이용해서 간단히 기록하고, 나중에 위키로 옮겨 적는 작업을 하게 될 것이다.

라이센스 비용

지금 엔터프라이즈 버전을 사용하고 있긴 하지만, 라이센스 비용을 지불하지 않았기 때문에 유료 기능이 비활성화 되어있다. Elasticsearch를 연동하는 등 여러가지 고급 기능을 사용하려면 라이센스 비용을 지불해야 하는데, 이게 과연 그만한 가치가 있는지 따져볼 필요가 있다.

Starter의 경우 월 $4 수준이기 때문에 큰 부담 없이 사용할 수 있지만, Ultimate의 경우 월 $99 수준이라 개인적으로 사용하기엔 조금 부담이 될 수 있다.

마무리

근 10년간 개인적인 기록을 정리하면서 고민했던 내용과, 최근 2주간 개인 위키를 사용한 소감을 간단하게(?) 정리해보았다. 위키로 기록을 관리하게 되면서 기존에 사용하던 도구에서 느꼈던 다양한 불편함을 해소하고, 사생활 보호 문제와 명확한 소유권 보장 등 부가적인 장점을 취할 수 있게 되었다. 하지만 아직 본격적으로 사용한다기보다는 시험 운용에 가깝다. 안정적으로, 그리고 장기적으로 개인 위키를 운영하기 위해서 앞으로 해결해야 할 일들이 많이 있겠지만, 왠지 즐거운 일이 될 것 같은 느낌이 든다.