빌드 로그
AIMetaClean 빌드인퍼블릭: 기술 스택과 아키텍처 결정
AI Meta Clean의 기술 스택과 아키텍처를 AI와 하나씩 비교하며 결정했습니다. Next.js, NestJS, BullMQ, PostgreSQL, Redis, MinIO부터 파일 폐기와 보안 원칙까지 문서화한 과정을 공개합니다.
goodtek을 운영하며 vibePulse를 비롯한 제품을 직접 만들고 있습니다. 배포, 인증, CI/CD, 모니터링처럼 실제로 막혔던 지점을 기록으로 남깁니다. 연락은 hello@goodtek.xyz.
빌드 로그
AI Meta Clean의 기술 스택과 아키텍처를 AI와 하나씩 비교하며 결정했습니다. Next.js, NestJS, BullMQ, PostgreSQL, Redis, MinIO부터 파일 폐기와 보안 원칙까지 문서화한 과정을 공개합니다.
빌드 로그
AI Meta Clean의 첫 번째 TASK로 제품의 목표와 사용자, MVP 범위, 제외할 기능을 정리했습니다. AI와 질문을 주고받으며 기획을 문서화하고, vibeops로 브랜치 생성부터 커밋, PR, 병합까지 마친 과정을 공개합니다.
빌드 로그
AI MetaClean을 아이디어 단계부터 기획, 개발, 출시, 홍보까지 전부 공개합니다. 이번 글에서는 GitHub와 VibeOps를 활용해 PC와 모바일 어디서든 이어서 바이브코딩할 수 있는 프로젝트 환경을 세팅합니다.
배포와 운영
GitHub과 GitLab은 단순한 코드 저장소가 아닙니다. 바이브코더가 꼭 알아야 할 Git, CI/CD, GitHub Actions, GitLab CI/CD, 자체 러너, 무료 사용량과 자동 배포 선택 기준을 쉽게 정리했습니다.
빌드 로그
실제 사람 사진은 인증에 실패했고, AI 이미지는 통과했습니다. 그 경험에서 시작된 질문 하나. AI 이미지 메타데이터를 전문적으로 분석하고 관리하는 서비스는 정말 필요할까요? AIMetaClean을 Build in Public 방식으로 만들어가며 시장을 검증해 봅니다.
빌드 로그
프롬프트만으로는 '나'를 넘길 수 없다. getPersona.md가 PERSONA.md 패키지로 그 문제를 풀려는 이유와, 지금까지의 검증을 정리했습니다.
빌드 로그
Day 2에서 DB·인증·시크릿을 깔았다면, Day 3는 MinIO·Redis·GitLab CI·Docker Compose·공유 Zod까지 — 카탈로그는 아직 없지만 고객에게 팔 서비스가 버틸 인프라·검증·계약 바닥을 한 번에 깔았습니다. Build in Public로, 화면 0개인 주에 왜 이 작업을 먼저 했는지 정리합니다.
빌드 로그
Day 1에서 모노레포와 DESIGN.md를 잡았다면, Day 2는 Postgres·API·Web·Better Auth OAuth·Infisical까지 보이지 않는 바닥을 깔았습니다. 카탈로그는 아직 없지만 /dashboard가 텅 비어 보이는 이유와, 그래도 지금 Foundation을 먼저 닫아 둔 이유를 정리했습니다.
빌드 로그
getpersona.md는 AI 코딩 에이전트와 팀에게 말투·성향·판단 기준·지식 경계를 구조화해서 전달하는 PERSONA.md 플랫폼입니다. getdesign.md가 “AI에게 디자인 감각을 주는 DESIGN.md 컬렉션”이라면, getpersona.md는 “AI에게 페르소나를 주는 PERSONA.md 컬렉션”을 목표로 합니다. 오늘은 카탈로그나 결제 UI 같은 겉모습은 거의 없습니다. 대신 모노레포, 제품 계약서, 디자인 시스템, SEO/AEO/GEO 골격까지 — 나중에 후회하지 않을 Foundation만 쌓았습니다.
빌드 로그
Product Hunt 출시를 준비하며 Arcade AI를 활용해 영어 데모 영상을 제작한 과정을 공유합니다. 기능 설명보다 문제를 먼저 전달하는 스토리 구성과 One Shot으로 영상을 완성한 경험을 담았습니다.
배포와 운영
GitHub Actions 무료 사용량 한계에 도달하면서 Podman, Caddy, Infisical 기반 무중단 배포 환경을 GitLab CI/CD로 이전한 기록입니다.
바이브코딩
AI와 함께 코딩하면 계획, 프롬프트, 문서, 실제 코드가 쉽게 섞입니다. 이번 TASK-013에서는 공개 상태 페이지를 만들려 했지만, 실제로 ship된 것은 실시간 대시보드, 알림 테스트 상태 추적, 디자인 정합 작업이었습니다. 이번 글에서는 TASK 이름보다 머지된 코드를 기준으로 사실을 검증한 과정과, Realtime 아키텍처·비동기 상태 모델·공통 계약 관리 등 AI와 함께 개발할 때 놓치기 쉬운 기준들을 정리합니다. Build in Public 관점에서 ‘만들려던 것’과 ‘실제로 만든 것’을 구분하는 방법을 공유합니다.