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

2.1 아키텍처 대 설계

• 아키텍트처럼 사고한다는 건, 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것
• 아키텍트는 비즈니스 요구사항을 분석해서 아키텍처 특성을 도출/정의하고 어떤 아키텍처 패턴과 스타일이 해당 문제 영역에 가장 알맞는지 선택 → 각종 구성 요소를 만든다.

아래는 아키텍트와 설계를 구분하는 기존 시각

• 전통적인 아키텍트와 개발자의 역할 모델은 문제가 많다.
  • 아키텍트와 개발자를 나누는 물리적 장벽을 통과하는 단방향 화살표가 모든 문제의 원인
  • 아키텍트가 내린 결정이 개발팀에서 전혀 쓸모가 없는 경우가 있음에도 불구하고, 이 내용이 다시 아키텍트에게 전달되는 일이 없는 것은 의도했던 아키텍처가 요원해지는 이유
• 제대로 된 아키텍처를 만들려면 반드시 아키텍트와 개발자를 가르키는 가상의 물리적 장벽을 허물고 양방향으로 소통하는 것이 필요

💡 그래서 아키텍처는 어디까지고 설계는 어디서부터일까?
    - 그런 경계는 따로 없다. 모두 소프트에웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있다.

2.2 기술 폭

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

🤔 일반 개발자들도 여러 가지 해결책을 생각하면 좋은 것 아닌가?
    - 아키텍트는 전체 시스템 구조에 대한 결정이며, 영향 범위가 전체 조직이므로 잘못된 결정 시 수정 비용이 매우 크다.
    - 그래서 장기적 관점에서의 설계가 필요하므로
    - 여러 가지 선택지에서 저울질을 하며 최적의 해결책을 찾는 능력이 중요한 것 같다.

2.3 트레이드오프 분석

• 아키텍처는 모든 게 다 트레이드오프다.
• 아키텍처를 문의하는 질문마다 "경우에 따라 다릅니다"라고 답할 때가 많은 것도 이 때문

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

• 코딩 실무와 소프트웨어 아키텍처의 균현을 맞추는 것도 아키텍트가 극복해야 할 어려운 일 중 하나
• 아키텍트가 개발팀에서 작업 중인 비즈니스 연관 코드를 직접 작성함으로써 개발자들이 프로세스, 절차, 개발 환경, 어느 부분에서 가장 큰 고통을 겪고 있는지 몸소 체험 가능
• 그래서 아키텍트가 코딩 실무 능력을 유지하는 것도 중요하다.
  • POC를 자주 해봐라
  • POC는 아키텍트가 소스 코드를 직접 작성해보면서 구현 상세를 생각하게 되므로 아키텍처 결정을 검증하는 데 유용
  • 여러 가지 솔루션으로 갈팡지팡하고 있는 아키텍트가 결정 장애를 극복하는 가장 좋은 방법은, 실제로 각 제품을 으용한 예제 코드를 짜보고 실행 결과를 비교해보는 것
  • POC 작업을 할 때에는 가능한 한 프로덕션 수준의 고품질 코드를 작성하는 게 좋다.
    • 이것이 레퍼런스 아키텍처가 되거나 다른 사람들이 따라하는 좋은 샘플이 되는 경우가 많다.
    • 양질의 코드를 작성하는 습관을 들이게 된다.
• 개발팀의 일상 업무를 간소화, 자동화하는 것도 코딩 실무 능력을 유지하며 개발팀을 더욱 능률적으로 만드는 일석이조의 방법

🤔 생각) 인정이다..
    - 아키텍처를 사용하고 있는 서비스 코드에서 문제가 발생하고 그 문제를 해결해야 하는 일이 많다보니 코딩 실무 능력을 유지하는 것이 중요하다고 느낀다.
    - 최근에도 패키지는 잘 서빙되었다고 생각했는데, 프로젝트에서 모듈을 해석할 수 없다는 에러에 대해 해결하려다보니 어려움이 많았다.
    - 그런 것들을 잘 흡수하려고 하고 있고, 그럼과 동시에 폭넓게 지식을 쌓을 기회도 많은 것 같다(워낙 다양한 상황에서 패키지에 대한 문의가 들어와서).