회귀론자

주로 원격으로 일하다가 하루는 일이 있어 출근했습니다. 요즘에는 출근하는 날이 출근 안하는 날보다 훨씬 적다 보니 회사에서 사람들을 정말 오랜만에 만나곤 합니다. 그리고 간만에 만난 김에 서로 어색하게 한 2미터쯤 떨어져 이야기를 하곤 합니다. 이 날도 다른 부서 분과 오랜만에 만나 이야기하다가 문득 기획서 이야기가 나왔습니다.

저희 팀은 기획서를 위키에 작성하고 있습니다. 실은 프로젝트를 처음 시작할 때는 그 이전 프로젝트에서 하던 대로 워드 문서로 작성해 형상관리도구에 올려 공유하곤 했고 이 관성을 그대로 유지했습니다만 개인적으로 마음에 드는 상황은 아니었습니다. 제 관점에서 워드는 개발 문서를 관리하기에 좋은 도구가 전혀 아니었고 문서를 작성하는 사람들에게 문서 자체가 아니라 문서의 형식이 더 많은 자원을 소모하게 유도했습니다. 시간이 흘러 워드를 버리고 기획서를 위키에 작성하기 시작했고 또다시 이로부터 시간이 흘러 어느 정도 팀에 문서를 작성하는 새로운 방법들이 정착하기 시작했습니다.

워드를 사용할 때에 비해 달라진 점은 우선 문서들 사이에 링크를 적극적으로 사용하게 된 점입니다. 워드 문서를 형상관리도구에 올려놓던 시대에는 다른 문서에 직접 링크를 만들 수가 없었습니다. 그래서 형상관리도구에 문서를 올려놓은 경로를 웹서버로 접근할 수 있게 만들어놓고 이 웹 경로를 공유하곤 했습니다만 절차가 아주 단순하지는 않아 널리 활용되지 않았습니다. 반면 웹브라우저를 통해 동작하는 위키는 그냥 주소 자체를 문서에 붙여넣으면 됐고 필요하면 문서 중간에 링크를 걸고 링크를 건 타겟 문서에도 지금 내가 작성한 문서의 링크를 참고 항목에 추가하는 등 문서들이 자신의 주제를 설명하는데 이전에 다른 사람들이 작성해 놓은 다른 문서를 적극적으로 활용하기 시작했습니다.

문서의 변경사항을 추적하기 쉬워졌습니다. 워드를 사용할 때 어떤 분들은 문서 어딘가에 ‘버전 별 변경사항’을 표로 만들어 기록해 오고 있었습니다. 문서를 열면 한 페이지짜리 표지, 목차, 그 다음에 항상 변경 이력 테이블이 나타났습니다. 분명 처음 이분들께 일을 가르친 누군가가 문서에는 항상 변경 이력을 남겨야 한다고 이야기했을 겁니다. 그리고 이분들은 이 행동의 목적을 깊히 생각하지 않았을 거고요. 워드 문서를 형상관리도구에 올리면서 문서 내부에는 변경이력을 서술하지만 정작 형상관리도구에는 ‘문서 수정’ 이라고 적어 커밋하는 참사가 한동안 일어났습니다. 문서를 위키로 작성하도록 팀 전체의 방식을 바꾸기 전에 문서 내부에 변경이력을 작성하지 말고 이를 커밋 메시지에 작성하도록 가이드했고 시간을 한참이나 써서 습관을 조금이나마 바꿀 수 있었습니다. 그 사이에 덜렁 ‘문서 수정’이라고 적힌 커밋메시지들을 쫓아다니며 수정해달라고 요청하는데 시간을 보내는 댓가를 치렀습니다.

문서를 위키에 쓰기 시작하면서 이 점도 훨씬 더 단순해졌습니다. 문서를 작성해 저장하면 문서를 커밋하는 추가 단계를 거칠 필요 없이 바로 문서가 공개됐습니다. 저장할 때마다 버전은 알아서 올라갔고 각 버전의 수정사항은 이게 중요한 변경일 때만 기입하게 했습니다. 어차피 뭘 수정했는지는 굉장히 편리하게 비교해볼 수 있었으니까요. 워드로 문서를 작성하던 시대에는 이 비교가 가능하기는 했지만 단순하지는 않았습니다. 그래서 변경한 부분에 색깔을 칠해두기도 하고 변경이력을 작성하느라 시간을 보내기도 했습니다. 하지만 더이상 그럴 필요가 없어졌습니다. 덕분에 사람들은 문서를 좀 더 적극적으로 수정하기 시작했고 지금도 완전하지는 않지만 문서들은 이전에 비해 더 최신 상태에 가까워졌습니다.

다시 간만에 출근해서 기획서 이야기를 하던 곳으로 돌아가봅니다. 이 분이 제게 하신 하소연은 문서들이 이전에 일하던 프로젝트에 비해 너무 자주 바뀌어 일하기 어렵다는 것이었습니다. 그래서 워드에 문서를 쓰는게 낫지 않겠냐는 건의를 해 오신 것이었습니다. 이런 건의에 대한 제 의견은 죄송하지만 꽤 강경한데 워드가 좋다면 워드를 사용하는 팀에 가서 일하는 수밖에 없다는 겁니다. 팀을 움직이는 주 동력은 우리들이 작성하는 기획서로부터 시작됩니다. 이 문서는 팀 전체를 움직입니다. 그만큼 이 문서들은 사려깊게 작성되어야 하고 또 이 문서들을 작성하는 과정이 더 쉬워야 합니다. 문서에 잘못된 점이나 새로운 수정사항이 생기면 더 빨리 반영되어야 하고 더 빨리 작업자들에게 전파되어야 합니다.

그래서 제 입장에서 문서가 자주 변하는 건 이분께는 죄송하지만 오히려 바람직한 일입니다. 하지만 강경한 입장을 있는 그대로 말하는건 올바른 의사소통 방법이 아니어서 문서 관리에 위키를 사용하는 팀에서 나타나는 당연한 현상이고 문서가 잘 바뀌지 않는다는 말은 팀이 기획서에 따라 수동적으로 일하고 있을 뿐 작업자 개개인이 각 기능에 별 관심이 없이 일하고 있다는 증거일 수도 있다고 말씀드리고 게임디자이너들에게 문서가 변경될 때 사소한 변경이 아니라면 이를 협업자들에게 더 잘 알리도록 해보겠다는 이야기로 끝을 맺었습니다.

어떤 팀에서는 이슈트래커와 문서관리도구, 일정관리도구가 서로 잘 통합되지 않는 점에 문제의식을 느껴 노션을 사용하기도 하지만 또 누군가는 이제서야 정착되어 잘 돌아가기 시작한 컨플루언스 대신 워드에 문서를 써 형상관리도구나 심지어 공유디렉토리에 올리자는 말을 의견이라고 내놓곤 합니다. 우리들은 더 복잡한 일을 더 잘 처리하기 위해 이런 회귀론자들을 설득하고 때로는 저항해야 합니다. 우리는 우리 일에 더 집중하고 이를 ‘자기 자신에게만 익숙한’ 효율적이지 않은 방법으로 되돌리려는 사람들이 나타나더라도 쉽게 흔들리지 않도록 노력해야 합니다.