Languages
도메인 모델은 타입으로, 성능은 컴파일러로.
주로 이럴 때 — 도메인 모델은 TS와 Rust로 잡고, 운영과 실험은 Python으로, 서비스 사이는 Go로 잇습니다.
유행을 따라가지 않습니다. 도메인이 요구하는 조건을 먼저 정리하고, 거기에 맞는 도구를 고릅니다. 아래는 지난 5년간 운영해 본 도구들 중 살아남은 것들의 목록입니다.
같은 도구도 도메인이 바뀌면 다르게 씁니다. 아래는 우리가 자주 쓰는 도구들입니다.
도메인 모델은 타입으로, 성능은 컴파일러로.
주로 이럴 때 — 도메인 모델은 TS와 Rust로 잡고, 운영과 실험은 Python으로, 서비스 사이는 Go로 잇습니다.
운영 데이터를 사용자 화면까지 그대로 이어주는 도구.
주로 이럴 때 — 데이터 구조가 자주 바뀌는 화면은 Next.js와 TanStack으로 시작합니다. 디자인 결정은 Tailwind 토큰에 담아 둡니다.
읽기·쓰기 분리, 멱등성, 시간 정렬을 코어에 내장하는 도구.
주로 이럴 때 — 결제·재고·정산처럼 어긋나면 안 되는 도메인은 Postgres + Kafka(Outbox)로 시작하고, 분석은 ClickHouse로 분리합니다.
배포 경로와 운영 지표를 하나로 묶는 도구.
주로 이럴 때 — 배포·롤백·모니터링을 하나의 파이프라인으로 묶습니다. 손으로 만든 인프라는 일주일 안에 Terraform으로 옮깁니다.
모델을 실험에서 운영 흐름으로 옮기는 도구.
주로 이럴 때 — 실험은 자유롭게 하되, 운영에는 추론 SLO와 회귀 테스트를 통과한 모델만 올립니다.
신뢰 계층을 출시 첫날부터 작동시키는 도구.
주로 이럴 때 — 인증과 키 관리는 첫 PR부터 들어갑니다. 감사 로그는 운영 데이터만큼 무겁게 다룹니다.
5년 동안 운영해 본 도구들만 남았습니다. 새 도구가 끌릴 때마다 이 네 가지를 다시 물어봅니다.
GitHub Star 수가 아니라, 새벽 3시에 장애가 나도 디버깅할 수 있는지가 기준입니다. 최신 도구일수록 검증된 사례는 적습니다.
도메인 경계는 타입으로 잡고, 런타임 검증은 외부와 닿는 지점에만 둡니다. PR 리뷰의 절반은 타입 설계 이야기로 채워집니다.
관리형 서비스를 쓰더라도, 6개월 안에 다른 클라우드로 옮길 수 있는 방법을 미리 마련해 둡니다. 새 의존성은 운영 비용을 충분히 따져본 뒤에 들입니다.
같은 도구도 결제 도메인과 콘텐츠 도메인에서는 다르게 씁니다. 도메인이 요구하는 보장 수준을 먼저 정리한 뒤, 거기에 맞는 도구를 가져옵니다.
도구 하나는 그냥 이름이지만, 묶음이 되면 의사결정이 됩니다. 세 도메인에서 자주 자리잡는 조합을 정리했습니다.
지연이 곧 손익이 되는 도메인입니다. 성능이 중요한 경로는 Rust로, 이벤트는 Kafka로, 분석은 ClickHouse로 나눕니다. 관측은 처음부터 OpenTelemetry로 통일합니다.
데이터 구조와 디자인이 자주 바뀌는 화면입니다. Next.js로 빠르게 만들고, Postgres와 Redis로 안정적으로 받칩니다.
OAuth/OIDC, KMS, 감사 로그를 운영 환경에 기본으로 포함합니다. SOC 2와 GDPR은 나중에 덧붙이는 게 아니라 출시일에 맞춥니다.
도구 자체가 결과를 만들진 않지만, 잘 고른 네 개는 도메인 운영을 바꿉니다.
CUDA·Triton 기반 추론을 운영 코드에 통합해, ML 추론 지연을 평균 4–10× 줄였습니다. 비용은 그만큼 늘지 않습니다.
Vercel·Cloudflare Edge로 사용자 가장 가까운 지점에서 인증·라우팅·실험을 처리. 중앙 서버 부하를 분산합니다.
Kafka와 Outbox 패턴으로 이중 기장과 멱등성을 보장합니다. 결제·정산·재고 도메인에서 누락 없이 운영됩니다.
OAuth/OIDC, KMS, 감사 로그를 운영 환경에 기본으로 포함합니다. 컴플라이언스는 나중에 보강하는 게 아니라 출시일에 맞춥니다.
쓸 줄 몰라서가 아니라, 얻는 것보다 운영 부담이 더 큰 경우입니다. 필요해지면 다시 꺼냅니다.
클라이언트가 여러 종류일 때만 쓸 값어치가 있습니다. 프론트엔드가 하나뿐이면 캐싱·권한·N+1 처리 비용이 이득을 다 가져갑니다.
조직 경계가 먼저, 코드 경계는 그다음입니다. 모듈러 모놀리스로 시작해서, 정말로 쪼개야 할 이유가 생겼을 때 쪼갭니다.
결정은 도구가 아니라 우리가 합니다. LLM은 추천·요약·초안까지만 맡기고, 실제 실행은 사람이나 정해진 규칙에 둡니다.
두 클라우드의 공통 부분만 쓰는 코드는 어느 쪽에서도 강하지 않습니다. 한쪽을 제대로 쓰고, 다른 쪽으로 옮겨갈 계획은 문서로만 남겨 둡니다.
먼저 어떤 문제인지부터 듣습니다. 데모와 견적, 일정은 그다음에 정리합니다. 첫 대화는 보통 30–45분이고, 필요하면 NDA부터 작성하고 시작합니다.