2018.06.18

블로그 | IT 개발자를 위한 글쓰기 가이드

Andrew C. Oliver | InfoWorld
개발자가 코드만 잘 써야 하는 것은 아니다. 글을 잘 쓰는 개발자는 커리어 경로에 있어 월등히 유리한 입지를 확보하게 된다.

필자가 다른 개발자와 함께 일을 하거나 이들을 멘토링할 때 느끼는 점은 글 쓰는 기술이 취약한 사람이 많다는 것이다. 이는 ‘글이 조잡하다거나’ 또는 제2언어를 쓸 때처럼 문법이 틀렸다거나 하는 차원을 넘어선다. 문제는 일정한 의도에 따라 생각을 체계화하여 독자에게 전달하지 못한다는 것이다. 누구나 한번쯤은 겪는 문제이긴 하다.

기술 계통 사람에게 완벽한 문법이나 문장을 기대하는 이는 드물다. 그러나 사람들이 이해할 수 있는 방식으로 사실을 명확히 전달할 수 있을 것이라는 보편적 기대치는 존재한다. 이러한 기대에 부응할 수 있느냐 없느냐는 소프트웨어 개발 조직의 리더가 되느냐, 아니면 혹독한 유지보수 코드를 모두 떠맡는 일꾼이 되느냐를 가르는 차이가 되는 경우가 많다.

다음과 같이 글 쓰기 작업을 하나씩 분해해보면 글을 통한 소통, 그리고 설득 과정이 한층 원활해질 것이다.



목적

글을 쓰는 첫 단계는, 기술적이든 또는 다른 경우이든, 목적(purpose)을 생각하는 것이다. 개발자라면 ‘이 소프트웨어가 하는 일과 그 이유를 설명하는’ 것이 보통이다. 때로는 ‘자신(개발자)의 방법이 가장 좋다고 누군가를 설득하는 것’이다. 여기서 대개 개발자가 추진하는 아이디어가 개략적으로 드러난다.

독자
기술 벤더의 기술 구현 관리자인 필자는 상이한 독자(audiences)를 겨냥한 글을 많이 쓴다. 이들은 대개 경영진, 설계자, 개발자, 실무자들이다. 독자는 예컨대 소매기업 실무자 같이 한 단계 더 구체적인 경우가 많다. 독자가 더 구체적일수록 이들에게 더 많은 말을 할 수 있으며, 더욱 효과적인 글이 가능해진다. 대다수의 개발자에게 표적 독자는 다른 개발자, 경영자, 실무자일 것이다.

디테일
디테일 수준은 목적 및 독자를 기준으로 한다. 목적과 독자에 따라 해당 글쓰기의 디테일이 크게 달라진다. 예컨대 필자가 인포월드에 머신러닝 클러스터링에 관해 기고할 때 이는 젊은 개발자나 매니저를 대상으로 했다. 그래서 알고리즘을 깊이 있게 다루지 않았다. 그러나 신예 수학자와 데이터 과학자를 대상으로 했다면 달라졌을 것이다.

개론적 수준의 글에서 구성(configuration)을 상세히 다룬다면 그것은 실수일 것이다. 반면 참고자료나 사용설명서를 쓴다면 구성을 명확히 해야 할 뿐 아니라 이들을 중심으로 문서를 구조화해야 한다.

전술 및 과정(Tactics and process)
목적, 독자, 디테일은 글쓰기의 가장 중요한 부분이지만, 생각을 정리하고 체계화하는 것이 결정적이다. 대다수 사람들은 학교에서 5문단 에세이 형식을 배웠다. 즉 서론, 3개의 지원 문단(본론), 그리고 결론이다.

대다수 전문적 집필에서 5 문단 형식을 따르지는 않을 것이지만, 양질의 작문을 보면 대개가 ‘글을 읽어야 하는 이유, 내용 소개, 가장 중요한 팩트와 이를 지지하는 상세 설명, 그리고 최종적으로 결론’이라는 기본적 구조를 갖는다.

이를 달성하는 데에는 2가지 방법이 있다. 하나는 일단 쓰고 나중에 편집하는 것이고, 다른 하나는 개요를 꼼꼼히 잡은 후 디테일을 채우는 것이다. 필자는 두 방법을 모두 사용하는데, 어떨 때는 하나만, 어떨 때는 두 방법을 섞어 사용한다. 때에 따라 말하려는 내용의 개요를 먼저 쓰기도 한다. 때에 따라 일단 쓰고 이후에 편집을 하기도 한다. 또 다른 경우에는, 일단 각 문단의 상부를 쓰고, 돌아가서 세부를 추가하기도 한다.

방식에 관계 없이, 이후 편집은 (다른 사람이 글을 편집 해준다 하더라도) 가장 중요한 부분이다. 마크 트웨인의 말처럼 “해야 할 일은 그냥 잘못된 단어들을 추려내는 것이다.” 다행히, 오늘 날에는 그저 백스페이스만 눌러도 이 작업 상당 부분을 진행할 수 있다.

내가 함께 일해온 사람들 가운데 일부는 아직도 자신의 생각을 간략히 정리하거나, 또는 단지 글을 쓰기 시작하는데 현실적으로 문제가 있다. 내가 이들을 위해 이용한 방법은 글을 쓰는 대신 그냥 말을 하도록 하는 것이었다. 글자 그대로, 그냥 설명하고, 녹음하고, 재생해서 타이핑하는 것이다. 시간이 더 걸리지만, 말은 이들의 가장 숙련된 소통 형식인 경우가 많다.

밈과 언어(Memes and prose)
최종적으로, 무언가를 표현하는 방식이다. 요점이 강조되었는가? 정연한가? 메시지를 표현하는 가장 명백한 방식은 무엇인가? 이는 소셜 미디어나 뉴스에서 언제나 볼 수 있다.

만약 필자가 ‘안정적 천재(stable genius)’를 언급한다면, 뉴스를 읽거나 보고, 또는 소셜 미디어를 하는 이들 다수는 즉시 누군가(도널드 트럼프)를 연상할 것이다(이를 밈(meme)이라고 한다). 어떤 개념을 설명한다면 이를 설명하는 가장 점착적인 방법(stickiest way)은 무엇인가?

개발자들은 흔히 길게 늘어뜨리는 경향이 있다. 이를 피하라. 일반적으로 밈, 격언, 강력한 말은 짧은 문장들로 이뤄진다. 경험으로 볼 때, 음절이 가장 짧은 단어를 사용하고, 의미를 전달할 수 있는 최소의 단어 수를 사용하는 것이 좋다. 그렇다고 암호적이거나 부자연스러워서는 안 된다.

연습
서툰 작문 기술이 경력에 지장을 줄 정도라면, ‘연습하면 완벽해진다’(practice makes perfect)라는 말을 기억하라. 블로그 운영을 고려하라(트위터 대신). 가족에게 장문의 이메일을 보내라(간단한 문자 메시지 대신). 코드가 어떻게 작용하는 지에 관한 설명서를 작성해보라. 설명서를 너무 많이 써서 해고된 개발자는 없다(읽는 사람이 아무도 없을지라도).

글 쓰는 것을 좋아하는 사람이 그렇게 많지는 않을 것이다. 그러나 글을 효과적으로 쓰는 개발자는 단순히 코딩만 하는 개발자보다 더 빨리 발전한다. 주로 이는 자신의 설명에만 몰입하지 말고 목적과 독자를 염두에 두는 것을 배우고 연습하는 문제이다. 개요를 잡고, 글을 쓰고, 이후 편집하든, 또는 말을 하고 이를 필사하든, 자신에게 가장 잘 맞는 방법을 시도하라. 여러 문장 구조 및 문구들을 실험하고, 가장 ‘점착적인’ 것을 결정하라. 무엇보다도, 잘 될 때까지 이를 계속하라.

* Andrew C. Oliver는 기업 검색 솔루션 기업 루시드웍스의 기술 구현 관리자다. ciokr@idg.co.kr 



2018.06.18

블로그 | IT 개발자를 위한 글쓰기 가이드

Andrew C. Oliver | InfoWorld
개발자가 코드만 잘 써야 하는 것은 아니다. 글을 잘 쓰는 개발자는 커리어 경로에 있어 월등히 유리한 입지를 확보하게 된다.

필자가 다른 개발자와 함께 일을 하거나 이들을 멘토링할 때 느끼는 점은 글 쓰는 기술이 취약한 사람이 많다는 것이다. 이는 ‘글이 조잡하다거나’ 또는 제2언어를 쓸 때처럼 문법이 틀렸다거나 하는 차원을 넘어선다. 문제는 일정한 의도에 따라 생각을 체계화하여 독자에게 전달하지 못한다는 것이다. 누구나 한번쯤은 겪는 문제이긴 하다.

기술 계통 사람에게 완벽한 문법이나 문장을 기대하는 이는 드물다. 그러나 사람들이 이해할 수 있는 방식으로 사실을 명확히 전달할 수 있을 것이라는 보편적 기대치는 존재한다. 이러한 기대에 부응할 수 있느냐 없느냐는 소프트웨어 개발 조직의 리더가 되느냐, 아니면 혹독한 유지보수 코드를 모두 떠맡는 일꾼이 되느냐를 가르는 차이가 되는 경우가 많다.

다음과 같이 글 쓰기 작업을 하나씩 분해해보면 글을 통한 소통, 그리고 설득 과정이 한층 원활해질 것이다.



목적

글을 쓰는 첫 단계는, 기술적이든 또는 다른 경우이든, 목적(purpose)을 생각하는 것이다. 개발자라면 ‘이 소프트웨어가 하는 일과 그 이유를 설명하는’ 것이 보통이다. 때로는 ‘자신(개발자)의 방법이 가장 좋다고 누군가를 설득하는 것’이다. 여기서 대개 개발자가 추진하는 아이디어가 개략적으로 드러난다.

독자
기술 벤더의 기술 구현 관리자인 필자는 상이한 독자(audiences)를 겨냥한 글을 많이 쓴다. 이들은 대개 경영진, 설계자, 개발자, 실무자들이다. 독자는 예컨대 소매기업 실무자 같이 한 단계 더 구체적인 경우가 많다. 독자가 더 구체적일수록 이들에게 더 많은 말을 할 수 있으며, 더욱 효과적인 글이 가능해진다. 대다수의 개발자에게 표적 독자는 다른 개발자, 경영자, 실무자일 것이다.

디테일
디테일 수준은 목적 및 독자를 기준으로 한다. 목적과 독자에 따라 해당 글쓰기의 디테일이 크게 달라진다. 예컨대 필자가 인포월드에 머신러닝 클러스터링에 관해 기고할 때 이는 젊은 개발자나 매니저를 대상으로 했다. 그래서 알고리즘을 깊이 있게 다루지 않았다. 그러나 신예 수학자와 데이터 과학자를 대상으로 했다면 달라졌을 것이다.

개론적 수준의 글에서 구성(configuration)을 상세히 다룬다면 그것은 실수일 것이다. 반면 참고자료나 사용설명서를 쓴다면 구성을 명확히 해야 할 뿐 아니라 이들을 중심으로 문서를 구조화해야 한다.

전술 및 과정(Tactics and process)
목적, 독자, 디테일은 글쓰기의 가장 중요한 부분이지만, 생각을 정리하고 체계화하는 것이 결정적이다. 대다수 사람들은 학교에서 5문단 에세이 형식을 배웠다. 즉 서론, 3개의 지원 문단(본론), 그리고 결론이다.

대다수 전문적 집필에서 5 문단 형식을 따르지는 않을 것이지만, 양질의 작문을 보면 대개가 ‘글을 읽어야 하는 이유, 내용 소개, 가장 중요한 팩트와 이를 지지하는 상세 설명, 그리고 최종적으로 결론’이라는 기본적 구조를 갖는다.

이를 달성하는 데에는 2가지 방법이 있다. 하나는 일단 쓰고 나중에 편집하는 것이고, 다른 하나는 개요를 꼼꼼히 잡은 후 디테일을 채우는 것이다. 필자는 두 방법을 모두 사용하는데, 어떨 때는 하나만, 어떨 때는 두 방법을 섞어 사용한다. 때에 따라 말하려는 내용의 개요를 먼저 쓰기도 한다. 때에 따라 일단 쓰고 이후에 편집을 하기도 한다. 또 다른 경우에는, 일단 각 문단의 상부를 쓰고, 돌아가서 세부를 추가하기도 한다.

방식에 관계 없이, 이후 편집은 (다른 사람이 글을 편집 해준다 하더라도) 가장 중요한 부분이다. 마크 트웨인의 말처럼 “해야 할 일은 그냥 잘못된 단어들을 추려내는 것이다.” 다행히, 오늘 날에는 그저 백스페이스만 눌러도 이 작업 상당 부분을 진행할 수 있다.

내가 함께 일해온 사람들 가운데 일부는 아직도 자신의 생각을 간략히 정리하거나, 또는 단지 글을 쓰기 시작하는데 현실적으로 문제가 있다. 내가 이들을 위해 이용한 방법은 글을 쓰는 대신 그냥 말을 하도록 하는 것이었다. 글자 그대로, 그냥 설명하고, 녹음하고, 재생해서 타이핑하는 것이다. 시간이 더 걸리지만, 말은 이들의 가장 숙련된 소통 형식인 경우가 많다.

밈과 언어(Memes and prose)
최종적으로, 무언가를 표현하는 방식이다. 요점이 강조되었는가? 정연한가? 메시지를 표현하는 가장 명백한 방식은 무엇인가? 이는 소셜 미디어나 뉴스에서 언제나 볼 수 있다.

만약 필자가 ‘안정적 천재(stable genius)’를 언급한다면, 뉴스를 읽거나 보고, 또는 소셜 미디어를 하는 이들 다수는 즉시 누군가(도널드 트럼프)를 연상할 것이다(이를 밈(meme)이라고 한다). 어떤 개념을 설명한다면 이를 설명하는 가장 점착적인 방법(stickiest way)은 무엇인가?

개발자들은 흔히 길게 늘어뜨리는 경향이 있다. 이를 피하라. 일반적으로 밈, 격언, 강력한 말은 짧은 문장들로 이뤄진다. 경험으로 볼 때, 음절이 가장 짧은 단어를 사용하고, 의미를 전달할 수 있는 최소의 단어 수를 사용하는 것이 좋다. 그렇다고 암호적이거나 부자연스러워서는 안 된다.

연습
서툰 작문 기술이 경력에 지장을 줄 정도라면, ‘연습하면 완벽해진다’(practice makes perfect)라는 말을 기억하라. 블로그 운영을 고려하라(트위터 대신). 가족에게 장문의 이메일을 보내라(간단한 문자 메시지 대신). 코드가 어떻게 작용하는 지에 관한 설명서를 작성해보라. 설명서를 너무 많이 써서 해고된 개발자는 없다(읽는 사람이 아무도 없을지라도).

글 쓰는 것을 좋아하는 사람이 그렇게 많지는 않을 것이다. 그러나 글을 효과적으로 쓰는 개발자는 단순히 코딩만 하는 개발자보다 더 빨리 발전한다. 주로 이는 자신의 설명에만 몰입하지 말고 목적과 독자를 염두에 두는 것을 배우고 연습하는 문제이다. 개요를 잡고, 글을 쓰고, 이후 편집하든, 또는 말을 하고 이를 필사하든, 자신에게 가장 잘 맞는 방법을 시도하라. 여러 문장 구조 및 문구들을 실험하고, 가장 ‘점착적인’ 것을 결정하라. 무엇보다도, 잘 될 때까지 이를 계속하라.

* Andrew C. Oliver는 기업 검색 솔루션 기업 루시드웍스의 기술 구현 관리자다. ciokr@idg.co.kr 

X