바이브 코딩 · 시작 전 · 01 / 10

바이브 코딩,
어디까지 직접 만들 수 있을까?

AI에게 말로 설명하면 화면이 생기고, 버튼이 동작하고, 데이터가 저장됩니다. 비전공자도 하루 만에 “돌아가는 것”을 만들 수 있는 시대가 됐습니다. 그런데 돌아가는 것과 믿고 쓸 수 있는 것은 다릅니다. 시작하기 전에 가장 먼저 정해야 할 것은 도구가 아니라 어디까지 직접 만들지입니다.

HandsMate 바이브 코딩 가이드 · 예상 읽기 7분
결론 먼저틀려도 내가 바로 고칠 수 있고, 피해가 나에게만 머무는 것은 직접 만드세요. 돈·개인정보·법적 책임이 걸리거나, 여러 사람이 매일 의존하게 될 것은 처음부터 전문가와 함께 설계하거나 맡기는 편이 결국 싸고 빠릅니다.

1. 바이브 코딩은 ‘말로 시키고, 보면서 고치는’ 개발입니다.

바이브 코딩은 코드를 한 줄씩 직접 쓰는 대신, 원하는 것을 AI에게 설명하고 만들어진 결과를 보며 계속 고쳐 가는 방식입니다. 문법을 몰라도 시작할 수 있다는 점에서 비전공자에게 문이 크게 열렸습니다.

다만 AI는 시키는 것은 잘 만들지만, 시키지 않은 것은 챙기지 않습니다. 권한, 예외 처리, 데이터 보관, 백업처럼 눈에 보이지 않는 부분은 만드는 사람이 먼저 떠올려야 합니다.

26년 동안 금융·공공·기업의 업무시스템을 만들며 반복해서 본 문제도 비슷했습니다. 화면이 완성되는 속도보다, 누가 무엇을 볼 수 있고 데이터가 틀렸을 때 어떻게 되돌리는지를 정하는 데 훨씬 많은 시간이 들었습니다. 바이브 코딩은 앞부분을 빠르게 만들어 줄 뿐, 뒷부분의 판단까지 대신해 주지는 않습니다.

2. 혼자 만들어도 좋은 것

사내 도구

나와 우리 팀이 쓰는 작은 도구

엑셀로 관리하던 목록을 화면으로 옮기기, 일정·재고·요청 현황을 한눈에 보는 페이지처럼 사용자가 정해져 있고 규모가 작은 도구입니다.

시제품

아이디어를 보여 주기 위한 데모

투자자·고객·개발사에게 “이런 흐름”이라고 설명하기 위한 화면과 동작입니다. 실제 운영이 아니라 대화를 위한 결과물이라 직접 만들기에 가장 좋습니다.

자동화

반복 업무를 줄이는 스크립트

파일 정리, 양식 변환, 보고서 취합처럼 매번 같은 순서로 하던 일을 자동으로 처리하는 작업입니다. 결과를 내가 바로 확인할 수 있어 위험이 낮습니다.

공통점은 틀려도 금방 알아차리고, 내가 직접 고칠 수 있으며, 피해가 밖으로 번지지 않는다는 점입니다.

3. 혼자 만들 때 조심해야 할 것

반대로 아래 기능은 “일단 돌아가게” 만든 뒤 나중에 고치기가 특히 어렵습니다. 처음부터 설계를 함께 보거나, 해당 부분만이라도 검증을 받는 것이 좋습니다.

기능왜 조심해야 하나현실적인 선택
결제·정산금액 오류는 바로 손해와 분쟁으로 이어집니다.검증된 결제 서비스 연동 + 전문가 점검
개인정보유출되면 법적 책임이 생기고 되돌릴 수 없습니다.수집 최소화, 보관·접근 설계는 함께
회계·세무 계산규칙이 복잡하고 해마다 바뀌며, 틀린 숫자가 신고로 이어집니다.검증된 솔루션 사용 또는 전문가 설계
여러 명이 매일 쓰는 운영 시스템동시 사용, 권한, 장애 대응이 필요합니다.시제품은 직접, 운영 전환은 함께
외부 기관·은행 연계규격과 인증 절차가 까다롭고 테스트 환경이 제한됩니다.연계 부분은 맡기기

4. 시작 전에 이 다섯 가지를 물어보세요.

질문 1틀리면 누가 손해를 보나?

나만이라면 직접, 고객·거래처라면 함께.

질문 2몇 명이 쓰나?

나 혼자·우리 팀이면 직접, 외부 사용자가 많다면 함께.

질문 3돈이나 개인정보를 다루나?

그렇다면 그 부분만이라도 전문가 검토를 받으세요.

질문 4얼마나 오래 쓸 것인가?

한 달짜리 실험과 3년 쓸 시스템은 설계부터 다릅니다.

질문 5. 다른 시스템과 연결되나? 혼자 동작하는 도구는 직접 만들어도 되지만, ERP·회계·외부 기관과 데이터를 주고받는 순간 규격과 책임이 함께 따라옵니다.

5. 길은 세 가지입니다: 직접 → 함께 → 맡김

직접

혼자 끝까지 만든다

다섯 질문에 대부분 “나만, 작게, 잠깐”이라고 답할 수 있을 때. 이 연재의 2~9편이 이 길을 위한 내용입니다.

함께

내가 만들고, 전문가가 설계와 점검을 맡는다

화면과 흐름은 직접 만들되, 데이터 구조·권한·보안처럼 나중에 바꾸기 어려운 부분만 전문가와 함께 정합니다. 비용 대비 효과가 가장 큰 방식입니다.

맡김

직접 만든 시제품을 기준으로 맡긴다

운영 시스템으로 키울 때는 맡기는 편이 낫습니다. 이때 직접 만든 시제품은 버리는 것이 아니라 가장 정확한 요구사항 문서가 됩니다.

6. 같은 주제라도 범위에 따라 선택이 달라집니다.

예를 들어 ‘견적 관리’를 만든다고 해 보겠습니다.

직접 만들기 좋은 범위

엑셀로 쓰던 견적서를 화면에서 작성하고, 품목·단가를 불러와 합계를 계산하고, PDF로 저장하는 내 업무용 도구.

→
함께하거나 맡길 범위

고객이 직접 로그인해 견적을 승인하고, 승인되면 세금계산서가 발행되고, 회계 장부에 자동으로 반영되는 시스템.

왼쪽은 틀려도 내가 바로 고치면 됩니다. 오른쪽은 고객 계정, 세금계산서, 회계 데이터가 얽혀 있어 한 번의 실수가 여러 곳에 남습니다. 왼쪽을 먼저 직접 만들어 써 보고, 오른쪽이 필요해질 때 그 결과물을 들고 상의하는 것이 가장 효율적인 순서입니다.

7. 시작하기 전 체크리스트

이 결과물을 쓸 사람을 한 문장으로 말할 수 있다.
틀렸을 때 피해를 보는 사람이 누구인지 알고 있다.
결제·개인정보·회계 계산이 들어가는지 확인했다.
한 달 실험용인지, 계속 쓸 도구인지 정했다.
다른 시스템과 연결되는 부분을 적어 두었다.
직접 · 함께 · 맡김 중 이번에 갈 길을 골랐다.
한 줄 원칙

내가 책임질 수 있는 만큼은 직접, 그 너머는 함께.

바이브 코딩의 가장 큰 가치는 전문가 없이 모든 것을 만드는 데 있지 않습니다. 원하는 것을 직접 만들어 보면서 정확하게 이해하고 설명할 수 있게 되는 것입니다. 다음 편에서는 이 범위에 맞는 도구를 고르는 법을 다룹니다.