바이브 코딩을 처음 시작할 때 어떻게 하냐는 질문이 들어와 간단하게 정리해봤습니다. 시작할 때는 어떤 범위로 얼마나 구현할지 먼저 정하는 게 좋습니다. 너무 큰 프로젝트를 고르면 AI가 만들어준 결과를 검증하기 어렵고, 너무 막연한 요구를 던지면 어디서부터 고쳐야 할지 알기 어렵습니다.
그래서 이번 라이브에서는 일부러 조건을 랜덤으로 정했습니다. [그림 1]처럼 도구, 주제, 스택, 기능을 슬롯머신처럼 뽑고, 그 조합 안에서 실제로 작동하는 작은 앱을 만들었습니다. 미리 각본을 짜고 완성된 결과만 보여주기보다, 라이브로 뽑힌 조건을 보면서 그 자리에서 방향을 잡는 게 좀 더 설명에 편할 것 같았거든요. 중간에 화면이 원하는 대로 안 나오거나, AI가 엉뚱한 구현을 하거나, 제가 다시 설명을 붙이는 장면도 그대로 있었습니다.
완성도가 목표라기보다, AI 코딩 도구를 어떻게 다루고 어디를 의심해야 하는지 보는 것이 목표였습니다. 특히 이 글에서 말하는 바이브 코딩은 개인이 테스트용으로 작은 앱을 만들고 검증해보는 수준을 기준으로 합니다. 다른 사람에게 공개하거나 실제 서비스를 운영하는 용도로 바로 쓰는 것은 추천하지 않습니다.
그림 1. 랜덤으로 조건을 정하는 선택기 화면
랜덤은 재밌다
랜덤으로 정하면 이상한 조합이 나옵니다. 하지만 그 이상함이 오히려 연습에는 좋습니다. 재미가 있으니까요.
이번에 나온 첫 번째 조합은 대략 이런 방향이었습니다.
- 도구는 ‘안티그래비티’
- 주제는 운빨
- 결과물은 기록장 또는 트래커
- 화면에는 애니메이션과 시각적 피드백이 필요합니다
- Vite, Recharts 같은 프론트엔드 스택을 활용합니다
처음에는 운빨과 기록장이 뭔가 조합이 잘 안돼서 클로드에 물어봤습니다. 덕분에 랜덤으로 스탯을 뽑고, 그날의 운을 점수화하고, 기록을 남기는 앱이라는 발상을 얻을 수 있었습니다. 이름을 붙이면 ‘오늘의 운빨’이 됐죠. 작은 앱이지만 미니게임, 입력, 계산, 화면 표시, 기록, 다시 뽑기 같은 요소가 들어갔죠. AI 코딩 도구를 연습하기에 적당한 프로젝트죠.
AI가 만든 결과는 반드시 의심해야 합니다
바이브 코딩으로 앱을 만들면 화면은 금방 나옵니다. 요즘 도구들은 기본 UI를 꽤 그럴듯하게 만들고, 차트나 카드 UI도 빠르게 붙입니다. [그림 2]처럼 시각적인 완성도는 생각보다 빠르게 올라옵니다.
그림 2. ‘오늘의 운빨’ 앱 결과 화면
문제는 그럴듯한 화면과 맞는 로직이 별개의 문제라는 점입니다.
라이브에서는 AI가 만들어준 앱에 이미 기록이 들어가 있는 것처럼 보이는 문제가 있었습니다. 사용자가 아무것도 하지 않았는데 과거 기록이 있는 것처럼 보이면, 데모 데이터인지 실제 기록인지 헷갈립니다. 점수와 등급이 맞지 않는 문제도 있었습니다. 화면에는 B급처럼 보이는데 계산 기준을 보면 다른 결과가 나왔죠.
이런 오류는 바이브 코딩에서 자주 나옵니다. 겉으로는 완성된 것처럼 보이는데, 눌러보면 계산이 맞지 않거나, AI가 편의를 위해 넣어둔 가짜 데이터가 진짜 기록처럼 보이는 식입니다. AI는 사용자가 원하는 분위기와 형태를 빠르게 맞추지만, 데이터의 의미와 계산 규칙을 끝까지 보장하지는 않습니다. 그래서 최소한 다음은 직접 확인해야 합니다.
- 처음 실행했을 때 없는 데이터가 있는 것처럼 보이지 않는지 확인합니다
- 같은 입력을 넣었을 때 같은 결과가 나오는지 확인합니다
- 점수, 등급, 설명 문구가 서로 일치하는지 확인합니다
- 새로고침하거나 다시 실행해도 상태가 이상하게 남지 않는지 확인합니다
- AI가 기존 주석이나 중요한 안내를 지우지 않았는지 확인합니다
바이브 코딩은 대충 맡기면 끝나지 않습니다. 사람이 결과를 보고 계속 좁혀가야 합니다. AI가 빠르게 만들고, 사람이 이상한 부분을 찾아 다시 시킵니다. 이 왕복이 실제 바이브 코딩입니다.
디자인 기준을 설정하는 design.md
디자인을 예쁘게 해달라고만 하면 결과는 들쭉날쭉합니다. 라이브에서는 디자인 방향을 문서로 정리하고, 참고할 분위기를 지정하는 방식으로 개선했습니다. 예를 들어 엔비디아 스타일처럼 어두운 배경, 초록색 포인트, 기술적인 대시보드 느낌을 지정하면 AI가 훨씬 일관된 화면을 만듭니다.
여기서 design.md 같은 파일이 유용합니다. 매번 채팅창에 디자인 설명을 반복하는 대신, 프로젝트 안에 디자인 기준을 남겨두는 것입니다.
이 방식은 PPT를 만들 때도 비슷하게 적용됩니다. 예쁜 PPT라는 말보다 어떤 청중을 위한 발표인지, 어떤 회사나 제품의 분위기를 참고할지, 한 장에 들어갈 정보량은 어느 정도인지가 더 중요합니다. 바이브 코딩에서 디자인은 감각 싸움처럼 보이지만, 실제로는 기준을 얼마나 잘 적어두느냐의 문제에 가깝습니다.
두 번째 예제: 온라인 청첩장
두 번째로는 온라인 청첩장을 만들었습니다. 요청 조건은 더 현실적이었습니다. 결혼식 정보를 보여주고, 어르신도 보기 좋게 큰 글자 모드를 제공하고, 참석 여부도 받을 수 있어야 합니다.
이 정도가 되면 단순한 정적 페이지가 아닙니다. 화면, 상태, 입력 폼, 저장소, 관리자 확인 화면이 필요합니다. AI에게 바로 만들라고 하기보다 먼저 계획을 짜게 하는 편이 낫습니다. [그림 3]처럼 계획을 먼저 만들면 구현 범위가 훨씬 잘 보입니다.
그림 3. AI가 만든 온라인 청첩장 구현 계획
계획을 먼저 보면 어느 순간부터 일이 커지는지 보입니다. 예쁘게 보이는 청첩장 화면만 만들면 간단하지만, 참석 응답을 저장하고 관리자만 확인하게 하려면 저장소와 권한 문제가 생깁니다. Vercel에 배포할지, Supabase를 쓸지, Google 스프레드시트와 Google Apps Script로 처리할지 같은 선택지도 생깁니다.
라이브에서는 복잡한 백엔드 대신 Google 스프레드시트와 Google Apps Script를 활용하는 방향으로 접근했습니다. 작은 규모의 개인용 프로젝트라면 이 방식이 꽤 실용적입니다. 별도 서버를 크게 운영하지 않아도 되고, 응답 결과를 Google 스프레드시트에서 바로 확인할 수 있습니다.
그림 4. 온라인 청첩장 미리보기와 작업 로그
하지만 여기서도 AI에게 완전히 맡기면 안 됩니다. AI가 먼저 구현을 시작해버리거나, 확인해야 할 설정을 뒤로 미루거나, 필요한 안내를 빼먹을 수 있습니다. 특히 외부 서비스와 연결되는 순간부터는 사람이 흐름을 잡아야 합니다.
연결이 늘어나면 책임도 늘어납니다
청첩장처럼 실제 사람에게 공개되는 앱은 단순한 데모와 다릅니다. 지도가 들어가면 카카오나 다른 지도 API 키가 필요할 수 있고, 참석 여부를 받으면 개인정보가 들어옵니다. [그림 5]처럼 저장 기능을 연결하는 순간부터 공개 링크를 배포했을 때의 책임도 함께 생각해야 합니다.
그래서 라이브에서도 바이브 코딩을 실제 상용 서비스 제작법처럼 권하지는 않았습니다. 개인이 테스트용으로 만들어보고, 내 컴퓨터나 제한된 환경에서 확인하는 정도라면 좋은 연습이 됩니다. 하지만 다른 사람의 정보를 받거나, 결제나 예약처럼 실제 피해가 생길 수 있는 기능을 붙이거나, 불특정 다수에게 공개하는 순간부터는 이야기가 달라집니다. 그때는 보안, 운영, 법적 책임을 별도로 점검해야 합니다.
그림 5. Google Apps Script 연결 작업
그래서 공개 서비스로 만들 때는 기능보다 먼저 확인해야 할 것이 있습니다.
- API 키가 브라우저에 그대로 노출되지 않는지 확인합니다
- 관리자 화면에 아무나 접근할 수 있지 않은지 확인합니다
- 참석자 이름, 연락처, 메시지 같은 개인정보를 어떻게 보관할지 정합니다
- 상업적으로 운영한다면 사업자 등록이나 약관이 필요한지 확인합니다
- 개인정보보호법을 고려해야 하는지 확인합니다
- Vercel, Supabase, Google 스프레드시트 같은 외부 서비스의 권한 설정이 적절한지 확인합니다
AI는 이런 항목을 말해달라고 하면 대체로 알려줍니다. 하지만 사용자가 묻지 않으면 그냥 넘어가는 경우도 많습니다. 바이브 코딩으로 만든 결과를 실제 서비스처럼 공개하려면, 보안과 법적 책임은 별도로 점검해야 합니다.
특히 개인용으로 써볼 앱과 다른 사람의 정보를 받는 서비스는 다르게 봐야 합니다. 전자는 빠르게 만들어도 괜찮지만, 후자는 저장, 삭제, 접근 권한, 책임 주체까지 생각해야 합니다.
바이브 코딩을 시작하는 기준
첫째, 처음부터 큰 서비스를 만들려고 하지 않는 것이 좋습니다. 작은 앱을 만들고, 실행하고, 이상한 점을 고치면서 AI 도구의 성향을 익히는 편이 낫습니다.
둘째, 프롬프트에는 기능만 쓰지 말고 사용자를 써야 합니다. ‘온라인 청첩장을 만들어줘’보다 ‘어르신도 봐야 하니 큰 글자 모드가 필요하고, 친구들은 일반 모드로 볼 수 있어야 한다’ 같은 조건을 붙이는 게 훨씬 낫습니다.
셋째, 계획과 디자인 기준을 파일로 남기는 것이 좋습니다. plan.md, design.md 같은 문서가 있으면 AI가 프로젝트의 방향을 잃을 가능성이 줄어듭니다.
넷째, 실행 결과를 직접 눌러봐야 합니다. 화면이 예뻐도 계산이 틀릴 수 있고, 버튼은 있어도 저장이 안 될 수 있습니다. AI가 만든 앱은 데모 화면이 아니라 동작으로 검증해야 합니다.
다섯째, 외부 서비스와 개인정보가 들어가면 속도를 늦춰야 합니다. 바이브 코딩은 빠르게 만들기에는 좋지만, 빠르게 공개해도 된다는 뜻은 아닙니다.
여섯째, 개인 테스트와 실제 서비스의 선을 분명히 그어야 합니다. 바이브 코딩으로 만든 결과는 먼저 개인용 실험물로 보고, 충분히 검증한 뒤에야 공개 여부를 고민하는 편이 안전합니다.
마무리
바이브 코딩은 코드를 모르는 사람이 모든 책임을 AI에게 넘기는 방법이 아닙니다. 반대로 개발자가 모든 것을 직접 짜야 한다는 방식도 아닙니다.
작은 목표를 잡고, AI에게 초안을 만들게 하고, 사람이 실행해보며 이상한 부분을 찾고, 다시 고치게 하는 흐름입니다. 이 과정에서 중요한 것은 완벽한 첫 프롬프트가 아니라 계속 확인하는 태도입니다.
랜덤으로 정한 운빨 스탯 트래커와 온라인 청첩장은 완성품이라기보다 좋은 연습 문제였습니다. 하나는 화면과 로직 검증을 보여줬고, 다른 하나는 배포와 저장소, 개인정보 문제를 보여줬습니다. 라이브로 보니 매끈한 완성 사례보다 오히려 이런 시행착오가 더 잘 드러났습니다.
바이브 코딩을 시작하고 싶다면 거창한 서비스를 고르기보다, 오늘 하나의 작은 앱을 정해서 끝까지 눌러보는 편이 낫습니다. 다만 그 결과는 어디까지나 개인 테스트 용도로 사용하는 편이 좋습니다. AI가 만들어준 결과를 그대로 믿지 않고, 내가 이해할 수 있는 크기로 줄여서 검증하세요.