AI 시대의 소프트웨어 아키텍처

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

원제 : Fundamentals of Software Architecture 2E
저자 : Mark Richards, Neal Ford
출판 : 한빛미디어, 2025 / O’Reilly, 2025

멋진 책이 돌아왔다. 초판도 많은 내용을 담고 있으나, AI 시대의 흐름에 따른 아키텍처 고려사항과 클라우드를 고려한 비용분석 내용이 추가되어 현행화를 이뤄냈다. 이번에는 새로운 2판을 읽어보면서 그간 나는 2022년과 달리 얼마나 생각이 변했고, 새로운 내용들은 어떤것인지 알아보는 시간을 가져보려 한다.

커리어 패스를 지나오면서 좋은 기회로 ‘새로운 제품 프로젝트’에 들어갈 기회가 있었다. 메이저 버전이 릴리즈 된 마당에 소회를 하자면 ‘그리 마음에 들지는 않지만, 레거시보다는 나아졌다’ 라고 자가평가 할 수 있겠다. 프로젝트 수행시 모든 수단과 방법을 최신 유행 공법으로 할 수 도 없고, 생각보다 타협을 봐야 하는 지점들이 많았다. 이 책의 서두에는 ‘모든 전략적 결정에는 트레이드오프가 따른다’ 라고 소개한다.

트레이드오프, 그리고 스펙트럼의 사고

프로젝트를 진행하면서 항상 의문인것은 설계와 아키텍처의 모호한 경계였다. 2장에서는 ‘아키텍처적 사고’를 다루면서 이 경계를 흥미롭게 풀어낸다. 집의 구조를 정의하는 것은 아키텍처고, 바닥이 카펫인지 원목인지는 설계라는 비유가 직관적이다. 하지만 현실의 결정은 대부분 이 둘 사이 어딘가에 위치한다. 마이크로서비스를 선택하면 구조가 바뀌니 아키텍처 쪽이고, UI 프레임워크 선택은 설계에 가깝지만, 그 사이의 수많은 결정들은 스펙트럼의 한 지점에 있다.

이번판에는 아키텍처의 ‘특성’을 추출하고 이를 분류하면서 도메인 이해관계자들과 협업할 때 제한과 우선순위를 어떻게 부여해야 하는지 설명하는 부분이 추가되었다. 4장과 5장은 이를 상세히 다룬다. 특히 5장의 ‘아키텍처 특성 워크시트’는 실무에서 바로 쓸 수 있는 도구다. 이해관계자들에게 “어떤 특성을 지원할까요?”라고 물으면 돌아오는 답은 늘 “전부 다”라는 관찰이 현실적이다. 워크시트는 최대 7개 칸으로 목록을 강제로 짧게 만들고, 최종적으로는 가장 중요한 3가지로 합의하라고 조언한다. 범용 아키텍처를 만들려는 욕망을 경계하고, 정말 중요한 것에 집중하게 만드는 장치다.

아키텍처 스타일의 지도

Part2는 이 책의 핵심이다. 모놀리스와 분산, 기술적 분할과 도메인 분할이라는 축을 중심으로 다양한 아키텍처 스타일을 펼쳐놓는다. 각 스타일은 토폴로지, 데이터 구조, 클라우드 고려사항, 팀 토폴로지, 그리고 언제 사용하면 좋고 언제 피해야 하는지까지 일관된 형식으로 정리되어 있다.

계층형 아키텍처는 가장 익숙한 스타일이다. 표현, 비즈니스, 영속성 계층으로 나뉘는 기술적 분할 방식이다. 작고 단순한 애플리케이션이라면 여전히 좋은 출발점이지만, 규모가 커질수록 유지보수성과 민첩성이 나빠진다. 이 스타일은 팀 구성과 무관하게 쓸 수 있지만, 클라우드 배포 시 계층을 모두 거쳐야 하는 구조 때문에 통신 지연이 문제가 될 수 있다.

파이프라인 아키텍처는 ‘파이프와 필터’로 불리는 단순하면서도 강력한 스타일이다. 각 필터가 단일 목적을 수행하고, 파이프로 단방향 연결된다. ETL 처리나 데이터 변환 작업에 자연스럽게 들어맞는다. AWS Step Functions 같은 클라우드 서비스와도 궁합이 좋다. 다만 필터 간 계약 관리와 오류 처리는 신경 써야 할 부분이다.

마이크로커널 아키텍처는 ‘플러그인 아키텍처’라고도 하는데, 제품 기반 애플리케이션에 특히 적합하다. 코어 시스템과 플러그인으로 구성되며, 확장성과 맞춤형 처리가 핵심이다. 다만 플러그인을 클라우드에 분리 배치하면 지연시간이 추가 부담으로 이어질 수 있어 주의가 필요하다.

서비스 기반 아키텍처는 마이크로서비스의 덜 복잡한 변형이다. 성긴(coarse-grained) 서비스들로 구성되며, 보통 모놀리스형 데이터베이스를 쓴다. 비즈니스 애플리케이션에서 많이 쓰이는 실용적인 스타일이다. 마이크로서비스만큼 극단적으로 분리하지 않으면서도 분산의 이점을 누릴 수 있다. 도메인 단위로 팀을 구성했을 때 가장 효과적이다.

이벤트 주도 아키텍처는 고확장성과 고성능이 필요한 곳에 쓰인다. 요청 기반 모델과 달리, 특정 이벤트에 반응해 행동을 취한다. 저자들은 EDA를 패턴이 아니라 스타일로 본다. 비동기 통신의 이점을 최대한 활용할 수 있지만, 비결정론적 이벤트 처리와 데이터 손실 방지는 복잡한 과제다. AMQP나 카프카 같은 메시징 인프라와 관측성이 필수다.

공간 기반 아키텍처는 독특하다. 중앙 DB가 확장의 병목이라는 전제에서 출발해, 메모리 내 데이터 그리드를 복제해 높은 확장성을 달성한다. 동시 사용자 수가 가변적이고 예측 불가능한 시스템에 적합하다. 클라우드와 온프레미스를 동시에 배포할 수 있다는 점이 다른 스타일에서는 찾기 어려운 강점이다.

오케스트레이션 주도 SOA는 “한때는 그럴듯했지만 결국 사장된 아키텍처”로 소개된다. 서비스 분류 체계와 엄격한 계층 구조가 특징인데, 이것이 오히려 팀 간 소통을 막고 개발 속도를 늦춘다. 저자들은 이 스타일을 “1법칙을 무시할 때 생기는 위험”의 본보기로 제시한다. 다만 현재는 클라우드와 온프레미스를 통합하는 용도로는 여전히 쓸 만하다고 평가한다.

모듈형 모놀리스의 귀환

초판 이후 DDD가 널리 채택되고 도메인 분할에 대한 관심이 높아지면서, 모듈형 모놀리스가 큰 인기를 끌었다. 그래서 2판에는 11장이 새로 추가됐다. 이 스타일은 모놀리스이지만 도메인 분할 방식을 따른다. 패키지 네이밍부터 다르다. 계층형이 com.app.presentation.customer.profile처럼 기술 관심사를 앞에 두는 반면, 모듈형 모놀리스는 com.app.customer.profile처럼 도메인을 먼저 둔다.

이 스타일의 위험은 명확하다. 시스템이 너무 커지거나, 코드 재사용을 과도하게 하거나, 모듈 간 통신이 너무 많아지면 비정형 모놀리스로 전락한다. 경계가 흐려지고 분석이 어려워진다. 그래서 도메인을 처음부터 잘 정의하는 것이 중요하다. 모듈형 모놀리스는 도메인 전문성을 가진 교차 기능 팀과 가장 잘 맞는다. UI/백엔드/DB로 팀을 나누는 기술 분할 방식과는 궁합이 나쁘다.

마이크로서비스, 재사용과 중복의 트레이드오프

18장은 마이크로서비스를 다룬다. 이 스타일은 DDD의 경계 컨텍스트에서 영감을 받았고, ‘무공유(share nothing)’ 아키텍처라고도 불린다. 전통적인 모놀리스가 재사용 가능한 클래스와 공용 DB로 개념을 공유했다면, 마이크로서비스는 경계 컨텍스트 밖의 외부 요소와 결합하는 것을 절대 허용하지 않는다. 재사용을 제한하고 필요하면 중복을 허용한다. 1법칙의 전형적인 사례다. 재사용을 위해 상속과 조합을 쓰다 보면 결합도가 높아진다. 목표가 고도로 분리된 시스템이라면 중복을 선호하는 것이 합리적이다.

코레오그래피와 오케스트레이션의 선택도 흥미롭다. 코레오그래피는 중앙 조정자 없이 각 서비스가 필요한 다른 서비스를 직접 호출한다. 고도로 분리된 철학을 유지하지만 오류 처리가 복잡해질 수 있다. 반면 오케스트레이션은 중재자 서비스를 두어 복잡한 비즈니스 프로세스를 조정한다. 프런트 컨트롤러 패턴의 문제를 피할 수 있지만 중재자 자체가 병목이 될 수 있다.

트랜잭션 문제는 더 까다롭다. 마이크로서비스에서는 DB도 분리되는 것이 바람직한데, 그러면 원자성 보장이 어려워진다. 저자들은 “서비스 간 트랜잭션을 원하는 아키텍트에게 우리가 해줄 수 있는 최고의 조언은 ‘하지 마세요!’이다”라고 단호하게 말한다. 불가피하다면 사가 패턴을 쓸 수 있지만, 보상 트랜잭션 처리까지 고려하면 복잡도가 급격히 올라간다. 서비스 경계를 넘나드는 트랜잭션이 아키텍처의 지배적 특징이 될 정도로 빈번하다면, 마이크로서비스가 올바른 선택이 아닐 가능성이 높다.

마이크로서비스는 클라우드 네이티브 아키텍처로 불릴 만큼 클라우드와 궁합이 좋다. 서버리스에 대한 저자들의 관점도 명확하다. 서버리스는 아키텍처 스타일이 아니라 마이크로서비스의 배포 모델 중 하나다. AWS Lambda나 Azure Functions 같은 서버리스 함수도 ‘단일 목적, 독립 배포’라는 마이크로서비스 정의에 부합하지만, 컨테이너 기반 배포도 충분히 쉽고 유연하다.

일반적인 위험도 짚고 넘어간다. 서비스를 너무 작게 만드는 ‘모래알 안티패턴’과 서비스 간 통신이 너무 많아지는 문제다. ‘마이크로’는 크기가 아니라 서비스가 하는 일이라는 점을 명심해야 한다. 과도한 동적 결합이 발생한다면 서비스들을 더 성긴 단위로 통합하는 것도 방법이다.

스타일을 고르는 법

19장은 “상황에 따라 다르다”를 실제로 작동시키는 장이다. 아키텍처 유행은 계속 바뀐다. 과거 경험에서 얻은 통찰, 생태계의 변화, 새로운 역량의 등장, 가속화, 도메인의 변화, 기술의 변화, 외부 요인 등 여러 이유 때문이다. 쿠버네티스가 불과 몇 년 만에 일상 도구가 된 것처럼, 앞으로 몇 년 안에 그것도 다른 도구로 대체될 수 있다. 생성형 AI의 부상은 끝없는 발전과 예측 불가능성을 보여주는 대표 사례다.

스타일을 선택할 때는 도메인, 아키텍처 특성, 데이터 아키텍처, 클라우드 배포, 조직 요인, 프로세스와 팀, 도메인과 아키텍처의 동형성 등을 고려해야 한다. 특히 아키텍처 특성 분석이 핵심이다. 대부분의 문제 도메인은 거의 모든 범용 스타일로 구현 가능하다. 중요한 차별점은 어떤 특성들을 얼마나 잘 지원하느냐에 있다.

도메인과 토폴로지의 궁합도 중요하다. 마이크로커널은 맞춤성이 필요한 시스템에, 공간 기반은 유전체 분석처럼 병렬 처리가 많이 필요한 시스템에 적합하다. 반대로 결합도가 높은 코드베이스는 분산 아키텍처와 맞지 않고, 의미적 결합이 큰 도메인(다중 페이지 form 같은)은 마이크로서비스보다 서비스 기반 아키텍처가 낫다.

최종 결정은 세 가지 질문으로 정리된다. 모놀리스냐 분산이냐, 데이터는 어디에 둘 것인가, 서비스 간 통신은 동기적인가 비동기인가. 저자들은 “가능하면 동기를 기본으로, 필요할 때만 비동기”를 권장한다. 비동기는 규모와 성능 이점이 있지만 데이터 동기화, 교착, 경쟁 조건, 디버깅에서 많은 골칫거리를 유발한다.

팀과 아키텍트의 역할

24장은 팀을 다룬다. 기술적 아키텍처를 만들고 아키텍처적 결정을 내리는 것으로 아키텍트의 일이 끝나지 않는다. 개발 팀을 이끌고 구현 과정에서 지침을 제공할 책임이 있다. 전통적인 모델에서는 아키텍트의 결정이 개발 팀에 단방향으로만 전달되고, 개발 팀의 변경은 아키텍트에게 돌아오지 않는다. 이런 분리 모델에서는 아키텍처 목표가 거의 달성되지 않는다. 강력한 양방향 협업 관계를 형성해야 한다.

제약조건과 경계의 조절도 아키텍트의 몫이다. 경계가 너무 엄격하면 불만이 생기고, 너무 느슨하면 혼란이 생긴다. 적당한 경계에서 유능한 팀이 만들어진다. 얼마나 관여할지는 팀 친숙도, 팀 규모, 경험 수준, 프로젝트 복잡성, 프로젝트 기간 등 다섯 가지 요인으로 판단한다. 탄력적 리더십이 필요한 지점이다.

팀이 커지면 프로세스 손실, 다원적 무지, 책임 확산 같은 이상 징후가 나타난다. 병합 충돌이 자주 발생한다면 같은 코드를 수정하며 서로의 작업을 방해하고 있을 가능성이 있다. 회의에서 표정과 몸짓을 관찰해 다원적 무지를 감지하고, 안전하게 말할 수 있는 환경을 만들어야 한다. 팀이 커질수록 의사소통이 나빠지고 책임이 불명확해진다면 팀이 너무 크다는 신호다.

Part2의 모든 장에는 팀 토폴로지 고려사항이 추가됐다. 스트림 정렬 팀, 활성화 팀, 난해한 하위시스템 팀, 플랫폼 팀이 각 아키텍처 스타일과 어떻게 어울리는지 구체적으로 설명한다. 도메인 분할 아키텍처는 도메인 영역별 팀과, 기술적 분할 아키텍처는 기술 범주별 팀과 궁합이 좋다. 하지만 예외도 많고, 스타일마다 미묘한 차이가 있다. 이런 세밀한 가이드가 2판의 큰 강점이다.

변화하는 생태계 속에서

이 책을 덮으며 드는 생각은, 아키텍처가 결국 끊임없는 선택의 연속이라는 것이다. 완벽한 아키텍처는 없다. 모든 결정에는 트레이드오프가 따른다. 중요한 것은 무엇을 얻고 무엇을 포기하는지 명확히 이해하고, 그 이유를 설명할 수 있는가다. 초판을 읽고 3년이 지난 지금, 나는 여전히 트레이드오프 앞에 서 있다. 하지만 이제는 조금 더 담담하게, 그리고 조금 더 명확한 근거를 가지고 선택할 수 있게 됐다.

2판은 초판의 탄탄한 기초 위에 모듈형 모놀리스, 팀 토폴로지, 클라우드 고려사항, 그리고 AI 시대의 고민을 더했다. 변화의 속도가 점점 빨라지는 시대에, 변하지 않는 원칙과 변화에 대응하는 방법을 동시에 제시한다. 소프트웨어 아키텍트로 성장하고 싶다면, 그리고 설계와 아키텍처 사이의 모호한 경계에서 방향을 잡고 싶다면, 이 책은 여전히 가장 믿음직한 나침반이다.