Fix the Core First: 보험사 Encova가 코어 30여 개를 2개로 줄여 AI에 대비한 방법
미국 보험사 Encova는 인수로 16개 회사·26개 주에 흩어진 코어 시스템 30여 개를 정리해 지금은 2개 플랫폼으로 운영합니다. 기존 시스템을 잇지 않고 새로 구축했고, 31쪽 10년 비전을 12개월 이하 목표 350~400개로 쪼개 관리했습니다. Aventum·Amynta·Accelerant 사례와 함께 AI보다 코어와 데이터를 먼저 고친 방법을 정리했습니다.
AI 과제마다 낡은 코어 시스템을 돌아가야 하는 보험사는 파일럿을 늘려도 속도가 나지 않습니다. Encova는 코어 시스템 30여 개를 2개 플랫폼으로 줄인 뒤에야 과거의 운영 문제를 먼저 풀지 않고 AI를 받아들일 수 있게 됐습니다. 따라 하려면 목적지를 글로 먼저 쓰고, 공통화할 것과 지킬 것을 가르고, 현업과 IT를 한 팀으로 묶어야 합니다.
요약
Insurance Business의 Chris Davis는 보험사 리더들이 AI 이전에 레거시 코어를 어떻게 고쳤는지 세 편 연재로 다뤘고, 이 노트는 그 첫 편을 정리합니다. 중심 사례는 오하이오주 콜럼버스의 Encova Insurance입니다. 인수로 성장하면서 16개 회사가 26개 주에서 각자 정체성을 유지했고, 인프라 위에 인프라가 쌓였습니다. 최고전략책임자 John Kessler는 이 상태를 기술 부채가 깊게 쌓인 비대한 조직으로 표현합니다. Encova는 standardize(표준화), modernize(현대화), rationalize(합리화, 겹치는 시스템 정리) 세 원칙으로 코어 시스템 30여 개를 정리했습니다. 손해보험 계열은 Guidewire Insurance Suite로 옮겼고, 기존 시스템을 잇는 대신 이후 업무를 모두 새 코어에서 시작했습니다. 런던의 Aventum Group은 자체 플랫폼 ATOMX를 만들었고, Amynta Group은 사업마다 지켜야 할 차이를 남겼습니다.
그 결과 Encova는 지금 코어 플랫폼 2개로 움직입니다. Kessler는 덕분에 과거의 운영 문제를 먼저 해결하지 않고도 AI를 받아들일 수 있다고 말합니다. 반대로 인프라가 겹겹이 쌓인 보험사는 AI 과제를 할 때마다 코어를 우회하는 작업부터 해야 합니다. 원문은 이 차이를 세 가지 규율로 요약합니다. 벤더를 고르기 전에 목적지를 글로 쓰고, 무엇을 표준화하고 무엇을 지킬지 정하고, IT 프로젝트가 아니라 통합 팀으로 움직이는 것입니다. Accelerant의 Aaron DiCaprio는 같은 이야기를 데이터 쪽에서 합니다. 파편화된 데이터는 AI가 고쳐 주지 않으니 수집, 표준화, 검증, 이해의 기반부터 갖춰야 한다는 것입니다. 아래에서는 이 원칙을 메커니즘으로 풀고, 실제로 진단과 정비를 시작할 때 필요한 기술·현업 디테일을 덧붙입니다.
핵심 메커니즘
Human glue: 시스템 사이를 사람이 메우는 비용
Aventum의 CTO Hasani Jess가 쓴 표현입니다. 처음부터 서로 연결되도록 설계되지 않은 시스템 사이에서 직원이 같은 값을 두 번 입력하거나 파일을 손으로 옮기는 일을 말합니다. 입력은 한 시스템의 결과, 처리는 사람의 재입력과 이관, 출력은 다른 시스템의 입력입니다. 인수로 커진 보험사일수록 이런 지점이 많습니다. Amynta의 Anthony Slimowicz는 전통 보험사 상당수가 여전히 녹색 화면(green-screen) 백엔드를 쓰고, 그 둘레에 쓰기 편한 프런트엔드를 덧붙여 왔다고 설명합니다. 화면이 새로워도 뒤에서 사람이 메우는 구조는 그대로라는 뜻입니다. AI 과제에서는 이 지점이 곧 데이터가 끊기는 지점이므로, 정비 대상을 찾을 때 가장 먼저 셉니다. 가상 예시로, 청약 시스템에 넣은 사업장 주소를 보험료 시스템에 다시 치는 일이 하루 수십 건이면 그 연결이 첫 정리 대상입니다.
Standardize · Modernize · Rationalize: Encova의 세 원칙
Encova가 코어 시스템 30여 개를 정리할 때 쓴 기준입니다. Standardize는 같은 업무를 회사마다 다르게 처리하던 방식을 하나로 맞추는 일입니다. Modernize는 낡은 코어를 새 플랫폼으로 옮기는 일이고, Rationalize는 같은 기능을 하는 시스템을 줄이는 일입니다. 세 원칙을 함께 쓰는 이유는 순서에 있습니다. 업무 방식이 하나로 맞춰져야 옮길 대상이 줄고, 대상이 줄어야 새 플랫폼으로 옮기는 범위가 감당할 만해집니다. 인수가 여러 번 쌓인 회사, 같은 상품을 지역이나 법인마다 다른 시스템에서 파는 회사에 맞습니다. 사업 성격이 정말 다른 회사를 무리하게 한 틀에 넣을 때는 아래 Amynta식 판별을 먼저 거칩니다.
Greenfield와 net new: 옛 시스템을 잇지 않는 결정
Kessler는 Encova의 방식을 진짜 greenfield(빈 땅에 새로 짓기) 접근이라고 부르고, 이후의 모든 일을 net new(기존 것을 이어 쓰지 않고 새로 만든 것)로 했다고 설명합니다. 흔한 대안은 옛 코어를 살려 두고 그 위에 연결 계층과 새 화면을 붙이는 방식입니다. 이 방식은 초기 비용이 작지만 연결 지점과 human glue를 그대로 남깁니다. Greenfield는 되돌아갈 길을 일부러 없애 조직이 새 플랫폼에 집중하게 만듭니다. Encova는 손해보험 계열의 새 코어로 Guidewire Insurance Suite를 골랐습니다. 이 결정은 정비 범위가 넓고 경영진이 장기 비전을 문서로 약속한 경우에 맞습니다.
Written destination: 벤더보다 목적지를 먼저 쓴다
원문이 꼽은 첫 규율은 벤더를 고르기 전에 목적지를 글로 쓰는 것입니다. Encova의 당시 CEO는 10년 뒤 회사의 모습을 31쪽 문서로 썼고, 실행에 앞서 16개 계열사 직원들에게 직접 읽어 줬습니다. 이 비전은 10개 전략 방향으로 나뉘고, 다시 350~400개 목표로 쪼개졌습니다. 목표 하나의 기간은 12개월 이하입니다. 입력은 10년짜리 문장, 처리는 방향과 목표로의 분해, 출력은 1년 안에 끝나는 일 단위입니다. 이렇게 쪼개 두면 코어 교체처럼 몇 년 걸리는 일도 매년 끝난 목표와 남은 목표로 진척을 셀 수 있습니다. 목적지 문서 없이 벤더 데모부터 보면 기능 비교가 기준이 되고, 회사가 바꾸려는 모습은 뒤로 밀립니다.
Standardize or protect: 진짜 다른가, 습관인가
Amynta의 Slimowicz가 내놓은 판별 질문입니다. 어떤 사업의 요구가 정말 다른지, 아니면 그 차이가 그저 습관인지를 묻습니다. 그가 든 예는 근로자 재해보상(workers’ comp), 보증보험(surety), 무역신용(trade credit)처럼 요구가 실제로 다른 사업입니다. 이런 사업은 공통 플랫폼에 억지로 넣지 않고 보존합니다. 차이가 습관뿐이면 표준화합니다. Slimowicz는 인수 뒤 정문에 자기 브랜드를 걸고 자기 시스템을 강요하면, 애초에 돈을 주고 산 문화와 전문성을 잃는다고 경고합니다. MGA(Managing General Agent, 보험사 권한을 위임받아 인수·영업하는 대리점)의 경쟁력은 플랫폼이 아니라 판단에 있다는 것이 Amynta의 관점입니다.
Integrated teaming: IT 프로젝트가 아니라 통합 팀
Encova는 조직의 모든 분야에서 리더를 모아 하나의 통합 프로젝트 팀을 꾸렸습니다. Kessler가 밝힌 운영 원칙은 모든 일이 통합 팀을 거쳐 사업과 따로 놀지 않게 하는 것입니다. IT 프로젝트 방식에서는 IT가 요건을 받아 만들고 현업은 끝에 검수합니다. 통합 팀에서는 업무 방식을 표준화할지, 어떤 차이를 지킬지 같은 결정을 설계 단계에서 현업 리더가 함께 내립니다. 코어 교체는 업무 방식 변경과 같은 일이라, 현업이 결정에 빠지면 standardize 원칙이 종이에만 남습니다.
Data before AI: 수집·표준화·검증·이해가 먼저
Accelerant의 미국 프로그램 총괄 Aaron DiCaprio는 AI가 파편화되고 일관성 없는 데이터를 고쳐 주지 않는다고 말합니다. 보험사는 먼저 데이터를 받아들이고(ingest), 표준화하고(standardize), 검증하고(validate), 이해하는(understand) 인프라를 갖춰야 합니다. 입력은 여러 시스템과 외부에서 들어오는 원천 데이터, 처리는 형식과 코드를 맞추고 규칙으로 오류를 거르는 과정, 출력은 출처와 뜻을 아는 데이터입니다. AI 모델은 그 위에 놓입니다. 코어를 2개로 줄인 Encova가 AI를 바로 받을 수 있다고 말하는 이유도 같은 데서 나옵니다. 데이터가 나오는 곳이 적을수록 이 네 단계를 거칠 대상도 줄어듭니다.
통념과 다른 주장
흔히 이렇게 봅니다AI 파일럿을 먼저 띄우고, 레거시 코어는 연결 계층으로 우회하면 됩니다.
저자는 이렇게 봅니다코어를 먼저 정리한 회사만 AI 과제마다 코어를 돌아가는 일을 피할 수 있습니다.
근거Encova는 30여 개 코어를 2개 플랫폼으로 줄인 뒤 과거의 운영 문제를 먼저 풀지 않고 AI를 받을 수 있게 됐고, 인프라가 겹친 보험사는 매 과제마다 우회 작업을 해야 한다고 원문은 대비합니다.
흔히 이렇게 봅니다AI가 지저분한 데이터를 알아서 정리해 줍니다.
저자는 이렇게 봅니다파편화된 데이터는 AI가 고치지 못하며, 수집·표준화·검증·이해의 기반이 먼저입니다.
근거Accelerant의 DiCaprio가 이 순서를 직접 밝혔습니다.
흔히 이렇게 봅니다인수한 회사는 인수자의 시스템으로 빨리 통일하는 것이 효율적입니다.
저자는 이렇게 봅니다요구가 진짜 다른 사업은 보존하고, 차이가 습관인 곳만 표준화해야 합니다.
근거Amynta의 Slimowicz는 시스템을 강요하면 인수 대가로 얻은 문화와 전문성을 잃는다고 보고, 산재·보증·무역신용을 요구가 다른 사업으로 듭니다.
저자가 든 사례
Encova: 코어 30여 개를 2개 플랫폼으로
| 구분 | 내용 |
|---|---|
| 상황 | 인수로 16개 회사·26개 주가 각자 정체성을 유지, 인프라 위에 인프라가 쌓여 기술 부채가 깊어짐 |
| 한 일 | standardize·modernize·rationalize 세 원칙으로 코어 30여 개 정리, 손해보험은 Guidewire Insurance Suite로 새로 구축, 모든 분야 리더로 통합 프로젝트 팀 구성. 31쪽 10년 비전을 10개 방향·350~400개 목표로 분해 |
| 결과 | 코어 플랫폼 2개로 운영. 과거의 운영 문제를 먼저 풀지 않고 AI를 받을 수 있음. 기간과 비용은 원문에서 밝히지 않음 |
| 연결 | Standardize · Modernize · Rationalize, Greenfield, Written destination, Integrated teaming |
Kessler는 이 결정을 “We burned the boats”라는 말로 요약했습니다. 되돌아갈 배를 없앴다는 뜻입니다.
Aventum: 점 솔루션을 잇지 않고 ATOMX를 직접 개발
| 구분 | 내용 |
|---|---|
| 상황 | 연결되지 않은 시스템 사이를 이중 입력과 수작업 이관(human glue)이 메움 |
| 한 일 | 점 솔루션을 이어 붙이는 대신 ATOMX 플랫폼을 사내에서 개발. 외부 파트너 팀이 조직 안에 들어와 함께 일함 |
| 결과 | 지식재산(IP)을 회사가 보유. Jess는 규제 산업에서 빠르게 움직이는 데 따로 어려움이 있다고 언급. ATOMX의 기능 범위는 원문에서 밝히지 않음 |
| 연결 | Human glue |
Amynta: 지킬 것과 공통화할 것을 가른다
| 구분 | 내용 |
|---|---|
| 상황 | MGA와 특종 위험 사업을 여럿 운영 |
| 한 일 | 무엇을 현대화하거나 공통 플랫폼으로 옮기고 무엇을 각 사업의 고유함으로 남길지 구분 |
| 결과 | 요구가 다른 사업(산재·보증·무역신용)은 보존하는 원칙. 인수 뒤 시스템 강요를 경계 |
| 연결 | Standardize or protect |
Accelerant: AI 앞에 데이터 인프라
| 구분 | 내용 |
|---|---|
| 상황 | 보험사 데이터가 파편화되고 일관성이 없음 |
| 한 일 | 데이터를 수집·표준화·검증·이해하는 인프라를 먼저 갖춰야 한다는 원칙 |
| 결과 | 구체적 수치와 단계별 절차는 원문에서 밝히지 않음 |
| 연결 | Data before AI |
기술 디테일: 코어 정비를 AI 준비로 연결하려면
아래 스키마·설정값·기준은 원문에 없는 내용으로, 실제로 진단과 정비를 돌릴 때 필요한 것을 새로 정리한 가상 예시입니다.
시스템 카탈로그를 만들려면 (Standardize · Modernize · Rationalize, Standardize or protect와 연결) 정비 갈래를 정하기 전에 코어와 주변 시스템을 한 줄씩 적은 카탈로그를 만듭니다. 계열사 IT 담당자에게 같은 양식을 돌리고, LLM은 담당자가 보낸 운영 문서와 인터페이스 명세를 읽어 빈칸 후보를 채우는 데만 씁니다. 출력은 JSON으로 받고, 모델이 채운 칸은 source: "llm"으로 표시해 담당자가 확인한 칸과 구분합니다.
{
"system_id": "SYS-017",
"entity": "계열사 C",
"lines": ["상업용 재산", "배상책임"],
"function": "policy_admin",
"platform_age_years": 22,
"interfaces": [{"to": "SYS-021", "method": "batch_file", "manual_rekey": true}],
"line_need_differs": "habit",
"decision": "rationalize",
"evidence": [{"field": "line_need_differs", "source": "interview", "by": "상품 리드", "date": "2026-11-20"}]
}function은 policy_admin, billing, claims, rating, document, data_warehouse 중 하나로 고정합니다. line_need_differs는 Amynta식 판별 결과로 differs 또는 habit만 허용하고, differs로 적으려면 evidence에 현업 인터뷰 근거가 한 건 이상 있어야 합니다. decision은 replace, rebuild, protect, rationalize 네 값입니다. 같은 문서를 모델에 세 번 돌려 function 값이 갈리는 시스템은 자동 채움에서 빼고 담당자 인터뷰 목록으로 넘깁니다.
human glue를 세려면 (Human glue와 연결) interfaces[].manual_rekey가 true인 연결마다 하루 건수와 건당 처리 시간을 잽니다. 가능하면 두 시스템의 입력 로그에서 같은 계약번호가 짧은 간격으로 두 번 생성된 기록을 찾아 자동으로 셉니다. 로그가 없으면 담당자 2~3명에게 2주 동안 수기 집계를 받습니다. 이렇게 모은 표가 정비 우선순위와 AI 과제 후보 목록을 함께 만듭니다. 이중 입력이 많은 연결은 데이터가 끊기는 곳이기도 해서, 그 연결을 남겨 둔 채 AI를 붙이면 모델이 두 시스템 중 어느 값을 믿을지부터 정해야 합니다.
검증 계층을 두려면 (Data before AI와 연결) 새 코어든 남겨 둔 시스템이든, AI가 읽는 데이터는 같은 검증 계층을 거치게 합니다. 형식 검사(날짜·코드 형식), 참조 검사(계약과 고객이 서로 연결되는지), 업무 규칙(보험기간과 보험료가 맞는지), 출처 기록(어느 시스템에서 언제 왔는지) 네 가지를 둡니다. 실패한 레코드는 지우지 않고 격리 테이블로 보내 사유 코드를 붙입니다. AI 파일럿은 대상 데이터의 검증 통과율이 정한 기준(예: 98%)을 넘긴 업무부터 엽니다.
목표를 추적 가능한 데이터로 두려면 (Written destination과 연결) 350~400개 목표를 문서가 아니라 표로 관리합니다. 필드는 objective_id, direction_id(10개 전략 방향 중 하나), owner, start, end, systems_touched(카탈로그의 system_id 목록), done_criteria입니다. end - start가 12개월을 넘으면 입력을 막아 목표를 다시 쪼개게 합니다. systems_touched로 카탈로그와 이어 두면 시스템 하나를 폐기할 때 영향을 받는 목표가 바로 보입니다.
greenfield 전환 중 AI를 붙일 때는 (Greenfield와 연결) 옛 코어에 AI를 직접 붙이지 않고, 새 코어로 넘어온 업무에만 붙입니다. 옛 코어 데이터가 꼭 필요하면 읽기 전용 사본을 검증 계층에 통과시켜 쓰고, 옛 코어에 다시 쓰는 연결은 만들지 않습니다. 새 연결이 생기면 net new 원칙이 무너지기 때문입니다.
현업 실행 디테일: 누가, 언제, 무엇을
아래 역할과 일정은 원문에 없는 내용으로, 인수로 커진 보험사나 금융 그룹이 같은 정비를 시작할 때 필요한 것을 정리한 가상 예시입니다.
| 역할 | 하는 일 | 산출물 |
|---|---|---|
| CEO | 목적지 문서 작성과 전 계열사 공유 | 10년 비전 문서 |
| 전략책임자 | 비전을 전략 방향과 12개월 이하 목표로 분해 | 목표 표 |
| 통합 팀(상품·언더라이팅·보상·재무·IT 리더) | 표준화·보존 판정, 갈래 결정 | 판정 기록 |
| 계열사 IT 담당 | 시스템 카탈로그 작성, 인터페이스 확인 | 카탈로그 |
| 업무 담당자 | human glue 집계, 인터뷰 응답 | 이중 입력 집계표 |
| 데이터 엔지니어 | 검증 계층 구축, 통과율 보고 | 일일 검증 리포트 |
시작 전 준비물: 계열사별 시스템 목록과 계약 건수, 인터페이스 명세, 상품·사업별 요구 차이에 대한 메모, 최근 진행했거나 멈춘 AI 과제 목록과 멈춘 이유를 모읍니다. 멈춘 AI 과제가 어느 시스템에서 데이터를 못 받아 멈췄는지 적어 두면 카탈로그 우선순위의 근거가 됩니다.
갈래를 고르는 기준(가상 예시): 통합 팀은 주 1회 판정 회의에서 카탈로그 시스템을 10~15개씩 판정합니다. 같은 기능의 시스템이 계열사마다 있고 요구 차이가 습관이면 rationalize 후 replace, 회사의 차별점이 그 시스템 안의 판단 로직에 있고 시장에 맞는 제품이 없으면 Aventum처럼 rebuild, 요구가 진짜 다르고 인수한 전문성이 그 업무에 묶여 있으면 Amynta처럼 protect로 둡니다. 판정마다 근거 인터뷰 한 건과 담당 리더 이름을 남깁니다.
인터뷰·확인 질문
- 이 사업의 처리 방식이 다른 계열사와 다른 이유는 규제·상품 구조 때문인가, 오래된 관행 때문인가?
- 하루에 같은 값을 두 시스템에 넣는 일이 몇 건이고, 누가 하나?
- 이 시스템을 없애면 어느 목표가 영향을 받나?
- 지금 멈춘 AI 과제는 어느 시스템의 데이터가 없어서 멈췄나?
- 이 사업을 인수할 때 산 전문성은 어느 업무 단계에 들어 있나?
진행 판정 기준(가상 예시): 12주 안에 목적지 문서가 경영진 서명을 받고, 카탈로그가 계열사 전체 코어의 90% 이상을 덮고, 모든 시스템에 decision이 붙으면 갈래별 실행으로 넘어갑니다. AI 파일럿은 그 업무의 human glue 지점이 목록화되고 검증 통과율이 기준을 넘긴 곳부터 시작합니다.
적용 제언. 인수·합병으로 계열사가 늘어난 국내 보험·금융 그룹, 지역 법인마다 다른 ERP를 쓰는 제조 그룹이 첫 적용처입니다. 순서는 이렇습니다. 먼저 CEO가 5~10년 목적지를 문서로 쓰고, AX 추진 조직은 그것을 1년 이하 목표로 쪼갭니다. 다음으로 시스템 카탈로그와 human glue 집계를 함께 만들어, 정비 우선순위와 AI 과제 후보가 같은 표에서 나오게 합니다. 사업 성격이 정말 다른 계열사는 Amynta처럼 보존하되, 그 회사의 데이터도 같은 검증 계층은 거치게 합니다. AI 파일럿은 이 정비가 끝난 업무부터 붙이면, 과제마다 레거시를 우회하는 비용을 피할 수 있습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | Insurance Business(미국판), Chris Davis, 2026년 11월 11일, 세 편 연재 중 첫 편 |
| Encova Insurance | 오하이오주 콜럼버스. 16개 회사·26개 주, 코어 30여 개 → 2개 플랫폼. 손해보험은 Guidewire Insurance Suite. 세 원칙(standardize·modernize·rationalize), greenfield·net new, 통합 프로젝트 팀(John Kessler, EVP·최고전략책임자) |
| Encova 비전 | 당시 CEO가 쓴 31쪽 10년 비전, 16개 계열사 직원에게 낭독, 10개 전략 방향, 350~400개 목표, 목표당 12개월 이하 |
| Aventum Group | 런던. ATOMX 자체 개발, IP 보유, 파트너 팀 상주, human glue 개념(Hasani Jess, CTO) |
| Amynta Group | 보존 원칙. 산재·보증·무역신용 예시, 인수 뒤 시스템 강요 경계(Anthony Slimowicz, EVP·MGA 및 특종 위험 COO) |
| Accelerant | AI 이전에 데이터 수집·표준화·검증·이해 인프라(Aaron DiCaprio, 미국 프로그램 총괄) |
| 세 규율 | 벤더보다 목적지를 먼저 쓴다, 표준화할 것과 지킬 것을 정한다, IT 프로젝트가 아니라 통합 팀으로 |
| 같은 연재 | 2편 AI 파일럿 확산(QuoteWell, Crawford, Trucordia, Higginbotham), 3편 전문가 지식 전수(Crum & Forster, Relation, Higginbotham) |
핵심 개념
- Core system
- 보험사에서 계약 관리, 보험료 산출·청구, 보상 처리를 맡는 중심 시스템입니다.
- Technical debt
- 빠르게 덧붙인 시스템과 연결이 쌓여, 바꿀 때마다 추가 비용이 드는 상태입니다.
- Green-screen
- 글자만 나오는 오래된 터미널 화면으로 운영하던 메인프레임 시대의 시스템을 가리킵니다.
- Guidewire Insurance Suite
- 손해보험사가 계약·청구·보상 업무에 쓰는 상용 코어 시스템 묶음입니다.
- Point solution
- 업무 하나만 해결하는 개별 도구입니다. 여럿을 이어 붙이면 연결 지점이 늘어납니다.
- MGA
- Managing General Agent. 보험사로부터 인수·가격 결정 권한을 위임받아 특정 상품을 운영하는 대리점입니다.
- Surety
- 계약 이행이나 지급 의무를 보증하는 보증보험입니다.
- Trade credit
- 거래 상대가 대금을 못 갚을 위험을 보장하는 무역신용보험입니다.
내 메모
TODO: 내 생각 추가
원문은 Insurance Business 「Legacy insurance systems: how leaders are fixing the core first」(Chris Davis, 2026.11.11)입니다. 이 노트는 세 편 연재 가운데 첫 편(코어 정비)을 중심으로 정리했습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례는 원문이 언급한 내용을 AX Partners가 다시 정리했습니다. 기술 디테일의 스키마·설정값·기준, 현업 실행 디테일의 역할·일정·판정 기준, 적용 제언, 인포그래픽과 표는 실제로 돌릴 때 필요한 것을 새로 작성한 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.