제목은 낚시고 그냥 Q&A입니다. 사전 접수 시 받은 질문과 현장 댓글 질문을 포함해 3명의 테크니컬 라이터가 답변을 하는 형식입니다. 나름 정리를 했는데 실제 답변 내용을 잘못 이해하고 작성한 내용이 있을 수 있으니 영상을 꼭 참고하세요.
먼저 사전에 받은 5가지 질문에 대한 Q&A
(1) 앞으로 테크니컬 라이터의 전망은 어떤가요?
10년 이상 경력이 40.9%, 5년~10년 사이가 18.2%
(그럼 5년 차 이상 테크니컬 라이터가 답변자의 약 60% 정도가 된다는 이야기인데
어떻게 보면 테크니컬 라이터가 오래 할 수 있는 직종인가 싶기도 하지만
또 어떻게 보면 한 번 이 세계에 발을 디디면 빠져나가기 힘든 곳이기도 합니다.
전망이라는 관점에서 본다면 5년 이상 경력을 가진 분들에게 조직의 성장과 테크니컬 라이터의 영향력이 어떻게 변해왔는지. 예를 들어 팀이 어떤 식으로 성장해왔다던지 아니면 전체 개발 문화에서 문서화의 영향력이 어떻게 달라졌는지를 평가해야 하지 않았을까 싶네요).
(2) 테크니컬 라이터로 전향하면서 연봉 수준이 달라졌나요?
개발자에서 테크니컬 라이터로 전향(같은 조직 내에서)하는 경우에는 연봉 수준이 크게 달라지지는 않을 겁니다.
(다만 사내 정치적인 영향력(?)에 따라 연봉 인상 수준은 달라질 수 있습니다. 예를 들어 속해있는 그룹 내에서 문서화의 성과를 인정해주는 분위기가 아니라면 연봉 조정 시 가산점이 부여되지 않을 수 있고 이런 것이 누적되면 같이 개발하던 분들과 연봉 수준이 달라질 수 있습니다.
또 하나의 차이는 개발자는 아무래도 이직의 기회가 많죠. 100명 정도의 개발자를 뽑을 때 테크니컬 라이터는 1명 정도 뽑기 때문에(물론 이것도 흔한 경우는 아닙니다) 연봉을 높여가면서 자리를 옮길 기회가 그만큼 적습니다).
연봉 관련해서는 WTD 설문을 참고해도 도움이 될 겁니다. 2019년부터 3년째 같은 질문(약간씩 추가되긴 합니다만)에 대한 설문을 하고 있어서 연봉이나 업무 환경 관련 추이를 확인할 수 있습니다.
https://www.writethedocs.org/surveys/index.html
(3) 어색한 외래어 표기법, 지키시나요?
설문 조사 결과는 34%는 지켜야 한다. 나머지는 꼭 그래야 하나. 라고 답변을 달았다고 합니다.
카카오 엔터프라이즈 블로그에서도 이 문제를 다룬 적이 있는데 국립국어원 외래어 표기법을 따른다고 하네요.
https://tech.kakaoenterprise.com/132
(뭐 결론은 따라야 한다 또는 조직 내에 기준점은 필요하다 인듯합니다).
(4) 개발자와 협업할 때 특별한 팁이나 노하우가 있을까요?
개발자가 전체 문서의 관점에서 바라볼 수 있게 도와준다라고 답변을 했습니다.
(음. 이건 좀 모호한 답변이긴 한데 해석해보면 개발자가 공감하고 참여할 수 있는 가이드가 필요하다 뭐 이런 의미가 아닐까 싶네요.
API 문서화 같은 경우에는 테크니컬 라이터가 실질적으로 모든 문서화에 관여할 수가 없습니다.
작은 규모라면 모르겠으나 메서드(저는 메소드라고 씁니다만)가 몇 백개 이상 넘어가면 각 개발팀에서 직접 문서를 작성하고 테크니컬 라이터는 이를 조정하는 역할을 하게 됩니다. 때문에 문서에 기여하는 개발자들을 신뢰하고 그들이 쉽게 참여할 수 있는 환경(저작도구, 가이드, 배포 환경)을 만들어주는 것이 중요해지는 거죠).
(5) 테크니컬 라이터가 되려면 어떤 역량을 키워야 하나요?
김지현 님의 책 추천 2권입니다.
- 개발자를 위한 글쓰기 가이드(유영경)
작년에 나온 책이며 현재 배민 테크니컬 라이터 코치 유영경 님이 쓴 책입니다.
- 이공계 X의 글쓰기책 (유키 히로시)
절판되었다고 하는데 인터넷 서점이 아닌 쿠팡 등에서 새 책을 구입할 수 있습니다.
중고로는 7000원부터 시작하는 듯합니다.
- 클린 코드(로버트 C. 마틴)
소프트웨어 관련 고전이죠. '4장 주석' 뿐 아니라 전체적인 내용을 참고할만합니다.
또 하나의 추천하는 역량 강화 방법은 번역입니다.
아무래도 기술 문서의 대부분은 영어로 작성되어 있기 때문에 기술 문서를 번역하고 공개하는 것은 개발자 커뮤니티에 대한 기여가 될 수도 있습니다.
참고로 '토리맘의 한글라이즈 프로젝트'를 소개하고 있네요.
(개인으로 하기 부담스럽다면 주요 오픈 소스 프로젝트의 한글화 그룹에 참여하는 것도 좋은 방법입니다.
일부 테크니컬 라이터 공고를 보면 영문 아티클을 읽고 요약할 수 있는 능력을 요구하기도 합니다. 네이티브 하게 영어를 잘할 필요는 없지만 관련 기술의 영문 기술 문서를 읽고 구성원들에게 전달하거나 자체 기술 문서에 반영할 수 있는 능력은 필요하다는 것이죠. 그래서 영문 문서 번역하는 훈련은 실제 취업(?)을 위한 역량 개발일 수도 있습니다).
여기부터는 현장 질문이라고 합니다.
(6) 윤문 과정에서 중요하게 보는 포인트는 어떤 것이 있나요?
전체적인 통일성, 스타일 가이드에 맞게 작성되었는지
쉽게 작성되었는지
그리고 쉽게 작성하는 게 신경을 쓰면서 내용이 잘못 전달되지 않는지...
(7) 개발자보다 개발 지식이 부족할 때 수정 방향성에 대한 확인을 어떻게 갖나요?
물어보면 되죠.
(8) 개발자와 테크니컬 라이터의 장단점은?
테크니컬 라이터는 다양한 기술 스펙트럼을 접근할 수 있는 기회가 생깁니다.
(물론 이건 어느 정도 연차가 쌓이면 개발자 역시 올라갈 수 있는 부분이고 테크니컬 라이터가 바라보는 관점과 개발 총괄 등의 자리에서 바라보는 건 또 다른 문제라서 딱 장점이라고 할 수는 없을 것 같네요).
단점 중 하나는 테크니컬 라이터가 무엇을 하는 일인지 설명하기가(일반인에게) 어렵다는 겁니다.
(9) 테크니컬 라이터는 어떤 팀에 속하나요?
라인의 경우에는 개발 직군.
다른 곳은 기획, 기술전략, 데브렐 등등.
(10) 기술 문서에 적을 때 영문자로 적을지 외래어 표기로 적을지
많이 알려진 용어의 경우에는 외래어 표기법 기준으로
그렇지 않다면 개발자 또는 커뮤니티에서 확인하고 작성
(11) 개발자 인터뷰 시 개발자에게 바라는 점
테크니컬 라이터는 기술을 잘 모른다는 편견은 버려주세요(뭐 이건 개발 배경이 있는 테크니컬 라이터에게만 해당하겠지만)
테크니컬 라이터를 전문직(?)으로 인정해주기를.
