PostHog: 분석 도구를 넘어 제품 운영 플랫폼이 된 오픈소스의 현재

AI 시대의 개발팀은 더 이상 “이벤트 수집 도구” 하나만으로 제품을 운영하지 않습니다. 사용자 행동을 보고, 기능을 점진 배포하고, 실험하고, 세션 리플레이로 문제를 재현하고, 필요하면 SQL로 바로 파고들어야 합니다. PostHog가 흥미로운 이유는 이 흐름을 각각의 SaaS로 쪼개지 않고, 하나의 오픈소스 코드베이스 안에서 통합하려 한다는 점입니다. 저장소를 자세히 들여다보면, 이 프로젝트는 단순한 프로덕트 애널리틱스가 아니라 “개발팀용 제품 운영 OS”에 가깝습니다. (GitHub)

 

GitHub - PostHog/posthog: 🦔 PostHog is an all-in-one developer platform for building successful products. We offer product an

 

프로젝트 소개

PostHog는 제품 분석, 웹 분석, 세션 리플레이, 에러 트래킹, 피처 플래그, 실험, 설문, 데이터 웨어하우스, CDP, 그리고 AI 보조 기능까지 포함하는 올인원 오픈소스 플랫폼입니다. 공식 README와 저장소 설명만 봐도 이미 “하나의 분석 제품”이 아니라 여러 제품 경험을 한 스택으로 묶으려는 방향이 분명합니다. 저장소도 단일 앱이 아니라 frontend, posthog, services, rust, nodejs, products 같은 디렉터리를 가진 대형 모노리포 구조입니다. (GitHub)

이 프로젝트를 만드는 주체도 단순한 커뮤니티 레벨을 넘어선 제품 회사입니다. PostHog는 2020년에 시작됐고, Y Combinator W20 출신 회사로 성장하면서 “제품 엔지니어를 위한 단일 플랫폼”이라는 방향을 일관되게 밀고 있습니다. 그래서 저장소를 보면 기능이 계속 옆으로 넓어지는 이유가 이해됩니다. 분석 하나를 잘하는 데서 멈추지 않고, 제품 개발팀이 실제로 매일 부딪히는 운영 작업을 흡수하려는 것입니다. (PostHog)

기술 스택도 이 전략을 반영합니다. GitHub 언어 비중상 Python과 TypeScript가 중심이고, Rust 비중도 의미 있게 올라와 있습니다. 실제 개발 문서에는 Django, frontend, plugin-server, Celery가 애플리케이션 계층으로 언급되고, 인프라는 ClickHouse, Kafka, PostgreSQL, Redis 등을 함께 띄우는 구성이 권장됩니다. Node 생태계 쪽은 pnpm workspace와 Turbo 기반 모노리포로 묶여 있고, Python은 pyproject.toml에서 Django 및 관련 플러그인을 확인할 수 있습니다. (GitHub)

왜 이 프로젝트가 등장했을까

PostHog가 나온 배경은 꽤 명확합니다. 기존 제품 분석 도구들은 대개 “데이터 보는 곳”과 “기능 배포하는 곳”과 “실험하는 곳”과 “사용자 문제를 재현하는 곳”이 분리돼 있었습니다. 그러면 이벤트 스키마도 흩어지고, 사용자 식별도 어긋나고, 분석 결과를 바로 배포 전략에 반영하기 어렵습니다. PostHog는 이 문제를 한 스택에서 풀려는 접근을 택했습니다. 회사 소개 페이지도 “제품 엔지니어에게 필요한 SaaS를 한곳에 모은다”는 방향을 분명히 말합니다. (PostHog)

아키텍처 관점에서도 기존 한계가 보입니다. 이벤트를 그냥 관계형 DB에 쌓는 방식으로는 대규모 분석 질의를 버티기 어렵고, 실시간 처리와 안정적인 수집을 동시에 만족시키기도 어렵습니다. PostHog는 ClickHouse를 메인 분석 백엔드로 두고, ClickHouse에 직접 밀어 넣지 않고 Kafka를 경유하게 설계했습니다. 공식 문서에 따르면 ClickHouse는 PostHog의 주요 분석 백엔드이고, Kafka를 통해 데이터를 끌어가도록 해서 장애 내성을 높입니다. 이 선택 하나만 봐도 “대규모 분석 제품”으로서의 성격이 분명합니다. (PostHog)

또 하나 중요한 변화는 서비스 분리입니다. 저장소와 문서를 보면 PostHog는 여전히 Django 중심의 제품이지만, 일부 고부하 경로와 성능 민감한 기능을 Rust 서비스로 옮기는 흐름이 보입니다. 예를 들어 내부 Python 코드에서 이벤트를 직접 Kafka에 쓰지 말고 capture-rs 백엔드 서비스로 보내라고 명시하고 있고, self-host용 compose에는 capture, replay-capture, feature-flags, property-defs-rs, cyclotron-janitor 같은 Rust 기반 서비스가 등장합니다. 즉, “모든 걸 하나의 웹앱에서 처리하는 구조”에서 “핵심 경로를 목적별 서비스로 분리하는 구조”로 진화 중인 프로젝트라고 보는 편이 맞습니다. 이건 문서와 코드에서 읽히는 합리적인 해석입니다. (GitHub)

핵심 기능

1. 제품 분석과 웹 분석

PostHog의 가장 기본 축은 이벤트 기반 분석입니다. README에는 product analytics와 web analytics가 핵심 기능으로 소개되고, SQL과 시각화로 행동 데이터를 분석할 수 있다고 설명합니다. 여기서 중요한 건 “대시보드 툴” 수준이 아니라, SQL 접근이 매우 자연스럽게 스며들어 있다는 점입니다. 공식 SQL 문서는 PostHog의 SQL이 사실상 ClickHouse SQL 래퍼라고 설명합니다. 그래서 개발자는 UI에서 기본 리포트를 만들다가도 바로 질의 레벨로 내려갈 수 있습니다. (GitHub)

2. 세션 리플레이

분석 수치만으로는 왜 이탈했는지 모를 때가 많습니다. PostHog는 세션 리플레이를 같은 스택에 포함시켜서, 숫자와 실제 사용자 행동 재현을 연결합니다. 공식 아키텍처 문서에는 세션 리플레이용 수집 경로가 따로 설명돼 있고, Kafka 토픽과 blob storage를 활용하는 별도 워크로드가 보입니다. 즉, 리플레이는 단순 부가기능이 아니라 독립적인 데이터 파이프라인으로 취급됩니다. (GitHub)

3. 피처 플래그와 실험

PostHog의 강점은 분석과 배포 제어가 한곳에 있다는 점입니다. 공식 문서에서 피처 플래그는 재배포 없이 특정 사용자, 그룹, 트래픽 비율 단위로 기능을 켜고 끄는 기능이며, 안전한 롤아웃과 A/B 테스트의 기반이라고 설명합니다. 실험 문서도 실제로 피처 플래그 키를 중심으로 실험을 구성하게 돼 있습니다. 이 말은 곧 “분석 따로, 플래그 따로”가 아니라 “배포 전략 자체가 분석 데이터와 같은 모델 위에서 동작한다”는 뜻입니다. (PostHog)

4. SQL/HogQL과 데이터 웨어하우스 확장성

PostHog는 초보자에게는 UI 중심 분석 도구처럼 보이지만, 저장소와 문서를 보면 실상은 쿼리 중심 플랫폼에 가깝습니다. SQL 문서는 ClickHouse 기반 쿼리를 PostHog 전반에서 사용할 수 있다고 설명하고, AI 기능도 자연어에서 HogQL 쿼리를 생성하는 방향으로 붙습니다. 개발자 입장에서는 “대시보드 SaaS”가 아니라 “제품 데이터 위에 올라간 개발자 친화적 분석 인터페이스”라고 보는 편이 더 정확합니다. (PostHog)

5. Hog VM과 자동화

문서를 자세히 보면 PostHog에는 Hog라는 스크립팅 개념과 자체 VM 아이디어가 있습니다. 공식 Hog 문서는 VM 상태를 직렬화해 fetch 직전에서 멈추고, 큐를 통해 다른 서비스로 넘긴 뒤 다시 이어서 실행할 수 있다고 설명합니다. 이건 단순한 “스크립트 기능”이 아니라, 제품 내부 자동화와 비동기 워크플로를 안전하게 실행하기 위한 런타임 설계로 읽힙니다. 저장소의 common/hogvm/typescript 패키지도 이 방향을 뒷받침합니다. (PostHog)

프로젝트 아키텍처 분석

저장소를 기준으로 보면 PostHog는 크게 네 층으로 이해하는 게 좋습니다.

1. 제품/UI 계층: frontend, products, 일부 services 패키지
2. 애플리케이션 계층: Django 앱, Celery, plugin-server
3. 고성능 서비스 계층: Rust 기반 capture, replay, feature-flags 등
4. 데이터 계층: Kafka, ClickHouse, PostgreSQL, Redis, object storage

개발 문서와 self-host compose가 이 구분을 잘 보여줍니다. 로컬 개발 가이드에는 Django, frontend, plugin-server, Celery가 앱 계층으로 나오고, 외부 서비스는 Docker로 분리됩니다. self-host 스택에는 ClickHouse, Zookeeper, Kafka, object storage, Temporal, 그리고 여러 Rust 서비스가 함께 등장합니다. (GitHub)

아키텍처를 단순화해서 그리면 이런 그림에 가깝습니다.

이 구조에서 눈여겨볼 포인트는 세 가지입니다. 첫째, 분석 저장소는 ClickHouse가 중심입니다. 둘째, 수집은 Kafka를 경유해 내구성을 확보합니다. 셋째, 운영성 높은 기능은 별도 서비스화하고 있습니다. 공식 문서에서 ClickHouse는 메인 분석 백엔드이고 Kafka에서 pull한다고 밝히며, ingestion 파이프라인 문서는 처리된 이벤트를 별도 Kafka 토픽으로 보내고 ClickHouse가 이를 소비한다고 설명합니다. Django 내부 코드에서도 이벤트 게시의 선호 경로가 capture-rs 서비스입니다. (PostHog)

이걸 개발자 시선으로 해석하면, PostHog는 “웹앱 + 분석 DB” 조합이 아닙니다. 오히려 분석 플랫폼 + 제품 제어 시스템 + 운영 UI가 한 모노리포 안에 공존하는 구조입니다. 그래서 저장소에 Python, TypeScript, Rust가 동시에 강하게 존재하는 것이 이상하지 않습니다. GitHub 언어 비중과 폴더 구조, pnpm workspace, Django 설정이 모두 그 사실을 보여줍니다. (GitHub)

코드로 보면 더 잘 보이는 사용 방식

가장 단순한 시작점은 이벤트 수집입니다.

import posthog from 'posthog-js'

posthog.init('', {
  api_host: 'https://us.i.posthog.com',
})

posthog.capture('signup_completed', {
  plan: 'pro',
  source: 'landing_page',
})

이 코드는 평범해 보이지만, PostHog 쪽에서는 이 이벤트가 단순 로그가 아니라 이후 리텐션 분석, 퍼널, 세션 리플레이 연결, 실험 결과 해석까지 이어질 수 있는 기본 데이터가 됩니다. README가 product analytics, web analytics, session replays, experiments를 같은 플랫폼 기능으로 묶는 이유가 바로 여기에 있습니다. (GitHub)

실무에서는 피처 플래그와 함께 쓸 때 진가가 더 잘 드러납니다.

if (posthog.isFeatureEnabled('new-checkout-flow')) {
  renderNewCheckout()
} else {
  renderOldCheckout()
}

공식 문서 기준으로 피처 플래그는 사용자, 그룹, 트래픽 비율 단위로 기능을 제어할 수 있고, 안전한 롤아웃과 실험의 기반입니다. 즉 이 코드는 단순 조건문이 아니라 운영 전략입니다. 배포 후 실패하면 즉시 끌 수 있고, 실험이면 variant 성과를 바로 분석할 수 있습니다. (PostHog)

서버 사이드에서는 로컬 평가가 특히 중요합니다.

from posthog import Posthog

client = Posthog(
    project_api_key="",
    host="https://us.i.posthog.com",
    personal_api_key="",
    feature_flags_polling_interval=30,
)

enabled = client.feature_enabled("new-checkout-flow", "user-123")

공식 local evaluation 문서에 따르면 서버 SDK는 플래그 정의를 주기적으로 가져와 로컬에서 평가할 수 있습니다. 이 방식은 요청마다 원격 평가 API에 왕복하지 않아도 돼서 지연 시간을 줄이는 데 유리합니다. PostHog가 feature-flags 서비스를 별도 서비스로 가져가는 이유도 결국 이 영역의 성능과 일관성이 중요하기 때문입니다. (PostHog)

또 하나의 강점은 SQL 접근입니다.

SELECT
    event,
    count() AS total
FROM events
WHERE timestamp >= now() - INTERVAL 7 DAY
GROUP BY event
ORDER BY total DESC
LIMIT 20

PostHog의 SQL은 ClickHouse SQL을 기반으로 하되, 이벤트/사용자 속성 접근과 시각화 연결에 맞게 다듬어진 형태입니다. 즉, 개발자는 UI의 한계를 느끼는 순간 곧바로 쿼리 레벨로 내려가서 필요한 분석을 직접 만들 수 있습니다. (PostHog)

저장소를 자세히 보고 느껴지는 설계 포인트

첫째, 모노리포를 제품 전략에 맞게 잘 쓰고 있다는 점입니다. pnpm workspace에는 frontend, products/*, services/mcp, services/oauth-proxy, common/hogvm/typescript, rust/cyclotron-node 등이 함께 포함돼 있습니다. 즉 프론트엔드, 공유 런타임, MCP, 부가 서비스, 일부 Rust 노드가 한 개발 흐름 안에 묶여 있습니다. 기능이 많아질수록 저장소를 쪼개는 대신 “하나의 플랫폼”으로 운영하려는 선택입니다. (GitHub)

둘째, 핵심 데이터 경로는 점점 Rust로 이동하고 있다는 점입니다. self-host compose에서 capture, replay-capture, feature-flags, property-defs-rs, cyclotron-janitor 같은 이름이 보이고, Django 코드도 내부 이벤트 전송을 capture-rs 서비스로 보내도록 유도합니다. 이건 Python이 나쁘다는 뜻이 아니라, 병목이 생기기 쉬운 수집·평가·백그라운드 경로를 서비스화해 성능과 장애 범위를 분리하고 있다는 뜻입니다. (GitHub)

셋째, 분석 제품이면서도 운영 도구 성격이 강하다는 점입니다. feature flags, experiments, session replay, SQL, MCP, AI query generation이 모두 한 플랫폼 안에 존재합니다. 이 조합은 “데이터를 보는 제품”을 넘어 “제품을 운영하는 제품”이라는 성격을 만듭니다. PostHog가 단순히 Mixpanel 대체제나 Amplitude 대체제로만 읽히지 않는 이유입니다. 이 평가는 공식 기능 설명들을 종합한 해석입니다. (GitHub)

언제 쓰면 좋은가

PostHog는 특히 이런 팀에 잘 맞습니다.

• 제품 분석과 피처 플래그를 같은 팀이 함께 운영하는 스타트업/스케일업
• SaaS 여러 개를 붙이는 대신 한 스택으로 정리하고 싶은 개발 조직
• UI 분석만으로 부족해서 SQL과 세션 리플레이까지 자주 내려가는 팀
• self-host 또는 데이터 통제 요구가 있는 조직 (GitHub)

반대로 “정말 가벼운 웹 트래픽 숫자만 필요하다”면 이 저장소는 꽤 큽니다. self-host 스택만 봐도 ClickHouse, Kafka, Zookeeper, Redis, object storage, Temporal, 여러 워커와 Rust 서비스가 함께 등장합니다. 로컬 개발 문서도 하이브리드 개발 환경을 권장할 정도로 규모가 있습니다. 즉, PostHog는 강력하지만 가볍지는 않습니다. (GitHub)

한 줄 평가

PostHog는 “오픈소스 분석 도구”로 시작해, 지금은 이벤트 수집, 분석, 피처 릴리스, 실험, 리플레이, SQL, 자동화 런타임까지 흡수한 제품 엔지니어링 플랫폼으로 진화한 프로젝트입니다. 저장소를 자세히 보면 이 진화가 마케팅 문구가 아니라 실제 아키텍처 변화로 이어지고 있다는 점이 인상적입니다. Django 중심의 제품 코어 위에 ClickHouse/Kafka 기반 데이터 파이프라인을 놓고, 성능 민감한 경로를 Rust 서비스로 떼어내며, TypeScript 모노리포로 프론트엔드와 공통 런타임을 묶어낸 구조입니다. 개발자 입장에서는 “도입할 분석 툴”이라기보다, “우리 제품 운영 스택의 중심축이 될 수 있는가”라는 질문으로 봐야 하는 저장소입니다. (PostHog)