개발자가 기술 블로그를 잘 못 쓰는 이유 중 하나는 블로그에 글을 쓰는 방법이 학생이었을 때 배운 글쓰기 방법과 다르기 때문이다. 학생이었을 때 배운 글쓰기 방법은 주로 논설문이나 설명문을 쓰는 방법이었다. 논설문이나 설명문은 목적이 분명해야 해서 다음 질문에 먼저 답할 수 있을 때 비로소 글쓰기를 시작할 수 있다.
이 글을 왜 쓰는가?
이 글을 읽는 독자는 누구인가?
이 글을 읽는 독자에게 무엇을 말하려고 하는가?
이 글이 주장하는 바가 무엇인가?
이 글이 주장하는 바의 근거가 분명한가?
이런 질문에 대답해야 하니 글쓰기는 자연스럽게 문제해결 과정이 되었다. 글쓰기를 문제해결 과정으로 배운 것이다. 문제해결 과정의 핵심은 문제를 충분히 고민하여 해결 방안을 전략적으로 선택하는 것이다. 이를 글쓰기에 대입하면, 글을 쓰기 전에 계획을 세우는데, 이 계획 단계에 시간을 충분히 할애해야 한다.
무턱대고 글부터 쓰면 안 되고, 충분히 생각해서 주제를 정하고 주제 의식을 확립한 후 글을 쓸 때 자료나 아이디어를 구해야 한다. 그러고 나면 독자를 분석해서 글의 수준이나 방향을 정해야 한다.
기술 블로그를 읽는 독자의 수준은 일정하지 않다. 개발자 블로그를 보는 사람은 대부분 개발자이지만, 개발자의 폭과 깊이가 천차만별이다. 개발자의 블로그는 딱히 주장도 없다. 단지 개발자가 했던 선택과 몇몇 상황에서 더 좋은 방법을 제시할 수 있을 뿐이다. 독자에게 그렇게 하라고 주장해서 설득하고 싶은 마음을 가진 개발자는 전혀 없다.
저자가 추천하는 블로그에 글 쓴느 적합한 3가지 방법을 소개한다. 첫째 소재 우선 글쓰기, 둘째 자기 수준 글쓰기, 셋째 재미있는 글쓰기다.
첫째, 주제 의식을 버리고 소재 의식으로 쓰자
소재 우선 글쓰기는 주제 의식이 아니라 소재 의식을 갖고 쓰는 것이다. 주제 의식이 민족이나 권선징악, 자존감이나 자본주의와 같은 추상적 가치를 기반으로 한다면 소재 의식은 특정한 대상이나 상황에 대한 자기만의 관점이나 생각, 해결 방안을 뜻한다.
ex) 소재 의식: 데이터베이스의 자동증가 값을 기본키로 사용할 수 없을 때는?
이러한 점에서 기술 블로그는 일상을 다룬 수필이나 에피소드와 비슷하다. 수필을 평가하는 평론가나 국어 선생님들이 수필의 주제를 찾는 것이지, 수필을 쓰는 사람은 그저 일어난 이야기를 할 뿐이다.
둘째, 독자 수준이 아니라 자기 수준으로 쓰자
글쓰기 전문가들은 다른 글을 쓸 때 초등학생도 이해할 수 있도록 쉽게 풀어서 쓰라고 한다. 하지만 직장에서 하는 일을 초등학생에게 풀어서 설명하기는 어렵다.
면접에서 정말 많이 나오는 질문인 초등학생, 중학생 수준이라고 생각하고 기술을 설명해달라는 질문이 있다. 이 질문에 대한 답변은 대부분이 비유를 하여 쉽게 설명한다.
개발자가 기술 블로그를 쓸 때는 독자를 생각해서 굳이 어려운 용어를 해석해 풀어쓰거나 쉬운 용어로 바꿀 필요가 없다. 원래 사용하는 용어로 표기하되, 필요하다면 그 용어를 설명하는 링크를 걸어두면 된다. 기술 블로그란 것은 결국 실력이 비슷한 독자를 위한 것이다. 독자에게 설명하는 것이 아니라 핵심만 쓰고 나머지는 독자가 공부할 수 있게 길만 터놓는 것이 현명한 방법이다.
그래야 개발자도 자기가 쓰려는 글의 본질에 집중할 수 있다.
셋째, 재미있는 글을 쓰자
논문이나 기술 메뉴얼, 사용 설명서를 쓸 때는 자신의 경험을 녹여내거나 글의 기교를 부릴 여지가 별로 없다. 이런 글은 군더더기 없이 깔끔하지만, 글 쓰는 재미나 읽는 재미가 별로 없다.
글쓰기 기교는 글을 아름답게 만들고 쉽게 읽히게 한다. 기교를 부리다 보면 글쓰기가 재미있고 글도 재미있어진다. 글에 재미가 있으면 독자가 활발히 반응하고 독자의 반응이 활발하면 블로거는 글을 계속 쓸 동력을 얻는다. 글쓰기 기교는 이렇게 선순환을 만든다.
글의 종류별로 목차 잡는 법 1 - 저술
기술 블로그의 4종류, 저, 술, 편, 집
개발자가 기술 블로그에 쓰는 종류는 매우 다양하다. 직접 개발한 과정, 튜토리얼, 개발 가이드, 에러나 버그를 해결하는 방법, 세미나 후기나 책 리뷰, 스스로 깨달은 교훈, 각종 레퍼런스, 개발 상식 등 수도 없이 많다. 하지만 이런 글은 모두 4가지로 분류할 수 있다.
구분
내용
종류
저
직접 경험하고 실험한 내용이나 결과
개발기, 도입기, 적용기
술
어떤 것을 분석하여 의미를 풀이하고 해석한 것
기술 소개, 용어 분석, 에러 해결 방법 등
편
산만하고 복잡한 자료를 편집해 질서를 부여한 것
프로그램 설치/설정 방법, 튜토리얼, 세미나 후기, 책 리뷰
집
여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것
명령어 모음, 팁, 00가지 규칙
저: 개발기는 목차를 잘 잡아서 본문부터 쓰자
저는 직접 경험한 것을 쓴 것이다. 개발 과정과 결과를 쓴 개발기가 여기에 해당한다.
맵 절차적 생성기를 활용한 게임 개발기
유니티 게임 고도엔진으로 포팅하기
개발 과정과 결과를 다룬 개발기를 쓸 때는 무엇보다 목차를 잘 구성해야 한다. 목차만 제대로 잡으면 다른 종류의 글보다 쓰기 쉽다. 다시 말하면, 많은 개발자가 개발기 목차를 구성하지 못해서 개발기를 잘 못 쓴다.
개발기 목차는 1차원 단방향이다. 1장 다음에는 2장이 이어지고, 2장 다음에는 3장이 순서대로 이어진다. 하지만 개발자의 경험은 2차원 양방향이다. A문제를 해결하려고 했지만, 다시 E문제가 생기고 F코드를 썼는데 G 버그가 생겨서 한참을 복기하다가 H 코드로 바꾸는 식으로 경험한다. 그래서 개발자 머릿속에는 자신의 경험이 길을 잃고 헤매다 겨우 목적지에 도착한 모습으로 남아 있다. 이렇게 복잡한 2차원 양방향 개발 경험을 1차원 단뱡향 목차로 바꾸어야 하니 어렵다.
2차원 양방향 경험을 1차원 단방향 목차로 바꾸는 핵심 방법은 최종적으로 성고한 루트와 실패한 루트를 구별하는 것이다. 내 생각에는 위에서 말한 결험들이 잘 버전관리가 되어 있고, 문서화가 되어있다면 더 좋을 것 같다.
위 내용대로 구별을 잘해서 목차를 구성했다면 보통 머리말부터 글을 쓰려할텐데 개발자가 가장 어려워하는 내용이 머리말이다. 본문을 잘 적고 이후에 작성하자.
술: 원전을 비교하고 실험해 풀이해서 쓰자
술은 어떤 것을 분석해 의미를 풀이하고 해석한 것이다. 인문학에서 술은 경전을 해설한 글을 말한다. 개발에서 술은 새로운 기술을 자세하게 또는 비유해 설명한 것, 비슷한 용어를 비교해 풀이한 것, 에러 해결 방법 등이 여기에 해당한다. 예를 들면 다음과 같은 글이 술에 해당된다.
C++11의 auto 키워드 사용법
유니티 ScriptableObject에 대한 이해
인문학에 경전이 있는 것처럼 개발에도 원전, 즉 원서나 원문, 프로토콜이나 레퍼런스가 있다. 그래서 술에 해당되는 기술 블로그를 쓸 때는 본래 내용을 바탕으로 자기 생각이나 분석, 해설을 덧붙이는 방식으로 쓰는 게 좋다.
글의 종류별로 목차 잡는 법 2 - 편집
편: 순서를 요약하여 쓰자
편은 산만하고 복잡한 자료를 편집해 질서를 부여한 것이다. 프로그램 설치나 설정 순서, 개발 방법, 튜토리얼, 컨퍼런스 후기 등이 해당된다.
편을 쓰는 방법은 저술보다 쉽다. 시간 순서로 하나씩 나열해 내용을 쓴 다음, 단계로 묶어서 요약하기만 하면 글이 완성되기 때문이다.
작성에 대한 팁은 일단 글을 순서대로 쭉 쓰고, 목차를 정한뒤 내용을 자세히 적으면 된다. 여기에 단계를 더해 질서 있게 보여준다.
집: 글쓰기가 두렵다면 자료를 모아 핵심으로 엮어서 쓰자
집은 여러 살마의 견해나 흩어진 자료를 한데 모아 정리하는 것이다. 자료가 아니라 비슷한 여러 책을 한데 모아 출간한 것을 전집이라고 하는데, 이때 '집'은 단순히 여러 책을 모은 것이고, 지금 말하는 '집'은 자료를 모아 하나의 책으로 엮은 것이다.
집은 여러 자료를 하나로 묶기 때문에 이것저걱 아무렇게나 집어넣을 수가 없다. 따라서 요점만을 축약해서 모아야 하는데 이를 집요라고 한다.
좋은 코딩을 위한 13가지 규칙
유니티 사용 팁 모음
대부분 이런 글들이 조회수를 담당하며 이는 고수보다 초보자가 더 검색을 많이하기 때문이다. 개발을 다룬 저술은 쓰기 어렵지만 꾸준히 천천히 쓰며 익숙해지자
7장: 기술 블로그 쉽게 쓰고 운영하기
기술 블로그를 쉽게 쓰는 방법 3가지
개발자가 기술 블로그를 잘 못 쓰는 이유
개발자가 기술 블로그를 잘 못 쓰는 이유 중 하나는 블로그에 글을 쓰는 방법이 학생이었을 때 배운 글쓰기 방법과 다르기 때문이다. 학생이었을 때 배운 글쓰기 방법은 주로 논설문이나 설명문을 쓰는 방법이었다. 논설문이나 설명문은 목적이 분명해야 해서 다음 질문에 먼저 답할 수 있을 때 비로소 글쓰기를 시작할 수 있다.
이런 질문에 대답해야 하니 글쓰기는 자연스럽게 문제해결 과정이 되었다. 글쓰기를 문제해결 과정으로 배운 것이다. 문제해결 과정의 핵심은 문제를 충분히 고민하여 해결 방안을 전략적으로 선택하는 것이다. 이를 글쓰기에 대입하면, 글을 쓰기 전에 계획을 세우는데, 이 계획 단계에 시간을 충분히 할애해야 한다.
무턱대고 글부터 쓰면 안 되고, 충분히 생각해서 주제를 정하고 주제 의식을 확립한 후 글을 쓸 때 자료나 아이디어를 구해야 한다. 그러고 나면 독자를 분석해서 글의 수준이나 방향을 정해야 한다.
기술 블로그를 읽는 독자의 수준은 일정하지 않다. 개발자 블로그를 보는 사람은 대부분 개발자이지만, 개발자의 폭과 깊이가 천차만별이다. 개발자의 블로그는 딱히 주장도 없다. 단지 개발자가 했던 선택과 몇몇 상황에서 더 좋은 방법을 제시할 수 있을 뿐이다. 독자에게 그렇게 하라고 주장해서 설득하고 싶은 마음을 가진 개발자는 전혀 없다.
저자가 추천하는 블로그에 글 쓴느 적합한 3가지 방법을 소개한다. 첫째 소재 우선 글쓰기, 둘째 자기 수준 글쓰기, 셋째 재미있는 글쓰기다.
첫째, 주제 의식을 버리고 소재 의식으로 쓰자
소재 우선 글쓰기는 주제 의식이 아니라 소재 의식을 갖고 쓰는 것이다. 주제 의식이 민족이나 권선징악, 자존감이나 자본주의와 같은 추상적 가치를 기반으로 한다면 소재 의식은 특정한 대상이나 상황에 대한 자기만의 관점이나 생각, 해결 방안을 뜻한다.
이러한 점에서 기술 블로그는 일상을 다룬 수필이나 에피소드와 비슷하다. 수필을 평가하는 평론가나 국어 선생님들이 수필의 주제를 찾는 것이지, 수필을 쓰는 사람은 그저 일어난 이야기를 할 뿐이다.
둘째, 독자 수준이 아니라 자기 수준으로 쓰자
글쓰기 전문가들은 다른 글을 쓸 때 초등학생도 이해할 수 있도록 쉽게 풀어서 쓰라고 한다. 하지만 직장에서 하는 일을 초등학생에게 풀어서 설명하기는 어렵다.
면접에서 정말 많이 나오는 질문인 초등학생, 중학생 수준이라고 생각하고 기술을 설명해달라는 질문이 있다. 이 질문에 대한 답변은 대부분이 비유를 하여 쉽게 설명한다.
개발자가 기술 블로그를 쓸 때는 독자를 생각해서 굳이 어려운 용어를 해석해 풀어쓰거나 쉬운 용어로 바꿀 필요가 없다. 원래 사용하는 용어로 표기하되, 필요하다면 그 용어를 설명하는 링크를 걸어두면 된다. 기술 블로그란 것은 결국 실력이 비슷한 독자를 위한 것이다. 독자에게 설명하는 것이 아니라 핵심만 쓰고 나머지는 독자가 공부할 수 있게 길만 터놓는 것이 현명한 방법이다.
그래야 개발자도 자기가 쓰려는 글의 본질에 집중할 수 있다.
셋째, 재미있는 글을 쓰자
논문이나 기술 메뉴얼, 사용 설명서를 쓸 때는 자신의 경험을 녹여내거나 글의 기교를 부릴 여지가 별로 없다. 이런 글은 군더더기 없이 깔끔하지만, 글 쓰는 재미나 읽는 재미가 별로 없다.
글쓰기 기교는 글을 아름답게 만들고 쉽게 읽히게 한다. 기교를 부리다 보면 글쓰기가 재미있고 글도 재미있어진다. 글에 재미가 있으면 독자가 활발히 반응하고 독자의 반응이 활발하면 블로거는 글을 계속 쓸 동력을 얻는다. 글쓰기 기교는 이렇게 선순환을 만든다.
글의 종류별로 목차 잡는 법 1 - 저술
기술 블로그의 4종류, 저, 술, 편, 집
개발자가 기술 블로그에 쓰는 종류는 매우 다양하다. 직접 개발한 과정, 튜토리얼, 개발 가이드, 에러나 버그를 해결하는 방법, 세미나 후기나 책 리뷰, 스스로 깨달은 교훈, 각종 레퍼런스, 개발 상식 등 수도 없이 많다. 하지만 이런 글은 모두 4가지로 분류할 수 있다.
저: 개발기는 목차를 잘 잡아서 본문부터 쓰자
저는 직접 경험한 것을 쓴 것이다. 개발 과정과 결과를 쓴 개발기가 여기에 해당한다.
개발 과정과 결과를 다룬 개발기를 쓸 때는 무엇보다 목차를 잘 구성해야 한다. 목차만 제대로 잡으면 다른 종류의 글보다 쓰기 쉽다. 다시 말하면, 많은 개발자가 개발기 목차를 구성하지 못해서 개발기를 잘 못 쓴다.
개발기 목차는 1차원 단방향이다. 1장 다음에는 2장이 이어지고, 2장 다음에는 3장이 순서대로 이어진다. 하지만 개발자의 경험은 2차원 양방향이다. A문제를 해결하려고 했지만, 다시 E문제가 생기고 F코드를 썼는데 G 버그가 생겨서 한참을 복기하다가 H 코드로 바꾸는 식으로 경험한다. 그래서 개발자 머릿속에는 자신의 경험이 길을 잃고 헤매다 겨우 목적지에 도착한 모습으로 남아 있다. 이렇게 복잡한 2차원 양방향 개발 경험을 1차원 단뱡향 목차로 바꾸어야 하니 어렵다.
2차원 양방향 경험을 1차원 단방향 목차로 바꾸는 핵심 방법은 최종적으로 성고한 루트와 실패한 루트를 구별하는 것이다. 내 생각에는 위에서 말한 결험들이 잘 버전관리가 되어 있고, 문서화가 되어있다면 더 좋을 것 같다.
위 내용대로 구별을 잘해서 목차를 구성했다면 보통 머리말부터 글을 쓰려할텐데 개발자가 가장 어려워하는 내용이 머리말이다. 본문을 잘 적고 이후에 작성하자.
술: 원전을 비교하고 실험해 풀이해서 쓰자
술은 어떤 것을 분석해 의미를 풀이하고 해석한 것이다. 인문학에서 술은 경전을 해설한 글을 말한다. 개발에서 술은 새로운 기술을 자세하게 또는 비유해 설명한 것, 비슷한 용어를 비교해 풀이한 것, 에러 해결 방법 등이 여기에 해당한다. 예를 들면 다음과 같은 글이 술에 해당된다.
인문학에 경전이 있는 것처럼 개발에도 원전, 즉 원서나 원문, 프로토콜이나 레퍼런스가 있다. 그래서 술에 해당되는 기술 블로그를 쓸 때는 본래 내용을 바탕으로 자기 생각이나 분석, 해설을 덧붙이는 방식으로 쓰는 게 좋다.
글의 종류별로 목차 잡는 법 2 - 편집
편: 순서를 요약하여 쓰자
편은 산만하고 복잡한 자료를 편집해 질서를 부여한 것이다. 프로그램 설치나 설정 순서, 개발 방법, 튜토리얼, 컨퍼런스 후기 등이 해당된다.
편을 쓰는 방법은 저술보다 쉽다. 시간 순서로 하나씩 나열해 내용을 쓴 다음, 단계로 묶어서 요약하기만 하면 글이 완성되기 때문이다.
작성에 대한 팁은 일단 글을 순서대로 쭉 쓰고, 목차를 정한뒤 내용을 자세히 적으면 된다. 여기에 단계를 더해 질서 있게 보여준다.
집: 글쓰기가 두렵다면 자료를 모아 핵심으로 엮어서 쓰자
집은 여러 살마의 견해나 흩어진 자료를 한데 모아 정리하는 것이다. 자료가 아니라 비슷한 여러 책을 한데 모아 출간한 것을 전집이라고 하는데, 이때 '집'은 단순히 여러 책을 모은 것이고, 지금 말하는 '집'은 자료를 모아 하나의 책으로 엮은 것이다.
집은 여러 자료를 하나로 묶기 때문에 이것저걱 아무렇게나 집어넣을 수가 없다. 따라서 요점만을 축약해서 모아야 하는데 이를 집요라고 한다.
대부분 이런 글들이 조회수를 담당하며 이는 고수보다 초보자가 더 검색을 많이하기 때문이다. 개발을 다룬 저술은 쓰기 어렵지만 꾸준히 천천히 쓰며 익숙해지자