저는 Lovable을 사용하여 단 한 번의 주말 동안 역할 기반 그룹 여행 플래너인 TripNest(소유자/편집자/조회 권한, 일정 계획, 준비물 목록, 그룹 메시징 포함)를 구축했습니다. 일요일 밤에는 출시할 준비가 된 것처럼 보였습니다. 하지만 실제 사용자에게 배포하기 전, 무료 보안 스캔을 통해 8가지의 치명적인 문제를 발견했습니다.

🔗 직접 체험하기:

문제점

저는 가족 및 친구들과 함께 짧은 여행(주로 공휴일 로드트립)을 자주 다니는데, 이를 조직하는 과정은 항상 엉망이었습니다:

• 파편화된 정보 — 일정은 누군가의 메모 앱에 있고, 항공권 정보는 200개의 메시지가 쌓인 그룹 채팅방에 묻힌 스크린샷으로 공유되며, 단일 진실 공급원(Single source of truth)이 없습니다.
• 안전한 제어 공유 방식의 부재 — 계획을 세운 사람이 다른 사람에게 계획을 보여주려 해도, 누군가 실수로 호텔 예약을 삭제하거나 날짜를 변경할 위험 없이 권한을 부여할 방법이 없습니다.
• 소음 속에 묻히는 여행 채팅 — 여행 관련 결정 사항들이 관련 없는 그룹 채팅 메시지 속에 파묻혀 버립니다.

TripNest는 하나의 공간과 적절한 권한 모델(Permission model)을 통해 이 문제를 해결합니다.

작동 방식: 3가지 역할
관리자(Admins) — 단일 진실 공급원. 참가자 및 플래너를 추가하거나 제거합니다.
플래너(Planners) — 관리자 수준의 제어 권한 없이 일정을 구성할 수 있습니다 (전체 여행이 아닌 활동을 담당하는 친구에게 적합합니다).
참가자(Participants) — 위험 부담 없는 가시성. 일정을 따라가되, 날짜를 변경하거나 항공편을 삭제할 수 있는 권한은 없습니다.

핵심 기능: 여행 생성, 역할 기반 초대(가입 전 승인 방식), 협업 가능한 일자별 일정, 항공 정보 저장, 준비물 목록, 그리고 여행당 전용 그룹 메시지 스레드.

기술 스택 (Tech Stack)
Lovable (초기 구축 + 반복 개선)
React + TypeScript
Tailwind CSS
Supabase (Auth + PostgreSQL)
Google Maps + OpenWeather (위치/날씨 데이터)
Perfai Security (무료 액세스 제어 테스트)
구축하기

저는 제품, 사용자, 페이지, 시각적 방향, 워크플로우 및 기술적 요구 사항을 모두 포함하는 하나의 길고 상세한 프롬프트로 시작했습니다. Lovable이 화면별로 추측하며 만드는 대신, 연결된 첫 번째 버전을 구축할 수 있도록 세부 사항을 앞부분에 집중 배치했습니다. 첫 번째 패스(pass)에서 디자인 시스템(일관된 타이포그래피, 간격, 카드, 버튼, 양식)은 완벽하게 구현되었지만, 완성된 제품은 아니었습니다. 저는 남은 주말 동안 컴포넌트(components)를 서로 연결하고, 예외 케이스(edge cases)를 수정하며, 떠오르는 기능들을 추가하는 반복 작업(iteration)에 시간을 보냈습니다.

도전 과제
제한된 Lovable 크레딧 — 모든 프롬프트는 채팅 예산에서 차감되므로, 모호한 프롬프트는 비용이 많이 들었습니다. 따라서 관련 변경 사항을 일괄 처리해야 했고, 메시지를 보내기 전에 제가 정확히 무엇을 원하는지 미리 깊이 생각해야 했습니다.
기능 전반에 걸친 역할 로직(Role logic) — 소유자(Owner)/편집자(Editor)/뷰어(Viewer) 권한이 여행, 일정, 준비물 목록 및 메시징 전반에 걸쳐 일관되게 유지되도록 만드는 작업은 그 어떤 단일 기능보다 훨씬 더 많은 반복 작업이 필요했습니다.
비사용자와의 공유 — 초기에는 TripNest 계정이 없는 사람을 초대하는 기능이 실패했습니다. 이메일 초대는 커스텀 도메인(비용 발생)이 필요했기 때문에, 대신 복사 가능한 링크 공유 기능을 구현했습니다.
"게시됨(Published)" ≠ "출시 준비 완료(Ready to Release)"

일요일이 되었을 때, TripNest는 계정, 역할별 대시보드, 지속성 데이터(persisted data), 그리고 Lovable에서 제공하는 라이브 게시 URL을 갖춘 완전히 기능적인 프로토타입(prototype)이 되었습니다. 겉보기에는 완성된 것처럼 보였습니다.

하지만 게시를 했다는 것은 앱이 실행된다는 것만을 증명할 뿐입니다. 그것은 권한 부여 모델(authorization model)이 직접적인 요청(direct requests) 하에서도 견고한지, 민감한 데이터에 의도된 UI 외부에서 접근할 수 없는지, 또는 인증(auth) 엔드포인트(endpoints)가 남용을 방어할 수 있는지를 증명하지는 않습니다.

그래서 출시 준비가 되었다고 판단하기 전에, 저는 라이브 배포 버전을 Perfai Security를 통해 실행했습니다. 이는 코드 리뷰가 아니라, 배포된 앱을 대상으로 접근 가능한 경로(routes), 역할, 요청을 매핑한 다음 약점을 조사하는 실제 테스트였습니다.

결과: 8개의 치명적인 문제 발견. 이 중 어느 것도 앱을 정상적으로 사용하는 동안에는 보이지 않았습니다. UI는 세련되어 보였고, 대시보드는 적절히 분리되어 있었으며, 인증과 일반적인 흐름은 모두 잘 작동했습니다. 이 문제들을 수정한 후, 두 번째 스캔에서는 아무런 문제가 발견되지 않았습니다.

핵심 요약 (Takeaway)
Lovable은 주말 만에 상세한 사양을 작동하는 앱으로 만들어냈으며, 이는 진심으로 인상적이었습니다. 하지만 "분위기에 맞춰 코딩하고(vibe-coded) 배포하는 것"이 "실제 사용자 데이터를 맡겨도 안전한 것"과 같지는 않습니다. 보안 점검은 제품을 구축하는 과정을 대체할 수 없으며, 계정, 권한 및 개인 기록을 다루게 된다면 이는 선택 사항이 아닙니다. 모바일 반응형(mobile responsiveness)이나 환경 설정(environment configs)을 확인하는 것과 마찬가지로, 출시 체크리스트의 필수적인 일부입니다.

이것이 제가 TripNest를 구축하는 데 사용한 프롬프트입니다:

TripNest – 협업형 여행 플래너

사용자가 여행을 생성하고, 친구들과 협업하며, 일정(itinerary)을 짜고, 여행 문서를 업로드하며, 여행 추천을 받을 수 있는 TripNest라는 이름의 현대적인 풀스택(full-stack) 여행 계획 웹 앱을 구축하세요.

이 앱은 프로덕션 환경에 즉시 사용 가능해야 하며(production-ready), 보안 모범 사례(security best practices)를 따라야 합니다.

기술 스택 (Tech Stack)
React + TypeScript
Tailwind CSS
Supabase (인증(Auth) + PostgreSQL)
반응형 UI (Responsive UI)

API
Google Maps API – 목적지 검색, 지도, 명소
OpenWeather API – 일기 예보
Amadeus API – 항공 및 호텔 검색

인증 (Authentication)
다음 기능을 포함한 안전한 이메일/비밀번호 인증을 구현하세요:

• 회원가입 (Sign up)
• 로그인 (Login)
• 비밀번호 찾기 (Forgot password)
• 로그아웃 (Logout)

사용자 역할 (User Roles)

여행자 (Traveler)

• 자신의 여행 생성, 수정 및 삭제
• 협업자 초대
• 여행 문서 업로드

중재자 (Moderator)

• 공개 여행 및 댓글 중재
• 초대받지 않은 경우 비공개 여행에 접근할 수 없음

관리자 (Admin)

• 사용자 관리
• 분석 데이터(analytics) 조회
• 관리자 대시보드 접근
• 관리자 전용 보호된 경로 (Protected admin-only routes)

데이터베이스 (Database)
다음 항목을 위한 관계형 테이블(relational tables)을 생성하세요:

• 사용자 (Users)
• 여행 (Trips)
• 여행 멤버 (Trip Members: 소유자, 편집자, 조회자)
• 일정 항목 (Itinerary Items)
• 저장된 장소 (Saved Places)
• 댓글 (Comments)
• 알림 (Notifications)
• 업로드된 파일 (Uploaded Files)

기능 (Features)

• 대시보드 (Dashboard)
• 여행 CRUD (생성, 조회, 수정, 삭제)
• 공유된 일정 (Shared itineraries)
• 권한을 가진 협업자 초대
• 검색 및 필터링
• 지도 (Maps)
• 날씨 (Weather)
• 항공권 검색
• 알림 (Notifications)
• 파일 업로드 (PDF/이미지)
• 공개 및 비공개 여행

권한 (Permissions)

• 소유자(Owners)는 협업자와 여행을 관리할 수 있습니다.
• 편집자(Editors)는 일정을 수정하고, 파일을 업로드하며, 댓글을 달 수 있습니다.

조회자(Viewers)는 조회와 댓글 작성만 가능합니다.

사용자는 본인의 데이터 또는 초대받은 여행 정보에만 접근할 수 있어야 합니다.

API 엔드포인트 (API Endpoints)

다음 엔드포인트들을 포함합니다:

/users
/trips
/itinerary
/comments
/files
/notifications
/search
/weather
/flights
/admin

모든 엔드포인트는 적절한 권한 부여 (Authorization)를 강제해야 합니다.

보안 요구 사항 (Security Requirements)

프론트엔드(Frontend)와 백엔드(Backend) 모두에서 권한 부여를 구현합니다.

적절한 경우 Supabase의 행 레벨 보안 (Row Level Security, RLS)을 사용합니다.

다음 사항을 방지해야 합니다:

• 타 사용자의 여행 정보에 대한 무단 접근
• 무단 수정 또는 삭제
• IDOR (Insecure Direct Object References, 부적절한 직접 객체 참조)
• 무단 파일 다운로드
• 무단 API 접근
• 수평적 및 수직적 권한 상승 (Horizontal and vertical privilege escalation)
• 관리자 (Admin) 역할 없이 관리자 페이지에 접근하는 행위

목표: 다수의 사용자, 공유 리소스, 역할 기반 권한 (Role-based permissions), CRUD 작업, 외부 API 연동 및 보안 권한 부여를 갖춘 현실적인 협업형 SaaS 애플리케이션을 구축합니다.