마지막 수정: 2026년 2월 16일
설계자의 눈으로 보는 것. 아키텍처의 관점에서 보는 것.
변경사항이 아키텍처의 확장성에 미칠 영향력을 고려해야 한다.
집이 몇 층짜리인지? 침실은 몇 개인지 → 전체적인 구조를 정의한다.
마이크로서비스는 시스템의 구조와 형태를 결정한다.
바닥이 카펫인지, 원목 바닥인지, 벽지, 조명이 어떤지 → 설계와 연관.
UI의 느낌과 모양은 시스템의 설계를 정의한다.
아키텍처와 설계 스펙트럼 어딘가에 위치하게 된다.
이 둘 중 어디에 더 가까운지 판단하는 기준은 다음과 같다.
지식 피라미드에 있어서 아키텍트에게는 개발자와 다른 접근이 필요하다.
기술적 너비를 넓혀 본인이 아는 지식에만 매몰되지 않도록 경계해야 하고, 그 기술과 같이 사장되지 않도록 해야 한다.
시스템을 이해하는 것을 넘어, 비즈니스 동인을 확장성, 가용성, 성능 같은 아키텍처 특성들로 옮길 줄도 알아야 한다.
비즈니스 도메인 지식, 비즈니스의 이해관계자와의 원만하고 협력적인 관계가 필요하다.
아키텍트는 코드 구현에 할애할 수 있는 시간이 많지 않다. 다이어그램을 작성하거나 아주 많은 회의에 참석해야 할 수도 있다. 이 경우 시스템의 핵심 개발을 맡으면, 병목으로 인해 개발 팀의 발목을 잡을 수도 있다.
대신 아키텍트는 소규모 비즈니스 기능성(예: UI 개발) 개발을 담당하고, 시스템의 핵심은 개발팀에 일임하는 것이 좋은 방법일 수 있다.