goodtek

빌드 로그

"—"로 비어 있던 화면을, 진짜 제품으로

백엔드가 아무리 잘 돌아도, 사용자가 보는 게 빈칸이면 그건 아직 제품이 아닙니다. 이번 TASK-012는 그 빈칸을 채우는 일이었습니다. 대시보드 요약, 모니터 상세(가동률·지연 차트·장애 타임라인), 알림 채널 관리, 알림 이력까지 — 한 호흡에 "실서비스 급" 화면을 만들었습니다.

빌드 로그

감지 → 판단 → 알림: vibePulse의 심장을 만든 6개의 TASK

goodtek이 만들고 있는 vibePulse는 "내가 만든 웹/API가 지금 살아 있는가"를 확인하고, 죽으면 즉시 알려주는 초간단 생존 확인 SaaS입니다. 이번 글은 그 핵심 파이프라인 — 모니터를 만들고(TASK-006), 주기적으로 찌르고(007), 장애를 판단하고(008), 신호가 끊기면 알아채고(009), 알림을 큐에 태워(010), 슬랙·카카오톡으로 보내기까지(011) — 를 한 호흡에 만든 기록입니다.

빌드 로그

TASK-005 OAuth 로그인 구현

vibePulse TASK-005에서는 OAuth 로그인 흐름을 구현했습니다. 처음에는 이메일, 카카오, 네이버까지 함께 고려했지만, 초기 타겟인 바이브코더와 개발자에게 가장 빠르게 닿는 Google·GitHub 로그인에 집중하기로 결정했습니다. 인증 범위를 줄이는 과정, Better Auth 구현, allowlist, 온보딩 연결, i18n UX와 로그인 화면 개선까지 실제 시행착오를 정리했습니다.

빌드 로그

TASK-004: 보이지 않는 데이터베이스 기반 만들기

지난 TASK에서 사용자에게 보이는 화면을 만들었다면, 이번에는 그 화면과 기능들이 의존하게 될 보이지 않는 데이터베이스 기반을 준비했습니다. Postgres와 Redis를 띄우고, 스키마를 적용한 뒤 기초 데이터를 넣고, API가 실제 DB에 연결되는지 확인한 기록입니다.

빌드 로그

TASK-003: 기능을 붙이기 전에, 전체 화면을 먼저 만들었습니다

goodtek은 Build in Public 방식으로 vibePulse SaaS를 만들고 있습니다. TASK-003에서는 기능을 하나씩 붙이기 전에, 출시까지 필요한 전체 화면의 흐름을 먼저 그렸습니다. DESIGN.md로 일관성을 유지하면서도 기능 범위와 연결 구조를 더 선명하게 확인한 프론트 구현 기록입니다.

빌드 로그

TASK-002 배포 부트스트랩: 지속 가능한 SaaS를 위한 기초 공사

바이브 코딩으로 제품을 빠르게 만드는 것만으로는 실제 SaaS를 운영하기 어렵습니다. vibePulse TASK-002에서는 develop은 dev로, main은 prod로 배포되는 무중단 배포 기반을 만들고, GHCR·Infisical·rootless Podman·Caddy Blue/Green 구조를 통해 지속 가능한 개발 환경을 구축했습니다.

빌드 로그

Build Log: TASK-001 모노레포 만들기

vibePulse의 첫 번째 실제 작업으로 TASK-001 모노레포를 구성했습니다. Next.js, NestJS, worker, Postgres/TimescaleDB, Redis, CI, /health 체크까지 한 번에 잡으면서 빠른 구현보다 먼저 기준을 세우는 것이 왜 중요한지 돌아봤습니다. 운영 DB 데이터 전략과 named volume에 대한 고민도 함께 정리했습니다.

바이브코딩

vibeops init 이후, 코딩보다 먼저 정한 것들

vibeops init으로 프로젝트 골격을 만들고, LLM과 티키타카하며 VibePulse의 아키텍처, 기술 스택, UX, 알림 구조, 데이터 보존 전략, TASK 단위 로드맵을 먼저 정리한 과정입니다. 코딩을 시작하기 전에 AI에게 맡길 것과 사람이 통제할 기준을 어떻게 나눴는지 기록했습니다.

빌드 로그

goodtek의 첫 번째 SaaS를 만들기 시작합니다

만드는 속도는 빨라졌는데, 배포한 서비스가 지금 살아 있는지는 여전히 몰랐습니다. 사용자는 못 들어오는데 만든 사람만 모르는 상황을 없애려고 vibePulse를 시작한 이유를 정리했습니다.

배포와 운영

운영 서버에 배포 버튼을 누르기 전에 정한 것: 유료 회원에게 404를 보여주지 않기 위해

운영 서버 배포는 새 코드를 올리는 일이 아니라, 사용자의 접속을 끊지 않고 시스템을 교체하는 일입니다. goodtek이 유료 회원에게 404를 보여주지 않기 위해 Blue/Green 배포, Caddy upstream 전환, health check, 실제 끊김 테스트까지 구축하고 검증한 과정을 정리했습니다.

배포와 운영

.env 파일 대신 Infisical을 쓰기로 한 이유

.env 파일을 직접 관리하던 방식에서 벗어나 Infisical로 환경변수 기준을 다시 세운 과정입니다. 로컬, dev 서버, GitHub Actions 배포 흐름을 정리하면서 겪은 시행착오와 goodtek이 선택한 운영 기준을 기록했습니다.

바이브코딩

바이브코딩이 꼬이는 순간, 문제는 코드가 아니라 사이클이었다

task done을 실행했는데 git status는 여전히 dirty였습니다. 버그가 아니라 사람과 CLI와 Git의 책임 경계가 정해지지 않은 문제였고, add → ship → merge → sync로 사이클을 나눈 이유를 정리했습니다.