💡 이 글은 지극히 주관적인 내용을 담고 있습니다.
블로그 포스팅을 작성하는 방법은 다양하며, 본인의 성향, 목적, 공부 방법에 따라 천차만별로 나뉩니다.
다만, 아직 어떻게 글을 구조적으로 작성하고, 포스팅을 활용하는 방법을 모르는 분들을 위해 작성하게 되었습니다.
(참고로 고려한 독자층은 학생입니다.)
제가 작성한 포스트를 읽어 보시고, 이러한 구성이 마음에 드신다면 따라해보시길 권장드리며,
아이디어를 참고해서 독자적인 전략을 구상해보는 것도 의미있는 일이라고 생각합니다.
1. Introduction
📌 The reason why I am writing this post
최근 들어, 블로그를 시작하는 지인이 많아졌다.
그와 동시에, 포스팅을 대체 어떻게 적어야 하는 지 물어보는 사람도 많아졌다.
나는 오랜 시행 착오를 끝에, 나름대로 내게 가장 잘 맞는 블로그 포스팅 작성 방법을 고안해냈다.
그래서 이런 경험들을 공유하고자 글을 작성하게 되었다.
(원래 로그에 대한 고찰을 쓰다가, 너무 길어져서 이걸 먼저 쓰기로 했다.)
📌 Balancing Study and Posting
기술 블로그를 시작한 사람들은 저마다의 목적이 있을 것이다.
공부일 수도 있고, 취업을 위한 전략적 행동일 수도 있고, 셀럽이 되고 싶거나(?) 뭐 이런 것들 말이다.
어쨌든 단순히 메모장 정도로 사용할 것이 아니라면, 분명히 기술 블로그가 갖춰야 할 중요한 요소는 전문성이다.
(다른 것들도 있겠지만 반드시 하나 선택해야 한다면, 난 전문성을 뽑았을 뿐이다.)
문제는 현업에서 일하는 사람이라면 상관이 없겠지만, 나같은 학생은 전문성을 어필하기엔 뭔가 애매한 감이 있다.
직접 문제를 마주쳐서 해결한 경험일지라도, 그게 정말 최선의 방법이었는지, 정말 실무에서 사용하는 방법일지.
이런 측면에 있어서, 전문성을 너무 고집하려다 보면 결국 포스팅 작성을 망설이게 되고 대부분 여기서 포기해버린다.
그래서 내가 선택한 방법은 공부나 개발(혹은 연구 등)이 모두 끝나고 글을 작성하는 것이 아니라, 블로그를 작성과 공부를 병행하는 전략이었다.
이는 내 평소 공부 전략과 깊이 연관되어 있다.
- 학습하려는 내용의 숲(큰 그림)을 우선 살펴본다.
- 숲이 얼추 보이기 시작한다면, 구역별로 나누어 구체화한다.
- 각 구역을 탐색하기 위한 전략을 수립하고, 길을 밝혀나간다.
(TMT긴 하지만, 공부 전략은 정말정말 중요하다. 난 고등학생 시절 정말 치열하게 공부했지만, 매번 곰같이 공부한다는 얘기만 들었고, 실제로 성적도 형편없었다. 그러나 개발을 시작하고, 방대한 지식을 수용하기 위한 전략을 택하면서 학습 속도가 비약적으로 상승했었다. 자신만의 공부 전략이 없다면, 여러 방법들을 따라해보면서라도 만들어 보긴 적극 권장한다.)
문제는 여정이 모두 끝난 후 포스팅을 하려고 하면, 그 과정에서 겪었던 고난과 역경들에 대한 정보가 상당 수 손실된 상태일 확률이 높다. (본인의 기억력이 월등하게 좋다면 해당되지 않는 이야기)
학생이 전문성을 보이기 위해서 굳이 최선 혹은 최고의 솔루션을 도출해냈다는 결과에 맹목적일 필요는 없다.
그 여정 속에서 어떤 정보들을 바탕으로 어떠한 판단과 실수들을 했고, 이를 개선하기 위해 해결한 자신만의 방법들을 상세히 기술하는 것만으로도 가치있는 글을 작성할 수 있다.
이런 내용을 충분히 담기 위해서는 고민의 과정에 언제나 블로그 포스팅이 함께 해야만 한다.
단, 자체적인 솔루션이나 추론의 경우엔 사전에 미리 경고를 해두자.
그럼 잘못된 지식이 전파되는 것을 막고, 읽는 사람이 알아서 정보의 신뢰성을 필터링할 기회를 제공할 수 있다.
그리고 자신 또한 (최대한 정확한 정보를 전달하려 노력해야 하겠지만) 부담이 적어져, 보다 여유로운 마음으로 글을 작성할 수 있게 된다.
📌 Gather study members to review your blog post
잠깐이긴 하지만, 지인이 운영하던 블로그 리뷰를 위한 모임에 들어간 적이 있었다.
처음엔 큰 기대를 가지고 시작하지 않았지만, 생각 이상으로 안 좋은 포스팅 습관을 고치는데 상당히 개선이 되었다.
- 포스팅 작성 시 맥락이 끊기는 느낌을 개선하기 위해, 중간중간 전체 흐름을 상기시키는 내용을 삽입했다.
- 나는 이미 알고 있지만 고려 중인 독자층이 모를만한 용어 사용은 가급적 피하고, 피치 못할 경우 해당 개념을 직접 정리하거나, 관련 글을 하이퍼링크로 연결하거나, 아예 포스트 도입부에 경고 문구를 게시했다.
- 코드가 너무 많아서 가독성이 떨어지는 문제가 있어, 핵심 코드만 노출되도록 만들고 그 외는 github의 링크로 대체하였다.
글을 쓰는 시점의 나는 사전에 정말 많은 글들을 읽고, 고찰을 했기 때문에 이해하는데 큰 무리가 없다.
하지만 해당 개념을 전혀 모르는 상태의 독자에게 있어, 내 글이 정말 유의미하게 받아들여질 지는 알 수가 없다.
독자들이 댓글로 피드백을 남겨준다면 반영할 수 있겠지만, 솔직히 나도 공부할 때 방문한 블로그마다 댓글 다는 경우는 극히 적다.
따라서, 블로그를 운영하는 지인들과 함께 스터디 형식의 모임을 가져보는 것도 좋은 경험이 될 수 있다.
2. Purpose
📌 Why did you start a tech blog?
기술 블로그를 시작하려는 목적이 무엇인가?
단순히 메모장 정도로 사용하거나, 미래의 나를 위한 고찰을 끄적거리기 위한 목적이라면 자신에게 최적화하면 된다.
이런 경우, 본인이 필요한 게 아니라면 개념 정리조차 필요없다.
책을 공부하고 있다면 그냥 책을 읽고 본인이 읽고 든 생각 정도만 담는 게 오히려 깔끔하고 세련되게 보인다.
하지만 지식 공유를 포함하게 되면, 정보의 신뢰도에 대해 더 엄격하게 따져야 한다.
왜 블로그를 작성하는 지를 한 번쯤 꼭 상기하는 것이 좋다.
👇 서류나 면접에서 잘 보이려고 쓴다면?
이런 부류의 사람도 워낙 많이 봐서 내용을 추가해두었다.
면접관에게 잘 보이고 싶다는 욕구가 있다면, 면접관들이 싫어할 만한 내용이 뭔지를 생각해보는 게 쉽다.
왜냐면 좋아하는 것은 개인 성향이라 천차만별이지만, 보통 싫어하는 요소는 거의 비슷하기 때문이다.
1️⃣ 단순 개념 정리
- 블로그 내용을 복사/붙여넣기 한 수준의 블로그들을 심심치 않게 찾아볼 수 있다. 원문이 뭔지 알 수 있을 정도
- 이런 내용은 아무런 메리트가 없다. 그냥 '얘가 이런 거에 관심이 있나 보구나' 정도.
- 책을 정리하면서 분명히 모르거나, 의문이 생기는 부분들이 있을 텐데, 이에 대한 어떠한 고민의 흔적조차 남아있지 않다면 그냥 타이핑을 열심히 한 사람밖에 안 된다.
2️⃣ 불분명한 출처
- 명확한 정의가 존재하는 개념에 대해서 설명하는데, 아무런 출처가 남아있지 않은 경우가 빈번하다.
- 혹은 출처라고 존재하는 게 다른 학생들이 작성한 포스팅인 경우도 많다.
- 출처에 대한 검증이 이루어지지 않았다는 건 공부 목적으로도 손해지만, 그만큼 대충 공부한다는 방증이다.
3️⃣ 비약적인 결론
- 문제를 개선하기 위한 전략과 도구들을 탐색하는데, 그 이유가 나타나지 않은 경우가 많다.
- 예를 들어, "Kafka를 사용하여 서버 to 서버 통신 구현"라는 제목의 글을 작성한다면, 왜 굳이 kafka를 사용하여야 하는지는 전혀 고려한 흔적이 보이지 않은 경우에 해당한다.
- 문제에 대한 결론을 도출할 때는 틀려도 좋으니, 개인적인 고찰이 담겨있어야 한다.
4️⃣ 장황한 내용
- 면접관의 입장까지 가지 않더라도, 글의 가독성이 떨어지면 읽고 싶지가 않다.
- 서술식 구조를 배제하라는 의미가 아니다. 적어도 강조할 부분은 컬러를 입히거나, 글머리 기호를 적용하거나 별도로 구분할 수 있게 보여라.
📌 Who visits your blog?
만약 지식 전달의 목적을 가지고 있는 기술 블로그를 운영할 계획이라고 가정해보자.
그럼 본인의 글을 읽는 독자층은 누구인가?
이건 정말 중요한 문제다.
너무 어려운 개념을 낮은 독자층까지 고려하려면, 기초적인 용어도 하나하나 설명을 첨부해야 해서, 글이 필요 이상으로 장황해진다.
반대로 설명해야 하는데 누락하기도 한다.
이를 위해, 다음과 같은 고민들을 해볼 수 있다.
- 포스팅을 작성할 때, 독자층을 고려하여 상세 기술 정도를 채택하자. 예를 들어,
- 기초 지식: 숙련자가 읽을 경우는 거의 없으며, 본인 또한 초심자이므로 최대한 용어들을 정리
- 트러블 슈팅: 개인적인 경험이므로 문제 원인 분석 등은 상세히 적어야 함. 단, 과정에서 핵심이 되는 키워드를 제외하고는 별도의 언급을 하지 않는 게 나음.
- 내용이 너무 어려운 경우
- 포스팅을 분할해서 개념 정리 파트 정리 글 링크를 첨부
- 처음부터 어떤 사전 지식을 알고 있어야 하는 지 경고
📌 Structed Post
나는 포스팅을 작성할 때, 반드시 아래 5가지 순서를 따른다.
💡 포스팅 작성 순서
1. 대주제(제목)를 정한다.
2. 중주제들을 정한다.
3. 소주제들을 정한다.
4. 각 주제들에 적을 간략한 요약을 메모해둔다.
5. 내용을 구체화한다.
실제로 지금 작성 중인 글도 이렇게 하고 있다.
이 순서로 포스팅을 하면, 다음과 같은 이점을 얻는다.
- 대주제(제목) -> 중주제 -> 소주제를 정한다.
- 글을 쓰면서, 내용이 다른 주제로 넘어가지 않도록 틀을 잡을 수 있다.
- 내가 전달하고자 하는 메시지를 가장 효과적으로 알리는 구조를 고려할 수 있다.
- 스스로에게 큰 그림을 먼저 보고, 세부적인 항목을 구체화하도록 강제할 수 있다. (머리에 진짜 잘 남는다. 방대한 양의 지식들을 도서관의 책을 정리하듯 흡수할 수 있다.)
- 글의 순서가 체계적이기 때문에, 독자들에게도, 미래에 다시 찾아볼 나에게 있어서도 도움이 된다.
- 도중에 추가되어야 할 내용이 생겨도, 상위 항목 내에서 유연하게 순서와 카테고리를 변경할 수 있다.
- 각 주제들에 적을 간략한 요약을 적는다.
- 적다보면 내용을 잊어먹는 경우가 많기 때문에 필요하다.
- 요약을 적으면서, 중복될 것 같은 부분들을 사전에 미리 발견하기 용이하다.
이 방법의 단점은 글을 채우는 시간보다 각 주제를 정하는 시간이 훨씬 많이 소요된다는 것이다.
큰 그림을 보기 위해서, 방대한 양의 자료들을 서칭해봐야 할 것이며, 이러한 방법이 숙달되지 않은 사람에겐 더더욱 힘든 일이 될 가능성이 높다.
그래도 항상 지인들에게 추천하는 방법.
📌 How to Utilize Sources
포스팅 작성 순서의 카테고리들을 정하고 난 후에는 정말 많은 웹 페이지들이 펼쳐져 있는 상태일 것이다.
하지만, 너무 많은 웹 페이지가 열려 있으면 글을 작성하면서 원하는 내용을 찾기도 힘들다.
또한, 글을 작성하는 시간이 길어져서 흐름이 끊기면, 내가 해당 페이지를 왜 열어놨지 싶은 것들도 많다.
그래서 "(4) 요약" 단계에서 출처들을 일단 전부 복붙해두자.
그리고 현재 열려있는 모든 페이지를 닫아버리고, 현재 작성 중인 주제에 대한 페이지만 열어두면 훨씬 수월하게 글을 작성할 수 있다.
3. Contents
📌 Accuracy
정보의 신뢰도를 높이기 위한 가장 좋은 방법은 다른 신뢰있는 출처(논문, 책, 회사별 기술 블로그 등)를 인용하는 것이다.
가끔 아이디어 참고가 아니라, 개념 이해를 위해 내 블로그를 인용하는 경우가 있던데 제발...멈춰주세요...ㅠ
⚠️ 오래된 게시글은 신뢰있는 출처라도 경계해야 한다.
최근 IT 직군의 기술 발전 속도는 날이 갈 수록 빨라지고 있고, 트렌드는 날마다 바뀐다.
예전에 GC 동작에 대한 네이버 기술 블로그 글을 본 적이 있었는데, 19년도 자료를 25년도 시점에서 보다 보니 틀린 정보였던 적이 있다.
📌 Consideration
고찰의 과정은 기술 블로그의 핵심적인 부분이다.
적어도 아래 내용이 반드시 담겨야 한다.
- 문제 정의: 공부하려는 주제, 해결하려는 이슈 내용 등
- 고찰: 개인적인 고민이 담긴 학습 과정, 혹은 트러블 슈팅 과정 등
- 결과: 알게 된 점, 느낀 점, 성능 지표 평가 등
사실상 위 요소들이 양산형 블로그와 그렇지 않은 블로그들을 판가름하는 기준이라고 생각한다.
문제는 개인적인 고찰이 대체 어떤 내용을 담아야 하냐는 것이다.
1️⃣ 책 내용을 정리하고 있다면, 책에 나오지 않거나, 설명하지 않는 정보들을 찾아보라.
책의 수준이 깊어지면 깊어질 수록, 이해가 가지 않는 부분이 없다면 비정상적인 것이다.
그리고 책들도 독자 수준을 고려하여, 기본적인 개념은 모두 건너뛰기 때문에 내가 이해하지 못하는 개념을 따로 설명해주지 않을 수도 있다.
예를 들어, 나는 WebSocket 프로토콜에 대한 포스팅을 작성할 때, ITEF의 공식문서를 읽으면서 "Frame에 Mask 필드가 왜 필요한 거지?"라는 의문이 들어 정리하기도 했다.
이는 당연히 공부할 때 수반해야 하는 과정임에도 불구하고, 막상 포스팅을 작성할 때는 드랍하는 경우가 많다.
2️⃣ 트러블 슈팅에 대한 내용이라면, 과정 속에서 마주한 여러 상황을 기록하라.
트러블 슈팅은 다방면에서 개인의 문제 해결 능력을 최대한 활용해야 하는 경우가 많다.
- 문제의 원인을 어떻게 찾아냈고, 왜 그것이라 생각했는가?
- 이를 개선하기 위해 어떤 대안들을 고려해보았는가? 왜 그것이 최선의 방법인가?
- 왜 수많은 도구들 중, 그것을 현재 사용해야 하는가? 그 도구의 기능은 대체 무엇인가?
- 도중에 개선책이 잘못되었다면, 이를 어떻게 인지하고, 어떻게 바로잡았는가?
- 결과가 구체적으로 어떻게 개선되었으며, 더 나은 대안은 없었는가?
이 외에도 수많은 고민의 흔적들을 담을 기회들이 존재한다.
그런데, 정말 정말 수많은 블로그가 아쉽게도 원인 분석 후 결과로 끝나는 경우가 많다.
예를 들어, 소프트웨어의 병목 지점에서 성능 저하가 발생했다고 치자.
- 현재 작업 중인 소프트웨어 소개
- 원인 분석 후, 병목 지점 파악
- 개선 (짜잔~)
- 각종 출처들
하물며, 토스나 카카오, 네이버 같은 기술 블로그를 읽어봐도 이런 식으로 작성하지 않는다.
심지어 개선 이후, 오히려 효율이 떨어진다는 이유로 다시 롤백하는 과정까지 담는 경우도 존재한다.
학생 개발자 블로그나 나름 정보 전달을 목적으로 하는 블로그에서 이런 포스팅을 읽게 되는 경우, 난 고민도 하지 않고 페이지를 종료해버린다.
정보가 틀렸다는 것이 중요한 게 아니다.
당연히 개인적 고찰이기 때문에 틀릴 수 있으며, 이를 굳이 감추지 않아도 된다.
그런데 고찰이 담겨있지 않은 글들을 참고해버리면, 어떤 이유와 판단들로 결과가 나왔는 지 알 수 없기 때문에 또 다른 오류를 파생시킬 가능성이 농후한 잘못된 솔루션을 참고하게 될 수도 있다.
(물론, 아주 가끔 고찰만 안 적고 제대로된 솔루션을 주는 경우가 있다. 정말 필요하다면, 그 과정을 스스로 추적해보는 것도 좋은 방법이다.)
3️⃣ 정보의 출처를 비판적으로 바라봐라.
기술 발전 속도는 빠르며, IT 분야는 이 현상이 더 극심하게 나타난다.
어제까지 각광받던 책이 내일은 완전히 틀렸다고 부정당하는 게 이상하지 않을 수준이다.
즉, 선형대수학이라도 공부하는 게 아니라면, 무엇이든 비판적으로 보아야 한다.
IT 기술 블로그들의 내용은 너무나도 훌륭한 것들이 많지만, 그들 또한 자신의 서비스에 최적화된 형태의 다양한 솔루션을 제시하는 것일 뿐이다.
그건 정답이 아니다.
4️⃣ 신뢰할 수 없는 출처들을 활용하라.
정보의 출처가 믿을 수 있는 기관이 아닌, 스택 오버 플로우의 커멘트 같은 것들을 사용할 수밖에 없는 경우가 있다.
이는 보통 정답이 없는 문제(ex: 언제 로그를 남길 것이냐? 내 프로젝트에 적합한 아키텍처는 무엇이냐?)들일 경우에 더욱 심하다.
그럼 이건 써먹을 수 없는 걸까? 놉! 그렇지 않다.
구글에 떠돌아다니는 기술 블로그들을 그대로 인용하지 말라는 거지, 사용 방법이 없는 것은 아니다.
예전에 작성했던 글에서 여러 사람들의 의견들을 종합해서, 내 나름대로 분석을 해본 경험이 있다.
이 방법이 효과적인 이유는 두 가지 효과를 동시에 얻을 수 있다는 점이다.
- 혼자서 추론하고 끝내는 것이 아닌, 다양한 사람들의 의견들을 분석하여 유의미한 결과를 도출해볼 수 있다.
- 애초에 대놓고 추론이 난무하기 때문에, 읽는 독자로 하여금 정답이 아닌 개인적 고찰임을 분명히 보여줄 수 있다. 즉, 적어도 잘못된 정보가 전파되는 것을 막을 수 있다.
📌 Question
글을 쓰다 보면, 도저히 해결이 되지 않는 질문들이 남아있는 경우가 있다.
나는 이걸 버리지 않고, 일단 써둔다.
그리고 나름의 생각을 이것저것 덧붙여 두고, 그대로 원문과 함께 게시해버린다.
숲을 탐험하는 과정 속에서 그 무엇하나 버리지 말자.
나중에라도 이러한 질문에 대한 해답을 얻었을 때 해결하면 된다.
기록하지 않으면, 그대로 다이아 원석을 땅에 버리고 가버리는 꼴이다.
4. Conclusion
📌 Just Do It!!
여기까지 하면, 오히려 더 난감해 하는 사람들이 많다.
그런 사람들을 위해 해주고 싶은 말은 고민하다가 안 쓰는 거 보다는 그래도 일단 써보는 게 더 좋다는 것이다.
나 또한 이런 전략을 세우기 위해서 엄청나게 시행착오를 했고, 끊임없이 고민했으며, 지금도 그 과정에 있다.
책을 그냥 타이핑하다가 현타와서 접은 적도 있고,
나중에 개념이 기억이 안 나서 내 블로그를 다시 둘러보다가 뭔 소린지 이해 못한 경우도 많다.
어쨌든 본인에게 맞는 전략을 택하는 건 경험이라는 자산이 필요하고, 그러기 위해선 일단 해봐야 한다.
부디, 더 가치있는 블로그들이 많이 나오길 바라며 글을 마친다.