China Construction Bank AskAudit: 온톨로지 감사 에이전트로 여신 감사 보고서를 며칠에서 10분 안으로

China Construction Bank(중국건설은행, CCB) 내부감사팀은 고객·여신·지표·규정의 관계를 온톨로지로 정리하고 그 위에서 에이전트가 데이터 조회, 규정 검색, 시각화를 차례로 조율하게 했습니다. 그 결과 여신 감사 보고서 초안 작성이 3~5일에서 5~10분으로 줄었다고 보고했습니다. 같은 구조를 옮기려면 모델을 고르기 전에 보고서 문장마다 데이터 행과 규정 조항을 붙이는 근거 구조, 그리고 감사인이 직접 만든 정답 세트부터 준비해야 합니다.

요약

CCB 내부감사팀은 수천 곳의 여신 고객을 100개가 넘는 지표로 살피고 그 결과를 규정에 비추어 해석해야 했습니다. 기존 BI(business intelligence, 정형 보고·대시보드 도구)는 정해진 화면을 보여 주는 데는 맞지만 감사인이 그때그때 한 고객을 파고드는 drill-down(상세 내역으로 내려가며 보기)이나 지표가 왜 나빠졌는지 따지는 attribution analysis(원인 분석)에는 손이 많이 갔습니다. 감사 빈도와 규모가 커질수록 결론마다 근거를 일관되게 남기기도 어려웠습니다. 은행은 내부 감사인용 AI 어시스턴트 AskAudit을 만들었습니다. LLM, RAG(retrieval-augmented generation, 문서를 검색해 답의 근거로 넣는 방식), 온톨로지·지식 그래프, AI 에이전트를 네 계층으로 쌓은 구조입니다. 코드 없이 분석 시나리오를 늘리는 Prompt Framework, LLM이 뽑아낸 온톨로지, 분석과 보고서 작성을 기능 단위로 나눈 Skill 층, 조회·검색·시각화를 조율하는 ReAct+Plan 에이전트가 차례로 놓입니다. 이 사례는 Gartner 2026 Eye on Innovation Awards 은행·투자 부문에 제출·소개됐고 사용자가 제공한 Greater China 사례집에 실렸습니다.

사례집이 밝힌 기업 보고 실적은 다음과 같습니다. 감사 보고서 초안 작성은 3~5일에서 5~10분으로 99% 줄었고 수시 분석 요청은 2분 안에 끝납니다. LLM 응답 지연은 5.18초에서 2.78초로 짧아졌고 종단간(end-to-end) 벤치마크 정확도는 86.73%에서 93.88%로 올랐습니다. 전문가 검증에서는 감사 지적 분류가 95%를 넘었고 신용위험 등급 판정은 약 75%였습니다. 사례집은 성과의 이유를 구조에서 찾습니다. 분석 결과가 규정에 고정된 근거와 함께 나오므로 감사인이 결론을 거슬러 올라가 확인할 수 있다는 설명입니다. 은행의 한 고위 관계자는 AskAudit이 모든 인사이트를 “traceable, auditable and grounded in expert knowledge” 상태로 만들었다고 평가했습니다. 공개 자료로는 CCB가 2026년 3월 발표한 2025년 실적에서 AI 대형 모델을 그룹 안 398개 시나리오에 적용했다고 밝힌 내용을 확인했습니다. AskAudit만 따로 다룬 공개 자료는 찾지 못했습니다. 아래에서는 네 계층이 각각 어떻게 작동하는지 풀고 한국 제조 대기업 감사실이 같은 구조를 구매 감사에 옮기는 방법을 덧붙였습니다.

핵심 메커니즘

사례집은 네 계층의 이름과 역할만 짧게 적었습니다. 아래 작동 방식은 각 기법의 일반적인 구조에 비추어 재구성했고 작은 예시는 모두 가상 예시입니다.

Prompt Framework: 코드 없이 감사 시나리오를 늘리는 틀

새 감사 질문 유형을 개발자가 코드를 고치지 않고 양식만 채워 추가하게 하는 틀입니다. 사례집 표현으로는 zero-code scenario extension입니다. 감사인이 목적, 대상 고객 범위, 쓸 지표, 참조할 규정, 산출 형식을 적으면 프레임워크가 이를 에이전트 지시문과 Skill 호출 조건으로 바꿉니다. 등록된 시나리오는 질문 메뉴에 올라가 다음 감사부터 다시 쓸 수 있습니다. 감사 주제가 해마다 바뀌고 요청이 많은 조직에 맞습니다. 지표 정의나 규정 연결이 아직 없는 주제라면 양식만으로는 돌아가지 않으므로 온톨로지 쪽을 먼저 채워야 합니다. 가상 예시로, 감사인이 “부동산 업종 여신 가운데 담보 비율이 떨어진 고객 점검”을 양식 다섯 칸으로 등록하면 같은 점검을 지점별로 반복 실행할 수 있습니다.

LLM-extracted Ontology: 고객·여신·지표·규정을 잇는 지도

온톨로지는 감사 대상의 개념(고객, 여신 건, 지표, 규정 조항, 감사 지적)과 그 사이의 관계를 정의한 스키마입니다. 지식 그래프는 그 스키마에 실제 데이터를 채운 결과물입니다. AskAudit은 이 온톨로지를 LLM으로 추출했습니다. 규정집, 지표 정의서, 데이터 사전을 LLM에 넣어 개념·관계·조건 후보를 뽑고 감사인이 검수한 뒤 그래프에 싣는 흐름이 일반적입니다. 질문이 들어오면 에이전트는 그래프에서 경로를 따라가 필요한 데이터와 관련 조항을 함께 찾습니다. 지표 100여 개와 규정 조항의 관계를 모델이 매번 짐작하지 않고 지도에서 찾게 되므로, 결론이 어떤 조항에 근거했는지가 구조로 남습니다. 규정과 지표가 적고 관계가 단순하면 RAG만으로도 충분할 수 있습니다.

Skill: 반복 분석을 정해진 부품으로 만든 층

Skill은 추이 분석, 동종 비교, 원인 분해, 차트 그리기, 보고서 단락 쓰기처럼 자주 하는 작업을 입력과 출력이 정해진 기능 단위로 묶은 층입니다. 에이전트는 질문에 맞는 Skill을 고르고 고객·기간·지표 같은 파라미터를 채웁니다. Skill은 정해진 쿼리와 계산을 실행해 표, 차트, 단락 초안을 표준 형식으로 돌려줍니다. 숫자는 LLM이 직접 계산하지 않고 Skill 결과를 인용하게 되므로 같은 질문에 같은 숫자가 나옵니다. 같은 분석이 고객만 바꿔 반복되는 감사 업무에 잘 맞고 한 번만 하는 탐색 분석에는 Skill을 만드는 비용이 더 클 수 있습니다.

ReAct+Plan Agent: 계획을 세우고 한 단계씩 확인하며 실행

ReAct(reasoning+acting)는 생각, 도구 실행, 결과 관찰을 반복하며 다음 행동을 정하는 에이전트 방식입니다(Yao 외, 2022). AskAudit은 여기에 전체 단계를 먼저 짜는 Plan을 더했습니다. 질문이 들어오면 Plan이 조회, 규정 검색, 분석, 시각화, 서술 순서로 단계 목록을 만들고 단계마다 ReAct 루프가 Skill과 검색을 호출해 결과를 확인합니다. 마지막에 단계별 결과를 근거와 함께 엮어 보고서를 만듭니다. 수시 분석은 질문마다 필요한 단계가 달라 고정 파이프라인으로 처리하기 어렵습니다. Plan은 단계 누락을 줄이고 ReAct는 중간 결과를 보고 다음 행동을 고칩니다. 사례집은 이 층이 데이터 조회, 지식 검색, 시각화, 규정에 고정된 인사이트를 조율한다고 적었습니다.

사례 재구성

AskAudit: 여신 감사 분석과 보고서 작성

구분	내용
상황	CCB 내부감사팀은 수천 곳 고객과 100개 이상 지표를 놓고 여러 출처의 데이터를 분석하고 규정을 해석해야 했습니다. 기존 BI로는 수시 drill-down과 원인 분석이 어려웠고 근거가 분명한 결론을 대규모로 일관되게 내기도 어려웠습니다.
한 일	LLM, RAG, AI 에이전트, 온톨로지, 지식 그래프를 결합한 감사인용 어시스턴트 AskAudit을 만들었습니다. Prompt Framework, LLM-extracted Ontology, Skill 기반 분석·보고, ReAct+Plan 에이전트의 4계층입니다. 사례집이 꼽은 기술 범주는 AI Agents, Domain-Specific Language Models, LLMs, Data & Analytics, GenAI, Reasoning Models입니다.
결과	보고서 초안 3~5일에서 5~10분(99% 단축), 수시 분석 2분 미만, LLM 응답 5.18초에서 2.78초, 종단간 벤치마크 86.73%에서 93.88%, 전문가 검증은 감사 지적 분류 95% 초과·신용위험 등급 약 75%(모두 기업 보고 실적). 도입 기간, 사용자 수, 사용한 모델 이름은 사례집에서 밝히지 않았습니다.
연결	온톨로지가 규정 근거를 구조로 남기고 Skill이 숫자를 일관되게 만들며 ReAct+Plan이 질문마다 다른 단계를 조율합니다. 네 메커니즘이 모두 한 사례 안에서 맞물립니다.

기술 디테일: 우리 감사 데이터로 첫 프로토타입을 만들려면

아래는 사례집에 없는 내용으로, 같은 구조를 실제로 돌릴 때 필요한 것을 정리했습니다. 필드 이름과 설정값은 가상 예시입니다.

온톨로지는 규정 조항과 데이터 컬럼을 잇는 데서 시작합니다(LLM-extracted Ontology). 규정 문서는 조항 단위로 잘라 LLM에 넣고 조항마다 아래처럼 구조화 출력을 받습니다. temperature는 0으로 두고 같은 조항을 3회 추출해 2회 이상 나온 관계만 후보로 남기면 실행마다 달라지는 추출을 걸러 낼 수 있습니다. 후보는 감사인이 검수합니다. 처음 200개 조항은 전수, 이후에는 10%를 표본으로 봅니다. column_ref를 데이터 사전의 실제 컬럼과 대조해 못 찾은 것은 자동으로 검수 대기열에 보냅니다.

{
  "clause_id": "CR-4.2.3",
  "source_doc": "여신관리규정_2026.pdf", "page": 37,
  "subject_class": "CreditFacility",
  "indicator": "collateral_ratio",
  "column_ref": "loan_master.coll_ratio",
  "condition": "<", "threshold": 0.6, "unit": "ratio",
  "action_required": "재평가 및 보고",
  "effective_from": "2026-01-01"
}

Skill은 함수 명세로 정의합니다(Skill). Skill마다 이름, 설명, 입력 파라미터와 타입, 실행할 쿼리 템플릿, 출력 스키마, 기본 차트 유형을 둡니다. 에이전트에게는 명세만 보여 주고 SQL은 Skill 안에서만 실행되게 하면 모델이 임의의 쿼리를 만들 일이 없습니다. 첫 파일럿은 10~15개로 시작합니다. 추이(trend), 동종 비교(peer_compare), 원인 분해(attribution), 기준 위반 목록(breach_list), 차트(chart), 단락 작성(draft_section) 정도면 대부분의 여신 감사 질문을 덮습니다. 출력에는 항상 결과 행의 ID 목록(row_ids)을 담아 근거로 넘깁니다.

에이전트 루프에는 단계 상한과 근거 필드를 둡니다(ReAct+Plan). Plan 출력은 {"steps":[{"id":1,"type":"query|retrieve|analyze|visualize|write","skill":"trend","args":{...}}]} 형식의 JSON으로 받고 한 질문의 단계는 최대 10개로 제한합니다. 넘으면 질문을 나누라고 감사인에게 되묻습니다. 최종 보고서는 문장(claim) 단위로 {"text":..., "evidence":[{"type":"data","row_ids":[...]},{"type":"clause","clause_id":"CR-4.2.3"}]}를 붙여 내게 하고 아래 게이트에서 검사합니다. 근거가 빈 문장은 한 번 다시 생성하고 그래도 없으면 ‘확인 필요’ 표시를 달아 감사인에게 넘깁니다.

평가는 종단간 벤치마크와 과제별 전문가 검증을 나눠 둡니다. 사례집도 두 종류를 따로 보고했습니다. 종단간 벤치마크는 과거 감사 건에서 질문 100~200개를 뽑아 정답 숫자, 정답 결론, 근거 조항을 함께 적은 세트로 만듭니다. 질문마다 3회 실행해 결과가 다르면 편차로 기록합니다. 전문가 검증은 과제별로 따로 잽니다. 사례집에서 분류 과제와 등급 판정 과제의 검증 결과가 다르게 나온 것처럼, 우리 쪽에서도 과제마다 자동화 수준을 다르게 정하는 근거로 씁니다. 가상 기준을 들면, 검증 결과가 높은 분류 과제는 초안 자동 작성과 표본 검토로 돌리고 판단 폭이 큰 등급 판정은 AI가 근거와 후보 등급을 내고 감사인이 정합니다.

실패는 세 곳에서 자주 납니다. 첫째, 규정이 개정됐는데 그래프에 옛 조항이 남아 있으면 틀린 근거가 붙습니다. 조항마다 effective_from과 effective_to를 두고, 근거 게이트에서 감사 기준일에 유효한 조항만 통과시킵니다. 둘째, 고객이나 협력사 이름이 시스템마다 달라 같은 대상이 두 노드로 갈라집니다. 사업자등록번호 같은 고유 키로 먼저 묶고, 키가 없는 건은 이름 유사도 후보를 감사인이 확정합니다. 셋째, 질문이 모호하면 Plan이 엉뚱한 Skill을 고릅니다. 기간, 대상, 지표 가운데 하나라도 비어 있으면 실행 전에 되묻게 합니다.

응답 속도는 단계별로 재서 줄입니다. 사례집은 LLM 응답 지연이 5.18초에서 2.78초로 줄었다고만 밝혔고 어떻게 줄였는지는 밝히지 않았습니다. 직접 돌릴 때는 Plan, Skill 실행, 검색, 서술 단계마다 시간을 로그로 남기고 가장 긴 단계부터 손봅니다. 보통은 이렇게 줄입니다. 계획 수립과 Skill 선택은 작은 모델에 맡깁니다. 자주 찾는 규정 조항의 검색 결과는 캐시합니다. 서로 의존하지 않는 Skill 호출은 동시에 실행합니다.

넣어야 할 데이터는 다섯 묶음입니다. 고객 마스터와 여신 원장(또는 제조사라면 협력사 마스터와 구매 원장), 지표 정의서와 계산식, 현행 규정집과 개정 이력, 과거 감사 보고서와 지적 사례, 감사 분류 체계입니다. 과거 보고서는 정답 세트와 보고서 문체의 기준을 함께 만들어 줍니다. 모든 접근은 읽기 전용 계정으로 열고 개인 정보가 담긴 컬럼은 마스킹한 뷰로 제공합니다.

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

여기서는 한국 제조 대기업 감사실이 이 구조를 협력사 구매 감사에 옮기는 경우를 가상 예시로 듭니다. 협력사 수천 곳을 단가, 납기, 계약 조건, 거래 집중도 같은 지표 수십~100여 개로 보고 구매 규정에 비추어 판단한다는 점에서 CCB의 여신 감사와 문제 구조가 같습니다.

역할	인원	하는 일
감사실장	1명	스폰서. 범위 승인, 8주 차 진행 판정
감사 실무 리드	2~3명	시나리오 정의, 정답 세트 작성, 온톨로지 검수, 초안 품질 평가
구매·준법 규정 담당	1명	조항 해석이 갈리는 곳 확정, 규정 개정 이력 제공
데이터 엔지니어	1~2명	구매 원장·협력사 마스터 읽기 전용 뷰, Skill 쿼리 작성
AI 엔지니어	1~2명	온톨로지 추출, 에이전트·근거 게이트 구현, 벤치마크 실행
AX 추진 PM	1명	일정·산출물 관리, 보안 검토 일정 조율

시작 전 준비물은 지난 2년 감사 보고서 20~30건, 구매 규정집 최신본과 개정 이력, 지표 정의서, 데이터 사전, 읽기 전용 계정 발급 승인입니다.

기간	할 일	산출물
1~2주	감사 주제 하나(예: 단가 이상 협력사) 선정, 과거 보고서에서 질문 50개와 정답·근거 작성	정답 세트 v1, 시나리오 3개
3~4주	규정 조항 추출(3회 실행), 감사인 검수, 컬럼 연결	온톨로지 v1, 미연결 목록
5~6주	Skill 12개 구현, ReAct+Plan 루프와 근거 게이트 연결	작동하는 프로토타입, 단계별 시간 로그
7~8주	진행 중인 감사 2~3건에서 기존 방식과 나란히 초안 작성, 벤치마크 3회 실행	비교 보고서, 진행 판정

인터뷰에서 감사 실무자에게 물을 질문은 다음과 같습니다. 보고서 한 건을 쓸 때 가장 시간이 많이 드는 단계는 어디인가. 보고서 문장 하나가 근거로 삼는 데이터는 어느 시스템의 어느 표인가. 같은 조항을 사람마다 다르게 해석한 적이 있는가. 감사 지적은 어떤 분류 체계로 나누는가. AI가 초안을 내더라도 반드시 감사인이 정해야 하는 판단은 무엇인가.

진행 판정 기준(가상 예시)은 네 가지로 둡니다. 벤치마크 정확도가 85% 이상이면 범위를 넓히고 그 아래면 온톨로지와 Skill을 보완합니다. 보고서 초안의 모든 문장에 근거가 붙어야 합니다(근거 연결률 100%). 감사인이 초안을 고치는 데 드는 시간이 기존 작성 시간의 절반 이하여야 합니다. 파일럿에 참여한 감사인 5명 가운데 4명 이상이 다음 감사에도 쓰겠다고 답해야 합니다.

감사는 첫 에이전트 과제로 고르기 좋습니다. 데이터를 읽기만 하므로 운영 시스템을 건드릴 위험이 작고 근거를 남기는 문화가 이미 있으며 과거 보고서가 그대로 정답 세트가 됩니다. 감사실에서 만든 협력사·계약·규정 온톨로지는 구매 부서의 단가 점검, 준법팀의 거래 모니터링, 리스크팀의 협력사 평가에 다시 쓸 수 있습니다. 순서는 구매 감사에서 시작해 경비 감사, 재고 감사로 넓히는 편이 데이터 준비 부담이 적습니다. CFO와 감사위원회에는 시간 단축만이 아니라 벤치마크 정확도와 과제별 검증 결과를 함께 보고해, 어디까지 자동화하고 어디서 사람이 정하는지를 처음부터 합의해 둡니다.

원문 사례

항목	내용
회사	China Construction Bank(중국건설은행), 베이징
사례명	AskAudit: AI Assistant for Auditors
부문	Gartner 2026 Eye on Innovation Awards, Banking and Investing (제출·소개 사례)
사용자	내부감사팀(감사인)
문제	수천 고객·100개 이상 지표의 다중 출처 데이터 분석과 규정 해석, BI의 수시 drill-down·원인 분석 제약, 근거 있는 결론의 대규모 일관성
구조	Prompt Framework(zero-code 시나리오 확장) · LLM-extracted Ontology · Skill 기반 분석·보고 · ReAct+Plan Agent
핵심 기술	AI Agents, Domain-Specific Language Models, LLMs, Data & Analytics, GenAI, Reasoning Models
보고 실적	보고서 3~5일 → 5~10분(99% 단축), 수시 분석 2분 미만, 응답 5.18초 → 2.78초, 종단간 86.73% → 93.88%, 전문가 검증 분류 95% 초과·신용위험 등급 약 75%
공개 자료	CCB 2025년 실적 발표(2026.03.27): AI 대형 모델 누적 398개 시나리오 적용. AskAudit 개별 공개 자료는 확인하지 못함

핵심 개념

BI (business intelligence)

정해진 지표를 표와 대시보드로 보여 주는 정형 분석 도구.

drill-down

합계에서 지점, 고객, 거래 단위로 내려가며 세부를 보는 분석.

attribution analysis

지표 변화를 요인별로 나눠 무엇이 얼마나 영향을 줬는지 따지는 분석.

RAG

질문과 관련된 문서를 먼저 찾아 모델 입력에 넣고 그 문서를 근거로 답하게 하는 방식.

end-to-end benchmark

질문부터 최종 답까지 전체 과정을 정답 세트로 채점하는 평가.

expert validation

현업 전문가가 AI 결과를 직접 보고 맞는지 판정한 결과.

Domain-Specific Language Model

특정 업종이나 업무 데이터에 맞춰 학습하거나 조정한 언어 모델.

Reasoning Model

답하기 전에 중간 추론 단계를 거치도록 만든 모델.

내 메모

TODO: 내 생각 추가

근거: 사용자가 제공한 Gartner 2026 Eye on Innovation Awards Greater China 사례 자료(China Construction Bank, AskAudit: AI Assistant for Auditors, Banking and Investing, 슬라이드 26)와 확인한 공개 자료인 중국신문망의 CCB 2025년 실적 보도(https://www.chinanews.com.cn/cj/2026/03-28/10594428.shtml)입니다. Gartner 은행·투자 부문 페이지(https://www.gartner.com/en/about/awards/eye-on-innovation/banking-investing)에서는 2026년 수상 결과를 확인하지 못해 이 노트는 제출·소개된 사례로 적었습니다. AskAudit을 직접 다룬 추가 공개 자료는 확인하지 못했습니다. 요약·사례 재구성·원문 사례 표는 사례 자료의 내용을 AX Review가 다시 정리했고 ReAct 설명은 Yao 외(2022), ‘ReAct: Synergizing Reasoning and Acting in Language Models’(arXiv 2210.03629)를 참고했습니다. 핵심 메커니즘의 작동 방식, 기술·현업 디테일, JSON 예시, 일정·판정 기준, 인포그래픽과 표는 새로 작성했으며 숫자와 이름은 사례집 수치를 뺀 나머지가 모두 가상 예시입니다.