Lovable와 Supabase로 16개의 제품을 운영하며 겪은 기술적 실수들

Inithouse에서는 16개의 제품을 운영하고 있습니다. 모든 제품에 Lovable과 Supabase를 사용하며, 하나의 팀이 모든 것을 관리합니다.

16개의 제품을 관리한다는 것은 16개의 커스텀 도메인, 16개의 Supabase 프로젝트, 그리고 16세트의 edge functions를 관리한다는 의미입니다. 이러한 규모는 반복적인 실수를 초래합니다.

저희가 저지른 다섯 가지 기술적 실수와 이를 어떻게 해결했는지 소개합니다.

1. 일관성 없는 데이터베이스 스키마

초기 세 제품은 동일한 데이터에 대해 서로 다른 이름을 사용했습니다. 어떤 프로젝트는 분석을 위해 page_views를 사용했고, 다른 프로젝트는 analytics_events를 사용했습니다.

프로젝트마다 맞춤형 쿼리를 작성해야 했기 때문에, 공용 도구를 만드는 데 반나절이면 될 일이 2주나 걸렸습니다.

해결책: 공용 마이그레이션 템플릿을 구축했습니다. 이제 모든 신규 제품은 분석, 블로그 포스트, 인증(auth)을 위해 동일한 기본 테이블을 사용합니다.

2. 소리 없는 도메인 장애

Lovable에서는 커스텀 도메인을 연결할 수 있습니다. 때때로 배포는 성공하지만 DNS 검증이 실패하는 경우가 있습니다. 프리뷰 URL은 작동하지만, 라이브 도메인은 빈 페이지로 나타납니다.

한 제품에서는 문제를 인지하기 전까지 3일 동안 트래픽을 놓치기도 했습니다.

해결책: 배포 후 체크리스트를 사용합니다. 라이브 도메인을 시크릿 창에서 열어 확인합니다. 또한 cron job을 사용하여 5분마다 도메인에 핑(ping)을 보냅니다.

3. 파편화된 데이터 가시성

제품의 성과를 확인하려면 별도의 Supabase 대시보드와 GA4 속성을 일일이 열어야 했습니다. 마치 눈을 가리고 비행하는 것과 같았습니다.

해결책: 모든 Supabase 프로젝트에 통계 API 엔드포인트를 배포했습니다. 각 제품은 edge function을 사용하여 주요 지표를 하나의 형식으로 반환합니다. 간단한 스크립트를 통해 16개 엔드포인트의 데이터를 하나의 대시보드로 가져옵니다.

4. 컴포넌트 복사 및 붙여넣기

이전에는 React 컴포넌트를 한 프로젝트에서 다른 프로젝트로 복사해서 사용했습니다. 이는 버그를 유발했습니다. 예를 들어, 한 프로젝트의 가격 카드(pricing card)는 일회성 결제를 전제로 설계되었습니다. 이를 구독형 프로젝트에 붙여넣었을 때 Stripe 결제 흐름이 깨져버렸습니다.

해결책: 코드 복사 및 붙여넣기를 중단했습니다. 대신 컴포넌트 패턴 문서를 유지 관리합니다. Lovable에 해당 패턴을 기반으로 새로운 컴포넌트를 만들도록 요청합니다. 이를 통해 과거의 가정이 불러오는 버그를 방지합니다.

5. 채팅을 문서로 사용하기

Lovable의 채팅 기록을 문서처럼 사용했습니다. 하지만 긴 채팅 스레드에서 특정 기술적 결정을 찾는 것은 어렵고 느립니다.

해결책: 의사결정 기록을 Linear로 옮겼습니다. 모든 주요 기술적 변경 사항은 Linear에 무엇이 왜 바뀌었는지 설명하는 댓글로 남깁니다. Lovable 채팅은 실행을 위해, Linear는 의사결정을 위해 사용합니다.

교훈: 16개의 제품을 16개의 개별 프로젝트로 취급하지 마세요. 하나의 포트폴리오로 취급하세요. 템플릿을 표준화하고 모든 것을 중앙에서 모니터링하세요.

Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh