Data Quality Agent: Indegene이 품질 규칙을 AI 제안·전문가 승인으로 바꿔 데이터셋당 30시간을 4시간으로

Indegene은 데이터 품질 규칙을 사람이 처음부터 쓰던 일을 바꿨습니다. 이제 에이전트가 메타데이터와 업무 문서를 읽고 규칙과 SQL 초안을 내면, 사람은 검토하고 승인합니다. 회사 추정으로 데이터셋당 규칙 정의 공수가 약 30시간에서 4시간으로 줄었습니다. 따라 하려면 용어집·SOP 같은 업무 지식을 검색할 수 있게 모으고, 어떤 규칙을 누가 승인하는지부터 정해야 합니다.

요약

Indegene은 제약·바이오 기업의 영업, 의학, R&D, 안전성 업무를 맡아 운영하는 회사입니다. 이 회사는 상업·의학·임상·전사 데이터를 묶는 자사 플랫폼 NEXT UDP(NEXT Unified Data Platform)에 Data Quality Agent를 넣었습니다. 2026년 11월 4일 Indegene의 Shravan K S와 AWS의 Bhagyashree Chandak가 AWS 머신러닝 블로그에 구조와 수치를 공개했습니다. 에이전트는 Amazon Bedrock의 Claude Sonnet 4.5로 규칙과 코드를 만들고, Strands Agents(에이전트 프레임워크)와 Amazon Bedrock AgentCore(에이전트 실행·메모리·관측 서비스) 위에서 돕니다. 사용자가 테이블을 고르면 에이전트가 데이터를 프로파일링(빈 값 비율, 고유값 수, 값 범위 같은 현재 상태 측정)하고 과거 기준선과 비교해 이상을 찾습니다. 그 결과에 카탈로그, 기존 규칙, 두 지식 베이스를 더해 기술 규칙과 업무 규칙을 심각도와 함께 제안합니다. 사람이 승인하면 SQL·Python 코드를 만들고 검증해 중앙 규칙 저장소에 넣습니다.

테이블 하나가 규칙 묶음이 되기까지. 원문의 10단계를 다섯 덩어리로 묶어 새로 그림

출발점은 규칙의 주인이 둘로 갈려 있다는 문제였습니다. 데이터 엔지니어는 HCP(의료 전문가) ID가 비어 있지 않고 중복되지 않는다는 식의 기술 규칙을 코드에 둡니다. 현업은 한 지역의 시장점유율 합이 100%여야 한다는 식의 업무 규칙을 용어집, SOP, 전문가의 머릿속에 둡니다. 새 데이터셋이 올 때마다 프로파일링, 규칙 정의, SQL 작성, 검증을 손으로 반복했고 규칙은 SQL 스크립트와 스프레드시트, 카탈로그에 흩어졌습니다. 에이전트가 두 종류의 규칙을 한 흐름에 모으자 데이터셋당 규칙 정의·구현 공수가 약 30시간에서 4시간으로, 신규 테이블 등록이 2~5영업일에서 2~4시간으로 줄었습니다(회사 추정). 제안한 규칙의 60~75%는 고치지 않고 채택됩니다. 엔지니어와 스튜어드는 규칙을 쓰는 대신 검토하고 승인하는 데 시간을 씁니다. 아래에서 다섯 가지 작동 원리와 실제 테이블 예시를 보고, 따라 할 때 필요한 기술·현업 디테일을 붙입니다.

회사 추정(Indegene 운영 배포 기준). 약 85% 감소, 약 7배 생산성. 막대 길이는 0 기준 비례

핵심 메커니즘

Context Assembly: 규칙을 제안하기 전에 여섯 곳을 먼저 읽는다

에이전트는 규칙을 바로 쓰지 않습니다. 먼저 여섯 가지 문맥을 모읍니다. 카탈로그 메타데이터는 이 데이터가 무엇인지(스키마, 타입)를 알려 줍니다. 프로파일은 지금 데이터가 어떻게 생겼는지를 보여 줍니다. 이상 탐지 결과는 빈 값이 갑자기 늘거나 고유값 수가 바뀐 것처럼 최근에 변한 점을 짚습니다. 기존 활성 규칙을 함께 읽기 때문에 이미 있는 규칙과 겹치거나 부딪치는 제안을 피합니다. 마지막으로 External KB와 Internal KB에서 업계 표준과 회사 기준을 검색해 붙입니다. 이 순서 덕분에 제안이 열 이름만 보고 짐작한 규칙이 아니라 실제 값 분포와 회사 규정에 근거한 규칙이 됩니다. 이상 탐지는 AWS Lambda의 Python 프로세스가 맡으며, 원문은 이를 “statistical comparison against historical baselines”라고 설명합니다. 구체적인 통계 기법과 임계값은 원문에서 밝히지 않았습니다.

규칙 하나를 제안하기 전에 여섯 곳을 먼저 읽음

Two Knowledge Bases: 업계 공통 기준과 회사 고유 기준을 따로 둔다

지식 베이스는 둘입니다. External Reference KB는 승인된 표준 데이터 품질 프레임워크와 웹 검색, 통제된 스크래핑으로 만들고 주기적으로 갱신합니다. NPI(미국 의료 제공자 식별번호) 열이 보이면 10자리 숫자 형식과 참조 점검을 제안하는 식입니다. Internal Enterprise KB에는 업무 용어집, 데이터 사전, SOP, 규제 지침, 승인된 규칙, 검증된 스크립트, 과거 프로파일과 이상 이력, SME 피드백이 들어갑니다. 둘 다 Amazon Bedrock Knowledge Bases의 RAG(검색해 답에 붙이는 방식)로 꺼내 쓰고, 벡터 저장소로 Aurora PostgreSQL의 pgvector를 씁니다. 따로 두는 이유는 출처의 신뢰도와 갱신 주기가 다르기 때문입니다. 업계 표준은 어느 회사에나 맞지만, 시장점유율을 어느 단위로 합산하는지는 그 회사의 SOP만 압니다.

왼쪽은 어느 회사에나 맞는 기준, 오른쪽은 이 회사만의 기준

Rule Modes와 Severity: 범위와 무게를 정해 제안을 나눈다

사용자는 규칙을 만들 범위를 세 가지 모드에서 고릅니다. Column Level은 한 열의 타입, null, 길이·범위, 패턴, 고유성을 봅니다. Table Level은 레코드 일관성, 중복, 열 사이 검증, 참조 무결성, 테이블 전체의 업무 일관성을 봅니다. Custom Query는 현업이 평이한 영어로 쓴 검증 조건을 SQL로 바꾸고, 대화로 다듬거나 직접 고치게 합니다. 제안된 규칙에는 데이터셋 문맥, 규칙 종류, 업무 영향을 근거로 심각도가 붙습니다. Critical은 잘못된 상업 지표나 식별자, 업무 규칙 위반입니다. Basic은 스키마 준수, null, 길이 검증입니다. Complex는 복잡한 SQL이나 여러 열을 엮는 도메인 점검이고, Information은 알림용입니다. 회사 추정으로 심각도 제안 정확도는 75~85%라서 심각도도 사람이 확인하는 항목입니다.

심각도 정의는 원문, 오른쪽 승인 경로 열은 원문의 승인 원칙을 심각도에 대응시킨 개념도

Generate and Validate Code: 만든 모델과 다른 모델이 다시 본다

사람이 규칙을 승인하면 에이전트가 같은 뜻의 SQL, Python, PySpark 코드를 만듭니다. 코드 생성과 점검에는 Claude Sonnet 4.5와 AgentCore Code Interpreter(격리된 코드 실행 환경)를 씁니다. 검증은 세 겹입니다. 문법을 점검하고, 대상 스키마와 대조하고, 언어가 지원하면 표본 데이터로 시험 실행합니다. 그 위에 별도 LLM이 Validation Agent로서 다른 LLM이 만든 규칙과 스크립트를 다시 검토해 환각을 줄입니다. Amazon Bedrock Guardrails는 개인정보를 가리고, 프롬프트 인젝션을 막고, 검색한 지식에 근거가 없는 답을 표시합니다. 통과한 코드는 기존 ETL과 오케스트레이션(AWS Step Functions) 파이프라인에서 그대로 돌고, 승인된 스크립트는 Amazon S3에 보관합니다. 회사 추정으로 SQL 유효성은 스키마에 근거한 경우 90~97%, 사용자 정의 SQL은 80~90%입니다.

코드는 만든 모델과 다른 모델이 한 번 더 봄

Human Oversight와 Central Rule Repository: 승인 경로를 위험으로 나누고 결정을 남긴다

규칙마다 신뢰도 점수가 붙고, 자동 승인은 신뢰도가 높고 위험이 낮은 규칙에만 허용합니다. Critical 규칙과 업무 규칙은 언제나 SME에게 갑니다. 승인 여부와 관계없이 모든 결정은 중앙 규칙 저장소에 기록됩니다. 저장소는 규칙 ID, 이름, 종류, 열, 상태, 작성자, 생성일, 심각도, 버전을 관리하고 소유자를 지정합니다. 규칙 메타데이터는 Amazon DynamoDB에 둡니다. 검토자의 피드백은 AgentCore memory에 남고, 승인된 규칙과 피드백은 다음 제안의 지식이 됩니다. 그래서 같은 도메인의 두 번째 데이터셋부터는 더 빨라집니다. 회사 추정으로 새 규칙의 40~60%가 승인된 규칙을 고쳐 쓴 것이고, 같은 도메인의 신규 데이터셋 등록은 50% 빨라졌습니다. 신뢰도 점수의 구체적인 임계값은 원문에서 밝히지 않았습니다.

승인 결과가 다시 지식이 되는 순환. 새 규칙의 40~60%가 승인된 규칙을 고쳐 쓴 것(회사 추정)

통념과 다른 주장

흔히 이렇게 봅니다데이터 품질은 null, 타입, 중복, 참조 무결성 같은 기술 점검을 갖추면 지킬 수 있고, 그 일은 데이터 엔지니어의 몫이다.

저자는 이렇게 봅니다정적인 기술 점검으로는 제품 계층, 세그먼트, 지역 배정 같은 업무 문맥을 잡지 못합니다. 업무 규칙은 용어집·SOP·전문가에게 있으므로, 그 지식을 검색해 규칙으로 바꾸고 현업이 승인하게 해야 합니다.

근거원문의 HCP 테이블 예에서 기술 규칙을 모두 통과해도 지역·월별 점유율 합이 100%가 아니거나 전문과목과 맞지 않는 제품 처방이 섞이면 분석이 틀립니다. 그래서 에이전트는 Internal KB로 업무 규칙을 따로 제안합니다.

규칙의 주인을 한곳에 모으는 것이 출발점

흔히 이렇게 봅니다AI 자동화로 속도를 내려면 사람 승인 단계를 줄여야 한다.

저자는 이렇게 봅니다핵심 규칙과 업무 규칙은 언제나 SME가 승인하게 남겨 두고도 공수를 크게 줄일 수 있습니다. 사람은 규칙을 처음부터 쓰는 대신 제안을 검토하고 승인하는 데 집중합니다.

근거자동 승인을 고신뢰·저위험 규칙으로 한정한 상태에서 데이터셋당 공수가 약 30시간에서 4시간으로 줄었고, 제안의 20~35%는 사람이 고치거나 뒤집었습니다(회사 추정).

줄어든 것은 승인이 아니라 초안을 처음부터 쓰는 일

저자가 든 사례

HCP Product Performance 테이블: 한 테이블에서 세 종류의 점검이 나온다

상황: 의료 전문가별 제품 성과 테이블에는 HCP_ID, Specialty, Territory_ID, Product_ID, Prescription_Volume, Market_Share_Pct, Switch_Pct, Rating_Scale, Reporting_Month 9개 열이 있습니다.
한 일: 에이전트가 이상 점검(음수 전환율, 점유율 합 불일치, 처방량 급변, 제품 순위 불일치, 척도 밖 평점), 기술 규칙(HCP_ID 비null·비중복, 처방량 0 이상 숫자, 점유율·전환율 0~100, 날짜 형식, 지역·제품 ID의 참조 테이블 일치), 업무 규칙(지역·월별 점유율 합 100%, 전문과목에 맞는 제품 적격성, 적격 HCP만 타깃 세그먼트 포함)을 나눠 제안했습니다.
결과: 이 테이블 하나에 대한 처리 시간은 원문에서 밝히지 않았습니다.
연결: Context Assembly(프로파일·이상 탐지), Two Knowledge Bases(업무 규칙), Rule Modes와 Severity.

원문의 실제 사용 예를 재구성. 규칙 이름은 줄여 적음

NEXT UDP 운영 배포: 규칙 작성자에서 승인자로

상황: 세계 상위 20개 바이오제약사를 고객으로 둔 Indegene의 플랫폼에서 새 데이터셋마다 프로파일링, 규칙 정의, SQL 개발, 검증, 유지보수를 손으로 반복했습니다.
한 일: Data Quality Agent를 NEXT UDP의 독립 에이전트(데이터 수집, 품질, 오케스트레이션, 카탈로그, SQL Bot Generator) 가운데 하나로 운영에 넣었습니다.
결과: 규칙 정의·구현 약 30시간 → 4시간, 신규 테이블 등록 2~5영업일 → 2~4시간, 규칙 제안 정확도 80~90%, 수정 없는 채택 60~75%, SME 업무 관련성 평가 5점 만점에 4.0~4.5, 환각률 5~8% 미만(모두 회사 추정).
연결: Generate and Validate Code, Human Oversight와 Central Rule Repository.

모두 회사 추정치(Indegene 운영 배포). 빈 칸은 원문에 이전 값이 없음

기술 디테일: 품질 규칙 에이전트를 직접 만든다면

아래 필드명, 설정값, 기준은 실행 제안이자 가상 예시이며 Indegene이 밝힌 구현이 아닙니다. 원문에서 온 것은 따로 표시했습니다.

Context Assembly를 돌리려면 테이블 하나를 한 번의 생성 단위로 잡습니다. 입력은 여섯 덩어리를 고정된 순서로 넣습니다. 카탈로그 스키마, 열별 프로파일 요약(빈 값 비율, 고유값 수, 최소·최대, 상위 빈도값 10개, 정규식 패턴), 이상 탐지 결과, 기존 활성 규칙 목록, KB 검색 결과 상위 5~8건과 각 문서 ID입니다. 원본 행 전체는 넣지 않습니다. 원문의 metadata-first 프로파일링도 같은 생각으로, 메타데이터를 먼저 읽어 컴퓨트를 약 45~51% 줄였다고 밝혔습니다(회사 추정). 규칙 형식 설명, 표준 용어집처럼 매번 같은 부분은 프롬프트 앞쪽에 두고 Bedrock prompt caching을 걸면 캐시된 문맥의 입력 토큰 비용을 최대 90%까지 줄일 수 있습니다(원문 수치).

원문 수치: 캐시된 문맥 입력 토큰 비용 최대 90% 감소, metadata-first 프로파일링으로 컴퓨트 약 45~51% 감소(회사 추정)

규칙은 구조화 출력으로 받습니다. 자유 서술을 받지 않고 JSON 스키마를 강제합니다. 저장소 필드(규칙 ID, 이름, 종류, 열, 상태, 작성자, 생성일, 심각도, 버전)는 원문에 있는 항목이고, evidence와 confidence, route는 실행을 위해 덧붙인 가상 예시입니다. evidence에 KB 문서 ID나 프로파일 수치가 없으면 스키마 검증에서 떨어뜨립니다.

{
  "rule_id": "DQ-HCPPERF-017",
  "name": "territory_month_share_sum_100",
  "type": "business",
  "mode": "table_level",
  "columns": ["Territory_ID", "Reporting_Month", "Market_Share_Pct"],
  "severity": "critical",
  "definition": "같은 Territory_ID·Reporting_Month의 Market_Share_Pct 합은 100(허용 오차 ±0.5)",
  "evidence": [{"kb": "internal", "doc_id": "SOP-MKT-042", "section": "4.2"},
               {"profile": "sum_by_territory_month: 97.1~103.4"}],
  "confidence": 0.82,
  "route": "sme_review",
  "status": "proposed",
  "author": "dq-agent",
  "version": 1
}

신뢰도와 라우팅을 정하려면 같은 입력으로 3회 생성해(temperature 0~0.2) 세 번 모두 나온 규칙에 점수를 더 줍니다. 한 번만 나온 규칙은 신뢰도를 깎고 검토 큐로 보냅니다. 라우팅은 원문 원칙을 그대로 따릅니다. severity가 critical이거나 type이 business면 점수와 관계없이 SME로 보냅니다. 나머지는 예를 들어 0.85 이상이면 자동 승인, 그 아래면 데이터 엔지니어 검토로 보냅니다. 이 임계값은 가상 예시이므로, 첫 4주는 자동 승인을 끄고 사람 판정과 점수를 나란히 쌓은 뒤 정합니다.

코드 검증은 순서를 고정합니다. 생성한 SQL을 먼저 파서로 문법 점검하고, information_schema로 열 이름과 타입을 대조합니다. 그다음 표본 1만 행(가상 예시)에서 실행해 위반 건수가 0이거나 전체가 아닌지 봅니다. 위반이 100%면 규칙이나 SQL이 거꾸로 쓰였을 가능성이 큽니다. 마지막으로 생성 모델과 다른 모델에 규칙 정의와 SQL을 함께 주고 둘의 뜻이 같은지 판정하게 합니다. 원문의 Validation Agent가 이 자리입니다.

막히는 경우	증상	대응
업무 규칙의 근거 문서가 KB에 없음	`evidence`가 프로파일 수치뿐	업무 규칙 제안을 막고 SME에게 문서 요청 목록으로 전달
기존 규칙과 중복·충돌	같은 열에 범위가 다른 규칙 둘	생성 전에 활성 규칙을 문맥에 넣고, 저장 전 열·조건 비교로 차단
SQL이 표본에서 전부 위반	위반률 100%	부등호·단위(% 대 소수) 확인 후 재생성, 2회 실패 시 사람에게
심각도 과대·과소	Information으로 온 식별자 규칙	식별자·상업 지표 열은 critical 하한을 규칙으로 고정
사람이 제안을 그대로 승인	수정률 0%가 몇 주 지속	승인된 규칙 표본을 다른 검토자가 재심사
모델 교체 뒤 결과 변화	같은 테이블 제안이 크게 바뀜	모델 버전을 저장소에 기록, 교체 전 기존 테이블 20개 재생성 비교

현업 실행 디테일: 누가, 언제, 무엇을

원문은 데이터 스튜어드와 분석가가 흐름을 시작하고, 데이터 엔지니어와 스튜어드가 규칙을 검토·승인하며, 핵심·업무 규칙은 SME가 승인한다고 밝혔습니다. 아래 역할 표, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일
데이터 거버넌스 책임자	시범 도메인 선정, 자동 승인 허용 범위 결정, 최종 판정
데이터 스튜어드 2명	테이블 선택과 흐름 시작, 검토 큐 운영, 저장소 소유자 지정
데이터 엔지니어 1~2명	원본 연결, 기존 SQL 규칙 추출, 생성 코드 검증과 ETL 연결
현업 SME 2~3명(예: 영업 분석, 시장 조사)	용어집·SOP 제공, Critical·업무 규칙 승인, 업무 관련성 평가
AI 엔지니어 1명	KB 구성, 프롬프트·스키마, 신뢰도 점수와 로그
보안·컴플라이언스	개인정보 마스킹, 접근 권한, 감사 기록 확인

준비물. 시범 도메인의 테이블 10~20개, 그 테이블에 이미 걸린 품질 규칙(SQL 스크립트, 스프레드시트, 도구 설정에서 모두 추출), 업무 용어집과 데이터 사전, 지표 산식이 적힌 SOP, 최근 6개월 품질 장애 기록, 테이블당 지금 규칙 정의에 드는 시간 기록이 필요합니다. 기존 규칙 추출이 가장 오래 걸리므로 첫 주에 시작합니다.

기간	할 일	산출물
1~2주	기존 규칙 추출, 테이블 3개로 수작업 기준선 측정, 용어집·SOP를 KB에 적재	기존 규칙 목록, 테이블당 시간 기준선, KB 문서 목록
3주	원본 연결, 프로파일·이상 탐지, 규칙 제안과 코드 생성 연결	제안 규칙 JSON, 검증 로그
4~5주	병행 운영: 사람이 같은 테이블에 규칙을 따로 쓰고 제안과 비교, 자동 승인 끔	채택·수정·거절 비율, SQL 유효성, 심각도 일치율
6주	판정 회의, 자동 승인 범위와 다음 도메인 결정	진행·보완·중단 결정서

가상 예시 일정. 1~2주 준비, 3주 구축, 4~5주 병행 운영, 6주 판정

현업에 물을 것.

이 테이블로 내리는 결정은 무엇이고, 어떤 값이 틀리면 그 결정이 바뀌나요?
지표 산식(점유율, 전환율)은 어느 문서에 있고, 누가 최종 해석권을 갖나요?
지난 6개월 동안 품질 문제로 보고서를 다시 낸 적이 있다면 원인은 기술 규칙이었나요, 업무 규칙이었나요?
지금 규칙은 어디에 흩어져 있고, 소유자가 없는 규칙은 몇 개인가요?
자동 승인을 허용해도 되는 규칙은 어떤 종류이고, 절대 안 되는 규칙은 무엇인가요?

진행 판정 기준(예시). 원문이 밝힌 운영 수치를 비교 기준으로 씁니다. 병행 운영에서 수정 없는 채택률이 60% 이상, 스키마 기반 SQL 유효성이 90% 이상이고 테이블당 공수가 기준선보다 70% 이상 줄면 다음 도메인으로 넓힙니다. 채택률이 40~60%면 KB 문서를 보강해 2주 더 봅니다. 40% 미만이면 업무 문서가 부족한 것인지 프로파일 문맥이 부족한 것인지 나눠 다시 설계합니다. 어떤 경우에도 Critical·업무 규칙의 SME 승인은 유지합니다.

AX 적용 제언. 데이터 품질 규칙은 AI 과제 대부분의 앞단에 있어서, 이 사례는 제약 밖에서도 그대로 옮길 수 있습니다. 제조의 품질·설비 데이터, 유통의 판매·재고 데이터, 금융의 고객·거래 데이터 모두 기술 규칙과 업무 규칙이 따로 사는 구조가 같습니다. 순서는 셋입니다. 먼저 흩어진 기존 규칙과 SOP를 모아 KB를 만들고, 다음으로 승인 경로를 위험으로 나눠 SME 승인 대상을 정하고, 마지막에 에이전트를 붙입니다. 첫 도메인은 경영 보고에 쓰이고 업무 규칙이 많은 영역(영업 실적, 시장 점유율)이 좋습니다. 효과가 보이는 데다 SME가 검토에 나설 이유가 분명하기 때문입니다. 현업 스폰서는 그 보고서를 받는 사업부장이 맡는 편이 좋습니다.

원문 사례

항목	내용
원문	AWS 머신러닝 블로그, 2026.11.4 게재, Indegene과 공동 집필
저자	Shravan K S(Indegene 데이터 분석 시니어 매니저), Bhagyashree Chandak(AWS India 솔루션즈 아키텍트)
회사	Indegene(BSE 544172, NSE INDGN), 생명과학 업계의 영업·의학·R&D·안전성 업무 운영 파트너, 세계 상위 20개 바이오제약사가 고객
플랫폼	NEXT UDP, 독립 에이전트: Data Ingestion, Data Quality, Orchestration, Data Catalog, SQL Bot Generator
모델·프레임워크	Amazon Bedrock의 Claude Sonnet 4.5, Strands Agents, Bedrock AgentCore(runtime, Gateway, memory, Code Interpreter, Observability), Bedrock Guardrails, Bedrock Knowledge Bases
저장·실행	Aurora PostgreSQL pgvector, S3, DynamoDB, Redshift(주 원본), Snowflake(선택), Glue Data Catalog·crawler, Lambda, Step Functions, SQS·SNS·EventBridge
흐름	원본 선택 → 스키마 선택 → 프로파일 → 이상 탐지 → 규칙 관리 → 모드 선택 → 제안 → 검토·승인 → 코드 생성·검증 → 저장소
승인 원칙	규칙별 신뢰도 점수, 고신뢰·저위험만 자동 승인, Critical·업무 규칙은 항상 SME, 모든 결정 저장소 기록
성능	테이블 프로파일 약 100만 행 45~90초, 약 1,000만 행 2~5분, 규칙 생성 테이블당 20~45초, SQL 생성 규칙당 3~8초
규모	스키마 25~50개, 테이블 500~2,000개, 열 1만~5만 개, 저장소 규칙 1,000~1만 개
품질	제안 정확도 80~90%, 무수정 채택 60~75%, 수정·번복 20~35%, SQL 유효성 90~97%(스키마 근거)·80~90%(사용자 정의), 심각도 정확도 75~85%, SME 관련성 4.0~4.5/5, 환각률 5~8% 미만
효율	규칙 정의 약 30시간 → 4시간(약 85% 감소, 약 7배), 신규 테이블 2~5영업일 → 2~4시간, 수작업 SQL 작성 공수 60~80% 감소, 규칙 재사용 40~60%, 유지보수 공수 85% 감소
다음 단계	실패한 점검의 조치 추천, 반복되는 이상 패턴의 근본 원인 분석

핵심 개념

Data profiling: 열마다 빈 값 비율, 고유값 수, 범위, 자주 나오는 값과 패턴을 재서 데이터의 현재 상태를 요약하는 작업입니다.
Data steward: 특정 데이터 영역의 정의와 품질을 책임지고 규칙의 소유자 역할을 하는 담당자입니다.
HCP: Healthcare Professional. 의사·약사처럼 처방이나 의료 결정에 관여하는 전문가로, 제약 영업 데이터의 기본 단위입니다.
NPI: National Provider Identifier. 미국 의료 제공자에게 부여하는 10자리 숫자 식별번호입니다.
Switch %: 일정 기간에 다른 제품에서 이 제품으로, 또는 이 제품에서 다른 제품으로 처방이 옮겨 간 비율입니다.
pgvector: PostgreSQL에서 임베딩 벡터를 저장하고 유사도로 검색하게 해 주는 확장 기능입니다.
Prompt caching: 매 호출에 반복되는 프롬프트 앞부분을 모델 쪽에 저장해 두고 다시 쓰게 해 입력 비용과 지연을 줄이는 기능입니다.
Strands Agents: AWS가 공개한 오픈소스 에이전트 개발 프레임워크로, 모델 호출과 도구 사용 흐름을 코드로 정의합니다.

내 메모

TODO: 내 생각 추가

원문은 AWS 머신러닝 블로그의 「How Indegene is modernizing and scaling enterprise data quality in life sciences」(Shravan K S, Bhagyashree Chandak, 2026.11.4)입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 효과와 품질 수치는 모두 Indegene 운영 배포 기준의 회사 추정치입니다. HCP, Switch %, pgvector, Strands Agents, prompt caching의 뜻풀이는 일반적인 정의로 보탰습니다. JSON 예시, 신뢰도 라우팅 방식과 임계값, 검증 순서, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 아키텍처 그림과 전체 수치표는 원문 페이지에서 볼 수 있습니다.