[TIL] 아키텍처 특성은 어떻게 찾아내는가 (5장)

4장에서 아키텍처 특성이 무엇인지 정리했다.

그런데 실제 프로젝트에서는 누가 친절하게

우리 시스템의 핵심 아키텍처 특성은
Scalability, Availability, Security입니다.

라고 알려주지 않는다.

보통 요구사항 문서에는 기능 요구사항이 훨씬 많고, 아키텍처 특성은 여기저기 숨어 있다.

5장은 결국 이 질문에 대한 이야기다.

수많은 요구사항 중에서, 어떤 아키텍처 특성이 정말 중요한지 어떻게 찾아낼까?

모든 아키텍처 특성이 중요한 건 아니다

4장에서 아키텍처 특성의 종류를 보면 꽤 많았다.

Performance
Scalability
Elasticity
Availability
Reliability
Security
Maintainability
Deployability
Extensibility
...

그렇다면 프로젝트를 시작할 때 이걸 전부 챙기면 되는 걸까?

문제는 특성을 많이 선택할수록 설계가 복잡해진다는 점이다.

모든 특성을 중요하게 본다
        ↓
모든 상황을 대비한다
        ↓
구조가 복잡해진다
        ↓
비용과 개발 난이도가 올라간다

그래서 아키텍트가 해야 하는 일은 좋은 특성을 많이 고르는 것이 아니라,

이 시스템에서 정말 구조에 영향을 줄 정도로 중요한 특성이 무엇인지 골라내는 것

이다.

책에서는 이런 핵심 특성을 흔히 driving architecture characteristics, 즉 아키텍처를 실제로 움직이는 특성으로 본다.

요구사항 문서에서 힌트를 찾는다

아키텍처 특성은 기능 요구사항 안에 숨어 있는 경우가 많다.

예를 들어 이런 문장이 있다고 해보자.

사용자는 매일 오전 9시에 전날의 거래 내역 보고서를 확인할 수 있어야 한다.

겉으로 보면 단순한 기능 요구사항이다.

보고서를 만든다.

그런데 조금 더 생각하면 질문이 생긴다.

사용자가 몇 명인가?
 
보고서는 언제 생성하는가?
 
9시에 모든 사용자가 동시에 접근하는가?
 
보고서를 실시간으로 계산하는가?
 
미리 만들어두는가?

만약 고객이 100명이라면 큰 문제가 아닐 수 있다.

하지만 고객이 1,000만 명이고 오전 9시에 동시에 보고서를 확인한다면 이야기가 달라진다.

대규모 동시 요청
→ Scalability
 
특정 시간에 트래픽 급증
→ Elasticity
 
9시까지 반드시 생성되어야 함
→ Reliability / Performance

즉 하나의 기능 요구사항 안에서도 규모, 시간, 사용 패턴 같은 문맥에 따라 아키텍처 특성이 드러난다.

특히 숫자가 붙으면 의심해보자

요구사항에서 이런 표현을 발견하면 아키텍처 관점에서 한 번 더 보는 게 좋다.

동시에 10만 명이 사용할 수 있어야 한다.
 
응답 시간은 200ms 이하여야 한다.
 
99.99% 이상 사용 가능해야 한다.
 
장애 발생 후 5분 안에 복구해야 한다.
 
하루에 1억 건의 이벤트를 처리해야 한다.

이런 문장은 단순한 기능 설명이 아니다.

시스템 구조를 직접 밀어붙인다.

예를 들어

응답 시간 200ms 이하

라는 요구사항 하나만 있어도

캐시가 필요한가?
 
동기 처리를 줄여야 하는가?
 
DB 조회를 어떻게 최적화할 것인가?
 
서비스 간 네트워크 호출이 너무 많지는 않은가?

같은 설계 문제가 생긴다.

숫자로 표현되는 요구사항은 측정 가능한 아키텍처 특성일 가능성이 높다.

그런데 명시되어 있지 않은 특성도 있다

더 어려운 건 요구사항에 직접 쓰여 있지 않은 경우다.

예를 들어 온라인 경매 시스템을 만든다고 해보자.

요구사항에는 이렇게만 적혀 있을 수 있다.

사용자는 상품에 입찰할 수 있다.
 
가장 높은 가격을 제시한 사용자가 낙찰된다.

하지만 경매라는 도메인을 생각하면 자연스럽게 중요한 특성이 나온다.

마감 직전 입찰이 몰릴 수 있다.
→ Scalability / Performance
 
입찰 순서가 뒤바뀌면 안 된다.
→ Data Integrity / Consistency
 
낙찰 순간 시스템이 멈추면 안 된다.
→ Availability / Reliability

요구사항 문서에 Availability라는 단어가 없어도, 시스템 특성상 반드시 필요할 수 있다.

그래서 아키텍처 특성을 찾을 때는 단순히 문서에서 키워드를 검색하는 게 아니라

이 비즈니스가 실패하는 상황은 무엇인가?

를 생각해보는 것도 중요하다.

도메인 지식이 중요한 이유

결국 아키텍처 특성은 도메인과 떨어져서 생각하기 어렵다.

같은 기능이라도 도메인이 달라지면 중요도가 달라진다.

예를 들어 "메시지를 보낸다"라는 기능이 있다고 해보자.

사내 알림 시스템

메시지가 몇 초 늦게 와도 큰 문제 없음

성능이나 즉시성이 엄청 중요한 특성은 아닐 수 있다.

주식 거래 시스템

체결 정보가 몇 초 늦게 전달됨

굉장히 큰 문제가 된다.

여기서는

Latency
Reliability
Availability

같은 특성이 훨씬 중요해진다.

같은 기능이라도 비즈니스 맥락이 다르면 아키텍처 특성의 우선순위도 달라진다.

이해관계자의 말에서도 특성을 찾을 수 있다

아키텍처 특성은 요구사항 문서에만 있는 게 아니다.

기획자나 비즈니스 담당자가 이런 말을 할 수도 있다.

"이번 캠페인 때 사용자가 갑자기 엄청 들어올 수도 있어요."
 
"장애가 나더라도 결제는 절대 유실되면 안 돼요."
 
"앞으로 해외 서비스도 할 예정이에요."
 
"기능을 자주 출시해야 해요."

이걸 아키텍처 언어로 바꿔보면

갑작스러운 트래픽
→ Elasticity / Scalability
 
결제 유실 방지
→ Reliability / Data Integrity
 
해외 서비스
→ Scalability / Localization / Distribution
 
잦은 기능 출시
→ Deployability / Maintainability

가 된다.

그래서 아키텍트의 역할 중 하나는 비즈니스 언어를 기술적인 특성으로 번역하는 것이라고 볼 수도 있다.

중요한 건 단어보다 맥락이다

예를 들어 누군가 이렇게 말한다고 해보자.

"성능이 중요합니다."

이 말만 가지고는 아키텍처 결정을 하기 어렵다.

성능이라는 말 안에는 여러 의미가 섞여 있다.

응답 시간이 빨라야 한다?
 
처리량이 높아야 한다?
 
한 번에 많은 사용자를 받아야 한다?
 
배치 작업이 정해진 시간 안에 끝나야 한다?

각각 필요한 구조가 다를 수 있다.

그래서 좋은 아키텍처 특성은 가능하면 구체적으로 표현해야 한다.

나쁜 예
 
Performance가 중요하다.

보다

좋은 예
 
일반 API 요청의 95%가 300ms 이내에 응답해야 한다.

가 훨씬 낫다.

추상적인 특성을 측정 가능한 조건으로 바꾸면 이후 설계와 검증도 쉬워진다.

아키텍처 특성은 결국 트레이드오프로 이어진다

예를 들어 어떤 시스템에서 이런 세 가지를 핵심 특성으로 골랐다고 해보자.

High Availability
Scalability
Deployability

그러면 자연스럽게 구조도 영향을 받는다.

High Availability
→ 이중화, 장애 격리
 
Scalability
→ 수평 확장, stateless 설계
 
Deployability
→ 서비스 간 결합도 감소

그런데 이런 구조를 만들면

Operational Complexity ↑
Infrastructure Cost ↑
Distributed System Complexity ↑

같은 비용도 생긴다.

그래서 아키텍처 특성을 식별한다는 것은 단순히 체크리스트를 채우는 일이 아니다.

우리가 어떤 복잡성을 감수할 가치가 있는지 결정하는 과정

에 가깝다.

너무 많은 특성을 선택하면 아무것도 선택하지 않은 것과 비슷하다

예를 들어 프로젝트의 핵심 특성을 이렇게 정했다고 해보자.

Scalability
Availability
Performance
Security
Maintainability
Deployability
Elasticity
Reliability
Extensibility
Usability
Interoperability
...

다 중요해 보인다.

하지만 이렇게 되면 실제 의사결정에서 쓸 수가 없다.

예를 들어

성능을 위해 캐시를 추가할까?
 
아니면 단순성을 위해 추가하지 않을까?

라는 문제가 생겼을 때 무엇을 우선해야 하는지 알 수 없다.

그래서 핵심 특성은 우선순위가 드러날 정도로 좁혀야 한다.

우리 시스템에서 가장 중요한 것은
 
1. Availability
2. Scalability
3. Security

처럼 정해져 있다면 선택하기 쉬워진다.

아키텍처 특성은 모든 시스템에 동일하게 적용되지 않는다

재밌는 부분은 같은 회사 안에서도 서비스마다 핵심 특성이 다를 수 있다는 점이다.

예를 들어 쇼핑몰 회사가 있다고 하자.

상품 검색

Performance
Scalability
Availability

검색이 약간 오래된 데이터를 보여줘도 큰 문제는 없을 수 있다.

결제

Reliability
Security
Data Integrity

여기서는 데이터 정확성이 훨씬 중요하다.

추천 시스템

Scalability
Performance
Experimentability

조금 실패하더라도 서비스 전체가 멈추지는 않는다.

즉 하나의 거대한 시스템에서도 영역별로 중요한 특성이 다를 수 있다.

이 관점은 이후 시스템을 어떻게 나누고 경계를 설정할지와도 연결된다.

결국 5장은 "질문하는 법"에 대한 이야기 같다

4장이

아키텍처 특성이 무엇인가?

를 다뤘다면,

5장은

그럼 우리 시스템에서는 무엇이 중요한가?

를 찾아가는 과정에 가깝다.

요구사항을 볼 때 단순히

무슨 기능을 만들어야 하지?

만 보는 게 아니라

사용자는 얼마나 많은가?
 
언제 트래픽이 몰리는가?
 
이 기능이 실패하면 어떤 일이 생기는가?
 
얼마나 빨라야 하는가?
 
데이터가 유실되어도 되는가?
 
장애가 나도 계속 동작해야 하는가?
 
앞으로 얼마나 자주 변경될 기능인가?

같은 질문을 추가로 던지는 것이다.

그 질문의 답에서 아키텍처 특성이 나온다.

결국 아키텍처 특성 식별이란

한 줄로 정리하면,

기능 요구사항과 비즈니스 맥락 속에 숨어 있는 구조적 제약을 찾아내고, 그중 시스템의 성공에 정말 중요한 것만 골라내는 과정이다.

그리고 요구사항을 볼 때

"이 기능을 어떻게 구현하지?"

에서 한 발 더 나아가

이 기능은 얼마나 많이 사용될까?
 
실패하면 어떤 일이 일어날까?
 
얼마나 빨라야 할까?
 
트래픽은 일정할까?
 
데이터를 잃어도 될까?
 
이 요구사항 때문에 시스템 구조가 바뀌어야 할까?

를 묻는 것이 결국 아키텍처적인 사고에 가까운 것 같다.

4장에서 아키텍처는 무엇을 중요하게 볼지 결정하는 기술이라고 했다면,

5장은 그보다 한 단계 앞에서

무엇을 중요하게 봐야 하는지를 발견하는 기술

에 가까운 듯.

레퍼런스

• Mark Richards, Neal Ford, Fundamentals of Software Architecture — Chapter 5, Identifying Architectural Characteristics