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

인상깊은 부분

기술 폭

2장에서도 1장과 마찬가지로 기술폭에 대한 언급이 나와서 좀 더 생각해봄
문제를 해결할 수 있는 특정 기술보다는, 그 문제를 해결할 수 있는 여러 기술을 알라는 조언으로 생각하는 게 좋겠음
내가 알던 좋은 아키텍트 겸 리더는 훌륭한 개발자로 깊이를 만든 후 폭을 넓힌 것 같음. 혹은 둘 다 동시에 진행한 것으로 보여짐.
개인적인 경험으로 미루어 볼 때 깊이가 없으면 폭을 넓히기도 쉽지 않음.
기본적으로 어떤 문제를 해결하기 위해 다양한 솔루션을 확인하고, 특정 기술 한 두 가지 정도는 뾰족하게 가져가야 좋을 것 같음.

경매 시스템의 트레이드 오프

개인적으로 마음에 드는 예제 p60 ~ p63

---

요약

아키텍처 사고 방식은 크게 4 가지로 구성

1. 아키텍처와 설계의 차이 이해 및 개발팀과 어떻게 협력해야할 지 아는 것
2. 어느 정도 기술 깊이를 유지하면서 폭넓은 기술 지식 확보
3. 다양한 솔루션과 기술 간의 트레이드 오프를 이해
4. 비즈니스 동인의 중요성을 이해하고 그것을 아키텍처 관심사로 해석

2.1 아키텍처 대 설계

• 비즈니스와 기술 문제를 해겨랗기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 통합할 솔루션을 모색
• 전통적인 아키텍트와 개발자 역할 모델의 문제 - 아키텍트가 내린 결정이 개발팀에 쓸모가 없어서 개발팀이 아키텍처를 변경하기로 하더라도 다시 아키텍트에게 전달되는 일이 없음 (완전한 단절로 협업 X)
• 아키텍처와 설계의 경기는 따로 없다. 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있다.

2.2 기술 폭

• 업무를 진행하기 위해 기술 깊이를 확보해야하는 개발자와 달리, 아키텍트는 기술 폭을 갖춰야 함
• 아키텍트의 가치는 대부분 기술에 대한 폭넓은 이해와 그 기술을 사용해서 특정한 문제를 해결하는 것임. 아키텍트에게는 깊이보다 폭이 중요한 이유임. 기술적인 제약 하에 어떤 기능이 가장 알맞는 지 결정해야 하므로 폭넓은 솔루션을 두루 알고 있어야 함
• 지식 피라미드
  • 내가 알고 있는 것
    • 기술의 깊이에 해당
    • 계속 유지해야하는 전문성
    • 개발 초심자 시절에는 이 영역을 넓혀 경험과 전문성을 쌓는 데 주력함
  • 내가 모른다는 사실을 아는 것
    • 기술 폭에 해당하는 영역으로, 아래 영역을 얼마나 더 멀리 관통하는 가 임
    • 내가 얼마나 많이 알고 있는가를 의미
    • 아키텍트에게 중요한 것은 꼭대기와 중간임
  • 내가 모른다는 사실조차 모르는 것
• 개발자에서 아키텍트로 전환 시 두 가지 역효과
  • 다양한 분야에서 전문성을 유지하려고 하나, 어느 하나도 성공하지 못한 채 지침
  • 김빠진 전문성 (이미 낡은 정보가 되었는데 지식의 갱신 없이 의사결정)
• 깊이와 폭 사이에서 지식 포트폴리오의 균형을 맞추는 일은 모든 개발자가 커리어 내내 고민해야할 문제

2.3 트레이드 오프 분석

• 아키텍트처럼 생각하는 것은 기술 여부와 상관없이 모든 솔루션의 트레이드오프를 분석하여 최선의 솔루션을 결정하는 것
  • REST와 메시징 중 어느 게 더 나은지, 마이크로서비스가 딱 맞는 아키텍처 스타일인지, 아무리 구글링해도 정답은 나오지 않음
  • 아키텍처는 정답도, 오답도 없다. 오직 트레이드 오프만 있을 뿐
• 경매 시스템의 트레이드 오프 (p60 ~ p63) : 큐와 pub/sub 방식으로 구현이 가능한데, 어떤 선택을 해야할까? 신장성(보통 확장성이라고 함)과 보안 중 어떤 게 더 중요한가?
  • 큐 (Queue)
    • 장점
      • 지정된 컨슈머만 액세스 가능함
      • 수신하기로 약속된 서비스는 데이터를 받지 못해 데이터 유실(과 보안 침해)을 경고하는 알림 메시지 발송 가능
      • 큐 채널별로 컨슈머가 필요로하는 계약(메시지)을 가질 수 있음
      • 각 큐를 모니터링할 수 있고, 컨슈머마다 개별 로드밸런싱 로직을 적용할 수 있어 상호 독립적인 자동 확장이 가능
      • AMQP
    • 단점
      • 컨슈머가 늘어난다면, 기존 시스템의 프로듀서를 고쳐야함
      • 프로듀서가 누가 어떤 메시지를 사용하는지 알고 있으므로 시스템이 더 커플링 됨
  • 토픽 (Topic, pub/sub)
    • 장점
      • 아키텍처 신장성(extensibility, 확장성이라고도 함) : 컨슈머가 늘어나도 기존 경매 시스템을 고칠 필요 없음
      • 프로듀서는 어떤 서비스가 메시지를 어떻게 사용하는지 전혀 모르기에 커플링이 덜 됨
    • 단점
      • 도청이 쉬움
      • 한가지 계약(메시지)만 지원하므로 수신한 서비스는 모두 동일한 메시지를 받음
      • 메시지 개수를 모니터링할 수 없고 자동 확장(auto-scaling) 기능이 지원되지 않음

2.4 비즈니스 동인의 이해

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

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

• 코딩 실무와 아키텍처의 균형 맞추기
  • 병목 트랩(bottleneck trap)에 빠지지 말라
    • 아키텍트가 프로젝트의 크리티컬 패스(임계 경로, 최장 경로)에 있는 코드(보통 하부를 떠받치는 프레임워크 코드)의 소유권을 갖고 있는 경우 발생함
    • 아키텍트는 풀타임 개발자가 아님
  • 크리티컬 패스와 프레임워크 코드는 개발자에게 넘기고 비즈니스 기능(서비스나 화면)을 코딩하는 작업에 집중해서 1~3회 이터레이션 하는 것이 좋음
    • 아키텍트는 더 이상 팀의 병목점이 되지 않을 수 있고, 프로덕션 코드를 실제로 작성하는 실무 경험을 쌓게 됨
    • 크리티컬 패스와 프레임워크 코드를 개발팀에 분산시키고 소유권을 부여함으로써 시스템에서 가장 어려운 부분을 더 잘 이해할 수 있음
    • 개발팀에서 작업 중인 비즈니스 연관 코드를 직접 작성함으로써 개발자들이 프로세스, 절차, 개발 환경, 어느 부분에서 가장 큰 고통을 겪고 있는지 몸소 체험 가능
  • 코딩 실무 능력을 유지하는 네 가지 방법
    1. 개념 증명(POC)를 자주 해보는 것
       • 소스 코드를 직접 작성해보면서 구현 상세를 생각하게 되므로 아키텍처 결정을 검증하는 데 유용함
       • 작업 시에는 프로덕션 수준의 고품질 코드를 작성하는 게 좋음. 누군가의 레퍼런스 아키텍처가 될 수 있고, 좋은 습관을 들이게 됨
    2. 기술 부채 스토리나 아키텍처 스토리에 전념하는 것
       • 개발팀이 중요한 유저 스토리 작업을 할 수 있도록 우선순위 낮은 작업을 가져감
       • 혹시 이터레이션 내에 스토리를 끝내지 못했다고 해서 큰 영향을 미치지 않음
       • 이터레이션 중 발견한 버그를 잡는 일 역시 해당함
    3. 자동화
       • 평소 개발팀이 반복적으로 수행하는 작업이 있는지 살펴보고 그런 프로세스를 자동화하여 시간을 아껴주기
       • 간단한 커맨드라인 도구나 분석기를 만들어 일상 업무를 간소화/자동화
       • 아키텍처 컴플라이언스 보장을 자동화하기 위해 피트니스 함수를 사용하는 것도 방법
    4. 코드 리뷰