바이브코딩으로 업무 시스템을 만들어도 될까? 먼저 확인할 3가지 기준

요즘 업무 시스템 견적을 받아 보면 AI로 빨리 만들어 준다는 제안이 자주 보입니다. 가격도 기간도 매력적입니다. 그런데 막상 맡기려 하면 한 가지가 걸립니다. 우리 회사 업무가 그렇게 빨리 만들어도 되는 일인가, 하는 질문입니다.

이 연재는 AI에게 코드보다 설계 절차를 먼저 가르친 이야기로 시작했습니다. 다섯 편을 거쳐 이번이 결론입니다. 결론부터 적겠습니다. 저희는 AI로 일하는 것을 "무작정 바이브코딩"으로 하지 않습니다. 요구분석과 설계를 바탕으로 기초가 튼튼한 바이브코딩으로 합니다.

바이브코딩은 말로 시키면 AI가 바로 화면과 코드를 만들어 주는 방식입니다. 이 방식 자체는 나쁘지 않습니다. 저희도 씁니다. 문제는 방식이 아니라 순서였습니다. 무엇을 먼저 정하고 무엇을 AI에게 맡길지, 그 순서가 결과를 갈랐습니다.

업무 시스템은 홈페이지와 조건이 다릅니다

앞서 「AI로 빠르게 만든 사이트, 운영해 보니 달랐던 것들」에서 이노자일 홈페이지를 AI로 만들고 운영한 이야기를 적었습니다. 설계 문서 없이 맡기면 첫 주가 가장 빠르고 반년 뒤가 가장 느리다는 내용이었습니다. 이번에는 무대가 업무 시스템입니다.

업무 시스템은 세 가지가 다릅니다. 담당자가 여럿이고 여러 시스템이 서로 이어지며 운영 중에 요구가 바뀝니다. 저희는 2026년 2월부터 한 고객사의 전사 업무 시스템을 AI 에이전트 기반으로 최신화하는 사업을 맡아 이끌고 있고 그 안에서 광고 관리(6월) → 영업 관리(7월) → 구매·자산 관리(8월 21일) 순서로 시스템 세 개를 차례로 만들고 있습니다.

실무 담당자의 피드백이 "17항목"으로 왔습니다. 원문과 한 줄씩 대조하니 세부 요구는 42건이었습니다. 항목 하나에 요구가 여럿 들어 있었던 것입니다. 실무 담당자에게 되묻는 확인 질문지는 11차까지 이어졌습니다.

영업 시스템과 구매·자산 시스템을 잇는 흐름은 16단계였습니다. 첫 점검에서 끊긴 자리가 8곳 나왔습니다. 그중 하나는 화면마다 보면 전부 정상인데, 청구서에 줄 두 줄이 0원으로 찍히는 일이었습니다. 화면을 하나씩 만들어 눈으로 확인하는 방식으로는 잡히지 않는 부류입니다. 두 시스템 사이를 따라가 봐야 보입니다. "17항목" 그대로 시키면 42건 중 어느 것이 빠졌는지 아무도 모르는 것과 같은 이치입니다.

바로 써도 되는 일과 기초가 먼저 필요한 일을 가르는 기준

가르는 기준은 세 가지입니다. 하나라도 "그렇다"면 설계부터 다지고 셋 다 "아니다"면 바로 바이브코딩으로 가도 됩니다.

첫째, 이 화면을 쓰는 사람이 여럿인가. 혼자 쓰는 도구는 만든 사람이 곧 사용자라 요구가 따로 적혀 있지 않아도 됩니다. 담당자가 여럿이면 같은 단어를 다르게 쓰는 일이 생기고 그 차이를 적어 두지 않으면 AI는 그중 한 사람의 뜻대로 만들기 쉽습니다.

둘째, 다른 시스템과 데이터를 주고받는가. 혼자 서 있는 화면은 눌러 보면 됩니다. 이어진 시스템은 한쪽 화면이 전부 정상이어도 건너편에서 0원이 찍힐 수 있습니다. 두 쪽 사이의 흐름을 먼저 그려 두지 않으면 어디서 끊겼는지 찾기 어렵습니다.

셋째, 쓰는 동안 요구가 바뀌는가. 행사 페이지처럼 한 번 열고 닫는 것은 바뀔 일이 적습니다. 업무 시스템은 운영하면서 바뀝니다. 바뀔 때마다 처음부터 다시 시키면 지난번에 맞춰 둔 것이 어디서 깨지는지 알 수 없습니다.

세 질문에 모두 "아니다"인 일도 많습니다. 내부에서 혼자 쓰는 집계표, 한 번 쓰고 버릴 안내 페이지, 아이디어를 눈으로 확인하는 시제품 같은 것들입니다. 이런 일은 바이브코딩으로 바로 가는 편이 맞습니다.

기초가 있으면 요구가 바뀌어도 그 부분만 고칠 수 있었습니다

세 번째 기준이 실제로 어떻게 작동했는지 한 가지만 적겠습니다. 구매·자산 관리 시스템을 만드는 중에 발주처가 "배정이 어디서 시작되는가"를 다시 정의했습니다. 출발점이 바뀌면 뒤에 이어지는 흐름이 함께 영향을 받습니다.

새 기준으로 다시 보니 끊긴 자리 셋이 새로 드러났습니다. 그중 둘은 오류 없이 조용히 넘어가는 부류였습니다. 화면도 뜨고 저장도 되는데 결과가 틀린 것입니다.

저희는 결정 기록과 요구사항 추적표를 갖고 있었습니다. 어떤 결정이 어떤 화면과 어떤 업무 규칙에 닿아 있는지가 번호로 이어져 있었습니다. 그래서 새 정의가 영향을 주는 화면·규칙을 짚어 그 부분만 바꿨습니다. 처음부터 다시 만들지 않았습니다.

지금 저희는 분석과 시제품 코딩을 동시에 합니다. 운영 중 요구가 추가되면 분석과 함께 영향 평가를 합니다. 기존 화면·기능에 어디까지 미치는지 보고 나서 고칩니다. 복잡한 업무 분석에서 예전에는 담당자별 업무 흐름도를 한 주에 2~3장 그렸는데, 지금은 AI가 한 시간 안에 그 이상을 그리고 사람은 확인과 수정에 집중합니다. 저희 체감으로는 기존보다 10배 이상 빨라졌습니다. 설계를 먼저 한다고 느려지는 것이 아닙니다. 설계 자체를 AI가 하고, 사람은 확인하는 쪽으로 자리를 옮긴 것입니다.

다섯 편을 한 번에 — 설계부터 다진 AI 개발이 남긴 것

연재를 한 줄씩 정리하면 이렇습니다.

1. 코드보다 설계 절차를 먼저 가르쳤습니다. 약 20년 동안 손으로 하던 분석설계를 2026년 3월부터 AI에게 시키니 첫 결과가 14개 업무 영역 800장이 넘는 문서였습니다. 사람이 다 볼 수 없는 분량이었습니다. 문서가 아니라 절차가 필요하다고 보고, 사람이 단계마다 확인하는 7단계를 세웠습니다.
2. 외주 전에 받아야 할 설계 문서 7가지를 정했습니다. 요구 목록 → 영향 점검표 → 사용 장면 명세 → 업무 흐름 연결도 → 화면 목록 → 화면정의서 → 업무 규칙·요구사항 추적표 순서입니다.
3. 만드는 쪽과 검사하는 쪽을 나눴습니다. 역할 6개, 검사 5층. 검수자는 고치지 않습니다. 고치면 만드는 쪽이 되기 때문입니다.
4. 업무 흐름이 끊긴 곳을 반복 점검으로 찾았습니다. 흐름 끊김 점검 10차, 사용자 눈높이 점검 10차.
5. 반복 업무를 AI 작업 지침서로 남겼습니다. 순서·금지·확인·끝나는 조건만 고정하고 나머지는 열어 뒀습니다.

이 다섯 가지를 그대로 적용한 결과가 구매·자산 관리 시스템입니다. 8월 21일에 시작해 10월 1일까지 213번째 작업 묶음을 마쳤습니다. 묶음마다 점검을 통과해야 닫히는 방식입니다. 화면 82개가 모두 구현됐고 업무 규칙 402개와 안내 문구 500개를 문서와 코드에서 같은 번호로 관리합니다. 데이터 표는 124개, 자동 점검 17종이 모두 통과 상태입니다.

숫자보다 결함이 어디서 걸렸는지가 더 중요합니다. 만들지 않은 쪽의 검수가 "저장이 항상 실패하던" 결함을 작업 묶음을 닫기 전에 찾았습니다. 사용자 눈높이 점검은 8차에 처음으로 새 결함 0건이었고 10차도 0건이었습니다. 모든 결함은 운영 전 시제품 단계에서 걸렸습니다.

업체를 고를 때 — 연재 전체를 한 장으로 줄인 확인 목록

AI로 빨리 만들어 준다는 제안을 받았다면, 계약 전에 아래 질문을 한 번 해 보시길 권합니다. 연재 다섯 편에서 다룬 내용을 질문으로 옮긴 것입니다. 정답이 하나인 질문은 아니고 답하는 모습에서 그 팀이 일하는 방식을 가늠해 볼 수 있습니다.

• "저희 요구를 몇 건으로 정리하셨나요?" 전달한 항목 수와 정리된 요구 수가 그대로 같다면, 원문을 하나씩 다시 읽어 보지 않았을 수 있습니다. 저희 프로젝트에서는 실무 담당자가 피드백을 "17개 항목"으로 보내 줬는데, 항목마다 요청이 여러 개씩 들어 있어 하나씩 나눠 보니 실제 요청은 42건이었습니다.
• "애매한 부분은 어떻게 확인하시나요?" "다 이해했습니다"라는 답보다, 모호한 것을 모아 다시 물어 오는 과정이 있는 편이 놓치는 것이 적습니다.
• "개발에 들어가기 전에 어떤 설계 문서를 받을 수 있나요?" 요구 목록, 화면정의서, 요구사항 추적표처럼 받을 문서를 이름으로 답할 수 있어야 합니다. 2편에서 일곱 가지로 정리했습니다.
• "다른 시스템과 데이터가 오가는 흐름을 그림으로 보여 주실 수 있나요?" 화면 목록만으로는, 화면마다 정상인데 시스템 사이를 건너가며 청구 금액이 0원이 되는 문제를 놓치기 쉽습니다.
• "만든 사람과 검사하는 사람이 다른가요?" 만든 쪽이 스스로 통과시키는 구조라면 검사가 형식에 그치기 쉽습니다.
• "작업은 어떤 단위로 마무리하고, 마무리 기준은 무엇인가요?" 작업마다 통과해야 끝나는 조건이 있으면 "다 됐다"는 보고를 믿을 근거가 생깁니다.
• "운영 중에 요구가 바뀌면 영향받는 곳을 어떻게 찾나요?" 결정 기록과 요구사항 추적표가 있으면 전부 다시 만들지 않고 바뀐 부분만 고칠 수 있습니다.
• "반복되는 작업은 어떻게 같은 품질로 유지하나요?" 작업 순서와 확인 방법을 지침으로 남겨 두면 담당자가 바뀌어도 결과가 흔들리지 않습니다.
• "결함은 보통 언제, 어디서 잡나요?" 운영 전에 어디서 걸렀고 실제 사용자 피해가 있었는지 말할 수 있다면, 검사가 실제로 이뤄지고 있다는 뜻입니다.

전부 "예"여야 한다는 뜻은 아닙니다. 앞의 세 기준에 모두 "아니다"인 일이라면 이 목록 대부분이 필요 없습니다. 다만 담당자가 여럿이고 시스템이 이어지며 요구가 바뀌는 일이라면, 이 질문에 답이 없는 제안은 첫 주는 빠르고 반년 뒤가 느린 쪽으로 가기 쉽습니다.

결론은 바이브코딩을 안 하는 것이 아니었습니다

바이브코딩을 버리자는 글이 아닙니다. 저희도 화면과 코드는 AI로 빠르게 만듭니다. 다만 그 앞에 요구분석과 설계를 둡니다. 그 설계마저 AI가 하고 사람은 확인합니다. 그래서 느려지지 않고 요구가 바뀌어도 그 부분만 고칠 수 있습니다.

무작정 바이브코딩이 아니라 기초가 튼튼한 바이브코딩. 여섯 편에 걸친 이야기의 결론은 이 한 줄입니다.