Inithouse에서는 16개의 제품을 운영하고 있습니다. 모두 Lovable을 사용하며, 모두 Supabase를 백엔드로 사용합니다. 단 하나의 팀이 이 모든 것을 관리합니다. 이 숫자는 인상적으로 들릴 수 있지만, 이는 곧 16개의 커스텀 도메인(custom domains), 16개의 Supabase 프로젝트, 16세트의 엣지 함수(edge functions), 그리고 똑같은 실수를 반복할 16번의 기회를 의미하기도 합니다.

다음은 우리에게 가장 많은 시간을 소모하게 했던 다섯 가지 기술적 실수와 이를 어떻게 해결했는지에 대한 내용입니다.

실수 1: 모든 Supabase 스키마(schema)가 제각각이었다 (snowflake)

우리의 초기 세 제품은 동일한 기능에 대해 완전히 다른 테이블 이름을 사용했습니다. 한 프로젝트의 사용자 분석(User analytics) 데이터는 page_views에 저장되어 있었고, 다른 프로젝트에서는 analytics_events에, 세 번째 프로젝트에서는 user_activity를 사용했습니다. 인증(Auth) 테이블의 컬럼 이름도 달랐고, 블로그 테이블도 제각각이었습니다.

공통 통계 엔드포인트(stats endpoint)를 작성하려고 했을 때, 우리는 모든 프로젝트에 대해 맞춤형 쿼리(custom queries)를 작성해야 했습니다. 단 하루 오후면 끝날 작업이 2주나 걸렸습니다.

해결책: 우리는 공유 마이그레이션 템플릿(shared migration template)을 구축했습니다. 모든 신규 제품은 동일한 기본 테이블을 갖게 됩니다: analytics (페이지 뷰, 이벤트, 리퍼러(referrers)를 위한 표준화된 컬럼 포함), blog_posts (title, slug, content, published_at), 그리고 일관된 인증(auth) 설정입니다. 기존 프로젝트들은 업무가 적은 주간에 하나씩 소급 적용했습니다.

이제 Pet Imagination이나 Watching Agents 같은 서비스에 모니터링 엔드포인트를 추가하는 데는 하루가 아닌 20분밖에 걸리지 않습니다.

실수 2: Lovable이 게시(publish)한 후 커스텀 도메인이 깨짐 (그리고 아무도 알아차리지 못함)

Lovable은 커스텀 도메인(custom domain)을 연결할 수 있게 해줍니다. 아주 잘 작동하죠. 하지만 'Publish'를 누르고 배포 파이프라인(deploy pipeline)이 DNS 검증을 조용히 깨뜨리는 동작을 수행하기 전까지는 말입니다. Lovable 프리뷰 URL은 잘 작동하고, 배포도 성공하며, 초록색 체크 표시가 뜹니다. 하지만 실제 도메인은 인증서 오류를 표시하거나 빈 페이지를 보여줍니다.

누군가 라이브 URL을 확인하기 전까지, 한 제품에서 3일 동안의 트래픽을 손실했습니다. 프리뷰는 멀쩡했지만, 커스텀 도메인은 죽어 있었습니다.

해결책: 게시 후 체크리스트입니다. Lovable을 게시할 때마다, 우리는 시크릿 창(incognito window)에서 라이브 커스텀 도메인을 열어 정상적으로 로드되는지 확인합니다. 또한 간단한 업타임 체크(uptime check, 크론 잡(cron job)을 통해 5분마다 도메인에 curl 요청을 보냄)를 추가하여, 200 상태 코드가 아닌 다른 응답을 받으면 Slack으로 알림을 보내도록 했습니다.

기본적인 것처럼 들릴 수도 있습니다. 실제로 기본적입니다. 하지만 도메인이 16개나 되면, "그냥 확인하면 되지"라는 생각은 매우 빠르게 "확인하는 것을 잊어버렸다"로 변합니다.

실수 3: 중앙 집중식 모니터링의 부재

몇 달 동안, Be Recommended가 Voice Tables와 비교해 어떻게 운영되고 있는지 알고 싶다면, 누군가는 두 개의 별도 Supabase 대시보드와 두 개의 GA4 속성을 열고 수치를 머릿속으로 합쳐야 했습니다.

정기적으로 그렇게 하는 사람은 아무도 없었습니다. 우리는 포트폴리오 전체를 눈을 가린 채 운영하고 있었습니다.

해결책: 모든 Supabase 프로젝트에 배포된 통계 API 엔드포인트(stats API endpoint)입니다. 각 제품은 표준화된 JSON 형식으로 주요 지표(총 사용자 수, 이번 주 가입자 수, 페이지 뷰, 주요 유입 경로)를 반환하는 /functions/v1/stats 엣지 함수(edge function)를 노출합니다. 어그리게이터 스크립트(aggregator script)가 16개의 모든 엔드포인트에서 데이터를 가져와 단일 대시보드에 결과물을 쏟아붓습니다.

총 투입된 리소스는 하나의 엣지 함수 템플릿(실수 1에서 얻은 스키마 표준화 덕분에 재사용 가능)과 50줄짜리 어그리게이터뿐이었습니다. 첫날에 했어야 했습니다.

실수 4: 적응 과정 없이 컴포넌트를 복사하여 붙여넣기

Lovable은 React 컴포넌트를 생성합니다. 한 프로젝트에서 잘 작동하는 카드 컴포넌트가 있으면, 다음 프로젝트로 복사하고 싶은 유혹은 당연합니다. 우리는 이를 끊임없이 반복했습니다.

문제는 복사된 컴포넌트에는 전제 조건(assumptions)이 포함되어 있다는 점입니다. Magical Song의 가격 카드(pricing card)는 일회성 결제 흐름을 전제로 했습니다. 우리는 이를 구독형 제품에 붙여넣었고, 왜 Stripe 웹훅(webhooks)이 실패하는지 디버깅하는 데 이틀을 허비했습니다. 해당 컴포넌트가 새 프로젝트에는 존재하지 않는 일회성 체크아웃 엔드포인트를 호출하고 있었기 때문입니다.

또한 제품마다 동일한 컴포넌트의 버전이 조금씩 달라지는 결과가 발생했습니다. 한 프로젝트에서의 버그 수정이 다른 프로젝트로 전파되지 않았던 것입니다.

해결책: 우리는 원시 컴포넌트 (raw components)를 복사해서 붙여넣는 것을 중단했습니다. 대신, 컴포넌트 패턴에 대한 참조 문서 (reference doc)를 유지합니다. 새로운 프로젝트에 가격 카드 (pricing card)가 필요할 때, 우리는 패턴 문서를 구조적 참고 자료로 활용하여 Lovable에 요구 사항을 처음부터 설명합니다. 그러면 AI가 새로운 프로젝트의 스택 (stack)에 맞는 신선한 컴포넌트를 생성합니다.

설정은 더 느려졌지만, 유지보수는 더 빨라졌습니다. 오래된 가설으로 인한 유령 버그 (phantom bugs)도 사라졌습니다.

실수 5: Lovable의 AI 채팅을 문서로 취급하기

Lovable은 각 프로젝트의 전체 채팅 기록을 저장합니다. 모든 결정, 모든 프롬프트 (prompt), 모든 "버튼 색상을 바꿔줘"와 같은 요청이 그곳에 남아 있습니다. 우리는 이것을 우리의 문서로 취급했습니다: "모든 것이 Lovable 채팅에 있으니까."

문제는 6주 후에 특정 결정이 왜 내려졌는지 알아야 할 때 발생합니다. Lovable 채팅은 시간 순서대로 나열되어 있으며, 실패한 시도, 되돌려진 변경 사항, 그리고 지엽적인 실험들이 뒤섞여 있습니다. 200개의 메시지가 담긴 채팅 스레드에서 "이 제품에서 왜 Stripe에서 LemonSqueezy로 전환했는가"를 찾는 것은 매우 고통스러운 일입니다.

해결책: 우리는 결정 기록 (decision logging)을 Linear로 옮겼습니다. 모든 의미 있는 기술적 결정은 관련 이슈 (issue)에 한 줄의 코멘트로 남겨집니다: 무엇이 바뀌었는지, 왜 바뀌었는지, 그리고 무엇을 대체했는지 말입니다. Lovable 채팅은 실행 로그 (execution log)로 남겨두고, Linear가 결정 로그 (decision log)를 보유합니다.

Linear에서 "LemonSqueezy"를 검색하는 데는 2초가 걸립니다. 16개 프로젝트 전체의 Lovable 채팅에서 검색하는 데는 오후 내내 걸립니다.

다섯 가지 실수 뒤에 숨겨진 패턴

모든 실수는 동일한 문제의 변형입니다: 16개의 제품을 하나의 포트폴리오가 아닌 16개의 개별 프로젝트처럼 취급한 것입니다. 조기에 표준화하고, 중앙에서 모니터링하며, 제품을 만드는 도구 외부에서 문서화하십시오.

여러 개의 Lovable 프로젝트(또는 어떤 AI 빌더든 여러 프로젝트)를 운영하고 있다면, 세 번째 제품을 만들기 전에 템플릿과 모니터링부터 시작하십시오. 우리는 여덟 번째 제품이 되어서야 시작했습니다. 저희와 같은 실수를 하지 마세요.

16개의 제품 모두 inithouse.com에서 라이브로 운영되고 있습니다.