글쓰기 익숙하지 않은 개발자들에게 - 1

   타닥타닥, 우리가 일상에서 자주 듣는 소리입니다. 우리 곁에는 언제나 키보드가 있었습니다. 키보드가 없는 일상을 상상할 수 없을 정도로 너무나 익숙해져 있습니다. 프로그래밍을 처음 접할 때도 키보드 앞에 서있었고, 오늘도 내일도 무언가를 작성하기 위해 키보드를 두드리겠죠. 이 글은 그런 당신을 위한 글입니다.

   개발자들이 프로젝트를 진행할 때 빼놓을 수 없는게 바로 문서입니다. 기획자와 미팅하기 전에 기획서를 살펴봐야 하고, 이를 분석하며 작업 내역을 정리해야 합니다. 어떤 사람은 머릿속에 남기고, 손으로 직접 쓰기도 하며 타이핑하여 기록하죠. 미팅 후에는 업무 분업 구조(work-breakdown structure, WBS)를 작성하고 공유합니다. 그 후에야 본격적인 타이핑을 시작합니다. 코드를 작성하고, 프로젝트 진행 상황에 따라 사내 WIKI에 공유해야 될 내용을 적습니다. 이처럼 우리는 수많은 문서 속에 지내고 있습니다.

   그럼에도 불구하고 많은 개발자들이 말합니다. “저는 문서가 싫습니다. 글을 못 쓰는데, 문서 쓰는걸 좋아할리 없잖아요.” 정작 그런 말을 하는 개발자 본인도 기획서 없이 프로젝트를 진행하라고 맡기면 화낼게 분명합니다. 이미 우리는 협업을 위해 문서는 꼭 필요하다는 사실을 알고 있습니다. 그렇기에 저는 개발만 하고자 하는 사람들을 배려심 없는 개발자로 여깁니다. 물론 문서를 쓰기 위해 개발하는건 아니지만, 문서 하나 쓰지 않고 개발할 수 없는 노릇입니다. 플로우차트든 정책이든 개발 이슈든 기록을 해야 공유가 되고, 더 나은 방향으로 나아갈 수 있습니다. 주석과 커밋 로그만으로는 한계가 명확합니다. 그 뿐만 아니라 개발자는 이미 글을 잘 쓸 수 있는 환경에 놓여져 있습니다. 마음만 먹으면 당신도 충분히 글을 잘 쓸 수 있습니다. 단지 깨달지 못 하고 있을 뿐이죠. 하나씩 살펴보도록 할까요?

   컴퓨터 언어, 프로그래밍을 위한 개발 도구를 부르는 말입니다. 단순히 개념에 대한 이해를 돕기 위하여 ‘언어’라 부르는게 아닙니다. 프로그래밍은 글과 유사하기에 '언어'라는 단어를 차용하였습니다. 우리가 프로그래밍을 할 때 독자는 정해져 있는데, 바로 컴퓨터와 동료 개발자입니다. 개발자들은 끊임 없이 그들과 소통하기 위해 코드를 작성합니다. 처음부터 완벽한 코드를 짜는 사람은 많지 않습니다. 수차례 고민하며 끊임 없이 고쳐야만 마음에 드는 코드가 나옵니다. 코드를 작성하였다면 끝인가요? 아니죠. 동료 개발자에게 코드리뷰를 받아 오류가 없는지, 더 나은 구조로 만들 수 없었는지 검증 받습니다. 그 후에야 QA를 받을 수 있고, 런칭을 합니다.

   이를 글로 옮겨볼까요? 글을 쓰기 위해서는 주제를 선정하여야 합니다. 주제가 정해지면 플롯 또는 전반적인 구상을 잡습니다. 독자 범위를 정하고 어떤 식으로 이야기를 풀어나갈지 짜임새를 정합니다. 프로그래밍이라면 아키텍처를 그린다고 할 수 있겠죠. 그제서야 초고를 쓸 수 있습니다. 초고를 쓰고나서 수차례, 몇 십 차례 퇴고를 합니다. 태생적으로 잘 쓰는 사람이 아닌 이상에야 한두 번 고쳐서는 괜찮은 글이 나오기 힘듭니다. 퇴고 후에는 첨삭지도를 받기도 하며, 발간 전 교열을 받아 마무리 짓습니다. 똑같지 않나요? 작가와 개발자는 동일한 방식으로 일합니다. 이를 표로 옮기면 다음과 같이 완성됩니다.

 물론 일하는 방식이 같다고 한들 처음부터 글을 잘 쓸 수는 없습니다. 처음 접하는 프로그래밍 언어 또는 새로운 프레임워크, 신규 플랫폼을 접할 때 어떻습니까? 익숙해지기까지 시간이 필요합니다. 글도 마찬가지입니다. 처음에는 익숙하지 않습니다. 누구든지 손쉽게 글을 쓴다면 굳이 테크니컬 라이터가 별도로 존재할 필요가 없겠죠.

   하지만 프로그래밍처럼 글도 정형화 된 패턴이 존재합니다. 나의 의견을 내세우려면 어떤 방식으로 접근해야 하는지, 정보 교류 문서는 어떻게 작성해야 하는지 정해져 있습니다. 물론 그 패턴을 나열한다고 해도 이제 글을 써보기로 마음 먹은 사람들에게 별 도움이 되지 않습니다. 걸음마부터 하나 씩 시작해야 합니다. 무엇을 하든 기초가 튼튼해야 오래갈 수 있습니다. 프로그래밍도 마찬가지고, 글쓰기 또한 마찬가지입니다.

   처음 글을 쓰려고 할 때 가장 고민되는 요소는 바로 주제입니다. 어떤 주제로 써야 하는가, 이야기하고자 하는 내용이 명확하지 않다면 잡기 힘듭니다. 기술이라면 전문지식을 충분히 가지고 있어야 하고, 기술이 아니라면 나의 생각을 명확하게 전달할 수 있어야 합니다. 이를 위해 주제를 확실하게 다잡을 수 있는 키워드를 정하세요. 저는 글을 끄적일 때 음악을 통해 키워드를 찾고, 사람들과 대화를 하다가 떠오른 키워드로 글을 쓰며 연습합니다.

   키워드부터 시작하라는 이유는 간단합니다. 처음부터 복잡한 주제를 유려하게 풀어낼 수 없습니다. 하지만 키워드가 정해져 있다면 이야기는 달라지죠. 키워드는 글로 표현하고자 하는 핵심 포인트이기에 글 전반을 관통할 수밖에 없습니다. 자연스레 쓰다보면 주제가 정해집니다. 짧은 글도 괜찮습니다. 처음부터 길게 쓸 수는 없는 노릇이죠. 키워드를 통해 글 쓰는 방법을 익히는겁니다. 이렇게 글을 쓰다보면 점차 주제를 어떻게 활용해야 하는지 눈을 뜰 것입니다.

   주제가 아닌 키워드부터 시작하라는 말은 처음부터 목차에 연연할 필요가 없다는 이야기입니다. 글에 익숙한 사람이라면 주제와 목차를 활용할 줄 압니다. 하지만 초심자는 그렇지 않습니다. 우리가 개발을 처음 배우던 시기를 생각해보세요. 처음부터 상황에 적합한 디자인 패턴을 쓰고 아키텍처를 그렸나요? 아닙니다. 개발을 하다보니 디자인 패턴과 아키텍처의 중요성을 느꼈습니다. 필요에 의해 공부를 하였고 그 때서야 활용하기 시작하였습니다. 처음부터 목차에 연연하지 마세요. 순서는 퇴고하면서 맞추어도 늦지 않습니다. 당장은 글을 많이 써보고 익숙해지는게 중요합니다. 출퇴근 할 때 틈틈이 쓰기만 해도 충분합니다. 지금 보고 있는 이 글도 대부분 지하철 안에서 썼습니다.

   이제부터 더 실용적인 이야기를 하겠습니다. 사실 글을 쓸 때 몇 가지만 주의해도 ‘글을 쓸 줄 아는 사람’으로 보입니다. 맞춤법, 띄어쓰기, 오타 수정 같은 당연한건 다들 지키시겠죠. 이를 전제로 아래 내용을 지키고자 한다면 수려한 글을 쓸 수 있게 됩니다. 생각보다 어렵지 않습니다. 우선 단어에 대해 살펴보도록 합시다. 단어는 글을 이루는 문장을 만들기 위해 빠질 수 없는 요소입니다. 동일한 의미를 가진 문장일지라도 어떤 단어를 쓰냐에 따라 분위기가 달라집니다. 단어는 그만큼 중요합니다.

   사전만 찾아보면 쉽게 지킬 수 있는 첫 번째는 바로 유의어 사용입니다. 한 문장에 동일한 어휘를 반복해서 사용하는건 depth가 깊은 코드와 비슷한 느낌을 받습니다. 간혹 강조하기 위해서 동일한 단어를 한 문장에 여러 번 쓰기도 하지만, 일반적으로 대체 가능한 유의어를 활용하면 더 매끄럽게 읽을 수 있습니다. 또한 상황에 맞는 유의어를 활용하면 다채로운 표현을 만들어낼 수도 있습니다. 글을 쓰려고 하는 사람들에게 다양한 책을 읽으라는 이유 중 하나는 바로 수많은 어휘를 스스로 체득하기 위함입니다.

나는 오늘도 글을 쓴다.
저는 오늘도 글을 씁니다.
필자는 오늘도 글을 끄적입니다.

   두 번째, 문장에 어울리는 단어를 활용하세요. 문장은 평어체인데, 한자어를 지나칠 정도로 남용한다면 어떨까요? 단어와 문장 사이에 괴리감이 생깁니다. 예로부터 한자어는 존칭으로 공적이거나 사무적인 자리에서 사용하였습니다. 또한 일상에서 쓰는 어휘와 차이가 많습니다. 독자를 어떻게 선정하느냐에 따라 문장 뿐만 아니라 단어도 바꾸어야 합니다. 무작정 한자어를 남용한다고 글을 잘 쓰는게 아닙니다. 한자어 뿐만 아닙니다. 독자를 고려하여 주제에 어울리는 단어를 찾도록 고민해야 합니다. 이 또한 사전만 있어도 충분히 연습할 수 있습니다.

// bad case
저작에 익숙하지 않은 개발자를 위해 작성하고 있어요.
// good case
글에 익숙하지 않은 개발자를 위해 작성하고 있어요.

   다음은 문장을 살펴볼까요? 처음 글을 쓰고자 하는 사람들이 문장을 쓸 때 빈번하게 실수하는 부분이 있습니다. 그 세 번째는 바로 ‘쪼갤 수 있을 만큼 문장을 쪼개라.’입니다. 잠깐 프로그래밍으로 돌아가 볼까요? 우리가 함수를 작성할 때 지켜야 할 원칙이 있습니다. 함수 하나에 다양한 로직을 섞지 않지 않아야 한다는거죠. 문장도 비슷합니다. 프로그래밍과 달리 한 문장이 두세 가지 이야기를 해도 상관 없지만, 글에 익숙하지 않은 사람이 그렇게 쓸 경우 정체를 알 수 없는 괴이한 문장이 완성 되기 일수입니다. 저도 신경쓰지 않으면 실수할 정도로 주의를 요구하는 부분이니 처음에는 최대한 문장을 쪼개어 쓰기를 권장합니다.

// bad case
지인을 가르치기 위해 자료를 만들어야 하는데, 요즘 다른 분야에 관심이 많아 공부하고 있다.
// good case
지인을 가르치기 위해 자료를 만들어야 한다. 하지만 요즘 다른 분야에 관심이 많아 시간이 부족하다.
지인을 가르치기 위해 자료를 만들어야 하는데, 요즘 다른 분야에 관심이 많아 시간이 부족하다.

   네 번째는 어미에 대한 이야기입니다. 동일한 종결어미, 즉 문장 끝맺음을 계속해서 반복한다면 기계적인 느낌을 지울 수 없습니다. 뉴스를 들으면 가끔씩 기상 캐스터에게 기계적인 느낌을 받을 때가 있는데, 그럴 때는 동일한 억양으로 계속 ‘-습니다.’ 로 문장을 마무리 짓고 있었습니다. 열 명 중 세 명 이상에게 느끼는 감정입니다. 비단 말만 그럴까요? 글도 마찬가지입니다. 이와 별개로 한 문장에서 중복 어미를 여러 번 사용하면 흐름이 끊기는 느낌을 받습니다. 이 부분만 주의해도 꽤 많은 차이를 만들어 냅니다. 기억하세요. 중복 어미는 글을 재미없게 만들고 흐름을 끊어버립니다. 글은 기계가 아니라 사람을 위해 쓰는겁니다.

// bad case
나는 친구와 밥을 먹고 이야기를 하고 웃었다.
// good case
나는 친구와 밥을 먹으며 이야기를 하다 웃었다.

   이 외에도 하고 싶은 이야기는 많지만, 너무 길어져 다음 글을 통해 알려드리겠습니다. 대학생 시절 국문학과 교수님께 글을 배웠냐는 소리를 들었지만, 저는 정식으로 글을 배우지 않았습니다. 개발과 마찬가지로 체득하였을 뿐이죠. 그럼에도 불구하고 일반적인 사람들보다 글을 잘 쓴다고 자부합니다. 단지 체득한 기술일 뿐인데 말이죠. 여러분도 조금만 글에 관심을 가져도 충분히 잘 쓸 수 있습니다. 글은 프로그래밍과 다르지 않습니다. 아니, 프로그래밍도 글의 한 종류일 뿐입니다. 다음 글까지 이 사실을 잊지 마세요.