레이크와 웨어하우스 논쟁은 도구 취향으로 흐르기 쉽습니다. 스타트업 규모에서는 “지금 답이 필요한 질문이 무엇인가”가 더 중요합니다. 매출·전환·코호트처럼 정해진 BI 질문이 중심이면 웨어하우스가 단순합니다. 스키마가 비교적 안정적이고, SQL로 바로 리포트를 뽑을 수 있기 때문입니다.
데이터 레이크는 원본 로그, 클릭스트림, 이미지·문서, 반정형 JSON처럼 나중에 용도가 정해질 데이터를 싸게 오래 쌓을 때 유리합니다. 다만 “쌓아 두면 언젠가 쓴다”만으로는 비용과 거버넌스 부채가 커집니다. 레이크에 넣을 때도 최소 파티션·보관 기간·접근 권한은 정해야 합니다.
현실적인 시작은 둘을 동시에 짓지 않는 것입니다. 이번 분기에 필요한 리포트 3개를 고르고, 그 리포트의 원천 이벤트만 파이프라인으로 고정하세요. 주문, 결제, 가입, 주요 CTA 클릭 정도면 대부분 초기 의사결정에 충분합니다.
품질 규칙도 초기에 넣습니다. 중복 이벤트, 시간대, null 키, 늦게 도착하는 로그를 어떻게 처리할지 합의하지 않으면 대시보드 숫자가 매일 달라집니다. “어제의 매출이 오늘 바뀌는” 현상의 절반은 파이프라인 약속 부재입니다.
인력 관점에서는 SQL에 익숙한 분석가가 있으면 웨어하우스 중심이 생산적입니다. 데이터 엔지니어가 없고 원본 덤프만 늘리면 레이크는 파일 창고가 됩니다. 도구보다 “누가 매주 숫자를 책임지는가”를 먼저 정하세요.
요약: BI 중심·질문 고정 → 웨어하우스. 원본·비정형 장기 보관이 핵심 → 레이크(또는 레이크하우스) 검토. 어느 쪽이든 리포트 3개·품질 규칙·담당자부터. 둘 다 완벽히 갖추는 것은 성장 이후의 과제입니다.
