소프트웨어 아키텍처 패턴으로 시스템 구조 설계하기

코드 바깥에서 시스템의 골격을 정하는 일

소프트웨어 아키텍처 패턴은 시스템의 기본 구성 스키마와 하위 시스템 사이의 관계를 정리하는 규칙이다. 개별 객체나 모듈의 설계에 집중하는 디자인 패턴보다 한 단계 위에서, 시스템 전체의 골격을 결정하는 의사결정에 가깝다.

이런 구조를 공유하면 팀은 같은 설계 언어로 대화할 수 있다. 검증된 형태를 출발점으로 삼아 설계 단계의 시행착오를 줄이고, 성능·보안·가용성 같은 비기능 요구사항도 구조 차원에서 다룰 수 있다.

계층을 나누고 책임을 분리하는 방식

계층화 패턴

계층화 패턴은 시스템을 논리적으로 분리된 계층으로 구성한다. 각 계층은 자신에게 맡겨진 역할에 집중하고, 하위 계층이 제공하는 추상화된 서비스만 사용한다.

대표적으로 사용자 인터페이스를 맡는 프레젠테이션 계층, 도메인 로직을 처리하는 비즈니스 계층, 데이터를 영속적으로 저장하는 데이터 계층으로 구분할 수 있다. 이런 분리는 특정 계층의 기술 스택을 바꿀 때 다른 계층에 미치는 영향을 줄인다. 예를 들어 오라클 데이터베이스를 마이 SQL로 변경할 때 데이터 액세스 계층만 수정하면 된다.

반면 계층이 늘어날수록 요청이 여러 단계를 통과해야 하므로 성능 오버헤드가 생길 수 있다.

클라이언트-서버 패턴

클라이언트-서버 패턴은 리소스를 관리하는 서버와 이를 사용하는 클라이언트를 구분하는 네트워크 아키텍처다. 서버는 여러 클라이언트 요청을 받아 데이터를 조회하거나 변경한 뒤 결과를 반환한다. 클라이언트는 사용자 접점에서 요청을 만들고, 받은 결과를 가공해 보여준다.

서버에 부하가 집중될 수 있지만, 데이터 관리가 중앙에 모이므로 보안 정책을 수립하고 데이터 무결성을 유지하기 수월하다.

마스터-슬레이브 패턴

마스터-슬레이브 패턴은 작업을 지시하는 마스터 컴포넌트와 이를 수행하는 여러 슬레이브 컴포넌트로 구성된다. 마스터가 작업을 분할해 배분하면 슬레이브는 맡은 결과를 제출하고, 마스터는 이를 취합해 최종 결과를 만든다.

데이터베이스 복제 시스템에서는 마스터가 쓰기 작업을 맡고 슬레이브가 읽기 작업을 맡아 성능을 분산하는 용도로 활용된다.

브로커 패턴

브로커 패턴은 분산 환경의 컴포넌트가 서로의 물리적 위치를 알지 못해도 통신하도록 만드는 중개 구조다. 서비스 제공자는 브로커에 서비스를 등록하고, 클라이언트는 필요한 기능을 브로커에 요청한다. 브로커는 요청에 맞는 서비스 제공자를 찾아 전달한다.

구성 요소의 위치가 바뀌거나 서비스가 추가돼도 클라이언트 코드를 수정할 필요가 없다는 점이 이 구조의 장점이다.

사용자 인터페이스는 MVC로 나눌 수 있다

MVC는 사용자 인터페이스를 포함한 애플리케이션에서 데이터와 화면, 입력 처리를 분리하는 설계 지침이다.

모델은 시스템의 핵심 데이터와 이를 조작하는 로직을 담으며, 뷰나 컨트롤러에 의존하지 않는 독립적인 형태여야 한다. 뷰는 모델의 상태를 시각적으로 표현하고, 하나의 모델에 여러 뷰가 연결될 수 있다. 컨트롤러는 사용자 입력을 해석해 모델 상태를 바꾸거나 뷰를 업데이트한다.

이 구분 덕분에 디자이너는 뷰를 수정하고 개발자는 로직을 개선하는 병렬 작업이 가능해지며, 코드 재사용성도 높아진다.

정해진 해법이 없는 문제와 규칙 해석

블랙보드 패턴

블랙보드 패턴은 결정적인 알고리즘이 없는 복합 문제에 적합하다. 블랙보드는 현재 문제 상태와 부분 해법을 기록하는 중앙 메모리다. 독립적인 지식 소스 모듈은 이 내용을 확인하고 자신이 풀 수 있는 부분이 있으면 결과를 갱신한다. 제어 시스템은 어떤 지식 소스를 활성화할지 결정한다.

인터프리터 패턴

인터프리터 패턴은 자주 바뀌는 규칙이나 특정 도메인 언어를 처리할 때 사용한다. 각 문법 규칙을 클래스로 정의하고 이를 조합해 복잡한 식을 평가한다. SQL 파서나 통신 프로토콜 해석기처럼 특정 형식의 데이터를 해석해야 하는 분야에 적용할 수 있다.

요구사항이 패턴 선택을 결정한다

성능을 우선해야 한다면 단순하고 직관적인 파이프-필터 또는 마스터-슬레이브 구조가 유리할 수 있다. 유연성과 확장성이 중심이라면 마이크로서비스 전환에 적합한 브로커나 이벤트 버스 패턴을 검토할 수 있다. 사용자 경험이 중요한 경우에는 UI 로직을 체계적으로 관리하기 위해 MVC나 그 변형인 MVVM을 적용할 수 있다.

처리 속도가 핵심인 데이터 스트리밍 서비스에는 파이프-필터 패턴이 맞을 수 있다. 대규모 사용자 트래픽을 처리해야 하는 웹 서비스라면 클라이언트-서버 구조를 기반으로 하는 다층 구조(N-tier)나 이벤트 기반 아키텍처를 고려해야 한다. 확장성과 가용성이 우선인 경우에는 마이크로서비스 아키텍처의 근간이 되는 브로커 패턴이나 이벤트 버스 패턴을 심도 있게 검토할 필요가 있다.

완벽한 하나의 패턴은 없다. 팀의 숙련도, 개발 기간, 향후 확장 계획까지 함께 살피고, 각 구조가 제공하는 장점과 오버헤드를 비교해야 한다. 필요하다면 여러 패턴을 결합하는 하이브리드 접근도 선택지가 된다.

아키텍처 패턴은 시스템 생명주기 전반에 영향을 주는 선택이다. 새로운 변형 패턴이 등장하더라도, 기본 패턴의 성격과 트레이드오프를 이해하는 일은 견고하고 변화에 유연한 시스템을 설계하는 기반이 된다.

Sources

1. GilliLab IT 기술 총서 - 소프트웨어 공학 편
2. 정보관리기술사 합격 핵심 토픽 노트
3. IEEE Standard for Software Architecture Descriptions