토스 TW가 AI에게 자기 리뷰를 가르친 이야기

토스 테크 블로그에서 “Technical Writer, 사라질 결심”이라는 글을 읽었다. 제목을 두 번 봤다. TW(테크니컬 라이터)가 스스로 없어지겠다고 결심했다는 건데, 직무 폐지나 인력 감축 이야기인가 싶었다.

읽어보니 전혀 달랐다. TW가 오랫동안 쌓아온 리뷰 기준과 글쓰기 방식을 AI에게 가르쳐서, 반복적인 작업을 대신하게 만든 과정이었다. “사라지겠다”는 건 직무 자체가 아니라, 지금 방식의 일을 없애겠다는 뜻이었다.

1️⃣ 이게 뭐냐?

핵심은 암묵지를 AI에 어떻게 주입했느냐는 부분이었다. TW가 쌓아온 기준들—”한 페이지에는 하나만 다룬다”, “가치를 먼저 제시하고 설명한다”—을 AI에게 규칙 목록으로 넣으면 잘 안 됐다고 한다. 형식은 따르는데 의도를 못 잡는 식이었다는 것 같았다.

그래서 택한 방법은 잘못된 사례와 올바른 사례를 쌍으로 학습시키는 방식이었다. “이건 나쁜 예, 이렇게 고치면 좋다”라는 형태를 반복적으로 넣어 직관을 심어준 것이었다. 사람을 온보딩할 때 규칙집보다 실제 사례를 보여주는 게 더 빠른 것과 비슷한 방식이라는 생각이 들었다.

결과물은 두 가지였다. 하나는 사내 메신저 대화를 문서로 변환하는 챗봇 “토독이”였다. 대화 흐름 안에서 자연스럽게 암묵지를 포착해 문서화하는 역할이었다. 다른 하나는 PR마다 기술 문서를 자동으로 검토하는 GitHub 리뷰 봇이었다. 코드 리뷰처럼, PR을 열면 문서 품질 리뷰가 자동으로 달리는 구조였다.

특히 “토독이”가 흥미로웠던 건, 문서를 새로 쓰게 하는 게 아니라 이미 일어난 대화에서 건져 올린다는 방식이었다. 사람들이 문서화를 번거롭게 여기는 이유 중 하나가 “따로 시간을 내야 한다”는 것인데, 대화 흐름 안에서 포착하는 구조가 그 마찰을 줄이는 시도처럼 읽혔다.

2️⃣ 내가 든 생각

PR 리뷰 봇 이야기에서 생각이 좀 걸렸다. 처음엔 사용자가 직접 호출하는 방식으로 만들었는데 채택률이 낮았고, PR을 열면 자동으로 실행되는 흐름으로 바꿨다는 것이었다.

도구가 워크플로우 밖에 있으면 아무도 꺼내 쓰지 않는다는 걸 부딪히면서 발견한 거였다. 디자인에서도 비슷한 이야기를 자주 보는 것 같다. 기능이 얼마나 좋은가보다 언제, 어느 맥락에서 등장하느냐가 실제 채택을 좌우한다는 것. AI 도구도 그 원칙과 무관하지 않았다.

👉🏻 자동화 이후에 새 문제가 생겼다는 부분도 흥미로웠다. 문서가 너무 많이 쌓이면서 중복과 노후화가 새 골칫거리가 됐다는 것이었다. 생성이 자동화되면 관리도 자동화해야 한다는 수순이 생긴다. 생성→검증→갱신→폐기라는 순환 구조 설계가 다음 과제라는 거였다.

💡 여기서 든 질문: AI가 생성한 문서를 누가, 어떤 기준으로 “살아있는 문서”라고 볼 수 있을까? 순환 구조가 필요하다는 건 이해했는데, 폐기 기준을 세우는 일이 여전히 사람 몫이라면 자동화의 이득이 어디서 끊기는지가 아직 잘 안 보인다.

⭐️ 마지막으로, 이걸 공부하며 느낀 점

정리해보니 이 글의 핵심은 “TW가 사라진다”기보다 “반복 작업의 레이어가 바뀐다”에 가까웠다. 쓰고 리뷰하는 자리에서, 어떤 문서를 만들고 어떻게 순환시킬지 설계하는 자리로 올라간 것이었다. 더 쉬운 일이 됐다는 게 아니라, 일의 종류가 달라졌다는 쪽에 가까웠다.

---

참고 원문: 5. Technical Writer, 사라질 결심