GitHub Actions 기반 Blue-Green 배포를 GitLab CI/CD로 이전한 과정

GitHub Actions 무료 사용량 한계에 도달하면서 Podman, Caddy, Infisical 기반 무중단 배포 환경을 GitLab CI/CD로 이전한 기록입니다.

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) — 를 한 호흡에 만든 기록입니다.

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를 만들기 시작합니다

요즘 바이브코딩이라는 말을 정말 자주 봅니다. 예전에는 서비스를 하나 만들려면 기획하고, 디자인하고, 개발하고, 배포하고, 운영하는 과정이 꽤 멀게 느껴졌습니다. 아이디어가 있어도 “이걸 실제 서비스로 만들 수 있을까?”라는 질문 앞에서 오래 멈추는 일이 많았습니다. 그런데 이제는 조금 다릅니다. 아이디어만 있으면 AI와 함께 빠르게 화면을 만들고, 기능을 붙이고, 배포까지 해볼 수

AI가 빨라진 게 아니라, 기록이 빨라졌다

AI가 빨라진 게 아니라 기록이 빨라졌다. TASK 문서, Git 히스토리, PR, 검증 로그가 컨텍스트로 쌓이면서 goodtek-web의 개발 속도는 10~20분 단위로 빨라졌다. 이번 TASK-025에서는 AdSense 승인 준비를 위해 robots.txt, sitemap.xml, Contact, Privacy, Start Here, Projects, 허브 SEO를 정리하며 기초가 속도가 되는 과정을 기록했다.

무중단 배포

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

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

Build in Public

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

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

AI automation

애드센스 심사는 블로그가 아니라 메인 도메인이 받습니다

애드센스 승인은 블로그 서브도메인이 아니라 메인 도메인이 받습니다. 그래서 goodtek.xyz를 단순 랜딩이 아닌 블로그·서비스·정책이 연결되는 콘텐츠 허브로 다시 정리했습니다.

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

처음에는 단순한 문제처럼 보였습니다. goodtek website를 만들면서 VibeOps를 붙여 쓰고 있었고, 흐름도 그럴듯했습니다. TASK를 만들고, 브랜치를 따고, Cursor로 구현하고, 커밋하고, 푸시하고, MR을 만들고, 머지하면 끝. 그런데 이상하게도 끝난 것 같은데 끝나지 않았습니다. task done을 실행했는데 git status는 여전히 dirty였습니다. MR은 올라갔는데 로컬 TASK 문서는 또 바뀌어 있었습니다. 머지한 뒤에 develop을

CI/CD를 붙인다고 끝이 아니었습니다. Git Flow와 GitHub Actions를 맞춰가는 과정

처음에는 그냥 수동으로 배포해도 된다고 생각했습니다. 서버에 들어가서 코드를 받고, 빌드하고, 컨테이너를 다시 띄우면 끝. 솔직히 작은 프로젝트에서는 이게 더 빠르게 느껴질 때도 있습니다. 그런데 goodtek-web을 계속 만들다 보니 생각이 바뀌었습니다. 수동 배포는 처음 몇 번은 괜찮습니다. 하지만 반복되기 시작하면 문제가 조금씩 드러납니다. 어떤 브랜치가 배포됐는지 헷갈리고, 빌드가 깨진 상태로

AI 코딩이 빨라질수록, 작업 기준이 더 필요해졌다

AI 코딩 도구를 쓰면서 처음에는 이런 생각을 했습니다. “이제 개발이 엄청 빨라지겠는데?” 틀린 말은 아니었습니다. 실제로 Cursor 같은 도구를 쓰면 예전보다 훨씬 빠르게 코드를 만들 수 있습니다. 랜딩페이지 하나 만들고, 컴포넌트 나누고, 기본 API 붙이는 정도는 확실히 빨라졌습니다. 그런데 조금 써보니 다른 문제가 보였습니다. 코드는 빨리 만들어지는데, 프로젝트도 빨리 어질러질

Ghost 블로그를 CLI에서 Docker로 옮기고, Analytics까지 붙였습니다

처음에는 단순히 “Ghost 블로그에 조회수 좀 보고 싶다” 정도였습니다. 그런데 막상 들여다보니 일이 조금 커졌습니다. Ghost는 CLI 방식으로 떠 있었고, DB는 MariaDB였습니다. 블로그는 잘 돌아가고 있었지만, Ghost 6에서 내장 Web Analytics를 제대로 쓰려면 Docker 기반 구성이 훨씬 자연스러워 보였습니다. 그래서 결국 오늘 한 일은 이겁니다. Ghost CLI로 돌던 블로그를 Podman

Ghost 보안 업데이트를 하려다가 권한 문제부터 만났습니다

Ghost 보안 업데이트를 하려고 했는데, 첫 번째로 만난 건 보안 문제가 아니라 권한 문제였습니다. 분명 블로그는 정상적으로 돌고 있었습니다. 관리자 페이지도 열리고, 글도 보이고, 서버도 멀쩡해 보였습니다. 그런데 막상 서버에 들어가서 업데이트를 하려고 하니, Ghost는 이렇게 말했습니다. Permission denied. 서버 운영을 하다 보면 이런 순간이 자주 있습니다. 처음에는 “업데이트 명령어

Ghost 블로그를 Google Search Console에 등록하면서 겪은 사이트맵 시행착오

Goodtek 블로그 운영을 시작했으니 이제 블로그가 잘 검색되도록 해야하는 작업 중 하나가 Google Search Console 등록이었습니다. 블로그 글을 아무리 열심히 써도 Google이 내 글을 제대로 발견하지 못하면 검색 유입은 시작되지 않습니다. 특히 새로 만든 도메인과 새 블로그는 Google 입장에서 아직 신뢰도도 낮고, 어디에 어떤 글이 있는지도 모릅니다. 그래서 블로그를 만들었다면

바이브 코딩을 체계적으로 하는 방법: AI 개발을 레일 위에 올리기

바이브 코딩으로 당장 돌아가는 프로그램을 만드는 건 예전보다 훨씬 쉬워졌습니다. Cursor AI를 켜고 만들고 싶은 화면이나 기능을 설명하면, 생각보다 빠르게 결과가 나옵니다. 처음에는 정말 신기합니다. “이 정도면 혼자서 SaaS 하나 만들 수 있겠는데?”라는 생각도 듭니다. 그런데 실제 서비스를 만들려고 하면 이야기가 조금 달라집니다. 돌아가는 프로그램을 만드는 것과, 고객에게 팔

Obsidian, Quartz, Cloudflare Pages로 공개 개발노트를 만들며 배운 것

Goodtek을 만들면서 계속 고민하던 것이 하나 있었습니다. “개발하면서 생기는 생각과 시행착오를 어디에 남길 것인가?” 블로그에 정리하면 좋다는 것은 알고 있었습니다. 하지만 매번 블로그 글처럼 제목을 정하고, 문단을 다듬고, 썸네일까지 고민하다 보면 막상 기록 자체가 부담이 됩니다. 개발 과정에서는 짧은 결정들이 계속 생깁니다. 왜 이 구조를 선택했는지, 어떤 설정에서 막혔는지, 무엇을

NodeBB vs. Discourse: goodtek 커뮤니티를 NodeBB로 시작한 이유

블로그 다음에는 커뮤니티가 필요했다 석가탄신일까지 이어지는 3일 연휴. 연휴라고 하면 뭔가 여유가 있을 것 같지만, 대한민국 아빠에게 연휴는 그렇게 단순하지 않습니다. 아이와 놀아주고, 밥 먹이고, 씻기고, 재우고 나면 하루가 거의 끝납니다. 기획할 시간도, 코딩할 시간도 생각보다 없습니다. 아이가 잠들고 나서야 겨우 제 시간이 생깁니다. 보통 한두 시간 정도입니다. 그 시간에