소프트웨어 아키텍처 101

소프트웨어 아키텍처 101, 한빛미디어

현재 담당하고 있는 서비스의 아키텍처를 막연하게 마이크로서비스 아키텍처(Micro Service Architecture,MSA) 스타일로 설계된 것이라고 알고 있었습니다.

독립적으로 실행되는 여러 도메인 서비스로 구성되어 있었기 때문입니다. 저와 함께 일하고 있는 팀원들도 그렇게 인식하고 있었습니다.

물론, 마이크로서비스 아키텍처라고 하기에는 부자연스럽게 보이는 지점들이 분명히 있습니다.

도메인 서비스들이 데이터베이스를 공유하고 있고, 서비스 간 결합도가 생각보다 높았습니다. 또한, 하나의 서비스의 변경이 다른 서비스에 영향을 주는 구조였습니다.

하지만, “서비스를 운영해오면서 구조가 망가진 게 아닐까?”라는 정도로만 가볍게 생각했습니다.

아키텍처에 대한 지식이 없다보니 더 깊게 고민할 수도 없었습니다.

1. 사실은 마이크로 서비스가 아니라, 서비스 기반 아키텍처

그런데 이번에 소프트웨어 아키텍처 101을 읽으면서 한 가지 중요한 사실을 알 수 있었습니다.

소프트웨어 아키텍처 101에서 설명하고 있는 아키텍처 스타일을 기준으로 보니, 제가 담당하고 있는 서비스는 서비스 기반 아키텍처(Service-Based Architecture)에 더 가까웠습니다.

두 아키텍처는 비슷해 보이기도 하지만, 분명히 차이가 있습니다. 그 차이점을 알지 못하고, 그 동안 잘못된 전제 위에서 시스템의 구조를 바라보고 있었던 셈입니다.

서비스 기반 아키텍처라고 판단한 근거는 다음과 같습니다.

  1. 우선 서비스 배포단위가 세분화되어 있지 않았습니다. 큼지막한 기능 단위로만 분리되어 있었습니다. 소프트웨어 아키텍처 101에서는 이를 도메인 서비스라고 표현합니다.
  2. 결정적으로 서비스들이 데이터베이스를 공유하고 있습니다. 마이크로서비스 아키텍처의 핵심 원칙 중 하나인 “서비스별 독립적인 데이터 소유권”과는 거리가 있는 것입니다. 반면, 서비스 기반 아키텍처에서는 데이터베이스를 공유하는 구조가 흔히 나타납니다.

시스템 구조를 그림으로 그려보면 다음과 같습니다.

서비스 토폴로지

서비스는 분리되어 있지만, 데이터 계층은 하나로 묶여 있는 구조입니다. 전형적인 서비스 기반 아키텍처의 형태로 보는 것이 타당합니다.

사실 제가 담당하고 있는 서빗스는 “망가진 마이크로서비스”가 아니라,
“처음부터 서비스 기반 아키텍처로 설계된 구조”였던 것입니다.

2. 마이크로서비스 아키텍처 vs 서비스 기반 아키텍처

두 아키텍처는 “여러 개의 서비스로 시스템을 구성한다.”는 공통점을 가집니다. 하지만, 서비스의 경계와 독립성 수준에서 차이가 있습니다.

2.1. 서비스 단위의 크기

서비스 기반 아키텍처

* 비교적 큰 단위의 도메인 서비스
* 하나의 서비스가 여러 기능을 포함

마이크로서비스 아키텍처

* 매우 작고 명확한 책임 단위
* 하나의 서비스가 하나의 비즈니스 기능에 집중

2.2. 데이터 소유권

서비스 기반 아키텍처

* 서비스들이 데이터베이스를 공유할 수 있음
* 데이터 소유권이 명확히 분리되지 않을 수 있음

마이크로서비스 아키텍처

* 서비스별 독립적인 데이터베이스
* 다른 서비스의 DB에 직접 접근하지 않음
* 데이터는 API 또는 이벤트로만 교환 (👉 **이 부분이 가장 결정적인 차이입니다.**)

2.3. 배포 및 결합도

서비스 기반 아키텍처

* 데이터 공유로 논리적 결합이 존재(서비스는 분리)
* 배포 독립성이 제한적일 수 있음

마이크로서비스 아키텍처

* 서비스 단위의 완전한 독립 배포
* 장애 격리 수준이 높음
* 기술 스택까지 분리 가능

3. 그렇다면 서비스 기반 아키텍처는 나쁜 선택일까?

“그럼 우리 서비스는 잘못된 구조 위에서 운영되고 있었던 걸까요?”

아키텍처를 공부해보니 그런것은 아니었습니다. 서비스 기반 아키텍처가 마이크로서비스 아키텍처보다 덜 발전된 형태인 것은 아닙니다. 그저 적용 맥락이 다른 것 뿐입니다.

전담 아키텍트나 충분한 경험이 없는 상태에서 무리하게 마이크로서비스 아키텍처를 도입하면, 오히려 운영 복잡도만 증가할 수 있습니다.

운영 안정성이 더 중요한 상황에서는 서비스 기반 아키텍처도 충분히 합리적인 선택이 될 수 있습니다.

비즈니스 단위가 비교적 명확하고, 대규모 트래픽 분산이 핵심 요구사항이 아닌 경우에는 큰 단위의 도메인 서비스로 나누는 구조가 오히려 관리하기 쉬울 수 있기 떄문입니다.

특히, 모든 시스템이 마이크로서비스 아키텍처가 보장하는 극단적인 확장성과 완전한 독립 배포를 요구하는 것은 아닙니다.

4. 정리

중요한 것은 “서비스가 어떤 구조 위에서 운영되고 있는지를 정확히 아는 것”이라고 생각합니다.

우리 팀이 운영하고 있는 서비스가 망가진 마이크로서비스 아키텍처 구조가 아니라, 서비스 기반 아키텍처라는 사실을 인정한 순간 불필요한 자책이 사라졌습니다.

과도한 리팩터링 욕심을 버리고, 현실적인 개선 방향을 고민할 수 있을 것 같습니다.

“구조가 이상하다”는 막연한 느낌만 있었지만, 이제는 조금 더 명확하게 우리 서비스의 구조를 설명할 수 있게 되었습니다.

그것만으로도 충분히 의미가 있는 공부였다고 생각합니다.

포스팅 시리즈

#소프트웨어아키텍처101 #한빛미디어 #소프트웨어 #아키텍처 #서비스기반 #마이크로서비스 #MSA