소프트웨어 아키텍처는 확장보다 불변에 의해 결정된다¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
초안: 2022년 07월 / 개정: 2025년 11월

Architecture is decided more by its invariants than by its extensibility.

Abstract¶

많은 사람들이 어떤 아키텍처를 소개할 때, 확장성에 대해서 강조한다.
하지만 실제로 아키텍처의 생명주기, 즉 '아키텍처 사망'을 결정짓는 것은, 무엇을 쉽게 바꿀 수 없는지(불변 요소, invariants)다.
예를 들어, MSA(Microservices Architecture)는 서비스 단위로 시스템을 쪼개어 필요에 따라 독립적으로 확장할 수 있다는 점이 주로 부각된다.
MSA는 서비스 간 호출에 네트워크 처리가 필수적으로 발생한다.
또한 서비스는 각자의 데이터를 독점해야 한다는 원칙이 존재한다.
이를 지키지 않으면, 비용은 치르나 이점은 얻을 수 없다.
때문에 아키텍처의 선택은 어떤 확장성을 가질 것인가가 아니라, 어떤 비용을 기꺼이 치를 것인가를 핵심으로 해야 한다.
절대로 치를 수 없는 비용을 대가로 해서는 안 된다.
MSA는 특성상, 동일한 컴퓨팅에 대해, 더 높은 네트워크 사용률, 더 높은 CPU 사용률을 가질 수밖에 없다.
배치가 유연한 만큼 코딩에 제약사항이 있는 등, 이미 비용을 치르고 시작한다.
동적 배치를 관리할 관리 인력이 필연적으로 있어야 이익을 회수할 수 있다.
이는 MSA가 소규모 서비스, 가령 AWS EC2 기준 8vCPU / 32GiB 머신 5대 이하 + 로드밸런서의 규모에서는 MSA가 투자 대비 효용(ROI)을 가지기 어렵다는 것을 의미한다.
넷플릭스는 처음부터 MSA로 개발하지 않았다. 기존 자신들의 구조가 한계에 가까워졌을 때, MSA로 전환하였다.

확장성이란?¶

확장성이란 시스템이 증가하는 부하, 데이터, 사용자 수요에 맞춰 성능 저하 없이 유연하게 자원을 늘리거나 구조를 변경할 수 있는 능력을 의미한다. 예를 들어, 사용자가 급증할 때 서버를 추가하거나, 신규 외부 시스템과 연동을 추가하는 등 예상되지 않은 변동성에 대한 대응 능력을 말한다.

하지만 모든 메커니즘은 고유 특질에 의해 불가분의 단점과 비용을 함께 가지고 온다.

불변 요소이란?¶

불변 요소이란 시스템 구조나 운영에서 쉽게 바꿀 수 없는 제약, 즉 변화가 불가능한 '구조적 한계'를 의미한다. 가령 파이프라인 아키텍처를 선택했을 때, 개별 파이프 블록은 쉽게 교체가 가능하나, 시작과 끝이 정해진 파이프 구조 자체를 버릴 수는 없다. 또한 파이프를 타고 흐르는 데이터의 규격을 바꾸는 것도 쉽지 않다. 데이터 규격은 모든 파이프 블록이 엄수하는 약속이므로 변경은 호환성의 완전 상실을 의미하기 때문이다. 이러한 요소에 비하면, 선형 구조의 파이프를 분기가 존재하는 T자 파이프 구조로 변경하는 것은 보다 작은 규모의 문제이다.

Architecture Lifecycle¶

아키텍처의 생명주기는 설계, 도입, 운영, 변경, 그리고 폐기까지의 전 과정을 의미한다. 코드는 물리적 자산보다는 수정이 비교적 쉽고, 리팩토링 기술 또한 발전하였다. 그러나 모든 아키텍처는 시스템 전체를 지탱하는 데 있어, 가장 중요한 등뼈가 있기 마련이며, 이 등뼈를 부수기는 어렵다.

때문에 요구사항이 아키텍처가 가진 불변적 제약에 부딪히는 순간, 더 이상 획기적인 변화가 어려워지며, 이때가 바로 아키텍처가 '폐기'에 다가가는 시점이다.

넷플릭스는 처음부터 MSA로 개발하지 않았다. 기존 자신들의 구조가 한계에 가까워졌을 때, MSA로 전환하였다.

MSA의 비용구조¶

MSA는 매우 높은 고정비를 가진다. 마케팅적으로 '유연한 배치'라고 말하지만, 솔직히 그것은 '무작위 배치'이다. 우리는 사용자가 어디에 몰려들지 예언할 수 없다. 때문에 MSA는 시작부터 '무작위 배치'에 대응하기 위한 등뼈를 가지고 출발한다. 이는 개발 전 과정에서 단위 서비스 간 데이터 공유 불가, 달리 말해 모든 데이터 조달 비용이 발생하며, 트랜잭션(롤백 가능 등)은 기본적으로는 서비스 내부에서만 성립한다. 또한 단순 함수 호출(메모리 내 주소 이동)은 네트워크 송수신으로 변경되며, 그 지연 시간과 비용이 모두 계산되어야 한다. 또한 각 서비스별로 각자의 사용량에 따라 데이터베이스를 확장하기 위해서는, 다수의 소규모 데이터베이스와 저장소의 관리도 염두에 두어야 한다. 그렇지 않으면, 전체 시스템의 가용성은 DB 사양으로 제한된다. 물론 이에 대한 백업과 복원의 관리도 비용이다. 아울러 이만한 대가를 치른 효용성을 회수하려면, 당연히 '관리 인력이 상주'해야 한다. 배포와 운영의 자동화는 장점이 아니라, 비용 회수를 위한 필수 불가결한 결과일 뿐이다.

작은 규모에서 MSA를 사용한다면, 개발비는 3배, 운영비는 5배에 직면할 수 있다.

MSA의 RoI(Return on Investment) 구조¶

MSA의 투자 대비 효용(ROI)이 달성되려면, 동일 연산에 대해서도 상대적으로 많은 고정비를 감당해야 하므로, 시스템이 고부가가치를 가져야 한다.

즉, 브랜드 가치 따위를 등에 업고 (잠재적 경쟁사의 최소 원가보다) 비싸게 팔아야 한다.

모든 내부 처리에 네트워크 오버헤드가 존재하는 이상, 지연 시간에 관대해야 한다.

그러니까, 증권거래 시스템은 MSA로 만들면 안 된다.

MSA는 다대륙 IDC 배포도 가능하지만, 그 경우 지연 시간에 10배는 더 관대해야 한다.

파편화된 소규모 데이터베이스가 다수가 되긴 하겠으나, 개별 저장소는 워크로드 구조가 단순하여, 최적화 및 분산을 달성하기 매우 유리하다. 하지만 동시에 이 역할을 수행할 충분한 숫자의 DBA가 필요하다.

MSA 내부 서비스 유닛의 증가를 클라우드로 자동 조절한다고 해도, 네트워크 인프라를 모니터링하고 대응할 인력도 필요하다.

특히, 수요가 시간/일 단위로 변동하는 탄력적인 '상황'이 존재해야, 많은 관리 인력이 효용성을 가지게 된다.

On-Premise와 경제성을 비교하면...

On-Premise가 개발비가 상대적으로 적지만, 최대 수용량을 추정하고 그에 맞는 운영 규모를 24/7 유지
MSA는 개발비는 더 들어가지만, 현재 적정 수용량에 맞춰 상시로 운영 규모 조정

즉 탄력 운영을 통해, 운영비로 개발비용 회수라는 상황 자체가 만들어지지 않으면 MSA는 경제성이 없다.

소규모 스타트업이 이 비용을 치를 수 있는가?¶

누군가는 할 수 있다고 할지 모르겠으나, 나는 절대 안 한다.

MSA의 구조적 비용과 운영 복잡성은 소규모 스타트업에게는 감당하기 어려운 수준이다. 스타트업은 한정된 인력과 자원, 빠른 시장 진입이 중요한 환경에서 운영된다. 이 상황에서 MSA의 네트워크 오버헤드, 데이터 일관성 관리, 모니터링 요구, 다수의 데이터베이스 관리 등은 오히려 개발 속도를 늦추고, 운영 부담만 가중시킨다.

MSA의 진정한 효용은 대규모 트래픽, 빈번한 서비스 확장, 다수의 독립적 개발팀이 존재할 때 비로소 발휘된다. 즉 거대기업이 내부 요소를 전문화된 소규모 벤처처럼 잘게 나누어, 부분 최적화를 달성함으로써 전체 최적화를 달성하는 방식이다.

그러나 알고리즘을 공부해본 사람이라면, Greedy 전략이 항상 잘 작동하는 건 아니라는 것을 알 것이다.

결론¶

어떤 선택을 하던, '절대로 장점을 보고 아키텍처를 골라선 안된다'.

일반적으로 IT 시스템의 수명은 5~10년으로 7년이라고 생각하면 된다.
아키텍처는 시스템의 등뼈이고, 최소한 5년간은 변경하기 어렵다. 모듈을 격리 단위만 재개발하여 바꿔 끼울 수 있으나, 아키텍처를 바꾸는 것은 모듈 간 소통 방식을 변경한다는 의미이며, 거의 모든 모듈을 수정한다는 뜻이다. 또한 각 상황에 대한 성능 특성도 달라지게 된다.

현실적으로 아키텍처의 변형(variation)은 가능해도, 변경(change)은 불가능하다.

Check List

각각의 아키텍처가 요구하는 대가를 확인해라.
우리에게 적어도 5년간 변하지 않을 사실을 확인해라.
거의 유사한 장점을 가졌으나, 대가가 전혀 다른 선택지는 얼마든지 있다.
기꺼이 치를 수 있는 비용을 요구하는 아키텍처만 선택지로 고민하라.

SeeAlso¶

소프트웨어 아키텍처는 의사결정이지, 모방이 아니다 - 아키텍처 결정하기
One Man Framework 가능성의 증명 - MSA가 아니라서 더 유리한 사례
디자인 패턴은 본래 고쳐 쓰는 것이다 - 디자인 패턴도 정해진 내용이 확장성보다 중요하다.

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University