WEBVTT

00:00:00.000 --> 00:00:03.840
여러분의 로우코드 자동화가 고장나는 이유는 지나치게 똑똑하려고 하기 때문입니다.

00:00:04.000 --> 00:00:09.840
경직된 이프댄 논리는 매일 시스템을 멈추게 만드는 복잡한 현실세계의 데이터 불일치 앞에서 사형선고나 다름없습니다.

00:00:09.980 --> 00:00:13.000
데이터가 깨끗할 것이라는 가정은 로우코드 설계의 원제와 같습니다.

00:00:13.360 --> 00:00:17.760
우리는 이프댄 모델 위에 세상을 구축했지만 그 모델이 작동하려면 절대적인 확실성이 필요합니다.

00:00:17.920 --> 00:00:19.780
현실세계의 데이터는 확실하지 않습니다.

00:00:19.960 --> 00:00:20.700
오타가 있습니다.

00:00:21.020 --> 00:00:21.940
문맥이 빠져 있습니다.

00:00:22.300 --> 00:00:24.520
그것은 인간의 실수가 뒤섞인 혼돈의 흐름입니다.

00:00:24.520 --> 00:00:29.420
결정론적 시스템은 1%위 변수만 마주해도 구부러지지 않으며 당연히 적응하지도 못합니다.

00:00:29.580 --> 00:00:30.780
그저 고장날 뿐입니다.

00:00:30.960 --> 00:00:35.460
이로 인해 자동화의 강도가 가장 깨끗한 데이터 포인트에 위존하게 되는 취약성에 덫에 빠지게 됩니다.

00:00:35.660 --> 00:00:38.260
기업 환경에서 이는 성공을 위한 매우 낮은 기준입니다.

00:00:38.460 --> 00:00:41.620
하지만 문제는 데이터가 아니라 데이터를 처리하는 모델에 있습니다.

00:00:41.960 --> 00:00:43.220
결정론의 종말입니다.

00:00:43.480 --> 00:00:46.640
결정론적 논리는 구조화된 데이터 시대의 유물입니다.

00:00:46.920 --> 00:00:52.740
모든 것이 sql 테이블에 존재하고 인간을 미리 정의된 틀에 억지로 맞추던 시절에는 효과적이었습니다.

00:00:52.740 --> 00:00:54.560
하지만 그런 세상은 끝났습니다.

00:00:54.760 --> 00:01:00.120
오늘날 기업 데이터의 80%는 비정형이며 이는 이메일, 채팅, 음성 녹음 속에 존재합니다.

00:01:00.300 --> 00:01:06.220
기존의 파워 오토메이트 흐름은 사과 애플스와 사과 사계 포 애플스를 서로 다른 세계로 취급합니다.

00:01:06.400 --> 00:01:09.920
이진 시스템 입장에서 그들은 전혀 관련 없는 문자열일 뿐입니다.

00:01:10.140 --> 00:01:14.740
우리는 수동 데이터 정제 비용이 자동화 자체의 가치를 넘어서는 한계점에 도달했습니다.

00:01:15.100 --> 00:01:20.600
5초짜리 흐름을 실행하기 위해 2시간 동안 csv 파일을 수정해야 한다면 사실상 아무것도 자동화하지 못한 것입니다.

00:01:20.600 --> 00:01:22.620
단지 노동의 위치를 옮겼을 뿐입니다.

00:01:22.820 --> 00:01:26.220
ai는 단순히 파워 플랫폼 옆에 붙이는 화려한 새 기능이 아닙니다.

00:01:26.400 --> 00:01:29.420
이는 정확한 일치에서 유사성으로의 근본적인 전환입니다.

00:01:29.620 --> 00:01:32.120
구형 모델은 이것이 a인가? 라고 묻습니다.

00:01:32.360 --> 00:01:35.100
신형 모델은 이것이 a와 얼마나 비슷한가? 라고 묻습니다.

00:01:35.340 --> 00:01:37.380
여러분이 받은 편지함을 어떻게 살펴보는지 생각해보세요.

00:01:37.580 --> 00:01:39.880
청구서를 찾기 위해 머릿속으로 정규식을 돌리지는 않죠.

00:01:40.020 --> 00:01:40.880
패턴을 찾습니다.

00:01:41.120 --> 00:01:42.000
문맥을 찾습니다.

00:01:42.300 --> 00:01:47.240
글자가 일치하지 않아도 imv202와 청구서 번호 200이 가 같은 것임을 인식합니다.

00:01:47.240 --> 00:01:49.420
결정론적 시스템은 그렇게 할 수 없습니다.

00:01:49.700 --> 00:01:51.140
그들은 의도를 파악하지 못합니다.

00:01:51.340 --> 00:01:52.440
구문만을 볼 뿐입니다.

00:01:52.740 --> 00:01:56.540
2026년을 향해 나아가는 지금 구문은 의미보다 덜 중요해지고 있습니다.

00:01:56.860 --> 00:02:02.840
우리는 iot 센서, 실시간 스트림, llm 생성 요약으로 인한 데이터 볼륨의 폭발적인 증가를 목격하고 있습니다.

00:02:03.120 --> 00:02:07.980
하드코딩된 if된 분기로의 볼륨을 관리하려 한다면 여러분의 논리는 미로처럼 변할 것입니다.

00:02:08.220 --> 00:02:14.020
결국 50개의 중첩 조건이 담긴 흐름을 만들게 될 것이며 공급업체가 이메일 서명만 바꿔도 그 흐름은 고장날 것입니다.

00:02:14.020 --> 00:02:18.500
if된 모델은 입력값이 항상 스키마와 일치하는 완벽한 세상을 가정합니다.

00:02:18.700 --> 00:02:20.260
하지만 현실은 정반대입니다.

00:02:20.520 --> 00:02:22.420
데이터가 바로 변수이기 때문입니다.

00:02:22.620 --> 00:02:27.040
논리는 상수여야 하지만 우리의 논리는 현실과 마주했을 때 살아남기에는 너무나 경직되어 있었습니다.

00:02:27.220 --> 00:02:32.600
우리는 끊임없이 우박이 내리는 세상에 유리집을 지어놓고 왜 바닥이 파편으로 뒤덮였는지 위하에 하고 있습니다.

00:02:32.860 --> 00:02:36.480
확률적 설계로의 전환은 유리 대신 고무로 건물을 짓는 것과 같습니다.

00:02:36.840 --> 00:02:41.360
오타가 발생해도 부서지지 않고 그 충격을 흡수할 수 있는 시스템을 만드는 것입니다.

00:02:41.360 --> 00:02:45.980
우리는 시스템이 100% 맞거나 100% 틀려야 한다는 생각에서 벗어나고 있습니다.

00:02:46.240 --> 00:02:48.720
현실 세계에 100%란 존재하지 않으니까요.

00:02:48.900 --> 00:02:51.840
우리는 수십 년 동안 데이터 품질에 대해 스스로를 속여왔습니다.

00:02:52.080 --> 00:02:58.000
우리의 논리를 위해 깨끗한 방을 만들어두면서 영업팀의 지저분한 데이터가 시스템 전체에 장애를 일으키자 놀란 척했습니다.

00:02:58.260 --> 00:03:00.600
결정론의 종말은 곧 그 거짓의 종말입니다.

00:03:00.840 --> 00:03:04.640
입력값을 통제할 수 없음을 인정하고 처리 방식을 현대화해야 한다는 뜻입니다.

00:03:04.640 --> 00:03:11.440
우리는 이제 대략 적인 엔터프라이즈 위시대로 접어들고 있으며 완전히 틀린 것보다 적당히 맞는 것이 더 낫다는 것을 받아들이고 있습니다.

00:03:11.660 --> 00:03:19.040
90% 일치하는 데이터를 처리할 수 있는 시스템이 100% 일치하지 않는 모든 것을 거부하는 시스템보다 훨씬 더 가치있기 때문입니다.

00:03:19.240 --> 00:03:22.260
이것은 단순한 기술적 변화가 아니라 심리적인 변화입니다.

00:03:22.520 --> 00:03:26.700
시스템이 데이터의 일부에 대해 꽤 확신할 수 있다는 생각을 받아들여야 합니다.

00:03:26.940 --> 00:03:29.280
위심을 염두에 두고 설계하는 법을 배워야 합니다.

00:03:29.480 --> 00:03:32.840
비정형 정보를 처리하는 유일하게 정직한 방법은 위심하는 것이기 때문입니다.

00:03:32.840 --> 00:03:39.160
이러한 전화는 이진 법적 트리거에서 훨씬 더 미묘한 신뢰도 점수, 즉 불확실성의 아키텍처로 나아갈 것을 요구합니다.

00:03:39.300 --> 00:03:43.940
이진 법적 논리의 시대가 끝났음을 인정한다면 우리는 이를 새로운 프레임워크로 대체해야 합니다.

00:03:44.140 --> 00:03:46.180
저는 이것을 교양악단 모델이라 부릅니다.

00:03:46.420 --> 00:03:53.320
전통적인 IT 아키텍처에서는 모두가 딱딱한 악보를 보고 연주하는 독주자여서 한 사람이라도 음을 틀리면 공연 전체가 멈춥니다.

00:03:53.500 --> 00:03:57.660
하지만 확률적 아키텍처에서는 결정론적 지휘자가 확률적 연주자들을 관리합니다.

00:03:57.880 --> 00:04:00.040
지휘자는 바로 여러분의 파워 오토메이트 흐름입니다.

00:04:00.040 --> 00:04:03.160
흐름이 구조를 제공하고 템포를 설정하며 경계를 정의합니다.

00:04:03.300 --> 00:04:05.020
연주자는 바로 AI 모델입니다.

00:04:05.240 --> 00:04:10.540
재능은 뛰어나지만 표현력이 풍부해서 연주할 때마다 매번 정확히 똑같은 주파수를 내지는 않습니다.

00:04:10.760 --> 00:04:14.060
지휘자의 역할은 연주자들에게 로봇이 되라고 강요하는 것이 아닙니다.

00:04:14.260 --> 00:04:18.140
그들의 연주를 듣고 그 소리가 계속 진행하기에 충분한지 판단하는 것입니다.

00:04:18.380 --> 00:04:21.760
이것이 현대 설계의 핵심 기둥인 신뢰도 점수로 우리를 이끕니다.

00:04:21.980 --> 00:04:25.660
신뢰도 점수는 의심의 정도를 정량화하는 0에서 1 사이의 갑입니다.

00:04:25.660 --> 00:04:30.440
이는 모델이 이것이 일치한다고 생각하며 이만큼 확신한다 라고 말하는 방식입니다.

00:04:30.600 --> 00:04:32.860
과거에는 하드코딩된 경로를 사용했습니다.

00:04:33.140 --> 00:04:36.440
이메일 제목에 송장이 포함되어 있으면 첨부 파일을 저장하는 시기였죠.

00:04:36.640 --> 00:04:39.040
새로운 세계에서는 신뢰도 기반 나우팅을 사용합니다.

00:04:39.260 --> 00:04:42.080
우리는 모델 내부의 의심을 시스템이 볼 수 있게 만듭니다.

00:04:42.300 --> 00:04:47.140
이제 AI를 블랙박스로 취급하는 대신 특정 수준의 신뢰도를 가진 증인으로 대합니다.

00:04:47.440 --> 00:04:50.200
파워 플랫폼에서 이를 실제로 구축하는 방법은 다음과 같습니다.

00:04:50.540 --> 00:04:54.300
AI 빌더 나이저 AI를 사용하면 단순히 추출된 데이터만 얻는 것이 아닙니다.

00:04:54.300 --> 00:04:57.960
모든 개별 필드에 대한 확률을 나타내는 메타 데이터 계층을 얻게 됩니다.

00:04:58.180 --> 00:05:03.400
모델이 총액 1500달러를 추출하면 그 숫자에 대해 95% 확신한다는 사실도 함께 알려줍니다.

00:05:03.580 --> 00:05:06.640
아키텍트로서 이제 여러분에게는 세 가지의 명확한 실행 영역이 있습니다.

00:05:06.880 --> 00:05:08.340
첫 번째는 녹색 영역입니다.

00:05:08.600 --> 00:05:10.600
신뢰도가 0.90 이상인 경우입니다.

00:05:10.800 --> 00:05:14.840
오류 위험이 낮고 실수의 비용도 감당할 수 있으므로 자동화를 진행합니다.

00:05:15.080 --> 00:05:17.340
시스템은 사람의 개입 없이 작업을 수행합니다.

00:05:17.560 --> 00:05:19.080
두 번째는 노란색 영역입니다.

00:05:19.320 --> 00:05:21.980
신뢰도가 0.60에서 0.89 사이인 경우입니다.

00:05:21.980 --> 00:05:24.720
모델이 어느 정도 확신하지만 확실하지는 않은 상태입니다.

00:05:24.860 --> 00:05:27.380
문서가 약간 흐릿하거나 손끌씨가 지저분할 수 있습니다.

00:05:27.600 --> 00:05:29.580
이 영역에서는 데이터를 표시, 플래그, 합니다.

00:05:29.780 --> 00:05:32.340
시스템은 신속한 확인을 위해 데이터를 검토자에게 전달합니다.

00:05:32.540 --> 00:05:33.920
세 번째는 빨간색 영역입니다.

00:05:34.140 --> 00:05:35.800
신뢰도가 0.60 미만인 경우입니다.

00:05:35.980 --> 00:05:37.260
모델이 추측하고 있는 상태입니다.

00:05:37.440 --> 00:05:39.540
이 영역에서는 데이터를 거부하거나 상급자에게 보고합니다.

00:05:39.720 --> 00:05:42.340
해당 데이터가 운영 데이터베이스에 절대 접근하지 못하도록 차단합니다.

00:05:42.580 --> 00:05:44.320
이것은 투명한 위험 관리 계층입니다.

00:05:44.560 --> 00:05:47.520
안전장치를 유지하면서 자동화 규모를 확장할 수 있게 해줍니다.

00:05:47.780 --> 00:05:49.640
거버넌스에 미칠 영향을 생각해보세요.

00:05:49.900 --> 00:05:52.280
결정론적 시스템에서는 오류가 조용히 발생합니다.

00:05:52.460 --> 00:05:54.840
플로우가 실행되고 오타로 인해 잘못된 숫자를 선택하면

00:05:54.840 --> 00:05:56.580
그 틀린 값을 ERP에 기록합니다.

00:05:56.780 --> 00:05:58.740
분기가 끝날 때까지는 이 사실을 알 수 없습니다.

00:05:59.020 --> 00:06:01.220
확률적 시스템에서는 오류에 고유한 직증이 있습니다.

00:06:01.520 --> 00:06:03.060
시스템은 자신이 어려움을 겪고 있음을 알고

00:06:03.060 --> 00:06:05.460
이것을 처리했지만 신뢰도가 62%에 불과했다.

00:06:05.600 --> 00:06:06.120
고 알려줍니다.

00:06:06.280 --> 00:06:07.580
이는 매우 강력한 신호입니다.

00:06:07.820 --> 00:06:09.820
이 신호를 통해 위심 대시보드를 구축할 수 있습니다.

00:06:10.060 --> 00:06:12.100
모델이 정확히 어디에서 실패하고 있는지 볼 수 있습니다.

00:06:12.100 --> 00:06:14.520
어떤 공급업체가 AI가 읽을 수 없는 문서를 보내는지

00:06:14.520 --> 00:06:17.720
어떤 프로세스 단계가 계속해서 노란색 영역에 머무르는지 확인할 수 있습니다.

00:06:17.900 --> 00:06:19.560
여러분은 단순히 플로우를 구축하는 것이 아니라

00:06:19.560 --> 00:06:21.020
지능형 루프를 구축하는 것입니다.

00:06:21.200 --> 00:06:24.200
바로 이 지점에서 에이저 AI와 AI 빌더가 진가를 발휘합니다.

00:06:24.400 --> 00:06:26.500
이들은 이러한 점수를 세부적인 수준으로 공개함으로

00:06:26.500 --> 00:06:29.780
특정표, 셀 또는 특정 의도에 대한 신뢰도를 확인할 수 있습니다.

00:06:29.940 --> 00:06:32.960
파워FX를 사용하여 동적 임계값을 생성할 수도 있습니다.

00:06:33.180 --> 00:06:36.940
50달러짜리 비용 보고서라면 0.70 정도의 신뢰도로 충분할 수 있습니다.

00:06:37.200 --> 00:06:40.820
하지만 5만 달러짜리 구매 주문서 라면 0.98 정도는 되어야 합니다.

00:06:42.100 --> 00:06:44.140
비즈니스 위험과 일치시키는 것입니다.

00:06:44.300 --> 00:06:47.040
우리는 그동안 모든 데이터 포인트가 동일한 무게를 가진 것처럼 다뤄왔지만

00:06:47.040 --> 00:06:48.260
실제로는 그렇지 않습니다.

00:06:48.420 --> 00:06:50.600
확률적 설계를 사용하면 동일한 흐름 내에서도

00:06:50.600 --> 00:06:54.160
높은 위험이 따르는 결정과 낮은 위험의 결정을 다르게 처리할 수 있습니다.

00:06:54.400 --> 00:06:56.540
이제 완벽한 세상을 위해 구축하는 것이 아니라

00:06:56.540 --> 00:07:00.920
허용 가능한 불확실성의 범위를 정확히 파악하는 세상을 위해 구축하는 것입니다.

00:07:01.120 --> 00:07:04.520
점수를 마스터하고 나면 간극을 메우는 로직을 살펴볼 수 있습니다.

00:07:04.760 --> 00:07:07.540
퍼지 매칭, 퍼지 매칭, 과 의미론적, 시멘틱, 로직입니다.

00:07:07.540 --> 00:07:11.180
하지만 불확실성이 존재하는 중간지대의 데이터는 어떻게 처리해야 할까요?

00:07:11.340 --> 00:07:14.320
우선 정확한 일지, 이그젝트 매칭, 방식이 실패하고 있다는 점을 인정해야 합니다.

00:07:14.460 --> 00:07:16.320
맥락이 부족하기 때문에 실패하는 것입니다.

00:07:16.500 --> 00:07:19.800
기존 모델에서는 공급업체 이름의 마침표 하나만 틀려도 조회가 실패했습니다.

00:07:20.060 --> 00:07:23.700
조회로직은 사용자의 의도에는 관심이 없으며 오직 아스키간만 따지기 때문입니다.

00:07:23.880 --> 00:07:25.520
여기서 퍼지 매칭이 등장합니다.

00:07:25.760 --> 00:07:30.020
이는 유사도 점수를 계산하여 동일하지 않은 기록을 식별하고 연결하는 기술로

00:07:30.020 --> 00:07:32.560
IBM과 IBM 사이의 가교 역할을 합니다.

00:07:32.820 --> 00:07:34.920
그리고 그 영향력은 이론에 그치지 않습니다.

00:07:34.920 --> 00:07:39.220
연구에 따르면 퍼지 매칭을 구현하면 일치율을 최대 24%까지 높일 수 있습니다.

00:07:39.420 --> 00:07:43.720
이는 이전에는 거부되거나 사람이 직접 수정해야 했던 데이터의 24%를 의미합니다.

00:07:43.880 --> 00:07:46.900
대용량 환경에서는 수천 시간의 업무 시간을 절감하는 것과 같습니다.

00:07:47.220 --> 00:07:48.880
하지만 그 작동원리를 이해해야 합니다.

00:07:49.080 --> 00:07:50.760
이를 생각하는 두 가지 주요한 방법이 있습니다.

00:07:51.000 --> 00:07:52.380
첫째, 문자기반 로직입니다.

00:07:52.580 --> 00:07:54.860
이를 흔히 레벤슈타인 거리, 레벤슈타인 디스턴스라고 부릅니다.

00:07:55.040 --> 00:07:57.580
이는 한 문자열을 다른 문자열로 바꾸는데 필요한 편집 횟수를 계산합니다.

00:07:57.740 --> 00:07:59.300
모탈을 처리하는 데 아주 적합합니다.

00:07:59.300 --> 00:08:03.460
누군가 매니지먼트 대신 매니지라고 쓰면 시스템은 빠진 E와 A를 확인합니다.

00:08:03.580 --> 00:08:07.040
거리를 계산하여 두 단어가 거의 동일하다고 인식하는 것입니다.

00:08:07.240 --> 00:08:09.200
둘째, 의미론적 로직이 있습니다.

00:08:09.560 --> 00:08:10.840
여기서부터 흥미로워집니다.

00:08:11.020 --> 00:08:12.960
의미론적 로직은 철자에는 관심이 없습니다.

00:08:13.260 --> 00:08:14.380
중요한 것은 의미입니다.

00:08:14.600 --> 00:08:17.760
한 시스템에서는 커스터머라고 하고 다른 시스템에서는 클라이언트라고 한다면

00:08:17.760 --> 00:08:19.300
문자기반 매칭은 항상 실패합니다.

00:08:19.480 --> 00:08:21.860
하지만 의미론적 모델은 두 단어가 같은 의미임을 알고 있습니다.

00:08:22.140 --> 00:08:25.240
이것이 바로 문자를 매칭하는 방식에서 개념을 매칭하는 방식으로의 전환입니다.

00:08:25.240 --> 00:08:30.680
신뢰도 점수와 퍼지 매칭을 결합하면 비즈니스 데이터의 복잡한 현실을 다룰 수 있는 시스템이 만들어집니다.

00:08:30.820 --> 00:08:34.640
더 이상 사람이 오타를 낼 때 마다 중단되는 경직된 규칙에 얽매일 필요가 없습니다.

00:08:34.940 --> 00:08:37.640
여러분은 뉘앙스를 이해하는 시스템을 구축하게 되는 것입니다.

00:08:37.840 --> 00:08:43.240
이것이 바로 단순 자동화에서 진정한 디지털 지능으로 나아가며 자가수정 워크플로우를 구축하는 방법입니다.

00:08:43.460 --> 00:08:47.940
세계 최고의 퍼지 매칭을 사용하더라도 AI가 여전히 환각을 일으킨다는 현실을 직시해야 합니다.

00:08:48.180 --> 00:08:50.340
그것이 현재의 기술의 작동 방식입니다.

00:08:50.340 --> 00:08:55.480
최신 데이터에 따르면 가장 앞선 모델 조차 15에서 20%의 환각율을 보입니다.

00:08:55.640 --> 00:08:59.560
비즈니스 시스템을 구축할 때 5분의 1에 달하는 실패율을 무시할 수 없으며

00:08:59.560 --> 00:09:02.320
프롬프트 엔지니어링만으로 해결할 수는 없습니다.

00:09:02.620 --> 00:09:06.260
환각율 0%에 도달하는 것은 마술이 아님을 인정해야 합니다.

00:09:06.520 --> 00:09:08.800
그것은 의도적인 아키텍처 설계의 결과입니다.

00:09:09.020 --> 00:09:13.280
여기서 우리는 단순 자동화를 넘어 회복 탄력성을 갖춘 자가수정 워크플로우를 구축하기 시작합니다.

00:09:13.500 --> 00:09:16.660
우리는 이를 위해 이중 경로 검증 패턴이라 부르는 구조를 사용합니다.

00:09:16.660 --> 00:09:21.120
이것은 AI 위 창의적인 상상력이 실제 데이터를 망치지 않도록 방어막 역할을 합니다.

00:09:21.320 --> 00:09:23.960
현대적 아키텍트에게는 하나의 근본적인 원칙이 있습니다.

00:09:24.260 --> 00:09:26.920
절대로 거대 언어 모델에게 수학을 맡기지 마십시오.

00:09:27.080 --> 00:09:33.760
LLM은 소프트 추론 엔지니므로 의도를 파악하거나 복잡한 텍스트 더미에서 세부 정보를 찾는 데 탁월합니다.

00:09:34.020 --> 00:09:37.620
하지만 기본적인 산술 연산에 있어서는 통계적으로 신뢰할 수 없습니다.

00:09:37.960 --> 00:09:43.580
AI에게 송장해서 세 항목을 추출해 합계를 계산하라고 하면 사실상 시스템 실패를 자초하는 셈입니다.

00:09:43.580 --> 00:09:49.680
자가수정 설계에서는 지저분한 pdf에서 데이터를 추출하는 것과 같은 소프트 추론 작업에 LLM을 사용합니다.

00:09:49.840 --> 00:09:54.520
데이터를 확보한 후에는 이를 결정론적 시스템으로 넘겨 엄격한 제약 조건을 처리해야 합니다.

00:09:54.720 --> 00:09:58.900
더셈 작업은 파워 오토메이트 흐름이나 기본적인 규칙 엔진이 담당해야 합니다.

00:09:59.140 --> 00:10:02.620
세금을 확인하거나 통화 환율을 검증하는 작업도 마찬가지여야 합니다.

00:10:02.840 --> 00:10:09.380
LLM 이 합계를 500달러라고 주장하는데 계산 결과가 480달러라면 시스템이 실시간으로 환각을 포착한 것입니다.

00:10:09.620 --> 00:10:12.260
시스템은 중단되는 대신 복구 경로를 가동합니다.

00:10:12.260 --> 00:10:16.540
다른 프롬프트를 시도하거나 오류를 표시하여 사람이 검토하도록 할 수 있습니다.

00:10:16.780 --> 00:10:20.160
이것이 멈춰버리는 흐름과 스스로 치유하는 흐름의 차이입니다.

00:10:20.360 --> 00:10:24.020
우리는 로봇 프로세스 자동화, RPA 분야에서도 동일한 변화를 목격하고 있습니다.

00:10:24.260 --> 00:10:27.840
기존의 RPA는 화면에 정확한 좌표에 의존하기 때문에 매우 취약합니다.

00:10:28.040 --> 00:10:31.080
버튼이 왼쪽으로 3픽셀만 이동해도 봇 전체가 실패합니다.

00:10:31.340 --> 00:10:34.840
자가치유 RPA는 확률적 비전을 사용하여 이를 변화시킵니다.

00:10:35.020 --> 00:10:37.480
이제 봇은 특정 픽셀 좌표를 찾지 않습니다.

00:10:37.480 --> 00:10:41.360
대신 페이지 상단 근처에 있는 저장 아이콘처럼 생긴 버튼을 찾습니다.

00:10:41.620 --> 00:10:45.040
인터페이스가 바뀌면 보순 문맥을 활용해 즉시 적응합니다.

00:10:45.280 --> 00:10:49.340
새로운 네이아웃을 인식하고 자체 로직을 업데이트하여 작업을 완료합니다.

00:10:49.580 --> 00:10:56.500
이는 시스템이 잠재적 오류를 감지하고 사용자가 문제를 인식하기도 전에 해결책을 마련하는 복원력 있는 루프를 만듭니다.

00:10:56.700 --> 00:11:00.040
이러한 변화는 우리의 초점을 성공률에서 복구율로 옮겨놓습니다.

00:11:00.040 --> 00:11:05.640
우리는 ai를 완벽하게 만들려는 불가능한 시도를 멈추고 대신 시스템을 흔들림없게 만들기 시작합니다.

00:11:05.800 --> 00:11:09.340
이는 모든 거래마다 견제와 균형을 위한 계층을 구축하는 것입니다.

00:11:09.520 --> 00:11:12.840
ai를 쉽게 산만해지는 고속인턴처럼 다뤄야 합니다.

00:11:13.080 --> 00:11:18.900
수천 동의 이메일을 읽는 힘든 일은 맞기 돼 수석 감사관의 검증 없이 서명하게 해서는 안 됩니다.

00:11:19.240 --> 00:11:22.540
이 경우 당신의 결정 론적 코드가 바로 그 감사관입니다.

00:11:22.800 --> 00:11:29.620
사고와 계산을 분리함으로써 인간 언어의 복잡함을 처리하면서도 스위스 시계 같은 정밀함을 유지하는 시스템을 만듭니다.

00:11:29.620 --> 00:11:33.820
이것이 바로 ai를 테스트 단계를 넘어 비즈니스의 핵심으로 옮기는 방법입니다.

00:11:34.000 --> 00:11:37.780
모델을 신뢰하는 것이 아니라 모델 주변에 구축한 아키텍처를 신뢰하는 것입니다.

00:11:37.980 --> 00:11:42.300
모델이 가끔 실수하더라도 오류로 간주되지 않을 만큼 강력한 안전망을 만드세요.

00:11:42.520 --> 00:11:45.540
그것은 그저 자기 수정 주기에 또 다른 부분이 될 뿐입니다.

00:11:45.800 --> 00:11:53.080
실험실에서는 그럴듯해 보이지만 실제 운영 단계에서 가장 큰 병목현상은 ai가 아니라 인간이 개입해야 하는 현실입니다.

00:11:53.340 --> 00:11:58.720
실험실에서는 훌륭해 보이지만 실제 운영에서 가장 큰 병목현상은 ai가 아니라 바로 인간입니다.

00:11:58.720 --> 00:12:06.660
우리는 자동화를 흔히 인간과 기계 사이의 단순한 선택으로 이야기하지만 확률적 변화는 우리를 복잡한 중간지대로 몰아넣습니다.

00:12:06.900 --> 00:12:09.440
업계 지표는 꽤 냉정한 진실을 보여줍니다.

00:12:09.700 --> 00:12:14.100
ai 워크플로우의 약 50%는 완료되기 전에 여전히 전문가의 검토가 필요합니다.

00:12:14.300 --> 00:12:17.560
이것이 바로 우리가 파일럿 단계에서 운영 단계로 넘어갈 때 위기를 겪는 주된 이유입니다.

00:12:17.720 --> 00:12:21.060
수치를 보면 ai 파일럿 프로젝트의 88%가 1년 내에 실패합니다.

00:12:21.260 --> 00:12:23.200
기술이 고장나서 실패하는 것이 아닙니다.

00:12:23.200 --> 00:12:27.960
설계자들이 너무 이른 시기에 전체 작업의 100%를 자동화하려고 하기 때문에 실패하는 것입니다.

00:12:28.080 --> 00:12:33.700
깨끗한 테스트 데이터에서는 작동하는 시스템을 만들었지만 실제 부서의 마찰과 부딪히는 순간 로직이 무너지는 것입니다.

00:12:33.860 --> 00:12:37.120
인적 요소를 무시하면 검증 부담이라는 결과를 초래하게 됩니다.

00:12:37.380 --> 00:12:44.440
ai가 데이터 입력 시간을 10분 절약 해주더라도 팀이 결과를 신뢰하지 못해 검토에 50분을 더 쓴다면 사실 생산성은 떨어진 것입니다.

00:12:44.700 --> 00:12:47.040
여러분은 자산이 아닌 부채를 만든 셈입니다.

00:12:47.040 --> 00:12:51.320
2026년에 성공하는 설계는 검증 작업을 주요 기능으로 다룰 것입니다.

00:12:51.520 --> 00:12:54.300
그들은 사람의 검토를 시스템의 실패로 보지 않습니다.

00:12:54.560 --> 00:12:57.000
오히려 아키텍처의 필수적인 부분으로 봅니다.

00:12:57.260 --> 00:13:01.040
그들은 검토 비용을 첫날부터 투자 수익률 roi에 포함합니다.

00:13:01.280 --> 00:13:03.800
이를 실현하는 비결은 단계적 검토 로직입니다.

00:13:04.060 --> 00:13:06.880
이것이 정신을 잃지 않고 규모를 확장하는 방법입니다.

00:13:07.080 --> 00:13:09.320
확신도가 높은 거래는 조용히 처리됩니다.

00:13:09.560 --> 00:13:13.660
모델이 98% 확신하고 계산이 정확하다면 시스템은 그대로 진행합니다.

00:13:13.660 --> 00:13:17.960
하지만 앞서 언급한 노란색 영역처럼 확신도가 낮은 경우 에스컬레이션이 발생합니다.

00:13:18.100 --> 00:13:19.960
이는 사람의 역할을 완전히 바꿉니다.

00:13:20.140 --> 00:13:22.820
우리는 데이터 입력에서 데이터 감사로 나아가고 있습니다.

00:13:23.080 --> 00:13:26.500
구 모델에서 사람은 모든 타이핑과 클릭을 수행하는 엔진이었습니다.

00:13:26.700 --> 00:13:28.540
새로운 모델에서 사람은 관리자입니다.

00:13:28.820 --> 00:13:32.980
그들은 예외 상황을 처리하고 확률적 모델이 완전히 이해하지 못하는 민요한 차이를 제공합니다.

00:13:33.180 --> 00:13:35.340
팀 입장에서 이것이 어떤 느낌일지 생각해보세요.

00:13:35.660 --> 00:13:39.760
사람들은 실제로 어려운 5% 위 사례만 확인하면 된다는 것을 알 때 훨씬 더 몰입합니다.

00:13:39.980 --> 00:13:41.880
더 이상 반복 업무에 지루해하지 않습니다.

00:13:41.880 --> 00:13:44.500
그들은 어려운 사례의 복잡함에 도전의식을 느낍니다.

00:13:44.680 --> 00:13:47.440
하지만 이 일이 작동하려면 올바른 인터페이스를 구축해야 합니다.

00:13:47.640 --> 00:13:50.000
무언가 잘못되었다는 이메일만 보내서는 안 됩니다.

00:13:50.340 --> 00:13:52.240
나란히 비교하는 화면을 보여줘야 합니다.

00:13:52.500 --> 00:13:53.860
원본 문서를 보여주세요.

00:13:54.160 --> 00:13:58.560
AI가 추출한 내용을 보여주고 신뢰 점수가 떨어진 정확한 필드를 강조하세요.

00:13:58.800 --> 00:14:02.960
규모를 확장하려면 사람의 검토가 자동화의 약점이라고 생각하는 태도를 버려야 합니다.

00:14:03.220 --> 00:14:04.480
실제로는 정반대입니다.

00:14:04.760 --> 00:14:09.960
잘 통합된 사람은 확률적 시스템을 현실 세계에서 살아남을 만큼 강력하게 만듭니다.

00:14:09.960 --> 00:14:13.200
그것이 바로 자기교정 아키텍처의 최종계층입니다.

00:14:13.420 --> 00:14:14.700
에이전트 중심의 미래.

00:14:14.880 --> 00:14:17.980
우리는 에이전트 엔터프라이즈라는 새로운 지평을 바라보고 있습니다.

00:14:18.320 --> 00:14:21.300
이것이 우리가 오늘 논의한 모든 것의 논리적 종착점입니다.

00:14:21.560 --> 00:14:25.100
우리는 에이전트가 더 이상 단순한 스크립트나 기본 흐름에 머물지 않고

00:14:25.100 --> 00:14:27.660
인류 디지털 워커가 되는 세상으로 나아가고 있습니다.

00:14:27.960 --> 00:14:30.480
파워 플랫폼이 우리 눈앞에서 변화하고 있습니다.

00:14:30.800 --> 00:14:34.300
표준 앱 빌더에서 완전한 오케스트레이션 허브로 전환 중입니다.

00:14:34.540 --> 00:14:37.960
구 모델에서는 특정 문제를 해결하기 위해 특정 앱을 만들었습니다.

00:14:37.960 --> 00:14:42.200
하지만 에이전트 모델에서는 에이전트가 문제를 해결해주는 환경을 구축합니다.

00:14:42.400 --> 00:14:45.540
이러한 에이전트들은 정적인 단계 목록을 단순히 따르기만 하지 않습니다.

00:14:45.740 --> 00:14:48.380
그들은 환경을 관찰하고 자신의 확신 수준을 평가하며

00:14:48.380 --> 00:14:50.880
다음에 사용할 적절한 도구가 무엇인지 결정합니다.

00:14:51.100 --> 00:14:54.680
2026년이 되면 거버넌스는 2년 전과는 완전히 다른 모습일 것입니다.

00:14:54.860 --> 00:14:58.660
퍼뷰 나 센티널 같은 도구 들은 확률적 이상 탐지 방식으로 나아가고 있습니다.

00:14:59.020 --> 00:15:01.880
이제는 단순히 유출된 비밀번호만을 찾는 것이 아닙니다.

00:15:02.080 --> 00:15:05.400
대신 무언가 이상해 보이는 행동 패턴을 찾아내고 있습니다.

00:15:05.400 --> 00:15:10.660
데이터 추출에 사용하는 것과 동일한 유사성 논리를 이제 전체 테넌트 보완에 적용하는 것입니다.

00:15:10.860 --> 00:15:12.220
이러한 변화는 연구적입니다.

00:15:12.460 --> 00:15:17.140
경직된 조건문 논리에 매달리는 사람들은 결국 고장난 시스템과 불만 가득한 팀을 관리하게 될 뿐입니다.

00:15:17.300 --> 00:15:22.420
이런 환경을 견딜 수 없게 설계된 유리로 된 집을 보수하느라 끊임없는 유지보수의 굴레에 갇히게 될 것입니다.

00:15:22.640 --> 00:15:25.300
에이전트 기반 기업은 하나의 깨달음에서 시작됩니다.

00:15:25.520 --> 00:15:28.560
신뢰할 수 있는 결과를 얻기 위해 모든 변수를 통제할 필요는 없습니다.

00:15:28.940 --> 00:15:30.820
우리는 오직 아키텍처만 통제하면 됩니다.

00:15:30.820 --> 00:15:35.800
우리의 역할은 에이전트가 경계 안에서 작동할 수 있도록 인계각과 가드레일을 설정하는 것입니다.

00:15:35.960 --> 00:15:38.520
이 세계에서 비즈니스 로직은 유연성을 갖게 됩니다.

00:15:38.760 --> 00:15:43.840
개발자가 코드를 단 한 줄도 수정할 필요 없이 새로운 공급업체나 다양한 문서 형식을 처리할 수 있게 확장됩니다.

00:15:44.060 --> 00:15:46.100
이것이 바로 로우코드의 진정한 가치입니다.

00:15:46.280 --> 00:15:49.240
구문 작성 속도가 아닌 생각의 속도로 움직일 수 있는 능력입니다.

00:15:49.460 --> 00:15:51.520
하지만 그곳에 도달하려면 오늘부터 시작해야 합니다.

00:15:51.740 --> 00:15:55.480
완벽한 세상을 위해 구축하는 것을 멈추고 우리가 실제로 살고 있는 복잡한 세상을 위한 구축을 시작하십시오.

00:15:55.600 --> 00:15:57.120
불확실성을 받아들여야 합니다.

00:15:57.360 --> 00:15:58.600
구현도전 과제입니다.

00:15:58.600 --> 00:16:00.340
이번 주 여러분의 숙제입니다.

00:16:00.540 --> 00:16:02.420
가장 실패가 잦은 흐름을 찾아보세요.

00:16:02.620 --> 00:16:06.560
가장 복잡한 것을 고르지 말고 잘못된 데이터 때문에 가장 자주 멈추는 흐름을 찾으세요.

00:16:06.740 --> 00:16:08.520
목표는 데이터를 수정하는 것이 아닙니다.

00:16:08.720 --> 00:16:11.740
사용자 나 공급업체가 무엇을 보낼지는 우리가 통제할 수 없습니다.

00:16:12.040 --> 00:16:15.340
그 현실과 싸우는 대신 신뢰도 인계값을 추가해보십시오.

00:16:15.480 --> 00:16:18.800
AI 빌더나 LLM 액션에 들어가서 확률 점수를 확인하세요.

00:16:19.040 --> 00:16:20.640
간단한 조건을 만드십시오.

00:16:20.800 --> 00:16:24.380
신뢰도 점수가 85% 미만이면 흐름이 중단되지 않게 하세요.

00:16:24.380 --> 00:16:28.400
해당 사례를 검토 폴더 나 쉐어 포인트 목록으로 보내 수동으로 확인하게 하십시오.

00:16:28.600 --> 00:16:30.580
성공률이 어떻게 변하는지 지켜보십시오.

00:16:30.720 --> 00:16:35.160
모든 입력값이 완벽할 것이라는 가정을 벌이는 순간 시스템의 스트레스가 사라지는 것을 볼 수 있을 것입니다.

00:16:35.320 --> 00:16:38.780
이러한 사고의 전환이 도움이 되었다면 링크딘에서 저 미르코 피터스를 팔로우하세요.

00:16:39.000 --> 00:16:41.980
저는 이러한 아키텍처 패턴에 대한 심층 분석을 지속적으로 공유하고 있습니다.

00:16:42.220 --> 00:16:45.100
특히 지금 흐름이 자주 끊기고 있다면 이 내용을 팀과 공유하십시오.

00:16:45.220 --> 00:16:48.160
유리로 된 집을 짓는 것을 멈추고 위도를 가지고 구축하기 시작해야 합니다.

00:16:48.360 --> 00:16:51.880
이것이 바로 그 기법이며 실천하기 시작하면 다운타임이 절반으로 줄어듭니다.

00:16:51.880 --> 00:16:55.520
전문가들이 사용하는 고급 버전을 원하신다 면 다음 영상을 확인해보세요.

00:16:55.720 --> 00:16:57.600
더 많은 튜토리얼을 보려면 구독하세요.

00:16:57.840 --> 00:17:01.480
데이터의 복잡한 현실과 싸우지 말고 그에 맞춰 설계를 시작하세요.

00:17:01.720 --> 00:17:06.140
신뢰도 점수를 사용하면 취약한 흐름을 실제로 작동하는 탄탄한 시스템으로 바꿀 수 있습니다.

00:17:06.360 --> 00:17:07.660
하지만 중요한 점이 있습니다.

00:17:07.960 --> 00:17:10.280
모델은 올바르게 구축했을 때만 제대로 작동합니다.

00:17:10.460 --> 00:17:14.900
코파일러 스튜디오에서 이를 설정하는 정확한 방법을 알고 싶다면 지금 바로 다음 영상을 시청하세요.

00:17:14.900 --> 00:17:20.180
이 영상이 AI에 대한 여러분의 생각을 바꾸었다면 링크딘해서 저를 팔로우하거나 마스터 더 뉴모델을 구독하세요.