클로드 코드로 블로그 만들기 — 바이브 코딩 회고

시작은 방치된 티스토리에서

예전에 돌조끼LAB이라는 티스토리 블로그를 운영했었다. 애드센스도 붙이고, ROS 설치 가이드도 쓰고, 티처블머신으로 뭔가 만들어보기도 했는데... 2021년 이후로 한 글자도 안 썼다. 전형적인 ENFP식 블로그 운영이었다.

그러다 2026년 3월, 블로그를 다시 시작해보자는 생각이 들었다. 근데 이왕이면 그냥 다시 시작하는 게 아니라, 요즘 내가 관심 있는 걸로 해보고 싶었다. 바이브 코딩(Vibe Coding)으로 블로그 자체를 처음부터 만들어보는 거다.

바이브 코딩이 뭔데

바이브 코딩은 AI와 대화하면서 코드를 작성하는 개발 방식이다. 내가 "이런 기능 만들어줘"라고 말하면 AI가 코드를 짜고, 나는 그걸 검토하고 방향을 잡아주는 식이다. 전통적인 코딩이 타자를 치는 행위였다면, 바이브 코딩은 AI와 페어 프로그래밍을 하는 것에 더 가깝다.

나는 Claude Code를 사용했다. 터미널에서 Claude와 직접 대화하면서 파일을 읽고, 수정하고, 명령어를 실행할 수 있는 CLI 도구다.

바이브 코딩의 장점

• 속도가 미친다 — 첫 커밋에서 블로그의 전체 골격이 나왔다. 레트로 Mac OS 스타일 UI, SEO 설정, 검색, 태그 필터링, RSS 피드까지. 혼자 했으면 일주일은 걸렸을 작업이 하루 만에 돌아가는 상태가 됐다.
• 보일러플레이트 지옥 탈출 — sitemap.ts, robots.ts, JSON-LD 구조화 데이터 같은 건 매번 쓸 때마다 검색하게 되는데, AI가 알아서 세팅해준다.
• 탐색 비용 절감 — "Supabase에서 이 쿼리 어떻게 짜지?" 같은 질문을 하면 공식 문서 뒤질 필요 없이 바로 코드가 나온다.

바이브 코딩의 단점 (진짜 중요한 부분)

• AI는 맥락을 모른다 — "왜 이 기능이 필요한지", "우리 유저가 누군지"는 내가 설명해줘야 한다. 안 그러면 기능은 돌아가는데 방향이 이상한 코드가 나온다.
• 과잉 엔지니어링 유혹 — AI한테 뭘 시키면 일단 잘 만들어주니까, 필요 없는 기능까지 넣고 싶어진다. "이것도 넣어볼까?" 하다가 코드가 불어난다.
• 검증은 여전히 사람 몫 — AI가 짠 코드가 "돌아간다"와 "제대로 돌아간다"는 다른 얘기다. 특히 보안이나 성능 쪽은 반드시 사람이 확인해야 한다.

한눈에 보는 바이브 코딩 장단점

구분	장점	단점
속도	프로토타입 → 하루 만에 완성	빠른 만큼 검증 시간이 별도로 필요
품질	보일러플레이트, SEO 등 기본기 탄탄	도메인 특화 로직은 부정확할 수 있음
학습	모르는 스택도 빠르게 도입 가능	깊이 있는 이해 없이 넘어갈 위험
의사결정	선택지를 빠르게 비교 가능	최종 판단은 반드시 사람이 해야 함

왜 기존 템플릿 안 쓰고 처음부터 만들었나

솔직히 블로그만 빨리 시작하려면 Gatsby 템플릿이나 Next.js 블로그 스타터 쓰면 된다. 근데 이번에는 블로그를 만드는 것 자체가 목적이 아니었다.

나는 바이브 코딩을 실무에 적용하는 과정에서, 재사용 가능한 스킬(Skill) 시스템과 교육 자료를 만들고 싶었다. Claude Code에는 skill이라는 기능이 있는데, 특정 도메인의 코딩 규칙을 파일로 정리해두면 AI가 그걸 참고해서 코드를 작성한다. React 컴포넌트 작성 규칙, 코드리뷰 기준, 커밋 메시지 컨벤션 같은 걸 스킬로 만들어두면 프로젝트마다 일관된 품질의 코드를 뽑아낼 수 있다.

기존 프로젝트에서 이걸 실험하기엔 리스크가 있었다. 블로그는 망해도 나만 손해니까, 스킬을 만들고 테스트하기에 딱 좋은 샌드박스였다.

기술 스택

가볍게 정리하면 이렇다.

스택 자체는 요즘 흔한 조합이다. 중요한 건 이 스택을 AI와 함께 어떻게 세팅했느냐인데, 그건 아래에서.

바이브 코딩 실전기

Claude Code 스킬 시스템 세팅

이번 프로젝트에서 가장 공을 들인 부분이다. Claude Code에 스킬을 세팅하면 AI가 코드를 작성할 때 해당 규칙을 자동으로 참고한다.

예를 들어, React 컴포넌트를 작성할 때 "화살표 함수로 작성할 것", "CSS Module 분리할 것", "useMemo는 명시적 요청 없이 쓰지 말 것" 같은 규칙을 스킬에 넣어두면, AI가 알아서 그 규칙에 맞는 코드를 생성한다. 매번 "아 그거 화살표 함수로 바꿔"라고 말할 필요가 없어진다.

코드리뷰 스킬, 커밋 메시지 컨벤션 스킬, 접근성 가이드 스킬 등을 하나씩 만들면서 "AI에게 어떤 규칙을 어떤 형태로 전달해야 효과적인가"를 실험했다. 이 과정 자체가 바이브 코딩 교육 자료의 뼈대가 됐다.

AI 코드리뷰 — 생각보다 쓸만했다

코드리뷰를 AI한테 시켜봤다. /review 커맨드 하나로 현재 변경사항을 분석하고 피드백을 준다. 솔직히 시니어 개발자의 리뷰를 대체하진 못한다. 하지만 "이 변수명 좀 애매한데", "이 함수 너무 긴데 쪼개는 게 어때", "여기 타입 좁히기 빠졌네" 같은 기본적인 피드백은 꽤 정확하게 잡아준다.

특히 혼자 작업할 때 유용하다. 혼자 코드 치다 보면 내 코드가 다 좋아 보이는데, AI가 냉정하게 "이거 중복인데요"라고 말해주면 정신이 번쩍 든다.

최적화 — AI와 같이 삽질한 이야기

블로그에 지식 그래프(Knowledge Graph)라는 기능이 있다. 포스트와 태그를 노드로 연결해서 시각화하는 건데, 처음 만들었을 때 포스트가 좀만 많아져도 렌더링이 버벅였다.

Claude한테 "이거 느린데 최적화해줘"라고 하면 뭘 할까? 일단 뷰포트 컬링(화면 밖 노드는 렌더링 안 함), 정적 레이아웃(매 프레임마다 위치 재계산 안 함) 같은 걸 적용해준다. 여기까진 좋다.

근데 문제는 "어떤 최적화가 이 상황에서 효과적인가"를 판단하는 건 결국 내 몫이었다는 거다. AI는 가능한 최적화 기법을 다 알고 있지만, "지금 이 그래프에서 병목이 어디인지"는 실제로 프로파일링을 돌려봐야 안다. AI한테 "일단 다 해줘"라고 하면 불필요한 최적화까지 들어가서 코드만 복잡해진다.

도메인 지식이 필요한 순간들

바이브 코딩을 하다 보면 AI가 못하는 영역이 뚜렷하게 보인다.

SEO 전략 판단 — AI는 sitemap이나 robots.txt를 만들어줄 수 있다. 근데 "AI 봇(GPTBot, ClaudeBot 등)한테 크롤링을 허용할 건지 말 건지"는 내가 결정해야 할 비즈니스 판단이다. 나는 허용하기로 했는데, 이건 AI가 대신 결정해줄 수 있는 문제가 아니다.

slug 설계 — 처음에 AI가 제목을 기반으로 slug를 생성하게 만들었다. 한글 제목이면 한글 slug가 나온다. URL에 한글이 들어가면 브라우저에서 인코딩되어 지저분하게 보이고, 공유할 때도 불편하다. 이건 한국어 블로그를 운영해본 사람이면 바로 아는 건데, AI는 그런 실사용 맥락을 모른다. 결국 순차 번호 방식으로 바꿨다.

라이브러리 호환성 — Tiptap 에디터의 details 확장을 넣었는데, v3에서 지원이 안 돼서 빌드가 터졌다. AI가 "이 확장 써보세요"라고 추천해줬는데, 해당 버전에서 지원되는지까지는 확인을 못한 거다. npm 생태계의 버전 호환성 문제는 직접 부딪혀야 알 수 있는 영역이다.

디자인 결정 — 이 블로그는 클래식 Mac OS 스타일의 레트로 디자인을 쓴다. "이런 느낌으로 만들어줘"라고 하면 AI가 코드를 짜긴 하는데, "이 노드 크기가 너무 크다", "외곽선이 거슬린다", "간격이 좁다" 같은 시각적 판단은 실제로 화면을 보면서 내가 조정해야 했다.

AI vs 사람 — 누가 더 잘하나

앞으로의 블로그 운영 계획

예전 티스토리에서 느꼈던 거지만, 블로그는 결국 꾸준함이다. 이번엔 좀 더 다양한 주제로 가보려 한다.

• AI 관련 정보와 인사이트 — 현장에서 AI를 적용하면서 느낀 것들. 뉴스에서 보는 AI와 실제로 쓰는 AI는 꽤 다르다.
• 바이브 코딩 시리즈 — 이 글이 시작이다. Claude Code 스킬 세팅법, 프롬프트 작성 요령, 실전 트러블슈팅 등을 시리즈로 다룰 예정이다.
• 스타트업 운영 경험 — 스타트업을 하면서 겪은 기술적, 비기술적 이야기들. 실패담도 포함해서.
• 현장 경험 기반 생각들 — 개발하면서 쌓인 나만의 의견들. 정답이라기보다는 하나의 관점으로.
• 여행기 & 개인 아카이브 — 개발 얘기만 하면 질리니까. 내 삶의 기록도 남기고 싶다.

예전에 애드센스 붙이고 커피 한 잔 값 벌었을 때 그 기분을 아직 기억한다. 이번에도 그 작은 동기부여에서 시작해서, 좀 더 오래 가는 공간을 만들어보려 한다.

마무리

바이브 코딩으로 블로그를 만들어본 솔직한 소감은 이렇다. 빠르다, 근데 쉽진 않다.

AI가 코드를 대신 써주니까 빠른 건 맞다. 하지만 "뭘 만들지", "왜 이렇게 만들지", "이게 맞는 방향인지"를 판단하는 건 여전히 나의 일이다. 바이브 코딩은 코딩을 몰라도 되는 게 아니라, 코딩 이외의 판단력이 더 중요해지는 개발 방식이다.

그리고 하나 더. AI와 작업하면서 만든 스킬과 규칙들은 이 블로그뿐 아니라 다른 프로젝트에서도 계속 쓸 수 있다. 블로그 하나 만들면서 바이브 코딩 인프라까지 같이 세팅한 셈이다. 이게 기존 템플릿 안 쓰고 직접 만든 진짜 이유이기도 하다.

앞으로 이 블로그에서 더 많은 이야기를 풀어보겠다. 돌조끼LAB 시절처럼 흐지부지 되지 않기를. (이번엔 AI가 같이 하니까 좀 낫지 않을까. 아마도.)