확장 가능한 AI 에이전트 구축: 이벤트 기반 아키텍처로 1만 명까지 사용자 수 확장

AI 애플리케이션을 수백 명에서 수천 명의 사용자로 확장하면 중요한 아키텍처 변곡점이 나타납니다. 빠른 프로토타이핑을 가능하게 하는 동기식 아키텍처가 성장을 가로막는 병목 지점이 되는 것입니다. AWS를 기반으로 문서 분석, 콘텐츠 생성, 데이터 강화 등의 AI 애플리케이션을 구축하는 Startup의 경우, 요청당 워크로드를 처리하는 데 몇 초 또는 몇 분이 걸릴 수 있습니다. 여기에 수백 명의 동시 사용자가 곱해지면 동기식 아키텍처는 연결 풀을 고갈시키고 제한 시간 임계값을 초과하며 배포 속도를 떨어뜨리는 요인이 됩니다.

이 문서에서는 AWS의 이벤트 기반 아키텍처를 사용하여 사용자 100명 규모에서 1만 명 규모로 AI 문서 처리를 확장하는 방법을 간략하게 설명합니다.이러한 패턴은 다단계 처리가 요구되는 모든 AI 워크로드에 적용되지만, 지능형 문서 처리(IDP)가 그중 대표적인 예입니다.

모노리스가 적합한 경우(및 그렇지 않은 경우)

사용자 수가 수백 명인 환경에서는 모놀리식 문서 처리 파이프라인이 적합한 경우가 많습니다. 단일 컴퓨팅 인스턴스가 API를 통해 문서 업로드를 수신하고, Amazon Textract(스캔한 문서에서 텍스트, 필기 및 데이터를 자동으로 추출하는 기계 학습 서비스)를 직접 호출하여 정형 데이터를 추출하고, 비즈니스 규칙과 비교하여 결과를 검증하고, 추가 컨텍스트로 데이터를 보강하고, 최종 출력을 데이터베이스에 씁니다. 전체 워크플로가 단일 요청-응답 주기 내에서 동기적으로 실행됩니다. 초기 시작 단계의 경우 이 아키텍처는 개념적으로 간단하고 디버그하기 쉬우며 운영 오버헤드가 최소화된다는 유의미한 이점이 있습니다.

하지만 이 아키텍처는 규모가 커질수록 약점이 되는 가정들을 내포하고 있습니다. 즉, 동기식 처리에서는 각 단계가 HTTP 연결을 열린 상태로 유지할 수 있을 만큼 빠르게 완료된다고 가정합니다. 문문서 업로드가 급증하더라도 CPU 집약적일 수 있는 검증 단계가 과부하되지 않는다고 가정합니다. 아울러, 보강 단계에서 오류가 발생하더라도 전체 문서를 처음부터 다시 처리할 필요는 없다고 가정합니다. 이러한 가정은 사용자 수가 수백 명인 환경에서는 대체로 성립하지만, 규모가 커지면 어긋나기 시작합니다.

임계점

사용자가 1,000명이 되면 첫 번째 문제가 나타납니다. 추출 작업이 가장 많은 시간대에는 문서당 2~3초가 걸려, 백로그가 생성되기 시작합니다. 동일한 프로세스에서 실행되는 검증 단계는 독립적으로 확장할 수 없습니다. 추출 속도가 느리면 검증 작업이 대기하게 됩니다. 검증이 느리면 보강 작업이 대기하게 됩니다. 전체 파이프라인은 가장 느린 구성 요소의 속도만큼 느려집니다. 연결 시간 초과 사례가 늘어납니다. 사용자는 ‘처리 중’ 스피너가 해결되지 않는 상태를 보게 됩니다. 엔지니어링 팀이 더 많은 인스턴스를 추가하지만 이렇게 하면 아키텍처 병목 현상이 해결되기는커녕 문제가 좀 더 늦게 나타날 뿐입니다.

사용자가 5,000명이 되면 모놀리스를 유지할 수 없습니다. 보강 단계에서 단 한 번만 실패가 발생해도 역방향으로 영향을 미쳐 검증과 추출을 저해합니다. 팀은 전체 파이프라인을 다시 시작하지 않고는 검증 로직에 업데이트를 배포할 수 없습니다. 검증과 별개로 추출을 확장하는 것은 불가능합니다. 동일한 코드베이스에 결합되어 동일한 프로세스에서 실행되기 때문입니다. 사용자 수가 1만 명이 되면 다른 접근 방식이 필요하게 됩니다.

이벤트 기반 아키텍처로 이동

이벤트 기반 아키텍처는 동기 호출을 비동기 이벤트로 대체하여 이러한 제약을 해결합니다. 한 구성 요소가 다음 구성 요소를 직접 호출하는 대신, 각 구성 요소는 작업이 완료되면 이벤트를 게시하고 시작 시점을 알리는 이벤트를 구독합니다. 문서 업로드 API는 문서가 도착하면 이벤트를 게시합니다. 문서 업로드 API는 문서가 도착하면 이벤트를 게시합니다. 추출부터 검증, 보강에 이르기까지, 각 후속 구성 요소는 이전 이벤트를 구독하고 작업을 수행하고 다음 이벤트를 게시합니다.

이 패턴에서는 생산자와 소비자 사이에 위치하는 Amazon EventBridge(이벤트를 사용하여 애플리케이션을 연결하는 서버리스 서비스) 같은 이벤트 버스라는 간접 계층을 적용합니다. 생산자와 소비자는 서로에 대해 직접 알지 못합니다. 이러한 디커플링은 독립적인 확장, 장애 격리 및 배포 속도를 가능하게 하는 아키텍처상의 변화입니다.

AI 워크로드에 있어서 이 문제가 중요한 이유

특히 AI 워크로드에는 이 패턴의 이점이 큽니다. 데이터를 추출하는 데 간단한 인보이스의 경우 2초, 복잡한 계약의 경우 30초가 걸릴 수 있습니다. 대규모 언어 모델을 사용한 Amazon Bedrock 보강은 분류에 1초, 엔터티 추출에 10초가 걸릴 수 있습니다. 동기식 아키텍처에서는 이러한 가변적인 처리 시간으로 인해 예측할 수 없는 지연 시간이 발생합니다. 이벤트 기반 아키텍처에서는 각 단계가 고유한 속도로 처리되며 완료되면 이벤트를 게시합니다. 파이프라인의 처리량은 가장 느린 구성 요소의 제약을 받지 않고 각 단계의 독립적인 확장 동작에 의해 결정됩니다. 대규모 AI 워크로드의 경우 이는 최대 용량만큼 프로비저닝하는 대신 사용한 만큼만 비용을 지불하면 된다는 의미이기도 합니다.

전환 시기 

Startup이 특정한 변곡점에 도달하면 이 패턴을 필수적으로 적용해야 합니다. 동기식 병목 지점(고객 손실, 문제 해결에 소요되는 엔지니어링 시간, 업데이트를 안전하게 배포하지 못함)으로 인한 비용이 비동기식 복잡성 관리 비용을 초과하는 때가 그 변곡점입니다. 다음과 같은 징후가 보이기 시작하면 이 시점에 도달한 것입니다.

• 사용량이 많은 시간대에 로그에 연결 시간 초과 오류가 나타나는 경우
• 단일 배포에서 여러 팀 간의 변경 사항을 조정해야 하는 경우
• 개별 처리 단계를 독립적으로 확장할 수는 없는 경우
• 처리에 실패하면 전체 문서를 처음부터 다시 처리해야 하는 경우
• 오류율은 트래픽에 비례하여 증가하는 경우

사용자 수가 500명 미만인 초기 Startup의 경우 이벤트 기반 아키텍처는 운영 오버헤드가 이점보다 크기 때문에 시기상조인 경우가 많습니다. 사용자 수가 1,000명에서 1만 명 사이인 Startup의 경우 전환이 필요합니다.

실제 이벤트 기반 문서 처리 

이 패턴이 IDP에 어떻게 적용되는지 생각해 보십시오. 법률 기술을 지원하는 계약 분석 플랫폼을 구축하는 핀테크 Startup은 NDA, 고용 계약, 공급업체 계약 등 매일 수백 건의 계약을 받습니다. 각 문서는 업로드, 추출, 검증, 보강, 저장이라는 다단계 워크플로를 따릅니다. 이벤트 기반 아키텍처에서 각 단계는 이벤트에 의해 트리거되는 독립적인 구성 요소입니다.

이 워크플로는 사용자가 Amazon Simple Storage Service(S3) 버킷에 계약을 업로드할 때 시작됩니다. S3는 이벤트(객체 생성됨)를 EventBridge 기본 버스에 게시합니다. 이 이벤트를 구독하는 구성 요소는 문서를 검색하고 Textract를 직접 호출하여 텍스트, 테이블, 키-값 페어를 추출합니다. Textract는 문서를 비동기식으로 처리하고(처리하는 데 20-30초가 걸릴 수 있는 큰 PDF의 경우 매우 중요), 추출이 완료되면 구성 요소가 추출된 데이터를 포함하는 extraction.complete 이벤트를 게시합니다.

extraction.complete를 구독하는 두 번째 구성 요소는 추출된 데이터를 비즈니스 규칙과 비교하여 검증합니다. 계약서에 필수 조항이 포함되어 있는지, 날짜 형식이 올바른지, 상대방 이름이 명시되어 있는지 등을 검증하여 통과하면, 이 구성 요소는 validation.pass 이벤트를 게시합니다. 검증에 실패하면 validation.failed 이벤트를 게시하고 문서를 수동 검토 대기열(루프 워크플로우에서 사람이 사용하는 Amazon SQS 대기열)로 라우팅합니다.

validation.passed를 구독하는 세 번째 구성 요소는 Bedrock을 사용하여 계약 데이터를 보강합니다. 계약 유형(NDA, 고용, 공급업체)을 분류하거나, 엔터티(회사 이름, 날짜, 금액)를 추출하거나, Anthropic의 Claude와 같은 대규모 언어 모델을 사용하여 주요 용어를 요약할 수 있습니다. Bedrock의 서버리스 추론을 사용하므로, 구성 요소가 GPU 인프라를 관리할 필요가 없습니다. Bedrock API를 호출하고 정형 데이터 출력을 수신하기만 하면 됩니다. 보강이 완료되면 이 구성 요소는 enrichment.finished 이벤트를 게시하고Amazon DynamoDB(규모에 관계없이 밀리초의 지연 시간을 보장하는 서버리스 NoSQL 데이터베이스)에 최종 정형 데이터를 씁니다.

파이프라인에서 계약, 의료 기록 또는 재무제표 중 무엇을 처리하든, 이벤트 기반 패턴은 동일하게 유지됩니다. 각 단계의 AI 서비스만 변경됩니다. 의료 기록 파이프라인에서는 엔터티 추출에 Bedrock 대신 Amazon Comprehend Medical을 사용할 수 있습니다. 재무제표 파이프라인에서는 Textract의 전문화된 AnalyzeExpense API를 사용할 수 있습니다. 여기서 아키텍처 구축의 원칙은 각 단계가 이벤트를 게시하고 독립적으로 확장되며 다른 단계에 영향을 주지 않고 배포할 수 있다는 것입니다.

AWS는 이러한 파이프라인을 구축하는 개발자를 위해 AI 코딩 어시스턴트와 통합되는 Model Context Protocol(MCP) 서버를 출시했습니다. AWS Serverless MCP 서버는 개발자가 코딩 환경 내에서 직접 서버리스 애플리케이션을 구축하는 방법을 간소화할 수 있는 전문화된 기능을 제공하여 문서 검색에 소요되는 시간을 줄여줍니다.

디커플링의 비즈니스 사례

이 아키텍처의 비즈니스 효과는 단순히 기술적 우수성에 그치지 않습니다. 이벤트 기반 아키텍처는 비용을 고정 비용에서 가변 비용으로 바꿉니다. 컴퓨팅 인스턴스에서 실행되는 모놀리식 아키텍처에서는 문서 볼륨에 관계없이 Startup이 24/7으로 용량에 대해서만 비용을 지불합니다. AWS Lambda를 사용하는 이벤트 기반 아키텍처에서는 Startup이 실행 횟수, 기간, 할당된 메모리를 기준으로 실제 컴퓨팅 사용량에 대해서만 비용을 지불합니다. 트래픽이 가변적인 워크로드의 경우, 오전 2시에 문서 50건, 오후 2시에 문서 500건을 처리하면 인프라 비용을 크게 줄일 수 있습니다.

장애 격리를 통해 복원력이 향상됩니다. 모놀리식 파이프라인에서는 검증 로직의 버그로 인해 전체 프로세스가 중단되어 추출 및 보강이 차단될 수 있습니다. 하지만 이벤트 기반 파이프라인에서는 검증 실패가 검증 단계에만 영향을 미칩니다. 추출 작업에서 새 문서가 계속 처리되고, 보강 작업에서는 검증된 문서가 계속 처리됩니다. 실패한 이벤트는 나중에 분석할 수 있도록 Dead Letter Queue(DLQ)로 라우팅할 수 있으며, 팀은 전체 파이프라인을 다시 시작하지 않고도 검증 구성 요소에 수정 사항을 배포할 수 있습니다.

각 구성 요소를 독립적으로 배포할 수 있으므로 배포 속도가 빨라집니다. 팀은 추출 또는 검증 코드를 건드리지 않고도 Bedrock 보강 로직을 업데이트할 수 있습니다. Claude Sonnet에서 Claude Opus로 전환하여 정확도를 높일 수도 있습니다. 이렇게 하면 배포 리스크가 감소하고 팀이 더 빠르게 반복할 수 있게 됩니다. 시장 진출을 앞당기는 것이 곧 경쟁력과 직결되는 Startup에게 이는 매우 중요합니다.

시작하기 

모놀리식 아키텍처에서 이벤트 기반 아키텍처로 전환할 때 전체 애플리케이션을 다시 작성할 필요가 없습니다. 문서 추출과 같은 단일 비동기 워크플로를 파이프라인의 나머지 부분과 분리하는 것부터 시작합니다. 문서가 업로드될 때 EventBridge에 이벤트를 게시하도록 S3를 구성합니다. S3 이벤트를 구독하고 Textract를 호출하는 Lambda 함수를 생성합니다. 그런 다음 작업이 완료되면 Lambda 함수가 extraction.complete 이벤트를 게시합니다. 나머지 파이프라인은 동기식으로 유지합니다. 그런 다음 처리 지연 시간과 배포 속도에 미치는 영향을 측정합니다. 추적할 주요 지표는 P99 지연 시간, 오류율, 문서당 비용, 배포 빈도 등입니다. 가중되는 운영 복잡성보다 이점이 크다면, 검증 및 보강 단계로 확대하여 이 패턴을 적용합니다.

AWS는 IDP용 참조 아키텍처와 AWS Well-Architected Serverless Applications Lens의 모범 사례를 비롯하여, 이벤트 기반 아키텍처를 구축하기 위한 포괄적인 지침을 제공합니다. AWS를 기반으로 AI를 구축하는 Startup의 경우, 이 패턴은 단순한 이론이 아니라 수백 명에서 수백만 명의 사용자로 규모를 확장하는 기업이 사용하는 검증된 접근 방식입니다.

AWS를 기반으로 이벤트 기반 AI 애플리케이션을 구축할 준비가 되셨나요? AWS Activate는 Lambda, EventBridge, Bedrock 및 이 문서에서 다루는 기타 서비스의 비용을 충당할 수 있는 크레딧을 제공합니다. 또한 AWS Activate 커뮤니티에 참여하는 창업자들은 전문가 리소스, 기술 지원, 비즈니스 멘토십, 글로벌 Startup 커뮤니티와의 직접적인 관계를 활용할 수 있습니다. 지금 가입하여 AWS에서 프로덕션급 AI를 구축해 보세요.