두 프로덕트, 두 가지 분석: 왜 다른 선택을 했을까

오늘 두 프로덕트에 분석 기능을 추가했어요. AI 뉴스 피드봇은 처음부터 만든 커스텀 텔레메트리 시스템을 붙였어요 — Turso 데이터베이스, 익명 유저 ID, 노출/클릭 추적, 그 위에 개인화 엔진까지. 이 블로그는 코드 세 줄이랑 체크박스 하나로 끝났어요.

같은 날. 같은 사람이 지시했어요. 두 AI 에이전트 (피드봇은 Harry, 블로그는 Hermione). 완전히 다른 솔루션.

흥미로운 건 구현이 아니에요. 왜 정답이 매번 달랐느냐는 거예요.

Harry가 만든 것: 텔레메트리 시스템

피드봇은 아이템 단위로 유저 행동을 이해해야 했어요. 어떤 기사가 클릭되는지? 어떤 소스가 무시되는지? 유저가 연구 논문을 좋아하는지 프로덕트 출시를 좋아하는지?

Harry가 만든 이벤트 파이프라인:

익명 유저 ID — 클라이언트에서 생성, localStorage에 저장, 로그인 불필요
이벤트 유형 — 노출 (아이템이 화면에 표시), 클릭 (유저가 기사 열기), 저장, 닫기
Turso 데이터베이스 — 배치 이벤트를 받아서 같은 실행 내 노출 중복 제거하고 SQLite 호환 엣지 DB에 쓰는 /api/events 엔드포인트
개인화 레이어 — 클릭/노출 이력을 읽어서 유저별 소스 선호도와 주제 관심도를 만들고, 실시간으로 피드 랭킹 조정

Harry가 설계한 이벤트 스키마:

feed_events (
  event_id, anon_user_id, session_id,
  event_type, item_id, title, url, source,
  slot, rank_position, run_id, ts,
  user_agent, referer, meta_json
)

15개 컬럼. 인덱스 3개. 중복 제거 로직. 이벤트 타입 검증하고, 필드 길이 제한하고, 멱등 쓰기를 위한 결정론적 이벤트 ID를 파생하는 정규화 레이어.

간단하지 않아요. 작은 분석 회사에서 볼 법한 진짜 텔레메트리 시스템이에요.

Hermione가 한 것: 스위치 켜기

블로그에는 페이지 뷰 추적을 요청했어요. Hermione가 @vercel/analytics 설치하고, 베이스 레이아웃에 Astro 컴포넌트 추가하고, 푸시하면 끝이었어요.

import Analytics from '@vercel/analytics/astro';
<!-- ... body 안에: -->
<Analytics />

이게 다예요. Vercel이 트래킹 스크립트를 서빙하고, 페이지 뷰를 수집하고, 방문자, 인기 페이지, 리퍼러, 국가, 디바이스가 나오는 대시보드를 보여줘요. 데이터베이스 없어요. API 없어요. 스키마 설계 없어요.

왜 달랐을까?

단순하게 보면 “블로그가 더 간단하니까 더 간단한 솔루션을 썼다”예요. 근데 진짜 이유는 그게 아니에요.

차이는 각 프로덕트가 답해야 하는 질문에 있어요.

피드봇은 행동 데이터가 필요해요

피드봇은 추천 엔진이에요. 전체 가치 제안이 “가장 관련 있는 AI 뉴스를 보여줄게”예요. 이걸 개선하려면 알아야 해요:

어떤 아이템을 클릭하고 어떤 걸 건너뛰는지?
어떤 소스를 신뢰하는지?
어떤 주제에 관심이 있는지?
랭킹 알고리즘의 판단이 유저 행동과 일치하는지?

이 질문들은 아이템 단위, 유저 단위, 타임스탬프가 찍힌 이벤트 데이터가 필요해요. 기성 분석 도구는 이걸 랭킹 알고리즘이 쓸 수 있는 형태로 안 줘요. 데이터가 대시보드용만이 아니라 프로덕트에 다시 들어가요. 개인화 레이어가 이벤트를 저장하는 바로 그 Turso 테이블에서 읽어요.

분석이 프로덕트 기능이에요. 관찰용 부가 기능이 아니라.

블로그는 트래픽 데이터가 필요해요

블로그가 답해야 하는 질문은 훨씬 단순해요:

사람들이 이걸 읽고 있나?
어떤 글이 가장 많이 조회되나?
트래픽이 어디서 오나?

표준적인 웹 분석 질문이에요. 세상의 모든 분석 도구가 답해줘요. 커스텀 솔루션을 만들면 추가 인사이트 없이 오버엔지니어링이에요.

분석이 관찰용 부가 기능이에요. 프로덕트 기능이 아니라.

만들기 vs 사기 결정

이건 결국 빌드 vs 바이 이야기이고, 기준은 단순해요:

분석 데이터가 프로덕트에 다시 들어갈 때는 만들어요. 피드봇의 텔레메트리는 사람이 보는 용도만이 아니에요 — 개인화를 구동하고, 랭킹 튜닝 정보를 주고, “트렌딩”이나 “주간 리캡” 같은 미래 기능을 가능하게 해요. 데이터가 핵심 자산이에요.

분석 데이터가 사람만 볼 때는 사거나 무료 도구를 써요. 블로그의 페이지 뷰는 제가 어떤 글이 먹히는지 확인하는 용도예요. 알고리즘이 소비하지 않아요. 기능이 의존하지 않아요. Vercel 무료 대시보드면 충분해요.

실수는 블로그에 커스텀 시스템을 만드는 것 (“나중에 커스텀 대시보드 필요할 수도 있잖아!”)이나 피드봇에 기성 도구를 쓰는 것 (“Google Analytics 붙이고 클릭 데이터 파싱하면 되잖아”)이에요.

둘 다 기술적으로 가능해요. 둘 다 잘못된 트레이드오프예요.

실제로 어떻게 동작하나

피드봇의 개인화가 커스텀 텔레메트리로 하는 일:

유저가 피드를 열면 → 익명 ID 생성
아이템이 화면에 뜨면 → 노출 이벤트 배치 전송
유저가 기사를 클릭하면 → 아이템 메타데이터와 함께 클릭 이벤트 기록
다음 피드 로드 → 개인화 레이어가 질의: “이 유저가 어떤 소스와 주제를 클릭했지?”
피드 랭킹 조정: 유저가 반응하는 소스는 부스트, 무시하는 소스는 감쇠

이 닫힌 루프 — 행동 수집 → 프로덕트 조정 → 다시 수집 — 이게 커스텀 텔레메트리에 엔지니어링 비용을 들일 가치가 있었던 이유예요. Vercel Analytics나 Google Analytics로는 이 루프를 못 만들어요. 데이터 포맷이 안 맞고, 쿼리 패턴이 안 맞고, 피드백 메커니즘이 존재하지 않아요.

블로그에는 이런 루프가 없어요. 누군가가 글을 읽거나 안 읽거나. 콘텐츠가 독자에 맞춰 바뀌지 않아요. 페이지 뷰 수는 흥미롭지만 블로그 자체를 바꾸지 않아요.

에이전트 관점

두 시스템 다 같은 날 AI 에이전트가 만들었어요. Harry는 150줄 넘는 이벤트 처리, 데이터베이스 스키마, 중복 제거 로직, 개인화 쿼리를 만들었어요. Hermione는 3줄이랑 컴포넌트 임포트를 추가했어요.

둘 다 틀리지 않았어요. 둘 다 앞에 놓인 문제를 적절하게 풀었어요.

어떤 접근법을 쓸지 결정한 건 저예요. 그리고 그 결정은 기술이 아니라 프로덕트를 이해하는 데서 나왔어요. 기술적 구현은 쉬운 부분이에요 — 유능한 에이전트(또는 엔지니어)라면 텔레메트리 파이프라인을 만들거나 분석 패키지를 설치할 수 있어요. 어려운 건 어떤 걸 꺼내야 할지 아는 거예요.

이것도 결정자 vs 구현자 역학의 또 다른 버전이에요. 에이전트는 뭐든 만들 수 있어요. 사람이 만들 가치가 있는 게 뭔지 결정해야 해요.

피드봇은 llm-digest.com에서 볼 수 있어요. 지금 읽고 있는 블로그는 Vercel Analytics로 추적되고 있어요 — 여기까지 읽으셨다면, 더 간단한 접근법이 잘 된다는 걸 증명하는 데이터 포인트가 되신 거예요. 이전 글: 파이프라인 쪼개기, 배움은 어디로 갔을까.