스타일 기반의 문서작성

적어도 제가 보고 있는 인터넷 상의 타임라인에는 대략 반 년 정도 쿨타임이 찰 때마다 국내에 가장 널리 사용되는 것처럼 보이는 두 가지 위지윅 워드프로세서에 대한 이야기가 돌아오곤 합니다. 한글 워드프로세서는 한글을 입력하고 한국에서 문서를 만들고 사용하는데는 더할나위 없이 훌륭한 도구이지만 그 문서를 여러 사람들에게 공유하고 정보를 주고 받는 데는 별로 훌륭하지 않은 것 같아 보입니다. 이런 도구를 공공기관이나 학교에서 적극적으로 사용하고 문서를 필요로 하는 모든 사람들이 같은 도구를 사용하고 있으리라고 가정하는 자세가 여러 사람들을 불편하게 만들고 있습니다. 불편하다고 하면 문제가 작은 것 처럼 보이는데 사실상 정보 접근을 제한하고 있다고 봐야 합니다.

한편 마이크로소프트 워드 워드프로세서는 수 십년 전에는 모든 한글을 입력할 수 없었고 또 한국에서 요구하는 복잡한 수식이나 표를 만들기 어려워 널리 선택되지 않았지만 이 문서를 여러 사람들에게 공유하고 정보를 주고 받는 데는 상대적으로 더 나아 널리 사용되기 시작했습니다. 특히 워드를 구입할 때 함께 따라오는 엑셀과 파워포인트가 워낙 강력하고 또 각각의 용도에 가장 널리 사용되는 소프트웨어여서 워드 역시 충분하지는 않지만 자연스럽게 비슷한 지위를 얻게 됩니다.

처음 일을 시작하면서 문서 작성에 워드를 사용했는데 시간이 흐르면서 점차 워드 대신 전통적인 위키나 좀 더 현대적인 도구인 컨플루언스나 노션을 사용하게 되었습니다. 문서를 워드로 작성하던 프로젝트에서는 처음에는 여러 사람에게 문서를 편리하게 공유하기 위해 ‘공유디렉토리’에 문서를 넣어 두고 여러 사람이 동시에 편집하게 했었습니다. 한동안은 잘 동작하는 것 같았지만 누가 뭘 수정했는지, 또 문서를 누가 편집 중인지 잘 파악하기 어려웠고 또 누군가 실수로 혹은 고의로 문서를 수정하거나 삭제하면 문제가 생겼음을 인식하는데오래 걸린 나머지 문제를 해결하기 아주 어려웠습니다. 이는 백업이 있어도 마찬가지였는데 백업은 최악의 상황에 대응할 수단일 뿐 일상적인 실수에 대응하기는 어려운 방법이었습니다.

다른 조직에서는 여전히 워드로 문서를 작성했지만 문서를 형상관리도구에 등록하게 했습니다. 소스세이프라는 형상관리도구를 사용했는데 그 시대에는 형상관리도구 자체가 문제를 일으켜 사람들의 신뢰가 그리 높지 않은 상황이기도 했습니다. 하지만 문서 파일의 여러 버전을 볼 수 있고 각각의 버전을 누가 수정했는지 알 수 있으며 이전 버전으로 돌아갈 수 있다는 점은 공유디렉토리에 비해 훨씬 편안하고 또 안전하다고 느꼈습니다. 물론 누군가는 문서를 저장한 다음 다시 어딘가에 올려야 하는 과정이 불편하다고 하소연 하기도 했지만 이런 단점은 장점이 덮고도 남았습니다.

어느 프로젝트에서는 도쿠위키를 사용했는데 위키 사용에 익숙한 사람들에게는 별 문제 없는 당연한 환경이었지만 또 다른 사람들에게는 굉장히 불편하고 또 이해할 수 없는 편집 환경이었습니다. 링크를 만들 때, 테이블을 만들 때 위키 문법을 사용해야 했는데 위키 문법에 익숙해지는 것은 둘째 치고 위키 문법이라는 것이 존재한다는 사실을 납득하기 어려워 하기도 했습니다. 또한 게임 개발의 특성 상 문서에 이미지를 사용할 일이 아주 많았는데 매번 이미지를 위키 문법을 사용해 문서에 첨부하기도 힘들었고 또 큰 이미지 여러 장을 잘 처리하지도 못해 결국 공유디렉토리에 있는 원노트로 대체되었습니다.

시대가 지나며 큰 회사의 큰 프로젝트에 참여했더니 거기서는 컨플루언스 위키를 사용하고 있었는데 이전에 사용하던 위키와 가장 크게 다른 점은 위지윅 환경을 제공한 것입니다. 나중에서야 컨플루언스의 위지윅 환경이 전통적인 위키 사용자들로부터 비판 받은 적이 있음을 알게 됐지만 프로젝트에 참여하는 여러 사람들이 편안하게 사용하려면 그 정도 문제는 감수해야 한다고 생각합니다. 그 시대의 컨플루언스는 지금에 비하면 상당히 덜떨어진 편집 환경을 제공했지만 이전에는 문서가 ‘파일 하나’ 단위로 구분되었다면 이제는 컨플루언스 사이트 전체의 문서가 마치 거대한 문서 한 덩어리처럼 링크를 적극적으로 사용해 연결되기 시작합니다. 또한 이전 시대에 워드로 문서를 작성할 때와 비슷하게 문서를 저장하면 그걸로 끝이었고 어딘가에 다시 올리는 동작이 없어져 이를 편안하게 느끼는 사람들이 늘어났고요.

워드가 온라인 위키 형태로 바뀌면서 일어난 가장 큰 변화는 문서를 스타일에 따라 작성하도록 강제 되기 시작한 것입니다. 전통적인 워드프로세서에도 ‘스타일’ 기능이 있기는 하지만 워드프로세서를 처음부터 사용하던 사람들은 워드프로세서가 글자에 폰트 종류와 크기, 줄간격 등을 조절해 눈에 보기 좋은 문서를 만드는 과정으로 인식하는 경우가 많았습니다. 아주 오래 전에 관련 자격증이 있었는데 이 자격을 얻기 위한 실기 시험도 결국 눈으로 보기에 좋은 문서를 만드는데 집중되어 있었습니다.

하지만 문서를 구조화된 정보로 인식하면 문서는 눈으로 보기 위한 것이 아니라 정보를 보관하고 정보에 더 편리하게 접근하며 정보가 변경될 때 이를 빠르고 편리하게 편집하기 위한 수단에 가깝습니다. 이 관점에서 문서를 구성하는 여러 단계의 제목과 본문, 표와 그림은 정보를 구성하는 여러 방법 중 하나로 각각의 방법에 맞는 형식으로 표시하고 보기 좋은 문서라는 관점에서 정보를 체계에 따라 나열한 다음 체계 자체에 시각적 효과를 부여해 사람에게 익숙한 보기 좋은 문서를 만드는 과정입니다.

오래 전부터 워드프로세서를 사용하던 분들은 ‘스타일’ 기능이 생긴 다음에도 익숙한 방법으로 제목마다 직접 폰트 종류와 크기를 바꿔 가며 문서를 만들었고 이는 문서를 읽는데는 의미 있었지만 이 를 정보로 접근할 때는 문제가 많았습니다. 가령 문서를 웹으로 옮기거나 다른 형식으로 변환할 때 항상 시각적으로 같은 모양으로 만들 수밖에 없었습니다. 그래서 종종 문서를 웹에 공유할 때 텍스트 대신 이미지로 공유하기도 했는데 이는 문서 작성을 시각적으로 접근해서 생긴 어쩔 수 없는 결과입니다.

하지만 전통적인 위키와 현대적인 컨플루언스나 노션 모두 이런 전통적인 문서 작성 방법을 아예 제공하지 않습니다. 제목과 본문을 구분하고 싶으면 제목은 제목이라고 설정하고 본문은 본문이라고 설정하는 방법 밖에 없습니다. 그러면 제목과 본문은 위키에서 원래 제공하는 시각적인 형태를 강제로 따르는데 이 결과는 이전에 제목과 본문을 사람이 구분해 폰트 크기를 조절한 결과와 크게 다르지 않습니다. 이 강제 과정을 통해 자연스럽게 문서는 이전의 시각적 형태에서 체계를 갖춘 정보 형태로 변했습니다.

하지만 자연스럽게 변한 것은 아닙니다. 여전히 누군가는 제목 단계에 관계 없이 중간에 빨간 글씨나 큰 글씨를 입력하고 싶어했고 이를 허용하지 않는 위키를 불편해 하기도 했습니다. 또 지금도 제목 아래에 의미 없는 <hr />을 넣으며 없는 서식을 만들어내려는 시도가 보이기도 하는데 한동안은 이런 시도에 적극적으로 개입하곤 했지만 이 정도는 아무 것도 하지 않고 넘어갈 만한 그냥 웃긴 에피소드 정도로 받아들이고 있습니다.

최근에 팀 동료님과 밥을 먹다가 프로젝트에서 문서 도구로 노션을 사용하기 시작하면서 문서의 서식 보다는 문서 자체에 집중할 수 있게 되어 불편한 점도 있지만 또 좋은 점도 있는 것 같다는 말씀을 들었습니다. 사실 불편한 점이 뭔지는 대략 알 것도 같았습니다. 아무리 시간이 지나도 마음속 깊이 자리잡은 체계와 관계 없이 글자에 색상을 넣고 또 크기를 크게 하고 싶으며 표에 그림을 넣고 싶고 정렬을 바꾸고 싶을 겁니다. 이런 행동은 문서의 체계를 정의하고 유지하는데는 어울리지 않지만 개인이 문서를 통해 의사를 표현하려고 할 때는 어쩌면 단점이 될 수도 있을 겁니다. 하지만 서식에 집중하지 않고 문서 자체에 집중하고 문서를 통해 설명하려는 대상 자체에 집중하기 시작하면 그 결과는 훨씬 체계적으로 잘 정리된 문서가 됩니다.

개인적으로는 적어도 ‘문서’는 이런 제약을 가지고 작성하는 방향이 옳다고 생각합니다. 전통적인 시각적 접근은 ‘문서’보다는 파워포인트 프리젠테이션에 더 가깝다고 생각하며 문서 중간에 그런 요소를 추가해야 한다면 그건 전통적인 워드프로세서나 위키의 영역 밖의 일로 봐야 합니다. 핵심은 전통적인 자유로운 표현이 잘못된 것이 아니라 그런 표현은 그걸 더 잘 하는 전문적인 도구에 맡기고 문서는 문서 본연의 역할에 집중하자는 것입니다.

결론. 개인적으로는 전통적인 워드프로세서가 어느 시점에는 위키처럼 서식을 강하게 제한 받는 편집 모드가 도입되어 근본적으로 위키 편집기와 비슷한 모양으로 변해야 하지 않을까 싶습니다. 서식 제어 기능에 제한을 받는 사례에는 아웃룩 편집기나 원노트 편집기가 있고 이들의 동작은 방금 이야기한 제약과 상당히 비슷합니다. 문서는 과거의 시각적인 문서 작성에서 체계 기반으로 작성하며 내용에 집중하는 작성 방식으로 변할 겁니다.