rclone으로 Google Drive에 리눅스 서버 자동 백업하기 (GnuPG 암호화·복구까지)

오늘 서버가 뻗었습니다. 서버는 언제든 다시 접근하지 못할 수 있습니다. Google Drive, rclone, GnuPG를 이용해 비용 부담 없이 백업하고 안전하게 복구하는 방법을 정리했습니다.

GSAP - 여러분의 웹사이트가 허전하신가요?

AI로 웹사이트를 만들었는데 어딘가 비슷하고 AI 티가 났습니다. 계속 수정하며 토큰만 쓰다가 레퍼런스 분석과 GSAP을 적용해봤더니 결과가 달라졌습니다. 직접 만들며 경험한 인터랙티브 웹 제작 이야기를 공유합니다.

AI 채팅창을 직접 만들어보니, 진짜 중요한 건 스트리밍이었다

GPT나 Claude처럼 답변이 실시간으로 올라오는 AI 채팅창은 어떻게 만들까? 직접 구현하면서 알게 된 LLM 스트리밍 구조와 SSE, WebSocket의 차이, 그리고 SSE를 선택한 이유를 정리했습니다.

바이브코딩 초보를 위한 Git 사용법: 명령어는 몰라도 이것만 알면 됩니다.

Git이 어렵게 느껴지는 바이브코딩 초보자를 위한 가이드. Git과 GitHub의 개념부터 gh CLI 설치, GitHub 인증, AI 에이전트에게 Git 관리를 맡기는 방법까지 쉽게 설명합니다.

바이브코딩에서 UI보다 중요한 UX, 어떻게 벤치마킹하고 관리할까?

UI는 쉽게 벤치마킹할 수 있지만 UX는 화면만 봐서는 알기 어렵습니다. 좋은 서비스의 사용자 흐름을 분석하고, 공통 UX 원칙을 UX.md로 자산화해 Cursor·Codex·Claude Code가 계속 참고하도록 만드는 방법을 정리했습니다.

AI 크롤러 전부 차단하면 손해? GPTBot·OAI-SearchBot·ClaudeBot robots.txt 설정 정리

AI 크롤러를 전부 차단하면 ChatGPT·Claude·Perplexity 검색과 답변에서 내 사이트가 노출될 기회까지 막을 수 있습니다. OAI-SearchBot, GPTBot, ClaudeBot 등 AI 봇을 검색·사용자 요청·모델 학습 목적으로 구분하고, robots.txt와 Rate Limit을 활용해 검색과 인용은 허용하면서 학습용 수집은 선택적으로 차단하는 방법을 정리합니다.

바이브코딩할 때 꼭 알아야 할 로그인 저장소 - LocalStorage, Cookie, HttpOnly Cookie 차이

AI에게 로그인 기능을 맡겼다면 꼭 확인해야 할 보안 상식! LocalStorage, Cookie, HttpOnly Cookie의 차이와 아이디 저장, Access Token, Refresh Token은 어디에 저장해야 하는지 실제 서비스 관점에서 쉽게 정리했습니다. 로그인은 '되는 것'보다 '안전하게 되는 것'이 더 중요합니다.

AIMetaClean 빌드인퍼블릭: 기술 스택과 아키텍처 결정

AI Meta Clean의 기술 스택과 아키텍처를 AI와 하나씩 비교하며 결정했습니다. Next.js, NestJS, BullMQ, PostgreSQL, Redis, MinIO부터 파일 폐기와 보안 원칙까지 문서화한 과정을 공개합니다.

코드부터 짜지 않았습니다: AI와 시작한 첫 제품 기획

AI Meta Clean의 첫 번째 TASK로 제품의 목표와 사용자, MVP 범위, 제외할 기능을 정리했습니다. AI와 질문을 주고받으며 기획을 문서화하고, vibeops로 브랜치 생성부터 커밋, PR, 병합까지 마친 과정을 공개합니다.

AIMetaClean 빌드인퍼블릭: 바이브코딩 프로젝트 환경 하네스 세팅

AI MetaClean을 아이디어 단계부터 기획, 개발, 출시, 홍보까지 전부 공개합니다. 이번 글에서는 GitHub와 VibeOps를 활용해 PC와 모바일 어디서든 이어서 바이브코딩할 수 있는 프로젝트 환경을 세팅합니다.

GitHub이냐 GitLab이냐: 바이브코더가 자동화까지 챙겨야 하는 이유

GitHub과 GitLab은 단순한 코드 저장소가 아닙니다. 바이브코더가 꼭 알아야 할 Git, CI/CD, GitHub Actions, GitLab CI/CD, 자체 러너, 무료 사용량과 자동 배포 선택 기준을 쉽게 정리했습니다.

[빌드인퍼블릭] 진짜 사람 사진은 실패했고, 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으로 영상을 완성한 경험을 담았습니다.

배포와 운영

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로 일관성을 유지하면서도 기능 범위와 연결 구조를 더 선명하게 확인한 프론트 구현 기록입니다.