위키 글 제목에 (작성중)이라고 쓰면 안 되는 이유

지난 개인 위키로 컨플루언스 추천해요 (2024)와 컨플루언스 위키의 단점에서 개인 수준에서 위키를 적극적으로 오랜 기간에 걸쳐 사용하고 또 유지하는 분들을 찾기 쉽지 않다는 이야기를 했습니다. 그렇다고 위키를 사용하는 분들이 적은 것은 결코 아닐 수밖에 없는데 여러 회사가 회사 정보시스템으로 위키 모양의 도구를 사용하고 있기 때문입니다. 여러 사람들이 그들 스스로 위키위키 모양의 도구를 사용하고 있다는 사실을 직접적으로 인지하지 못할 수 있지만 사실은 꽤 많은 사람들이 회사의 정보시스템을 사용하며 위키를 사용하고 있고 위키의 여러 가지 기록 방식에 자신도 모르는 사이에 익숙해져 있을 가능성이 높습니다. 제가 일하는 분야에서는 여러 회사들이 컨플루언스 위키를 도입하고 있는데 이 제품을 사용해 여러 정보를 기록하고 또 다른 사람이 만든 정보를 찾아 업무를 수행하다 보면 자연스럽게 초기 위키위키가 지향하던 방식으로 일하고 있다는 사실을 알 수 있습니다.

다만 그런 방식을 개인 수준까지 가져오는 사람들은 그리 흔하지는 않아 보입니다. 기록에 대한 요구사항을 가지고 있으면서도 위키 모양의 도구를 사용할 생각을 잘 하시지 않는 분들과 이야기해 보면 회사에서 접한 위키는 그 규모가 너무 커서 개인 수준에서 그렇게 거대한 정보시스템 혹은 그 정보시스템의 근본인 위키위키 방식을 굳이 개인적인 수준에 사용해야 할 지 판단하기 어려워 하시곤 합니다. 물론 저는 항상 위키 모양의 기록 방식을 추천하고 또 컨플루언스 위키를 개인이 사용하는 것을 추천하는데 한국에서 사용할 수 있는 완전관리되는 위키를 2024년 현재 부가세 포함 월 12.71달러에 사용할 수 있는 서비스 중 가장 훌륭하기 때문입니다. 뜬금없이 여기서 또 영업하자면 개인이 사용하기에 컨플루언스 클라우드 정말 좋습니다.

한편 회사는 우리들에게 컨플루언스 위키를 던져줄 뿐 이를 활용하는 방법은 전적으로 각 부서들이 결정하도록 하기 때문에 프로젝트에 따라, 부서들마다, 또 개인들마다 위키를 사용하는 방식은 찬차만별입니다. 어떤 부서에서는 개인 공간에서 문서를 작성한 다음 문서가 완성된 다음에서야 개인 공간 밖으로 꺼내는 정책을 사용하기도 하고 또 다른 부서에서는 처음부터 프로젝트 공간에 문서를 작성하도록 하기도 합니다. 어떤 프로젝트에서는 위키에 회의록을 작성하되 회의록을 모아 놓는 공간에 작성하도록 하는 반면 또 다른 프로젝트에서는 회의록을 회의록끼리 모아두면 안돼요에 이야기한 대로 회의록이 있어야 할 눈에 잘 띄는 장소에 작성해도 아무 말도 하지 않기도 합니다. 애초에 위키위키는 문서를 수정할 때마다 그 문서의 이전 모든 버전을 저장하기 때문에 실수를 두려워하지 않고 거리낌 없이 문서를 수정할 수 있지만 이전에 파일시스템에 문서를 작성하던 습관을 그대로 유지하며 문서에 큰 변경을 가할 때마다 이전 문서를 그대로 두고 새 문서를 작성하기도 합니다. 처음에는 이런 사용 형태가 위키위키 관점에서 아주 이상하다고 생각했는데 또 곰곰이 생각해보니 어떤 문서들은 히스토리에서 서로 다른 리비전을 열어 놓고 살펴보는 것 보다 그냥 두 가지 최신 버전을 동시에 살펴볼 수 있도록 하는 편이 더 나은 상황일 수도 있겠다는 생각이 들었고 그 다음부터는 별로 이상하다고 생각하지 않기로 했습니다. 또 누군가는 계층형 위키를 쓰며 느끼는 관리방법의 충돌에 언급한 대로 계층구조를 별로 신경 쓰지 않고 문서를 작성하기도 하지만 또 다른 누군가는 컨플루언스 위키의 계층구조 기능을 적극적으로 활용해 관련된 문서를 계층에 따라 잘 정리해 놓기도 합니다. 개인적으로는 위키위키의 초기 방식에 따라 계층구조를 신경 쓰지 않는 입장이었지만 이런 사용을 ‘정리하지 않는 문서 작성’이라고 인식하는 분들의 요구사항을 달성하고 또 계층을 통해 문서의 온도를 관리하는 방식을 사용하기 시작했는데 이는 나중에 소개해 보겠습니다.

한편 이런 다양한 위키 사용 방법 중 가장 제 관심을 끈 것은 단연 계층형 위키를 쓰며 느끼는 관리방법의 충돌이지만 그 다음으로 제 관심을 끈 사용 방법은 문서 제목에 ‘(작성중)'이라고 표시해 이 문서가 현재 완료되지 않았음을 표시하는 것입니다. 이런 경향은 앞서 개인 공간에 문서를 작성한 다음 작성을 완료한 시점에 프로젝트 공간으로 문서를 옮기는 정책이 있는 프로젝트에서는 눈에 띄지 않지만 처음부터 프로젝트 공간에 문서를 작성하기 시작할 때 일어날 수 있는 실수를 줄이는 효과가 있습니다. 가령 기획팀에서 처음 작성하기 시작한 어떤 문서는 아직 문서를 작성하는 개인이나 이 개인이 속한 팀만의 의견을 반영한 상태일 수 있습니다. 아직 팀이나 프로젝트 관점에서 검토되지 않았기 때문에 달성 불가능하거나 지금까지 개발된 빌드의 여러 부분과 맞지 않는 요구사항을 언급하고 있을 수 있습니다. 아마도 이 문서는 여러 단계의 논의와 컨펌 과정을 거쳐 협업 부서들이 읽을 만한 요구사항을 포함한 모양으로 바뀌어 갈 겁니다. 하지만 이 과정에는 시간이 걸리고 이 과정이 수행되기 전 우연히 문서를 먼저 읽은 협업 부서 사람들이 기획팀이 완전 이상한 생각을 하고 있음에 당황하거나 감정적으로 대미지를 입고 기획팀에 대한 신뢰를 잃어버릴 가능성도 있습니다. 당연히 우리들은 그런 결과를 만들 생각이 없고 이를 위해 여러 단계의 논의 및 컨펌 과정을 수행하고 있습니다. 하지만 이런 단계의 진행을 모르는 팀 바깥에 있는 협업 부서들은 당장 문서에 적힌 미친 소리를 보고 당황할 수밖에 없고 이는 별로 이상하지 않습니다.

아마도 협업 부서의 누군가는 아직 완결되지 않은 문서의 이상한 내용을 보고 이에 대한 질문을 할 겁니다. 그리고 이 질문은 여러 사람을 거치는 사이에 그 규모가 처음 예상한 것보다 훨씬 커져 그저 기획팀에서는 작은 편의 기능 하나를 검토하고 있었을 뿐인데 그 다음 주에 진행된 고위 의사결정자들이 모인 회의에서 기획팀에서 빌드 전체를 다시 개발할 생각을 하고 있다는 것이 사실이냐는 질문을 받을 수도 있습니다. 바보같다고 생각할 수 있지만 충분히 일어날 수 있는 일이고 또 실제로 이 정도 상황이 일어나기도 합니다. 이 정도는 아니더라도 누군가는 실제 자신이 읽어야 하는 올바른 요구사항이 기입된 문서를 읽는 대신 그와 비슷한 내용이 적혀 있는 잘못된 요구사항이 기입된 문서를 보고 작업을 수행해 잘못된 결과를 도출할 가능성도 있고 실제로 이런 문제가 일어나기도 합니다. 이런 여러 가지 사건을 겪고 나면 작성 중인 문서는 일단 컨플루언스의 개인 공간에 작성한 다음 작성이 완료된 다음 프로젝트 공간으로 이동하거나 아직 작성 중인 문서에는 제목에 ‘(작성중)’이라는 문구를 추가해 문서를 보는 누군가가 아직 완성되지 않은 문서를 보고 당황하지 않도록 하는 조치를 취하곤 합니다. 컨플루언스 클라우드 버전을 기준으로 컨플루언스 위키에는 문서의 상태를 표시하는 기능이 있습니다. 이전에는 문서의 상태를 지정하는 기능이라기 보다는 그저 무언가의 상태를 정의하고 표현하는 매크로가 있긴 했지만 이는 다른 데이터와 상호작용해 동작한 결과가 아니라 그저 페이지에 글자색을 바꿔 주는 역할을 하는데 그쳤기 때문에 이 상태 표시 매크로를 잘 활용하는 사례를 거의 못 봤습니다. 하지만 컨플루언스 클라우드 버전에는 문서의 여러 상태를 정의하고 문서마다 각각의 상태를 지정하며 문서의 상태를 여러 가지 방법으로 바꾸면 이 상태가 문서에 직접 표시되는 방식으로 바뀌어 꽤 사용할 만한 모양이 되었습니다.

아틀라시안 웹사이트에서 문서 상태를 사용하는 사례를 찾아보면 초안 상태, 팀 내 컨펌 상태, 대기 상태, 개발 진행 상태, 취소된 상태 등 다양한 상태를 만든 다음 문서의 실제 진행에 따라 상태를 바꿔 문서를 열어볼 때 이 문서가 현재 어떤 상태인지 직관적으로 확인할 수 있습니다. 이는 마치 지라에서 미리 정의한 워크플로우에 따라 태스크 상태를 바꿔 가는 것과 비슷합니다. 처음 만든 태스크는 ‘Todo’ 상태에 있다가 누군가가 이 작업을 진행하기 시작할 때 ‘In Progress’ 상태로 바꾸고 작업이 완료되면 ‘Done’으로 바꿔 태스크가 완료되었음을 선언하는 동작과 아주 비슷합니다. 실제로 컨플루언스의 페이지 상태 기능은 지라의 태스크상태 기능과 아주 비슷해서 지라와 컨플루언스를 동시에 사용할 때 문서 작성 진행 상황을 어떻게 표시할지 정책을 고민하게 만듭니다. 만약 문서를 작성하는 작업을 지라로 나타냈다면 지라 태스크 상태에 따라 문서가 초안 상태인지, 팀 내 컨펌 및 이터레이션 상태인지, 다른 협업 부서에 공유되어도 되는 상태인지 따위를 지라 워크플로우를 정의해 이에 기반해 나타낼 수 있습니다. 하지만 동시에 컨플루언스 문서 자체에도 문서의 상태를 정의하고 상태를 바꿀 수 있으며 이 상태는 문서에 더 직관적으로 표현되기 때문에 문서에 지라 링크를 포함해 지라 상태가 보이게 만들지 아니면 문서의 현재 상태를 컨플루언스 문서 상태로 표현할지 고민할 수밖에 없습니다. 그래서 지라 오토메이션과 컨플루언스 오토메이션을 살펴보면 지라 태스크의 상태에 따라 컨플루언스 문서 상태를 바꿔 서로 상태를 동기화 해서 굳이 컨플루언스 문서에 수동으로 지라 링크를 포함하지 않아도 되도록 만들 수도 있음을 알 수 있습니다. 하지만 컨플루언스 위키의 단점에 소개한 대로 여러 회사들은 여전히 컨플루언스 서버 버전 7이나 8에 여전히 머물러 있기에 이런 오토메이션 기능을 사용할 수가 없어 문제를 자동화해 해결할 수가 없습니다.

결국 문제를 자동화 해서 해결할 더 나은 방법이 있지만 오래된 컨플루언스를 사용하는 이상 문제를 사람에 기댄 방법을 통해 완화할 수밖에 없는데 대표적으로 완성되지 않은 문서를 모두에게 공개되는 프로젝트 공간으로 이동 시키지 않거나 프로젝트 공간에서 문서를 작성하더라도 아직 작성이 끝나지 않은 문서 제목에 ‘(작성중)’이라고 표시해 검색 결과에 이 문서가 나타나더라도 아직 작성중인 문서로 인지할 수 있어 검색 결과를 통해 접근하지 않도록 할 수도 있습니다. 사람들을 편안하게 만드는 훌륭한 해결 방법은 아니지만 아주 나쁜 방법이라고 보기도 어렵습니다. 이론적으로 작성이 끝나면 문서 제목에서 ‘(작성중)’ 문구를 제거한 다음 협업 부서에 공유할 수 있고 이 문구가 붙어 있는 동안에는 문서에 이상한 내용이 포함되어 있더라도 협업 부서가 이를 미리 보더라도 이상한 내용에 신경 쓰지 않을 수 있게 해 줍니다. 특히 이미 공개된 프로젝트 공간에서 문서를 작성할 때 종종 이터레이션에 긴 기간이 걸리는 문서를 작성하게 될 수도 있는데 이 과정 전체를 프로젝트 공간에서 수행하면 같은 부서 뿐 아니라 아직 이 문서의 요구사항을 수행하지 않아도 되는 협업 부서에 이 요구사항이 이터레이션을 거쳐 수정되어 가는 과정을 소극적으로 공유하는 효과를 얻을 수도 있습니다. 어느 프로젝트에나 공개된 모든 문서를 읽는 한심하고 하릴없는 변태들이 있습니다. 저 자신도 그런 사람인데 시간이 날 때 프로젝트 전체에 그 동안 수정된 모든 문서를 살펴보면 개인이나 팀에 따라 문서를 완성해 가는 방식이 서로 다르며 각자가 수행하는 일의 진행 과정을 살펴볼 수도 있고 또 개개인이 기록을 만들어 가는 과정을 보고 각자의 특성을 파악할 수도 있어 굉장히 재미있습니다. 문서가 수정되어 가는 방식을 살펴보고 문득 ‘이거 아무개님 문서인가?’ 하고 올려다 보면 여지 없이 그 분 이름이 적혀 있을 때 특히 재미있습니다.

하지만 크게 두 가지 이유로 문서 제목에 ‘(작성중)’이라고 문서 상태를 표현하는 것을 개인적으로 권하지 않습니다. 물론 제가 속한 부서에서도 이 규칙을 사용해 문서를 작성하고 있고 당장 저는 이 규칙에 손을 댈 생각이 없지만 개인적으로는 문서 제목에 문서 상태를 표현하는 것은 좋지 않은 정책이라고 생각합니다. 먼저 위키위키의 규칙을 망가뜨릴 가능성이 있습니다. 초기의 위키위키는 문서를 파일시스템에 저장하고 문서 제목으로 문서를 찾을 수 있게 만들었습니다. 가령 AboutSomething이라는 제목으로 문서를 만들어 내용을 작성하고 나면 다른 문서를 작성할 때 위키에 따라 조금씩 다르지만 대체로 [[AboutSomething]]이라고 타이핑하면 자동으로 같은 제목의 문서를 연결해 줍니다. 그래서 굳이 저 문서의 실제 엡 주소를 붙여 넣어 링크를 만들지 않아도 위키 내부의 문서를 가리키는 링크를 편리하게 만들 수 있고 또 이렇게 만든 위키 내부를 가리키는 링크와 웹 주소를 사용한 위키 외부를 가리키는 링크를 시각적으로 구분해 표현할 수 있는 장점도 생깁니다. 또 문서 제목을 어느 정도 규칙에 맞춰 작성하다 보면 굳이 실제 문서를 직접 확인하지 않더라도 문서를 작성하면서 ‘아마 이 제목의 문서가 있겠지?' 싶어 확인하지 않고 제목으로 그 문서를 가리키는 내용을 작성한 다음 살펴보면 틀리지 않고 그 문서를 연결할 수 있어 익숙해지면 굉장히 편리합니다. 하지만 이 규칙은 문서 제목으로 문서를 찾고 또 문서 제목에 기반해 파일시스템에 문서를 저장한 덕분에 문서 제목이 변경되거나 파일시스템 상의 문서 위치가 변경되면 문제를 일으킬 수도 있었는데 AboutSomething 문서를 About Something으로 바꾸면 초기 위키위키에서는 이를 가리키는 링크가 깨지기도 했습니다. 그래서 당시 위키에는 깨진 링크를 표시하는 또 다른 시각적 방법을 사용해 링크가 깨졌음을 문서를 읽는 사람에게 알리고 아무나 이를 수정할 수 있게 했습니다.

이는 위키위키가 처음 발명된 극초기에 일어난 문제일 뿐 엔지니어들은 고작 이런 이유로 링크가 깨지고 이를 사람이 직접 수정하기를 원하지 않았기에 어떤 문서의 이름을 바꿔 파일시스템 상의 문서 위치 역시 바뀌더라도 자동으로 이 문서를 가리키고 있는 다른 모든 문서를 확인해 링크를 수정하는 기능을 추가합니다. 이 다음부터는 문서 이름을 수정하더라도 이 문서를 가리키는 여러 문서들의 링크를 깨지 않고 또 링크를 직접 수정할 일도 없어졌습니다. 이 전까지는 위키위키에서 문서 제목을 수정하는 일은 썩 좋은 아이디어가 아니었습니다. 문서 제목을 수정하는 순간 이 문서를 가리키는 여러 문서들의 링크가 깨진다는 의미이고 또 링크를 깨지 않으려면 문서 제목을 수정한 다음 이 문서를 가리키던 여러 문서들을 찾아 다니며 링크를 하나 하나 수정해야 한다는 의미이기도 했기 때문입니다. 그래서 지금 보고 있는 문서를 가리키는 다른 문서들의 목록을 표시하는 ‘백링크’ 기능이 강조되기도 했지만 문서 제목 변경을 다른 문서에 자동으로 반영해주는 기능이 일반화되면서 백링크 기능은 이전만큼 유용하지 않게 되었고 현대에는 적당히 위키위키라면 갖춰야 할 기능 정도로 인식되고 있는 것 같습니다.

이 시점부터 이전 시대에 게시판에 하던 것처럼 문서 제목에 여러 가지 추가 정보를 표현할 수 있게 됩니다. 가령 개발팀에서는 이번 마일스톤 목표에 해당하는 문서임을 나타내기 위해 문서 제목에 마일스톤 제목을 포함하기 시작했는데 가령 인터랙션 오브젝트 기획서가 이번 마일스톤에 포함된다면 컨플루언스 위키 상에서 이 문서의 이름은 [M8] 인터랙션 오브젝트 기획서가 됩니다. 이제 검색 결과에서 [M8] 을 포함한 문서 제목을 만나면 이번 마일스톤에 수행해야 할 요구사항을 포함한 문서라는 사실을 직관적으로 알 수 있기 때문에 굳이 ‘이거 언제까지 해야 함?’ 같은 질문을 할 필요도 없어집니다. 또한 문서 제목 규칙은 여기서 좀 더 확장되어 앞서 설명한 문서의 현재 상태를 포함하기 시작해 [M8] 인터랙션 오브젝트 기획서는 [M8] 인터랙션 오브젝트 기획서 (작성중)이 되었습니다. 이 문서 제목으로부터 여러 가지 정보를 얻을 수 있기에 이는 나쁘지 않은 선택처럼 보입니다. 문서 제목으로부터 이 문서의 요구사항을 달성해야 하는 마일스톤 정보를 알 수 있고 이미 이번 마일스톤의 데드라인을 알고 있는 이상 일정에 대한 질문을 할 필요가 없습니다. 그런데 뒤에 이 문서의 현재 상태가 함께 표현되기 때문에 문서를 지금 읽어볼지 아니면 다른 일을 먼저 한 다음 나중에 읽어볼지 결정하는데 도움이 되기도 합니다. 굳이 작성 중인 문서를 미리 시간을 들여 읽는 대신 다른 일을 할 결정을 내릴 수도 있고 또 아직 작성 중이거나 팀 내 이터레이션을 수행 중인 문서를 미리 살펴보고 마음의 준비를 할 수도 있습니다.

이런 행동이 위키위키의 규칙을 망가뜨릴 수 있다고 여기는 이유는 근본적으로 위키위키는 다른 문서를 ‘제목’을 통해 가리키며 제목을 변경하는 행동은 이 위키위키가 다른 문서를 가리키는 방법을 교란하기 때문입니다. 물론 현대에는 이런 특징에 의해 위키가 망가지는 꼴을 결코 용납하지 않고 또 이 망가진 상태를 수정하는 행동을 귀찮아 했을 것이 분명한 여러 엔지니어들의 기여 끝에 제목을 바꾼다고 해서 링크가 깨지지도 않고 제목을 바꾼다고 해서 매크로가 망가지지 않는 것은 사실입니다. 또한 현대의 위키는 제목을 통해 문서를 연결하는 것처럼 보이지만 내부적으로는 문서 번호를 사용해 문서를 연결하고 문서 제목이 바뀌더라도 문서 번호가 바뀌지 않는 방식을 사용해 문서의 모든 내용을 바꿔도 결코 링크가 깨지지 않도록 하고 있습니다. 가령 제가 이 글의 초안을 작성한 컨플루언스 문서 번호는 434879154인데 이 번호는 문서의 그 무엇을 바꿔도 결코 바뀌지 않습니다. 하지만 컨플루언스 위키를 예로 들면 위키의 여러 세부 기능들은 여전히 오래 전 위키위키가 처음 개발 되었을 때와 마찬가지로 문서 제목에 기반해 동작하고 있다는 사실을 알 수 있습니다. 가령 ‘Include’ 매크로를 사용해 다른 문서를 현재 문서에 포함하려면 문서 제목으로 다른 문서를 지정해야 합니다. 또 다른 문서의 기능 일부를 가져오기 위해 ‘PageProperty’ 매크로를 사용할 때에도 문서 제목으로 특정 계층구조를 가리켜야 합니다. 일단 다른 문서의 정보에 접근하는 모든 매크로는 ‘문서 제목’을 기준으로 상대 문서를 지정하는데 이는 위키위키가 처음 발명되었을 때의 동작이 수 십 년이 지난 현대에도 여전히 유지되고 있는 모습입니다.

물론 컨플루언스 위키는 내부적으로 이미 문서 제목에 의존하지 않고 문서 번호를 통해 문서 사이의 연결을 관리하고 있으며 여러 가지 하위 기능이 초기 위키위키의 전통에 따라 문서 제목을 요구하는 모양으로 동작하고 있지만 분명 내부적으로는 문서 제목에 근거해 문서 번호를 찾은 다음 그 번호로 연결을 만들고 있을 겁니다. 하지만 사용하는 위키 제품에 따라 이런 짐작이 통하지 않을 가능성이 여전히 남아 있습니다. 이전에 꽤 오랫동안 사용해 온 도쿠위키는 여전히 문서 제목에 기반해 파일시스템에 문서를 기록하고 또 문서 제목에 기반해 링크를 만들고 있습니다. 이들도 문서 제목을 바꾸면 자동으로 이 문서 제목을 가리키던 문서를 다 찾아낸 다음 변경된 문서 제목으로 링크를 바꿔 주며 이 기록을 각각의 문서 히스토리에 남겨 주기도 합니다. 개인적으로 컨플루언스 위키에서 이런 상대 문서 제목의 변경에 의한 현재 문서의 변경을 히스토리에 기록해 주지 않는 것에 비해 도쿠위키의 동작을 더 좋아합니다. 이런 상황에서 어떤 이유로 문서 제목을 바꿀 때 이 문서를 가리키고 있는 다른 문서의 링크가 변경되지 않는다면, 또 문서에 사용한 다른 문서를 가리키는 다양한 매크로의 연결 정보가 변경되지 않는다면 마치 위키위키가 처음 발명되었을 때 오직 문서 제목으로만 문서를 연결한 덕분에 문서 제목 변경에 따라 링크가 깨지고 문서 제목 변경을 약간 금기시하던 시대와 비슷한 결과를 맞을 수 있습니다. 이런 위험성은 실제로 위키 소프트웨어의 버그, 하드웨어의 일시적 오류 같은 통제하기 어려운 온갖 이유 때문에 실제로 발생할 수 있습니다. 그래서 이 모든 것이 자동화된 현대에도 위키위키의 오랜 전통을 따르고 있는 위키 제품이라면 제목을 함부로 수정하는 것은 아주 좋은 아이디어는 아닙니다.

같은 맥락으로 문서 제목에 정보를 표현하는 것 역시 그리 좋은 생각이 아닌데 제목을 바꿔야 한다는 점 뿐 아니라 문서 제목에 표현된 정보는 어떤 것은 유용하지만 또 다른 것은 위키위키의 속성 상 아무런 의미가 없을 수 있기 때문입니다. 먼저 앞서 소개한 [M8] 인터랙션 오브젝트 기획서 (작성중)이라는 문서 제목은 나쁘지 않아 보이지만 일단 이 문서는 어떤 이유로 이번 마일스톤 기간 안에 개발되지 않을 수 있습니다. 엔지니어 부서의 비용 문제, 혹은 에셋 제작이 늦어지거나 이 기능에 연관된 수정된 의사결정이 일어나면서 문서 자체가 취소될 수도 있습니다. 그러면 문서 제목에 포함된 마일스톤 번호를 수정하거나 아예 마일스톤 표시를 빼야 할 수 있고 이런 변경은 앞서 설명한 문서 제목을 바꿀 때 일어날 수 있는 여러 문제를 야기할 가능성이 있습니다. 그리고 근본적으로 위키위키 형식의 정보시스템에 올라온 ‘모든’ 문서는 ‘최종’ 상태가 될 수 없습니다. 우리들이 버전을 관리하지 않는 파일시스템에 기반해 문서를 작성할 때 파일 이름 뒤에 _최종 같은 문구를 붙이곤 하지만 _최종, _최최종, _진짜 최종 같은 문구가 밈이 될 정도로 이런 버전 표시 방법은 실제 세계에서 동작하지 않습니다. 문서는 일단 작성되기 시작하면 특정 시점에는 이 문서를 읽어야 하는 누군가에게 넘겨져 문서의 내용이 실행되어야 하지만 이 때 문서는 결코 완성되었기 때문에 그 내용이 앞으로 변경되지 않으리라고 보장할 수 없습니다. 문서의 내용을 실제로 수행하는 동안 상황은 시시각각 변화하고 이 문서가 근거로 삼고 있는 의사결정이 변경되거나 취소될 수 있으며 실제 문서의 요구사항을 수행하다 보니 문제가 발견되어 요구사항을 수정해야 할 수도 있는데 이럴 때마다 문서의 내용은 변경될 수밖에 없습니다. 결코 문서는 최종 상태에 도달하지 않습니다.

근본적으로 위키위키라는 정보 기록 방법은 문서가 처음 생성된 순간부터 영원히 수정될 거라는 사실을 인정하고 이를 뒷받침하는 구조를 선택했습니다. 누군가 문서를 수정할 때마다 이전의 모든 버전이 남아 있고 이 정보시스템이 동작하는 한 이전 모든 버전에 언제든 접근할 수 있습니다. 일을 하다 보면 종종 ‘문서에 새로 업데이트 된 부분에 표시해 달라’는 요구를 받기도 하는데 오래 전 워드프로세서 애플리케이션을 사용해 문서를 작성하던 습관을 여전히 유지하는 사람들은 문서에 수정된 부분을 하이라이트 해서 저장한 다음 전달하기도 합니다. 하지만 위키위키 규칙에 따라 만들어진 정보시스템, 가령 컨플루언스에서는 그냥 새로운 내용으로 문서를 업데이트 한 다음 이전 버전과 현재 버전의 차이를 표시하는 페이지를 연 다음 최신 문서 경로와 이전 문서와 차이를 표시하는 주소를 함께 전달하면 컨플루언스가 예쁘가 새로 추가된 부분, 삭제된 부분, 수정된 부분을 정리해 보여줍니다. 굳이 문서 자체에 수정된 부분을 언급하지 않아도 됩니다. 문서가 실제로 동작하는 동안 여러 가지 이유로 문서가 수정될 수 있으며 문서는 심지어 이 문서의 요구사항이 완전히 개발된 다음에도 여전히 수정될 수 있습니다. 이 문서를 통해 개발된 기능이 미래의 다른 기능에 의해 대체된다면 그 새로운 기능을 가리키는 링크를 문서 앞부분에 커다랗게 표시해 ‘이제 현재 문서 말고 이 새 문서를 읽으세요’ 라는 내용을 추가할 수도 있습니다.

이 모든 상황은 위키위키라는 형태의 정보시스템에 작성된 모든 문서는 근본적으로 영원히 ‘작성중’ 상태를 유지할 수밖에 없다는 사실을 말해줍니다. 문서는 처음 작성을 시작해 아직 그 누구의 확인도 거치지 않은 완전히 이상한 내용을 포함하고 있을 때부터 여러 단계의 논의와 확인, 그리고 협의를 거치는 사이에도 계속해서 변경되며 마일스톤 목표에 포함되어 실제로 내용이 수행되는 과정에서도 그 내용이 계속해서 변경될 겁니다. 개발 하는 도중 발생한 문제를 해결할 방법을 논의하면 회의록 문서 하나가 생길텐데 이 회의록에 의한 액션플랜은 빌드를 수정하는 것이기도 하지만 동시에 요구사항을 기록한 문서를 수정하는 것이기도 합니다. 한번 작성된 문서는 그 문서가 삭제되거나 프로젝트가 종료되어 컨플루언스 공간 전체가 아카이브 되는 순간을 맞이하기 전까지는 계속해서 ‘작성중’인 상태로부터 자유로울 수 없습니다. 그래서 개인적인 관점에서 위키 문서 제목에 ‘작성중’이라고 적는 행동은 마치 화학구조식에서 너무 당연해 탄소를 생략하는 대신 탄소가 들어갈 모든 자리 하나하나마다 탄소를 표시해 시인성이 떨어지도록 만들거나 수학 공식에서 1이 곱해지는 표현을 생략하던 모든 장소에 굳이 1을 써 넣어 식을 복잡하게 만드는 행동과도 비슷합니다. 마치 자동차 바퀴에 ‘굴러감’이라고 써 놓거나 모니터 앞에 놓인 키보드에 굳이 ‘타이핑 가능’이라고 적어 놓는 행동과도 비슷합니다. 모든 문서는 그 문서의 수명이 끝나는 그 순간까지 작성중인 상태이며 위키위키 형식의 정보시스템을 사용하는 모든 사람들은 이 사실을 인정해야만 합니다. 그리고 제목에 굳이 너무나도 당연한 사실을 언급하지 않아야 합니다.

제목으로 돌아가 ‘위키 글 제목에 (작성중)이라고 쓰면 안 되는 이유’는 현대적인 위키 관점에서 사실 없습니다. 수십년 전에 발명된 최초의 위키위키에서나 오직 문서 제목에만 의존해 문서를 링크해 문서 제목이 바뀌면 링크가 깨졌을 뿐 현대의 거의 모든 위키는 더이상 그렇지 않습니다. 때문에 굳이 기술적인 걱정 때문에 제목을 바꾸는 행동을 안 할 필요는 전혀 없습니다. 하지만 문서의 상태를 문서 제목에 포함하는 행동은 그 정보가 쉽게 바뀔 수 있기에 썩 추천하지 않습니다. 특히 문서의 상태를 표현할 때 ‘작성중’이라고 쓰는 행동은 위키위키 형식의 정보시스템에서 문서의 생애주기를 잘못 이해한 행동이라고 생각하며 이는 심지어 버전 관리 되지 않는 파일시스템에 문서를 작성할 때 파일 이름에 버전을 표시할 때 조차 달성할 수 없는 목표입니다. 문서는 결코 최종 버전에 도달하지 않습니다. 문서는 결코 작성중 상태를 벗어나지 않습니다. 때문에 문서 이름에 이 사실을 언급할 필요가 없습니다.