천 개의 마이크로서비스에 의한 죽음

• 마이크로서비스를 기본값처럼 도입하는 문화는 실제 규모 문제가 아니라 없는 문제를 풀기 위해 비용과 복잡도를 키워 왔다는 비판임
• JavaScript/Node.js 생태계의 폐쇄성, FAANG식 관행, 풍부한 벤처 자금이 맞물리며 스타트업도 web-scale 아키텍처를 흉내 내는 분위기가 생김
• Docker와 Kubernetes가 있어도 개발, 디버깅, 배포, 테스트, 회복력 확보 같은 분산 시스템의 난점은 사라지지 않음
• Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, WhatsApp 등은 모놀리식 코드베이스로 시작했거나 지금도 핵심에 모놀리스를 두고 있음
• 대부분의 회사는 진짜 분산 시스템이 필요한 규모에 도달하지 않으므로, 명확히 분리·확장해야 하는 부하가 있을 때만 서비스로 떼어내는 편이 현실적임

---

복잡도를 숭배하는 문화

• 사용자 생일 하나를 얻기 위해 복잡한 마이크로서비스 미로를 설명하다 실패하는 풍자는 현재 기술 문화의 과잉 설계를 겨냥함
• 당면 과제를 푸는 대신 없는 문제를 해결하느라 돈을 태우는 쪽으로 목표가 바뀐 것이 문제임
• JavaScript와 Node.js 비판은 특정 기술만의 문제가 아니라, 이미 배운 교훈을 다시 배우게 만드는 폐쇄적 소프트웨어 생태계의 위험과 연결됨
• 업계는 과거에도 CORBA와 SOAP 같은 복잡도 벽에 부딪힌 뒤 방향을 되돌린 경험이 있음

마이크로서비스 유행을 만든 조건

• 브라우저용 JavaScript를 쓰던 개발자들이 “full-stack”을 자처하며 서버 개발과 비동기 코드로 들어왔고, 초기 Node는 개인의 학습 프로젝트에 가까웠으며 초기 JavaScript는 서버 개발에 문제가 많은 선택지였음
• Node 바깥 세계가 사실상 없는 것처럼 받아들여지면서, Node 방식만이 유일한 방식이라는 독단적 사고가 생김
• 이후 FAANG 출신 인력들이 스타트업으로 들어와 “Google에서 하던 방식”을 맥락과 규모에 상관없이 정답처럼 전파함
  • 별도 User Preferences Service가 없으면 확장되지 않는다는 식의 압박이 대표적 예시임
• 벤처 자금이 풍부하던 시기에는 매출보다 투자자에게 폭발적 성장을 보여주는 일이 중요해졌고, 회사는 비싼 소프트웨어 엔지니어를 빠르게 채용해 “무언가”를 하게 만들었음

분산 시스템은 여전히 어렵다

• 마이크로서비스는 “확장 가능한 소프트웨어를 쓰는 새 방식”처럼 포장됐지만, 본질적으로 오래전부터 존재한 분산 시스템 문제와 맞닿아 있음
• 과거의 분산 시스템은 어렵고 위험한 도구로 여겨졌고, 특히 까다로운 문제를 위한 마지막 수단에 가까웠음
• 분산 시스템에서는 다음 작업이 모두 더 어렵고 오래 걸림
  • 개발
  • 디버깅
  • 배포
  • 테스트
  • 회복력 확보
• 마이크로서비스 기반 개발에는 표준 도구나 공통 프레임워크가 없으며, 2020년대에도 분산 시스템 작업은 조금 쉬워졌을 뿐임
• Docker와 Kubernetes는 분산 설정의 본질적 복잡도를 마법처럼 제거하지 못함

단순함이 더 좋은 결과를 낸 사례

• 5년간의 스타트업 코드 감사 요약은 잘된 스타트업일수록 거의 뻔뻔할 정도로 Keep It Simple 접근을 취했다고 정리함
• 조기 마이크로서비스 전환, 분산 컴퓨팅에 의존한 아키텍처, 메시징 중심 설계는 여러 회사를 곤란하게 만든 주요 함정이었음
• 많은 스타트업은 단순하고 성능 좋은 시스템을 만들면서도 “첫날부터 마이크로서비스를 하지 않는다”는 데 가짜 열등감을 느낌
  • “몇 명의 엔지니어가 유지하는 Django 모놀리스와 MySQL 인스턴스뿐인데 무엇이 잘못됐나”라는 질문의 답은 거의 항상 “잘못된 것이 없다”임
• 경험 많은 엔지니어도 오늘날의 기술 문화에서 부적절함을 느끼지만, 실제 문제는 부당한 과신과 낭비, Dunning-Kruger가 섞인 환경일 수 있음

모놀리스로도 성장한 회사들

• 모놀리스 없이는 성장할 수 없다는 생각은 신화에 가까움
• Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow 등은 모놀리식 코드베이스로 시작했으며, 일부는 지금도 핵심에 모놀리스를 유지함
• StackOverflow는 대형 사이트를 적은 하드웨어로 운영하는 점을 성능 페이지에서 자랑거리로 삼음
• Shopify는 여전히 Rails 모놀리스를 사용하며, 검증된 Resque로 수십억 개 작업을 처리함
• WhatsApp은 Erlang 모놀리스와 약 50명의 엔지니어로 크게 성장함
  • 엔지니어링 조직을 약 50명으로 작게 유지함
  • 개별 팀은 1~3명 규모이며 높은 자율성을 가짐
  • 서버는 적은 수를 선호하고 각 서버를 가능한 한 수직 확장함
• Instagram은 12명 규모 팀으로 수십억 달러에 인수됐고, Threads도 Instagram 모델을 따름

없는 문제를 풀지 말아야 함

• 핵심 질문은 “어떤 문제를 해결하는가”임
• 규모가 문제라면 무엇을 왜 별도 서비스로 나눠야 하는지 보여주는 데이터가 필요함
• 분산 시스템은 규모와 회복력을 위해 만들어지지만, 서비스 하나가 느려지거나 죽었을 때 다른 서비스로 트래픽이 몰리는 상황까지 고려해야 함
• 필요한 고려 요소는 시스템의 사용 패턴과 부하 특성에 따라 달라짐
  • 백프레셔
  • 서킷 브레이커
  • 큐
  • 지터
  • 모든 엔드포인트의 합리적 타임아웃
  • 작은 변경이 전체 장애를 만들지 않도록 하는 보호 장치
• 대부분의 회사는 진짜 분산 시스템이 필요한 거대한 규모에 도달하지 않음
• Amazon과 Google의 규모, 전문성, 자원을 갖추지 않은 채 그 방식을 흉내 내면 시간과 돈을 낭비하기 쉬움
• 나쁜 분산 시스템은 분산 시스템 자체보다 더 어렵다는 경고가 남음

팀별 서비스와 API라는 이상과 현실

• 회사 구조에 분산 토폴로지를 맞추려는 시도는 문제를 작은 조각으로 나누면 쉬워진다는 생각에서 출발함
• 이상적인 마이크로서비스는 전담 팀이 엄격히 유지하고, 아름답고 하위 호환되는 버전 API 뒤에 숨으며, 다른 팀과 거의 소통하지 않아도 되는 형태임
• 현실에서는 Slack 채널이 릴리스, 버그, 설정 변경, 깨지는 변경, 공지로 넘쳐남
• 모두가 항상 모든 상황을 파악해야 하며, 이미 바쁜 팀이 여러 마이크로서비스를 어설프게 맡는 일이 흔함
• 사람의 이동에 따라 서비스 소유권도 바뀌며, 하나의 좋은 경주차 대신 여러 대의 형편없는 골프 카트를 만드는 상황이 됨

마이크로서비스가 잃게 만드는 것들

• DRY의 약화

  • 마이크로서비스는 기본적으로 DRY하지 않으며, 각 서비스에 중복 보일러플레이트가 들어감
  • 작은 마이크로서비스에서는 배관 코드의 비중이 커져 평균 서비스 인스턴스가 제품 코드보다 “서비스” 코드에 가까워질 수 있음
  • 공통 코드를 빼내려 해도 선택지는 모두 고통을 동반함
    • 공통 라이브러리를 만들면 버전과 업데이트 전략을 정해야 함
    • 모든 저장소에 정기적으로 pull request를 만들어 강제 업데이트할 수 있음
    • 모노레포로 묶으면 그 자체의 문제가 생김
    • 일부 코드 중복을 허용하거나, 팀마다 매번 바퀴를 다시 만들게 됨

• 개발자 경험의 악화

  • 개발자 경험은 새 기능 개발이나 버그 수정에 필요한 마찰과 노력의 크기임
  • 마이크로서비스 환경에서는 특정 작업에 어떤 서비스를 띄워야 하는지, 어떤 팀과 누구에게 무엇을 물어야 하는지 알기 위해 전체 시스템의 정신 지도가 필요함
  • Spotify는 수많은 시스템과 서비스를 목록화하기 위해 Backstage를 만들었고, 이는 이 게임의 비용이 높다는 단서가 됨
  • Spotify가 아닌 회사들은 자체 솔루션을 임시방편으로 만들게 되며, 견고성과 이식성을 기대하기 어려움
  • 새 서비스를 시작하려면 자동화해야 할 항목도 많음
    • GitHub/GitLab 개발자 권한
    • 기본 환경 변수와 설정
    • CI/CD
    • 코드 품질 검사
    • 코드 리뷰 설정
    • 브랜치 규칙과 보호
    • 모니터링과 관측성
    • 테스트 하네스
    • 코드형 인프라
  • 여러 프로그래밍 언어를 쓰면 이 목록은 언어 수만큼 늘어남
  • 이런 자동화를 다듬는 데는 몇 달이 걸릴 수 있으며, 제품을 만들지 도구를 만들지 선택해야 하는 상황이 됨

• 통합 테스트의 어려움

  • 단일 서비스 테스트와 단위 테스트가 통과해도 각 커밋 뒤 핵심 경로가 여전히 유지되는지는 별개 문제임
  • 분산 설정의 통합 테스트는 거의 불가능에 가까운 문제로 다뤄지며, 그 자리를 관측성이 대체하게 됐다고 봄
  • 관측성은 새로운 산업 영역이 되었고, 비용뿐 아니라 개발자 시간도 요구함
  • 관측성은 플러그인처럼 바로 작동하지 않으며, 카나리 릴리스와 기능 플래그 등을 이해하고 구현해야 함
  • 문제를 쪼갠다고 해결이 쉬워지는 것이 아니라, 더 어려운 문제 묶음을 얻게 됨

모놀리스가 자동으로 좋은 코드는 아니다

• 모놀리스 옹호가 “모놀리스는 좋은 코드이고 마이크로서비스는 나쁜 코드”라는 뜻은 아님
• 현실에는 성급한 팀이나 평범한 팀이 만든 평범한 모놀리스가 많음
• 다만 분산 시스템은 대충 넘어간 부분, 나쁜 결정, 놓친 실패 모드에 훨씬 가혹함
• 항상 높은 수준으로 운영하지 않으면 분산 시스템에서는 대가를 치르게 됨

마이크로가 아니라 그냥 서비스면 충분할 수 있음

• 서비스가 꼭 “micro”일 필요는 없으며, 그냥 서비스로 충분한 경우가 있음
• 일부 스타트업은 함수마다 서비스를 만드는 수준까지 갔고, 검증되지 않은 카고 컬트가 얼마나 멀리 갈 수 있는지 보여줌
• 모놀리스로 시작하는 것은 명확한 선택지임
• “trunk & branches” 패턴도 여러 경우에 맞을 수 있음
  • 핵심 기능은 “고기와 감자” 같은 메인 모놀리스가 담당함
  • 명확히 식별 가능하고 별도 확장이 필요한 부하는 branch 서비스가 맡음
• CPU를 많이 쓰는 Image-Resizing Service는 User Registration Service보다 별도 서비스로 더 말이 됨
• 초당 등록 수가 독립 수평 확장을 요구할 정도로 많은지 묻는 질문이 서비스 분리 판단 기준이 됨

유행의 후퇴와 현실적 선택

• 마이크로서비스 과열은 식어가는 것으로 보이며, 벤처 자금 흐름이 조여지면서 기업들이 더 상식적인 결정을 하도록 시장에서 조정되고 있음
• web-scale 문제가 없는데 web-scale 아키텍처에 돈을 쓰는 방식은 지속 가능하지 않음
• 뉴욕에서 필라델피아로 가야 한다면 복잡한 우주선을 만들기보다 90분짜리 Amtrak 기차표를 사는 편이 문제에 맞는 해법임

[GN⁺]

Hacker News 의견들

• 나는 마이크로서비스를 강하게 옹호해 온 사람 중 하나고, Netflix 플랫폼 구축을 도왔으며 전 세계를 다니며 장점을 설파해 왔지만, 스타트업에 조언할 때는 거의 항상 모놀리스로 시작하라고 말함
  코드베이스와 데이터베이스를 하나로 두는 편이 훨씬 쉽고, 꽤 오래 확장 가능함. DynamoDB 같은 키/값 저장소를 쓰면 관계형 기능 일부를 잃긴 하지만 더 버틸 수 있음
  모놀리스도 Lambda에 배포할 수 있고, 서비스를 쪼개지 않아도 Lambda의 장점을 얻을 수 있음
  성장한 뒤에야 독립적으로 확장해야 하거나 별도 배포가 필요한 부분을 자체 데이터 저장소를 가진 마이크로서비스로 떼어내면 됨
  마이크로서비스는 플랫폼 유지에만 엔지니어링 시간의 최소 25% 를 잡아먹으므로, 그만큼의 효율을 회수할 수 없으면 가치가 없음

  • “꽤 오래”라는 표현은 과소평가임. SQL을 어느 정도 다룰 줄 아는 사람이 있으면, 그냥 Postgres를 큰 DB 서버에 올리는 것만으로도 진짜 DBA를 뽑을 생각을 하기 전까지 5천만 행짜리 테이블까지 갈 수 있음
  • 그 시점에는 마이크로서비스로 쪼개기보다 모놀리스를 컴포넌트로 리팩터링하고, 추적을 통해 실제 성능 지표를 봐야 함
    성장 중일 때는, 아니 대부분의 경우에는 아예 마이크로서비스를 하지 않는 편이 낫다
    그리고 제발 데이터를 쪼개지 말아야 함. 데이터는 코드보다 관리가 훨씬 복잡함
  • 아주 단순한 진리로 귀결됨. 가능한 한 단순하게, 필요한 만큼만 복잡하게 만들라는 것임
    지금보다 더 복잡하게 만드는 건 언제든 가능함. 모놀리스에서 일부를 떼어 서비스로 만들 수도 있고, 물론 어렵긴 하지만 이미 들어간 복잡성을 시스템에서 빼내는 것과는 비교가 안 됨
    여러 마이크로서비스를 다시 모놀리스로 되돌려 본 사람은 알겠지만, 보통은 처음부터 다시 만드는 것과 비슷한 작업량이 됨
  • 많은 사업은 애초에 확장 자체가 필요 없음. Netflix는 고객 수가 많고 고객당 매출이 낮은 유형이지만, 고객 수는 적고 고객당 매출이 높은 사업도 많고 어쩌면 더 많음
    이런 제품은 원한다면 정말로 노트북에서 운영 환경을 돌릴 수도 있음
    이전 직장에서는 고객 300명을 위해 마이크로서비스 잔치를 벌였음. 수천 명만 되어도 성공이고 수만 명이면 대성공인 사업이었는데도 그랬음
    보통은 플랫폼 유지에 엔지니어링 시간 25%를 쓰지 않기 때문에, 로컬에서 실행도 불가능하고 운영 환경은 덕트테이프로 겨우 붙어 있는 상태가 됨
    최근 면접에서 “동시 접속자 5억 명” 시스템을 설계하라는 질문을 받았는데, 그 회사는 대체로 고객 수가 적고 고객당 매출이 높은 유형이었음
    5억은 전 세계 인터넷 연결 인구의 약 10%라 말도 안 되는 숫자라는 걸 짚어내는 시험이었는지, 스타트업이 실제로 그렇게 될 수 있다고 믿은 건지 아직도 모르겠음
    나는 가장 단순한 것, 즉 모놀리스를 만들고 기능과 사람들이 원하는 제품인지 확인하는 데 집중하겠다고 답했고 채용되지 않았음
  • Netflix, Amazon, Reddit 규모가 되기 전에는 개인적으로 마이크로서비스를 권하지 않겠음. 그 정도 규모에서도 내부에 그 수준의 전문성이 있어야 하고, 아니면 악몽이 됨

• 기여자가 약 800명인 거대한 모놀리스에서 일하고 있는데, 사용자 생일 같은 단순한 필드를 추가하는 일도 똑같이 복잡함. 다만 복잡성이 전부 기술적인 것은 아니고, 모두의 코드를 건드리기 때문에 “조직적 정렬”이 필요함
  설계와 리뷰가 끝없이 반복되고, 최소 2명의 아키텍트 승인이 필요하며, 여러 계획 주기에 추가됨. 실제 코드는 반나절도 안 걸림
  코드 리뷰에서 90% 테스트 커버리지를 맞춰야 하지만 테스트가 너무 많아 PR 하나로는 커서 여러 PR로 쪼개고 여러 주간 릴리스에 걸쳐 들어가게 됨
  그래서 기능 플래그 뒤에 숨기는데, 현재 기능 플래그가 13,000개 있음
  운영에 들어가고 대시보드와 모니터링이 붙으면 켰다 껐다를 반복함. 생일 기능이 왜 과금 서비스를 망가뜨렸는지 확신이 없지만 원인으로 보이므로 몇 주 분석해야 함
  결국 1년 뒤 그 일을 맡은 엔지니어는 좋은 평가를 받고 승진 후보가 될 수도 있음. 그리고 곧바로 개발 3년 차에 들어선 또 다른 망가진 프로젝트, 사용자가 시간대를 설정할 수 있게 하는 일에 투입됨

  • 핵심은 마이크로서비스냐 모놀리스냐가 아니라 글에서 말한 복잡성 교단의 사도들에 가까움
    마이크로서비스도 모놀리스도 만능 망치나 은탄환이 아니고, 반대로 악 그 자체도 아님. 둘 다 트레이드오프가 있는 도구이고, 조직마다 다른 맥락의 트레이드오프와 결합됨
    문제는 엔지니어가 복잡성에 매혹되고 “단순함”을 “임시방편”과 혼동하는 것, 그리고 조직이 도구와 아키텍처 패턴을 맹목적으로 흉내 내는 것임
    아키텍처나 디자인 패턴을 쓰기만 하면 이점이 생긴다고 믿고 순진하게 적용해도 그런 일은 일어나지 않음
  • 거대한 모노레포를 옹호하는 사람들은 Google이 그 단일 코드베이스를 리팩터링하고 테스트하기 위한 도구만 만드는 팀들을 따로 갖고 있다는 점을 종종 잊음
  • 어떤 기술 스택 패러다임을 써도 망칠 회사처럼 들림
  • 이 회사는 코드 변경을 빠르게 출시해야 하는 경쟁 압력이 없어 보임. 하지만 도전자가 나타나거나 해자가 사라지면 문제가 될 것임
    소프트웨어 엔지니어링은 복잡성과 끝없이 싸우는 일이라는 점을 마음에 새기려 했고, 성공한 때도 실패한 때도 있음
    이 싸움은 항상 해야 하고 최우선 가치여야 함. 그렇지 않으면 이런 일이 벌어짐
    이 전쟁을 끝내 주는 아키텍처나 이념은 없고, 그냥 이 직업의 본질임
  • 기능 플래그 13,000개는 미친 수준임. 이전 직장에서 명시적으로 일부 고객에게만 켜고 끌 필요가 없는 새 기능에는 “릴리스” 플래그를 쓰자고 고집했던 게 다행임
    운영 환경에서는 이런 릴리스 플래그를 켤 수 없게 했고, 개발자는 최종 테스트와 릴리스 전에 플래그 코드를 제거해야 했음
    플래그가 필요한 기능마다 약간의 일이 더 생기지만, 몇 달만 지나도 코드베이스 복잡성이 줄어드는 효과가 크게 돌아옴

• 마이크로서비스는 기술 문제가 아니라 사회적 문제에 대한 해법임
  N명의 엔지니어가 있는 팀은 N²의 조율이 필요함. 큰 팀은 끝없는 회의, 이메일, 설계 리뷰에 빠지고, 작은 팀은 더 효과적이지만 큰 시스템 유지에 어려움을 겪음
  시스템을 하위 시스템으로 나누면 각 팀이 자기 퍼즐 조각에 집중하면서 사람 간 조율을 줄일 수 있음
  마이크로서비스가 복잡성과 오버헤드를 추가하는 건 맞지만, 이 접근은 큰 조직이 큰 시스템을 빠르게 만들고 반복 개선할 수 있게 해 줌

  • 실제로는 그렇게 되지 않음. 시스템을 하위 시스템으로 나누면 기존 연결이 하위 시스템 사이의 새 연결로 매핑될 뿐, 근본 문제를 풀기 위한 연결은 여전히 필요함
    이제 직접 연결하는 대신 팀 간 “교차 기능” 회의와 복잡한 통신 계층이 필요해짐
    만약 하위 시스템 간 연결이 거의 필요 없는 분해를 찾았다면, 원래 시스템에서도 그 연결은 존재하지 않았을 것이고 N² 문제도 없었을 것임
  • 이론적으로는 동의하지만, 실제로 마이크로서비스 중심으로 팀이 그렇게 조직된 걸 본 적이 없음
    반복해서 본 건 “모두가 모든 마이크로서비스에 책임진다”는 하나의 거대한 팀이고, 결국 아무도 아무것도 책임지지 않게 됨
  • 사람들은 코드베이스에 별도 디렉터리를 만들 수 있다는 걸 잊는 듯함
    “사람 문제”를 해결하겠다며 사소한 기술 문제를 복잡한 분산 시스템 문제로 바꿈
    이제 진짜 문제가 생김
  • 작은 팀이 큰 시스템 유지에 어려움을 겪는다는 말도 솔직히 확신이 안 듦. 좋은 엔지니어 7명으로 웹 UI와 두꺼운 클라이언트가 모두 있는 350만 줄짜리 프로젝트를 유지한 적이 있음
    두 종류의 데이터베이스를 지원했고, 수평 확장 가능한 작업 실행기도 있었음
    한때 35명이었지만 해고로 7명까지 줄었고, 그때 오히려 훨씬 더 많은 일을 해내기 시작함. 모두를 맞추는 데 쓰는 시간이 크게 줄었기 때문임
    회의, 승인, 리뷰, 계획, 회고, 관리 회의가 훨씬 줄었고, 개발자들의 재량이 커져서 그냥 일을 끝냈음
    기능은 절반의 시간으로 쉽게 처리했고, 나머지 50%를 기술 부채 상환에 썼음. 복잡성을 가차 없이 줄였기 때문에 새 기능 추가 속도도 빨라짐
    어떤 프로젝트는 더 많은 인원이 필요하겠지만, 일정 시간 안에 시스템에 추가할 수 있는 복잡성에는 상한이 있다고 봄
    임계치를 넘겨 개발자를 늘리면 주당 기능 수는 그대로인데 모두가 조금 덜 일하고 소통에 더 많은 시간을 쓰게 됨
    이 과정을 수천 명까지 반복하면 필드 하나 추가하는 데 몇 달이 걸림
  • 왜 꼭 서비스로 쪼개야 함?
    서로 다른 폴더로 옮기는 방법은 생각해 봤는지 궁금함
    새 저장소, 새 Docker 설정까지 갖춰 모듈화할 필요가 없음. 그냥 폴더를 쓰면 됨

• 흔히 본 패턴은 이렇다. 현재 CTO나 VP들이 원래 모놀리스를 만들었거나 만드는 데 참여했음
  아무도 CTO에게 그 코드가 형편없다고 말하고 싶어 하지 않음. 혹은 시대가 달라져 전면 개편이 필요한 코드일 뿐 모놀리스라는 사실과는 무관함
  CTO는 마케팅이나 투자 유치로 바빠 마이크로서비스냐 모놀리스냐를 결정하지 못하고, 새로 뽑힌 아키텍트가 결정을 내림
  모두가 마이크로서비스에 환호함. 빠르게 성장하는 진지한 기술 회사라는 서사에 잘 맞고, 아무도 혼자 반대하거나 CTO를 비판하고 싶어 하지 않기 때문임
  진심으로 마이크로서비스가 최선의 트레이드오프라서 권하는 경우는 거의 없음. 자기 일을 좋아하고, 사람을 더 뽑는 걸 좋아하고, 회사의 서사에 잘 맞기 때문임
  대대적 개편 중에 많은 코드를 다시 쓰고 개선할 수 있는데, 그걸 그냥 마이크로서비스 이전이라고 부르면 됨
  결국 CTO의 감정을 다치게 하지 않고, 군중을 따라가며, 거의 모두가 지지하는 명분으로 오래된 나쁜 코드를 대량으로 다시 쓰는 방식이 됨

  • CTO의 코드가 형편없다고 말하고 싶어 하지 않는 건 패턴이 아니라 사실상 피할 수 없는 일임
    개인 리드 엔지니어든 CTO/창업자든 결국 뒤돌아보면 더 잘할 수 있었다고 결론 내리게 되고, 팀이 성실히 따라온 패턴과 프로세스의 이득과 단점을 기쁨과 공포 속에서 보게 됨
  • 방금 묘사가 StumbleUpon의 지난 5년을 그대로 설명함

• 내 편향을 확인해 주는 글이라 더 좋음
  몇 년째 말해 왔지만, 마이크로서비스 광풍은 평범한 엔지니어들이 수요를 유지하기 위한 핑계에 가깝다고 봄. 평범함이 이를 부추기고, 동시에 많은 기술 회사를 계속 굴러가게 함
  UNIX를 제대로 다루고 StackOverflow 같은 아름다운 미니멀 시스템을 만들 수 있는 유능한 엔지니어는 충분하지 않음
  그래서 평범함을 가리는 연막으로서의 마이크로서비스는 계속 남을 것임. AWS 같은 클라우드 제공자들이 가능한 모든 채널로 자신을 홍보하고 의사결정자들이 그 길을 택하게 만들기 때문에 더더욱 그렇다

  • 안전한 모놀리스식 시스템을 유지하자고 권하는 아키텍트를 아무도 뽑거나 듣지 않는 이유를 모르겠음
    클라우드, 마이크로서비스, 검증 안 된 최신 프레임워크를 말하지 않으면 시대에 뒤처진 늙은이 취급을 받음
    그런 시스템이 가장 효율적이거나 강력하거나 안전한 경우는 드문데도 그렇다
    지금 회사는 다른 기업 내부에서 쓰는 소프트웨어를 만드는데, 동시 사용자가 많아야 200명이고 사용량 급증도 없음
    평범한 웹 서버에 완벽한 환경이고 예기치 못한 확장 문제도 없을 텐데 모두가 클라우드로 가고 싶어 함
    이유는 경영진, 프로그래머, 심지어 고객까지 클라우드 마케팅에 설득되어 클라우드가 멋지다고 믿기 때문이라고 봄
  • 잘못된 이유, 예를 들어 이력서에 좋아 보인다는 이유로 마이크로서비스에 열광하는 개발자들이 분명히 있지만, 더 큰 문제는 회사가 복잡성을 다루는 방식임
    회사는 조직도만 내보내는 게 아니라 모든 역기능과 역사적 짐까지 제품에 실어 보냄
    5년 전에는 효율적이고 잘 설계된 데이터 모델과 API, 잘 작성되고 테스트된 코드가 있는 아름다운 플랫폼이었어도, CEO의 계속되는 방향 전환, 영업팀이 밀어붙인 막판 고객 요청, 필요하지도 요청받지도 않은 기능을 추가하는 제품 관리자들, 부족한 인력과 시간 때문에 5년 뒤에는 완전히 엉망이 될 수 있음
    어느 날 거대한 기술 부채 더미 앞에서 버그 수정과 기능 추가가 필요 이상으로 오래 걸리는 상황을 마주하게 되고, 마이크로서비스는 모든 걸 불태우고 처음부터 다시 시작하지 않아도 된다고 속삭이는 세이렌의 노래처럼 들림
  • StackOverflow는 UNIX가 아니라 Windows 위에 만들어졌음
    꼬투리 잡기처럼 보일 수 있지만 더 큰 요점이 있음. 기술 선택이 병목인 경우는 드묾
  • 내 경험상 평범한 엔지니어도 Ruby on Rails 같은 의견이 강한 프레임워크를 쓰면 괜찮은 모놀리스를 만들 수 있음
    반대로 마이크로서비스는 움직이는 부품과 실패 모드가 더 많아 훨씬 복잡하므로, 평범한 엔지니어는 물론 평범하지 않은 많은 엔지니어도 문제를 만들 가능성이 훨씬 큼
  • 평범한 엔지니어라기보다 이력서를 채우고 싶은 경험 부족한 엔지니어일 수도 있음
    이 일을 할 때 무엇이 중요한지 현재 세대에게 제대로 가르치는 데 실패한 것 같음

• 작은 팀에서 마이크로서비스로 옮기는 중이라 공감함. 가장 큰 문제는 관측 가능성임
  운영에서 문제가 생겼을 때 정확히 무엇이 잘못됐는지 알아내는 일이 엄청난 잡일이 됨
  분산 애플리케이션 하나의 로그를 따라가는 정도로는 부족하고, 서로 메시지가 뒤섞인 여러 분산 애플리케이션의 로그를 동시에 봐야 함
  추적을 시각화하는 도구가 생기면 괜찮겠지만, 작은 팀이라 사람의 대역폭이 제한되어 있고 아직 그런 도구가 없음
  반대로 모놀리스에는 몇 년 전부터 NewRelic이 통합되어 있었음. 성능 문제는 있었지만 대부분 인덱스와 몇 개의 구체화 뷰로 해결됐음
  무엇이 잘못됐는지 파악하기가 쉽고, 코드가 오래되고 경쟁 조건이 가득해도 문제 해결 자체는 어렵지 않음
  각 마이크로서비스마다 별도 데이터베이스 인스턴스를 두고 나중에 업그레이드해야 할 때가 두려움. 하나의 데이터베이스 인스턴스에 여러 데이터베이스를 두길 바랐지만 그 아키텍처는 선택지에 없음

  • OTEL(OpenTelemetry) 도구와 라이브러리, 또는 Prometheus, Tempo, Loki가 있는 Grafana 스택을 살펴볼 만함
    중앙 집중식 로깅과 서비스 호출/코드 실행 추적은 새롭지 않음. 다만 종종 나중 일로 밀리다가 이런 불쾌한 상황에 빠짐
    처음부터 올바른 도구를 넣지 않았기 때문에 팀은 더 작고 더 제한된 상태가 됨. 서비스들이 무엇을 하는지 거의 또는 전혀 모르기 때문임
    데이터베이스 인스턴스는 하나씩 업그레이드하면 됨. 보안 등 심각한 버그가 있는 게 아니라면 단지 업그레이드가 가능하다는 이유만으로 서두를 필요는 없음
  • 클라우드를 안 쓰는지 궁금함. 클라우드 제공자는 중앙 집중식 로깅을 제공하므로, 서비스 사이에 요청 ID를 넘기고 로그 항목에 그 ID를 넣으면 서비스 간 요청을 추적할 수 있음

• 이런 글을 읽으면 묘하게 치료받는 느낌이 듦. 10년 전에도 같은 말을 크게 외쳤지만 불신자 취급을 받으며 조용히 하라는 말을 들었기 때문임
  “마이크로서비스” 패러다임이 입맛을 쓰게 남긴 건 양해 바람. 최신 유행 기술의 트레이드오프를 완전히 이해하지 않고 전면 수용했을 때 어떤 결과가 생기는지 실제로 겪었음
  오래전 StumbleUpon에 채용됐을 때, 선도적인 컴퓨터과학 박사라는 사람이 잘 돌아가고 수익도 내던 PHP 모놀리스를 Scala/Java 마이크로서비스 아키텍처로 바꾸려던 시기였음
  신규 입사 절차에는 그 미친 컴퓨터과학자와의 이상한 1:1도 있었는데, 그는 마이크로서비스의 장점을 열변으로 설명했고 “그냥 숫자 목록을 더하는 분산 서비스를 왜 만들죠?” 같은 질문은 “왜 훨씬 나은지 넌 이해 못 할 것” 식의 손짓으로 능숙하게 피했음
  30명 넘는 신규 채용과 4년 넘는 강도 높은 개발이 지난 뒤, 더 이상 수익을 내지 못하는 회사에는 더 느리고 버그가 많고 디버깅 불가능한 분산 지옥도만 남았음
  전체 설계자이자 아키텍트는 그때가 “안식년”을 가기에 좋은 시점이라고 판단했고, 얼마 지나지 않아 몇 번째인지 모를 투자금도 바닥나 모두가 일자리를 찾게 됨

• 이 글은 Amtrak 비유를 빌리자면 완전히 선로를 이탈했음
  저자는 형편없는 마이크로서비스를 만들었다면 그냥 모놀리스를 만들기만 했어도 마법처럼 괜찮았을 거라고 전제함
  같은 수준의 설계와 엔지니어링으로 쓰레기 같은 마이크로서비스를 만들었더라도, 목표가 모놀리스였으면 황금빛 결과가 나왔을 거라는 식임
  글 중간중간 자기만족도 강하고, 풀스택 JS 개발자에 대한 코멘트가 그런 예임
  그런데 실제 엔지니어링 관점의 내용은 거의 없음. 측정값이나 데이터를 기대해도, 돌아오는 건 장광설뿐임
  시스템 변경 비용을 낮게 유지하기 위해 복잡성을 관리하는 것은 좋은 목표지만, 이 글이 제안하는 건 그게 아님
  이 점을 인정했거나, 데이터나 최소한 일화라도 하나 제시했다면 글이 더 나았을 것임
  우리 팀이라면 이미 모든 걸 안다고 믿고 더 성장할 게 없는 사람보다, 시야를 넓혀 풀스택 개발자로 성장하고 싶어 하는 밝고 열정적인 프런트엔드 개발자를 택하겠음

  • 제시된 이분법이 너무 단순화되어 저자의 신뢰성을 의심하게 됨. 어떤 아키텍처든 제대로 유지하지 않으면 시간이 지나며 짓누르는 짐이 됨
  • 반대편 동전도 똑같음. 형편없는 모놀리스를 만들었다면 그냥 마이크로서비스로 만들기만 했어도 마법처럼 괜찮았을 거라는 주장도 마찬가지임

• 현재 직장에서 이 흐름과 싸우고 있고, 어떤 팀에서는 어느 정도 성공했지만 다른 팀에서는 훨씬 덜 성공했음. 그 팀들은 이제 자신들이 만든 분산 모놀리스와 싸우는 중임
  아이러니하게도 전직 FAANMG 출신들은 모두 모놀리스 지지 쪽임
  많은 사람이 마이크로서비스가 반복적 과정의 결과라는 점을 놓치는 듯함. 결국 확장해야 하는 부분을 모놀리스에서 떼어내는 것임
  마이크로서비스에는 필요할 때가 아니면 유지하고 싶지 않은 기본 인프라가 많이 필요함
  대부분의 회사는 그 패턴을 지원할 적절한 플랫폼도 갖고 있지 않음

• 공감함. 우리 회사에서는 도구가 제대로 동작하지 않아 디버깅 자체를 포기한 상태임
  로컬 머신에서 서비스 하나를 실행하려면 나머지 9개가 이 서비스와 붙도록 맞춰야 함
  고객을 위한 “기능”을 만들기라도 하면 당연히 최소 2개 서비스를 동시에 건드려 더 많은 데이터를 옮겨야 함
  한쪽에 중단점을 걸면 다른 쪽은 시간 초과가 됨
  그래서 모든 개발자가 로컬 VM에 릴리스 빌드를 배포하고, 핫 리로드 없이 console.log, System.PrintLines(), _logger를 심은 뒤 흩어진 로그 파일을 읽고 있음
  당연히 나는 배에서 뛰어내릴 예정임

  • 세 번째 문단은 적어도 모든 것을 구조화 로그로 바꾸고 로컬 집계기로 보낼 수 있게 하면 어느 정도 개선될 수 있음
    전부 분산 추적으로 옮기면 더 좋겠지만, 요청을 제대로 추적하려면 추적 메타데이터를 전반적으로 통일해야 해서 투자가 더 큼
    개발보다 운영에 더 도움이 될 가능성이 크지만, 그래도 도움이 될 것임. 제대로 된 구간 정보만 있어도 난장판을 이해하는 데 많은 통찰을 줌
    한쪽 중단점이 다른 쪽 시간 초과가 된다면, 개발 모드에서 시간 초과를 늘리거나 끄는 방법이 없는지 궁금함
  • 우리는 mirrord와 스테이징 환경을 함께 써서 전체 스택을 로컬에 띄우지 않고 특정 서비스만 실행함. 서비스가 약 5개뿐이라 원래도 큰 문제는 아니었음
  • Telepresence가 있음