16장. 3~4주차: 품질과 배포

1~2주차가 "정말 이걸 만들 가치가 있나?"를 확인하는 시간이었다면, 3~4주차는 질문이 달라진다. 이제는 "이걸 남에게 써 보라고 내밀 수 있나?"를 물어야 한다. 여기서 많은 솔로 빌더가 한 번 더 착각한다. 배포 버튼만 누르면 끝이라고 생각하는 것이다. 하지만 실제로는 그 반대다. 배포는 완성의 도장이 아니라 운영의 출발선이다.

프로토타입 단계에서는 한 번 돌아가면 감동이다. 서비스 단계에서는 열 번 중 열 번 비슷하게 돌아가야 안심이다. 사용자는 당신의 구조적 우아함보다, 로그인되는지, 저장이 되는지, 갑자기 에러가 나지 않는지에 더 민감하다. 그래서 3~4주차의 핵심은 기능 추가가 아니라 신뢰성 추가다.

이 장에서는 네 가지를 다룬다. 테스트를 어떻게 자동 생성하고 어디까지 믿을지, 보안 점검을 어떻게 습관이 아니라 시스템으로 만들지, GitHub Actions와 Claude Code 기반 자동화로 배포 루프를 어떻게 세울지, 그리고 Vercel·Cloudflare·Lightsail 중 무엇을 고를지를 살펴본다. 중요한 것은 하나다. 혼자 만들더라도, 혼자 믿지 말 것. 파이프라인이 대신 의심하게 만들어야 한다.

16.1 테스트 자동 생성과 커버리지

솔로 빌더가 테스트를 싫어하는 이유는 대개 같다. 시간이 없다. 기능도 아직 덜 만들었다. 그리고 솔직히, 지금 당장 눈앞의 버그 하나 고치는 게 더 급하다. 다 맞는 말이다. 하지만 테스트는 "나중에 여유 생기면 하는 일"이 아니다. 오히려 나중에 내가 지금의 나를 덜 원망하게 만드는 장치에 가깝다.

여기서 중요한 건 처음부터 거대한 테스트 왕국을 세우는 게 아니다. 테스트도 제품처럼 얇게 시작해야 한다. AI 에이전트가 섞인 시스템의 테스트는 보통 네 층으로 생각하면 이해가 쉽다.¹

• 가장 아래는 유틸 함수, 검증 로직, 포맷터, 권한 체크처럼 빠르게 돌 수 있는 단위 테스트다.

• 그 위는 한 기능이 의도한 제약을 지키는지 보는 동작 테스트다. 예를 들어 "로그인하지 않은 사용자는 생성 API를 호출할 수 없다" 같은 규칙이다.

• 그 위는 여러 조각이 이어지는 통합 테스트다. 폼 입력, API 호출, DB 저장, 다시 조회까지 한 줄 흐름이 붙는지 본다.

• 맨 위는 소수의 E2E 또는 회귀 테스트다. 느리고 비싸지만, 실제 사용자 흐름이 깨졌는지 잡아낸다.

이 피라미드의 장점은 분명하다. 가장 자주 깨지는 것은 아래에서 싸게 잡고, 정말 비싼 문제만 위에서 확인한다. 솔로 빌더에게 이 구조가 중요한 이유는 시간이 없어서다. 모든 걸 E2E로 확인하면 멋있어 보이지만, 금방 귀찮아지고 결국 아무것도 안 돌리게 된다.

Claude Code는 여기서 아주 좋은 "초안 생성기"가 된다. changed files와 커버리지 리포트를 읽혀 주고, 빠진 분기만 메우는 테스트를 먼저 쓰게 하면 된다. 이미 여러 CI 패턴에서 AI가 변경 파일의 커버리지를 보고 테스트 초안을 생성하는 흐름이 실전적으로 쓰이고 있다.² 다만 기억할 점이 있다. AI가 쓴 테스트는 정답이 아니라 첫 번째 제안이다. 특히 다음 두 종류의 테스트는 사람이 꼭 봐야 한다.

• 테스트가 구현 세부사항만 확인하고 있는지

• 정말 중요한 실패 경로를 빼먹고 있는지

• 통과만 시키기 위한 의미 없는 커버리지 패딩인지

커버리지는 숫자라서 달콤하다. 90%라고 나오면 갑자기 모든 게 괜찮아 보인다. 하지만 솔로 빌더에게 더 중요한 질문은 따로 있다. 핵심 경로가 보호되고 있는가? 예를 들어 당신이 만드는 SaaS가 피드백 정리 도구라면, 진짜 중요한 것은 이런 것들이다.

• 인증이 깨지지 않는가

• 핵심 생성 흐름이 저장까지 이어지는가

• 요금제 제한이나 권한 제한이 새 코드에서 우회되지 않는가

• 실패했을 때 사용자에게 최소한 이해 가능한 메시지가 나오는가

이 네 가지를 잡는 테스트가 있다면, 화면의 작은 문구가 바뀌는 것보다 훨씬 큰 안심을 준다.

실전에서는 이렇게 요청하면 좋다.

변경된 파일 기준으로 테스트 누락을 찾아줘. Vitest를 사용하고, 기존 패턴을 따르되 의미 없는 커버리지 채우기는 하지 마. 정상 경로뿐 아니라 실패 경로와 권한 경계도 포함해줘. 마지막에는 어떤 위험을 테스트가 아직 못 덮는지도 적어줘.

여기서 마지막 한 문장이 중요하다. AI는 테스트를 써 줄 수는 있지만, 무엇을 아직 모르는지까지 자동으로 완벽하게 알려주진 못한다. 그래서 항상 "남은 구멍"을 말하게 해야 한다.

솔로 빌더에게 추천하는 최소 테스트 루틴은 간단하다.

• 기능 하나를 끝낼 때마다 단위 테스트부터 붙인다.

• PR 전에는 changed files 기준 커버리지를 확인한다.

• 메인 브랜치 머지 전에는 핵심 사용자 흐름만 E2E로 확인한다.

• 느린 회귀 테스트는 밤에 돌린다.¹

이렇게 하면 테스트가 개발을 막지 않는다. 오히려 개발을 덜 두렵게 만든다. 그게 포인트다.

16.2 보안 검토 자동화

품질 문제가 "망가진 기능"이라면, 보안 문제는 "잘 동작하는데 위험한 기능"이다. 이게 더 무섭다. 왜냐하면 배포 직후에는 겉보기로 멀쩡해 보이기 때문이다.

특히 AI와 함께 코딩할 때는 더 그렇다. 에이전트는 대개 작동하는 코드를 빠르게 만들어 준다. 하지만 작동과 안전은 같은 말이 아니다. 로그인 API가 잘 돌아간다고 해서 권한이 올바른 것은 아니고, 검색 기능이 잘 동작한다고 해서 SQL 인젝션에 안전한 것도 아니다.

그래서 보안은 "출시 직전에 한 번 보는 체크리스트"가 아니라, PR마다 자동으로 걸리는 문지기여야 한다. 작은 SaaS라면 세 겹만 있어도 꽤 튼튼해진다.

첫째, 정적 분석과 의존성 검사를 건다. 위험한 라이브러리 버전, 하드코딩된 비밀값, 뻔한 취약 패턴은 사람 눈보다 도구가 잘 잡는다.

둘째, AI 리뷰를 따로 돌린다. 단순 스타일 리뷰가 아니라, XSS, SQL Injection, 인증/인가 누락, 환경변수 노출, 오픈 리다이렉트 같은 보안 항목만 보게 한다. PR 기반 AI 리뷰는 실제로 가장 먼저 도입하기 좋은 패턴으로 여겨진다. 코드를 바꾸지 않고, 차이만 읽고, 위험을 댓글로 남기기 때문이다.²

셋째, 고위험 영역만큼은 인간 검토를 남긴다. 결제, 관리자 권한, 데이터 내보내기, 조직 간 데이터 분리 같은 부분이다. 여기서는 "CI 통과 = 안전"이라고 생각하면 안 된다.

솔로 빌더 제품에서 특히 자주 터지는 실수는 네 가지다.

• SQL을 문자열로 이어 붙인다.

• 서버 전용 환경변수를 클라이언트 번들에 흘린다.

• 로그인 체크는 있는데 리소스 소유권 검사가 없다.

• 에러 메시지에 내부 구조를 너무 자세히 보여 준다.

예를 들어 Supabase나 ORM을 쓴다고 안심하면 안 된다. ORM을 써도 raw query 한 줄이면 다시 위험해진다. 인증을 붙였다고 안심해도 안 된다. "로그인한 사용자"와 "이 데이터를 볼 권한이 있는 사용자"는 전혀 다른 말이기 때문이다.

Claude Code에게는 이런 식으로 시킬 수 있다.

이 PR diff를 보안 관점으로만 리뷰해줘. XSS, SQL Injection, SSRF, 인증/인가 누락, 환경변수 노출, 민감정보 로깅 여부를 중심으로 보고, 실제 악용 시나리오를 짧게 붙여줘. 위험도는 high / medium / low로 분류하고, 수정 우선순위를 제안해줘.

이 프롬프트가 좋은 이유는 "문제가 있나?"가 아니라 "어떻게 터지나?"를 묻기 때문이다. 공격 시나리오가 붙는 순간, 추상적인 걱정이 실제 우선순위로 바뀐다.

자동 수정은 신중하게 써야 한다. 린트, import 정리, 단순 null 체크 같은 저위험 수정은 자동화해도 괜찮다. 하지만 인증, 권한, 결제, 데이터 삭제 로직은 자동 수정 후 자동 머지까지 가면 안 된다. 이 구간은 속도보다 사고 방지가 훨씬 싸다.

정리하면 보안 자동화의 목표는 "취약점을 0으로 만들기"가 아니다. 그건 거짓말에 가깝다. 진짜 목표는 평범한 실수를 프로덕션까지 못 가게 막는 것이다. 혼자 만들수록 이 방어막은 더 필요하다. 대신 봐 줄 동료가 없기 때문이다.

16.3 GitHub Actions + Claude Code GHA로 CI/CD 구축

이제 품질과 보안이 어느 정도 자동화됐다면, 다음은 그것들을 습관이 아니라 파이프라인으로 고정할 차례다. 여기서 GitHub Actions가 가장 좋은 이유는 단순하다. 솔로 빌더에게는 새 도구를 하나 더 배우는 비용도 꽤 크다. 이미 GitHub를 쓰고 있다면, 가능한 한 그 안에서 끝내는 편이 낫다.

에이전트가 들어간 CI/CD의 핵심은 "AI가 알아서 다 한다"가 아니다. 오히려 반대다. 어디까지 자동으로 맡기고, 어디서 사람이 멈춰 세울지를 명확히 정하는 것이 핵심이다. 요즘의 에이전틱 워크플로우는 보통 이벤트 기반으로 움직인다. 이슈, PR, 스케줄, 코멘트 같은 트리거가 생기면 에이전트가 코드를 읽고, 수정하거나 리뷰하고, PR을 만들고, 그 뒤는 CI와 사람이 받는 구조다.³

솔로 빌더라면 처음부터 거창하게 갈 필요 없다. 아래 3단계면 충분하다.

• PR이 열리면 린트, 타입체크, 테스트, 시크릿 스캔, AI 리뷰를 실행한다.

• main에 머지되면 빌드하고 배포한다.

• 배포 직후 스모크 테스트를 돌려 실패하면 즉시 알림을 보낸다.

여기서 중요한 것은 PR 단계다. 많은 사람이 배포 자동화부터 생각하지만, 사실 더 큰 절약은 머지 전에 문제를 잡는 것에서 나온다. PR 단계에서 에러를 막으면, 배포 실패와 롤백과 사용자 사과문까지 한꺼번에 줄어든다.

가장 실용적인 구성은 이런 식이다.

name: ci

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - checkout
      - install
      - lint
      - typecheck
      - test
      - security-scan
      - ai-review

이건 멋진 YAML이 아니라, 그냥 혼자서도 유지 가능한 질서다. 여기에 Claude Code를 붙일 때는 욕심내지 말고 두 역할만 맡기면 충분하다.

첫째, 리뷰어 역할이다. diff를 읽고 버그·보안·성능 리스크를 코멘트로 남긴다.²

둘째, 실패 분석가 역할이다. 테스트나 빌드가 깨졌을 때 로그를 읽고 원인을 요약한다. 자동 수정까지 붙일 수는 있지만, 초반에는 시도 횟수를 제한하는 게 좋다. 두 번 고쳐도 안 되면 사람에게 넘기는 식이 안전하다.²

이 흐름을 잘 설계하면, 혼자 일해도 마치 작은 팀처럼 움직인다. 내가 자는 동안 테스트가 돌고, 출근 전에 "무엇이 깨졌는지" 요약이 와 있고, 수정이 간단하면 에이전트가 초안을 만들어 둔다. 이게 솔로 빌더가 얻는 비대칭 우위다. 시간을 늘리는 건 아니지만, 맥락 전환 비용을 확 줄인다.

배포 파이프라인도 하나의 원칙만 지키면 훨씬 덜 흔들린다. 빌드한 산출물을 한 번만 만들고, 같은 산출물을 환경별로 밀어라. staging과 production에서 다른 걸 다시 빌드하면, "내 컴퓨터에서는 됐는데"의 조금 더 세련된 버전만 생긴다.

Cloudflare Workers를 배포한다면 GitHub Actions에서 Wrangler 액션을 이용해 main 푸시 시 자동 배포하는 흐름이 공식 문서에도 정리되어 있다. 이때 API 토큰과 계정 ID는 꼭 최소 권한으로 좁혀야 한다.⁵ 즉, 자동화는 강할수록 좋지만, 자격 증명은 좁을수록 좋다.

배포 직후에는 꼭 스모크 테스트를 둬라. 스모크 테스트는 거창하지 않아도 된다.

• 홈페이지가 200을 반환하는지

• 로그인 페이지가 열리는지

• 핵심 POST 요청이 성공하는지

• DB 연결 에러가 없는지

이 네 가지만 확인해도 "배포는 성공했지만 서비스는 죽어 있는" 황당한 상황을 많이 줄일 수 있다.

그리고 마지막으로 하나. 처음부터 모든 브랜치, 모든 커밋, 모든 스케줄에 에이전트를 붙이지 마라. 비용과 노이즈가 먼저 터진다.³ 수동 트리거나 PR 기반부터 시작하고, 진짜 이득이 확인된 자동화만 남겨야 한다. 자동화는 많을수록 좋은 게 아니라, 고장 났을 때 내가 이해할 수 있을 만큼만 좋은 것이다.

16.4 Vercel, Cloudflare, Lightsail 배포 비교

이제 어디에 올릴지 고를 차례다. 솔로 빌더는 이 질문을 기술 취향으로 풀면 안 된다. 정답은 "제일 멋진 인프라"가 아니라 내가 다음 달에도 감당할 수 있는 인프라다.

세 가지를 아주 현실적으로 보자.

세 플랫폼을 한 문장으로 요약하면 이렇다.

Vercel은 가장 빨리 내보내는 선택, Cloudflare는 가장 넓게 가까이 보내는 선택, Lightsail은 가장 많이 책임지는 대신 가장 많이 통제하는 선택이다.

솔로 빌더 관점에서는 보통 이렇게 고르면 실수가 적다.

• Next.js + Supabase + 일반적인 SaaS라면 먼저 Vercel을 본다.

• 전 세계 사용자에게 짧은 응답시간이 중요하고, 엣지 친화적인 구조라면 Cloudflare를 본다.

• 백그라운드 워커, 커스텀 서버 설정, 고정비 예측 가능성이 더 중요하면 Lightsail을 본다.

특히 Vercel은 빠른 프리뷰 배포와 프런트엔드 중심 개발에 강하다. 사이드 프로젝트에서는 이 속도가 엄청난 무기다. 링크 하나로 바뀐 화면을 확인하고, 친구에게 보내고, 다시 고칠 수 있다. "배포"가 이벤트가 아니라 일상이 된다.

반면 Cloudflare는 AI 기능을 붙일 때도 생각보다 매력적이다. Workers AI는 서버리스 방식으로 모델 추론을 붙일 수 있고, Cloudflare 네트워크 가까이에서 실행되기 때문에 지연시간 측면에서 장점이 있다.⁶ 다만 이 선택은 편리한 Node 서버를 그대로 올리는 선택이 아니라, 런타임 사고방식을 조금 바꾸는 선택이다.

Lightsail은 느낌이 다르다. 이쪽은 "플랫폼이 알아서 해준다"보다 "내가 직접 챙긴다"에 가깝다. 대신 얻는 것도 분명하다. 장기 실행 프로세스, cron, Redis, Nginx, 세밀한 네트워크 제어, 예측 가능한 월 비용 같은 것들이다.⁷ 수익화형 사이드 프로젝트나 백오피스 도구처럼 서버가 꽤 오래 살아 있어야 하는 제품에는 오히려 마음이 편할 수 있다.

핵심은 멋이 아니라 운영 피로도다. 밤 11시에 배포가 실패했을 때, 당신이 고칠 수 있는 플랫폼이 좋은 플랫폼이다.

배포는 끝이 아니라 운영의 시작점

3~4주차의 마지막 목표는 "배포했다"가 아니다. "배포하고도 다시 고칠 수 있는 상태를 만들었다"가 목표다. 이 차이는 정말 크다.

배포 직후 최소한 이것들은 갖춰 두는 편이 좋다.

• 에러를 볼 수 있는 로그 경로

• 실패 시 되돌릴 수 있는 배포 절차

• 핵심 흐름을 확인하는 스모크 테스트

• 비밀값과 환경변수 관리 규칙

• DB 백업 또는 복구 계획

이 다섯 가지가 있으면 서비스는 아직 작아도 제법 "운영되는 물건"처럼 변한다. 반대로 기능이 아무리 많아도 이게 없으면, 제품이라기보다 운 좋은 데모에 가깝다.

솔로 빌더에게 배포는 감동의 순간이기도 하다. 도메인을 붙이고, 첫 사용자에게 링크를 보내고, 내 손으로 만든 것이 인터넷 위에 살아 움직이는 걸 보는 일은 꽤 짜릿하다. 하지만 그 짜릿함이 오래 가려면 다음 문장이 따라와야 한다.

"망가져도 내가 어디를 봐야 하는지 안다."

그 상태까지 왔다면, 이제 당신의 사이드 프로젝트는 단순한 프로토타입을 넘어선다. 기능을 만든 사람이 아니라, 서비스를 운영하기 시작한 사람이 된다. 그리고 그 순간부터 배포는 종착점이 아니라, 진짜 제품 만들기의 첫날이 된다.

참고

¹CI/CD for AI Agents: Building a Proper Testing and Deployment Pipeline for Agentic Systems

²CI/CD with AI Agents: Pipeline Integration Patterns

³Agentic Workflows Explained: How AI Agents Are Changing CI/CD Pipelines

⁴Deploy AI at the speed of frontend

⁵GitHub Actions · Cloudflare Workers docs

⁶Overview · Cloudflare Workers AI docs

⁷Amazon Lightsail Documentation