프리뷰 링크: 결과물보다 검증 슬롯

2026년 5월 15일 | 바이브코딩 Tips

---

프리뷰 링크가 하나 생기면 작업이 끝난 것처럼 보이지만, 나는 그 링크를 결과물이 아니라 검증 슬롯으로 본다. Lovable 같은 모바일·웹 AI 빌더를 쓰면 화면 하나는 정말 빨리 나온다. 문제는 그 속도 때문에 “일단 보이네”와 “쓸 수 있네” 사이의 틈이 자주 묻힌다는 점이다. 그래서 프리뷰를 공유할 때는 링크만 던지지 않고, 그 링크가 무엇을 검증해야 하는지까지 같이 묶어 두는 편이 덜 흔들렸다.

예전에는 나도 프리뷰 URL을 받으면 바로 디자인부터 봤다. 버튼 간격, 색, 첫 화면의 어색함 같은 게 먼저 눈에 들어왔다. 그런데 실제로 사고가 나는 지점은 조금 달랐다. 링크는 살아 있는데 로그인 뒤 라우팅이 끊기거나, 모바일에서는 카드가 맞는데 데스크톱에서 빈 상태가 깨지거나, 생성된 코드가 한 파일 안에 너무 많은 상태를 밀어 넣어 다음 수정이 어려워지는 식이었다. 화면은 빨리 확인되지만 검증은 느리게 따라오는 구조였던 셈이다.

Figure 1. 프리뷰 링크는 결과 공유가 아니라 다음 검증을 여는 슬롯으로 남겨 두는 편이 안전했다.

1. 프리뷰 링크에는 질문이 같이 붙어야 한다

프리뷰가 위험한 이유는 링크 자체가 너무 그럴듯하기 때문이다. “여기서 확인해 주세요” 한 줄이면 충분해 보이지만, 그 상태에서는 보는 사람마다 다른 것을 본다. 한 사람은 첫 화면만 보고, 다른 사람은 버튼 색만 보고, 또 다른 사람은 URL이 열린다는 사실만 보고 넘어간다. 에이전트가 만든 작업을 받을 때는 이 차이가 꽤 크다. 그래서 나는 프리뷰 링크 옆에 검증 질문을 같이 붙인다.

• 어떤 변경을 확인하는 링크인가: 레이아웃, 라우팅, 폼 상태, 데이터 표시 중 하나로 좁힌다.
• 반드시 눌러야 하는 경로는 무엇인가: 홈 → 상세 → 저장처럼 클릭 순서를 한 줄로 적는다.
• 깨지면 어디서 멈출 것인가: 계속 고치지 말고 되돌릴 조건을 먼저 적는다.

이 세 줄을 붙이면 프리뷰 링크가 갑자기 작아진다. “전체 앱을 봐 주세요”가 아니라 “이 링크에서 저장 버튼 뒤 성공 상태만 봐 주세요”가 된다. 나는 이 축소가 중요하다고 본다. 바이브코딩에서 속도가 나는 이유는 큰 목표를 빨리 던지기 때문이지만, 품질이 남는 이유는 마지막 확인 대상을 작게 자르기 때문이다.

2. 화면 검증과 코드 검증은 같은 사람이 안 해도 된다

웹 AI 빌더의 장점은 화면을 빠르게 볼 수 있다는 것이고, 약점도 똑같다. 화면이 빨리 나오니 코드가 어떤 모양으로 생겼는지는 뒤로 밀린다. 특히 모바일에서 시작한 작업은 더 그렇다. 이동 중에는 프리뷰가 열리는지, 대략 의도한 화면인지 정도만 보게 되고, 실제 diff나 테스트는 데스크톱으로 돌아와야 잡힌다. 그래서 나는 프리뷰 슬롯을 모바일 확인과 데스크톱 확인 사이의 얇은 계약으로 쓴다.

모바일에서는 첫 화면, 핵심 클릭 경로, 입력 폼의 체감 정도만 본다. 대신 데스크톱에서는 생성된 파일 수, 상태 관리 위치, 라우팅 변경, 테스트 가능성을 본다. 둘을 한 번에 처리하려고 하면 모바일에서는 너무 무겁고, 데스크톱에서는 이미 첫인상에 끌려간다. 프리뷰 슬롯을 따로 두면 “링크가 그럴듯하다”와 “merge해도 된다”를 분리할 수 있다.

3. 프리뷰 카드에 남기는 정보는 많을 필요가 없다

내가 쓰는 프리뷰 카드는 길지 않다. 길어지면 또 하나의 문서 작업이 되고, 짧으면 링크만 던지는 버릇으로 돌아간다. 적당한 크기는 다섯 줄 안팎이었다.

• Preview URL: 공유할 링크 하나만 남긴다.
• 생성 프롬프트: 마지막으로 넣은 요청을 한 문장으로 줄인다.
• 기대 동작: 반드시 통과해야 하는 사용자 경로 1개를 적는다.
• 미확인 영역: 아직 안 본 화면이나 브라우저 조건을 숨기지 않는다.
• 되돌림 기준: 이 조건을 넘으면 추가 수정 대신 롤백한다.

여기서 제일 자주 빠지는 건 미확인 영역이다. 에이전트가 만든 결과를 사람에게 보여 줄 때는 이상하게 “거의 됐다”는 말이 먼저 나온다. 그런데 실제로는 Safari를 안 봤거나, 빈 데이터 상태를 안 봤거나, 로그인 뒤 화면을 안 본 경우가 많다. 미확인 영역을 적어 두면 프리뷰는 덜 멋있어 보이지만, 다음 사람이 이어받기는 훨씬 쉬워진다.

4. 에이전트에게도 프리뷰 슬롯을 다시 먹인다

프리뷰 슬롯은 사람 사이의 메모로 끝나지 않는다. 다음 에이전트 턴에 그대로 넣기 좋다. 나는 “이 프리뷰에서 아래 클릭 경로만 검증하고, 미확인 영역은 새 작업으로 벌리지 말고, 실패하면 되돌림 기준에 따라 멈춰라”처럼 다시 넘긴다. 이렇게 하면 에이전트가 링크를 보고 마음대로 새 리팩터링을 시작하는 일을 줄일 수 있다.

특히 웹 빌더에서 흔한 실패는 검증 중에 새 기능을 더 붙이는 것이다. 버튼 하나가 안 눌리는 걸 고치다가 컴포넌트 구조를 다시 짜고, 라우팅 하나를 보다가 디자인 시스템까지 건드린다. 프리뷰 슬롯에 되돌림 기준을 같이 넣으면 이런 확장을 막는 데 도움이 된다. “수정”이 아니라 “검증”이라는 작업 이름을 유지하는 셈이다.

이때 에이전트에게 다시 넘기는 말도 짧게 유지한다. “새 화면을 만들지 말고, 이 프리뷰에서 실패한 클릭 경로만 고쳐라. 파일이 세 개를 넘으면 멈추고 이유를 보고하라. 통과 증거는 스크린샷이나 테스트 결과 중 하나로 남겨라.” 이 정도면 충분하다. 문장이 길어질수록 에이전트는 다시 설계 작업으로 착각한다. 프리뷰 슬롯은 다음 큰 프롬프트가 아니라, 이미 만든 것을 작게 잠그는 장치에 가깝다.

5. 내가 실제로 보는 종료 조건

프리뷰 슬롯의 종료 조건은 거창하지 않다. 첫째, 링크가 열리고 핵심 클릭 경로가 한 번 통과해야 한다. 둘째, 생성 코드의 변경 범위가 설명 가능한 수준이어야 한다. 셋째, 미확인 영역이 다음 작업으로 분리되어야 한다. 이 셋 중 하나라도 애매하면 나는 merge보다 보류에 둔다. 빠른 빌더일수록 보류 칸이 있어야 한다. 보류 없이 계속 고치면 결국 “처음엔 빨랐는데 마지막엔 더 오래 걸린” 작업이 된다.

프리뷰 링크 하나만으로도 팀의 판단이 꽤 빨리 움직인다. 그래서 더더욱 링크를 결과물처럼 다루지 않으려고 한다. 링크는 잠깐 열린 창이고, 검증 슬롯은 그 창에서 무엇을 봤는지 남기는 기록이다. 나는 모바일이나 웹 AI 빌더를 쓸수록 이 차이를 더 자주 의식하게 됐다. 화면을 빨리 얻는 건 좋다. 다만 그 화면을 어디까지 믿을지 정하는 작은 칸이 옆에 있어야, 다음 수정도 덜 시끄럽게 이어진다.

결국 프리뷰 슬롯의 목적은 속도를 늦추는 게 아니다. 속도 때문에 사라지는 증거를 붙잡는 쪽에 가깝다. 링크, 클릭 경로, 미확인 영역, 되돌림 기준이 한 묶음으로 남아 있으면 다음 사람도 같은 화면을 같은 질문으로 볼 수 있다. 그 정도만 되어도 AI 빌더의 초안은 훨씬 다루기 쉬운 재료가 된다. 작은 기록 하나가 다음 수정의 소음을 줄이고, 검증 책임도 흐리지 않는다.