Yuri Gubin, DataArt CTO – 인터뷰 시리즈

Yuri Gubin, DataArt CTO는 DataArt에서 18년 이상 근무한 베테랑 기술 임원 겸 소프트웨어 아키텍트로, 소프트웨어 아키텍처, 솔루션 아키텍처, 클라우드 기술, 혁신, 그리고 경영 리더십을 아우르는 역할을 거쳐 2026년 3월에 최고 기술 책임자(Chief Technology Officer)로 임명되었습니다. 그의 업무는 금융 서비스, 의료, 여행, 사물인터넷(IoT) 등 다양한 산업 분야에서 복잡한 기술 과제를 해결하는 데 초점을 맞추었으며, 특히 클라우드 컴퓨팅, AI, 데이터 플랫폼, 엔터프라이즈 소프트웨어 아키텍처에 전문성을 가지고 있습니다. CTO가 되기 전, Gubin은 5년 이상 DataArt의 최고 혁신 책임자(Chief Innovation Officer)로 근무했으며 2021년부터 회사의 파트너 이사회(Board of Partners) 구성원으로 활동하고 있습니다. 그는 또한 Forbes Technology Council의 전문 회원으로 AI 및 클라우드 컴퓨팅 전문가 그룹에 참여하고 있으며, Girls Who Code의 기술 고문으로서 아키텍처, 데이터 보호, 플랫폼 거버넌스 및 기술 정책에 대해 조언하고 있습니다. DataArt는 현재 그를 뉴욕에 기반을 둔 최고 기술 책임자로 명시하고 있습니다.

DataArt는 1997년 뉴욕에서 설립된 글로벌 소프트웨어 엔지니어링 및 데이터·AI 전환 회사입니다. 이 회사는 20개국 이상에서 활동하는 6,000명 이상의 기술 전문가로 성장했으며 400개가 넘는 고객에게 인공지능 및 머신러닝, 데이터 및 분석, 클라우드 전환, 맞춤형 소프트웨어 엔지니어링, 사이버보안, 레거시 현대화 등을 포함한 서비스를 제공하고 있습니다. DataArt는 금융 서비스, 의료·생명과학, 여행, 미디어·엔터테인먼트, 소매 등 다양한 분야에서 활동하며 AWS, Google Cloud, Microsoft Azure, Snowflake, Databricks와 같은 플랫폼과 기술 파트너십을 유지하고 있습니다. 2025년에 회사는 데이터 및 AI 역량에 1억 달러 규모의 3년 투자 계획을 발표했으며, 2026년에는 AI 에이전트, 재사용 가능한 가속기, 거버넌스, 보안 및 컴플라이언스를 기업 소프트웨어 개발에 통합하도록 설계된 AI 기반 운영 모델인 Artisyn을 출시했습니다.

DataArt에서 거의 20년 동안 근무하시면서 소프트웨어 아키텍트와 솔루션 아키텍트에서 최고 혁신 책임자, 그리고 현재 CTO까지 성장하셨습니다. 그 과정에서 어떻게 진정으로 변혁적인 기술을 과대광고의 흐름과 구분하시게 되었으며, 오늘날 AI에 대한 귀하의 ‘회의적 낙관주의’에 어떤 영향을 미쳤나요?

우리는 수년간 클라우드와 모바일의 부상, 다양한 세대의 AI, 자동화, DevOps 및 SRE 등 여러 물결을 목격해 왔으며, 그 동안 저는 이러한 주제들에 대해 코딩하고, 아키텍처를 설계하며, 고객에게 조언을 제공해 왔습니다. 제가 깨달은 점은 기술을 사용하면 거의 모든 것을 할 수 있고 기술 자체가 매우 강력하지만, 세부 사항에 문제가 숨어 있으며 이를 올바르게 이해하고 있어야만 의미 있게 작동한다는 것입니다.

클라우드 환경이 점점 더 비싸지고, AI 모델이 기대한 대로 성능을 내지 못하며, 릴리스 주기를 자동화하려는 시도가 제대로 구현되지 못하는 경우를 많이 보았습니다. 좋은 결정과 나쁜 결정이 미치는 영향을 직접 목격했기 때문에 새로운 기술이 등장하고 모든 발표와 약속, 과대광고를 접할 때마다 저는 같은 전제로 돌아갑니다: 기술로 거의 모든 것이 가능하지만, 알아야 합니다 자신이 무엇을 하고 있는지를.

연구개발(R&D)과 특히 실제 프로젝트를 통해 기술을 제대로 파악하게 됩니다. 이는 무엇이 가능한지, 무엇이 불가능한지, 그리고 어디에서 문제가 발생할 수 있는지를 배우는 방법이기 때문입니다. 각 프로젝트에서 얻은 교훈을 바탕으로 동료, 다른 아키텍트 및 분석가와 이야기를 나누며 패턴이 존재하는지, 그 패턴을 기반으로 어떤 시스템을 만들 수 있는지를 이해하려고 합니다. 결국 이러한 경험이 가이드라인이 되고, 자신이 좋다고 생각한 결정이 실제로 좋은 결과를 가져오는지 확인하게 됩니다.

이것이 바로 회의적 낙관주의가 나오는 이유입니다. 기술이 무엇을 약속하든, 여전히 자신이 무엇을 하고 있는지를 알아야 하며, 이러한 지식은 경험, 협업, 그리고 끊임없는 학습과 개선, 과대광고 뒤에 일종의 시스템을 구축하려는 노력에서 비롯됩니다.

엔터프라이즈 AI가 실험을 장려하는 단계에서 실제로 어떤 실험을 규모 확대해야 할지 결정하는 단계로 이동하고 있는 것으로 보입니다. 어떤 신호가 AI 사용 사례가 더 넓은 배포에 준비되었음을 알려주며, 기업이 너무 일찍 규모를 확대하고 있음을 나타내는 경고 신호는 무엇인가요?

무언가를 확장할 수 있는지, 아니면 다른 방식을 취해야 하는지를 파악하기 위해 저는 채택 곡선과 학습 곡선이라는 두 가지 방법을 사용합니다.

AI 사용 사례가 제대로 작동하고 있는지 판단하려면 일정 시간을 두고 그 사례가 제공하는 가치와 사용자 여정이 어떻게 되는지를 파악해야 합니다. 그래야 특정 팀이나 워크플로우에서 즉각적인 ‘와우’ 효과만이 아니라 상승과 하강을 모두 볼 수 있습니다. 몇 주 후에 같은 사용자가 어떻게 되는지도 확인해야 합니다. 여전히 사용하고 있나요? 그 자동화나 AI 기능에 여전히 만족하고 있나요, 아니면 단지 확장해서는 안 될 일시적인 현상이었나요?

이러한 것들 중 일부는 시간이 지나야 검증될 수 있습니다. 항상 최초의 개척자는 존재하는데, 보통 가장 기술에 능숙하고 매우 호기심이 많은 사람들입니다. 그리고 나서 초기 채택자를 따르는 사람들과 초기 다수를 포함한 다른 부문에서도 시도해야 합니다. 일단 그것이 그곳에서 입증되면, 예, 이를 확장하고 해당 사용 사례를 다른 부서로 확대할 수 있습니다.

모든 주요 모델 출시가 조직 내에서 직원들에게 최신 기능에 즉시 접근하도록 압박을 가할 수 있습니다. 기술 리더는 새로운 모델이 단순히 또 다른 실험 및 비용의 물결을 일으키는 것이 아니라 의미 있는 개선을 나타내는지 어떻게 평가해야 할까요?

다시 한 번 제 회의적인 낙관주의를 말씀드리겠습니다. 이미 모델이 구축되어 있고 수천 명이 매일 AI를 사용하고 있으며, 다양한 모델과 도구가 이미 사용 가능하다고 가정해 보세요. 새로운 모델이 출시되면 과대 광고와 자연스러운 호기심 때문에 모든 사람이 그것을 실험하고 싶어할 것이며, 이는 좋은 일입니다. 하지만 그 실험이 반드시 특정 결과를 목표로 하거나 방향이 잡힌 것은 아니며, 때로는 차이를 측정조차 할 수 없을 수도 있습니다.

규모가 커질수록 이것은 중요합니다. 새로운 모델이 기존 모델에 비해 어떻게 작동하는지 살펴보는 것이 몇 명이 아니라 수천 명이 실험에 시간을 투자할 수 있습니다. 특정 사용 사례에 대해 결과가 그다지 중요하지 않을 수도 있습니다. 동시에 어떤 것이 정말 잘 작동한다면, 조직 내에서 무엇이 효과적인지에 대한 학습이 모두에게 명확히 설명되거나 보이지 않을 수도 있습니다.

그래서 새로운 모델을 평가하는 최초의 그룹은 조직 전체가 아니라는 점이 중요합니다. 해당 팀은 물론 법무와 보안을 포함한 R&D 그룹이 밀접하게 협력해야 합니다. 우리는 모델을 포괄적으로 평가하고 신속히 검토한 뒤, 보안, 규정 준수 및 기술에 관한 의견과 안내와 함께 더 넓은 청중에게 전달합니다. 새로운 모델과 주요 업데이트가 지속적으로 등장함에 따라 이러한 모델과 사고방식을 갖추어야 합니다. 이는 일회성 작업이 절대 아닙니다.

DataArt는 기술, 법무, 규정 준수, InfoSec 및 기타 팀을 포함하는 교차 기능 “AI SWAT”를 만들었습니다. 이 그룹은 실제로 어떻게 운영되며, 새로운 AI 도구가 보다 넓은 사용을 위해 승인되기 전에 해결해야 할 위험 유형이나 질문은 무엇입니까?

시작 이래로, 우리는 약 4~5개월마다 이 그룹에 대해 다양한 목표를 설정해 왔다고 생각합니다. 우선순위, 목표, 때로는 사명을 변경하며, 이러한 목표의 많은 부분이 AI와 관련됩니다. 인력 역량 강화, 시장 진출 및 새로운 기능, 파트너십, 혹은 조직 전체와 ADLC 전반에 걸쳐 AI를 보다 넓게 활용하도록 하는 것이 될 수 있습니다.

구체적인 주제는 시간이 지남에 따라 변하며, 이는 지속적으로 전략을 재검토하고 가정을 검증하며 전환이 필요한지, 팀의 다음 주제가 무엇이어야 하는지를 이해해야 하기 때문에 건강한 일이라고 생각합니다.

이 그룹은 다양한 부서의 대표들로 구성되며, 그 목적 중 하나는 단순히 모든 사람에게 정보를 전달하는 것입니다. 새로운 발표, 질문 또는 기회가 있을 때마다 누군가가 해당 주제를 정기 회의 중 하나에 제시할 수 있습니다. 비록 그것이 좁은 팀에만 관련된 기술 질문처럼 보여도, 오늘날 이러한 주제는 조직의 많은 부분에 영향을 미칠 수 있습니다.

그래서 새로운 파트너십, 도구 또는 가속기를 평가할 때 우리는 이를 공개적으로 논의하여 모든 사람이 상황을 이해하고 질문을 하거나 감독할 기회를 가질 수 있도록 합니다. 새로운 AI 도구의 경우, 기술만으로는 이를 독립적으로 평가할 수 없습니다. 보안, 법무 및 규정 준수 부서도 해당 도구가 회사 또는 고객 데이터를 어떻게 처리하는지, 적용되는 제약 조건은 무엇인지, 그리고 규모에 맞게 안전하게 사용할 수 있는지를 이해해야 합니다.

때때로 AI SWAT 팀은 역량 강화와 같은 특정 프로그램에도 참여합니다. 이때 우리는 목표를 설정하고 로드맵을 작성하며 다양한 그룹이 어떻게 온보딩될지를 결정합니다. 실제로 이와 같이 운영됩니다: 사람들에게 정보를 제공하고, 특정 프로그램에 함께 작업하며, 이사회에 회사 전반에서 AI가 어떻게 진행되고 있는지 가시성을 제공하는 것입니다.

AI 지원 소프트웨어 개발에 대한 태도가 매우 다양하게 나타나고 있습니다. 일부 조직은 에이전시 개발을 적극적으로 확장하고 있는 반면, 다른 조직은 여전히 AI 생성 코드를 금지하고 있습니다. 이러한 격차를 설명하는 요인은 무엇이며, 위험에 민감한 기업들이 소프트웨어 엔지니어링에서 AI가 더 큰 역할을 하는 데 편안함을 느끼기 위해 무엇이 변해야 할까요?

아마도 ‘아니오’라고 말하는 사람과 ‘예’라고 말하는 사람 사이의 차이를 주도하는 요인은 그들의 위험 선호도와 모호함 및 불확실성에 대한 태도일 것입니다. 두 유형의 조직 모두에게 도움이 되는 것은 지속적인 교육, 실험 및 평가입니다. AI를 수용하고 전반에 걸쳐 통합하는 많은 조직과 협력하고 있음에도 불구하고, 결과와 영향을 측정하는 데 여전히 어려움이 존재합니다. 솔직히 말하면, AI의 영향을 어떻게 측정하고 팀의 성과를 어떻게 평가할지에 대한 질문은 때때로 전혀 예상치 못한 순간에 떠오르며, 마치 아무도 이전에 이에 대해 생각해 본 적이 없는 듯합니다.

AI 이니셔티브를 보다 포괄적으로 평가하기 시작하면, 실제로 제공하고 있는 영향과 가치를 이해하게 되고, 이는 기술이 적합한 영역에 대한 더 나은 의사결정으로 이어집니다. AI를 거부하는 기업이라 할지라도, 기술이 무엇을 할 수 있는지와 현재 위치를 지속적으로 검토하는 과정이 필요합니다. 3년 전의 결정이 아무도 그 가정들을 재검토하지 않아 회사 정책으로 남아 있기를 원하지 않을 것입니다.

Agentic AI는 개별 팀이 자체 에이전트를 만들기를 점점 더 쉽게 만들어, 거의 동일한 작업을 수행하는 다수의 에이전트가 생길 가능성을 높입니다. 언제 실험이 에이전트 과잉으로 변하고, 소유권, 권한, 중복 및 수명 주기 관리를 관리하기 위해 어떤 종류의 거버넌스 레이어가 필요한가요?

AI 라이선스가 모든 개발자에게 제공되고 실험이 무분별해지는 전형적인 상황을 보면, 모두가 각자 자신의 방식으로 무언가를 만들기 시작합니다. 일반적으로 이는 성과가 저조한 팀, 기대 미달, 품질 저하 및 비용 상승으로 이어집니다. 결국 기대한 대로 작동하지 않고 품질이 나쁘며 비용이 많이 듭니다. 이를 완화하려면 보다 넓은 부서 또는 조직 차원의 노력의 일부인 팀 차원의 협력이 필요하며, 여기서 거버넌스가 역할을 합니다.

프로젝트 수준에서는 지식 베이스와 컨텍스트, 그리고 AI를 활용하기 시작하는 사용 사례에 대해 합의할 수 있습니다. 이후 개발 워크플로우의 일부가 되는 스킬과 에이전트를 생성하고 모두가 재사용하도록 하면, 매번 새로 만들지 않고도 지식과 모범 사례를 축적할 수 있습니다. 이러한 프로젝트 수준의 노력은 기업 아키텍처 위원회, 기술 그룹, CTO 또는 AI 도입을 담당하는 팀과 같은 조직에 의해 조정되어야 합니다. 잘 작동하는 에이전트를 재사용하고 프로세스가 견고함을 확인하여 조직 전체에 혼란이나 소음이 되지 않도록 해야 합니다.

따라서 프로젝트 수준, 혹은 프로그램 수준에서의 동기화된 노력이 필요하고, 이는 부서 및 조직 차원에서도 이루어져야 한다고 생각합니다.

파일럿 단계에서는 토큰 사용량과 추론 비용이 비교적 작게 보일 수 있지만, AI 시스템이 수천 명의 직원이나 자율 에이전트에 배포될 때는 크게 증가합니다. 기업은 AI 비용 관리를 어떻게 접근해야 하며, AI 워크로드 전용의 FinOps와 유사한 체계가 등장할 것으로 기대하십니까?

우선 거의 이상적인 시나리오는 AI 비용이 상승했다가 정체기에 도달하고, 이후 시간이 지나면서 약간 감소하는 경우입니다. 이는 비용을 예측하고 통제하며, 실제 AI에 얼마를 지출하고 있는지 파악하고, 의사결정의 결과를 확인할 수 있음을 의미합니다. 반면 비용이 계속 오르내리는 경우는 보통 지속 가능하지 않다는 신호이며, 비용이 상승했다가 완전히 떨어지는 경우는 도입이 이루어지지 않거나 무언가가 제대로 작동하지 않거나, 사람들이 다른 것을 사용하고 있어 이를 파악하지 못한다는 뜻입니다.

FinOps가 존재하듯 AI FinOps도 존재합니다. 일부 기법은 매우 기술적이고, 다른 일부는 꽤 단순합니다. 가장 비싼 모델에 항상 의존하지 않도록 선호 모델을 선택하는 것처럼 기본적인 수준부터 시작해, 이러한 결정이 차곡차곡 비용 절감으로 이어집니다. 동시에 비용 절감과 통제 방법을 아는 것은 전체 방정식의 절반에 불과합니다. 제가 보기엔 FinOps는 AI 활동을 평가할 때 무엇을 측정할지 정의해야 하므로 제품 및 비즈니스 리더도 참여하는 학문이자 방법론입니다.

따라서 AI FinOps는 AI SWAT 팀에 해당하는 팀이 논의하기에 좋은 주제라고 생각합니다. 즉, 얼마나 지출하고, 얼마나 회수하며, 어떻게 통제하고, 어떤 기회가 있는지를 다루는 것입니다.

많은 기업이 AI 도입 이전 팀의 생산성에 대한 신뢰할 수 있는 기준을 마련하지 않았음에도 불구하고 AI의 ROI를 입증하라는 요구를 받고 있습니다. AI가 실질적인 비즈니스 가치를 창출하고 있는지를 판단하려면 조직은 실제로 무엇을 측정해야 할까요?

AI에 대한 태도나 현재 위치와 관계없이, 이미 에이전트를 여기저기 사용하고 있든 다음 해에 AI를 도입할 계획이든, 현재는 기준선을 설정하는 것이 필수입니다.

측정항목에는 여러 종류가 있습니다. 일부는 주관적이며, 이는 개발자나 직원들의 피드백으로 간단히 파악할 수 있습니다. 사람과 함께 일하기 때문에 그들이 AI 가치를 어떻게 인식하는지 이해하는 것이 중요합니다. 보다 객관적인 측정은 기계적 또는 합성 지표에서 시작할 수 있지만, 지나치게 의존하지 않기를 권합니다. 예를 들어 코드 커밋이나 스토리 포인트와 같은 지표가 있습니다. 이러한 지표는 작업이 진행되고 있음을 보여주지만, 실제 가치나 영향을 충분히 나타내지는 못합니다.

더 큰 차이를 만드는 것은 작업이 얼마나 빠르게 혹은 얼마나 잘 전달되었는지를 설명하는 메트릭입니다. 리드 타임이나 MTTR과 같은 DORA 메트릭을 생각해 보세요. 장애 복구 속도, 프로덕션 버그 수정 속도, 혹은 이러한 측정값이 시간에 따라 어떻게 변하는지를 말입니다. 어느 시점의 하나의 숫자는 추세를 알려주지 못합니다. 우리 아키텍트 중 한 명이 최근에 언급했듯이, 소프트웨어 개발에서 좋은 메트릭은 AI 도입이 확대됨에 따라 추정치가 얼마나 신뢰할 수 있는가가 될 수도 있습니다. 이는 노력의 지속 가능성과 팀의 실제 생산성을 나타내기 때문입니다. 또한 비용을 추적해야 합니다. 이익만 이야기하고 이를 달성하는 비용을 이해하지 못한다면 전체 그림을 파악할 수 없습니다.

소프트웨어 개발 외에도 비슷한 방식으로 생각합니다. 모든 워크플로우나 프로세스에는 작업 단위와 완료 정의가 존재합니다. 청구를 처리하든, 서류를 검토하든, 고객 요청을 다루든, 제공하는 것이 무엇인지 정의하고 AI 적용 전후에 걸린 시간, 현재 얼마나 빠르고 잘 수행되는지, 그리고 비용이 얼마인지 측정하십시오. 이는 기준선과 메트릭 프레임워크를 설정하는 좋은 출발점이 됩니다.

DataArt는 Artisyn과 같은 이니셔티브를 통해 소프트웨어 전달 라이프사이클 전반에 AI를 내재화해 왔습니다. AI가 구현, 테스트, 워크플로우 작업을 더 많이 담당하게 되면서, 소프트웨어 엔지니어링의 어떤 부분이 인간에게 더 가치 있게 되고, 어떤 기술이 중요도가 낮아질 위험이 있을까요?

AI를 개발에 효과적으로 활용하려면 좋음의 정의를 아직도 기억하고 있어야 합니다. 에이전트를 안내하고 결과를 검토하며 제약을 설정하고 규칙을 정의할 전문성이 필요합니다. 베스트 프랙티스와 좋은 아키텍처가 어떤 모습인지 이해해야 합니다. 그렇지 않으면 무엇이 개발되고 있는지 알 수 없으며, 이러한 전문성의 가치는 매우, 매우 크게 상승하고 있습니다.

아키텍처 패턴을 이해하는 것이 중요하며, 특정 산업, 애플리케이션 또는 솔루션 유형에 적합한 것이 무엇인지 아는 것도 중요합니다. 현재 좋은 아키텍처가 무엇인지, 솔루션이 확장될 때에도 여전히 좋은 아키텍처가 무엇인지 알아야 합니다. 왜냐하면 때때로 동일한 아키텍처가 솔루션이나 플랫폼의 전체 수명 동안 작동하지 않을 수 있기 때문입니다.

특정 솔루션에 적합한 균형을 맞추는 것이 인간적인 부분입니다. 이는 서비스와 소프트웨어 개발 뒤에 숨은 감각, 장인 정신입니다. 자신이 무엇을 하고 있는지 알아야 하며, 이는 고객과 산업을 이해함으로써 얻어집니다.

어떤 기술이 덜 중요해질까요? 제가 확답하기는 어렵지만, 아마도 코드를 입력하는 속도가 될 수도 있습니다. 농담이지만, 이제 코드를 훨씬, 훨씬 빠르게 만들 수 있고, 특정 라이브러리나 언어에 대한 지식도 AI 덕분에 훨씬 빨리 습득할 수 있습니다.

.NET 개발자가 Java 개발자로 매우 빠르게 전환하는 모습을 보았습니다. 5년 전이나 10년 전이라면 대규모 전환은 거의 불가능하다고 말했겠지만, 요즘은 가능합니다. 강력한 시니어 개발자는 언어 간 이동이 점점 쉬워지고 있습니다. 왜냐하면 진정으로 중요한 것은 기술, 아키텍처, 솔루션 베스트 프랙티스, SDLC 및 ADLC에 대한 이해이기 때문입니다.

기업이 수십 개의 AI 파일럿에서 독립적으로 행동할 수 있는 프로덕션 시스템으로 전환함에 따라, AI 에이전트가 비용이 큰 실수를 저질렀을 때 최종적인 책임은 개발자, 비즈니스 소유자, 모델 제공자, 거버넌스 팀 중 어디에 있어야 할까요, 혹은 이들 중 일부 조합에 있어야 할까요?

저는 무비난 협업과 공동 책임이라는 개념을 좋아합니다. 조직 내 모든 사람이 베스트 프랙티스, 아키텍처 프레임워크, 솔루션에 기여하기 때문입니다. 한 개발자가 AI를 사용하든 사용하지 않든 코드를 작성하면, 다른 개발자가 이를 검토하고, 팀 리드가 가이드를 제공하며, 아키텍트가 아키텍처와 제약을 제시하고, 거버넌스 팀이 예산, 일정, 릴리스에 대한 결정을 돕습니다. 모두가 어느 정도 관여하고 있습니다.

문제가 발생했을 때 대부분은 프로세스가 제대로 작동하지 않기 때문에, 그 의미에서 책임은 다양한 역할에 걸쳐 공유됩니다. 하지만 단순히 책임이 공유되고 무비난이라고만 말하는 것은 충분하지 않습니다. 여전히 구체적인 책임으로 세분화되어야 합니다.

개발자는 풀 리퀘스트로 제출한 코드에 대해 책임을 지며, 해당 코드가 어떻게 동작하는지 이해해야 합니다. 아키텍트는 내린 결정과 에이전트 및 개발자에게 제공된 아키텍처 결정에 대해 책임을 집니다. 플랫폼 팀은 누가 어떤 코드를 만들었든 솔루션의 신뢰성에 대해 책임을 집니다.

따라서 책임은 존재하지만 팀, 역할, 부서별로 세분화해서 정의해야 합니다. “AI가 이 일을 했어요”라는 분석만으로는 충분하지 않습니다. 어떤 제어, 테스트 또는 감시가 그 실패를 프로덕션에 이르게 했는지 물어야 합니다.

유닛 테스트가 부족해 나쁜 코드가 프로덕션에 배포되었거나, 감시와 검토가 부족해 발생했다면 그 책임을 AI에게 떠넘길 수 없습니다. 또한 모든 버그나 장애에 대해 모델 제공자나 클라우드 제공자를 일괄적으로 비난할 수도 없습니다.

훌륭한 인터뷰에 감사드립니다. 더 알고 싶은 독자분들은 DataArt를 방문해 주세요.