Logtide: 출시 후 2개월 (실제 수치)
Source: Dev.to
위의 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)
두 달 전, 저는 Logtide(당시 LogWard라 불렸음)를 출시했습니다 – 오픈‑소스이며 프라이버시‑우선의 Datadog 및 Splunk 대안입니다.
📊 숫자 (완전 솔직하게)
GitHub
| 지표 | 값 |
|---|---|
| 스타 | 0 → 223 |
| 이슈 | 27개 접수, 6개 열림 (모두 개선 사항, 치명적 버그 없음) |
| 기여자 | 단독 개발자 + SDK 기여자 1명 (Kotlin) |
사용량
| 지표 | 값 |
|---|---|
| Docker Hub 다운로드 | 3,000+ |
| 활성 배포 | ~500명 사용자 (대부분 자체‑호스팅) |
| 최대 배포 | 500 k logs/day |
| 클라우드 vs. 자체‑호스팅 | 90 % 자체‑호스팅 |
✅ 실제로 효과가 있었던 것
1. 올바른 마케팅 채널
우승자: virtualizationhowto.com – 한 기술 블로거가 Logtide를 발견하고 글을 작성함.
- 결과
- 120+ GitHub 스타 (해당 게시물 하나만으로)
- 트래픽 급증: 2,500 명의 방문자 (24 시간 내)
- 80+ 새로운 자체‑호스팅 배포
교훈: 평판이 좋은 사람의 한 번의 좋은 리뷰 > 소셜 미디어에 10개의 게시물.
준우승: Reddit + Dev.to – r/selfhosted와 Dev.to에 올린 글이 꾸준히 트래픽을 유입함.
- 왜 효과가 있었는가
- 자체‑호스팅 사용자는 프라이버시( GDPR 관점)에 민감함
- Docker‑Compose 배포 (클론 → 실행까지 5 분)
- “벤더 락‑인 없음” 메시지가 공감을 얻음
2. 실제로 사용되는 기능
| Feature | Usage |
|---|---|
| Logs (obviously) | 100 % |
| SIEM Dashboard | 60 % |
| OpenTelemetry traces | 40 % |
놀라운 점: SIEM 사용 비율이 예상보다 훨씬 높음.
이유: 사용자는 로그를 보는 것보다 위협을 탐지하기를 원함.
가장 많이 쓰이는 Sigma 규칙은 보안에 초점이 맞춰져 있지 않음:
- “결제 실패” 알림
- “API 500 오류” 급증
- “데이터베이스 타임아웃” 패턴
교훈: 보안 기능은 판매에 도움이 되지만, 실제로 사람들이 쓰는 것은 비즈니스 모니터링임.
3. 성과를 낸 기술적 결정
TimescaleDB가 올바른 선택이었음.
| Decision | Reason |
|---|---|
| Use TimescaleDB for time‑series compression | ClickHouse보다 간단하면서도 빠름 |
| Compression | 90 % 스토리지 절감 (보통 100 GB → 10 GB) |
| Query speed | 50‑150 ms for 10 M+ logs |
| Operational simplicity | 익숙한 PostgreSQL만 있으면 됨 |
가장 큰 배포 사례 통계
- 500 k 로그/일
- 30일 보관
- DB 크기: 15 GB (압축 후)
- 쿼리 성능: sub‑100 ms
교훈: “충분히 좋은” 성능 + 운영의 단순함 > 최대 속도.
4. 합리적인 커뮤니티 요청
Issue #68 – Substring Search
- 요청: “전체 텍스트 검색으로
spa.bluez5.native안에 있는bluez를 찾을 수 없습니다.” - 초기 생각: “전체 텍스트 검색이면 충분, 와일드카드만 쓰세요.”
- 현실: 현재 검색의 **40 %**가 부분 문자열 모드로 사용됨.
왜?
- 로그에 포함된 UUID(부분 검색)
- 파일 경로(예:
/app/services/auth) - 점(.)이 포함된 서비스 이름
교훈: 사용자는 자신의 워크플로를 개발자보다 더 잘 알고 있다. GitHub 이슈에 귀 기울이자.
❌ What Didn’t Work
1. The Rebrand (Forced, Not Chosen)
| 이벤트 | 날짜 |
|---|---|
| 상표 충돌 발견 | Jan 7 |
| 해결 방안 협상 | Jan 7‑12 |
| LogWard → Logtide 완료 | Jan 12 |
영향
- 모든 SEO 모멘텀 상실 (Google이 “LogWard”를 색인함)
- 기존 링크/북마크 깨짐
- 초기 사용자 혼란 (“잠깐, Logtide가 뭐지?”)
비용: ~40 h 문서, SDK, Docker 이미지 등 이름 변경에 소요
교훈: 무엇이든 이름 짓기 전에 반드시 상표를 확인하라. 끝.
긍정적인 점: “Logtide”가 “LogWard”보다 더 멋지게 들린다.
2. Features Nobody Asked For
OpenTelemetry 메트릭 (아직 구현되지 않음)
- 계획: OTLP 메트릭 지원 (CPU, 메모리, …)
- 현실: 오직 2명의 사용자만 요청함.
왜? 대부분의 사용자는 이미 메트릭에 Prometheus를 사용하고 있다.
결정: 무기한 연기. 로그 + 추적에 집중.
교훈: 사용자가 요청한 것을 만들고, 당신이 필요하다고 생각하는 것을 만들지 말라.
3. Architectural Regrets
Redis가 불필요할 수도 있다.
-
현재 스택
- PostgreSQL + TimescaleDB (로그 저장)
- Redis (BullMQ를 이용한 백그라운드 작업 큐)
-
문제: Redis는 자체 호스팅 사용자에게 운영 복잡성을 추가한다.
-
탐색 중인 대안
- 작업 큐를 위한 PostgreSQL
SKIP LOCKED(“Redis를 PostgreSQL로 교체했다” 기사에서 증명)
- 작업 큐를 위한 PostgreSQL
-
다음 버전 (0.5.0): Redis를 완전히 제거할 수도 있다.
교훈: 모든 의존성은 부채이다. 모든 것을 의문시하라.
😮 예상치 못한 학습
1. 자체 호스팅이 우세
- 예상: 클라우드 vs. 자체 호스팅 50/50
- 실제: 90 % 자체 호스팅
왜?
- 프라이버시 우려 (GDPR)
- 데이터 거주지 요구사항
- 인프라 제어
- SaaS 로깅 플랫폼에 대한 불신
로드맵 영향
- 클라우드 기능보다 Docker‑Compose 개선을 우선시
- 자체 호스팅 문서 개선
- Kubernetes Helm 차트 추가
교훈: 상상 속 사용자가 아니라 실제 사용자를 파악하라.
2. Sigma 규칙이 차별화 요소
- 예상: “보유하면 좋은 보안 기능”
- 실제: “Logtide를 선택한 주요 이유”
사용자 피드백
- “드디어 Splunk 비용 없이 보안 탐지가 가능해졌어요.”
- “Sigma 규칙이 바로 작동합니다.”
- “MITRE ATT&CK 매핑이 놀랍습니다.”
가장 많이 요청된 사항
- 더 많은 사전 구축 Sigma 규칙
- SigmaHQ 통합 (규칙 자동 가져오기)
- 맞춤형 규칙 편집기 UI
교훈: 고유한 차별점을 찾아라. Logtide에게는 **