시스템 설계의 품질 속성과 트레이드오프

시스템 설계란

시스템 설계는 요구 사항을 만족하는 구성 요소와 그 사이의 데이터 흐름을 정하는 일이다. 기능 요구 사항(무엇을 하나)은 출발점일 뿐이고, 설계의 대부분은 비기능 요구 사항(얼마나 많이, 얼마나 빨리, 얼마나 오래 멈추지 않고)을 맞추는 데 쓰인다. 그 비기능 요구 사항을 품질 속성(quality attribute) 이라 부른다.

네 가지 품질 속성

가용성과 신뢰성은 다르다. 가용성은 응답이 오는지, 신뢰성은 그 응답이 맞는지를 본다. 가용성을 높인 시스템도 오래된 데이터를 돌려줄 수 있다.

처리량을 높이는 법

처리량(throughput)은 단위 시간에 처리하는 요청 수다. 높이는 순서는 대개 이렇다.

1. 캐시로 디스크·DB 같은 느린 I/O까지 가지 않게 한다.
2. 계산이 무거운 작업은 스레드·워커 수를 늘린다. 단, 너무 많으면 문맥 전환과 경합으로 오히려 느려진다.
3. 병목을 측정해 찾고, 무거운 작업은 비동기 처리로 요청 경로에서 떼어 낸다.

확장 전략의 세부는 웹 확장성의 구성 요소, 가용성을 이중화로 높이는 구조는 고가용성 이중화 구조와 장애 감지에 있다.

여기에 두 가지를 더 본다. 관리 용이성(Manageability) 은 운영의 확장성이다. 문제를 얼마나 빨리 진단하고, 얼마나 쉽게 고치고 배포하나로 잰다. 비용(Cost) 은 장비·라이선스값만이 아니라 만드는 데 드는 개발 시간, 운영 인력, 교육까지 합친 총소유비용(TCO)이다. 서버를 더해 확장성을 얻으면 관리할 서버와 비용이 늘듯, 속성끼리는 자주 부딪친다.

성능 문제와 확장성 문제는 증상이 다르다. 사용자 한 명일 때도 느리면 성능 문제이고, 한 명일 때는 빠른데 부하가 몰릴 때만 느려지면 확장성 문제다. 목표는 「받아들일 만한 지연 시간 안에서 최대 처리량」이다.

다섯 가지 트레이드오프

정답인 설계는 없고, 무엇을 얻으려고 무엇을 내주는지가 있을 뿐이다.

SQL·NoSQL, 배치·스트림, 동기·비동기처럼 기술 선택에서 반복되는 양자택일과 흔한 문제의 처방은 시스템 설계의 선택지와 흔한 문제의 해법에 있다.

빌딩 블록

대부분의 설계는 아래 부품의 조합이다.

클라우드 설계의 다섯 기둥과 원칙

클라우드 제공자는 품질 속성을 Well-Architected Framework의 다섯 기둥으로 묶는다. AWS·Azure·Google Cloud가 같은 이름의 틀을 쓴다(AWS와 Google Cloud는 여섯 번째로 지속 가능성을 둔다). 설계 리뷰를 할 때 다섯 기둥을 하나씩 짚으면 빠진 것이 드러난다.

기둥을 지키는 설계 원칙은 세 무리로 정리된다.

이 원칙을 구현하는 구체 패턴은 클라우드 설계 패턴과 복원력 패턴에 있다.

설계 진행 순서

열린 문제(「X 같은 서비스를 설계하라」)를 받으면 아래 순서로 범위를 좁혀 간다. 실제 대화는 순서대로 흐르지 않지만, 빠뜨린 단계가 없는지 확인하는 뼈대가 된다. 답보다 근거가 중요하다. 정답이 하나인 문제가 아니므로 선택마다 이유와 대가를 말로 남긴다.

• 처음부터 큰 그림을 완성하려 하지 않는다. 단순하게 시작하고 반복해서 키운다.
• 써 보지 않은 기술은 「X는 써 보지 않았지만 Y 문제의 흔한 해법이다」처럼 정직하게 말한다. 제품의 세부 설정보다 필요를 알아보고 흔한 해법을 짝짓는 능력이 더 중요하다(로드 밸런서가 필요하다는 판단과 NGINX가 흔한 선택이라는 지식).
• 설계 감각에 필요한 바탕은 동시성(스레드, 교착, 일관성), 네트워크(IPC, TCP/IP, 처리량과 지연의 차이), 추상화(OS·파일 시스템·DB가 대략 어떻게 동작하나), 실제 성능 수치, 어림셈, 가용성·내구성이다. 모두를 깊이 알 필요는 없고, 어떤 질문을 던지고 언제 전문가를 찾을지 알 만큼 익숙하면 된다.

어림셈: 봉투 뒷면 계산

어림셈(back-of-the-envelope calculation) 은 대략의 숫자로 불가능한 설계를 일찍 걸러 내는 계산이다. 남은 후보만 프로토타입이나 마이크로벤치마크로 확인한다. 어림셈 결과와 벤치마크가 다르면 머릿속 모델 어딘가가 틀린 것이므로 그 차이에서 배운다.

예: URL 단축 서비스
새 URL 월 1억 개 × 평균 수명 10일 × 하루 1회 클릭 ≈ 월 10억 클릭
10억 / (30일 × 86,400초) ≈ 초당 약 400 요청 (최대치는 평균의 몇 배로 잡는다)

어림셈의 재료는 기본 연산의 비용이다. 아래는 Jeff Dean이 정리한 고전적인 수치(2009년 무렵)로, 절대값보다 자릿수 차이를 외우는 표다.

• 지금 하드웨어는 메모리 순차 읽기·네트워크가 이보다 몇 배 빠르고, SSD의 무작위 읽기는 수십~100µs 수준이라 HDD 탐색보다 두 자릿수 빠르다. 그래도 메모리 < 같은 DC 왕복 < 디스크 < 대륙 간 왕복의 순서와 무작위 I/O가 순차 I/O보다 훨씬 비싸다는 결론은 그대로다.
• OS 수준 비용도 같은 방식으로 어림한다. 시스템 콜은 수십수백 ns, 컨텍스트 전환은 캐시 오염까지 치면 수 µs수십 µs, fork()는 수십~수백 µs다.
• 프론트엔드 쪽 수치(네트워크 왕복, 파싱, 프레임 예산)는 프론트엔드 개발자가 알아야 할 지연 시간 숫자에 있다.

설계 논의 체크리스트

실무 설계 문서를 쓸 때는 위 진행 순서를 조금 더 넓혀, 아래 항목이 빠지지 않았는지 본다.

flowchart TB
  S1["1. 요구 사항<br/>기능, 사용자 수, 읽기·쓰기 비율, 지연·가용성 목표"] --> S2["2. 용량 추정<br/>QPS, 저장량, 대역폭 → 비용 추정"]
  S2 --> S3["3. 아키텍처<br/>구성 요소와 데이터 흐름, 동기·비동기 경계"]
  S3 --> S4["4. 데이터 설계<br/>데이터 모델, 저장소 선택, 분할·복제"]
  S4 --> S5["5. 도메인 설계<br/>서비스·모듈 경계, 책임 분리"]
  S5 --> S6["6. 품질 속성<br/>확장성, 가용성, 신뢰성, 성능, 보안"]
  S6 --> S7["7. 운영<br/>관측, 배포, 테스트, 유지보수성"]
  S7 --> S8["8. 사람<br/>사용자 경험, 문서화, 기존 시스템에서의 이전(migration) 계획"]

자주 나오는 약어

정리

• 설계의 대부분은 확장성·가용성·신뢰성·성능 같은 비기능 요구 사항을 맞추는 일이다.
• 가용성은 응답이 오는지, 신뢰성은 응답이 맞는지다. 둘을 따로 목표로 잡는다.
• 모든 선택은 트레이드오프다. 무엇을 얻고 무엇을 내주는지 말로 적어 둔다.
• 설계는 빌딩 블록의 조합이다. 부품 하나하나의 역할과 한계를 알면 처음 보는 문제도 조립할 수 있다.

관련 노트: 시스템 설계의 선택지와 흔한 문제의 해법, 소프트웨어 아키텍처 패턴, 웹 확장성의 구성 요소, 고가용성 이중화 구조와 장애 감지, 장애 확산을 막는 복원력 패턴, 분산 시스템의 통신·데이터 흐름 패턴, 백엔드 개발자가 알아야 할 것