아키텍처 - 아키텍처 사고

- 출처: 이 글은 도서 '소프트트웨어 아키텍처 101'을 참조하여 작성된글입니다.

- 개요

아키텍처 사고는 단순히 '아키텍처를 생각하는것'이라고 많은 오해를 하지만 아키텍처 관점에서 사물을 바라볼줄 알아야 하는것을 의미한다. 아키텍트의 사고방식은 크게 4가지 사고방식으로 나눌 수 있다.

 

• 아키텍처와 설계 차이의 이해
• 기술의 깊이보다는 폭넓은 지식의 이해
• 다양한 솔루션과 기술간의 Trade off 이해
• 비즈니스 동인(행동을 촉발시키는 내적 원인의 총칭)의 중요성이해(이 글에서는 다루지 않는다.)

---

- 아키텍처 vs 설계

아키텍처와 설계의 차이점은 모호한 경우가 많다. 이를 이해하기 위해 전통적인(기존 시각의) 아키텍트와 개발자의 책임을 이해해보자.

 

아키텍트

 

• 비즈니스 요구사항을 분석하여 아키텍처의 특성(~성) 도출
• 이를 토대로 스타일을 선택
• 아키텍처 패턴과 스타일을 토대로 각종 컴포넌트 설계

 

위의 단계를 거쳐 아티팩트를 개발팀에 전달하면 개발팀은 아래와 같은 업무를 수행한다.

 

개발자

 

• 각 컴포넌트의 클래스 다이어그램 설계
• UI화면
• 소스코드 개발/테스트

 

이런 전통적인 시각의 아키텍트와 개발자의 책임은 한 가지 문제점을 안고 있다. 아키텍트가 개발자에게 일방적으로 전달하고 나면 개발자로부터 피드백을 받는 과정이 없다는것이다.

 

이런 문제를 해결하기 위해 폭포수 모델과는 달리 요즘은 이터레이션을 통한 발전을 통해 서로 소통하는 구조로 변화하였다. 이는 하나의 소프트웨어를 성공하기 위해 아키텍트와 개발자가 서로 소통하는것이 중요하다는것을 의미한다.

---

- 기술폭

이 세상의 지식을 3단계로 나누면 아래와 같이 나눌 수 있다.

 

1. 내가 알고 있는 것(익숙한 것)
2. 내가 모른다는 사실을 아는 것
3. 내가 모른다는 사실도 모르는 것

 

만약 이 글은 읽고 있는 독자가 자바 프로그래머라면 자바에 대한 깊은 이해를 하고 있을 것이고, 이는 1. 에 해당한다. 또한 다른 언어나 다른 언어의 특징에 대해 들어본적이 있을것인데, 이런 특징을 알고 있다고 해서 직접 코딩으로 구현할수는 없는 이러한 지식들은 2. 에 해당한다.

 

개발자는 1.에 대한 지식에 시간을 들여 이를 유지해야하지만 아키텍트는 1.을 약간 희생하는 한이 있더라도 2.에 해당하는 여러가지 솔루션이나 해결방법 및 특징을 폭넓게 알고 있는것이 중요하다.

---

- Trade off

아키텍처는 모든것이 다 트레이드오프이다. 그래서 상황에 따라 다르다는 말을 할 수 밖에 없다. 이 책을 저술한 저자 2 사람은 아래와 같은 말들을 남겼는데 이는 이런 심정을 잘 대변해주는 대목이다.

 

"아키텍처는 구글링해도 안 되는 것이다.", "아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐."

 

아래처럼 경매 참가자들이 입찰을 하는 경매 시스템을 생각해보자.

 

<Topic>

 

 

 

<Queue>

 

Bid producer 가 각 서비스로 메시지를 전달하는 방식에는 발행/구독 패턴(Topic)과 각 서비스에 Queue를 두어 점대점(Queue)으로 메시징을 전달하는 방식을 고려해볼 수 있다.

Topic 방식을 이용하면 추가적인 서비스가 해당 정보를 이용하더라도 별도의 Queue를 만들지 않아도 된다. 또한 수신자와 1:1로 소통하지 않으므로 커플링이 덜된다.

 

하지만 모든 수신자가 발행자가 정한 데이터를 이용해야하므로 커스터마이징이 불가하다. 반면 Queue 방식은 필요에 따라 자신만의 Contract(두 모듈이나 서비스가 서로 소통하기 위한 규약)을 가질 수 있다.

 

이렇듯 아키텍트는 다른 방식에 대한 트레이드 오프를 분석하여 이를 고려한 결정을 내릴 수 있어야 한다.