Process Context Layer: Novo Nordisk가 AI 에이전트 100여 개를 프로세스 맥락 위에서 돌리고 감시하는 방식

Celonis의 주장은 간단합니다. AI 에이전트는 실제 업무 흐름을 아는 맥락 계층 위에서 돌아야 하고 성과가 떨어지면 에이전트만이 아니라 그 아래 프로세스도 고칠 수 있어야 합니다. Novo Nordisk는 임상 개발에 에이전트 100개 이상을 이렇게 운영한다고 소개됐습니다(벤더 설명). 따라 하려면 에이전트 실행 기록을 프로세스 케이스와 묶어 볼 수 있는 데이터부터 갖춰야 합니다.

요약

프로세스 마이닝(시스템 로그로 실제 업무 흐름을 재구성하는 기술) 회사 Celonis가 2026년 11월 3일 자사 블로그에 Emma Ketterer 이름으로 짧은 안내 글을 올렸습니다. 출발점은 기존 시스템 위에 AI를 얹으면 겉으로는 나아 보여도 해결 안 된 비효율이 그대로 남는다는 진단입니다. 고장 난 프로세스를 자동화하면 비효율도 함께 커지고 나중에 최적화해도 이미 낡은 회사를 다듬는 데 그친다는 것입니다. 글은 이를 피하려면 두 역량이 필요하다고 봅니다. 하나는 일이 실제로 어떻게 도는지 보는 operational clarity(운영 가시성)이고 다른 하나는 그 맥락으로 조직을 흔들지 않고 실행하는 power to act(실행력)입니다. Celonis는 자사 플랫폼이 이를 Analyze(분석), Design(설계), Operate(운영) 세 단계로 돌리고 운영에서 생긴 이탈을 다시 분석에 넣는 closed loop(닫힌 고리)로 묶는다고 설명합니다.

세 단계는 한 방향으로 끝나지 않고 운영 결과가 다시 Analyze로 돌아갑니다(벤더 설명)

근거로는 고객 사례 세 건과 이름 없는 예시 두 건을 듭니다. Novo Nordisk는 임상 개발에 기성품과 맞춤형을 합쳐 AI 에이전트 100개 이상을 배치했고 그 대부분이 Celonis가 제공하는 맥락 계층 위에서 돕니다. 에이전트 성과를 실시간으로 보다가 떨어지면 에이전트를 고칠지 그 아래 프로세스를 고칠지 고르고 그 결과 출시 기간이 크게 줄었다고 합니다(수치는 밝히지 않음). Mercedes-Benz는 시스템 90개 이상과 데이터 30TB를 Celonis에 연결해 공급망 차질에 더 빨리 대응하려 하고 플라스틱 유통사 Vinmar는 30억 달러 규모 사업부의 주문~청구 과정을 자동화해 생산성이 20% 올랐다고 밝혔습니다. 모두 벤더 블로그가 전한 수치입니다. 글은 이 접근을 “clarity + action”이라는 공식으로 묶습니다. 아래에서는 세 단계와 맥락 계층이 어떻게 작동하는지, 실제로 에이전트를 프로세스 맥락 위에서 돌리려면 무엇이 필요한지 풀어 봅니다.

원문의 출발점: 고치지 않은 프로세스를 자동화하면 비효율도 함께 커진다는 주장

핵심 메커니즘

Operational clarity와 Power to act: 보는 힘과 실행하는 힘

operational clarity는 일이 매일 실제로 어떻게 돌아가는지, 누가 관여하는지, 기존 프로세스 지도에 안 잡히는 예외와 이탈이 무엇인지를 세밀하게, 실시간으로 아는 상태입니다. 앞으로 내릴 결정이 어떤 영향을 낼지 미리 보는 능력도 여기에 넣습니다. power to act는 그 맥락을 조직을 흔들지 않고 안전하게 실행에 옮기는 능력입니다. 원문은 둘 중 하나만 있으면 과거 방식에 맞춰 최적화하게 된다고 봅니다. 보기만 하면 바뀌지 않고 보지 않고 실행하면 낡은 흐름을 더 빨리 돌릴 뿐이라는 뜻입니다.

작은 예시(가상 예시): 구매 승인 에이전트를 붙이기 전에 로그를 보니 발주의 15%가 사후 승인으로 처리되고 있었다면, 에이전트에 “승인 요청을 빨리 보내라”고 시키기 전에 사후 승인이 왜 생기는지부터 풀어야 합니다.

원문이 꼽은 두 역량. 하나만 갖추면 과거 방식에 맞춰 최적화하게 된다는 설명

Analyze: 실제 흐름을 보고 고칠 순서를 정한다

Analyze는 원천 시스템에서 데이터를 안전하게 뽑아 실시간으로 갱신되는 digital twin(운영의 디지털 복제본)을 만드는 단계입니다. 원문은 Salesforce, Workday, ServiceNow 같은 범용 시스템과 FIS(금융), CTMS(임상시험 관리), MES(제조 실행) 같은 업종 시스템을 예로 듭니다. 이 twin에서 근본 원인을 찾고 격차마다 고쳤을 때의 가치를 산정해 무엇을 어떤 순서로 풀지 정합니다. 출력은 “풀 만한 문제 목록과 순서”입니다. 데이터가 여러 시스템에 흩어진 end-to-end 프로세스(주문~청구, 구매~지급)일수록 효과가 큽니다. 한 시스템 안에서 끝나는 단순 업무라면 그 시스템 보고서로도 충분할 수 있습니다.

Analyze: 원천 시스템 데이터를 모아 어디부터 고칠지 순서를 낸다

Design: 만들기 전에 실제 케이스로 시험한다

Design은 예산을 쓰기 전에 프로세스를 다시 그리는 단계입니다. 모범 사례를 바탕으로 목표 모델 초안을 만들고 바꾼 내용을 실제 케이스에 시뮬레이션해 보고 전환을 웨이브(나눠 진행하는 묶음)로 계획합니다. 원문은 이 단계에서 에이전트가 추론과 예측, what-if 시나리오, 장단점 비교, 맞춤 추천을 맡는다고 설명합니다. 핵심은 “가상의 표준 흐름”이 아니라 “지난 분기에 실제로 지나간 케이스”에 새 규칙을 대 본다는 점입니다. 그래야 예외 케이스가 새 설계에서 어디로 빠지는지 미리 보입니다.

Design: 만들기 전에 실제 케이스로 바뀐 프로세스를 시험한다. 에이전트가 예측·추천을 돕는다(벤더 설명)

Operate와 closed loop: 운영의 이탈이 다음 설계로 돌아온다

Operate에서는 팀이 프로세스마다 앱과 에이전트를 만들어 운영에 넣습니다. 원문은 이것이 Celonis 플랫폼 안에서든 밖에서든 가능하다고 말합니다. 운영 중에는 목표 모델을 얼마나 지키는지 모델링하고 시간이 지나며 실현된 가치를 측정합니다. closed loop는 이 단계에서 생긴 변화와 이탈, 예를 들어 에이전트가 예상하지 못한 경로를 탔거나 팀이 새 작업 방식을 만든 일을 다음 Analyze와 Design의 입력으로 되돌리는 구조입니다. 한 번 설계하고 끝내는 프로젝트가 아니라 계속 돌아가는 운영 체계로 보라는 주장입니다.

Operate: 운영 중 생긴 이탈이 다음 분석과 설계의 입력이 된다

Celonis Context Model: 사람과 에이전트가 함께 보는 운영 맥락

Context Model은 세 단계 모두의 바탕입니다. 회사가 지금 어떻게 돌아가는지와 어떻게 돌아야 하는지를 계속 갱신해 사람과 AI 에이전트에게 같은 그림으로 줍니다. 원문은 이 계층이 있어서 Celonis가 다른 “에이전틱” 기술과 다르다고 설명합니다. 에이전트 입장에서 보면 “이 건은 어떤 승인 한도를 따르나”, “이 예외는 어느 앞단에서 생겼나” 같은 질문에 답해 줄 조회처입니다. 원문의 은행 예시가 바로 이 질문입니다. 맥락 없이 문서와 화면만 보는 에이전트는 개별 건은 처리해도 그 건이 전체 흐름에서 어디쯤인지 모릅니다.

Context Model은 세 단계 모두의 바탕. 사람과 에이전트가 같은 현재·목표 모습을 본다(벤더 설명)

통념과 다른 주장

흔히 이렇게 봅니다AI 에이전트를 지금 업무에 빨리 붙이면 그만큼 효율이 오르고 프로세스 개선은 나중에 해도 된다.

저자는 이렇게 봅니다고치지 않은 프로세스를 자동화하면 비효율도 함께 커집니다. 나중의 최적화는 이미 낡은 구조를 다듬는 일이 되므로, 실제 흐름을 먼저 보고 목표 모델을 시험한 뒤 에이전트를 얹어야 합니다.

근거Novo Nordisk는 에이전트 성과가 떨어질 때 에이전트만이 아니라 그 아래 프로세스를 고치는 선택지를 둡니다. Vinmar는 주문~청구 과정을 자동화해 생산성이 20% 올랐다고 밝혔습니다(벤더 설명).

흔히 이렇게 봅니다에이전트 품질 관리는 프롬프트, 모델, 도구를 다듬는 일이다.

저자는 이렇게 봅니다에이전트 성과를 프로세스와 함께 봐야 합니다. 성과가 떨어진 원인이 에이전트일 수도, 그 아래 프로세스일 수도 있으니 둘 중 무엇을 고칠지 골라야 합니다.

근거Novo Nordisk는 에이전트 대부분을 Celonis 맥락 계층 위에서 돌리며 성과를 실시간으로 보고 하락하면 에이전트와 프로세스 중 고칠 대상을 정합니다.

저자가 든 사례

Novo Nordisk: 에이전트 100개 이상을 프로세스 맥락 위에서 감시

상황: 제약사 Novo Nordisk는 임상 개발에서 출시까지 걸리는 시간을 줄이려 합니다.
한 일: 기성품과 맞춤형을 합쳐 AI 에이전트 100개 이상을 임상 개발에 배치했고 대부분이 Celonis 맥락 계층 위에서 돕니다. 성과를 실시간으로 보고 하락하면 에이전트를 고칠지 그 아래 프로세스를 고칠지 고릅니다.
결과: 출시 기간이 크게 줄었다고 했으나 수치는 원문에서 밝히지 않았습니다.
연결: Context Model, Operate와 closed loop.

Novo Nordisk: 출시 기간이 크게 줄었다고 했으나 수치는 밝히지 않음(벤더 설명)

Mercedes-Benz와 Vinmar: 연결의 규모와 자동화의 결과

상황: Mercedes-Benz는 정시 납품, 품질, 애프터서비스에서 공급망 차질에 더 빨리 대응해야 했습니다. Vinmar가 부딪힌 문제는 원문에서 밝히지 않았습니다.
한 일: Mercedes-Benz는 시스템 90개 이상과 데이터 30TB를 Celonis에 연결해 일이 실제로 도는 모습을 전체로 봤습니다. Vinmar는 30억 달러 규모 사업부의 주문~청구 과정을 자동화했습니다.
결과: Mercedes-Benz는 대응 속도가 빨라졌다고만 했고 수치는 밝히지 않았습니다. Vinmar는 생산성 20% 향상을 밝혔습니다.
연결: Analyze(연결과 가시성), Operate(자동화와 가치 측정).

두 고객 사례의 숫자. 모두 Celonis 블로그가 밝힌 벤더 설명

은행과 방산: 맥락 없이는 움직이면 안 되는 에이전트

상황: 회사 이름 없이 든 예시입니다. 은행의 대금 정산 에이전트는 어떤 승인 한도가 적용되는지, 예외가 어디서 생기는지 알아야 합니다. 방산 기업의 물류 에이전트는 변동이 큰 상황에서도 엄격한 제약을 지켜야 합니다.
한 일·결과: 원문에서 밝히지 않았습니다. 두 업종에서는 규정 준수와 감사 가능성이 타협할 수 없는 조건이라는 점을 짚는 데 썼습니다.
연결: Context Model(에이전트가 조회할 운영 맥락).

원문의 예시 두 개(회사명 없음): 에이전트가 맥락 없이 움직이면 안 되는 업무

기술 디테일: 에이전트를 프로세스 맥락 위에서 돌리려면

아래 필드명, 설정값, 기준은 실제로 돌릴 때 필요한 것을 새로 정리한 가상 예시입니다. Celonis나 Novo Nordisk가 밝힌 구현이 아닙니다.

Context Model에 해당하는 데이터를 만들려면 프로세스 마이닝의 기본 단위인 이벤트 로그부터 갖춥니다. 최소 필드는 case_id(주문 번호, 임상시험 신청 번호처럼 한 건을 묶는 키), activity, timestamp, resource(사람·시스템·에이전트), source_system입니다. 주문과 송장, 납품처럼 한 케이스에 여러 객체가 엮이면 객체 단위(object-centric) 로그로 두는 편이 분석이 덜 꼬입니다. 에이전트가 행동할 때도 같은 로그에 resource = agent:<agent_id>로 기록해야 사람의 작업과 에이전트의 작업을 같은 흐름 안에서 비교할 수 있습니다.

에이전트에는 맥락을 조회 도구로 줍니다. 프롬프트에 프로세스 전체를 붙이지 않습니다. 에이전트가 건 하나를 처리할 때 get_case_context(case_id) 같은 도구를 불러 현재 단계, 지금까지 지난 활동, 적용되는 규칙(예: 승인 한도), 같은 변형의 평균 처리 시간, 앞단 이탈 여부를 구조화된 값으로 받게 합니다. 응답에는 데이터 기준 시각을 넣어, 에이전트 판단이 몇 분 전 데이터를 근거로 했는지 남깁니다.

{
  "case_id": "PO-2026-104233",
  "current_step": "invoice_match",
  "variant": "3way_match_with_price_change",
  "rules": [{"name": "approval_limit", "value": 50000, "currency": "USD"}],
  "upstream_deviations": ["po_changed_after_gr"],
  "median_cycle_days_same_variant": 6.5,
  "as_of": "2026-11-07T09:10:00+09:00"
}

에이전트 실행 로그는 케이스와 묶어 남깁니다. 실행마다 run_id, agent_id, agent_version, case_id, input_context_hash, action, outcome(성공·실패·사람 이관), human_override(사람이 결과를 바꿨는지), latency_ms를 기록합니다. Novo Nordisk처럼 “에이전트를 고칠지 프로세스를 고칠지”를 가르려면 이 로그가 프로세스 케이스와 같은 키로 이어져 있어야 합니다.

원인을 가르는 규칙을 미리 정합니다. 에이전트 성공률이 기준선보다 떨어지면 실패 건을 프로세스 변형별로 나눠 봅니다. 실패가 특정 변형이나 특정 앞단 이탈(예: 입고 뒤 발주 변경)에 몰려 있으면 프로세스 문제로 보고 흐름이나 규칙을 고칩니다. 실패가 변형과 관계없이 고르게 퍼져 있고 같은 입력에서 결과가 흔들리면 에이전트 문제로 보고 프롬프트, 도구, 모델 버전을 봅니다. 특정 원천 시스템에서 온 건만 실패하면 데이터 연결이나 정의 문제입니다.

가상 예시: 에이전트 로그를 프로세스 케이스와 묶어야 무엇을 고칠지 가를 수 있다

감시 지표는 에이전트별로 일 단위로 봅니다. 처리 건수, 자동 완료율, 사람 이관률, 사람 수정률, 케이스 리드타임 변화, 목표 모델 준수율(conformance)을 기본으로 둡니다. 경보 기준 예시는 7일 이동평균 대비 자동 완료율 5%p 하락, 또는 사람 수정률 2배 상승입니다. 에이전트가 100개를 넘으면 사람이 대시보드를 하나씩 볼 수 없으므로, 경보가 뜬 에이전트만 위 원인 판정 흐름으로 보내는 큐를 만듭니다.

Design의 시뮬레이션은 지난 케이스 재생으로 시작합니다. 최근 3~6개월 케이스를 새 규칙에 다시 흘려, 규칙이 바뀌면 어떤 케이스가 다른 경로로 빠지는지, 승인 단계가 몇 건 줄거나 늘어나는지를 셉니다. 확률 모델까지 가기 전에 이 재생만으로도 예외 케이스가 어디로 새는지 대부분 드러납니다.

막히는 경우	증상	대응
케이스 키가 시스템마다 다름	주문 번호와 송장 번호가 안 이어짐	키 매핑 테이블을 먼저 만들고 매핑률 95% 미만이면 분석 범위를 좁힘
에이전트 행동이 로그에 안 남음	사람 작업만 보이고 에이전트 경로가 빈칸	에이전트 실행 로그를 같은 이벤트 로그에 쓰도록 배포 조건으로 정함
맥락 데이터가 늦음	에이전트가 이미 바뀐 상태로 판단	응답에 `as_of`를 넣고 지연 허용치(예: 15분)를 넘으면 사람에게 이관
원인 판정이 늘 “에이전트”로 끝남	프로세스 수정이 한 번도 안 나옴	판정 회의에 프로세스 오너를 고정 참석자로 둠
에이전트 수가 늘며 중복	같은 단계를 두 에이전트가 처리	에이전트 목록에 담당 단계(activity)를 등록하고 겹치면 배포를 막음

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

아래 역할 표, 일정, 판정 기준은 원문의 세 단계를 한 프로세스에서 시작하는 경우로 새로 짠 가상 예시입니다.

역할	맡는 일
프로세스 오너(현업 임원)	대상 프로세스와 목표 지표 결정, 프로세스 수정 승인
프로세스 분석가 1~2명	이벤트 로그 설계, 현행 흐름·예외 분석, 가치 산정
데이터 엔지니어 1~2명	원천 시스템 추출, 케이스 키 매핑, 갱신 주기 운영
AI 엔지니어 1~2명	에이전트 개발, 맥락 조회 도구, 실행 로그와 감시 지표
현업 담당자 3~5명	예외 처리 방식 설명, 시뮬레이션 결과 검토, 병행 운영
리스크·컴플라이언스	승인 한도·감사 요건 정의, 에이전트 권한 검토

준비물. 대상 프로세스 하나(주문~청구나 구매~지급처럼 시스템 두세 개를 지나는 것), 관련 시스템의 6~12개월 이벤트 데이터 접근 권한, 현재 프로세스 지도와 승인 규정, 지금의 리드타임·처리 비용 기준선, 이미 쓰고 있는 자동화·에이전트 목록이 필요합니다.

가상 예시 일정: 측정, 설계, 에이전트 투입, 감시를 한 프로세스에서 순서대로

기간	할 일	산출물
1~2주	데이터 추출, 케이스 키 매핑, 현행 흐름과 상위 변형 분석	현행 프로세스 지도, 예외 상위 10개, 개선 가치 순위
3~4주	목표 모델 작성, 지난 케이스 재생 시뮬레이션, 웨이브 계획	목표 모델, 시뮬레이션 결과, 1차 웨이브 범위
5~8주	1차 웨이브 프로세스 수정, 에이전트 1~2개 병행 운영	에이전트 실행 로그, 자동 완료율·사람 수정률
9주~	감시 지표 운영, 월 1회 원인 판정 회의	에이전트 수정·프로세스 수정 목록, 실현 가치 보고

현업에 물을 것.

이 프로세스에서 가장 자주 생기는 예외는 무엇이고 지금 누가 어떻게 처리하나요?
공식 지도와 실제 처리 방식이 다른 단계는 어디인가요?
에이전트가 절대 혼자 판단하면 안 되는 건(금액, 고객, 규제)은 무엇인가요?
에이전트 결과가 나빠졌을 때 프로세스를 바꿀 권한은 누구에게 있나요?
이미 쓰는 자동화나 에이전트가 이 프로세스의 어느 단계에 붙어 있나요?

진행 판정 기준(예시). 1~2주 차에 케이스 키 매핑률이 95%를 넘고 상위 변형 5개가 전체 케이스의 절반 이상을 설명하면 Design으로 넘어갑니다. 병행 운영에서 에이전트 자동 완료율이 기준선 대비 개선되고 사람 수정률이 10% 아래로 내려오며 리드타임이 줄면 다음 웨이브로 넓힙니다. 원인 판정 회의에서 한 달 동안 프로세스 수정이 한 건도 나오지 않으면 closed loop가 작동하지 않는 것으로 보고 회의 구성과 데이터를 다시 봅니다.

AX 적용 제언. 국내 기업이 에이전트를 여러 부서에서 따로 붙이기 시작했다면 이 글의 메시지는 “에이전트 목록보다 프로세스 지도가 먼저”입니다. 순서는 이렇게 권합니다. 먼저 이미 돌고 있는 에이전트와 RPA를 프로세스 단계에 매핑해 겹침과 빈칸을 봅니다. 다음으로 시스템 두세 개를 지나는 핵심 프로세스 하나를 골라 이벤트 로그를 만들고 에이전트 실행 기록을 같은 로그에 남기게 합니다. 마지막으로 에이전트 성과 회의에 프로세스 오너를 고정으로 앉혀 “에이전트를 고칠지, 프로세스를 고칠지”를 실제로 결정하게 합니다. 제조라면 MES와 구매 시스템을 잇는 납기 대응, 금융이라면 대금 정산과 예외 승인이 첫 후보로 알맞습니다. 이 순서가 프로세스 혁신(PI) 프로젝트와 에이전트 도입 예산을 한 묶음으로 관리하게 해 줍니다.

원문 사례

항목	내용
원문	Celonis 블로그, 2026.11.3 게재, 약 2분 분량
저자	Emma Ketterer (Celonis)
핵심 주장	고치지 않은 프로세스에 AI를 얹으면 비효율도 함께 커진다. operational clarity와 power to act가 함께 필요하다
플랫폼 구성	Analyze, Design, Operate 세 단계와 closed loop, 바탕에 Celonis Context Model
예로 든 원천 시스템	Salesforce, Workday, ServiceNow, FIS, CTMS, MES
Novo Nordisk	임상 개발에 AI 에이전트 100개 이상(기성품·맞춤형), 대부분 Celonis 맥락 계층 위, 성과 실시간 감시 후 에이전트 또는 프로세스 수정, 출시 기간 크게 단축(수치 없음)
Mercedes-Benz	시스템 90개 이상, 데이터 30TB 연결, 공급망 차질 대응 가속(수치 없음)
Vinmar	30억 달러 사업부의 주문~청구 자동화, 생산성 20% 향상
이름 없는 예시	은행 대금 정산 에이전트(승인 한도·예외 출처), 방산 물류 에이전트(엄격한 제약)
보강 자료	Celonis 블로그 Novo 기고(Stephanie Bova, 2026.7.1): 프로토콜 이탈, 이슈 관리, 임상시험 신청 과정부터 적용했고 문제를 사람·프로세스·데이터·기술 중 어디서 왔는지 나눠 본 뒤 기술 스택보다 업무 흐름을 먼저 고친다고 밝힘
수치 성격	모두 벤더 블로그가 전한 고객 수치이며 외부 검증 자료는 원문에 없음

핵심 개념

Process mining: ERP·CRM 같은 시스템이 남긴 이벤트 기록으로 업무가 실제로 지나간 경로와 시간, 예외를 재구성하는 기법입니다.
Event log: 케이스 번호, 활동, 시각, 수행자를 한 줄씩 적은 기록으로, 프로세스 마이닝의 기본 입력입니다.
Variant: 같은 프로세스 안에서 활동 순서가 같은 케이스 묶음입니다. 표준 경로와 예외 경로를 구분할 때 씁니다.
Conformance: 실제 케이스가 목표 모델을 얼마나 따랐는지 재는 지표입니다. Operate 단계의 준수 측정이 여기에 해당합니다.
Order-to-invoice: 주문 접수부터 송장 발행까지 이어지는 과정으로, 영업·물류·재무 시스템을 함께 지납니다.
CTMS: Clinical Trial Management System. 임상시험의 일정, 기관, 대상자, 예산을 관리하는 시스템입니다.
MES: Manufacturing Execution System. 공장 현장의 작업 지시, 실적, 품질 기록을 관리하는 시스템입니다.

내 메모

TODO: 내 생각 추가

원문은 Celonis 블로그의 「Future-proofing operations with Enterprise AI and agentic automation systems」(Emma Ketterer, 2026.11.3)입니다. 벤더가 쓴 글이라 고객 수치는 모두 Celonis가 전한 설명이며 외부 검증을 거친 값이 아닙니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Partners가 다시 정리했고 기술 디테일, 현업 실행 디테일, 인포그래픽, 표는 실제로 돌릴 때 필요한 내용을 새로 작성한 가상 예시입니다. Novo Nordisk의 적용 범위는 같은 블로그에 실린 Stephanie Bova(Novo R&D 디지털 전환 책임자)의 기고 「How Novo speeds up drug development with smarter AI」(2026.7.1)로 보강했습니다. 전체 내용은 원문에서 볼 수 있습니다.