AI가 배포와 설정을 엮는 법
여기서 바이브 코딩이 빛난다. 배포 설정은 정밀하고, 잘 문서화되어 있으며, 보일러플레이트가 많은 — 바로 AI가 잘하는 종류의 일이다. 당신이 지시하고, AI가 쓴다.
효과적인 프롬프트는 이렇게 들린다:
- "이 Node 앱에
Dockerfile과, 그것을 배포할 Railway 설정을 추가해줘." - "
main에 푸시할 때마다dist/폴더를 Cloudflare Pages에 배포하는 GitHub Actions 워크플로를 작성해줘." - "서버리스 함수에서 콜드 스타트 타임아웃이 나고 있어 — 무엇이 문제일 가능성이 높고 설정을 어떻게 고치면 될까?"
여기 AI가 당신을 위해 만들어 줄 종류의 파일이 있다 — 코드를 푸시할 때마다 정적 사이트를 자동으로 배포하는 배포 워크플로:
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci && npm run build
- name: Publish to Cloudflare Pages
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CF_API_TOKEN }}
command: pages deploy dist --project-name=my-app
이 문법을 외울 필요는 없다. 그것이 무엇을 하는지 알아보면 된다: main에 푸시할 때마다, 코드를 체크아웃하고, 빌드하고, 결과를 게시한다. 무언가 깨지면 에러를 AI에게 다시 붙여넣고 설정을 고쳐달라고 요청하라.
많은 빌더는 처음엔 GitHub Actions 파일을 아예 건너뛰고 그냥 자기 터미널에서 명령 하나로 배포한다. 그게 첫날에 무언가를 라이브로 보기에 가장 빠른 길인 경우가 많다. 같은 Cloudflare Pages 배포를 명령줄에서 하면 이렇게 생겼다:
# install the CLI once
npm install -g wrangler
# build your site, then push the output folder live
npm run build
wrangler pages deploy dist --project-name=my-app
첫 실행은 브라우저로 로그인하라고 요청할 것이고, 그 후로는 명령 하나면 된다. 트레이드오프는 단순하다: 터미널 명령은 "지금 당장 출시"에 훌륭하고, GitHub Actions 파일은 "영원히 자동으로 출시"에 훌륭하다. 대부분의 프로젝트는 전자로 시작하고 배포가 일상이 되면 후자를 더한다. 당신이 어느 지점에 있든 맞는 것을 AI에게 요청하라.
진짜 고통을 덜어주는 몇 가지 지시 요령:
- AI가 행동하기 전에 설명하게 하라. "설정을 쓰기 전에, 이 프로젝트에 어떤 호스팅 유형이 맞고 왜 그런지 말해줘." 이것은 과도한 엔지니어링을 일찍 잡아낸다.
- 비밀(secret)을 코드 밖에 둬라. API 키와 비밀번호는 플랫폼의 환경 변수 / 시크릿 저장소에 넣고, 커밋하는 파일에는 절대 넣지 마라. 위의
CF_API_TOKEN처럼 시크릿 참조를 쓰도록 AI에게 요청하라. - 일찍 배포하고, 자주 배포하라. 첫날에 "hello world"를 라이브로 올려라. 처음부터 작동해 온 파이프라인은 출시 시점에 급조한 것보다 디버깅하기 훨씬 쉽다.
- 롤백 시나리오를 미리 물어라. "이 배포가 망가지면, 작동하던 버전으로 어떻게 되돌리지?" 좋은 플랫폼은 이전 배포들을 클릭 한 번 거리에 둔다. 되돌리기 버튼이 존재한다는 걸 필요해지기 전에 알아두면 새벽 2시의 패닉이 어깨 으쓱으로 바뀐다.