에이전틱 AI 프로젝트에 대한 모든 아키텍처 검토는 결국 동일한 질문으로 귀결됩니다. '현재 갖고 있는 보유한 스택이 우리가 구축하려는 것을 지원할 수 있는가?' 벡터 데이터베이스를 벤치마킹하여 답을 찾고 싶은 마음이 들 정도입니다. 더 중요한 질문은, 해당 아키텍처가 동일한 보장으로 동일한 쿼리에서 데이터와 의미에 관한 질문에 답할 수 있는지 여부입니다.

이것이 바로 에이전트에게 실제로 필요한 것입니다. 이는 대부분의 팀이 시스템의 나머지 부분이 이미 형태를 갖춘 후에 마지막으로 결정하는 스택 부분입니다. 운영 데이터베이스는 기정 사실로 간주됩니다. 하버드 비즈니스 리뷰 분석 서비스에 따르면, 전체 조직 중 15%만이 데이터 기반이 에이전틱 AI를 지원할 준비가 되어 있다고 생각합니다. 그 결과는 화이트보드에서는 그럴듯해 보이지만 프로덕션에서는 무너지기 시작하는 분리 아키텍처가 탄생합니다.

두 패턴은 솔직히 비교할 가치가 있습니다:

• 통합 아키텍처: 단일 플랫폼에서 운영 데이터와 벡터 검색을 함께 처리합니다.
• 분할 아키텍처: 전용 벡터 저장소(Pinecone, Weaviate, 또는 Elasticsearch와 같은 검색 엔진)가 운영 데이터베이스와 함께 위치하며, ETL 파이프라인이 두 데이터베이스를 동기화합니다.

Postgres 마이그레이션 바이러스 주기 분석

개발자 에코시스템에서는 몇 달에 한번 씩 'Postgres로 다시 돌아간 이유'라는 블로그 게시물이 인기를 끕니다. 이 글이 회자되는 즉시 예측 가능한 동일한 논점으로 댓글 창이 가득 채워집니다. 바로 MongoDB는 확장되지 않고, 조인이 없으며, 트랜잭션이 약하다는 것입니다. The Decipherist는 필명으로 활동하며 10년간 MongoDB를 실행해 온 Tim Carter Clausen은 실제 운영 데이터를 바탕으로 각 비판에 대해 직접적으로 답변합니다.

스택의 나머지 부분과 일치하는 데이터 모델을 갖춘 데이터베이스를 선택하면 아키텍처 문제로 인해 엔지니어링 속도가 방해받지 않도록 할 수 있습니다.

심층 분석: SQL 번역 비용

일반적인 SQL 요청은 한 번의 왕복 과정에서 8번의 형식 변경을 수행합니다.

1. 클라이언트가 JSON을 전송합니다.
2. API가 이를 JavaScript 로 구문 분석합니다.
3. ORM 도구는 해당 객체를 정규화된 테이블에 흩어져 있는 행으로 분해합니다.
4. 데이터베이스는 작업을 수행합니다.
5. 행들이 다시 조립됩니다.
6. 객체에 다시 매핑됩니다.
7. 객체는 JSON으로 다시 직렬화됩니다.
8. 응답이 전송됩니다.

MongoDB에서는 이를 네 가지 변환으로 수행하는데, Clausen은 데이터의 형태가 실제로 변경되지 않기 때문에 이를 네 가지라고 부르는 것은 과장이라고 주장합니다. SQL 경로의 형식이 변경될 때마다 CPU와 메모리를 사용하고, 지연 시간이 발생하며, 버그가 숨을 수 있는 여지가 생깁니다.

스키마 업데이트의 실제

MongoDB에서는 필드 이름 변경, 중첩 객체 추가 또는 문서 구조 조정이 다운타임 없이 모두 실시간으로 이루어집니다. 대규모 관계형 테이블에 대한 동일한 작업으로 몇 분 또는 몇 시간 동안 쓰기 잠금 상태가 될 수 있습니다. 매주 배포하는 팀에 있어, 이 차이는 이론적인 것이 아닙니다. 오늘 오후에 필드를 추가하는 것과 다음 분기의 유지 관리일정을 예약하는 것의 차이입니다.

인덱싱 계층의 잠재적 비용

인덱싱 계층에서도 동일한 아키텍처 차이가 나타납니다. 운영 체제를 운영하는 사람이라면 누구나 익숙한 쿼리를 생각해 보겠습니다. 특정 국가에서 특정 제품에 대한 최근 10건의 주문을 반환하는 쿼리입니다.

• document model: 배열 내부에 중첩된 필드를 포함하여 단일 복합 인덱스가 이러한 역할을 직접 제공합니다.
• 관계형 시스템(JSONB): 이와 동등한 작업을 수행하려면 일반적으로 배열 내용에 대한 GIN 인덱스, 스칼라 필드에 대한 별도의 B-트리 인덱스, 쿼리 플래너가 피할 수 없는 강력한 정렬 작업이 필요합니다. 계획은 필요 이상으로 많은 행을 읽으며, 데이터가 증가할수록 확장성이 떨어집니다. 애플리케이션 계층에서는 이러한 문제가 확인되지 않지만, 클라우드 청구서에서는 확연히 드러납니다.

데이터 지역성의 구조적 힘

두 가지 모두 아래에 있는 구조적 인사이트는 데이터 지역성입니다. 문서 모델에서는 논리적 모델과 물리적 모델이 동일합니다. 애플리케이션이 쓰는 형태가 데이터베이스가 저장하는 정확한 형태이고, 데이터베이스가 저장하는 형태가 검색 계층이 AI 에이전트에 반환하는 정확한 형태입니다. 이러한 동등성 덕분에 동기화 파이프라인, 이중 쓰기 로직 및 복잡한 조정 작업이 완전히 제거되어 단편화된 아키텍처에서 동일한 결과를 얻을 수 있습니다.

아키텍트의 의사 결정 프레임워크

Pachot의 의사 결정 프레임워크는 기술적 현실의 방향을 다음과 같이 제시합니다.

• 관계형(Postgres) 선택: 아직 모든 사용 사례가 파악되지 않은 다양한 애플리케이션을 지원하는 중앙화된 데이터베이스의 경우.
• 문서(MongoDB) 선택: 도메인 모델에서 구축되고 애플리케이션이 이를 추론하는 방식 그대로 저장되는 단일 애플리케이션의 경우.

그 다음으로는, 2026년에 다음 중 어느 것을 구축하려고 하는지를 생각해봐야 합니다. 경계 컨텍스트를 가진 마이크로서비스, 주 단위로 반복되는 스키마, 또는 애플리케이션이 자연스럽게 생각하는 방식으로 저장된 도메인 객체 중 무엇을 구축하십니까?

"데이터베이스는 올바르게 사용하면 빠르고 효율적입니다. 가장 중요한 것은 자신이 잘 알고 있거나 배우고 싶은 데이터베이스를 선택하는 것입니다."
— Franck Pachot, AWS Data Hero 및 Oracle Certified Master

강연 영상 보기