아키텍처 특성? 나쁜 것 중에서 제일 나은 아키텍처를 선택하라

소프트웨어 아키텍처 101 - YES24

 

트레이드오프와 최고의 제일 나은 아키텍처

최고(best)의 아키텍처를 고집하지 말고 나쁜 것 중에서 제일 나은(least worst) 아키텍처를 선택하세요
- 소프트웨어 아키텍처 101, p.99.

제목과 위의 인용문에 있듯 나쁜 것중에 제일 나은(least worst) 아키텍처를 선택하는 것이 핵심 내용이다.

Generic 프로그래밍을 너무 좋아한 나머지 아키텍처에서도 Generic 아키텍처를 찾는 사람들이 있는데, 이는 가장 흔한 안티 패턴이라고 한다. 사실 조금만 생각해보면 당연한 것이, 아키텍처는 건물의 설계와 같다. 세상에 어떠한 건물의 설계가 모든 경우의 수를 다 맞춰줄 수 있는가 생각해보면 알 수 있다. 그런 것은 없다. 즉, 어떤 것을 맞추다 보면 다른 쪽에 문제가 생기는 트레이드오프가 있기 때문이다.

물론, 어느 한쪽에 Fit하진 않지만 전체를 아우를 수 있는 아키텍처 설계를 할 수 있다. 하지만 어플리케이션의 요구 수준을 충분히 만족시키지 못할 가능성이 높다. 더군다나 우리는 일반적으로 하나의 아키텍처에서 전혀 성격이 다른 애플리케이션들을 동작시켜야 할 일이 없다. 뿐만 아니라 전체를 아우르다 보면 덩치가 커져서 또 다른 트레이드오프가 생겨나게 된다. 

그리고, 아키텍처를 설계하는데 있어서 설계 시점과 요구도의 불완전함 등등 여러 가지 요소에 의해 모호한 점이 많을 수밖에 없는데, (뒤에 다루겠지만 아키텍처 특성 또한 모호하다) 이 때문에 완벽한? 혹은 최고의 아키텍처에 집착하지 말고 가장 나은(least worst) 아키텍처를 선택하라고 하는 것이다.

---

아키텍처 특성이란?

여기서는 아키텍처의 특성을 다음과 같이 정의한다

주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들

뭔가 이상하다. 도메인 기능과 직접적인 관련이 없는 모든 것들이라니? 비즈니스 로직과 상관이 없네? 그렇다면, 별로 안 중요한 건가?라는 생각을 할 수 있다.

하지만, 도메인 기능을 설계/시스템 차원에서 보다 잘 만들 수 있게 하기 위한 필수적인 작업인 것이다. 도메인 기능을 아무리 잘 구현한다한들 그 기반이 엉터리라면 그것은 기초 공사가 똑바로 되지 않은 건물과 같은 것이다. 운이 좋으면 당분간 문제가 없겠지만(없는 듯 보이겠지만) 이내 그것은 엄청난 후폭풍으로 나타날 것이다.

아무튼 이러한 측면에서, 아키텍처 특성은 아래의 세 가지 기준을 충족해야 한다고 한다.

• 비도메인(non-domain) 설계 고려사항을 명시한다
• 설계의 구조적 측면에 영향을 미친다
• 애플리케이션 성공에 (절대적으로) 중요하다

즉, 위의 기준들을 생각하며, 각각의 아키텍처 특성을 보고서 애플리케이션에 맞는 설계를 해야 하는 것이다.

---

아키텍처 특성 종류

여기에 나열할 특성들이 세상 모든 아키텍처 특성은 아니다. 소프트웨어 분야 특성상 계속 발전해 나가는 것도 있고, 애플리케이션에 따라 다뤄야 할 특성들이 다른데, 이 애플리케이션은 그 규모와 범위가 방대하기 때문이다.

또, 국제 표준이라는 것이 없기 때문에, 위에 나열했던 아키텍처 특성의 기준들을 떠올리며 아래의 것들을 레퍼런스 삼아 필요에 따라 특성을 추가할 수 있어야 한다.

참고로, 용어들을 쓸 때 영어에 볼드체를 사용했는데, 번역된 말보다 영어로 기억하는게 그 '의미'를 이해하는데 훨씬 낫기 때문이다.

운영(operational) 아키텍처 특성

• 운영/DevOps와 많은 부분이 중첩되는 특성 (같이 공유합시다)
• 아래 표의 용어와 정의를 보면, 몇몇은 그 나물의 그 밥 같지만, 각각 조금씩 포인트가 다르다 (물론, 모호할 수 있다)

용어	정의
가용성 (availability)	시스템이 얼마나 오랫동안 사용 가능해야 하는가?
연속성 (continuity)	재해 복구 능력 (DR: Disaster Recovery)
성능 (performance)	stress test, peak 분석, 기능 사용 빈도 분석, 필요 용량, 응답 시간 등등 (특징: 측정하려면 오래 걸림)
복구성 (recoverability)	장애 발생 시 얼마나 신속하게 시스템을 재가동 시켜야 하는가? (가용성, 연속성과 밀접한 관련) 백업 전략과 하드웨어 다중화 요건에 영향을 미친다
신뢰성/안전 (reliability/safety)	시스템에 Fail-safe가 필요한가? 시스템 실패 시 Cost가 큰가?
견고성 (robustness)	프로그램 실행 중 외부 요인(인터넷 접속 끊긴, 정전, 하드웨어 실패)에 의해 발생하는 에러 및 경계 조건을 감당하는 능력
확장성 (scalability)	유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력

 

구조(structure) 아키텍처 특성

• 좀 더 쉽게 말하면, 코드의 구조에 대한 특성이라고 보면 된다.
• 모듈성, 커플링 제어, 가독성, 내부 품질 평가 등에 대한 것이다.

용어	정의
설정성 (configurability)	end user가 소프트웨어 설정을 쉽게 바꿀 수 있는가?
신장성 (extensibility)	새로운 기능 삽입이 용이한가?
설치성 (installability)	지원하는 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있는가?
활용성/재사용 (leverageability/reuse)	공통 컴포넌트를 여러 제품에서 활용할 수 있는가?
지역성 (locality)	다국어 지원 (특히 멀티바이트 문자(한국어 등) ~ 화폐 단위 등)
유지 보수성 (maintainability)	시스템을 얼마나 쉽게 변경/개선할 수 있는가?
이식성 (portability)	멀티플랫폼 지원 (OS뿐만 아니라 서로 다른 벤더의 DB 등)
지원성 (supportability)	어느정도의 기술 지원이 필요한가? 예를 들어, 시스템 에러 발생 시, 디버깅을 위해 어느정도 수준의 기능이 필요한가?
업그레이드성 (upgradeability)	버전 업데이트/업그레이드를 쉽고 빠르게 할 수 있는가?

 

아키텍처 공통 특성

• 위의 두 범주와 다르게 따로 분류하기 어려운 특성들이다 (중요 설계 제약조건/고려사항 등)

용어	정의
접근성 (accessibility)	장애인등 모든 유저가 접근하는데 불편함이 없는가?
보관성 (archivability)	데이터를 별도로 archiving 해야 하는가? 아니면 일정 시간 경과 후 삭제해야 하는가?
인증 (authentication)	유저가 본인이 맞는 것을 증명하기 위해 필요한 보안 요구사항 수준
인가 (authorization)	유저가 어플리케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구사항 수준
합법성 (legal)	시스템 운영상 법적 제약조건이 있는가? 어플리케이션 개발/배포 방법에도 법적 규정이 있는가?
프라이버시 (privacy)	회사 내부의 트랜잭션을 외부에 드러내지 않는 기능 (암호화 트랜잭션 등) 등
보안 (security)	데이터를 암호화 후 D에 보관해야 하는가? 통신 암호화가 필요한가? 원격 유저 엑세스는 어떤 종류의 인증이 필요한가? 등
사용성/성취성 (usability/achievability)	유저가 원하는 목적을 달성하기 위해 필요한 교육/훈련 수준 - 쉽게 말해 러닝커브, 사용성이 좋은가?

 

소프트웨어 아키텍처는 모호한 것들로 가득하다, 하지만...

서두와 특성을 설명할 때, 이 모호함에 대해서 계속 설명했지만, 위의 테이블들을 보고 나서 더 모호함 하다고 느꼈을 수 있다. 사실 표준도 없고, 애플리케이션의 요구사항과 특성에 따라서 기준이 천차만별이고, 따라서 자체 기준을 세워야 하는 경우가 있는데, 이때 단순화를 위해 선택하는 단어 또한 사람마다 이해하고 있는 뉘앙스가 다를 수 있어 모호할 수 있다.

 

따라서, 적어도 같이 설계하고, 개발하는 집단 혹은 도메인 안에서라도 서로 오해하는 일이 없도록 최대한 보편적인 언어를 정해서 사용해야 한다. (프로그래밍하면서 이름짓기에 대부분의 시간을 쓰는 것과 같은 이치다)

즉, 커뮤니케이션이 중요한 것이다.

 

결론은 이러한 소프트웨어 아키텍처의 특성을 생각하며, 트레이드 오프를 고려하며 "성공적인 애플리케이션 서비스/유지보수"에 맞는 가장 나은(least worst) 아키텍처를 선택하는 능력을 기르는 것이 중요하다.