살려 낸 101번 째 문서 시스템: (1) 문제 정의 과정
지난 7월 26일에 Toss Makers Conference(TMC)에서 지난 1년 간 만든 문서 시스템에 대해 발표했다. 연초에 사내에서 발표 등록 공지가 났을 때는 제안을 받고 꽤 망설였다. 4년 정도 SLASH 컨퍼런스를 위해 연사분들의 장표와 스크립트 검수를 도왔지만, 직접 발표한다는 것은 생각해 본 적이 없었기 때문이다. 다만 이전에 박씨와 관련해 회사 블로그에 썼던 글의 반응이 좋았던 것이 생각났다. 회사 동료들과 주변인들로부터 외부의 여러 긍정적인 반응을 공유받았고, 커피챗 요청을 받기도 했다. 그때 정말 많은 조직에서 문서를 기반으로 지식을 공유할 수 있는 시스템을 필요로 한다는 것을 느꼈다. 그래서 그간 업데이트된 문서 시스템을 한 번 더 공유해봐도 괜찮겠다는 생각이 들어 용기를 냈다.
발표를 준비하면서 가장 신경 쓴 것은 찾아 오신 분들이 '무언가 얻어갔으면 좋겠다'는 것이었다. 업계 전반적으로 문서에 관심을 갖고, 시스템을 만드는 사람들이 많아지는 것이 가장 원하는 결과였기 때문이다. 그래서 발표에서는 문서 시스템의 각 요소가 해결하려는 문제와 구현 방식을 중심으로 다루었다.
발표를 앞두고 너무 긴장했고(손에 식은땀이 가득 난 채 올라갔지만 다들 티 나지 않았다고 해서 다행), 마친 뒤에는 무척 후련해 그냥 잊고 있었다. 그리고 한 달 반이 지나 발표 영상이 올라와서 다시 보니 너무 구현 위주로 이야기 한 것 같다는 생각이 들었다. 영상을 본 친구들의 피드백도 비슷했다.
"발표 대부분이 제작 과정에 대한 얘기다보니 얼마나 치밀하게 만들어졌는지 알 수 있네. 퀄리티가 엄청 높고 장인정신이 느껴져. 다만 문제 정의가 보편적이고 실제적이라 되게 와닿았거든. 이 부분에 대해서 더 듣고싶은데 너무 소박하게 넘어간 것 같네. ㅋㅋ 특히 마지막 장표 부분. 네가 생각하는 문서의 가치에 대해 더 알고 싶다."
사실 발표를 '무언가 얻어가게끔'하는 방향으로 바꾸기 전에는 이런 것들을 이야기 할까 했었는데, '나에게만 중요한 게 아닐까?', '너무 원론적인 이야기로 흐르진 않을까?'하는 노파심에 거의 빼고 마지막 장표만 남게 됐다. 하지만 친구 말처럼 실제로 내게 정말 가치있었던 것들은 문제 정의의 과정이나 장표의 마지막 부분에 나오는, 문서가 조직의 인프라이자 성장동력이라는 부분이었다. 그래서 이 글에서는 문제 정의 과정을, 다음 글에서는 문서의 가치를 다뤄보려고 한다.
문제 정의 과정
2021년부터 2024년까지 3년 넘게 토스페이먼츠에서 우리 제품을 쓰는 외부 개발자를 위한 기술 문서를 만들었다. 만들면서 늘 마음 한 편에 '사람들은 읽고 싶지 않아하는데, 내가 하는 일이 그들에게 큰 의미가 있을까?'라는 질문이 있었다. 문서가 없으면 연동을 할 수가 없으니 물론 중요하긴 하다. 하지만 나 역시 문서가 정말 편리하기 어렵다는 것에도, 텍스트를 읽기 귀찮다는 점에도 공감할 수 있었다. 그렇게 일을 하면 할수록 문서에 대한 양가적인 감정이 깊어졌다.
그 문제를 정면으로 돌파하고 싶어서 토스페이먼츠에서 마지막으로 한 일이 개발자센터를 텍스트와 읽기 경험이 아니라 코드와 개발자경험(DX, Developer eXperience)을 중심으로 개편하는 것이었다. 그렇게 개발자들이 좋아하는 코드 기반으로 체험할 수 있는 샌드박스를 만들고, 스크롤하면서 문서와 코드와 미리보기가 한 번에 되는 튜토리얼이 있는 개발자센터가 탄생했다.
그리고 작년 여름 토스 코어에 합류했다. 이번에 내가 풀어야 하는 문제는 내부 지식이 모두에게 가닿지 않는 문제였다. 특히 조직의 규모와 성숙도가 높아진 프론트엔드 챕터는 같은 질문이 반복적으로 올라오고, 각자의 머릿 속에만 있는 수많은 정보와 지식이 잘 퍼지지 않아 오랫동안 고생중이었다. 그래서 거기에 대한 해결책으로 문서를 만들고, 문서를 기반으로 일하고 싶어했다. 하지만 발표에서도 잠시 이야기 했던 것처럼 이 문제를 문서 '마련하기'만으로 해결할 수는 없다는 걸 이미 앞서 3년 간 경험했고, 그래서 다른 방식으로 해결해야 했다.
그래서 합류하자마자 1:1로, 또 그룹으로 많은 인터뷰(FGI, Focus Group Interview)를 했다. 그 과정을 돌아보며 쓴 글이 훌륭한 기술 문서, 좋은 테크니컬 라이팅이란 뭘까? 였다.
그러면 단순히 존재하는 모든 지식을 모아 정적인 문서를 만들면 될까? 개발자들 스스로도 그렇게는 안된다고 1:1 혹은 포커스 그룹 인터뷰에서 이야기 했고 나 역시 그걸로는 충분하지 않다고 생각했다.
팀 내 개발자들이 작성한 문서를 사용하게 하는 시도는 이미 수차례 실패했고 Slack 채널이나 동료에게 먼저 묻는 행동이 지속됐다. 그렇다면 '문서를 기반으로 한 업무 방식'이라는 개념을 재정의해야 하는 것 아닐까?
개발자는 문서를 읽고 깊이 있는 지식을 얻고 싶어할 때도 있지만, '업무할 때'라는 조건 안에서는 대부분 빠르게 문제를 해결하고 싶어한다. 그래서 팀 내 개발자가 하는 행동은 온오프라인에서 '질문한다'는 것이다.
수많은 인터뷰는 내가 세운 가설에 확신을 심어준 결정적인 과정이었다. 여러차례 사람들을 만나 이야기하고 관찰하다보니 우리가 못하게 하고 싶은, '업무 메신저나 동료에게 물어보기'는 막을 수 없는 자연스러운 행동이라는 생각이 들었다. 그렇다면 사람들의 자연스러운 행동을 그대로 살리면서 문서와 연결할 수 있는 방법이 없을까? 여기에 대한 답으로 '질문이 생겼을 때 문서를 볼 수 있게 하자'라는 방향이 정리되었다.
*참고로 이 과정을 진행할 때 나에게는 액션리서치라는 방법론 도구가 있었다. 사회과학에서 현장의 문제를 해결하기 위해 당사자들의 목소리를 듣고 문제 정의를 한 뒤 함께 해결책을 실천하는 방법론이다. 오래전부터 유저의 의견과 행동을 귀담아 듣는 방식을 당연하게 여기며 일해온 IT 업계에서는 특별하지 않게 느껴질 수 있지만, 문제 해결의 주체가 연구자나 프로젝트 리드 혼자가 아니라 함께 해결한다는 관점이 중요한 차이점이다. 나는 이 문제 해결의 주체가 결국 일하고 있는 팀원들이라고 생각해서 적용해 볼 수 있겠다고 생각했다. 모든 과정이 온전한 액션리서치라고 하긴 어렵다 싶긴 하지만 지속적으로 사람들의 의견을 받고 같이 개선했다는 점에서 어느 정도 잘 사용했다고 생각한다.
그리고, 인터뷰 과정에서 예상치 못하게 만난 기쁨이 있었다. 사람들이 문서를 무척 필요로 한다는 점이었다. 내심 사람들은 문서를 따분하게 여기고 도움이 안된다며 싫어할 거라고 짐작했는데, 그런 생각이 깨졌다.
합류 후 첫 주 동안 10명 이상의 개발자를 인터뷰했는데, 생각보다 많은 구성원이 ... 같은 문제의식을 공유하고 있다는 점이 놀라웠다. 심지어 이미 여러 차례 조직 내에서 문서화를 시도한 경험도 있었다. 충분히 고무적인 상황이었다. 많은 조직이 문서의 비효율성에 집중하는데, 오히려 이 팀은 문서의 필요성을 인지하고 적극적으로 노력해본 경험이 있었기 때문이다. 이는 테크니컬 라이터로서 내가 가진 문제의식을 이미 경험해 봤고 공감하는 사람들이 많다는 것을 뜻했고, 실제로 그랬다.
그래서 프론트엔드 챕터에서 문서를 질문을 하면 볼 수 있도록 만들기 시작했고, 그 과정은 지난 발표에 담겨 있다.