기술 블로그를 운영하면서 가장 큰 고민은 “어떻게 하면 꾸준히 양질의 글을 쓸 수 있을까"입니다. 특히 다국어로 콘텐츠를 제공하고 싶다면 번역까지 신경 써야 하니, 부담이 배로 늘어나죠.

/dev/write는 이런 고민에서 시작했습니다. Hugo 정적 사이트 생성기에 GitHub Copilot을 결합해서, 글쓰기에만 집중할 수 있는 환경 을 만들어봤습니다.

왜 또 블로그 시스템인가?

솔직히 말하면, 기존 블로그 플랫폼들도 충분히 좋습니다. Medium, velog, 티스토리 모두 훌륭한 선택지예요. 하지만 몇 가지 아쉬운 점이 있었습니다.

첫째, 다국어 지원 입니다. 한국어로 쓴 글을 영어와 일본어로도 제공하고 싶었는데, 대부분의 플랫폼에서는 별도 계정이나 복잡한 설정이 필요했습니다.

둘째, AI 학습 데이터로 사용되는 것에 대한 우려 입니다. 열심히 쓴 글이 동의 없이 AI 모델 학습에 사용되는 건 썩 유쾌하지 않더라고요.

셋째, 자동화된 워크플로우 입니다. 글을 쓰고, 검토하고, 번역하고, 발행하는 과정을 최대한 자동화하고 싶었습니다.

그래서 Hugo + PaperMod 테마를 기반으로, 이 세 가지를 해결하는 시스템을 직접 만들었습니다.

GitHub Copilot과 함께 글쓰기

/dev/write에서 가장 재미있는 부분은 GitHub Copilot을 글쓰기 도구로 활용하는 방식입니다. VS Code에서 / 명령어를 입력하면 다양한 프롬프트를 호출할 수 있어요.

/create-draft Docker 컨테이너 네트워킹에 대해 써줘

이렇게 주제만 던져도 되고, 좀 더 구체적으로 개요를 제공할 수도 있습니다.

/create-draft
- 주제: Kubernetes 입문
- 다룰 내용: Pod, Service, Deployment 개념
- 대상 독자: Docker는 아는 개발자

기존에 작성해둔 README나 문서가 있다면, 그걸 기반으로 튜토리얼을 만들어달라고 할 수도 있어요.

/create-draft 이 README 파일을 기반으로 튜토리얼 포스트를 만들어줘
#file:README.md

AI가 전부 쓰는 게 아니에요

물론 AI에게 처음부터 끝까지 맡기는 것만이 답은 아닙니다. 오히려 내가 먼저 초안을 쓰고, AI가 살을 붙이는 방식 이 더 좋은 결과를 내는 경우가 많아요.

예를 들어, 예전에 다른 블로그에서 썼던 글을 가져와서 기술 블로그 스타일로 다시 정리하고 싶다면:

/complete-manual-post 이 글을 기술 블로그 스타일로 다시 써줘
#file:my-old-post.md

직접 쓴 초안이 있다면, 코드 예제를 추가하거나 설명을 보강해달라고 할 수도 있습니다.

내가 쓴 이 초안을 기반으로 내용을 더 풍부하게 만들어줘.
코드 예제를 추가하고, 설명을 더 자세하게 해줘.
#file:2025-12-05-my-draft.md

개인적인 경험이나 의견이 중요한 글, 기술적 정확성을 직접 검증하고 싶은 글은 이 방식이 훨씬 효과적입니다. AI는 도우미일 뿐, 최종 판단은 사람이 하는 거니까요.

글 하나 쓰면 세 개가 나온다

/dev/write의 또 다른 특징은 자동 번역 입니다. 한국어로 글을 쓰면 영어와 일본어 버전이 자동으로 생성됩니다.

물론 기계 번역의 한계는 있습니다. 하지만 처음부터 세 개 언어로 글을 쓰는 것보다는 훨씬 낫죠. 번역된 결과를 검토하고 필요한 부분만 수정하면 됩니다.

번역 과정에서 일관성을 유지하기 위해 몇 가지 규칙이 있어요.

  • slug, translationKey, date 같은 메타데이터는 모든 언어에서 동일하게 유지
  • 제목, 태그, 요약, 본문은 각 언어로 번역
  • 코드 블록은 번역하지 않음 (당연하죠!)

영어는 American English로, 일본어는 です/ます체로 작성됩니다. 기술 용어는 원어를 유지하거나 괄호로 병기해요. “컨테이너(Container)” 이런 식으로요.

번역이 끝나면 검증 스크립트로 세 언어 버전이 제대로 맞춰졌는지 확인합니다.

.\scripts\validate-translations.ps1

기술 문서의 정확성 검증

기술 블로그에서 가장 중요한 건 정확성 입니다. 특히 Azure나 .NET 같은 Microsoft 기술을 다룰 때는 공식 문서와 일치하는지 확인하는 게 필수죠.

/dev/write는 MS Learn MCP 서버 를 통해 이 과정을 자동화했습니다. mcp.json 파일에 MCP 서버를 등록해두고 이를 사용하도록 했습니다.

MCP 서버가 Microsoft 공식 문서를 조회해서 최신 API 버전인지, deprecated된 기능은 없는지, 공식 권장 사항과 맞는지 검토해줍니다. 블로그 글에 “이 방법은 더 이상 권장되지 않습니다"라는 댓글이 달리는 걸 미리 방지할 수 있어요.

예약 발행을 구현했다가 철회한 이유

초기에는 미래의 date 값과 GitHub Actions cron을 조합해 예약 발행을 구현했어요. 하지만 실제로 운영해보니 GitHub Actions가 지정한 시각에 정확히 시작되지는 않았습니다. 러너 대기열과 서비스 상황에 따라 발행 시각이 늦어질 수 있었어요.

정적 사이트의 공개 방식도 예약 발행과 잘 맞지 않았습니다. Hugo가 미래 글을 목록과 빌드 산출물에서 제외할 수는 있지만, 공개 Git 저장소가 서버 인증이나 비공개 콘텐츠 보관 기능을 제공하는 건 아니니까요.

그래서 예약 발행 기능을 철회했습니다. 이제 date에는 미래 시각을 쓰지 않고, 세 언어의 draft를 false로 바꾼 커밋을 main에 반영할 때 글을 발행합니다. 정확한 시각과 발행 전 접근 제어가 필요하다면 해당 기능을 제공하는 게시 플랫폼을 선택하는 편이 맞다고 판단했어요.

AI 크롤러 공개 정책

/dev/write는 검색과 인용 가능성을 넓히기 위해 주요 AI 크롤러의 접근을 허용합니다. robots.txt에는 GPTBot, Google-Extended, CCBot, anthropic-ai 등을 허용하는 규칙을 명시했습니다.

robots.txt는 크롤러에 전달하는 요청이며 접근 제어 수단은 아닙니다. 크롤러 공개 정책과 별개로 콘텐츠의 CC BY-NC 4.0 라이선스 조건은 그대로 적용됩니다.

로컬에서 미리보기

글을 발행하기 전에 어떻게 보이는지 확인하고 싶다면, Hugo 서버를 로컬에서 실행하면 됩니다.

hugo server -D

-D 옵션을 붙이면 draft: true인 글도 볼 수 있어요. 브라우저에서 http://localhost:1313으로 접속하면 실시간으로 미리보기가 됩니다. 파일을 수정하면 자동으로 새로고침되니까 편하게 확인할 수 있어요.

마무리

/dev/write는 아직 완벽하진 않습니다. 하지만 글쓰기에 집중하고, 나머지는 자동화한다 는 목표는 어느 정도 달성한 것 같아요.

다국어 지원, AI 기반 편집, 번역 검증과 배포 자동화까지 기술 블로그 운영에 필요한 기본 흐름을 갖췄습니다. 플랫폼에 맞지 않는 기능은 운영 결과를 바탕으로 걷어내면서 계속 개선할 예정이에요.

혹시 관심이 있으시다면 GitHub 저장소를 방문해 주세요. 피드백은 언제나 환영합니다.