서론
최근 Velog에서, Obsidian + Quartz 기반의 개인 블로그로 이전을 완료했다.
구현한 지는 꽤 되었는데, 글들을 모두 옮기고, 블로그를 조금씩 커스터마이징을 하고, 포트폴리오를 수정하느라 이제서야 글을 작성하게 되었다.
이번 글에서는 이전한 이유, 그리고 앞으로 블로그를 어떻게 운영해나가고 싶은지 마음가짐을 적어보려고 한다.
Velog에서 옮긴 이유
나는 기존에 Velog에서 나름 활발하게 활동했었다.
벨로그에서 첫 글을 작성한게 23년 5월이었고..이후로도 알고리즘, 개발, 회고 등 다양한 주제로 250개 이상의 포스팅을 진행했다. 처음에는 그저 일기장처럼 사용할 생각이었으나, 글을 적을수록 욕심도 생겼고 양질의 글을 작성하니 꽤나 많은 관심도 받았다.
이로 인해 나름 많은 팔로워도 생기고, 큐시즘 / 원타임 / 일단 등을 홍보하는 데에도 꽤나 큰 도움이 되었다고 생각한다.
하지만 때로는 이런 마음도 생겼다. 썸네일을 어떻게 뽑아야 사람들이 더 볼까? / 어떻게 글을 작성해야 사람들이 더 좋아해줄까? 이는 내가 블로그를 작성하는 본질과는 조금 다른 마음이었다. 그로 인해서 작성에 대한 부담감도 생겼고, 내용을 다듬기보다 겉을 치장하는 데 시간을 더 많이 쓰기도 하였다.
블로그를 통해 자신을 알리고, 다른 사람들에게 자신이 아는 것을 가이드하고 싶은 마음이 크다면 그렇게 운영하는 게 맞겠다. 하지만 나는 근본적으로 내가 생각하는 것 / 하고 싶은 말 / 기억하고 싶은 것 들을 기록하는 용도로 블로그를 시작했기 때문에 이제는 다른 방안을 찾아야만 했다.
그렇기 때문에 이전부터 해 보고 싶었던 개인 블로그 구현을 시작했고, 지금은 성공적으로 이관을 완료한 상황이다.
Velog의 지속 가능성
개인적인 내 마음의 변화와 별개로, Velog가 앞으로 얼마나 갈지에 대해서도 회의적이었다.
1. 업데이트 부재
우선은 벨로그는 지속적으로 업데이트를 진행하지 않았다. 현재 깃허브를 보면 아카이빙 상태로 더이상의 코드 수정은 일어나지 않고 있다.
물론 벨로그 자체는 너무 잘 만든 블로그이고, 업데이트가 없음에도 이정도로 사용자가 있다는 것에도 박수를 칠 만한 일이다. 하지만 문제는 지속적으로 발생할텐데, 이를 해결하지 못 한다는 것은 적어도 나에게는 불만사항이었다.
제작자의 의도일 수도 있지만 타 블로그 사이트에 비해서 통계 기능이 약한데, 이를 보완하기 위해 사용자들이 직접 대시보드를 구현하는 경우도 있을 정도이니 말이다.
2. AI 글 및 악성 광고
어느 순간부터 AI를 통해서 글을 딸깍 작성한 글들이 벨로그 트렌딩에서 보이기 시작했다.
이에 대해 나쁘다고만은 볼 수 없다. 하지만 이러한 상황이 지속적으로 발생한다면, 개인의 인사이트와 감정이 담긴 양질의 글들은 점점 줄어들 것이고, 결국 죽은 인터넷 이론 이 현실화될 것이다. (이미 상당 부분 진행되고 있다고 보기는 한다.)
위는 최근 필자가 벨로그에 오랜만에 들어간 후, 트렌딩에서 보고 캡쳐한 이미지이다. 이전에도 악성 홍보 댓글을 다는 경우는 빈번했으나, 트렌딩을 잠식할 정도로 심각하지는 않았다. 이제는 AI 및 악성 봇을 돌려서 더욱 강한 화력으로 밀어붙이고 있는 듯하다.
이를 잡기 위해서는 보안 업데이트가 필요한데, 현재 Velog는 개발중이지 않으니 해결될 것이라는 것도 불투명했다.
물론 여전히 양질의 글을 작성하시는 분들이 벨로그에 많고, 이미 쌓여있는 아카이브들은 큰 가치가 있다고 생각한다. 그리고 타인과의 소통을 하기 어려워졌다는 점도 아쉽기는 하다.
그러나 이러한 모습들을 보며 이번 기회로 블로그를 이전한 것에 스스로 잘했다라는 생각이 들었고, 앞으로 나만의 방식으로 블로그를 운영해야겠다는 마음이 강하게 생겼다.
Obsidian + Quartz를 택한 이유
이제부터는 블로그를 어떻게 구현했는지에 대해 적어볼 예정이다. 수많은 구현 방법이 있지만, 그 중에서도 해당 방법을 택한 이유는 무엇일까?
노션에서 Obsidian으로
우선은 옵시디언부터 언급하고 넘어가는 것이 좋을 것 같다. 필자는 대학교 때부터 노션을 굉장히 즐겨 썼다. 개인 기록을 할 때도, 팀플을 할 때에도 유용했고, 특히 블럭 단위로 옮기고 수정 삭제를 할 수 있는 점이 좋았다. 이는 지금도 유효하며, 앞으로도 팀 단위 작업을 할 때는 노션을 활용할 계획이다.
하지만 노션은 무거운 앱이었다. 데이터가 쌓일 수록 점점 느려짐을 느꼈다. 이는 개인적인 기록 목적으로 활용하기에는 조금 적합하지 않아 보였다. 그래서 나는 네이티브 메모앱과 같은 속도와 간결함, 그리고 커스터마이징을 할 수 있는 앱을 찾았고 옵시디언 을 택하게 되었다.
이미 옵시디언에 대해서는 너무나도 정보가 많고, 잘 활용하시는 분들이 많기 때문에 굳이 소개할 필요는 없을 것 같다. 필자는 옵시디언으로 이전한 후 회사 / 프로젝트 등 주요한 정보들을 모두 옮겼고, 지금은 일을 할 때도 노션, 메모 앱 등을 옵시디언으로 모두 대체하고 있다.
또한 옵시디언의 가장 좋은 점은 로컬에 md파일로 저장된다는 것인데, 이는 cli로 실행하는 클로드 코드와도 궁합이 아주 좋았다. AI는 형태가 정해져있는 md파일을 잘 이해하고, 이를 산출물로도 잘 만들어주기 때문이다. 그렇기에 옵시디언에 있는 문서를 AI에게 참조시키고, 수정하는 데에도 용이했다.
현재는 클로드 코드 + 옵시디언으로 개발 후 pr / 포트폴리오 내용 업데이트 등을 스킬스로 만들어 자동화 해 둔 상태이다. 이에 대해서는 차후 기회가 된다면 글로 작성해 볼 예정이다!
Quartz
이전부터 고민이었던 부분이 글을 기록하는 곳이 너무 제각각이라 통합하기가 어렵다는 점이었다. 즉, 노션에서 글을 작성 → Velog로 옮김 / 또는 클로드가 만들어 낸 산출물(프로젝트 내에 위치) → 노션에서 정제 → Velog에서 퍼블리시 .. 이러한 작업들을 하다 보니 한 곳에서만 문서를 수정하고 싶다는 마음이 생겼다.
그렇게 현재는 블로그 글, 개인 기록, 프로젝트 내 md파일(심볼릭 링크로 연결) 등을 모두 옵시디언에서 CRUD할 수 있도록 통합해 둔 상태이다. 이제는 통합한 문서들을 퍼블리싱할 기술이 필요했는데, 여러 스택들을 찾아보다가 해당 글을 읽고 나서 Quartz를 택했다.
옵시디언을 기반으로 구현되었기 때문에 가장 궁합이 좋을 수 밖에 없고, 글의 형태도 동일하기 때문에 원하는 모습으로 깔끔하게 퍼블리시할 수 있다. 또한 직접 코드를 수정해서 다양하게 커스터마이징을 할 수 있는데 이에 대한 내용은 아래에서 이어질 예정이다.
구현 과정 및 회고
해당 파트는 클로드코드와 함께 작성하였다. 블로그를 구현한 내용 / 필자가 클로드코드에게 지시한 것 / 프롬프팅 스타일 등을 세션 대화 내용 기반으로 작성해달라고 하였다.
이는 차후 AI에게 더욱 명확한 지시를 하기 위한 목적의 회고이다.
Quartz는 Obsidian 기반의 정적 사이트 빌더이지만, 그 자체로 완성된 블로그는 아니다. 내가 원하는 모습으로 만들기 위해서는 직접 코드를 수정해야 했고, 이 과정에서 클로드 코드(Claude Code)와 함께 바이브 코딩을 진행했다.
약 한 달간 총 98개의 커밋 중 60개 이상을 클로드와 함께 작업했고, 20개 이상의 대화 세션을 통해 블로그를 완성해 나갔다. 아래에서는 어떤 기능들을 커스터마이징했는지, 그리고 AI와 어떻게 협업했는지 회고해보겠다.
커스터마이징 한 기능들
1. 프리미엄 UI/UX 리디자인
가장 공을 들인 부분이다. 기본 Quartz 테마는 깔끔하지만, 개인 기술 블로그로 쓰기엔 조금 밋밋했다. Medium 같은 세련된 느낌을 원했고, 해외 개인 기술 블로그들을 참조하면서 전체적인 색상 팔레트, 타이포그래피, 카드 디자인을 전면 개편했다.
특히 다크모드를 기본 테마로 설정한 건 개발자 블로그라는 정체성에 맞다고 판단했기 때문이다. 코드 하이라이팅도 라이트/다크 모드에 따라 다른 Shiki 테마(github-light / tokyo-night)를 적용해서 가독성을 높였다.
2. 포트폴리오 페이지
블로그를 단순한 글 모음이 아니라, 나를 보여주는 공간으로 만들고 싶었다. 그래서 인덱스 페이지에 포트폴리오를 통합했고, EN/KO 언어 전환 기능까지 구현했다. 기술 스택 태그, 프로젝트 외부 링크, 성과 항목에 블로그 글 링크 칩 등을 추가해서 포트폴리오만으로도 내가 어떤 사람인지 전달할 수 있도록 했다.
3. 읽기 경험 개선
글을 읽는 경험도 신경 썼다. 읽기 진행률 바(ReadingProgress), 관련글 추천(RelatedPosts), 연도별 그룹화 등을 추가했다. 특히 관련글 추천은 같은 태그를 가진 글들을 자동으로 연결해주는데, 옵시디언의 백링크 철학과도 잘 맞아서 만족스러웠다.
4. 모바일 최적화
생각보다 많은 시간이 든 부분이다. 스티키 헤더, TOC(목차) 토글 접기, 수평 오버플로우 수정, 카드 레이아웃 깨짐 등 모바일에서 발생하는 이슈들을 하나하나 잡아갔다. 프론트엔드를 주로 하지 않는 입장에서 반응형 디자인의 디테일을 잡는 건 쉽지 않았지만, 이 과정에서 CSS와 레이아웃에 대한 이해가 많이 늘었다.
5. 터미널 스타일 브랜딩 & OG 이미지
블로그의 정체성을 >_ 터미널 프롬프트로 잡았다. 파비콘과 페이지 타이틀에 이 컨셉을 적용했고, OG 이미지도 직접 제작해서 카카오톡이나 슬랙에서 링크를 공유했을 때 미리보기가 깔끔하게 나오도록 했다. OG 메타태그 수정과 캐시 버스팅 등 사소하지만 중요한 작업들도 많았다.
6. PWA 지원 & 기타
홈 화면에 설치할 수 있는 PWA(Progressive Web App) 기능도 추가했다. 폴더 목록 스타일 개선, 파일 개수 표시, 소셜 링크 버튼, Giscus 댓글, Google Analytics 연동 등 사소하지만 블로그답게 만들어주는 기능들을 하나씩 붙여나갔다.
클로드 코드와 바이브 코딩
바이브 코딩이란
바이브 코딩(Vibe Coding)은 AI에게 자연어로 원하는 것을 설명하고, AI가 코드를 생성하면 피드백을 주면서 반복적으로 완성해나가는 방식이다. 정확한 코드를 직접 작성하기보다는, 방향성과 느낌(vibe)을 전달하고 AI와 함께 만들어가는 것이 핵심이다.
나는 프론트엔드 개발자가 아니다. TypeScript, SCSS, Preact 등은 업무에서 깊게 다루지 않는 기술들이다. 하지만 클로드 코드와 함께라면 내가 원하는 블로그를 직접 만들 수 있겠다는 확신이 있었고, 실제로 그렇게 되었다.
지시한 것들
한 달간의 작업을 돌아보면 크게 다음과 같은 것들을 클로드에게 지시했다.
1. 디자인/UI 작업
- “Medium 같이 조금 더 고급지고 세련된 느낌으로 바꿔줘”
- “해외 개인 기술 블로그를 참조해서 UI/UX를 개선해줘”
- “색 더 진하게”, “이거 심각하게 깨지는데?”
- 구체적인 디자인 시안 없이도, 레퍼런스와 느낌을 전달하면 클로드가 구현해주었다.
2. 콘텐츠 정제 작업
- Velog에서 가져온 250개 이상의 글에 대해 frontmatter(description, tags 등)를 표준화
- 46개 글의 description을 경어체로 통일하고 온점 추가
- 옵시디언의 백링크와 태그 체계를 활용한 글 간 연결
3. 기능 구현: 조사 → 설계 → 구현
- PWA 지원: 먼저 Quartz 빌드 파이프라인을 조사하게 한 뒤, 설계 → 구현 → PR 생성까지 진행
- 이미지 관리 방식: 옵시디언 + Quartz 사용자들이 이미지를 어떻게 관리하는지 웹 리서치를 시킨 후, 우리 프로젝트에 맞는 방식을 채택
- OG 이미지/메타태그: 카카오톡 미리보기 대응까지 반복 수정
4. 포트폴리오/이력서 자동화
- 여러 레포지토리의 PR을 스캔해서 포트폴리오용 마크다운을 자동 생성
- 영문 이력서 버전 제작 및 PDF 변환 가이드
프롬프팅 회고
잘 지시한 부분
1. CLAUDE.md로 규칙을 문서화한 것
프로젝트 루트에 CLAUDE.md를 두면 클로드가 매 세션마다 이를 참조한다. 여기에 git add -A 금지, 커밋 스타일, 디렉토리 구조, 기술 스택 등을 명시해두니 반복적인 설명이 필요 없었다. 일종의 온보딩 문서 역할을 한 셈이다.
2. 스킬(Skills)과 서브에이전트를 적극 활용한 것
클로드 코드에는 /superpowers:brainstorm, /superpowers:write-plan 같은 스킬이 있다. 복잡한 기능을 구현할 때는 먼저 브레인스토밍 스킬로 방향을 잡고, 플랜 스킬로 구체적인 구현 계획을 세운 후 실행했다. 또한 frontend-developer, ux-researcher, code-reviewer 같은 서브에이전트를 병렬로 활용해서 조사/구현/리뷰를 동시에 진행하기도 했다.
3. 제약 조건을 명확히 건 것
“커밋은 내가 해달라고 하면 해”, “git add -A 쓰지 마”, “push는 내 승인 후에만” 같은 제약 조건을 세션 초반에 명확히 전달했다. 이게 없으면 AI가 자의적으로 커밋하거나 코드를 변경할 수 있기 때문에, 통제권을 유지하는 것이 중요했다.
4. 조사 → 설계 → 구현의 단계적 접근
“그냥 구현해줘”가 아니라, “먼저 조사해줘” → “설계해줘” → “이제 구현해줘” 순서로 진행한 것이 좋은 결과를 냈다. 특히 PWA 구현이나 이미지 관리 방식 결정에서 이 패턴이 효과적이었다.
5. 레퍼런스를 함께 전달한 것
“Medium 같은 느낌”, “Vercel 블로그 참고해서” 처럼 구체적인 레퍼런스를 함께 전달하면 클로드가 의도를 훨씬 잘 파악했다. 추상적인 “예쁘게 해줘”보다 “이 사이트처럼 해줘”가 10배 효과적이다.
앞으로 보완하면 좋을 부분
1. 프론트엔드 용어를 더 정확하게 사용하기
“이거 왼쪽으로 좀 옮겨줘” 보다는 margin-left를 줄여줘 또는 flex-direction을 row로 바꿔줘 같이 CSS 속성명으로 지시하면 수정 횟수가 줄어들 것이다. 바이브 코딩이라고 해서 기술적 이해가 필요 없는 것은 아니다. 오히려 기본적인 HTML/CSS 구조를 이해할수록 AI에게 더 정확한 지시를 할 수 있다.
2. 디자인 목업을 활용하기
텍스트로 디자인을 설명하는 데는 한계가 있었다. “색 더 진하게”, “이거 좀 이상한데?” 같은 피드백은 여러 번의 반복을 초래했다. 간단한 목업이나 와이어프레임을 함께 첨부하면 의사소통 비용을 크게 줄일 수 있을 것이다.
3. 구체적인 수치를 제시하기
“여백 좀 줄여줘” 보다는 padding을 16px에서 8px로, “폰트가 작아” 보다는 font-size를 14px에서 16px로 처럼 수치를 명시하면 한 번에 원하는 결과를 얻을 확률이 높아진다.
4. 체계적인 QA 프로세스 도입
구현 후 바로 커밋하는 경우가 많았는데, npx quartz build --serve로 로컬에서 확인하는 체크리스트를 만들어두면 좋을 것 같다. 모바일 뷰, 다크모드, OG 미리보기 등을 체계적으로 검증하는 루틴이 필요하다.
5. 변경 범위를 작게 유지하기
한 번에 너무 많은 것을 바꾸면 문제가 생겼을 때 원인을 찾기 어렵다. “UI 전면 리디자인” 같은 큰 단위보다는 “카드 디자인 변경” → “색상 팔레트 변경” → “타이포그래피 변경” 처럼 작은 단위로 나눠서 진행하고, 각각 커밋하는 습관을 들이면 더 좋을 것이다.
이와 같은 회고는 이번이 처음인데, 꽤나 유용한 것 같다. 앞으로는 코드보다 프롬프트를 공유하는 일이 많아질 것이라고 한다. 그렇기에 더 나은 프롬프팅 역량을 기르기 위해서 이러한 회고를 자주 진행하며 개선해 나가야겠다.
특히 프론트엔드 관련 용어와 공부를 어느정도는 진행해야겠다.
앞으로의 블로그 방향성
이전에 작성하던 방식과 크게 달라질 것 같지는 않다. 하지만 전보다는 조금 더 부담을 내려 놓고, 정말 내가 남기고 싶은 생각들을 더욱 많이 남겨보고 싶다.
블로그 스터디도 리소스가 되는 한 계속해서 운영하며 1년에 40개 이상의 포스팅은 꾸준하게 해 보고 싶다. 그리고 메인에 있는 포트폴리오도 1달마다 주기적으로 업데이트하며 나의 현재 역량을 체크할 예정이다.
블로그 자체가 나를 보여주는 곳이기에, 앞으로도 차곡차곡 당시의 마음가짐과 경험을 남겨보자!