[Chapter 2] 아키텍처 사고

아키텍처 사고

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

 

아키텍처  대 설계

• 아키텍트와 개발자를 가르는 가상의 물리적 장벽을 허물고 두 팀이 양방향으로 소통하는 관계를 정립해야 한다.

 

기술 폭

• 아키텍트는 어느 한 가지 문제만 해결 가능한 한 가지 전문 지식보다는, 문제를 해결할 수 있는 다섯 가지 솔루션을 알고 있는 게 더 중요하다.

 

트레이드 오프 분석

• 아키텍트처럼 생각하는 것은 기술 여부와 상관 없이 모든 솔루션의 트레이드오프를 분석하여 최선의 솔루션을 결정하는 것이다.

 

토픽을 이용한 서비스 간 통신

• 장점
  • 아키텍처 신장성architecture extensibility가 무엇보다 확실한 강점이다.
  • 나중에 입찰자가 스스로 입찰한 전체 기록을 조회할 수 있는 이력 서비스를 새로 도입하더라도 기존 경매 시스템은 전혀 고칠 필요가 없는 구조이다. Bid history 서비스가 신설되면 이미 입찰 정보다 담긴 토픽을 그냥 구독하면 되기 때문이다.
  • 토픽을 사용하 모델에서 Bid Producer는 입찰 정보를 어느 서비스가 어떻게 사용하는지 전혀 모르기 때문에 커플링이 덜 된다.
• 단점
  • 누구나 입찰 데이터에 액세스 할 수 있으므로 데이터 보안 문제가 불거질 수 있다.
  • 한 가지 계약contract만 지원하므로 입찰 데이터를 수신한 서비스는 모두 동일한 계약 및 입찰 데이터 세트를 받아야 함
  • 메시지 개수를 모니터링 할 수 없고 자동 확장auto-scailing 기능이 지원되지 않는 단점이 있다.

 

토픽을 이용한 서비스 간 통신

• 장점
  • 큐에 전달된 데이터는 큐를 수신하는 지정된 컨슈머만 액세스가 가능하므로, 악의적인 서비스가 큐를 리스닝 해서 입찰 정보가 유출될 경우 정작 수신하기로 약속된 서비스는 데이터를 받지 못해 데이터 유실과 그로 인한 보안 침해를 경고하는 알림 메시지를 발송할 수 있다.
  • 각 컨슈머가 필요로 하는 데이터에 관한 자신만의 계약을 가질 수 있다.
  • 각 큐를 따로 모니터링 할 수 있고 입찰 컨슈머마다 개별적으로 로드 밸런싱load balancing 로직을 적용할 수 있기 때문에 상호 독립적인 자동 확장이 가능하다.
• 단점
  • 새로운 입착 기능을 추가할 일이 발생할 경우, 변경 작업이 수반된다.
  • 입찰 정보가 누구에 의해 어떻게 사용되는지 Bid Producer가 정확히 알고 있으므로 시스템이 더 커플링 된다.

 

토픽의 장점	토픽의 단점
아키텍처 신장성	데이터 액세스 및 보안 문제
서비스 디커플링	서로 다른 계약 혼용 불가
	모니터링과 프로그래밍 방식의 확장성

 

 

비즈니스 동인의 이해

• 아키텍처 사고는 성공적인 시스템 구축에 필요한 비즈니스 동인을 이해하고 요구사항을 확장성, 성능, 가용성 등의 아키텍처 특성으로 이해하는 것이다.

 

아키텍처와 코딩 실무 간 균형 맞추기

• 아키텍트는 풀타임 개발자가 아니므로 개발자 역할과 아키텍트 역할의 균형을 잘 맞춰야 한다.
• 아키텍트가 개발팀과 함께 코드를 개발할 수 있는 경우, 크리티컬 패스와 프레임워크 코드는 다른 개발팀 사람에게 넘기고 비즈니스 기능(서비스나 화면)을 코딩하는 작업에 집중해서 1~3회 이터레이션을 수행하는 것이 좋다. 이렇게 하면 아래의 3가지 측면에서 장점이 있다.
  
  1. 아키텍트는 더 이상 팀의 병목이 되지 않고 프로덕션 코드를 실제로 작성하는 실무 경험을 쌓게 된다.
  2. 크리티컬 패스와 프레임워크 코드를 각기 해당하는 개발팀에 분산시키고 소유권을 부여함으로써 시스템에서 가장 어려운 부분을 더 잘 이해할 수 있게 된다.
  3. 아키텍트가 개발팀에서 작업 중인 비즈니스 연관 코드를 직접 작성함으로써 개발자들이 프로세스 절차, 개발 환경, 어느 부분에서 가장 큰 고통을 겪고 있는지 몸소 체험할 수 있다.
• 아키텍트가 개발팀과 함께 코드를 개발할 수 없는 경우 아래의 4가지를 통해 코딩 실무 능력을 유지할 수 있다.
  1. 개념 증명proof-of-concept를 자주 해본다. 이 때, POC 작업을 할 때는 가능한 한 프로덕션 수준의 고품질 코드를 작성하는 게 좋다.
  2. 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채technical debt 스토리나 아키텍처 스토리에 전념한다.
  3. 아키텍처의 컴플라이언스 보장을 자동화하기 위해 피트니스 함수를 사용한다.
  4. 코드 리뷰를 자주 한다.