Lovable와 Supabase로 16개의 제품을 운영하며 겪은 기술적 실수들
Inithouse에서는 16개의 제품을 운영하고 있습니다. 모든 제품에 Lovable과 Supabase를 사용하며, 한 팀이 모든 것을 관리합니다. 언뜻 듣기에는 좋아 보이지만, 16개의 커스텀 도메인, 16개의 Supabase 프로젝트, 그리고 16세트의 edge functions를 마주하게 되면 이야기가 달라집니다.
저희는 시간을 허비하게 만든 실수들을 저질렀습니다. 가장 컸던 다섯 가지 기술적 실수와 그 해결책을 소개합니다.
- 일관성 없는 데이터베이스 스키마
초기 세 제품은 동일한 데이터에 대해 서로 다른 테이블 이름을 사용했습니다. 어떤 프로젝트는 분석을 위해 page_views를 사용했고, 다른 프로젝트는 analytics_events를 사용했습니다. 이로 인해 코드를 공유하는 것이 불가능해졌습니다. 오후 한나절이면 끝날 작업이 2주나 걸리기도 했습니다.
해결책: 공유 마이그레이션 템플릿을 구축했습니다. 모든 신규 제품은 분석, 블로그 포스트, 인증(auth)을 위한 동일한 기본 테이블을 갖게 됩니다. 여유로운 주간을 이용해 기존 프로젝트들도 소급 적용했습니다. 이제 모니터링 엔드포인트를 추가하는 데 하루가 아닌 20분이면 충분합니다.
- 깨진 커스텀 도메인
Lovable을 사용하면 커스텀 도메인을 연결할 수 있습니다. 때때로 배포는 성공하지만 DNS 검증이 실패하는 경우가 있습니다. 프리뷰 URL은 작동하지만, 라이브 도메인은 빈 페이지를 보여줍니다. 라이브 URL을 확인하지 않아 3일 동안 트래픽을 놓친 적도 있습니다.
해결책: 게시 후 체크리스트를 사용합니다. 모든 라이브 도메인을 시크릿 창(incognito window)에서 열어 확인합니다. 또한 도메인 연결에 실패할 경우 Slack으로 알림을 보내는 업타임(uptime) 체크 기능을 추가했습니다.
- 파편화된 데이터 가시성
제품마다 별도의 대시보드를 열지 않고서는 전체 포트폴리오의 성과를 파악할 수 없었습니다. 마치 눈을 가리고 비행하는 것과 같았습니다.
해결책: 모든 Supabase 프로젝트에 통계 API 엔드포인트를 배포했습니다. 각 제품은 사용자 수, 가입자 수와 같은 주요 지표를 표준화된 형식으로 전송합니다. 단 하나의 스크립트가 이 데이터를 수집하여 하나의 대시보드에 보여줍니다.
- 컴포넌트 복사 붙여넣기
예전에는 한 프로젝트의 React 컴포넌트를 다른 프로젝트로 복사해서 사용하곤 했습니다. 하지만 이 컴포넌트들은 과거의 가정을 그대로 품고 있었습니다. 예를 들어, 한 제품의 가격 카드(pricing card)가 다른 제품에서 결제 흐름이 달라 작동하지 않는 식이었죠. 이런 유령 버그(phantom bugs)를 디버깅하느라 며칠을 허비했습니다.
해결책: 복사 붙여넣기를 중단했습니다. 대신 컴포넌트 패턴 문서를 유지 관리합니다. Lovable에게 이 패턴을 기반으로 새로운 컴포넌트를 만들도록 요청합니다. 설정하는 데 시간은 더 걸리지만 유지 관리는 훨씬 쉬워졌습니다.
- 채팅 기록을 문서로 사용하기
기술적 의사결정을 기억하기 위해 Lovable의 채팅 기록에 의존했습니다. 하지만 채팅 로그는 매우 지저분합니다. 성공적인 변경 사항과 실패한 시도가 뒤섞여 있기 때문입니다. 긴 스레드 속에서 특정 변경의 이유를 찾아내는 것은 매우 어렵습니다.
해결책: 의사결정 기록을 Linear로 옮겼습니다. Linear에 무엇이 왜 바뀌었는지 한 줄로 기록합니다. Lovable 채팅은 실행을 위한 것이고, Linear는 의사결정을 위한 것입니다.
교훈은 간단합니다. 16개의 제품을 16개의 개별 프로젝트로 취급하지 마세요. 하나의 포트폴리오로 취급하세요. 템플릿을 표준화하고 모든 것을 한 곳에서 모니터링하세요.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi