대부분의 스타트업 BI 프로젝트는 너무 일찍, 너무 크게 시작합니다.
창업자는 간단한 질문을 던집니다. "이 채널로 들어온 사용자들이 첫 실행 이후에 다시 돌아오고 있나요?" 답은 쿼리 하나면 됩니다. 그런데 현실에서는 종종 플랫폼 프로젝트로 번집니다. 모든 소스를 연결하고, 웨어하우스를 구축하고, 이벤트를 정의하고, 신원을 정리하고, 대시보드를 연결한 뒤 기다리는 식이죠.
그 작업이 언젠가 중요해지는 건 맞습니다. 하지만 작은 팀에게는 첫 수순으로 잘못된 선택일 수 있습니다. 제품 데이터베이스는 이미 창업자가 알아야 할 것의 대부분을 알고 있습니다. 누가 가입했는지, 누가 무언가를 실행했는지, 무엇을 사용했는지, 비용이 얼마나 들었는지, 무엇이 실패했는지, 그리고 다시 돌아왔는지를 알고 있죠.
진짜 문제는 진실이 어디에 있느냐가 아닙니다. 원본 프로덕션 데이터베이스를 노출하지 않으면서 에이전트가 그 진실을 분석하도록 어떻게 허용하느냐입니다.
이것이 바로 VM0에서 우리가 사용하는 패턴입니다. 마스킹된 읽기 전용 Neon 브랜치를 만들어, 에이전트가 절대 봐서는 안 될 데이터는 주지 않으면서 BI를 돌리기에 충분한 진실은 제공하는 것이죠.
창업자의 문제: 데이터 팀이 생기기 전에 질문이 먼저 도착한다
초기 단계 회사에 부족한 것은 질문이 아닙니다. 시간입니다.
매일같이 창업자 팀은 이런 것들을 알고 싶어 합니다.
- 어제의 트래픽이 실제 사용자로 전환되었나?
- 어떤 가입 채널이 실제로 무언가를 실행하는 사람들을 만들어내는가?
- 첫 실행 사용자들이 7일이나 30일 후에 다시 돌아오는가?
- 어떤 유료 계정이 조용해지고 있는가?
- 어떤 모델 라우트가 비용을 끌어올리고 있는가?
- 트라이얼 남용 사용자들이 전환하기 전에 컴퓨트를 태우고 있는가?
- 제품 건강도가 어제보다 나아졌는가, 나빠졌는가?
이 질문들 중 어느 것도 별스러운 것이 아닙니다. 스타트업의 운영 리듬 그 자체입니다.
하지만 전통적인 BI 방식으로 이 질문들에 답하려면 많은 오버헤드가 생깁니다. 보통은 제품 데이터베이스에서 데이터를 다른 시스템으로 옮기는 것부터 시작합니다. 그다음 그것을 정규화하고, 지표를 정의하고, 관계를 다시 구축하고, 대시보드를 세팅합니다. 팀은 더 깔끔한 분석 스택을 얻지만, 창업자는 SQL 쿼리 하나로 시작할 수 있었던 답을 며칠 혹은 몇 주씩 기다리는 경우가 많습니다.
작은 스타트업에게 이 거래는 본말이 전도된 것일 수 있습니다. 처음 20개의 운영 질문을 던지는 데 완전한 데이터 플랫폼이 필요한 것은 아닙니다. 필요한 것은 이미 가지고 있는 진실의 원천을 안전하게 쿼리할 방법입니다.
데이터베이스가 이미 진실의 원천이다
VM0에서 제품 데이터베이스는 많은 창업자 수준 의사결정에 중요한 사실들을 담고 있습니다.
- 조직과 사용자
- 가입 및 구독 상태
- 에이전트 실행과 스케줄
- 크레딧 소비와 사용 이벤트
- 선택된 모델과 프로바이더 라우트
- 커넥터 상태
- 실패 상태와 타임스탬프
이 관계들은 이미 그곳에 존재합니다. 하위 단계의 어떤 대시보드보다 신선하며, 제품이 실제로 어떻게 동작하는지를 반영합니다.
이것이 중요한 이유는 많은 초기 BI 질문이 관계형이기 때문입니다. 창업자는 단순히 페이지뷰나 실행 수만 원하는 게 아닙니다. 시스템 전반에 걸친 행동을 연결하고 싶어 합니다.
이 채널로 가입한 사용자 중 몇 명이 0일차에 무언가를 실행했고, 첫 실행 이후 몇 명이 돌아왔는가?
또는:
지난 7일 동안 아무것도 실행하지 않은 유료 조직은 어디이며, 그들은 이전에는 활발해 보였는가?
또는:
신규 트라이얼 계정이 가입 후 첫 6시간 동안 얼마나 많은 컴퓨트를 태웠으며, 우리가 남용 순찰을 바꾸기 전과 후는 어떻게 다른가?
이런 질문들은 제품 데이터베이스 안에 자연스럽게 자리 잡고 있습니다. 모든 답이 데이터를 별도 플랫폼으로 옮기는 데서 시작해야 한다면 훨씬 어려워집니다.
안전하지 않은 지름길은 원본 프로덕션 접근이다
솔깃한 지름길은 분명합니다. 그냥 에이전트가 프로덕션을 쿼리하게 하는 것이죠.
이것은 용납될 수 없습니다.
프로덕션 데이터베이스에는 회사에서 가장 민감한 자료가 담겨 있을 수 있습니다. 이메일 주소, 프롬프트, 채팅 내용, 자격 증명, 암호화된 프로바이더 상태, 로그, 오류 메시지, API 키, 그리고 내부 운영 기록 등이죠. 에이전트가 아무리 조심하더라도 원본 접근은 경계 문제를 만듭니다. 에이전트가 너무 많은 것을 볼 수 있습니다. 쿼리, 보고서, 또는 스크린샷의 실수 하나가 팀이 결코 노출하려 하지 않았던 정보를 새어 나가게 할 수 있습니다.
쓰기 접근은 더욱 나쁩니다. BI는 프로덕션을 변경할 수 있어서는 안 됩니다. 분석가는, 사람이든 에이전트든, 잘못된 명령 한 번에 사용자 데이터를 바꿔버릴 수 있어서는 안 됩니다.
그래서 질문은 에이전트가 SQL을 작성할 수 있느냐가 아닙니다. 작성할 수 있습니다. 질문은 프라이버시와 안전을 절대적 제약으로 유지하면서도 그들이 유용할 만큼 충분한 진실을 줄 수 있느냐입니다.
우리에게 그 제약들이 바로 핵심입니다.
- 에이전트는 원본 프롬프트를 봐서는 안 됩니다.
- 에이전트는 원본 이메일을 봐서는 안 됩니다.
- 에이전트는 자격 증명이나 비밀 정보를 봐서는 안 됩니다.
- 에이전트는 민감한 자유 텍스트 로그를 봐서는 안 됩니다.
- 에이전트는 BI 소스에 대한 쓰기 접근 권한을 가져서는 안 됩니다.
- 그래도 창업자 팀은 실용적인 운영 질문에 빠르게 답을 얻을 수 있어야 합니다.
이것이 우리에게 필요했던 시스템의 모습입니다.
안전한 중간 지대: 마스킹된 읽기 전용 데이터베이스
Neon은 브랜치가 Postgres 데이터베이스의 저렴하고 격리된 복사본이기 때문에 유용한 패턴을 가능하게 합니다. 프로덕션과 유사한 브랜치를 만들어 변환한 뒤, 프로덕션 자체가 아니라 그 브랜치를 노출할 수 있습니다.
VM0에서는 이것을 활용해 우리가 MaskDB라고 부르는 것을 만듭니다.
흐름은 단순합니다.
- 프로덕션 Neon 부모 브랜치에서 시작합니다.
- 정해진 일정에 따라 새 브랜치를 만듭니다.
- PostgreSQL Anonymizer와 VM0 전용 마스킹 헬퍼를 설치합니다.
- 민감한 컬럼에 보안 레이블을 적용합니다.
- 브랜치에 정적 익명화를 실행합니다.
- 특별한 처리가 필요한 필드에 최종 커스텀 마스크를 적용합니다.
SELECT접근 권한을 가진masked_readonly역할을 만듭니다.- 에이전트가 프로덕션이 아니라 그 역할로 쿼리하게 합니다.
중요한 점은 마스킹이 정적이라는 것입니다. 민감한 값들은 에이전트가 연결하기 전에 마스킹된 브랜치에서 다시 작성됩니다. 이것은 모든 하위 쿼리에게 무엇을 선택하지 말아야 하는지 기억하라고 요구하는 것과는 다릅니다. 브랜치 자체가 경계입니다.
우리의 MaskDB에서 자격 증명과 비밀 정보는 삭제됩니다. 이메일과 전화번호는 부분적으로 마스킹됩니다. 프롬프트, 채팅 메시지, 스케줄 프롬프트, 에이전트 출력 같은 사용자 콘텐츠는 제거됩니다. 오류 텍스트는 전체 스택이나 메시지가 아니라 클래스 수준으로 축소됩니다. 분석에 절대 나타나서는 안 되는 테이블은 통째로 삭제할 수 있습니다.
동시에 org_id, user_id, clerk_user_id 같은 불투명한 식별자는 조인 가능한 상태로 유지됩니다. 바로 이것이 BI를 가능하게 만듭니다. 에이전트가 사람의 이메일 주소나 프롬프트 텍스트를 알 필요는 없습니다. 하지만 같은 조직이 가입했고, 작업을 실행했고, 크레딧을 소비했고, 구독했고, 휴면 상태가 되었거나 나중에 돌아왔다는 사실은 알 필요가 있습니다.
그 균형이 핵심 전부입니다. 사람이 읽을 수 있고 민감한 자료는 마스킹하되, 관계형 척추는 보존하는 것이죠.
경계가 생기면 에이전트가 할 수 있는 일
마스킹된 읽기 전용 데이터베이스가 존재하면 에이전트는 아주 빠르게 유용해질 수 있습니다.
제품 데이터를 직접 대상으로 질문할 수 있습니다.
- 7일 및 30일 사용자 리텐션
- 가입에서 첫 실행까지의 활성화
- 첫 실행 기준 리텐션
- 유료 조직 휴면
- 구독 상태와 이탈 감시
- 선택된 모델별 모델 사용량
- 내장 라우트 대 사용자 프로바이더 라우트
- 트라이얼 컴퓨트 소비
- 모델별 실행당 비용
- 코호트별 실패율과 완료율
또한 그 데이터베이스의 진실을 주변 시스템과 결합할 수도 있습니다.
우리의 Morning Brief는 Plausible, Axiom, Sentry, Google Ads, GitHub, 그리고 다른 운영 소스에서 데이터를 끌어옵니다. 데이터베이스는 사용자와 조직이 무엇을 했는지 알려줍니다. Plausible은 사이트에서 무슨 일이 일어났는지 알려줍니다. PostHog는 제품 이벤트 맥락에 도움이 됩니다. Axiom은 로그와 요청 경로에서 무슨 일이 있었는지 알려줍니다. Sentry는 오류를 잡아냅니다. Stripe와 Clerk는 결제와 신원을 설명하는 데 도움이 됩니다. GitHub는 엔지니어링 처리량을 보여줍니다.
핵심은 모든 도구를 SQL로 대체하는 것이 아닙니다. 핵심은 에이전트가 창업자들이 실제로 신경 쓰는 사실들을 연결하게 하는 것입니다.
예를 들면:
어제 유료 Google이 오가닉보다 더 많은 트래픽을 보냈다. 그 사용자들이 실제로 첫 실행에 도달했는가, 아니면 퍼널 상단에서 멈췄는가?
또는:
우리는 트라이얼 남용 순찰을 바꿨다. 신규 트라이얼 계정이 첫 몇 시간 동안 더 적은 컴퓨트를 태웠는가?
또는:
이 모델 라우트는 실행당 더 저렴하다. 그것이 실제 과거 채팅 사용량에서 나타나는가, 아니면 가격 이론에서만 그러한가?
이것들은 대시보드 질문이 아닙니다. 운영 질문입니다. 매주, 때로는 매일 바뀝니다. 안전한 데이터베이스 접근 권한을 가진 에이전트는 매번 엔지니어링에게 새 뷰를 만들어달라고 요청하지 않고도 이 질문들에 답할 수 있습니다.
실제 사례: 리텐션과 외부 사용자 건강도
우리의 일일 내부 분석 중 하나는 직전 24시간에 걸친 외부 사용자 건강도를 들여다봅니다.
이 보고서는 MaskDB에서 시작한 뒤 엄격한 제외 집합을 적용합니다. 내부 VM0 조직은 제거됩니다. Clerk에서 차단되었거나 잠긴 스팸 조직도 제거됩니다. 동일한 제외 집합이 가입 수와 리텐션 코호트를 포함해 모든 곳에 적용되므로 분모를 감사 가능한 상태로 유지합니다.
거기서부터 에이전트는 간결한 운영 보고서를 만들 수 있습니다.
- 실행 수와 활성 외부 조직
- 완료율
- 웹, CLI, 스케줄, 비-Zero 라우트에 걸친 트리거 구성
- 모델 구성
- 프로바이더 모드
- 유료 조직 활동
- 휴면 유료 조직
- 신규 유료 가입과 트라이얼 중인 조직
- 이탈 감시
- 30일 사용자 세분화
- 가입에서 실행까지의 리텐션
- 첫 실행 리텐션
이것이야말로 창업자 팀에게 필요한 종류의 보고서입니다. 원본 프롬프트가 필요 없습니다. 원본 이메일이 필요 없습니다. 프로덕션 쓰기 접근 권한이 필요 없습니다.
다만 제품 사실들을 올바르게 조인할 능력은 필요합니다.
한 실행에서 에이전트는 소수의 활성 외부 조직이 대부분의 볼륨을 견인하고 있다는 것, 여러 유료 조직이 조용해졌다는 것, 그리고 최근 가입 코호트가 분모를 부풀린 스팸 가입 때문으로 보이는 가파른 활성화 절벽을 보였다는 것을 발견했습니다. 이것들은 창업자가 몇 주 후 대시보드 리뷰에서 발견할 것이 아니라 빠르게 봐야 하는 종류의 것들입니다.
두 번째 사례: 트라이얼 남용 경제학
마스킹된 제품 데이터는 고전적인 BI 차트가 아닌 질문에도 유용합니다.
트라이얼 남용을 살펴봤을 때 유용한 지표는 총 소비 컴퓨트가 아니었습니다. 총 소비량은 오래된 계정 쪽으로 편향될 텐데, 그들은 크레딧을 소비할 시간이 더 많았기 때문입니다. 더 나은 질문은 이것이었습니다.
신규 계정이 가입 후 첫 몇 시간 동안 얼마나 많은 트라이얼 컴퓨트를 태우는가?
MaskDB를 사용해 에이전트는 가입 이후 일치하는 시간 창에서 컴퓨트 소비를 측정했습니다. 사용 이벤트에서의 크레딧 소비, 조직 메타데이터에서의 가입 타임스탬프, 그리고 구독 상태를 활용해 트라이얼 경제학을 유료 사용량과 분리했습니다.
순찰이 도입된 후, 가입 후 첫 몇 시간 동안 태워진 평균 트라이얼 컴퓨트가 80% 이상 떨어졌습니다. 과도하게 태우는 꼬리는 거의 사라졌습니다. 90번째 백분위수에서 첫 몇 시간의 트라이얼 컴퓨트는 약 $4.05에서 약 $0.26으로, 94% 하락했습니다.
이 숫자는 단순한 분석 포인트가 아닙니다. 사업에 대한 운영적 관점을 바꿉니다. 창업자 팀에게 남용이 단지 탐지되고 있을 뿐 아니라, 트라이얼의 단위 경제학이 올바른 방향으로 움직이고 있다고 말해줍니다.
그리고 이것이 가능했던 것은 데이터베이스가 진실을 가지고 있었고, 마스킹된 브랜치가 에이전트로 하여금 그 진실을 안전하게 분석하게 만들었기 때문입니다.
세 번째 사례: 실제 제품에서의 모델 비용
가격 페이지와 벤치마크 시트는 유용하지만, 창업자들이 실제로 신경 쓰는 질문에는 답하지 못합니다.
이 모델이 우리의 실제 제품에서, 실제 실행 전반에 걸쳐 얼마의 비용이 드는가?
MaskDB를 사용해 에이전트는 실행 기록을 실행 시점에 선택된 모델과 조인하고 사용 이벤트에서 청구된 크레딧을 집계함으로써 과거 채팅 실행을 비교했습니다.
이 구분이 중요합니다. 사용자의 현재 기본 모델 프로바이더를 사용해 과거 실행을 귀속시켜서는 안 됩니다. 기본값은 바뀌기 때문입니다. 실행 시점에 선택된 모델이 진실의 원천입니다.
우리의 분석에서 DS v4 Pro는 채팅 실행당 중앙값 모델 크레딧 비용이 Sonnet의 약 49%였습니다. 다시 말해, 실제 중앙값 채팅 실행은 그 라우트에서 대략 51% 더 저렴했습니다.
다시 말하지만, 이것은 창업자 수준의 BI입니다. 제품 행동, 인프라 비용, 그리고 모델 전략을 연결합니다. 새 웨어하우스가 필요하지 않습니다. 올바른 관계형 데이터에 대한 안전한 접근이 필요할 뿐입니다.
이것은 웨어하우스를 영원히 대체하는 것이 아니다
회사에 더 정형화된 데이터 스택이 필요해지는 지점이 있습니다.
지표에 강력한 시맨틱 거버넌스가 필요할 때, 여러 팀이 같은 정의에 의존할 때, 과거 백필이 복잡해질 때, 대시보드가 운영 체계의 일부가 될 때, 웨어하우스나 레이크하우스가 올바른 답이 될 수 있습니다.
하지만 많은 스타트업이 그 답에 너무 일찍 손을 뻗습니다.
당신이 작은 창업자 팀이라면, 첫 BI 시스템은 질문에 답하는 데 도움을 줘야지, 유지해야 할 두 번째 제품을 만들어서는 안 됩니다. 마스킹된 데이터베이스가 그 다리가 될 수 있습니다. 데이터 모델링이 중요하지 않은 척하는 것이 아닙니다. 제품 데이터베이스가 이미 다음 일련의 의사결정에 필요한 관계들을 담고 있다는 것을 인정하는 것입니다.
에이전트가 판단의 필요성을 없애주지는 않습니다. 분석의 첫 버전을 더 저렴하게 돌릴 수 있게 만들어줄 뿐입니다.
창업자 팀을 위한 패턴
패턴은 단순합니다.
- 제품 데이터베이스를 첫 번째 진실의 원천으로 취급하세요.
- 에이전트에게 원본 프로덕션을 절대 노출하지 마세요.
- 손으로 만든 샘플 데이터셋이 아니라 프로덕션과 유사한 브랜치를 사용하세요.
- 접근 전에 민감한 컬럼을 정적으로 마스킹하세요.
- 분석이 여전히 작동하도록 불투명한 조인 식별자를 보존하세요.
- 읽기 전용 역할을 통해 브랜치를 노출하세요.
- 에이전트가 마스킹된 DB와 주변 도구 전반에 걸쳐 분석가 루프를 돌리게 하세요.
이렇게 하면 창업자 팀은 완전한 데이터 플랫폼을 먼저 구축하지 않고도 유용한 운영 체계를 얻습니다.
또한 더 깔끔한 보안 태세를 만들어냅니다. 에이전트에게는 단단한 경계가 있습니다. 에이전트가 보는 데이터베이스는 이미 변환되어 있습니다. 에이전트가 사용하는 역할은 쓰기를 할 수 없습니다. 에이전트가 만드는 보고서는 해시되거나 집계된 식별자로 제한될 수 있습니다.
그것이 VM0에서 우리가 원했던 균형입니다. 프라이버시와 보안을 거래의 대상이 아니라 바닥으로 삼으면서도, 창업자 팀에게 사업을 이해할 훨씬 빠른 방법을 제공하는 것이죠.
데이터 레이크를 구축하기 전에, 제품 데이터베이스의 마스킹된 읽기 전용 브랜치가 팀이 실제로 가진 다음 20개의 질문에 답할 수 있는지 먼저 물어보세요.
우리에게는 그것이 BI로 가는 더 빠른 길이었습니다.
출처
- Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
- PostgreSQL Anonymizer의 Neon 포크: https://github.com/neondatabase/postgresql_anonymizer
