만약 당신이 B2B SaaS 기업의 기술 창업자(Technical Founder)이거나 엔지니어링 리더라면, 엔터프라이즈 소프트웨어의 가장 어둡고 비용이 많이 드는 비밀을 알고 있을 것입니다. 바로 **커스텀 클라이언트 통합 (Custom Client Integrations)**입니다.

마침내 거대한 Fortune 500 기업과의 계약을 성사시켰습니다. 샴페인을 터뜨릴 준비가 되었습니다. 그때, 그들의 IT 부서가 폭탄 발언을 던집니다. "저희는 AS/400 메인프레임에서 내보낸 20년 된 독자적인 XML 형식을 통해서만 일일 재고 데이터를 보낼 수 있습니다."

갑자기 제품 로드맵(Product Roadmap)이 중단됩니다. 이 단 한 명의 클라이언트가 가진 레거시 쓰레기 데이터를 당신의 현대적인 JSON 데이터베이스로 수집하기 위해, 커스텀 파서(Parser), 크론 잡(Cron jobs), 매핑 스크립트(Mapping scripts)를 작성하는 데 3주를 소비하도록 "통합 엔지니어 (Integration Engineers)" 팀을 할당해야 합니다.

이것은 영혼을 갉아먹는, 확장 불가능한(Unscalable) 작업입니다.

하지만 다시는 ETL (Extract, Transform, Load) 파서를 작성할 필요가 없다면 어떨까요? 단 하나의 범용 API 엔드포인트를 구축하고 모든 엔터프라이즈 클라이언트에게 이렇게 말할 수 있다면 어떨까요? "데이터 형식이 무엇이든 상관없습니다. 가공되지 않은 XML, 이상한 JSON, CSV, SOAP 페이로드, 또는 EDIFACT를 보내주세요. 이 하나의 URL로 보내주시면, 저희 인프라가 동적으로 이를 파악할 것입니다."

7가지 AWS 서버리스 프리미티브(Serverless Primitives)를 사용하여 **"Zero-Code" 범용 AI 데이터 수집 엔진 (Universal AI Ingestion Engine)**을 구축함으로써 커스텀 통합 팀을 없애는 방법을 소개합니다.

전환점: 코드 생성(Code Generation) vs. 데이터 처리(Data Processing)

데이터 통합에 AI를 적용할 때 엔지니어들이 저지르는 가장 흔한 실수는 LLM에게 데이터를 처리하도록 요청하는 것입니다.

만약 5GB 크기의 XML 파일을 Claude 3.5 Sonnet에 전달하고 JSON으로 출력해달라고 요청한다면, 즉시 컨텍스트 윈도우(Context Window) 제한에 걸리게 됩니다. 설령 성공하더라도, 파일 하나당 수백 달러의 토큰 추론 비용을 지불해야 할 것입니다.

전환점: 우리는 데이터를 처리하기 위해 AI를 사용하지 않습니다. 우리는 파서를 작성하기 위해 AI를 사용합니다.

우리는 LLM에 혼란스러운 클라이언트 데이터의 아주 작은 2KB 샘플과 우리가 요구하는 JSON 스키마(Schema)의 엄격한 복사본을 제공합니다. AI는 데이터를 매핑하기 위한 매우 최적화된 Python 스크립트를 작성합니다. 그런 다음 우리는 표준적이고 저렴한 AWS 컴퓨팅을 사용하여 5GB 페이로드에 대해 해당 Python 스크립트를 실행합니다.

아키텍처: 7개 서비스 워크플로 (The 7-Service Workflow)

이 범용 수집 엔진(Universal Ingestion Engine)을 구축하는 데 필요한 정확한 AWS 아키텍처는 다음과 같습니다.

1. Amazon API Gateway (범용 관문 (The Universal Door))

모든 콘텐츠 타입(*/*)을 수락하도록 구성된 단일 REST 엔드포인트를 노출합니다. 이는 어떠한 검증도 수행하지 않는 "덤 파이프 (dumb pipe)" 역할을 합니다.

2. Amazon Kinesis Data Streams (버퍼 (The Buffer))

API Gateway는 파싱되지 않은 혼란스러운 페이로드(payloads)를 즉시 Kinesis로 떨어뜨립니다. 만약 레거시 클라이언트(legacy client)에 버그가 있어 실수로 한 번에 1,000만 개의 행을 쏟아붓더라도, Kinesis가 급증하는 트래픽을 흡수하여 백엔드가 충돌하는 것을 방지합니다.

3. AWS Step Functions (오케스트레이터 (The Orchestrator))

Kinesis는 Step Functions 상태 머신(state machine)을 트리거합니다. 이는 제어 평면(control plane) 역할을 하여, 변환 단계 동안 클라이언트 데이터가 누락되거나 손실되지 않도록 보장합니다.

4. Amazon Bedrock (스키마 번역기 (The Schema Translator))

Step Functions는 원시 페이로드의 아주 작은 샘플(처음 50줄)을 추출하여 Amazon Bedrock (Claude 3.5 Sonnet)으로 보냅니다.
프롬프트 (The Prompt): "이 원시 데이터를 분석하세요. 필드를 식별하세요. 이 원시 페이로드를 문자열로 받아 제공된 JSON 스키마(JSON Schema)와 엄격하게 일치하는 JSON 배열을 출력하는, 의존성이 없는(dependency-free) 고도로 최적화된 Python 스크립트를 작성하세요."

5. AWS Lambda (동적 실행기 (The Dynamic Executor))

Step Functions는 Bedrock이 생성한 Python 스크립트와 전체 데이터 페이로드를 모두 일시적인(ephemeral) AWS Lambda 함수로 전달합니다. Lambda 함수는 페이로드를 대상으로 AI가 생성한 코드를 실행하여, 레거시의 혼란을 밀리초 단위 내에 아름답고 엄격하게 검증된 JSON으로 변환합니다.

6. Amazon EventBridge (이벤트 라우터 (The Event Router))

Lambda 함수는 완벽하게 매핑된 JSON을 EventBridge 버스로 푸시합니다. 핵심 애플리케이션 마이크로서비스(microservices)는 이 데이터가 20년 된 SOAP 페이로드(payload)에서 유래했다는 사실을 전혀 모른 채 원활하게 데이터를 소비합니다.

7. Amazon SQS (AI 폴백 (The AI Fallback))

만약 Bedrock이 혼란을 겪거나(예: "세 가지 다른 통화 기호가 사용되었기 때문에 'Cost' 필드를 정확하게 매핑했는지에 대한 확신이 80%뿐입니다"), Lambda 실행 중 Python 에러가 발생하면, Step Functions는 페이로드를 SQS 데드 레터 큐(Dead Letter Queue, DLQ)로 라우팅합니다. 이는 엔지니어에게 Slack 알림을 보내 AI의 매핑을 검토하고, Python 스크립트를 수정하며, 페이로드를 승인하도록 트리거합니다.

CTO의 관점: 현실적인 경제성 (Grounded Economics)

이 내용을 엔지니어링 리더십에 설명할 때, 그들의 반응은 매우 강렬합니다: "잠깐만요. 우리가 커스텀 통합(custom integrations) 팀을 해고할 수 있다고요? 고객에게 단순한 웹훅(webhook)만 제공하면, AI가 실시간으로 직접 Python 스크립트를 작성한다는 건가요?"

네, 맞습니다. 하지만 왜 우리가 코드 생성(code generation)과 데이터 실행(data execution)을 분리해야 하는지 증명하기 위해 단위 경제성(unit economics)을 살펴보겠습니다.

시나리오: 100,000개의 트랜잭션 레코드가 포함된 500MB 규모의 레거시 XML 파일 수집.

**접근 방식 A: "단순 AI" 방식 (LLM을 통한 데이터 처리)

• 500MB를 LLM에 직접 전달할 수는 없습니다. 데이터를 청크(chunk)로 나누어야 합니다.
• 데이터를 청크로 나누어 수백 번의 API 호출을 통해 Claude 3.5 Sonnet에 100,000개의 레코드를 전달한다고 가정해 봅시다.
• 비용: 토큰 추론(token inference) 비용으로 파일 한 개당 약 $50.00에서 $100.00 이상 소요.
• 지연 시간(Latency): 몇 분에서 몇 시간.

**접근 방식 B: "Zero-Code" 아키텍처 (LLM을 통한 코드 작성)

• XML의 2KB 샘플을 Claude 3.5 Sonnet에 전달합니다.
• Bedrock 비용: 약 1,000개의 입력 토큰 + 500개의 출력 토큰 = 약 $0.0105.
• Lambda가 생성된 Python 스크립트를 500MB 파일에 대해 실행합니다 (2GB RAM Lambda 함수를 사용하여 10초 동안 실행).
• Lambda 비용: 약 $0.000333.
• 총 비용: 1.1센트 미만.
• 지연 시간(Latency): 약 12초.

정확히 동일한 의미론적 변환(semantic translation)을 달성하면서도, 수익 마진을 온전히 유지할 수 있습니다.

엔지니어링 현실 점검: 트레이드오프(Tradeoffs) 및 가드레일(Guardrails)

클라우드 아키텍트로서 저는 경고해야 합니다. 프로덕션 환경에서 동적으로 생성된 코드를 실행하는 것은 엄청난 보안 리스크를 동반합니다. 엄격한 아키텍처적 가드레일(guardrails) 없이는 이를 배포할 수 없습니다.

1. RCE 취약점 (샌드박싱(Sandboxing)은 필수)

당신은 말 그대로 AI에게 코드를 작성하도록 요청한 뒤, exec() 또는 import를 사용하여 서버에서 이를 실행하는 것입니다. 만약 악의적인 클라이언트가 AI에게 리버스 셸(reverse-shell) 스크립트를 작성하도록 유도하는 프롬프트 인젝션(prompt-inject) 페이로드를 업로드한다면, 당신은 AWS 계정의 열쇠를 그들에게 넘겨주는 셈입니다.
해결책: "동적 실행기(Dynamic Executor)" Lambda 함수는 완전히 격리되어야 합니다. 이 함수는 VPC 인터넷 접속이 전혀 없어야 하며, IAM 실행 역할(IAM Execution Role)은 EventBridge에 대한 events:PutEvents 권한 외에는 어떠한 권한도 가져서는 안 됩니다. 또한 완전히 일시적(ephemeral)이고 폐쇄된 실행 환경에서 구동되어야 합니다.

2. 대용량 파일의 물리적 한계 (API Gateway 제한)

위의 아키텍처에서는 API Gateway를 사용합니다. 하지만 API Gateway에는 10MB라는 엄격한 페이로드(payload) 제한이 있습니다. Kinesis 레코드는 기본적으로 **1 MiB(최대 10 MiB까지 설정 가능)**의 제한을 가집니다.
해결책: 클라이언트가 5GB 크기의 거대한 XML 파일을 전송하는 경우, 웹훅(webhook)을 사용할 수 없습니다. 클라이언트가 파일을 보안 **Amazon S3 버킷(Amazon S3 Bucket)**에 업로드하도록 안내해야 합니다. 이 경우 동일한 Step Functions 워크플로우가 트리거되지만, Lambda는 이벤트 페이로드에서 데이터를 읽는 대신 S3로부터 데이터를 스트리밍(streaming)하게 됩니다.

3. 번역 캐싱 (멱등성(Idempotency))

동일한 클라이언트를 위해 매일 Bedrock에 Python 스크립트를 작성하도록 요청해서는 안 됩니다.
해결책: 생성된 스크립트가 성공적으로 실행되고 검증을 통과하면, ClientID를 키(key)로 하여 Amazon DynamoDB 테이블에 해당 스크립트를 저장하십시오. 다음 날 클라이언트가 동일한 형식을 보낼 때, Step Functions는 Bedrock을 완전히 건너뛰고 DynamoDB에서 캐싱된 Python 스크립트를 가져와 즉시 실행합니다.

결론

B2B 데이터 통합은 수십 년 동안 수동적이고 영혼을 갉아먹는 병목 구간(bottleneck)이었습니다.

Amazon Bedrock의 추론 능력 (reasoning capabilities)과 AWS Lambda 및 Step Functions의 원시 컴퓨팅 실행 능력을 결합함으로써, 우리는 클라이언트의 포맷팅 혼란 (formatting chaos)으로부터 애플리케이션을 완전히 분리(decouple)할 수 있습니다.

커스텀 ETL 파이프라인 (ETL pipelines) 작성을 중단하십시오. 범용적인 문 (universal door)을 구축하고, AI가 다리를 놓게 하십시오.

귀하의 SaaS는 현재 커스텀 엔터프라이즈 데이터 통합 (enterprise data integrations)을 어떻게 처리하고 있습니까? 스키마 변환 (schema translation)을 위해 LLM을 사용하는 실험을 해보셨나요? 아래 댓글에서 함께 논의해 봅시다!