<div id="readability-page-1" class="page"><div>안녕하세요, 토스 Technical Writing Chapter Lead 한주연입니다. 이번 시리즈에서는 토스의 Technical Writer(이하 TW)들이 어떻게 '문서를 쓰는 사람'에서 '조직의 지식 시스템을 설계하는 사람'으로 일을 넓혀왔는지 이야기해보려고 해요.<hr>"이거 왜 이렇게 되어 있나요?" 회사에서 일하다 보면 하루에도 몇 번씩 듣고, 또 묻는 질문이에요. 코드를 짠 사람의 기억을 함께 더듬거나, 1년 전 업무 메신저 스레드까지 뒤져가며 맥락을 찾으신 적 많으실 거예요. 심지어 이미 사람이 자리를 비우거나 회사를 떠나서 답을 얻을 수 없는 경우도 있죠.특히 요즘은 AI에게 일을 맡기다 보면 이 문제를 더 자주 느끼실 거예요. AI는 일반적인 지식은 잘 알고 있지만, 우리 조직만의 맥락과 히스토리는 모르기 때문에 매번 맥락과 정보를 넣어줘야 해요. 흔히 코드가 SSoT(Single Source of Truth)라고들 해요. 그런데 코드에는 '결과'만 남아요. 무엇을 하는지는 적혀 있어도, 왜 이렇게 짰는지, 어떤 결정을 거쳐 여기까지 왔는지는 빠져 있죠. 주석 하나 없는 코드 앞에서 한참 헤매본 경험, 다들 있으실 거예요.저는 그래서 문서화가 여전히 중요하다고 생각해요. 진짜 SSoT는 코드와, 그 코드를 둘러싼 맥락이 함께 있어야 비로소 완성됩니다. 코드가 왜 그런지는 결국 우리가 알려줘야 하죠. AI에게 일을 시키려면, 우리가 아는 걸 먼저 어딘가에 남겨야 합니다. 그래서 Technical Writing Chapter는 이 부분을 채우기 위한 일을 하고 있습니다.그런데 단순히 이 맥락을 채우기 위한 문서를 쓰는 것이 저희의 일은 아닙니다. 제가 처음 토스 커뮤니티에 합류했던 5년 전과 지금을 비교해 보면, TW가 하는 일은 많이 달라졌습니다.<figure id="383a360d-33e3-8015-89b2-d3adb9d39f75"><img src="https://static.toss.im/ipd-tcs/toss_core/live/270b98b2-b315-4c45-be6e-c3b911eb99cd/image.png" alt=""></figure>또, 일의 목표도 달라졌습니다. 올해 목표는 사람이 문서를 직접 쓰지 않아도 지식이 쌓이게 만드는 것입니다. 그리고, Technical Writing Chapter의 궁극적인 목표는 사라지는 것입니다.TW를 떠올렸을 때 어떤 일을 할 거라고 생각하셨나요? 사실 저는 TW가 AI에게 가장 먼저 대체될 거라고 생각했었는데요. 제 예상과는 반대로 할 일이 더 넓어지고 많아진다고 느낍니다. 기술 문서를 쓰는 역할을 하던 TW가 어떻게 위와 같은 일을 하고, 이런 목표를 가지게 됐을까요?<h3 id="383a360d-33e3-8035-9bbd-d1e005cecb94">문서를 쓰는 일에서, 직접 찾아가는 방향으로</h3>제가 사내 문서화를 처음 시작했을 때 가장 먼저 했던 일은 프론트엔드 챕터의 온보딩 문서 만들기였어요. 그런데 내부 문서를 만들면서 계속 마음에 걸리는 게 있었어요. 저는 Technical Writing의 목표가 글을 잘 쓰는 게 아니라 독자가 문제를 해결하고 목표를 이루도록 돕는 것이라고 생각하거든요. 그런데 문서가 아무리 좋아도, 사람들은 필요한 것만 찾지 처음부터 끝까지 읽진 않습니다. 사실 저조차도 그렇고요. 그래서 문서를 쓴 뒤 링크를 던지는 것 말고, 어떻게 하면 사람들이 이 내용을 실제로 활용하게 할지를 고민하게 됐어요.고민하다 만든 게 ‘<a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/toss-frontend-ai-docs">박씨’라는 챗봇</a>이었어요. (*참고: <a target="_blank" rel="noreferrer noopener" href="https://www.youtube.com/watch?v=zlXsomDPQ_U">TMC25 - 100번 실패하고 살려 낸 문서 시스템</a>) 사람들이 매일 쓰는 메신저와 IDE 안에서, 대화하듯 물어보면 기존 문서를 근거로 출처까지 달아 답해주는 챗봇이에요. 지금은 많은 곳에서 익숙해진 것처럼 문서를 찾아오게 하는 대신, 문서가 사람들이 일하는 자리로 찾아가게 만든 거죠.<figure id="383a360d-33e3-80bc-80f7-ebded3aaf1f5"><img src="https://static.toss.im/ipd-tcs/toss_core/live/1ab8dff9-dd40-4d21-acb5-a0a259471e87/image.png" alt=""></figure>흥미로운 건 그다음이었어요. 문서를 쓰는 것도 읽는 것도 관심이 없었던 팀원들이 찾아오기 시작했어요. "우리 챕터도, 우리 조직도 이런 걸 만들고 싶다"고 하면서요. 조직의 크기가 커지면서 다들 반복되는 질문에 답하는 데 지쳤고, 암묵지를 사람이 아니라 시스템에서 얻고 싶어 했어요. 마침 AI가 빠르게 발전하면서 "AI에게 일을 시키려면 문서가 필요하다"는 흐름까지 더해졌죠.오랫동안 귀찮은 일 취급받던 문서가 갑자기 모두가 원하는 것이 된 게 신기하기도 했습니다. 이런 흐름 속에서 저는 팀원 모두가 쓸 수 있는 지식 시스템 제품을 만들기 시작했습니다. 이 제품은 다음 글에서 자세히 소개할게요. <figure id="383a360d-33e3-8048-9f7c-ef80a511d940"><img src="https://static.toss.im/ipd-tcs/toss_core/live/e7fb7b6f-64d9-413b-b9e1-666cfdf06da7/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2026-06-17_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_4.23.01.png" alt=""></figure><h3 id="383a360d-33e3-802f-9842-dcebcae1ecc1">문서에서 지식 시스템으로</h3>그때부터 TW들은 직무에 갇히지 않고 일을 넓혔어요. TW는 이제 문서를 쓰는 사람이 아니라, 위와 같이 각 조직에 맞는 지식 시스템을 설계하는 사람이 되어야 한다고 판단했어요. AI가 점점 더 많은 일을 하는 지금, 조직에 흩어진 지식과 암묵지가 문서화되는 게 정말 중요하다는 생각도 들었습니다.잘 만든 지식 시스템은 두 가지 가치를 가집니다. 위로는 조직 전체의 생산성을 끌어올리고, 아래로는 모든 팀원이 쉽고 빠르게 적응할 수 있도록 하방을 막아줍니다. 조직이 커질수록 질문이 늘고 커뮤니케이션 비용이 급증하기 때문에 잘 설계된 지식 시스템은 우리가 일하는 속도와 품질을 지켜주는 중요한 인프라입니다.지금 토스의 Technical Writing Chapter가 하는 일은 크게 네 파트로 나뉩니다.첫 번째, 제품을 만들어요. 사내 지식을 관리하는 플랫폼 '토독'을 직접 만들고 운영하는 팀을 이끌고 있어요. 두 번째, 각 조직에 들어가 문서화를 주도해요. 각 조직에 맞는 방식으로 흩어진 지식을 모으고, 활용도를 극대화합니다. 조직마다 필요한 지식 시스템의 성격이 달라서 접근 방식도 달라져요.세 번째, 이 과정에서 사람이 하는 Technical Writing을 없앱니다. AI 워크플로와 자동화로 모두가 비슷한 품질로 문서를 쓰고 리뷰 받을 수 있게 합니다.<figure id="383a360d-33e3-8075-a934-fa084a8244c0"><video muted="" loop="" autoplay="" playsinline=""><source src="https://static.toss.im/ipd-tcs/toss_core/live/de7f0294-9359-499e-9c11-ff2ccf6bfaa4/%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB_%E1%84%80%E1%85%B5%E1%84%85%E1%85%A9%E1%86%A8_2026-02-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_11.36.39_(1)_(1).mp4"></video></figure><figure id="383a360d-33e3-8041-9a3d-e6ebde4111bb"><img src="https://static.toss.im/ipd-tcs/toss_core/live/d96ae646-ca67-4a12-b33f-87d938db261b/image.png" alt=""></figure>마지막으로, 토스의 문서화 문화를 만듭니다. 전 커뮤니티 대상으로 AI가 잘 읽을 수 있는 문서를 쓰는 방법 같은 주제로 세션을 열어요. 또 조직별로 문서화 길드와 지식 커미티를 운영하며 토스 곳곳에서 지식을 다루는 방식 자체를 바꿔 나가고 있어요.<h3 id="383a360d-33e3-80ac-b888-eff2647c0ea7">이 시리즈에서 다룰 이야기</h3>이 시리즈에서는 앞으로 이런 이야기를 들려드릴게요.저희 직무의 이름은 여전히 ‘Technical Writer’지만, 실제로 하는 일은 조직의 지식 인프라를 설계하는 것에 가까워요. 정해진 직무를 수행한 게 아니라, 풀어야 할 문제를 따라가다 직무를 새로 그린 거죠. 그러다 어느새 업계 어디에도 없는 모습이 됐습니다.그리고 이건 Technical Writing만의 이야기가 아니라고 생각해요. AI가 모든 직군의 일을 다시 정의하는 지금, 자기 직무의 외연을 스스로 넓히는 일은 누구에게나 열려 있는 선택지니까요. 한 명이었던 챕터가 셋이 되고 더 많은 동료를 찾고 있는 지금, 저희 이야기를 하나씩 풀어볼게요.</div></div>

토스테크

안녕하세요, 토스 Technical Writing Chapter Lead 한주연입니다. 이번 시리즈에서는 토스의 Technical Writer(이하 TW)들이 어떻게 '문서를 쓰는 사람'에서 '조직의 지식 시스템을 설계하는 사람'으로 일을 넓혀왔는지 이야기해보려고 해요.
"이거 왜 이렇게 되어 있나요?" 회사에서 일하다 보면 하루에도 몇 번씩 듣고, 또 묻는 질문이에요. 코드를 짠 사람의 기억을 함께 더듬거나, 1년 전 업무 메신저 스레드까지 뒤져가며 맥락을 찾으신 적 많으실 거예요. 심지어 이미 사람이 자리를 비우거나 회사를 떠나서 답을 얻을 수 없는 경우도 있죠.
특히 요즘은 AI에게 일을 맡기다 보면 이 문제를 더 자주 느끼실 거예요. AI는 일반적인 지식은 잘 알고 있지만, 우리 조직만의 맥락과 히스토리는 모르기 때문에 매번 맥락과 정보를 넣어줘야 해요. 흔히 코드가 SSoT(Single Source of Truth)라고들 해요. 그런데 코드에는 '결과'만 남아요. 무엇을 하는지는 적혀 있어도, 왜 이렇게 짰는지, 어떤 결정을 거쳐 여기까지 왔는지는 빠져 있죠. 주석 하나 없는 코드 앞에서 한참 헤매본 경험, 다들 있으실 거예요.
저는 그래서 문서화가 여전히 중요하다고 생각해요. 진짜 SSoT는 코드와, 그 코드를 둘러싼 맥락이 함께 있어야 비로소 완성됩니다. 코드가 왜 그런지는 결국 우리가 알려줘야 하죠. AI에게 일을 시키려면, 우리가 아는 걸 먼저 어딘가에 남겨야 합니다. 그래서 Technical Writing Chapter는 이 부분을 채우기 위한 일을 하고 있습니다.
그런데 단순히 이 맥락을 채우기 위한 문서를 쓰는 것이 저희의 일은 아닙니다. 제가 처음 토스 커뮤니티에 합류했던 5년 전과 지금을 비교해 보면, TW가 하는 일은 많이 달라졌습니다.
또, 일의 목표도 달라졌습니다. 올해 목표는 사람이 문서를 직접 쓰지 않아도 지식이 쌓이게 만드는 것입니다. 그리고, Technical Writing Chapter의 궁극적인 목표는 사라지는 것입니다.
TW를 떠올렸을 때 어떤 일을 할 거라고 생각하셨나요? 사실 저는 TW가 AI에게 가장 먼저 대체될 거라고 생각했었는데요. 제 예상과는 반대로 할 일이 더 넓어지고 많아진다고 느낍니다. 기술 문서를 쓰는 역할을 하던 TW가 어떻게 위와 같은 일을 하고, 이런 목표를 가지게 됐을까요?
문서를 쓰는 일에서, 직접 찾아가는 방향으로
제가 사내 문서화를 처음 시작했을 때 가장 먼저 했던 일은 프론트엔드 챕터의 온보딩 문서 만들기였어요. 그런데 내부 문서를 만들면서 계속 마음에 걸리는 게 있었어요. 저는 Technical Writing의 목표가 글을 잘 쓰는 게 아니라 독자가 문제를 해결하고 목표를 이루도록 돕는 것이라고 생각하거든요. 그런데 문서가 아무리 좋아도, 사람들은 필요한 것만 찾지 처음부터 끝까지 읽진 않습니다. 사실 저조차도 그렇고요. 그래서 문서를 쓴 뒤 링크를 던지는 것 말고, 어떻게 하면 사람들이 이 내용을 실제로 활용하게 할지를 고민하게 됐어요.
고민하다 만든 게 ‘박씨’라는 챗봇이었어요. (*참고: TMC25 - 100번 실패하고 살려 낸 문서 시스템) 사람들이 매일 쓰는 메신저와 IDE 안에서, 대화하듯 물어보면 기존 문서를 근거로 출처까지 달아 답해주는 챗봇이에요. 지금은 많은 곳에서 익숙해진 것처럼 문서를 찾아오게 하는 대신, 문서가 사람들이 일하는 자리로 찾아가게 만든 거죠.
흥미로운 건 그다음이었어요. 문서를 쓰는 것도 읽는 것도 관심이 없었던 팀원들이 찾아오기 시작했어요. "우리 챕터도, 우리 조직도 이런 걸 만들고 싶다"고 하면서요. 조직의 크기가 커지면서 다들 반복되는 질문에 답하는 데 지쳤고, 암묵지를 사람이 아니라 시스템에서 얻고 싶어 했어요. 마침 AI가 빠르게 발전하면서 "AI에게 일을 시키려면 문서가 필요하다"는 흐름까지 더해졌죠.
오랫동안 귀찮은 일 취급받던 문서가 갑자기 모두가 원하는 것이 된 게 신기하기도 했습니다. 이런 흐름 속에서 저는 팀원 모두가 쓸 수 있는 지식 시스템 제품을 만들기 시작했습니다. 이 제품은 다음 글에서 자세히 소개할게요. 
문서에서 지식 시스템으로
그때부터 TW들은 직무에 갇히지 않고 일을 넓혔어요. TW는 이제 문서를 쓰는 사람이 아니라, 위와 같이 각 조직에 맞는 지식 시스템을 설계하는 사람이 되어야 한다고 판단했어요. AI가 점점 더 많은 일을 하는 지금, 조직에 흩어진 지식과 암묵지가 문서화되는 게 정말 중요하다는 생각도 들었습니다.
잘 만든 지식 시스템은 두 가지 가치를 가집니다. 위로는 조직 전체의 생산성을 끌어올리고, 아래로는 모든 팀원이 쉽고 빠르게 적응할 수 있도록 하방을 막아줍니다. 조직이 커질수록 질문이 늘고 커뮤니케이션 비용이 급증하기 때문에 잘 설계된 지식 시스템은 우리가 일하는 속도와 품질을 지켜주는 중요한 인프라입니다.
지식이란 특정한 맥락에서 개인이나 조직이 문제·상황을 이해하고 더 나은 결정을 내려 행동하게 하는 검증된 정보예요. 맥락에 맞게 검증되어 있어야 지식이에요.
지식 시스템은 이 지식을 한곳에 모아, 필요한 사람과 AI에게 제때 가닿게 하는 구조예요. 코드·대화·배포처럼 곳곳에 흩어진 지식을 단일한 원천(Single Source of Truth)으로 모으고, 사람이 읽을 수 있을 뿐 아니라 AI가 이해할 수 있도록 구조화해서, 질문과 자동화로 바로 활용되게 만드는 것이죠.
지금 토스의 Technical Writing Chapter가 하는 일은 크게 네 파트로 나뉩니다.
첫 번째, 제품을 만들어요. 사내 지식을 관리하는 플랫폼 '토독'을 직접 만들고 운영하는 팀을 이끌고 있어요. 
두 번째, 각 조직에 들어가 문서화를 주도해요. 각 조직에 맞는 방식으로 흩어진 지식을 모으고, 활용도를 극대화합니다. 조직마다 필요한 지식 시스템의 성격이 달라서 접근 방식도 달라져요.
세 번째, 이 과정에서 사람이 하는 Technical Writing을 없앱니다. AI 워크플로와 자동화로 모두가 비슷한 품질로 문서를 쓰고 리뷰 받을 수 있게 합니다.
마지막으로, 토스의 문서화 문화를 만듭니다. 전 커뮤니티 대상으로 AI가 잘 읽을 수 있는 문서를 쓰는 방법 같은 주제로 세션을 열어요. 또 조직별로 문서화 길드와 지식 커미티를 운영하며 토스 곳곳에서 지식을 다루는 방식 자체를 바꿔 나가고 있어요.
이 시리즈에서 다룰 이야기
이 시리즈에서는 앞으로 이런 이야기를 들려드릴게요.
전문성 밖으로 나아가기: 테크니컬 라이팅의 전문성이 어떻게 '토독'이라는 제품으로 녹아들었는지 이야기해요.
우리 팀의 문서화는 왜 실패할까? / 같은 문제 다른 해법 (coming soon): 거의 모든 회사가 겪는 "지식이 안 쌓인다"는 문제에 어떻게 접근했고 무엇을 배웠는지 두 편의 인터뷰로 공유해요.
Technical Writer, 사라질 결심 (coming soon): 테크니컬 라이터의 일을 어디까지 자동화할 수 있는지, 저희가 만든 것들을 공유해요.
Knowledge 전문가로 거듭나기 (coming soon): 챕터 없이도 조직이 스스로 지식을 생산·관리하게 만드는, 마지막 목표로 가는 고민을 나눠요.
저희 직무의 이름은 여전히 ‘Technical Writer’지만, 실제로 하는 일은 조직의 지식 인프라를 설계하는 것에 가까워요. 정해진 직무를 수행한 게 아니라, 풀어야 할 문제를 따라가다 직무를 새로 그린 거죠. 그러다 어느새 업계 어디에도 없는 모습이 됐습니다.
그리고 이건 Technical Writing만의 이야기가 아니라고 생각해요. AI가 모든 직군의 일을 다시 정의하는 지금, 자기 직무의 외연을 스스로 넓히는 일은 누구에게나 열려 있는 선택지니까요. 한 명이었던 챕터가 셋이 되고 더 많은 동료를 찾고 있는 지금, 저희 이야기를 하나씩 풀어볼게요.

1. 세상에 없던 직무를 만들어가기

댓글