Monic 프레임워크: Cognica가 API 아키텍처를 재편하는 방법

1. API가 복잡해지는 이유

API(Application Programming Interface)는 현대 소프트웨어의 핵심이지만 전통적인 API 설계 방식, 특히 REST API는 시스템 규모가 커질수록 확장성과 유지보수라는 어려움에 부딪힙니다. Cognica의 Monic 프레임워크는 이 문제를 아키텍처 수준에서 재설계하기 위해 개발되었습니다.

1.1 리소스 중심 아키텍처(REST)의 구조적 문제

REST 기반 설계에서는 새로운 기능이 추가될 때마다 새로운 엔드포인트가 필요합니다. 이로 인해 다음과 같은 구조적 문제가 발생합니다:

• 엔드포인트 급증과 관리 부담: 기능이 늘어날수록 엔드포인트 수가 기하급수적으로 증가하며, 이는 관리 복잡성과 모니터링 비용을 유발합니다.
• 문서화 및 유지보수의 비효율: 새 엔드포인트마다 별도의 문서화가 필요하고, 코드와 문서 불일치가 자주 발생합니다.
• 버전 관리의 어려움: 리소스 스키마 변경 시 /v1, /v2와 같은 버전 관리가 필수화되며, 운영비용이 증가합니다.
• 데이터 오버페칭/언더페칭 문제: 클라이언트는 종종 불필요한 데이터를 받거나, 여러 번 호출해야 필요한 데이터를 완성할 수 있습니다.

결과적으로 REST는 서비스가 복잡해질수록 엔드포인트의 폭발적 증가와 유지보수의 악순환에 빠지게 됩니다.

2. 대안의 등장

REST의 한계를 보완하기 위해 GraphQL, gRPC 같은 프레임워크가 등장했지만, 이들 역시 완벽하지 않습니다.

2.1 유연하지만 계산에는 약한 GraphQL

GraphQL은 클라이언트가 원하는 데이터 구조를 직접 정의할 수 있어 REST의 오버페칭 문제를 해결했습니다. 그러나 GraphQL은 주로 Query에 초점을 두고 있어, 클라이언트가 복잡한 계산 로직을 선언적으로 표현하기 어렵습니다. 결국 서버는 별도의 서비스 계층을 통해 계산 로직을 따로 구현해야 합니다.

2.2 고성능이지만 경직된 gRPC

gRPC는 Protocol Buffers와 HTTP/2를 기반으로 고성능 서버 간 통신을 제공합니다. 하지만 이는 사전에 정의된 서비스 계약에 강하게 종속되며, 프론트엔드나 분석 애플리케이션에서 필요한 동적인 요구사항 변경에 빠르게 대응하기 어렵습니다.

즉, GraphQL과 gRPC는 각각 데이터 유연성과 성능 측면에서는 발전했지만, 여전히 클라이언트가 서버의 구조에 종속되는 문제를 완전히 해소하지 못했습니다.

3. Monic의 관점: '클라이언트 의도'와 '서버 인프라'의 분리

Monic 프레임워크의 핵심 목표는 "클라이언트의 의도를 표현 가능한 계산식으로 전달하고, 서버는 이를 효율적으로 실행하는 구조"를 만드는 것입니다.

기존 마이크로서비스 아키텍처에서는 클라이언트가 단일 결과를 얻기 위해 여러 엔드포인트를 조합해야 했습니다.
이로 인해 개발자는 서비스 오케스트레이션과 버전 관리에 과도한 리소스를 소모합니다.

Monic은 이러한 구조를 완전히 바꿉니다. 하나의 /compute 엔드포인트와 통합된 쿼리 언어를 통해, 클라이언트는 더 이상 여러 리소스를 호출하지 않고 하나의 계산식만 전달하면 됩니다. 즉, 시스템은 "리소스를 조립하는 방식(REST)"에서 "계산식을 실행하는 방식(Monic)"으로 패러다임이 전환됩니다.

이 방식은 서버리스 환경에서도 강력한 장점을 가집니다. 여러 개의 함수형 API를 구성해야 하는 기존 모델과 달리, Monic의 단일 함수(Mono Lambda) 스타일은 구성 오버헤드를 줄이고 코드 공유를 쉽게 하며, Python 표현식 기반의 격리를 통해 보안과 확장성을 동시에 확보합니다.

4. 데이터베이스와의 연계

Cognica는 AI시대에 필요한 데이터베이스를 개발하고 있습니다. Cognica의 데이터베이스는 키-값(Key-Value), 문서(Document), 시계열(Time-Series), 벡터(Vector) 모델을 하나의 통합 엔진에서 지원하며, 별도의 검색엔진이나 외부 데이터레이어 없이도 작동하는 구조를 지향합니다. 즉, 데이터의 저장·검색·집계·벡터화가 모두 단일 시스템 내에서 일어납니다.

이런 구조에서는 API와 데이터베이스의 경계가 자연스럽게 흐려집니다. 데이터를 "전달"하는 대신, 데이터베이스가 직접 "계산"을 수행하고, API는 단순히 그 계산식을 전달하는 역할을 맡게 되는 구조입니다.

따라서 Monic 프레임워크는 단순한 API 개선이 아니라, 데이터베이스 아키텍처에서 출발한 프레임워크의 확장판입니다. Cognica가 추구하는 "Simple but powerful database system"이라는 비전은 Monic에서도 그대로 이어집니다. 복잡한 분산 API 대신, 단 하나의 /compute 엔드포인트로 모든 연산을 수행하게 하는 것입니다.

결국 Monic은 데이터베이스와 API를 하나의 계산 시스템으로 통합하는 접근방식이며, 이는 Cognica의 "기술스택 단순화" 철학의 핵심이라 할 수 있습니다.

5. API를 '데이터 계산 언어'로 재정의하다

Monic 프레임워크의 출발점은 단순한 기술적 최적화가 아닙니다.
Cognica는 API를 "데이터를 전송하는 통로"가 아닌, "비즈니스 로직을 표현하고 실행하는 언어(Computational Interface)"로 재정의하고 있습니다. REST가 리소스를 "전송(Representation)"하고, GraphQL이 데이터를 "질의(Query)"했다면, Monic은 그 위에 "비즈니스 로직을 표현(Expression)"하는 계층을 더합니다.

Cognica의 방식은 다음과 같은 변화를 이끌어냅니다:

• 엔드포인트 중심에서 표현식 중심으로 — /compute 단일 엔드포인트가 모든 요청을 통합
• 데이터 전달 중심에서 계산 결과 중심으로 — API가 단순한 통신 인터페이스가 아닌 계산 인터페이스로 진화
• UI 종속 구조에서 인프라 독립 구조로 — 프론트엔드 변경에 흔들리지 않는 안정적인 API 생태계 구현

API는 이제 더 이상 명세서가 아니라, 데이터와 계산을 연결하는 언어가 됩니다.

6. 마무리

Monic 프레임워크는 데이터베이스와 애플리케이션 간의 관계 자체를 재설계하려는 시도입니다. Cognica가 구축해온 데이터 저장·검색·벡터 처리 기술은 이제 API 레벨에서 그대로 확장되어, 개발자가 단 하나의 계산식으로 모든 연산을 표현할 수 있는 새로운 형태의 인터페이스로 진화하고 있습니다.

다음 글에서는 실제로 Cognica가 Monic을 통해 Python 표현식, Polars 엔진, 그리고 /compute 단일 엔드포인트를 활용하여 API기술을 어떻게 구현하고 있는지 살펴보겠습니다.