brunch

You can make anything
by writing

C.S.Lewis

by Vintage appMaker Oct 05. 2023

개발자 글쓰기 #1-구조적으로 만들기

생존형 개발자의 생각 #86

"김성(根性)모 화백"을 존경하는 27년차 개발자의 근성(根性)으로 보면


”개발자가
누구나 읽기 쉬운 글을 쓴다?
그러면 근성 개발자가 아니지…”


라는 생각을 할 때가 많다. 이유는 개발자는 하루종일 기계(PC, 핸드폰, 기타 장비등등)가 자신이 설계한 인공지능(로직)으로 행동하도록 논리적 문장을 오류없이 쓰고 고치는 사람이다. 그래서 정의되지 않은 변수로 다양한 분기를 만드는 인간적인 사고의 글은 제어하기 힘들기 때문이다(문장의 오류를 고치다가 괴상한 글이 나온다).

bing: 프롬프트 "기계적 사고방식으로 프로그래밍하는 개발자를 수채화로 그리기"


일러두기: 다음 글은 3꼭지 정도로 완성될 것이다(이 포스팅은 첫번째이다). 개발자 대상으로 “평이한 글(?)”을 작성하는 방법을 정리한 것이다. 이유는 몇 몇 공학계열의 지인들이 일반인을 위한 책을 써야 한다. 그래서 조언하다보니 만나서 알려주는 것보다 summary한 내용을 공유하는 것이 훨씬 효율적이라는 판단되어 정리했다.


그런 점에서
독자층을 고려해
근성 개발자가 읽기 쉽게
글을 만들었다.


개발자도 어쩌면(?) 글을 잘 쓸 수 있다


개발자의 글쓰기는 언제나 힘들다. 독자층이 자신과 같은 전문가 집단이어도 힘들지만 일반인을 대상으로 한 글쓰기는 더욱 더 힘들다. 그러나 달리 생각해보면 개발자의 글쓰기가 더 쉬울 수 있다. “구조”를 만들고 활용할 줄 안다면 쉽게 해결된다. 구조를 설계하고 사용하는 스킬을 연마한다면 그 구조에 글을 채워넣는 것은 생각보다 어렵지 않다. 마치 프로그래밍을 할 때, 함수와 클래스를 설계하고 모듈화해서 사용하는 것과 유사하다. 단지 어설픈 글욕심만 부리지 않으면 된다. 어설픈 글욕심은 “함축된 단어, 자의적 해석,  나만의 가치를  장황하게 설명 ”만 하지 않으면 된다는 말과 같다. 글욕심만 버린다면 “무리없이 읽을 수 있는 글”은 누구나 만들수  있다.


그리고 희망적인 것은 “개발자의 글쓰기는 나를 대상으로 쓰지 않는다”는 점이다. 망치는 글의 대부분나의 욕망과 감정에 집중하며 낭폐를 보는 반면 개발자의 글은 나에 집중하지 않기 때문에 “객관적”인 글이 쉽게 나올 수 있다(코딩하며 자신의 감정을 기록하는 개발자가 있나? 있다면 예외다.). 결론적으로 신뢰도가 높은 글이 될 수 있다.

개발자 글쓰기를 한 페이지로 생각나는 대로 정리했다


문서에서 중요한 것


1996년 대학졸업 후, 직장생활을 한 시기부터 지금까지 “문서화”는 주된 업무 중에 하나였다.  직장경력 90% 이상이  “미들웨어, OS(Operation System),  플랫폼, 플러그인 API”로 불리던 덩치 큰 소프트웨어 솔루션이다보니 “일반 개발자를 위한 교육문서와 예제” 작성은 필수였다.


결론적으로 “프로그래밍 스킬”과 마찬가지로 “문서화 스킬” 역시 중요했다. “애플리케이션 개발자를 위해 솔루션을 개발하는 개발자”였기에 일반 개발자들이 어떻게 반응할 지 예상해가며 문서를 만들었다. 그러다보니 “누가 읽을 것인가?  무엇을 전달할 것인가? 읽는 사람은 어떻게 반응할 것인가?”를 머릿 속에서 시뮬레이션하는 글쓰기 습관을 가지게 되었다.


개발자가 일반 글을 쓴다면


사실, 개발자가 일반적인 글을 쓰는 것은 힘들다. 사용하는 용어부터 사고방식, 심지어 글자(다양한 언어로 코딩 ㅜㅜ)까지 매우 일반적이지 못한 것들로 가득하기 때문이다. 그래서 문장을 만들다보면 어느시점에선 일반인들이 납득하기 힘든 “근성 프로그래밍형 글(함축, 함수형 논리, 데이터기반, 엄격한 룰)”이 만들어질 때가 많다.


이것보다 더 깔끔한 자기소개글은 없다. kotlin 유저라면 말이다. 지금은 Dart에 쩔어살지만 kotlin의 영혼을 잊지않았다.


그러나 코딩이나 글쓰기가 구조적 사고방식으로 만들어진다는 점에서 일맥상통하는 부분이 있다. 그런 점에서  “프로그래밍 하듯 구조화”로 일반 글을 쓰게되면 어렵지 않게 쓸 수 있다. 경험상 더 빨리, 더 많이 찍어내기도 한다. 단지 일반용어로 짧고간단하게 만들면 된다.


개발자가 평이한 글을 쓸 때, 다음과 같이 쓰면 오류없는 결과물로 가까이 갈 수 있다(오류없는 글이 어디있겠는가? 적어질 뿐이겠지..).


읽히기 쉬운 구조를 만들기: ”뻔하지 않은 내용을 뻔하게 보이도록 써야 한다”. “읽어서 이해하는 것이 아니라 읽기 전에 추측하며 파악되게 써야한다”. 이런 것들이 가능하려면 사람들이 “자주 쓰는 문장구조”를 활용해야 한다. 나만의 창작(나만의 알고리즘?)을 하지말고 “익숙한 문단(검증된 코드)”을 활용하라는 것이다. 이것은 프로그래밍과 매우~ 매우~ 유사하다.


뻔한 글쓰기에 필요한 구성요소: (1)누구나 쉽게 예상할 수 있는 키워드(단어), (2)단순한 흐름(1, 2, 3, 4식의 간단명료한 순차적 흐름), (3)흐름에 맞는 결론으로 끝맺음이 중요하다. 프로그래밍을 한마디로 표현하자면 “함수를 만들고 사용하는 과정”이라 할 수 있다. 글도 마찬가지이다. 문장을 만들고, 문장을 활용하여, 결과값(결론)을 만들어내는 과정이다.


“Simple is the Best”로 작성: 뻔한 글쓰기는 Simple하게 써야 한다. 글의 호흡도 짧아야 하며, 문장이 익숙해야 하고 불필요한 단어를 제거하며 최소한만 사용하는 것이 좋다. 그런 점에서 C와 같은 고급언어(20세기에는 C가 고급언어였다)에서 시작된 “짧은 코드로 최소한의 여러개 파일로 모듈화”와 일맥상통한다. (1) 불필요한 단어제거 (2) 필수내용만 짧은 문장으로 설명 만 한다면 읽다가 분노하는 일(도대체 이게 무슨말이야?)은 적어지게 된다.


아웃라인 글쓰기를 시작해라: 개발자에게 개발툴이 제2의 뇌가 되듯이 글쓰기에도 툴(방법)은 생각을 정리해준다. 그런 점에서 개발자 또는 비개발자를 구분할 필요없이 절대적으로 추천하는 방법은 아웃라인 글쓰기이다. 글의 구조를 시각적으로 바로 알 수 있기에 문단의 위치와 추가, 삭제, 수정을  빠르게 판단할 수 있다. 구글에서 아웃라인 글쓰기 프로그램을 검색하면 5~7개 정도의 소프트웨어를 추천받을 수 있다.

아웃라인 글쓰기는 목차 스타일로  "들여쓰기로 글을 쓴다"라로 생각하면 된다.



Next


매거진의 이전글 인수인계의 중요성
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari