블로그를 만들고 싶었던 게 아니라, 잘 만든 블로그를 갖고 싶었던 거였다
2분 읽기
최근에 개인 블로그를 하나 만들었다. 직접 호스팅하고, 구조를 잡고, 운영까지 전부 내가 관리하는 형태다.
사실 처음은 아니다. 돌아보면 블로그를 만들려는 시도는 두세 번 정도 있었고, 매번 비슷하게 시작했다가 흐지부지 끝났다.
세 번의 시도
처음은 2021년 즈음, Jekyll 기반의 정적 블로그였다. GitHub Pages와 연동해 쉽게 배포할 수 있었고, 기술적으로도 크게 어렵지 않았다. 하지만 취향이 확고한 게 문제였다. 마음에 들지 않는 부분이 보이면 고쳐야 직성이 풀렸고, 그게 반복되다 보니 글을 쓰기도 전에 지쳐버렸다.
다음은 노션이었다. 가볍게 시작할 수 있었고, 구조도 깔끔해서 글 쓰는 데 집중하기엔 좋은 도구였다. 하지만 계정을 정리하던 중 노션에도 손을 댔고, 실수로 워크스페이스를 통째로 날려버렸다. 뒤 이야기는 굳이 적지 않겠다. 꽤 마음이 아팠다. 그 일을 겪은 이후로, 자식(?)같은 데이터들을 플랫폼에 맡기는 게 불안하게 느껴졌다.
2023년쯤에는 블로그를 직접 만들려고 했다. 당시 많은 개발자들이 블로그를 만들고 글을 공유하고 있었고, 나 역시 그 경험이 부러웠고 직접 해보고 싶었다. 단순히 블로그를 갖는 것이 아니라, 블로그를 구축하는 전체 사이클을 경험해보고 싶었다. 문제는 방향성이었다. 잘 만들고 싶다는 생각만 있었지, 어디까지 만들면 끝인지에 대한 기준이 없었다. 결국 만들다가 멈췄다.
이후에는 GitHub 레포지토리에 마크다운으로 글을 쓰며, 글 쓰는 행위 자체에만 집중하려고 했다. 그러다 보니 자연스럽게 블로그에 대한 생각도 멀어졌다.
접근 방식을 바꿨다
몇 번이나 멈췄지만 다시 한 번 블로그를 만들었다.
이전과 가장 크게 달라진 점은 접근 방식이었다. 이번에는 Claude Code의 Superpowers를 적극적으로 활용했다. 단순히 코드를 대신 작성하는 도구가 아니라, 설계를 함께 고민하는 파트너처럼 활용했다.
그리고 무엇보다, 바로 코드를 치던 습관을 의도적으로 미뤘다.
페이지 구조, 코드 품질, 테스트, 배포 방식 같은 것들을 대충이 아니라 끝까지 구현할 수 있는 수준으로 정리했다. 특히 이번에는 HTML 형식의 와이어프레임을 요청해 브라우저에서 검토하는 과정까지 포함했다.
결국은 Divide and Conquer
작업 방식도 바꿨다.
예전에는 “블로그 만들기”를 하나의 목표이자 큰 작업으로 봤다면, 이번에는 여러 phase로 나눠서 접근했다.
- 최소 구조 만들기
- 글 작성 및 렌더링
- 배포와 호스팅
- 이후 개선
각 단계마다 여기까지 하면 끝이라는 기준을 두니 진행이 훨씬 명확해졌다.
일단 구성하고 완성한 뒤에 개선하자는 생각을 기준으로 삼았다. 잘 만드는 것? 마음에 드는 결과를 만드는 것? 그건 다음 문제였다.
먼저 필요한 구조와 시스템을 만들고 배포까지 하나의 사이클을 완성하는 데 집중했다. 결과적으로 코드 작성 단계에서는 이미 방향이 정해져 있었기 때문에 훨씬 단순하게 진행할 수 있었다.
이번에 느낀 것
개발 이야기를 하다 보니 사뭇 진지해졌다. 돌이켜보면 나는 블로그를 만들고 싶었던 게 아니라, '잘 만든' 블로그를 갖고 싶었던 것 같다. 완성 기준은 높고 모호하니, 하다가 지쳐서 냅다 누워버리곤 했다.
이번에는 '잘'은 기대하지도 않았다. 계획대로 완성하는 것 자체가 목표였고, 박명수의 말마따나 '중꺾그마' 중요한 건 꺾였는데도 그냥 하는 마음이었다.
개발을 시작한 지도 어느덧 5년 차가 되어간다. 서당개도 3년이면 풍월을 읊는다는데, 이제는 잘하려고 애쓰기보다 해봤던 것들을 끝까지 적용해보는 게 더 중요하다고 느낀다.
나만 그런지는 모르겠지만, 어딘가 비슷한 경험을 하는 사람도 있지 않을까 싶어서 실패담을 자세히도 남겨봤다.
관련 글
6분 읽기
무엇이 탁월한 개발자를 만드는가: 자가 점검해 보기
탁월한 엔지니어의 다섯 가지 핵심 역량을 정리하고, 주니어·프론트엔드 개발자의 관점에서 스스로를 점검한 기록입니다.