대학교 4학년 1학기, 취업 준비를 시작하면서 블로그를 만들었다. 이유는 단순했다. 선배가 "기술 블로그 있으면 면접에서 플러스야"라고 했다. 주변 동기들도 벨로그나 티스토리에 글을 쓰기 시작했다. 나도 안 하면 뒤처지는 것 같았다.

벨로그에 계정을 만들고 첫 글을 썼다. "JavaScript의 클로저(Closure) 정리"였다. 솔직히 다른 블로그 글 세 개를 참고해서, 내 말투로 다시 정리한 수준이었다. 클로저가 뭔지 설명하고, 예제 코드 넣고, "이렇게 사용할 수 있다"로 끝내는 전형적인 정리 글.

그 글을 쓰는 데 3시간이 걸렸다. 대부분의 시간은 "이걸 이미 설명한 글이 수백 개 있는데, 내가 왜 또 쓰지?"라는 생각과 싸우는 데 썼다.

이력서에 적을 수 있다는 동기#

처음 6개월은 오로지 취업을 위해 글을 썼다. 이력서 "기술 블로그" 칸에 링크를 넣기 위한 목적. 그래서 주제도 면접에 나올 법한 것들로 골랐다. 호이스팅, 이벤트 루프, React 생명주기, HTTP 메서드. 면접 기출 문제집을 보면서 글감을 정했다.

글의 패턴도 뻔했다. "개념 설명 → 예제 코드 → 정리"의 3단 구조. 내 의견이나 경험은 거의 없었다. 교과서를 재가공하는 느낌에 가까웠다.

그래도 효과는 있었다. 면접에서 "블로그 운영하시네요. 어떤 글을 주로 쓰시나요?"라는 질문을 받았고, "학습한 내용을 정리하면서 이해를 깊게 하려고 합니다"라고 대답했다. 면접관이 고개를 끄덕였다. 그게 합격의 결정적 요인이었는지는 모르겠지만, 마이너스는 아니었을 거다.

입사 후 글쓰기가 멈추다#

입사하고 나서 블로그를 거의 안 썼다. 취업이라는 목표가 사라지니까 동기도 사라졌다. 일이 바빴던 것도 있다. 퇴근하면 지치고, 주말에는 쉬고 싶었다. "이번 주말에는 글 써야지"를 매주 미뤘다. 한 달이 지나고, 두 달이 지나고.

벨로그 대시보드에 들어가면 마지막 글이 입사 전에 쓴 거였다. 방문자 수는 꾸준히 있었다. 클로저 글이 검색에 걸려서 하루에 20~30명이 들어왔다. 방문자가 있는데 새 글이 없다는 게 좀 찝찝하긴 했는데, 글을 쓸 에너지가 없었다.

다시 쓰기 시작한 계기#

입사 6개월 쯤, 회사에서 Next.js의 SSR과 SSG를 제대로 이해하지 못해서 삽질한 적이 있다. getServerSideProps에서 API를 호출하는데, 매 요청마다 느린 외부 API를 때려서 페이지 로딩이 3초가 넘었다. getStaticProps로 바꾸고 ISR을 적용해서 해결했는데, 이 과정에서 SSR과 SSG의 차이를 완전히 이해하게 됐다.

그날 퇴근하고 글을 하나 썼다. 이전과 다른 점은, 교과서적인 정리가 아니라 내가 겪은 문제와 해결 과정을 적었다는 거다. "이런 상황이었고, 이렇게 삽질했고, 결국 이렇게 해결했다." 글의 톤이 달라졌다. 설명이 아니라 경험담에 가까웠다.

이 글의 반응이 좋았다. 벨로그에서 "좋아요"를 30개 넘게 받았다. 댓글도 달렸다. "저도 같은 실수 했어요", "ISR 적용하니까 해결됐다는 거 도움 됐습니다" 같은 댓글. 교과서 정리 글에는 없던 반응이었다.

그때 깨달은 거다. 사람들이 읽고 싶어하는 글은 개념 정리가 아니라 경험이라는 걸. 클로저가 뭔지는 MDN에 더 잘 나와있다. 하지만 "클로저를 잘못 써서 메모리 누수가 생긴 프로덕션 사례"는 MDN에 없다.

벨로그에서 직접 만든 블로그로#

벨로그에서 한동안 글을 쓰다가, Next.js + MDX로 블로그를 직접 만들었다. 이유는 몇 가지 있었다.

첫째, 포트폴리오. 블로그 자체가 프론트엔드 프로젝트가 된다. 도메인을 사고, 배포하고, SEO를 신경 쓰고. 이 과정이 공부가 됐다.

둘째, 커스터마이징. 벨로그는 깔끔한데, 내가 원하는 대로 수정하는 데 한계가 있다. 코드 블록 스타일이나 목차 기능 같은 걸 내 맘대로 바꾸고 싶었다.

셋째, 소유권. 플랫폼이 서비스를 종료하면 글이 사라진다. 내 도메인, 내 리포지토리에 있으면 그런 걱정이 없다. MDX 파일은 마크다운이니까, 나중에 다른 프레임워크로 옮기기도 쉽다.

블로그를 직접 만드는 과정에서 배운 것도 많다. next-mdx-remote로 MDX를 파싱하는 법, rehype와 remark 플러그인으로 마크다운을 확장하는 법, 다이나믹 OG 이미지를 생성하는 법. 블로그 하나 만들면서 배우는 게 이렇게 많을 줄 몰랐다.

직접 만들어서 귀찮은 점도 있다. 벨로그는 마크다운 쓰고 발행 버튼만 누르면 끝인데, 직접 만든 블로그는 MDX 파일 작성하고, git commit하고, push하면 Vercel에서 빌드되는 방식이다. 글 하나 쓰는 데 발행까지의 마찰이 더 크다. 가끔 "그냥 벨로그에 쓸걸" 생각하는 순간도 있다. 그래도 내 블로그라는 소유감이 좋아서 계속 유지하고 있다.

글쓰기에 대한 오해#

"블로그 써야 하나요?"라는 질문을 후배한테 받은 적이 있다. 솔직한 답은 "안 써도 된다"이다. 블로그 없어도 취업할 수 있고, 좋은 개발자가 될 수 있다. 블로그는 선택이지 필수가 아니다.

다만 글쓰기가 학습에 도움이 되는 건 사실이다. 파인만 학습법이라고, 누군가에게 설명할 수 있어야 진짜 이해한 거라는 말이 있다. 블로그 글을 쓰는 건 "가상의 독자에게 설명하는" 행위다. 설명하다가 막히면 내가 모르는 부분이 드러난다.

그리고 하나 더, 글은 잘 쓸 필요 없다. 나도 처음 글들은 지금 보면 부끄럽다. 문장이 어색하고, 구조가 산만하고, 핵심이 불명확하다. 근데 그게 당연하다. 글쓰기도 코딩처럼 반복하면 나아진다. 첫 PR이 완벽하지 않듯이, 첫 글도 완벽하지 않다.

글쓰기가 주는 것#

지금 블로그를 계속하는 이유는 취업 때문이 아니다. 몇 가지 이유가 있는데, 가장 큰 건 "생각이 정리된다"는 거다.

머릿속으로는 이해한 것 같은데, 글로 쓰려고 하면 막히는 부분이 드러난다. "React의 re-render가 발생하는 조건"을 설명하려고 하면, 내가 정확히 모르는 부분이 나온다. state가 바뀔 때? props가 바뀔 때? 부모가 리렌더링될 때? Context가 변경될 때? 이걸 글로 정리하면서 빈틈을 채운다.

두 번째는 기록이다. 6개월 전에 해결한 문제를 다시 만났을 때, 블로그에서 검색하면 된다. 예전에는 슬랙에서 나한테 DM으로 코드 조각을 보내거나 메모 앱에 대충 적어놨는데, 찾기가 어려웠다. 블로그에 정리해두면 나중에 찾기 쉽고, 다른 사람도 볼 수 있으니까 일석이조다.

세 번째는 의외인데, 사람과의 연결이다. 블로그 글을 트위터에 공유했을 때 DM이 온 적이 있다. "글 잘 읽었다, 나도 비슷한 경험이 있다"는 메시지. 비슷한 고민을 하는 사람이 있다는 게 위로가 됐고, 가끔은 그게 기술적인 대화로 이어지기도 했다. 한 번은 내가 쓴 React Query 관련 글을 읽은 다른 회사 개발자가 "우리 팀에서도 비슷한 이슈가 있었는데 이렇게 해결했다"고 알려준 적이 있다. 혼자서는 절대 알 수 없었을 해결법이었다.

꾸준히 쓰는 게 어렵다#

솔직히 꾸준히 쓰는 건 여전히 어렵다. 한 달에 두세 편 쓰겠다는 목표를 세워도, 바쁜 달에는 한 편도 못 쓴다. 글 하나를 쓰는 데 짧으면 2시간, 길면 6시간이 걸린다. 개발 시간을 빼면 남는 시간이 많지 않다.

그래도 안 쓰는 것보다는 가끔이라도 쓰는 게 낫다는 걸 안다. 완벽한 글을 쓰려고 하면 영영 안 쓰게 된다. 초안이 80%면 일단 올린다. 나중에 부족한 부분이 보이면 수정하면 된다.

블로그를 시작한 이유는 이력서에 한 줄 추가하기 위해서였다. 근데 1년 반 정도 쓰다 보니, 그게 목적이었던 시기는 지났다. 지금은 그냥 쓰고 싶어서 쓴다. 생각을 정리하고 싶어서, 기록을 남기고 싶어서, 가끔은 누군가에게 도움이 됐다는 피드백이 좋아서.

다음 글 주제를 뭘로 할지 메모장에 적어뒀다. 여섯 개 정도 있다. 그 중에 실제로 쓰게 될 건 두세 개겠지. 그래도 괜찮다.