한 줄 정의
소프트웨어 아키텍처는 시스템의 구조, 품질 속성, 행동, 규칙을 종합적으로 설계하는 것이며, 그 본질은 트레이드오프입니다.
쉽게 말하면
건물을 짓기 전에 “어떤 구조로, 어떤 품질 기준으로, 어떤 방들을 배치하고, 어떤 규칙을 적용할 것인가”를 결정하는 것과 같습니다.
건축가가 “이 건물은 지진에 강해야 하니까 이런 구조로 가자”라고 결정하듯, 소프트웨어 아키텍트는 “이 시스템은 확장성이 중요하니까 마이크로서비스로 가자”라고 결정합니다.
다만 건축과 달리 소프트웨어 아키텍처에는 정답이 없고, 모든 선택에는 트레이드오프가 따릅니다.
왜 중요한가?
아키텍처 없이 시스템을 만들면, 초기에는 빠르게 개발할 수 있지만 시스템이 커질수록 무질서해집니다. 개발자마다 서로 다른 방향으로 코드를 작성하고, 성능이나 확장성 같은 품질 속성은 우연에 맡겨집니다.
이 상태가 지속되면 구조적 붕괴(structural decay) 가 발생합니다. 나중에 수정하려 해도 이미 얽힌 의존성 때문에 손대기 어려운 상태가 되는 것입니다.
아키텍처는 이런 혼란을 방지하기 위한 프레임워크이자, 팀 전체가 같은 방향을 바라보게 하는 나침반입니다.
핵심 내용
소프트웨어 아키텍처의 정의
소프트웨어 아키텍처는 네 가지 차원으로 구성됩니다. 이 분류가 유용한 이유는, “아키텍처”라는 모호한 단어를 구체적으로 논의할 수 있게 해주기 때문입니다.
mindmap root((소프트웨어 아키텍처)) 아키텍처 스타일 시스템의 뼈대 계층형, 마이크로서비스 등 아키텍처 특성 품질 속성 가용성, 확장성, 성능, 보안 논리적 컴포넌트 행동의 구성 요소 도메인, 엔티티, 워크플로 아키텍처적 결정 규칙과 제약 팀 전체에 영향
1. 아키텍처 스타일
시스템의 뼈대 입니다. 계층형, 마이크로서비스, 이벤트 주도 같은 구조적 형태를 말합니다.
여기서 중요한 포인트는 스타일 자체에 좋고 나쁨이 없다는 것입니다. 맥락에 따라 계층형이 최선일 수도, 마이크로서비스가 최선일 수도 있습니다.
2. 아키텍처 특성
시스템이 갖춰야 할 품질 속성 입니다. 가용성, 확장성, 성능, 보안 등 흔히 ‘~성(-ility)‘으로 끝나는 것들이 여기에 해당합니다.
기능 요구사항(“사용자가 주문할 수 있어야 한다”)과는 구분됩니다. 아키텍처 특성은 “그 주문 기능이 1초 안에 응답해야 한다”처럼 시스템이 어떻게 동작해야 하는지 를 정의합니다.
3. 논리적 컴포넌트
시스템의 행동을 담당하는 구성 요소 입니다. 도메인, 엔티티, 워크플로 등을 어떤 컴포넌트로 나누고 조합할 것인지를 설계합니다.
4. 아키텍처적 결정
시스템에 적용할 규칙과 제약조건 입니다. “표현 계층은 데이터베이스에 직접 접근할 수 없다” 같은 것이 대표적인 예입니다.
한번 정해지면 개발 팀 전체의 설계 방향을 제약하기 때문에, 잘못된 결정은 나중에 뒤집기가 매우 어렵습니다.
아키텍처는 맥락(context) 안에서만 이해할 수 있습니다.
2002년에는 마이크로서비스를 만들려면 서비스당 Windows 라이선스 50개, 앱서버 라이선스 30개가 필요했습니다. 같은 아키텍처 스타일이라도 시대와 환경이 다르면 완전히 다른 의미를 가집니다.
소프트웨어 아키텍처의 법칙
제1법칙: 모든 것은 트레이드오프이다
이 책에서 가장 핵심적인 메시지 입니다.
성능을 높이면 복잡도가 올라갑니다. 확장성을 확보하면 비용이 증가합니다. 유연한 설계를 하면 초기 개발 속도가 느려집니다.
아키텍트의 모든 결정에는 이런 양면이 존재하며, “공짜 점심”은 없습니다.
트레이드오프가 아닌 무언가를 발견했다고 생각한다면, 아마도 트레이드오프를 아직 찾아내지 못했을 가능성이 높다.
그리고 한 번 분석했다고 끝이 아닙니다. 비즈니스 요구사항이 변하고 기술 환경이 바뀌면, 과거의 최선이 현재의 최선이 아닐 수 있습니다. 트레이드오프 분석은 지속적으로 반복해야 합니다.
제2법칙: “어떻게”보다 “왜”가 더 중요하다
경험 있는 아키텍트라면 시스템이 어떻게 동작하는지는 코드를 보고 파악할 수 있습니다. 하지만 왜 그렇게 결정했는지 는 코드만 봐서는 알 수 없습니다.
당시에 어떤 트레이드오프를 고려했고, 어떤 대안을 검토했고, 왜 이 방향을 선택했는지. 이 맥락이 없으면 후임자가 해당 결정을 이해하거나 올바르게 변경하기 어렵습니다.
이것이 ADR(Architecture Decision Record) 같은 결정 기록이 중요한 이유입니다.
제3법칙: 대부분의 결정은 스펙트럼 위에 있다
“모놀리스냐 마이크로서비스냐” 같은 이분법적 사고는 위험합니다. 실제로는 그 사이에 서비스 기반 아키텍처, 모듈형 모놀리스 등 다양한 선택지가 존재합니다.
대부분의 아키텍처적 결정은 양극단이 아니라 스펙트럼 위의 어딘가 에 위치합니다.
아키텍트의 기대 역할
아키텍트에게 기대되는 8가지 핵심 역할입니다:
1. 아키텍처적 결정을 내린다
구체적 기술 선택이 아닌 지침 수준의 결정을 내립니다. “React를 써라”가 아니라 “반응형 프레임워크를 써라”가 아키텍처적 결정입니다. 특정 기술을 콕 집어주는 것이 아니라, 팀이 올바른 방향에서 선택할 수 있도록 가이드하는 것입니다.
2. 아키텍처를 지속적으로 분석한다
기존 아키텍처가 현재 비즈니스와 기술 환경에서 여전히 유효한지 지속적으로 점검해야 합니다. 이것을 아키텍처 활력(architecture vitality) 이라고 합니다.
이 노력이 부족하면 구조적 붕괴가 서서히 진행됩니다. 개발자가 성능이나 확장성에 영향을 주는 코드를 변경할 때, 아키텍처 관점에서 검토하는 사람이 없으면 품질이 조금씩 무너집니다.
3. 최신 트렌드를 계속 따라간다
아키텍트가 내리는 결정은 오랫동안 영향을 미칩니다. 트렌드를 놓치면 몇 년 뒤에 기술 부채로 돌아올 수 있습니다.
클라우드, 컨테이너, 생성형 AI 등 기술 변화가 빠르기 때문에 편안한 영역에 안주하지 않고 계속 학습 하는 자세가 중요합니다.
4. 결정 사항의 준수를 보장한다
결정을 내리는 것만으로는 부족합니다. 개발 팀이 아키텍처적 결정과 설계 원칙을 실제로 따르고 있는지 지속적으로 확인해야 합니다.
문서화해서 공유하는 것에서 끝나면, 시간이 지나면서 위반 사항이 쌓이고 아키텍트의 의도는 무산됩니다.
5. 다양한 기술을 이해한다
기술적 깊이(depth)보다 너비(breadth) 가 더 중요합니다.
캐싱 제품 하나를 완벽히 아는 것보다, 10가지 캐싱 제품의 장단점을 두루 아는 것이 아키텍트에게는 더 가치 있습니다. 다양한 기술의 트레이드오프를 파악하고 있어야 상황에 맞는 최선의 선택을 할 수 있기 때문입니다.
6. 비즈니스 도메인을 숙지한다
비즈니스 도메인을 모르면 효과적인 아키텍처를 설계할 수 없습니다. 증권사 아키텍트가 PER이나 파생상품이 뭔지 모른다면 이해관계자와 소통 자체가 안 됩니다.
가장 성공적인 아키텍트들은 기술 지식뿐 아니라 비즈니스에 대한 핵심적인 이해력 을 갖추고 있었습니다.
7. 대인 관계 스킬을 갖춘다
아키텍트 역할의 최소 절반은 리더십 입니다. 팀워크, 조정력, 코칭, 멘토링 능력이 모두 포함됩니다.
기술적으로 뛰어나지만 팀을 이끌지 못하는 아키텍트는 많습니다. 반대로, 기술력은 보통이지만 리더십과 대인 관계 능력이 뛰어난 사람이 오히려 더 효과적인 아키텍트가 되는 경우도 있습니다.
8. 정치를 파악하고 헤쳐 나간다
아키텍트가 내리는 거의 모든 결정은 도전을 받습니다. 어떤 아키텍처 스타일을 사용할지, 어떻게 통신할지, 공유 기능성을 어떻게 관리할지 등 모든 것에 반발이 있을 수 있습니다.
개발자 시절에는 승인 없이 자유롭게 결정할 수 있었지만, 아키텍트는 모든 결정을 정당화하고 설득해야 합니다. 협상 능력은 필수입니다.
정리
| 차원 | 핵심 질문 | 예시 |
|---|---|---|
| 아키텍처 스타일 | 어떤 구조로 만들 것인가? | 계층형 vs 마이크로서비스 |
| 아키텍처 특성 | 어떤 품질 속성이 중요한가? | 성능 vs 확장성 |
| 논리적 컴포넌트 | 어떤 단위로 행동을 나눌 것인가? | 주문 컴포넌트, 결제 컴포넌트 |
| 아키텍처적 결정 | 어떤 규칙을 적용할 것인가? | 계층 간 직접 호출 금지 |
아키텍트 vs 개발자
| 기준 | 아키텍트 | 개발자 |
|---|---|---|
| 기술 초점 | 너비(breadth) | 깊이(depth) |
| 결정 범위 | 지침 제시 | 구체적 기술 선택 |
| 결정의 자유도 | 모든 결정을 정당화해야 함 | 비교적 자유롭게 결정 |
| 필요 역량 | 기술 50% + 리더십 50% | 기술 중심 |
내 생각
-
아키텍처라는 역할이 공식적으로 있든 없든, 시스템의 구조를 결정하는 사람은 반드시 존재합니다. “우발적 아키텍트(accidental architect)“가 바로 그런 경우입니다.
-
제2법칙(“왜”가 중요하다)은 실무에서 가장 체감되는 부분입니다. 레거시 시스템을 인수받았을 때, 왜 이런 구조를 선택했는지 기록이 없으면 변경 자체가 두려워집니다.
-
아키텍트 역할의 절반이 리더십이라는 점은 많은 개발자가 간과하는 부분입니다. 기술적으로 완벽한 설계를 했더라도, 팀을 설득하지 못하면 그 설계는 실현되지 않습니다.
관련 개념
출처
- 소프트웨어 아키텍처 The Basics, Ch01 서론