생성형 AI 워크플로우가 고전적 머신러닝과 닮아 보이지만 실제로는 시간 배분과 실행 세부가 크게 다르며, 도구 난립·프롬프트 비대화·불투명한 파이프라인·피드백 시스템 부재·이해관계자 소통 부족 같은 새로운 기술 부채가 빠르게 쌓일 수 있음을 설명한다.
고전적 머신러닝과 생성형 AI 워크플로우를 넓게 비교해 보면, 전반적인 워크플로우 단계는 두 분야에서 비슷하게 유지됩니다. 둘 다 데이터 수집, 특성 공학, 모델 최적화, 배포, 평가 등이 필요합니다. 하지만 실행 세부 사항과 시간 배분은 근본적으로 다릅니다. 무엇보다도 생성형 AI는 제대로 관리하지 않으면 빠르게 누적될 수 있는 고유한 기술 부채의 원천을 도입합니다. 예를 들면 다음과 같습니다.
이 글에서는 이러한 기술 부채의 각 형태를 차례대로 다룹니다. 궁극적으로 고전적 ML에서 생성형 AI로 전환하는 팀은 이러한 새로운 부채 원천을 인지하고 개발 관행을 그에 맞게 조정해야 합니다. 즉, 고전적 ML 프로젝트에서 지배적이었던 데이터 정제와 특성 공학보다 평가, 이해관계자 관리, 주관적 품질 모니터링, **계측(instrumentation)**에 더 많은 시간을 투입해야 합니다.
현재 분야의 위치를 이해하려면, 생성형 AI 워크플로우가 고전적 머신러닝 문제에 사용하는 워크플로우와 어떻게 다른지 비교해 보는 것이 유용합니다. 아래는 고수준 개요입니다. 이 비교에서 드러나듯, 큰 흐름의 단계는 동일하지만 실행 디테일의 차이 때문에 강조되는 단계가 달라집니다. 또한 생성형 AI는 새로운 형태의 기술 부채를 도입하며, 이는 운영 환경(production)에서 시스템을 유지하는 방식에 영향을 줍니다.
| 워크플로우 단계 | 고전적 ML | 생성형 AI |
|---|---|---|
| 데이터 수집 | 수집 데이터는 소매 판매나 장비 고장처럼 현실 세계의 사건을 나타냄. CSV, JSON 같은 구조화된 형식이 자주 사용됨. | 수집 데이터는 언어 모델이 관련성 높은 응답을 제공하도록 돕는 문맥적 지식을 나타냄. 구조화된 데이터(종종 실시간 테이블)와 비정형 데이터(이미지, 비디오, 텍스트 파일)를 모두 사용할 수 있음. |
| 특성 공학/데이터 변환 | 데이터 변환은 문제 공간을 더 잘 반영하도록 새 특성을 만들거나(예: 타임스탬프에서 평일/주말 특성 생성), 모델이 데이터에 더 잘 맞도록 통계적 변환을 수행함(예: k-means를 위해 연속 변수를 표준화하거나, 왜도 데이터에 로그 변환을 적용해 정규분포에 가깝게 만듦). | 비정형 데이터의 경우 변환은 청킹(chunking), 임베딩 표현 생성, (가능하면) 청크에 제목·태그 등 메타데이터 추가를 포함함. 구조화 데이터의 경우 LLM이 테이블 조인을 고려하지 않도록 테이블을 비정규화(denormalize)하는 작업이 포함될 수 있음. 테이블과 컬럼 메타데이터 설명을 추가하는 것도 중요함. |
| 모델 파이프라인 설계 | 보통 3단계의 기본 파이프라인으로 구성: (1) 전처리(표준화, 정규화, 원-핫 인코딩 등 통계적 컬럼 변환) (2) 모델 예측(전처리된 데이터를 모델에 전달해 출력 생성) (3) 후처리(대개 비즈니스 로직 필터 등 추가 정보로 출력 보강) | 보통 질의 재작성(query rewriting), 어떤 형태의 정보 검색(retrieval), 경우에 따라 도구 호출(tool calling), 마지막에 안전성 점검을 포함함. 파이프라인이 훨씬 복잡하고 데이터베이스·API 통합 같은 더 복잡한 인프라를 포함하며, 때로 그래프 형태 구조로 다뤄짐. |
| 모델 최적화 | 교차검증, 그리드 서치, 랜덤 서치 같은 방법으로 하이퍼파라미터 튜닝을 수행함. | temperature, top-k, top-p 같은 하이퍼파라미터를 바꾸기도 하지만, 대부분의 노력은 모델 행동을 유도하는 프롬프트 튜닝에 쓰임. LLM 체인이 여러 단계를 포함할 수 있으므로, AI 엔지니어는 복잡한 작업을 더 작은 구성요소로 분해하는 실험도 수행함. |
| 배포 | 모델은 LLM 같은 파운데이션 모델보다 훨씬 작음. 전체 ML 애플리케이션을 CPU에 호스팅할 수 있으며 GPU가 필요하지 않은 경우가 많음. 모델 버전 관리, 모니터링, 계보(lineage)가 중요. 예측은 복잡한 체인/그래프를 거의 필요로 하지 않으므로 보통 트레이스를 사용하지 않음. | 파운데이션 모델은 매우 커서 중앙 GPU에 호스팅하고 여러 사용자 대면 AI 애플리케이션에 API로 제공하기도 함. 애플리케이션은 파운데이션 모델 API를 감싸는 “래퍼(wrapper)”로 동작하며 비교적 작은 CPU에서 호스팅됨. 애플리케이션 버전 관리, 모니터링, 계보가 중요. 또한 LLM 체인/그래프가 복잡할 수 있으므로 쿼리 병목과 버그를 식별하기 위한 적절한 트레이싱이 필요함. |
| 평가 | 분류는 F1, 회귀는 RMSE 같은 정의된 정량 지표로 성능 평가 가능. | LLM 출력의 정당성은 요약·번역 품질처럼 주관적 판단에 의존. 따라서 보통 정량 지표보다 가이드라인을 통해 응답 품질을 판단함. |
가격 예측 프로젝트와 도구 호출 에이전트를 만드는 프로젝트를 병행해 본 경험에서, 모델 개발과 배포 단계에서 큰 차이가 있음을 확인했습니다.
내부 개발 루프(inner development loop)는 보통 머신러닝 개발자가 모델 파이프라인을 만들고 다듬는 과정에서 거치는 반복적 프로세스를 뜻합니다. 일반적으로 운영 테스트와 모델 배포 이전에 이루어집니다.
아래는 고전적 ML과 GenAI 전문가가 이 단계에서 시간을 어떻게 다르게 쓰는지입니다.
고전적 ML 모델 개발에서 시간을 잡아먹는 요인
데이터 수집과 특성 개선: 고전적 머신러닝 프로젝트에서는 반복적으로 특성과 입력 데이터를 개선하는 데 대부분의 시간을 씁니다. 여러 팀이 관여하거나 수동으로 관리하기 어려울 정도로 특성이 많을 때는 Databricks Feature Store 같은 특성 관리/공유 도구를 사용합니다.
반면 평가는 단순합니다. 모델을 실행해 정량 지표가 개선됐는지 확인한 뒤, 다시 더 나은 데이터 수집과 특성 설계가 모델을 어떻게 향상시킬지 고민하면 됩니다. 예컨대 가격 예측 모델의 경우, 팀은 대부분의 오예측이 데이터 이상치(outlier)를 고려하지 못한 데서 비롯됨을 관찰했습니다. 이후 모델이 그 패턴을 식별할 수 있도록 이러한 이상치를 표현하는 특성을 어떻게 포함할지 고민해야 했습니다.
생성형 AI 모델 및 파이프라인 개발에서 시간을 잡아먹는 요인
평가: 생성형 AI 프로젝트에서는 데이터 수집/변환과 평가 사이의 상대적 시간 배분이 뒤집힙니다. 데이터 수집은 대개 모델에 충분한 문맥을 제공하기 위한 것으로, 비정형 지식 베이스 문서나 매뉴얼 형태일 수 있습니다. 이런 데이터는 광범위한 정제가 필요하지 않습니다. 하지만 평가는 훨씬 더 주관적이고 복잡해 결과적으로 더 많은 시간이 듭니다. 모델 파이프라인뿐 아니라 평가 세트도 반복적으로 개선해야 합니다. 또한 고전적 ML보다 엣지 케이스를 고려하는 데 더 많은 시간을 씁니다.
예를 들어 초기 평가 질문 10개는 사용자가 지원 봇에 물어볼 수 있는 질문의 전체 스펙트럼을 커버하지 못할 수 있습니다. 이 경우 더 많은 평가를 수집해야 합니다. 또는 설정해 둔 LLM 판정자(judge)가 너무 엄격해 관련 답변이 테스트에서 탈락한다면, 탈락을 막기 위해 판정자 프롬프트를 재작성해야 할 수도 있습니다. MLflow의 Evaluation Datasets는 항상 정확히 동작해야 하는 “골든 세트(golden set)” 예제를 버전 관리하고 개발·감사(audit)하는 데 유용합니다.
이해관계자 관리: 또한 응답 품질은 최종 사용자 입력에 좌우되므로, 엔지니어는 비즈니스 최종 사용자 및 PM과 더 많은 미팅을 하면서 요구사항을 수집·우선순위화하고 사용자 피드백을 바탕으로 반복 개선합니다. 역사적으로 고전적 ML은 (예: 시계열 예측처럼) 광범위하게 최종 사용자 대면이 아니었거나 비기술 사용자에게 덜 노출된 경우가 많아, 생성형 AI의 제품 관리 요구는 훨씬 큽니다.
응답 품질 피드백 수집은 Databricks Apps에 간단한 UI를 호스팅하고 MLflow Feedback API를 호출하는 방식으로 할 수 있습니다. 피드백은 MLflow Trace와 MLflow Evaluation Dataset에 추가되어, 피드백과 모델 개선 사이의 선순환을 만들 수 있습니다.
다음 도표는 모델 개발 루프에서 고전적 ML과 생성형 AI의 시간 배분을 비교합니다.
모델 개발 루프와 달리, 모델 배포 루프는 모델 성능 최적화에 초점을 두지 않습니다. 대신 엔지니어는 운영 환경에서의 체계적 테스트, 배포, 모니터링에 집중합니다.
이 단계에서 개발자는 프로젝트 업데이트를 쉽게 하기 위해 설정을 YAML 파일로 옮길 수 있습니다. 또한 Pandas 대신 PySpark 같은 더 견고한 프레임워크를 사용해 정적 데이터 처리 파이프라인을 스트리밍 방식으로 리팩터링할 수도 있습니다. 마지막으로 모델 품질을 유지하기 위한 테스트, 모니터링, 피드백 프로세스를 어떻게 설정할지 고려해야 합니다.
이 시점에서는 자동화가 필수이며, CI/CD는 협상 불가능한 요구사항입니다. Databricks에서 데이터 및 AI 프로젝트의 CI/CD를 관리하기 위해 보통 Databricks Asset Bundles를 선택합니다. Asset Bundles는 잡과 파이프라인 같은 Databricks 리소스를 소스 파일로 기술할 수 있게 하고, 프로젝트 소스 파일과 함께 메타데이터를 포함할 수 있는 방법을 제공합니다.
모델 개발 단계와 마찬가지로, 이 단계에서도 생성형 AI와 고전적 ML 프로젝트에서 시간이 가장 많이 드는 활동은 서로 다릅니다.
고전적 ML 모델 배포에서 시간을 잡아먹는 요인
리팩터링: 고전적 머신러닝 프로젝트에서 노트북 코드는 상당히 지저분해질 수 있습니다. 서로 다른 데이터셋·특성·모델 조합을 계속 테스트하고, 폐기하고, 다시 조합하기 때문입니다. 그 결과 코드를 더 견고하게 만들기 위해 노트북 코드를 리팩터링하는 데 상당한 노력이 필요할 수 있습니다. (예: Databricks Asset Bundles MLOps Stacks 템플릿)처럼 정해진 코드 저장소 폴더 구조는 이러한 리팩터링에 필요한 스캐폴딩을 제공할 수 있습니다.
리팩터링 활동 예시는 다음과 같습니다.
for 루프 제거)품질 모니터링: 품질 모니터링도 시간이 많이 드는 부분인데, 데이터 오류가 다양한 형태로 나타나며 탐지하기 어렵기 때문입니다. 특히 Shreya Shankar 외 연구진은 논문 “Operationalizing Machine Learning: An Interview Study,”에서 “데이터 포인트의 일부 특성이 null인 것 같은 소프트 오류는 덜 치명적이며 여전히 합리적인 예측을 산출할 수 있어, 포착하고 정량화하기 어렵다”고 지적합니다. 게다가 오류 유형마다 필요한 대응이 다르고, 적절한 대응을 결정하기가 항상 쉽지는 않습니다.
추가로, 서로 다른 종류의 모델 드리프트(특성 드리프트, 데이터 드리프트, 라벨 드리프트 등)를 서로 다른 시간 단위(일/주/월)로 측정해야 하므로 복잡성이 증가합니다. 이를 쉽게 하기 위해 개발자는 Databricks Data Quality Monitoring을 사용해 모델 품질 지표, 입력 데이터 품질, 모델 입력과 예측의 잠재적 드리프트를 통합 프레임워크에서 추적할 수 있습니다.
생성형 AI 모델 배포에서 시간을 잡아먹는 요인
품질 모니터링: 생성형 AI에서도 모니터링이 상당한 시간을 차지하지만 이유가 다릅니다.
실시간 요구사항: 이탈 예측, 가격 예측, 재입원 예측 같은 고전적 ML 프로젝트는 배치 모드로 예측을 제공할 수 있으며 하루/주/월 1회 실행하는 식입니다. 반면 많은 생성형 AI 프로젝트는 가상 지원 에이전트, 실시간 전사 에이전트, 코딩 에이전트 같은 실시간 애플리케이션입니다. 따라서 실시간 모니터링 도구를 구성해야 합니다. 즉 실시간 엔드포인트 모니터링, 실시간 추론 분석 파이프라인, 실시간 알림이 필요합니다.
또한 Databricks AI Gateway 같은 API 게이트웨이를 설정해 LLM API에 대한 가드레일 점검을 수행하면 안전성과 데이터 프라이버시 요구사항을 지원할 수 있습니다. 이는 오프라인 프로세스로 수행되던 전통적 모델 모니터링과는 다른 접근입니다.
주관적 평가: 앞서 언급했듯 생성형 AI 애플리케이션 평가는 주관적입니다. 배포 엔지니어는 추론 파이프라인에서 주관적 피드백 수집을 어떻게 운영화할지 고려해야 합니다. 이는 모델 응답에 대해 LLM 판정자 평가를 수행하거나, 일부 응답을 선별해 도메인 전문가가 평가하도록 노출하는 형태가 될 수 있습니다. 독점(proprietary) 모델 제공자는 시간이 지나며 모델을 최적화하므로, 그들의 “모델”은 사실상 회귀(regression)가 발생할 수 있는 서비스입니다. 따라서 평가 기준은 (자가 학습 모델처럼) 모델 가중치가 고정되어 있지 않다는 점을 고려해야 합니다.
자유형 피드백과 주관적 평점 제공 능력이 핵심이 됩니다. Databricks Apps와 MLflow Feedback API 같은 프레임워크는 이런 피드백을 수집하고 특정 LLM 호출과 연결해 주는 간단한 사용자 인터페이스를 가능하게 합니다.
테스트: 생성형 AI 애플리케이션에서 테스트는 다음 이유로 더 시간이 많이 듭니다.
아직 해결되지 않은 과제: 생성형 AI 애플리케이션 자체는 점점 더 복잡해지지만, 평가와 테스트 프레임워크는 아직 이를 따라잡지 못했습니다. 테스트를 어렵게 만드는 시나리오는 다음과 같습니다.
이 복잡성을 다루는 첫 단계는 보통 에이전트 출력의 트레이스를 가능한 한 정확하게 캡처하는 것입니다(도구 호출, 추론, 최종 응답의 실행 히스토리). 자동 트레이스 캡처와 수동 계측을 조합하면 에이전트 상호작용의 전체 범위를 커버하는 데 필요한 유연성을 얻을 수 있습니다. 예컨대 어떤 함수든 입력과 출력을 캡처할 수 있도록 MLflow Traces의 trace 데코레이터를 사용할 수 있습니다. 동시에 특정 코드 블록 내에서 커스텀 MLflow Traces 스팬(span)을 만들어 더 세밀한 작업을 로깅할 수도 있습니다.
계측을 통해 에이전트 출력으로부터 신뢰할 수 있는 단일 진실 공급원(source of truth)을 집계한 뒤에야, 개발자는 실패 모드를 식별하고 그에 맞는 테스트를 설계할 수 있습니다.
사람의 피드백 통합: 품질을 평가할 때 이 입력을 통합하는 것은 매우 중요합니다. 하지만 일부 활동은 시간이 많이 듭니다. 예를 들면:
보통 에이전트가 어떻게 응답해야 하는지에 대한 공통 루브릭을 만들려면 대면 논의와 워크숍이 필요합니다. 사람 주석자들의 기준이 정렬(alignment)된 뒤에야, MLflow의 make_judge API나 SIMBAAlignmentOptimizer 같은 함수를 사용해 그 평가를 LLM 기반 판정자에 신뢰성 있게 통합할 수 있습니다.
기술 부채는 개발자가 장기적 유지보수성을 희생하고 빠르고 허술한 해결책을 구현할 때 쌓입니다.
고전적 ML의 기술 부채
Dan Sculley 외 연구진은 이러한 시스템이 축적할 수 있는 기술 부채 유형을 훌륭하게 요약했습니다. 논문 “Machine Learning: The High-Interest Credit Card of Technical Debt,”에서 이를 크게 세 가지로 분류합니다.
생성형 AI는 눈에 잘 띄지 않는 새로운 형태의 기술 부채를 도입합니다. 이 절에서는 이 숨은 기술 부채의 원천을 살펴봅니다.
도구는 LLM의 역량을 확장하는 강력한 방법입니다. 하지만 사용하는 도구 수가 늘어날수록 관리가 어려워질 수 있습니다.
도구 난립은 단지 발견 가능성(discoverability)과 재사용 문제만이 아니라, 생성형 AI 시스템의 품질에도 악영향을 줄 수 있습니다. 도구가 많아지면 두 가지 핵심 실패 지점이 나타납니다.
도구 난립에 대한 가장 깔끔한 해법은 팀이 사용하는 도구를 전략적으로 최소화하는 것입니다.
하지만 적절한 거버넌스 전략은 더 많은 팀이 GenAI를 프로젝트와 시스템에 통합할수록, 다수의 도구와 접근을 확장 가능하게 관리하는 데 도움이 됩니다. Databricks의 Unity Catalog와 AI Gateway는 이런 규모를 위해 구축된 제품입니다.
최신 모델은 수 페이지 분량의 지시문도 처리할 수 있지만, 지나치게 복잡한 프롬프트는 지시 간 충돌이나 오래된 정보 같은 문제를 초래할 수 있습니다. 특히 프롬프트가 편집되지 않고, 서로 다른 도메인 전문가나 개발자에 의해 시간이 지날수록 계속 덧붙여지는 경우에 그렇습니다.
서로 다른 실패 모드가 나타나거나 새로운 질의가 범위에 추가될 때마다, LLM 프롬프트에 지시를 계속 더하고 싶은 유혹이 생깁니다. 예를 들어 프롬프트가 처음에는 재무 관련 질문 처리 지시로 시작했다가, 이후 제품, 엔지니어링, 인사 관련 질문으로까지 분기될 수 있습니다.
소프트웨어 공학에서 “갓 클래스(god class)”가 좋지 않아 분해해야 하듯, 메가 프롬프트도 더 작은 프롬프트로 분리해야 합니다. 실제로 Anthropic도 프롬프트 엔지니어링 가이드에서 이를 언급합니다. 일반적으로 길고 복잡한 프롬프트 하나보다 여러 개의 작은 프롬프트를 두는 편이 명확성, 정확성, 문제 해결에 도움이 됩니다.
프레임워크는 프롬프트 버전을 추적하고 기대 입력/출력을 강제함으로써 프롬프트를 관리 가능하게 만들 수 있습니다. 프롬프트 버전 관리 도구의 예로는 MLflow Prompt Registry가 있으며, Databricks에서 실행 가능한 DSPy 같은 프롬프트 최적화 도구는 프롬프트를 개별 또는 전체로 최적화할 수 있는 자가 포함(self-contained) 모듈로 분해하는 데 도움이 됩니다.
최근 트레이싱이 주목받는 데에는 이유가 있습니다. 대부분의 LLM 라이브러리와 추적 도구는 LLM 체인의 입력과 출력을 트레이싱하는 기능을 제공합니다. 응답이 에러—악명 높은 “죄송하지만 그 질문에는 답할 수 없습니다”—로 돌아올 때, 중간 LLM 호출의 입력과 출력을 살펴보는 것은 근본 원인을 특정하는 데 필수적입니다.
저는 한 애플리케이션에서 SQL 생성이 워크플로우에서 가장 문제가 되는 단계일 거라고 처음에는 가정했습니다. 하지만 트레이스를 검사해 보니 다른 이야기가 나왔습니다. 가장 큰 오류 원천은 실제로 질의 재작성 단계였습니다. 이 단계에서 우리는 사용자 질문의 엔터티를 데이터베이스 값과 일치하는 엔터티로 업데이트했습니다. LLM은 재작성이 필요 없는 질의를 재작성하거나, 원래 질의에 온갖 추가 정보를 마구 끼워 넣기 시작했습니다. 이는 곧이어 진행되는 SQL 생성 과정을 정기적으로 망가뜨렸습니다. 트레이싱은 문제를 빠르게 식별하는 데 도움이 됐습니다.
올바른 LLM 호출을 트레이싱하는 데는 시간이 걸릴 수 있습니다. 기본 제공 트레이싱을 도입하는 것만으로는 충분하지 않습니다. MLflow Traces 같은 프레임워크를 사용해 관측 가능성(observability)을 갖추도록 앱을 적절히 계측하는 것이 에이전트 상호작용을 더 투명하게 만드는 첫 단계입니다.
LLM이 놀라운 이유는 몇 개의 간단한 프롬프트를 주고 결과를 체인으로 엮으면, 뉘앙스와 지시를 매우 잘 이해하는 것처럼 보이는 무언가가 나오기 때문입니다. 하지만 사용자 피드백으로 응답을 그라운딩하지 않은 채로 이 길을 너무 멀리 가면, 품질 부채가 빠르게 쌓일 수 있습니다. 가능한 한 빨리 “데이터 플라이휠(data flywheel)”을 만드는 것이 도움이 되며, 이는 다음 세 단계로 구성됩니다.
스포츠 통계를 질의하기 위한 텍스트-투-SQL 애플리케이션을 개발하면서, 사람 피드백의 중요성을 다시금 깨달았습니다. 도메인 전문가는 스포츠 팬이 데이터와 어떻게 상호작용하길 원하는지 설명해 주었고, 무엇을 중요하게 여기는지 명확히 하며, 스포츠를 거의 보지 않는 저라면 절대로 떠올리지 못했을 통찰을 제공했습니다. 그들의 입력이 없었다면, 제가 만든 애플리케이션은 사용자의 요구를 충족하지 못했을 가능성이 큽니다.
사람 피드백을 수집하는 일은 대단히 가치가 있지만, 대개 끔찍할 정도로 시간이 많이 듭니다. 먼저 도메인 전문가와 시간을 잡아야 하고, 전문가 간 차이를 조정하기 위한 루브릭을 만들고, 피드백을 평가해 개선점을 도출해야 합니다. 또한 피드백 UI가 비즈니스 사용자가 접근할 수 없는 환경에 호스팅되어 있다면, 적절한 접근 권한을 제공받기 위해 IT 관리자와 계속 조율하는 과정이 끝이 안 보이는 일처럼 느껴질 수 있습니다.
최종 사용자, 비즈니스 스폰서, 인접 팀과 정기적으로 상의하며 올바른 것을 만들고 있는지 확인하는 일은 모든 종류의 프로젝트에서 기본 중의 기본입니다. 그러나 생성형 AI 프로젝트에서는 이해관계자 커뮤니케이션이 그 어느 때보다 중요합니다.
왜 잦고 밀도 높은(high-touch) 커뮤니케이션이 중요한가:
생성형 AI 프로젝트에서 다뤄야 할 다른 형태의 기술 부채도 많습니다. 예를 들어 적절한 데이터 접근 제어를 강제하거나, 안전 관리 및 프롬프트 인젝션 방지를 위한 가드레일을 두거나, 비용 폭증을 방지하는 것 등이 있습니다. 여기에는 가장 중요해 보이고, 쉽게 간과될 수 있는 항목만 포함했습니다.
고전적 ML과 생성형 AI는 동일한 기술 영역의 서로 다른 변주입니다. 둘의 차이를 인지하고, 그 차이가 솔루션을 구축·유지하는 방식에 미치는 영향을 고려하는 것이 중요하지만, 어떤 진실은 변하지 않습니다. 소통은 여전히 격차를 메우고, 모니터링은 여전히 재앙을 막으며, 장기적으로는 깔끔하고 유지보수 가능한 시스템이 혼란스러운 시스템보다 더 뛰어난 성과를 냅니다.
조직의 AI 성숙도를 평가해 보고 싶으신가요? 가이드를 읽어보세요: AI 가치 실현: 기업을 위한 AI 준비도 가이드.