Tech Stack: 1년 안에 20배 확장하면서 배운 교훈

Source: Dev.to

1년 전, 나는 우리의 기술 스택에 대해 글을 썼고, 그것이 어떻게 lean 클라우드‑컴퓨팅 스타트업을 운영하는 데 도움이 되었는지 설명했습니다. 그 이후로 우리는 20× 이상 확장했습니다. 이런 성장은 재미있지만, 많은 것들과 가정을 깨뜨려서 빠르게 어려운 선택을 해야 합니다 :‑D

여기서 바뀐 점, 변하지 않은 점, 그리고 그 과정에서 배운 점을 정리했습니다.

변함없는 것들

• Frontend – 여전히 Nuxt와 TypeScript, Tailwind 사용 (RIP @adamwathan).
• Backend – 여전히 Go와 Gin.
• Infrastructure – 여전히 Hetzner 베어‑메탈에 Firecracker를 사용해 가상화.
• IaC – 여전히 Terraform.
• Caching – 여전히 Redis.
• Customer support – 여전히 Crisp.
• Transactional email – 여전히 AWS SES.

고장이 나지 않았다면 고치지 말라.

하지만 많은 것들은 고장이 났거나, 같은 방식으로 운영하기엔 너무 비쌌다.

Source: …

관측성: Axiom → Parseable

이것이 우리에게 가장 큰 운영 변화였습니다. 작년에는 Axiom의 로그 기능을 칭찬했었는데, 무료 티어에서는 정말 좋았지만 규모가 커지면서 문제가 생겼습니다.

트래픽이 증가함에 따라 더 나은 트레이싱과 상세한 로그가 필요해졌습니다. 우리 Axiom 청구서는 €1,000 / 월을 넘어 급격히 상승하기 시작했습니다. 이 시점에서 스스로에게 물어야 합니다: 이게 지속 가능할까? 당연히 그렇지 않죠.

우리는 Parseable 로 마이그레이션했으며, MinIO 를 이용해 S3 호환 스토리지를 제공하는 쿠버네티스 환경에 자체 호스팅했습니다. 모든 것이 베어메탈에서 실행됩니다. 제품은 아직 초기 단계처럼 보이지만, 팀이 빠르게 대응하고 문제가 발생했을 때 신속히 수정해 줍니다. Anant와 Deba에게 큰 감사를 전합니다!

추천할까요? 많은 돈을 시간과 교환할 수 없다면, 네. 자체 호스팅 관측성은 작업이 필요하지만, 우리 “규모”(아직도 작음)에서는 충분히 가치가 있습니다. 우리는 여전히 Grafana 를 사용해 대시보드와 알림을 관리하고 있으며, 이는 변함없습니다(지금은 청구서가 점점 부담이 되고 있습니다).

Object Storage: Backblaze → IONOS / Hetzner

지난 해 우리는 Backblaze를 블롭 스토리지로 사용했습니다. 저렴하고 신뢰성이 높았습니다. 문제는 기술적인 것이 아니라 정치적인 것이었습니다.

우리가 성장하면서, 특히 유럽 기업 고객들이 미국 공급업체에 데이터를 저장하는 것에 대해 반발하기 시작했습니다 (GDPR, 데이터 주권, 내부 정책). 메시지는 명확했습니다: 미국 공급업체 금지! 그래서 모든 미국 공급업체를 교체하려는 우리의 움직임이 Backblaze에서 시작되었습니다.

우리는 객체 스토리지로 IONOS와 Hetzner로 옮겼습니다. 이들이 Backblaze만큼 좋은가요? 전혀 그렇지 않습니다. 하지만 유럽에 기반을 두고 있고, (간신히) 충분히 만족스러우며, 고객 요구사항을 충족합니다. 솔직히 말해서, 사용이 강제되지 않는다면 저는 사용하지 않을 것입니다. 여기서는 선택의 여지가 거의 없는 것 같습니다.

CDN: Cloudflare → Bunny

스토리 자체는 스토리지와 동일합니다. Cloudflare는 우리가 절대 사용하지 않을 기능들을 가진 놀라운 제품이지만, 고객들은 유럽 대안을 원했습니다.

Bunny가 그 요구를 충족합니다. Cloudflare만큼 기능이 완전하지는 않지만, CDN 요구를 완벽히 처리합니다. 빠르고 가격도 합리적이며 유럽에 기반을 두고 있습니다. 매우 간단한 설정 덕분에 마이그레이션은 2 hours도 채 걸리지 않았습니다.

CI/CD: GitHub Actions → Namespace

GitHub Actions는 우리에게 잘 맞았지만 정체되었습니다. Firecracker 관련 테스트를 위해 중첩 가상화와 더 나은 성능이 필요했지만 GitHub에서는 제공되지 않았습니다.

우리는 러너를 위해 Namespace로 전환했습니다. 훌륭한 제품이며, 유럽 기반이라는 점도 여기서 점점 중요한 요소가 되고 있습니다. 성능 향상만으로도 전환할 가치가 있었습니다.

하지만 결국 완전 자체 호스팅 러너로 마이그레이션할 가능성이 높습니다. 규모가 커질수록 더 많은 제어권을 원하기 때문입니다.

데이터 지속성: 가장 큰 문제

이것은 우리에게 가장 중요한 아키텍처 변화였습니다. 작년에는 PostgreSQL과 Timescale을 사용해 수억 개의 분석 행을 포함한 모든 것을 실행한다고 자랑했었습니다. 데이터베이스가 2 TB에 도달할 때까지는 잘 작동했죠.

2 TB가 되면 PostgreSQL 관리가 어려워집니다. 사소한 쿼리 하나가 프로덕션을 다운시킬 수 있고, 확장은 고통스럽고, 데이터베이스 전문가들은 비웃기 시작합니다. (이야기의 나머지는 다음 파트에서 계속됩니다…)

# About Me

2 TB is probably nothing in the grand scheme of things! I am not a Postgres pro, and honestly wasn’t planning on becoming one. Additionally, the cost just started to hurt—especially considering that we want to do another 20× in 2026.

So we built something simpler: hot data lives in **Postgres**, then gets flushed to S3 as **Parquet** files. For queries we use **DuckDB** to read directly from S3. DuckDB is **amazing**.

The results surprised us. P99 latency actually improved. Why? Most queries are “give me the last 5 minutes of metrics” or “show me the last 500 logs.” That’s all hot data sitting in Postgres. Historical queries hit S3, and DuckDB handles Parquet files like a champ. Those are, if not cached, slightly slower.

This architecture saves money, scales better, and plays to our strengths. We understand S3. We don’t understand running a 10 TB Postgres cluster. :D

패턴

• European everything.
  고객 압력이 우리를 EU 공급업체로 이끌었습니다. 이는 기술적인 결정이 아니라, 스타트업과 인디 해커를 넘어 성장할 때 마주하는 비즈니스 현실입니다.

• Self‑host at scale.
  SaaS 제품은 청구서가 일정 금액을 초과할 때까지는 좋습니다. 그때는 여러분의 시간 비용이 그들의 가격보다 저렴한지 계산해야 합니다.

• Simple beats clever.
  우리는 멋진 분산 데이터베이스를 만들지 않았습니다. 데이터를 S3에 플러시하고 DuckDB로 쿼리합니다. 화려하진 않지만 동작합니다! (사실, 단순함 자체가 꽤 매력적이지만, 이력서 중심 개발에는 그다지 좋지 않죠.)

다음은

• 우리는 곧 CI 러너를 자체 호스팅할 가능성이 높습니다.
• 유럽 규정 준수를 고려해 AWS SES의 대안을 검토하고 있습니다.

스택은 계속 진화할 것입니다—대규모 인프라를 구축하는 것이 바로 그런 것이죠. 하지만 핵심 철학은 변하지 않습니다: 단순하게 유지하고, 유지보수가 쉽도록 하며, 문제가 요구할 때만 복잡성을 추가합니다.

2026년 현재 우리는 이렇게 성장했습니다: 규모가 20배로 확대되고, 몇 가지 힘든 교훈을 얻었으며, 스택은 그 어느 때보다 유럽 친화적입니다.

감사합니다,
Jonas