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

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

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