마틴 파울러가 소개하는 소프트웨어 아키텍처
🤔핵심 목표
1. 마틴 파울러(Martin Fowler)가 약 10분 동안 이야기한 소프트웨어 아키텍처를 정리한다.
1 마틴 파울러가 소개하는 아키텍처
소프트웨어 아키텍트는 팀에서 가장 노련한 개발자이자 설계자다. 요구사항을 바탕으로 어떤 컴포넌트와 인터페이스로 시스템을 구성할지 디자인하고, 그 결과를 팀과 공유해 합의를 이끌어낸다. 이렇게 합의된 설계가 곧 아키텍처이며, 이는 한 번 정하면 바꾸기 어려운 결정들의 집합이다. 그래서 아키텍처에는 제품의 핵심 가치가 담기고, 개발에 참여하는 모든 사람이 이해하고 동의하는 최소한의 공통 기반이 된다.
아키텍트는 등반의 가이드와 같다. 팀을 이끌고 가르치며 구성원의 역량을 끌어올리고, 프로젝트 전반의 상황을 면밀히 파악한다. 작은 징후에서 리스크를 미리 발견해 문제로 커지기 전에 대응하고, 이를 위해 팀 전원과 긴밀히 협업한다.
아키텍처는 바꾸기 어렵다. 바꾸기 어려울수록 시스템의 복잡도와 비용은 높아진다. 따라서 “아키텍처라 부를 만한 것”은 가능한 적을수록 좋다. 바꾸기 어려운 것을 바꾸기 쉽게 만들 수 있다면(유지·보수·기능 추가가 쉬워진다면) 그것은 더 이상 아키텍처적 제약이 아니다. 훌륭한 아키텍트는 불가역적 결정을 최소화하고, 변경이 쉬운 구조를 설계해 아키텍처의 크기를 줄이는 사람이다.
비록 고객의 눈에는 보이지 않지만, 이런 아키텍처에 품질을 투자하는 것은 장기적으로 큰 경제적 이익을 가져온다. 내부 품질을 높여 유지·보수와 기능 추가를 쉽게 만들어 두면, 시간이 지날수록 개발 속도는 유지되고 총비용은 줄어든다.
- 아키텍처 = 나중에 바꾸기 어려운 결정의 집합 + 팀이 합의한 최소 공통 기반
- 아키텍트 = 가이드/코치: 합의 주도, 리스크 조기 발견, 팀 역량 향상, 긴밀한 협업
- 목표 = 불가역적 결정을 최소화하고 변경 용이성을 극대화하여 “아키텍처의 크기”를 줄이는 것
- 효과 = 내부 품질에 대한 선제 투자로 장기 비용 절감과 지속 가능한 개발 속도 확보
2. 마틴파울러: 소프트웨어 아키텍처란 무엇인가?
마틴 파울러는 소프트웨어 아키텍처를 두 가지로 요약한다.
- 첫째, 노련한 개발자들이 공유하는 시스템 설계에 대한 이해 (Expert developers’ shared understanding of the system design)
- 둘째, 나중에 바꾸기 어려운 결정들 (Decisions that are hard to change)
이 정의는 문서나 다이어그램의 유무보다 팀이 무엇을 중요하게 여기고 어떻게 일관되게 만들지 초점을 둔다.
1) Expert developers’ shared understanding of the system design
아키텍처는 주로 개발자들의 문제다. 고객은 아키텍처를 알 필요도, 관심도 없다. 고객에게 중요한 것은 “요구사항이 원하는 대로 동작하느냐”뿐이다. 반면 개발자는 그 요구를 어떤 큰 덩어리의 컴포넌트로 나누고, 컴포넌트 간 인터페이스를 어떻게 설계할지 고민한다. 경험 많은 개발자들이 이러한 구조를 도출해 팀에 명료하게 공유하고, 팀이 같은 그림을 머릿속에 갖도록 합의를 이끌어낸다. 이 공유된 이해가 곧 아키텍처의 중요한 절반이다.
왜 합의가 필요할까? 아키텍처는 팀 전체가 같은 제약과 원칙 아래에서 움직이게 하는 최소 공통 기반이기 때문이다. 합의 없이는 각자가 제멋대로 구현하여 일관성이 무너지고, 변화가 누적될수록 복잡도와 비용이 급증한다.
우리가 흔히 떠올리는 아키텍처 다이어그램, 컨텍스트/컨테이너/컴포넌트 도식, 시퀀스/데이터 흐름 그림 등은 공유된 이해를 표현(representation)한 결과물일 뿐이다. 즉, 다이어그램 자체가 아키텍처가 아니라, 팀이 합의한 중요한 결정과 그 의미가 아키텍처다. 표현 방식은 팀과 상황에 맞게 가볍고 변화 가능해야 하며, 이해를 돕고 합의를 유지하는 데 기여하면 충분하다.
2) Decisions that are hard to change
아키텍처의 절반은 나중에 바꾸기 어려운 결정들이다. 경계를 어디에 둘지, 데이터와 상태를 어떻게 분할할지, 동기·비동기 통신과 트랜잭션 경계를 어떻게 잡을지, 배포와 운영 토폴로지는 무엇으로 갈지 같은 선택은 한 번 내려지면 코드와 인프라 전반에 파급효과를 만든다. 그래서 이 영역일수록 신중해야 하며, 가능하면 불가역적 선택의 개수를 줄이고 변경에 강한 구조를 지향해야 한다.
훌륭한 아키텍트는 “아키텍처라 부를 만큼 바꾸기 어려운 것”의 범위를 최소화하고, 나머지는 팀이 상황에 맞춰 쉽게 바꿀 수 있게 설계한다. 흔히 “프로젝트 초기에 제대로 알고 결정했어야 하는 것”이라 부르는 이유가 바로 여기에 있다. 쉬운 것은 언제든 수정하면 된다. 그러나 핵심 가치와 맞닿은 결정은 시스템 곳곳에 스며들기 때문에 가능하면 바꾸지 않으려는 성질을 띤다. 결국 이 축의 요지는 불가역성이고, 그 대표 사례가 도메인 경계 설정, 핵심 데이터 모델, 통신 방식, 트랜잭션/일관성 모델, 배포 단위와 운영 토폴로지다.
3. 마틴 파울러: 그래서 아키텍처란 무엇인가?
마틴 파울러가 정리하듯, 아키텍처는
“노련한 개발자들이 공유한 시스템 설계에 대한 이해와 나중에 바꾸기 어려운 결정들”
이 합쳐진 것이다. 프로젝트가 추구하는 핵심 가치를 담고, 그 특성상 바꾸기 어렵기에 신중히 다루어야 하며, 팀에서 가장 경험 많은 사람이 윤곽을 잡아 명확히 공유하고, 팀 전체가 같은 이해로 일관되게 만들고 유지해 가는 것, 그것이 좋은 소프트웨어 아키텍처다. 다이어그램과 산출물은 이 공유된 이해의 표현물일 뿐, 그 자체가 본질은 아니다.
한 문장으로 압축하면 이렇다. 아키텍처란 “모든 중요한 것들”이다. 쉽게 바꾸어서는 안 되고, 충분히 이해하고 합의한 뒤에 만들어야 하는 중요한 결정들의 집합이며, 좋은 아키텍처일수록 불가역적 결정을 줄이고 변경을 쉽게 만든다.
- 아키텍처 = (공유된 이해) + (바꾸기 어려운 결정)
- 고객은 결과를 본다. 아키텍처는 개발자가 책임지는 내부 품질의 문제다.
- 경험 많은 개발자가 컴포넌트와 인터페이스의 윤곽을 잡고 팀 합의를 이끈다.
- 불가역적 결정은 최소화하고, 변경 용이성을 최대화한다.
- 다이어그램은 합의를 보조하는 표현 수단이지, 목적 그 자체가 아니다.
아키텍트의 역할: 가이드이자 복잡도 감축자
소프트웨어 아키텍처에 대한 정의가 자리잡았다면, 이제 아키텍트는 무엇을 하는 사람인가를 분명히 해야 한다. 흔히 아키텍트를 “큰 결정을 빠르게 내려 팀이 따라오게 만드는 사람”으로 오해한다. 이 틀에선 팀이 그 결정을 감당할 수 있는지, 결정의 질과 타이밍이 현장과 맞는지가 뒷전으로 밀린다. 아이러니하게도 이런 방식일수록 아키텍트의 가치는 “결정의 수”에 반비례한다는 경험칙이 생긴다. 결정이 많아질수록 팀은 지치고 복잡도는 쌓이기 때문이다.
1) 흔한 오해에서 벗어나기
아키텍트의 핵심은 “빨리 많이 결정하기”가 아니다. 결정의 불가역성을 낮추고, 팀이 안전하게 변경할 수 있도록 길을 터주는 일이다. 중요한 결정을 적게, 더 늦게 내리더라도 팀이 충분히 이해하고 실행할 수 있게 만드는 것이 장기적으로 더 효과적이다.
2) 가이드로서의 아키텍트
좋은 아키텍트는 등반의 가이드에 가깝다. 프로젝트 전반의 지형을 누구보다 잘 알고, 작은 이슈가 큰 위험으로 번지기 전에 조기에 감지하고 교정한다. 이를 위해 팀 전원과의 밀도 높은 소통과 협업을 일상적으로 수행한다. 무엇보다 멘토로서 지식을 전파하고 실천을 돕는다. 실력이 남다르기 때문에 어려운 문제 앞에서 팀이 의지할 수 있는 기준점이 되고, 그 과정을 통해 팀 전체의 역량을 끌어올려 더 높은 요구사항을 감당하게 만든다.
3) “아키텍처 제거반”으로서의 역할
아키텍처는 본질적으로 되돌리기 어려운 것들의 집합이다. 그렇다면 아키텍트의 또 다른 임무는 이 불가역성 자체를 줄이는 것이다. 되돌리기 어려운 결정을 되돌리기 쉽게 만들면, 그것은 더 이상 아키텍처적 제약이 아니게 되고 시스템의 복잡도는 감소한다. 복잡도가 줄면 적은 인력으로 유지·보수가 가능해지고 변화에 대한 대응력이 높아진다.
즉, 아키텍트는 “아키텍처라 불러야 할 만큼 바꾸기 어려운 것”의 범위를 지속적으로 축소하는 사람이다. 경계를 명확히 하되 결합을 낮추고, 데이터와 상태를 분리하되 이동 비용을 낮추며, 통신과 트랜잭션을 설계하되 대체·진화 가능한 선택지를 남겨 두는 식으로 불가역성을 깎아낸다.
4) 최종 정리
- 아키텍트는 결정 제조기가 아니라 변경 가능성의 수호자다.
- 팀이 이해하고 실행할 수 있는 작은 불가역성만 남기고, 나머지는 쉽게 바뀌는 구조로 설계한다.
- 조기 감지·조기 조치, 깊은 협업, 지속적 멘토링을 통해 팀 전체의 실력을 끌어올린다.
- 결과적으로 복잡도를 낮추고, 적은 인력으로도 유지·보수 가능한 시스템을 만든다.
한 마디로 아키텍트는 가이드이자, 불가역적 결정을 최소화해 복잡도를 줄이는 “아키텍처 제거반”이다.
4. 소프트웨어 품질과 돈
겉으로 보기엔 품질을 낮춰 빠르게 출시하는 편이 회사에 유리해 보인다. 같은 기능을 더 적은 개발 시간으로 만들면 이익처럼 느껴지기 때문이다. 하지만 이 판단은 짧은 시야의 착시다. 출시 이후에야 진짜 비용이 본격적으로 발생하기 때문이다.
로버트 마틴(Robert C. Martin)이 말하듯, 좋은 아키텍처의 목표는 “적은 인력으로 유지·보수 가능한 상태”를 만드는 것이다. 곧, 좋은 품질 = 출시 후 변경이 쉬운 상태다. 이 상태에서는 리팩터링, 버그 수정, 신규 기능 추가가 빠르고 안전하게 진행된다. 결과적으로 개발 속도는 유지되거나 가속되고, 총비용(TCO)은 시간이 지날수록 줄어든다. 이것이 곧 회사와 고객 모두의 이익으로 돌아온다.
초기 투자 vs. 누적 비용
- Good design 곡선: 초기에 핵심 가치에 집중한 최소 아키텍처를 세우고(노련한 개발자가 윤곽 설계), 팀 전원이 이해·합의하도록 만든다. 그러면 이후 변경 비용이 완만하게 증가하거나 거의 평탄하다. 기능을 추가할수록 생산성이 유지된다.
- Bad design 곡선: 빨리 내기 위해 설계를 생략하면, 초반엔 빨라 보이지만 곧 결합도와 부채가 누적되어 변경 한 번에 연쇄 수정이 터진다. 일정이 지속적으로 밀리고, 인력이 늘어도 속도가 오르지 않는 역설에 빠진다.
왜 “좋은 품질”이 곧 이익인가
- 변경 단가 절감: 기능 1개당 투입 공수가 줄어든다. 같은 팀으로 더 많은 가치를 낸다.
- 리스크 비용 감소: 장애·롤백·품질 이슈로 인한 기회비용과 평판 손실을 줄인다.
- 옵션 가치 확보: 아키텍처가 작고 유연할수록 새로운 시도를 싸게 해볼 수 있다.
- 채용·온보딩 비용 축소: 이해 가능한 구조는 합류 속도를 높이고 이탈을 줄인다.
실행 체크리스트(짧고 강하게)
- 최소 아키텍처: “나중에 바꾸기 어려운 것”만 의식적으로 결정하고, 나머지는 쉽게 바뀌게 남겨둔다.
- 경계 먼저: 도메인 경계와 데이터 소유권을 명확히. 통신/트랜잭션 경계는 대체 가능하게.
- 공유된 이해: 다이어그램은 표현 수단일 뿐. 팀 전원이 같은 모델을 말로 설명할 수 있어야 한다.
- 품질 게이트: 작은 단위 테스트·CI/CD·관측(로그/메트릭/트레이싱)으로 변경 비용을 상수화한다.
- 부채 상환 루프: 매 스프린트마다 작은 부채 상환 슬롯을 고정 편성해 누적을 막는다.
한 문장으로 정리하면 이렇다.
좋은 품질에 대한 초기 투자는 “출시 후 매 순간의 생산성”으로 복리처럼 이자 붙여 돌아온다. 그래서 좋은 아키텍처를 고집하는 일은 장인정신이 아니라, 가장 현실적인 이익 극대화 전략이다.