’‘우리도 Netflix 처럼 *MSA 로 가야 합니다’‘. ’‘우리도 Google 처럼 *Kubernetes 로 *가야 합니다’‘. ’‘우리도 Uber 처럼 *ELK 로 *가야 합니다’‘. 2020 ~ 2025 한국 IT 업계의 *수많은 *기술 임원이 *반복한 *문장들 이다. 그리고 수많은 *팀이 *그 결정 *후 *6 개월 ~ 2 년 동안 *’‘기능을 전혀 추가하지 *못하고 *인프라만 *세팅’’ 하다가 *번아웃 했다.

이 글은 ’‘MSA / Kubernetes / ELK 는 나쁘다’’ 라고 말하지 *않는다. ’‘조건이 맞을 때’’ 는 압도적으로 *옳다. 다만 ’‘조건이 안 맞을 때 *얼마나 *비싸지는가’‘, ’‘그 조건의 손익분기점은 *어디인가’‘, ’‘그 전 단계에서 *어떤 *대안이 *충분한가’’ 를 수치 + 사례 + 권고 로 본다.

대상은 ’‘기술 결정을 내려야 하는 *모든 백엔드 *리더 / 시니어’’ 와 ’‘’‘우리 회사는 이거 도입할 *준비가 *됐을까?’’ 가 진심으로 *궁금한 모든 사람.

1. 오버엔지니어링의 *진짜 정의

1.1 ’‘오버엔지니어링 ≠ 기술이 *복잡’’

흔한 오해: ’‘MSA 쓰면 오버엔지니어링’‘. 틀린 정의.

진짜 정의:

’‘해결하려는 문제의 *비용 *대비 *해법의 *비용이 *훨씬 *큰 상태’‘.

  • ’‘MSA 도입 비용 *= *팀 1 년 *공수 *(예: 10 억)’’
  • ’‘그 결과 *얻는 *이익 *= *연 1 천만 *원 *정도의 *유연성’’
  • ’‘비용 : 이익 *= 100 : 1 → *오버엔지니어링’’

반대로 같은 MSA 가 수십억 *손실을 *막아주면 *옳은 선택.

1.2 손익분기점의 *3 변수

1) 팀 규모     - 작은 팀이 큰 도구를 쓰면 *운영 비용 *압도*
2) 트래픽 규모 - 작은 트래픽엔 *수평 확장 *필요 *없음*
3) 비즈니스 가치 - *느린 *변경이 *얼마나 *돈을 *잃게 *하는가*

이 3 변수 가 모두 *임계치 *넘으면 *베스트 프랙티스 *적용. 하나라도 *못 넘으면 *대안 우선.

2. MSA — *’‘Netflix 의 답이 *우리의 *답인가’’

2.1 MSA 가 *가져오는 *진짜 비용

  • 운영 비용 — 서비스당 CI/CD 파이프라인 + *모니터링 + *알람
  • 인지 비용 — ’‘이 변경이 어떤 서비스에 *영향?’’ 추적이 수배 ↑
  • 인프라 비용 — 서비스 수 × *기본 인스턴스 = *최소 비용 *바닥
  • 개발 속도 — ’‘간단한 기능이 5 개 서비스 *동시 *수정 필요’’
  • 분산 트랜잭션 — Saga / Outbox / Idempotency 의 *복잡성
  • 인력 — DevOps + SRE *전담 *필수

2.2 MSA 의 *손익분기점

조건 임계치 의미
팀 인원 50 명 이상 팀 분리가 *진짜 *필요한 *규모
서비스 수 팀 ≥ 5 개 Conway’s Law 적용 가능
배포 빈도 주 *수십 회 이상 모놀리식이 *진짜 병목
도메인 복잡도 명확한 *bounded context *4 개+ 분리 후도 *결합 *낮음
운영 성숙도 분산 트레이싱 / 중앙 로깅 *기 보유 없으면 *디버깅 *불가능

요약: ’‘팀 50 명 이상 + 명확한 도메인 분리 + 운영 도구 보유’‘* → MSA 진검토. 셋 중 *하나라도 *없으면 *오버엔지니어링 *위험 ↑.

2.3 MSA 의 *흔한 *오버엔지니어링 시나리오

*시나리오 1 — *’‘팀 5 명이 10 개 *마이크로서비스’’

*한 사람당 *2 ~ 3 서비스 *책임*
*PR conflict *수시*
*''*나는 *모든 서비스 *모른다''* 가 *팀 *전체 정서*
*간단한 *기능 추가 → *5 ~ 6 *서비스 동시 *변경*
*결과: *기능 추가 *주 1 회 *수준으로 *침몰*

*시나리오 2 — *’‘도메인 모르고 기술로 *분리’’

[안티 패턴]
  - Java Service (회원)
  - Python Service (추천)
  - Node Service (실시간 알림)

*도메인 *경계 *없음 → *''*추천 = 회원 데이터 + 상품 데이터 + 실시간 이벤트''*
*결국 *3 서비스가 *모두 *서로 *호출
*도메인 변경 *= *3 서비스 *동시 *변경

*시나리오 3 — *’‘분산 트랜잭션 몰랐다’’

*주문 → 결제 → 재고 → 배송* MSA
*그런데 *Outbox / Saga *모름 → *''*결제 *성공 *후 *재고 *실패''* 빈발
*월 *수십 건의 *고객 *환불 *민원
*조직이 *''*MSA 가 *문제''* 가 *아니라 *''*우리가 *MSA 운영 *준비가 *안 됨''* 을 *깨달음*

2.4 MSA 의 *대안 — *모놀리식 → *모듈러 모놀리식

모놀리식

[장점]
- *단순*
- *트랜잭션이 *DB 안에서 *완결*
- *디버깅 *직관적*
- *배포 *간단*

[단점]
- *팀 수 *늘어나면 *충돌
- *큰 변경 *위험
- *기술 스택 *고정*

모듈러 모놀리식 (Modular Monolith)

[하나의 *배포 단위]
  com.lemuel.order/         ← *Module A*
  com.lemuel.payment/       ← *Module B*
  com.lemuel.inventory/     ← *Module C*

[경계 강제]
  - Spring Modulith 또는 *ArchUnit
  - *모듈 *간 통신은 *이벤트 또는 *인터페이스
  - *내부 *DB *스키마 *분리

[장점]
- 모놀리식의 *단순함*
- MSA 의 *경계 명확성*
- *팀 분리 *시점에 *모듈 → 서비스 *추출 가능*

2026 권장 기본값**: **’‘Modular Monolith → *팀이 *진짜 *분리될 때 *서비스로 *추출’‘. ’‘처음부터 MSA’’ 는 Netflix 가 *2008 년부터 *준비한 *규모 의 조직만.

2.5 MSA 회귀 사례 — *’‘큰 회사도 되돌렸다’’

  • Segment (2018) — 140 서비스 → 1 모놀리스
  • Amazon Prime Video (2023) — Lambda+Step Functions → EC2 (비용 90% 절감)
  • Istio (2020) — 4 컴포넌트 → istiod 단일 바이너리

’‘우리도 Netflix 처럼’’* 의 반례. ’‘되돌리는 게 부끄러운 *것이 *아니다’‘.

3. Kubernetes — *’‘Google 의 답이 *우리의 *답인가’’

3.1 K8s 가 *가져오는 *진짜 비용

  • 학습 곡선 — 6 개월 ~ 2 년. Pod / Service / Ingress / ConfigMap / Secret / RBAC / Helm / Operator…
  • 운영 인력 — 최소 *0.5 명 *전담. ’‘Kubernetes Administrator’’* 의 시장 가격
  • *인프라 *오버헤드** — *컨트롤 플레인 *상시 *3 노드 + *kube-system *각종 *Pod
  • *디버깅 *복잡도** — *’‘Pod 가 왜 *Pending?’’ 에 7 가지 *원인
  • *YAML 무한 *증식** — *’‘우리 클러스터의 *YAML 이 *몇 줄?’’

3.2 K8s 의 *손익분기점

조건 임계치 의미
서비스 수 10 개 이상 수동 *관리 *한계
트래픽 변동 주간 *5 배 이상 *피크 자동 *스케일링 *진짜 가치
멀티 환경 dev / staging / prod *분리 운영 환경 일관성 가치
운영 인력 DevOps *0.5 명 이상 *확보 없으면 *Pod 한 번 멈추면 *재기 *불가
컨테이너 표준화 모든 서비스 *Dockerfile 보유 기본 전제

3.3 K8s 의 *흔한 *오버엔지니어링 시나리오

*시나리오 1 — *’‘1 ~ 2 서비스 K8s 운영’’

*Spring Boot *1 개를 *K8s 위에 *올림
*컨트롤 플레인 3 노드 + worker 3 노드 = 인프라 *월 *50 만원
*''*동일 *서비스를 *EC2 *2 대로 *운영하면 *월 *5 만원''*
*K8s 의 *복잡함이 *''*고가용성''* 외에 *0 가치 *제공*

*시나리오 2 — *’‘Dev 환경도 K8s’’

*개발자 *각자 *Minikube *띄움
*''*내 노트북에서 *Postgres 가 *왜 안 *뜨지?''* 가 *주 *2 회 *발생
*Docker Compose 라면 *10 분에 *해결될 *문제를 *반나절 *허비

*시나리오 3 — *’‘Operator 의 늪’’

*Postgres Operator, Kafka Operator, Elastic Operator
*''*Operator 가 *자동화 *해준다*'' 의 *환상
*실제로는 *Operator 자체가 *별도 *학습 부담
*Operator 가 *버그 나면 *내가 *Operator 의 *코드를 *읽어야 함

3.4 K8s 의 *대안

Tier 1 — *’‘아직 컨테이너 단계’’*

[Docker Compose]
  - *한 호스트* 에 *여러 컨테이너*
  - *서비스 < 10 개* 면 *완전 충분*
  - *개발 환경 *최강*
  - *Production 도 *작은 트래픽엔 *가능*

Tier 2 — *’‘Managed Kubernetes / Lite K8s’’

[K3s / k0s]
  - *경량 K8s*
  - *컨트롤 플레인 *1 바이너리*
  - *소규모 / Edge / homelab *최적*

[ECS Fargate / Cloud Run / App Runner]
  - *클라우드 *관리형 *컨테이너*
  - *K8s 없이 *컨테이너 *오케스트레이션*
  - *''*K8s 학습 비용 *없이 *컨테이너 운영''*

Tier 3 — *’‘PaaS / Serverless’’

[Heroku / Vercel / Railway / Fly.io]
  - *Git push = *배포*
  - *''*인프라 *0% *고민''*

[AWS Lambda / Cloud Functions]
  - *Stateless + 짧은 작업*
  - *''*트래픽 0 → 비용 0*''*

3.5 ’‘K8s 도입 결정 흐름도’’*

Q1. 서비스 수 ≥ 10 인가?
  └ No  → Docker Compose 또는 ECS Fargate
  └ Yes → Q2

Q2. DevOps 전담 인력 있는가?
  └ No  → Managed K8s (EKS, GKE, AKS) 또는 K3s
  └ Yes → Q3

Q3. 멀티 클라우드 / 온프레미스 필요한가?
  └ No  → Managed K8s 가 *답*
  └ Yes → 셀프 호스팅 K8s 검토

4. ELK — *’‘Splunk 의 답이 *우리의 *답인가’’

4.1 ELK 가 *가져오는 *진짜 비용

  • Elasticsearch 클러스터 — 최소 3 노드, 메모리 32 GB ↑ 권장
  • Logstash 설정 — ’‘파이프라인 문법 학습’’ + ’‘튜닝 안 하면 성능 *바닥’’
  • 인프라 비용 — ’‘로그 수십 GB/일 → 디스크 + 메모리 *지속 증가’’
  • 운영 인력 — ’‘Elasticsearch 전담 *0.3 명 이상’’
  • *Kibana 사용 *학습** — *’‘개발자 전체에 *KQL 교육’’

4.2 ELK 의 *손익분기점

조건 임계치 의미
로그 *볼륨 5 GB/일 이상 ’‘tail / grep 으로 한계’’
서비스 수 5 개 이상 ’‘로그가 흩어져 있음’’
다인 검색 팀 5 명 이상이 *수시 검색 ’‘Kibana 의 가치 비로소 *발휘’’
보안 / 컴플라이언스 로그 *보존 정책 *법적 요구 ’‘ELK 의 세분화된 권한 가치’’
대시보드 분석 / 모니터링 *대시보드 정기 사용 Grafana 만으로 *부족한 경우

4.3 ELK 의 *흔한 *오버엔지니어링 시나리오

*시나리오 1 — *’‘하루 200 MB 로그를 *ELK 로’’*

*트래픽이 *적어 *로그도 *적음
*그런데 *''*production 은 *ELK 가 *표준''* 으로 *도입*
*ES 클러스터 *3 노드 *상시 가동
*월 *클라우드 비용 *수십 ~ 수백만 원
*tail -f / journalctl 로 *충분했을 *것

*시나리오 2 — *’‘Logstash 안 알고 도입’’

*''*ELK 도입''* 결정 후 *''*Logstash 가 *왜 *느린지 *모르겠음''*
*튜닝 안 한 *Logstash + 큰 grok 패턴 → *CPU 100%*
*로그 *수집이 *실시간 못 *따라 잡음
*결국 *Filebeat → Kafka → ... 으로 *재구조화 *수개월*

*시나리오 3 — *’‘Kibana 안 쓰는 Kibana’’

*Kibana 띄워두지만 *''*아무도 안 들어감''*
*특정 *장애 시에만 *''*어떻게 *쓰는 거지''* 헤맴
*결국 *grep 으로 돌아감
*월 비용은 *계속 *나감

4.4 ELK 의 *대안

Tier 1 — *’‘로그 직접 보기’’*

[journalctl + grep + jq]
  - *단일 노드 *또는 *systemd 운영*
  - *''*5 분 *훈련으로 *대부분의 *조회 *가능''*
  - *비용 *0*

Tier 2 — *’‘경량 로그 집계’’*

[Loki + Grafana]
  - *Grafana Labs 의 *''*log aggregation""*
  - *''*ES 와 *달리 *인덱스 *없음 → *저장 *비용 *수십 분의 1*''*
  - *Promtail 로 *수집 *간단*
  - *''*Kibana 같은 *깊은 분석은 *못 하지만 *로그 검색은 *충분''*

[Vector + Clickhouse]
  - *Vector — *''*경량 로그 *수집 + 변환''*
  - *Clickhouse — *''*컬럼 *기반 *분석 DB *(로그 적합)''*

Tier 3 — *’‘통합 관측 SaaS’’*

[Datadog / New Relic / SigNoz / Honeycomb]
  - *''*직접 *운영 *0%''*
  - *''*로그 + 메트릭 + 트레이스 *통합""*
  - *비용은 *''*GB 당 *과금""*
  - *''*소규모는 *저렴*, 큰 규모는 *ELK 보다 *비쌈""*

4.5 ELK 도입 *결정 *흐름도

Q1. 일 로그 볼륨 ≥ 5 GB?
  └ No  → journalctl / 단순 파일 / Loki
  └ Yes → Q2

Q2. ES 운영 인력 0.3 명+ 있는가?
  └ No  → Managed (Elastic Cloud / OpenSearch Service) 또는 Loki / Datadog
  └ Yes → Q3

Q3. *복잡한 *집계 / 대시보드 *주기적 필요?
  └ No  → Loki + Grafana
  └ Yes → ELK 또는 OpenSearch

5. 3 가지 도구의 *’‘함께’’* 오버엔지니어링

가장 위험한 *패턴:

’‘우리도 현대적이 되자!’’ — MSA + K8s + ELK + Kafka + Istio + Prometheus + Grafana + 다 *한 번에’‘

이게 한국 IT 의 *2018 ~ 2024 *수많은 *기술 *전환에서 *반복된 *’‘거대한 오버엔지니어링’‘.

5.1 함께 도입의 *복합 비용

*개별 학습: *
  - MSA  6 개월
  - K8s  6 개월
  - ELK  3 개월
  - Kafka 3 개월

*동시 도입 시:
  - *학습이 *겹쳐 *서로 *연결됨 ↑
  - *''*이 *오류가 *MSA 때문인가? K8s 때문인가? ELK 때문인가?''*
  - *디버깅이 *''*3 가지 *동시 *알아야 함''* → *전문성 *벽

*예상 기간: *6 개월 → *2 년+*

5.2 현장 *실제 사례 (익명)

[기업 A — 50 명 *팀]
  - 2021 *Spring Cloud + EKS + ELK + Kafka *동시 도입*
  - 2022 *''*개발 속도 *반토막''*. *기능 추가 *불가*
  - 2023 *''*MSA 의 *절반 + EKS 유지 + ELK 폐기 + Kafka 유지''* 로 *축소*
  - 2024 *''*개발 속도 *회복''*

[기업 B — 200 명 *팀]
  - 2020 *EKS 도입
  - 2022 *MSA 도입 (모놀리식 분리)
  - 2024 *ELK 도입 (Loki 에서 *전환)
  - *''*점진적 *도입이 *맞았다''*

인사이트: ’‘한 가지씩 순차적 *도입이 *동시 도입의 *3 배 *효과적’‘.

6. ’‘손익분기점 판단 *체크리스트’’*

6.1 MSA *체크리스트

  • 팀 *50 명 이상
  • 명확한 *bounded context *4 개 이상
  • 각 도메인의 *변경 빈도가 *다름
  • 분산 트레이싱 *운영 중
  • 중앙 *로깅 *구축됨
  • Saga / Outbox *팀에서 *이해함
  • DevOps / SRE *전담 *있음

6 개 이상 → MSA *도입 검토. 5 개 이하 → 모듈러 *모놀리식 우선.

6.2 K8s *체크리스트

  • 서비스 *10 개 이상
  • 컨테이너 *표준화 *완료
  • DevOps *0.5 명 *이상 *확보
  • 트래픽 *변동성 *큼 (5 배 이상)
  • 멀티 환경 (dev/staging/prod) *운영

4 개 이상 → K8s (관리형 우선). 3 개 이하 → Docker Compose / ECS Fargate / Cloud Run.

6.3 ELK *체크리스트

  • 일 로그 *5 GB 이상
  • 5 명 이상 *수시 *로그 *검색
  • 보안 / 컴플라이언스 *로그 *보존 *요구
  • 주간 / 일일 *대시보드 *사용
  • 전담 *0.3 명 *이상

4 개 이상 → ELK 또는 *OpenSearch. 3 개 이하 → Loki + Grafana 또는 *SaaS.

7. ’‘도입의 3 단계 *진화 *경로’’*

7.1 Stage 0 (스타트업, *팀 < 10)

[코드]        Modular Monolith
[배포]        Docker Compose 또는 단일 서버
[로깅]        journalctl + 파일 (필요 시 Loki)
[DB]          PostgreSQL 단일
[메시지]      DB / cron (이벤트 필요 시 PostgreSQL LISTEN)
[관측]        Grafana + Prometheus + Loki

*비용: *월 *5 ~ 50 만원*

7.2 Stage 1 (성장기, *팀 10 ~ 30)

[코드]        Modular Monolith + (1~2 추출 가능 서비스)
[배포]        Managed K8s (ECS Fargate / Cloud Run) 또는 K3s
[로깅]        Loki 또는 Managed (Datadog 검토)
[DB]          PostgreSQL + Read Replica
[메시지]      SQS / Kafka (MSK Serverless)
[관측]        Grafana + Prometheus + Loki + Tempo (트레이싱)

*비용: *월 *100 ~ 500 만원*

7.3 Stage 2 (확장기, *팀 30 ~ 100)

[코드]        모듈러 모놀리식 + 4 ~ 6 서비스
[배포]        Managed K8s (EKS / GKE)
[로깅]        ELK 또는 SigNoz
[DB]          Aurora / RDS Multi-AZ
[메시지]      MSK / Kinesis
[관측]        ELK + Prometheus + Grafana + Tempo + APM

*비용: *월 *수천만 원*

7.4 Stage 3 (대기업, *팀 100+)

[코드]        본격 MSA (수십 서비스)
[배포]        멀티 클러스터 K8s + Service Mesh
[로깅]        ELK + Splunk 또는 자체 데이터 레이크
[DB]          분산 DB (Aurora, Spanner, CockroachDB 등)
[메시지]      Kafka 자체 운영 + Schema Registry
[관측]        ELK + Prometheus + Cortex + Tempo + Datadog + 자체 도구

*비용: *월 *수억 ~ 수십억 원*

7.5 ’‘Stage 건너뛰기’’* 의 함정

[안티 패턴] Stage 0 → Stage 2 *직접 도약

원인:
- *''*우리도 *대기업처럼''* 의 *유혹
- *기술 *리더의 *''*이력서 *주도 *결정""*

결과:
- *팀이 *도구에 *압도됨
- *기능 *개발 *속도 *반토막
- *번아웃 / 퇴사 *증가
- *6 ~ 12 개월 후 *축소 결정 (자존심에 *상처)

원칙: ’‘한 Stage 씩 *진화. *각 단계에서 *6 ~ 12 *개월 *안정화 후 *다음 단계’‘.

8. 대안의 *재발견 — *’‘과소 평가된 기술들’’

8.1 모놀리식의 *재발견

  • Shopify — 매출 수십 조 인데 Rails 모놀리식 (Sorbet + Packwerk)
  • GitHub — Rails 모놀리식 *기반
  • Basecamp / 37signals — ’‘The Majestic Monolith’’* 캠페인*
  • Stack Overflow — ’‘9 서버로 수억 페이지뷰’’

8.2 ’‘싱글 서버’’* 의 재발견

  • ’‘EC2 c7i.4xlarge 1 대 + RDS + Redis’’ 만으로 월 *1 천만 *MAU *서비스 가능
  • ’‘K8s + MSA 없이 *수십 ~ 수백만 사용자’’

8.3 ’‘PostgreSQL 만으로’’* 의 재발견

- 메시지 큐: *PostgreSQL LISTEN / NOTIFY*
- 전문 검색: *PostgreSQL Full-Text Search (FTS)*
- 벡터 검색: *pgvector*
- 시계열: *TimescaleDB*
- 캐시: *PostgreSQL + 인덱스 + (필요 시 Redis)*

’‘PostgreSQL 하나로 *Redis + Kafka + ES + Pinecone 의 *80% *기능 *대체 가능’‘. 작은 규모에선 *압도적 *효율.

8.4 ’‘Hugo / Jekyll / Astro’’* 의 재발견

  • 동적 사이트 *필요 *없으면 *정적 사이트 *생성기
  • ’‘Hosting 비용 *거의 0 (GitHub Pages, Cloudflare Pages)’’
  • ’‘보안 / 운영 고민 *거의 0””

8.5 ’‘SQLite’’* 의 재발견

  • ’‘1 사용자 < 100 동시 *연결’’* 이면 SQLite *충분
  • ’‘단일 파일 = 백업 *간단””
  • ’‘Litestream 으로 S3 *복제””

9. 결정 *언어 — *’‘도입 제안 시 *해야 할 *질문 *5 개’’*

기술 도입 제안이 *나오면 *시니어가 *다음 *5 개 *질문 *던져야 함:

Q1. ’‘해결하려는 문제가 *얼마나 *비싼가’’

  • 현재 *얼마나 *돈을 *잃고 있나
  • 얼마나 *시간 / 인력 *낭비 *중인가
  • 고객 *몇 명이 *불편한가

Q2. ’‘제안된 도구가 그 문제를 *얼마나 *해결하나’’

  • 전부 해결? *부분 *해결?
  • 측정 *지표가 *있는가

Q3. ’‘도입 비용은 *얼마인가’’

  • 학습 *기간
  • 인프라 *비용
  • 팀의 *’‘다른 일 *못 하는 *기회 비용””

Q4. ’‘도입의 대안은 *무엇이 *있는가’’

  • ’‘아무것도 안 함’’
  • ’‘기존 도구 조정””
  • ’‘다른 도구””
  • ’‘이번 도구””*

Q5. ’‘철회 가능 한가’’

  • ’‘도입 후 *’‘이거 아니다’’ 라고 판단 시 *얼마나 *쉽게 *되돌리나””
  • ’‘되돌리는 비용 *예측””

이 5 개 질문에 *명료한 *답이 *있으면 *도입. 없으면 *’‘조금 더 검토”“.

10. 정리 — ’‘과학으로서의 기술 결정’’

10.1 3 가지 *진실

  1. **’‘베스트 프랙티스 ≠ 모두에게 *베스트. *조건이 *맞을 때만 *베스트.’’’*
  2. **’‘도구의 비용은 *학습 / 운영 / 인지 *모두 합치면 *예상의 *3 배.’’’*
  3. **’‘한 단계씩 진화. *Stage 건너뛰기는 *6 ~ 12 *개월 후 *축소.’’’*

10.2 2026 권장 *기본값 *재정의

[모놀리식 → MSA] *팀 *50 명, *4+ bounded context, *운영 도구 *있을 때*
[Docker Compose → K8s] *10+ 서비스, *변동 트래픽, *DevOps *0.5 명*
[Loki → ELK] *5 GB/일+, *팀 검색 *수시, *대시보드 *필수*

10.3 시니어의 *역할

  • ’‘이 도구가 *우리 *현재 *문제를 *푸는가’’ 를 판단
  • ’‘우리 팀의 *준비도’’ 를 솔직히 *평가
  • ’‘임원의 ’‘우리도 Netflix 처럼’‘’’ 을 현실로 *번역””
  • ’‘도입 전 *작은 *PoC 로 *검증””
  • ’‘철회 경로 *항상 *준비””

마지막 한 문장:

’‘베스트 프랙티스 보다 *’‘우리에게 맞는 *프랙티스’’ 가 항상 *옳다. *Netflix 의 *답은 *Netflix 의 *문제에 *맞춰진 *답이고, *우리는 *우리의 *문제에 *우리의 *답을 *찾아야 한다’‘.

기술은 유행이 *있다. ’‘MSA 가 답’‘, ’‘K8s 가 표준’‘, ’‘ELK 가 현대적’’ 이 2018 ~ 2024 의 *유행이었고, *2024 ~ 의 *’‘반대 흐름””* 도 시작 *중. ’‘Modular Monolith’’* 가 재발견 *되고, *’‘PostgreSQL 만으로””* 가 다시 *주목 *받고, *’‘Loki 가 ELK 의 *경량 대안”” 으로 부상 한다. 유행에 *흔들리지 *않고 *’‘우리 문제””* 에 집중하는 *시니어가 *’‘지진 *위에서 *살아남는 *시니어””.

더 읽으면 좋은 자료

  • David Heinemeier Hansson, The Majestic Monolith (Basecamp/37signals 블로그)
  • Alexandra Noonan, Goodbye Microservices (Segment, 2018)
  • Amazon Prime Video Tech Blog, Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% (2023)
  • Kelsey Hightower, ’‘Monoliths are the future’’* (트위터 발언)
  • Shopify Engineering, Deconstructing the Monolith 시리즈
  • Stack Overflow Engineering, The architecture of Stack Overflow (2016)
  • Grafana Labs, Loki vs Elasticsearch 가이드
  • Sam Newman, Monolith to Microservices (2 권으로 MSA 의 *반성)
  • Vlad Khononov, Learning DDD — Bounded Context 의 *현대적 정리
  • Brian Foote, Joseph Yoder, Big Ball of Mud (1999) — 진흙공의 *원전
  • Will Larson, An Elegant Puzzle — 시니어 의사결정의 *원전