오래된 SW 엔지니어의 평생 공부

최근에 Facebook에서 Netflix Architecture[1]라는 포스팅을 본 적이 있다.  이미 댓글에서도 언급했지만, 실재로는 기술 스택(Tehcnology Stack)을 표현한 것이었고 아키텍처 혹은 시스템 아키텍처라고 보기는 어려웠다. 이 두 용어는  자주 사용되지만, 이 두 용어는 서로 다른 개념을 지칭한다. 아마도 이 둘을 혼동하는 이유는 밀접하게 연관되어 있기 때문일 것이다. 

Technology Stack (기술 스택)

기술 스택은 특정 소프트웨어 프로젝트 또는 애플리케이션을 구축할 때 사용되는 기술들의 집합을 의미한다. 이는 프로그래밍 언어, 프레임워크, 데이터베이스, 서버 환경, API 등을 포함할 수 있다. 기술 스택은 주로 개발에 사용되는 도구와 기술들의 "목록"으로 볼 수 있다. 종종 기성 상용품(Commercial Off The Shelf, COTS)인 경우도 많다.

예를 들어, 웹 애플리케이션을 개발하기 위해 다음과 같은 기술 스택을 사용할 수 있습니다:

• 프론트엔드: React, Angular
• 백엔드: Node.js, Ruby on Rails
• 데이터베이스: PostgreSQL, MongoDB
• 서버 환경: AWS, Azure

System Architecture (시스템 아키텍처)

시스템 아키텍처는 소프트웨어 시스템의 구조적 설계를 말한다. 일반적으로는 구조를 설명하기 위해 시스템의 컴포넌트와 그들이 서로 상호 작용하는 방식을 설명하는 것을 가리킨다. 이러한 설명은 시스템의 요구 사항을 어떻게 만족하는지를 보여 주기 위한 것이 하나의 용처이다. 

예를 들어, 시스템 아키텍처 설계에는 기술 스택 뿐 아니라, 앞에서 이야기 한 것 처럼 시스템의 요구 사항을 어떻게 만족하는지 보여 주기 위한 고려사항이 포함될 수 있다.

- 구성 요소의 배치: 서비스 지향 아키텍처(SOA), 마이크로서비스
- 데이터 흐름: 동기식 API 호출, 비동기식 메시징 시스템
- 보안 구조: 인증 및 권한 부여 방식

결론

기술 스택은 "무엇을" 사용할지에 대한 결정인 반면, 시스템 아키텍처는 "어떻게" 시스템을 구성하여 요구 사항을 만족하는지에 대한 계획이나 설명이다.  개발자와 설계자가 이 두 개념을 혼동하는 것은, 두 분야가 각각 다루는 세부사항과 전반적인 설계가 서로 긴밀히 연결되어 있기 때문일 수 있다. 아키텍처 설명하는데 기술 스택이 사용될 수 있고, 기술 스택이 아키텍처에서 설명하는 것이 부족할 수 있다는 것을 이해한다면 복잡하고 어려운 개발 업무를 효과적으로 진행할 수 있는 기반이 된다.

참고 문서

[1] Netflix Architecture, https://www.facebook.com/tipsbykavindu/photos/netflix-architecture-/536074732617368/?_rdr

[1]의 4장은 패턴 언어 개요를 다루고 있다. 여기서는 기본 메시지 구조 관련한 패턴에 대해 살펴 보자

1. 아토믹 파라미터 (Atomic Parameter)

• 설명: API 메시지에서 사용되는 가장 기본적인 단위로, 단순한 비정형 데이터(예: 숫자, 문자열, 불리언 등)를 표현.
• 주요 특징:
  • 메시지 교환의 기본 전송 단위로 사용.
  • 단일 값으로 명확하게 정의되어 있음.
  • 이름, 타입, 선택성 등을 명시하여 데이터의 의미를 전달.
• 포스의 충돌:
  • 과도한 사용 시 API의 효율성이 떨어질 수 있음.
  • 단일 값만으로 표현할 수 없는 복잡한 구조의 데이터 요구에 대응하기 어려움​

2. 아토믹 파라미터 리스트 (Atomic Parameter List)

• 설명: 여러 개의 아토믹 파라미터가 밀접하게 연관되어 있을 때 이를 하나의 그룹으로 결합해 표현하는 방식.
• 주요 특징:
  • 관련된 데이터 엘리먼트를 논리적 그룹으로 묶음.
  • 클라이언트가 특정한 데이터 필드만 선택적으로 요청할 수 있도록 허용.
  • 리스트는 위치 인덱스 또는 키로 식별되며, 필요 시 반복적으로 사용할 수 있음.
• 포스의 충돌:
  • 과도한 중첩으로 인해 데이터 파싱과 처리의 복잡도가 증가할 수 있음.
  • 특정 플랫폼에서 스칼라 값의 제한으로 인한 구현 문제 발생 가능.

3. 파라미터 트리 (Parameter Tree)

• 설명: 아토믹 파라미터와 리스트만으로 표현할 수 없는 복잡한 데이터를 계층적 구조로 정의.
• 주요 특징:
  • 복잡한 데이터 구조를 계층적으로 표현해 데이터의 포함 관계를 명확히 함.
  • 각 노드는 단일 아토믹 파라미터, 리스트, 또는 또 다른 트리로 구성될 수 있음.
  • 재귀적으로 정의되며, JSON 등에서 객체의 중첩 구조를 표현하는 데 유용.
• 포스의 충돌:
  • 중첩 구조가 지나치게 복잡해지면 대역폭과 성능 저하 우려.
  • 복잡한 구조의 데이터 트리로 인해 API 간 상호운용성이 떨어질 수 있음.

4. 파라미터 포리스트 (Parameter Forest)

• 설명: 여러 개의 파라미터 트리를 그룹화해 최상위 레벨에서 관리하는 패턴.
• 주요 특징:
  • 여러 트리들을 하나의 구조로 결합하여 사용자가 필요한 데이터를 쉽게 참조 가능.
  • 다양한 파라미터 트리를 독립적으로 관리할 수 있도록 함.
  • 요청이나 응답 본문에서 복수의 파라미터 트리를 노출.
• 포스의 충돌:
  • 복잡한 데이터 구조로 인해 직렬화와 역직렬화의 부담이 커질 수 있음.
  • 구조적 복잡성으로 인해 메시지 교환 시 불필요한 데이터 전송이 발생할 위험.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의 4장은 패턴 언어 개요를 다루고 있다. 여기서는 API 방향 및 가시성 관련한 패턴에 대해 살펴 보자

1. 프론트엔드 통합 (Frontend Integration)

• 설명: 모바일 앱이나 웹 애플리케이션의 사용자 인터페이스를 백엔드 서비스와 연결하여 데이터를 교환하고 기능을 수행할 수 있게 해주는 패턴.
• 주요 특징:
  • 주로 HTTP/REST API로 구현되며 클라이언트에서 백엔드로 요청을 전달.
  • 데이터 소스 및 프로세싱 로직을 프론트엔드에 제공.
  • 클라이언트가 백엔드 활동을 호출하거나 데이터를 업로드할 수 있도록 함.
• 포스의 충돌:
  • 데이터의 적시성과 효율성을 유지하면서 요청의 페이로드 크기를 최적화해야 함.
  • 과도한 통신으로 인한 성능 저하와 클라이언트 오버페칭을 방지해야 함.

2. 백엔드 통합 (Backend Integration)

• 설명: 시스템의 서로 다른 백엔드 컴포넌트 간에 데이터를 교환하고 상호작용을 트리거할 수 있게 하는 패턴.
• 주요 특징:
  • 분산된 애플리케이션의 백엔드에서 데이터를 교환하고 활동을 트리거할 수 있도록 지원.
  • 비동기 메시징, HTTP, gRPC 등 다양한 기술로 구현 가능.
  • 클라이언트가 아닌 다른 백엔드 시스템에서 독점적으로 사용됨.
• 포스의 충돌:
  • 시스템 간 상호 운용성을 유지하면서 독립적 개발이 가능하도록 해야 함.
  • 데이터 교환과 처리 속도를 균형 있게 조정해야 함.

3. 퍼블릭 API (Public API)

• 설명: 공개적으로 제공되는 API로, 전 세계 누구나 접근할 수 있는 형태로 배포됨.
• 주요 특징:
  • 공용 인터넷에 노출되며 사용자 인증 및 액세스 제어가 필요할 수 있음.
  • API 키 또는 인증 토큰을 통해 보안 유지.
  • 서비스 레벨 계약(SLA)과 요금제 등을 통해 경제적 모델을 구축.
• 포스의 충돌:
  • 높은 보안성과 안정성을 제공하면서 사용자 접근성을 보장해야 함.
  • 공정한 요금제 설정과 과도한 API 사용 방지를 위한 제한 필요.

4. 커뮤니티 API (Community API)

• 설명: 여러 조직이 공동으로 사용하는 API로, 특정 사용자 그룹에게만 제한된 접근을 허용하는 형태.
• 주요 특징:
  • 제한된 네트워크(예: 엑스트라넷)를 통해 배포.
  • 특정 커뮤니티의 회원만 사용 가능.
  • 보안 및 커뮤니티 지원 관리가 중요.
• 포스의 충돌:
  • 보안성과 사용 편의성을 동시에 만족해야 함.
  • 커뮤니티 회원들 간의 상호작용과 API 사용 정책을 일관되게 관리해야 함.

5. 솔루션 내부 API (Solution Internal API)

• 설명: 동일한 애플리케이션 내에서 사용되는 API로, 내부 컴포넌트 간 통신을 위해 설계됨.
• 주요 특징:
  • 마이크로서비스, 모듈 등 내부 시스템 컴포넌트 간 데이터 전송에 사용.
  • 로컬에서 실행되거나 동일한 데이터 센터 내에서 작동하는 서비스 간 통신을 지원.
  • 외부 노출 없이 내부에서만 사용됨.
• 포스의 충돌:
  • 시스템 내에서 효율적인 통신을 유지하면서 데이터의 일관성을 보장해야 함.
  • 독립적 배포와 함께 복잡한 시스템의 결합성을 줄여야 함.