규모 조정 가능한 AI 에이전트 구축: Startup을 위한 시스템 지향 참조 아키텍처

빌더는 세대마다 추상화 수준의 변화를 겪습니다. 어셈블리 언어는 더 높은 수준의 언어로 대체되었습니다. 모노리스는 분산 시스템으로 발전했습니다. 온프레미스 인프라는 클라우드 네이티브 플랫폼에 자리를 내주었습니다. 그리고 이제 소프트웨어 자체가 모델, 컨텍스트, 에이전트, 적응형 워크플로를 기반으로 하는 AI 네이티브로 바뀌고 있습니다. 

Werner Vogels는 re:Invent 2025에서 이 순간을 다음과 같이 분명하게 표현했습니다. 성공하는 개발자는 시스템에서 사고하고 정밀하게 구축합니다. 성공하는 기업은 AI를 가장 일찍 도입하거나 가장 유능한 모델을 선택한 회사가 아니라, 전체 시스템을 생각하고 모든 아키텍처 결정이 그 위와 아래 계층에 영향을 미친다는 것을 이해하는 사람들입니다. 

현대적 AI 스택은 모델 선택, 검색 연결, 오케스트레이션 추가, 배포 등 체크리스트로 취급되는 경우가 너무 많습니다. 하지만 AI 기반 제품은 개별 구성 요소가 각각 인상적으로 보이더라도 실제로는 실패할 수 있습니다. 반대로, 실제 환경의 로드에서도 속도, 신뢰성, 거버넌스, 비용 간의 균형을 유지하며 시스템이 예측 가능하게 동작할 때 성공합니다. 

Peter DeSantis는 re:Invent 2025에서 인프라 측면에서 이러한 주장을 펼쳤습니다. AWS가 20년 동안 집착해 온 다섯 가지 기본 요소인 보안, 가용성, 탄력성, 민첩성, 비용은 이제 더 중요해졌습니다. AI 워크로드는 모든 아키텍처 약점을 가중시킵니다. 사용자 100명으로 확장되는 시스템은 사용자가 1만 명에 달하면 구조적으로 장애가 발생할 수 있습니다. 프로토타입 단계에서 합리적으로 보이는 비용 모델이 실제 프로덕션 볼륨에 적용할 경우 현실성이 없게 될 수 있습니다. 좋은 의도를 바탕으로 구축된 거버넌스 접근 방식으로는 기업 보안 검토를 통과할 수 없습니다.

이 문서에서는 프로토타입 단계에서 프로덕션 단계로 진행하는 모델 빌더 팀과 AI 네이티브 SaaS 팀을 위한 시스템 지향 참조 아키텍처를 간략하게 설명합니다. 이 아키텍처는 두 팀이 함께 작업할 때 최대한의 가치를 제공하는 5개의 계층으로 이루어져 있습니다.

서비스만이 아니라 시스템 전체를 관점으로 생각하기

생성형 AI 설계에서 흔히 저지르는 실수는 각 계층을 독립적으로 최적화하는 것입니다. 한 팀이 ‘최고의’ 모델을 선택합니다. 다른 한 팀은 ‘최고의’ 벡터 저장소를 선택합니다. 또 다른 팀은 이미 익숙한 오케스트레이션 프레임워크를 선택합니다. 각각의 결정은 그 자체로만 보면 합리적으로 보일 수 있지만, 사용자가 경험하는 것은 검색 속도, 응답 품질, 워크플로 내구성, 정책 적용, 테넌트 격리, 서비스 비용 등 전체 시스템 차원의 동작입니다.

AI 네이티브 소프트웨어에서는 ID와 권한이 어떻게 검색 및 도구 액세스로 유입되는지, 컨텍스트 최신성이 어떻게 출력 품질을 좌우하는지, 오케스트레이션이 어떻게 재시도, 상태 및 장기 실행 단계를 처리하는지, 관찰성이 모델 직접 호출, 워크플로 및 애플리케이션 로직에 어떤 영향을 미치는지, 스토리지, 추론 및 워크플로 실행 전반에서 비용이 어떻게 증가하는지 등 계층 간의 상호 작용 방식에서 그 결과가 나타납니다. 

최고의 AI 스택은 개별적으로 가장 인상적인 부분을 가진 스택이 아닙니다. 피드백 루프가 안정적이고 예측 가능한 시스템 동작을 생성하는 프로세스입니다. 이러한 관점을 바탕으로, Startup에게 유용한 AWS의 현대적 AI 네이티브 참조 아키텍처를 소개합니다.

계층 1: 데이터 및 컨텍스트 기반

모든 AI 제품은 데이터 기반 위에 구축됩니다. 이 계층은 제품이 지속적이고 통제된 컨텍스트에서 AI 동작을 기반으로 작동할 수 있는지 여부를 결정합니다. 프로덕션 시스템에서 컨텍스트는 검색 품질, 모델 동작, 개인화 및 신뢰를 형성합니다. 이 계층이 취약하거나 오래되거나 제대로 관리되지 않으면 불안정성이 상향으로 확산됩니다.

실제 환경에서는 네 가지 장애 모드가 일반적으로 나타납니다.

• 신뢰할 수 있는 소스 데이터는 특정 모델이나 검색 전략보다 오래 지속되어야 합니다. 데이터 아키텍처를 특정 임베딩 모델에 너무 밀접하게 결합하는 팀은 모델이나 액세스 패턴이 변경될 때마다 기반을 재구축하는 경우가 많습니다. 
• 신속하고 상황에 맞는 액세스를 제공하려면 컨텍스트가 체계적으로 구성되어야 합니다. 검색 지연은 제품 품질의 문제로 이어지며, 상위 계층으로 갈수록 복잡해집니다.
• 정확도를 높이기 위해 사용되는 컨텍스트가 오래되거나 과도하게 공유되거나 테넌트 간에 제대로 격리되지 않은 경우, 리스크를 초래할 수 있습니다. 통제된 경계는 규정 준수뿐만 아니라 정확성과 신뢰를 보장하는 데 필수적입니다.
• 수명이 긴 비정형 데이터, 벡터 임베딩 및 작동 상태는 서로 다른 용도로 사용되며, 서로 가까이 있더라도 구조적으로 구분되어야 합니다.

Amazon Simple Storage Service(Amazon S3)는 문서, 기록, 아티팩트 및 로그에 대한 표준 기록 시스템으로 계속 사용됩니다. S3 Vectors는 이러한 기반을 벡터 10억 개 규모의 네이티브 벡터 스토리지로 확장하여, S3의 탄력성, 내구성, 가용성 모델을 보존합니다. 지식 집약적인 제품을 구축하는 ISV의 경우, 프로비저닝, 확장 및 보안을 위한 별도의 벡터 데이터베이스 없이 동일한 액세스 정책에 따라 동일한 버킷에서 규제 콘텐츠, 고객 상호 작용 기록, 검색 기능을 모두 사용할 수 있습니다.

이전에 별도의 벡터 데이터베이스를 관리하던 팀은 인프라의 나머지 부분과 별도로 프로비저닝을 처리하고, 인덱스 상태를 모니터링하고, 이벤트 규모 조정을 계획해야 했습니다. S3 Vectors는 이러한 문제를 완전히 없앱니다. 즉, 이미 문서 저장소를 관리하는 데 사용되는 것과 동일한 액세스 정책을 상속하므로 별도의 확장 전략이나 추가 자격 증명 관리가 필요 없으며 모니터링해야 할 새로운 장애 지점도 없습니다.

전문 벡터 저장소는 여전히 사용됩니다. OpenSearch는 애플리케이션이 정확한 키워드 매칭을 의미론적 연관성과 결합해야 하거나 짧은 지연 시간으로 검색 성능을 최적화해야 하는 경우에 더 적합합니다. 데이터가 순수한 텍스트가 아닌 경우 Amazon Nova Multimodal Embeddings가 중요한 역할을 하게 됩니다. 스캔한 PDF를 정형 레코드와 함께 처리하는 계약 인텔리전스 플랫폼 또는 스크립트가 포함된 비디오를 인덱싱하는 미디어 플랫폼은 단편화된 파이프라인 대신 공유 벡터 스페이스를 활용할 수 있습니다.

주요 서비스: Amazon S3, Amazon S3 Vectors, Amazon OpenSearch Service(GPU 가속), Amazon Nova Multimodal Embeddings, Amazon Bedrock Knowledge Bases. 

시작점: 처음부터 접두사 기반 테넌트 격리를 사용하여 소스 문서를 S3에 저장한 다음, 사용자 지정 검색 로직을 구축하기 전에 해당 버킷에 대해 Bedrock Knowledge Base를 구성합니다.

계층 2: 모델 및 서빙

이 계층은 시스템이 인텔리전스를 생성하는 방법과 이를 수행하는 데 드는 비용을 결정합니다. 가장 성능이 뛰어난 모델을 결정하는 것이 아니라, 각 워크로드 유형에 대해 정확성, 지연 시간, 비용 및 제어의 적절한 균형을 제공하는 모델 전략이 무엇인지에 따라 결정합니다.

도메인별 빌더(리걸테크, 코딩 어시스턴트 또는 금융 문서 분류기)에는 일반 프론티어 모델로는 일관되게 제공하거나 경제성을 유지할 수 없는 독자적인 정확성이 요구됩니다. 현대적 ISV는 대규모 쿼리에서 예측 가능한 지연 시간과 비용을 보장받아야 합니다. 또한 추론 소비자는 요청 라우팅, 요약, 엔터티 추출과 같은 일상적인 작업에 대해 프론티어 모델 수준의 비용을 지불하는 것을 피해야 합니다. 이러한 작업의 경우 더 작은 규모로 튜닝된 모델이 훨씬 낮은 비용으로도 동일한 수준의 성능을 제공하기 때문입니다.

대부분의 팀에게 Amazon Bedrock은 Anthropic의 프론티어 모델과 함께 18개 이상의 개방형 모델로 구성된 관리형 팔레트로, 추론 인프라 실행으로 인한 운영 부담이 없습니다. 그중 Nova 2는 비용 대비 성능이 가장 뛰어난 티어에 속합니다. 제품이 성숙해질수록 중요한 질문은 "어떤 모델이 가장 뛰어난가?"에서 "우리의 경쟁력는 독자적인 모델 동작에서 오는가, 아니면 독자적인 제품 워크플로에서 오는가?"로 바뀌게 됩니다. Bedrock Reinforcement Fine-Tuning(RFT)은 분야별 작업에서 기본 모델보다 더 높은 정확도를 달성할 수 있으며, 따라서 더 작고, 더 빠르며, 비용 효율적인 모델 변형도 프로덕션 볼륨에 사용할 수 있습니다.

더 많은 제어권이 필요한 팀에게는 미세 조정, 평가, MLOps 및 사용자 지정 배포를 심층적으로 수행해야 하는 빌더를 위한 관리형/제어형 티어인 Amazon SageMaker AI가 적합합니다. 또한 독점 모델 동작이 제품 자체에 포함된 경우에도 더 적합합니다. 음성 네이티브 경험을 위한 양방향 스트리밍의 경우와 같이, 완전관리형 서비스가 제공하지 않는 런타임 패턴이 필요한 팀에게도 SageMaker AI는 실용적인 선택이 될 수 있습니다. 오디오를 스트리밍하고 일부 스크립트를 내보내면 응답을 기다리는 지연을 체감하기보다 자연스럽고 유연한 상호 작용을 경험할 수 있습니다.

파운데이션 모델을 새로 구축하는 팀에게 EC2 Trn3(Trainium3)는 네이티브 PyTorch 통합을 통해 훈련 비용을 40% 절감하고 메가와트당 5배 더 높은 출력 토큰을 제공하므로, 팀이 모델 코드를 변경하지 않고도 훈련 및 배포할 수 있습니다. Amazon Elastic Kubernetes Service(EKS)는 완벽한 런타임 제어 또는 특화된 서빙 스택을 필요로 하는 팀을 위한 솔루션으로, 스펙트럼의 최하단에 있습니다.

모델 티어 결정에 따라 시스템의 비용 하한선이 정해집니다. 모든 요청이 프론티어 모델로 기본 설정되면, 검색, 에이전트 및 다단계 워크플로가 추가됨에 따라 비용이 빠르게 상승합니다. 체계적인 모델 전략은 작업 요구 사항에 맞게 기능을 조정하여 모르는 사이에 모델 비용이 제품의 경제성을 해치지 않도록 합니다.

Bedrock의 요금 페이지에서 입력 및 출력 토큰의 현재 모델별 비용을 비교해볼 수 있습니다. 아키텍처를 마무리하기 전에 예상 요청량을 기준으로 이러한 계산을 실행하는 것이 좋습니다.

주요 서비스: Amazon Bedrock(서버리스 추론, 서비스 티어), Amazon Nova 2 패밀리, Bedrock RFT, SageMaker AI, EC2 Trn3(Trainium3).

시작점: 규모에 따라 비용 부담이 빠르게 가중되는 만큼, 어떤 워크로드에 프론티어 모델이 필요하고 어떤 워크로드를 더 작거나 더 저렴한 대안으로 처리할 수 있는지 파악합니다.

계층 3: 추론 및 에이전틱 런타임

추론은 아키텍처 의도가 사용자에게 나타나는 동작으로 바뀌는 단계입니다. 이 계층은 지연 시간, 처리량, 동시성, 세션 상태, 도구 상호 작용 패턴, 수요가 급증하는 상황에서의 품질, 고객 상호 작용당 비용 등을 관리합니다. 문제는 기능이 아니라, 여러 테넌트, 급증하는 수요, 실패할 수 있는 도구 직접 호출, 밀리초가 아닌 몇 분 동안 실행되는 워크플로 등 실제 상황에서의 신뢰성, 격리 및 비용 일관성입니다.

이 계층은 최신 ISV가 기업에 판매할 수 있는지 아니면 얼리 어답터에게만 판매할 수 있는지를 결정합니다. 모델 성능은 뛰어나지만 테넌트 격리, 워크플로 내구성, 감사 가능한 도구 직접 호출 기록이 없는 에이전트 애플리케이션은 기술적으로 잘못되어서가 아니라 시스템 수준에서 신뢰할 수 없기 때문에 조달 검토에 실패합니다.

Bedrock의 기반 추론 엔진인 Mantle 프로젝트는 인프라 수준에서 신뢰성과 격리를 지원합니다. 서비스 티어 라우팅을 통해 계약 인텔리전스 플랫폼은 사용자용 조항 추출 작업은 우선순위가 높은 경로로 보내고, 백그라운드 규제 교차 참조 작업은 유연한 경로로 보내 사용자 경험을 저하시키지 않으면서 비용을 최적화할 수 있습니다. 고객별 대기열 격리는 한 테넌트의 문서 업로드 급증이 다른 테넌트의 활성 검토 세션에 영향을 미치지 않도록 보장합니다. Mantle의 핵심 혁신적인 기능 중 하나인 저널은 추론 상태를 지속적으로 체크포인트하므로, 12분 동안 실행된 실사 워크플로가 실패하더라도 처음부터 다시 시작하는 것이 아니라 12분 지점부터 재개됩니다.

Amazon Bedrock AgentCore는 대부분의 팀에서 구축하는 데 몇 개월이 걸리는 프로덕션 런타임을 제공합니다. 여기에는 모든 프레임워크(LangGraph, CrewAI, Strands Agents, OpenAI Agents SDK)에 대한 컨테이너 기반 에이전트 배포, 세션 간 에피소드 메모리, Cedar 정책 적용을 통한 MCP 기반 도구 접근, 그리고 실제 평가기를 활용한 지속적인 품질 평가 기능이 포함됩니다. 법률 SaaS 팀이 자체 에이전트 인프라를 운영할 경우 일반적으로 여러 명의 엔지니어가 컨테이너화, 세션 관리, 도구 보안 업무를 담당해야 합니다. AgentCore는 이러한 문제를 관리형 계층으로 통합하여, 엔지니어링 역량을 거래 성사에 직접 기여하는 조항 라이브러리, 위험 분류 체계, 고객별 정책 규칙 개발에 집중할 수 있게 합니다.

기업 영업 주기에서 이 계층의 성공과 실패를 가르는 원칙은 메커니즘과 선의의 의도 사이의 구분입니다.

주요 서비스: Amazon Bedrock(Project Mantle: 서비스 티어, 대기열 격리, 저널), AgentCore(런타임, 메모리, 게이트웨이, 평가, ID), Strands Agents, AWS Step Functions, Amazon Simple Queue Service(SQS). 

시작점: 에이전트가 충족해야 하는 기업 요구 사항을 나열하고 각 요구 사항을 프롬프트 전략이 아닌 구체적인 메커니즘에 매핑합니다.

계층 4: 오케스트레이션 및 컴퓨팅

이 계층에서는 AI가 단일 모델 직접 호출에서 벗어나 소프트웨어가 됩니다. 대부분의 프로덕션 AI 제품은 컨텍스트를 검색하고, 모델을 간접적으로 호출하고, 도구를 직접적으로 호출하고, 출력을 검증하고, 다운스트림 작업을 트리거하고, 결과를 유지하고, 비동기식으로 워크플로에 다시 진입하는 다단계 시스템입니다. 오케스트레이션은 구현 세부 사항이 아니라 핵심 애플리케이션 아키텍처의 일부입니다.

계약 분석을 수행하는 금융 서비스 SaaS 플랫폼을 생각해 보세요. 단일 요청에는 문서 수집, 청킹, 임베딩 생성, 이전 계약에 대한 검색, 조항에 대한 다단계 추론, 검토자로의 라우팅, 다운스트림 규정 준수 워크플로 트리거가 포함될 수 있습니다. 이는 단일 추론 직접 호출이 아니라 몇 분 또는 몇 시간에 걸친 분기 로직, 재시도, 상태 전환 및 비동기 단계를 포함하는 내구성 있는 애플리케이션 워크플로입니다.

여기의 구조적 인사이트는 서버리스 컴퓨팅의 혁신을 가능케 한 요소를 반영합니다. 목표는 단순히 인프라를 더 쉽게 관리하는 것이 아니라 인프라 관리 자체의 특정 범주를 완전히 없애는 것입니다. Lambda 관리형 인스턴스는 이러한 원칙을 일반적으로 존재하는 공백 영역에 적용합니다. 일부 워크로드에는 특정 컴퓨팅 특성, 임베딩 생성을 위한 대용량 메모리, 문서 사전 처리 파이프라인 또는 CPU를 많이 소비하는 모델 추론이 필요합니다. 이러한 작업은 단순한 서버리스 함수에는 너무 무겁지만, 그렇다고 직접 서버 플릿을 운영할 정도는 아닙니다. 매일 수천 개의 법률 문서를 처리하는 Startup은 스타트업은 이러한 작업을 특정 인스턴스 프로파일에서 실행하면서도, Lambda가 프로비저닝, 확장, 패치 관리를 담당하도록 하여 EC2 플릿 운영 부담을 떠안지 않으면서도 서버리스 아키텍처를 유지할 수 있습니다.

심층적인 런타임 제어를 필요로 하는 팀을 위해, EKS는 사용자 지정 추론 서버를 실행하는 모델 빌더 또는 Kubernetes에서 표준화하는 플랫폼 팀이 선호하는 일관성과 제어 기능을 제공합니다.

Amazon DynamoDB는 자연스럽게 워크플로 상태, 세션 메타데이터, 테넌트 구성, 멱등성 키, 도구 결과 및 감사 참조를 위한 트랜잭션 컨트롤 플레인으로 적합합니다. 서비스와 워크플로 단계 간에 업무가 이전될 때 애플리케이션의 일관성을 유지하는 것은 운영 백본입니다. 이는 검색에 사용되는 시맨틱 메모리 계층과는 다릅니다.

AI 기반 개발 환경인 Kiro는 소프트웨어 제공 액셀러레이터로서 이 계층에 사용됩니다. 그 역할은 팀이 자연어 요구 사항을 구조화된 설계, 사양 및 구현 작업으로 변환할 수 있도록 지원하여, 시스템 아키텍처의 일관성을 유지하면서 팀이 더 빠르게 업무를 진행할 수 있도록 하는 것입니다.

주요 서비스: Lambda Managed Instances, Lambda Durable Functions, Amazon DynamoDB, Amazon EC2 M9g(Graviton5), AWS Step Functions, Amazon ECS on Graviton5, Amazon EventBridge, Amazon SQS. 

시작점: 오케스트레이션 도구를 선택하기 전에 실패, 분기 또는 비동기적으로 실행될 수 있는 모든 단계를 식별하여 서류상 워크플로를 매핑합니다.

계층 5: 거버넌스, 관찰성, 신뢰

바로 이 계층에서 많은 AI 스택이 여전히 문제를 일으킵니다. 팀은 거버넌스를 나중에 추가할 수 있는 것으로 취급합니다. 광범위한 도구 액세스, 제한된 평가, 모호한 프롬프트 기반 제약 조건을 가진 에이전트는 신뢰를 약화시키고 도입의 장벽으로 작용합니다. 더 나은 원칙은 무엇일까요? 바로 의도가 아니라 메커니즘입니다.

기업 구매자는 AI 시스템을 도입하기 전에 “데이터가 테넌트의 경계를 넘어가지 않는다는 것을 입증할 수 있는가?”와 “귀사의 AI가 주장하는 경계 내에서 동작하며, 그 경계를 강제하는 메커니즘에서 실제 발생한 결과를 보여주는 로그를 통해 이를 증명할 수 있는가?”라는 두 가지 일관된 질문을 던집니다.

의료 ISV의 경우 이는 환자에게 허용된 범위를 벗어난 의료 기록에는 액세스할 수 없는 HIPAA 범위 내 에이전트를 의미합니다. 금융 서비스 SaaS 제공업체의 경우에는 고객별 데이터 액세스 계약에 따라 도구 직접 호출이 제한되는 투자 리서치 어시스턴트를 의미합니다. 이러한 요구사항은 규제 대상 기업 환경에서의 표준적인 배포 요건이며, 예외적인 사례가 아닙니다.

Bedrock Confidential Computing은 실행 중에 데이터를 보호하고 보다 확실한 런타임 경계를 제공하여 추론 플레인의 데이터 격리 문제를 해결합니다. Bedrock, AgentCore, Lambda, S3 등의 서비스는 통합 ID 모델 내에서 작동할 수 있으므로, 각 계층에 대해 별도의 권한 부여 시스템을 구축하지 않고도 데이터, 모델 간접 호출 및 에이전트 도구 사용 전반에 걸쳐 액세스 거버넌스를 일관되게 적용할 수 있습니다. 데이터 액세스를 관리하는 정책이 모델 직접 호출 및 도구 권한에도 적용됩니다. 그러면 도구 직접 호출 로그가 감사 가능한 시스템 동작 기록이 됩니다.

이 계층의 거버넌스에는 테넌트 인식 데이터 제어, 모델 및 프롬프트 버전 관리, 도구 직접 호출과 워크플로 전반에 걸친 추적 가능성, 환경 또는 고객별 비용 가시성, 애플리케이션/워크플로/모델 계층 전반에 걸친 엔드 투 엔드 관찰성도 포함됩니다. 이러한 요소는 있으면 좋은 아키텍처적 사치품이 아닙니다. 팀이 시스템 동작을 이해하고, 적절한 계층에서 인시던트를 조사하고, 원시 로그를 뒤져 이벤트를 재구성하지 않고도 규정 준수를 입증할 수 있게 해주는 필수 요소들입니다.

EMEA 지역에서 운영하는 팀에게는 규제 환경이 이러한 아키텍처 결정의 상당 부분에 영향을 미칩니다. 데이터 레지던시와 관련한 GDPR 요건으로 인해 테넌트 격리는 단순한 엔터프라이즈 영업 요구 사항이 아니라 법적 요건이기도 합니다. S3 접두사 기반 격리와 테넌트별 암호화는 이를 충족하는 실질적인 메커니즘입니다. 또한 EU AI Act는 고위험 AI 애플리케이션에 대해 투명성과 인적 감독에 관한 추가 의무를 부과하며, 이는 감사 로그와 도구 직접 호출 추적 가능성 요구 사항에 직접적으로 연결됩니다.

참고로, 모든 AWS EMEA 지역에서 Bedrock 모델 가용성, S3 Vectors 및 AgentCore를 일률적으로 사용할 수 있는 것은 아닙니다. 팀은 특정 아키텍처를 적용하기 전에 대상 지역에서의 가용성을 확인해야 합니다.

또한 Startup 팀은 S3 Vectors와 AgentCore를 비롯하여 위에서 언급한 일부 서비스가 프로덕션 환경에서는 비교적 새로운 서비스라는 점에 유의해야 합니다. 핵심 인프라로 사용하기 전에 특정 사용 사례와 지역의 성숙도를 검증하세요.

주요 서비스: Amazon Bedrock(기밀 컴퓨팅), AWS Identity and Access Management(IAM), Amazon CloudWatch, AgentCore Policy(Cedar), AgentCore Evaluations, AWS Security Hub. 

시작점: 구매자 또는 규정 준수 책임자에게 감사 로그에서 증명해야 할 내용을 결정합니다. 그런 다음 이를 시작점으로 필요한 정책과 도구에 대해 거꾸로 생각해 봅니다.

전체 시스템을 하나로 합치는 방법

사용자 요청이 애플리케이션에 들어오면 런타임이 요청을 인증하고 테넌트 컨텍스트를 확인합니다. 이후 컨텍스트 계층에서 관련 메모리와 제품 지식을 검색합니다. 오케스트레이션 계층은 해당 작업이 단순한 모델 상호 작용인지, 아니면 여러 단계를 거치는 워크플로인지 판단합니다. 추론 계층은 다음 단계에 대한 생성 또는 추론을 수행합니다. 정책은 간접 호출할 수 있는 도구를 제한합니다. 장시간 실행되는 단계는 상태를 체크포인트로 저장하고 장애 발생 시 정상적으로 복구합니다. 시스템은 각 단계에서 텔레메트리를 생성합니다. 평가와 피드백 루프는 시간 경과에 따른 품질을 측정합니다. 제품 팀은 이러한 신호를 활용해 프롬프트를 개선하거나, 정책을 업데이트하거나, 검색 품질을 개선하거나, 더 심층적인 모델 맞춤화가 필요한 시점을 결정합니다.

이것이 바로 실제로 적용되는 시스템 사고입니다. 성공하는 아키텍처는 데이터, 컨텍스트, 추론, 워크플로, 거버넌스, 운영을 하나의 일관된 시스템으로 구성하여, 회사가 성장하고 규모가 확장되더라도 안정적이고 예측 가능하게 동작하도록 만드는 아키텍처입니다.

대부분의 Startup 팀에게 진입점은 계층 1입니다. 에이전트나 오케스트레이션을 시작하기 바로 전에 데이터 기반과 테넌트 격리를 확보합니다. 그 뒤에 오는 계층의 신뢰성은 그 아래 계층의 신뢰성이 바탕이 되어야만 실현됩니다.

직접 빌드하고 직접 소유

잘 설계된 AI 스택은 특정 서비스 하나 때문이 아니라 각 계층이 하나의 일관된 시스템으로 함께 작동하기 때문에 출시 기간 단축, 신뢰성 향상, 신뢰 확보, 비용 통제를 가능케 합니다. 스택이 시스템 지향으로 설계되어 있다면, 새로운 기능이 등장할 때마다 다시 구축할 필요 없이 비즈니스 성장에 맞춰 아키텍처를 지속적으로 발전시킬 수 있습니다.