✍🏻 개발자가 개발만 잘하면 될까? - 나만의 글쓰기 프로세스 이번 주는 어떤 내용으로 글을 쓸까 고민하다가 ‘저의 글쓰기 프로세스’를 다룰까 합니다. 저는 글을 잘 쓰고 싶거든요. 예전

✍🏻 개발자가 개발만 잘하면 될까? - 나만의 글쓰기 프로세스 이번 주는 어떤 내용으로 글을 쓸까 고민하다가 ‘저의 글쓰기 프로세스’를 다룰까 합니다. 저는 글을 잘 쓰고 싶거든요. 예전 라인에서 근무했을 때 시니어 개발자님이 개발자는 개발만 잘하면 되는 게 아니다. 테크니컬 라이팅이라고 하는 글쓰기도 잘해야 한다는 말씀을 해주셨는데 그때부터 관심을 가졌던 것 같아요. 현재 직장에서 근무할 때도 글을 써야 하는 일은 매우 많거든요? 지금 생각나는 일만 하더라도 이 정도가 있네요. - 업무에 대해 커뮤니케이션을 할 때 - 지식을 팀에 공유할 때. - 장애 공지 문서를 쓸 때 - 개발한 것에 대해 문서화를 할 때 앞으로 글 쓸 일이 많기 때문에 저만의 글쓰기 프로세스를 체계화해두는 것이 필요하다고 생각해서 이 글을 쓰는 이유도 있고요 여러분들은 어떻게 쓰는지 궁금하기도 해서 여쭙고 싶어서 쓰는 이유도 있습니다. 일단 제가 쓰는 방식부터 소개할게요. 1️⃣ 주제와 예상 독자를 선정 먼저 어떤 주제로 글을 쓸 지 정합니다. 광범위하고 막연한 주제로 글을 쓰면 다뤄야 하는 내용이 많아져서 명확한 주제를 고르려고 노력하고요. 주제를 먼저 선정하면 글의 분량도 어느 정도 결정 나서 좋아요. 그러면 이걸로 글을 쓸 수 있을 만큼 충분한 분량이 있는지 확인해볼 수 있거든요. 다음으로 이 글을 ‘누가 읽을까?’를 생각해보는데요. 예상 독자가 정해지면 전달할 내용의 깊이가 조절돼서 독자 입장에선 이해하기 쉽고, 작성자 입장에선 필요한 말만 할 수 있어서 좋아요. 예시로 제가 개발한 것에 대해서 팀 위키에 글 쓸 땐 늘 신규 입사자가 읽는다고 생각하고 글을 써요. 2️⃣ 초안을 작성한다 글 쓸 땐 상위 레벨의 추상화 수준을 먼저 설계하고 쓰는데요. 코드 설계하는 거랑 비슷해요. top-down 방식으로 인터페이스를 모두 설계해놓고 구현은 나중에 하는 방식으로 합니다. 추상화 수준을 먼저 설계하는 이유는 자연스러운 글의 흐름을 만들기 위해서예요. 이렇게 추상화 수준을 잡아놓았다면 이제 그냥 글을 씁니다. 여기선 흐름이 이상한 것 같아도, 정확한 내용이 아닌 것 같아도 일단은 씁니다. 이렇게 하는 이유는 마틴 파울러 (Martin Fowler) 가 리팩터링 (Refactoring)에서 말한 두 개의 모자와 이유가 같은데요. “기능 추가 모자와 리팩터링 모자는 동시에 쓸 수 없다. 한 번에 하나씩만 착용할 수 있다.” 글을 쓰는 것과 고치는 작업은 각각 뇌의 다른 영역을 쓰기 때문에 일단은 글을 쓰는 데만 집중합니다. 3️⃣ 검토한다. 초안을 썼으면 검토 작업을 하는데요. 여러 가지 필터 체인을 두고 이 필터들을 다 통과하는지 확인합니다. 모두 통과했다면 게시하고요. 통과하지 못하는 부분이 있다면 통과할 때까지 수정합니다. 첫 번째로 적용하는 필터 체인은 명확성, 간결성, 일관성이 있는지 확인합니다. 명확성은 모호함이 없고 확실하게 내용을 전달하는지 체크하는 걸 말합니다. 주로 맥락에 맞는 단어를 쓰는지, 애매한 표현의 단어를 쓰고 있지는 않은지 확인하는 작업을 해요. 간결성은 표현하는 문장이 간결한지를 따져봅니다. 간결하다는 건 결국 쉽다는 뜻이기도 하거든요. 일관성은 문서 전체에서 말하는 내용이 일관적인지를 따져봅니다. 앞에서 말한 것과 뒤에서 말한 게 다르다면 제가 말한 내용을 독자가 신뢰할 수 없겠죠. 두 번째 필터 체인은 중요한 내용이 먼저 나오는지 확인합니다. 즉 핵심을 가장 먼저 쓸려고 노력합니다. 글은 처음 부분이 가장 많이 읽히고 다 읽히지 않는 경우도 많기 때문에 가장 중요한 내용을 앞에 두려고 합니다. 세 번째 필터 체인은 맞춤법 검사를 합니다. 당연한 것들은 무조건 지키려고 노력하는데요. 이런 사소한 부분에서 실수가 난다면 제 글을 믿기 힘들겠죠? 그래서 마지막에는 꼭 맞춤법 검사를 합니다. 저는 이렇게 글을 씁니다. 여러분들은 어떻게 쓰는지 궁금하네요. 제가 보고 배울 수 있게 많이 알려주세요. 😃