플레이북 25편

비개발자 바이브 코딩, 배포 뒤가 진짜다
사이트를 운영하며 겪은 다섯 가지

환경, 자동화|2026년 10월 13일|10분 분량

먼저 답하면

바이브 코딩은 코드를 직접 짜지 않고 AI에게 말로 시켜 프로그램을 만드는 방식이에요 만드는 건 생각보다 빨리 끝납니다 진짜 일은 배포, 즉 만든 것을 인터넷 주소에 올려 다른 사람이 쓰게 한 뒤에 생겨요 이 사이트를 운영하며 배운 원칙은 다섯 가지입니다 올리는 길은 하나로, 0건도 실패로, 안내판은 날짜로 확인, 한글 이름은 조심, 비용 기준은 미리

"바이브 코딩 비개발자", "바이브 코딩 현실"을 찾고 있나요? 지금 읽고 계신 이 사이트도 개발자가 아닌 사람이 Claude Code로 짓고 운영하고 있어요 이 글은 만드는 법이 아니라 올린 뒤에 실제로 겪은 일을 다룹니다

Claude Code를 처음 쓴다면 1편과 2편부터, 반복 업무 자동화의 큰 흐름은 17편에 있어요

먼저 용어 세 개

버전 기록(git) - 파일을 고칠 때마다 "언제, 무엇을 바꿨나"를 남겨 두는 장부예요 잘못되면 예전 상태로 돌아갈 수 있습니다 파일을 저장하는 것과는 별개라서, 고친 뒤 변경 내용을 장부에 따로 남겨야 기록됩니다
저장소에 올리기 - 내 컴퓨터의 버전 기록을 온라인 보관함에도 똑같이 올려 두는 일이에요 다른 컴퓨터나 다른 작업 창도 그걸 받아 씁니다
배포 - 만든 사이트를 실제 인터넷 주소에 반영하는 일이에요 배포한 순간부터 방문자가 그 버전을 봅니다

1. 올리는 길은 하나로 - 배포 전에 장부부터 맞춘다

이 환경의 기록

장부와 실제 사이트가 어긋날 뻔한 일이 세 번

흔히 겪는 장면 - 인쇄소에 원고를 넘기기 직전, 넘기는 파일이 정말 최종본인지 확인하지 않으면 옛 원고가 인쇄되죠

이 환경에서는 - 운영 초기에 같은 실수가 세 번 날 뻔했어요 한 번은 다른 작업 창에서 버전 기록에 아직 남기지 않은 수정이 배포에 섞일 뻔했고, 한 번은 다른 컴퓨터에서 한 수정을 받아 오지 않은 채 배포했으며, 한 번은 버전 기록에 남기지 않고 바로 배포했다가 다음 배포가 그 수정을 조용히 되돌릴 뻔했습니다

그래서 배포를 명령 하나로만 하게 묶었어요 이 명령은 배포하기 전에 파일에 저장했더라도 버전 기록에 아직 남기지 않은 수정이나 새 파일이 없는지, 온라인 보관함과 내 컴퓨터가 같은지를 먼저 확인하고, 하나라도 어긋나면 배포를 멈춥니다 배포가 끝나면 실제 사이트의 버전이 장부의 최신 버전과 같은지 다시 확인해요 비상시 예전 버전으로 되돌리는 것도 이 길을 따르고, 되돌린 사실은 바로 장부에 남깁니다

여러 작업 창이 같은 사이트를 동시에 고칠 때도 같은 원칙이에요 이 사이트의 다른 글을 발행하던 날에도 다른 작업 창이 같은 사이트의 다른 부분을 고쳐 먼저 배포했는데, 그 창이 "배포 전에 내 수정을 먼저 받아 가라"고 알려 줬고 그 변경을 받아 합친 뒤에 배포했어요

그대로 요청하기 - 배포 전 점검

배포하기 전에 확인만 해줘 파일에 저장했더라도 버전 기록에 아직 남기지 않은 수정이나 새 파일이 있는지, 온라인 보관함과 내 컴퓨터의 버전 기록이 같은지, 지금 실제 사이트에 올라가 있는 버전이 무엇인지 알려줘
어긋난 게 있으면 무엇을 먼저 맞춰야 하는지 순서대로 정리해줘
배포와 업로드는 내가 확인한 뒤에 하자 지금은 아무것도 올리지 마

2. 0건도 실패로 - 초록불을 믿지 않는다

이 환경의 기록

결과가 0건인데 "성공"으로 끝났다

흔히 겪는 장면 - 택배가 안 왔는데 "배송 완료" 문자만 와 있는 상황이에요

이 환경에서는 - 매주 새 용어 후보를 찾아 주는 자동 작업이 어느 주에 한 건도 못 찾았는데, 프로그램은 "정상 종료"로 끝나 성공 표시가 떴어요 6일 뒤에야 "요즘 새 용어가 안 나온다"는 말로 알게 됐습니다

결과 건수를 확인하는 관문 자체는 17편에서 다뤘어요 이 사고에서 새로 배운 것은 세 가지입니다

정상인 0건은 구분한다 - 결과가 나와야 하는 작업에서 이유 없이 0건이면 실패로 표시해요 다만 "후보는 있었는데 전부 이미 있던 것이라 걸러진 경우"는 정상입니다
실패 표시가 뒤의 작업을 멈추는지 먼저 본다 - 자동 작업이 줄줄이 이어져 있으면, 앞 단계를 실패로 바꾸는 순간 꼭 돌아야 할 뒤 단계까지 멈출 수 있어요 바꾸기 전에 연결 관계부터 확인합니다
감시자는 감시 대상 밖에 - 작업이 아예 안 돌면 그 안의 점검도 같이 안 돌아요 그래서 주 1회 작업은 매일 도는 다른 작업이 대신 지켜보게 했습니다

그대로 요청하기 - 조용한 실패 찾기

이 프로젝트의 자동 작업들을 읽고, 결과가 0건이거나 중간에 오류가 나도 성공으로 끝나는 곳을 표로 찾아줘
각 작업이 안 돌았을 때 누가 알아챌 수 있는지도 같이 적어줘
코드는 아직 고치지 말고 찾은 것만 보여줘

3. 검색엔진에 주는 안내판은 날짜로 확인한다

이 환경의 기록

새 글 목록이 2주 가까이 멈춰 있었다

흔히 겪는 장면 - 가게 앞 메뉴판을 두 주째 안 바꿔서, 새 메뉴가 나온 줄 손님이 모르는 것과 같아요

이 환경에서는 - 검색엔진에 "우리 사이트에 이런 페이지들이 있다"고 알려 주는 목록(사이트맵)이 12일 넘게 갱신되지 않고 있었어요 페이지는 멀쩡히 열렸지만, 그 사이 올린 새 글을 확인해 보니 표본 6건이 모두 검색엔진에 아직 알려지지 않은 상태였습니다 페이지가 열리는지만 보고 "목록이 최신인지"는 안 본 탓이었어요

그래서 배포할 때마다 목록에 담긴 주소 수, 가장 최근 날짜, 목록이 마지막으로 새로 만들어진 시각을 자동으로 확인하게 했습니다 페이지가 열리는지와 목록이 최신인지는 별개라는 게 교훈이에요

4. 한글 파일 이름은 조심한다

이 환경의 기록

"분명히 있는데 못 찾는다"가 여러 번

흔히 겪는 장면 - 화면에는 똑같이 '가'로 보여도, 컴퓨터 안에서는 완성된 글자 하나로 기록할 수도 있고 자음과 모음의 조합으로 기록할 수도 있어요 사람 눈에는 같아도 컴퓨터는 다른 글자로 봅니다

이 환경에서는 - 폴더를 뒤져서 얻은 한글 이름과 코드에 적어 둔 같은 이름이 서로 다른 값으로 비교되는 일이 여러 번 났어요 2026년 9월까지 기록에 남은 것만 다섯 번이고, 있는 파일을 못 찾거나 같은 대상이 두 개로 갈리는 식으로 자리를 바꿔 가며 드러났습니다 오류 메시지가 나지 않아 매번 늦게 발견됐어요

새 이름을 영문으로 짓는 기본 처방은 8편에 있어요 여기서 더할 교훈은 하나입니다 비교하는 양쪽을 같은 방식으로 맞춰야 한다는 것이에요 한쪽만 맞추면 여전히 갈립니다 한글 경로를 다루는 코드를 AI에게 맡길 때 "한글 이름은 비교하는 양쪽 모두 같은 방식으로 맞춘 뒤에 비교해줘(정규화)"라고 덧붙이세요

5. 비용은 쓰는 만큼 나온다 - 한도와 대응을 미리 적어 둔다

이 환경의 기록

무료 한도를 크게 넘겨 유료 플랜을 유지했다

흔히 겪는 장면 - 기본요금 안에서 쓰다가 어느 달부터 사용량 요금이 붙기 시작하는 전기요금과 비슷해요

이 환경에서는 - 사이트를 올려 두는 호스팅 서비스는 다시 만든 페이지를 저장하는 데이터 양을 일정 크기 단위로 세고, 무료 플랜에는 그 월 한도가 있어요 이 사이트는 한 결제 주기의 20일 만에 한 달 한도의 약 세 배를 이미 썼습니다 확인한 원인은 두 가지였어요 새 글을 하나 올릴 때마다 저장해 둔 자료 전체를 비우는 설정과, 저장해 둔 자료가 한 시간마다 만료돼 다시 저장되는 설정이었습니다 비우는 범위를 좁히고 만료 간격도 하루로 늘리자 하루 사용량이 가장 많던 날의 6분의 1 안팎으로 줄었지만(두 조치를 함께 적용해 각각의 효과는 따로 재지 않았어요), 한 달로 환산하면 여전히 한도의 두 배 안팎이라 유료 플랜을 유지했습니다 배포가 잦은 날 사용량도 늘어 보여서 고칠 것을 모아 배포하는 것을 다음 대응으로 잡았는데, 배포 횟수만의 영향을 따로 재 본 것은 아니에요

데이터를 보관하는 서비스도 무료 한도를 넘으면 사이트가 멈출 수 있어서, "무료로 유지하되 막히면 즉시 유료로 올린다"는 기준을 미리 정해 두었어요 비용 문제는 막힌 뒤에 결정하면 늦습니다 고칠 것은 모아서 한 번에 배포하고, 서비스별 무료 한도와 넘었을 때의 대응을 미리 적어 두세요

운영 점검표

배포는 정해진 명령 하나로만 하고, 그 명령이 버전 기록에 남기지 않은 수정과 온라인 보관함과의 차이를 먼저 확인하는가
배포 뒤 실제 사이트의 버전이 장부의 최신 버전과 같은지 확인하는가
여러 작업 창이 같은 사이트를 고칠 때 서로 알리고 받은 뒤 배포하는가
자동 작업이 이유 없는 0건이나 오류를 성공으로 넘기지 않는가, 실패 표시가 꼭 돌아야 할 뒤 작업까지 멈추지 않는가
자동 작업이 안 돌면 알아챌 다른 감시자가 있는가
검색엔진에 주는 목록이 최신 날짜인지 배포 때 확인하는가
한글 이름을 비교할 때 양쪽을 같은 방식으로 맞춘 뒤에 하는가
서비스별 무료 한도와 넘었을 때의 대응을 적어 두었는가
고칠 것을 모아서 배포하는가

자주 묻는 질문

비개발자도 바이브 코딩으로 서비스를 운영할 수 있나요?

이 사이트가 그 사례예요 다만 만드는 것보다 운영이 더 손이 갑니다 배포를 한 길로 묶고, 조용한 실패를 잡는 감시와 비용 기준을 처음부터 같이 만들어 두는 편이 좋습니다

배포가 정확히 무엇인가요?

만든 사이트를 실제 인터넷 주소에 반영하는 일이에요 배포한 순간부터 방문자가 그 버전을 보기 때문에, 올리기 전에 버전 기록과 실제로 올릴 파일이 같은지 확인해야 합니다

고칠 때마다 바로 배포하면 안 되나요?

안 되는 건 아니에요 다만 이 사이트는 쓰는 만큼 요금이 붙는 항목이 있고, 배포가 잦은 날 사용량도 늘어 보여서 고칠 것을 모아 배포합니다 배포 횟수만의 영향을 따로 재 본 것은 아니지만, 모아서 올리면 배포 전 점검도 한 번에 끝나요

자동 작업이 잘 도는지 어떻게 알 수 있나요?

성공 표시만 믿지 말고 결과 건수를 함께 보세요 결과가 나와야 하는 작업에서 이유 없이 0건이면 실패로 표시하되, 정상적으로 걸러져 0건인 경우는 구분하고 실패 표시 때문에 뒤의 필요한 작업까지 멈추는지도 먼저 확인하세요 그 작업 밖의 다른 작업이 대신 지켜보게 하면 작업이 아예 안 돈 경우도 잡을 수 있어요

한글 파일 이름을 쓰면 안 되나요?

쓸 수는 있어요 다만 한글은 같은 글자를 두 가지 방식으로 적을 수 있어서, 이 환경에서는 눈으로 같은 이름을 프로그램이 다른 값으로 비교해 파일을 못 찾는 일이 여러 번 있었습니다 새 이름은 영문으로 짓고, 한글 이름을 비교할 때는 양쪽을 같은 방식으로 맞춘 뒤에 하세요

잘못 배포하면 되돌릴 수 있나요?

버전 기록이 있으면 예전 버전으로 되돌릴 수 있어요 다만 급하게 되돌린 뒤에는 그 사실을 바로 버전 기록에 남겨야, 다음 배포가 되돌린 상태를 다시 덮어쓰지 않습니다

처음 시작은 1편, 자동화 설계는 17편, 사고를 막는 권한과 기록 기준은 18편, 다른 AI로 검수하는 법은 20편으로 이어집니다

검증 기준일: 2026-10-08 KST 한 사이트의 실제 운영 기록을 바탕으로 썼으며, 서비스별 무료 한도와 요금은 각 서비스의 현재 안내를 확인하세요

AI 에이전트 실전 플레이북 - 계속 더해 가는 시리즈

← 플레이북 전체 목록 보기

비개발자 바이브 코딩, 배포 뒤가 진짜다사이트를 운영하며 겪은 다섯 가지

먼저 용어 세 개

1. 올리는 길은 하나로 - 배포 전에 장부부터 맞춘다

장부와 실제 사이트가 어긋날 뻔한 일이 세 번

2. 0건도 실패로 - 초록불을 믿지 않는다

결과가 0건인데 "성공"으로 끝났다

3. 검색엔진에 주는 안내판은 날짜로 확인한다

새 글 목록이 2주 가까이 멈춰 있었다

4. 한글 파일 이름은 조심한다

"분명히 있는데 못 찾는다"가 여러 번

5. 비용은 쓰는 만큼 나온다 - 한도와 대응을 미리 적어 둔다

무료 한도를 크게 넘겨 유료 플랜을 유지했다

운영 점검표

자주 묻는 질문

비개발자 바이브 코딩, 배포 뒤가 진짜다
사이트를 운영하며 겪은 다섯 가지