모바일 Lovable 작업은 handoff bundle로 끊기

2026년 4월 29일 | 바이브코딩 Tips

---

Lovable이 iOS와 Android 앱으로 들어왔다는 소식을 보고 제일 먼저 든 생각은 "이제 폰에서도 웹앱을 만들 수 있겠네"가 아니었다. 오히려 나는 모바일에서 시작한 vibe coding 작업을 어디서 끊어야 하는가 쪽에 더 눈이 갔다. Vibe Coding은 자연어 지시로 코드나 앱 구조를 만들어 가는 방식인데, 모바일 앱이 붙으면 시작은 훨씬 쉬워지고 마무리는 더 위험해진다. 지하철에서 떠오른 아이디어를 음성으로 던지는 건 좋지만, 그 결과를 바로 배포 가능한 변경으로 취급하면 맥락이 너무 얇다.

TechCrunch는 4월 28일 Lovable이 모바일 앱을 출시했고, 음성 또는 텍스트 프롬프트로 이동 중에도 웹사이트와 웹앱 아이디어를 만들 수 있게 했다고 보도했다. 동시에 Apple의 App Store 규칙 때문에 vibe-coding 앱이 호스트 앱 안에서 새 코드를 내려받거나 기능을 바꾸는 식으로 동작하기는 어렵고, 생성된 앱 프리뷰가 웹 브라우저 쪽으로 이동했다는 설명도 같이 붙어 있었다. 나는 이 대목에서 무릎을 쳤다. 모바일 앱은 구현 환경이라기보다 캡처 환경에 더 가깝게 써야 한다는 뜻으로 읽혔기 때문이다.

Lovable 모바일 앱 화면. 이동 중 프롬프트 입력은 쉬워졌지만, 검증과 병합까지 같은 화면에서 끝내면 위험해진다. 이미지 출처: TechCrunch / Lovable.

모바일 vibe coding의 함정: 시작 속도와 종료 기준이 따로 논다

폰에서 프롬프트를 던지는 순간은 보통 맥락이 빈약하다. 노트북 앞에서라면 기존 이슈, 테스트 실패 로그, 최근 diff, 환경 변수, 배포 브랜치 상태를 같이 보는데, 모바일에서는 대부분 "이런 기능 하나 있으면 좋겠다" 정도의 아이디어만 있다. 이 상태에서 에이전트가 autonomously run 된다는 말은 편한 동시에 불편하다. 실행은 자동인데, 요구사항은 아직 반쯤 말로만 떠 있는 상태라서 그렇다.

그래서 나는 모바일 Lovable 같은 도구를 쓴다면 첫 번째 규칙을 이렇게 잡는 편이 낫다고 본다. 폰에서는 구현을 끝내지 말고 handoff bundle만 만든다. 여기서 handoff bundle은 대단한 문서가 아니다. 데스크톱으로 돌아왔을 때 바로 검증할 수 있게 목표, 건드린 표면, 보류한 결정, 테스트 명령, 배포 금지를 한 묶음으로 남긴 작은 파일이다. 이름은 거창하게 붙였지만 실제로는 30줄짜리 메모면 충분하다.

프롬프트에 먼저 넣을 한 줄

내가 모바일에서 쓴다면 첫 프롬프트는 기능 설명보다 아래 문장으로 시작할 것 같다. 핵심은 생성 자체를 막는 게 아니라, 생성 결과를 곧장 최종 산출물로 착각하지 않게 만드는 것이다.

이 작업은 모바일 초안 단계다. 배포하거나 publish하지 말고, 변경 제안과 preview URL, 검증해야 할 handoff bundle만 만들어라. 기존 인증, 결제, 데이터 삭제, 권한 관련 로직은 건드리지 마라.

이 한 줄을 넣으면 에이전트의 역할이 조금 달라진다. "기능을 끝내는 사람"이 아니라 "데스크톱 검토로 넘길 초안을 만드는 사람"이 된다. 별 차이 없어 보이지만, 실제 작업에서는 꽤 크다. 특히 모바일에서 말로 아이디어를 던질 때는 금지 범위가 빠지기 쉽다. 로그인, 결제, 권한, 데이터 삭제 같은 부분은 건드리지 말라고 먼저 못 박아 두는 편이 안전하다.

handoff bundle 템플릿

나는 아래 정도를 최소 템플릿으로 둔다. 프레임워크가 React든 Next.js든, Lovable이 만든 웹앱이든, 다른 AI 빌더가 만든 초안이든 크게 다르지 않다. 중요한 건 "무엇을 만들었는가"보다 무엇을 아직 확인하지 않았는가가 남는 것이다.

# mobile_handoff.md

작업 목표:
- 사용자가 말한 기능을 한 문장으로 다시 쓴다.

변경 제안:
- 새로 만든 화면 또는 컴포넌트
- 수정한 데이터 흐름
- 추가한 외부 API나 라이브러리

건드리지 말아야 할 영역:
- 인증
- 결제
- 권한 체크
- 데이터 삭제/복구
- 운영 환경 설정

프리뷰:
- preview URL
- 확인해야 할 화면 2~3개

데스크톱에서 실행할 검증:
- npm run lint
- npm test
- 핵심 플로우 수동 확인

남은 질문:
- 요구사항이 애매한 부분
- 사용자가 다시 결정해야 하는 부분

이 파일의 장점은 모바일에서 만든 변경을 나중에 읽을 수 있다는 데 있다. vibe coding 작업은 처음에는 빠른데, 하루만 지나도 내가 무슨 말을 시켰는지 흐려진다. 특히 음성 프롬프트는 더 그렇다. 말할 때는 자연스럽지만, 나중에 보면 요구사항과 잡담이 섞여 있다. handoff bundle은 그 섞임을 한 번 정리해서 데스크톱 작업면으로 넘기는 얇은 게이트다.

나는 여기서 "자동화가 어디까지 했는가"보다 "사람이 어디서 다시 잡을 것인가"를 더 중요하게 본다. 모바일에서 나온 결과물이 아무리 빠르게 보여도, 운영 코드에 들어갈 변경은 결국 재현 가능한 검증 절차를 지나야 한다. 그래서 handoff bundle에는 멋진 설명보다 재실행 가능한 명령, 아직 답하지 않은 질문, 건드리면 안 되는 파일 범위를 우선 넣는다.

데스크톱으로 돌아와서 보는 순서

모바일에서 만든 결과를 열었다면 나는 바로 예쁜 화면부터 보지 않는다. 먼저 변경 범위를 본다. 화면이 그럴듯해도 인증 파일이나 설정 파일이 같이 바뀌어 있으면 경계가 잘못 잡힌 것이다. 로컬 저장소로 export할 수 있는 도구라면 아래 순서가 제일 단순하다.

git diff --stat

git diff --name-only

npm run lint

npm test

여기서 `git diff --name-only` 결과에 예상 밖의 파일이 끼어 있으면, 나는 그 작업을 기능 검토가 아니라 범위 복구 작업으로 바꾼다. 예를 들어 단순한 랜딩 페이지 문구 수정이라고 생각했는데 auth, billing, database migration 쪽 파일이 같이 바뀌었다면 그 변경은 일단 멈춘다. 에이전트가 틀렸다는 뜻이라기보다, 모바일 프롬프트가 충분히 좁지 않았다는 신호에 가깝다.

프리뷰 URL은 완료 신호가 아니다

Lovable 기사에서 흥미로웠던 부분은 generated app preview가 웹 브라우저 쪽으로 이동했다는 점이었다. 이건 사용자 입장에서는 조금 번거롭게 보일 수 있지만, 개발자 입장에서는 오히려 좋은 경계일 수 있다. 프리뷰는 결과를 보는 표면이고, 병합은 별도의 결정이어야 한다. 둘이 같은 버튼으로 붙어 있으면 사람이 확인해야 할 단계를 너무 쉽게 건너뛴다.

그래서 모바일 vibe coding에서는 프리뷰 URL을 "완성본"이 아니라 "검토용 산출물"로 부르는 편이 낫다. 팀 작업이라면 PR 설명에 바로 붙일 수도 있지만, 그때도 handoff bundle의 남은 질문을 같이 붙인다. 내가 실제로 보고 싶은 건 "잘 만들었습니다"가 아니라 "아직 확인하지 않은 것은 이것입니다"에 가깝다.

내가 정한 사용 기준

정리하면, 모바일 Lovable류 도구를 쓸 때 내 기준은 세 가지다. 첫째, 폰에서는 아이디어 캡처와 초안 생성까지만 맡긴다. 둘째, 에이전트에게 배포 금지와 위험 영역 금지를 첫 프롬프트에 넣는다. 셋째, 데스크톱으로 넘어올 때 handoff bundle, diff 범위, 테스트 결과를 한 세트로 본다. 이 정도만 지켜도 "와, 폰에서 앱 만들었다"는 흥분이 "왜 운영 설정이 바뀌었지"라는 허무함으로 넘어가는 일을 꽤 줄일 수 있다.

출처는 TechCrunch의 Lovable 모바일 앱 출시 기사다. 기사에서는 Lovable 앱이 iOS와 Android에 올라왔고, 음성/텍스트 프롬프트로 웹사이트나 웹앱을 만들 수 있으며, Apple의 규칙 때문에 생성 앱을 호스트 앱 내부에서 바로 실행하는 방식에는 제약이 있다는 점을 같이 짚었다. 나는 이 소식을 모바일 개발 도구 뉴스보다, vibe coding 작업을 캡처 단계와 검증 단계로 나눠야 한다는 실무 신호로 읽었다.