테크니컬 라이팅 강연에서 나왔던 질문과 답변 모음
알립니다 — 처음 이 글을 게시할 때에는 유료 멤버쉽 구독자 전용으로 글을 게시했지만, 많은 분들이 보실 수 있게하기 위하여 공개 글로 다시 전환하였습니다. 많이 살펴봐주시고 공유해주시면 감사하겠습니다! 또한, 글에서 오타와 누락된 부분을 보완했습니다. 피드백을 남겨주신 데브시스터즈 동료 분께 감사드립니다!
시작하며
올해 3월부터 7월까지 네 곳의 IT 기업에서 초청을 해주신 덕분에 많은 분들에게 “개발자 출신 테크니컬 라이터”로서 테크니컬 라이팅, 정보 전달을 위한 글쓰기라는 주제로 많은 분들과 커뮤니케이션하고, 저의 직업적인 커리어를 확고하게 만들어주는 좋은 강연을 해낼 수 있었습니다. 다시 한 번 제안주신 여러 관계자 여러분들께 깊은 감사의 말씀을 드립니다.
질문과 답변 모음
이번 글은 총 네 번의 강연회에서 수집된 청중들께서 올려주신 글쓰기에 관련된 문답 중 몇 가지를 선정하여 정리한 것입니다.
테크니컬 라이팅 그 자체에 대해서나, 글쓰기에 어려움을 겪고 계신 분들에게 도움이 될 수 있을 것 같아 따로 정리해 본 것으로, 역시 문답자료 공개에 동의해주신 관계자 여러분들께도 감사드립니다.
편리하게 보실 수 있도록, 다섯 개씩 나누어 질문을 배치했습니다.
Q: 글을 잘 쓰기 위해 평상시에 어떠한 훈련을 하시는지 궁금합니다.
강의 중에도 언급했지만, 다른 사람이 쓴 글이나 표현을 많이 접하고 친해지려 노력합니다. 그리고 같은 글을 내가 쓴다면 어떤 식으로 표현했을까를 상상해보려고 많이 노력하는 것 같습니다. 그리고 글을 잘 쓰려면 “많이 아는 것”도 중요하다고 보는데요, 그래서 많은 뉴스 기사나 정보를 접하려고 노력합니다.
Q: 글쓰기가 자꾸 우선순위에서 밀리는데, 정기적으로 릴리즈를 하기 위한 노하우가 있나요?
한 가지 짚고 넘어갈 것은, 제가 오늘 이 자리에서 말씀드리는 모든 내용은 “비문학적 글쓰기”, “산업 영역의 글쓰기”에 관한 내용이었습니다. 이 맥락 안에서 이야기해볼게요.
글을 꾸준히 써서 포스팅하는 것은 실제로 어려운 일이 맞습니다. 저 또한 개인적으로 운영하는 블로그에 글을 정기적으로 올리지 못하고 있기도 합니다. 글을 꾸준히 쓰는 연습을 하는 것은 좋지만, 꼭 어딘가에 글을 올려서 내보여야 한다는 것과는 분리해서 생각하시고, 꼭 필요한 상황에서 적재적소에 효율적으로 글을 쓸 수 있도록 연습을 자주 하시는 것을 권해드리고 싶습니다.
만약 문학 작가로서의 등단을 지망하고 계시거나, 문학적인 글쓰기를 목표로 하고 계신 것이라면 아쉽지만 제가 말씀드릴 수 있는 것이 많지는 않을 것 같다는 점을 다시 한 번 양해 말씀을 구하겠습니다.
Q: 글의 목차 잡기가 어려운데, 목차 잡는 노하우가 있나요?
오늘 강의에서도 말씀드렸다시피, 글의 종류 (사용자 가이드, 개발자 가이드)에 따라 어느정도 목차의 구성은 보편적으로 정해져 있습니다. 그런 목차들의 템플릿을 자산처럼 만들어서 새로운 문서를 만들일이 있을 때 그 목차부터 꺼내서 쓰시는 것을 추천드리고, ChatGPT가 이런 부분에 대해서도 답을 잘 해줄 것입니다.
다른 한 편으로 목차도 중요하지만, 글을 작성할 때 저는 흔히 쓰는 프레임워크로, 페르소나 — 시나리오 — 질문과 답변이라는 3단 구성을 많이 씁니다. 6하 원칙의 변형판이라고도 볼 수 있는데요, 페르소나는 이 문서를 누가 읽을 것인지, 시나리오는 이 문서를 가지고 페르소나에 해당하는 사람들이 무엇을 할 것인지, 그리고 질문과 답변은 각 시나리오별로 사람들이 내용을 따를 때 가질만한 의문이나 어려움들은 어떤 것이 있을지를 생각해보고 정리하는 것입니다. 이렇게 기본 뼈대를 잡은 상태에서 목차 안에 내용을 잘 분류해서 넣는다면 쉽게 문서를 완성할 수 있는 것 같습니다.
Q: 글을 쓰려고 자료를 찾다 보면 자꾸 다른 길로 빠지는데, 길을 헤매지 않기 위한 노하우가 있나요?
어떤 일을 진행하면서 집중하고 싶은데 다른 길로 빠질 것 같은 예감이 든다면, 저는 웹 브라우저에서는 읽기 목록이라는 기능을 이용해서 깊이있게 읽어봐야 할 내용은 나중에 다시 읽어볼 수 있도록 보관해두는 기능 (즐겨찾기와는 다릅니다.)을 이용해서 정리해 두고요, 슬랙이나 유사 메신저들에서는 나중에 알림 기능을 이용해서 긴급하게 답해야 할 내용이 아니라면 시차를 두고 목표한 작업을 모두 달성했다고 생각했을 때 하나씩 처리하는 것을 선호합니다.
Q: 글을 쓰는 것도 중요하지만, 글이 많은 사람들에게 읽히게 하는 것도 중요하다고 생각합니다. 그런 관점에서 내가 쓴 블로그 글 등을 좀 더 포털 등에 잘 걸릴 수 있게 하는 노하우가 있을까요?
다소 식상한 답변일 수는 있지만, 사람들의 눈에 잘 띄게 하기 위해서 가장 중요한 것은 역시 태그 선정과 초록 (abstract)을 어떻게 잘 쓰는가에 달려있지 않을까 생각합니다. 그리고 그에 앞서, 정말 사람들에게 도움이 될 만한 “영향력”을 줄 수 있는 정보를 담은 글인가가 노출 횟수에 많은 영향을 주지 않을까 생각합니다.
Q: 글 쓴 것들에 대한 정리는 어떻게 하시는지 궁금합니다. 나중에 다시 작성한 글을 찾게 될 경우 쉽게 찾는 남정현님만의 정리법이 궁금 합니다.
“썼던 글을 잘 정리하고 나중에 다시 찾아서 재활용할 수 있는 가능성을 높이는 제일 좋은 수단은 아무래도 위키에 글을 남기는 것이라고 생각합니다. 단, 위키를 메모장처럼 사용하거나, 다른 사람이 볼 수 없도록 글을 비밀스럽게 쓰는 것 보다는, 처음부터 공개적으로 많은 사람들이 볼 수 있도록 열어두려고 노력합니다.
이렇게 하는 이유는 같은 주제를 놓고, 기존에 완성된 문서를 보완하는 것이 아니라, 중복된 문서를 발견하지 못해서 매번 새롭게 쓰게 되서 문서가 흩어지는 것을 예방하기 위함입니다. 기존에 작성된 문서를 발견할 수 있는 확률을 높이기 위해 위키의 기능을 최대한 많이 학습해서 활용하는 것이 저만의 정리법이라고 생각합니다. (또한 이런 작업을 팀원 모두가 쓰는 위키를 대상으로 진행한다면, 이를 위키 정원을 가꾼다고 하여 위키 가드닝이라고도 부르기도 합니다.)”
Q: IT 지식 부족해도 최대한 이해할 수 있게 쉽게 글쓰는 방법이 있을까요?
중은 자기 머리를 못 깎고, 요리사는 자기 음식을 못 먹는다는 말이 있듯이, 자기가 잘 아는 내용을 지식이 부족한 사람을 위해 설명하는 것은 매우 고통스러울 수 있습니다. 쉽지는 않겠지만, 입장을 바꿔서 “그럴 수 있어” 라고 생각하고, 독자의 시선에서 글을 읽어보고 무엇을 어떻게 알려줘야 할지에 대해 고민해보면서 글을 쓰시는 방법이 좋다고 생각합니다.
물론, 이렇게 글을 작성하다보면 설명해야 할 내용이 너무 많고 깊어져서 길을 잃기 쉽습니다. 이런 경우 크게 두 가지 접근 방법을 생각할 수 있는데요, 첫 째는 내가 쓰는 글에 레벨을 정하는 것입니다.
글에서 설명할 난이도를 미리 설정하면, 얼마나 구체적이고 상세한 정보를 담아야 할지 기준을 정할 수 있게 됩니다. IT 지식이 부족한 독자들을 위해서 글을 써야 한다면, 깊이있는 내용보다는 전반적인 배경과 맥락을 이해할 수 있는 정보들을 중심으로 우선 순위를 두어서 설명할 수 있을 것입니다.
둘 째는 내가 쓰는 글의 기-승-전-결, 일종의 목차를 정하는 것입니다. 글을 어떻게 풀어나갈지, 그 끝에 어떤 메시지를 전하고 싶은지를 글을 먼저 쓰지 않고 스케치를 먼저 하는 것입니다. 일러스트로 인체를 그릴 때, 인체 비율부터 그리는 연습을 하는 것이 좋다는 이야기를 많이 들으셨을텐데요! 글을 쓸 때에도 마찬가지라고 생각합니다. 의식의 흐름을 따라 글을 써내려가면 맥락을 잃어버리기 쉽고, 목적을 달성하지 못하는 애매한 글이 만들어지기 쉽죠!
그렇게 만든 뼈대를 가지고 IT 지식이 부족한 독자들에게 어필할 수 있는 글이 될 것인가 아닌가를 판단하는 것도 수월할 것이고, 혹시 큰 폭으로 수정해야 하더라도 부담없이 글의 구성을 변경하여 목적을 달성하기 좀 더 쉬워질 것이라고 생각합니다. 내용을 먼저 써내려가기 시작한다면 나중에 바꾸기가 무척 어려워지니까요.
Q: 책을 읽는 것이 글쓰기에 많이 도움이 될까요?
책을 읽었으므로 글쓰기에 도움이 될 것이다” 라고 단언하기는 어렵습니다. 그러나, 책을 읽는 과정에서 일어나는 다양한 경험치 축적이 장기적으로는 글을 쓰는데 도움을 줄 확률을 높이는 “투자”라고는 생각합니다. 그런데 저는 책을 읽는 것을 썩 좋아하진 않습니다. 사람마다 정보나 경험치 축적을 하게 되는 경로는 다양할 수 있으니 취향과 기호에 맞는 방법으로 정보를 습득하는 채널을 만드신다면 좋을 것 같다는 의견을 드려봅니다.
Q: 글을 쓰다 보면 글씨 크기는 어떻게 해야할지, 줄바꿈을 어디서 몇 줄이나 해야 할지, 한 문단에 글을 얼마나 담아야 할 지, 목차 구성은 어떻게 해야 하는 지 등등 내용 외적인, 가독성 측면에서 고민이 많습니다. 글이 너무 빽빽해 보이지도 않고 그렇다고 스크롤이 너무 길어지지도 않도록 글을 가독성 있게 쓰는 방법이 궁금합니다.
테크니컬 라이터의 입장에서는 “적절한 텍스트와 문단 배치”를 통해서 정보를 효과적으로 전달할 수 있도록 글을 구성하는 것이 중요하다고 생각합니다. 전달해야 할 텍스트의 내용이 많아서 가독성을 신경써야 하는 상황이라면, 애초에 텍스트를 좀 더 줄이거나 읽기 쉽게 구성할 수 있는 여지는 없을지에 대해 고민을 해볼 것 같습니다.
그러나 내용에 대한 고민을 할 수 없거나, 이미 완성된 문서의 가독성이나 심미성에 초점을 맞추어야 한다면, 이는 테크니컬 라이팅의 영역이 아닌 디자인의 영역이라서 제가 답을 직접 드리기는 어려울 것 같다는 점 양해 말씀 구하겠습니다.
Q: 이론적인 부분과 더불어 실무에서 적용된 “쉽고 사용자가 이해하기쉬운” 문장 예시 같은것들도 궁금합니다~
실무에서 적용된 문장 예시를 구체적으로 들기는 워낙 케이스가 많고 다양해서 콕 집어서 말하기는 어려울 것 같습니다. 다만 어려운 내용을 독자를 잘 정해서 이해하기 쉽게 쓴 잘 된 예제를 하나 들어볼 수 있다면, “누구나 쉽게 이해할 수 있는 Git 입문”이라는 웹 사이트의 콘텐츠가 괜찮은 예제라고 생각합니다. (https://backlog.com/git-tutorial/kr/)
Q: 같은 사실도 직무나 경험에 따라 서로 이해하고 있는 범위나 방향이 달라 커뮤니케이션 시 생각을 주고 받는 게 어렵습니다. 글쓰기나 말하기 전 주제를 풀어나갈 때 생각의 기준을 어떻게 잡아야 할까요?
같은 사실을 서로 다르게 알고 있는 원인은 말씀하신대로 서로 다른 백그라운드를 가지고 있기 떄문이죠. 좀 극단적인 예를 하나 들어보겠습니다. “security”라는 단어가 IT 직군에서는 정보 보안이라는 의미를 가지고 있지만, 군사 분야에서는 “물리적인 보안”이라는 의미를 가지고, 또 경제 분야에서는 “담보”라는 뜻을 가집니다. 이처럼 단어 하나도 매우 다르게 해석이 될 수 있음을 인지하고, 프로젝트에 참여하는 사람이 하나의 백그라운드를 갖출 수 있도록 “용어집”을 만들어서 지속적으로 생각의 기준을 동기화할 수 있도록 노력하는 것이 필요하다고 생각합니다.
Q: 작성하고자 하시는 글의 깊이를 정하는 방법이 궁금합니다. (독자를 임의로 정하거나, 기술 스택을 정해서 하시는지 등)
전달할 내용을 들을 사람의 이해도를 레벨로 정의하는 테크 레벨 스키마를 정해두면 유용합니다. 보통 4단계로 이야기하며, 100은 초심자, 200은 유경험자, 300은 전문가, 400은 상급자로 설정하고, 여기에 맞추어 글을 쓰거나 전달할 내용을 간소화할지, 구체화할지 여부를 정할 수 있을 것이라고 생각합니다.
Q: 테크니컬 라이터가 글을 쓸 때, 독자에 따라 글 쓰는 방법이 다를까요? 다르다면 어떤 점을 고려해서 작성하시나요? 예를 들어,개발자간 공유 문서, 사용자 가이드 같은 것이 궁금합니다.
독자에 따라 “어떤 글”을 쓸 것인지가 달라지므로, 글 쓰는 방법도 달라진다고 말할 수 있습니다. 가전 제품을 예로 들어보죠. 가전 제품을 구매해서 사용하는 일반 사용자에게는 “분해 수리 방법”이나 내부에 들어가는 펌웨어의 API 명세, 회로 구성, 부품 무결성 확인 방법을 이야기할 이유가 없습니다. 반대로, 자가 수리 전문가를 위한 지침에서는 이런 정보들이 반드시 들어있어야 할 것입니다. 소프트웨어의 경우에도 마찬가지겠죠!
Q: 좋은 테크니컬라이터가 갖춰야될 역량이 있다 한다면, 일반적인 개발자가 갖춘 소양과 비교하여 어떤 부분들이 더 필요하고, 어떤 부분들은 덜 필요할까요?
테크니컬 라이터에게 필요한 역량은 역시 “정보 전달 능력”이라고 생각합니다. 여기에는 글쓰기와 같은 전통적인 역량은 물론이고, 정보를 구조화해서 체계를 만드는 기획력, 그리고 이를 매체에 녹이기 위한 다양한 본인만의 수단을 갖추는 것으로 완성된다고 생각합니다. 그 수단이라는 것이 어떤 분은 글쓰기일 수 있고, 어떤 분은 영상 녹화나 편집일 수 있으며, 또 어떤 분은 소프트웨어 개발 일수도 있습니다.
Q: 테크니컬 라이터라는 직종이 개인적으로는 다소 생소한데, 개인적으로 생각하시는 해당 직군의 미래전망이나 비전이 있다면 공유해주세요
테크니컬 라이터는 상당히 오래된 직군입니다. 본디 공장 자동화 분야에서나 가전 제품 분야에서 최종 사용자에게 하드웨어의 조작법을 설명하거나 가이드 출판을 담당하는 것이 주된 업무이고, 광의적으로는 글을 “비문학적”으로 다루는 모든 일을 가리키기도 합니다.
예를 들어, 법조계의 경우 법에 관련된 글쓰기, 의료계의 경우 의료 전문 지식을 다루는 글쓰기를 하는 사람, 마케팅 분야에서는 카피라이터, 소프트웨어의 경우 UI/UX 라이터, 그리고 최근 LLM AI의 경우 AI가 어떤식으로 입력을 받아들이고 어떤 출력을 낼 것인지까지 설계하고 고려하는 프롬프트 엔지니어링까지 광범위한 분야에 걸쳐 테크니컬 라이팅이 이루어집니다.
그리고 테크니컬 라이팅을 넘어 이 모든 것을 테크니컬 커뮤니케이션이라고 부르는 것을 저희 직군에서는 선호하며, 이것이 미래 전망이나 비전을 잘 표현하는 이름이라고 생각합니다. 즉, “정보를 구조화하고 가공하는 일”이 필요하다고 여겨지는 한 계속 수요나 응용 폭이 넓어질 수 밖에 없다고 생각합니다.
Q: 아티클 작성 시 흥미를 유발하게끔 첫 문단을 잘 써야 한다는 압박 때문에 글쓰기가 오래 걸리는 편입니다. 그래서 찾아보니 주제를 나타내는 문장 외에 의문형으로 첫 문장을 시작해도 독자의 관심을 끌 수 있다는 정보를 본 적 있는데 다른 팁도 있으실까요?
어떤 종류의 아티클을 쓰시는가에 따라 달라진다고 생각합니다. 질문해주신 내용은 마케팅 콘텐츠나 정보 전달 목적의 블로그 포스팅에 관한 내용으로 보이는데, 문장으로 인입 (Ingestion)을 유도하는 스킬 중 하나로 말씀하신 “질문 던지기”를 많이 사용하는 것 같습니다.
제 경우 특별히 더 좋은 팁이 있다거나 한 것은 아닙니다. 다만, 가장 기본적인 부분이 될 것 같은데요, 아티클을 누가, 왜, 어떻게, 무엇을 위해 읽는가에 대한 분석이 가장 기본이 된다고 생각합니다. 독자 분석이 충분히 이루어진 상태에서 접근한다면, 글의 기본 성분을 쉽게 완성할 수 있을 것이고, 이를 토대로 많은 리뷰어들과 함께 논의를 하면서 사람들의 이목을 끄는 포인트를 더 잘 잡을 수 있을 것이라고 생각합니다.
그리고 글을 어떻게 표현하는가에 대한 기교보다는, 글 자체가 무엇을 담고 있는지, 어떤 내용을 전하고 싶은지가 정말 중요하다고 생각합니다. 그렇기에, 특별한 기교나 복잡한 서식을 적용하지 않았어도 바이럴을 통해 긱뉴스에 소개된 포스트가 몇 가지 있습니다. (https://news.hada.io/topic?id=8292, https://news.hada.io/topic?id=6991)
Q: Human-AI Interaction Design이 중요해짐에 따라 마이크로소프트, 구글 등 다양한 기업에서 가이드가 나오고 있습니다. 이런 가이드는 다양한 리서치와 사용자들의 참여가 필수적인데요, 저희 같은 경우에는 매우 한정된 리소스로 소수의 인원이 참여하여 작성하게 됩니다. 이런 제약을 극복하는 데에 있어 도움될 만한 조언을 부탁드려도 되나요?
이전에는 테크니컬 라이터가 정보를 수집해서 사람들에게 어떤 정보를 전달할 것인가에만 초점을 맞추었다면, 이제는 제품을 접하는 사용자의 엔드-투-엔드 경험안에 테크니컬 라이터가 모두 개입하는 것이 필수라고 생각합니다. 하지만 말씀하신대로 경영적인 이유로 인해 많은 인원을 투입하지는 못합니다.
그래서 문서화 엔지니어링, 문서 자동화, 컴퓨터 기반 번역 도구 (CAT), LLM AI 프롬프트 엔지니어링 같이 적극적인 자동화를 통해 테크니컬 라이터가 콘텐츠의 본질에만 집중할 수 있게 하고, 다른 사람에게 위임하거나, 자동화의 이점을 얻을 수 있는 부분은 최대한 자동화를 하는 전략이 많이 필요할 것이라고 생각합니다.
다만 이런 자동화의 이점을 잘 누리려면, 테크니컬 라이팅에 참여하는 분들 모두 본인의 이력이나 배경과는 무관하게 소프트웨어 공학이나 소프트웨어 엔지니어링을 적극적으로 수용하고 활용하려는 자세가 반드시 필요하다고 생각합니다. 이것이 IT 분야의 테크니컬 라이터, 테크니컬 커뮤니케이터, UI/UX 디자이너들에게 요구되는 새로운 챌린지라고 생각합니다.
Q: 데브시스터즈에서는 다양한 도구를 활용하여 조직 차원에서 문서화를 추진하고 그 문서화 KPI를 추진하고 계신 점이 흥미롭다고 느껴왔습니다. 조직의 성과로 이를 인정하고 있는 사례가 구체적으로 듣고 싶습니다!
최근 2~3년 내에 가장 크게 진행했던 조직 차원의 문서화 사례로, 데브시스터즈의 Notion 기반 엔터프라이즈 포털 사이트인 TEAMDEV Home이 있습니다. TEAMDEV Home은 현재도 계속해서 발전해나가고 있으며, HR 부서, IT 지원 부서, 복지 부서 등 여러 핵심 부서들이 구성원들에게 전해야 할 정보들을 지속적으로 TEAMDEV Home 내 가이드 문서에 꾸준히 업데이트를 하면서 최신 상태를 유지하고 있습니다.
TEAMDEV Home과 관련된 자세한 내용은 https://www.notion.so/ko-kr/customers/devsisters 문서에서 읽어보실 수 있습니다.
이외에도, 노션을 기반으로 다양한 활동 (뉴스레터 발행, 각종 문서 관리, 회의록 관리)을 데브시스터즈 내 여러 법인과 팀에서 적극적으로 수행하고 있습니다. 몇 가지 예외를 제외하면, 대부분의 문서화는 노션을 사용하는 것이 데브시스터즈 내에서 de-facto standard (사실 상의 표준)로 깊이 자리잡게 되었습니다.
Q: ChatGPT를 활용하여 자료 수집, 정리, 오류 검토 등이 손쉬워지면서 점차 콘텐츠를 자동 생산하는 방법들도 많이 생겨나고 있는데요. GPT 외에 또 다른 자동화 도구를 소개해 주신다면 어떤 게 있을까요?
LLM AI 이외에도 제가 일하는 테크니컬라이팅 팀에서는 Phrase (구 Memsource)를 이용하여 기술 문서 번역을 진행하는 것을 시험해보고 있고, 번역 백엔드로는 DeepL와 Google ML Translator를 시험해보고 있습니다.
그리고 영어 작문을 할 때, 좀 더 네이티브 잉글리시에 가까우면서, 상황과 맥락에 맞는 어휘나 T&M을 잡아주는 Grammarly 같은 도구도 적극 활용해서 영작 효율을 많이 높이고 있습니다.
테크니컬 라이팅 팀 이외의 곳에서는 콘텐츠 현지화를 위해 Lokalise를 이용하고 계시고, ChatGPT에 프롬프트 엔지니어링을 접목해 게임 콘텐츠 창작을 실험해보고 계신 것으로 알고 있습니다.
Q: Stripe, Google Developers, Amazon Alexa, Apple Developer, Netfix, 우아한형제들, 당근마켓, 44BITS, WiteTheDocs, Kakao Tech& 처럼 잘 관리되는 기술 블로그 및 콘텐츠가 많아지고 있는데, 연사님이 좋은 글이라고 생각하고 즐겨찾는 기술 작가 또는 기술 채널은 무엇인가요?
저는 Microsoft MVP로서 지금도 활발하게 활동하다보니 Microsoft Learn의 기술 자료를 찾아볼 일이 자주 있어서, Microsoft Learn 사이트의 여러 문서나 Microsoft Writing Style Guide를 자주 참고하여 문서를 작성합니다.
그 외에 특별히 정해놓은 채널은 없지만, IT 관련 지식으로는 긱뉴스, 해커뉴스, 스택오버플로우, 네오윈 등 기술 관련 커뮤니티에서 많은 인사이트와 정보를 얻고 있으며, 선별에 많은 에너지를 써야 하긴 하지만, 그럼에도 시중 언론 매체들 (주요 언론사)의 기사도 자주 접하면서 요즈음의 트렌드나 현상도 균형있게 살펴보면서 인사이트를 얻으려 많은 노력을 기울이고 있습니다.
그리고 테크니컬 라이팅 자체에 관해서는 Technical Writer HQ 웹 사이트에서 많은 인사이트를 얻고 있습니다.
Q: 글을 쓰는 것이 코드를 작성하는 것보다 더 어렵게 느껴집니다.
그렇습니다. 쉽지 않죠! 차라리 코드는 컴파일러, 린터, 문법 검사기라도 있으니 뭐가 틀렸는지 바로 알 수 있지만, 글은 리뷰어의 손을 거치기 전까지는 잘못을 알아차리기까지 꽤 시간도 걸립니다. 그리고 코드랑은 다르게 오만가지 표현을 쓸 수 있는 글은 선택 장애를 유발하기도 합니다.
일단 내가 글을 어떻게 써야 할 것인가에 대해서는 코드를 작성하는 것과 비슷한 마인드셋을 갖추면 좋다고 생각합니다. 구성적인 측면에서는 독자 분석과 목차 설계를 연습하면서 자신만의 스키마를 갖추는게 좋겠습니다.
쓰여진 글이 타당한가를 살펴보기 위해서는 맞춤법 검사기 같은 기계적인 도구도 괜찮고, 영작이라면 Grammarly 같은 AI 기반 검증 도구를 이용할 수도 있습니다.
탈고가 가장 고통스러운 작업이 될 수도 있는데, 이 때에는 컴퓨터 화면을 벗어나서 일부러 종이에 인쇄를 해서 내용을 본다거나, 스마트폰이나 TV 등으로 문서를 가져가서 편한 자세로 문서를 읽어보세요. 보이지 않던 것이 보이기 시작할 겁니다.
그리고 가장 중요한 것 — 글 쓰기에는 왕도가 없습니다. 캐시에 저장된 데이터가 있으면 응답 속도가 빠른 서비스를 만들 수 있는 것처럼, 글쓰기도 충분한 연습과 경험치 축적을 통해 본인만의 글쓰기 노하우 캐시, 즉, 글 쓰기 근육을 만들어야 한다는 것입니다.
Q: 글쓰기에 대해 잘 모르지만 글이 더 비정형화(?) 되어 있어서 그렇다고 생각하는데, 특히 기술적인 문서 혹은 Article을 쓸 때 정형화된 접근방법 같은 것이 있나요?
저는 글을 쓸 때 3단 분석을 주로 채택합니다.
- 누가 글을 읽는가 / 제품을 사용하는가
- 글을 통해 독자가 뭘 알고 싶어하는가 / 제품을 통해 사용자가 할 법한 일들은 무엇이 있을까
- 독자가 정보를 얻으려할 때 막힐 만한 부분이 무엇이 있고, 이를 해소하려면 뭘 해야 할까 / 제품을 사용하다가 마주할 수 있을 만한 어려움이 무엇이 있으며, 이를 해결하려면 뭘 해야 할까
이와 같이 구성을 시작하면 정보 전달을 위한 정형화된 글쓰기의 뼈대로는 나쁘지 않은 구성이 나오는 것 같습니다.
여기에 더해, 문서에 대한 접근성을 높이기 위한 다양한 수단 — 논문에는 초록 (Abstract)을 잘 써두는 것, 블로그 아티클에서라면 해시 태그나 키워드 선정을 잘 해두는 것과 같은 부수적인 옵션을 더하게 될 것 같네요.
Q: Chat GPT와 같이 글쓰기에 도움이 되는 도구를 사용하는 것이 작가의 ‘글쓰기 역량’에 어떤 영향을 끼친다고 생각하시나요? 검토 목적으로 사용을 많이 하고 있는데 의존성이 생기는게 두렵기도 하고, 글작성 시에 어떻게 활용하면 좋을지도 고민됩니다. 정현님은 얼만큼 어떻게 활용하고 계신가요?
저는 ChatGPT를 Firestarter, 즉 글을 쓰기 위한 초안을 만들어주는 도구로 유용하게 잘 활용하고 있습니다. 저는 문학 작가가 아닌 비문학 작가이며, 창작성과 독창성이 중요한 사람은 아닙니다. 그보다는 정보를 전달하는 것이 가장 큰 일이고 해결해야 할 일이기 때문에 ChatGPT를 활용할 수 있는 도구로 얼마든지 쓸 수 있다는 입장입니다.
ChatGPT는 그럴듯해 보이는 출력을 내보이긴 합니다만, 몇 가지 치명적인 한계들이 존재합니다. 대표적으로 사람처럼 추론이 불가하기 때문에, 주어진 입력 이상의 정보나 추측, 예측 같은건 하지 못하죠! (그래서 플러그인의 의미가 더 강력해지기도 합니다.)
그리고 자신만의 논점을 이야기하거나 주장하지 못하며, 일관성이 없는 답변을 자주 볼 수 있습니다. 뿐만 아니라, 같은 질문에 대한 답도 그 때 그 때 달라서 일관성이 결여되는 모습도 자주 볼수 있습니다.
반면, ChatGPT는 언어 모델을 서비스화한 것이므로, 평소에 자신이 확신을 가지고 이야기하지 못하는 주제에 대한 답을 창작하는 것에는 큰 도움을 받을 수 있습니다. 부끄럽습니다만, 제 경우 어떤 팀이나 조직의 미션과 비전을 정하라고 할 때 이 둘을 정확히 구분해서 이야기하는 것을 어려워 하고, 또, 목적과 목표를 나눠서 이야기하는 것을 어려워하는데, 이런 부분을 LLM AI의 도움을 얻어 교정을 받는 일은 생산성에 큰 도움이 됩니다.
정리하면, ChatGPT는 충분히 의존할만한 도구이지만, 계속 자주 사용하다보면 ChatGPT의 한계도 명확히 알 수 있게 됩니다. 원한다고 해도, ChatGPT 만으로 만사를 해결할 수 없다는 것을 빠르게 깨달을 수 있을 것입니다.
Q: 업무상 작성하게 되는 기술문서 외에, 개인 블로그 등으로 작성하실 때 주제 선정의 기준이나 동기가 궁금합니다. 그리고 글쓰기는 시간과 에너지가 많이 소요될텐데 일상적으로 이를 위한 스케줄링을 어떻게 하시는지 궁금합니다.
역시 제일 중요한 것은 본인이 정말로 즐기고 재미있어 하는 주제를 찾는 것이라고 생각합니다. 그리고 그런 주제를 가지고 글을 쓸 때에는 정말 다양한 조사와 취재 과정이 필요할테니, 꼭 도서관에 앉아서 책을 읽는 것 뿐이 아니라 비판적인 사고를 가지고 다양한 매체와 현상을 접해보시는 것이 중요합니다. 강연에서도 말씀드렸다시피, 글쓰기에서 나오는 표현의 학습 과정은 y=f(x) 같은 알고리즘이나 수식으로 표현할 수 있는 것이 아닙니다.
스케줄링은 사람마다 전략이 모두 다 다를 것 같은데요! 제 경우에는 평소에 내가 어떤 글을 써야겠다고 생각하는 주제가 있다면, 그것을 제텔카스텐과 같이 메모를 데이터베이스 형태로 보관해둡니다. 나중에 이것을 엮어서 글을 쓰는 방식으로 짧은 시간에도 글을 빠르게 쓸 수 있도록 빌드업하려고 준비를 하기 때문에, 자주 글을 쓰진 못하지만, 글을 써야겠다고 마음을 먹으면 2~3시간 안에도 글을 써내는 것 같습니다.
Q: 하나의 글을 완성하는 것을 넘어, 스스로 작성한 여러 편의 글이 나의 전문성과 생각을 대변해주는 기록이 되었으면 좋겠습니다. 고려해야 할 점이 있을까요?
회사에서도 브랜드 보이스가 중요해지는 시대가 되었지요! 개인도 마찬가지라고 생각합니다. 스스로의 전문성과 생각을 대변해주는 기록이 되기 위해서는, 본인이 “무엇을 하는 사람”이고, “무엇을 가치있게 생각하는 사람”인지 본인만의 보이스, 브랜드 아이덴티티를 구축해야 할 것이라고 생각합니다.
제 경우에는, 20여년 이상 “마이크로소프트 개발자 기술 전문가”로서의 브랜드 보이스와 이이덴티티를 구축해왔었습니다. 그리고 이를 시작점으로 다양한 커뮤니티에서 활동하면서 “스페셜티”를 갖춘 전문가로서 활동하려고 많은 노력을 기울였습니다.
질문해주신 분께서도 본인의 커리어와 관심사를 토대로 이런 아이덴티티를 찾는 과정을 계속 반복해보시면 어떨까 생각합니다.
Q: 꼼꼼한 내용과 한눈에 잘 들어오는 내용, 두 마리 토끼를 잡을 수 있는 구성과 표현방식은 어떤게 좋을까요?
역시 독자 분석을 철저히 해두는 것이 중요하지 않나 생각합니다. 독자가 누구인지를 알아야 꼼꼼함의 정도 (정보의 해상도)를 올바르게 정할 수 있고, 한 눈에 잘 들어오도록 구성을 하는 방식 (다이어그램을 쓸지, 사례 중심으로 쓸지, 동화책의 삽화로 쓸지 등)도 정할 수 있다고 생각합니다.
Q: 맞춤법 교정 툴 어떤 것을 쓰시나요? 요즘 글들을 보면 가독성 또는 글의 스타일을 위해 맞춤범이 완벽하지 않아도 허용하는 부분이 있는 것 같습니다. 정현님은 어느 ‘정도’를 지키시는지도 궁금합니다.
한국어의 경우 특별히 쓰는 도구는 없지만, OS나 오피스 스위트, 브라우저가 제공하는 기본적인 맞춤법 도구를 적당히 활용하고 있습니다. 영어의 경우 Grammarly를 적극적으로 활용하고 있고요!
강연에서 말씀드린 것과 같이 우리는 비문학을 다루는 사람들이며, 정보를 전달하는 것이 목적인 사람들입니다. 개인적으로는 규칙을 지키는 것이 정보를 전달하는 것보다 높은 우선 순위를 가진다고 생각하지는 않다고 생각합니다.
“설루션”과 “솔루션” 예를 들었을 때처럼, 우리가 정보를 전달해야 할 대상이 국어의 문법에 중요한 가치를 두는 사람들이고, 문법에 관해 올바른 정보를 전달해야 하는 입장이라면, “설루션”이라는 어색하지만 국문법 상 맞는 표기를 쓰는 것이 타당할 것입니다.
반면, 바로 옆 자리에 앉아있는 동료나 고객사들을 위한 제품 가이드를 쓰는 자리에서 “설루션”이라는 표현을 고집할 이유는 없을 것입니다.
즉, “정도”라는 것이 따로 있지는 않다고 생각합니다. 그 보다는, “정보를 잘 전달할 수 있겠는가?” 라는 질문에 따라 기준을 유연하게가지고 간다고 생각합니다.
Q: B2B 고객 대상 안내 매뉴얼 및 기술문서를 쓰면서 무엇을 어디까지 설명해야 할지, 어떻게 해야 더 쉽게 설명할 수 있을지 잘 모르겠습니다. 기술문서를 비개발자가 읽도록 쓰는 기술에 대해서도 궁금합니다.
독자 분석이 중요함을 반복해서 계속 말씀드리게 됩니다! 그리고 3단 구성에 따라 안내하려는 내용이나 전달하려는 기술 정보를 가지고 독자들이 궁금해할 만한 내용, 하고 싶어할 만한 일들을 열거하고, 이를 토대로 정보를 전달하는 것이 중요하지요.
기술 문서를 비개발자가 읽도록 쓰기 위해서는 약간의 응용이 필요할 것이라고 생각합니다. 한 번에 많은 정보를 전달하는 것보다, 비개발자가 기술 문서의 내용에 익숙해질 수 있도록 단계별로 참여할 수 있도록 학습 경로 (Learning Path)를 만들어주는 것이 필요하지 않는가 생각합니다.
이런 학습 경로를 잘 만든 예시를 꼽자면 저는 Microsoft Learn 사이트의 학습 모듈들이 좋은 예제라고 생각합니다. (https://learn.microsoft.com/en-us/training/)
Q: 기술 문서, 가이드라인 등이 조직 내외부적으로 통용되는 규칙으로 자리잡기 위해서(이해하고 공감하는 것을 넘어 일상적으로 실행하도록 만들기 위해서) 어떤 노력들이 필요한가요?
문서화가 주는 가치, 효용성을 이해할 수 있는 계기를 한 번 이상은 접하셔야 다음을 이야기할 수 있지 않을까 생각합니다.
그래서 한 방에 모든 것을 문서화하기보다, 작은 영역이지만 문서화가 되지 않았었기 때문에 문제가 되거나 아쉬웠던 부분이 어떤 게 있었는지 회고 등을 통해 충분히 파악해보시고, 이런 문제를 해결하기 위한 문서화를 작은 단위에서부터 점점 규모를 키워나가보면서 시도해보시면 자연스럽게 문서화를 정립시킬 수 있지 않을까 생각합니다.
그리고 가능하다면, (주제넘는 이야기일 수 있겠습니다만) 상위 리더십을 가지고 계신 리더 분들께서도 문서화에 대한 관심과 투자를 더해주시는 것이 문서화를 촉진하는데 큰 도움이 된다고 생각합니다. 그 중에서도 기술 리더십을 가지고 계신 분들이라면 특히 문서화의 가치와 중요성을 더 잘 알고 계실 것이라고 생각합니다.
그 외에도, Notion을 사용하면서 체득한 정보를 공유해주신 분도 계셔서 나눔해봅니다.
업무 생산성 도구로서, 콘텐츠 생산 도구로서, 노션을 많이들 사용하고 있는데 공유하 고 싶은 정보가 있어 아래에 남깁니다!
- Notion VIP는 노션 사용자들을 위한 커뮤니티 사이트입니다. 노션 사용 관련 정보를 제공하며, 다양한 종류의 노션 템플릿을 제공하고 있습니다.
- Notion Depot은 노션 템플릿 공유 사이트 중 하나로, 다양한 분야의 노션 템플릿을 제공하고 있습니다. 또한, 사용자들은 직접 템플릿을 제공하고 공유할 수도 있습니다.
- Notion Templates는 노션에서 제공하는 공식 템플릿 페이지입니다. 노션에서 제공 하는 다양한 종류의 템플릿을 제공하며, 사용자들은 이를 활용하여 자신만의 노션 페이 지를 만들 수 있습니다.
- r/Notion은 노션 관련 정보를 공유하는 레딧 커뮤니티입니다. 노션 템플릿을 비롯한 다양한 정보를 공유하고, 사용자들은 자신의 템플릿을 공유할 수도 있습니다.
마무리
앞으로도 테크니컬 라이터로서 업을 이어나가면서, 더 많은 분들께 정보를 전달하기 위해 글을 쓰고, 문서화를 하는 작업의 중요성과 가치를 전하는 일을 계속 해 나가고 싶습니다.
하반기에도 계속해서 외부 강연을 진행할 예정이오니, 글쓰기나 문서화에 관련된 고민이 있으시다면 함께 나누면서 다같이 성장할 수 있는 계기를 마련하면 더할 나위없이 좋을 것 같습니다. :-D
