블로그 개발 이유와 과정

블로그 시작한 이유

누구도 나를 위해 지식을 정리해 주지 않는다

초·중·고 때의 공부는 모든 것이 잘 준비된 특별한 환경이었다.
교과서와 참고서에는 개념 설명, 용어 정의, 유형별 문제가 적절한 순서와 난이도로 배치되어 있다.
중단원, 대단원 문제처럼 이해도를 점검할 수 있는 장치도 마련되어 있다.
이 모든 내용은 “한 권”이라는 형태로 깔끔하게 정리되어 있다.
여기에 더해 친절하게 만들어진 강의와 보조 자료도 많다.
내용이 이해되지 않는다면, 나를 이해시켜 줄 다른 자료를 쉽게 찾아볼 수 있다.

하지만 학교 밖에서는 그런 환경이 당연하지 않다.
회사에 매뉴얼이 없을 수도 있고, 업무가 구두로만 전달되기도 한다.
누군가가 회의 결과를 대신 정리해 주지도 않는다.
정보는 계속 흘러들어오고, 결국 내가 직접 정리해야 한다.

프로그래밍을 공부할 때도 마찬가지였다.
기술이 빠르게 변하다 보니 쏟아지는 정보에 비해 출판되는 책은 그리 많지 않다.
책을 찾아도 번역이 어색하거나, 저자 한 사람의 관점으로만 서술되어 나에게 그 설명이 잘 와닿지 않기도 한다.
결국 대부분의 자료는 공식 문서, 블로그 글, 강의, 소스 코드처럼 사방에 흩어져 있기 마련이다.
따라서 수많은 자료를 직접 읽고 비교하며, 내가 이해한 방식으로 다시 정리하는 과정이 필요하다.

복습을 위해 기록이 필요하다

무언가를 한 번 이해했다고 해서 곧바로 나의 지식이 되는 것은 아니다.
그 순간에는 분명히 이해한 것 같아도, 시간이 지나면 모든 것이 희미해진다.
왜 그런 문제가 생겼는지, 어떤 선택지를 비교했는지, 결국 왜 그 방식으로 해결했는지까지 모두 기억하기란 쉽지 않다.

학교 공부에서는 의도적으로 복습하지 않아도 진도를 나가다 보면 자연스럽게 복습이 이루어진다.
비슷한 문제와 응용 문제를 반복해서 만나면서, 이전에 배운 내용을 다시 떠올릴 기회가 생기기 때문이다.
필요할 때 의도적으로 복습하기도 비교적 쉽다.
내용이 책이라는 형태로 잘 조직되어 있으니, 다시 펼쳐서 앞뒤 맥락을 따라가면 된다.

하지만 프로그래밍에서는 그런 반복이 저절로 주어지지 않는다.
한 번 해결한 문제와 똑같거나 비슷한 상황을 다시 만날 기회가 많지 않고, 다시 만나더라도 한참 시간이 지난 뒤인 경우가 대부분이다.
게다가 앞서 말했듯이 프로그래밍 관련 자료는 한 권의 책처럼 정리되어 있지 않고 여러 곳에 흩어져 있다.
그 사이에 내가 참고한 자료와 이해한 흐름을 스스로 정리해 두지 않으면, 막상 같은 문제를 다시 마주했을 때 “예전에 풀어본 적 있다”는 느낌만 남을 뿐이다.

기록은 단순히 배운 내용을 보관하는 일이 아니다.
적는 행위 자체가 이해를 점검하는 과정이다.
머릿속에서 흐릿하게 알고 있던 것을 글로 꺼내다 보면, 실제로 이해한 것과 그렇지 않은 것이 드러난다.
또 내가 이해한 흐름을 글로 남겨두면 시간이 지난 뒤에도 기억을 빠르게 복원할 수 있다.
블로그는 그런 의미에서 미래의 나를 위한 복습 장치가 된다.

기존 블로그 플랫폼을 검토하다

상용 플랫폼을 이용하면 글쓰기에만 집중할 수 있어 좋은 선택지다.
하지만 실제로 검토해 보니 각 플랫폼마다 아쉬운 점이 있었다.

• 티스토리

  • 운영 주체와 소유권이 여러 차례 바뀌어 왔다.
  • 백업, 복원, API, 수익 창출 관련 정책도 계속 변해 왔다.
  • 이런 이유로 장기적으로 안정적인 플랫폼인지 확신하기 어려웠다.

• 네이버 블로그

  • 같은 글도 PC용 주소와 모바일용 주소가 따로 존재하는데, PC에서 구글로 검색했는데 모바일용 주소가 상단에 나올 때가 많아 불편하다.
  • 수익 창출 방식이 네이버 애드포스트 중심으로 제한되고, 외부 광고 스크립트나 블로그 구조를 자유롭게 삽입하기 어렵다.

• Velog

  • 플랫폼 내부의 트렌딩, 추천, 최신 글 영역을 통해 글이 노출될 기회가 있다.
  • 공식 다크 모드가 없다.
  • 태그 중심의 분류 방식이 개인적으로 피곤하게 느껴졌다.

• Medium

  • 해외에서는 널리 쓰이고 글쓰기에 집중하기 좋은 플랫폼으로 평가된다.
  • 하지만 한글 글꼴과 국내 사용성 측면에서 아쉬움이 있다는 의견이 있었다.
  • 국내에서는 Medium으로 작성된 글을 자주 접하지 못했고, 비주류 플랫폼을 감수하면서까지 선택할 만한 이유를 찾기 어려웠다.

플랫폼보다 요구 사항 정리가 우선이었다

상용 블로그 플랫폼을 둘러보았지만 고민 없이 뛰어들고 싶은 선택지가 없었다.
플랫폼에 나를 맞추기보다, 내가 어떤 블로그를 원하는지 먼저 정리하기 시작했다.

시간순 정렬만으로는 학습 흐름을 담기 어렵다

대부분의 블로그는 게시물을 시간순으로 보여준다.
주제별 페이지로 글을 묶어 두더라도, 결국 그 안에서는 작성일을 기준으로 정렬되는 경우가 많다.

시간순 정렬은 글쓴이가 어떤 순서로 생각을 쌓아왔는지 보여준다는 점에서 유용하다.
하지만 읽는 사람에게 필요한 순서와 항상 일치하지는 않는다.

어떤 주제는 쉬운 글에서 어려운 글로, 개념 설명에서 실습으로, 배경지식에서 구체적인 문제 해결로 이어지는 흐름이 더 중요하다.
시간순 정렬은 글을 찾아보는 한 가지 방식일 뿐, 모든 상황에 적합하지는 않다.

정리는 타인만을 위한 일이 아니다.
시간이 지난 뒤 이 글들을 가장 자주 다시 읽을 사람은 결국 나 자신이다.
글들이 다시 찾아보기 좋은 순서로 놓여 있지 않으면, 나중에 다시 읽을 때 당시의 학습 흐름을 되살리기 어렵다.
결국 장기 기억으로도 잘 이어지지 않는다.

태그는 분류일 뿐, 읽는 순서를 만들어 주지 않는다

태그는 글을 여러 기준으로 묶을 수 있다는 장점이 있다.
글이 여러 주제에 걸쳐 있을 때 태그를 달아두면, 사용자는 같은 태그를 가진 글을 쉽게 찾아볼 수 있다.

하지만 태그는 관련 글을 모아 보여줄 뿐, 어떤 순서로 읽어야 하는지는 알려주지 않는다.
태그 페이지 안에서도 글은 대부분 시간순으로 정렬되기 때문에, 앞에서 말한 문제가 그대로 남는다.

또한 글을 쓸 때마다 어떤 태그를 달지 고민해야 한다.
시간이 지나면 js, javascript, JavaScript처럼 같은 의미의 태그가 다른 이름으로 쌓이기도 한다.
자동으로 태그를 생성하는 도구를 사용하더라도, 그 태그가 글의 내용을 잘 나타내는지 확인하는 과정은 남는다.

결국 태그를 관리하는 부담이 글쓰기의 부담으로 이어진다.

원하는 순서로 글을 배치하고 싶었다

수학 내용이 수학 책으로 묶이고 영어 내용이 영어 책으로 묶이듯이, 내 글도 주제별로 묶어 둘 공간이 필요했다.
각 주제 안에서는 단순히 작성일순으로 글을 나열하는 것이 아니라, 어떤 글을 먼저 읽고 어떤 글로 이어가면 좋을지 직접 정하고 싶었다.
나에게 필요한 것은 글의 단순한 나열이 아니라, 학습 흐름에 맞춘 큐레이션이었다.

플랫폼에 종속되고 싶지 않았다

상용 블로그 플랫폼은 편리하지만, 플랫폼의 변화에 계속 영향을 받는다.
서비스가 사라지거나 운영 정책이 마음에 들지 않는 방향으로 바뀌면, 기존 글을 백업하고 다른 곳으로 옮겨야 한다.
글쓰기 에디터나 관리 도구도 플랫폼의 업데이트에 따라 달라질 수 있고, 그 방향이 내 글쓰기 방식과 맞지 않을 수도 있다.

이런 영향을 줄이려면 글이 특정 플랫폼 안에만 갇혀 있어서는 안 된다.
내가 직접 관리할 수 있는 파일 형태로 남아 있어야, 필요할 때 원하는 방식으로 블로그를 옮기거나 고치기 쉽다.
상용 플랫폼에 글을 맡기는 일은 편리하지만, 오래 유지할 글이라면 내가 소유하고 관리할 수 있는 쪽이 더 맞다고 판단했다.
그래서 마크다운 파일을 기반으로 하는 SSG(Static Site Generator) 블로그를 직접 만들기로 했다.

시행착오

React를 이유로 Gatsby를 선택했다

마음에 드는 테마가 없으니 기존 것을 수정하는 것보다 직접 만드는 편이 빠르겠다고 판단했다.
이왕 직접 만들 거라면 프론트엔드에서 널리 사용되는 React를 익히는 기회로 삼고 싶었다.
Astro에서도 React를 사용할 수 있지만, React 기반인 Gatsby가 뭔가 더 React 친화적일 것이라는 막연한 생각으로 선택했다.

하지만 돌아보면 이 선택은 블로그에 필요한 기능보다 내가 써보고 싶은 기술을 먼저 생각한 결정이었다.
내가 만들려던 블로그는 글이 중심인 단순한 사이트였다.
상태를 관리해야 할 기능은 다크 모드 토글이나 검색창 정도였다.
대부분의 화면은 마크다운 본문을 렌더링하거나 마크다운 글 목록을 보여주는 정도면 충분했다.
React가 가진 장점을 제대로 쓸 만큼 복잡한 화면은 없었다.

스타일링에는 SCSS가 익숙했다.
styled-components는 SCSS 문법을 그대로 사용할 수 없어서 제외했다.
Tailwind CSS는 스타일이 복잡해질수록 className이 길어지는 점이 마음에 걸렸다.
특히 디자인 요구 사항이 계속 바뀌고 있어 길게 나열된 유틸리티 클래스를 지우고 다시 붙이는 일을 반복하게 될 것 같았다.
잦은 수정에는 SCSS가 더 편하다고 판단해 Tailwind CSS를 제외했다.
결국 기존에 사용하던 방식과 가장 비슷한 SCSS와 CSS Modules의 조합을 선택했다.
하지만 컴포넌트마다 .module.scss 파일이 하나씩 따라붙는 구조는 생각보다 번거로웠다.
작은 UI 하나를 수정할 때도 .jsx 파일과 .module.scss 파일을 계속 오가야 했기 때문이다.
이럴 거라면 처음부터 템플릿과 스타일, 로직을 한 파일에 작성할 수 있는 Vue를 선택하는 편이 낫지 않았을까 하는 생각도 들었다.

플러그인을 설치하는 과정도 순탄하지 않았다.
플러그인 하나를 추가하려 했는데, peer dependency 조건 때문에 설치가 막혔다.
강제로 설치해 보았지만 빌드가 되지 않았고, 해당 플러그인의 낮은 버전을 설치해도 해결되지 않았다.
결국 함께 쓰던 다른 플러그인의 버전을 낮춘 뒤에야 빌드가 통과했다.

더 신경 쓰인 것은 Gatsby에서 기능을 붙일수록 플러그인이 계속 늘어난다는 점이었다.
지금은 각 플러그인이 왜 필요한지 알고 있지만, 시간이 지나 블로그 구조를 다시 손볼 때도 그 맥락을 기억하고 있을지는 확신하기 어렵다.
일부 플러그인은 호출 순서까지 신경 써야 했다.
주석으로 맥락을 남겨 두더라도, 플러그인 업데이트로 예상하지 못한 문제가 생길 가능성은 남아 있었다.
블로그처럼 오래 유지할 도구에 이런 부담을 계속 쌓고 싶지는 않았다.

가장 크게 걸린 문제는 개발 서버의 cold start 시간이었다.
개발 과정에서 구조를 여러 차례 바꿔 구조마다 시간을 기록하지는 못했지만, 개발 서버가 20초 안에 시작된 적이 없었다.
원인을 가늠하기 위해 간단한 프로젝트를 만들어 비교해 보았다.
CLI로 생성한 기본 Gatsby 프로젝트는 시작하는 데 4초가 걸렸고, 최소한의 코드에 마크다운 파일 3,000개를 추가한 프로젝트는 13초가 걸렸다.

상용 플랫폼에서 브라우저를 열고 5초 정도면 글을 읽거나 편집 상태로 진입할 수 있다.
반면 직접 만든 블로그에서는 로컬 서버로 글을 확인하기까지 그보다 몇 배나 기다려야 하고,
이런 불편이 반복되면 블로그를 장기적으로 운영하기 어렵다고 판단했다.

그래서 다른 프레임워크를 찾아보았다.
같은 조건으로 Astro를 테스트했을 때는 마크다운 파일 3,000개가 있어도 개발 서버가 3초 안에 실행되었다.
이 차이가 충분히 크다고 판단했고, Astro로 방향을 바꾸었다.

마크다운 파일에는 글만 담고 싶었다

일반적으로 마크다운 파일 상단 프론트매터에는 title, description, slug, date, updated, category, tags 같은 메타데이터를 작성한다.
반면 티스토리 같은 상용 플랫폼에서는 제목과 본문만 작성하면 된다.
이처럼 마크다운에는 글 자체에 필요한 것만 담고, 프론트매터 같은 메타데이터를 없애면 깔끔하고 관리 대상도 사라지니 블로그 운영이 편해질 것이라 여겼다.

가장 먼저 떠올린 방법은 프론트매터를 전혀 쓰지 않고 파일 메타데이터를 활용하는 것이었다.
title은 파일명으로 대신하고, slug는 파일명에서 공백과 특수문자를 가공해 만들며, date와 updated는 파일의 생성일과 수정일을 참조하는 방식이다.
description, category, tags는 메타데이터에서 가져올 수 없지만, 애초에 사용하지 않는 기능이므로 문제되지 않았다.

하지만 파일 정보를 기반으로 하는 것은 문제가 있었다.
파일 생성일은 파일이 만들어진 시점을 나타내지만, 프론트매터의 date는 글이 발행된 시점을 나타낸다.
예를 들어 1월 1일에 파일을 만들고 며칠 동안 글을 작성한 뒤 1월 5일에 글을 완성해 발행했다면, date는 1월 5일이어야 한다.
글의 발행일을 수정하기 위해 CLI로 파일 정보를 수정하는 일은 부자연스럽다.
게다가 파일의 날짜는 복사나 압축 해제, 배포 과정에서 바뀔 수도 있다.
그래서 메타데이터 자체를 사용하지 않는 방법은 어렵다고 판단했다.

두 번째 방법은 메타데이터의 필요성은 인정하면서 파일명에 프론트매터를 넣는 것이었다.

2020_01_01_변수.md

앞의 날짜는 date, 뒤의 파일명은 title과 slug로 사용하려 했다.
그러나 한글 URL을 사용해야 한다는 점이 마음에 걸렸다.
또한 글을 날짜순이 아니라 원하는 순서대로 정렬하고 싶었다.

001_2020_01_01_변수(Variable).md

이를 위해 파일명 앞에 글 번호를 붙이고 해당 번호를 정렬 기준으로 사용했다.
title과 slug가 같으면 괄호를 생략하고, 다르면 slug를 괄호 안에 적었다.
실제로 동작하는 방식이었지만, 파일 탐색기에서 글을 찾을 때 불편했다.
VS Code의 탐색기를 항상 열어 두는데, 평소 너비에서는 파일명 15~25자 정도만 보인다.
파일명 앞부분의 글 번호와 날짜가 절반을 넘게 차지하니 title은 일부만 보이고 slug는 보이지도 않았다.
파일명에 넣은 날짜는 화면에 표시할 정보일 뿐, 파일 탐색기에서 제목으로 글을 찾을 때는 도움이 되지 않았다.
이 방식은 결국 프론트매터에서 항목별로 나누어 작성할 정보를 비좁은 파일명 하나에 억지로 넣고 있는 것이었다.

이쯤에서 프론트매터를 왜 없애려 했는지 다시 생각해 보았다.
실제로 관리하면서 불편을 겪어 출발한 문제가 아니었다.
프론트매터 없이 본문만 남긴 마크다운이 더 깔끔해 보일 것이라는 느낌과,
프론트매터는 관리하기 번거로울 것이라는 막연한 우려에서 출발했을 뿐이다.
프론트매터 작성이 번거롭다면 직접 스크립트를 만들거나 확장 프로그램을 사용해 자동화할 수도 있다.
결국 프론트매터를 작성하는 것이 가장 단순하고 명확한 방법이라는 것을 깨달았다.

파일 경로로 카테고리와 글 목록을 자동 생성했다

처음에는 프론트매터로 글의 분류와 순서를 관리하는 방법을 생각했다.
category로 주제를 나누고, order나 weight 같은 속성으로 카테고리 안에서의 정렬 순서를 정하는 방식이다.

하지만 이 방식은 글을 옮기거나 구조를 바꿀 때마다 부담이 생긴다.
예를 들어 프로그래밍 개념에 모아둔 글 중 객체지향 관련 글이 많아져 별도 카테고리로 분리하고 싶다면, 관련 글의 프론트매터를 모두 수정해야 한다.
카테고리 안에서의 정렬 순서를 바꾸는 일도 마찬가지로 번거롭다.
order를 1단위로 두면 글 하나를 삽입하거나 삭제할 때마다 값을 다시 맞춰야 한다.
그 영향을 줄이려고 처음부터 10, 20, 30처럼 간격을 두고, 수정할 때 1단위로 조정하는 방법도 있다.
하지만 시간이 지나면 29, 32처럼 깔끔하지 않은 숫자가 생기고, 관리를 위해 둔 숫자가 다시 관리의 대상이 된다.

그렇다고 목차 페이지를 수동으로 만드는 것도 피곤한 일이다.
처음에는 c, java, leetcode, baekjoon 정도로 시작하겠지만, 글이 늘어날수록 관리해야 할 페이지도 함께 늘어난다.
글을 하나 쓸 때마다 링크를 수동으로 추가하고, 분류가 바뀔 때는 목차 페이지를 두 개씩 열어놓고 링크를 옮겨야 한다면 글쓰기보다 관리 작업이 더 번거로워진다.

이 문제를 해결할 방법을 고민하던 중 한 가지 아이디어가 떠올랐다.
폴더와 파일 경로를 활용해 분류 페이지를 자동으로 생성하는 것이다.
예를 들어 blog/online judge/leet code/easy/two sum.md라는 마크다운 파일이 있다면,
해당 경로를 기준으로 다음과 같은 페이지들을 자동으로 만드는 것이다.

생성되는 경로	페이지 종류
/online-judge	카테고리 페이지
/online-judge/leet-code	카테고리 페이지
/online-judge/leet-code/easy	글 목록 페이지
/online-judge/leet-code/easy/two-sum	글 페이지

카테고리 페이지
/online-judge/leet-code

글 목록 페이지
/online-judge/leet-code/easy

이 방식의 장점은 분명했다.
폴더와 파일 경로가 그대로 블로그의 URL 구조가 되기 때문에, 폴더를 만들면 카테고리 페이지나 글 목록 페이지가 생기고 마크다운 파일을 넣으면 글 페이지가 생긴다.
주제별 목차를 따로 만들거나 프론트매터에 category를 작성할 필요도 없다.
글을 다른 주제로 옮기고 싶을 때 관리 화면이나 별도 설정을 수정하는 대신 폴더를 옮기거나 파일 위치를 바꾸면 된다.
에디터의 파일 트리에서 보이는 구조가 그대로 블로그 구조로 이어진다는 점도 직관적이었다.

하지만 구현을 마치고 동작을 확인해 보니 예상하지 못한 단점이 드러났다.

폴더 깊이를 자유롭게 조절할 수 있다는 점은 오히려 완벽한 분류 체계를 만들고 싶다는 부담으로 이어졌다.
글이 충분히 쌓이기 전에는 어떤 기준으로 나누는 것이 맞는지 판단하기 어렵다.
폴더 구조가 곧 블로그 주소가 되다 보니, 나도 모르게 글 작성보다 분류를 먼저 붙잡고 있었다.
폴더와 파일을 옮기기만 하면 언제든 바꿀 수 있는데도, 지금 당장 완성된 체계를 갖춰야 할 것 같았다.

무엇보다 분류 기준이 시간이 지나도 유지될지 확신하기 어려웠다.
지금은 왜 이 폴더를 만들고 이 글을 그 안에 넣었는지 설명할 수 있다.
하지만 글이 늘고 관심사가 바뀐 뒤에도 같은 기준이 자연스럽게 느껴질지는 알 수 없었다.
결국 몇 달 뒤의 나는 또 다른 분류를 하겠다며 폴더 구조를 다시 손보고 있을 것 같았다.

폴더 깊이가 깊어질수록 원하는 글에 도달하기까지 거쳐야 할 단계도 늘어났다.
글의 위치를 알고 있어도 빠르게 접근하기 어렵고, 기억이 흐릿해지면 결국 검색에 의존하게 된다.
그렇게 되면 폴더 구조는 탐색을 돕는 장치가 아니라, 검색으로 우회해야 하는 장애물이 된다.
애초에 검색은 보조 수단에 가까워야 한다고 생각했다.
검색이 글을 찾아가는 주된 경로가 되는 순간, 이 블로그의 구조는 제 역할을 하지 못하는 셈이었다.

결국 조화로운 지식 정원을 기대했지만, 실제로는 미로를 만드는 느낌이 들기 시작했다.
그래서 파일 경로를 기준으로 카테고리 페이지와 글 목록 페이지를 자동 생성하는 방식을 포기했다.

블로그의 기준을 다시 정하다

블로그를 직접 만드는 일이 이렇게 어려울 줄은 몰랐다.
처음에는 마크다운을 화면에 렌더링하는 단순한 것이라 생각했다.
하지만 실제로는 글을 쓰고, 확인하고, 분류하고, 나중에 다시 찾아보는 흐름 전체를 설계하는 일이었다.

돌아보면 가장 큰 문제는 전체를 충분히 그려 보지 않은 채, 대략적인 방향만 잡고 만들기 시작했다는 점이었다.
구현 중에 모호한 부분이 드러날 때마다 고민과 수정을 반복했고, 그 과정에서 이미 만든 기능을 버리거나 되돌리는 일이 생겼다.
처음부터 블로그를 어떻게 쓰고 유지할지 더 구체적으로 상상했다면 시행착오를 줄일 수 있었을 것이다.

시행착오 끝에 알게 된 것은, 내가 원하던 블로그는 복잡한 도구가 아니라는 점이었다.
나에게 필요했던 것은 더 많은 기능이나 더 정교한 분류 체계가 아니라, 오래 지속할 수 있는 단순한 흐름이었다.

이러한 기준을 바탕으로 지금의 블로그를 만들었다.

블로그 전체의 구조와 글을 읽는 순서는 blog/archive.md 하나의 목차에서 관리하기로 했다.
주제별 헤딩 아래에 글 링크를 원하는 순서로 배치하는 방식이다.
새 글은 우선 # Inbox에 쌓아 두고, 글의 역할이 분명해졌을 때만 적절한 주제와 순서로 옮긴다.
이렇게 하면 글을 쓸 때는 분류를 고민하지 않아도 되고, 나중에 블로그 전체의 흐름을 보며 목차를 정리할 수 있다.

다만 마크다운 글과 목차 파일의 프론트매터가 어긋나지 않도록 관리할 방법이 필요했다.
이 문제는 VS Code 확장 프로그램으로 해결했다.
확장 프로그램은 새 글을 생성할 때 마크다운 글에 프론트매터를 자동으로 추가하고 # Inbox에 링크를 넣는다.
이후 마크다운 글의 프론트매터를 확장 프로그램으로 수정하면 목차 파일의 링크 정보도 함께 갱신한다.

글쓰기와 정리를 의도적으로 분리한 이 구조는 글쓰기를 시작하는 부담을 줄이고, 완벽한 분류 체계에 얽매이지 않게 한다.
책은 발행되는 순간 목차가 고정되지만, 이 블로그의 목차는 글이 쌓이면서 함께 만들어진다.
그렇게 이 블로그는 점점 더 정교한 책이 되어 간다.