2026년 7월 1일

바이브코딩 수정 비용은 어떻게 정해질까

AI로 만든 사이트나 MVP를 수정 의뢰할 때 3만원짜리 수정과 15만원짜리 작업이 왜 달라지는지 배포 오류, 화면 수정, 구조 정리 기준으로 설명합니다.

바이브코딩으로 만든 사이트를 고치려고 할 때 제일 먼저 막히는 질문이 있습니다.

"이거 고치면 비용이 얼마나 나오지?"

겉으로는 버튼 하나, 화면 하나, 배포 에러 하나처럼 보입니다. 그런데 견적은 눈에 보이는 증상만으로 잘 나오지 않습니다. 같은 흰 화면이어도 단순 이미지 경로 문제면 작게 끝나고, 환경 변수와 로그인 콜백, 배포 설정이 같이 얽혀 있으면 확인 범위가 커집니다.

그래서 비용을 볼 때는 작업 시간보다 먼저, 문제가 어디에서 시작됐는지와 재현할 단서가 있는지를 봐야 합니다.

3만원에 가까운 작업

작게 끝나는 작업은 공통점이 있습니다. 문제가 보이는 위치가 분명하고, 수정 범위도 한두 파일 안에서 끝납니다.

예를 들면 이런 요청입니다.

이런 작업은 보통 확인과 수정이 빠릅니다. 다만 "문구만 바꾸면 될 줄 알았는데 저장 로직까지 같이 깨져 있다"처럼 범위가 달라지면 비용도 달라질 수 있습니다.

MVP 화면이나 반응형 UI처럼 눈에 보이는 문제는 단순 CSS 한 줄로 끝나지 않을 때가 많습니다. 실제 화면에서 어떤 요소가 서로 밀고 있는지, 모바일에서만 깨지는지, 이미지가 늦게 뜰 때 흔들리는지까지 같이 봐야 합니다.

예를 들면 이런 작업입니다.

이 구간에서는 "한 군데만 고치면 되겠지"가 잘 안 맞습니다. AI가 이미 여러 번 고친 프로젝트는 한 곳을 건드리면 다른 화면이 같이 움직이는 일이 많아서, 먼저 화면 단위로 나눠야 합니다.

비용이 커지는 작업은 보통 코드보다 구조가 문제입니다. 겉으로는 작은 요청이어도 실제로는 앞으로 운영할 수 있게 정리해야 하는 경우입니다.

예를 들면 이런 상황입니다.

이런 작업은 "버그 하나 수정"이라기보다 "운영 가능한 상태로 정리"에 가깝습니다. LastFix에서 15만원 작업이 된 사례도 화면 하나를 예쁘게 만드는 일이 아니라, 고객이 앞으로 직접 데이터를 넣을 수 있게 구조를 분리하는 일이었습니다.

비용을 줄이는 데 가장 도움이 되는 건 긴 설명이 아니라 재현 가능한 단서입니다.

문의할 때 아래 중 세 가지만 있어도 진단 속도가 빨라집니다.

"사이트가 이상해요"보다 "아이폰에서 문의 버튼을 누르면 흰 화면이 뜹니다"가 훨씬 빠릅니다. 후자는 바로 재현을 시작할 수 있기 때문입니다.

코딩 의뢰 사이트를 여러 곳 찾아보다 보면 견적을 빨리 받고 싶어서 문제를 크게 뭉뚱그려 말하게 됩니다. 그런데 바이브코딩 프로젝트에서는 이게 오히려 불리할 수 있습니다.

피하면 좋은 요청은 이렇습니다.

이런 말이 틀린 것은 아닙니다. 다만 견적을 내는 사람 입장에서는 확인 범위가 너무 넓습니다. 가능하면 "지금 막힌 문제 하나"와 "나중에 하고 싶은 개선"을 분리해서 전달하는 편이 좋습니다.

바이브코딩 수정 비용은 화면에 보이는 증상만으로 정해지지 않습니다.

작은 UI 수정은 작게 끝날 수 있고, 배포 오류나 구조 정리는 더 넓게 봐야 합니다. 처음부터 완벽하게 설명하려고 애쓰기보다, 지금 막힌 장면을 짧게 적는 게 더 낫습니다. 그 한 문장이 비용을 현실적으로 잡는 출발점이 됩니다.

수정 비용 상담

내 바이브코딩 프로젝트가 어느 정도 작업인지 먼저 확인하세요

화면 주소, 에러 메시지, GitHub 저장소, 배포 로그가 있으면 단순 수정인지 구조 점검이 필요한 작업인지 먼저 나눠봅니다.