아키텍처적 사고

설계자의 눈으로 보는 것. 아키텍처의 관점에서 보는 것. 변경사항이 아키텍처의 확장성에 미칠 영향력을 고려해야 한다.

아키텍처(Architecture)와 설계(Design)의 차이

Architecture

집이 몇 층짜리인지? 침실은 몇 개인지 → 전체적인 구조를 정의한다. 마이크로서비스는 시스템의 구조와 형태를 결정한다.

Design

바닥이 카펫인지, 원목 바닥인지, 벽지, 조명이 어떤지 → 설계와 연관. UI의 느낌과 모양은 시스템의 설계를 정의한다.

아키텍처 vs 설계, 판단 기준

아키텍처와 설계 스펙트럼 어딘가에 위치하게 된다. 이 둘 중 어디에 더 가까운지 판단하는 기준은 다음과 같다.

• 전략적인지 전술적인지
  • 전략(Strategy)적일수록 아키텍처, 전술(Tactics)적일수록 설계에 가깝다.
• 변경이나 구축에 얼마나 많은 노력이 필요한지
  • Monolithic → MSA (Architecture), UI input order (Design)
• 트레이드오프의 중요도

기술적 너비와 깊이

지식 피라미드에 있어서 아키텍트에게는 개발자와 다른 접근이 필요하다. 기술적 너비를 넓혀 본인이 아는 지식에만 매몰되지 않도록 경계해야 하고, 그 기술과 같이 사장되지 않도록 해야 한다.

Technology Radar | Guide to technology landscape

트레이드오프 분석

비즈니스 동인(Business Driver)의 이해

시스템을 이해하는 것을 넘어, 비즈니스 동인을 확장성, 가용성, 성능 같은 아키텍처 특성들로 옮길 줄도 알아야 한다. 비즈니스 도메인 지식, 비즈니스의 이해관계자와의 원만하고 협력적인 관계가 필요하다.

아키텍처와 코딩 실무 균형

아키텍트는 코드 구현에 할애할 수 있는 시간이 많지 않다. 다이어그램을 작성하거나 아주 많은 회의에 참석해야 할 수도 있다. 이 경우 시스템의 핵심 개발을 맡으면, 병목으로 인해 개발 팀의 발목을 잡을 수도 있다.

대신 아키텍트는 소규모 비즈니스 기능성(예: UI 개발) 개발을 담당하고, 시스템의 핵심은 개발팀에 일임하는 것이 좋은 방법일 수 있다.

개발 팀과 동일 코드를 작업할 수 없는 경우

1. PoC를 자주 진행한다. PoC에 필요한 소스는 아키텍트가 담당하며, 구현상의 세부사항과 전체 솔루션 개발에 필요한 비용의 양을 가늠할 수 있다.
2. 기술 부채 해결. 기술 부채를 해결하는 작업은 한 Iteration 안에서 우선순위가 낮기 때문에, 달성하지 못하더라도 악영향이 없다.
3. 버그 수정.
4. 자동화. 개발팀의 일상 업무를 자동화할 수 있는 것들.
5. 코드 검토. 개발 팀의 기술 준수 여부 확인 등 아키텍트가 소스 코드에 직접 관여하게 되고, 코칭과 멘토링의 기회를 얻게 된다.