[리뷰] 테크니컬 커뮤니케이션

어떤 이유로 작성했는지 기억이 나지 않는데, 아마도 책을 읽다가 중간에 멈춘 모양입니다. 아마 이 시기부터 테크니컬 라이팅 관련 도서 리뷰를 남겨보자 생각을 했나 본데, 처음 잡은 책이 너무 방대한 책이라 ^^

 

최신판은 아래 링크를 참고하세요.

https://www.amazon.com/Technical-Communication-MIKE-MARKEL-ebook/dp/B0DK45ZMGQ

1장

테크니컬 커뮤니케이션의 정의와 목적을 간단하게 설명합니다. 몇 가지 내용만 뽑아보았습니다.

 

Technical communication encompasses a set of activities that people do to discover, shape, and transmit information. 테크니컬 커뮤니케이션은 정보를 발견하고 다듬고 공유하기 위한 활동을 담고 있습니다.

The biggest difference between technical communication and the other kinds of writing you have done is that technical communication has a somewhat different focus on purpose and audience. 테크니컬 커뮤니케이션이 일반적인 글쓰기의 차이는 글을 쓰는 목적과 글을 읽는 대상이 다른 초점을 갖는다는 것입니다.

이 책에서는 글로 쓰는 것 뿐 아니라 말하기, 듣기, 쓰기, 읽기 4가지 관점에서 테크니컬 커뮤니케이션을 설명하고 있습니다. 이하의 내용은 그런 관점에서 바라봐야 합니다.

Technical communication begins with identifying a problem and thinking about how to solve it. 테크니컬 커뮤니케이션은 문제를 확인하고 해결 방법을 생각하는데서 출발합니다.

첫 번째 목적에 대해서는 생각해보았지만(보통의 교과서에 나오는 내용이고), 두 번째 동기 부여라는 측면에서는 생각해보지 못한 것 같네요.

- Communication that helps others learn about a subject, carry out a task, or make a decision 사용자가 알고 싶어하는 주제를 배우거나 특정 작업을 수행하고 의사 결정을 하는데 도움이 되기 위한 커뮤니케이션
- Communication that reinforces or changes attitudes and motivates readers to take action 사용자의 의지를 확고하게 하거나 생각을 바꿀 수 있도록 동기를 부여하는 커뮤니케이션

이 책의 독자는 학부 학생을 대상으로 합니다. 1장 중간에 아래와 같은 언급이 있고, 실제 책과 연결된 사이트는 학생들을 위한 사이트로 연결됩니다.
In most of your previous academic writing, your audience has been your instructor. 학교에서 글을 쓸 때 여러분의 독자는 선생님뿐이었을 겁니다.

 

2장

2장에서는 윤리적인 문제 등등을 설명하는데 그냥 한 번 쓰윽 읽으면 좋은 정도.

상표에 관해서는 다른 곳에서 보지 못했던 내용이 있어 정리해봅니다.
- 제품 이름 뒤에 TM 기호를 붙인다고 법적 권리가 부여되는 건 아닙니다.
- 상표는 다른 텍스트와 구별할 수 있게 합니다. 굵은 글꼴, 기울임체, 다른 글꼴 등.
- 상표를 명사나 동사처럼 쓰지 마세요. 그렇게 쓰면 일반 용어로 인식할 수 있다고 합니다. 예를 들어 제록스(xerox)를 그냥 쓰면 '복사하다' 동사로 인식할 수 있어서 상표로 사용하는 경우에는 'Xerox® photocopier'와 같은 식으로 사용해야 합니다. 마찬가지로 'iPad® tablets', 'LaserJet® printers' 뭐 이런 식으로

법적인 문제는 제조 분야에서 민감한 부분이라 아마 그쪽 일을 하게 되면 좀 더 깊이 다루게 될 겁니다.
- 기본적으로 해당 국가의 법을 따라야 합니다.

한국에서는 제조물 책임법에 따릅니다. 이에 대해서 흥미로운 사례가 있어서 소개합니다.
이호재님의 블로그에서 제품 결함을 3가지로 구분하고 있는데 설계나 제조 결함에 대해서는 사용자에게 주의시켜야 할 뿐 정당화는 할 수 없다고 합니다. / hoze.tistory.com/m/586

 

3장

3장에서는 기술 문서 작성의 단계(계획, 초안 작성, 수정, 편집, 교정)을 설명합니다. 

그 중에서 계획은 1/3 정도 일정이 필요한 중요한 단계라고 설명하는데 이메일 처럼 짧은 문서라도 계획은 중요하다고 합니다.

계획에는 아래의 내용이 포함됩니다. 그냥 내용에 대한 고민 뿐 아니라 문서를 작성하기 위한 준비 작업 전반적인 내용을 포함합니다. 그래서 이메일을 보내더라도 계획이 필요하다고 하는 모양입니다.
- 독자(과업) 분석
- 저작 도구
- 배포 방식 등등

전문가 도구는 스크리브너(Scrivener)를 소개하고 있습니다. 네이버 블로그에 검색해보면 간혹 등장하긴 합니다. 한국어 가이드 문서는 공식 제공하지 않고 2018년에 번역하신 분이 있긴 하네요.

heets.tistory.com/75

맥용 글쓰기 프로그램 스크리브너(scrivener)3 의 한국어 튜토리얼 가이드

초안 작성 전에 템플릿을 만드어야 함(없다면)
- 문서에서는 워드에서 제공하는 스타일 템플릿을 사용하는 것도 나쁘지 않다고 하네요.

소개하는 팁이 독특한데 "Try invisible writing"라고
텍스트를 최대한 보이지 않게 만든 환경에서 작성한다면 중간에 멈추고 고치려는 생각이 들지 않을 것임. 그냥 초안 작성은 흘러가듯 작성하라고 합니다.

 

4장

협업에 대한 이야기입니다. 

문서 작성 규모가 크거나 다양한 저자의 참여가 필요한 경우에는 고려해야 할 부분입니다. 하지만 그 만큼 어려움도 있다는 이야기겠죠.

여기서 이야기하는 협업에는 문서 작성 계획에 필요한 정보 수집이나 미팅 등의 과정은 포함하지 않고 실제 문서 작성에 필요한 협업을 이야기합니다. 딱히 뭔가 특별한 팁은 없습니다. 일반적인 프로젝트 협업을 생각하면 될 듯 합니다.

스타일 시트를 미리 만들어야 한다 정도가 다른 부분이 아닐까 싶네요.

공동 작업 문서에 코멘트를 다는 방법 등은 기술적인 부분이라 상세히 살펴볼 필요는 없습니다.

VIRTUAL WORLDS도 살짝 다루고 있습니다.
요즘 뜨거운 메타버스 이야기죠.
비용을 줄일 수 있다는 관점에서 언급하고 있는데 문서 작성에서는 살짝 벗어난 주제인 것 같기도~