[소프트웨어 아키텍처 101] CHAPTER 4, 5. 아키텍처 특성 정의와 식별

지난주는 시간 관계상 Chapter4에서 소개된 아키텍처의 특성을 많이 다루지 못하여 스터디 범위가 Chapter4, 5가 되었다. 과연 책에서 언급되는 아키텍처 특성과 멘토님이 설명해주시는 특성은 뭐가 다르고 무엇이 중요할까? 그리고 책에서 소개하는 아키텍처 설계 방법은 특성과 어떻게 연결될까? 리마인드하며 쓴 이 글을 통해 고민할 포인트가 많았던 회차였구나 싶다.

너무 긴글은 호흡이 딸리니 최대한 짧고 굵게 시작!

💡 ‘내 생각’부분은 스터디때 바로바로 적었던 내용이라 올바른 정보가 아닐 수 있음을 전달드립니다. 또한 이 포스팅은 스터디한 내용 리마인드하는 개념이므로 정확하지 않은 정보가 있을 수 있음을 안내드립니다.

 

---

 

Chapter4. 아키텍처 특성 정의

지난주 스터디는 ‘모듈성’과 ‘아키텍처 특성 정의’에 대해 이야기 나눴다. 모듈성은 아키텍처의 핵심 특성 중 하나로 시스템 간에 최소한의 의존성을 가지도록 독립적이고 자율적인 구성 요소로 분리하는 개념이다. 이를 통해 독립적인 모듈 개발, 테스트, 유지보수 및 확장이 용이해지게 된다. 책에서는 모듈성을 저수준 코드의 특성이라고 이야기한다. 그렇다면 넓은 범위의 고수준 특성은 무엇이 있을지 알아보자.

 

저수준과 고수준 관계

저수준(Low Level)

저수준은 구체적인 구현 세부사항, 기술적 메커니즘, 코드 수준의 디자인에 관련된 개념이다.

• 구체적인 구현 세부사항에 집중
• 기술 스택에 밀접하게 관련됨
• 코드 레벨에서 직접 다루는 문제들
• ‘어떻게(How)’ 구현할 것인가에 집중

예시

1. 모듈성 : 코드가 얼마나 잘 모듈화되어 있는지 (클래스/함수 설계, 인터페이스 정의 등)
➡️ 구체적인 구현 세부사항에 집중
➡️ 기술적 메커니즘

 

2. 코딩 표준 : 코딩 컨벤션, 네이밍 규칙 등
➡️ 코드 레벨에서 직접 다루는 문제들
➡️ 기술 스택에 밀접하게 관련됨

 

3. 알고리즘 효율성 : 특정 기능 구현의 시간/공간 복잡도
➡️ 구체적인 구현 세부사항에 집중

 

4. 데이터 구조 선택 : 특정 문제에 적합한 자료 구조 (배열, 해시맵, 트리 등)
➡️ ‘어떻게(How)’ 구현할 것인가에 집중

 

5. 메모리 관리 : 메모리 할당/해제 전략
➡️ 코드 레벨에서 직접 다루는 문제

 

고수준(High Level)

고수준은 전체 시스템의 구조, 아키텍처 결정, 비즈니스 요구사항 충족에 관련된 더 추상적인 개념이다.

• 시스템 구조와 설계 원칙에 집중
• 비즈니스 목표와 직접 연관됨
• 추상적이고 개념적인 수준에서 다루는 문제들
• '무엇을(What)' 해결할 것인가에 초점

예시

1. 확장성 : 증가하는 부하를 처리하기 위해 시스템을 확장하는 능력
➡️ 시스템 구조와 설계 원칙에 집중
➡️ 추상적이고 개념적인 수준에서 다루는 문제들

 

2. 탄력성 : 장애 상황에서 시스템이 복구되는 능력
➡️ '무엇을(What)' 해결할 것인가에 초점
➡️ 비즈니스 목표와 직접 연관됨

 

3. 유지보수성 : 시스템이 변화에 얼마나 잘 적응할 수 있는지
➡️ 추상적이고 개념적인 수준에서 다루는 문제들

 

4. 상호운용성 : 다른 시스템과 얼마나 잘 통합되는지
➡️ 시스템 구조와 설계 원칙에 집중

 

5. 보안 : 시스템이 보안 위협에 대응하는 방식
➡️ '무엇을(What)' 해결할 것인가에 초점

 

실제 예시

실제 웹 애플리케이션을 개발한다고 하였을 때 저수준과 고수준에서 고려해야 할 사항들은 무엇이 있을까?

 

저수준 고려사항

1. 코드 모듈화 : 프론트엔드 컴포넌트 설계, 백엔드 서비스 설계
➡️ 기술적 메커니즘

 

2. 데이터베이스 스키마 설계 : 테이블 구조, 인덱싱 전략
➡️ 구체적인 구현 세부사항에 집중

 

3. HTTP 요청 처리 메커니즘 : 비동기 처리 패턴, 캐싱 전략
➡️ 기술적 메커니즘

 

4. 특정 API 엔드포인트 구현 : 인증/인가 로직, 입력 유효성 검사
➡️ 코드 레벨에서 직접 다루는 문제들

 

고수준 고려사항

1. 마이크로서비스 vs 모놀리식 아키텍처 선택
➡️ 추상적이고 개념적인 수준에서 다루는 문제들

 

2. 클라우드 배포 전략 (멀티 리전, 가용성 영역 등)
➡️ 시스템 구조와 설계 원칙에 집중

 

3. 부하 분산 및 자동 확장 정책
➡️ '무엇을(What)' 해결할 것인가에 초점

 

4. 장애 복구 전략 (서킷 브레이커, 폴백 메커니즘)
➡️ 비즈니스 목표와 직접 연관됨

 

5. 데이터 일관성 모델 (강한 일관성 vs 최종 일관성)
➡️ 추상적이고 개념적인 수준에서 다루는 문제들

 

저수준과 고수준 관계

저수준과 고수준은 상호 보완적인 관계이다. 고수준 아키텍처 결정은 저수준 구현에 영향을 미치고, 마찬가지로 저수준 결정은 고수준 목표 달성에 영향을 준다.

• 고수준에서 선택한 마이크로서비스 아키텍처는 저수준에서 서비스 간 통신 방식, API 설계 등에 영향을 준다.
• 저수준에서의 효율적인 코드 모듈화와 재사용성은 고수준에서의 유지보수성과 확장성 목표 달성에 기여한다.

결국 고수준 원칙을 유지하면서 저수준 구현이 이를 잘 지원하도록 설계하는 것이 중요하다.

 

4.1 아키텍처 특성

과거에도 아키텍처 특성을 체계화하려는 시도는 있었지만 아직도 보편적인 표준은 따로 없으며 조직마다 자체적으로 해석하여 용어를 정의합니다. 또한 빠르게 변화하는 소프트웨어 생태계 특성상 새로운 개념, 용어, 측정, 검증이 계속 출현하기 때문에 계속 새로운 방식으로 아키텍처 특성을 정의하게 됩니다. -92p

 

책에서도 말하고 있듯 실무자들 사이에서 많이 언급될 수 있는 ‘가용성, 성능, 보안’ 같은 특성들을 제외하고 보편적인 표준이 없다. 그래서인지 책에서 소개하는 아키텍처 특성과 멘토님께서 소개하신 특성의 공통분모가 적을 수밖에 없는 것도 이해가 간다. 명세기 스터디 내용을 되짚어보는 글이니 멘토님께서 소개한 특성들만 다뤄보고자 한다.

책과 멘토님께서 공통적으로 언급한 아키텍처 특성

 

• 성능(Performance)
  • 시스템이 비즈니스 요청을 처리하는 데 걸리는 시간
  • 대용량의 데이터 처리가 요구되거나, 빠른 계산/처리가 중요한 경우
  • 예시 : 온라인 결제 시스템에서 주문이 들어왔을 때 결제 승인까지의 처리 속도가 매우 중요합니다.
• 가용성(Availability)
  • 시스템이 정상적으로 운영되는 시간의 비율이며, 일반적으로 99.9%와 같은 수치로 표현됨
  • 24시간 연중무휴 서비스를 제공해야 하는 시스템
  • 예시 : 온라인 뱅킹 시스템은 항상 사용 가능해야 하므로, 가용성이 매우 중요한 요소입니다.
• 확장성(Scalability)
  • 사용자의 증가나 요청 건수가 늘어나더라도 성능, 응답성, 오류율을 일정하게 유지할 수 있는 능력
  • 사용자 기반이 지속적으로 늘어나는 시스템, 또는 급격한 트래픽 증가에 대비해야 하는 경우
  • 예시 : 소셜 미디어 플랫폼은 사용자가 늘어나도 일관된 성능을 유지해야 한다.
• 복구 가능성(Recoverability)
  • 시스템이 장애 발생 후 이전 상태에서 빠르게 복구할 수 있는 능력
  • 시스템 충돌이나 장애 발생 시 데이터 손실 없이 빠르게 복구가 필요한 경우
  • 예시 : 데이터베이스 백업 및 복구 시스템을 통해 장애 후에도 서비스가 신속하게 복구될 수 있습니다.
• 보안(Security, 암시적 특성)
  • 민감한 데이터와 기능에 대한 접근을 제한하고, 위협으로부터 보호하는 능력
  • 개인정보 보호, 금융 거래 등 보안이 최우선 과제인 시스템
  • 예시 : OAuth 인증 및 데이터 암호화를 통해 사용자의 정보를 보호하는 웹 애플리케이션이 이에 해당합니다.
• 유지보수성(Maintainability, 암시적 특성)
  • 시스템 변경, 버그 수정, 기능 개선 등을 쉽게 할 수 있도록 구성된 정도
  • 지속적인 업데이트와 확장이 필요한 장기 운영 시스템
  • 예시 : 모듈화된 코드 구조나 클린 아키텍처를 채택한 애플리케이션은 유지보수성이 높습니다.

 

멘토님께서 언급하신 특성

• 응답성(Responsiveness)
  • 사용자가 요청 후 응답을 받기까지 걸리는 시간
  • 사용자 경험이 중요한 어플리케이션에서, 즉각적인 피드백이 요구될 때
  • 예시 : 검색 엔진에서 사용자가 검색어를 입력했을 때 빠르게 결과를 보여주는 것이 중요합니다.
• 내결함성(Fault Tolerance)
  • 치명적인 오류가 발생하더라도 시스템의 다른 부분이 정상적으로 작동하는 능력
  • 일부 모듈 또는 컴포넌트가 장애가 발생해도 전체 시스템이 마비되지 않아야 하는 경우
  • 예시 : 분산 시스템에서 일부 서버가 다운되더라도 나머지 서버가 요청을 처리할 수 있도록 구성합니다.
• 탄력성(Elasticity)
  • 예상치 못한 또는 예측된 극한 부하 상황에서 신속하게 자원을 확장하거나 축소할 수 있는 능력
  • 단기간에 사용자 수가 급증하거나 특정 이벤트 시 부하가 급증할 때
  • 예시 : 온라인 쇼핑몰은 블랙 프라이데이 같은 이벤트 시 갑작스러운 방문자 증가에 대비해 탄력적으로 자원을 할당합니다.
• 데이터 무결성(Data Integrity)
  • 시스템 내 데이터가 항상 정확하며, 손실 없이 유지되는 것
  • 금융, 의료 등 데이터의 정확성이 절대적으로 중요한 분야
  • 예시 : 은행 거래 데이터베이스는 어떤 상황에서도 거래 데이터가 손실되지 않아야 한다.
• 데이터 일관성(Data Consistency)
  • 여러 데이터 저장소나 테이블 간의 데이터가 서로 동기화되어 일관성 상태를 유지하는 것
  • 분산 시스템이나 복제 데이터베이스 환경에서 데이터의 신뢰성을 보장해야 할 때
  • 예시 : 전자상거래 재고 관리 시스템에서 모든 데이터베이스에 재고 정보가 동일하게 반영되어야 합니다.
• 적응성(Adaptability)
  • 시스템이 변화하는 환경이나 새로운 기능 요구사항에 신속하게 적응할 수 있는 능력
  • 빠르게 변화하는 시장이나 기술 환경에 대응할 필요가 있는 경우
  • 예시 : 모바일 앱이 운영체제 업데이트나 새로운 사용자 요구에 따라 기능을 쉽게 수정하거나 추가할 수 있어야 합니다.
• 동시성(Concurrency)
  • 여러 사용자의 요청을 동시에 처리하는 능력
  • 다수의 사용자가 동시에 접속하는 시스템에서, 요청을 처리할 필요가 있을 때
  • 예시 : 멀티플레이어 게임 서버는 동시에 다수의 플레이어의 입력을 받아 처리해야 합니다.
• 상호운용성(Interoperability)
  • 서로 다른 시스템 간에 데이터를 주고 받으며 협력할 수 있는 능력
  • 외부 시스템이나 서비스와 연동하여 비즈니스 요청을 처리해야 할 때
  • 예시 : ERP 시스템과 CRM 시스템이 서로 데이터를 교환하며 협업하는 경우가 이에 해당합니다.
• 확장 용이성(Extensibility)
  • 시스템에 새로운 기능이나 서비스를 쉽게 추가할 수 있는 구조적 특성
  • 시간이 지남에 따라 추가 기능이 필요해질 가능성이 있는 시스템
  • 예시 : loT 플랫폼은 새로운 장치나 기능을 모듈 형태로 쉽게 통합할 수 있어야 합니다.
• 배포 용이성(Deployability)
  • 소프트웨어를 배포할 때 필요한 절차, 빈도, 그리고 배포 위험도를 의미
  • 자주 업데이트하거나 신속하게 버그를 수정해야 하는 환경
  • 예시 : CI/CD 파이프라인을 통해 작은 변경사항을 자주 배포하는 시스템에서 중요합니다.
• 테스트 용이성(Testability)
  • 시스템의 기능을 충분하고 쉽게 테스트할 수 있는 정도
  • 개발 과정에서 품질 보증과 오류 예방을 위해 자동화 테스트가 중요한 경우
  • 예시 : 단위 테스트와 통합 테스트가 잘 구성된 애플리케이션은 버그 발견과 수정이 용이합니다.
• 추상화(Abstraction)
  • 시스템 내 각 구성 요소가 다른 부분과 격리되어 독립적으로 관리될 수 있는 정도
  • 복잡한 시스템에서 각 모듈 간의 의존성을 줄이고 유지보수를 쉽게 해야 할 때
  • 예시 : API 기반의 마이크로서비스 아키텍처는 각 서비스가 독립적으로 개발되고 배포될 수 있도록 추상화되어 있습니다.
• 워크폴로(Workflow)
  • 복잡한 업무 처리를 위해 여러 서비스나 모듈이 순차적 혹은 병렬적으로 협력하는 프로세스를 관리하는 능력
  • 여러 단계를 거쳐야 하는 비지니스 프로세스
  • 예시 : 전자상거래 주문 처리 시스템은 결제, 재고 확인, 배송 요청 등 여러 단계를 하나의 워크플로로 관리합니다.
• 구성 가능성(Configurability)
  • 다양한 설정과 환경에 맞게 시스템을 쉽게 구성하고 업데이트할 수 있는 능력
  • 여러 고객이나 환경에 따라 다른 설정이 필요한 경우
  • 예시 : 사용자 맞춤형 대시보드가 다양한 설정 옵션을 제공하여 각 사용자의 요구에 맞게 구성될 수 있어야 합니다.
• 타당성(Feasibility, 암시적 특성)
  • 아키텍처 설계 시 시간, 예산, 개발자의 역량 등의 제약을 고려하는 특성
  • 제한된 리소스와 짧은 일정 내에 제품을 출시해야 하는 스타트업이나 프로젝트
  • 예시 : MVP(최소 기능 제품) 개발 시, 복잡한 기능보다는 빠른 출시와 개발 난이도를 고려하여 설계합니다.
• 관측성(Observability, 암시적 특성)
  • 시스템의 건강 상태, 성능, 오류 등을 모니터링하고 분석할 수 있는 능력
  • 장애를 조기에 발견하고, 성능 개선 및 문제 해결이 필요한 운영 환경
  • 예시 : 로그 수집 도구와 모니터링 시스템을 통해 실시간으로 시스템 상태를 확인할 수 있습니다.

책에서 언급한 특성

범위별 특성 종류만 소개하겠습니다. 자세한 내용은 '소프트웨어 아키텍처 101'를 참조하여 주세요.

 

운영 아키텍처 특성

• 가용성(Availability)
• 연속성(Continuity)
• 성능(Performance)
• 복구 가능성(Recoverability)
• 신뢰성/안전(Reliability/Safety)
• 견고성(Robustness)
• 확장성(Scalability)

구조 아키텍처 특성

• 설정성(Configurability)
• 신장성(Extensibility)
• 설치성(installability)
• 활용성/재사용(leverageability/reuse)
• 지역성(locality)
• 유지보수성(maintainability)
• 이식성(portability)
• 지원성(supportability)
• 업그레이드성(upgradeability)

아키텍처 공통 특성

• 접근성(Accessibility)
• 보관성(Archivability)
• 인증(Authentication)
• 인가(Authorization)
• 합법성(Legal)
• 프라이버시(Privacy)
• 보안(Security, 암시적 특성)
• 사용성/성취성(Usability/Achievability)

 

Q1. 가장 기억에 남는 아키텍처 특성이 있으신가요? 있다면 왜 가장 기억에 남으시나요?

“아키텍처 특성은 어떻게 나열해도 불완전한 목록이 될 수밖에 없고, 소프트웨어마다 고유한 팩터를 바탕으로 중요한 아키텍처 특성이 도출될 수도 있습니다. 또한, 지금까지 설명한 용어는 대부분 의미가 미묘하거나, 객관적으로 정의하기 어렵거나, 다소 부정확하고 모호한 부분도 있습니다.“

 

내 생각

챕터 5를 읽을 때 보았던 ‘확장성’은 동시 유저 성능을 나타낸다고 하였는데 코드레벨단에 관련된 특성으로 ‘확장 용이성’이 아키텍처의 특성으로 정의되어 있다고 하여 신기했습니다. 기존의 코드의 확장성은 개발자 단에서 이야기 나누는 좀더 물리적인 개념이라고 생각했었기 때문에 신기했던 것 같습니다.

 

---

 

Chapter5. 아키텍처 특성 식별

챕터5에서는 아키텍처를 구축하거나 기존 아키텍처의 타당성을 검증할 때 제일 먼저 진행하는 아키텍처 특성 식별에 대해서 이야기 한다. 아키텍처 특성을 식별하기 위해 아키텍트가 지녀야 할 지식으로 ‘도메인 관심사’, ‘요구사항’, ‘암묵적 도메인 지식’ 이렇게 세 가지가 필요한데 이번 챕터에서는 ‘도메인 관심사’, ‘요구사항’에 대해서 이야기하고 있다.

 

5.1 도메인 관심사, 요구사항에서 아키텍처 특성 추출

이번 목차에서는 아키텍트 외에 ‘도메인 이해관계자’가 등장한다. 도메인 이해관계자라 하면 전략 담당부, 제품 관리자, 마케팅 담당자, 재무 담당자 등으로 연결시켜볼 수 있을텐데 각 이해관계자들과 아키텍트가 어떤 고민에서 서로를 이해하지 못하는지 알아보자.

아키텍트는 고객 만족을 지원하기 위해 아키텍처를 어떻게 구축해야 할지 전혀 모르고, 도메인 담당자는 애플리케이션을 개발하는데 가용성, 상호운용성, 학습성 같은 것들을 왜 고민해야 하는지 답답합니다. - 103p

 

아키텍트, 도메인 이해관계자 둘이 고민을 좁히려면 도메인 관심사를 아키텍처 특성으로 옮겨야 하는데 아래 표는 일반적인 도메인 관심사와 이를 뒷받침하는 아키텍처 특성을 정리한 표이다.

도메인 관심사	아키텍처 특성
인수 합병	상호운용성, 확장성, 적응성, 신장성
출시 시기	민첩성, 시험성, 배포성
유저 만족	성능, 가용성, 내고장성, 시험성, 배포성, 민첩성, 보안
경쟁 우위	민첩성, 시험성, 배포성, 확장성, 가용성, 내고장성
시간 및 예산	단순성, 실행성

 

Q2. 어떤 아키텍처 특성들을 추출할 수 있을까요?

“당일 마지막 주식 가격은 무슨 일이 있어도 제시간에 제공돼야 한다" - 도메인 이해관계자

 

내 생각

• 유저 만족 : “제시간에 제공돼야 한다”를 달성해야 유저 만족도 상승
• 경쟁 우위 : “무슨 일이 있어도” 서비스를 제공하는 것이 소프트웨어의 경쟁성(?)
• 시간 및 예산 : 제시간에 제공돼지 않으면 회사, 소프트웨어의 신뢰성이 떨어지기 때문에

책

한가지 특성만이 도메인 관심사의 정점인 양 집중하면 안된다. 예를 들어 위의 요구사항에 대해 아키텍트가 ‘성능’에만을 집중했다면 분명 실패한 설계가 될 것이다. 성능외에 고려해야 할 사항은 아래와 같다.

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

 

Q3. 어떤 요구사항들이 숨겨져 있을까요? 여기서 어떤 아키텍처 특성들을 추출할 수 있을까요?

어느 아키텍트가 대학교 학사 관리 시스템에서 수강 등록을 처리하는 애플리케이션을 설계한다고 합시다.

 

내 생각

• 요구사항
  • 인수 합병 : 증가하는 요청을 처리하기 위해 시스템을 확장할 수 있는가(확장성)
  • 출시 시기 : 개강 전에 안전하게 오픈할 수 있는지(배포성)
  • 유저 만족 : 수강 신청 요청에 신청 확정까지 빠른 속도를 보장하는가(성능)
• 아키텍처 특성 : 확장성, 배포성, 성능, 탄력성

 

5.2 아키텍처 카타

수년 전, 테드 뉴어드라는 저명한 아키텍트는 초보 아키텍트가 도메인에 관한 설명을 보고 아키텍처 특성을 도출하는 연습을 할 수 있도록 아키텍처 카타(architectural katas)를 고안했습니다. 카타는 일본 전통 무술에서 비롯된 용어로, 올바른 자세와 기술을 중시하는 개인 훈련 체계입니다. -104p

 

아키텍처 카타 섹션

• 설명(description) : 시스템으로 해결하려는 전체 도메인 문제
• 유저(users) : 시스템을 사용할 것으로 예상되는 유저의 유형과 인원수
• 요구사항(requirements) : 아키텍트가 도메인 유저 및 도메인 전문가의 말을 듣고 예상하는 도메인/도메인 수준의 요구사항
• 부가 콘텍스트(additional context) : 요구사항에는 명확하게 기술되어 있지 않지만 아키텍트가 암묵적인 문제 영역에 관한 지식을 이용해 반드시 고려해야 할 여러 가지 항목들

💡 저자의 블로그에 여러가지 카타 목록을 게시하였는데 설계 연습에 참고하시면 좋습니다

 

5.3 사례 연구: 실리콘 샌드위치

실리콘 샌드위치 카타를 예로 들어 아키텍트가 요구사항을 바탕으로 아키텍처 특성을 도출하는 방법을 알아보자

설명
실리콘 샌드위치는 전국 가맹점을 보유한 샌드위치는 전국 가맹점을 보유한 샌드위치 브랜드로, (현재의 매장 서비스와 병행하여) 온라인 주문 시스템을 구축하려고 한다.

유저
앞으로 수천 명, 어쩌면 수백만 명에 달할 지도 모른다

요구사항
- 유저가 주문을 하면 샌드위치를 픽업하러 갈 시간 및 상점까지 가는 경로를 전달받는다(교통 정보가 포함된 여러 외부 지도 서비스와의 연계는 필수임)
- 배달 서비스가 가능한 지점은 기사를 보내 샌드위치를 유저에게 배달한다
- 모바일 기기에서도 이용 가능하다
- 전국 어느 지점이나 이용 가능한 프로모션/스페셜 행사를 제공한다
- 특정 지점에서만 이용 가능한 로컬 프로모션/스페셜 행사를 제공한다
- 온라인 결제, 대면 결제, 배송 시 결제 등 다양한 결제 옵션을 제공한다

부가 콘텍스트
- 샌드위치 지점은 가맹점이므로 소유자가 다 다르다
- 모회사는 머지않아 해외 시장도 진출할 계획이다
- 이 회사는 값싼 인력을 고용해 이윤을 최대화하는 것이 목표다

 

Q4. 샌드위치 카타에서 어떤 아키텍처 특성이 보이시나요? 명시적 특성과 암묵적 특성으로 분류해봅시다.

아키텍트의 임무는 엄청난 노력을 기울여 도메인 요구사항을 충족하는 전체 시스템을 코드레벨로 설계하는 것이 아니라, 설계, 특히 구조와 관련이 있거나 영향을 미치는 것들을 찾아내는 것입니다. 우선, 아키텍처 특성이 될 만한 것들을 명시적인 것과 암묵적인 것으로 분류합니다. -106p

 

내 생각

명시적 특성

• 트래픽 증가를 견뎌야 하니 ‘탄력성’
• 동시 유저 성능의 ‘확장성’
• 외부 시스템 호출을 위한 ‘신뢰성’
• 외부 시스템 호출 실패할 경우를 위한 ‘안정성’
• 어떤 기기에도 호환되어야 하니 ‘이식성’
• 커스터마이징이 될 수 있으니 ‘맞춤성’
• 아키텍처 비용에 제약을 가하므로 ‘타당성’ (?)
• 해외 시장 진출을 대비한 ‘국제화’

묵시적 특성

• 가용성, 신뢰성, 보안

책

명시적 특성

: 필요한 설계의 일부로서 요구사항 정의서에 기술되는 특성

 

1. 유저가 주문을 하면 샌드위치를 픽업하러 갈 시간 및 상점까지 가는 경로를 전달받는다(교통 정보가 포함된 여러 외부 지도 서비스와의 연계는 필수임)

➡️ 외부 지도 서비스는 곧 연계 지점에 해당하므로 ‘신뢰성’

➡️ 서드파티 시스템 호출 실패할 경우 전체 시스템에 타격을 입으므로 ‘안정성’

 

2. 모바일 기기에서도 이용 가능하다
➡️ 웹 애플리케이션과 다양한 네이티브 웹 애플리케이션 중 어느 쪽으로 개발할 것인가에 대한 방향성이 중요하므로 ‘이식성’

 

3. 전국 어느 지점이나 이용 가능한 프로모션/스페셜 행사를 제공한다, 특정 지점에서만 이용 가능한 로컬 프로모션/스페셜 행사를 제공한다

➡️ 프로모션과 스페셜 행사에 관한 커스터마이징을 의미하므로 ‘맞춤성’

 

4. 온라인 결제, 대면 결제, 배송 시 결제 등 다양한 결제 옵션을 제공한다

➡️ 온라인 결제이니 ‘보안’

 

5. 샌드위치 지점은 가맹점이므로 소유자가 다 다르다

➡️ 이 요구사항은 아키텍처 비용에 제약을 가하므로, 아키텍트는 단순하거나 기능이 조금 빠진 아키텍처로도 충분하지 결정하는 ‘타당성’이 필요하다

 

6. 모회사는 머지않아 해외 시장도 진출할 계획이다

➡️ 해외 시장 진출 계획으로는 ‘국제화’

 

묵시적 특성

: 요구사항 정의서에 따로 기술되지 않는 특성으로 중요한 설계 요소로 꼽는 아키텍처 특성

• 마땅히 사이트에 접속할 수 있어야 하므로 ‘가용성’
• 시스템이 문제없이 사용할 수 있어야 하므로 ‘신뢰성’
• 공통적인 암묵적 특성인 '보안’

•  

---

 

마무리

단순 요약보다는 스터디때 이야기 나눴던 주제에 대한 생생한 TMI를 쏟아내고 싶었는데 건조하다 못해 쫙쫙 갈라지는 요약글 같이 되어버렸다… 어떻게 하면 보는 사람들도 쭉쭉 읽어가는 글을 쓸 수 있을까?

“많이 써봐야지 어쩌겠어~”

 

 

그런 의미로, 다음주 주제는 chapter 6, 7이지만 이번 챕터의 내용에서 나온 kata를 연습할 듯 하다. 저자의 블로그에 올라온 카타 중에 Going Green 아키텍처 문제가 공유되었는데 이 글을 보시는 독자분들도 아래 Worksheet를 참고하여 아키텍처 특성을 도출하는 연습을 해보시는건 어떠세요?

Arichitecture Characteristics Worksheet

Architectural Katas - Going Green