토스 토독 사례…문서를 쉽게 쓰는 도구에서 유효한 지식을 유지하는 시스템으로

ARCH-B

ARCH-B

토스테크 기반 · 2026년 10월 12일 · 5분 분량

0

한눈에 보는 핵심요약

토스가 토독의 설계와 테크니컬 라이터의 제품 개발 역할을 영문 연재로 소개했다. 작성 장벽, 자료 분산과 문서의 낡은 정보를 해결하려는 사내 플랫폼 사례다. AI 연결과 자동 초안 제공의 현재 설명을 문서의 지속적 갱신이라는 개발 목표와 구분해 살펴본다.

  • 토독은 사내 문서 플랫폼 사례이며 9월 영문 글은6월 한국어 연재의 공개판이다.
  • 직접 작성·자료 연결·API/CLI/MCP 활용과 팀별 문서 공간을 설계했다고 설명했다.
  • AI 편집·초안 지원과 별도로 지속적 갱신·유효한 지식 판별은 계속 해결하는 과제다.
토스 토독 사례…문서를 쉽게 쓰는 도구에서 유효한 지식을 유지하는 시스템으로
이미지 제공: 토스테크 · 원출처 기사

문서 전문성을 사내 제품의 판단으로 옮겼다

토스는 9월 7일 영문 연재 둘째 편에서 사내 문서 플랫폼 토독을 소개했다. 6월 19일 한국어 원문을 영어로 공개한 글이며 새 외부 서비스 출시가 아니다. 한주연 Knowledge System Team 리더는 개발자·디자이너·테크니컬 라이터와 로드맵과 우선순위를 정하고 사용자 인터뷰와 기능 구현에도 참여한다고 설명했다. 문서의 요구를 전달하는 역할에서 제품을 결정하는 역할로 넓어진 경험이다.

토스는 2025년 10월 토독 베타를 열었다고 설명한다. 원문은 출시 약 반년 뒤의 규모로 문서 500개 이상, 유효한 페이지 4만 개 이상과 월 사용자 1,000명 이상을 제시했다. 이는 회사가 소개한 해당 시점의 내부 수치이며 9월의 새 측정이나 생산성 향상을 독립적으로 입증한 자료는 아니다. 사용자 수요와 채택 규모를 보여 주는 맥락으로 제시됐다.

작성 장벽·문서 부채·자료 분산을 함께 다룬다

기존 정적 사이트 생성기 기반 문서는 작은 수정에도 저장소 복제, Markdown 작성과 PR 검토를 거쳐야 해 비개발자의 진입 장벽이 높았다고 밝혔다. 다른 문서 도구에는 작성자와 날짜가 불명확한 메모, 오래된 정책과 미완성 기록이 쌓였다고 설명한다. 팀마다 고른 도구와 코드, 대화에 지식이 흩어져 믿을 수 있는 자료를 찾기도 어려웠다는 진단이다.

토독은 누구나 직접 작성·편집하도록 하고 GitHub와 다른 문서 도구, 사내 메신저의 정보를 연결하는 방향으로 설계됐다. 자체 봇이나 API, CLI와 MCP를 통해 AI가 자료를 활용할 수 있다고 설명한다. 하나의 플랫폼 안에서 팀마다 문서 공간을 쓰게 해 새 팀이 도구와 기반 시설을 다시 고르는 부담도 줄이려 했다. 첫 편의 문서 전달 챗봇에서 조직 지식 플랫폼으로 범위를 확장한 사례다.

초안 지원 다음에는 지식의 유효성이 남는다

원출처는 테크니컬 라이터의 문서 기준을 AI 편집과 자동 초안 봇에 반영했다고 설명했다. 하지만 누구나 쉽게 문서를 만들수록 품질 관리가 어려워지고, 별도로 문서화할 시간을 내는 부담도 남았다고 밝혔다. 따라서 업무 중의 결정과 토론, 코드가 자연스럽게 문서로 이어지도록 제품을 설계하고 있다고 소개한다.

결정 뒤의 코드 변경과 논의를 관측해 문서를 갱신하고 정책이 실제 구현과 일치하는지 판단하는 시스템은 계속 해결하는 과제로 제시됐다. 문서의 낡은 정보를 감지하고 담당자에게 알리며 프로젝트 기록을 저절로 남기는 하루에 대한 글의 마지막 설명은 미래 구상이다. 글을 수집하거나 생성할 수 있다는 기능과 모든 지식을 스스로 최신 상태로 유지한다는 완성된 보장은 다르다.

ARCH.B 분석

접근이 쉬워지는 만큼 신뢰 기준도 필요하다

토독 사례의 핵심 문제는 자료가 없다는 데만 있지 않다. 자료가 많아도 어느 정책이 현재 유효한지 알 수 없으면 사람이든 AI든 잘못된 판단에 사용할 수 있다. API나 MCP로 접근하기 쉬워지는 것은 활용의 조건이지만 신뢰의 조건을 자동으로 충족하지 않는다. 출처와 담당자, 갱신 이력 같은 기준이 문서의 내용과 함께 전달되는지 살펴볼 이유가 있다.

문서의 수와 조회 이용자 수는 채택을 판단할 자료이며 답변의 정확도나 업무 완료율과는 다른 지표다. 팀이 유사한 플랫폼을 만든다면 반복 질문에 실제로 도움이 됐는지, 최신 정책을 찾을 수 있는지와 수정할 담당자를 알 수 있는지를 따로 볼 수 있다. 더 많은 페이지를 모으는 목표만으로는 원출처가 진단한 오래된 정보와 문서 부채의 문제를 해결하기 어렵다.

ARCH.B 분석

문서 생성과 정책 판단의 책임을 연결한다

토론에서 초안을 자동으로 만들면 사람이 다시 정리하는 비용을 줄일 여지가 있다. 그러나 토론에는 검토 중인 대안과 최종 결정이 함께 남을 수 있다. 이를 모두 같은 수준의 확정된 지식으로 저장하면 나중에 읽는 사람과 에이전트가 의도를 구분하기 어렵다. 어떤 사건이 문서를 만들고 누가 유효성을 확인하는지를 정해야 업무 기록이 신뢰할 지식으로 바뀐다.

코드 변경도 정책 변경을 곧바로 뜻하지 않는다. 구현과 문서를 비교할 수 있는 연결은 유용하지만 불일치가 발견됐을 때 어느 쪽을 고칠지 판단할 업무 맥락이 필요하다. 테크니컬 라이터의 전문성을 시스템에 반영한다는 방향은 이러한 기준과 검토 흐름을 제품에 넣는 문제로 읽힌다. 도입 성과는 자동 생성량보다 조직이 유효한 자료를 유지하고 사용할 수 있는지에서 평가할 수 있다.

출처

토스테크의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.

2. Beyond Our Expertise (새 창)

Share

Related

함께 읽기 좋은 글