바이브코딩 리뷰 관점에서 보면, 바이브코딩은 프롬프트 한 번으로 앱 하나를 뚝딱 완성하는 일이 아닙니다. AI가 실제 코드를 작성해 주기 때문에 구현 시간은 크게 줄일 수 있지만, 원하는 결과에 도달하려면 아이디어를 문서화하고, 로드맵을 검증하고, 구현 결과를 눈으로 확인하고, 다시 수정하는 과정을 끈질기게 반복해야 합니다. 제가 여러 앱을 동시에 개발하면서 정착시킨 워크플로우 역시 결국 구현·리뷰·수정이라는 세 단어로 요약됩니다.
바이브코딩 리뷰: 많이 만들지만, 가볍게 만들지는 않습니다
시아메이커랩은 한 번에 여러 프로젝트를 진행하며 제한된 시간 안에 가능한 한 많은 앱을 배포하려 노력하는 1인 개발자이자 1인 사업자입니다. 동시에 제게는 충실해야 할 본업인 회사 생활이 있습니다. 개발에 쓸 수 있는 시간은 회사에서 간간이 생기는 짧은 틈이나 가족이 잠든 뒤의 시간처럼 잘게 나뉘어 있습니다.
그래서 잠깐의 여유에도 프롬프트를 하나라도 더 보내려 하고, 같은 시간에 더 정확한 결과를 얻을 수 있는 프롬프트가 무엇인지 매번 고민합니다. 효율은 제게 선택이 아니라 여러 프로젝트를 계속 이어가기 위한 생존 방식에 가깝습니다. 그렇다고 앱 하나하나를 가벼운 마음으로 대충 만든다는 뜻은 아닙니다. 빠르게 만드는 것과 확인하지 않고 내놓는 것은 전혀 다른 일입니다.
초기에는 구현 결과를 충분히 재확인하지 않고 업로드했다가 앱이 시작하자마자 크래시해 사용자가 그대로 떠나는 일을 몇 차례 겪었습니다. 개발 환경에서는 잘 실행되던 앱이 새로 설치된 기기에서는 알 수 없는 이유로 열리지 않는 상황이었습니다. 그 경험 이후 배포 전 결과물을 최대한 직접 확인하고, 특히 앱 데이터와 프로세스가 없는 상태에서 처음부터 실행하는 콜드 스타트 테스트를 반드시 거치는 습관이 생겼습니다.
1단계: 아이디어를 MVP 문서로 고정합니다
앱 아이디어가 떠오르면 곧바로 구현부터 시작하지 않습니다. 먼저 ChatGPT와 대화하며 아이디어를 최소 기능 제품, 즉 MVP의 형태로 구체화합니다. 이 앱이 누구의 어떤 문제를 해결하는지, 가장 먼저 동작해야 할 핵심 기능은 무엇인지, 첫 버전에서 제외해도 되는 것은 무엇인지 정리합니다.
정리한 내용은 Claude Code나 Codex가 작업하는 프로젝트의 루트에 mvp.txt로 저장합니다. 그리고 다음과 같은 요청으로 첫 로드맵을 만듭니다.
루트에 저장된 mvp.txt 문서를 분석하고, 실질적인 기능 구현을 위한 로드맵 문서를 작성해 줘.
여기서 만들어진 로드맵은 완성된 계획이 아니라 첫 번째 초안입니다. AI가 그럴듯한 단계와 기능을 적었다는 이유만으로 바로 구현에 들어가면, 중간에 지원되지 않는 라이브러리를 발견하거나 서로 충돌하는 설계 때문에 큰 부분을 다시 만들 수 있습니다. 따라서 실제 구현보다 먼저 로드맵 자체를 여러 관점에서 반복 검토합니다.
2단계: 로드맵을 여러 방향에서 공격적으로 검토합니다
로드맵 검토는 한 번의 긴 프롬프트로 끝내기보다 목적을 나누어 여러 차례 진행합니다. 한 번에 너무 많은 기준을 요청하면 각 항목의 검토가 얕아지거나 중요한 문제가 다른 요구에 묻히기 쉽기 때문입니다. 제가 주로 확인하는 축은 다음과 같습니다.
- 구현 순서: 선행 작업과 의존 관계에 맞게 단계가 배열되어 있는지 확인합니다.
- 기술적 실현 가능성: 각 기능이 Android에서 실제로 구현 가능한지, 필요한 리소스와 라이브러리를 확보할 수 있는지 검토합니다.
- UI·UX: 현재 앱의 핵심 작업에 맞는 화면 구조와 사용자 흐름을 구상해 로드맵에 반영합니다.
- 라이선스: 공식 문서와 저장소를 확인해 상업용 배포에 문제가 없는지 살핍니다. 특히 GPL·AGPL처럼 프로젝트 전체에 영향을 줄 수 있는 조건을 주의합니다.
- 버전과 의존성: 실제 사용할 라이브러리와 현재 시점의 최신 안정 버전을 기록하고, 버전 충돌 가능성을 구현 전에 점검합니다.
- 시장과 핵심 가치: 주요 경쟁 앱과 잠재 경쟁 제품의 기능 차이를 조사하고, 사용자들이 실제로 원하는 핵심 가치가 로드맵에 구현되어 있는지 확인합니다.
- 사용자 불편: 커뮤니티와 리뷰에서 반복되는 불편 사항과 개선 요청을 찾아 Android에서 실현 가능한 범위로 확장합니다.
- 계획 정합성: 구현 불가능한 항목, 서로 충돌하는 계획, 비용과 난이도에 비해 가치가 낮은 기능을 찾아 제거하거나 수정합니다.
실제로는 위 목록보다 더 많은 질문을 던집니다. 같은 로드맵을 “실현 가능한가”, “사용자에게 가치가 있는가”, “배포해도 법적으로 안전한가”, “유지보수할 수 있는가”라는 서로 다른 렌즈로 계속 들여다봅니다. 검토 결과가 나올 때마다 로드맵을 갱신하고, 다시 전체 흐름을 읽어 앞뒤가 어긋난 곳은 없는지 확인합니다.
이 단계는 얼핏 구현을 미루는 일처럼 보일 수 있습니다. 하지만 잘못된 방향으로 빠르게 달리는 것보다 출발 전에 방향을 교정하는 편이 훨씬 저렴합니다. 제가 기대하는 최종 결과물과 충분히 가까운 계획이 되었다고 느낄 때 비로소 장시간 구현 작업을 시작합니다.
3단계: 잠들기 전 장시간 구현 목표를 맡깁니다
보통 아이를 돌보다 잠들기 전, AI 에이전트에게 로드맵 전체 구현을 목표로 전달합니다. 제가 사용하는 지시의 형태는 대략 다음과 같습니다.
/goal 모든 로드맵 계획을 구현하고, 모든 계획이 완료될 때까지 멈추지 마.
각 항목이 마무리될 때마다 단위 테스트, 버전 관리, Git 커밋을 실행하고
로드맵 문서에 해당 항목이 완료되었음을 체크해 줘.그러면 AI는 제가 자는 동안 로드맵의 기능을 차례로 구현합니다. 보통 다음 날 아침이면 완료되어 있지만, 규모에 따라 이틀 가까이 계속 작업하는 경우도 있습니다. 이 방식의 장점은 사람이 자거나 본업을 수행하는 시간에도 구현이 진행된다는 점입니다. 다만 오래 실행된다는 사실이 올바른 결과를 보장하지는 않습니다. 작업 범위가 클수록 중간 판단이 누적되며 처음 의도에서 멀어질 가능성도 함께 커집니다.
4단계: 완료 보고를 믿지 않고 갭을 다시 찾습니다
AI가 “로드맵을 모두 완료했다”고 보고해도 그것으로 끝내지 않습니다. 로드맵과 현재 앱의 구현 상태를 다시 정밀 비교해 빠진 기능, 형식적으로만 연결된 화면, 원래 의도와 다르게 해석된 동작을 찾습니다. 확인된 차이는 로드맵에 올바르게 기록하고, 남은 항목을 구현하는 2차 작업을 시작합니다. 필요하다면 3차, 4차 작업도 이어집니다.
이때 중요한 것은 문서의 체크 표시가 아니라 실제 앱의 상태입니다. 테스트를 통과했다는 기록이 있어도 기능이 사용자가 기대하는 흐름으로 이어지지 않을 수 있고, 버튼이 동작하더라도 화면 구성이 불편할 수 있습니다. 그래서 로드맵의 완료 여부와 제품의 완성도를 서로 다른 문제로 다룹니다.
5단계: 전문 관점과 실제 기기 흐름으로 리뷰합니다
Kotlin 앱이라면 Material 3, Jetpack Compose, Adaptive UI 등 분야별 지침과 전문 스킬을 활용해 화면과 구조를 여러 차례 검토합니다. 휴대전화 한 대에서 보기 좋은 화면이 태블릿이나 폴더블에서도 자연스러운지, 컴포넌트의 상태와 내비게이션이 Compose 방식에 맞는지, 접근성과 터치 영역이 충분한지 확인합니다.
그다음에는 mobile-mcp 같은 도구로 에뮬레이터를 조작하며 버튼을 하나씩 눌러 봅니다. 화면을 여는 것만으로는 부족합니다. 데이터를 입력하고, 저장하고, 취소하고, 뒤로 이동하고, 오류 상황을 만들고, 앱을 다시 실행해 상태가 올바르게 남는지 살핍니다. 도구를 이용한 검증과 함께 제가 직접 앱을 사용하면서 느끼는 불편도 계속 기록합니다.
이 단계에서는 의도와 실제 UI·UX가 어긋난 부분이 끊임없이 발견됩니다. 경쟁 앱을 다시 살펴보기도 하고, 사용자 핵심 가치가 정말 눈에 보이는 기능으로 구현되었는지 AI에게 반복해서 질문하기도 합니다. 완성품을 한 번에 찍어내는 느낌보다는 거친 조각을 조금씩 깎아 원하는 형태에 가까워지게 만드는 과정에 더 가깝습니다.
6단계: 배포 전 콜드 스타트까지 확인합니다
기능 검토가 끝나면 전체 기능 리뷰와 오류 점검을 다시 수행합니다. 그리고 반드시 앱이 이미 실행 중인 상태가 아니라, 프로세스가 완전히 종료된 상태에서 처음부터 시작되는지를 확인합니다. 필요하면 앱 데이터가 없는 신규 설치 조건에서도 실행합니다.
콜드 스타트에서는 초기화 순서, 저장 데이터 마이그레이션, 권한, 네트워크 연결, 의존성 주입처럼 평소 실행 중에는 드러나지 않는 문제가 한꺼번에 나타날 수 있습니다. 사용자가 앱을 다운로드한 뒤 첫 화면조차 보지 못하고 떠나는 일을 완전히 없앨 수는 없겠지만, 최소한 제가 재현할 수 있는 시작 단계의 실패는 배포 전에 막으려 합니다.
바이브코딩에서 절약되는 것은 타이핑이지 판단이 아닙니다
바이브코딩은 개발자가 코드를 한 줄씩 직접 수정하는 시간을 크게 줄여 줍니다. 그러나 프로그램 하나를 별다른 노력 없이 아주 짧은 시간에 완성해 준다는 뜻은 아닙니다. 무엇을 만들지 정의하고, 계획의 허점을 찾고, AI가 잘못 이해한 방향을 바로잡고, 결과를 검증하는 일은 여전히 개발자의 몫입니다.
AI가 코드를 대신 작성해도, 제품에 대한 책임과 최종 판단까지 대신 맡아 주지는 않습니다.
대부분의 시간은 화려한 생성의 순간보다 기다리고, 읽고, 틀린 부분을 찾고, 다시 요청하는 인내의 과정에 가깝습니다. 특히 앱이 처음 원하던 방향에서 벗어나 엉뚱한 구조로 자라기 시작하면 충격과 공포에 가까운 시간을 만나기도 합니다. 그럴수록 한 번에 모든 것을 뒤집기보다 로드맵과 현재 상태의 차이를 작게 나누고, 구현·리뷰·수정의 순환으로 다시 중심을 잡아야 합니다.
개발 이야기에는 앞으로도 제가 이 과정에서 겪은 실패와 해결 과정, 반복 작업을 조금 줄여 준 팁을 계속 남겨 보려 합니다. 바이브코딩에 도전하는 예비 바이브코더 여러분께 이 글이 “왜 생각보다 오래 걸리지?”라는 불안을 덜고, 자신만의 검증 습관을 만드는 작은 출발점이 되었으면 합니다.
답글 남기기