왜 이 블로그를 직접 만들기로 했나 (DevToolStack 개발기 #1)

첫 편은 시작점 이야기다. 이 블로그는 글을 쓰는 곳이면서, 그 자체가 만들어보고 싶었던 물건이었다. 앞으로 여러 편에 걸쳐 어떻게 만들었는지를 적는다.

1. 남의 플랫폼으로는 되는 게 없었다

1.1 처음 세운 설계를 버렸다

처음 생각은 단순했다. 구글 블로거에 API로 글을 밀어 넣으면 되지 않을까. 호스팅도 공짜고, 애드센스도 붙어 있고, 만들 게 거의 없었다.

1.2 적어보니 열일곱 개였다

그런데 하고 싶은 걸 하나씩 적어 내려가다 보니 전제가 무너졌다. 적다 보니 기능 요구사항만 열일곱 개가 나왔다.

여기에 비기능 요구사항이 아홉 개 더 붙었다. 월 0원에 최대한 가깝게, 맥북이 꺼져 있어도 블로그는 살아 있게, 광고가 뜰 때 본문이 밀리지 않게 같은 것들이다.

다 적고 나니 답이 나왔다. 하고 싶은 것의 대부분이 "발행" 바깥에 있었다. 블로거가 열어주는 건 마지막 한 칸이고, 나머지 열여섯 칸은 손댈 수 없는 자리였다.

글 생성 과정도 마찬가지였다. AI로 글을 무분별하게 찍어내는 블로그로 만들고 싶지 않았고, 직접 개발하고 실험한 내용을 생생하게 담으려면 초안을 다듬는 과정에 내가 계속 개입해야 했다. 게다가 운영 비용을 아끼려면 AI는 구독형이 아니라 쓴 만큼 내는 종량제로 붙여야 했는데, 이 호출과 검수를 블로거 안에서 처리할 방법이 없었다. 결국 글감 정리부터 초안 생성, 수정, 발행까지를 오가는 별도의 어드민 서버가 있어야 한다는 결론에 닿았다.

처음에는 채팅으로 그때그때 요청하고 답을 받아 기능을 붙이는 식으로 개발을 진행했다. 그렇게 쌓다 보면 구조가 얽혀서 결국 프로젝트를 통째로 갈아엎는 일이 반복됐다. 이후 바이브 코딩 관련 자료를 찾아보면서 개발 워크플로우 자체가 중요하다는 걸 알게 됐고, 기획과 요구사항 정리, 설계, 검토 과정에 충분히 시간을 쓴 뒤 개발에 들어가는 편이 결과적으로 더 효율적이라는 걸 깨달았다. 이 부분은 2편 "코드보다 디자인 시안을 먼저 만든 이유"에서 더 자세히 다룬다.

요구사항을 먼저 끝까지 적어보는 것만으로 설계 하나가 갈렸다는 게 이 프로젝트에서 처음 배운 것이다.

2. 왜 직접 만들기로 했나

2.1 만든 것을 알리는 창구도 필요했다

이유가 하나 더 있었다. 그동안 앱이나 프로그램, 웹사이트를 만들어 왔는데 만들어 놓고 끝나는 경우가 많았다. 어딘가에 정리해 두지 않으니 나중에 나조차 무엇을 어떻게 만들었는지 다시 찾기 어려웠다.

개발 과정을 글로 남기면 두 가지가 동시에 해결된다. 기록이 남고, 그 글을 타고 들어온 사람이 만든 물건을 보게 된다. 블로그가 개발 노트이면서 동시에 내가 만든 것들의 진열창이 되는 셈이다.

이건 광고 수익과는 별개의 목적이다. 그리고 이쪽이 더 오래 갈 이유라고 생각한다.

AI를 쓰기로 한 이상 이 문제도 짚고 넘어가야 했다. 글감 정리나 초안 작성까지 AI에게 맡기고 그대로 발행하면 애드센스 정책에서 요구하는 수준의 콘텐츠가 되지 않을뿐더러, AI가 틀린 내용을 그럴듯하게 써놓으면 나조차 모르고 넘어갈 수 있다. 그래서 AI는 초안을 잡는 데까지만 쓰고, 그 내용이 맞는지는 내가 직접 확인한 뒤 실제로 겪은 과정과 삽질을 더해서 올리기로 했다.

2.2 무엇에 대해 쓸 것인가

주제를 정할 때 경쟁 강도나 검색량을 따져볼 수도 있었다. 어떤 분야가 이미 포화인지, 어떤 키워드가 비어 있는지 같은 것들이다.

그렇게 정하지 않기로 했다. 내가 만들고 싶은 것에 집중하기로 했다.

이유는 단순하다. 검색이 잘 되는 주제를 골라봤자 내가 흥미 없는 분야면 글이 안 나온다. 억지로 몇 편 쓰다가 멈춘 블로그를 만들고 싶지는 않았다. 반대로 내가 실제로 만들고 있는 것에 대해 쓰면, 글감은 개발하는 동안 저절로 생긴다.

그래서 인프라, 자동화, 개발 도구 쪽으로 방향만 잡고 시작했다. 내가 손대고 있는 것들이 그쪽이기 때문이다.

3. 비용을 최소화하려니 설계가 정해졌다

예산은 "월 얼마까지"가 아니라 **"가능한 한 0원"**으로 잡았다. 취미로 시작하는 일에 고정비가 붙으면 부담이 생기고, 부담이 생기면 그만두게 된다.

이 한 줄이 나머지를 거의 다 결정했다.

• 서버비를 안 내려면 → 블로그는 정적 사이트여야 한다
• 그래도 편집기와 대시보드는 필요하다 → 어드민은 집에 있는 맥북에서 돌린다
• AI에 종량제 요금을 안 내려면 → 이미 쓰고 있는 구독을 그대로 쓴다
• 맥북에 있는 어드민을 밖에서 쓰려면 → 터널로 뚫고 앞을 막는다

제약이 선택지를 줄여준 셈이다. 도메인도 이때 샀다. devtoolstack.bid — 저렴해서 골랐다.

4. 그리고 명백히 틀린 결정을 했다

AI는 구독을 쓰기로 했으니 추가 비용이 없다. 그러면 매일 새벽에 자동으로 돌려서 하루 한 편씩 쌓으면 되겠다고 생각했다. 설계 문서에도 그렇게 적었다.

이 결정은 나중에 뒤집힌다. 이유는 단순했다. 내가 글을 쓰지도 않는 날에 AI가 혼자 돌면서 사용량만 깎아먹고 있었던 것이다. 지금 이 블로그의 AI는 내가 버튼을 누를 때만 움직인다.

왜 그렇게 바뀌었는지는 5편에서 쓴다.

5. 노린 것은 순환 효과다

2.1에서 블로그가 진열창도 된다고 적었는데, 정확히 말하면 한 방향이 아니라 고리다.

만들다 보면 막힌다. 막힌 걸 고치면서 알게 된 것이 생긴다. 그게 글감이다. 지어낼 필요가 없다 — 이미 겪었으니까.

그 글은 같은 에러 메시지를 검색창에 넣어 본 사람에게 닿는다. 그렇게 들어온 사람은 글만 보고 나가지 않는다. 글 옆에서 내가 실제로 만들어 내놓은 앱을 보게 된다.

그리고 앱을 하나 더 만들면 또 막히고, 또 쓸 것이 생긴다.

flowchart TD
  dev["앱·도구를 만든다"] --> stuck["막히고, 고친다"]
  stuck --> post["배운 것을 글로 남긴다"]
  post --> search["같은 문제로 검색한 사람이 들어온다"]
  search --> show["만들어 둔 앱이 눈에 띈다"]
  show -->|다시| dev

이 고리에서 광고는 곁다리다. 고리가 돌기만 하면 광고 수익이 0원이어도 기록과 홍보는 남는다. 반대로 고리가 안 돌면 광고를 붙여봤자 볼 사람이 없다.

6. 앞으로 쓸 것

잘 된 것만 적지는 않을 생각이다. 되돌린 결정과 막혔던 지점이 사실 더 쓸 만한 이야기다.