ee/ 제외) · 셀프호스팅 hobby 지원 · 최신 커밋 2026-07-18 3eda4bf8 · TrendShift Daily #17 · #Self-hosted)
PostHog(포스트혹, 마스코트는 고슴도치 hedgehog)는 "제품을 만드는 데 필요한 모든 데이터·분석·실험 도구를 한곳에 모은 오픈소스 플랫폼"이다. 보통 스타트업은 사용자 행동 분석엔 Amplitude/Mixpanel, 세션 녹화엔 FullStory/Hotjar, 기능 플래그엔 LaunchDarkly, 데이터 수집·전송엔 Segment, 설문엔 또 다른 SaaS… 이렇게 도구를 대여섯 개씩 붙인다. PostHog는 이 전부를 하나의 이벤트 데이터 위에서 돌아가는 단일 제품으로 통합했다.
핵심은 "이벤트(event) 하나가 모든 기능의 원료"라는 설계다. 사용자가 버튼을 누르고, 페이지를 보고, 에러를 만나는 모든 순간이 이벤트로 기록되면 — 같은 데이터로 제품 분석(퍼널·리텐션), 웹 분석(GA 대체), 세션 리플레이(그 사용자의 화면 재생), 에러 추적, 기능 플래그, A/B 실험을 전부 뽑아낼 수 있다. 2026년 PostHog는 여기에 한 겹을 더 올렸다 — "데이터에서 문제(에러·rage click·실패한 쿼리)를 스스로 찾아 리포트와 Pull Request까지 만드는" self-driving 모드. 즉 "분석해서 보여주는" 도구에서 "분석해서 고쳐 주는" 도구로 정체성을 넓히는 중이다.
common/hogql_parser/). 여기에 더해 데이터 파이프라인 변환을 짜는 미니 언어 Hog와 그걸 실행하는 가상머신 HogVM까지 있다. 회사 이름(Hog=고슴도치)을 언어에까지 붙인, PostHog의 정체성이 드러나는 부분이다.예전엔 사용자 행동을 알려면 분석 클리닉, 녹화 클리닉, 실험 클리닉을 따로 예약해야 했다(도구 대여섯 개). PostHog는 한 번 채혈한 피(=이벤트)로 모든 과의 진단을 동시에 내주는 종합병원이다. 퍼널이 새는지, 어느 화면에서 화가 났는지, 새 기능이 지표를 올렸는지를 같은 데이터로 한 화면에서 본다.
2026년 버전은 여기서 한 발 더 간다 — "이 환자(제품)는 여기가 아프니 이렇게 고치세요"라는 리포트와, 심지어 코드 수정 PR까지 자동으로 만들어 의사(개발자)의 승인을 기다린다(self-driving 모드). 진단 기계에서 처방 기계로 진화 중인 병원이다.
PostHog는 신생 레포가 아니다(2020년 시작, 이미 수만 스타의 유명 제품). 그런데 2026년 7월 다시 트렌딩에 오른 이유는 "제품 데이터를 보여주는 도구"에서 "제품을 스스로 고치는 플랫폼"으로 정체성을 재선언했기 때문이다. README 첫 줄이 아예 "the open source platform for building self-driving products"로 바뀌었고, 에러·rage click·실패한 쿼리 같은 신호를 사람이 검토·머지할 수 있는 리포트와 PR로 자동 변환하는 self-driving 모드를 전면에 내세운다. 여기에 Slack·웹·데스크톱(PostHog Code)·에디터(MCP)에서 전부 조종 가능하다는 "어디서나 조종" 서사가 얹혔다.
| 포인트 | 내용 |
|---|---|
| 정체 | 올인원 제품 운영체제(Product OS). 분석·리플레이·플래그·실험·에러추적·설문·데이터웨어하우스·CDP를 하나의 이벤트 데이터 위에서 돌린다. 클라우드(US/EU) 또는 셀프호스팅. |
| 차별점 | 도구 대여섯 개를 하나로 — Amplitude+FullStory+LaunchDarkly+Segment+…를 통합. 데이터가 한곳에 있으니 "퍼널 이탈 → 그 사용자 세션 재생 → 플래그로 실험"이 끊김 없이 이어진다. |
| 2026 재포지셔닝 | self-driving 모드 — 데이터의 이상 신호를 자동으로 조사해 리포트·PR 생성(사람이 승인·머지). "분석"에서 "자율 개선"으로. |
| 오픈소스 신뢰 | MIT 라이선스(코어)에 회사 핸드북·전략·급여 체계까지 오픈소스. 한 줄 Docker로 셀프호스팅 가능, 완전 FOSS 원하면 posthog-foss 미러 제공. |
| 엔지니어링 스케일 | Django·React·Rust·C++가 뒤섞인 초대형 모노레포(py 14,814 · ts/tsx 10,919 · rust 1,255 파일 · products/ 86개 제품). 대규모 이벤트 인프라의 실전 교본. |
도구를 따로 쓰면 마치 병원·약국·헬스장·영양사가 서로 차트를 안 넘겨주는 것과 같다. 분석 도구는 "결제 퍼널이 샌다"고만 말하고, 그 사용자가 실제로 화면에서 무엇을 했는지는 다른 도구(세션 리플레이)에 있어 연결이 끊긴다.
PostHog는 이 모든 차트가 같은 환자 번호(=이벤트/사람 ID)로 묶인 한 병원이다. "퍼널 이탈률 급증 → 클릭 한 번에 그 사용자들의 세션 재생 → 원인 발견 → 기능 플래그로 수정본 실험 → 실험 결과 확인"이 한 화면 안에서 흐른다. 통합의 진짜 가치는 기능 개수가 아니라 이 끊김 없는 흐름에 있다.
README의 self-driving 서사는 강렬하지만, 실제 동작은 "사람이 검토하고 머지하는(you review and merge)" 리포트·PR 생성이다. AI가 알아서 프로덕션을 바꾸는 게 아니라, 사람 승인 단계가 반드시 끼는 반자동이다. 마케팅 문구와 실제 워크플로를 구분해서 읽자. PostHog의 검증된 본체는 여전히 ClickHouse 위의 제품 분석이고, AI 레이어는 그 위에 얹힌 2026년의 새 층이다.
PostHog를 처음 열면 압도된다. 이유는 이게 "웹앱 하나"가 아니라 수십 개의 서비스가 모인 분산 시스템이기 때문이다. 언어별로 역할이 명확히 나뉘어 있으니, 그 지도를 먼저 그려 두면 길을 잃지 않는다.
레포 루트의 posthog/가 전통적인 Django 모놀리스(API·모델·쿼리 러너)다. 이게 "제어탑" — 사용자를 인증하고, 대시보드를 정의하고, HogQL 쿼리를 조립해 ClickHouse에 던지고 결과를 돌려준다.
| 구성요소 | 버전 · 역할 |
|---|---|
| Django | ~5.2 — 웹 프레임워크. djangorestframework ~3.16(REST API), django-redis, django-two-factor-auth(2FA) 등 확장 다수. |
| ClickHouse 클라이언트 | clickhouse-connect 0.8 + clickhouse-driver 0.2.10 + clickhouse-pool — 이벤트 데이터 조회의 실제 통로. |
| Celery | 5.6 + celery-redbeat — 비동기 작업 큐(리포트 계산·이메일 등 백그라운드 작업). |
| Dagster | 1.10 — 데이터 오케스트레이션(파이프라인 스케줄·의존성 관리). 무거운 데이터 잡의 지휘자. |
| Anthropic SDK | anthropic 0.80 — AI/self-driving 기능이 LLM(Claude)을 호출하는 통로. |
frontend/는 React 18 + TypeScript SPA인데, 상태 관리에 Redux/Zustand가 아니라 Kea(PostHog가 오래 밀어 온 상태 라이브러리)를 쓴다. 화면 단위는 scene(씬)이라 부른다.
| 구성요소 | 버전 · 역할 |
|---|---|
| React | 18.3 — UI 라이브러리. |
| Kea | 상태 관리(+ kea-router 라우팅, kea-forms 폼, kea-loaders 로딩). PostHog 프론트의 정체성. |
| Monaco Editor | 0.55 — VS Code의 그 에디터. HogQL 쿼리 작성 UI. monaco-vim(Vim 모드)까지. |
| Vite / 빌드 | Vite 기반 개발 서버 + 별도 toolbar 빌드. TypeScript 검사는 tsgo, 포맷은 oxfmt(Rust 기반 도구). |
| 시각화 | d3 + d3-flame-graph(플레임 그래프), react-grid-layout(대시보드 배치), react-simple-maps(지도). |
이벤트가 초당 수만 개씩 쏟아질 때 Python은 느리다. 그래서 수집·처리의 뜨거운 경로는 Node.js와 Rust가 맡는다.
| 구성요소 | 역할 |
|---|---|
plugin-server(nodejs/) | Node.js 서비스 묶음 — 인제스천 파이프라인·CDP·세션 리코딩. node-rdkafka(Kafka 소비), @clickhouse/client(적재), @posthog/hogvm(Hog 실행), ioredis, pino(로깅). |
Rust 서비스(rust/) | ~1,255개 .rs. capture(이벤트 수신 엔드포인트), feature-flags(플래그 판정), property-defs-rs(속성 정의), cyclotron(잡 큐), personhog(사람 식별 분산 시스템), cymbal(에러 추적 심볼리케이션). |
HogQL 파서(common/hogql_parser/) | C++ — ANTLR로 생성한 Lexer/Parser. HogQL 텍스트를 AST로 파싱하는 최고 성능 경로. |
| 구성요소 | 역할 |
|---|---|
| ClickHouse | 이벤트·세션 데이터의 본진. 컬럼형 OLAP DB. 분석 쿼리의 실제 대상. |
| PostgreSQL 15 | 앱 메타데이터(계정·대시보드 정의·플래그 설정). 소량·트랜잭션 데이터만. |
| Kafka / Redpanda | 이벤트 인제스천 버퍼. hobby 배포에선 Kafka 대신 Redpanda(redpandadata/redpanda, Kafka 호환)를 쓴다. |
| Redis | 캐시·큐·플래그 캐시(redis7). |
| Temporal | 워크플로 엔진 — 배치 익스포트·장기 실행 워크플로(temporal-django-worker). |
| MinIO / S3 | 세션 리코딩·대용량 파일 오브젝트 스토리지(hobby는 MinIO). |
| Browserless | 헤드리스 크로미움 — 리포트 이미지 렌더링 등. |
이 거대한 시스템도 결국 두 방향의 데이터 흐름으로 요약된다. 하나는 사용자의 이벤트가 밖에서 들어와 ClickHouse에 쌓이는 길(쓰기), 다른 하나는 사람이 던진 질문(HogQL)이 ClickHouse를 조회해 답이 되어 나오는 길(읽기)이다. 이 둘을 분리해서 보면 수십 개 서비스의 존재 이유가 한눈에 들어온다.
핵심 설계는 "받기"와 "처리"의 분리다. capture(Rust)는 이벤트를 받아 Kafka에 던지기만 하고 무거운 일을 안 한다 — 그래야 트래픽이 폭주해도 요청을 떨어뜨리지 않는다. 실제 정제·사람 식별·변환은 뒤에서 plugin-server(Node)가 자기 속도로 처리한다. Kafka가 그 사이의 완충지대(buffer) 역할을 하며 폭주를 흡수한다. 이건 대규모 이벤트 시스템의 교과서적 패턴이다.
여기서 배울 점은 "사용자에게 SQL을 직접 열어주되 안전하게" 하는 방법이다. 날것의 ClickHouse SQL을 노출하면 다른 팀 데이터를 훔쳐보거나 DB를 망가뜨릴 수 있다. PostHog는 HogQL이라는 중간 언어를 두고, 번역 단계에서 "이 팀의 데이터만" 같은 격리 조건과 권한을 강제로 주입한다. 즉 HogQL은 편의 문법이 아니라 보안 경계(security boundary)이기도 하다.
products/ 아래 86개 폴더가 각각 하나의 제품(기능 플래그·실험·세션 리플레이 등)이다. 중요한 건 각 제품이 자기 백엔드(Django 앱)·프론트(React scene)·라우트(manifest.tsx)·MCP 도구(mcp/)·에이전트 스킬(skills/)을 한 폴더 안에 다 소유한다는 점이다(수직 분할). 제품끼리 서로의 내부를 import하지 않고(tach로 import 경계 강제), 테스트도 Turbo로 바뀐 제품만 선택 실행한다. "거대 모노레포지만 각 조각은 독립적"이라는 균형을, 폴더 구조와 도구(Turbo·tach)로 물리적으로 강제한 사례다.PostHog는 이념적으로 한 언어를 고집하지 않는다 — 제어·비즈니스 로직은 개발 속도가 빠른 Python(Django), 화면은 React/TS, 초당 수만 건을 받는 뜨거운 경로는 Rust, 텍스트 파싱은 C++. 각 언어를 "가장 잘하는 일"에만 쓰고, 그 사이를 Kafka·ClickHouse·HTTP로 잇는다. 스타트업이 성장하며 어떻게 단일 Django 앱에서 다국어 분산 시스템으로 진화하는지를 통째로 보여주는, 살아 있는 표본이다.
클론하면 루트에만 수십 개 폴더와 docker-compose.*.yml이 대여섯 개 있어 당황한다. 하지만 "언어별 코드 폴더 + 배포 조합별 compose 파일"이라는 규칙만 알면 정리된다.
package.json의 version: "0.0.0"은 "제품 버전"이 아니다루트 package.json은 "@posthog/root"에 version 0.0.0이다. 이걸 "0.0.0 알파"로 오해하면 안 된다 — PostHog는 semver 릴리스 버전이 없는 지속 배포(continuous deployment) 제품이다. 클라우드는 하루에도 수십 번 배포되고, 셀프호스팅은 Docker 이미지 태그($POSTHOG_APP_TAG)로 버전을 잡는다. 즉 "버전 진실원"이 파일이 아니라 배포 파이프라인/이미지 태그에 있다. 유명 대형 제품이라 별점·버전 수치는 본문에 인용하지 않는다(모멘텀 순위 기준 Daily #17).
ee/ 폴더는 MIT가 아니다 — "MIT 오픈소스"라 뭉뚱그리지 말 것PostHog는 코어가 MIT지만 ee/(enterprise) 디렉토리는 별도의 상용 라이선스(ee/LICENSE)다. "absolutely 100% FOSS"가 필요하면 PostHog가 별도로 제공하는 posthog-foss 미러(모든 독점 코드 제거판)를 써야 한다. 셀프호스팅·재배포 시 이 경계를 반드시 확인하자. 한국어 문서·README는 없다(=사실상 첫 한국어 정리).
대량 이벤트를 다루는 SaaS를 만들려면 "왜 Postgres가 아니라 ClickHouse인가", "왜 capture와 plugin-server를 분리하는가", "Kafka는 어디에 끼는가"를 알아야 한다. PostHog는 이 모든 결정을 실전 프로덕션 규모로 보여주는 몇 안 되는 오픈소스다. rust/capture → Kafka → nodejs/ → ClickHouse 경로를 따라가 보라.
ANTLR로 문법(.g4)을 정의하고, C++로 파서를 생성하고, AST를 안전한 타깃 SQL로 번역하며 권한·격리를 주입하는 전 과정이 posthog/hogql/와 common/hogql_parser/에 통째로 있다. "질의 언어를 직접 만든다"는, 컴파일러 이론이 실무에서 어떻게 쓰이는지의 살아 있는 예제.
86개 제품이 한 저장소에 있는데 어떻게 서로 얽히지 않는가? 각 제품이 자기 폴더에 모든 걸 소유(vertical slice)하고, tach가 import 경계를, Turbo가 변경분만 테스트하도록 강제한다. docs/internal/monorepo-layout.md는 "언제 nested→root로 올리나" 같은 실전 규칙까지 문서화돼 있어 그 자체로 좋은 교재다.
Rust 서비스가 만든 데이터를 Node가 처리하고, Python이 조회하고, C++ 파서를 Python이 호출한다. 이 언어 경계를 Kafka(메시지)·ClickHouse(공유 저장)·gRPC/proto(proto/)로 어떻게 잇는지가 폴더마다 드러난다. "언제 새 언어를 도입할 가치가 있는가"의 판단 근거를 실물로 볼 수 있다.
① hobby로 직접 띄워 이벤트 하나 흘려보기 — bin/deploy-hobby로 로컬에 올리고 posthog-js로 테스트 이벤트를 쏜 뒤, ClickHouse에 실제로 들어가는지 확인. ② HogQL로 SQL 짜 보기 — 앱의 SQL 에디터에서 이벤트를 직접 조회하며 HogQL 문법과 ClickHouse SQL 번역 결과를 비교. ③ 제품 하나 골라 수직 분할 관찰 — products/feature_flags/를 열어 backend/frontend/manifest/mcp가 어떻게 한 폴더에 공존하는지 따라 읽기.
PostHog 셀프호스팅은 명령 한 줄로 시작한다:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"하지만 이 한 줄이 docker-compose.hobby.yml에 정의된 ~40개 서비스를 띄운다. Postgres·Redis·ClickHouse·Redpanda(Kafka)·Temporal·MinIO·Browserless부터 capture·plugin-server·feature-flags·personhog-replica·cymbal까지. 그래서 "가벼운 앱"이 결코 아니다.
| 항목 | 요구/권장 |
|---|---|
| 배포 방식 | Linux + Docker. bin/deploy-hobby 한 줄 스크립트. |
| 메모리 | 최소 4GB 권장. ClickHouse+Kafka+Postgres+Temporal이 동시에 뜨므로 실제론 더 넉넉해야 편하다. |
| 확장 한계 | 셀프호스팅 hobby는 월 약 10만 이벤트까지 권장. 그 이상은 PostHog Cloud로 이전 권고. |
| 지원 | 오픈소스 배포에는 고객 지원·보장 없음(공식 명시). 프로덕션 규모는 클라우드가 정답. |
| 클라우드 대안 | PostHog Cloud US/EU — 월 100만 이벤트·5천 리코딩 등 무료 티어. 대부분 사용자에게 권장 경로. |
| 개발 환경 | pnpm 모노레포 + uv(Python) + Cargo(Rust). docker-compose.dev.yml로 로컬 스택 구동. |
PostHog 셀프호스팅은 "버튼 하나로 조립되는 이케아 가구"가 아니라 "버튼 하나로 착륙하는 소형 우주정거장"에 가깝다. 명령은 한 줄이지만, 그 안에서 데이터베이스·메시지 큐·워크플로 엔진·스토리지·다수의 마이크로서비스가 동시에 살아난다. 학습·실험엔 훌륭하지만, 진짜 트래픽을 받으려면 이 모든 부품을 운영할 각오(또는 클라우드 선택)가 필요하다.
여유 있는 Linux 서버(또는 로컬 Docker, 4GB+)에 deploy-hobby로 PostHog를 올린다. 간단한 정적 HTML에 posthog-js 스니펫을 붙여 페이지뷰·클릭 이벤트를 발생시키고, PostHog 대시보드의 Activity에서 실시간으로 들어오는지 확인한다. 목표: "이벤트가 SDK→서버→ClickHouse까지 흐른다"를 눈으로 확인.
PostHog의 SQL 에디터에서 HogQL로 "최근 7일 DAU", "이벤트별 발생 수 Top 10" 같은 쿼리를 직접 작성한다. 같은 질문을 순수 ClickHouse SQL로도 짜 보고, HogQL이 어떻게 팀 격리·기간 필터를 자동으로 끼워 넣는지 번역 결과를 비교한다. 목표: 도메인 특화 언어가 "편의 + 보안"을 동시에 하는 원리 이해.
products/feature_flags/의 UI로 플래그를 하나 만들고, 앱 코드에서 posthog.isFeatureEnabled()로 분기시킨다. 사용자 비율(rollout %)을 바꿔 가며 같은 사용자에게 항상 같은 결과가 나오는지(결정론적 해싱) 확인. 목표: 플래그가 단순 on/off가 아니라 "안정적 사용자 배정"임을 체득.
rust/capture부터 시작해 "이벤트가 어디서 검증되고 어느 Kafka 토픽으로 가는지"를 코드로 추적한다. 여력이 되면 cargo build -p capture로 그 크레이트 하나만 빌드해 본다. 목표: 초당 수만 건을 받는 서비스가 "받기만 하고 빠르게 흘려보내는" 이유를 코드로 확인.
products/error_tracking/ 같은 제품 하나를 골라 backend/(Django 모델·API), frontend/(React scene), manifest.tsx(라우트), mcp/(AI 도구)를 전부 읽고, 이 제품이 다른 제품을 import하지 않고 어떻게 독립적으로 완결되는지 확인한다. 목표: "모노레포지만 조각은 독립"이라는 아키텍처 원칙을 실물로 이해.
| 주차 | 주제 | 무엇을 · 왜 |
|---|---|---|
| 1주차 | 컬럼형 DB & OLAP | ClickHouse 기본 — 행 기반(OLTP) vs 컬럼 기반(OLAP)의 차이, MergeTree 엔진, 왜 분석 쿼리가 빠른가. 로컬에 ClickHouse를 띄워 샘플 이벤트를 넣고 집계 쿼리를 직접 돌려 본다. |
| 2주차 | 이벤트 스트리밍 | Kafka(또는 Redpanda) — 프로듀서/컨슈머, 토픽, 파티션, 왜 "수집과 처리를 분리"하는가. PostHog의 capture → Kafka → plugin-server 흐름을 이 개념으로 다시 읽는다. |
| 3주차 | 파서 & DSL | ANTLR + AST — 문법 정의(.g4)로 파서를 생성하고, AST를 순회해 다른 형태로 번역하는 컴파일러 기초. posthog/hogql/grammar/를 읽고 HogQL이 어떻게 ClickHouse SQL이 되는지 추적. |
| 4주차 | 모노레포 운영 & Django/React | Turbo·pnpm workspace·tach로 거대 모노레포를 나누는 법 + Django REST + React/Kea 상태 관리. products/ 한 제품을 처음부터 끝까지 읽으며 수직 분할을 체득. |
PostHog는 "데이터가 어디에 어떻게 저장되는가(ClickHouse)"를 모르면 나머지가 안 읽힌다. 그래서 1주차에 컬럼형 DB부터 잡고, 2주차에 그 DB로 데이터가 어떻게 흘러 들어가는가(Kafka)를 배운 뒤, 3주차에 사용자가 그 데이터에 어떻게 질문하는가(HogQL/파서)를, 마지막 4주차에 이 모든 걸 담는 그릇(모노레포·프레임워크)을 익힌다. 데이터의 저장→유입→질의→포장 순서다.
| 용어 | 뜻 |
|---|---|
| Product OS | PostHog의 자기 규정. 제품 분석·리플레이·플래그·실험 등을 한 이벤트 데이터 위에 통합한 "제품 운영체제". |
| self-driving | 2026년 재포지셔닝. 데이터의 이상 신호를 자동 조사해 리포트·PR을 만들되 사람이 검토·머지하는 반자동 개선 워크플로. |
| ClickHouse | 컬럼형(columnar) OLAP 데이터베이스. PostHog 이벤트 데이터의 본진. 대량 집계에 최적화. |
| OLTP vs OLAP | OLTP=행 기반, 개별 레코드 읽기/쓰기(Postgres). OLAP=컬럼 기반, 대량 집계(ClickHouse). PostHog는 둘을 역할별로 함께 쓴다. |
| HogQL | PostHog가 만든 SQL 방언. 이벤트·사람 개념에 맞춘 문법을 안전한 ClickHouse SQL로 번역(+권한·팀 격리 주입). |
| Hog / HogVM | 데이터 파이프라인 변환용 미니 언어(Hog)와 그 실행 가상머신(HogVM). CDP 변환에 쓰인다. |
| capture | Rust로 짠 이벤트 수신 엔드포인트. 받아서 검증 후 Kafka로 흘려보내기만 하는 뜨거운 경로의 첫 관문. |
| plugin-server | nodejs/의 Node.js 서비스 묶음. 인제스천 정제·사람 식별·CDP·세션 리코딩 처리. |
| Kafka / Redpanda | 이벤트 스트리밍 버퍼. 수집과 처리를 분리해 폭주를 흡수. hobby 배포는 Kafka 호환 Redpanda 사용. |
| Temporal | 워크플로 엔진. 배치 익스포트 등 장기 실행 작업을 관리. |
| Dagster | Python 데이터 오케스트레이터. 무거운 데이터 잡의 스케줄·의존성 관리. |
| Kea | PostHog 프론트의 상태 관리 라이브러리(Redux 대신). 화면 단위는 scene. |
| 수직 분할(vertical slice) | 각 제품이 자기 backend·frontend·라우트·MCP·스킬을 한 폴더에 소유하는 구조. Turbo·tach로 경계 강제. |
| ee/ | 엔터프라이즈 디렉토리. MIT 아님, 별도 상용 라이선스. 완전 FOSS는 posthog-foss 미러. |
| hobby deploy | 한 줄 Docker 셀프호스팅. 4GB+ 권장, 월 ~10만 이벤트까지, 지원 없음. |