Claude Code로 블로그를 만들고 운영하는 전 과정 정리

개발자가 아닌 사람이 직접 블로그를 만든다는 것

준이아빠블로그(digitalmarketer.co.kr)는 디지털 마케터인 제가 Claude Code로 직접 만들었습니다. 화면과 데이터 구조, 배포 설정을 AI와 대화하며 만들고, 결과를 확인하면서 운영해 왔습니다. 개발을 업으로 삼은 적은 없습니다.

Claude Code는 파일을 읽고 고치거나 명령을 실행하는 AI 에이전트입니다. 원하는 기능을 설명하면 구현을 도와주지만, “완료했습니다”라는 답변만으로 올바른 사이트가 생겼는지는 알 수 없습니다. 제가 맡아야 할 일은 무엇을 만들지 정하고 실제 결과를 확인하는 것입니다.

이 글은 구축 경험과 운영 구조를 설명합니다. 터미널과 파일 수정이 아직 낯설다면 쉽게 풀어쓴 버전의 HTML 한 장 실습을 먼저 해 보세요. 여기서는 그보다 한 단계 넓혀, 여러 글을 목록과 상세 화면으로 연결하는 과정을 다룹니다.

Claude Code를 선택한 이유

제가 원한 것은 디자인과 기능을 직접 바꿀 수 있는 블로그, 반복되는 글쓰기와 검수를 줄이는 절차, 기존 코드를 계속 수정할 수 있는 환경이었습니다. Claude Code가 관련 파일을 찾아 읽고 기존 패턴을 참고하는 방식이 이 작업에 잘 맞았습니다.

프로젝트에 새로 합류한 팀원이 기존 작업을 읽고 시작하는 모습과 닮았습니다. 다만 모든 파일을 자동으로 완벽하게 읽는 것은 아니고, 다른 제작 도구도 기존 코드를 수정할 수 있습니다. 도구 이름만으로 일관성이 보장되지는 않습니다. 어느 파일을 참고했는지와 무엇을 바꿨는지 확인하는 과정이 필요합니다.

준이아빠블로그에서는 “글마다 태그를 여러 개 붙이고 같은 태그의 글을 모아 보게 해 달라”처럼 사용자의 행동을 설명했습니다. 처음부터 데이터베이스 전문 용어를 외우기보다, 원하는 화면과 확인할 결과를 함께 말했습니다.

기술 스택과 현재 콘텐츠 저장 방식

기술 스택은 사이트를 구성하는 도구의 조합입니다. 각 도구가 어느 일을 맡는지 알면 문제가 났을 때 어디부터 볼지 정하기 쉽습니다.

처음에는 Neon PostgreSQL 데이터베이스와 Drizzle ORM을 사용했습니다. 데이터베이스는 자료를 저장하고 조회하며, ORM은 코드에서 데이터베이스를 다루는 작업을 돕습니다. 2026년 10월 현재 학습 글은 Markdown 파일이 원본이므로 옛 “JSON 작성 후 데이터베이스 삽입”을 현재 운영 순서로 사용하지 않습니다.

Markdown은 # 제목 같은 기호로 글 구조를 표현하는 텍스트 형식입니다. 글 맨 앞에는 제목과 날짜 같은 정보를 따로 적기도 합니다. 현재 블로그에서는 content/insights, content/classes, content/courses로 인사이트와 클래스, 코스 정보를 나눕니다. 이 폴더 구조를 모든 새 블로그가 그대로 따라야 하는 것은 아닙니다.

초기에 거쳤던 구축 단계

처음에는 글 종류와 카테고리를 정했습니다. AI가 기본 폴더와 데이터 구조를 만들면 제가 필요한 항목이 있는지 확인했습니다. 이어 화면의 글꼴과 여백, 빨간 포인트 색을 정하고 글 목록과 상세 화면을 연결했습니다.

디자인은 “예쁘게”보다 구체적으로 요청했습니다. 모바일에서는 본문을 크게, PC에서는 목록과 본문을 구분하고, 기존 화면과 같은 색을 쓰도록 했습니다. 재사용할 부품이 생기면 이후 화면에서도 같은 부품을 참고하게 했습니다. AI가 자동으로 학습되어 영구히 같은 디자인을 보장하는 것은 아니므로 실제 화면은 계속 확인했습니다.

그다음 태그, 연재물, 검색용 제목과 설명, 사이트맵, RSS, 공유 미리보기 이미지를 붙였습니다. 사이트맵은 검색 서비스에 페이지 주소를 알려 주는 목록이고, RSS는 새 글 소식을 다른 프로그램이 읽도록 제공하는 형식입니다. 이런 기능은 글 한 편의 화면이 제대로 나오는 것을 확인한 뒤 추가했습니다.

마지막으로 코드 저장소를 Vercel과 연결해 사이트를 공개했습니다. 초기 구축에 본업 틈틈이 약 2주가 걸렸습니다. 제 사례의 기간이며, 모든 사람의 완성 시간이나 운영 비용을 예측하는 기준은 아닙니다.

글 두 편이 있는 작은 사이트부터 실행합니다

다음은 처음 블로그 전체 구조를 연습하는 예입니다. 앞의 HTML 실습보다 준비할 것이 늘어납니다. Claude Code 설치와 로그인이 필요하고, Next.js 프로젝트를 실행할 Node.js와 npm도 필요합니다. Node.js는 자바스크립트 프로그램을 실행하고, npm은 프로젝트가 쓰는 프로그램 묶음과 명령을 관리합니다. 이 프로그램 묶음을 패키지라고 부릅니다.

Node.js 공식 다운로드에서 현재 LTS 버전의 설치 안내를 확인합니다. LTS는 비교적 긴 기간 유지보수하는 배포 버전입니다. 2026년 10월 4일의 Next.js 설치 문서는 Node.js 20.9 이상을 요구합니다. Claude Code 자체의 기본 설치와 Next.js 실행에 필요한 준비는 구분합니다.

설치 후 터미널이나 PowerShell을 새로 열어 다음을 한 줄씩 실행합니다.

둘 다 버전 번호가 나와야 합니다. 명령을 찾을 수 없다고 하면 프로젝트 생성부터 진행하지 말고 설치 경로와 터미널 재실행 여부를 확인합니다. PowerShell에서 npm.ps1 실행 정책 오류가 나오면 npm.cmd --version으로 확인합니다. 이후에도 같은 오류가 나면 npm.cmd run dev처럼 실행할 수 있습니다. 이를 위해 컴퓨터 전체의 실행 정책을 풀거나 관리자 권한을 먼저 사용할 필요는 없습니다.

첫 AI 요청은 계정의 사용량을 쓰고, 패키지 설치에는 인터넷 연결이 필요합니다. 이 실습에서는 유료 데이터베이스나 공개 배포 계정을 만들지 않습니다.

개인 연습 폴더 blog-next-practice를 새로 만든 뒤, 쉬운 버전의 폴더 이동 방법으로 그 폴더에서 claude를 실행합니다. 기존 폴더를 덮어쓰지 않습니다. 대화 입력란에 다음을 넣습니다.

제안된 파일과 설치 내용을 읽고 진행합니다. 모르는 패키지는 무엇에 필요한지 설명하게 합니다. 파일 변경이나 명령 실행을 직접 확인하려면 수동 승인 모드를 사용합니다. 불필요한 기능을 먼저 제안하면 범위를 글 두 편으로 다시 좁힙니다.

생성된 package.json은 프로젝트의 설정과 실행 명령을 적는 파일입니다. AI에게 dev와 build가 각각 어떤 명령인지 설명하게 합니다. dev는 작업 중 화면을 보는 개발 서버를, build는 배포할 사이트를 생성하는 검사를 위한 명령으로 구성하도록 요청합니다.

AI가 폴더 안에 하위 프로젝트 폴더를 만들었다면 package.json이 있는 실제 폴더를 확인합니다. 새 터미널 창에서 그 폴더로 이동한 뒤, 위 명령 구성이 맞는지 확인하고 실행합니다. package.json을 못 찾는 오류가 나면 현재 경로부터 다시 봅니다.

터미널에 표시된 주소를 브라우저에서 엽니다. 보통 http://localhost:3000이며 다른 포트를 사용하면 실제 출력된 주소를 따릅니다. localhost는 현재 컴퓨터를 가리킵니다. 이 주소를 다른 사람에게 보내도 그 사람이 내 사이트에 접속하는 것은 아닙니다.

완료 기준은 목록, 원문, 이동과 모바일 화면입니다

AI가 파일을 만들었다는 답변보다 다음 결과를 직접 확인합니다.

• 첫 화면에 글 제목 두 개가 보입니다.
• 제목을 누르면 해당 본문이 열리고, 독서 기록에는 10쪽과 15쪽, 산책 기록에는 20분과 25분이 보입니다.
• 각 글의 목록 링크를 누르면 첫 화면으로 돌아갑니다.
• 창을 좁혀도 글과 메뉴가 가로로 잘리지 않습니다.

다음으로 개발 서버를 실행한 터미널에서 Ctrl + C를 눌러 서버를 멈춥니다. Claude Code의 대화창과 혼동하지 않습니다. 같은 터미널에서 다음을 실행합니다.

오류 없이 끝나는지 봅니다. 빌드 통과는 기술적 검사이며, 글의 사실이나 화면의 편의성까지 보장하지는 않습니다. 다시 화면을 확인하려면 npm run dev로 개발 서버를 켭니다.

오류가 나면 명령과 첫 오류 문장, 파일명과 줄 번호를 Claude Code에 알려 줍니다. 비밀번호나 접속 토큰이 포함된 로그는 그대로 붙여 넣지 않습니다. AI에게 원인을 설명하고 이번 오류와 관련된 파일만 수정하도록 요청한 뒤 같은 검사부터 다시 합니다.

예를 들어 화면에 Cannot find module이 나오면 필요한 패키지를 못 찾는 상태일 수 있습니다. 무조건 삭제하고 재설치하기보다 프로젝트 폴더가 맞는지, 패키지 설치가 완료되었는지부터 확인합니다. 주소를 열 수 없으면 개발 서버 터미널이 계속 켜져 있는지도 봅니다.

수정 전 독서 기록의 Markdown 파일을 프로젝트 밖의 개인 백업 폴더에 복사합니다. 글 폴더 안에 사본을 두면 별도 글로 표시될 수 있으므로 구분합니다. 이제 독서 기록의 10쪽만 12쪽으로 바꿔 보세요. content/posts의 해당 파일이 수정되었는지, 화면에는 12쪽과 15쪽이 보이는지 확인합니다. 잘못 바뀌었다면 사본과 비교해 해당 문장만 복원하고 화면을 다시 확인합니다. 마지막에는 직접 쓴 짧은 글 한 편을 추가하고, 목록과 상세 화면이 함께 늘어나는지 확인합니다. 이 두 작업이 되면 예제를 넘어 같은 방법을 반복할 수 있습니다.

CLAUDE.md는 반복 지시를 남기는 설명서입니다

CLAUDE.md에는 목적과 파일 위치, 실행 명령, 확인 기준을 적습니다. 프로젝트의 기본 폴더에 두면 Claude Code가 대화를 시작할 때 참고합니다. 공식 메모리 문서

처음에는 다음 정도로 시작해도 됩니다. 아래의 폴더와 명령은 앞의 연습 프로젝트가 그 구조로 만들어졌을 때 사용합니다.

이미 파일이 있다면 덮어쓰지 않고 필요한 규칙만 보완합니다. 새 대화에서 /context의 Memory files에 파일이 표시되는지 봅니다. 지시문은 참고 자료이므로 모든 동작을 강제로 차단하는 보안 장치와는 다릅니다. 대화가 길어지면 현재 목표와 남은 일을 짧게 기록하고 다음 작업을 시작합니다.

반복 운영은 역할과 검사 기준부터 정합니다

실제 운영에서는 주제 선정, 자료 조사, 초안, 검수, 검색용 정보 확인, 공개를 나눕니다. 검수에는 문장뿐 아니라 원문 출처, 수치의 기간과 대상, 링크가 포함됩니다. 검색용 제목과 설명을 다듬는 SEO 작업은 글을 이해하기 쉽게 만드는 일부 과정이며, 순위를 보장하지 않습니다.

초기 블로그에서는 주제 추천, 작성, 검수, 검색 점검을 네 AI 역할로 나누고 content-ops 같은 자체 스킬로 연결했습니다. 이 이름은 Claude Code의 기본 명령이 아닙니다. 같은 이름을 입력한다고 다른 컴퓨터에 그 절차가 생기지 않습니다. 현재는 작업에 맞는 스킬과 필요한 검토만 적용하며, 항상 네 서브에이전트를 실행하지 않습니다.

스킬은 반복 작업의 지침과 자료를 묶은 것이고, 서브에이전트는 분리해서 맡긴 작업을 수행하는 보조 AI입니다. 작업을 나누면 추가 사용량이 생기고, 서로 같은 잘못된 전제를 따라갈 수도 있습니다. 짧은 글 하나를 고치는 일부터 복잡한 분담 체계를 만들 필요는 없습니다.

GA4는 방문 경로와 페이지 이용을 집계하는 도구입니다. 초기에는 Claude 관련 글을 찾는 방문이 많다는 관찰로 활용 사례 글을 기획했습니다. 옛 글에 적힌 상위 순위와 배수는 당시 분석이며, 지금의 성과 수치로 재사용하지 않습니다. 분석할 때는 같은 기간의 같은 지표로 비교하고, 조회가 많다는 이유만으로 유용한 글이라고 단정하지 않습니다.

커밋과 공개 배포를 구분합니다

파일 저장은 현재 내용을 남기는 일이고, Git 커밋은 선택한 변경의 이력을 기록하는 일입니다. 푸시는 이력을 원격 저장소로 보내는 동작입니다. 원격 저장소와 호스팅 서비스가 자동 배포로 연결되어 있으면 푸시가 공개 사이트 변경으로 이어질 수 있습니다.

처음에는 잘 된 연습 파일을 별도로 복사해 두어도 됩니다. Git을 쓰기 시작했다면 변경 목록을 보고 이번 작업에 해당하는 파일만 커밋에 포함합니다. “전부 커밋해 줘”라는 요청으로 다른 업무 파일이나 비밀값까지 넣지 않습니다. 되돌릴 때도 다른 사람이 수정한 내용을 덮지 않고 이번 변경을 구분합니다.

공개할 때는 원격 저장소의 공개 범위, 서비스의 현재 요금 조건, 공개될 내용과 환경 변수를 확인합니다. 환경 변수는 프로그램이 실행할 때 읽는 설정이며, 비밀값을 포함할 수 있습니다. Vercel의 Git 배포 안내에서 미리보기와 실제 운영 배포의 차이를 확인하고 목적에 맞게 연결합니다.

제 경험에서 도움이 된 것은 반복되는 파일 수정과 오류 확인을 AI에게 맡기는 방식이었습니다. 그렇다고 기술적으로 완벽한 결과가 자동으로 생기거나 모든 글을 30분 안에 공개할 수 있는 것은 아닙니다. 글 두 편의 화면과 수정 결과를 혼자 확인할 수 있게 된 뒤, 필요한 기능과 운영 자동화를 하나씩 추가하면 됩니다.