알아서 공개되는 구조를 만든다
사람이 손으로 공개하는 한 통째로 맡기기는 완성되지 않습니다. GitHub Actions로 자동 테스트·자동 배포·프리뷰 환경을 AI에게 만들게 하면 내 일은 승인 버튼을 누르는 것만 남습니다.
앞 글 전부 통째로 넘긴다에서 Issue를 넘기면 풀 리퀘스트가 돌아오는 흐름을 만들었습니다. 이 글에서는 여기서 한번 손을 멈추고, 승인하면 알아서 공개되는 구조(CI/CD)를 AI에게 만들게 합니다. 이 구조가 완성되면 다음 글 동시에 여러 개 굴린다에서 여러 Issue를 동시에 돌릴 준비가 끝납니다.
앞 글에서 Issue를 넘기면 풀 리퀘스트가 돌아오는 흐름이 생겼습니다.
여기서 한번 손을 멈추고 구조를 하나 만듭니다. 승인하면 알아서 공개되는 구조입니다. 업계에서는 CI/CD라고 부르는데 이름은 안 외워도 됩니다.
통째로 넘기기가 성립하는 조건
왜 지금 이 얘기를 할까요. 이유는 분명합니다.
사람이 손으로 공개 작업을 하는 한, 통째로 맡기기는 완성되지 않습니다.
상상해 보세요. AI가 아무리 빨리 만들어도 공개할 때마다 절차서를 보면서 10분짜리 작업을 해야 한다면. 반드시 게을러집니다. "오늘은 피곤하니까 공개는 주말에 몰아서" — 이렇게 만든 게 공개되지 않은 채 쌓여 갑니다.
개선 루프를 돌린다에서 자세히 얘기하겠지만 공개되지 않은 것에서는 아무 배움도 안 생깁니다. 여러분의 귀찮음이 루프 전체의 병목이 되는 겁니다.
그래서 공개에서 여러분의 손을 뺍니다.
GitHub Actions는 "올리면 알아서 해 주는 담당"
도구는 딱 둘 — Claude Code와 GitHub에서 "책상에 사는 요정"이라고 소개한 GitHub Actions 차례입니다.
구조는 이렇습니다. 리포지토리에 "이럴 땐 이렇게 해"라는 절차서를 놔두면 GitHub가 그대로 자동으로 움직여 줍니다.
바이브 코딩에서 쓰는 절차는 사실상 두 개뿐입니다.
| 계기 | 자동으로 하는 일 |
|---|---|
| AI가 풀 리퀘스트를 올리면 | 망가진 데 없는지 자동으로 검사한다 (테스트) |
| 내가 풀 리퀘스트를 승인하면 | 실서비스로 배포한다 |
이게 돌아가면 여러분의 작업은 정말로 "승인 버튼을 누른다"뿐이 됩니다. 누르고 몇 분 뒤엔 변경이 실서비스에 반영돼 있습니다. 풀 리퀘스트를 만들고 머지하는 손놀림은 Git 조작 자동화에 정리돼 있으니, 승인 버튼이 어디 있는지 헷갈리면 거기서 확인하세요.
망가져도 되는 자리를 확보한다 (프리뷰 환경)
있으면 세계가 바뀌는 구조가 하나 더 있습니다. 프리뷰 환경입니다.
풀 리퀘스트가 올라온 시점에 그 변경을 반영한 "임시 서비스"가 자동으로 뜨고 URL이 발급되는 구조입니다.
전부 통째로 넘기는 글에서 "돌아오면 실제로 돌려 본다"고 했죠. 프리뷰 환경이 있으면 이 확인이 "온 URL을 폰으로 연다"로 끝납니다. 소파 위에서, 출퇴근 지하철에서 승인 판단을 할 수 있습니다.
실서비스는 아직 멀쩡하니까 프리뷰에서 망가져 있어도 아무도 곤란하지 않습니다. 과감하게 되돌릴 수 있는 건 망가져도 되는 자리가 있기 때문입니다.
사람이 정할 것·AI에게 맡길 것
그럼 이 구조를 만드는 작업 자체는 어떻게 할까요. 당연히 전부 AI에게 통째로 넘깁니다. 절차서(설정 파일) 내용을 여러분이 쓸 일도 읽을 일도 없습니다.
다만 넘기기 전에 정해 둘 게 네 가지 있습니다. 이게 이 글의 체크리스트입니다.
## 자동화 전에 사람이 정할 것
1. 승인하면 바로 공개해도 되는가?
(개인 프로젝트라면 예스여도 된다. 누군가와 같이 운영한다면 상의 필요)
2. 자동 검사로 최소한 지키고 싶은 건 무엇인가?
(예: "메인 페이지가 열릴 것", "게시물이 저장될 것".
전문적인 테스트 항목은 AI에게 맡기고, 나는 "절대 망가지면 안 되는 경험"을 든다)
3. 프리뷰 환경은 만들 것인가?
(월 몇천 원 들 수 있다. 폰으로 확인하고 싶으면 강력 추천)
4. 공개가 실패했을 때 어떻게 알려 줬으면 하는가?
(예: 메일, 카카오톡. "못 알아채는 것"이 가장 무섭다)정했으면 이렇게 넘깁니다.
"이 리포지토리에 자동 테스트와 자동 배포를 설정해 줘. 방침은 다음 네 가지. (위 답을 붙인다). 설정했으면 구조를 초보자용으로 docs/deploy.md에 설명으로 남겨 줘."
마지막 한 문장이 포인트입니다. 구조 설명을 적어 두면 반년 뒤에 "이거 어떻게 돼 있었더라?" 싶을 때 AI와 같이 다시 읽을 수 있습니다.
해 보기
- 위 네 항목에 답을 적는다
- 답을 붙여서 자동화 구축을 AI에게 넘긴다
- 완성되면 시험 삼아 작은 Issue 1건을 흘려 본다 — 넘기고, 프리뷰로 확인하고, 승인하고, 실서비스에서 확인한다
이 한 바퀴가 손 안 대고 흘러가면 여러분의 공장은 완성입니다. 이후 여러분의 일은 "정한다"와 "판단한다"로 완전히 좁혀집니다.
다음 글: 동시에 여러 개 굴린다
자주 묻는 질문
팀에 Claude Code를 도입하려면 실제 코드베이스에 맞춘 설계가 필요합니다.
무료 상담 신청