개발자 블로그 만들기, 크몽 문의 0건 보고 미루던 걸 하루 만에 끝낸 이유

크몽에 서비스를 올려두고 한참을 기다렸는데 문의가 하나도 안 왔어요. 개발자 블로그 만들기는 몇 달 전부터 “해야지” 하고 미뤄둔 일이었는데, 결국 그 무반응이 저를 다시 이 일 앞에 앉혔어요. 오늘 글은 그 이야기예요. 왜 지금 블로그를 만들었는지, 그리고 미루던 걸 어떻게 하루 만에 끝냈는지.

사업자를 낸 지 한 달 조금 넘었어요. 외주로 생계를 버티면서 제 서비스를 준비하는 구조로 가기로 했고, 그래서 크몽에 SSL 인증서 설치, 홈페이지와 서버 이전 같은 상품을 하나씩 올렸어요. 유입 경로를 늘려보겠다고 상품 수도 늘렸고요. 그런데 결과는 조용했어요. 너무 조용해서 이런 생각까지 들더라고요. 나는 돈 버는 방법을 모르는 사람인가.

크몽 외주 문의가 없을 때 처음 든 생각

솔직히 처음엔 원인을 찾고 싶었어요. 뭐가 문제인지 알면 고치면 되니까요. 그래서 크몽 판매자 화면을 뒤졌는데, 제가 원하는 정보가 없었어요. 내 상품이 검색에 몇 번 노출됐는지, 몇 번 클릭됐는지 같은 숫자를 볼 수가 없더라고요. 노출이 안 되는 건지, 노출은 되는데 안 눌리는 건지, 눌리는데 문의로 안 이어지는 건지. 셋 중 어디가 막혔는지 모르니 뭘 고쳐야 할지도 모르는 상태였어요.

AI한테 이 상황을 털어놨더니 이런 답이 왔어요. 리뷰가 0개인 신규 판매자는 플랫폼 안에서 거의 안 보이는 게 정상이고, 지금은 팔았는데 안 팔린 게 아니라 아직 진열대에 안 올라간 상태에 가깝다고요. 로그아웃 상태로 고객이 칠 법한 검색어를 직접 넣어보고 내 상품이 몇 페이지에 나오는지 확인해보라는 말도 덧붙였고요. 맞는 말이었어요. 그런데 동시에 이게 얼마나 불리한 구조인지도 선명해졌어요. 고객이 판매자를 고르는 시장에서 리뷰 없는 사람은 고를 이유가 없거든요.

주변에서 일을 받아오는 방법도 생각해봤어요. 예전 회사와 가끔 외주 협업을 하니까 거기서 넘치는 일을 받아볼까 했는데, 거기도 일감이 넘치는 상황은 아니었어요. 기댈 데가 하나씩 지워지는 느낌이었어요.

돌아보면 플랫폼 외주의 가장 큰 약점은 쌓이지 않는다는 거예요. 크몽에 상품을 몇 개 올리든, 그 상품이 보이느냐 마느냐는 플랫폼 안의 순위가 정해요. 제가 오늘 한 노력이 내일의 노출로 이어진다는 보장이 없어요. 반대로 검색으로 들어오는 글은 한 번 써두면 계속 남아요. 오늘 쓴 글이 석 달 뒤에 누군가의 검색어에 걸려서 문의가 될 수도 있어요. 속도는 느려도 방향은 쌓이는 쪽이죠.

외주 시장이 죽은 건지, 내가 잘못 사는 건지

그러다 결국 이 말이 튀어나왔어요. 이 시장 외주가 다 죽은 것 같다. 이렇게 사는 게 맞나.

이 감각이 완전히 틀린 건 아니라고 생각해요. 요즘은 AI로 누구나 웬만한 건 직접 만들어요. “홈페이지 하나 만들어주세요” 같은 단순한 외주는 확실히 설 자리가 줄고 있고, 단가도 체감상 많이 내려왔어요. 저처럼 에이전시에서 일하다 나온 사람이 제일 먼저 느끼는 변화이기도 하고요.

그런데 곰곰이 따져보니 “외주가 죽었다”와 “내가 잘못 살고 있다”는 전혀 다른 문장이었어요. 앞의 건 시장 이야기고, 뒤의 건 제 선택 이야기예요. 시장이 바뀌는 건 제가 어쩔 수 없지만, 그 시장에서 제가 어디에 서 있을지는 고를 수 있잖아요.

그리고 한 가지가 눈에 들어왔어요. 저는 지금까지 남이 만든 진열대에만 물건을 올리고 있었어요. 크몽이라는 플랫폼의 알고리즘이 저를 보여줄지 말지 결정하는 구조요. 거기선 제가 할 수 있는 게 거의 없어요. 노출 숫자조차 안 보여주니까요. 이 구조를 벗어나려면 제 진열대가 하나는 있어야 했어요. 제가 쓴 글이 검색으로 사람을 데려오고, 그 사람이 저를 알고 문의하는 경로. 그게 개인 블로그였어요.

개발자 블로그 만들기를 계속 미뤘던 진짜 이유

사실 저는 예전부터 자기 도메인으로 블로그를 운영하는 개발자들을 동경했어요. 플랫폼에 기대지 않고 자기 주소에 자기 글을 쌓아가는 사람들. 그래서 블로그를 하겠다는 결정 자체는 한참 전에 했어요. 애드센스 수익보다는 유입과 문의 경로를 만드는 게 목적이었고요.

근데 안 했어요. 하겠다 해놓고 계속 안 하고 있었어요.

이유를 뜯어보면 두 개였어요. 첫 번째는 글쓰기 자체가 부담이었다는 거예요. 매번 직접 긴 글을 쓴다고 생각하면 시작하기 전부터 지쳤어요. 두 번째가 더 컸는데, 기존 사이트 구조로는 블로그를 붙일 수가 없었어요. 제 메인 사이트는 블로그를 염두에 두고 만든 구조가 아니라서, 거기에 글을 얹으려면 뜯어고쳐야 했거든요.

그래서 서브도메인을 떠올렸는데, 여기서 또 막혔어요. 예전에 운영하던 서브도메인들이 검색엔진에 아예 안 잡혔던 기억이 있었거든요. 그러면 블로그 하나 하려고 도메인을 새로 사야 하나, 비용이 들더라도 하나하나 도메인을 붙여야 하나. 이런 고민을 하다 보면 글은 0개인 채로 또 하루가 지나갔어요.

이거 개발자라면 한 번쯤 겪어봤을 거예요. 글 쓰는 게 아니라 글 쓸 환경을 만드는 데서 멈추는 거요. 개발자 블로그 만들기가 어려워서가 아니라, 만드는 방법을 너무 많이 알아서 고르다 지치는 거예요. 서버를 직접 세울 수도 있고 프레임워크를 새로 짤 수도 있으니, 선택지가 많은 게 오히려 발목을 잡아요.

서브도메인은 검색이 안 된다는 오해

결론부터 말하면 도메인을 새로 살 필요는 없었어요. 서브도메인도 검색엔진에 정상적으로 잡혀요. 제가 겪은 “검색이 안 된다”는 현상은 서브도메인 자체의 문제가 아니었을 가능성이 컸어요.

구글은 서브도메인을 본 도메인과 분리된 별도 사이트처럼 다뤄요. 그래서 서치콘솔에서도 서브도메인은 따로 인증하고 따로 성과를 봐야 한다고 구글의 존 뮐러가 설명한 적이 있고, Search Engine Journal이 이 내용을 정리해뒀어요. 등록을 안 해두면 검색엔진 입장에선 존재를 알 길이 느린 거죠. 여기서 등록 방식도 중요했어요. Search Console 고객센터 설명을 보면 URL 접두사 속성은 입력한 프로토콜과 주소로 시작하는 URL만 포함하고, 도메인 속성은 모든 하위 도메인과 프로토콜을 한 번에 포함해요. 대신 도메인 속성은 DNS로 소유권을 확인해야 하고요. 그러니까 메인 도메인을 URL 접두사 방식으로만 등록해뒀다면, 그 아래 서브도메인은 구글 입장에서 아무도 알려주지 않은 사이트가 되는 거예요. 제 DNS는 Cloudflare에서 관리하고 있어서 TXT 레코드 하나만 추가하면 도메인 속성으로 전부 묶을 수 있었어요. 서브도메인을 몇 개를 더 만들든 따로 등록할 필요가 없어지는 셈이죠. 한국 검색 유입을 생각하면 네이버 서치어드바이저에도 사이트를 등록하고 사이트맵과 RSS를 제출해야 하고요.

두 번째 의심은 렌더링 방식이었어요. 저는 평소에 React 계열로 서비스를 만드는 일이 많아서, 서브도메인에 올린 것 중에 브라우저에서 자바스크립트가 돌아야 내용이 채워지는 방식이 섞여 있었다면 그것도 원인이 될 수 있었거든요. 구글의 자바스크립트 SEO 기본 문서를 보면, 구글은 이런 페이지를 렌더링 대기열에 넣었다가 나중에 자바스크립트를 실행해서 내용을 읽어요. 이 대기가 몇 초일 수도 있지만 더 길어질 수도 있다고 적혀 있고, 모든 봇이 자바스크립트를 실행하는 건 아니라서 서버 렌더링이나 사전 렌더링이 여전히 좋은 선택이라고 권하고 있어요.

그러니까 블로그는 처음부터 완성된 HTML로 떨어지는 정적 사이트로 만들면 이 문제를 통째로 피할 수 있어요. 서브도메인이냐 하위 경로냐보다 이게 훨씬 결정적이었던 거죠.

서브도메인과 /blog 같은 하위 경로 중에 뭘 고를지도 고민했어요. 이론적으로는 하위 경로가 메인 도메인에 점수를 모아준다는 장점이 있어요. 근데 제 메인 사이트는 아직 쌓아둔 권위랄 게 크지 않아서 나눠질 것도 별로 없었어요. 반면 서브도메인은 기존에 쓰던 구조와 똑같고, 경로 설정 때문에 링크가 깨질 걱정도 없었죠. 지금 제게 제일 큰 위험은 SEO 효율이 아니라 세팅하다 또 멈추는 거였어요. 그래서 blog.dddiwbsy.com으로 갔어요.

Astro 테마 고르고 Cloudflare로 띄우기까지

블로그 엔진은 Astro로 정했어요. 기본이 정적 사이트 생성이라 빌드하면 완성된 HTML이 나오니까, 위에서 말한 렌더링 문제와 거리가 멀어요. 테마는 처음에 뉴스레터용 테마를 봤다가, 글이 “몇 호” 단위로 번호가 매겨지는 구조라 개발 블로그와는 결이 안 맞아서 접었어요. 대신 고른 게 Monograph예요. 에세이와 개발자 블로그를 위한 텍스트 중심의 미니멀 테마라고 소개돼 있고, 사이트맵, RSS, robots.txt, 구조화 데이터 같은 SEO 기본기가 처음부터 들어 있어요. 코드 블록 하이라이팅과 복사 버튼, 문의 폼도 기본 포함이라 제 목적과 딱 맞았어요. 라이트와 다크 모드 전환, 키보드로 여는 검색창, 탭으로 나뉜 코드 예시 같은 것도 들어 있어서, 기술 글을 쓸 때 따로 손볼 게 거의 없어요.

테마를 고를 때 제가 세운 기준은 하나였어요. 개발자 블로그 만들기에서 테마는 오래 붙잡을수록 손해라는 것. 예쁜 테마를 찾아 헤매는 시간은 글 한 편을 쓰는 시간보다 훨씬 길어지기 쉬워요. 그래서 개발 글에 필요한 기능이 기본으로 들어 있는지만 보고, 두 번째로 본 테마에서 멈췄어요. 폰트와 사이트 정보, 샘플 글 정리 같은 손질은 이 글을 쓰는 동안 따로 돌리기로 했고요.

배포는 원래 제가 늘 하던 방식대로 하려고 했어요. 서버에 nginx 설정 추가하고 인증서 붙이는 거요. 손에 익은 방식이긴 한데, 글 하나 올릴 때마다 빌드하고 서버에 올리는 과정이 또 하나의 문턱이 될 것 같았어요. 그래서 이번엔 Cloudflare로 세팅해보기로 했어요. 제 도메인 DNS가 이미 Cloudflare에 있어서 연결할 게 거의 없었거든요.

여기서 한 번 헷갈린 게 있어요. Pages로 만든다고 들어갔는데 화면에 배포 명령으로 npx wrangler deploy가 떠 있더라고요. 알고 보니 Cloudflare가 호스팅을 Workers 중심으로 합치는 흐름이라 이 화면이 Workers 쪽 설정이었어요. Astro 공식 배포 문서도 지금은 Workers 기준으로 안내하고 있고요. 되돌아갈 필요는 없었고, 레포 루트에 설정 파일 하나만 추가하면 정적 사이트로 그대로 돌아가요.

{
  "name": "dddiwbsy-blog",
  "compatibility_date": "2026-09-29",
  "assets": {
    "directory": "./dist",
    "not_found_handling": "404-page"
  }
}

빌드 결과물 폴더를 정적 파일로 서빙하라는 설정이에요. 정적 사이트라면 Astro용 Cloudflare 어댑터는 설치할 필요가 없다고 Cloudflare 공식 문서에도 나와 있어요. 빌드할 때 모든 페이지가 미리 만들어지니 그 결과물만 올리면 되거든요. 괜히 “Cloudflare에 올린다”는 말만 보고 어댑터를 깔면 서버 렌더링 모드로 바뀌어버리니 조심해야 해요.

빌드 명령은 npm run build, 배포 명령은 기본값 그대로 두고 배포를 눌렀어요. 성공하고 나서 커스텀 도메인에 blog.dddiwbsy.com을 넣으니 DNS와 SSL이 알아서 잡혔어요. 몇 달을 미룬 일이 하루 안에 끝났어요. 허무할 정도로요.

이렇게 해두면 글을 올리는 흐름이 단순해져요. 마크다운 파일 하나를 콘텐츠 폴더에 넣고 GitHub에 push하면, Cloudflare가 저장소 변경을 감지해서 빌드하고 배포까지 알아서 해요. Astro 공식 배포 문서도 push할 때마다 자동으로 빌드와 배포가 돌아가게 구성하는 방식을 안내하고 있어요. 서버에 접속할 일도, 파일을 올릴 일도 없어요. 제가 nginx 대신 이 방식을 고른 이유가 바로 이거예요. 글 하나 올리는 데 드는 동작이 줄어들수록 계속 쓸 확률이 올라가니까요.

개발자 블로그 만들기는 끝이 아니라 입구

지금 블로그엔 테마에 들어 있던 영어 샘플 글이 그대로 있어요. 정리하고 나서 검색엔진에 등록할 생각이에요. 더미 글이 먼저 색인되면 첫인상이 꼬이니까요. 그리고 이 글이 샘플을 밀어내고 들어갈 첫 번째 진짜 글이 될 거고요.

순서도 정해뒀어요. 샘플 글을 전부 지우고 사이트 이름과 설명, 한글 폰트, 카테고리를 제 것으로 바꾼 다음, 이 글을 올려요. 그다음에 구글은 도메인 속성으로 한 번에 묶고, 네이버 서치어드바이저에는 블로그 주소를 사이트로 등록한 뒤 사이트맵과 RSS 주소를 제출할 거예요. 테마가 빌드할 때 사이트맵과 RSS를 알아서 만들어주니 따로 만들 건 없어요. 등록을 먼저 해버리고 싶은 마음도 있었는데, 검색엔진이 처음 보는 모습이 영어 더미 글이면 그것도 손해라서 참았어요.

돌이켜보면 개발자 블로그 만들기를 미룬 이유는 기술이 아니었어요. 서브도메인도, 테마도, 배포도 막상 해보니 하루 거리였어요. 진짜 문제는 “완벽한 구조를 먼저 갖춰야 시작할 수 있다”는 생각이었어요. 이것만 내려놓으면 개발자한테 블로그는 제일 빨리 만들 수 있는 채널이에요.

글쓰기 부담은 방식을 바꿔서 풀기로 했어요. 혼자 빈 화면 앞에 앉아서 쓰는 대신, 실제로 겪은 일과 판단을 이야기하듯 풀어내고 그걸 AI와 함께 글로 정리하는 방식이요. 대신 경험은 제가 겪은 것만, 정보는 확인한 것만 쓴다는 원칙은 지킬 거예요. 이 블로그의 가치는 결국 거기서 나오니까요.

앞으로는 이런 걸 쓸 생각이에요. 서버, 도메인, SSL, 배포처럼 제가 실제로 부딪히며 해결하는 것들. 그리고 AI로 누구나 서비스를 만드는 시대에, 만든 걸 실제로 굴러가게 만드는 일. 외주 시장이 줄어드는 건 맞지만, 만들어진 것들이 늘어나는 만큼 그걸 제대로 띄우고 고치는 일은 오히려 늘어날 거라고 보고 있어요. 이 블로그가 그 일을 찾는 사람과 저를 연결해주는 입구가 됐으면 해요.

크몽 문의 0건이 준 교훈은 이거였어요. 남의 진열대에서 기다리기만 하면 제 차례는 안 와요. 그래서 제 진열대를 하나 세웠고, 오늘 첫 물건을 올려요.