토요일 밤 11시 48분, 동네 공방 예약 앱의 첫 버전이 완성됐다고 가정해 보겠습니다. 달력에서 시간을 고르고 결제 버튼을 누르면 “예약이 완료되었습니다”라는 화면이 뜹니다. 만든 사람은 친구에게 링크를 보냅니다. 친구도 예약에 성공합니다.
그런데 다음 날 아침, 같은 시간에 두 명이 예약돼 있습니다. 한 명은 결제됐고 다른 한 명은 결제 승인 문자만 받은 상태입니다. 관리자는 누구의 예약을 취소해야 하는지 모릅니다. 앱은 분명 작동했는데, 서비스는 작동하지 않았습니다.
바이브 코딩의 진짜 난점은 코드를 만드는 순간보다 정상 화면 밖에서 벌어지는 일을 책임지는 순간에 나타납니다.
바이브 코딩은 무엇인가
바이브 코딩은 “예약 화면을 만들어 줘”, “로그인을 붙여 줘”처럼 원하는 결과를 자연어로 설명하고, AI가 생성한 코드를 실행해 보며 반복적으로 고치는 개발 방식입니다. 코드를 한 줄도 직접 쓰지 않을 수 있고, 개발자가 구조를 잡은 뒤 AI에게 구현을 맡길 수도 있습니다.
일반적인 AI 보조 개발과 경계가 딱 잘리는 용어는 아닙니다. 다만 실무에서는 다음 차이가 중요합니다.
| 구분 | 사람이 주로 통제하는 것 | AI가 주로 맡는 것 | 흔한 위험 |
|---|---|---|---|
| AI 보조 개발 | 구조, 변경 범위, 리뷰, 배포 | 함수 초안, 테스트, 반복 작업 | 검토 누락 |
| 바이브 코딩 | 목표와 화면 결과 | 여러 파일의 생성·수정·실행 | 이해하지 못한 변경이 누적됨 |
바이브 코딩 자체가 나쁜 것은 아닙니다. 아이디어를 확인하고 작은 도구를 만드는 속도는 크게 높일 수 있습니다. 문제는 시제품에서 얻은 속도를 그대로 운영 품질로 착각할 때 생깁니다.
데모와 서비스 사이에는 무엇이 빠져 있나
데모는 한 사람이 예상한 순서대로 움직이면 충분합니다. 서비스는 예상 밖의 사람과 상황까지 견뎌야 합니다.
예약 앱만 해도 화면 뒤에는 이런 질문이 숨어 있습니다.
- 두 사람이 동시에 같은 시간을 선택하면 누가 성공하는가
- 결제는 됐지만 예약 저장이 실패하면 어떻게 복구하는가
- 사용자가 결제 버튼을 두 번 누르면 한 번만 처리되는가
- 주소창의 예약 번호를 바꾸면 다른 사람 기록이 보이는가
- 관리자가 실수로 예약을 지우면 되돌릴 수 있는가
- 서버가 멈췄을 때 사용자는 무엇을 보게 되는가
기능 목록에는 “달력, 로그인, 결제”라고 세 줄만 적혀 있어도, 운영 조건은 수십 개가 됩니다. AI는 말하지 않은 조건을 항상 알아서 채우지 않습니다. 그래서 바이브 코딩에서 가장 값비싼 능력은 프롬프트 문장을 멋지게 쓰는 기술보다 빠진 조건을 발견하는 기술입니다.
실패했을 때 다른 사람의 돈·계정·개인정보가 영향을 받고, 그 피해를 즉시 되돌릴 방법을 설명하지 못한다면 아직 비공개 테스트 단계에 가깝습니다.
한 건의 예약이 지나가는 길
화면만 보면 예약은 버튼 한 번으로 끝납니다. 시스템 안에서는 여러 단계가 이어집니다.
이 흐름에서 한 단계만 어긋나도 “결제는 됐는데 예약은 없음”, “예약은 두 개지만 결제는 하나” 같은 불일치가 생깁니다. 보기 좋은 화면은 이 문제를 보여 주지 않습니다.
첫 번째 검토: 무엇이 바뀌었는지 설명할 수 있는가
AI에게 버튼 색상만 바꿔 달라고 했는데 인증 설정과 데이터베이스 파일까지 수정될 수 있습니다. 도구가 “완료했습니다”라고 말한 설명과 실제 변경 내역은 같지 않을 수 있습니다.
코드를 잘 읽지 못하더라도 다음은 확인할 수 있습니다.
| 확인 대상 | 왜 중요한가 | 초보자가 볼 수 있는 신호 |
|---|---|---|
| 새 파일·삭제 파일 | 예상 밖 기능이 섞였는지 확인 | 변경 파일 수가 요청보다 지나치게 많음 |
| 외부 패키지 | 공급망과 유지보수 위험 | 낯선 이름, 오래된 버전, 과도한 권한 |
| 환경 변수 | 비밀키 노출 여부 | 코드 안에 API 키나 비밀번호가 보임 |
| 데이터베이스 변경 | 되돌리기 어려운 수정인지 확인 | 테이블 삭제, 필드 형식 변경, 대량 이동 |
| 권한 설정 | 사용자 범위가 넓어졌는지 확인 | 관리자 토큰, 전체 읽기·쓰기 권한 |
한 번에 바뀐 양이 크면 잘못된 부분을 찾기도 어렵고 되돌리기도 어렵습니다. “로그인 화면”, “로그인 API”, “권한 검사”, “로그아웃”처럼 변경을 작게 나누는 이유가 여기에 있습니다.
두 번째 검토: 정상 동작이 아니라 실패 장면을 만든다
테스트 버튼이 초록색이라는 사실은 테스트의 내용이 좋다는 뜻이 아닙니다. AI가 만든 테스트가 AI가 만든 가정만 확인할 수도 있습니다.
다음 표는 초보자가 직접 재현할 수 있는 실패 장면입니다.
| 기능 | 평소 확인 | 일부러 망가뜨려 볼 조건 |
|---|---|---|
| 회원가입 | 올바른 이메일로 가입 | 빈 값, 중복 주소, 지나치게 긴 입력, 인증 링크 재사용 |
| 로그인 | 정상 로그인 | 연속 실패, 만료 세션, 탈퇴 계정, 다른 사용자 URL 접근 |
| 파일 업로드 | 이미지 한 장 | 큰 파일, 실행 파일, 확장자 위장, 같은 이름 두 번 |
| 예약 | 빈 시간 한 건 | 두 브라우저 동시 예약, 새로고침, 뒤로 가기, 중복 클릭 |
| 결제 | 한 번 승인 | 승인 후 저장 실패, 웹훅 지연, 환불 중 재시도 |
| AI 기능 | 일반 질문 | 긴 입력, 개인정보, 악성 지시, 외부 API 중단 |
2025년에 공개된 한 벤치마크에서는 실제 오픈소스 기능 요청 200개를 여러 코딩 에이전트에 맡겼고, 특정 에이전트·모델 조합에서 기능상 정답인 결과가 61%였던 반면 안전하다고 평가된 결과는 10.5%였습니다. 이 수치를 모든 도구에 일반화할 수는 없습니다. 다만 기능 테스트 통과와 보안 검토 통과는 다른 사건이라는 점은 잘 보여 줍니다.
세 번째 검토: 로그인과 권한을 따로 본다
로그인은 “누구인지”를 확인합니다. 권한은 “그 사람이 이 행동을 해도 되는지”를 확인합니다.
관리자 메뉴를 화면에서 숨겨도 서버의 관리자 주소가 열려 있다면 권한 통제가 아닙니다. 사용자는 화면을 거치지 않고 요청 주소를 직접 호출할 수 있기 때문입니다. 서버는 매 요청마다 최소한 네 가지를 다시 판단해야 합니다.
- 로그인 상태가 유효한가
- 요청한 데이터가 그 사용자의 것인가
- 해당 역할이 이 행동을 할 수 있는가
- 세션이 취소되거나 만료되지 않았는가
패스키처럼 강한 로그인 방식을 쓰더라도 권한 검사가 빠지면 다른 사람의 데이터가 노출될 수 있습니다. 로그인 수단의 강도와 서버가 수행하는 권한 검사는 서로 다른 층으로 봐야 합니다.
네 번째 검토: 데이터가 들어와서 사라질 때까지 그린다
개인정보 처리방침을 붙였다고 데이터 설계가 끝난 것은 아닙니다. 이름과 이메일이 어디에 저장되고, 누구에게 전송되고, 탈퇴 후 언제 지워지는지까지 이어져야 합니다.
각 화살표 옆에는 네 가지 메모가 필요합니다. 수집 목적, 접근자, 보관 기간, 삭제 방식입니다. AI 기능이 있다면 사용자의 입력이 외부 모델 사업자에게 전송되는지도 포함됩니다. 기기 안에서 처리하는 대안을 검토할 때는 온디바이스 LLM 개인정보 가이드가 이어지는 읽을거리입니다.
다섯 번째 검토: 비용과 장애를 숫자로 제한한다
사용자가 열 명일 때 무료였던 앱이 천 명일 때도 무료인 것은 아닙니다. AI API는 입력 길이, 출력 길이, 재시도, 동시 요청에 따라 비용이 달라집니다. 파일 저장과 이미지 변환, 문자 발송도 같은 방식으로 누적됩니다.
운영 전에 다음 숫자가 있어야 합니다.
- 사용자 한 명의 분당·일당 요청 상한
- 입력 글자 수와 파일 크기 상한
- 몇 초 후 요청을 중단할지
- 월 예산의 경고선과 강제 중단선
- 자동 재시도 횟수와 간격
- 트래픽 급증 때 읽기 전용으로 바꿀 기준
여기서 중요한 것은 정교한 예측보다 끝없이 늘어나지 않게 막는 장치입니다. 실패한 요청을 무한 재시도하면 장애가 비용 폭증으로 이어질 수 있습니다.
여섯 번째 검토: 문제가 생겼다는 사실을 먼저 알 수 있는가
운영자는 사용자의 항의 메일보다 먼저 장애를 알아야 합니다. 이를 위해 로그, 지표, 알림이 필요합니다.
- 로그는 한 요청에서 무슨 일이 있었는지 남깁니다.
- 지표는 오류율·응답 시간·결제 실패율의 변화를 보여 줍니다.
- 알림은 정해 둔 기준을 넘었을 때 사람을 호출합니다.
모든 입력을 그대로 로그에 남기는 것은 위험합니다. 비밀번호, 인증 토큰, 카드 정보, 주민등록번호처럼 민감한 값은 가리거나 애초에 기록하지 않아야 합니다. 로그의 목적은 사건을 재구성하는 것이지 데이터를 복제하는 것이 아닙니다.
일곱 번째 검토: 되돌리는 데 몇 분이 걸리는가
롤백은 “예전 코드를 다시 올리면 된다”보다 넓은 개념입니다. 코드, 데이터베이스, 외부 연동, 사용자 안내가 함께 움직입니다.
예를 들어 새 버전이 예약 상태 값을 confirmed에서 paid로 바꿨다면 코드만 예전 버전으로 되돌렸을 때 기존 데이터가 읽히지 않을 수 있습니다. 결제 사업자에는 이미 승인된 거래가 남아 있을 수도 있습니다.
배포 전 한 장으로 적을 내용은 다음과 같습니다.
| 항목 | 적어 둘 답 |
|---|---|
| 배포 책임자 | 누가 공개 범위를 넓히는가 |
| 중단 기준 | 어떤 오류율·결제 실패율에서 멈추는가 |
| 이전 버전 | 어느 버전으로 돌아가는가 |
| 데이터 복구 | 백업 시점과 복원 방법은 무엇인가 |
| 외부 처리 | 결제·메일·문자 취소는 누가 하는가 |
| 사용자 안내 | 어디에 어떤 문구를 공지하는가 |
“문제가 생기면 AI에게 고쳐 달라고 한다”는 복구 계획이 아닙니다. 장애 중에는 원인을 모르는 상태에서 새 변경을 더하는 일이 위험을 키울 수 있습니다.
혼자 배포해도 되는 범위, 도움을 받아야 하는 범위
작은 앱이라고 항상 안전한 것은 아니고, 큰 앱이라고 항상 위험한 것도 아닙니다. 피해의 크기와 되돌리기 난이도가 기준입니다.
| 프로젝트 | 개인 시험에 적합 | 공개 전 별도 검토가 필요한 지점 |
|---|---|---|
| 계산기·개인 메모 | 대체로 적합 | 백업, 오류 처리 |
| 행사 안내 페이지 | 대체로 적합 | 문의 폼 스팸, 접근성, 개인정보 문구 |
| 회원제 커뮤니티 | 주의 | 인증, 권한, 신고·차단, 삭제 요청 |
| 예약·결제 | 고위험 | 동시성, 중복 결제, 환불, 장애 대응 |
| 의료·금융·법률 판단 | 매우 고위험 | 규제, 책임, 전문가 최종 판단 |
| 사내 데이터 연결 | 매우 고위험 | 최소 권한, 퇴사자 처리, 감사 로그 |
초보자에게 좋은 첫 프로젝트는 기능이 단순한 앱이 아니라 실패해도 다른 사람의 돈과 계정이 다치지 않는 앱입니다.
AI에게 다시 물어볼 때 유용한 질문
“문제 없어?”라고 물으면 대답도 넓고 낙관적일 수 있습니다. 범위를 좁힌 질문이 낫습니다.
이 변경을 공개 배포한다고 가정한다.
1. 정상 경로가 아니라 실패 경로를 8개 찾아라.
2. 다른 사용자의 데이터에 접근할 수 있는 서버 요청을 표시하라.
3. 중복 클릭·재시도·네트워크 단절 때 데이터가 어떻게 남는지 설명하라.
4. 새로 추가된 패키지와 외부 전송을 목록으로 만들어라.
5. 이 변경을 10분 안에 되돌리려면 무엇이 준비돼야 하는가.
확인하지 못한 항목은 추측하지 말고 '검증 필요'로 표시하라.이 프롬프트도 검토를 대신하지 않습니다. 다만 “괜찮다”는 인상 대신 확인할 대상을 뽑아내는 데 유용합니다. 같은 모델의 자기검토만 믿기보다 자동 테스트, 정적 분석, 실제 시나리오, 다른 사람의 리뷰를 겹치는 편이 낫습니다. 여러 도구와 사내 데이터까지 연결한다면 기업 AI 에이전트 도입 가이드의 권한·승인 기준도 함께 적용해야 합니다.
출시 버튼 앞에서 남겨야 할 기록
바이브 코딩으로 만든 앱이 프로덕션에 갈 수 있는지는 코드가 AI로 만들어졌는지보다 누가 무엇을 확인했고, 실패하면 어떻게 멈추며, 누구에게 어떤 피해가 생길 수 있는지에 달려 있습니다.
- 이번 변경의 완료 조건과 실패 조건이 한 문장으로 적혀 있다
- AI가 수정한 파일·패키지·환경 변수·데이터베이스 변경을 확인했다
- 다른 사용자 데이터 접근, 중복 클릭, 네트워크 단절을 직접 시험했다
- 로그인과 서버 권한 검사를 구분해 확인했다
- 개인정보의 수집·외부 전송·보관·삭제 경로가 문서화돼 있다
- 비용 상한, 오류 알림, 자동 재시도 한도가 정해져 있다
- 문제 발생 시 이전 버전과 데이터로 돌아가는 절차가 있다
- 결제·의료·금융·사내 데이터처럼 고위험 기능은 독립 검토를 받았다
반복 업무 자체를 AI에게 맡길 때의 범위 설계는 개인 AI 에이전트 운영법에서 더 자세히 이어집니다.
마지막 질문은 간단합니다. “이 앱은 잘 돌아가는가?”가 아니라 “잘못 돌아갔을 때도 우리가 책임 있게 멈출 수 있는가?”입니다. 그 질문에 구체적인 답이 생기는 순간, 데모는 비로소 서비스에 가까워집니다.