하이독스의 기원
처음 모습
하이독스의 가장 오래된 정체성은 개인 클라우드 저장소였다.
처음에는 자료를 올리고 내려받는 것이 핵심이었다. 사이트 안에는 특별한 내용이 거의 없었고, 저장소로 이동하는 입구만 있었다.
그 입구는 단순한 바로가기였지만, 동시에 하이독스 포털의 가장 오래된 형태였다.
포털로 확장된 계기
단테 신곡 정리 작업을 시작하면서, 나의 작업을 연속적으로 이어서
할 작업장이 필요하게 되었다. 하지만 이때 까지만 해도 하이독스를 건들 생각은
하지 않았다.
그런데, 실생활에서 나의 업무 패턴을 보니 너무 반복작업이 많았다. 이 반복을 줄이기 위한 시스템이 필요하게 되었다.
그래서, 기존의 하이독스를 재건축하기로 마음먹었다. 하나의 작업장에서 나의 개인적인 업무와 실생활의 모든 업무를 처리할수 있게 하자. 그래서 하이독스는 점차 책의 문장, 업무 문서 등을 관리하는 포털의 형태를 갖추기 시작했다.
여기서 말하는 포털은 대형 포털을 그대로 흉내 낸다는 뜻이 아니다. 나에게 필요한 모든 입구가 한곳에 모인 장소를 뜻한다.
- 저장소로 들어가는 입구
- 도서관으로 들어가는 입구
- 표 편집기로 들어가는 입구
- 게시판을 통해 사람들과 대화를 나누는 광장 입구
처음에는 저장소 입구 하나뿐이었지만, 그 입구 하나가 지금의 포털로 확장되었다.
왜 단테 신곡이었나
단테 신곡 은 나에게 우연처럼 들어왔다가 중심이 된 책이다.
나는 오래전에 민음사판 단테 신곡 을 사두었지만, 오랫동안 읽지 못했다.
그 책은 책장에 남아 있었고, 전혀 읽을 생각이 없는 어려운 고전으로만 있었다.
그러다 시간이 지나 책을 읽어야 겠다고 마음먹었을 때, 가장 먼저 붙잡은
문학 작품이 단테 신곡 이었다. 이 책은 단순한 독서 대상이 아니라
오래 두고 되풀이해 다룰 수 있는 작업 대상이 되었다.
단테 신곡 을 선택한 이유는 하나로만 설명하기 어렵다. 처음으로
직접 사두었던 문학 고전이라는 개인적인 기억이 있었고, 지옥·연옥·천국으로
이어지는 큰 구조가 있었고, 원문과 번역과 발음과 해석을 나누어 다루기
좋은 문장 단위의 흐름이 있었다. 오래된 고전이라 공개 원문을 바탕으로
장기 작업을 이어가기에도 적합했다.
무엇보다 단테 신곡 은 하이독스가 단순한 저장소를 넘어설 수
있게 만들었다. 읽기만 하는 책이 아니라, 정리하고, 비교하고, 다시 쓰고, 노래로
바꾸고, 표와 도서관 구조로 관리해야 하는 책이 되었기 때문이다.
단테 신곡과 하이독스의 노래
하이독스가 단순한 자료 저장소를 넘어 포탈로 변한 계기는 단테 신곡
정리 작업이었다.
단테 신곡 은 단순한 독서 대상이 아니었다. 원문을 여러 단위로 정리하고,
번역, 발음, 주석, 실제 노래가 될 후보 문장을 함께 남겨야 하는
정리 작업의 대상이었다.
이 작업은 하이독스의 노래로 이어진다. 하이독스의 노래는 단순 번역문이 아니라, 이탈리아어 원문의 발음, 리듬, 흐름, 시적 형식을 참조하면서 한국어로 다시 만드는 고도의 창작 작업이다.
업무 보조로 확장
단테 신곡 정리와 하이독스의 노래 작업을 거치며 하이독스에는 원본
보존, revision 같은 구조가 생겼다.
이 구조는 다시 실제 업무를 보조하는 방향으로 확장되었다. 엑셀로 하던 업무기록표 작성, 수정, 비교, 문서 출력 흐름을 웹에서 보조하는 표 편집기가 필요해졌다.
따라서 하이독스의 업무 보조 기능은 별개의 기능이 아니라, 클라우드 저장소와 문학 자료 정리 작업에서 생긴 구조가 현실 업무로 이어진 결과이다.
Emacs Org가 선택된 이유
현재 하이독스 문서의 중심에는 Org가 있다. Org는 내가 아주 오래전부터 존재만 알고 있던 Emacs를 본격적으로 사용하게 만든 결정적인 이유이기도 하다. 처음에는 단순한 메모 형식처럼 보였지만, 써 볼수록 Org는 문서, 일정, TODO, 표, 실행 기록, 출판까지 품을 수 있는 작업의 바탕이라는 것을 알게 되었다.
Org의 가장 큰 매력은 단순한 텍스트 파일이라는 점이다. 내용은 사람이 바로 읽을 수 있고, 일반 편집기로도 열 수 있으며, 특정 서비스나 독자 포맷에 갇히지 않는다. 그런데 Emacs와 만나면 이 단순한 텍스트가 여러 방향으로 자라난다. 처음에는 메모였던 것이 TODO가 되고, TODO가 일정이 되고, 일정과 작업 기록이 문서가 되고, 그 문서가 다시 HTML 도움말과 릴리즈 노트로 출판된다.
내가 특히 감탄한 기능은 다음과 같다.
- 일정 관리를 문서 안에서 함께 다룰 수 있다.
- TODO 상태를
TODO,DONE같은 사이클로 바꾸며 작업 흐름을 관리할 수 있다. - 작업 메모, 판단 보류, 완료 기록을 한 파일 안에서 이어서 남길 수 있다.
- Python 같은 스크립트 언어를 문서 안에서 실행하고, 그 결과를 문서의 일부로 남길 수 있다.
- 표를 텍스트로 작성해도 Emacs가 열과 간격을 맞춰 보기 좋게 정렬해 준다.
- 제목 구조를 접고 펼치면서 큰 문서도 단계적으로 읽고 정리할 수 있다.
- 같은 원본을 사람이 읽는 문서, 작업 TODO, HTML 도움말, 운영 기록으로 확장할 수 있다.
대부분의 앱은 이런 기능을 독자적인 파일 포맷과 자체 저장소 안에서 해결한다. 그 방식은 편리하지만, 시간이 지나면 자료가 특정 앱 안에 갇히기 쉽다. 반대로 Org는 평범한 텍스트 파일을 유지하면서도, Emacs 안에서는 강력한 작업 환경이 된다. 이 점이 하이독스의 방향과 잘 맞았다.
하이독스는 원본을 훼손하지 않고, 수정 이력을 남기고, 도움말을 작성하고 릴리즈 노트를 관리하려 한다. Org는 이 흐름을 자연스럽게 받쳐 준다. 아직 정리되지 않은 생각을 붙잡고, 사용자에게 공개할 설명을 다듬고, 릴리즈 노트에서는 이미 반영된 변화를 남긴다. 이런 모든 나의 작업들이 하나의 Org문서 하나로 표현할 수 있다.
그래서 Org는 하이독스에서 단순한 문서 작성 도구가 아니다. 생각을 붙잡는 메모장이며, 작업을 굴리는 TODO 시스템이고, 표를 정리하는 도구이며, 도움말을 출판하는 원본이고, 나중에 왜 그렇게 만들었는지를 설명해 주는 운영 기록이다.
하이독스가 Org를 선택한 이유는 결국 하나로 모인다. Org는 단순한 텍스트에서 출발하지만, 필요할 때마다 일정, 작업, 표, 코드 실행, 도움말, 릴리즈 기록으로 확장된다. 그 확장성은 하이독스가 개인 작업에서 운영 가능한 포털로 자라나는 방식과 닮아 있다.