토스 문서화 거버넌스 공부 정리 | 기준 없는 자동화가 헛도는 이유

토스 테크 블로그에서 Technical Writer 시리즈를 읽다가 마지막 편인 “6. 도구를 넘어, 기준과 책임으로”를 먼저 읽게 됐다. 제목에서 기대한 건 문서화 툴 추천 같은 글이었는데, 실제로는 꽤 다른 이야기가 들어있었다.

자동화도 해보고 AI도 도입했는데 결국 잘 안 됐다는 경험담이었다. 그 이유로 짚은 부분이 흥미로워서 좀 더 읽어봤다.

1️⃣ 이게 뭐냐?

토스 TW 팀에서 문서화 워크숍을 열고 문화를 만들려 했는데 지속이 안 됐다는 얘기에서 글이 시작한다. 워크숍 참여는 있었지만 2차 기여로 이어지지 않았고, AI로 자동화한 문서는 시간이 지나면서 낡은 정보로 잘못된 답변을 내놓기 시작했다.

이유로 짚은 건 기준이 없었다는 점이었다. 글을 쓰려는 사람이 “어느 깊이로, 어떤 독자에게 맞춰 쓸지”를 매번 혼자 판단해야 했다. 의지가 있어도 시작하기 어려운 구조였던 것 같다.

그래서 세운 게 기준과 책임 구조였다. 무엇을 조직 지식으로 남길지부터 정하기로 했다. “반복해서 묻는 질문, 중요한 의사결정, 새로 온 사람이 알아야 할 것.” 기준이 있으니 각 문서에 책임자와 검토 주기를 붙이는 것도 자연스럽게 따라왔다.

거버넌스 구조도 이중으로 만들었다. 전사 기준은 TW 챕터가 관리하고, 도메인별 예외나 세부 운영은 각 조직이 자율적으로 맡는다. 중앙에서 전부 통제하면 현장 속도를 따라가기 어렵고, 현장에만 맡기면 기준이 흩어진다는 두 문제를 함께 풀려 한 것 같았다.

2️⃣ 내가 든 생각

AI 자동화가 오히려 신뢰를 잃게 된 대목이 흥미로웠다. 낡은 정보로 틀린 답변이 나오자 사람들이 참조를 멈췄다고 한다. “정확성은 기술이 아니라 소유권과 검토 주기로 담보된다”는 표현이 나왔는데, 이 말이 꽤 오래 남았다.

자동화가 없어서 실패한 게 아니라, 자동화된 결과물에 “이건 누가 책임지고 언제 확인하는가”가 없어서 신뢰가 무너진 거라는 것이다.

디자인을 공부하다 보면 이 상황이 컴포넌트 라이브러리를 만들 때와 자꾸 겹쳐 보인다. 구현이 아무리 잘 돼있어도 “어떤 상황에서 쓸지, 누가 관리할지”가 없으면 각자 다르게 쓰다가 결국 흩어지는 것처럼. 도구보다 기준이 먼저여야 한다는 게, 문서화에서도 같은 결론인 것 같았다.

문화 조성을 먼저 시도한 게 실패 원인 중 하나였다는 부분도 인상적이었다. 기준 없는 문화란 결국 각자 자기 방식으로 하는 것이고, 그러면 나중에 통일하기가 더 어려워진다. 기준이 먼저 잡혀야 그 위에 문화가 생기는 순서인 것 같았다.

👉🏻 기준 없는 자동화는 신뢰를 쌓는 게 아니라 오히려 깎아낼 수도 있다는 게 공부하면서 든 생각이었다.

💡 여기서 드는 질문? 지금 내가 쓰고 있는 도구들에 기준이 있는가? 아니면 있다고 가정하면서 쓰고 있는 건가?

⭐️ 마지막으로, 기준과 책임의 자리를 공부하며 느낀 점

정리해보니 이 글은 문서화 방법 이야기라기보다 기준 없는 시스템이 어떻게 실패하는가에 관한 이야기에 가까웠다. 자동화가 없어서 실패한 게 아니라, 기준이 없어서 자동화가 헛돌았다는 것. 디자인 시스템을 공부할 때 자꾸 만나던 “도구보다 정의가 먼저”라는 말이 여기서도 같은 결론으로 이어졌다.

---

참고 원문: 6. 도구를 넘어, 기준과 책임으로