컴포저블 아키텍처는 하나의 거대한 올인원 플랫폼 대신, 독립적이고 상호 교환 가능한 최고 수준의 구성 요소들을 API를 통해 서로 소통하게 하여 소프트웨어 시스템을 구축하는 방식입니다. 이는 헤드리스 운동이 기반으로 하는 더 넓은 개념이며, 개방적이고 컴포저블한 엔터프라이즈 기술을 장려하는 벤더 중립적인 산업 단체인 MACH Alliance와 밀접하게 관련되어 있습니다.
간단한 용어 정리부터
"컴포저블(composable)"이라는 단어는 세 가지 매우 다른 분야에서 사용됩니다. 이 가이드의 나머지 부분을 이해하려면 지금 이 용어들을 정리해둘 필요가 있습니다.
- 컴포저블 아키텍처 (본 문서)는 소프트웨어 설계 접근 방식입니다. 애플리케이션을 각각 API를 통해 통합되는 별도의 비즈니스 구성 요소들로 조립합니다.
- 컴포저블 인프라는 하드웨어 및 데이터센터 개념입니다. 컴퓨팅, 스토리지 및 네트워킹 리소스가 통합되어 필요에 따라 워크로드에 할당됩니다. 이는 애플리케이션 코드에 있지 않고 운영 체제 하위 계층에 존재합니다.
- DeFi 컴포저빌리티는 블록체인 개념으로, 종종 "머니 레고"라고 불립니다. 대출 및 스왑 프로토콜과 같은 스마트 계약들이 서로 위에 쌓여 새로운 금융 상품을 생성합니다.
같은 어근을 가진 단어이지만, 서로 관련 없는 세 가지 계층입니다. 앞으로는 "컴포저블"이 소프트웨어 아키텍처의 의미로 사용됩니다.
컴포저블 아키텍처가 실제로 의미하는 것
컴포저블 시스템은 각각 완전한 비즈니스 기능을 소유하는 모듈식의 독립적인 단위로 구축됩니다. 각 작업에 가장 적합한 도구를 선택하고, API를 통해 연결하며, 나중에 전체 시스템을 다시 구축할 필요 없이 그중 하나를 교체할 수 있습니다.
구성의 단위는 이름이 있습니다: 패키지형 비즈니스 기능(packaged business capability), 줄여서 PBC입니다. 가트너는 PBC를 자체 포함된 비즈니스 데이터, 로직, 프로세스를 포함하며 API 및 이벤트 채널을 통해 다른 애플리케이션과 상호 작용하는 독립적으로 배포 가능한 기능으로 정의합니다.
PBC를 박스에 담긴 전체 비즈니스 도메인이라고 생각해보세요. "결제" PBC는 결제 수단, 사기 감지, 환불 및 분쟁을 소유합니다. "검색" PBC는 인덱싱, 순위 지정 및 쿼리 처리를 소유합니다. 각 PBC는 원시 데이터베이스 테이블이 아닌 비즈니스 수준의 API를 노출하며, 벤더로부터 조달하거나 직접 구축할 수 있습니다. 키트의 부품을 조립하는 방식처럼 이러한 블록들로 제품을 구성하는 것입니다.
컴포저블 vs 모놀리식
모놀리식은 모든 기능을 공유 데이터베이스를 사용하는 하나의 배포 가능한 애플리케이션으로 묶습니다. 이는 시작하기는 간단하지만 성장할수록 변경하기가 어려워집니다. 컴포저블 아키텍처는 이러한 기능들을 분리하여 각 기능이 독립적으로 발전할 수 있도록 합니다. 모놀리식 대 마이크로서비스 분할에 대해 읽어보셨다면, 컴포저블은 동일한 변화를 비즈니스 기능 관점에서 설명한 것입니다. 즉, 마이크로서비스는 기술적 분해이며, PBC는 비즈니스 도메인적 분해입니다.
다음은 간략한 대조표입니다.
| 측면 | 모놀리식 | 컴포저블 아키텍처 |
|---|---|---|
| 변경 단위 | 전체 애플리케이션 | 단일 PBC |
| 데이터 | 하나의 공유 데이터베이스 | 각 기능이 자체 데이터를 소유 |
| 벤더 선택 | 하나의 플랫폼, 모두 수용 | 기능별 최고 수준 |
| 프런트엔드 | 백엔드에 결합됨 | 분리되어, 다양한 채널 지원 |
| 통합 | 내부 함수 호출 | API 및 이벤트 |
| 종속 위험 | 높음 | 낮음, 구성 요소 교체 가능 |
트레이드오프는 분명합니다. 컴포저블은 유연성과 교체 가능성을 제공합니다. 또한 통합하고, 모니터링하며, 계약을 유지해야 할 더 많은 움직이는 부품들을 제공합니다.
MACH: 대부분의 사람들이 의미하는 표준
팀들이 "컴포저블"이라고 말할 때, 그들은 대개 MACH 원칙을 따르는 스택을 의미합니다. MACH는 약어이며, MACH Alliance(2020년 설립)는 이를 개방적이고 컴포저블한 시스템을 위한 아키텍처로 홍보합니다.
- M, 마이크로서비스(Microservices). 기능은 하나의 블록이 아닌 작고 독립적으로 배포 가능한 서비스로 구축됩니다.
- A, API-우선(API-first). 모든 기능은 API를 통해 노출됩니다. UI는 해당 API의 여러 소비자 중 하나일 뿐, 유일한 진입점은 아닙니다.
- C, 클라우드 네이티브(Cloud-native). 구성 요소는 탄력적 확장 및 관리형 서비스를 사용하여 클라우드를 위해 구축됩니다.
- H, 헤드리스(Headless). 프런트엔드가 백엔드로부터 분리되어 있어, 동일한 API를 통해 웹, 모바일, 키오스크 또는 다른 어떤 곳으로든 배포할 수 있습니다.
컴포저블, 헤드리스, MACH는 동의어가 아니라는 점에 유의하세요. 헤드리스는 MACH의 한 글자입니다. MACH는 컴포저블 시스템을 구축하는 특정적이고 주관적인 방식입니다. 컴포저블은 이 모든 것을 아우르는 포괄적인 개념입니다.
API-우선 원칙이라는 핵심
이러한 맥락을 파고들면 같은 결론에 도달합니다. 즉, API는 컴포저블 시스템을 하나로 묶는 통합 계층입니다. 구성 요소들이 독립적이고 각자가 자체 데이터를 소유한다면, 그들을 연결하는 유일한 것은 그들 간의 계약(contract)입니다.
그렇기 때문에 API-우선 개발은 협상 불가능한 핵심 원칙입니다. 모놀리식에서는 두 모듈이 동일한 데이터베이스에 직접 접근하여 서로의 함수를 호출할 수 있습니다. 컴포저블 시스템에서는 그러한 지름길이 사라집니다. 기능은 노출하는 API만큼만 유용하며, 시스템은 각 부분 간의 계약만큼만 안정적입니다.
이것은 또한 API가 더 이상 보조적인 역할이 아니라 그 자체가 제품이 되는 순간이기도 합니다. 프런트엔드가 헤드리스이고 기능들이 교체 가능할 때, API가 바로 다른 팀과 파트너가 실제로 소비하는 제품이 됩니다. 이를 부주의하게 설계하면 하위의 모든 소비자가 그 영향을 느낄 것입니다.
장점과 단점
컴포저블의 장점을 요약하자면 다음과 같습니다.
- 최고 수준(Best-of-breed). 한 벤더의 가장 약한 모듈에 만족하는 대신, 각 기능에 가장 강력한 도구를 사용합니다.
- 독립적인 변경. 나머지 부분에 영향을 주지 않고 하나의 PBC를 교체하거나 업그레이드할 수 있습니다.
- 적은 종속성. 교체 가능한 구성 요소는 단일 플랫폼에 얽매이지 않는다는 것을 의미합니다.
- 병렬 팀. 분리된 기능들을 통해 팀들이 각자의 일정에 따라 작업을 배포할 수 있습니다.
- 다채널. 헤드리스 프런트엔드는 하나의 API 세트가 다양한 표면(채널)에 서비스를 제공하도록 합니다.
그리고 솔직한 비용(단점)은 다음과 같습니다.
- 통합 오버헤드. 더 많은 구성 요소는 연결하고 모니터링해야 할 더 많은 연결을 의미합니다.
- 계약 규율. 한 API의 호환성 파괴 변경은 이를 호출하는 모든 것에 영향을 미칠 수 있습니다.
- 운영 복잡성. 모니터링, 인증 및 버전 관리가 하나의 서비스가 아닌 여러 서비스에 걸쳐 이루어집니다.
- 초기 설계. 배포하기 전에 경계와 계약에 더 많은 시간을 할애해야 합니다.
유연성, 확장성 및 여러 채널이 필요할 때 컴포저블은 강력하게 적합합니다. 잘 구축된 단일 모놀리식으로 충분할 때는 과할 수 있습니다.
Apidog의 역할: API-우선 원칙의 핵심
Apidog는 아키텍처를 컴포저블하게 만들지는 않습니다. Apidog는 CMS, 커머스 엔진, API 게이트웨이 또는 MACH 플랫폼이 아니며, 그 어떤 것도 대체하지 않습니다. Apidog는 MACH의 "A" 즉, API-우선 원칙을 담당하며, 이는 컴포저블 시스템의 다른 모든 것이 의존하는 계층입니다.
API가 독립적인 구성 요소들 간의 유일한 인터페이스이기 때문에, 계약은 정확해야 합니다. Apidog는 해당 계약을 설계하고, 테스트하고, 모의(mock)하고, 문서화하는 곳입니다.
- 설계 우선 계약. 구현을 작성하기 전에 각 기능의 API를 OpenAPI 계약으로 정의하여, 소비자와 제공자가 사전에 형태에 동의하도록 합니다.
- 목 서버(Mock servers). 분리된 팀들은 서로를 기다릴 필요가 없습니다. 목 서버는 백엔드 PBC가 아직 구축 중인 동안 프런트엔드 또는 파트너가 계약에 맞춰 개발할 수 있도록 합니다.
- 헤드리스 테스트 실행. Apidog CLI는 GUI 없이 CI에서 바로 API 테스트를 실행합니다. 이는 "헤드리스"와 개념적으로 일치합니다. 즉, 테스트는 화면을 통하지 않고 계약에 따라 실행됩니다.
- 도구에서 관리. MCP를 통해 AI 에이전트 또는 IDE에서 API 프로젝트를 진행할 수 있습니다.
시스템이 API-가-제품 모델을 따른다면, 이것은 계약의 정확성을 유지하는 품질 계층입니다. 백엔드가 존재하기 전에 계약을 설계하고 모의하려면 Apidog를 다운로드하세요.
컴포저블 아키텍처를 채택해야 할 때
다음 중 두 가지 이상에 해당할 때 컴포저블을 고려하세요.
- 공유 로직으로 여러 채널(웹, 모바일, 매장 내, 음성)에 서비스를 제공해야 할 때.
- 다른 기능들이 매우 다른 속도로 변경되며, 작은 수정 때문에 모든 것을 재배포하는 데 지쳤을 때.
- 하나의 통합 솔루션 대신 기능별로 최고 수준의 벤더를 원할 때.
- 벤더 종속성이 실제 비즈니스 위험이 될 때.
- API 계약 및 통합을 장기적으로 관리할 팀과 규율이 있을 때.
촉박한 일정으로 단일 제품을 출시하는 소규모 팀이라면, 깔끔한 모놀리식이 더 현명한 선택인 경우가 많습니다. 컴포저블은 규모가 커질 때 그 복잡성을 정당화합니다.
자주 묻는 질문
컴포저블 아키텍처는 마이크로서비스와 동일한가요?
아니요, 하지만 서로 중첩됩니다. 마이크로서비스는 시스템을 작은 배포 가능한 서비스로 분해하는 기술적인 방법입니다. 컴포저블 아키텍처는 비즈니스 기능(PBC)을 따라 분해하며, API로 연결된 최고 수준의 교체 가능한 구성 요소 개념을 추가합니다. 마이크로서비스는 일반적으로 컴포저블 시스템의 백엔드를 구축하는 방식입니다. 더 넓은 분할에 대해서는 모놀리식 대 마이크로서비스를 참조하세요.
컴포저블과 헤드리스의 차이점은 무엇인가요?
헤드리스는 프런트엔드가 백엔드로부터 분리되어 있어 어떤 클라이언트든 동일한 API를 소비할 수 있음을 의미합니다. 컴포저블은 독립적이고 API로 연결된 기능들로 전체 시스템을 조립하는 더 넓은 접근 방식입니다. 헤드리스는 컴포저블 시스템이 따르는 경향이 있는 한 가지 원칙(MACH의 "H")입니다. 스택 전체가 완전히 컴포저블하지 않더라도 하나의 기능에서 헤드리스일 수 있습니다.
패키지형 비즈니스 기능(PBC)이란 무엇인가요?
PBC는 데이터, 로직, API를 포함하여 완전한 비즈니스 기능을 소유하는 독립적인 단위입니다. 가트너는 PBC를 자체적으로 배포 가능하며 API 및 이벤트 채널을 통해 다른 애플리케이션과 상호 작용하는 기능으로 설명합니다. 비즈니스 수준의 API를 노출하는 "검색", "결제" 또는 "재고" 구성 요소가 일반적인 PBC입니다.
컴포저블로 전환하기 위해 API 플랫폼이 필요한가요?
API 계약을 설계하고, 테스트하고, 안정적으로 유지할 방법이 필요합니다. 왜냐하면 이 계약들이 독립적인 구성 요소들을 하나로 묶는 유일한 것이기 때문입니다. 이는 여러 별도의 도구들의 집합이 될 수도 있고, 설계, 모의(mocking), 테스트 및 문서를 한곳에서 처리하는 단일 플랫폼이 될 수도 있습니다. 핵심은 특정 제품이 아니라 계약 규율입니다.
정리하며
컴포저블 아키텍처는 속(genus)이며, 헤드리스, MACH, 마이크로서비스는 그 안의 종(species)입니다. 핵심은 간단합니다: 독립적인 기능, 최고 수준의 선택, 그리고 연결 조직으로서의 API. 마지막 부분에 대부분의 위험이 존재합니다. 왜냐하면 계약이 곧 시스템이기 때문입니다. Apidog와 같은 도구로 API 설계, 모의(mocking), 테스트 및 문서를 올바르게 처리한다면, 컴포저블이 약속하는 나머지(교체 가능성, 다채널, 종속성 없음)는 견고한 기반을 갖게 될 것입니다.