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

오늘 두 프로덕트에 분석 기능을 추가했습니다. 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 사기 (Build vs Buy)

결국 빌드와 바이의 문제이고 기준은 명확합니다:

분석 데이터가 프로덕트 내부 로직으로 다시 순환할 때는 직접 만듭니다. 피드봇의 텔레메트리는 사람이 리포트를 보는 용도에 그치지 않습니다. 개인화를 굴리고, 랭킹 가중치를 보정하며, 향후 트렌딩이나 주간 요약 같은 기능을 지탱하는 핵심 자산이 되기 때문입니다.

데이터의 최종 소비자가 사람뿐일 때는 기성 도구를 씁니다. 블로그 페이지 뷰는 제가 어떤 글의 반응이 좋은지 훑어보는 용도면 충분합니다. 알고리즘이 이 숫자를 읽을 필요도 없고 글 목록이 독자에 맞춰 동적으로 재배치될 일도 없습니다. Vercel 무료 대시보드로 차고 넘칩니다.

진짜 실수는 “혹시 나중에 필요할지 모르니까” 블로그에 커스텀 DB를 붙이거나, “일단 편하니까” 피드봇에 Google Analytics 스크립트만 심어놓고 클릭 로그를 파싱하려 드는 타협에서 나옵니다. 둘 다 기술적으로는 가능하겠지만 잘못된 트레이드오프입니다.

실제로 어떻게 동작하나

피드봇의 개인화 로직은 커스텀 텔레메트리를 통해 다음과 같이 순환합니다:

유저가 피드를 열면 클라이언트에서 익명 ID 생성
화면에 아이템이 노출되면 배치 노출 이벤트 전송
유저가 기사를 클릭하면 아이템 메타데이터와 함께 클릭 이벤트 기록
다음 피드를 새로고침할 때 개인화 레이어가 질의: “이 유저가 최근 반응한 소스와 주제는 무엇인가?”
피드 랭킹 보정: 자주 반응한 소스에는 가중치를 부여하고 지나친 소스는 우선순위를 낮춤

이 닫힌 루프(행동 수집 → 프로덕트 조정 → 다시 수집)야말로 커스텀 텔레메트리에 엔지니어링 리소스를 투입할 충분한 이유가 됩니다. Vercel Analytics나 Google Analytics로는 이 사이클을 구성할 수 없습니다. 데이터 포맷도, 쿼리 방식도 맞지 않으며 무엇보다 프로덕트로 되먹이는 피드백 통로가 없기 때문입니다.

블로그에는 이런 동적 피드백이 필요하지 않습니다. 독자는 글을 읽거나 읽지 않을 뿐이고 콘텐츠가 독자의 반응에 맞춰 실시간으로 문장을 고쳐 쓰지도 않습니다. 페이지 뷰 숫자는 운영자에게 좋은 참고 자료지만, 블로그 시스템 자체를 변화시키지는 않기 때문입니다.

에이전트 관점

두 시스템 모두 같은 날 AI 에이전트의 손을 거쳐 완성됐습니다. Harry는 150줄이 넘는 이벤트 핸들러, DB 스키마, 중복 방지 로직, 개인화 쿼리를 작성했고, Hermione는 패키지 하나와 컴포넌트 세 줄을 얹었습니다.

두 에이전트 모두 주어진 문제에 딱 맞는 크기의 해법을 찾아내 과제를 훌륭하게 완수했습니다.

하지만 어느 쪽에 어떤 방식을 적용할 것인가는 제가 결정했습니다. 그 결정은 기술 문법이 아니라 각 프로덕트가 지닌 본질적인 목적을 이해하는 데서 나왔습니다. 요즘 에이전트들은 텔레메트리 파이프라인이든 서드파티 라이브러리 연동이든 금세 코드로 뽑아내니 기술 구현 자체는 비교적 쉬운 편입니다. 정말 어려운 부분은 지금 이 순간 어떤 카드를 꺼내 들어야 하는지 판별하는 감각입니다.

이것 역시 결정자와 구현자의 역할 분담이 드러나는 장면입니다. 구현은 에이전트가 눈부시게 해낼 수 있지만, 무엇을 만들고 무엇을 사거나 건너뛸지 저울질하는 책임은 온전히 사람의 몫으로 남습니다.

피드봇은 llm-digest.com에서 운영 중입니다. 지금 읽고 계신 이 블로그는 Vercel Analytics로 가볍게 측정되고 있으니, 여기까지 글을 읽어주신 것 자체가 가장 단순한 해법이 잘 작동하고 있음을 증명하는 생생한 데이터 포인트인 셈입니다. 이전 글: 파이프라인 쪼개기, 배움은 어디로 갔을까.