리모트는 매끄럽기보다는 울퉁불퉁하다
문서화를 잘하면 (원활한 비동기 커뮤니케이션과 함께) 리모트가 쉬워진다. 이런 종류의 이야기는 이제는 당연해서 업계의 상식과도 같다. 나 역시 코로나 시절에는 문서화가 역시 리모트의 핵심이 아닐까 하고 생각했다. 그런데 요즘 창업을 준비하며 오케스트라 팀이 아닌 재즈 밴드 팀1으로 일하다 보니 이 당연한 생각이 어딘가 미심쩍기 시작했다. 심지어는 이 문서화에 대한 강조가 이전 회사의 팀과 제품을 갉아 먹었던 게 아닌가 하는 생각까지 들었다.
리모트로 일하는 조직은 좀 더 매끄러운 커뮤니케이션을 위해 자꾸 무언가의 산출물artifact2을 만들어 내야한다. PM은 디자이너에게 넘기기 위한 제품 스펙 문서를 작성하고, 디자이너는 개발자에게 넘길 목적으로 와이어프레임을 만들어 내고, 개발자는 이 자료들을 바탕으로 테크스펙을 작성한 후 마일스톤을 세워 전달한다. 단계마다 각 인원이 책임질 산출물이 분명하기에 각자의 관심사는 (함께 해결할 그 사용자의 문제가 아니라) 산출물을 향한다. 매끄러운 바통 터치가 일어나는 이 일련의 과정은 명백히 우리가 '폭포수'라고 부르는 방식과 많이 닮아있다. 매끄러운 커뮤니케이션을 위한 산출물에 관한 강조—대부분의 경우 문서화에 대한 강조—는 많은 경우 폭포수 방식으로 돌아가자는 선언이 된다.
문서화에 큰 가치를 둔 조직은 점차 성과output가 아니라 결과outcome에 집중하는 경향3이 생긴다. 제품 스펙 문서를 깔끔하게 잘 작성하는 PM이 동료에게 존경받기에 PM의 업무는 제품 스펙 문서를 작성하는 것에 가까워진다. 마찬가지로 디자이너는 피그마 파일을 얼마나 깔끔하게 잘 관리하는지, 개발자는 테크 스펙 문서를 얼마나 잘 작성하는지가 중요해진다. 이렇게 명확하고 군더더기 없는 문서 위에 오가는 코멘트 속에서 애초에 팀에서 해결하기로 한 사용자의 문제는 흐릿해지고, 산출물의 형태만이 또렷해진다. 반면에 사람들은 우리가 무언가 매끄럽고 더없이 효율적으로 일하고 있다는 착각에 빠진다. 문서화가 (그 자체로는 아무런 잘못이 없음에도) 이렇게나 위험하다. 매끄러움은 종종 우리를 속인다.
물론 사용자의 문제라는 본질만 우리가 잊지 않는다면 이토록 매끄러운 업무 방식이 도대체 뭐가 문제냐고 따질 수도 있겠다. 나는 "사용자의 문제라는 본질만 우리가 잊지 않는다면"라는 전제 같은 게 가능하리라고 믿지도 않지만, 그런 전제를 받아들일지언정 문제가 사라지지는 않는다. 사용자 인터뷰를 다녀보면 더 온전한 형태의 프로토타입을 준비할수록 사용자에게 진실을 듣기 어려워진다. 반면에 허술한 종이로 만든 것 같은 페이퍼 프로토타입을 가져가면 사용자는 스스로 그림까지 그려가며 이러면 좋겠다고 마구 얘기를 쏟아낸다. 한번 상상해보자. 누군가 몇 시간씩 공들여 정성스럽게 요리한 음식을 대접했는데, 맛없다는 말을 하기란 참으로 힘든 일이다. 완벽함은 꽤 빽빽해 틈을 찾기에도, 그 틈 사이로 몸을 비집고 들어가기에도 부담스럽다.
누군가는 그건 문서화 자체의 문제가 아니라 심리적 안정감의 문제가 아니냐고 따질 것이다. 맞다. 심리적 안정감이 높은 조직은 공들여 요리한 음식에도 무례하지 않게 별로라는 소리를 할 수 있는 조직이다. 그런데 내가 지적하고 싶은 건 빽빽한 문서가 커뮤니케이션을 완전히 대체하는 조직일수록 심리적 안정감이 형성될 가능성이 적다는 점이다. 사람 사이의 상호작용이 아닌 텍스트로 대부분의 소통이 이뤄지는 조직에서 심리적 안정감이 형성될 가능성이 얼마나 될까? 게다가 대부분의 피드백이 (비언어적 표현을 함께 사용할 수 있는) 말이 아닌 텍스트로 이뤄지는 환경에서는 (말솜씨에 비해 글솜씨는 차이가 꽤 크기에) 불필요한 오해를 만들어 내기 지나치게 쉽다. 누군가 용기 내 남긴 의견이 누군가에게는 공격으로 바뀌는 순간 심리적 안정감은 무너지기 마련이다.
심리적 안정감을 떠나 작성에 공을 들인 문서는 작성자 자신도 변경에 대한 저항이 클 수밖에 없다. 6에서 12 페이지 분량의 제품 스펙 문서는 다른 사람이 피드백을 주기 어려운 수준을 넘어서, 어떤 피드백을 받아도 기존의 문서 내용을 완전히 폐기하고 백지상태로 다시 시작하는 결정을 내리는 게 거의 불가능한 수준이다. 이 문서를 작성하는 데 쓴 시간이 모두 매몰 비용으로 작용하기 때문이다. 그렇기에 계획을 따르기보다 변화에 대응하는 쪽에는 1-pager의 헐렁함이 유용하다.
물론 위에서 열거한 모든 내용이 결국 다 역량의 문제인 게 맞다. 빽빽한 문서를 마치 GPT가 작성하듯 시간과 에너지를 거의 소비하지 않고 작성할 수 있으며 팀원과의 상호작용을 놓치지 않고 텍스트만으로도 피드백이 창발하는 조직이 있다면 이런 고민이 다 무슨 소용이 있겠는가. 내가 말하고 싶은 건 어떤 환경이 조직의 생존 측면에서 더 유리할지 생각해 보자는 것이다. 스타트업은 극단적으로 실용적인 조직이(어야 하)기에 생존에 조금이라도 유리한 결정이 항상 이겨야 한다.
그러면 대체 뭐 어떻게 하자는 것인가. 문서화를 아예 하지 말자는 말인가? 물론 그건 절대 아니다. 위에서도 밝혔듯 문서화는 그 자체로 아무런 문제가 없다. 그저 내 제안은 단순히 문서의 용도를 나누어 생각하자는 것이고, (온라인이든 오프라인이든) 얼굴을 보고 대화를 나누는 방식을 문서 기반의 커뮤니케이션에 비해 선호하자는 것이다.
가장 실천적인 접근은 '문서'라는 것의 어떤 스테레오타입을 벗어 던지는 것에서부터 시작이다. 문서란 언제나 내러티브를 지닌 빼곡한 텍스트일 필요는 없다. 예를 들어 문서의 용도를 독자의 유형에 따라 메모와 아카이브로 나누어 생각해 보자. 메모의 주된 독자는 지금 나와 이 프로젝트를 함께하는 동료들이다. 어차피 대부분의 프로젝트는 그 기간이 그리 길지 않고—만약 어떤 프로젝트가 아주 긴 호흡으로 진행된다면 과연 이게 최선의 형태일지 고민해 볼 필요가 있다—워킹 그룹이 아닌 팀의 형태로 일할 테니 아마도 모두 같은 토양을 공유할 것이다. 그렇기에 이들에게 필요한 문서의 형태는 내러티브를 담은 빼곡한 텍스트가 아니라 프로젝트의 디테일을 간결하게 명시해 둔 말 그대로의 메모일 뿐이다. 반면에 아카이브의 주된 독자는 공통의 토양을 공유하지 않는 누군가이다. 그들에게 필요한 문서는 알아들을 수 없는 메모가 아닌, 프로젝트의 배경과 진행 경과, 그리고 성과를 정리해 둔 텍스트일 수 있다. 물론 이 문서는 프로젝트가 완전히 종료되는 시점에 회고의 방식 중 하나로 프로젝트를 함께한 팀원들과 협력적으로 완성해 사후에 회사의 위키 같은 곳에 아카이브 해두면 충분하다.
사실 이 글에 쓰인 모든 '리모트'라는 단어를 '애자일'로 바꿔도 상관이 없다. 애자일에는 스크럼을 비롯해 애자일의 가치를 좀 더 매끄럽게 누리고자 고안한 여러 구현체가 있지만, 내 경험상 애자일은 본래 매끄러울 수 없고, 어딘가 투박하고 그래서 울퉁불퉁한 것이다. 위대한 제품은 물 흐르듯 컨베이어 벨트를 누비며 만들어지지 않는다. 그보다는 고통스러운 출산의 과정에 좀 더 가깝지 않을까?