DDIA (데이터 중심 애플리케이션 설계) Chapter 1

고태규·2026년 9월 9일

목록 보기

1/4

해당 스터디는
데이터 중심 애플리케이션 설계 (Designing Data-Intensive Applications)
https://www.wikibook.co.kr/data-intensive/
를 기반으로 진행한 내용입니다.

DDIA 1주차 - 01장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

1. 데이터 중심 애플리케이션

오늘날 많은 애플리케이션은 계산 중심(compute-intensive)이 아니라 데이터 중심(data-intensive)이다.

CPU 성능이 애플리케이션을 제한하는 요소가 아니라, 데이터의 양 / 데이터의 복잡도 / 데이터의 변화 속도가 더 큰 문제라는 뜻이다.

데이터 중심 애플리케이션은 보통 아래와 같은 표준 구성 요소를 조합해서 만든다.

데이터베이스: 나중에 다시 데이터를 찾을 수 있게 저장
캐시: 읽기 속도 향상을 위해 값비싼 수행 결과를 기억
검색 색인(search index): 키워드 검색이나 다양한 필터링을 제공
스트림 처리(stream processing): 비동기 처리를 위해 다른 프로세스로 메시지 전달
일괄 처리(batch processing): 주기적으로 대량의 누적 데이터를 분석

1-1. 왜 전부 데이터 시스템으로 묶는가

일반적으로 데이터베이스, 큐, 캐시는 서로 다른 범주의 도구로 생각한다.

하지만 최근 도구들은 분류 간 경계가 흐려지고 있다.

메시지 큐로 사용하는 데이터스토어인 Redis
데이터베이스처럼 지속성을 보장하는 메시지 큐인 Apache Kafka

또한 단일 도구로는 요구사항을 모두 만족시킬 수 없기 때문에, 작업을 태스크로 나누고 애플리케이션 코드로 여러 도구를 연결하게 된다.

메인 DB와 캐시 및 검색 색인의 동기화를 맞추는 책임은 결국 애플리케이션 코드에 있다.

이렇게 여러 구성 요소를 조합해 특수 목적의 시스템을 만든 것을 복합 데이터 시스템이라 부른다.

즉, 이제 개발자는 애플리케이션 개발자일 뿐만 아니라 데이터 시스템 설계자이기도 하다.

1-2. 이 책이 중점을 두는 세 가지 관심사

신뢰성(Reliability): 하드웨어/소프트웨어 결함, 인적 오류에 직면하더라도 시스템은 지속적으로 올바르게 동작해야 한다.
확장성(Scalability): 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 적절한 방법이 있어야 한다.
유지보수성(Maintainability): 시간이 지나 다양한 사람들이 시스템을 다루더라도 모두가 생산적으로 작업할 수 있어야 한다.

2. 신뢰성(Reliability)

2-1. 신뢰성이란

소프트웨어에 대한 일반적인 기대치는 다음과 같다.

애플리케이션은 사용자가 기대한 기능을 수행한다.
사용자가 범한 실수나 예상치 못한 사용법을 허용할 수 있다.
예상된 부하와 데이터 양에서 필수 사용 사례를 충분히 만족한다.
허가되지 않은 접근과 오남용을 방지한다.

이것을 한 문장으로 줄이면 "무언가 잘못되더라도 지속적으로 올바르게 동작함"이 신뢰성의 의미다.

2-2. 결함과 장애는 다르다

이 장에서 가장 중요하게 짚고 넘어가야 할 용어 구분이다.

결함(fault): 사양에서 벗어난 시스템의 한 구성 요소
장애(failure): 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우

결함을 예측하고 대처할 수 있는 시스템을 내결함성 또는 탄력성을 지녔다고 말한다.

다만 결함 확률을 0으로 줄이는 것은 불가능하다.

따라서 목표는 결함을 없애는 것이 아니라, 결함이 장애로 번지지 않게 설계하는 것이다.

이때, 여기서 반직관적인 이야기가 나온다.

고의적으로 결함을 일으켜 결함률을 증가시키는 방법이 납득할 만하다는 것이다.

실제로 많은 중대한 버그는 미흡한 오류 처리에 기인하기 때문에, 일부러 결함을 유도해 지속적으로 훈련하고 테스트해야 한다.

Netflix의 카오스 몽키(Chaos Monkey)가 이런 접근 방식의 대표적인 예다.

2-3. 하드웨어 결함

하드디스크의 평균 장애 시간(Mean time to failure, MTTF)은 약 10~50년으로 보고됐다.

즉, 10,000개의 디스크로 구성된 저장 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다고 예상해야 한다.

전통적인 대응: 각 하드웨어 구성 요소에 중복 추가 (RAID 구성, 이중 전원 장치, 핫 스왑 CPU, 예비 디젤 발전기 등)
변화한 상황: 데이터 양과 계산 요구가 늘어나면서 사용하는 장비 수가 늘었고, 이에 비례해 하드웨어 결함율도 증가했다.
클라우드 환경: AWS 같은 플랫폼은 가상 장비 인스턴스가 별도의 경고 없이 사용 불가가 되는 상황이 상당히 일반적이다. 단일 장비 신뢰성보다 유연성과 탄력성을 우선하도록 설계됐기 때문이다.

그래서 하드웨어 중복만이 아니라 소프트웨어 내결함성 기술로 전체 장비 손실을 견디는 시스템으로 옮겨가고 있다.

2-4. 소프트웨어 오류

하드웨어 결함은 보통 무작위적이고 서로 독립적이다.

반면, 체계적 오류는 노드 간 상관관계가 있어 오히려 더 많은 시스템 오류를 유발한다.

잘못된 특정 입력에 모든 애플리케이션 서버 인스턴스가 죽는 버그
CPU 시간, 메모리, 디스크 공간, 네트워크 대역폭 같은 공유 자원을 과도하게 사용하는 프로세스
속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스
한 구성 요소의 작은 결함이 차례차례 번지는 연쇄 장애

이러한 버그들은 특정상황에 의해 발생되기 전까지 오랫동안 나타나지 않으며, 소프트웨어의 체계적 오류에는 신속한 해결책이 없다.

따라서, 소프트웨어 오류에 대한 문제해결을 위해서는

시스템의 가정과 상호작용에 대해 주의 깊게 생각하기
빈틈없는 테스트
프로세스 격리
죽은 프로세스의 재시작 허용
프로덕션 환경에서의 측정, 모니터링, 분석

이러한 방식들이 문제 해결에 도움을 준다.

2-5. 인적 오류

대규모 인터넷 서비스에 대한 한 연구 결과가 인상적이었다.

운영자의 설정 오류가 중단의 주요 원인인 반면, 하드웨어(서버나 네트워크) 결함은 중단 원인의 10~25% 정도에 그친다.

사람이 미덥지 않음에도 시스템을 신뢰성 있게 만들려면 다양한 접근 방식을 결합해야 한다.

오류 가능성을 최소화하는 설계: 잘 설계된 추상화와 API로 옳은 일은 쉽게, 잘못된 일은 막는다. 단, 인터페이스가 지나치게 제한적이면 사람들은 이를 피해서 작업하므로 균형이 어렵다.
실수가 잦은 부분의 분리: 실제 데이터로 안전하게 실험할 수 있지만 실제 사용자에게는 영향이 없는 비 프로덕션 sandbox를 제공한다.
모든 수준에서의 철저한 테스트: 단위 테스트부터 통합 테스트, 수동 테스트까지. 특히 정상 동작에서는 거의 발생하지 않는 Corner Case를 다루는 데 유용하다.
빠르고 쉬운 복구: 설정 변경 내역을 빠르게 롤백하고, 새로운 코드는 서서히 롤아웃하며, 이전 계산이 잘못된 경우를 대비해 데이터 재계산 도구를 제공한다.
상세하고 명확한 모니터링: 성능 지표와 오류율. 다른 엔지니어링 분야에서는 원격 측정(telemetry)이라 부른다.
조작 교육과 실습: 까다롭지만 매우 중요한 측면 중 하나이다.

3. 확장성(Scalability)

시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작한다는 보장은 없으며, 성능 저하를 유발하는 흔한 이유 중 하나는 부하 증가이다.

확장성은 증가한 부하에 대처하는 시스템 능력을 설명하는 용어지만, 단순히 수치 하나로 말할 수 있는 성질은 아니다.

확장성을 논한다는 것은 "시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택은 무엇인가?", "추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?"를 고려한다는 의미다.

3-1. 부하 기술하기 (용어 정리)

부하 성장에 대한 질문 (부하가 두 배가 되면 어떻게 될까?)을 논의하려면, 먼저 현재 부하를 간결하게 기술할 수 있어야 한다.

이때 사용하는 것이 부하 매개변수(load parameter)다.

부하 매개변수: 시스템의 부하를 나타내는 몇 개의 숫자. 웹 서버의 초당 요청 수, DB의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자 수, 캐시 적중률 등이 될 수 있다.

가장 적합한 부하 매개변수 선택은 시스템 설계에 따라 달라진다.

이 책은 트위터를 예로 들어 설명하는데, 사례를 따라가려면 용어 두 개를 먼저 정리하고 가는 편이 좋다.

홈 타임라인(home timeline): 트위터 메인 화면으로, 내가 팔로우하는 사람들이 작성한 트윗을 시간 역순으로 모아서 보는 피드다.
팬 아웃(fan-out): 한 사용자가 트윗 하나를 올렸을 때, 그 글을 받아봐야 하는 모든 팔로워에게 퍼뜨려 전달하는 과정 또는 그 작업량을 말한다.

3-2. 트위터 사례 - 팬 아웃을 언제 할 것인가

트위터의 주요 두 가지 동작은 다음과 같다.

트윗 작성(쓰기): 평균 초당 4.6k 요청, 피크일 때 초당 12k 요청 이상
홈 타임라인 조회(읽기): 초당 300k 요청

여기서 중요한 건 읽기가 쓰기보다 압도적으로 많다는 점이다. 초당 12,000건의 쓰기 처리 자체는 사실 상당히 쉽다.

트위터의 확장성 문제는 트윗 양이 아니라 팬 아웃 때문이다.

개별 사용자는 많은 사람을 팔로우하고, 많은 사람이 개별 사용자를 팔로우하기 때문이다. 이 두 동작을 구현하는 방법은 크게 두 가지다.

접근 방식 1 - 읽는 시점에 합치기

트윗 작성: 트윗 테이블에 새 레코드를 한 줄 넣고 끝낸다.
타임라인 조회: 사용자가 타임라인을 새로고침할 때마다 DB가 실시간으로 일한다.
팔로우 테이블에서 내가 팔로우하는 사람을 찾고 → 그 사람들의 트윗을 트윗 테이블에서 모두 찾아오고 → 시간순으로 정렬해 합친다.

SELECT tweets.*, users.* FROM tweets
  JOIN users   ON tweets.sender_id    = users.id
  JOIN follows ON follows.followee_id = users.id
  WHERE follows.follower_id = current_user

장점: 쓰기 작업이 매우 가볍다. 트윗을 쓸 때 할 일이 거의 없다.
단점: 조회할 때마다 복잡한 조인과 정렬을 반복해야 한다. 읽기가 쓰기보다 압도적으로 많은 트위터에서는 이 부하를 감당하지 못했다.

접근 방식 2 - 쓰는 시점에 미리 뿌리기

구조: 각 사용자마다 전용 우편함 역할을 하는 홈 타임라인 캐시를 둔다.
트윗 작성: 누군가 트윗을 쓰면 그 사람의 팔로워 목록을 확인하고, 모든 팔로워의 우편함에 해당 트윗을 미리 하나씩 복사해서 넣는다. (fan-out)
타임라인 조회: 계산할 필요 없이 자기 우편함에 이미 모여 있는 목록만 꺼내 읽는다.
장점: 읽기 요청 시 결과가 이미 완성돼 있으므로 조회가 아주 빠르고 비용이 거의 들지 않는다.

트위터의 첫 번째 버전은 접근 방식 1을 사용했지만, 홈 타임라인 질의의 부하를 감당하지 못해 접근 방식 2로 전환했다.

게시된 트윗의 평균 속도가 홈 타임라인 읽기 속도보다 100배 정도 낮기 때문에, 이 경우에는 쓰기 시점에 더 많은 일을 하고 읽기 시점에 적은 일을 하는 것이 바람직하다.

그런데 접근 방식 2에는 유명인 문제가 있다

읽기는 편해졌지만, 반대로 쓸 때 해야 할 일(팬 아웃)이 폭발적으로 늘어났다.

평균적으로 트윗이 약 75명의 팔로워에게 전달되므로, 초당 4.6k 트윗은 초당 345k건의 캐시 쓰기가 된다.
문제는 평균값이 사용자마다 팔로워 수가 매우 다르다는 사실을 가린다는 점이다. 일부 사용자는 팔로워가 3천만 명이 넘는다.
즉, 유명인의 단일 트윗 하나가 3천만 건 이상의 쓰기 요청이 될 수 있다.
트위터는 5초 이내에 팔로워에게 트윗을 전송하려고 하는데, 이 목표를 맞추는 것이 중요한 도전 과제가 됐다.

최종 해결책 - 두 방식을 섞은 혼합형

팔로워가 적은 대다수 사용자와 팔로워가 수백만 이상인 소수 사용자를 나눠서 처리한다.

일반 사용자가 트윗을 쓸 때: 접근 방식 2를 쓴다. 팔로워 수가 적으므로 팔로워들의 우편함에 바로 복사해 넣는다.
유명인이 트윗을 쓸 때: 팬 아웃에서 제외한다. 팔로워 우편함에 일일이 복사하지 않고 유명인의 트윗은 그대로 둔다.
홈 타임라인을 조회할 때: 자기 우편함(미리 들어온 일반 사용자들의 트윗)을 꺼내고, 내가 팔로우하는 유명인의 트윗은 접근 방식 1처럼 읽는 시점에 별도로 가져와 시간순으로 합친다.

이 혼합형 접근 방식으로 좋은 성능의 지속적인 전송이 가능해졌다.

이 사례가 말하고자 하는 핵심

트위터의 핵심 부하 매개변수는 초당 트윗 수가 아니라 사용자당 팔로워 수의 분포였다.

시스템을 설계할 때 평균값(사용자당 평균 팔로워 75명)만 보고 판단하면 안 된다는 이야기다.

평균만 보면 접근 방식 2가 완벽해 보이지만, 실제로는 소수의 극단적인 이상치(팔로워 수천만 명의 유명인)가 시스템 전체를 마비시킬 수 있다.

3-2. 성능 기술하기 (평균이 아니라 백분위)

일괄 처리 시스템: 처리량(throughput)에 관심
온라인 시스템: 응답 시간(response time)이 더 중요

여기서 지연 시간과 응답 시간의 구분도 짚고 간다.

응답 시간(response time): 클라이언트 관점의 시간. 실제 처리 시간(서비스 시간) + 네트워크 지연 + 큐 지연을 포함한다.
지연 시간(latency): 요청이 처리되길 기다리는, 휴지 상태인 시간

응답 시간은 단일 숫자가 아니라 측정 가능한 값의 분포로 생각해야 한다.

전형적인 응답 시간을 알고 싶다면 평균은 그다지 좋은 지표가 아니다. 얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않기 때문이다.

중앙값(p50): 사용자가 보통 얼마나 기다리는지 알고 싶을 때 좋은 지표
상위 백분위(p95, p99, p999): 특이 값(outlier)이 얼마나 나쁜지 확인. 꼬리 지연 시간(tail latency)이라 부른다.

꼬리 지연 시간이 중요한 이유는 서비스의 사용자 경험에 직접 영향을 주기 때문이다.

아마존은 내부 서비스의 응답 시간 요구사항을 99.9분위로 기술한다. 요청 1,000개 중 1개만 영향이 있음에도 그렇게 한다.
응답 시간이 가장 느린 요청을 경험한 고객이 대개 데이터가 가장 많은, 즉 가장 소중한 고객이기 때문이다.
아마존은 응답 시간이 100밀리초 증가하면 판매량이 1% 줄어들고, 1초가 느려지면 고객 만족도 지표가 16% 줄어드는 현상을 관찰했다.
반면 99.99분위는 최적화 비용이 너무 커서 이익이 충분치 않다고 여긴다.

함께 알아둘 개념 두 가지

선두 차단(head-of-line blocking): 서버는 병렬로 소수의 작업만 처리할 수 있어, 느린 요청 몇 개가 후속 요청 처리를 지체시킨다. 이 때문에 클라이언트 쪽에서 응답 시간을 측정하는 것이 중요하다.

꼬리 지연 증폭(tail latency amplification): 하나의 최종 사용자 요청이 여러 백엔드를 호출하면, 가장 느린 호출이 끝날 때까지 기다려야 한다. 작은 비율의 백엔드 호출만 느려도 최종 사용자 요청의 상당 비율이 느려진다.

따라서, 서비스의 지연과 응답 시간을 알고 싶다면, 평균을 사용하는것보다 백분위를 사용해서 분석하는 것이 좋다.

3-3. 부하 대응 접근 방식

용량 확장(scaling up): 수직 확장. 좀 더 강력한 장비로 이동
규모 확장(scaling out): 수평 확장. 다수의 낮은 사양 장비에 부하를 분산 → 비공유 아키텍처

현실적으로 좋은 아키텍처는 두 방식의 조합이다. 적절한 사양의 장비 몇 대가 다량의 낮은 사양 가상 장비보다 훨씬 간단하고 저렴한 경우도 많다.

탄력적 시스템: 부하 증가를 감지해 컴퓨팅 자원을 자동 추가. 부하를 예측할 수 없을 때 유용하다.
수동 확장 시스템: 더 간단하고 운영상 예상치 못한 일이 더 적다.

Stateless 서비스를 다수 장비에 배포하는 일은 간단하다. 하지만 Stateful 데이터 시스템을 분산하는 일은 아주 많은 복잡도를 추가한다.

그리고 결정적으로, 범용적이고 모든 상황에 맞는 확장 아키텍처는 없다.

각 크기가 1kB인 초당 100,000건의 요청을 처리하는 시스템과, 각 크기가 2GB인 분당 3건의 요청을 처리하는 시스템은 데이터 처리량이 같아도 완전히 다른 시스템이다.

확장성 있는 아키텍처는 '주요 동작이 무엇이고 잘 하지 않는 동작이 무엇인지'에 대한 가정 위에 세워진다.

그래서 스타트업 초기 단계나 검증되지 않은 제품이라면, 미래를 가정한 부하에 대비하기보다 빠르게 반복해서 제품 기능을 개선하는 작업이 더 중요하다.

4. 유지보수성(Maintainability)

소프트웨어 비용의 대부분은 초기 개발이 아니라 지속해서 이어지는 유지보수에 들어간다.

버그 수정, 시스템 운영 유지, 장애 조사, 새 플랫폼 적응, 새 사용 사례를 위한 변경, 기술 채무 상환, 새 기능 추가 등이 모두 여기에 해당한다.

희망적인 점은, 유지보수 중 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 설계할 수 있다는 것이다.

이를 위한 세 가지 설계 원칙은 다음과 같다.

4-1. 운용성(operability): 운영의 편리함 만들기

좋은 운영성이란 반복되는 태스크를 쉽게 만들어, 운영팀이 고부가가치 활동에 노력을 집중하게 하는 것이다.

데이터 시스템이 할 수 있는 일은 다음과 같다.

좋은 모니터링으로 runtime 동작과 시스템 내부에 대한 가시성 제공
표준 도구를 이용한 자동화와 통합 지원
개별 장비 의존성 회피. 유지보수로 장비를 내려도 시스템 전체는 계속 운영 가능해야 함
만족할 만한 기본 동작을 제공하되, 필요할 때 기본값을 재정의할 자유를 관리자에게 부여
적절한 자기 회복이 가능하면서, 필요 시 관리자가 수동으로 제어할 수 있게 함
예측 가능하게 동작하고 예기치 않은 상황을 최소화함
좋은 문서와 이해하기 쉬운 운영 모델 제공 (예: "X를 하면 Y가 발생한다")

4-2. 단순성(simplicity): 복잡도 관리

프로젝트가 커지면 시스템은 매우 복잡하고 이해하기 어려워지며, 복잡도는 다양한 증상으로 나타난다.

상태 공간의 급증
모듈 간 강한 커플링(tight coupling)
복잡한 의존성
일관성 없는 명명과 용어
성능 문제 해결을 목표로 한 해킹
임시방편으로 문제를 해결한 특수 사례

복잡한 소프트웨어에서는 변경이 있을 때 버그가 생길 위험이 더 크다. 개발자가 시스템을 이해하기 어려워지면 숨겨진 가정과 의도치 않은 결과를 간과하기 쉽다.

시스템을 단순하게 만드는 일이 반드시 기능을 줄인다는 의미는 아니다. 우발적 복잡도(accidental complexity)를 줄인다는 뜻일 수 있다.

우발적 복잡도란 문제 자체에 내재하지 않고 구현에서만 발생하는 복잡도를 말한다.

그리고 우발적 복잡도를 제거하기 위한 최상의 도구는 추상화다.

고수준 프로그래밍 언어는 기계 언어, CPU 레지스터, 시스템 호출을 숨긴 추상화
SQL은 디스크 기록, 메모리 자료 구조, 다른 클라이언트의 동시 요청, 고장 후 불일치를 숨긴 추상화

다만 좋은 추상화를 찾기는 매우 어렵다. 분산 시스템 분야에는 좋은 알고리즘이 많지만, 이를 복잡도를 관리 가능한 수준으로 유지해주는 추상화로 묶는 방법은 아직 명확하지 않다.

4-3. 발전성(evolvability): 변화를 쉽게 만들기

시스템의 요구사항이 영원히 바뀌지 않을 가능성은 매우 적다.

새로운 사실을 배우고, 예기치 않은 사용 사례가 나타나고, 비즈니스 우선순위가 바뀌고, 법적/규제 요구사항이 변경된다.

조직 프로세스 측면에서는 agile 작업 패턴이 변화 적응 프레임워크를 제공한다. TDD, 리팩토링 같은 도구도 여기서 나왔다.

다만 애자일 기법에 대한 설명은 대부분 아주 작은 로컬 규모(같은 애플리케이션 안의 소스 파일 몇 개)에 초점을 맞추고 있다.

이 책이 찾는 것은 여러 애플리케이션과 서비스로 구성된 대규모 데이터 시스템 수준에서 민첩성을 높이는 방법이다.

예를 들어 트위터의 홈 타임라인 아키텍처를 '접근 방식 1'에서 '접근 방식 2'로 리팩토링하는 방법 같은 것이다.

그래서 데이터 시스템 수준에서는 민첩성 대신 발전성이라는 단어를 사용한다.

5. 정리

애플리케이션이 유용하려면

기능적 요구사항(데이터를 저장/조회/검색/처리하는 일)
비기능적 요구사항(보안, 신뢰성, 법규 준수, 확장성, 호환성, 유지보수성)

을 모두 충족시켜야 한다.

1장은 그중 비기능적 요구사항의 세 축을 다뤘다.

신뢰성: 결함이 발생해도 시스템이 올바르게 동작하게 만든다는 의미다.
결함은 하드웨어(대개 무작위), 소프트웨어(보통 체계적이고 다루기 어려움), 사람(가끔 불가피하게 실수함)에게서 온다. 내결함성 기술은 최종 사용자에게 특정 유형의 결함을 숨겨준다.
확장성: 부하가 증가해도 좋은 성능을 유지하기 위한 전략이다. 이를 논하려면 부하와 성능(응답 시간 백분위을 양적으로 기술하는 방법이 먼저 필요하다.
유지보수성: 본질은 시스템에서 작업하는 엔지니어와 운영팀의 삶을 개선하는 것이다. 좋은 추상화는 복잡도를 줄이고, 좋은 운용성은 시스템의 건강 상태를 잘 관찰하고 효율적으로 관리할 수 있게 한다.

고태규

다음 포스트