살려 낸 101번 째 문서 시스템: (2) AI 시대, 문서의 가치
앞서 이야기 한 문제를 해결하기 위해 문득 생각난 RAG 기반의 챗봇을 도입했다. 업무 메신저에 챗봇을 붙이고, 챗봇에게 문서에 있는 내용을 물어보게 했다. 문서 사이트에 들어가 읽는 방식이 아니라 업무 메신저에 질문하고 답변을 받는 방식으로 바꾸자 실질적인 문서 콘텐츠 활용량이 엄청나게 늘었고, 다들 편리하다며 좋아했다.
챗봇을 사용해 문서 접근성을 높이면서 깨달은 건, 답변의 기반이 되는 문서가 무엇보다 중요하다는 점이었다. 봇은 쉽게 붙일 수 있지만, 인풋인 정보가 잘 정리되어 있지 않으면 좋은 답을 얻을 수 없었다. 그래서 나는 좋은 문서를 쓸 수 있는 역량이 곧 중요한 AI 활용 역량이라고 생각하게 됐다.
AI의 등장으로 테크니컬 라이팅이 가장 빠르게 대체될 거라고 예상했지만, 실제로는 정반대였다. 팀을 위해 구조화되고 이해하기 쉬운 정보를 만드는 일은 테크니컬 라이팅의 핵심 원칙이자 지금까지 내가 해온 일과 같았다.
그리고 또 하나, 늘 가지고 있던 '문서가 도움이 될까?'라는 의문도 오히려 해소됐다. 요즘은 개발자들도 알아서 마크다운 형식으로 각자의 문서를 만들곤 한다. 코딩에 AI를 활용하면서 Cursor 룰이나 Claude에게 적용할 학습 문서를 만드는 것이다. 결국 AI에게 일을 잘 시키려면 프롬프트나 문서로 내가 하고 싶은 것을 설명하고 맥락을 이해시키는 게 자연스럽게 중요해졌다.
이런 상황에서 테크니컬 라이터의 역할은 조금 달라진다고 생각한다. 단순히 기술 문서를 작성하는 데 그치지 않고, AI가 이해할 수 있도록 글쓰기 원칙을 만들고 개선할 수 있어야 한다. 나아가 조직의 중요한 정보를 체계적으로 문서화하고 이를 활용할 수 있는 지식 시스템을 설계하는 일까지 포함해 볼 수도 있을 것이다. 즉, 개인의 글쓰기 역량을 조직의 역량으로 확장(scale-up)하는 것이 테크니컬 라이터의 과제가 된 것 같다.
확장하는 테크니컬 라이팅
왜 테크니컬 라이터의 역량을 조직의 역량으로 확장해야 할까? AI가 정말로 유용하게 사용되려면 단순한 데이터가 아니라 조직 내부의 정보가 필요하다. AI는 외부에 공개된 정보는 어느 정도 학습하고 있지만 우리 조직만의 맥락과 히스토리는 모르기 때문이다. 그래서 앞으로 AI를 사용해 팀의 업무를 자동화하고 싶은 조직이라면 문서화는 선택이 아니라 필수다. 문서가 곧 조직의 자산이자, 역량의 기반이 될 것이다. 하지만 조직에 흐르고 있는 수많은 정보를 한 두명이 문서화 할 수는 없다. 따라서 테크니컬 라이터의 역량은 조직에 확산돼야 한다.
그런데 그 확산 전략이 ’수십, 수백명의 구성원 모두가 테크니컬 라이터처럼 문서화를 할 수 있다’여야 할까? 그보다는 좀 더 현실적이고 자연스럽게 문서 시스템을 만드는 것이 효율적일 것이다. 지금까지 누군가의 학습을 돕기 위해 문서를 작성해 온 테크니컬 라이터들이 바로 우리 조직이 어떻게 지식을 남기고, 관리하고, 활용할지 그 시스템을 가장 잘 설계할 수 있는 사람들이라고 생각한다.
문서로부터 질적 변화 만들기
앞으로는 이렇게 문서화한 내용 뿐 아니라 사람들이 문서를 기반으로 AI와 함께 나눈 대화, 질문한 내용도 전부 다 유의미한 데이터로 회사에 중요한 자산이 될 것이다. 예를 들어 신규입사자가 가장 자주하는 질문이 무엇인지에 대한 데이터를 쌓아두면, 온보딩 과정에서 꼭 필요한 정보를 빠르게 보완할 수 있고, 조직이 어디서 반복적으로 지식의 공백을 겪고 있는지도 파악할 수 있다. 이렇게 축적된 기록은 조직의 업무 효율을 높이고, 학습 문화를 개선하는 중요한 기반이 된다.
실제로 프론트엔드 챕터는 온보딩 문서가 1년 간 계속 발전해서 이제 신규입사자가 주변 동료나 메이트(신규입사자의 버디)에게 궁금한 점을 물어볼 일이 거의 없어졌다. 메이트 바이 메이트로, 사람마다 온보딩 해주는 양과 질이 다르다는 문제도 거의 해소됐다. 신규입사자는 문서에서 필요한 정보를 바로 찾을 수 있고, 실습 프로젝트 문서를 따라하면서 알아서 온보딩한다. 문서를 기반으로 온보딩하면 막히는 부분이나 어려운 지점이 더 빠르게 공유되고, 파악되며, 다시 적용되는 자율적인 시스템으로 굴러가게 된다. 개인 차원에서는 낯선 조직에서 빠르게 적응할 수 있어 좋고, 조직 차원에서도 사람이 해야 하는 일이 시스템으로 대체되어 좋다.
중요한 건 단순히 문서가 온보딩 시간을 줄였다는 양적 차원의 변화뿐 아니라, 일하는 방식 자체를 바꿨다는 질적 차원의 변화라고 할 수 있다. 예전에는 반드시 사람이 시간을 써야 했던 일이, 이제는 문서를 통해 언제든 가능해진 것이다.
더 먼 미래
요즘도 많은 분들이 문서의 필요성을 느끼고 우리 팀에 찾아오고 있다. 규모가 커졌는데 여전히 업무 메신저나 코드를 보면서 파악해야 하는 비효율을 견디기에 임계점이 온 조직이 많기 때문이다. 토스는 내부에서만 사용하는 도구도 많아서, 이 도구를 사용하는 내부 인원의 반복되는 질문을 대응하는데 드는 시간을 줄이고 본 업무에 집중하고 싶은 팀도 많다.
그래서 그동안 만든 문서 시스템을 더 많은 팀에서 사용할 수 있도록 스케일 업 하기로 했다. 스케일 업을 위해서는 문서 작성을 어렵게 하는 허들을 모두 제거해야 한다. 그 중 가장 큰 허들은 문서를 작성하는 도구였다. 지금까지는 GitHub에 연결된 코드로 문서를 만들었지만, 이 방식은 너무 복잡해서 비개발자와 개발자가 모두 불편해했다. Notion은 구조화 된 문서를 만들고 자체적으로 데이터를 관리하기 어렵다. 그래서 자체 문서화 도구를 만들고 있다. 이 도구에서 테크니컬 라이터 없이도 양질의 문서를 쓰고, 리뷰 하고, 손쉽게 배포하고, 봇과 연결하고... 나중에는 앞으로 팀의 방향이나 전략까지 물을 수 있었으면 좋겠다.
이 인프라가 모두 깔리면 조직에서 필요로 하는 사람과 학습하는 방식, 일하는 방식도 많이 달라질 것이다. 반복되는 업무가 사라지고, 사람은 중요한 문제 해결에 집중하면 우리의 일에 또 다른 질적 변화가 생기지 않을까? 아마 모든 정보가 유기적으로 연결되어 제공된다면, 이제 간단한 실험이나 코드 생성은 직군과 상관없이 누구나 쉽게 할 수 있을 것이다. 그때쯤에는 내가 테크니컬 라이터의 일을 재정의한 것처럼 모두가 자신의 일을 새롭게 정의하게 될지도 모른다.
이전 글
Jennybe