2. 전문성 밖으로 나아가기

TW가 제품 오너로 일한다는 것

앞서 토스의 Technical Writer(이하 TW)가 하는 일을 네 가지로 나눠 소개했어요. 그중 첫 번째가 '제품을 만든다'였죠. TW가 제품을 만든다는 게 어떤 의미인지, 제 이야기부터 풀어볼게요.

저는 지금 Knowledge System Team이라는 제품 팀의 리더로 일하고 있어요. 개발자·디자이너·TW와 함께 제품의 방향을 잡고, 로드맵과 우선순위를 정합니다. 사용자를 직접 인터뷰해 인사이트를 팀에 가져오고, 기능을 기획하고, AI 도구로 직접 만들기도 하고요. 단순히 문서와 관련된 요구사항을 전달하는 사람이 아니라, 제품에 대한 판단을 내리고 실제로 만드는 메이커로 일하고 있는 거죠.

TW가 왜 제품을 만들고 있을까요? 이 제품의 핵심이 문서와 지식을 다룬다는 점 때문인데요. TW들은 왜 어떤 문서는 읽기가 어려운지, 무엇이 좋은 문서인지, 어떤 구조여야 AI가 잘 활용할 수 있는지 같은 질문들을 가장 오랫동안 고민하며 기준을 세워왔어요. 그래서 이를 녹인 제품을 만드는데 가장 중요한 인사이트를 제공할 수 있습니다.

저희가 만들고 싶은 끝그림은 TW의 전문성이 하나의 제품으로 확장되어 문서와 실제 업무 워크플로우가 연결되고, 일만 하면 지식이 자동으로 쌓이고, 누구나 쉽게 그 지식에 접근하고 활용하는 모습이에요. 그 목표를 위해 만들고 있는 제품을 소개드릴게요.

TW의 고민이 담긴 제품, ‘토독(todoc)’

문서화 도구가 오랫동안 지속적으로 작동하고, 다른 조직으로도 스케일업을 하려면 어떻게 해야 할까요? 오랜 고민 끝에 작년 10월, 사내 문서 플랫폼 토독(todoc)을 런칭했어요.

작년 10월 베타 오픈 공지를 올리자마자 "지금 바로 써보고 싶어요", "드디어 원하던 문서 플랫폼이 나왔어요" 같은 긍정적인 반응이 많아 놀랐는데요. 이미 문서화를 하고 있는 조직에서도, 아직 문서가 잘 정리되지 않은 조직에서도 AI로 쉽게 연결할 수 있고, 팀의 지식을 쉽게 쌓을 수 있는 플랫폼이 절실했던 것으로 이해했어요.

반년이 지난 지금 토독에는 약 500개 이상의 문서, 40,000개 이상의 유효한 페이지가 쌓였고, 매달 1000명 이상이 사용하고 있습니다.

GitHub이나 문서 툴을 사용하면 되는데 왜 새로운 제품을 만들었을까요? 기존의 내부 문서들은 몇 가지 문제가 있었어요.

먼저 기존에 정적 사이트 생성기(SSG, Static Site Generator)로 만들어져 있는 문서는 비개발자가 사용하기는 어려웠어요. 문서 하나를 고치려면 저장소를 클론해, 마크다운을 작성한 뒤, PR을 올려 리뷰를 받는 등의 과정이 필요한데요. 개발자에게는 익숙해도, 디자이너나 PM에게는 문서를 쓰기도 전에 포기하게 만드는 허들이었습니다.

그리고 기존 문서 툴에는 너무 많은 메모와 '쓰레기 지식'들이 누적되어 있었어요. 누가 언제 왜 썼는지 알 수 없는 내용들, 이미 바뀐 정책을 가리키는 낡은 문서들, 쓰다 만 메모들 등등… 다들 경험해 보신 적 있을 거예요. 이런 상태에서는 기존 문서 툴 자체가 문서 부채라서 양질의 지식을 판별하고 관리하는 것이 거의 불가능해요.

마지막으로 이렇게 지식들이 각자 혹은 팀별로 선택한 도구에 파편화되어 있었어요. SSG로 만든 문서에, 각종 문서 툴에, 코드에, 협업 메신저 속 논의에, 누군가의 머릿속에 흩어져 있었죠. 이렇게 흩어진 소스를 한곳에 모으지 않으면 조직의 지식이 잘 쌓일 수도, 활용할 수도 없을 거라고 판단했습니다.

그래서 토독은 네 가지를 핵심 가치로 잡았어요.

1. 누구나 문서를 쉽게 쓸 수 있어요.

문서화의 모든 장벽을 없앴어요. 토독에서 누구나 곧바로 문서를 만들고 고칠 수 있고, GitHub, 문서 툴, 사내 메신저 등 어떤 소스로 시작하든 토독으로 연결할 수 있어요.

2. 토독에 있는 지식은 AI로 쉽게 활용할 수 있어요.

잘 모으고 관리한 지식은 결국 AI가 쓰기 위한 것이기도 해요. 토독에 문서를 쓰면 AI 활용이 무척 쉬워요. 팀 별로 사용하는 봇과 연결해서 쓸 수 있고, API/CLI/MCP 모두 자유롭게 사용할 수 있죠. 그래서 각 팀에서 요청 봇이나 제품 스펙을 정리하기 위한 용도 등으로 다양하게 활용하고 있어요.

3. 모든 사내 지식을 한 곳에 모아 단일 진실 공급원(SSoT, Single Source of Truth) 역할을 해요.

토독은 흩어진 소스들을 한곳으로 연결해서 완결된 문서를 만들고, "이건 어디서 찾지?"를 고민할 필요가 없게 만들어요. 무엇이 지금도 유효한 최신 지식인지 한곳에서 판별할 수 있으니, 토독이 조직의 단일 진실 공급원 역할을 하는 거죠.

4. 확장 가능한 구조가 된다

어떤 조직이 문서화를 하고 싶을 때 툴을 선택하거나 새로 구축하는 게 아니라, 이미 돌아가는 토독 위에서 시작하면 돼요. 하나의 플랫폼 위에서 각자의 문서 공간을 가질 수 있죠. 지금까지는 문서를 쓰려면 팀마다, 챕터마다 따로 도구를 정해야 하고 인프라를 세팅하거나 관리해야 하는 공수가 들었어요. 토독이 생겼기 때문에 이제 팀원들은 문서를 쓰는데만 집중하면 돼요. 이런 구조를 이제 계열사로도 확장하고 있어요.

남은 과제들

문서의 진입 장벽을 낮추면 많은 사람들이 문서를 쉽게 쓸 수 있지만 동시에 문서의 질은 유지하기가 힘들다는 문제도 생깁니다. 그래서 "어떻게 문서의 질까지 유지할까"도 TW들이 자주 하는 고민인데요. 이전에는 이 고민을 TW가 직접 문서를 리뷰하고, 낡은 문서가 없는지 확인하면서 해결했습니다. 토독에서는 이런 TW의 일을 TW가 판단해온 "좋은 문서의 기준"을 바탕으로 자동화해서 AI 교정 기능이나 문서 봇을 통한 초안 자동화를 제공하기도 했습니다.

그치만 이런 기능들은 여전히 사람들이 직접 문서를 쓴다는 것을 전제로 합니다. 그리고 사용자들을 봤을 때 저는 이것으로는 충분하지 않다고 느꼈어요.

'문서를 쓰겠다'고 따로 마음먹고 완성하기까지는 많은 노력과 시간이 들어요. 그래서 일을 하다 보면 자연스럽게 문서가 생기게끔 하고 있어요. 토독은 사내 메신저에서 오가는 의사결정, 코드, 논의를 자동으로 문서로 만들어줘요. 코드 변경, 의사결정 이후 논의 모니터링을 통해 누군가의 의지에 기대지 않아도 문서가 갱신되는 구조도 만들고 있고요.

단순한 정보 수집과 문서 생성을 넘어, 무엇이 지금도 유효한 지식인지를 가려내는 것이 문서의 핵심이라고 생각해요. 정책과 실제 반영된 코드가 어긋나지 않는지, 이 지식이 실제로 쓰이고 있는지, 얼마나 최신인지 까지 토독 시스템 위에서 풀어 나가고 있어요.

전문성의 확장과 이동

예전에 TW에게 중요한 역량이 좋은 문서를 직접 잘 쓰는 능력에 가까웠다면, 이제는 좋은 문서가 반복해서 나오도록 시스템을 설계하는 능력을 중심으로 일해야 한다고 생각해요. TW가 쌓아온 전문성은 사라지지 않고 다음과 같이 시스템 속에 녹아있습니다.

• "왜 문서가 안 읽히는가"를 고민하던 경험은 → 누구나 쉽게 쓰고, AI가 잘 읽는 문서의 기준이 됐어요.
• "좋은 문서란 무엇인가"에 대한 판단은 → AI 교정과 자동 리뷰의 기준으로 옮겨갔고요.
• 문서가 낡았는지 확인하고, 유효한 지식을 판단하는 역량은 → 무엇이 지금도 유효한 지식인지 판별하는 시스템이 됐습니다.

이 변화 속에서 저희가 하는 일은 명확해요.

1. 흩어진 지식이 모일 곳을 만든다.
2. 좋은 문서의 기준을 정의한다.
3. 그 기준을 사람의 판단이 아니라 시스템으로 옮긴다.
4. 일하는 과정 속에서 문서가 자연스럽게 만들어진다.
5. 그 위에서 지식이 스스로 갱신되게 한다.

토독이 모든 과제를 마친 뒤, 제품 팀 리더이자 TW로써 저의 하루는 이런 모습입니다.

1달 넘은 문서 확인해 달라는 공지를 할 필요가 없어졌다. 토독이 낡은 문서를 감지해서 담당자에게 직접 알림을 보내고 개선점을 제안하고 있었다. 누가 챙기지 않아도 문서는 신뢰할 수 있는 상태였다. 더 이상 프로젝트 관리 도구를 직접 업데이트하지 않았다. 팀이 일하면서 남긴 흔적들이 이미 정리되어 있었다. 주연님은 다음 방향을 고민하는 데만 시간을 썼다. 릴리즈마다 썼던 공지, 문의마다 반복했던 설명들이 남아있어서 새로 온 팀원도, 처음 연동하는 팀원도 같은 질문을 다시 하지 않았다. 이렇게 한 번 일하면 흔적이 남아 모두의 업무 실행 시간이 줄었다. 어느 날 주연님은 노트북을 열었다가 조용히 닫았다. 할 일이 없었다. 토독이 너무 잘 돌아가고 있었다.

이렇게 토스의 Technical Writing Chapter는 TW의 전문성, 기준 자체가 시스템화 되는 것에 집중하고, 나아가 지식 관리 거버넌스를 만들어서 조직마다 문서화를 잘 할 수 있게 만들어 두고 다음 일을 하러 갈 예정입니다.