빌드 로그
AIMetaClean 빌드인퍼블릭: 기술 스택과 아키텍처 결정
AI Meta Clean의 기술 스택과 아키텍처를 AI와 하나씩 비교하며 결정했습니다. Next.js, NestJS, BullMQ, PostgreSQL, Redis, MinIO부터 파일 폐기와 보안 원칙까지 문서화한 과정을 공개합니다.
빌드 로그
vibePulse, AIMetaClean, getpersona.md를 만들면서 남긴 작업 기록입니다. TASK 단위로 무엇을 정하고 무엇을 미뤘는지 그대로 적었습니다.
빌드 로그
코드부터 짜지 않았습니다: AI와 시작한 첫 제품 기획
AI Meta Clean의 첫 번째 TASK로 제품의 목표와 사용자, MVP 범위, 제외할 기능을 정리했습니다. AI와 질문을 주고받으며 기획을 문서화하고, vibeops로 브랜치 생성부터 커밋, PR, 병합까지 마친 과정을 공개합니다.
빌드 로그
AIMetaClean 빌드인퍼블릭: 바이브코딩 프로젝트 환경 하네스 세팅
AI MetaClean을 아이디어 단계부터 기획, 개발, 출시, 홍보까지 전부 공개합니다. 이번 글에서는 GitHub와 VibeOps를 활용해 PC와 모바일 어디서든 이어서 바이브코딩할 수 있는 프로젝트 환경을 세팅합니다.
![[빌드인퍼블릭] 진짜 사람 사진은 실패했고, AI 사진은 통과했다 — AIMetaClean이 시작된 이유](/blog/content/images/size/w600/2026/07/1000037427.png)
빌드 로그
[빌드인퍼블릭] 진짜 사람 사진은 실패했고, AI 사진은 통과했다 — AIMetaClean이 시작된 이유
실제 사람 사진은 인증에 실패했고, AI 이미지는 통과했습니다. 그 경험에서 시작된 질문 하나. AI 이미지 메타데이터를 전문적으로 분석하고 관리하는 서비스는 정말 필요할까요? AIMetaClean을 Build in Public 방식으로 만들어가며 시장을 검증해 봅니다.
빌드 로그
getPersona.md를 왜 만드는가 — AI에게 '나'를 맡기려면 프롬프트만으로는 부족하다
프롬프트만으로는 '나'를 넘길 수 없다. getPersona.md가 PERSONA.md 패키지로 그 문제를 풀려는 이유와, 지금까지의 검증을 정리했습니다.
빌드 로그
getpersona.md를 이어가며 — AI 에이전트용 페르소나 플랫폼, Day 3 Foundation
Day 2에서 DB·인증·시크릿을 깔았다면, Day 3는 MinIO·Redis·GitLab CI·Docker Compose·공유 Zod까지 — 카탈로그는 아직 없지만 고객에게 팔 서비스가 버틸 인프라·검증·계약 바닥을 한 번에 깔았습니다. Build in Public로, 화면 0개인 주에 왜 이 작업을 먼저 했는지 정리합니다.
빌드 로그
getpersona.md를 이어가며 — AI 에이전트용 페르소나 플랫폼, Day 2 Foundation
Day 1에서 모노레포와 DESIGN.md를 잡았다면, Day 2는 Postgres·API·Web·Better Auth OAuth·Infisical까지 보이지 않는 바닥을 깔았습니다. 카탈로그는 아직 없지만 /dashboard가 텅 비어 보이는 이유와, 그래도 지금 Foundation을 먼저 닫아 둔 이유를 정리했습니다.
빌드 로그
getpersona.md를 시작하며 — AI 에이전트용 페르소나 플랫폼, Day 1 Foundation
getpersona.md는 AI 코딩 에이전트와 팀에게 말투·성향·판단 기준·지식 경계를 구조화해서 전달하는 PERSONA.md 플랫폼입니다. getdesign.md가 “AI에게 디자인 감각을 주는 DESIGN.md 컬렉션”이라면, getpersona.md는 “AI에게 페르소나를 주는 PERSONA.md 컬렉션”을 목표로 합니다. 오늘은 카탈로그나 결제 UI 같은 겉모습은 거의 없습니다. 대신 모노레포, 제품 계약서, 디자인 시스템, SEO/AEO/GEO 골격까지 — 나중에 후회하지 않을 Foundation만 쌓았습니다.
빌드 로그
Product Hunt 소개 영상, 막막했는데 Arcade로 한 번에 만들었습니다
Product Hunt 출시를 준비하며 Arcade AI를 활용해 영어 데모 영상을 제작한 과정을 공유합니다. 기능 설명보다 문제를 먼저 전달하는 스토리 구성과 One Shot으로 영상을 완성한 경험을 담았습니다.
바이브코딩
AI와 함께 코딩할 때 먼저 배운 것: 만든 것과 만들려던 것을 구분하기
AI와 함께 코딩하면 계획, 프롬프트, 문서, 실제 코드가 쉽게 섞입니다. 이번 TASK-013에서는 공개 상태 페이지를 만들려 했지만, 실제로 ship된 것은 실시간 대시보드, 알림 테스트 상태 추적, 디자인 정합 작업이었습니다. 이번 글에서는 TASK 이름보다 머지된 코드를 기준으로 사실을 검증한 과정과, Realtime 아키텍처·비동기 상태 모델·공통 계약 관리 등 AI와 함께 개발할 때 놓치기 쉬운 기준들을 정리합니다. Build in Public 관점에서 ‘만들려던 것’과 ‘실제로 만든 것’을 구분하는 방법을 공유합니다.
빌드 로그
"—"로 비어 있던 화면을, 진짜 제품으로
백엔드가 아무리 잘 돌아도, 사용자가 보는 게 빈칸이면 그건 아직 제품이 아닙니다. 이번 TASK-012는 그 빈칸을 채우는 일이었습니다. 대시보드 요약, 모니터 상세(가동률·지연 차트·장애 타임라인), 알림 채널 관리, 알림 이력까지 — 한 호흡에 "실서비스 급" 화면을 만들었습니다.
빌드 로그
감지 → 판단 → 알림: vibePulse의 심장을 만든 6개의 TASK
goodtek이 만들고 있는 vibePulse는 "내가 만든 웹/API가 지금 살아 있는가"를 확인하고, 죽으면 즉시 알려주는 초간단 생존 확인 SaaS입니다. 이번 글은 그 핵심 파이프라인 — 모니터를 만들고(TASK-006), 주기적으로 찌르고(007), 장애를 판단하고(008), 신호가 끊기면 알아채고(009), 알림을 큐에 태워(010), 슬랙·카카오톡으로 보내기까지(011) — 를 한 호흡에 만든 기록입니다.