신뢰성, 확장성, 유지보수성

좋은 데이터 시스템이란 결국 세 가지로 판가름 나 — 신뢰성, 확장성, 유지보수성. 이 세 축 중 하나라도 무너지면 나머지가 아무리 훌륭해도 쓸모없어지거든.

요즘 애플리케이션은 데이터 중심(data-intensive) 이야. CPU가 병목이 아니라 데이터의 양, 복잡도, 변화 속도가 문제지. Redis가 메시지 큐로 쓰이고, Kafka가 DB처럼 내구성 있는 저장을 제공하는 세상에서 "이건 DB고 이건 큐야"라고 칼로 자르는 건 무의미해. 개발자는 여러 도구를 조합해서 새로운 데이터 시스템을 설계하는 사람이 된 거야.

신뢰성은 "뭔가 잘못되더라도 계속 올바르게 동작하는 것"이야. 핵심 구분이 있는데, 결함(fault) 과 장애(failure) 는 다르다는 거. 결함은 구성요소 하나가 사양에서 벗어나는 거고, 장애는 시스템 전체가 서비스를 못 하는 거야. 디스크가 만 개인 클러스터에서는 매일 하나씩 죽는다고 보면 돼. 클라우드에서는 하드웨어 중복성보다 소프트웨어 기반 내결함성이 더 중요해졌고, 대규모 서비스 연구에 따르면 장애의 주 원인은 하드웨어가 아니라 운영자의 설정 실수야. "올바른 일을 하기 쉽고, 잘못된 일을 하기 어렵게" 시스템을 설계하는 게 답이지.

확장성을 이야기할 때 "X는 확장 가능하다/불가능하다"라고 말하는 건 의미가 없어. "시스템이 이렇게 성장하면, 대처할 선택지가 뭔가?"라고 물어야 해. 트위터 예시가 잘 보여주는데, 트윗 쓰기는 초당 수천 건이지만 타임라인 읽기는 초당 30만 건이야. 읽기가 압도적으로 많으니까 쓰기 시점에 비용을 치르는 게 낫다는 결론이 나오고, 팔로워 3천만 명인 유명인은 예외로 처리하는 하이브리드로 간 거지. 부하 매개변수의 분포가 아키텍처를 결정한다는 핵심을 보여줘. 성능을 볼 때도 평균만 보면 안 돼. p95, p99 같은 백분위를 봐야 해 — 느린 응답을 경험하는 사용자가 보통 가장 가치 있는 고객이거든.

유지보수성은 소프트웨어 비용의 대부분이 초기 개발이 아니라 유지보수에 들어간다는 현실에서 출발해. 운용성, 단순성, 발전성 — 이 세 원칙이 핵심이야. 특히 추상화가 복잡성을 다루는 최고의 도구지. SQL이 대표적인 예시잖아 — 디스크 구조, 동시성, 충돌 복구 같은 복잡한 걸 감추고 선언적 질의로 추상화한 거.

---

정리

1장 읽고 기억할 거 세 가지:

1. 결함과 장애는 다르다. 결함은 피할 수 없고, 결함이 장애로 이어지지 않게 설계하는 게 신뢰성이다
2. 확장성에 만능 해법은 없다. 시스템의 부하 특성을 정확히 이해하고, 그에 맞는 아키텍처를 선택해야 한다
3. 소프트웨어 비용의 대부분은 유지보수다. 운용성, 단순성, 발전성을 처음부터 설계에 녹여야 한다