테크니컬 라이터에게 차례는

내가 테크니컬 라이팅 지원자들을 평가하여 채용을 결정해야 할 지위에 있다면, 전혀 내키는 일이 아니지만, 어떤 과제로 그들을 잘 판단할 수 있을까? 10 여년 전에 내가 잠깐 팀장으로 있을 때 어떤 테스트도 없이 면접만으로 몇몇을 뽑았다.  그들이 해야 할 일이 테크니컬 라이팅보다 프로젝트 관리에 더 가까웠다는 사정도 있었지만, 지금도 마찬가지인데, 당시에 경력 있는 테크니컬 라이터들을 찾기 어려워서, 지원자 대부분이 대학을 마친 지 얼마 되지 않은 젊은 친구들이었고, 나는 그들에게서 적성만 보려 했다. 그들의 영작 능력이 기대에 미치지 못한다는 것을 안 뒤로 면접 뒤에 영어 번역을 시켜보기도 했는데, 솔직히 말하자면 테크니컬 라이터를 평가하기에 합당한 방법이 무엇인지 알지 못했다.

테크니컬 라이터를 구하는 광고들이 요구하는 것들은 대개 이와 같다.

- 뛰어난 문서 작성 능력
- 저작 도구 사용 경험 (이 조건은 업체에 따라 다르다. 매우 드물지만 프레임메이커 사용 능력을 요구하는 곳도 있다.)
- 개발자와 원활한 커뮤니케이션
- 영어 글쓰기 

영어로 본사 개발자와 소통할 수 있는 능력을 요구하는 경우도 있다. 아주 유창해야 하리라 생각해서 그런 곳에 지원할 엄두를 내지 못했었지만, 내가 몇몇 고객사들을 통해 목격한 바로는 깔끔하게 진행되는 컨퍼런스 콜이 없었다. 서로가 서로에게 원하는 것들을 확실하게 납득시키고 끝내는 것처럼 보이지 않았다. 영어도 문제이지만 전문가들끼리도 기술적인 문제는 대화로 풀기 쉽지 않기 때문이다. 하지만 메일이라는 보조 수단도 있으니까 결국 어떻게든 문제들을 하나씩 처리해나가는 것 같다.

영어가 단기간에 향상시키기 어려운 능력이지만, 영어를 전혀 못하는 사람이 그런 일을 맡게 될 리는 없으니, 좀 노력하고 경험하면 개선되지 않을까 싶다. 글쓰기도, 적성에 맞다면, 배울 수 있다. 테크니컬 라이팅은 다른 종류의 글쓰기와 달리 방법론적으로 잘 수립되어 있다. 그 규칙들을 익히면 훌륭하지 않더라도 정보 전달에 실패하지 않는 글을 만들 수 있다고 본다. 개발자와의 커뮤니케이션은 전제된 기술에 대한 이해가 깊을수록 수월한데, 그것 못지않게 말귀 어두운 개발자에 대한 인내심이 중요하다.

테크니컬 라이터에게 요구되는 대부분의 능력들을 가르칠 수 있고 배울 수 있다고 생각한다. 다만 쉽지 않다고 생각되는 한 가지가 있다. 바로 차례 만들기이다. 다음과 같은 목차를 전형적인 것으로 생각할 수 있지만, 실제로는 그 전형에 딱 들어맞는 경우들이 생각만큼 흔하지 않다.

Introduction - (safety) - Installation - Operation - Maintenance - Troubleshooting - Warranty - Technical Information

장 (chapter) 수준에서 고민할 것은 없다. 그보다 낮은 수준에서 여러 선택지들을 두고 고민하게 된다. 포장 상자를 열고 제품이 제대로 작동하는 것을 사용자가 확인하기까지, 그 절차가 직선적이면 좋겠지만, 그렇게 단순하지 않은 제품들이 점점 늘어나고 있다. 

제품 설치 / PLC 따위 다른 장치와 연결 / 전원 연결 / 기능 설정 / 네트워크 설정 / 웹 접속 

이 경우에 웹 접속을 마지막 단계에 두어야 할 것 같지만, 기능 설정을 마지막에 두는 것도 가능하다. 이상적인 설치 순서를 말할 수 있지만, 사용 환경이 저마다 다르기 때문에, 모든 사용자에게 그것을 따르라고 강요할 수 없다. 한 절(section)을 앞으로 당기거나 뒤로 미는 것이 간단한 결정이 아니다. 그에 따라 다른 몇몇 절들을 함께 옮기거나 내용을 고쳐야 하기 때문이다. 그 와중에 잘못 연결된 상호참조를 놓치기 십상이다.

차례 만들기는 정보 모듈을 배열하는 방법을 결정하는 것이다. 여러 지침서들을 읽은 뒤에 내가 세운 규칙들은 다음과 같다.

- 제품의 수명 주기 동안 이루어질 논리적 사용 순서를 정의하라 .
- 제품 사용의 모든 단계에서 사용자가 가질 법한 모든 의문에 답하라 .
- 사용자가 제품을 잘못 사용할 수 있는 모든 경우를 가정하라 .
- 사용자가 무엇을 가장 자주 되풀이할지 고려하라.

차례는 사용 순서뿐만 아니라 우리가 문서를 작성하는 방법에도 영향을 준다. 이를테면 "따라하기" 방식으로 글을 쓰는 것은 다소 지겨운 일이 될 수 있다. 

차례를 정해놓고 내용을 작성하라는 교과서적 지침을 나는 신뢰하지 않는다. 그것은 좁은 범주에서 비슷한 문서화를 반복하는 경우에만 가능하다. 오늘까지 가스 탐지기의 매뉴얼을 작성하고 내일부터 주차 관리 프로그램의 매뉴얼을 작성하는 나에게 그것은 따를 수 있는 방법이 아니다. 그럴듯하게 말하자면 문서화에서도 Agile 방법론을 쓸 수밖에 없다. 

그런데 "차례 만들기"를 가르칠 수 있을까? 정보 덩어리를 논리적으로 결합하는 데에 무슨 모범 답안이 있을까? 전에 이것도 방법론이라 생각하여 작성한 글이(https://hoze.tistory.com/1303) 있는데, 다시 읽어보니 너무 추상적이다.

테크니컬 라이터의 역량을 평가하는 데에 가장 좋은 방법은 그에게 차례를 만들게 하고 제1 장의 첫 절을 쓰게 하는 것이다. 그 다음에 그가 그렇게 작성한 이유를 듣는 것이다.