소프트웨어 아키텍처는 종종 ‘정답이 있는 기술 문제’로 오해되지만, 실제로는 수많은 선택과 타협의 연속입니다. 완벽한 구조를 쫓는 대신, 상황에 맞는 균형점을 찾는 능력이 점점 더 중요해지고 있죠. 이 글에서는 많은 개발자가 빠지는 세 가지 착각인 트레이드 오프, MSA, 그리고 소프트 스킬을 통해 아키텍처를 바라보는 관점을 어떻게 다시 세워야 하는지 이야기해 보려 합니다.

Q1. 완벽한 아키텍처가 존재한다?

A. NO!

왜냐하면 아키텍처의 모든 결정은 ‘트레이드오프’이기 때문입니다.  “소프트웨어 아키텍처의 모든 것은 트레이드오프다” 라고, 『소프트웨어 아키텍처 The Basics(2판)』에서도 소프트웨어 아키텍처의 첫 번째 법칙이라며 아주 분명하게 말하는 것처럼요. 

아키텍처는 어떤 선택을 하면 그 선택이 가져오는 장점뿐만 아니라, 동시에 감수해야 하는 단점도 같이 따라온다는 의미입니다.  그래서 ‘정답 아키텍처’는 애초에 존재하지 않는 것이죠. 

많은 개발자분들이 구글이나 넷플릭스의 아키텍처를 보면서  “저 구조가 성공의 비결인가 보다!” 하고 그대로 따라 하려는 경우가 많은데요, 책은 이것이 큰 착각이라고 말합니다. 그 이유는 간단합니다. 

그 기업들은 자신들의 규모·조직 문화·운영 방식·트래픽·인력 구조에 맞춰 수많은 결정을 반복해 왔기 때문입니다. 같은 아키텍처라 하더라도 환경이 다르면 결과도 완전히 달라지게 마련입니다.

책에서는 이런 경고도 덧붙입니다.

“트레이드오프가 아닌 무언가를 발견했다고 생각한다면, 아직 트레이드오프를 못 찾은 것일 가능성이 높다.”
“트레이드오프 분석을 한 번만 하고 끝낼 수는 없다.”

즉, 아키텍처는 고정된 해답이 아니라 상황이 바뀔 때마다 다시 따져봐야 하는 ‘살아있는 판단의 연속’이라는 뜻입니다. 그래서 완벽한 아키텍처는 없고, 최적의 균형점을 찾는 능력이 진짜 아키텍트의 핵심 역량이라고 말하는 것이죠.

Q2. 마이크로서비스(MSA)가 무조건 정답이다?

A. NO!

상황에 따라 ‘모듈형 모놀리스’도 훌륭한 선택지가 될 수 있습니다. 하지만 요즈음의 개발자들에게는 “모놀리스는 구식 / 나쁜 것, MSA는 정답” 이라는 인식이 지배적이었습니다. 이 통념을 이번 2판에서 정면으로 반박합니다. 무려 ‘모듈형 모놀리스’를 하나의 독립된 챕터(11장) 로 새롭게 추가했을 정도니까요.

책에서는 모듈형 모놀리스가 다음과 같은 이유로 매우 실용적이라고 말합니다.

“단순하고 비용이 낮아서, 예산과 시간이 빠듯할 때 좋은 선택이다.”

“초기에는 모듈형 모놀리스로 시작하고, 필요할 때 분산 아키텍처로 전환하는 것이 효과적이다.”

“도메인 중심 팀(CFT)과 잘 맞고, 각 팀이 독립적으로 모듈을 소유하고 개발할 수 있다.”

MSA처럼 처음부터 모든 것을 나누고 분산시키는 방식은 복잡성, 비용, 운영 난이도 측면에서 너무 큰 부담이 됩니다. 반대로, 모듈형 모놀리스는 구조적 모듈화는 유지하면서도 배포·운영은 단일 체계로 유지해 복잡성을 크게 낮출 수 있는 아키텍처죠.

더불어 이번 2판에서 추가된 아키텍처의 세 번째 법칙에 따르면 “대부분의 아키텍처 결정은 양자택일이 아니라 스펙트럼이다”라는 개념은  MSA vs 모놀리스처럼 흑백으로 나누는 사고 자체가 잘못임을 강조합니다.

Q3. 아키텍트는 코딩과 기술만 잘하면 된다?

A. 기술만 잘해선 절대 부족하다!

'협상과 리더십이 없는 아키텍트는 실패한다.' 아키텍처는 기술 결정뿐만 아니라, 팀 구조, 비즈니스 요구사항, 그리고 사람 간의 소통이 얽혀 있는 문제입니다. 코드를 넘어 조직과 비즈니스를 이해해야 진짜 아키텍트가 될 수 있습니다. 기술만 잘하는 아키텍트는 반드시 한계를 만나게 되죠. 아키텍처를 기술적인 결정만으로 생각하면 쉽게 실패합니다. 책에서는 아키텍트에게 필요한 역량 중 상당 부분이 오히려 사람·팀·조직과 관련된 능력이라고 분명히 말합니다.

왜 그럴까요? 아키텍처는 설계 문서 한 장으로 끝나는 일이 아니기 때문입니다. 실제로는 팀 구성, 개발자 간의 소통, 비즈니스 이해관계, 조직 구조, 협업 방식 등 수많은 비기술적 요소가 얽힌 종합적인 문제이기 때문이죠. 책에서는 전통적인 아키텍트-개발자 분리 구조가 실패하는 이유를 이렇게 지적합니다.

“아키텍트와 개발자 사이의 장벽이 모든 문제의 원인이다.”

“아키텍트와 개발 팀 사이에 강력한 양방향 협업 구조가 필요하다.”

즉, 아키텍트는 설계만 잘한다고 역할이 끝나는 것이 아니라, 팀이 제대로 구현할 수 있도록 조율하고 설득하고 협력하는 능력이 필수적입니다. 그래서 이 책에서는 아키텍트를 위한 협상, 커뮤니케이션, 리더십, 팀 페어링 등의 소프트 스킬을 매우 강조합니다.  코드를 넘어 조직과 사람을 이해하는 아키텍트여야 비로소 아키텍처가 현장에서 살아 숨 쉬게 되는 것이죠.

오늘날의 소프트웨어 아키텍처는 하나의 스펙트럼 위에 놓여 있습니다. 한쪽에는 복잡한 시스템을 빠르게 구축하는 클라우드 네이티브 개발이, 다른 한쪽에는 생성형 AI를 활용해 아키텍처 사고·도식화·분석까지 진화시키는 현대적 엔지니어링이 있습니다.

전판 『소프트웨어 아키텍처 101』이 아키텍트의 기초 체력을 다지는 책이었다면, 새롭게 돌아온 『소프트웨어 아키텍처 The Basics(2판)』은 생성형 AI, 클라우드·데이터·팀 토폴로지 등 지난 10년간의 변화를 모두 반영하여 ‘지금 당장 실무에서 통하는 아키텍처 사고방식’을 다시 설계한 업그레이드판입니다.

막연했던 아키텍처의 세계가 선명해지는 경험을 이 책과 함께 해보시길 바랍니다.