아마존웹서비스, 다중 계정 환경에서 텍스트랙트 어댑터 수명 주기를 자동화하는 아키텍처 공개

아마존웹서비스(AWS)는 완전관리형 머신러닝 문서 처리 서비스인 아마존 텍스트랙트(Amazon Textract)의 어댑터 수명 주기 관리(Lifecycle Management) 아키텍처를 공개하고 다중 계정 환경에서의 배포·운영 패턴을 제시했다. 이번에 정리된 아키텍처는 맞춤형 쿼리(Custom Queries) 어댑터를 비롯해 양식(Forms), 테이블(Tables) 어댑터 전반에 적용할 수 있는 설계로, AWS 시스템즈 매니저 파라미터 스토어(AWS Systems Manager Parameter Store)에 어댑터 식별자(ID)를 외부화하는 방식을 도입했다. 이를 통해 개발자는 애플리케이션 코드를 재배포하거나 서비스를 중단하지 않고도 단 몇 초 만에 프로덕션 환경의 어댑터 버전을 갱신할 수 있는 체계를 갖출 수 있다. 더불어 AWS 클라우드포메이션(AWS CloudFormation)과 테라폼(Terraform)을 이용한 인프라 템플릿, 문서 라우팅을 위한 사전 분류 파이프라인, 계정 간 어댑터 승격 절차를 통합하여 제공한다.

조직이 청구서 처리, 모기지 신청, 보험금 청구 등 문서 업무 자동화에 텍스트랙트를 도입한 뒤 개념 검증(PoC) 단계에서 실제 프로덕션으로 전환할 때 세 가지 핵심 과제에 직면하게 된다. 첫째는 훈련된 어댑터를 훈련 계정에서 프로덕션 계정으로 안전하게 이동시키는 승격(Promotion) 문제로, 기존에는 AWS 지원(AWS Support) 티켓을 통한 수동 작업이 요구되어 릴리스 속도를 늦추는 병목이 발생했다. 둘째는 텍스트랙트의 API가 페이지당 기능 유형별로 단 하나의 어댑터만 적용할 수 있도록 제한되어 있어, 여러 서식 버전이 공존하는 기업 환경에서 적합한 어댑터를 골라내는 업스트림 라우팅 구조가 필수적이라는 점이다. 셋째는 규제 대상 산업군에서 요구하는 전송 및 유휴 상태 암호화, 네트워크 격리, 최소 권한 원칙의 IAM 설정, 감사 로깅 등 프로덕션 환경에 부합하는 엔터프라이즈 보안 요건을 충족해야 하는 배경이 존재했다.

제안된 처리 파이프라인은 문서 분류, 어댑터 선택, 텍스트 추출의 단계를 명확히 분리하여 동작한다. 문서가 아마존 S3(Amazon S3) 버킷에 유입되면 경량화된 사전 분류(Pre-classification) 단계에서 DetectDocumentText API로 원시 텍스트를 추출한 뒤 양식 제목, 버전 식별자, 고유 필드 라벨 등의 텍스트 마커를 검색해 문서 버전을 판정한다. 분류 결과가 나오면 파라미터 스토어에서 해당하는 어댑터 ID를 실시간으로 조회하고, 동기식 AnalyzeDocument 또는 비동기식 StartDocumentAnalysis API를 호출해 커스텀 쿼리 추출을 수행한다. 추출된 키-값 쌍은 데이터베이스나 워크플로 엔진 같은 다운스트림 시스템으로 전달된다. 환경 토폴로지는 훈련(Training), 검증(Validation), 사전 프로덕션(Pre-production), 프로덕션(Production)의 4단계를 권장하며, 조직 규모에 따라 단일 계정 내 태그와 버킷 기반 격리부터 다중 전용 계정 구조까지 유연하게 구성할 수 있다.

계정 간 어댑터 이동 전략으로는 두 가지 접근법이 제시되었다. 첫 번째는 표준 '교차 계정 복사(Cross-Account Copy)'로, 훈련 계정에서 생성한 어댑터를 AWS 지원 티켓을 통해 대상 계정으로 복사하여 각 환경이 독립된 어댑터 ID를 유지하는 방식이다. 이는 관리 대상 어댑터가 10개 미만이고 업데이트가 드문 조직에 적합하다. 두 번째는 '중앙 집중식 허브 계정(Centralized Hub Account)' 방식으로, 단일 허브 계정에서 모든 어댑터를 훈련하고 각 워크로드 환경이 교차 계정 IAM 역할(AssumeRole)을 통해 허브 계정의 텍스트랙트를 호출하는 구조다. 이 방식은 반복적인 지원 티켓 발행을 없애주지만 혼동된 대리자(Confused Deputy) 공격 방지를 위해 sts:ExternalId 조건을 엄격히 설정해야 한다. 인프라 코드로 배포할 때 어댑터 자체는 클라우드포메이션에서 네이티브 생성을 지원하지 않아 AWS CLI나 람다(Lambda) 기반 커스텀 리소스를 사용해야 하며, 테라폼의 경우 1.4 버전 이상에서 제공되는 terraform_data 리소스와 local-exec 프로비저너를 임시 대안으로 활용하도록 명시했다.

이 수명 주기 관리 패턴을 적용하면 어댑터 배포와 애플리케이션 비즈니스 로직이 완전히 분리되어 운영 효율이 크게 개선된다. 모델을 재학습하거나 새 버전을 릴리스할 때 파라미터 스토어의 값만 수정하면 다운타임 없이 즉시 반영된다. 어댑터 훈련 및 버전 관리 지침에 따르면 어댑터당 최소 5개 이상의 훈련 문서와 5개 이상의 테스트 문서가 필요하며, 최대 용량은 훈련 2,500페이지, 테스트 1,000페이지까지 지원된다. 문서 유형이 바뀌거나 기능 유형이 다를 때는 새 어댑터를 생성하고, 동일 양식에서 쿼리 추가·수정이나 주석 오류를 수정할 때는 기존 어댑터의 새 버전을 생성하는 식의 분리 기준도 제공된다. 비용 측면에서는 허브 계정 방식을 도입할 경우 모든 API 호출 요금이 단일 계정으로 청구되므로 비용 할당 태그를 통한 내부 정산(Chargeback) 체계가 필요하며, 텍스트랙트는 정액 요금제이므로 계정 통합에 따른 볼륨 할인은 제공되지 않는다.

프로덕션 환경의 보안 강화를 위한 구체적인 구성 요소도 명시되었다. 네트워크 격리를 위해 AWS 프라이빗링크(AWS PrivateLink) 기반의 VPC 엔드포인트를 구성하여 인터넷 통신 없이 아마존 사설 네트워크 내에서 API 호출을 처리해야 한다. 저장 데이터 암호화를 위해서는 고객 관리형 KMS 키(SSE-KMS)를 적용하고, S3 버킷 정책에 aws:CalledViaFirst 조건 키를 추가하여 텍스트랙트를 거치지 않는 직접 버킷 접근을 차단한다. 또한 민감 정보(PII, PHI) 처리에 대비해 AWS 오거니제이션(AWS Organizations)의 AI 서비스 옵트아웃 정책(AI services opt-out policies)을 계정이나 조직 단위에 적용하면, 서비스 개선 목적으로 AWS가 데이터를 저장하거나 활용하지 않도록 강제할 수 있다. 텍스트랙트는 동기식 처리의 경우 응답 반환 후 문서를 보관하지 않으며, HIPAA, PCI DSS, FedRAMP High, SOC 1/2/3, ISO 계열 등 주요 컴플라이언스 인증 요건을 충족한다.

아키텍처 적용 시 반드시 고려해야 할 기술적 제약과 한계도 함께 확인되었다. 우선 지원 파일 포맷은 JPEG, PNG, PDF, TIFF로 한정되며 XFA 기반 PDF는 지원되지 않는다. 파일 처리 용량의 경우 동기식 AnalyzeDocument API는 최대 10MB 크기의 단일 페이지만 처리할 수 있으며, 다중 페이지 처리를 위해서는 최대 3,000페이지를 지원하는 비동기식 StartDocumentAnalysis API를 사용해야 한다. 계정 간 어댑터 복사를 진행할 때 출발지와 목적지 계정은 반드시 동일한 AWS 리전에 위치해야 하며, 복사 과정에서 전달되는 것은 훈련된 모델 가중치(Weights)뿐이므로 쿼리 정의와 훈련 데이터는 파라미터 스토어나 형상 관리 도구에 개발자가 직접 외부 보관해야 한다. 또한 현재 텍스트랙트의 문서 처리 액션은 리소스 레벨 IAM 권한을 지원하지 않아 정책의 리소스 항목을 와일드카드(*)로 지정해야 하는 제약이 있으며, 중앙 집중식 허브 방식을 채택할 경우 초당 트랜잭션(TPS)과 월간 어댑터 버전 생성 쿼터가 단일 계정에 집중되므로 사전 쿼터 증설이나 분산 복사 방식 검토가 요구된다.