▲

도대체 무엇을 만든 거지

 (wthhyb.sacha.house)
2P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 실제 사용자 수가 적음에도 불구하고 불필요하게 복잡한 시스템 구조를 사용하는 문제 지적
  • Redis, MongoDB, Kubernetes, 마이크로서비스 등 다양한 기술을 무분별하게 결합한 사례 제시
  • 단일 Postgres 인스턴스와 간단한 서버 구성만으로 충분한 상황 강조
  • 복잡성은 미덕이 아니며, 필요성이 입증될 때만 확장해야 함을 강조
  • 스타트업과 개발팀이 규모에 맞는 단순한 설계 원칙을 지켜야 함을 상기시키는 내용

불필요한 기술 스택의 남용

  • Redis와 MongoDB가 동시에 사용되는 등 무작위로 선택된 기술 조합을 비판
    • “왜 Redis가 MongoDB와 대화하고 있나?”, “왜 MongoDB를 사용하는가?”라는 질문 제시
  • 실제 사용자 수가 12명(그중 6명은 테스트 계정)에 불과함에도 분산 시스템을 도입한 점 지적
  • 단일 Postgres 인스턴스로 충분했음에도 과도한 확장을 선택한 사례로 언급

배포 및 인프라 구조의 과잉

  • 현재 구성: 15개의 마이크로서비스, 8개의 데이터베이스, 3개 환경의 Kubernetes 클러스터, 4개의 메시지 큐, 서비스 메시, 2시간 걸리는 CI/CD 파이프라인
  • 필요한 구성으로는 단일 서버, Postgres, 캐싱용 Redis 정도만 제시
  • 실제 요구사항 대비 인프라 복잡도 과잉을 명확히 대비시킴

시스템 복잡성과 설명 가능성

  • 주니어 개발자에게 시스템을 설명할 때 스파게티처럼 얽힌 다이어그램이 필요하다면 문제가 있다고 지적
  • 복잡성은 미덕이 아니다라는 문장으로 핵심 메시지 요약
  • 단순하게 시작하고, 필요가 입증될 때만 복잡성을 추가해야 함을 강조

핵심 교훈

  • 기술 선택과 시스템 설계는 규모와 실제 사용량에 맞게 단순화해야 함
  • 무분별한 확장과 과도한 기술 스택 도입은 유지보수성과 효율성을 해침
  • 스타트업이나 소규모 팀이 “규모에 맞는 단순함” 을 지키는 것이 중요함
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 가끔은 이런 행동이 단순한 미루기(procrastination) 같음
    고객, 투자자, 법무팀 같은 사람들과 이야기하기 싫으니까, 대신 엔지니어 입장에서 ‘재미있는 일’을 함
    겉보기엔 생산적인 것처럼 보이지만 사실은 제자리걸음 중임

    • 결국 즐거움 중독으로 진화하는 과정 같음
      매일 일부러 불편한 일을 하지 않으면 점점 퇴화하게 되고, 나중에 피할 수 있었던 큰 문제를 만나게 됨
      이건 소프트웨어뿐 아니라 인생 전반에도 해당됨
    • 나도 초반 5년 정도 부트스트래핑할 때는 그랬음
      돈을 벌려면 재미있는 일보다 우선순위가 맞는 일을 해야 한다는 걸 배웠음
    • 이게 정말 ‘재미’ 때문일까?
      현실과 동떨어진 CTO나 VPE의 이상적인 아키텍처 욕심을 채우기 위한 건 아닐까 생각함
      예전에 시스템 디자인 인터뷰에서 모놀리식 vs 마이크로서비스를 두고 눈치 싸움을 했던 기억이 있음
      결국 권한 있는 사람들이 원하는 방향이 명확하고, 그걸 거스르는 건 정치적 자본을 태우는 일임
    • 어떤 사람들은 이런 걸로 자기 과시를 함
      “나는 ABC랑 XYZ를 연결해봤어” 같은 식으로 기술 스택 자랑을 늘어놓음

  • 이력서를 멋지게 보이게 하려는 욕심도 있음
    사실 대부분의 프로젝트는 1990년대 기술로도 충분히 가능하지만, 분산 시스템 같은 단어가 들어가면 훨씬 ‘쿨’해 보임
    업계의 잘못된 채용 문화 탓에, 요리사가 칼을 잘 쓰는 것보다 ‘특정 브랜드의 칼’을 써야 인정받는 꼴임

    • 좋은 회사는 이런 언어 경험 요건을 강요하지 않음
      예를 들어 DuckDuckGo는 알고리즘과 자료구조만 요구하고 “참고로 Perl을 씀”이라고만 밝힘
      Stream은 Go를 모르는 지원자에게 10주 코스를 제공하고, Jane Street도 OCaml 경험을 요구하지 않음
      내가 일하는 bevuta IT GmbH도 입사 후 Clojure를 배울 수 있게 해줬음
      이런 접근은 “Ruby on Rails 10년 경험자” 같은 구식 공고와는 완전히 다름
    • 나도 솔직히 불필요하게 복잡한 아키텍처를 설계한 적이 있음
      새로운 걸 시도해보고 비교해보고 싶었기 때문임
    • 면접에서 단순한 Postgres 기반 솔루션을 옹호하느라 시간을 쓰면, 면접관이 기대하는 분산 시스템 얘기를 못 하게 됨
      결국 수백 명의 사용자를 위해 불필요한 복잡성을 떠드는 게 업계의 현실임

  • “Redis로 캐싱”이라는 말이 너무 흔하지만, 사실 Postgres로도 충분함
    굳이 Redis를 쓰자고 하는 건 저자 본인도 오버엔지니어링 욕구를 못 이긴 것 같음

    • 나는 개인적으로 캐싱을 Postgres에 넣고 싶진 않음
      규모가 작을 땐 캐싱이 필요 없고, 임시 데이터를 별도 시스템에 두는 게 더 매력적임
      프레임워크의 캐시 추상화도 대부분 Redis를 염두에 두고 설계되어 있음
      처음엔 인메모리 캐시로 시작하고, 필요할 때 Redis를 추가하는 게 좋음
    • 작은 규모라도 캐시가 도움이 될 때가 있음
      하지만 Redis/Valkey는 과함. memcached가 훨씬 단순하고 실용적임
      Redis처럼 상태를 저장하지 않아서, 캐시 일관성에 의존하는 나쁜 설계 패턴을 피할 수 있음
      DB 캐시는 파일 시스템을 거쳐야 해서 느림
    • Redis는 Postgres가 느려질 때 임시 완충재로 쓰는 게 맞음
      쿼리를 효율적으로 짜는 건 완전히 다른 문제임
      Postgres를 다시 빠르게 만들면 Redis를 제거할 수도 있지만, 보통은 그냥 둠
    • Postgres에 eventually consistent 인메모리 캐시가 있냐는 의문이 있음
    • Redis는 규모가 커질 때 확실히 차이를 만듦
      AWS Lambda 기반 웹앱에서 초당 1000요청을 처리할 때 Postgres는 힘들지만 Redis는 거뜬했음
      단순함 덕분에 예외적으로 쓸 가치가 있음

  • 저자가 “단순함”을 주장하면서도 Tailwind + JS 프레임워크 + 번들러로 페이지를 만든 게 재밌음
    단순 HTML로 만들 수도 있었을 텐데 말임

    • 나도 저자의 철학에 공감함
      그래서 직접 만들 수 있는 단순한 웹 프레임워크 MastroJS를 소개함
    • 그래도 Tailwind는 거대한 프레임워크는 아님
      실제로는 사용한 유틸리티 클래스만 CSS로 생성함
    • React, Tailwind, 번들러, Google Font… 인간은 참 모순적인 존재임

  • 원문 트윗은 Jeff Atwood의 2013년 트윗에서 비롯된 것임

    • 그래서 기사 제목에 (2013)을 추가해야 함

  • 지금 나도 비슷한 결정을 고민 중임
    시장 검증이 안 된 제품이라면 작고 빠르게 시작해 피벗 가능한 MVP를 만드는 게 맞음
    반면 투자자나 대기업에 확장성 있는 설계 능력을 보여줘야 한다면 처음부터 스케일 가능한 구조를 택해야 함
    비즈니스 모델이 단일 DB로는 감당 안 될 정도로 커져야만 성립한다면, 초기부터 확장형 아키텍처로 가는 게 장기적으로 이득임

  • 인프라 악몽 속에서 일하는 입장에선 단순함이 허무맹랑하게 들릴 수 있음
    하지만 많은 복잡성은 기술적이라기보다 조직적 문제 해결을 위한 것임
    배포 자동화, 장애 대비 중복성, CI 파이프라인, 비밀 관리, 캐싱 등은 팀을 보호하기 위한 안전장치임
    이런 걸 무시하는 건 팀 단위로 일할 때 위험함

    • 사실 이런 요구사항은 모놀리식 서버 + Postgres로도 충분히 가능함
    • CI나 시크릿 관리 같은 건 아키텍처 복잡성과 별개임
      SQLite도 프로덕션에서 충분히 쓸 수 있는데, “테스트용만”이라는 편견이 퍼져 있음
      PaaS 기본 설정이 불필요하게 복잡한 경우도 많음
    • CI 파이프라인은 처음부터 거창하게 만들 필요 없음
      체크리스트 기반 빌드 프로세스부터 시작하고, 그게 안정되면 자동화로 확장하면 됨
    • 캐시 무효화처럼 컴퓨터 과학의 어려운 문제는 여전히 존재함
      FAANG급이 아닌 서비스에서 마이크로서비스가 진짜 필요한 사례를 보고 싶음
    • 결국 Conway의 법칙처럼 조직 구조가 시스템 설계에 반영됨

  • 생각하기가 두려워서 다들 표준 기술 스택만 따라감
    Kafka, Mongo, Redis 같은 걸 무비판적으로 쓰는 게 문제임
    사실 필요한 기능만 직접 구현하는 게 더 낫고, 최소 구성요소 선택 능력이 엔지니어의 핵심임
    Kafka 같은 건 괜히 돈 낭비임

    • “생각하지 않는 동료들 사이에선 아무도 비판하지 않는다”는 말이 인상적임

  • “필요할 때만 복잡성을 추가하라”는 말은 맞지만, 나중에 추가하기 어려운 경우도 있음
    초기 설계가 잘못되면 전체 재작성이 필요할 수도 있음
    그래서 현실적으로는 단순한 k8s 구성 같은 절충안이 필요함

  • 최근 인터뷰에서도 비슷한 경험을 했음
    10년 동안 나는 PMF(Product-Market Fit) 확보에 집중했지, 처음부터 확장성에 집착하지 않았음
    제품이 시장에 맞으면 돈으로 확장 문제를 해결할 수 있음
    하지만 면접에서 “Django 서비스를 하루 1천만 요청으로 스케일링하는 법”을 묻길래
    “서버 스펙을 올리면 된다”고 답했더니 만족스럽지 않았던 듯함

답변달기