헌팅턴 은행(The Huntington National Bank)은 미국 10대 은행 중 하나로, 약 10년간 축적된 4억 건 이상의 금융 문서에서 PII를 자동 레닥션하기 위해 AWS와 공동 프로젝트를 진행한 것으로 분석된다. 본문에서는 AWS 기반 문서 처리, 민감정보 탐지, MLOps 거버넌스까지 엔드투엔드 아키텍처와 운영 설계의 핵심을 정리한다.
- 대규모 백로그 자동화: 수작업으로는 수년이 걸릴 4억 건 레닥션을 AI 파이프라인으로 전환
- 정책 기반 일관성: Amazon Comprehend와 커스텀 NER로 일관된 PII 탐지 정책을 거버넌스 차원에서 운영
- 엔드투엔드 MLOps: Amazon Textract, Comprehend, Bedrock, 휴먼 인 더 루프를 결합한 검증형 워크플로우
대규모 금융 문서 레닥션은 단순 마스킹 작업이 아니라 규제 준수와 데이터 거버넌스를 코드로 정의하는 MLOps 프로젝트에 가깝다.
금융권의 문서 레닥션은 수천 건 단위 소규모 작업에서는 사람이 처리할 수 있지만, 4억 건 이상의 누적 리포지토리에서는 수작업 자체가 한계에 부딪힌다. 헌팅턴 은행이 AWS와 함께 구축한 자동화 사례는 이러한 대규모 백로그를 정책 기반으로 풀어낸 레퍼런스로 읽힌다. 본문은 아키텍처 구성, 거버넌스 설계, 정량 효과, 도입 시사점 순으로 전개한다.
4억 건 문서, 수작업으로는 왜 한계인가
헌팅턴 은행이 직면한 레닥션 백로그의 실체
헌팅턴 은행은 약 10년 동안 운영 과정에서 발생한 문서를 내부 리포지토리에 축적해 온 것으로 분석되며, AWS ML Blog에 따르면 그 규모는 4억 건을 넘는다. 사람이 직접 검토해야 하는 레닥션 작업은 문서당 수 분이 아닌 수십 분이 소요될 수 있으며, 검토자별 판단 편차도 함께 발생할 수 있다. 결국 일관성 부족과 처리 지연이 동시에 누적되는 구조적 병목이 만들어진다.
금융권 규제와 데이터 최소화가 핵심인 산업의 충돌
금융권은 GLBA, SOX, NYDFS 등 다층 규제 아래에서 개인식별정보 최소 보유 원칙을 준수해야 할 수 있다. 4억 건 규모의 문서에서 PII를 어떻게 식별하고, 어떤 보존 기간을 적용하며, 외부 공유 시 어떤 마스킹 규칙을 적용할지 결정하는 일은 단순 IT 작업이 아니라 컴플라이언스 의사결정이다. 따라서 자동화 이전에 정책 명세와 감사 가능성이 우선 설계되어야 한다.
AWS 기반 레닥션 파이프라인 아키텍처
문서 수집과 분류: Amazon S3와 Amazon Textract의 역할
파이프라인의 시작은 Amazon S3에 저장된 원본 문서 풀이다. PDF, 스캔 이미지, 이메일 첨부 등 다양한 형식이 섞여 있을 수 있으며, Amazon Textract는 스캔 문서와 이미지 내 텍스트를 구조화된 형태로 추출해 후속 모델이 처리하기 좋은 입력으로 정규화한다. 문서 유형 분류는 추후 레닥션 룰 분기의 기준이 되므로, 이 단계의 품질이 전체 파이프라인의 안정성을 좌우한다.
민감정보 탐지: Amazon Comprehend와 커스텀 NER
추출된 텍스트에 대해 Amazon Comprehend의 PII 탐지 기능이 기본 식별을 수행하고, 금융권 도메인 특화 엔터티(예: 계좌번호, 내부 고객번호, 약정서 특화 필드)는 커스텀 NER 모델로 보강하는 구성이 자연스럽다. Comprehend는 관리형 서비스로서 운영 부담을 줄이고, 커스텀 NER은 도메인 정확도를 끌어올리는 역할을 분담한다. 두 출력을 머지한 뒤 신뢰도 임계값을 적용해 자동 마스킹 대상과 휴먼 검토 대상으로 라우팅한다.
레닥션과 검증: Amazon Bedrock과 휴먼 인 더 루프
탐지된 엔터티 위치에는 마스킹 토큰 또는 시각적 가림이 적용된다. Amazon Bedrock 기반 생성형 모델은 마스킹 후 문서의 가독성과 문맥을 유지하는 보조 작업, 또는 휴먼 검토 대상 샘플의 우선순위 분류에 활용될 수 있다. 그리고 일부 민감 케이스는 라벨링 담당자에게 전달되어 최종 결정되며, 이 피드백은 모델 재학습 데이터로 회수된다.
| 단계 | 핵심 AWS 서비스 | 주요 산출물 |
|---|---|---|
| 수집/저장 | Amazon S3 | 원본 문서 객체, 메타데이터 태그 |
| 문서 추출 | Amazon Textract | 구조화된 텍스트, 표, 폼 필드 |
| 민감정보 탐지 | Amazon Comprehend(PII), 커스텀 NER | 엔터티 오프셋, 라벨, 신뢰도 |
| 레닥션 적용 | Amazon Bedrock, 마스킹 엔진 | 레닥션된 PDF/이미지, 감사 로그 |
| 검증/재학습 | 휴먼 인 더 루프, SageMaker | 검수 결과, 재학습 데이터셋 |
운영 거버넌스와 MLOps 설계
정책 기반 마스킹 룰과 모델 버전 관리 전략
단일 모델이 모든 문서 유형을 책임지는 구조는 운영 리스크가 크다. 도메인별, 문서 유형별 마스킹 정책을 코드 형태로 정의하고, 동일 입력에 대해 동일 출력이 나오도록 버전 관리하는 것이 핵심이다. Amazon Comprehend의 커스텀 모델과 룰 기반 사전을 조합해 정책 변경 시 재학습과 재처리가 결정적으로 재현 가능하도록 설계할 필요가 있다.
감사 로그, 재처리, 롤백을 고려한 워크플로우
금융 컴플라이언스에서는 누가, 어떤 정책 버전으로, 어떤 문서를 레닥션했는지가 추적 가능해야 한다. 따라서 처리 이력, 모델 버전, 휴먼 검토 결과를 통합 로그로 남기고, 정책 오류가 발견되면 영향 문서만 선별해 재처리하거나 롤백할 수 있는 워크플로우가 필요하다. 이 부분이 갖춰지는 경우 자동화가 감사 부서의 승인을 받기 쉬워진다.
도입 효과와 정량 지표
처리 속도, 비용, 정확도의 변화
AWS ML Blog 사례 기준으로 4억 건 규모의 백로그는 수작업만으로 해결하기 어려우며, 자동화 도입을 통해 처리 속도 면에서 큰 폭의 개선이 있었던 것으로 분석된다. 정량 수치 자체는 원문에 명시되지 않은 항목이 많아 보수적으로 해석해야 하며, 인스턴스 기반 처리와 관리형 서비스의 조합은 단위 문서당 처리 비용을 낮추는 방향으로 작용한다. 정확도는 휴먼 인 더 루프 라벨을 반영한 지속 개선 구조에서 점진적으로 향상된다.
컴플라이언스 리스크 감소와 업무 부담 경감
속도와 비용만큼 중요한 변화는 정책 일관성과 감사 대응력이다. 동일 마스킹 정책이 전사 문서에 일괄 적용되므로 담당자별 편차가 사라지고, 감사 요청 시 레닥션 이력을 빠르게 조회할 수 있다. 또한 검토 담당자는 자동 처리 결과의 예외 케이스에 집중하게 되어 업무 부담이 경감된다.
다른 금융기관이 참고할 시사점
단계별 도입 체크리스트
- 문서 인벤토리 정리 및 도메인별 마스킹 정책 명세화
- Amazon Textract 기반 추출 품질 검증 및 예외 유형 정의
- Amazon Comprehend PII와 커스텀 NER의 분담 기준 수립
- Amazon Bedrock과 휴먼 인 더 루프를 결합한 검증 루프 설계
- S3 버킷 정책, KMS 암호화, IAM 역할 기반 접근 제어 구성
- 감사 로그, 모델 버전, 재처리/롤백 절차 운영 문서화
흔히 놓치는 함정과 권장 구현 패턴
흔히 발생하는 함정은 추출 단계의 품질 저하를 모델 단계에서 보정하려 하거나, 레닥션 정확도만 추구하고 감사 추적성을 등한시하는 경우다. 권장 패턴은 추출-탐지-적용-검증의 4단계를 명확히 분리하고, 각 단계의 품질 지표를 별도로 모니터링하는 것이다. 또한 PII 데이터 자체는 최소한의 기간만 보존하고, 학습 데이터는 비식별화 후에만 사용하는 정책이 병행되어야 한다.
핵심 정리
- 헌팅턴 은행 사례는 4억 건 금융 문서 레닥션을 엔드투엔드 MLOps로 풀어낸 레퍼런스다.
- Amazon Textract, Comprehend, Bedrock, 휴먼 인 더 루프 조합이 정책 일관성과 처리 속도를 동시에 끌어올린다.
- 자동화의 진짜 가치는 정확도뿐 아니라 정책 기반 거버넌스와 감사 추적성 확보에 있다.
- 도입 초기에는 추출 품질 관리, 모델과 룰의 분담, 재처리/롤백 설계에 충분한 시간을 할애해야 한다.
참고 출처: AWS ML Blog – Huntington Bank 레닥션 사례 원문, AWS Machine Learning Blog 인덱스