최고보다는 최적을
이 글은 2016년 국내 통신 대기업의 프로젝트에 애플리케이션 아키텍트로 참여하던 당시에 작성한 글이다. 글에 언급한 기술요소들이 지금과 비교하면 조금 과거스러울 수 있다.
현장에서 아키텍트 업무를 수행하다 보니, 여러 가지 단상들이 스쳐 지나가는 요즘이다.
그중, 최신기술과 좋은 아키텍처에 관한 단상이다.
최신 기술, 진보적 기술을 많이 사용하면 좋은 아키텍처인가?
엔터프라이즈 웹기반 시스템일 경우, 대략 다음과 같은 가상의 시나리오를 생각해 볼 수 있다.
클라이언트는 HTML5와 CSS3 기반으로 가고, AngularJS와 ReactJS와 같은 자바스크립트 라이브러리를 사용해서 SPA(Single Page Application) 아키텍처를 실현하고 반응형 웹과 N-Screen에 대응하고, 서버는 MSA(Micro Service Architecture)를 차용해서 API Gateway를 만들어 공통 접점을 제공하고, 이때 통신은 REST기반 JSON 포맷을 사용한다. I/O 작업위주의 서버는 Node.js기반으로 가고 탄력적인 확장성을 위해 이벤트 시스템 부분을 클라우드 시스템을 선택적으로 도입한다. 속도를 위해 웹캐시를 전면에 배치하고 웹방화벽으로 보안성을 높인다. 대용량을 대비해서 NoSQL계열 Database를 활용하고 인메모리 기반 데이터 캐시를 사용하고 대용량 데이터의 실시간성 처리를 위해 Lamda Architecture를 구현한다. 그리고 인증은 OAuth로 처리하고, 최신 프레임워크의 OOO 기능을 사용해서 이러이러한 기능을 구현하고, 로그는 ELK 스택을 도입해서 간지 나게 만든다. 기타 등등
조금 과장된 가상의 시나리오지만, 썩 괜찮아 보이는 아키텍처 전략이다.
위에 나열된 기술들은 참신하고 좋은 기술들이다.
나 역시 이런 기술들에 매료되어 탐독하고 아키텍처에 반영하도록 권고하고 싶은 것들이다.
최신 기술이라는 게 결국 예전 기술의 단점을 극복하고 공학적으로나 개발적으로나 많은 장점이 있다 보니, 적절히 잘 조합하면 좋은 아키텍처가 될 가능성은 상당히 높아진다.
But, 여기서 중요한 것은 '최적화'이다.
아키텍처 드라이버라는 것이 있다.
아키텍처 설계에 영향을 주는 요소 또는 아키텍처 설계를 위한 요구사항을 일컫는데 다음과 같은 3가지 전제를 기반으로 한다.
1) 기능 요구사항
시스템이 수행해야 하는 기능적 요구사항.
실제 시스템이 업무적으로 수행되어야 하는 각종 기능을 말한다.
2) 품질속성
기능 요구사항 외에 성능, 가용성, 확장성, 보안 등 품질에 관련된 시스템 속성이다.
카네기 멜론 대락 SW공학센터에서는 비즈니스 품질속성, 시스템 품질속성, 아키텍처 품질속성 세 가지로 분류하고 있다.
3) 제약사항
사전에 고려되어야 하는 제약사항.
예를 들어 레거시와 연동에 따른 제약사항, 비용에 대한 제약사항, 조직에 대한 제약사항 등 많은 고려할 사하이 있다.
어떠한 아키텍처도 모든 품질속성을 만족시킬 수는 없다.
만족시켜야 할 품질속성 간 Trade-off가 존재하며 어떤 품질속성을 만족시키느냐에 따라 아키텍처 전략이 달라진다.
또한 모든 시스템에는 제약사항이라는 것이 존재한다. 사람에 대한 것일 수도 있고, 기술에 대한 것일 수도 있고, 돈에 대한 것일 수도 있고, 어찌해 볼 수 없는 레거시 시스템에 대한 것일 수도 있다.
즉 모든 이상적인 기술을 이용하지 못하는 현실적인 제약사항이 존재한다는 것이다. 그 제약사항이라는 것이 결코 유지되어서는 안 될 단죄(?)의 대상이라면, 그 타당함을 앞세워 제약사항을 무시할 수도 있겠지만 그렇지 않은 경우도 많다는 것이 문제다.
여기서 한 가지 더 언급이 필요한 아키텍처 이론을 들자면, 아키텍처 ABC라고 불리는 Architecture Business Cycle이다.
아키텍처 비즈니스 사이클은 아키텍처에 영향을 주는 요소와 아키텍처 간 주고받는 피드백의 순환관계를 묘사하는 것으로 아키텍처 수립에 있어 다양한 영향요인과 그들 간의 관계를 설명하는 모델이다.
다음과 같은 것들이 아키텍처에 영향을 주고 아키텍처 역시 이들에게 영향을 주게 된다.
1) 이해관계자
고객, 사용자, 개발자, PM, 마케팅 책임자 등 서로 다른 관점과 목표를 가진 이해관계자들 각각의 관심사와 상충되는 요구사항이 영향요인으로 작용한다.
2) 개발조직
개발을 직접 수행하는 개발조직의 특성으로 조직의 숙련도와 조직구조 등이 영향요인으로 작용한다.
3) 아키텍트의 경험
아키텍트 자신의 성공과 실패 경험, 교육과 연습이 영향요인으로 작용한다.
4) 기술환경
아키텍처 수립 당시의 기술환경으로 업계의 표준관행, 공학기법, 최신기술 등이 영향요인으로 작용한다.
아키텍처 수립에 있어 기술환경은 주요 영향요인 중 하나지만, 절대적 기준이 될 수는 없다.
내가 생각하는 좋은 아키텍처는 현실적으로 실현 가능한 아키텍처로 어느 경우에도 통용되는 '최고의 아키텍처'란 존재할 수 없고 '최적의 아키텍처'만이 존재함을 강조하고 싶다.
그리고 현장의 많은 아키텍트들이 기술적 지식과 경험 외에도, 이러한 제약사항에서 최적화를 위해 고민에 고민을 거듭하고 있다.