6. 도구를 넘어, 기준과 책임으로

안녕하세요. 토스 Technical Writing Partner 황동진입니다.

앞서 Technical Writing Chapter는 이런 다짐을 했어요. "문서를 직접 쓰고 다듬는 일은 AI에게 넘기고, 지식이 생기고 순환하고 정리되는 구조를 설계하는 사람이 되겠다." 저는 커머스 도메인에 소속된 Technical Writer(이하 TW)로서 그 일을 먼저 도메인 안에서 시도해봤는데요.

커머스 도메인에서는 쇼핑 홈, 상품, 주문, 결제, 정산처럼 서로 맞물린 일을 여러 팀이 함께 만들고 운영해요. 정책이 하나라도 바뀌면 각 팀에서 만드는 화면과 운영에 영향을 주는데, 그 변화들을 쉽게 확인할 수 있는 방법이 없었습니다. 그러다 보니 이미 정한 내용을 다시 묻거나, 같은 기능을 서로 다른 이름으로 부르며 회의 시간을 쓰는 일도 있었어요. 하나의 제품을 여러 팀에서 만드는 거대한 기능 조직에서 지식이 흩어져 있으면 이런 비효율과 불편함이 무척 치명적입니다.

앞선 글들에서는 토독, Skill 등으로 전사적인 지식 관리 문제를 풀어가는 과정을 소개했는데요. 막상 도메인 안에서 일해 보니, 지식을 모으는 도구와 자동화가 있어도 그것만으로 지식 시스템이 완성되지는 않았어요. 무엇을 남길지, 누가 책임질지, 어떤 문서를 믿을지 함께 정하는 기준과 문화가 없으면 도구는 금방 헛돌았습니다. 이 글에서는 제가 한 도메인의 지식을 모으는 과정에서 무엇을 배웠고, 그 배움이 어떻게 정책과 문화에 대한 고민으로 이어졌는지 이야기해볼게요.

혼자 더 쓰는 것의 한계

처음에는 제가 직접 문서를 더 많이 쓰면 된다고 생각했습니다. 커머스 위키라는 공간을 만들고, 용어사전과 온보딩 문서를 채우고, 코드와 흩어진 자료를 모아 정책 문서를 정리했어요. 효과도 있었어요. 셀러와 상점처럼 팀마다 다르게 부르던 표현을 한곳에 정리하니 회의에서 용어를 맞추는 시간이 줄었고, 다른 팀의 기능을 이해할 때도 출발점이 생겼습니다.

하지만 제가 혼자 문서를 쓰는 속도로는 제품이 바뀌는 속도를 따라갈 수 없었어요. 커머스의 지식은 늘 현장에서 먼저 생겼고, 저는 그 뒤를 쫓아가며 정리하는 사람이었습니다. 담당자가 바뀐 정책, 실험으로 잠깐 켜졌다 꺼진 화면, 사내 메신저 스레드에서 논의한 내용까지 혼자 따라잡는 건 불가능했어요. 단순히 문서를 더 쓰는 게 답이 아니라는 걸 그제야 알게 됐습니다.

문화만으로는 부족했던 이유

그 다음에는 사람들이 직접 문서를 더 잘 남기게 하려고 여러 시도를 했어요. 커머스 위키를 저 혼자 채우는 저장소가 아니라, 도메인 구성원이 함께 쓰고 고치는 공간으로 만들고 싶었거든요. 그래서 문서화를 또 하나의 일거리로 느끼지 않도록, 관심을 끌고 참여의 문턱을 낮추는 시도를 차례로 해봤습니다.

먼저 위키를 '가끔 검색하는 저장소'가 아니라 '매주 읽을거리'로 만들고 싶어서 '커머스 위키 뉴스'라는 주간 뉴스레터를 띄웠어요. 새로 올라온 문서와 그 주에 합의된 용어('즉시할인'을 '추가할인'으로 통일한 것처럼요), 정독해야 풀 수 있는 퀴즈, 기여해 주신 분들의 이름을 담았죠.

정책 질문 봇, 워크숍, 길드 등으로 참여의 문턱은 더 낮췄어요. '커머스 정책이 궁금해요' 채널을 열어 흩어져 있던 정책 질문을 정책 질문봇에 모았고, 봇이 답하지 못한 질문은 문서가 비어 있다는 신호로 삼았죠. 한 시간 만에 AI로 위키 문서 한 편을 완성해 보는 워크숍을 열어 '자주 받는 문의'처럼 손에 잡히는 주제부터 직접 써보게 했고, 거기서 관심을 보인 분들과는 문서화를 함께 고민하는 길드를 꾸렸습니다.

이 시도들은 분명 의미가 있었어요. 문서 요청이 늘고, 위키를 인용하는 일이 잦아지고, 공식 용어를 챙기는 분위기도 생겼습니다. 그런데 워크숍에 와서 첫 문서를 쓰는 것까지는 됐지만 두 번째, 세 번째 기여로는 이어지지 않았어요. 길드는 자발적인 모임이라 무언가를 결정하거나 강제할 힘이 없었고요. 무엇보다 문서 쓰는 일은 늘 우선순위에서 밀렸고, 한번 올라온 문서도 시간이 지나면 갱신되지 않았어요.

예를 들어 워크숍에 온 한 분은 자주 받는 질문을 문서로 정리하다가, 어느 수준으로 써야 할지 막막해했어요. 우리 팀이 실무에 바로 쓰려면 디테일을 더 넣어야 했지만, 그 디테일은 다른 팀이 우리 팀 맥락을 훑어볼 땐 오히려 노이즈였거든요. 같은 내용을 개발자에게 맞춰 변수명까지 써 두면 개발자에게는 유용해도 비개발자는 읽기 어려워졌고요. 무엇을 어느 깊이로, 누구에게 맞춰 남겨야 하는지 정해진 게 없으니 글쓴이 혼자 매번 판단할 수밖에 없었어요.

여기서 두 번째 배움을 얻었어요. 사람들은 문서화에 관심이 없는 게 아니었어요. 무엇을, 어디에, 어디까지 남겨야 하는지, 내가 쓴 게 맞는지 확인받을 구조가 없었을 뿐이에요. 문서화 문화는 이런 활동만으로는 생기지 않았어요. 문서화가 일하는 흐름 안에 들어오고, 한 사람의 노력이 아니라 팀의 책임으로 인정받을 때 비로소 지속됐습니다.

자동화가 드러낸 진짜 문제

그래서 자동화가 필요했어요. 사람이 큰맘 먹고 문서를 쓰는 구조가 아니라, 일하는 과정에서 지식이 저절로 생기고 갱신되는 구조로 바꾸는 거였어요. 그사이 커머스 위키는 일하는 데 필요한 지식을 한곳에 모아 둔 문서로 자리를 잡았는데요.

이 공간을 채우는 일을 이제 사람이 하지 않습니다. 매일 밤 AI가 두 가지 신호를 보고 문서 초안을 만드는데요. 하나는 제품 변경을 알리는 공지예요. 배포나 정책 변경 공지가 올라오면 반영할 내용을 추려 문서를 갱신할 초안을 만들어요. 동시에 커머스 질의 응답봇의 질의응답 결과도 살펴봅니다. 봇이 답하지 못한 질문은 문서에 그 지식이 아직 없다는 신호라, 자동 작업이 관련 자료에서 근거를 모아 초안을 쓰고 바로 검토할 수 있게 올려둬요. 사람은 AI가 올린 초안을 열어 근거를 확인하고 승인하면 됩니다. 빈 화면 앞에서 문서를 시작하는 일은 이제 사람의 몫이 아니게 된 거죠.

이 자동화 덕분에 문서를 처음부터 쓰는 부담은 크게 줄었어요. 그러나 여전히 남은 문제가 있었습니다. AI가 여러 맥락을 모아 문서를 만드는 작업은 곧잘 해냈죠. 그런데 이번엔 비슷한 문서가 자꾸 쌓여 무엇이 최신인지 알 수 없었고, 가끔 봇은 낡은 정책을 근거로 태연히 틀린 답을 내놓기도 했습니다.

도구는 정보를 더 빨리 모으고 초안을 더 쉽게 만들어요. 하지만 '이 문서를 믿어도 되는가', '이 정책은 누가 책임지는가', '이건 현행 정책인가 아니면 끝난 실험의 기록인가'는 도구가 대신 정해주지 못했어요. 자동화는 문제를 없앴다기보다, 기준이 없다는 사실을 더 또렷하게 보여줬습니다.

기준과 책임으로 문제 해결하기

커머스에서 가장 크게 느낀 건, 문서를 더 많이 만든다고 문제가 풀리지는 않는다는 점이었어요. 그때부터 스스로에게 하는 질문도 "문서를 어떻게 만들까?"가 아니라 "어떻게 믿을 수 있는 지식을 만들까?"로 바뀌었어요. 믿을 수 있는 지식을 만드는 건 도구만으로 해결할 수 없었어요. 담당자가 바뀐 정책은 어떻게 다시 검증해야 하는지, 오래된 결정이 담긴 문서는 언제 폐기해야 하는지, 같은 주제의 문서가 여러 개일 때 어떤 문서를 믿어야 하는지를 도구가 정해주지는 못하니까요.

실제로 정책 담당자가 바뀌었는데, 기존 검수 기준이 왜 그렇게 정해졌는지 아무도 설명하지 못해 정책 정비가 막힌 적이 있었어요. 누가 문서를 안 써서가 아니라, '이건 조직에 남겨야 한다'는 기준이 없고 남긴 뒤 누가 관리할지 정해지지 않아서 구조적으로 생긴 일이었습니다. 그래서 저는 커머스에서 이 문제를 함께 정하자고, '커머스 문서·지식 거버넌스'를 챕터에 처음 제안했어요. 문서와 지식을 누가, 언제, 어떤 기준으로 만들고 관리하고 폐기할지를 이해관계자가 함께 정하고, 규칙을 한 번 정하고 끝내는 게 아니라 적용해 보고 다시 고치자는 것이었습니다.

이 고민은 커머스에만 머물지 않았어요. 다른 조직에서도 문서화 도구가 제대로 작동하려면, 거기에 맞는 정책과 거버넌스가 함께 필요했습니다. 그래서 Technical Writing Chapter는 도메인과 챕터 문서화를 하며 그동안 고민한 내용을 모아, 토스 팀 전체가 함께 지킬 정책으로 정리했어요.

그렇게 다음과 같은 토스 팀의 지식 관리 기준이 나오게 되었습니다.

토스 팀의 지식 관리 기준

• 아는 것은 조직에 남긴다: 반복해서 묻는 질문, 중요한 의사결정, 새로 온 사람이 알아야 하는 내용 세 가지는 무조건 조직의 지식으로 만듭니다.
• 남긴 지식은 찾을 수 있게 정리한다: 사람이 검색해도, AI가 참조해도 필요한 정보를 찾을 수 있게 지식을 분류·구조화합니다. 분류 체계를 어떤 기준으로 짤지는 팀 성격에 맞게 정해요. 대표적으로 이렇게 나눌 수 있어요.
  • 기술 레이어 기준: 지식이 다루는 기술 단계로 나눠요. 데이터나 시스템이 거치는 흐름이 뚜렷한 팀에 잘 맞아요.
  • 서비스 도메인 기준: 지식이 다루는 서비스 영역으로 나눠요. 담당하는 도메인이 여러 개로 구분되는 팀에 잘 맞아요.
  • 기능 단위 기준: 지식이 설명하는 시스템이나 기능으로 나눠요. 기능별 경계가 분명한 팀에 잘 맞아요.
• 필요한 순간에 쓸 수 있게 한다: 문서는 저장만 해두지 않고, 질문봇이나 GitHub 등에서 업무 흐름 안에서 바로 활용될 수 있게 연결합니다.
• 정확한 정보를 최신으로 유지한다: 책임자와 검토 주기를 정해 팀원들이 오래된 정보를 사용하지 않도록 관리합니다.

이 기준을 만들 때 가장 중요하게 생각한 건 '무엇이 조직의 지식인가'였어요. 단순히 글로 적혀 있다고 모두 지식은 아니니까요. 저희는 사람이 특정 상황을 이해하고 더 나은 결정을 내리는 데 도움이 되는 정보만 지식이라고 봤습니다. 사내 메신저에서 논의한 내용, 업무 도구에 남은 판단도 맥락이 확실하고 내용 검증을 거쳐야 조직의 지식으로 남을 수 있는 거죠.

또, 지식을 처음 남기는 순간부터 필요한 사람이 찾아 쓰고 다시 검토하는 순간까지, 지식이 조직 안에서 신뢰할 수 있게 유지되기 위해 필요한 모든 과정을 기준에 담으려고 했습니다. 지식은 쌓아두는 것보다, 계속 믿고 쓸 수 있는 상태로 유지하는 일이 더 중요하다고 봤기 때문이에요.

Knowledge Committee가 하는 일

물론 기준을 세우는 것만으로는 충분하지 않습니다. 정한 기준대로 잘 운영되고 있는지 계속 확인하고 고쳐가지 않으면, 지식이 제대로 관리되지 않는 문제가 다시 생기니까요. 그래서 제안한 게 Knowledge Committee예요. Knowledge Committee는 토스 팀 전체가 따르는 문서 운영 기준을 정의하고, 유지하고, 조직 간에 기준이 부딪힐 때 조율하는 협의체예요. 정해진 구성원이 의사결정 권한을 갖고, 그 결정이 조직 안에서 실제 효력을 갖는다는 점이 길드와 달라요.

운영은 두 층으로 나눴어요. TW 챕터는 전사에 걸친 지식 관리 기준을 맡아요. 무엇을 문서로 볼지, 어떤 상태로 남길지, 출처와 책임자를 어떻게 다룰지 같은 공통의 기준을 정비하죠. 각 도메인과 챕터는 그 기준 안에서 자기 영역을 운영해요. 어떤 문서를 기준으로 삼을지, 누가 책임질지, 언제 갱신하거나 폐기할지는 현장을 가장 잘 아는 사람들이 정해요.

이렇게 나누는 이유는 단순해요. 전사 기준이 없으면 도메인마다 지식이 제각각으로 쌓이고, 그렇다고 중앙에서 모든 운영을 정하면 현장의 속도를 따라갈 수 없거든요.

예를 들어 실험을 자주 하는 커머스의 한 조직에서 '배포 후에는 문서를 갱신한다'는 기준을 기계적으로 적용하면, 잠깐 켰던 실험 정책이 그대로 남아 혼란을 줄 수 있어요. 나중에 누군가 그 정책을 물으면 봇이 이미 끝난 실험을 현행 정책이라 답하기도 하고요. 이런 예외를 각 조직이 커미티로 가져오면, 커미티는 확정 배포와 실험 배포를 구분하는 규칙을 기준에 더하고, 보완된 기준을 다시 모든 조직에 전파해요. 각 조직의 시행착오가 토스 팀 전체의 노하우가 되는 거죠.

개인의 기억이 조직의 지식이 되도록

지금까지 시리즈에서 소개한 여러 도구와 자동화, 또 앞으로 만들어 갈 제도적·문화적 노력까지 모두 Technical Writing Chapter가 토스 팀의 지식 시스템을 만들기 위한 시도입니다. 저희가 꿈꾸는 것은 지식이 개인의 기억이나 흩어진 기록에만 머무르지 않고, 조직 안에서 계속 쌓이고 다시 쓰이는 조직이거든요.

그리고 이 지식 시스템을 토스 팀 곳곳에 전파하려고 합니다. 지식이 만들어지고, 검증되고, 다시 쓰이는 흐름이 특정한 사람의 노력에 기대지 않고 자연스럽게 자리 잡게 만드는 거예요. 이렇게 된다면 지식을 남기는 일은 따로 마음먹고 해야 하는 숙제가 아니라, 그냥 일하는 방식의 일부가 됩니다. 이때쯤에는 TW 챕터가 없어져도 되지 않을까요?

지금까지 저희의 여정을 여섯 편의 글로 공유드렸어요. 토스의 TW들은 라이팅에만 머무르지 않고, 그동안 쌓은 경험을 바탕으로 시스템을 설계하고 제품과 거버넌스를 만들어 가는 역할로 나아가고 있습니다. 신뢰할 수 있는 지식을 쌓아두고, 누구나 찾을 수 있게 하는 것. 그리고 일하면 지식이 쌓이고, 그렇게 쌓인 지식이 다음 사람의 출발점이 되는 조직이 저희가 꿈꾸는 모습입니다.