3시간 자고 다시 일어났습니다. ️

이제 Product Hunt 출시 준비도 거의 끝이 보이네요.

출시 당일에는 Product Hunt를 중심으로 Reddit, X, Threads, LinkedIn, Hacker News, Indie Hackers 등에 순차적으로 공유해 볼 계획입니다.

혹시 제가 놓치고 있는 채널이나, 출시 후 꼭 해보면 좋았던 것들이 있을까요?

Product Hunt 런칭 경험이 있으신 분들의 조언을 듣고 싶습니다.

AI 시대에 가장 많이 바뀐 것은 코딩이 아니었습니다.

요즘 주변을 보면 정말 신기한 일이 벌어지고 있습니다.

예전에는 개발을 한 번도 해보지 않았던 사람들이 AI와 함께 서비스를 만들기 시작했습니다. 디자이너가 SaaS를 만들고, 마케터가 Discord Bot을 만들고, 기획자가 AI Agent를 만들고, 학생이 하루 만에 서비스를 배포합니다. 몇 년 전만 해도 상상하기 어려웠던 일들이 이제는 너무 자연스러워졌습니다.

그런데 한 가지 공통점을 발견했습니다.

대부분은 만드는 방법은 알고 있습니다. 하지만 운영하는 방법은 잘 모릅니다.

밤새 바이브 코딩으로 앱을 만들고 배포까지는 성공합니다. 그런데 며칠 뒤 갑자기 "서비스가 안 된다"는 연락을 받습니다. 알고 보니 백그라운드 Worker가 멈춰 있었고, Discord Bot은 이미 연결이 끊어져 있었으며, AI Agent는 API 호출 오류 이후 그대로 멈춰 있었습니다.

더 재미있는(?) 경우도 있습니다. 집 PC에서 앱을 실행해 두고 사용하는 경우인데, 새벽에 Windows Update가 설치되면서 PC가 재부팅됩니다. 앱은 다시 실행되지 않지만 본인은 그 사실을 3일 뒤에야 알게 됩니다.

웹사이트는 멀쩡해 보이는데 실제 일을 하는 Worker만 죽어 있는 경우도 정말 자주 봤습니다.

예전에는 가장 어려운 것이 코드를 작성하는 일이었습니다. 지금은 AI가 그 시간을 엄청나게 줄여주고 있습니다. 대신 새로운 문제가 생겼습니다.

"내 앱이 지금도 살아 있는 걸 어떻게 알지?"

저는 앞으로 AI 시대에는 코딩보다 운영(Operation)이 더 중요한 역량이 될 것이라고 생각합니다.

그래서 이 문제를 해결해 보고 싶어 vibePulse를 만들고 있습니다. 웹사이트와 API는 URL만 등록하면 바로 모니터링할 수 있고, URL이 없는 Worker, Bot, AI Agent는 Vibe Install 기능으로 Claude, ChatGPT, Gemini 같은 AI에게 프롬프트 하나만 전달하면 Heartbeat 모니터링까지 자동으로 설치됩니다.

현재 Product Hunt 출시를 준비하면서 마지막 다듬는 작업을 하고 있습니다.

혹시 여러분도 비슷한 경험이 있으셨나요? AI로 만든 프로젝트를 운영하면서 가장 불편했던 점이나 예상하지 못했던 문제가 있었다면 댓글로 공유해 주세요. 여러분의 경험이 다음 기능을 만드는 데 큰 도움이 될 것 같습니다.

---

vibePulse
https://vibepulse.goodtek.xyz

Product Hunt 출시 준비 중

#BuildInPublic #VibeCoding #AI #IndieHackers #SaaS #Monitoring #Heartbeat #ProductHunt #vibePulse

다들 아래와 같이 스케쥴로 72h간 정도 남기고 모두 지우는 스케쥴을 작성해 두면 좋을 것 같네요.

sudo crontab -u gitlab-runner -l
0 3 * * * podman system prune -af --filter "until=72h" >> /home/gitlab-runner/podman-prune.log 2>&1
15 3 * * * podman builder prune -af >> /home/gitlab-runner/podman-prune.log 2>&1

요약
develop/main push 후 CD 파이프라인이 서버 디스크 부족으로 실패했습니다.
원인은 배포마다 쌓인 미사용 컨테이너 이미지이고, 즉시 조치는 수동 prune, 재발 방지는 deploy.sh에 자동 정리 추가로 처리했습니다.

증상
GitHub Actions CD의 SSH 배포 단계에서 exit code 125로 종료되었습니다.

==> pull ghcr.io/***/vibepulse-worker:b2bcf4b2...
...
no space left on device
web, api 이미지 pull은 성공
worker 이미지 unpack 중 실패
blue/green 배포에서 현재 슬롯(blue)은 그대로 — pull 실패는 health gate 이전이라 트래픽 전환 없음
원인
서버 root 볼륨이 100% 사용 상태였습니다.

항목 수치
디스크
89G 중 89G 사용 (~484M 여유)
Podman 이미지
618개 중 8개만 사용 중
회수 가능 용량
~48GB (96%)
매 push마다 web / api / worker 3개 이미지가 git SHA 태그로 pull되지만, deploy.sh에 이전 이미지 정리 로직이 없어 태그만 쌓였습니다.

추가로 api/worker 이미지는 아직 전체 monorepo node_modules를 포함하는 walking skeleton 구조라 태그당 ~2.3GB 수준입니다. (이미지 슬리밍은 TASK-018 예정)

배포 구조 (참고)
Blue/Green: blue 311x, green 321x 포트
새 슬롯 pull → health check → Caddy 전환 → 구 슬롯 종료
런타임: rootless Podman
스토리지: ~/.local/share/containers/storage/
실패 시점에는 green 슬롯 worker pull 중이었고, blue 슬롯이 계속 서비스 중이었습니다.

즉시 조치 (서버)
실행 중인 컨테이너가 참조하는 이미지는 유지됩니다.

실행 중 컨테이너 확인

podman ps --format 'table {{.Names}}\t{{.Image}}'

미사용 이미지·레이어 정리

podman image prune -a -f
podman system prune -f

공간 확인

df -h /
podman system df
약 45~48GB 회수 후 CD 워크플로를 재실행합니다.

재발 방지 (코드 변경)
scripts/deploy.sh에 prune_unused_images()를 추가했습니다.

시점 동작
pull 전
미사용 이미지 정리 → 새 이미지 pull 전 디스크 확보
구 슬롯 compose down 후
이전 SHA 태그 이미지 정리
prune_unused_images() {
echo "==> prune unused $CONTAINER_RUNTIME images"
"$CONTAINER_RUNTIME" image prune -a -f
"$CONTAINER_RUNTIME" system prune -f
}
실행 중 컨테이너(현재 active 슬롯 + Postgres/Redis 등)가 쓰는 이미지는 삭제되지 않음
docker/podman 모두 동일 명령 사용
교훈 / 체크리스트
컨테이너 이미지도 디스크를 먹는다 — 로그·DB만 볼 게 아니라 podman system df도 주기적으로 확인
SHA 태그만 쓰는 CD는 prune이 필수 — 배포 스크립트에 정리 단계를 넣거나 cron으로 보완
blue/green은 일시적으로 이미지가 2세트 — 디스크 여유는 최소 태그 2~3세트 분량 권장
실패해도 서비스는 유지될 수 있음 — pull/health gate 실패 시 새 슬롯만 정리되고 기존 슬롯 유지 (의도된 동작)
후속 (선택)
항목 설명
TASK-018
api/worker 이미지 슬리밍 (prod-only node_modules)
디스크 용량
89G root에서 빈번한 CD 시 여유 확보 검토
모니터링
디스크 사용률 알람 (예: 85% 이상)
한 줄 요약
CD가 이미지를 계속 쌓아 root 디스크를 채웠고, podman image prune -a로 복구한 뒤 deploy.sh에 배포 전·후 자동 prune을 넣어 재발을 막았다.

goodtek vibepulse % vibeops init

Agent clients
Which coding agents will you use? (Space toggle · Enter confirm) Cursor
(.cursor/rules, .cursor/skills)

Branch policy
Branch policy GitFlow lite — develop (integration) + main (production)
→ vibeops init → /Users/hjhamm/goodtek/vibepulse
project: vibepulse
vibeops: 2.3.0
clients: Cursor (.cursor/rules, .cursor/skills)
git: integration=develop, production=main

✓ created .cursor/rules/01-task-source-of-truth.mdc
✓ created .cursor/rules/02-git-safety.mdc
✓ created .cursor/rules/03-docs-before-ship.mdc
✓ created AGENTS.md
✓ created docs/logs/README.md
✓ created docs/project/03-architecture.md
✓ created docs/project/05-current-state.md
✓ created docs/project/06-decisions.md
✓ created docs/tasks/TASK-000-template.md
✓ created .cursor/skills/implement-task/SKILL.md
✓ created .cursor/skills/plan-task/SKILL.md
✓ created .vibeops.json
✓ created .vibeops.env.example
✓ created .gitignore

done: 14 created, 0 overwritten, 0 skipped.

Git repository
Create initial commit? Yes
Initial commit message initialize vibepulse project

Git setup:
✓ git init
✓ production branch main
✓ initial commit on main
✓ integration branch develop

Remote origin is required for push and merge requests.
GitHub repository name (owner/repo or name for gh to create) vibepulse
Creating GitHub repository via gh…

Remote bootstrap:
✓ pushed main → origin
✓ pushed develop → origin

Next steps:

1. Read AGENTS.md
2. Cursor: @docs/tasks/TASK-001-….md in Ask, then Agent (+ /plan-task, /implement-task)
3. vibeops llm connect — LLM for task add / task ship
4. Push branches to origin (first time only):
   git push -u origin main
   git push -u origin develop
5. vibeops task add — branches from develop (pulls latest first)
6. vibeops task ship → merge → sync — TASK lifecycle on github
   goodtek vibepulse %

여러분이라면 goodtek에 SSO를 지금 도입하시겠습니까?

솔직히 말하면, SSO라는 단어는 꽤 매력적입니다.

서비스가 여러 개로 나뉘기 시작하면 이런 생각이 바로 듭니다.

“로그인을 하나로 묶어야 하지 않을까?”

현재 goodtek이 가려는 구조를 보면 더 그렇습니다.

• goodtek.xyz — 메인 웹사이트
• blog.goodtek.xyz — Ghost 블로그
• community.goodtek.xyz — NodeBB 커뮤니티
• notes.goodtek.xyz — 공개 노트 / 개발 로그
• app.goodtek.xyz — 나중에 SaaS 앱들

이렇게 보면 SSO 방향 자체는 맞아 보입니다.

웹사이트, 블로그, 커뮤니티, 노트, SaaS 앱이 하나의 생태계로 묶이는 그림이니까요.
사용자 입장에서도 한 번 로그인해서 여러 서비스를 오가는 경험은 분명 좋습니다.

그런데 여기서 질문이 하나 생깁니다.

지금 goodtek이 해결해야 할 가장 중요한 문제가 정말 “통합 로그인”일까요?

저는 이 지점에서 조금 멈췄습니다.

SSO가 필요한가보다 중요한 질문

SSO가 필요한지 아닌지만 보면 답은 쉽습니다.

언젠가는 필요할 수 있습니다.

문제는 “언젠가”가 아니라 지금입니다.

지금 Keycloak 같은 중앙 인증 서버를 직접 붙이면, 인증은 단순 기능이 아니라 하나의 운영 대상이 됩니다.

로그인만 되는 게 아닙니다.

• 세션 관리
• 리프레시 토큰
• 이메일 인증
• 비밀번호 초기화
• OAuth 설정
• 백업
• 업그레이드
• 장애 대응
• 보안 패치
• 운영 모니터링

이 모든 게 따라옵니다.

처음에는 “로그인 통합하면 깔끔하겠다”로 시작했는데, 어느 순간 인증 서버 자체가 또 하나의 제품이 될 수 있습니다.

문제는 SSO가 좋은 기술이냐가 아니라, 지금 인증이 goodtek의 핵심 병목이냐입니다.

지금 goodtek에 더 급한 것들

goodtek 입장에서는 이미 해야 할 일이 많습니다.

웹사이트를 만들고, 블로그를 운영하고, 커뮤니티를 키우고, 공개 노트를 정리하고, SaaS 앱을 만들고, CI/CD와 운영 자동화도 다듬어야 합니다.

이 상황에서 Keycloak까지 직접 운영하기 시작하면, 제품보다 인프라가 더 무거워질 수 있습니다.

제 기준으로 보면 지금은 이렇게 나누는 게 더 현실적입니다.

영역 지금 선택 이유
웹사이트 로그인 없음 랜딩, SEO, AdSense, 연결 구조가 먼저
Ghost 블로그 Ghost 기본 멤버 뉴스레터와 구독 기능이 이미 있음
NodeBB 커뮤니티 자체 로그인 + 소셜 로그인 초기 커뮤니티에는 충분함
Notes 공개 문서 신뢰 자산과 개발 로그 역할
SaaS 앱 앱 자체 인증 또는 SaaS형 인증 실제 인증이 필요한 핵심 영역

즉, 모든 곳에 중앙 인증을 먼저 깔기보다 로그인이 진짜 필요한 곳부터 가볍게 시작하는 방식입니다.

Keycloak이 틀렸다는 말은 아닙니다

여기서 오해하면 안 되는 게 있습니다.

저는 Keycloak이 나쁘다고 생각하지 않습니다.

오히려 특정 시점이 오면 굉장히 좋은 선택이 될 수 있습니다.

예를 들면 이런 상황입니다.

• SaaS 앱이 여러 개 생긴다
• 커뮤니티 계정과 SaaS 계정을 반드시 하나로 묶어야 한다
• 조직/팀 단위 계정이 필요하다
• RBAC, 그룹, 역할 관리가 복잡해진다
• 고객사별 SSO 요청이 들어온다
• SAML, OIDC 같은 B2B 요구사항이 생긴다
• 자체 호스팅을 유지해야 하는 명확한 이유가 있다

이 정도까지 가면 이야기가 달라집니다.

그때는 Keycloak이 단순한 오버엔지니어링이 아니라 필요한 기반 인프라가 될 수 있습니다.

하지만 지금이 “나중에 필요할 것 같으니 미리 붙이자”에 가깝다면, 저는 조금 빠르다고 봅니다.

지금은 설계상 여지만 남기기

제가 생각하는 현실적인 선택은 이겁니다.

SSO를 완전히 무시하지는 않되, 지금 당장 운영하지는 않는다.

예를 들어 SaaS 앱의 DB 설계에서 나중에 외부 IdP로 옮길 수 있는 여지만 남깁니다.

users
id
email
name
avatar_url
provider
provider_account_id
created_at
accounts
user_id
provider
provider_account_id
access_token
refresh_token
memberships
user_id
product
role
status

이 정도만 해두면 나중에 Keycloak, Authentik, Zitadel, Auth0, Clerk 같은 선택지로 갈 때 완전히 막히지는 않습니다.

처음부터 중앙 인증 서버를 운영하는 것과, 나중에 옮길 수 있게 데이터 구조를 열어두는 것은 다릅니다.

저는 후자가 지금 goodtek에 더 맞다고 봅니다.

지금 필요한 건 완성된 통합 인증 시스템이 아니라, 나중에 통합할 수 있는 느슨한 구조입니다.

제 결론

제 결론은 이렇습니다.

지금 goodtek은 SSO를 도입하지 않는 쪽이 맞다.

조금 더 정확히 말하면,

SSO 방향은 고려하되, Keycloak 같은 중앙 인증 서버를 지금 직접 운영하지는 않는다.

현재 단계에서는 이렇게 가는 게 가장 현실적이라고 봅니다.

• 웹사이트: 로그인 없음
• 블로그: Ghost 기본 멤버 기능
• 커뮤니티: NodeBB 기본 로그인 + Google/GitHub 로그인
• Notes: 공개 운영
• SaaS 앱: 앱 자체 인증 또는 Better Auth / Auth.js / Supabase Auth / Clerk 같은 가벼운 인증

그리고 실제로 커뮤니티와 SaaS가 연결되고, 결제/권한/등급/조직 계정이 얽히기 시작하면 그때 SSO를 진지하게 검토합니다.

그때 Keycloak을 붙여도 늦지 않다고 생각합니다.

오히려 지금은 콘텐츠, 커뮤니티, 제품이 먼저입니다.

인증 시스템이 아무리 잘 되어 있어도 들어올 사용자가 없으면 운영할 것도 없습니다.
반대로 사용자가 생기고 서비스 간 연결이 진짜 필요해지면, 그때의 SSO는 훨씬 명확한 이유를 갖게 됩니다.

여러분은 어떻게 생각하시나요?

여러분이라면 goodtek 같은 구조에서 SSO를 지금 도입하시겠습니까?

아니면 일단 각 서비스를 독립적으로 운영하고, SaaS 앱에만 가벼운 인증을 붙인 뒤 나중에 통합하시겠습니까?

특히 궁금한 건 이 부분입니다.

초기부터 SSO를 깔아두는 게 장기적으로 이득일까요, 아니면 지금은 오히려 제품보다 인프라를 키우는 선택일까요?

저는 지금 단계에서는 후자에 가깝다고 봅니다.
하지만 SSO를 초기에 깔아두고 나중에 덕을 본 경험이 있다면, 그 이야기도 들어보고 싶습니다.

Android에서 Obsidian으로 메모를 수정하고, Termux에서 Git으로 "pull", "commit", "push"를 해보면서 중요한 걸 하나 배웠습니다.

Git은 파일을 잘 합쳐주지만, 같은 파일의 같은 위치를 여러 기기에서 동시에 수정하면 자동으로 처리하기 어렵다는 점입니다.

예를 들어 PC에서 "content/backlog/tasks.md"를 수정하고 GitHub에 push했습니다.
그런데 Android에서도 같은 "tasks.md"를 수정한 상태에서 "git pull --rebase"를 실행하면 충돌이 날 수 있습니다.

GitHub: A → B
Android: A → C

Git은 GitHub의 최신 변경사항 "B" 위에 Android의 변경사항 "C"를 다시 얹으려고 합니다.

A → B → C

하지만 "B"와 "C"가 같은 파일, 같은 줄 근처를 수정했다면 Git은 어느 쪽 내용을 살려야 할지 판단하지 못합니다.

그래서 이런 충돌이 발생합니다.

CONFLICT (content): Merge conflict in content/backlog/tasks.md

이건 Git이 망가진 것이 아니라, 오히려 내용을 함부로 덮어쓰지 않기 위해 멈춘 것입니다.

동시에 수정하면 왜 어려운가

서로 다른 파일을 수정하면 Git이 대부분 자동으로 합칠 수 있습니다.

PC → content/blog/idea.md 수정
Android → content/backlog/tasks.md 수정

이 경우는 충돌 가능성이 낮습니다.

하지만 같은 파일을 양쪽에서 수정하면 충돌 가능성이 높아집니다.

PC → content/backlog/tasks.md 수정
Android → content/backlog/tasks.md 수정

특히 같은 줄 근처를 수정하면 Git은 사람이 판단해야 한다고 보고 멈춥니다.

결국 문제는 “Git을 못 써서”가 아니라, 하나의 파일을 여러 기기에서 동시에 편집하는 구조 자체가 충돌에 취약하다는 점입니다.

앞으로의 운영 원칙

Goodtek notes는 Android, PC, GitHub가 함께 쓰이는 구조입니다.

그래서 앞으로는 아래 원칙으로 운영하는 것이 좋겠습니다.

수정 전에는 먼저 받기
수정 후에는 바로 올리기

Android에서 작업할 때는 먼저 최신 상태를 받습니다.

pull-notes

그 다음 Obsidian에서 메모를 수정합니다.

수정이 끝나면 바로 올립니다.

sync-notes

PC에서 작업할 때도 마찬가지입니다.

git pull --rebase origin main

메모 수정

git add content
git commit -m "Update notes"
git push

핵심 흐름은 단순합니다.

받고 → 쓰고 → 올리기

파일을 쪼개면 충돌이 줄어든다

"tasks.md" 하나에 모든 백로그를 계속 적으면 충돌이 자주 날 수 있습니다.

특히 Android와 PC에서 자주 열어보는 파일이라면 더 그렇습니다.

그래서 하나의 큰 파일에 모든 걸 넣기보다, 역할별로 나누는 편이 좋습니다.

예를 들면 이렇게 나눌 수 있습니다.

content/backlog/
├── inbox.md
├── tasks.md
├── ideas.md
└── content-ideas.md

더 충돌을 줄이려면 날짜별 파일도 괜찮습니다.

content/backlog/daily/
├── 2026-06-03.md
├── 2026-06-04.md
└── 2026-06-05.md

또는 월별로 나눌 수도 있습니다.

content/backlog/
├── tasks-2026-06.md
├── ideas-2026-06.md
└── content-ideas-2026-06.md

이렇게 하면 PC와 Android가 같은 파일을 동시에 수정할 확률이 줄어듭니다.

Goodtek notes 추천 구조

Goodtek notes에서는 Android와 PC의 역할을 나누는 방식이 좋아 보입니다.

Android
→ 빠른 메모, 순간적으로 떠오른 생각 기록

PC
→ 정리, 편집, 블로그 글로 확장, 구조화

그래서 Android에서는 주로 "inbox.md"를 사용합니다.

content/backlog/inbox.md

생각난 것은 일단 여기에 빠르게 적습니다.

• 나중에 Android Git 동기화 글 블로그로 정리하기
• notes.goodtek.xyz 백로그 구조 정리하기
• sync-notes 충돌 방지 로직 개선하기

그리고 PC에서 시간이 날 때 정리합니다.

inbox.md
→ tasks.md
→ content-ideas.md
→ build-log
→ blog.goodtek.xyz 글

이렇게 하면 Android에서는 빠르게 기록하고, PC에서는 천천히 정리할 수 있습니다.

정리

이번에 배운 것은 단순한 Git 명령어가 아닙니다.

Obsidian 노트를 여러 기기에서 운영하려면 Git 충돌을 없애는 것보다, 충돌이 덜 나게 쓰는 구조를 만드는 것이 더 중요하다는 점입니다.

앞으로 Goodtek notes는 이렇게 운영합니다.

Android에서 쓰기 전 pull-notes
Android에서 쓴 후 sync-notes

PC에서 쓰기 전 git pull --rebase
PC에서 쓴 후 git push

Android는 inbox 중심
PC는 정리와 편집 중심

하나의 큰 파일보다 작은 파일 여러 개
동시에 같은 파일 수정하지 않기

결국 핵심은 이것입니다.

Git을 잘 쓰는 방법은 충돌을 잘 해결하는 것만이 아니다.
충돌이 덜 나는 기록 구조를 만드는 것이다.

Goodtek notes도 이런 작은 운영 원칙을 하나씩 쌓아가면서 더 오래 유지할 수 있는 기록 시스템으로 만들어가야겠습니다.

요즘 ● goodtek-web을 만들면서 계속 드는 생각이 있습니다.

“일단 만들고, 나중에 구조 잡으면 되지 않을까?”

초반에는 이 말이 꽤 합리적으로 들립니다.

너무 처음부터 완벽한 구조를 잡으려고 하면 속도가 안 나고, 아직 아무도 쓰지 않는 제품에 과한 시스템을 붙이는 것도 낭비처럼 보입니다.

저도 처음에는 일단 돌아가게 만드는 쪽에 가까웠습니다.

화면이 뜨고, 기능이 동작하고, 서버에 올라가면 일단 다음으로 넘어갔습니다.

그런데 계속 만들다 보니 생각이 조금 바뀌었습니다.

나중에 붙이는 게 생각보다 쉽지 않습니다.

배포 자동화든, CI/CD든, 브랜치 전략이든, 무중단 배포든 겉으로 보면 “나중에 붙이면 되는 것”처럼 보입니다.

하지만 실제로는 기존 구조를 꽤 많이 건드리게 됩니다.

배포 방식이 바뀝니다.
브랜치 흐름이 바뀝니다.
서버에 코드가 반영되는 방식이 바뀝니다.
환경 변수 관리 방식이 바뀝니다.
컨테이너를 재시작하는 방식도 바뀝니다.

이건 단순히 설정 파일 몇 개를 추가하는 일이 아니었습니다.

제품이 돌아가는 흐름 자체를 바꾸는 일에 가까웠습니다.

더 큰 문제는, 그때 이미 고객이 쓰고 있을 수도 있다는 점입니다.

고객이 사용하는 제품에 배포 구조를 크게 바꾸는 건 단순한 리팩토링이 아닙니다.

서비스가 중간에 멈출 수 있습니다.
예상하지 못한 502가 날 수 있습니다.
새 컨테이너가 정상적으로 뜨지 않을 수 있습니다.
롤백이 준비되어 있지 않으면 대응도 어려워집니다.

dev 환경에서는 괜찮습니다.

“잠깐 안 되네. 다시 보자.”

이렇게 넘길 수 있습니다.

하지만 고객이 돈을 내고 쓰는 production 환경에서는 다릅니다.

그 잠깐의 중단도 사용자 경험이 됩니다.
그리고 그 경험은 신뢰와 바로 연결됩니다.

그래서 이번에 ● goodtek-web에 Git Flow + GitHub Actions 기반 dev CI/CD를 먼저 붙였습니다.

흐름은 이렇게 잡았습니다.

task 브랜치
→ PR
→ CI 검증
→ develop 머지
→ dev 서버 자동 배포
→ health check

겉으로 보면 기능은 하나도 늘지 않았습니다.

사용자 화면이 좋아진 것도 아니고, 새로운 버튼이 생긴 것도 아닙니다.

하지만 제품을 계속 운영할 수 있는 기반은 조금 더 단단해졌습니다.

이번 작업의 목적은 “자동 배포 붙였다”가 아니었습니다.

나중에 고객이 쓰고 있는 제품 위에서 위험하게 구조를 갈아엎지 않기 위해, 지금 dev 환경에서 미리 흐름을 잡아두는 것이었습니다.

처음부터 모든 걸 완벽하게 만들 필요는 없다고 생각합니다.

하지만 나중에 붙이기 어려운 것들은 분명 있습니다.

배포 구조.
데이터 구조.
인증 구조.
권한 구조.
운영 환경.

이런 것들은 제품이 커지고 사용자가 생긴 뒤에 바꾸려면 비용이 커집니다.

그때는 코드만 바꾸는 게 아니라, 이미 사용 중인 서비스를 건드리는 일이 되기 때문입니다.

요즘은 그래서 이런 기준을 세우고 있습니다.

빠르게 만들어도 된다.
하지만 나중에 붙이면 제품을 흔들 수 있는 것들은 너무 늦기 전에 바닥을 깔자.

이번 dev CI/CD 작업도 그런 맥락이었습니다.

아직 완전한 무중단 배포까지 간 건 아닙니다.

하지만 다음 단계로 갈 수 있는 길은 열어뒀습니다.

앞으로는 이런 것들을 차근차근 붙여가야 합니다.

production 배포 workflow.
운영 배포 승인 절차.
GHCR 기반 이미지 배포.
blue/green 배포.
롤백 가능한 구조.

오늘도 화려한 기능은 아니었습니다.

하지만 나중에 고객이 쓰고 있는 제품 위에서 식은땀 흘리며 구조를 바꾸지 않기 위해, 지금 작은 dev 환경에서 먼저 연습하고 있습니다.

여러분은 어떤 것들이 **“나중에 붙이면 늦는 구조”**라고 생각하시나요?

최근 goodtek-web 첫 작업을 하면서 느낀 건,
AI가 코드를 빨리 만들어줄수록 작업 기준이 더 중요해진다는 점이었습니다.

예를 들면 이런 기준입니다.

• 작업 시작 전에 범위를 먼저 정한다
• 무엇을 하지 않을지도 함께 정한다
• 구현 전에 Plan을 남긴다
• 완료 기준과 테스트 결과를 기록한다
• 작업은 PR 단위로 닫는다

저는 이번에 Task → Plan → Build → Test → PR 흐름으로 정리해봤습니다.

여러분은 AI 코딩할 때 어떤 방식으로 프로젝트가 어지러워지는 걸 막고 계신가요?

좋았던 방식, 실패했던 방식, 아직 고민 중인 방식 모두 궁금합니다.

[블로그 글 확인하기]
https://t.co/WaaG9afLRf

SaaS를 만들다 보니 생각보다 빨리 고민하게 되는 게 있었습니다.

코드를 어디에 둘 것인가?

GitHub로 갈지, GitLab으로 갈지입니다.

처음에는 그냥 저장소 선택 정도로 생각했는데, 실제로는 브랜치 전략, 이슈 관리, PR/MR, CI/CD, 개발 서버 배포, 운영 서버 배포까지 전부 연결되더라고요.

제 기준에서는 현재 초기 1인 SaaS는 GitHub가 더 현실적이라고 보고 있습니다.

이유는 단순합니다.

GitHub는 개발자 생태계가 크고, 자료도 많고, 나중에 오픈소스로 공개하거나 빌드로그를 공유하기에도 좋습니다.

GitHub Actions만으로도 develop 브랜치 배포, main 브랜치 운영 배포 정도는 충분히 구성할 수 있고요.

반대로 GitLab은 조금 더 조직적인 DevOps 플랫폼에 가까운 느낌입니다.

자체 Runner를 운영하거나, private repo 중심으로 관리하거나, 보안·권한·CI/CD를 더 강하게 통제해야 하는 팀이라면 GitLab이 더 좋아 보입니다.

그래서 지금 제 생각은 이렇습니다.

초기에는 GitHub로 빠르게 시작하고,

팀이 커지거나 자체 Runner·보안·내부 DevOps 체계가 중요해질 때 GitLab을 다시 검토한다.

Goodtek 같은 1인/소규모 SaaS 프로젝트라면 일단은 GitHub가 맞는 선택 같다는 생각이 듭니다.

여러분은 어떻게 생각하시나요?

1인 개발이나 소규모 SaaS 기준으로 GitHub와 GitLab 중 어디를 더 선호하시나요?

GitHub Actions만으로 충분했는지, 아니면 GitLab CI/CD가 더 편했는지도 궁금합니다.

예전에는 아이디어를 빠르게 만들고, 작게 출시하고, 시장 반응을 보면서 개선하는 방식이 정석에 가까웠습니다.

그런데 요즘은 상황이 조금 달라진 것 같습니다.

바이브코딩, AI 코딩 도구, 노코드/로우코드 툴 덕분에 제품을 만드는 허들이 크게 낮아졌습니다. 예전에는 MVP 하나를 만드는 데 몇 주, 몇 달이 걸렸다면 지금은 며칠 만에 그럴듯한 제품을 만들 수 있습니다.

문제는 여기서 생깁니다.

너무 이른 단계에서 MVP를 공개하면 아이디어 자체가 노출됩니다. 그리고 누군가는 비슷한 서비스를 더 빠르게 만들거나, 심지어 더 좋은 기능을 붙여서 먼저 출시할 수도 있습니다.

그러면 질문이 생깁니다.

이제는 공개 MVP보다 비공개 MVP가 더 나은 전략일까요?

아니면 어설픈 MVP를 내기보다, 처음부터 어느 정도 완성도 있는 제품으로 출시하는 것이 맞을까요?

제 생각에는 MVP 방법론이 사라진 것은 아니고, “공개 MVP”의 의미가 바뀌고 있는 것 같습니다.

이제 중요한 것은 단순히 빨리 출시하는 것이 아니라,

누구에게 먼저 보여줄 것인가어디까지 공개할 것인가무엇을 숨기고 무엇을 검증할 것인가아이디어보다 실행력과 배포력을 어떻게 쌓을 것인가

이런 전략이 더 중요해진 것 같습니다.

특히 AI 시대에는 아이디어 자체보다 실행 속도, 사용자 이해, 브랜드, 커뮤니티, 배포 채널이 더 큰 차별점이 될 수 있다고 봅니다.

여러분은 어떻게 생각하시나요?

요즘 시대에도 공개 MVP가 여전히 맞을까요, 아니면 비공개 검증 후 완성도 있게 출시하는 쪽이 더 맞을까요?

안녕하세요. goodtek 커뮤니티를 시작합니다.

goodtek은 앞으로 AI 자동화와 SaaS 개발을 직접 실험하고, 그 과정을 블로그와 커뮤니티에 함께 기록해 나가려고 합니다.

블로그에는 조금 더 정리된 글을 올릴 예정입니다.

예를 들어 NodeBB 설치 방법, Caddy 설정, Podman Compose 구성, AI 자동화 아이디어 검증, SaaS 개발 과정처럼 나중에 다시 찾아볼 수 있는 내용을 글로 정리합니다.

커뮤니티는 그 글에서 끝나지 않는 이야기들을 이어가는 공간입니다.

블로그 글을 보고 따라 하다가 막힌 부분이 있거나, 더 좋은 방법이 있거나, 비슷한 아이디어를 함께 이야기하고 싶다면 이곳에서 편하게 남겨 주세요.

앞으로 Goodtek에서 다룰 주제는 이런 것들입니다.

• AI 자동화

• SaaS 만들기

• 브라우저 자동화

• n8n, Notion, Agent Workflow

• Docker, Podman, Caddy, PostgreSQL 같은 개발/운영 환경

• 블로그와 커뮤니티를 키워가는 과정

• 실패와 시행착오를 포함한 실제 운영 기록

처음부터 완벽한 커뮤니티를 만들기보다는, 직접 만들고 운영하면서 조금씩 다듬어 가려고 합니다.

질문, 의견, 피드백 모두 환영합니다.

goodtek 블로그와 커뮤니티가 함께 배우고 실험하는 공간이 되면 좋겠습니다.

감사합니다.