번역글

평범한 문서가 성장을 방해합니다

문서화의 금본위를 정립한 인물을 꼽자면 바로 Dave Nunez입니다. 만약 Stripe 문서를 참고해 본 적이 있다면, Dave와 그의 팀이 세심하게 제작한 결과물을 보았을 것입니다. Dave는 Stripe에서 5년간 문서화 팀을 이끌었으며, 그 전에는 Uber의 기술 콘텐츠 및 정보 시스템을 총괄했습니다. 현재 그는 Abstract Group을 통해 조언과 컨설팅을 제공하고 있습니다.

만약 당신의 문서가 그저 평균적이거나 상태가 나쁘다면, 이 인터뷰에서 실질적인 개선을 시작하는 데 필요한 모든 것을 얻을 수 있습니다. 우리는 다음 주제를 다룰 것입니다:

훌륭한 기술 작가가 갖춰야 할 성격적 특성
문서화 성공을 측정하는 지표 (단순히 페이지뷰가 아닙니다)
마케팅이 문서화 팀과 강력한 협력 파트너가 될 수 있는 방법
언제 작가를 고용해야 하고, 어떤 점을 고려해야 하는지
Dave가 "망가진" 또는 복잡한 문서를 고치는 방식
Stripe에서의 경험담을 통해 문서화와 사용자 경험(사용자 조사에 큰 역할을 함)을 이해하는 데 도움이 되는 이야기들

이 스크린샷을 여기에 남겨두겠습니다:

기술 작문에 어떻게 입문하게 되었고, 문서화 작성, 전략 및 리더십이 본인에게 맞는 것임을 어떻게 알았나요? 기술 작문에서 특히 유리한 성격적 특성은 무엇인가요?

저는 영문학을 전공했으며 글쓰기를 좋아합니다. 여러 비즈니스 관련 글쓰기 일을 시도한 후, 한 친구로부터 그의 스타트업에서 기술 작가를 찾고 있다는 전화를 받았습니다. 그리고 금세 저는 기술과 스타트업 문화에 매료되었죠. 그곳에서는 무슨 수를 써서라도 일을 해내야 했습니다.

저는 문서화가 비즈니스와 고객 성공에 있어 완전히 활용되지 않은 도구라는 믿음을 갖게 되었습니다. 마치 업계 전체가 고객이 문서에서 고통을 겪는 것이 당연하다고 여기는 것처럼 보였죠. 그래서 저는 문서를 위한 제품 관리자처럼 행동하기로 했습니다. 제품 관리자는 엔지니어와 협력하고 사용자 피드백을 수집하며, 제품의 전체적인 사용자 경험을 평가합니다. 일단 제가 어느 정도 성과를 거두기 시작하니, 점점 더 이 일에 빠져들었고 어디까지 갈 수 있을지 도전하고 싶었습니다.

성공에 필요한 성격적 특성:

글쓰기를 사랑해야 합니다. 하루 종일 텍스트와 씨름하게 될 테니까요.
복잡한 주제와 학습을 즐겨야 합니다. 이 역할에서는 새로운 기술을 배우고, 매우 똑똑한 사람들에게 그것을 가르칠 수 있어야 합니다. 그게 얼마나 어려운 일인가요! 이 역할에서 중요한 것은 빠르게 배우는 능력을 키우고, 엔지니어들과 밀접하게 협력하며 제품에 몰입하는 것입니다.
마지막으로, 저는 경쟁심이 강합니다. 저는 이 작은 분야에서 가능한 최고의 결과물을 만들기 위해 나름의 경쟁을 벌였습니다. 아무도 저와 경쟁 중인 줄 몰랐지만, 저는 승리하려고 했습니다.

흥미로운 점은, Dave는 기술 작가로 시작할 때 개발자가 아니었다는 것입니다! 그는 야간 수업을 듣고, 책을 많이 읽으며, Codeacademy를 통해 스스로 개발을 공부했습니다. 그는 새로운 기술 개념을 빠르게 배우는 능력이 훌륭한 문서 작가의 핵심 특성 중 하나라는 사실을 깨달았으며, 기술에만 매몰되기보다 유연하고 변화에 열려 있어야 한다고 생각했습니다. 이런 접근은 시간이 지나면서 더 많은 제품을 다루고, 직업적으로 성장하는 데 큰 도움이 됩니다.

마케터로서 (외부 고객 대상) 문서는 개발자 유입 경로의 필수적인 부분이라고 생각합니다. 당신은 업무에서 마케팅과 얼마나 자주 협력하나요? 좋은 마케팅 파트너와 그렇지 못한 파트너를 구분하는 기준은 무엇인가요?

저는 마케팅과 협력하는 것을 정말 좋아합니다. 우리는 여러 공통점을 공유하고 있습니다:

우리는 콘텐츠를 제작하고, 마케팅 콘텐츠나 문서를 소비하기 싫어하는 개발자를 교육해야 합니다.
조직 내에서 우리는 높은 기대치, 짧은 일정, 그리고 우리가 무슨 일을 하는지 잘 모르는 많은 협력자들과 맞닥뜨립니다.

먼저, 약한 마케터가 무엇인지 이야기하겠습니다. 불행히도 그런 사람들도 존재합니다. 약한 마케터는 자기 역할에만 충실하고 R&D에 뛰어들기를 두려워하는 사람입니다. 엔지니어 및 PM과의 미팅에 참석할 의지가 없다면, 좋은 결과를 기대할 수 없습니다. 실제로 제품을 테스트하고 피드백을 제공할 때 마케터의 신뢰도가 크게 상승합니다. 팀의 나머지 구성원들은 마케터가 유의미한 의견을 내놓기를 원합니다!

가장 강력한 마케터는 자신이 제공하는 가치에 대한 확신이 있습니다. 그들은 제품의 이름, 짧은 설명, 또는 GTM 전략을 제대로 정립하는 것이 얼마나 중요한지를 팀에 설득하는 데 주저하지 않습니다. Stripe에서 가장 성공적인 마케터는 필요할 때 단호하게 의견을 제시하는 사람들이었습니다. 그들은 훌륭한 일을 했을 뿐만 아니라, 최고의 아이디어를 위해 싸우는 모습으로 리더십의 존경도 얻었습니다.

마케팅이 문서화 전략을 지원하기 위해 무엇을 해야 한다고 생각하나요? 강력한 마케팅 파트너와 협력하여 문서화 노력이 개선된 사례가 있나요?

Stripe에서는 "통합 경험"이라는 스프린트가 12-15개월 동안 진행된 적이 있습니다. 모든 것은 한 사용자의 나쁜 트윗에서 시작되었죠. 창업자가 이끄는 스타트업에서 많은 사람들의 악몽이 시작되는 것처럼 말입니다. 결국 우리는 통합 경험을 개선하려고 했습니다. 이는 GDPR 및 SCA와 같은 통제할 수 없는 규제 요구 사항으로 인해 복잡해졌습니다.

처음 3-6개월 동안 이 문제를 해결하려고 노력했지만, 또 다른 사용자가 혼란스럽다는 트윗을 올렸고, 많은 사람들이 이에 동조하여 Hacker News에까지 퍼졌습니다. 외부의 검증이 내부의 변화를 촉발시켰고, 우리는 Stripe를 다시 단순하게 만들기 위한 결단을 내렸습니다. 사용자에게 내부 복잡성을 떠넘기지 않기 위해서 말이죠.

우리는 데이터 과학자, 제품 마케터, 사용자 연구원, 디자이너, 엔지니어를 모두 모아 정말 좋은 제품 경험과 훌륭한 문서를 만들어냈습니다. 특히 기억나는 것은, 제품 마케터들이 우리와 함께 열심히 일했지만 억지로 뭔가를 강요하지 않았다는 점입니다. 그들은 필요할 때 그 자리에 있었고, 참여할 필요가 없는 결정에서는 한 발 물러나 있었습니다. 그들이 우리를 도울 준비가 된 관계와 인맥을 가지고 있다는 점도 매우 귀중했습니다. 문서화 작업을 진행하면서 이름 짓기, 메시징, 포지셔닝에서 막히면 그들은 즉각적인 해결책을 제공해주었고, 팀의 작업을 신속하게 풀어줬습니다. 이것은 정말 귀중한 지원이었습니다.

좋은 문서와 나쁜 문서를 구분하는 기본적인 기준은 무엇인가요?

결국 좋은 문서는 사람을 위한 것입니다.

Patrick과 John Collison은 Stripe 문서 경험이 마치 커피를 마시며 친구가 Stripe 설정 방법을 알려주는 것과 같아야 한다고 말했습니다. 친구는 무엇을 사용해야 하고, 무엇을 피해야 하는지 알려주며, 필요할 때 유용한 YouTube 링크를 꺼내 보여줄 것입니다.

우리가 문서를 작성할 때는 30-60분 정도의 집중 시간이 있는 사람을 떠올리곤 했습니다. 좋은 문서는 짧고 스캔하기 쉽습니다. UX가 뛰어나고, 검색이 잘되며, 레이아웃에 여백이 있습니다.

반면 나쁜 문서는 그 반대입니다. 종종 기계나 존재하지 않는 사람을 위해 작성된 듯한 느낌을 줍니다. 자동 번역을 쉽게 하기 위해 작성된 문서는 어색하고 기계적인 언어를 사용하며, 번역 비용을 절감하려는 목적이 명확합니다. 또 다른 나쁜 문서는 그저 텍스트의 벽으로 이루어져 있으며, 개발자가 그렇게 긴 글을 읽고 싶어 한다는 비현실적인 가정을 하고 있습니다.

문서화 성공을 어떻게 측정하나요?

X에 도달하는 시간

가장 좋은 측정 기준은 개발자가 달성해야 할 작업을 완료하는 데 걸리는 시간입니다. Stripe에서 우리는 사람들이 온보딩의 첫 번째 관문을 넘어설 수 있는 활동, 즉 테스트 결제를 실행하는 데 주목했습니다. 우리는 온보딩 경험에 집착하며, 그 과정에서 발생하는 작은 불편을 모두 제거하여 평균적으로 4배 더 짧은 시간을 달성했습니다.

지원 요청률

문서 관리자들은 지원 티켓을 얼마나 많이 방어하는지에 집착합니다. 그 숫자는 팀의 예산을 정당화하기 때문이죠. 제가 Stripe에 이 지표를 도입했을 때, 지원 요청률이 매우 높았던 이전에 비해 1% 미만으로 줄어든 것이 매우 자랑스러웠습니다!

그러나 John Collison은 이에 대해 "그건 좋지만, 우리는 비용 절감에 집중할 필요가 없다. 이건 정말 사용자 경험 측면에서 훌륭한 일이다. 사용자는 지원팀에 연락하는 것을 원하지 않으니, 문서를 그렇게 잘 만들어 그럴 필요가 없게 하자"라고 말했습니다.

페이지뷰는 중요하지 않다

Google Analytics, 페이지뷰, 이탈률, CSAT 등을 살펴볼 수는 있지만, 저는 이러한 지표들이 단독으로는 그다지 의미가 크지 않다고 생각합니다.

클라이언트에게 반복해서 강조하는 문서화 관련 조언은 무엇인가요? 큰 변화를 빠르게 얻을 수 있는 가장 빠른 방법은 무엇인가요?

시작하기 경험에 집착하라. 많은 클라이언트가 훌륭한 문서를 만들고 싶어 하면서도 모든 것을 한꺼번에 하려고 합니다. 이 방식은 대부분 번아웃으로 이어집니다. 또는 해야 할 일이 너무 많아져 아무 것도 시작하지 못하고 마비되기도 합니다.

사용자는 시작조차 하지 못하면 당신에게 결코 비용을 지불하지 않을 것입니다. 그래서 그 부분부터 먼저 고치세요. 그런 다음에야 정보 구조, 디자인, 검색 등의 문제를 고민할 수 있습니다. 시작하기 경험을 개선하기 위해:

마찰 로그를 작성하세요. 회사의 모든 사람들이 시작하기 경험을 직접 겪어보게 하세요. 라이브로 전환하는 과정에서 발생하는 모든 간극과 불편함을 찾아내세요.
사용자 조사를 하세요. 가장 큰 활성화 장애물을 찾아내세요. 때로는 깨진 링크가 있는 혼란스러운 자동 이메일일 수도 있고, 마케팅 페이지에 빠진 CTA일 수도 있습니다. 대부분은 혼란스러운 문서와 사용자 요구를 반영하지 못한 제품 때문입니다.

작은 개선들은 쌓입니다. 당신이 기업이든 PLG이든 첫 인상은 매우 중요합니다. 훌륭한 온보딩 경험을 통해 사용자와의 신뢰를 쌓는 것은 매우 귀중합니다. Stripe의 개발자 경험은 완벽하지 않았지만, 우리는 항상 개선하고 발전시켜 나갔습니다. 그 결과 개발자들은 우리에게 신뢰를 주었고, 스스로 문제를 해결하거나 피드백을 제공하려 했습니다. 그들은 우리가 그 피드백을 진지하게 받아들일 것이라는 것을 알았기 때문입니다.

Stripe 문서 개선에서 의외로 큰 영향을 미친 변화나 개선이 있었나요?

우리가 실행한 연구 중 하나는 우리가 예상했던 것과 전혀 다른 결과를 낳았습니다.

Stripe에서 우리는 공식적으로 사용자 연구원을 통해서든, 비공식적으로 우리 스스로 하든, 많은 사용자 조사를 수행했습니다. 통합 경험 스프린트를 진행하는 동안 사용자들이 Stripe를 복잡하다고 느끼는 이유를 이해하려고 했습니다. 우리는 문제를 알고 있다고 생각하며 인터뷰를 시작했죠...

그러나 인터뷰가 10분 지나면 사용자에게는 이미 10개의 탭이 열려 있었습니다. 그리고 20분이 지나면 그 수가 15개로 늘어나며, 사용자는 당황한 상태였습니다. 우리는 개발자가 여러 가지 상황에서 문맥 전환을 자주 겪는다는 점을 간과했습니다. 컴파일 대기, PR 검토, Slack 메시지 확인, 이메일 확인, 미팅 참여 등등 말이죠. 그래서 만약 우리가 15개의 탭이 필요한 단편적인 경험을 제공한다면, 당연히 그들은 부정적인 감정을 느낄 수밖에 없었습니다.

결국 우리는 SEO 플레이북에 따라 문서에 수많은 인라인 링크를 사용했지만, 개발자는 이 모든 링크를 클릭해서 다 읽어야 한다고 생각했고, 그 결과 탭에 묻히게 되었습니다.

그래서 우리는 SEO 플레이북을 버리고, 꼭 필요한 경우가 아니면 인라인 링크를 넣지 않기로 했습니다. 그 후, 문서팀은 정말 멋진 호버 기능을 만들었고, 작가들은 광범위한 용어집을 작성했습니다. 이제 용어에 마우스를 올리면 정의가 팝업으로 표시되어 사용자가 한 페이지 내에서 작업을 계속할 수 있게 되었습니다.

작가를 채용할 때 어떤 점을 고려하나요? 그리고 언제 문서를 전담할 정규직 인력을 고용해야 한다고 판단하나요?

저는 팀의 필요에 따라 달리 봅니다. 어떤 곳에서는 이미 다양한 문제를 겪어본 경력직을 필요로 합니다. 그들은 마이그레이션이나 대규모 정보 구조 개편 같은 복잡한 작업을 처리하는 방법을 알고 있습니다. 반면 주니어 인력은 신선한 시각으로 들어와, 경력직이 지겨워하는 일을 기꺼이 해냅니다.

개발자 중심 제품을 가진 회사라면 처음부터 문서화를 담당할 사람을 생각해야 합니다. 초반에는 직접 많은 콘텐츠를 작성하게 될 것이고, 정규직 작가를 꿈꾸게 될 것입니다. 그 사람이 누구일까요? 어떤 기술을 가지고 있을까요? 이렇게 하면 2년 후 성공해서 첫 기술 작가를 고용할 준비가 되었을 때, 3-6개월을 허비하지 않고, 2-4주 만에 적합한 인재를 찾을 수 있을 것입니다.

"언제"라는 시점을 정량적으로 말하자면, 엔지니어들이 문서 작업에 할애하는 시간이 정규직 인력이 해결할 수 있는 수준을 넘었을 때입니다. 이 시점에서 기술 작가는 회사의 비용을 절감하고, 문서의 품질을 향상시킬 것입니다.

⚡️ 번개 질문

요즘 가장 마음에 드는 문서는?

아직도 Stripe입니다. 뭔가를 해야 할 때 Stripe 문서를 찾습니다. 저는 그들의 결정이 얼마나 많은 사용자 연구를 바탕으로 이루어졌는지 알고 있고, 그들의 사고방식도 어느 정도 알기 때문에 디자인 선택을 평가할 수 있습니다.

요즘 불타는 개발자 브랜드는?

브랜드 면에서, 몇몇 회사는 쉽게 얻을 수 없는 후광을 가지고 있습니다. 한 번 얻으면 개발자들과의 신뢰와 호의가 쌓여 진입 장벽을 형성하죠.

Linear: 티켓을 다시는 보고 싶어 하지 않았던 개발자들에게 큰 승리를 안겨준 제품입니다. 그런데 Linear 덕분에 이제 티켓이 반갑기까지 하죠!
Graphite.dev: 그들은 실제로 제 이전 고객이었지만, 개발자들이 그들을 얼마나 좋아하는지 자주 듣습니다. 내부에 있었기 때문에 그 팀이 도구에 얼마나 몰입하고, 사용자 피드백을 끊임없이 반영해 거의 매일 작은 개선을 하고 있다는 것을 알 수 있었습니다. 그 작은 변화들이 모여 큰 차이를 만들죠!

컨설팅의 장점 하나와 단점 하나는?

장점: 수많은 스타트업과 일할 수 있다는 것. 그들은 대기업이 감히 하지 못하는 큰 위험을 감수할 준비가 되어 있습니다.
단점: 팀과 오랜 시간 함께하지 않기 때문에 복도에서 나누는 대화가 시제품으로 이어지고, 결국 제품에 새로운 혁신을 불러오는 그런 기회를 놓친다는 점입니다. 같은 방향으로 함께 달리며 큰 꿈을 꾸는 경험이 없습니다.

기술 작문이나 문서화에 대한 비인기 의견은?

저는 대부분의 문서가 필요 없다고 생각합니다. 사람들은 완전함을 목표로 삼고, 그 결과 모든 질문에 답하는 끝없는 페이지들을 만들어냅니다. 하지만 제품이 빠르게 변화할 때는 이런 문서를 유지하는 것이 불가능합니다. 문서 작성은 60-80%의 핵심 사용자가 필요로 하는 작업에 집중해야 하고, 나머지 엣지 케이스에 대해서는 필요할 때 개발해야 합니다. 페이지를 삭제하거나 다듬는 것을 두려워하지 마세요! 이 사고방식은 제품 자체에 대한 집중력을 요구하며, 너무 많은 사용자에게 너무 많은 것을 제공하려 하면, 그 복잡성이 문서에 반영되어 사용자에게 혼란과 초점을 잃은 인상을 줄 것입니다.

(출처: Developer GTM)