MAKING · 제작기

바이브데일리 제작기: 카톡방에 흘러가던 글을 웹에 붙잡아 두기까지

오픈채팅방에 매일 올리던 글이 흘러가 사라지는 문제에서 시작한 하루 한 편 아티클 사이트. 첫날 두 시간 사이의 커밋 여덟 개, 공유 카드 썸네일이 빈 칸으로 뜨던 robots.txt 문제, 글 49편이 쌓이자 무거워진 홈, 기사로 답하는 물어보기와 브라우저 속 로봇 팔까지 커밋 114개로 돌아봤습니다.

2026.10.07 · KKflow · 읽는 시간 약 10분

바이브데일리는 바이브 코딩, 그러니까 AI와 함께 코딩하는 일에 관한 글을 하루 한 편 올리고 모아 두는 모바일 웹입니다. 저장소의 운영 브랜치에는 2026년 7월 13일부터 10월 7일까지 커밋이 114개 있습니다. 그중 106개는 Claude Code가 작성자로, 8개는 사용자 계정으로 남아 있고, 사용자 계정 커밋에도 Claude가 공동 작성자로 올라 있습니다. 이 글은 그 기록과 저장소의 기획안(docs/기획안-v1.0.md), README를 근거로 쓴 제작기입니다.

시작: 카톡 메시지는 흘러가면 끝이다

다른 제작기와 달리 바이브데일리는 "왜 만들었나"가 기록에 남아 있습니다. 첫 커밋과 같은 날 쓴 기획안의 첫 장이 그 이유입니다. 카카오톡 오픈채팅방 "⚡ AI랑 코딩하는 사람들"에 매일 글을 올리던 운영 방식에 두 가지 한계가 있었다고 적혀 있습니다.

휘발성 — 카톡 메시지는 흘러가면 끝이라, 어제 올린 좋은 글을 새로 들어온 사람이 볼 방법이 없다.
관리 부재 — 어떤 글을 언제 올렸는지, 반응이 어땠는지 기록이 남지 않는다.

해결책은 한 줄이었습니다. "웹에서 발행하고, 카톡엔 링크만 뿌린다." 글은 웹에 쌓고, 방에는 링크만 올립니다. 링크를 붙여 넣으면 썸네일과 제목, 요약이 담긴 카드가 펼쳐지게 합니다. 기획안은 이 카드를 두고 "OG 카드 품질이 이 서비스의 절반이다"라고까지 썼습니다.

글은 웹에 쌓이고 카톡방에는 링크만 가는 흐름입니다. 기획안의 한 줄 요약은 “웹에서 발행하고, 카톡엔 링크만 뿌린다”였습니다. 예약한 글은 공개 시각이 지나면 따로 깨우는 작업 없이 나타납니다.

7월 13일: 두 시간 사이의 커밋 여덟 개

첫 커밋은 7월 13일 아침 8시 40분(한국 시각)의 "바이브데일리 MVP 구현"입니다. 기획안이 "1주 목표"로 잡았던 MVP가 한 커밋에 들어 있습니다. 홈 피드와 태그 필터, 마크다운 글 페이지, 로그인 없는 ⚡ 리액션, 글마다 자동으로 그려지는 공유 썸네일, 그리고 관리자 화면(글쓰기·미리보기·이미지 올리기·예약·통계)까지입니다. 화면은 Next.js 14, 데이터와 로그인은 Supabase로 만들었습니다.

이 구조에서 눈여겨볼 만한 설계가 하나 있습니다. 예약 발행을 따로 돌리는 작업 없이 처리한 방법입니다. 데이터베이스의 행 단위 보안 규칙(RLS)이 "공개 시각이 지금보다 이전인 글만 독자가 읽을 수 있다"고 정해 두고, 페이지는 60초마다 새로 만들어지게(ISR) 했습니다. 그러면 내일 아침 8시로 예약한 글은 8시가 지나는 순간 규칙상 읽을 수 있는 글이 되고, 1분 안에 페이지에 나타납니다. 정해진 시각에 "이제 공개해"라고 깨워 줄 예약 작업이 필요 없습니다.

그 뒤 두 시간 동안 일곱 개의 커밋이 더 들어갔습니다.

9시 37분 — 배포 서버에 환경변수가 없어 가짜 주소로 빌드되면서 로그인이 안 됐습니다. 공개용 접속 키는 보안 규칙이 지켜 주는 공개 키라서, 코드에 기본값으로 넣고 환경변수가 있으면 그 값을 쓰게 바꿨습니다. 기획안에서 vibe.kk-flow.com이던 주소도 실제 주소인 vibedaily.kk-flow.com으로 고쳤습니다.
9시 50분 — 매일 오전 8시에 서버가 직접 xAI의 Grok API를 불러 기사를 만들고 발행하는 예약 작업을 붙였습니다. 요일별로 소재를 돌리고, 최근 제목 7개와 겹치지 않게 하는 장치도 있었습니다.
10시 00분 — 10분 만에 이 방식을 걷어 냈습니다. 서버가 기사를 만드는 대신, 바깥의 자동화가 기사를 만들어 보내면 받아서 발행하는 기사 등록 API(POST /api/articles)로 바꿨습니다. 왜 바꿨는지는 커밋에 적혀 있지 않습니다.
10시 11분~10시 33분 — 스크롤 어색함을 고치고, 태그 필터를 칩 나열에서 필터 아이콘으로 바꾸고, 라이트·다크·시스템 테마를 넣었습니다.

기사 등록 API에는 두 가지 안전장치가 있습니다. 발행 비밀값은 서버 환경변수가 아니라 데이터베이스 안의 함수가 확인하고, 같은 주소(slug)로 두 번 보내면 두 번 발행하지 않고 건너뜁니다. 자동화가 실수로 같은 글을 두 번 보내도 방에 같은 링크가 두 번 올라가지 않게 하는 장치입니다. README에는 이 API를 Grok의 스케줄 작업과 연결하는 예시가 적혀 있지만, 실제 운영에서 Grok은 쓰지 않습니다(운영자 확인). Grok을 부르는 예약 작업은 첫날 10분 만에 코드에서 빠졌습니다. 지금 이 API는 바깥에서 글을 보낼 수 있는 입구로 남아 있고, 관리자 화면에서 쓰고 발행하는 길도 그대로 있습니다. 사이트는 Claude Code와 함께 만들었습니다.

7월: 되돌린 커밋과, 숫자가 안 올라가던 버튼

7월 17일 아침에는 짧은 소동이 있었습니다. 8시 24분에 푸터에 다른 KKflow 서비스 링크를 넣었는데, 배포 연결(웹훅)이 유실되어 배포가 시작되지 않았습니다. "재배포 트리거"라는 이름의 커밋이 두 번 이어졌고, 8시 38분에 처음의 푸터 커밋을 통째로 되돌렸습니다. 되돌린 이유는 기록에 없습니다.

같은 날 ⚡ 버튼도 고쳤습니다. 버튼을 누른 직후 새로고침하면 60초 동안 저장된 옛 페이지가 보여서, "충전 완료"라고 떴는데 숫자는 그대로인 것처럼 보였습니다. 커밋은 이걸 "혼란"이라고 불렀습니다. 버튼이 화면에 나타날 때 데이터베이스에서 지금 숫자를 직접 읽어 오게 바꿨습니다. 앞에서 예약 발행을 공짜로 해 준 60초짜리 캐시가, 여기서는 정반대로 발목을 잡은 셈입니다.

7월 23일에는 글과 별도로 AI 모델 비용 계산기(/tools/ai-cost.html)를 만들었습니다. 같은 날 저녁 설명 문구를 하나 고친 커밋이 있습니다. 원래 문구가 "한글이 영어보다 토큰을 적게 쓰는 것"처럼 읽힐 수 있어서, 글자당 한글이 영어보다 토큰을 더 많이 쓰고 그만큼 비용도 더 든다고 바로잡았습니다. 8월 1일에는 조회수가 부풀지 않도록, 한 번 본 글을 기억하는 저장소를 탭을 닫으면 사라지는 곳(sessionStorage)에서 남아 있는 곳(localStorage)으로 옮겼습니다.

날짜별 커밋 수 (한국 시각). 7월 13일부터 10월 7일까지 87일 동안 커밋 114개, 커밋이 있었던 날은 32일입니다. 운영 브랜치 기준입니다. 9월에는 커밋이 두 번뿐입니다.

공유 카드 썸네일이 빈 칸으로 뜨던 일

"OG 카드가 서비스의 절반"이라던 바로 그 카드에서 문제가 났습니다. 8월 8일 커밋에 따르면, X(트위터) 같은 곳에 링크를 올리면 미리보기 이미지가 계속 빈 칸으로 나왔습니다. 원인은 robots.txt였습니다. 검색 로봇이 API 주소를 긁어 가지 않도록 /api/ 전체를 막아 두었는데, 썸네일 이미지도 /api/og에 있었던 것입니다. 그래서 /api/og만 허용하는 예외를 넣었습니다.

엿새 뒤(8월 14일) 같은 문제를 다시 고친 커밋이 나옵니다. 커밋 설명이 원인을 꼼꼼히 적었습니다. robots.txt 표준(RFC 9309)대로라면 "더 긴 규칙이 이긴다"라서 Allow: /api/og가 Disallow: /api/를 이겨야 합니다. 하지만 X의 카드 로봇은 이 우선순위를 따르지 않아 이미지를 막힌 것으로 봤습니다. 이번에는 예외를 더 붙이는 대신, 이미지 주소 자체를 /api/ 밖인 /og로 옮겼습니다. "어떤 크롤러가 와도 해석이 갈리지 않게" 하려는 것이었고, 예전 주소로 저장된 카드를 위해 /api/og에서 /og로 넘겨주는 영구 이동도 함께 넣었습니다. 규칙을 해석하는 쪽이 여럿이면, 해석할 여지를 없애는 편이 확실하다는 기록입니다.

글 49편, 이미지 요청 49개

8월 25일에는 쌓인 글이 문제가 됐습니다. 커밋에 따르면 글이 49편까지 늘었는데, 홈 화면이 그 전부를 한 번에 그리고 있었습니다. 카드마다 썸네일을 불러오니 첫 화면에서 이미지 요청이 49개 나갔고, 스크롤도 끝없이 길었습니다. 목록을 불러올 때 글 본문까지 함께 받고 있었는데, 본문 안에 차트가 base64 글자로 박혀 있어서 발행된 글 전체 본문만 281KB였습니다. 목록 화면은 본문을 쓰지도 않는데 말입니다.

고친 방법은 단순했습니다. 홈의 지난 글은 최근 6편만 보여 주고 "아카이브 전체 보기" 버튼을 둡니다. 다만 태그를 고른 상태에서는 자르지 않습니다. 그 태그의 글을 다 보려고 고른 것이니까요. 목록을 불러올 때는 본문을 빼고, 목록 전용 타입을 따로 만들었습니다.

같은 날부터 이튿날까지는 본문 그림을 눌러 크게 보는 기능을 만들고 세 번 고쳤습니다. 마지막 수정(8월 26일)의 설명에는 실측값이 남아 있습니다. 처음에는 그림을 화면보다 크게 띄우고 밀어서 보게 했는데, 밀려고 손을 대면 닫기로 처리되어 좌우가 사실상 보이지 않았습니다. 그래서 그림을 항상 화면 안에 다 들어오게 맞추고, 좁은 화면에서 가로로 긴 그림은 90도 눕혀 띄우게 했습니다. 390×844 화면에서 긴 변이 562px, 본문에서보다 1.57배 크게 보인다고 적혀 있습니다.

바이브데일리의 커밋 가운데 27개는 이름에 "기사용"이나 "기사:"가 들어간, 특정 글에 넣을 그림·차트·영상을 만드는 커밋입니다. 사이트의 기능만큼이나 글에 들어갈 자료를 만드는 데 많은 커밋이 쓰였습니다. 9월에는 커밋이 두 번뿐입니다(9월 9일 글용 스크린샷, 9월 24일 유입 경로 기록). 그 사이의 사정은 기록에 없습니다.

10월 2일: 지난 글로 답하는 '물어보기'

10월 2일 하루 동안 커밋 13개가 들어가며 물어보기(/ask)가 생겼습니다. 방문자가 질문하면 지금까지 발행한 글에서 관련 있는 글 4편을 찾아, Anthropic의 Claude Haiku 4.5가 그 글들을 근거로 답하는 기능입니다. 기획안의 "휘발성" 문제를 한 번 더 푼 셈입니다. 지난 글이 남아 있을 뿐 아니라, 이제는 질문으로 꺼내 볼 수 있습니다.

같은 날의 커밋들을 따라가면 이 기능이 어떻게 다듬어졌는지 보입니다.

AI를 부르지 않는 경우부터 — 관련 글이 하나도 없으면 AI를 부르지 않습니다. 근거 없는 답을 만들지 않기 위해서입니다.
찾는 방법 — 긴 글은 앞부분만 넘기던 것을 소제목 단위로 나눠 질문과 겹치는 부분을 넘기게 바꿨고, "어디", "어떻게" 같은 질문 말투 낱말은 검색에서 뺐습니다.
근거만 보여 주기 — 답의 마지막 줄에 "참고: 번호"를 달게 하고, 실제로 근거로 쓴 글만 링크로 보여 줍니다.
같은 질문은 저장한 답으로 — 질문은 원문이 아니라 해시로만 저장하고, 7일이 지나거나 새 글이 올라오면 저장한 답을 버립니다. 저장한 답으로 응답할 때는 AI를 부르지 않고 하루 횟수에도 넣지 않습니다.
하루 한도 — 처음에는 한 사람당 하루 10번, 사이트 전체 300번이었고, 같은 날 오후 한 사람당 5번으로 줄였습니다. 채팅창과 물어보기 페이지에 오늘 남은 횟수가 보입니다.

외부 AI에 질문을 보내게 된 만큼, 첫 커밋에서 개인정보처리방침에 처리 위탁 내용을 함께 더했습니다. 질문 저장 방식을 바꿀 때도 방침 문구를 같이 고쳤습니다. 이 기능을 만드는 과정은 그 뒤 바이브데일리의 글로도 쓰였고, 같은 날 오후의 커밋 다섯 개가 그 글에 넣을 그림(API 키 흐름, 요청·응답 모양, 답하는 4단계, 글 점수 매기기)입니다.

10월 5일: 브라우저 속 로봇 팔

가장 최근의 큰 작업은 로봇입니다. 10월 4~5일, "휴머노이드 로봇에는 AI가 얼마나 들어가 있을까요"라는 글을 위해 실험을 했습니다. tools/robot-sim의 README에 구조가 적혀 있습니다. Claude Code가 ROS MCP 서버를 거쳐 ROS 2 노드에 명령을 보내고, 그 노드가 MuJoCo 물리 시뮬레이터 속 Franka Panda 로봇 팔을 움직여 빨간 컵을 접시로 옮기는 실험입니다. 커밋에는 "1회차(컵 놓친 실험)" 그림과 GIF도 남아 있습니다. 첫 시도는 실패했고, 그 실패도 글의 재료가 됐습니다.

10월 5일 밤에는 이 실험을 누구나 브라우저에서 해 볼 수 있는 로봇 팔 실험실(/lab/robot)을 만들었습니다. 물리 엔진은 Google DeepMind의 MuJoCo WebAssembly 버전, 화면은 three.js입니다. 같은 밤 16분 사이에 로봇 모양 묶음과 물리 엔진 파일을 gzip으로 받게 바꾸고, 내려받기 진행률과 오류 표시를 붙이고, 슬래시 없이 주소를 열어도 파일 경로가 맞게 고친 커밋이 이어졌습니다. 하루 한 편 글을 올리는 사이트가, 글에 나온 실험을 직접 돌려 보는 곳까지 넓어진 것입니다.

돌아보며

바이브데일리의 기록은 "카톡에 흘러가는 글을 붙잡아 두자"는 한 문장에서 출발해서, 그 문장을 조금씩 넓혀 온 과정으로 읽힙니다. 처음에는 글을 웹에 남기는 것, 다음은 그 링크가 카톡과 X에서 제대로 펼쳐지게 하는 것, 그다음은 쌓인 글이 무거워지지 않게 하는 것, 그리고 쌓인 글을 질문으로 다시 꺼내 쓰는 것입니다.

또 하나 눈에 띄는 것은 같은 장치가 양쪽으로 작용한 장면입니다. 60초짜리 페이지 캐시는 예약 발행을 별도 작업 없이 해결해 줬지만, 같은 캐시 때문에 ⚡ 숫자가 안 올라가는 것처럼 보였습니다. /api/를 막은 robots.txt는 API를 지켰지만 썸네일까지 막았습니다. 편하게 해 주는 장치일수록, 그 장치가 어디까지 닿는지를 확인해야 한다는 기록입니다.

바이브 코딩을 처음 시작한다면 바이브 코딩을 시작할 때 알아 두면 좋은 일곱 가지를 함께 보셔도 좋습니다. 가입 없이 쓰는 웹 서비스를 만들 때의 고민은 이 글에, KKflow의 다른 제작기는 QRforge, 사주 플로우, 로또르르에 있습니다.