[소프트웨어 아키텍처 101] Ch.5 아키텍처 특성 식별

1. 도메인 관심사에서 아키텍처 특성 도출

도메인 이해관계자와 협력해서 주요 아키텍처 특성을 정의하는 한 가지 팁은, 최종 목록을 가능한 한 짧게 하는 것이다. 아키텍처에서 가장 흔한 안티패턴 중 하나가, 모든 아키텍처 특성을 지원하는 제네릭 아키텍처를 설계하려는 것이다. 아키텍처 특성의 개수에 연연하지 말고 가급적 설계를 단순화하는게 좋다.

 

대부분의 아키텍처 특성은 핵심 도메인 이해관계자들의 의견을 듣고 도메인 관점에서 무엇이 중요한지 의견을 교환하면서 정리된다. 여기서 문제는 아키텍트와 도메인 이해관계자들이 서로 다른 언어로 말을 한다는 것이다. 예를 들어, 아키텍트는 확장성, 상호운용성, 내고장성, 학습성, 가용성을 운운하는데, 도메인 이해관계자는 인수 병합, 고객 만족, 출시 시점, 경쟁 우위를 논하는 식이다. 서로 말이 안 통하기 때문에 각자 상대방을 이해하기가 어렵다.

예를 들어, 도메인 이해관계자가 ‘당일 펀드 종가는 무슨 일이 있어도 제시간에 마감돼야 한다’는 요구사항을 제시했다고 가정해보자. 만약 이 말을 들은 아키텍처가 오로지 성능이 중요한 것이라 착각하고 성능에만 집중한다면 다음과 같은 이유로 실패할 것이다.

• 필요한 시점에서 시스템을 사용할 수 없다면 얼마나 빠른 지는 중요하지 않다.
• 도메인이 더 커지고 펀드가 많이 유입되면 제시간에 종가 계산을 마칠 수 있도록 시스템 규모를 확장할 수 있어야 한다.
• 시스템은 가용성과 더불어 펀드 종가 계산 도중 시스템이 멎는 불상사가 생기지 않도록 안정성도 보장되어야 한다.
• 펀드 종가 계산이 약 85% 완료된 상태에서 시스템이 다운되면? 즉시 시스템을 복구해서 가장 마지막에 펀드 종가가 계산된 시점부터 다시 실행해야 한다.
• 시스템은 빠른 것도 중요하지만 펀드 종가는 정확하게 계산되어야 한다.

 

2. 요구사항에서 아키텍처 특성 도출

예상 유저수와 그에 따른 확장 문제는 보통 도메인 관심사에서 빠지지 않는 단골 손님이다. 아키텍트가 알고 있는 도메인 지식에서 도출되는 특성들도 있는데, 이것이 아키텍트가 도메인 지식을 갖고 있으면 이로운 이유이다.

예를 들어, 어느 아키텍트가 대학교 학사 관리 시스템에서 수강 등록을 처리하는 어플리케이션을 설계한다고 가정하자. 계산 편의상, 총 학생 수는 1,000명이고 학생 일인 당 10시간의 수강 신청을 한다고 보면, 등록 기간 중 학생들의 시스템 이용 시간이 고루 분산되리라는 전제 하에 시스템 규모를 일정하게 설계해야 하는가? 아니면, 보통 대학생들의 성향과 습관에 대한 지식을 바탕으로 마감 10분 전부터 1,000명의 학생 모두가 수강 신청을 하려고 달려들어도 문제없는 시스템을 설계해야 하는가? 학생들의 성향을 안다면 답은 너무 쉽다.