직업으로서 테크니컬 라이터

내가 테크니컬 라이터로서 경력을 시작할 무렵부터 그 뒤로 수 년 동안 테크니컬 라이터가 유망한 직종에 포함되었다. 아마도 그렇게 예견한 사람들은 미국에서 GDP 같은 지표가 어느 수준에 도달했을 때 테크니컬 라이팅에 대한 수요가 크게 증가했다는 따위의 분석에 의지했을 것이다. 나는 그것이 거대 기업 하나 때문에 평균 매출이 왜곡되는 것과 같은 착각이었을지도 모른다고 생각한다. 테크니컬 라이터에 대한 수요와 보수가 미국에서만 유독 높은 것이 아닐까?

테크니컬 라이터를 찾는 일자리가 여전히 드물다. 내가 생각하기에 가장 근본적인 이유가 우리 문화가 글을 중시하지 않는 데에 있다. 캐나다 친구가 말하길, 전통적인 영어 사용 국가에서 글을 잘 쓰는 사람은 존경받고 그렇지 않은 사람들은 멸시당하는데, 그 정도가 다른 언어권보다 훨씬 심하다고 한다. 분명한 건 그 점에서 우리 사회는 정반대 편에 있다. 그래서 나는 앞으로도 테크니컬 라이터가 인기 있는 직업이 되기 어렵다고 본다. 그렇다고 이 일을 피해야 할 직업으로 볼 필요는 없다. 작은 시장에서는 경쟁도 적은 법이니까.

연유가 무엇이든 이 분야에 발을 디뎠다면, 어느 길로 갈지 모색하는 것이 좋을 것이다. 여기에서 해묵은 질문, "공학 전공자와 문학 전공자 중에 누가 더 나은 테크니컬 라이터가 될 수 있는가"에 대해 잠시 생각해 보자. 내 경험이 가르쳐준 답은 독자가 전문가인지 아닌지에 달려있다.

대부분의 매뉴얼은 불특정 다수를 대상으로 한다. 그런 매뉴얼의 내용은 설치, 사용, 관리에 국한된다. 자동차 매뉴얼이 자동차에 사용된 모든 기술의 메카니즘에 대해 설명할 필요가 없고, 따라서 테크니컬 라이터가 그 기술들을 개발자들만큼 깊이 이해할 필요도 없다. 한 제조사에서 몇 년 일하면서 개발자들의 도움을 받으면 매뉴얼을 작성하기에 충분한 지식을 갖게 된다. 그런 경우에 전공은 문제가 되지 않는다.

감당하기 어려운 일은 산업용 장비에서 겪는다. 주어진 색채와 형상의 기준에 따라 불량 곡물을 선별하는 장비에 대해 매뉴얼 작성을 맡은 적이 있다. 공장 기계들이 복잡하고 서로 매우 달라 보여도 그것들을 이루고 있는 부품들은 대동소이하다. 센서, 서보 모터, 공압 장치, 제어 보드, 배전반, 그리고 소프트웨어. 몇 차례의 경험으로 이제는 그런 것들을 별로 두려워하지 않는다. 내가 그 광학 선별기에서 겪은 어려움은 선별 기준을 설정하는 방법이었다. RGB을 비롯한 여러 값들을 설정하면 몇 가지 그래프가 나타는데 그 관계를 도무지 이해할 수 없었다. 

테크니컬 라이터에게 개발자의 도움이 무엇보다 중요하다. 내가 지금도 부끄러워하는 프로젝트는 선박 장치였는데 돌이켜 생각하면 초보자가 할 수 있는 일이 아니었다. 경쟁사의 두꺼운 영어 매뉴얼을 읽고 그것을 모방하라는 것이었다. 선박에 대한 지식이 일체 없는데다 지금만큼 영어 문서를 빨리 읽지 못했다. 지금의 나라면, 그리고 개발자들이 많이 도와준다면 그 실패한 프로젝트를 해낼 수 있으리라 생각한다.

공장 기계와 의료 장비를 포함하여 산업용 설비에서 개발자의 도움이 으레 기대에 못 미치기 마련인데, 그 이유가 대개 다음 세 가지 중 하나이다. 

첫째, 개발자들은 자신이 맡은 부분만 잘 설명할 수 있다. 
둘째, 다른 업체가 개발한 소프트웨어 라이브러리를 사용하고 있다.
셋째, 십수 년에 걸쳐 소프트웨어 개발자가 바뀌면서 핵심 코드에 대한 노하우가 전수되지 않았다.

이것들이 극복할 수 없는 장애라고 생각하지 않는다. 내가 제조사에 고용되어 많은 시간을 쏟아 그런 장비에 대한 지식을 쌓으면 능히 해낼 수 있으리라 믿는다. 하지만 테크니컬 라이터를 채용하는 제조사는 내가 아는 범위에서 매우 드물다. 이유가 무엇이든 내가 따질 문제가 아니다.

분명 내가 할 수 없는 일도 있다. 항공기 개발을 위한 소프트웨어의 문서화 프로젝트에 참여한 적이 있다. 내가 담당한 일은 쉽게 말해 "기술적인" 편집이었다. hoze.tistory.com/1860에서 그 일이 어떤 것이었는지 엿볼 수 있다. 그 매뉴얼은 많은 수식과 그래프를 포함했다. 그런 소프트웨어의 매뉴얼은 개발자만이 작성할 수 있다.

이보다 덜 극단적인 경우는 DVR 같은 장치의 드라이버 개발을 위해 디바이스 제조사가 제공하는 라이브러리 또는 구글 같은 인터넷 서비스 기업들이 제공하는 API이다. 나는 몇 차례 그런 회사에 지원한 적이 있는데, 개발자 출신의 테크니컬 라이터들이 채용된 것 같다. 나는 파이썬으로 클래스를 만들 줄 안다. 그래서 위에서 언급한 것과 마찬가지로 그런 IT 기업에서 오래 일하며 개발자들에게 배우면 API 문서를 충분히 만들 수 있으리라 생각한다. 하지만 그들은 그렇게 보지 않는 것 같다. 

이해할 수 있다. 내가 만난 고객들 대부분은 자신들의 제품이 단순하지 않다고 생각한다. 사실이다. 많은 프로젝트에서 제품에 적용된 기술들 가운데 이해하기 어려운 것들을 적어도 한두 가지 발견한다. API 소프트웨어에서는 한두 가지로 그치지 않을 것이다.

테크니컬 라이터에게 크게 두 가지의 길이 있다. 하나는 API나 그 이상의 수준에서 소프트웨어를 문서화하는 것이다. 대부분 소프트웨어를 전공한 사람들이 그 일자리를 차지할 것이다. 다른 길은 나머지 모든 분야이다. 물론 거기에서도 매우 높은 수준의 지식을 요구하는, 이를테면 석유 시추선 같은, 분야가 있을 것이다. 하지만 일반적으로 뭉뚱그리자면 나는 그렇게 두 분야로 나누고 싶다. 

API와 다른 분야로 나누는 데에 지식 말고 다른 이유가 하나 더 있다. 소프트웨어 관점에서 보자면 기능에 관계 없이 제품들은 하드웨어가 있거나 없는 것으로 나뉜다. 편의를 위해 하드웨어 제품과 소프트웨어 제품으로 나누어 보자. 그 두 가지 매뉴얼 사이에서 공통점을 찾기 어렵다. 문서 구성에서부터 문장 스타일에 이르기까지 거의 모든 점에서 서로 확연히 다르다. 

하드웨어 제품의 매뉴얼에서 가장 중요한 것은 "안전"이다. 안전이 하나의 챕터를 차지하고, 문서의 처음부터 끝까지 경고문이 두세 페이지마다 등장한다. 소프트웨어 매뉴얼에도 "Caution"이 이따금 등장하지만 그것은 고작 데이터 손실을 경고한다. 하드웨어 매뉴얼에 포함된 삽화의 많은 부분이 CAD 데이터에서 가공된 것이다. 소프트웨어 매뉴얼에는 스크린샷이 포함된다. 삽화를 만드는 과정이 서로 완전히 다르다. 스크린샷을 캡처하는 작업은 결코 단순하지 않다. 유의미한 데이터로 채워지지 않은 화면은 쓸모없기 때문이다. 하드웨어 매뉴얼은 예외 없이 PDF로 만들어지지만, 소프트웨어 기업들은 HTML을 더 선호한다. 이것은 두 분야에서 사용되는 문서 도구가 다르다는 것을 의미한다. 그밖에도 많은 차이점들이 있다. 그래서 테크니컬 라이터가 되려는 당신에게(hoze.tistory.com/1743) 같은 책은 소프트웨어 테크니컬 라이터에게 그다지 도움이 되지 않는다. 그들은 Developing Quality Technical Information 같은 책을 봐야 한다.

API 문서화는 다른 테크니컬 라이터들이 진입하기 어려운 분야이다. 그 반대도 마찬가지이다. IT 기업들은 나 같은 일반적인(?) 테크니컬 라이터를 선호하지 않겠지만, 내가 일하고 있는 곳과 같은 문서화 서비스 회사는 API 문서화만 해본 사람을 기피할 것이다.

API 문서화는 상대적으로 좁은 시장이지만 보수는 다른 시장보다 좋을 것이다. 이 시장이 얼마나 커질지 모르겠지만, 개발에 흥미를 잃은 소프트웨어 개발자들이, 더 많은 경쟁자들이 생기기 전에, 모색해볼 만하지 않을까 싶다. 나는 내가 해왔던 대로 가는 것이 합리적일 것이다.