컨플루언스의 체크박스 기능은 함정이다

저는 위키 모양의 기록방식에 관심이 있습니다. 현대에 위키 모양의 기록 방식은 이 방식을 이렇게 별도의 이름으로 부를 필요가 굳이 없을 정도로 보편화되었다고 생각합니다. 문서를 시각적 관점 보다는 의미 관점으로 작성한 결과가 시각적으로 표시되도록 작성하고 표준화된 방법으로 문서 사이를 연결하며 문서에 동적 컨텐츠를 편리하게 포함할 수 있습니다. 과거 꽤 여러 프로젝트에서 전체 프로젝트를 지탱하는 문서를 생산하는데 마이크로소프트 워드를 사용한 적 있는데 처음에는 이게 얼마나 이상한 것인지 잘 몰랐습니다. 원래 문서라면 당연히 마이크로소프트 워드를 사용하고 이를 형상관리도구에 커밋해 여러 버전을 관리하거나 문서 맨 앞 부분에 날짜, 이름을 적고 무엇을 수정했는지 기록하는 페이지를 남기는 일이 이상하지 않다고 생각했습니다. 하지만 이런 모든 작업 하나하나는 문서 만들기를 점점 어렵게 만들었는데 이게 계속되는 야근으로 지쳤기 때문인지 이런 방법 자체가 문서 만들기를 어렵게 만들기 때문인지 판단하기 쉽지 않았습니다. 하지만 제대로 된 웹 기반의 위키를 통해 프로젝트 문서를 생산하게 되면서 이전에 마이크로소프트 워드로 프로젝트 문서 전체를 생산하는 일이 그렇게 힘들었던 이유는 그 일을 그 방식으로 사람에게 시키는 발상 자체가 잘못되었기 때문이라고 확실히 말할 수 있습니다.

웹 브라우저로 문서를 편집하는 위키 방식의 문서 작성은 일단 문서와 문서를 연결하는 표준 방법이 생겨 서로 간에 다른 경로를 걱정하지 않고 문서를 연결할 수 있게 해 주었습니다. 마이크로소프트 워드를 사용해 문서를 작성할 때는 다른 문서의 링크를 만들고 싶어도 이를 쉽사리 실행하기 어려웠는데 가장 큰 이유는 사람들마다 형상관리도구에 설정한 로컬 경로가 서로 달랐지만 워드는 이런 경로 차이를 곧이곧대로 링크에 반영해 한 기계에서 정상 동작하는 링크가 다른 기계에서는 없는 위치를 가리키기 십상이었습니다. 한동안은 온보딩 매뉴얼에 모두가 형상관리도구를 처음 설정할 때 같은 경로를 가리키도록 설정하는 것으로 어느 정도 문제를 완화할 수 있었지만 누군가는 스토리지가 부족해 새 스토리지를 연결하며 경로가 바뀌면 또 다시 모두가 사용하는 문서의 링크가 깨질 수밖에 없었습니다. 하지만 모든 문서가 웹 브라우저로 접근할 수 있는 웹 주소 모양이 되면서 근본적으로 이런 고민을 할 필요가 없게 됩니다. 모든 사람들은 자신의 로컬 경로와 아무 관계 없이 똑같은 웹 주소를 사용하게 됐고 이 주소를 연결하면 모든 사람들의 기계에서 똑같이 사용할 수 있습니다. 덕분에 연결을 좀 더 적극적으로 사용해 회의록 밑에 이전부터 시작해 오늘 이 회의록에 도달하게 만든 문서들 링크를 전부 붙여 둘 수도 있게 됐는데 만약 이전처럼 모든 문서가 파일 모양이고 각자의 서로 다른 로컬 경로에 저장되는 상황이었다면 이런 링크를 적극적으로 만들 수 없었을 겁니다.

또 문서에 동적 컨텐츠를 아주 편안하게 포함할 수 있게 됐습니다. 가령 여러 문서에 똑같이 포함되어야 하는 문단이 있을 수 있습니다. 게임에서 바닥에 뭔가를 배치해야 하는 상황을 생각해보면 바닥에 배치할 수 있는 물건의 형태는 여러 가지일 겁니다. 만약 디펜스 게임이라면 바닥에는 몰려오는 적들을 처치할 무기를 배치할 수 있어야 하고 또 도시를 만드는 게임이라면 여러 종류의 건물과 장식물을 배치할 수 있어야 합니다. 그런데 이들을 배치하는데는 항상 비슷한 체계와 규칙, 그리고 비슷한 인터페이스를 사용할 가능성이 높습니다. 이 모든 물체들을 항상 같은 그리드 시스템에 의해 정렬하고 또 항상 같은 회전 규칙에 의해 회전 시키는 등 비슷한 내용이 여러 문서에 걸쳐 나타나야 할 수 있는데 이들을 각 문서마다 매번 똑같이 말하는 것은 그리 좋은 아이디어가 아닙니다. 그렇다고 이 부분을 별도 문서로 분리해 링크로 연결해 놓으면 읽는 사람 입장에서 중간에 다른 문서를 함께 열어 놓고 봐야 하니 가독성이 떨어집니다. 이렇게 여러 문서에 같은 내용이 반복해서, 정확히 똑같이 등장해야 한다면 위키 문서에서는 이 부분을 다른 문서로 분리한 다음 분리한 문서를 현재 작성 중인 문서에 포함할 수 있는데 이 부분은 포함된 문서의 수정에 따라 바로바로 반영되어 가독성을 해치지 않으면서도 여러 장소에서 사용되는 내용을 항상 최신으로 유지할 수 있습니다.

전에 ‘회의록을 회의록끼리 모아두면 안돼요’라고 말한 적 있고 팀에서 회의록을 모아 두라고 만든 경로나 회의록을 만들 때 사용하라고 준비해 둔 템플릿을 효과적으로 무시하며 제가 옳다고 생각하는 아무 위치에나 회의록을 생성하고 있습니다. 분명 이런 걸 예쁜 모양으로 정리해 놓기를 좋아하는 누군가는 제 행동이 그리 탐탁찮을 것이 분명합니다. 물론 저 역시 회의록을 어느 한 장소에 모아 놓을 때가 있는데 바로 특정 기획서가 유발한 여러 회의를 그 기획서 하위 경로에 모아 놓는 것입니다. 그러면 회의록 상위에 있는 기획서나 그 하위에 있는 회의록 각각에 이들과 관련된 모든 회의록 목록을 각각의 문서 맨 아래의 참고 항목에 모아 놓고 싶을 때가 있는데 이 때 기획서 경로의 하위에 있는 모든 문서 목록을 나열하게 만들 수도 있습니다. 위키에서 이런 기능은 지정한 경로 하위에 있는 문서 목록이나 특정 조건에 맞는 문서 목록을 나열하도록 할 수도 있고 나열하는 단위를 하위에 있는 첫 번째 문서만 나열하거나 그들의 하위에 있는 문서가 있다면 이들도 가져다가 표시하도록 설정할 수도 있으며 문서 각각이 나열될 정렬 순서도 변경할 수 있습니다. 만약 비슷한 행동을 워드 문서로 하려고 하면 각각의 문서마다 링크를 하나하나 만들어야 하고 새로운 회의록이 추가될 때마다 이 경로를 포함해야 하는 모든 문서를 수정해야만 하는 귀찮은 일이 생겼을 겁니다. 이런 식으로 위키를 사용하기 시작하면서 문서 경로 문제가 영원히 일어나지 않을 뿐 아니라 문서 작성에 수고를 크게 줄여주는 동적인 요소를 자유롭게 넣을 수 있게 됩니다.

하지만 이런 변화를 모든 사람이 반기고 또 모든 사람이 빠르게 익숙해진 것은 아닙니다. 같은 회사 안에서도 어떤 프로젝트는 회사가 제공하는 컨플루언스를 사용하는 반면 어떤 프로젝트는 서기 2024년에도 여전히 마이크로소프트 워드에 문서를 작성하고 이를 퍼포스에 올려 가며 사용하고 있습니다. 요새도 간혹 구직을 위해 제출해 주신 문서를 검토하다 보면 아주 오래된 문서 형식으로 만들어진 마이크로소프트 워드 문서 앞부분에 한 페이지를 뒤덮는 표가 포함되어 있고 여기에는 누가, 언제, 무엇을 수정했는지 기록된 모습을 마주칠 때가 있는데 이런 문서를 보면 개인적으로는 일단 한숨부터 나옵니다. 서기 2024년에 이게 대체 무슨 닭짓거리인가 싶습니다. 그런 업데이트 테이블은 하나같이 초반에는 잘 관리되다가 뒤로 가면 전혀 관리되지 않기 일쑤이기 때문에 괜히 사람을 귀찮게 만들 뿐 아무런 의미도 없습니다. 하지만 아직도 이런 방식으로 프로젝트에 생산되는 모든 문서를 관리하기를 원하는 고위의사결정자들이 있고 실적을 내는 이상 이들의 취향을 존중하는 입장이지만 개인적으로는 별로 마주치고 싶지 않기도 합니다. 여러 가지 상황에 그럭저럭 잘 적응하는 스타일이라고 생각하지만 다시 마이크로소프트 워드로 프로젝트 문서 전체를 생산해야만 하는 상황과 마주하고 싶지는 않습니다.

한편 이전부터 위키를 사용해 모든 개인 기록을 만들어내면서 오랫동안 고민해 온 주제가 있습니다. 아주 오래된 위키에는 없었지만 적어도 지금 사용하는 컨플루언스와 그 직전에 사용하던 도쿠위키에는 있었던 체크박스 기능입니다. 체크박스는 한 페이지 안에서 간단히 체크박스 목록을 만들어 어떤 작업을 수행했는지, 아직 수행하지 않았는지 여부를 표시할 수 있도록 하기 위한 기능인 것 같아 보입니다. 만약 회의록을 작성할 때 액션 플랜이 도출되고 각각의 항목을 누가 수행해야 할지도 확정되었다면 종종 이 체크박스 목록을 이용해 액션 플랜을 나열하곤 합니다. 개인적으로도 위키 문서에 생각을 타이핑하다가 할 일을 도출하면 이들을 체크박스 목록으로 나타낸 다음 하나씩 체크 해 가며 진행 상황을 관리해 보려고 한 적이 있습니다. 그런데 위키 문서에 이런 부분을 작성하려고 할 때마다 이 부분을 체크박스 목록으로 나타내는 것이 올바른지 아니면 그냥 위키 문서로 작성한 다음 완료된 항목의 포멧을 취소선으로 변경하는 것이 올바른지는 고민거리입니다. 체크박스의 기능은 그저 체크박스를 체크하면 이 항목에 취소선이 그어지는 것 뿐인데 이는 위키 문서를 직접 편집해서 취소선을 긋는 것과 결과적으로 아무런 차이가 없기 때문입니다. 물론 체크박스를 클릭하기만 하면 알아서 이 항목 전체에 취소선이 그어지니 편리할 수도 있지만 위키를 사용해 온갖 문서를 작성하는데 익숙해지면 문서를 편집 모드로 전환해 취소선을 긋고 나서 저장하는 것이 체크박스를 클릭하는 것에 비해 그리 복잡하거나 귀찮게 느껴지지 않습니다.

도쿠위키를 사용하던 시대에는 그래도 있는 기능을 충실히 사용하는 것이 좋지 않을까 싶어 이런 상황에 체크박스를 즐겨 사용했습니다. 몇 년에 걸쳐 이 방식으로 할 일을 관리해 봤는데 결국 이 체크박스는 아주 짧은 단위 시간 동안 처리할 일을 기록하고 관리하기에는 적합하지만 단위 시간이 조금만 길어져도, 그러니까 한 번에 처리할 수 있는 범위를 초과하고 하루 단위를 넘어가는 순간 관리 불가능한 모양으로 바뀐다는 사실을 단지 저 혼자 사용하는 위키만으로도 충분히 경험하게 됩니다. 하루 동안 여러 가지 주제에 대해 위키를 사용해 생각하며 각각의 생각에 대한 여러 페이지를 만들었고 각각의 페이지에는 이 페이지의 생각 끝에 제가 해야 할 일 몇 가지 씩을 체크박스 모양으로 만들어 놓았습니다. 그런데 이 체크박스는 그저 포멧을 변경하는 기능 이외에는 아무런 역할도 하지 않기 때문에 그 날 안에 체크박스에 기입한 항목을 모두 처리하지 않으면 그 다음부터는 체크박스 모양으로 나열했지만 체크되지는 않은 여러 항목을 추적할 수 없게 됩니다. 물론 각각의 문서를 매일 검토하며 아직 취소선을 긋지 않은 체크박스를 찾아 다니며 이들 하나하나를 수행할 수도 있겠지만 근본적으로 위키는 계속해서 문서가 늘어나며 이전에 작성했던 문서는 그 수명이 빠르게 끝나며 이와 함께 그 내용이 쉽게 낡을 수 있습니다. 이런 상황에서 이전에 작성한 여러 문서에 걸친 체크박스를 하나하나 챙기는 것은 아주 어려웠고 꽤 오랫동안 이런 방식으로 할 일을 관리하려고 시도하며 할 일을 수행하는 것 보다 할 일을 관리하고 아직 취소선을 긋지 않은 체크박스가 남아 있는지 찾아 다니는 일 자체가 너무나 고통스러웠습니다.

저와 비슷한 문제를 겪고 있던 도쿠위키 커뮤니티의 개발자들이 여러 페이지를 스캔해 각 페이지에 있는 체크박스들을 한 곳에 모아 보여주고 이 곳에서 바로바로 각 페이지에 흩어져 있는 체크박스를 제어할 수 있게 해 주는 플러그인을 개발하기도 했습니다. 이런 플러그인은 앞서 위키에 문서를 작성하면서 사용할 수 있게 된 동적 요소와 같은데 이런 플러그인 덕분에 오래 전에 문서를 작성할 때 수행해야 한다고 생각해 만들어 뒀지만 이후 버려진 수많은 체크박스들이 아직 완료되지 않은 상태로 문서 곳곳에 남아 있다는 사실을 알게 됩니다. 하지만 이들 대부분은 이미 시일이 지나 이미 수행했지만 체크하지 않았거나 이제는 체크하든 안하든 의미 없게 된 것들이 많았습니다. 또한 각 체크박스 항목들은 이들을 포함한 페이지에서는 각각의 맥락을 쉽게 인지할 수 있지만 체크박스 항목만을 한 페이지에 모아 페이지와 체크박스를 분리한 환경에서 보면 그 맥락을 쉽게 알 수 없는 경우도 있었습니다. 가령 다음 주에 출근해 작성하기 시작해야 할 어떤 기획서에 대해 주말에 개인 위키에 타이핑하며 생각하다가 ‘무슨무슨 게임을 플레이 해 보자’라고 기입한 체크박스 항목을 만들었다면 이 항목이 포함된 페이지와 이 체크박스 항목을 함께 보면 이게 무엇 때문에 해야 하는 일인지 맥락을 쉽게 파악할 수 있습니다. 하지만 별도 페이지에서 체크박스 항목만 모아 놓고 살펴보면 왜 뜬금없이 이 게임을 플레이 해 봐야 하는지 이해할 수 없을 수 있습니다. 세상의 누군가는 기억력이 좋아 페이지와 그 페이지에 포함된 체크박스 항목 사이의 맥락을 제거한 상태에서도 각각의 목적을 잊지 않을 수 있을지 모르지만 저는 그렇지 않았습니다.

결국 할 일은 별도로 지라를 사용하기 시작해 이후 지금까지 완전히 굳어졌고 위키 역시 도쿠위키에서 컨플루언스로 바꾼 다음 현재에 이르렀습니다. 이 사이에 일어난 할 일 관리에 가장 큰 변화는 여전히 컨플루언스 위키에 문서를 작성하고 이 문서로부터 어떤 할 일을 도출하면 이들을 체크박스 목록으로 만드는 대신 바로 지라 태스크로 만들어버리는 것입니다. 문서 모양은 이전과 별로 다르지 않습니다. 문서 내용이 이어지고 문서 중간, 혹은 끝부분에 지금까지의 내용에 따라 제가 수행해야 하는 일이 지라 태스크 목록으로 중간 중간에 끼어들어 있습니다. 어느 때는 지라 태스크 여러 개가 이전에 체크박스 목록을 나열할 때처럼 나열되어 있기도 합니다. 겉보기에는 이전과 크게 다르지 않지만 차이는 이제부터입니다. 이 목록을 지라 쪽에서 보면 마치 이전에 체크박스를 스캔해 한 페이지에 모아 놓았던 페이지와 비슷해 보이지만 지라에서는 이들을 칸반보드 모양으로 표시할 수도 있고 또 지라 태스크 항목 각각은 그 내용에 자신이 어느 컨플루언스 페이지에 포함되어 있는지 자동으로 기록되기 때문에 도쿠위키에서 체크박스를 한 페이지에 모아 놓은 상태에서 맥락을 파악하기 어려웠던 것과 달리 각 태스크의 맥락을 순식간에 파악할 수 있습니다. 또한 각 태스크 별로 진행 상황을 지라 쪽, 그리고 컨플루언스 쪽에서 똑같이 바로바로 파악할 수 있고 일의 진행을 컨플루언스 문서에 기입할 수도 있지만 지라 태스크 그 자체가 자기 자신에 내용, 답글을 기록할 수 있어 문서와 분리된 위치에 태스크 각각의 진행 메모를 남길 수도 있게 됩니다.

가령 저는 지금 이 글의 초안을 컨플루언스 위키에 작성하고 있는데 이 글을 작성하는 행동 자체가 지라 태스크를 통해 이미 정의되어 있습니다. 이 지라 태스크를 문서 맨 위에 붙여 놓고 글을 작성하는데 지라 쪽에서 보면 이렇게 글 각각을 작성해여 함을 나타내는 태스크를 칸반보드 모양으로 모아 볼 수 있고 태스크 각각에는 자동으로 이 글을 작성하는 컨플루언스 페이지가 연결되어 있고 또 글 작성 과정에 추가적으로 할 일 따위를 답글 모양으로 기록할 수도 있어 문서로부터 태스크를 도출하고 문서에 태스크를 포함해 놓았지만 이들이 서로의 맥락을 제거한 상태로 표시되더라도 여전히 이들 각각의 맥락을 쉽게 유지할 수 있습니다. 만약 이런 항목을 체크박스 모양으로 만들어 놓았다면 체크박스의 문서가 같은 위치에 나열될 때는 이들의 맥락을 당연히 파악할 수 있겠지만 이들이 각각 서로 다른 목록에 나타나는 순간 이들의 맥락을 따라잡기는 아주 힘들고 또 단순 체크박스는 그 진행을 기록할 방법을 가지고 있지도 않아 체크박스의 태스크를 수행하며 발생한 새로운 기록은 이를 위한 또 다른 위키 페이지를 만들거나 처음 이 체크박스를 발생 시킨 페이지에 그런 내용을 추가해야만 할 수도 있습니다. 이 방법이 틀렸다고 보기는 어렵고 또 이런 방식이 어떤 측면에서는 업무의 진행을 기록하기에 적절할 수 있지만 이런 고민을 해야 하는 상황 자체가 마음에 들지 않습니다. 그래서 지금은 컨플루언스 위키에 문서를 작성하고 문서 작성 중 제가 할 일이 발생하거나 반대로 어떤 할 일에 의해 문서를 작성하게 되면 반드시 이들을 위키가 제공하는 체크박스 기능 대신 지라 태스크를 사용해 기입하고 있습니다.

한번은 큰 프로젝트에서 회의록 문서의 액션 플랜 항목을 체크박스 모양으로 기입하고 있는 모습을 봤고 지금까지 이런 고민을 해 온 저는 보나마나 이 체크박스들이 전혀 관리되고 있지 않으리라 짐작했습니다. 회의록 몇 개를 열어 보니 여지 없이 체크박스들은 그저 기입 되어 있을 뿐 관리되지 않고 있었고 1년 전, 2년 전에 만들어진 체크박스 역시 이들 중 극히 일부만 취소선이 그어져 있을 뿐 관리되지 않고 있었습니다. 아주 쉬운 접근 방법은 이 각각의 문서에 체크박스를 만들어 놓고 이를 관리하지 않는 문서 작성자들에게 책임을 묻는 것입니다. 문서 작성자들이 게으르고 부주의했기 때문에 액션 플랜에 기입한 체크박스를 끝까지 책임 지지 않았다고 정의하고 이들을 무책임한 사람들로 몰아 붙이면 일시적으로 다시 체크박스 관리가 잘 되는 기적적인 효과를 볼 수 있습니다. 하지만 이는 이렇게 될 수밖에 없는 상황을 만들어 놓고 그저 사람들을 다그쳐 결과를 만들어낼 뿐이어서 똑같이 일시적으로는 동작하겠지만 시간이 조금만 지나면 다시 이전과 같은 상태로 돌아가거나 구성원들의 사기를 크게 떨어뜨려 충분한 경험을 가진 사람들이 프로젝트로부터 이탈하게 만드는 원인으로 작용합니다. 또 다른 접근에는 앞서 도쿠위키 사례에서 소개한 체크박스들을 한 곳에 모아 관리하는 방법인데 이 방법 역시 저 혼자 문서를 만들고 저 혼자 할 일을 관리하는 상황에서조차 효과적이지 않다는 사실을 소개했습니다.

이 상황으로부터 근본적으로 빠져 나갈 방법은 컨플루언스의 체크박스 기능은 그저 오래 전부터 그런 기능이 있어 왔기 때문에 아직도 남아 있는 기능으로 할 일을 관리할 수 있을 것처럼 보이지만 실제로는 전혀 그렇지 않은 함정으로 인식하고 이를 아예 사용조차 하지 않는 것입니다. 컨플루언스 위키의 체크박스 기능은 아무 기능도 아니며 그냥 문서 편집 모드로 진입하지 않고서도 미리 정해진 위치에 취소선을 그리는 기능 이상도 이하도 아니라고 생각해야 합니다. 대신 어지간한 컨플루언스를 사용하는 프로젝트에서는 당연히 지라를 함께 사용하고 있을 겁니다. 이 경우 처음부터 프로젝트 전체에 걸쳐 우리들이 수행해야 하는 모든 태스크는 지라를 통해 관리하기로 모든 프로젝트 구성원들 사이에 약속 되어 있고 또 경우에 따라 태스크를 관리해 목표 수행의 위험성을 평가하고 이를 제거하는 업무를 수행하는 별도 직군이 있을 수 있습니다. 처음부터 우리들은 할 일을 지라를 통해 관리하고 있었던 겁니다. 그렇다면 회의록의 액션 플랜 항목은 함정 기능인 컨플루언스 위키의 체크박스 대신 그 각각을 지라 태스크로 만들어 기입하기만 하면 이 모든 문제를 꽤 잘 해결할 수 있습니다. 회의록에 기입된 지라 태스크는 체크박스와 마찬가지로 회의록의 짧은 수명 동안 유지된 다음 잊혀지겠지만 이들을 지라 쪽에서 보면 여전히 사라지지 않고 누군가는 해야 할 일로써 남아 있고 이들이 발생한 회의록의 수명과 무관한 수명을 유지하며 완료 될 때까지 지라에 계속해서 남아 있게 됩니다. 이 상황에서 누구도 무책임해질 필요가 없습니다. 기계가 그 역할을 대신 해 주는 이상 사람은 그저 각 태스크가 가리키는 업무를 수행하기만 하면 됩니다.

그래서 개인적으로 컨플루언스 위키에 있는 체크박스 기능은 기능이 아니라 일종의 함정이라고 평가합니다. 마치 어떤 할 일을 관리할 수 있을 것처럼 보이지만 실제로는 전혀 그럴 수 없습니다. 체크박스에 근거한 업무가 진행되지 않는다 하더라도 이는 개인의 무책임이나 무관심의 산물이 아닙니다. 애초부터 사람은 그렇게 생겨 먹었지만 그런 사람의 특징을 무시하고 만들어진 아주 오래된 관리 방법일 뿐이며 지라가 존재하는 현대에는 이는 관리 방법이라고도 할 수 없습니다. 컨플루언스 위키를 사용하는 거의 모든 팀에서 태스크 관리에 지라를 사용하고 있는 이상 위키 페이지로부터 발생한 작은 태스크가 체크박스 같은 추적 되지 않는 이상한 모양으로 존재해서는 안됩니다. 이들은 지라 모양으로 관리되어야 하고 일단 지라 모양으로 관리되는 이상 그 누구도 무책임해지거나 쓸데 없이 과도한 관리 로드를 짊어질 필요가 없습니다. 컨플루언스 위키의 체크박스 기능은 절대 사용해서는 안됩니다. 이는 현대에 함정에 불과합니다.