구글 테크니컬라이터가 전하는 이야기

이 글은 구글에서 테크니컬라이터로 일하고 있는 Diane Bates의 발표를 정리한 글이다.

유명 글로벌 기업에서는 테크니컬라이터들이 어떻게 일하는지 궁금했었는데 이 영상을 통해 구글의 테크니컬 라이터들이 일하는 과정(Work Process)과, 더불어 그들이 겪고 있는 어려움들 또한 엿볼 수 있어 좋았다. 

[원본 영상]How to work with technical writers, SRE Converence 2017

화자는 영어를 전공한 24년 경력의 테크니컬 라이터이다. 테크니컬 라이터로 일하기 전 electronics technician으로 9년동안 일하다가 테크니컬 라이터로서 전향하였고 그 후 크고 작은 회사에서 계약직, 정규직으로 경력을 쌓았다. 그 이후엔 MS에서 대부분의 경력을 쌓았고 현재는 SRA 기관을 위해 구글에서 테크니컬 라이터로서 일하고 있다.

 [여지껏 난 테크니컬 라이터로서 경력이 6년이나 되었는데도 아직 이룬게 없다며 혹은 아는게 많지 않다며, 더 배울 수 있는 곳으로 빨리 이직을 해야겠다고 조바심을 내곤 했다. 이렇게 오랜 경험을 가지고 있는 화자의 24년 경력 이야기를 듣고 보니 나는 아직 햇병아리이고, 오히려 그래서 더 앞으로도 경력을 쌓을 수 있는 기회가 많다는 것과, 더 다양한 길로도 가능성이 열려있다는 생각이 들었다. 조바심 낼 필요 없이 내 분야에서 전문성을 가지기 위해 꾸준히 노력한다면 그 어떤 길을 가든 내가 원하는 것을 얻을 수 있을 것이다.]

 

기술 문서(Technical Documentation)는 왜 필요한가?

문서를 제작하는데 적합한 툴이 없거나 문서가 제대로 있지 않으면 필요한 정보를 track down하는데 시간을 소요해야 한다.
만약 문서 없이 시행과 착오, 질문 등을 통해서 제품을 이용하는 방법을 알아내야 한다면 얼마나 많은 엔지니어링 시간이 소모되어야 할까? 한 명의 테크니컬라이터와 한 명의 엔지니어만 있으면 회사 사람들과 사용자들의 상당히 많은 시간을 절약할 수 있다. 테크니컬라이터는 사용자가 무엇을 필요로 하는지, 그들의 문제에 답이 될 정보들을 어떻게 정리(organize)해서 써야할 지 안다. 엔지니어에게 tool을 사용하여 개발하게 하는 것처럼, 테크니컬 라이터에게 문서를 쓰게 하자.

테크니컬라이터 는 왜 필요할까?

테크니컬라이터는 사용자의 대변인과 같아 상품, UI 문구, 에러 메시지에 대한 피드백을 주기도 하고, 프로세스, 스크립트를 추가하도록 제안하거나 구성을 변경하도록 피드백을 줄 수 있다. 예로 화자가 한 회사에서 설치 과정에 번거러운 과정을 삭제하여 설치 시간을 절약한 경험을 예로 들며, 테크니컬 라이터가 상품의 문제를 바라보며 엔지니어에게 즉각적인 피드백을 줄 수 있는 존재라 말한다.

[나 또한 이러한 경험이 있다. 사용자 매뉴얼을 제작하기 위해 프로그램을 사용해보다가 버그를 찾아내는 경우도 있고, UI 용어를 다르게 사용함으로써 사용자가 느끼게 될 혼란을 사용자 대신 전하기도 한다. 간혹 사용자가 더 쉽게 설정하고 변경 하기 위한 아이디어를 건의하기도 한다. 다만 그 의견이 실행에 옮겨지는지에 대한 여부는 개발자 몫이긴 하지만. 긴박한 일정은 그러한 아이디어를 우선 순위에서 밀리게 하는 경우가 많다. ]

 

 Planning documentation projects

테크니컬 라이터는 고용하는 이유? 
고객이 질문을 너무 한다거나, 그 질문에 일일히 대답해주기 어렵거나, 상품에 대해 모른다거나, 참고 정보(reference information)가 필요한 새 API가 생겼다거나, 문제에 어떻게 대응할지 모른다거나 하는 경우 테크니컬 라이터를 고용하게 된다.

테크니컬라이터를 고용하고 나서는 목표을 정하게 된다. What problems are we trying to solve? 어떤 문제를 해결하려 하는가?
 

프로젝트 계획하기:
이 단계에서는 프로젝트를 위해 목표를 세우고, 엔지니어링 자원을 할당하고, 테크니컬 라이터에게 그 상품을 이해하도록 도와야 한다.
어느 엔지니어가, 어느 테크니컬 라이터와 함께 작업할건지 정하고, 테크니컬 라이터들의 작업시간을 할당해야 한다. 이 때, 엔지니어는 테크니컬 라이터가 작업할 시간이 필요하다는 점에 대해 인식하고 있어야 한다. 작업 시간에는 리뷰 작업(Review process)도 필요하기 때문이다. 그리고 테크니컬 라이터들이 필요한 자원(computer와 같은 resource)도 파악한다. 

[우리 회사에서는 이 부분이 많이 간과되고 있다. 매뉴얼보다는 고객이 요청한 데드라인이 중요하고,내가 제작하는 매뉴얼이 다루는 소프트웨어(비전 프로그램)은 장비셋업이 거의 다 이루어진 막바지에 셋팅이 시작되므로 그 내용을 다루는 매뉴얼은 정말 데드라인 전날, 아니 몇 시간에 전에 작업이 마무리 되는 경우도 있다. 아무도 나의 작업 시간은 고려해주지 않은 채로, 그렇게 장비 위주로 생산 일정이 정해진다. 아니 사실은 장비를 담당하는 엔지니어도 모르는 채로 데드 라인이 정해지거나 당겨지기도 한다. 이상적인 이야기겠지만 장비의 컨셉미팅 때 테크니컬 라이터도 함께 컨셉에 대해 설명 듣고 매뉴얼 작업을 같이 진행하면 참 좋으련만. 이런 생각을 오랫동안 해왔는데 구글에서는 정말 저렇게 일을 진행한다니. 부럽고, 부럽다. ]

 

 
Doc Project Lifecycle

1. Planning phase : 목적과 데드라인 설정하고, 테크니컬 라이터를 만나 resource를 전달하고, 그들이 필요한 문서나 요청사항을 받는 단계.

2. Writing phase: 테크니컬 라이터가 리서치 하고 초안 쓴 사람들과 미팅하고, 기술 리뷰(tech review)를 보내고, 변경사항 추가 하는 단계.

3. Final phase: polish(publish)- 테크니컬 라이가 쓴 변경사항을 두 번째로 기술 리뷰하고, 최종 변경사항을 추가하는 단계.
위 과정을 거쳐 문서를 발행(release) 한다.

 

[구글에서 테크니컬 라이터들이 일하는 과정을 들으면, 다양한 리소스와 커뮤니케이션, 리뷰가 참 중요하단 생각이 든다. 우리는 얼마나 다양한 자료를 수집하기 위해 관련 내용을 전달 받거나 개인적인 리서치를 진행하는지, 더 정확한 컨텐츠 제작을 위해 커뮤니케이션을 하는지, 기술 리뷰를 통해 정확한 내용과 통일감 있는 문서를 제작하는지, 우리의 프로세스와 함께 우리의 의지력을 돌아볼 수 있는 계기가 되었다.] 

테크니컬 라이터와 일하기
미팅 시, 프로젝트의 목표, 기대효과, 타임라인에 대해 논의하게 된다. 이 때, 테크니컬 라이터에게 상품에 대한 간단 소개를 하고, 테크니컬 라이터가 글쓰는 동안 엔지니어가 달성(accomplish )해야 하는 것에 대해서도 논의한다. 그러면 테크니컬 라이터는 필요한 문서 리스트를 만들고 그 리스트의 목적을 달성하기 위해 일할 것이다. 또한 최종 데드라인을 말해주고 거꾸로부터 각각의 마일스톤을 위한 타임라인을 세운다.
* Milestone layout, process timeline template 찾아보기

[Collaboration]

얼마나 자주, 무엇(email, meeting)을 통해서 문서를 통합(sync)할 건지, 어떤 방식으로 질문을 할 건지(scrum meeting, On-off question) or 일하는동안 방해받지 않는걸 원하진 않는지 작업 전에 정한다.

 
[Help the writer get strated]

테크니컬라이터를 미팅 시 초대하거나, 사용자 리스트나 팀 메일 리스트의 멤버로 추가 되어있는지 확인한다. 또한 테크니컬 라이터의 자료 접근 권한을 확인한다. API guide의 경우에는 소스코드 접근이 가능한지에 대한 사항들도 확인한다. 

테크니컬 라이터에게 설명해줄 별도의 시간이 필요할 수도 있다. 또한 별도로 테크니컬 라이터에게 설명해줄 엔지니어를 할당(Assign)한다.

[개인적으로 이 방법을 선호한다. 중요도가 낮은 문서작업에 협조하는 정도가 개인 성향별로 혹은 라이터와의 친분도에 따라 다르다. 얼마나 협조해주느냐에 따라서도 문서의 질이 달라진다. 그래서 특정 문서나 자료를 제작하고자 할 때, 해당 부서장이나 팀장에게 담당자 지정을 요청드린다. 자기 일이 아니어도 적극적으로 알려주는 이도 있지만, 내 일이 아니라고 질문을 피하는 개발자도 있기 때문에. 담당자로 지정 되면 라이터가 와서 질문하면 적어도 내 일이 아니니까 라는 표정은 짓지 않을 수 있으니까. ]

 

 

[Technical Reviews]

초안 작성 후, 팀 내의 한두명의 엔지니어에 의해 기술 리뷰가 이루어진다. Technical Reviewer로 지정된 엔지니어는 코드 리뷰와 같은 방식으로 접근해야 한다. 코드 리뷰처럼 꼼꼼히 해야 한다는 뜻이다. 기술적으로 잘못된 내용을 지적할 때는 지적만 하지 말고 왜 틀렸는지 설명해주는 게 좋다. 그리고 배경 지식을 곁들여준다면 테크니컬 라이터가 절차 중에 어떤 스텝이 빠졌는지, 혹은 아직 문서에 언급되지 않은 배경 정보(background information)과 개념들을 파악하는데 도움이 될 것이다.

 

또한 화자는 다음과 같이 테크니컬 라이터들과 일할 때, 피해야할 것들에 대하여 이야기한다.

그 중에서, 컨셉  데드라인에 따라 문서 질이 결정되므로 마감일(Deadline)이 변경되면 테크니컬 라이터에게 꼭 알려달라고 말한다. 문서 제작은 제품 사이클 막바지에 작업되므로, 제품 출시쯤에도 더 많은 정보가 채워질 수도 있다.

마지막으로 화자는 나에게 아인슈타인의 명언을 남겨주었다.
If you can’t explain it simply, you don’t understand it well enough. – Albert Einstein

 

내가 요새 들어 공부할 때마다 마음 속으로 되내이게 되는 구절이다. 누군가에게 설명할 수 없다는건 내가 그것을 충분히 이해하지 않은 것과 같다. 지식의 깊이의 문제가 아니라 간단한 개념이라도 누군가에 설명할 수 있어야 내 머릿속에 있는 것이다.