새로운 시리즈를 만들어보려고 한다.
이름은 읽어보았다, 책 제목 의 형식으로 정했고 말 그대로 책을 읽고 내가 느꼈던 감정이나 감상에 대한 것을 적어보려고 한다.
서론
서론이니까 정말 하고싶은 말 다하고 본론으로 넘어가겠다(?)
취업을 하고 고민에 빠졌다.
출근까지 남은 시간은 일주일.
일주일동안 공부하면 더 도움이 될까?
언어나 CS에 대한 공부를 해야하는걸까?
라는 질문을 계속 나에게 던져봤는데, 좁은 범위를 공부하는 것보다 아예 더 큰 방법론쪽에서 공부를 하는게 도움이 될 것 같았다.
그래봐야 고작 일주일이긴한데..뭐 아무튼
그럼 어떤 방법론을 공부해야하는걸까? 라는 고민에서 글쓰기에 대한 공부를 한번 해보자. 라는 생각이 들었다.
왜냐하면 인간이라는 종족이 이렇게 만물의 영장이 될 수 있던 것에는 언어라는 것이 존재했고,
기록이라는 것과 시너지가 발생하였기에 가능했다고 생각하고 있기 때문이다.
그리고 회사업무를 하다보면 수많은 문서를 주고받고 아래에서 적힐 내용이지만
코드를 짠다는 것은, 글을 쓰는 것과도 거의 같다고 보고 있는 편이다.
흔히 말하는 코드의 가독성을 시작으로 개발자의 글쓰기는 일반적인 글쓰기와 다른가? 라는 관점에서 책을 찾다가 아래 책을 추천받았다.
나는 지금까지 전문적으로 글쓰기에 대한 교육을 받지도, 공부를 해본 적도 없다.
그냥 내가 읽어보고 눈에 안들어오는 것 같다 싶으면 수정을 거듭하면서 나만의 글쓰기에 형식이 만들어졌다.
나만의 글쓰기는 내가 가지고 있는 지식과 정보를 총망라하여 구성에 맞게 설명하는 것에 강점이 있다.
하지만 코드를 작성하고 주석을 다는 것은 또 다르더라. 그래서 계속 궁금했다.
그리고 책을 받은 날 다 읽어버렸다.
개발자의 글쓰기(코드 작성법)은 도대체 어떻게 하면 좋은 것인가?
그런 질문에 대답을 해주는 책이라고 생각해서 주문을 했는데 엄밀하게 따지면 코드 작성법을 깊게 설명하는 책은 아니다.
개발자라는 직함을 가지고, 다른 직함을 가진 사람과 대화를 할 때 도움을 받을 수 있는 책이라고 생각한다.
그렇기에 내가 작성하는 내용 또한 코드의 작성법이 아닌 글쓰기 그 자체에 초점이 맞춰져 있다.
해당 서적을 추천하고 싶은 사람은 아래와 같다.
- 한줄 요약하면 팀리더, CTO
- 소프트웨어 엔지니어가 아닌 직함과 서류로 업무를 보는 사람
- 개발외주를 받고자하는 사람
- 사용자에게 보여지는 패치노트를 작성하는 사람
- 사용자와 대화를 하는 사람
이라면 한번쯤은 읽어보는게 좋지 않을까, 라고 생각하고 있다.
말 한마디로 천냥 빚을 갚는다는 이야기가 있는데
반대로 말 한마디로 천냥 빚이 생길 수 있다. 그런 천냥 빚을 만들고 싶다 않다면 한번 읽어봐라(.....)
국어가 진짜 조사 하나로 정말 큰 차이를 줄 수 있기에, 대중 앞에서 이야기하는 사람은 언제나 조심해야한다.
그런 부분에 대해서도 언급이 있어서 나는 재밌게 읽었다.
개발? 비개발?
많은 회사에서 개발직군, 비개발직군 이렇게 두개를 분류하는 경우가 많다.
과거에는 개발자가 아닌 프로그래머라는 이름으로 불리던 직업이었는데, 바뀐 것은 왜 그럴까 라는 생각을 하면서
개발자 자체에 대하여 사전적 의미를 찾아봤다.
개발의 사전적 의미를 찾아보면
- 지식이나 재능 따위를 발달하게 함.
- 새로운 물건을 만들거나 새로운 생각을 내어놓음
라고 나오는 것을 볼 수 있다. (네이버 국어사전 발췌)
그렇다면 개발자는
- 지식이나 재능을 발달하게 하는 사람
- 새로운 물건이나 생각을 내놓는 사람
이라는 것인데, 왜 굳이 코드를 짜는 사람만 개발자라고 부르는 것일까?
개발자가 아닌, 소프트웨어 엔지니어라는 직함이 정확하며 개발자의 범위는 매우 넓다고 생각하고 있다.
그래서 나는 이렇게 생각하고 있다.
- 소프트웨어 엔지니어는
코드 - 기획자는
문서 - 디자이너는
그림
각자 담당하고 있는 매개체를 통하여 문제를 해결하는 개발자라고 말이다.
개발자는 글쓰는 사람이다.
어떻게보면 끼워맞추기라고 생각할 수 있겠지만, 나는 개발자는 글쓰는 사람이라고 생각한다.
소설가에 비유하는 경우도 많은데 나는 조금 더 큰 범위에서 바라봤다.
프로그래밍 언어(programming language)는 컴퓨터 시스템을 구동시키는 소프트웨어를 작성하기 위한 형식언어이다. 고급 언어일수록 사람이 사용하는 언어에 가깝다.
위키백과에 적혀있는 프로그래밍 언어의 설명이다.
프로그래밍 언어란 컴퓨터에게 무언가를 시키기 위해 생겨난 것이다.
초창기에는 기계어, 어셈블리어라는 것으로 코딩을 했는데 왜 굳이 고급 언어가 발생했을까? 에 대한 의문을 던져봤다.
내가 생각하는 정답은, 결국은 언어이기 때문이다.
언어라는 것은 시간이 지날수록 사용자에 의하여 변화하고 탄생한다.
아래는 적힌 이야기는 훈민정음의 창제 이유다.
우리나라의 말소리는 중국과 달라 그 한자와는 서로 잘 통하지 아니하므로,
어리석은 백성이 말하고자 할 때가 있어도 마침내 제 뜻을 잘 표현하지 못하는 사람이 많은지라,
내 이를 딱하게 여기어 새로 스물여덟 글자를 만드노니, 사람마다 하여금 쉬이 익혀서 날마다 쓰기 편하게 하고자 할 따름이니라.
말하는 것이 서로 통하지 않아서, 자신을 표현하기 힘들기에 만들었다.
단순히 기능적 발전을 위한 것이 아니라, 조금 더 원활한 소통을 위해 고급언어가 생겨졌다고 나는 생각한다.
코드를 작성하는 과정에 있어서 아래와 같은 일들이 있다.
- 흔히 함수, 메소드, 변수 상수 이름을 지을 때 의미를 부여해서 작성하세요.
- 혼자만 보는 코드가 아니니까, 가독성에 주의하면서 짜세요.
- 작성된 코드에 대한 평가와 수정도 이루어진다.
이러한 모든 부분은 글쓰기에 똑같이 존재한다.
어떤 글이냐에 따라 성격이 많이 달라지긴 하면서도
글이라는 것은 대부분 누군가에게 보여주는 것이기에 비슷하다.
- 읽는 사람을 생각하며 내가 이끌어내고자 하는 의미를 생각할 수 있도록 고민한다.
- 한번 작성한 것으로 끝나는 것이 아니라 끊임없이 수정을 거친다.
여기서의 공통점은 내가 작성한 것에 대하여 타인이 이해하기 쉽도록 노력을 한다. 라는 것이다.
이렇게 유사점이 많기에, 나는 개발자는 글쓰는 사람이라고 보고 있다.
하지만 글쓰는 것은 정말 어렵다.
왜냐하면 정규 교육과정에 글을 쓰는 방법과 중요성에 대하여 제대로 가르치지 않기 때문이다.
쓰지 않더라도, 많이 읽어본 사람이라면 어떻게 쓰는 것이 좋다. 라는 감각이 존재하지만
디지털 세상에 가까워진 지금의 세상에서 글을 읽는 사람보다 영상을 보는 사람이 많아지고 있는 것이 현실이다.
그렇기 때문에 많은 사람들이 글을 쓰는 것에 두려움이 있어서 쓰기를 꺼리고
개발자같은 경우에는 가독성이 좋은 코드에 대한 고민을 하지 않는 것이라고 감히 생각하고 있다.
그래서 결론은 무엇이냐, 이 책은 글이라는 것은 어떻게 쓰는 것이 좋은지 알려주는 책이라는 것이다.
본론
어떤 방식으로 책에 대한 독후감(?)을 써보는게 좋을지 많은 고민을 했다.
- 책에 대한 내용을 가지고 요약해서 필요한 것만 보여주는 것.
- 책을 보고나서 내가 생각했던 이야기를 풀어놓는 것.
이렇게 두 가지로 책을 읽은 후기를 남길 수 있을 것이라 생각하는데 나같은 경우에는 후자에 가깝게 작성을 하려고 한다.
왜냐하면 책이라는 것은 사람마다 읽어서 얻는 것이 다르기에 전자의 방식은 옳지 못하다고 생각한다.
그러니 흥미가 생긴다면 직접 사서 읽어보는 것을 추천한다.
왜 글을 씁니까?
글은 도대체 왜 쓸까?
복잡하게 생각할 필요 없다, 말로 하는게 너무 어려우니까.
인간의 기억은 완벽하지 않고, 인간의 집중력은 그렇게 길지 않다.
그래서 인간은 중요한 것이 있다면 글을 적어서 전달하거나 보관했다.
반대로 생각하면 글을 적어서 줬는데, 이해가 안된다고 이야기를 듣는다면 그냥 말로 전하는 편이 좋다(....)
무엇을 이야기하고 싶습니까?
글을 쓸 때, 제일 먼저 고려해야하는 사항은 뭘까?
그것은 바로 이 글로 인해서 얻고자 하는 목적이다.
글의 카테고리는 매우 많은데, 각각 글마다 쓰는 방법이 다르기 때문이다.
그리고 글마다 독자의 수준이 천차만별이다.
글을 쓰는 것이 어려운 이유다.
하지만, 반대로 이것들만 정확하게 알고 있다면 난이도가 확연하게 줄어든다.
가독성이 최우선이다.
글을 쓸 때 제일 중요시 해야하는 것은 바로 가독성이다.
왜?
글을 읽는다는 것은 생각보다 심적 소모가 큰 행위에 속한다.
괜히 세줄요약 필수라는 말이 있는게 아니다(....)
이러한 가독성을 올리기 제일 좋은 방법은 최대한 짧게 쓰는 것이다.
글 매체에 익숙하지 않은 사람들은 스크롤의 길이를 보고 도망간다. 진짜
하지만 내용이 많은 것을 강제로 줄여버린다면, 글로 전하고자 싶었던 의미를 주지 못할 가능성이 높다.
그리고 글을 엄청 많이 써본 사람이 아니라면 내용을 압축해서 전달하는게 정말 어렵다. (내 글이 길어지는 이유기도 하다..)
그래서 필요한 것이 바로 여러가지 옵션(?)이다.
바로 위에 적혀있는 내 글을 기준으로 설명을 해보겠다.
글에 여러가지 옵션을 사용하는 이유.
단순하게 이 사진 속의 글에서 내가 가독성을 위해서 사용한 요소가 무엇일까?
- 글씨의 크기
- 글씨의 굵기
- 글씨의 색상
- 배경색 넣기
4가지 요소를 사용해서 가독성을 높혀줬다.
이런 작업을 하는 이유는 뭘까?
- 글(말)이라는 것은 핵심을 전하려면 선행되어야하는 것이 존재한다.
- 어쩔 수 없이 글이 길어지다보면 전하려고 하는 것이 무엇인지 까먹는다.
즉 이런 작업이 없다면 가독성이 떨어지고, 글 자체의 의미를 이해를 못하게 된다.
그럼 위에 언급한 4가지를 제외하고 또 어떤 방법이 있을까?
- 글머리기호
- 문장 맨 앞에 숫자 쓰기
- 표
- 그림
차례대로 예시를 들어가며 설명을 해보겠다.
글머리기호
글머리 기호가 무엇이냐. 라고 하면 내 글에도 평소에 많이 보이는 이거다.
- 짠
- 짠
- 짠
- 짠
왜 사용하는 것일까?
나열을 할 수 있고 연관성을 표현할 수 있다.
문장 맨 앞에 숫자 쓰기
말 그대로 문장 앞에 숫자를 순서대로 나열하는 것이다.
- 콜라가 마시고 싶다.
- 편의점에서 콜라를 팔고 있다.
- 나가서 사오자.
글머리 기호와는 무슨 차이가 있을까?
그것은 바로 숫자의 유무다.
사람은 자연스럽게 숫자가 있으면 순서가 있다고 판단한다.
- 글씨의 크기
- 글씨의 굵기
- 글씨의 색상
- 배경색 넣기
- 글씨의 크기
- 글씨의 굵기
- 글씨의 색상
- 배경색 넣기
위에는 글머리 기호를 사용한 것은 모두 중요하구나, 라고 생각하지만
아래는 숫자가 1에 가까울수록 중요하구나, 라고 생각하는게 일반적이다.
그래서 흐름이 정말 중요하다면 숫자를 적어넣고, 그것이 아니라면 글머리 기호를 사용하는 것이 좋다.
두 개의 특징을 예시로 알아보자.
글머리기호는 한번만 사용할 수 있지 않고 아래로 파고들 수 있다는 장점이 있다.
- 글씨의 크기
- 크기를 크게 주는 것으로 제일 먼저 눈에 띄게 할 수 있습니다.
- 차이가 너무 크면 가독성을 오히려 해치기에 적당히 조절하는 편이 좋습니다.
- 크기를 크게 주는 것으로 제일 먼저 눈에 띄게 할 수 있습니다.
이런식으로 중요도에 따라서 부가설명이 가능하다.
숫자를 넣는 경우에는 흐름이 정말 중요할 때 쓰면 좋다.
예를 들자면 설명서에서 많이 사용한다.
- 블루투스를 연결하기 위하여 제품의 전원을 먼저 켜주세요.
- 페어링을 위하여 특정 버튼을 10초간 눌러주세요.
- 컴퓨터에서 블루투스 탭을 들어가 해당 제품을 선택해주세요.
3.1 만약 정상적으로 연결이 되지 않는다면 제품을 껐다 켜주세요.
이처럼 순서대로 해야할 때 사용하면 좋고, 문제가 발생한다면 3.1, 3-1 이런식으로 또 다른 방법을 제시해줄 수 있다.
표
표는 비교를 할 때 정말 사용하면 좋은 방식이다.
(제 블로그에서 긁어왔음)
개발자들이 정말 많이 쓸 제안서 같은 것에서 정말 유용하게 사용할 수 있다.
여러가지에 대한 비교를 할 경우 보통 O X 이런식으로 한눈에 알아볼 수 있게 하는 것이 큰 특징이다.
그리고 저 특징을 활용하면, 비교를 할 때 사용하면 확 와닿을 수 있다.
| mac 노트북 | window 노트북 | |
|---|---|---|
| 들고 다닐 수 있는가? | O | O |
| 게임을 할 수 있는가? | X | O |
| 스타벅스에 들어갈 수 있는가? | O | X |
그림(영상,움짤)
엄청 긴 설명을 한장의 사진으로 해결할 수 있는 최고의 방식이다.
순서, 강조도 사진 내부에서 해결을 하는 경우도 있다.
특히 사진을 사용 할 때 좋은 경우는 디자인 시안같은 것이라고 생각한다.
만약 요청을 이렇게 받았다고 가정해보자. 코카콜라 디자인처럼 만들어주세요!
극단적인 예시를 들어서, 코카콜라가 뭔지 모르고 그 세상에는 코카콜라가 없었다고 치자(?)
그럴 때 코카콜라 사진을 찍어서 주는 것으로 글로는 형용할 수 없는 효율을 낼 수 있다.
단어, 조사 하나에도 의미가 있다.
사실 이 주제를 쓰기 위하여 포스팅을 하고 있는 것과 다름없다(....)
그것은 바로 문장 하나하나를 뜯어보는 사람이 존재한다. 라는 것이다.
위에 적었던 것을 예시로 들어보자!
페어링을 위하여 특정 버튼을 10초간 눌러주세요.
만약 문제가 발생하여 10초 이내로 페어링 준비가 되지 않았다면 클레임이 들어온다.
그렇다고 아래처럼 이렇게 쓰는 것은 안된다.
페어링을 위하여 일정 시간동안 눌러주세요.
일정 시간이 도대체 얼만큼인지 가늠을 할 수 없기에 설명서보자마자 바로 욕을 할 것이다.
사람마다 일정 시간이라는 간격이 다르기 때문이다.
그래서 보통 이런식으로 작성한다.
페어링을 위하여 특정 버튼을 10~30초 가량 눌러주세요, 기기에 따라 편차가 존재할 수 있습니다.
왜 이렇게 적는 것일까?
필터링 없이 이야기하면 책임을 회피하기 위해서다.
필터링을 걸어놓는다면 여지를 남겨놓기 위해서. 정도?
그저 10~30초 가량 눌러주세요 라고만 적어놨다면 저 시간보다 오래 걸린다면 또 다시 클레임이 들어온다.
30초 눌러도 안됐는데, 이거 불량품 아니냐고
하지만 기기에 따라 편차가 존재할 수 있습니다. 라는 문장을 넣은 것으로 아, 뽑기 실패했네 같은 생각으로 이어진다.
그걸로 클레임을 걸면 어쩔 수 없는데....
말장난처럼 보이지만, 이런 말을 들어본 적이 분명 있을 것이다.
계약서 작성할 때 유심히 보세요, 글씨가 작고 많다고 슬쩍 불이익을 받을 수 있는 내용을 넣어놨을 수 있어요.
요즘에는 많이 안그런다곤 하던데 과거에는 빈번하게 있었다고 들었다.
그럼 만약 개발자가 작성하는 글 중에서, 어떤 유형에서 주의를 해야할까?
- 위에 직급에게 전달하는 글을 쓸 때
- 비즈니스 관계에 있는 회사에게 전달하는 글을 쓸 때
- 사용자가 보는 글을 쓸 때
- 영상으로 기록이 남는 말을 할 때(말이지만 추가했다.)
주의를 하면서 글을 쓰는 경우가 대부분인데, 고의로 넣는 경우도 존재하긴 한다.
심지어는 악용을 하는 경우도 있고 (어떤 핵과금 게임사의 간담회처럼)
실제로 돈이 오가는 비즈니스 관계에서 사용하는 문서를 작성할 경우 매우 고려를 해서 작성해야한다.
반대로 기술제안서같이 책임을 회피하고 싶은(ㅎㅎ...) 문서를 작성할 때는 고의로 넣기도 한다.
이런 일이 벌어질 수도 있다고 적어놨는데요?
해당 주제가 이 책을 읽으면서 큰 공감을 가졌던 파트고 이것을 위해서라도 한번 쯤은 읽어보는 것이 좋다고 생각했다.
글을 쓸 때 이렇게까지 고려를 많이 해야하는가! 생각할 수 있겠지만, 별 수 없다(....)
그리고 결국 잘 쓰기 위해서는 끊임없이 써보는 것이 답이라서 뛰어난 해결책이 있는 것도 아니다.
마치 코드처럼.
조금 특이한 방식의 독후감을 썼다고 생각한다.
그냥 내가 평소에 글을 쓰던 방식이 실제로 의미가 존재한다! 라는 것에 감명을 받기도 했고
에러메세지, 릴리스 문서, 장애 보고서, 개발 가이드, SI 제안서 등 다양한 주제가 있었지만 정말 기본적인 글쓰기에 관한 주제로 써봤다.
내가 생각한 것처럼 적히지 않아서 엄청 많이 지우고 새로 썼는데, 솔직히 아쉬운 마음이 크다(...)
하지만 시간이 지난 후 다시 책을 읽는다면 또 다른 생각을 할 것이 분명하기에 조금은 내려놓고 가볍게 적어봤다.
끗
nice post!