아키텍처 사고란 무엇입니까?
아키텍처 사고란 아키텍처 관점에서 사물을 바라보는 것입니다. 아래와 같은 활동은 아키텍처 사고에 해당합니다.
- 아키텍처와 설계의 차이를 이해하고, 어떻게 개발팀과 협력해야 할지 고민하는 것
- 기술의 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것
- 다양한 솔루션과 기술 간의 트레이드오프를 이해, 분석, 조율하는 것
- Biz Driver의 중요성을 이해하고 이를 아키텍처 관심사로 해석하는 것
아키텍처와 설계의 차이점
아키텍트처럼 사고한다는 건 Business와 Techinical Problem을 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것입니다.
전통적 역할 모델에서의 아키텍트
전통적인 프로세스에서 아키텍트는 비즈니스 요구사항을 분석해서 아키텍처 특성을 도출/정의하고 어떤 아키텍처 패턴과 스타일이 해당 문제 영역에 가장 알맞은지 선택하여 각종 컴포넌트를 생성합니다. 그리고 이를 Artifact를 통해 개발팀에 전달하고, 개발팀은 각 컴포넌트의 클래스 다이어그램을 그린 뒤 UI 화면을 만들고 소스 코드를 개발/테스트합니다.
그러나 이러한 역할 모델은 아키텍트와 개발자를 나누는 일종의 물리적 장벽을 형성합니다. 과거 아키텍트가 내린 결정이 개발, 비즈니스 환경의 변화로 개발팀에 전혀 쓸모없는 제약 사항이 작용할 수 있습니다. 그러나 이러한 역할 모델에선 아키텍트와 개발팀이 완전히 단절되어 있기 때문에 원래 의도했던 방향과 전혀 다른 결과를 낳을 수 있습니다. 따라서 올바른 아키텍처 만들기 위해 아키텍트와 개발자는 양방향 소통 관계를 정립해야 할 필요가 있습니다.
성공적인 아키텍처를 위해 요구되는 역할 모델
성공적인 아키텍처를 만들기 위해 아키텍트는 가상의 팀에 소속되어 팀 내 개발자를 멘토링/코치하는 역할을 수행할 수 있어야 합니다. 변화에 둔감하고 융통성 없는 구식 폭포수 모델과 달리, 요즘 시스템 아키텍처는 매 프로젝트 단계마다, 매 Iteration마다 변화하고 발전하기 때문에 아키텍트와 개발팀은 응집성을 가질 필요가 있으며, 아키텍처와 설계의 경계를 나누는 것이 아닌 양쪽 모두 SDLC의 일부로서 서로 동기화될 필요가 있습니다.
Technical Depth
업무를 진행하기 위해 테크니컬 깊이를 확보해야 하는 개발자와 달리 아키텍트는 아키텍트답게 사고하고 아키텍처 시각을 유지하기 위해 기술 폭을 갖추어야 합니다.
즉, 개발자는 Technical Depth를 위해 '내가 알고 있는 것'에 집중해야 할 필요가 있는 반면 아키텍트는 '내가 알고 있는 것'과 '내가 모른다는 사실을 아는 것'에 초점을 둘 필요가 있습니다.
개발자에서 아키텍트로 커리어를 전환하고자 흔히 겪는 어려움
- 지나치게 본인이 닦아온 기술의 전문성 유지에 집중한 나머지 기술 폭을 넓힐 수 없음
- 자신의 낡은 정보가 아직도 첨단을 달리고 있는 것처럼 그릇된 인식에 사로잡혀 김빠진 전문가가 될 수 있음
Frozen Caveman Anti-Pattern
꽁꽁 언 원시인 안티 패턴은 야생에서 자주 볼 수 있는 행위와 연관된 안티패턴으로 어떤 아키텍처는 언제나 가장 비합리적인 관심사로 회귀하려는 아키텍트가 이 안티 패턴에 해당됩니다. 예를 들어, 어떤 아키텍트가 과거 ~ 시스템에서 곤란한 문제를 겪었고, 이제는 해당 사고가 재발할 가능성이 희박하지만 해당 아키텍트는 이 특수한 아키텍처 특성에 극도의 경계심을 가지게 됩니다. 이 패턴에 빠지지 않기 위해 진짜 기술 리스크와 리스크처럼 보이는 기술 리스크의 차이를 이해하는 것은 아키텍트에 있어 매우 중요합니다.
트레이드오프 분석
아키텍트처럼 생각하는 것은 기술 여부와 상관없이 모든 솔루션의 트레이드오프를 분석하여 최선의 솔루션을 결정하는 것입니다. 전 세계 최고의 It 컨설팅 기업인 쏘트웍스의 저명 아키텍트 "마크 리처즈"는 다음과 같은 말을 합니다.
"아키텍처는 구글링해도 안되는 것이다."
모든 아키텍처는 트레이드오프이며 "경우에 따라 다릅니다".
경매 참가자들이 원하는 물품에 입찰을 하는 경매 시스템을 예로 들어보면, 다음과 같은 다이어그램을 그려볼 수 있습니다.
입찰이라는 행위는 Bit Producer에서 이벤트의 형태로 발행되고 이를 Bid Capture, Bid Tracking, Bid Analytics에 전달합니다. 이 경우 이벤트는 큐를 이용한 Point-to-Poing 방식이나 Topic을 사용한 Pub/Sub 방식으로 구현할 수 있습니다.
Topic 기반 Event 발행 모델의 이점
Topic을 활용한 이벤트 발행은 확장성에 있어 이점이 있습니다. Queue를 통한 이벤트 발행 방식에선 Bid Producer 서비스가 세 Queue에 모두 접속해야 하지만 Topic을 활용한 Pub/Sub 방식에선 한 토픽에 한 번만 연결하면 됩니다. 따라서 나중에 Bid 이벤트를 받아야 하는 새로운 서비스를 구현하더라도 기존 경매 시스템은 수정할 필요가 없습니다.
Topic 기반 Event 발행 모델의 한계
그러나 Topic을 이용한 방식은 event 트래킹에 있어서 어려움이 있습니다. Queue를 사용한 모델은 입찰 정보가 누구에 의해 어떻게 사용되는지 Bid Producer에서 파악할 수 있으므로 event 추적에 있어 이점이 있습니다.
또한, Topic을 이용한 방식은 보안에 있어서도 Queue 방식에 비해 불리합니다. Topic 모델의 경우 누구나 Bid 데이터에 액세스할 수 있으나 Queue 모델은 해당 큐를 수신하는 지정된 컨슈머만 액세스 가능합니다. 악의적인 서비스가 Queue를 리스닝 해서 입찰 정보가 유출될 경우, 수신하기로 약속된 서비스는 데이터를 받지 못해 데이터 유실이 발생할 것이며, 이를 경고하는 알림 메시지가 발송될 것입니다.
또한, Topic 솔루션은 한 가지 Contract만 지원하므로 Bid 데이터를 수신한 서비스는 모두 동일한 계약 및 Bid 데이터 세트를 받아야 합니다. 따라서 만일 신규 서비스에서 호가 정보를 추가할 땐, 다른 서비스도 호가 정보를 수신 방아야 합니다. 그러나 큐 모델은 채널이 제각기 나누어져 있어 계약도 분리되어 있기 때문에 그럴 일이 없습니다.
이외에도 Topic 솔루션은 Topic의 메시지 개수를 모니터링할 수 없고 자동 확장이 지원되지 않는 단점이 있습니다. 반면 큐 솔루션은 부분적 부하 분산이 가능하고 상호 독립적인 오토-스케일링이 가능합니다.
