나만 없어 진짜 사람들 블로그 다 있고 나만 없어

이 글은 개발자의 글쓰기 책의 "기술블로그 쉽게 쓰고 운영하기" 챕터의 내용을 요약한 글입니다.

들어가며

해야지 해야지하면서 안하던 것, 나한텐 그게 개발 블로그를 시작하는 것이다.

사실 깃헙블로그 만들기를 시도했었지만, 뭔가 아는 것도 없고 제대로 완성된 글을 올려야할 것 같은 느낌에 자가검열하다보니 결국 글을 올리지 못한 적도 있다. 다음에 뭘 좀 알게되면 재도전해야지! 했지만 여전히.. 뭘 좀 아는 것 따윈 없는 것 같다ㅎㅎ

아니 왜 이렇게 블로그를 시작하기가 어렵지?

이런 의문을 품고 살고 있었는데, "개발자의 글쓰기" 책에서 와닿는 내용이 있어서 요약해보았다.
글이 길다 싶으면 진한 글씨만 슥- 읽어보고 블로그를 시작해보자!

개발자가 기술 블로그를 잘 못 쓰는 이유

이유야 많지만, 가장 큰 이유는 우리가 학교나 회사에서 배우고 쓰는 글쓰기 방법과 블로그에 글을 쓰는 방법이 다르기 때문이다.

우리가 학교나 회사에서 배우고 쓰는 글쓰기 방법은 주로 논설문, 설명문이다. 이 글들은 전형적인 '문제해결의 글쓰기'이다. 특징은 아래와 같다.

• 주제가 분명해야한다.

  이 글을 왜 쓰는지, 무엇에 대한 글인지 답할 수 있어야한다.

• 독자수준을 고려해서 써야한다.

  읽는 독자가 누구인지, 독자가 원하는 것이 무엇인지 답할 수 있어야한다.

• 주장을 펼쳐야한다.

  주장하는 바가 무엇인지, 주장하는 바의 근거가 논리적이고 분명한지 답할 수 있어야한다.

글 한번 쓰는데 답해야할 것이 왜 이렇게 많은지(ㅠ)

문제해결의 글쓰기는 본질 자체가 문제에 충분히 고민하고 다양한 해결방안 중 하나를 전략적으로 선택하는 과정을 나타내는 것이다. 결국 익숙한대로 쓰려다보면 1) 주제가 분명하지 않거나 2) 독자수준으로 풀어쓰기 귀찮아지거나 3) 논리에 부족함이 있으면 목차도 못 잡고 한 줄도 못 쓰게 되는 것이다! 여기에 완벽주의까지 있으면 진짜 쓸 수가 없다..

반면 블로그에 글쓰는 방법은 상당히 다른 특징을 가진다.

• 주제가 불분명하다.

  ex) 개발기의 경우 딱히 주제라 할 만한 것이 없다. 억지로 주제를 짜내봤자 '힘들었던 개발 과정'이거나 '열심히 해봐라' 식의 메세지 밖에 없다. 그저 개발 과정 그 자체를 말하려는 것뿐이다. 어떤 강렬한 주제 의식이 있기 힘들다.

• 독자수준이 천차만별이다.

  ex) 개발자 블로그를 보는 사람은 대부분 개발자이지만, 그 수준은 천차만별이다. 개발자가 되고 싶은 나 같은 사람도 네이버 기술 블로그에서 TensorFlow를 활용한 네이버쇼핑의 상품 카테고리 자동 분류 같은 글을 흥미롭게 읽는다(물론 읽는 것과 이해하는건 달라요..). 이미 현업에서 열일하는 개발자님들도 velog에 올라오는 주니어의 삽질글을 읽기도 할 것이다.

• 딱히 주장을 펼치는 글이 아닐 수 있다.

  ex) TensorFlow를 활용한 네이버쇼핑의 상품 카테고리 자동 분류 같은 글을 예로 들면, 매칭 기능을 위해 CNN-LSTM 모델을 사용했다고 썼더라도 독자에게 그 모델을 써라고 주장하지는 않는다. 그냥 문제를 해결하는데 CNN-LSTM 모델을 선택했을 뿐이다. 물론 추천 정도는 할 수 있겠지만, 독자의 수많은 변수사항도 모른채 주장해서 설득하고 싶어하는 개발자는 거의 없다.

이런 특징을 고려하면 주제 우선 글쓰기, 독자 중심 글쓰기, 주장하는 글쓰기가 개발자 블로그에 보통 글쓰는 방법으로는 적합하지 않다는 것을 알 수 있다.

대신 1) 소재 우선 글쓰기, 2) 자기 수준 글쓰기, 3) 재미있는 글쓰기를 고려해보자!

기술 블로그를 쉽게 쓰는 방법 3가지

✅ 주제의식은 버리고 소재의식으로.

주제 의식이 아니라 소재 의식을 갖고 쓴다. 여기서 말하는 주제의식과 소재의식은 아래를 뜻한다.

주제의식	소재의식
추상적 가치를 기반으로 하는 글의 중심 사상 ex) 권선징악, 민족, 자존감, 자본주의	특정한 대상이나 상황에 대한 자기만의 관점이나 생각, 해결방안

주제의식 글쓰기는 주제를 정하고, 주제의식을 가지고 소재를 찾은 다음, 글 전체에 주제를 녹이면서 쓴다. 주제의식을 다른 사람에게 공감시키겠다는 목적을 가지고 있다.

소재의식 글쓰기는 독자와 상관 없이, 만난 대상이나 상황을 벗어날 때까지 겪은 일을 담담하게 정리해서 얘기할 뿐이다. 있었던 일을 쓰는 수필이나 에피소드 같은 글이다. (물론 국어 티-쳐들은 수필의 주제를 찾으실거다.)

예를 들어서 당근마켓 기술블로그의 딥러닝으로 동네생활 게시글 필터링하기 글을 보자. 동네 생활 게시글 필터링 모델을 개발할 필요를 느꼈고, 이를 위해 어떤 상황이라 어떤 기술을 선택했는지, 만족스러웠는지 어땠는지를 담담하게 적은 것이다. 전형적인 소재의식의 글이다.

벨로그에 올라와있는 모빈켈님의 아무도 가르쳐 주지 않는 것 글을 봐도 마찬가지다. 막 거창한 의식을 가지고 이를 퍼뜨리려고 하는 글이 아니다. 그냥 아무도 안 알려주는데 유용한 팁들을 정리해뒀을 뿐이다.

✅ 독자 수준이 아니라 자기 수준으로.

흔히 글쓰기 전문가들은 초등학생도 이해할 수 있도록 쉽게 풀어쓰라고 한다. 물론 쉬우면 좋다. 그런데 쉽게 쓰는데는 한계가 있다. 직장에서 겪은 일을 어떻게 초등학생이 이해할 수 있도록 쉽게 풀어쓸 수 있을까? 쉽게 쓰려면 비유를 써야하는데 생각보다 어려운 작업이다. 잘못 비유하면 의도와 다르게 오해를 불러일으킬 수 있고, 그 조차도 어떤 것의 원리를 간접적으로 모사한 것에 불과하다.

쉽게 쓰려고 너무 노력하다보면 설명이 많아져서 글이 늘어지고 무엇보다 글쓰는 개발자가 지치기 쉽다. 해법은 간단하다.

독자가 이해하지 못할 것으로 예상하거나 추가 정보가 필요한 용어에는 링크를 걸어주자!

굳이 어려운 용어를 풀어서 쓰거나 쉬운 용어로 바꿀 필요가 없다. 핵심 내용만 쓰고 궁금한 사람은 더 공부할 수 있게 길을 터놓으면 충분하다. 궁금한 사람은 알아서 찾아볼 것이고 링크 안의 설명이 더 도움될 것이다.

✅ 노잼 대신 유잼으로.

너무 당연한 얘기인데, 이왕이면 재밌게 쓰자!

논문이나 기술 매뉴얼, 사용 설명서를 쓸 때는 자신의 경험을 녹여내거나 글의 기교를 부릴 여지가 별로 없다. 정확하고 군더더기가 없이 깔끔하지만 글 쓰는 재미나 읽는 재미가 별로 없다. 예를 들어 위키피디아의 객체 지향 프로그래밍의 역사 항목을 보자.

객체 지향 언어의 시초

객체 지향 언어의 시초는 1960년 노위지안 컴퓨팅 센터의 조한 달과 크리스틴이 발표한 시뮬라67이다. 시뮬라67이 채택하고 있는 가장 중요한 개념은 클래스의 도입으로서 이 아이디어는 스몰토크, C++ 등에도 사용되었다. 하지만 시뮬라 67의 발표 이후 10여년 간 객체 지향 언어는 전혀 주목을 받지 못하였다. 1970년대 컴퓨터 산업을 주도한 IBM, AT&T, 미 국방성 등에서 관심을 두지 않았기 때문에 시뮬라 67은 실용적인 언어로 발전하지는 못하였다. 하지만 이의 학문적 가치는 인정받고 있다.

반면 [나무위키의 글]([https://namu.wiki/w/%EA%B0%9D%EC%B2%B4%20%EC%A7%80%ED%96%A5%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D](https://namu.wiki/w/객체 지향 프로그래밍))을 보자. 나름 기교를 부린 글이라 쉽게 읽히고 재밌다. 시간도둑이 따로 없다.. 뭐야 내 시간 돌려줘요

객체 지향 언어의 시작과 발전

초기 프로그래밍 방식은 [절차적 프로그래밍](https://namu.wiki/w/절차적 프로그래밍) 방식이었다. 학교대사전의 고등학생 알고리즘처럼 입력을 받아 명시된 순서대로 처리한 다음, 그 결과를 내는 것뿐이라는 생각이 지배적이었다. 프로그램을 명령어의 모음으로 인식한 것이다. 또한 프로그래밍이란 어떻게 어떤 논리를 어떤 순서대로 써나가는 것인가로 간주되었다. 즉, 프로그램 자체가 가지는 기능에 대해서만 신경을 썼지, 이 프로그램이 대체 어떤 데이터를 취급하는 것인가에는 그다지 관심이 없었던 것이다.

그러나, 이 방식은 간단한 알고리즘이면 모를까 조금만 복잡해지면 순서도로 나타내는 것이 불가능할 정도로 꼬인 "[스파게티 코드](https://namu.wiki/w/스파게티(소스 코드))"를 만들게 된다. 간단히 말해서 스타크래프트를 위의 순서도로 그려야 된다고 생각해봐라! 이렇게 꼬여버린 코드는 다른 사람이 보고 이해하는 것이 거의 불가능할 뿐더러 심지어는 작성한 본인조차도 유지보수에 어려움을 겪게 된다. 명령어의 양이 많아지는 것은 기본이고, 특정 코드 부분은 어디에 사용되는 코드고 해당 코드 부분은 어디까지 이어지는지의 흐름을 파악하기도 힘들어지며, 중복 코드 대처도 매우 골치아프다. OOP를 사용하면 코드의 중복을 어느 정도 줄일 수 있고 입력 코드, 계산 코드와 결과 출력 코드 등 코드의 역할 분담을 좀 더 확실하게 할 수 있어서 가독성이 높아질 수 있다.

기교라는게 대단한게 아니라 단순 사실 나열에서 벗어나서 개인적인 경험이나 생각을 좀 더 녹여내는 것이다. 막 드립을 찰지게 치거나 웃길 필요도 없다. 그냥 AI가 쓴 것 같은 글에서만 벗어나자..!

재밌는 글일 수록 사람들이 많이 읽고 피드백도 많이준다. 결과적으로 지속적으로 글을 쓸 수 있는 동력이 된다.

마치며

결국 개발 블로그를 쓰려면 '완벽주의'나 묘한 '사명감'(?)을 버리는 것이 핵심인 것 같다. 둘 모두 아무도 나한테 요구한 적 없는디 스스로 요구하면서 시작도 못 했던 것이 맞다. 블로그 글은 블로그 글답게, 쉽고 가볍게 글을 써보자! 사실 스스로 하는 소리다.