[PoEAA] 백엔드 개발자의 역할 - 소프트웨어 아키텍처와 엔터프라이즈 애플리케이션의 의미

결국 백엔드 개발자는 소프트웨어 아키텍처를 이해하고, 도메인 로직을 코드로 설계해야 한다.
여기에 있어 소프트웨어 아키텍처의 의미와 엔터프라이즈 애플리케이션의 정의는 백엔드 개발자가 해야하는 일을 명확히 정의하는 아주 중요한 주제라고 할 수 있다.
따라서 이에 대한 정의를 먼저 해두자.

아키텍처

아키텍처는 아주 많은 사람들이 정의하려고 하지만 의견이 분분한 용어다.
하지만 그 안에서 몇 가지 공통적인 정의가 있다.

• 시스템을 구성 요소로 나누는 최상위 수준의 분해이다.
• 번복하기 어려운 결정이다.
• 아키텍처는 한 가지 방법으로는 설명할 수 없다.
• 하나의 시스템 안에도 여러 아키텍처가 있을 뿐 아니라, 아키텍처적으로 무엇이 중요한지에 대한 관점도 시스템의 수명 기간 중 달라질 수 있다.

랄프 존슨의 견해에서도 아키텍처에 대한 흥미로운 관점을 획득할 수 있다.

• 아키텍처는 프로젝트에 참여하는 전문 개발자의 시스템 설계에 대한 공유된 이해를 반영하는 '주관적 개념'이다.
  • 이 공유된 이해는 시스템의 중요 컴포넌트, 그리고 이 컴포넌트 간의 상호작용 방법에 대한 것이다.
• 또한 아키텍처는 결정에 관한 것이기도 하다.
  • 아키텍처는 '번복하기 어려운 것'이다.
  • 그러므로 개발자들이 '되도록이면 일찍, 그리고 올바르게 내리고 싶어하는 것'이다.
  • 어떤 것이 원래 생각했던 것보다 바꾸기 쉽다면 더 이상 아키텍처가 아니게 된다.

결국 아키텍처의 본질은 그것이 무엇이든 "중요한 것"으로 요약된다.

 
 
PoEAA에서는 이런 중요한 부분에 대한 통찰과 함께, 가급적 일찍 내려야 하는 결정에 대해 언급한다.
가장 간단하고 중요한 방법은 역시 "Layer" 개념이므로, 거대한 엔터프라이즈 애플리케이션을 "계층"으로 분할하는 방법, 그리고 이 계층 간에 "상호작용"하는 방법을 다룬다.
 
물론 어떤 엔터프라이즈 애플리케이션은 이런 계층형보다 '파이프-필터', 'MQ'와 관련된 다른 접근법이 유용할 수도 있다.
하지만 가장 많이 사용되고 좀 더 다양한 상황에 유용하게 활용될 수 있는 '계층형 아키텍처'를 집중적으로 다룬다.

엔터프라이즈 애플리케이션

Enterprise Application 이란 무엇일까?

• 대규모의 복잡한 데이터와 함께, 논리적 추론으로는 설명되지 않는 비즈니스 규칙을 처리해야 하는 애플리케이션
• "Information System", "Data Processing" 등 다양한 이름으로 불렸다.

좀 더 구체적인 예를 들어보자.

• EA는 일반적으로 persistent data를 처리한다.
  • 이러한 '지속적 데이터'는 오랫동안 유지되고, 따라서 마이그레이션에 대한 대비가 되어 있어야 한다.
• EA는 일반적으로 막대한 양의 데이터를 처리한다.
  • 따라서 성능적인 문제를 완화할 수 있어야 한다.
• EA는 일반적으로 여러 사람이 동시에 데이터에 접근한다.
  • 따라서 동시성 문제에 대한 대비가 되어 있어야 한다.
• EA는 이렇게 많은 데이터를 처리하기 위한 사용자 인터페이스 화면의 수도 많다.
• EA는 단독으로 운영되는 경우가 거의 없고, 다른 분산된 엔터프라이즈 애플리케이션과 통합해야 하는 경우가 많다.
• 기업이 통합 기술을 단일화하더라도 비즈니스 프로세스의 차이와 데이터에 대한 개념 불일치로 인한 문제가 발생하며, 이러한 의미와 정의의 불일치를 잘 다룰 수 있어야 한다.
• EA는 서로 다른 '비즈니스 논리'(라 불리우는 비논리 상황)를 최대한 효과적으로 구성해, 이해관계자 간의 상호작용을 도와야 한다.

엔터프라이즈 애플리케이션은 "대규모 시스템"이라는 뜻이 아니다.
다양한 이해관계가 얽혀 있는 정치적이고 비논리적인 문제를 일관되고 논리적으로 풀어내는 애플리케이션이라는 뜻이다.

엔터프라이즈 애플리케이션의 유형

그렇다면 엔터프라이즈 애플리케이션에는 어떠한 유형이 있을까?
이를 이해하기 위해 세가지 예시를 준비했다.

• B2C 온라인 쇼핑몰
• 임대 계약 자동화 시스템
• 소규모 기업을 위한 간단한 비용 추적 시스템

B2C 온라인 쇼핑몰

온라인 쇼핑몰의 경우, 많은 사람들이 사이트에 방문해 상품을 구경하고 장바구니를 이용해 구매한다.

• 이러한 사이트는 극히 많은 사용자를 처리할 수 있어야 하므로 리소스를 아주 효율적으로 사용해야 하며, 하드웨어를 추가해 쉽게 규모를 확장할 수 있어야 한다.
• 이러한 애플리케이션의 도메인 논리는 '주문 포착', 비교적 간단한 '가격 및 배송 계산', '배송 알림' 등과 같이 상당히 단순할 수 있다.
• 또한 누구라도 쉽게 시스템에 접근할 수 있어야 하므로 최대한 다양한 브라우저로 이용할 수 있는 아주 일반적인 웹 프레젠테이션이 필요하다.
• 데이터 원본은 주문을 저장하기 위한 데이터베이스를 포함하며 가용성과 배송 정보를 지원하기 위해 재고 시스템과의 통신 기능도 포함할 수 있다.

임대 계약 자동화 시스템

• 동시 사용자 수가 수백 명 미만으로 작기 때문에, B2C 쇼핑몰보다는 시스템 설계 면에서는 훨씬 단순하다.
• 하지만, 비즈니스 논리 면에서는 훨씬 복잡하다. 임대 업계의 경쟁력을 높이기 위한 이전의 계약과의 차별화가 들어가기 때문에, 월임대 수수료 계산, 조기 반환이나 지불 지연과 같은 상황 처리, 기록된 임대 기록에 대한 데이터 유효성 검사 등의 복잡한 작업을 수행해야 한다.
• 이러한 복잡한 비즈니스 도메인이 까다로운 이유는 규칙이 매우 임의적이기 때문이다.
• 또한 UI도 더 복잡하다.
• 복잡한 사용자 상호작용은 더 복잡한 트랜잭션 동작으로 이어진다.
  • 임대 예약 하나를 진행하는 데 한/두시간 논리적 트랜잭션이 걸릴 수 있다.
  • 자산 가치 평가와 가격 책정을 위해 수백 개의 테이블과 패키지에 대한 연결을 포함하는 복잡한 DB 스키마가 이용될 수도 있다.
  • 또한 DB 내 데드락 발생 혹은 경쟁 상태 발생 가능성이 높아진다.

소규모 기업을 위한 간단한 비용 추적 시스템

• 사용자가 많지 않고 논리가 단순하며, HTML 뷰를 통해 회사 전체에서 쉽게 접근할 수 있다.
• 하지만 빠르게 구축해야 하며, 시스템이 성장하면서 비용 변제 계산, 급여 시스템으로 데이터 공급, 세금 계산, CFO에게 전달할 보고서 제공, 항공 예약 웹 서비스와의 연결 등의 새로운 기능이 필요할 수 있음을 감안해야 한다.
• 다른 위 두 예제 시스템에 적합한 아키텍처를 이 시스템에 적용하려고 하면 개발 속도가 느려진다.
  • 비즈니스 가치가 있는 시스템의 개발이 늦춰지면 비용이 손실되는 것과 같다.
• 당장의 유연성을 고려한 선택이 잘못된 경우, 유연성을 위해 추가한 복잡성이 오히려 향후 발전을 방해하고 배포를 지연시켜 결과적으로 손해를 유발할 수 있다.

---

이러한 세 가지 엔터프라이즈 애플리케이션의 예에는 저마다 어려움이 있다.
결국 아키텍처를 선택한다는 것은 시스템의 특정한 문제를 이해하고 이해를 바탕으로 적절한 설계를 선택한다는 의미이다.
결국 우리는 다양한 엔터프라이즈 애플리케이션의 설계 패턴을 학습하고, 적절한 패턴을 선택하며, 적절하게 요구에 맞춰 수정할 수 있어야 한다.

 

본 내용은 마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴 도서를 참고하여 작성되었습니다.

엔터프라이즈 애플리케이션 아키텍처 패턴 - 예스24