당신의 AI 프로젝트, '예쁜 쓰레기'가 되고 있진 않습니까? 2026년 1월, 충격적인 통계가 발표되었습니다. 전 세계에서 진행되는 AI 프로젝트 중 절반 이상이 PoC(Proof of Concept, 개념 증명) 단계에서 중단된다는 것입니다. 가트너는 생성형 AI 프로젝트의 30%가 파일럿을 넘지 못하고 사라질 것으로 예측했습니다. 수억 원을 들여 챗봇을 개발했지만, 정작 상담원들은 불편하다며 예전 엑셀 파일을 다시 열어보는 상황을 목격하고 당황한 DX 팀장들이 정말 많습니다.
화려한 데모 영상 뒤에 숨겨진 엉망진창인 데이터 때문에 밤새워본 적 있으시죠? 문제는 기술이 아닙니다. AI 모델은 완벽한데 직원이 쓰지 않는 이유, 데모는 성공했는데 실제 환경에선 작동하지 않는 이유는 비즈니스 프로세스와의 통합(Integration) 실패와 변경 관리(Change Management) 부재에 있습니다.
최신 산업 리포트에 따르면, AI 프로젝트 실패의 80%는 기술적 문제가 아니라 조직적·문화적 요인 때문입니다. 데이터 사일로, 직원 반발, 확장성 부재가 3대 장벽입니다. 이 글에서는 왜 대부분의 AI 프로젝트가 실험실에서 죽는지 냉철하게 진단하고, 파일럿에서 전사 확산으로 이어지는 구체적인 로드맵을 제시하겠습니다.
왜 80%의 AI 프로젝트는 실험실에서 죽는가?
AI는 마법 지팡이가 아니라, 고도화된 소프트웨어일 뿐입니다. 하지만 많은 경영진이 "AI만 도입하면 모든 문제가 해결될 것"이라는 기술 만능주의에 빠져 있습니다. 현실은 정반대입니다. 산업 현장 데이터에 따르면, AI 도입의 최대 걸림돌은 다음과 같습니다.
AI PoC란 무엇이며 왜 실패하나요?
**PoC(Proof of Concept)**는 기술 검증을 의미하지만, 비즈니스 목표와 정렬되지 않거나 확장성을 고려하지 않은 설계 때문에 실제 도입 단계에서 실패하는 경우가 많습니다. PoC는 "이 기술이 작동하는가?"를 확인하는 단계이지만, 정작 중요한 질문인 "이 기술이 우리 조직에서 지속 가능하게 작동하는가?", "비용 대비 가치를 창출하는가?"에는 답하지 못합니다.
AI 프로젝트 실패의 주요 원인 (2026년 통계)
| 실패 원인 | 비율 | 구체적 문제 |
|---|---|---|
| 데이터 품질 부족 | 35% | 불완전·부정확·편향된 학습 데이터 |
| 비즈니스 가치 불명확 | 28% | ROI 기대치 설정 실패, KPI 부재 |
| 조직 저항 및 문화 장벽 | 22% | 직원 반발, Change Management 부재 |
| 기술적 확장성 부족 | 15% | 데모용 아키텍처, 프로덕션 환경 미고려 |
| 비용 초과 | 12% | 숨겨진 운영 비용 (Hidden Cost) |
| 규제 및 윤리 문제 | 8% | 개인정보 보호, AI 편향성 |
가장 놀라운 사실은 기술적 문제는 15%에 불과하다는 점입니다. 나머지 85%는 조직, 문화, 프로세스, 비용 등 비기술적 요인입니다. AI는 외부에서 가져온 좋은 기술(장기)이라도 조직의 체질(면역 체계)과 맞지 않으면 거부당하는 장기 이식 거부 반응과 같습니다.
좀비 프로젝트의 특징
성공한 기업들은 AI 도입 초기부터 **'종료 조건(Exit Criteria)'**을 명확히 합니다. PoC가 성공했을 때 바로 폐기할지, 아니면 어떤 기준으로 상용화할지 미리 정하지 않으면 예산만 낭비하는 '좀비 프로젝트'가 됩니다. 좀비 프로젝트의 특징은 다음과 같습니다.
- 목표 불명확: "AI로 뭔가 해보자"는 있지만 구체적 KPI가 없음
- 무한 반복: PoC가 끝나도 "한 번 더 검증"을 반복하며 상용화를 미룸
- 책임 회피: 성공 기준이 없어 누구도 책임지지 않음
- 예산 낭비: 매년 "연구개발비"라는 이름으로 예산만 소진
비즈니스 현장에서는 이런 좀비 프로젝트가 3~5년간 지속되다가 결국 조용히 중단되는 사례가 빈번합니다.
장벽 1. '데이터 사일로(Silo)': 연결되지 않은 정보의 비극
"데이터만 많으면 된다?"는 가장 흔한 착각입니다. 쓰레기 데이터(Garbage In)는 쓰레기 모델(Garbage Out)을 만들 뿐이며, '데이터의 양'보다 '비즈니스 관련성'이 중요합니다.
데이터 사일로란 무엇인가?
데이터 사일로(Data Silo)는 조직 내 데이터가 부서별·시스템별로 고립되어 있어 통합되지 않는 현상을 말합니다. 마케팅 부서는 CRM 데이터를, 영업 부서는 ERP 데이터를, IT 부서는 로그 데이터를 각각 보유하지만, 이들이 서로 연결되지 않습니다.
산업 현장의 한 전문가는 이렇게 지적합니다. "AI 데모는 쉽고, PoC도 나이스하게 나오지만, 프로덕션 확산은 데이터 구조의 빈틈 때문에 막힙니다." AI가 제대로 작동하려면 데이터에 네 가지 요소가 필요합니다.
1. 시간(Time) 특정 현상이 언제 발생했는지 타임스탬프가 명확해야 합니다. 예를 들어 제조 공정에서 불량이 발생한 시점을 정확히 기록하지 않으면, AI는 원인을 파악할 수 없습니다.
2. 구조(Structure) 어떤 설비와 라인에서, 어떤 변수로 발생한 값인지 명확히 구분되어야 합니다. 같은 온도 데이터라도 "A 라인 1번 센서"와 "B 라인 2번 센서"의 데이터가 섞이면 AI는 혼란에 빠집니다.
3. 맥락(Context) 이 데이터가 어떤 공정 상태에서 어떤 의미를 갖는지 정보를 부여해야 합니다. 단순한 숫자 나열이 아니라 "이 값은 정상 범위인가, 이상 징후인가"라는 비즈니스 맥락이 필요합니다.
4. 추적성(Traceability) 앞선 세 요소가 합쳐져야 특정 KPI의 변동 원인을 나중에 되짚을 수 있습니다. "왜 이번 달 불량률이 올랐는가?"라는 질문에 답하려면 데이터가 추적 가능해야 합니다.
데이터 사일로 해결 전략
1. 데이터 민주화(Data Democratization) 모든 부서가 필요한 데이터에 접근할 수 있도록 권한을 재설계합니다. 단, 보안과 개인정보 보호 규정을 준수해야 합니다.
2. 데이터 레이크(Data Lake) 또는 데이터 웨어하우스 구축 분산된 데이터를 하나의 저장소로 통합합니다. AWS S3, Azure Data Lake, Google BigQuery 같은 클라우드 기반 솔루션이 효과적입니다.
3. API 통합 서로 다른 시스템 간 데이터 교환을 위한 API를 구축합니다. 예를 들어 CRM(Salesforce)과 ERP(SAP)를 API로 연결해 실시간 데이터 동기화를 구현합니다.
4. 메타데이터 관리 데이터의 정의, 출처, 품질, 업데이트 주기 등을 문서화하는 메타데이터 관리 시스템을 도입합니다. 가트너는 메타데이터를 기반으로 데이터를 정렬·검증·관리하는 것이 AI 성공의 핵심이라고 강조합니다.
데이터 품질 vs 데이터 양
| 구분 | 데이터 양 중심 | 데이터 품질 중심 |
|---|---|---|
| 접근 방식 | "일단 모든 데이터를 수집하자" | "비즈니스 목표에 필요한 데이터만 정제" |
| 결과 | 노이즈 많음, 학습 속도 느림 | 정확도 높음, 빠른 인사이트 |
| 비용 | 저장 비용 높음 | 저장 비용 낮음, 정제 비용 있음 |
| AI 성능 | 편향·오류 가능성 높음 | 신뢰도 높은 예측 |
일반적인 실패 사례를 보면, 기업들은 "데이터를 많이 모으면 AI가 알아서 학습할 것"이라고 착각합니다. 하지만 현실은 품질 낮은 데이터 100만 건보다 품질 높은 데이터 10만 건이 훨씬 효과적입니다.
장벽 2. '문화적 저항': AI를 불신하는 직원들
기술적으로 완벽한 AI라도 직원들이 사용하지 않으면 실패입니다. 변경 관리(Change Management)는 AI 도입의 가장 중요하면서도 가장 간과되는 요소입니다.
왜 직원들은 AI를 거부하는가?
1. 일자리 위협 공포 "AI가 도입되면 내가 해고될까?"라는 두려움이 가장 큽니다. 특히 정형화된 업무를 수행하는 직원일수록 위협을 느낍니다.
2. 신뢰 부족 "AI가 내놓은 결과를 믿어도 되나?"라는 의심입니다. 특히 생성형 AI의 환각(Hallucination) 문제가 알려지면서 불신이 커졌습니다.
3. 학습 부담 새로운 시스템을 배우는 것 자체가 부담입니다. 특히 IT 리터러시가 낮은 직원들은 "그냥 예전 방식이 편하다"고 저항합니다.
4. 책임 회피 "AI가 잘못된 판단을 내리면 누가 책임지나?"라는 질문에 명확한 답이 없으면 직원들은 AI 사용을 꺼립니다.
실패 사례: A 제조사의 불량 검출 AI
A 제조사는 비전 AI를 도입해 제품 불량을 자동으로 검출하는 시스템을 구축했습니다. 기술적으로는 완벽했고, PoC에서 95% 정확도를 달성했습니다. 하지만 현장 확산에 실패했습니다. 원인은 **'작업자들의 반발'**이었습니다.
작업자들은 "AI가 우리를 감시하고 평가하려는 것"으로 받아들였고, 의도적으로 AI를 회피하거나 결과를 무시했습니다. 일부는 AI 카메라에 스티커를 붙이기도 했습니다. 결국 수억 원의 투자가 물거품이 되었습니다.
성공 사례: B사의 변경 관리 전략
반면, B사는 AI 도입 전 3개월간 작업자들과 워크숍을 열어 **'AI가 당신을 감시하는 게 아니라 돕는 도구'**임을 설득했습니다. 구체적인 전략은 다음과 같습니다.
1단계: 투명한 소통
- AI가 무엇을 하는지, 어떤 데이터를 수집하는지 명확히 설명
- "AI가 직원을 평가하지 않는다"는 경영진의 공식 약속
2단계: 초기 참여
- 작업자들을 AI 설계 과정에 참여시켜 의견 수렴
- "이 기능이 있으면 좋겠다"는 피드백 반영
3단계: 파일럿 그룹 선정
- 자발적 참여자들로 파일럿 그룹 구성
- 성공 사례를 만들어 다른 직원들에게 전파
4단계: 인센티브 제공
- AI를 적극 활용하는 직원에게 보상 제공
- 성과 개선을 개인 평가에 긍정적으로 반영
결과: 90%의 수용률을 달성했고, 불량률이 40% 감소했습니다. 기술보다 사람이 먼저입니다.
AI 챔피언(Champion) 제도
성공적인 기업들은 각 현업 부서에서 AI를 잘 활용하는 에이스를 선발해 전파자로 삼는 **'AI 챔피언 제도'**를 운영합니다. AI 챔피언은 다음 역할을 수행합니다.
- 동료 직원들의 AI 사용 교육 및 지원
- AI 관련 피드백을 IT 부서에 전달
- 성공 사례를 공유하고 Best Practice 전파
- 저항하는 직원들을 설득하는 '문화 전도사' 역할
이 제도는 특히 IT 리터러시가 낮은 조직에서 효과적입니다.
장벽 3. '확장성(Scalability) 부재': 데모용 아키텍처의 한계
PoC는 성공했는데 왜 프로덕션으로 확장되지 않을까요? 이유는 간단합니다. 데모용 아키텍처는 실제 운영 환경을 고려하지 않기 때문입니다.
데모와 프로덕션의 차이
| 구분 | PoC (데모) | Production (실운영) |
|---|---|---|
| 데이터 규모 | 소량 샘플 데이터 (수천~수만 건) | 대규모 실제 데이터 (수백만~수억 건) |
| 처리 속도 | 느려도 괜찮음 (배치 처리) | 실시간 또는 준실시간 필수 |
| 오류 허용도 | 높음 (실험이므로) | 낮음 (비즈니스 영향 큼) |
| 보안 | 제한적 고려 | 엄격한 규제 준수 필수 |
| 통합 | 독립 시스템 | 기존 시스템과 통합 필수 |
| 비용 | 일회성 개발 비용 | 지속적인 운영·유지보수 비용 |
일반적인 실패 사례를 보면, PoC에서는 노트북 1대로 돌아가던 모델이 프로덕션에서는 100대의 사용자 동시 접속을 처리해야 합니다. 인프라 비용이 예상의 10배로 뛰고, 응답 속도가 느려져 사용자 불만이 폭증합니다.
숨겨진 운영 비용 (Hidden Cost)
AI 프로젝트의 ROI가 낮은 이유 중 하나는 숨겨진 운영 비용을 간과하기 때문입니다.
| 비용 항목 | 내용 | 예상 비중 |
|---|---|---|
| 초기 개발 비용 | 모델 개발, PoC, 인프라 구축 | 20% |
| 데이터 수집·정제 | 데이터 품질 개선, 라벨링 | 30% |
| 인프라 운영 | GPU 서버, 클라우드 비용 | 25% |
| 모델 재학습·업데이트 | 성능 유지 위한 지속적 학습 | 15% |
| 모니터링·거버넌스 | AI 윤리, 편향성 점검, 감사 | 10% |
놀랍게도 초기 개발 비용은 전체의 20%에 불과하고, 나머지 80%는 운영 단계에서 지속적으로 발생합니다. 이것을 고려하지 않으면 AI가 "비용을 먹는 하마"가 됩니다.
기술 부채(Technical Debt)
빠르게 만든 PoC는 코드 품질이 낮고 문서화가 부실한 경우가 많습니다. 이것을 기술 부채라고 합니다. 기술 부채는 시간이 지날수록 눈덩이처럼 커져, 나중에는 시스템 전체를 다시 만들어야 하는 상황이 발생합니다.
해결책은 초기부터 **확장 가능한 아키텍처(Scalable Architecture)**를 설계하는 것입니다. 구체적으로는 다음과 같습니다.
1. 마이크로서비스 아키텍처
- AI 모델을 독립된 서비스로 분리
- 필요에 따라 특정 모듈만 확장 가능
2. MLOps (Machine Learning Operations)
- 모델 개발, 배포, 모니터링을 자동화
- 지속적인 재학습 및 업데이트 파이프라인 구축
3. 컨테이너화 (Docker, Kubernetes)
- 환경 독립적으로 배포 가능
- 리소스 효율적 관리
4. 클라우드 네이티브 설계
- Auto-scaling으로 트래픽 변동 대응
- 서버리스(Serverless) 아키텍처로 비용 최적화
성공적인 확산을 위한 3단계 로드맵 (Pilot -> Pivot -> Scale)
AI를 PoC에서 전사 확산으로 이어가는 성공적인 로드맵은 Think Big, Start Small, Scale Fast 전략입니다.
1단계: Pilot (작게 시작)
목표: 기술 검증 및 비즈니스 가치 확인
핵심 활동
- 명확한 비즈니스 문제 정의 (예: "고객 이탈률 10% 감소")
- KPI 설정 (성공 기준을 수치화)
- 작은 규모의 파일럿 프로젝트 실행 (1~3개월)
- 종료 조건(Exit Criteria) 명확화
- 성공 시: 다음 단계로 진행
- 실패 시: 폐기 또는 방향 전환
체크리스트
2단계: Pivot (개선 및 확장 준비)
목표: 파일럿 결과 분석 및 전사 확산 준비
핵심 활동
- 파일럿 결과 철저히 분석
- 무엇이 효과적이었는가?
- 어떤 문제가 발생했는가?
- 직원 피드백은?
- 아키텍처 재설계 (확장성 고려)
- 거버넌스 체계 수립
- AI 윤리 가이드라인
- 책임 소재 명확화 (Human-in-the-loop)
- 모니터링 및 감사 프로세스
- Change Management 본격화
- 전사 교육 프로그램
- AI 챔피언 양성
체크리스트
3단계: Scale (전사 확산)
목표: AI를 조직 전체로 확산하여 비즈니스 가치 극대화
핵심 활동
- 단계적 확산 (한 번에 모든 부서가 아님)
- 우선순위 높은 부서부터 순차 적용
- 각 단계마다 학습 및 개선
- AI CoE (Center of Excellence) 운영
- 전사 AI 전략 수립 및 실행
- 부서 간 Best Practice 공유
- AI 리터러시 교육
- 지속적 모니터링 및 개선
- 모델 성능 추적 (Drift 감지)
- 비즈니스 KPI 달성 여부 점검
- 사용자 피드백 수렴 및 반영
체크리스트
PoC 단계 vs Scaling 단계 핵심 체크리스트
| 체크 항목 | PoC 단계 | Scaling 단계 |
|---|---|---|
| 목표 | 기술 검증 | 비즈니스 가치 실현 |
| 데이터 규모 | 샘플 데이터 | 전사 데이터 통합 |
| 성능 요구사항 | 느려도 OK | 실시간 응답 필수 |
| 아키텍처 | 단순 구조 | 확장 가능 설계 (MLOps) |
| 보안·규제 | 제한적 | 엄격한 준수 |
| 조직 변화 | 소수 참여 | 전사 교육 및 Change Mgmt |
| 비용 | 일회성 | 지속적 운영 비용 고려 |
| 거버넌스 | 최소 | Human-in-the-loop, 감사 체계 |
AI 거버넌스: 통제 없는 AI는 위험하다
AI가 내놓은 잘못된 가격 정보 하나가 기업 신뢰도를 바닥으로 떨어뜨릴 수 있습니다. 실제로 한 항공사는 챗봇이 환불 규정을 잘못 안내하는 바람에 소송까지 갔습니다. 이를 막기 위해선 AI의 답변을 검수하고 통제하는 'Human-in-the-loop' 프로세스가 필수입니다.
AI 거버넌스의 핵심 요소
1. 윤리적 AI (Ethical AI)
- 편향성(Bias) 점검: AI가 특정 인종, 성별, 연령에 차별적이지 않은가?
- 공정성(Fairness): 모든 사용자에게 동등한 서비스를 제공하는가?
- 투명성(Transparency): AI 결정 과정을 설명할 수 있는가? (Explainable AI, XAI)
2. 책임 소재 명확화
- AI가 잘못된 결정을 내렸을 때 누가 책임지는가?
- 일반적으로는 "AI를 승인한 인간"이 최종 책임자
3. 모니터링 및 감사
- AI 출력 결과를 실시간 모니터링
- 정기적인 성능 감사 (모델 Drift 탐지)
- 규제 준수 여부 점검 (GDPR, 개인정보보호법 등)
4. Human-in-the-loop
- 중요한 결정은 반드시 인간이 최종 승인
- 예: 대출 승인 AI → 결과는 AI가 제시하지만 최종 승인은 인간
자주 묻는 질문 (FAQ): AI 프로젝트 실행 궁금증 해결
Q1. PoC와 MVP(최소 기능 제품)의 차이는 무엇인가요? PoC는 "기술적으로 가능한가?"를 검증하는 것이고, MVP는 "실제 사용자가 가치를 느끼는가?"를 검증하는 것입니다. PoC는 내부 실험이고, MVP는 실제 고객이 사용하는 초기 제품입니다. AI 프로젝트에서는 PoC 이후 MVP를 거쳐 정식 출시로 가는 단계적 접근이 권장됩니다.
Q2. AI 도입 시 가장 먼저 고려해야 할 비용은? (GPU vs 인건비) 초기에는 GPU 같은 인프라 비용에 주목하지만, 장기적으로는 데이터 정제 및 유지보수 인건비가 훨씬 큽니다. 일반적으로 AI 프로젝트 비용의 30~40%가 데이터 관련 인건비입니다. 클라우드를 사용하면 GPU 비용은 변동 비용으로 관리할 수 있지만, 숙련된 데이터 엔지니어와 ML 엔지니어 확보는 고정 비용입니다.
Q3. 내부 개발 vs 외부 솔루션 도입, 무엇이 유리한가요? 정답은 "업무 특성"에 따라 다릅니다. **범용적인 기능(챗봇, 번역, OCR 등)**은 외부 SaaS 솔루션이 비용 효율적입니다. 반면 **핵심 경쟁력과 직결된 고유 업무(제조 공정 최적화, 금융 리스크 모델 등)**는 내부 개발이 유리합니다. 대부분의 기업은 하이브리드 접근을 택합니다. 범용 기능은 외부 솔루션을 쓰고, 핵심 기능만 내부 개발하는 것입니다.
Q4. 생성형 AI 환각(Hallucination) 문제는 어떻게 해결하나요? 환각은 LLM이 존재하지 않는 정보를 사실처럼 생성하는 현상입니다. 해결 방법은 다음과 같습니다.
- RAG(Retrieval-Augmented Generation): 검증된 지식 베이스에서 정보를 검색해 답변
- 사실 검증 레이어: AI 답변을 검증하는 추가 모델 사용
- Human-in-the-loop: 중요한 답변은 인간이 검토 후 제공
- 신뢰도 점수 표시: AI가 확신하지 못하는 답변에는 경고 표시
Q5. AI 전담 조직(CoE)은 꼭 필요한가요? 규모가 큰 조직일수록 필요합니다. AI CoE(Center of Excellence)는 전사 AI 전략을 수립하고, 부서 간 중복 투자를 방지하며, Best Practice를 공유하는 역할을 합니다. 작은 조직이라면 "AI 챔피언" 몇 명으로 시작해도 충분합니다. 중요한 것은 형식이 아니라 "AI를 전사적으로 조율하는 구심점"이 있느냐입니다.
Q6. AI 리터러시 교육은 어떻게 진행하나요? 전 직원이 AI 전문가가 될 필요는 없습니다. 역할별로 다른 교육이 필요합니다.
- 경영진: AI의 전략적 가치와 ROI 이해
- 현업 직원: AI 도구 사용법 (실습 중심)
- IT/데이터팀: 기술적 구현 및 MLOps
- 법무/컴플라이언스: AI 윤리 및 규제
교육은 온라인 강의, 워크숍, 핸즈온 프로젝트를 혼합하는 것이 효과적입니다.
Q7. AI 프로젝트의 ROI는 언제 나타나나요? 일반적으로 6개월~2년이 소요됩니다. 단순 자동화(챗봇, OCR 등)는 빠르면 3~6개월, 복잡한 예측 모델(수요 예측, 리스크 관리 등)은 1~2년이 걸립니다. 중요한 것은 단기 ROI만 보지 말고, 장기적인 경쟁력 확보를 함께 고려해야 한다는 점입니다.
마무리: 기술이 아니라 통합이 핵심이다
AI 프로젝트가 PoC의 늪에 빠지는 이유는 명확합니다. 기술적 환상에 빠져 조직, 문화, 프로세스와의 통합을 간과하기 때문입니다. 데이터 사일로, 문화적 저항, 확장성 부재라는 세 가지 장벽을 넘지 못하면 아무리 뛰어난 AI 모델도 실험실에서 죽습니다.
성공의 핵심은 세 가지입니다.
첫째, 비즈니스 목표와의 정렬입니다. "AI로 뭔가 해보자"가 아니라 "이 문제를 AI로 해결하면 매출이 X% 증가한다"는 명확한 가치 제안이 필요합니다.
둘째, 사람 중심의 접근입니다. 기술보다 사람이 먼저입니다. AI를 사용할 직원들을 초기부터 참여시키고, Change Management에 충분한 시간과 자원을 투입해야 합니다.
셋째, 확장 가능한 설계입니다. PoC 단계부터 "이것이 전사로 확산될 때 어떤 모습일까?"를 고민하고, 데모용이 아닌 프로덕션급 아키텍처를 설계해야 합니다.
AI는 마법 지팡이가 아닙니다. 조직의 체질에 맞게 통합되고, 직원들의 신뢰를 얻으며, 지속 가능한 ROI를 창출할 때 비로소 가치를 발휘합니다. Think Big, Start Small, Scale Fast 전략으로 작게 시작해서 크게 키우세요. 당신의 AI 프로젝트가 '예쁜 쓰레기'가 아니라 '비즈니스 혁신'이 되기를 바랍니다.
공식 참고 링크 안내
맥킨지 AI 현황 리포트 가트너 AI 트렌드 및 전망 앤드류 응의 AI 변환 플레이북 구글 클라우드 AI 채택 프레임워크
.jpg)
.jpg)
.jpg)
0 댓글