아키텍트가 주변을 바라보는 관점 : 아키텍처적인 눈으로, 즉 아키텍처 관점에서 사물을 바라보는 것
아키텍트의 사고 방식
1) 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하려면 개발팀과 어떻게 협력해야 할지 아는 것
2) 어느 정도 기술 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것
3) 다양한 솔루션과 기술 간의 트레이드오프를 이해, 분석, 조율하는 것
4) 비즈니스 동인의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것
2.1 아키텍처 대 설계
아키텍트가 하는 일과 개발자가 하는 일은 어떻게 다를까?
아키텍트처럼 사고한다는 것 = 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것
그림 2-2 ) 전통적인 아키텍트의 책임과 개발자의 책임 비교. 아키텍트는 비즈니스 요구사항을 분석해서 아키텍처 특성을 도출/정의하고 어떤 아키텍처 패턴과 스타일이 해당 문제 영역에 가장 알맞는지 선택하여 각종 컨포넌트를 만듬. 이러한 활동을 수행한 결과, 아티팩트를 만들어 개발팀에 전달하면, 개발팀은 각 컴포넌트의 클래스 다이어그램을 그린 뒤 UI 화면을 만들고 소스 코드를 개발/테스트 함
전통적인 아키텍트와 개발자의 역할 모델은 문제가 많음 -> 아키텍트와 개발자를 나누는 가상의 물리적 장벽을 통과하는 단방향 화살표가 아키텍처와 연관된 모든 문제의 원인. 아키텍트가 개발팀과 완전히 단절되어 있음
제대로 된 아키텍처를 만들려면 반드시 아키텍트와 개발자를 가르는 가상의 물리적 장벽을 허물고 두 팀이 양방향으로 소통하는 관계를 정립해야 함
그림 2-3 ) 아키텍트, 개발자 모두 활발히 소통하면서 아키텍트는 팀 내 개발자를 멘토링/코치하는 역할도 수행할 수 있도록 가상의 동일한 팀에 소속
아키텍처는 어디까지고 설계는 어디서부터일까? -> 경계는 따로 없음. 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있음
2.2 기술 폭
기술 세부 범위 또한 개발자와 아키텍트 차이
업무를 진행하기 위해 기술 깊이를 확보해야 하는 개발자와 달리, 소프트웨어 아키텍트는 아키텍트답게 사고하고 아키텍처 시각을 유지하기 위해 상당한 기술 폭을 갖춰야 함
그림 2-4 ) 세상에 존재하는 모든 기술 지식을 응축하여 나타낸 지식 피라미드. 내가 알고 있는 것 -> 내가 모른다는 사실을 아는 것 -> 내가 모른다는 사실조차 모르는 것. 기술 전문가가 자신의 커리어 단계마다 가치를 달리 해야 할 지식의 종류를 알 수 있음
'내가 알고 있는 것' : 자바 프로그래머가 자바를 아는 것처럼 전문 기술자가 일상 업무 수행에 사용하는 기술, 프레임워크, 언어, 도구 등
' 내가 모른다는 사실을 아는 것 ' : 전에 한 번 들어봤거나 얕은 지식은 갖고 있지만 실무 경험은 거의 전무한 기술
'내가 모른다는 사실조차 모르는 것' : 기술자가 해결하려는 문제에 완벽한 정답임에도 불구하고 그 존재조차 알지 못하는, 절대 다수의 기술, 도구, 프레임워크, 언어
개발 초심자 시절에는 피라미드의 꼭대기를 점점 넓혀 경험과 전문성을 쌓는데 주력함 -> 중간 영역이 점점 넓어지고, 관련 기술과 아티팩트를 더 많이 접하면서 '내가 모른다는 사실을 아는 것' 이 점점 늘어남
그림 2-5 ) 피라미드의 꼭대기를 넓히는 것 => '내가 알고 있는 것'은 '내가 계속 유지해야할 것' 이기도 함. 시간을 들여서 전문성을 유지해야 함. 피라미드 꼭대기의 크기가 바로 그 사람의 기술의 깊이
그림 2-6 ) 아키텍트의 가치는 기술에 대한 폭넓은 이해와 그 기술을 사용해서 특정한 문제를 해결하는 것. 꼭대기와 중간층이 중요함. 아키텍트의 기술 폭은 중간 영역이 아래 영역을 얼마나 더 멀리 관통하는가, 임
개발자가 아키텍트로 전환하려면 관점을 전환해야 하지만, 간과하여 역효과가 발생하는 것
1 ) 아키텍트가 되어 다양한 분야에서 전문성을 유지하려고 하나, 어느 하나도 성공하지 못한 채 지쳐버림
2 ) 김빠진 전문성이 나타남 => 지식의 낡은 정보가 첨단을 달리고 있는 것처럼 그릇된 인식에 사로잡힘
'꽁꽁 언 원시인' 안티패턴
야생에서 자주 볼 수 있는 행위와 연관된 안티패턴
어떤 아키텍처든 언제나 가장 비합리적인 관심사로 회귀하려는 아키텍처
과거와 같은 사고가 재발할 가능성이 희박함에도, 특수한 아키텍처 특성에 강박관념을 가지게 됨
일반적으로 과거의 나쁜 결정이나 예기치 못한 사고에 파묻혀 그 이후로 매사 극도의 경계심을 갖게 된 아키텍트에서 두드러짐
진짜 기술 리스크와 리스크처럼 보이는 기술 리스크의 차이를 이해하는 것 => 아키텍트가 평생 학습해야 할 주제
2.3 트레이드오프 분석
기술 여부와 상관 없이 모든 솔루션의 트레이드오프를 분석하여 최선의 솔루션을 결정하는 것
아키텍처는 구글링해도 안 되는 것이다
아키텍처는 모든 게 다 트레이드오프임
저마다 다른 환경, 상황, 문제를 안고 있기 때문
아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐.
그림 2- 8 ) 경매 시스템 예시. Bid producer -> Bid capture, Bid tracking, Bid analytics
Bid Producer (입찰 프로듀서) 서비스는 입찰자로부터 입찰을 생성하고, 입찰 금액을 Bid Capture, Bid Tracking, Bid Analytics 서비스에 전달
큐를 이용한 점대점 메시징 방식, 토핑을 사용한 메시지 발행/구독 방식 => 아키텍처적으로 사고하려면 각 방안의 트레이드오프를 분석하고 주어진 상황에서 가장 나은 선택을 해야 함
2. 아키텍처 사고
2.1 아키텍처 대 설계
2.2 기술 폭
2.3 트레이드오프 분석
2.4 비즈니스 동인의 이해
2.5 아키텍처와 코딩 실무 간 균형 맞추기