마지막 수정: 2026년 2월 16일
프론트엔드 개발자로서 나에게 익숙한 지식과 경험이 너무 미미하다고, 쉽게 대체 가능하다고 느꼈다.
마크업, API 상하차 외에 커다란 프로젝트가 어떻게 구성되고 각자의 영역이 맞물리는지 알고 싶었다.
좀 더 거시적인 인력이 되고자 가장 먼저 눈에 띄었던 책을 집어들었다.
(그리고 새 그림 그려진 오렐리 표지가 마음에 들었다.)
소프트웨어 아키텍트는 복잡한 소프트웨어를 깊게 이해해야 한다.
불완전한 정보에 근거해 수많은 트레이드오프를 결정해야 하며, 이는 생성형 AI 그 이상의 역할이다.
20세기 후반에는 MSA를 구축할 수 없었을 것이다. 아키텍트는 우리가 처한 상황의 맥락 안에서 결정을 내려야 하며, 복잡하게 변화하는 상황에서 여러 트레이드오프를 저울질하여 최적의 균형을 맞춰야 한다.
모든 아키텍처는 자신이 탄생한 환경의 영향을 받는다.
1법칙 소프트웨어의 모든 것은 트레이드오프이다.
모든 트레이드오프를 아우르는 포괄적인 아키텍처 정의는 절대로 할 수가 없다.
환경과 상황마다 매번 트레이드오프 평가를 다시 해야 한다.
2법칙 어떻게(방법)보다 왜(이유)가 더 중요하다.
경험이 많은 아키텍트는 아키텍처가 어떻게 작동하는지 파악할 수 있지만, 왜 그렇게 결정했는지는 알 수 없다.
3법칙 대부분의 아키텍처적 결정은 양자택일이 아니라 양극단 사이의 스펙트럼에 있는 한 지점이다.
의사 결정을 내리는 상황, 고려하던 트레이드오프가 우선시되도록 맥락을 형성하는데, 이 상황의 특징은 대부분 양자택일이 아니라는 것이다.