[소프트웨어 아키텍처 101] Ch.2 아키텍처 사고

아키텍트의 사고 방식

1. 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하려면 개발팀과 어떻게 협력해야 할지 아는 것
2. 어느 정도 기술 깊이를 유지하면서 폭 넓은 기술 지식을 확보하는 것 → 그래서 아키텍트는 다른 사람들이 보지 못하는 해결책과 가능성을 떠올릴 수 있다.
3. 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고, 조율하는 것
4. 비즈니스 동인의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것

 

전통적인 아키텍트의 책임과 개발자의 책임

 

가운데의 단방향 화살표가 아키텍처와 연관된 모든 문제의 원인!

• 개발팀이 아키텍처를 변경하기로 결정한 내용이 다시 아키텍트에게 전달되는 일은 거의 없다.
• 아키텍트가 개발팀과 완전히 단절되어있기 때문이다.
• 그렇기에 두 팀이 양방향으로 소통하는 관계를 정립해야 한다.

 

그럼 아키텍처는 어디까지고 설계는 어디서부터일까?

그런 경계는 따로 없다.

 

 

세상의 모든 지식은 다음과 같이 세 가지 종류로 나누어져 있을 것이다.

• 내가 알고 있는 것
• 내가 모른다는 사실을 아는 것
• 내가 모른다는 사실조차 모르는 것

 

p. 56
아키텍트의 가치는 대부분 기술에 대한 폭넓은 이해와 그 기술을 사용해서 특정한 문제를 해결하는 것입니다.
...
아키텍트의 기술 폭은 바로 이 중간 영역이 아래 영역을 얼마나 멀리 관통하는가, 입니다.

 

p. 60
아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐.

 

트레이드오프에 대해 고민해보자.

 

토픽을 사용한다면 아키텍처 신장성(architecture extensibility)이 무엇보다 확실한 강점이다. 큐를 사용한다면 Bid Producer 서비스가 세 큐에 접속해야 하지만, 토픽을 사용하면 한 토픽에 한 번만 연결하면 된다. 나중에 입찰자가 스스로 입찰한 전체 기록을 조회할 수 있는 이력 서비스를 새로 도입하더라도 기존 경매 시스템은 전혀 고칠 필요가 없는 구조이다. Bid History 서비스가 신설되면 이미 입찰 정보가 담긴 토픽을 그냥 구독하면 된다. 그러나 큐를 사용하면 Bid History 서비스용 큐가 새로 필요하고 Bid Producer 서비스가 이 큐에 접속하려면 어떤 식으로든 변경이 불가피하다.

이 시스템에 새로운 입찰 기능을 추가할 일이 발생할 경우, 큐를 사용하면 적잖은 변경 작업이 수반되지만 토픽을 사용하면 기존 인프라를 전혀 손 댈 필요가 없다. 토픽을 사용한 모델에서 Bid Producer는 입찰 정보를 어느 서비스가 어떻게 사용하는지 전혀 모르기 때문에 커플링이 덜 된다. 반대로, 큐를 사용한 모델은 입찰 정보가 (누구에 의해) 어떻게 사용되는지 Bid Producer가 정확히 알고 있으므로 시스템이 더 커플링 된다.

 

💬여기까지만 보았을 때는 '그럼 당연히 토픽을 써야하는 것 아닌가?' 라는 생각이 들 수 있다. 그 다음을 봐보자.

 

소프트웨어 아키텍트는 토픽 솔루션은 누구나 입찰 데이터에 액세스 할 수 있으므로 데이터 보안 문제가 불거질 수 있지만, 큐 솔루션은 큐에 전달된 데이터는 큐를 수신하는 지정된 컨슈머만 액세스가 가능하다. 악의적인 서비스가 큐를 리스닝해서 입찰 정보가 유출될 경우, 정작 수신하기로 약속된 서비스는 데이터를 받지 못해 데이터 유실을 경고하는 알림 메시지가 발생할 것이다. 정리하면 토픽은 도청하기가 쉽지만 큐는 그렇지 않다.

보안 문제뿐만 아니라, 토픽 솔루션은 한 가지 계약(constract)만 지원하므로 입찰 데이터를 수신한 서비스는 모두 동일한 계약 및 입찰 데이터 세트를 받아야 한다. 하지만 큐 솔루션은 각 컨슈머가 필요로 하는 데이터에 관한 자신만의 데이터 계약을 가질 수 있다.

토픽 솔루션은 토픽의 메시지 갯수를 모니터링 할 수 없고 자동 확장(auto-scaling) 기능이 지원되지 않는 단점이 있다. 반면에 큐 솔루션은 각 큐를 따로 모니터링 할 수 있고 입찰 컨슈머 마다 개별적으로 로드 밸런싱(load balancing, 부하 분산) 로직을 적용할 수 있기 때문에 상호 독립적인 자동 확장이 가능하다. 이러한 트레이드오프는 AMQP(Advanced Message Queuing Protocol)의 구조상 (프로듀서가 메시지를 보내는) 익스체인지와 (컨슈머가 리스닝하는) 큐를 분리할 수 있으므로 프로그래밍 방식의 로드 밸런싱과 모니터링이 가능한 기술적인 특성과도 연관이 있다.

 

💬2챕터를 읽으면서 가장 흥미로웠던 내용이 바로 이 파트였다. 토픽과 큐의 장단점을 서로 비교해보고 경우에 따라 선택하는 것... 이게 바로 아키텍트가 해야 하는 일이구나. 이 선택은 언제나 "It depends!" 일테고.

 

p. 62
프로그래머는 장점은 잘 알지만 트레이드오프는 하나도 모른다. 아키텍트는 둘 다 잘 알아야 한다.

 

 

코딩 실무와 소프트웨어 아키텍처의 균형을 맞추는 Tip

병목 트랩에 빠지지 말라.

• 아키텍트가 프로젝트의 크리티컬 패스에 있는 코드의 소유권을 갖고 있는 경우 발생한다.
• 크리티컬 패스와 프레임워크 코드는 다른 개발팀 사람에게 맡기고 비즈니스 기능을 코딩하는 작업에 집중해서 1~3회 이터레이션을 수행하는 것이 좋다.

 

코딩 실무 능력 유지 방법

• 개념 증명을 자주 해보는 것
• 기술 부채 스토리나 아키텍처 스토리에 전념하는 것
• 간단한 커맨드라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화하는 것
• 코드 리뷰