본문으로 건너뛰기
J
피드

소프트웨어 아키텍처의 최대 죄악: 상태의 불필요한 분산

backend 약 3분
tags
#architecture#state-management#database#complexity
vote
0
댓글
북마크

아키텍처 인터뷰 경험에서 도출한 핵심 교훈. 소프트웨어의 최악의 우발적 복잡성은 상태의 불필요한 분산, 복제, 재구조화임. 코드는 부채이고 데이터가 자산이므로, 상태를 최소화하고 정규화해서 한 곳에 잘 관리하라는 주장.

  • 1

    코드는 부채, 데이터는 자산 — 레거시 데이터는 재앙이 될 수 있음

  • 2

    인터뷰 후보자들이 본능적으로 컴포넌트 추가로 문제를 해결하려 함

  • 3

    파생 가능한 데이터는 저장하지 말고 계산할 것

  • 4

    정규화로 데이터 중복 제거하고 단일 정본을 참조하게 만드는 것이 핵심

  • 5

    K8s처럼 정보 단일 소스가 없으면 디버깅 자체가 불가능해짐

소프트웨어 아키텍처 인터뷰를 많이 해본 Samir Talwar가 내린 결론: 아키텍처의 최대 죄악은 상태(state)의 불필요한 분산, 복제, 재구조화라는 거임.

  • 인터뷰 때 설계 문제가 생기면 대부분의 후보자가 본능적으로 "컴포넌트를 하나 더 추가하자"고 반응함. 단순화가 아니라 복잡화로 가는 거임
  • 코드는 부채(liability)이고 데이터가 자산(asset)임. 레거시 코드는 짜증나는 수준이지만, 레거시 데이터는 재앙 수준이 될 수 있음
  • "DB에 전 고객의 마지막 주소가 없으면... 영원히 없는 거다" — 데이터는 코드처럼 리팩터링으로 복구가 안 됨
  • 실제 사례: 여러 MongoDB 인스턴스에 데이터가 흩어져 있고, 일부만 백업되고, 중복 저장된 조직에서 일해 봤는데, 새 기능에 필요한 데이터가 고객 50%분밖에 없는 상황이 벌어짐
  • K8s 디버깅 사례도 나옴. Pod가 왜 재배포됐는지 알고 싶었는데, 쿠버네티스에는 정보의 단일 소스가 없어서 여러 곳을 교차 참조해도 결국 원인을 못 찾았다는 거임
  • 상태를 최소화하는 핵심 원칙: 파생 가능한 데이터는 저장하지 말고 계산할 것. 예를 들어 합계를 저장하는 대신 매번 계산하면 됨
  • 캐싱은 괜찮지만, 파생 데이터를 "저장"하는 순간 그건 고정된 상태가 되어버려서 스키마 변경 시 마이그레이션 대상이 됨
  • 정규화(normalization)가 요즘 인기를 잃었지만, 데이터 중복을 없애고 단일 정본(canonical version)을 참조하게 만드는 가장 좋은 방법임

한 줄 요약: "상태를 한 곳에 두고, 잘 관리해라(Put your state in one place, and make it good)."

상태를 한 곳에 두고 잘 관리하라(Put your state in one place, and make it good). 캐싱은 괜찮지만 파생 데이터를 저장하면 마이그레이션 부채가 됨.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.