AI 잘 쓰는 회사들이 먼저 고친 것 (스노우플레이크 월드투어 서울 총정리)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

스노우플레이크 월드투어 서울의 기업 사례에서 AI를 잘 활용하기 위해 먼저 고친 것은 흩어진 데이터, 제각각인 업무 용어, 복잡한 접근 절차와 권한 통제였다.

📌 핵심 요점

1. AI 성과의 출발점은 데이터 준비다. 데이터를 모으고 정제하는 데 더해 컬럼의 의미, 값의 범위, 집계 기준을 정의해야 한다. 위메이드플레이는 복잡한 게임 로그를 컬럼으로 펼치고 단일 소스와 업무 설명을 마련했다.
2. 시멘틱 레이어는 회사의 언어를 AI가 이해하도록 연결한다. 아모레퍼시픽은 브랜드·채널 데이터를 통합하고 신제품·지역 등의 의미를 정의했다. KT는 여러 도구가 같은 지표 정의를 참조하도록 설계했으며, 온톨로지는 객체 사이의 관계와 영향까지 표현하는 방법으로 소개됐다.
3. 현업이 직접 활용할 수 있어야 전사 확산으로 이어진다. 자연어 질문과 코딩 어시스턴트는 조회·정제·대시보드 제작의 접근성을 높인다. GS건설은 데이터 준비에 걸리던 시간을 2주 이상에서 하루 이틀 정도로 줄였다고 소개했으며, 현장 직원의 역할도 결과 확인과 승인으로 바뀌었다.
4. 행동하는 에이전트에는 판단 검증과 접근 권한 통제가 함께 필요하다. 티냅스는 판단을 즉시 검증하고 실수를 다음 판단 기준에 반영하는 구조를 구축했다. 네패스는 사람이 확인할 지점을 구분했고, 호라이즌 카탈로그는 민감한 데이터 식별과 권한별 접근·마스킹을 관리하는 기능으로 소개됐다.
5. 운영 구조를 정비하고 효과가 큰 업무부터 확장해야 한다. 아이스버그는 여러 엔진이 같은 데이터를 활용하도록 돕고, 네오위즈의 독립 컴퓨팅과 데이터 스트림은 자원 경합과 인프라 운영 부담을 줄이는 접근을 보여준다. 도입은 특정 업무에서 작게 시작해 실제 효과를 확인한 뒤 넓히는 방식이 제안됐다.

🧩 배경과 문제 정의

• 스노우플레이크 월드투어 서울은 8월 27일 열린 행사로, 글로벌 서밋의 신기술과 국내 기업의 활용 사례를 다뤘다. 핵심 문제는 AI 도입을 실제 생산성 향상과 새로운 사업 기회로 연결하는 것이다.
• 기업 데이터는 부서와 시스템별로 흩어져 있고, 같은 용어도 서로 다른 의미로 쓰인다. 데이터의 의미와 품질을 정리하지 않으면 AI가 정확한 답을 내거나 신뢰할 수 있는 행동을 하기 어렵다.
• AI 활용의 기반은 데이터 준비, 구성원의 손쉬운 업무 활용, 보안과 거버넌스다. 답변을 넘어 행동하는 AI 에이전트에는 판단 검증과 권한 통제도 필요하다.

🕒 시간순 섹션별 상세정리

1. AI 도입의 목표가 실질적인 사업 성과로 옮겨간다

• 기업은 AI와 내부 데이터를 결합해 생산성을 높이고 새로운 사업 기회를 만들려 한다. 이제는 기술 도입을 넘어 실제 성과를 내는 것이 핵심 과제다. [01:41]
• 성과를 위한 세 가지 조건은 AI가 이해할 수 있는 데이터, 구성원이 데이터를 업무에 바로 활용할 수 있는 접근성, 보안과 통제된 거버넌스 안에서의 운영이다. [02:15]

2. 데이터의 분절과 의미 불일치가 AI 활용을 막는다

• 데이터 저장 위치와 지표가 흩어져 있고 부서마다 시스템과 용어가 다르면, AI가 데이터를 제대로 해석해 답하기 어렵다. AI가 데이터 문제까지 알아서 해결할 것이라는 기대가 도입의 걸림돌이 된다. [04:24]
• KB국민은행의 과제에는 부서·시스템별 데이터 사일로, 정형·비정형 데이터의 혼재, 비즈니스 의미를 담은 메타데이터 부족, 데이터 품질과 금융권의 엄격한 거버넌스·컴플라이언스가 포함된다. [06:05]

3. 데이터 수집·문맥 부여·자연어 활용을 하나로 연결한다

• 첫 단계는 조직 안에 분산된 데이터를 모으고 정제하는 것이다. 에이전트가 회사 데이터를 바탕으로 행동하려면 활용할 데이터가 먼저 준비돼야 한다. [06:40]
• 두 번째 단계는 데이터에 비즈니스 문맥을 부여하는 것이다. 팀마다 ‘매출’의 의미가 다를 수 있으므로, AI가 어떤 데이터를 찾아 어떤 의미로 해석해야 하는지 정의해야 한다. [07:05]

4. 시멘틱 뷰가 회사 고유의 용어를 AI와 연결한다

• 현업 인터뷰를 통해 금융·제조 등 업종과 회사마다 사용하는 용어를 정리하고, 각 단어의 의미를 미리 정의한다. 이 정의가 있어야 AI가 해당 회사의 언어를 이해하기 쉬워진다. [08:44]
• 시멘틱 뷰는 데이터의 비즈니스 문맥을 정의하는 레이어다. 데이터만으로 드러나지 않는 업무상 의미를 AI와 에이전트가 이해하도록 돕는다. [09:23]

5. AI의 능력과 기업이 맡길 수 있는 범위를 구분한다

• 티냅스의 기준은 AI가 일을 얼마나 잘했는지 채점하는 데서 나아가, 어디까지 믿고 맡길 수 있는지를 정하는 것이다. 행동하는 에이전트에는 능력뿐 아니라 판단과 행동에 대한 신뢰가 필요하다. [11:33]
• 티냅스는 AI의 판단을 즉시 검증하고, 실수가 발생하면 다음 판단 기준에 반영하는 두 단계 구조를 구축했다. 이 서비스는 스노우플레이크의 보안과 데이터 관리 체계 위에서 운영된다. [12:05]

6. 기존 기업과 스타트업은 출발점이 달라도 데이터 기반이 필요하다

• KB국민은행은 오랜 기간 축적한 데이터를 수집하고 다시 정제해, 에이전트가 신뢰할 수 있는 데이터로 만드는 단계에 있다. 기존 데이터가 많다는 점이 준비 작업의 출발점이다. [14:25]
• 티냅스는 기존에 쌓인 데이터가 적은 신생 기업이므로 처음부터 AI와 에이전트에 맞는 데이터를 만들기 상대적으로 쉽다. 출발점은 달라도 신뢰할 수 있는 데이터 기반이 필요하다는 원칙은 같다. [15:02]

7. 아모레퍼시픽은 브랜드·채널 데이터를 모으고 업무 의미를 입혔다

• 아모레퍼시픽은 브랜드와 채널별로 흩어진 데이터를 통합하고 의미를 부여해 AI가 활용할 수 있는 환경을 구축했다. 데이터가 많아도 위치와 의미를 모르면 활용하기 어렵다는 문제에 대응한 것이다. [17:20]
• ‘지난 분기 북미 신제품 매출’이라는 질문에는 신제품과 북미의 정의가 필요하다. 예시에서는 신제품을 출시 3개월 이내 제품으로, 북미를 미국과 캐나다로 정의해 매출과 관련 프로모션을 해석할 수 있게 한다. [17:53]

8. AI 데이터 서비스를 반복 가능한 파이프라인으로 표준화한다

• 아모레퍼시픽은 내부 시멘틱 매니저로 도메인 용어, 시멘틱 뷰 관련 메타데이터, 배포 이력을 자체 거버넌스에 맞게 관리했다. 실적·고객·재고 등 주제별 시멘틱 뷰도 만들었다. [19:08]
• 코어텍스 서치로 입력 표현을 올바른 브랜드에 매핑하고, 분석 결과를 엑셀로 내보내는 커스텀 툴을 연결했다. 전사에 공개한 서비스의 에이전트는 실적 기반으로 제공됐다. [19:52]

9. 시멘틱 레이어는 의미를, 온톨로지는 객체 간 관계를 다룬다

• ‘고객’은 전체 고객이나 현재 상품 가입 고객 등 서로 다른 범위를 뜻할 수 있다. 시멘틱 레이어·시멘틱 뷰는 이런 비즈니스 맥락을 정의해 AI가 데이터를 이해하도록 돕는다. [21:19]
• 아모레퍼시픽은 객체 간 관계를 표현하는 온톨로지도 적용했다. 재고 부족 상황에서 현재 수치뿐 아니라 발생 이유와 이후 영향의 관계까지 파악하도록 맥락을 구성했다. [22:04]

10. 데이터 플랫폼의 사용 편의성이 업무 집중을 돕는다

• 데이터 플랫폼은 인프라 설정과 튜닝에 전문 지식이 필요한 영역이다. 스노우플레이크의 제품 철학은 사용을 쉽게 만들어 사용자가 비즈니스 문제에 더 집중할 수 있도록 하는 것이다. [23:37]
• 데이터 플랫폼에서 AI 데이터 플랫폼으로의 변화는 모인 데이터를 새로운 AI 기술로 더 쉽게 처리하려는 방향이다. AI가 기존 데이터 분석의 접근성을 높이는 역할을 한다. [24:37]

11. 위메이드플레이는 대용량 게임 로그를 AI가 탐색할 구조로 바꿨다

• 게임에서는 플레이어의 행동 데이터가 초 단위로 대량 발생하고, 사람이 읽기 어려운 JSON 형태로 쌓인다. 위메이드플레이는 복잡한 구조를 컬럼으로 정리하고 흩어진 데이터를 모은 뒤 각 데이터에 의미를 붙였다. [25:39]
• 시멘틱 뷰로 의미를 정리한 결과, 게임 기획자나 운영자가 질문을 세세하게 구체화하지 않아도 AI가 의도를 파악하고 데이터를 탐색할 수 있는 구조를 만들었다. [26:11]

12. 아이스버그로 데이터 이동과 복사에 따른 문제를 줄인다

• 위메이드플레이는 아이스버그 테이블을 사용해 데이터를 스노우플레이크 네이티브 저장소로 옮기지 않고 AWS S3에 저장했다. 카탈로그 연동으로 여러 팀과 도구가 복사 없이 동일한 데이터 환경을 이용하게 했다. [26:30]
• 기존에는 플랫폼 A의 데이터를 플랫폼 B로 전달해야 해 중복 저장과 전송 지연이 발생했다. 이 지연 때문에 최신 데이터를 바로 보기 어려운 문제가 있었다. [27:47]

13. 카탈로그가 여러 엔진의 업데이트를 통제한다

• 카탈로그는 여러 엔진이 같은 데이터를 업데이트할 때 중앙에서 개입해 잘못된 업데이트를 막는 트랜잭션 관리 역할을 한다. 공유 데이터 환경에는 조회뿐 아니라 변경을 조정하는 기능도 필요하다. [29:02]
• 아이스버그와 카탈로그 같은 기술이 향후 데이터 플랫폼의 기반 기술로 시장을 이끌 것이라는 전망이다. [29:23]

14. 질문자가 직접 답을 얻으려면 AI가 데이터 기준을 이해해야 한다

• 위메이드플레이가 지향하는 AX는 질문하는 사람이 직접 답을 얻는 것이다. 그 전제는 AI가 회사 데이터를 알아들을 수 있어야 한다는 점이다. [29:37]
• AI가 이해해야 할 대상에는 컬럼의 의미, 들어오는 값, 집계 기준까지 포함된다. 자연어 질문을 업무에 맞는 답으로 연결하려면 이런 데이터 정의가 필요하다. [29:53]

15. 로그를 펼치고 업무 의미를 부여하는 데이터 정비

• 로그 점검 결과 데이터 구조 전반의 변경이 필요해졌으며, 첫 작업은 뭉친 로그를 컬럼으로 펼치는 평탄화였다. 이어 어디서 질문하든 한 곳에서 답을 얻는 단일 소스화와 AI가 이해할 수 있도록 데이터에 설명을 붙이는 의미 부여를 추진했다. [30:20]
• 데이터의 단순 보관을 넘어 비즈니스 맥락을 진단하고 시맨틱 컨텍스트를 자동 구성하는 방식이 필요하다. 에이전트의 성능을 높이려면 기반 데이터부터 AI가 이해하기 좋은 상태로 만들어야 한다. [30:46]

16. GS건설의 데이터 정리 자동화와 현업 중심 AI

• IT 팀이나 개발자만 사용하는 AI는 조직 전체로 확산되는 속도가 느려질 수밖에 없다. 현업 직원 누구나 직접 사용할 수 있는 환경이 전사 활용의 핵심 조건이다. [31:32]
• GS건설은 프로젝트마다 구조가 다르고 규모가 큰 데이터를 정리·검증하는 과정을 AI로 자동화했다. 현장 직원의 업무는 복잡한 데이터를 직접 처리하는 방식에서 AI가 정리한 결과를 확인하고 승인하는 방식으로 바뀌었다. [32:05]

17. 자연어 질문으로 현장 데이터를 조회하는 업무 방식

• 기존에는 용접 작업이 있었던 현장을 찾으려면 PMX에 접속해 메뉴를 이동하고 조회 조건을 설정한 뒤, 필요하면 엑셀로 내려받아 재가공해야 했다. 신규 담당자나 시스템에 익숙하지 않은 사용자에게는 절차가 복잡했다. [32:44]
• 에이전트 도입 이후에는 원하는 질문을 자연어로 입력한다. 특정일의 용접 작업 현장을 묻는 예시에서 에이전트는 시맨틱 뷰로 질문의 의미를 해석하고 필요한 L2 데이터를 조회하도록 구성됐다. [33:29]

18. 코코가 낮추는 데이터 처리와 시각화의 진입 장벽

• 기존 데이터 정제는 전문가가 SQL이나 파이썬으로 수행했지만, 내장 코딩 어시스턴트인 코코를 이용하면 전문 지식이 없는 사용자도 자연어로 데이터 처리 작업을 요청할 수 있다. [34:54]
• 비전문가가 보유 데이터와 원하는 시각화 형태를 입력하면 대시보드를 자동으로 만들 수 있다. 다른 담당자에게 제작을 요청하던 업무를 사용자가 직접 수행할 수 있는 범위가 넓어진다. [35:26]

19. 네오위즈의 독립 분석 환경과 통합 거버넌스

• 네오위즈의 각 게임은 독립적인 팀이 개발·운영하지만, 같은 데이터 인프라에서 동시에 분석하면서 컴퓨팅 자원 경합이 발생했다. 서로 관련 없는 팀의 분석 작업이 공유 인프라에서 영향을 주는 구조였다. [38:01]
• 각 게임 팀이 독립된 웨어하우스 컴퓨팅으로 분석하고, 거버넌스와 보안 규칙은 하나의 플랫폼에서 일관되게 적용하도록 개선했다. [38:52]

20. 게임 증가에 대응하는 수집·실행 구조의 표준화

• 기존에는 수집·실행 도구가 서로 다른 환경에서 동작하고, 레드시프트도 세 개 클러스터로 나뉘어 있었다. 게임이 늘수록 수집 경로와 운영 경계가 늘어나고, 용량 계획과 확인 지점도 많아지는 것이 과제였다. [41:00]
• 데이터 소스는 유지하면서 수집 경로를 표준화하고, 수집·적재와 실행·오케스트레이션을 구분했다. 게임별 데이터는 AWS DMS의 CDC 방식으로 실시간 수집·적재하고, 이벤트 데이터 수집에는 카프카 경로를 추가했다. [41:58]

21. 데이터 엔지니어의 중심 업무를 품질과 비즈니스 로직으로 이동

• 데이터의 양과 종류가 계속 늘어나는 상황에서는 사람이 수집·처리 과정을 하나씩 관리하는 방식이 한계에 부딪힌다. 프로세스를 더 쉽게 운영하도록 만드는 것이 중요한 과제다. [43:53]
• 코딩 어시스턴트로 기술적 작업을 수행하기 쉬워지면서, 데이터 엔지니어가 처리 효율과 제공 속도뿐 아니라 데이터 품질 향상과 비즈니스 로직 개선에 더 집중할 수 있을 것으로 전망한다. [44:15]

22. 뱅크샐러드의 자동 품질 검증과 부족한 운영 인력

• 사람이 모든 데이터를 검증하기 어려운 규모에 대응해 뱅크샐러드는 스노우플레이크 기반 자동화 환경을 구축했다. 오류를 즉시 감지하고 비즈니스 팀이 직접 데이터 품질을 검증하는 환경으로 운영 자원을 절감했다. [45:47]
• 2024년 초에는 데이터 엔지니어가 부족했지만 기존 파이프라인 운영, 신규 데이터 적재, 품질 확인, 장애 대응 업무는 그대로 남아 있었다. 특히 반복되는 배치 복구가 큰 부담이었다. [46:26]

23. 배치 복구와 느린 분석이 만든 서비스·업무 지연

• 스팟 인스턴스 회수로 배치가 실패하고 자동 재시도까지 실패하면, 담당자가 로그와 실패 지점을 확인해 수동으로 재실행해야 했다. 심한 날에는 하루에 열 번 넘게 실패해 파이프라인 개선보다 전날 배치 복구에 시간을 쓰는 일이 잦았다. [47:31]
• 복구가 늦으면 최신 계산 결과가 사용자의 아침 앱 이용 전에 서빙 계층까지 도착하지 못할 가능성이 있었다. 일부 스파크 쿼리는 3~4분, 일상적으로 확인하는 대시보드는 열리는 데 10분 이상 걸리는 경우가 잦았다. [48:03]

24. 스트리밍 인프라가 데이터 팀에 지우는 운영 부담

• 실시간 처리를 위한 카프카 인프라는 일반 배치 인프라보다 설정과 관리가 어렵다. 데이터 스트림은 고객이 직접 구축·운영하던 부담을 스노우플레이크가 맡아 센서나 보안 관련 실시간 데이터를 수집·분석할 수 있도록 하려는 제품이다. [49:24]
• 기존 스트리밍 환경에서는 토픽 하나를 만들기 전부터 클러스터와 브로커 수·타입·크기를 결정해야 한다. 이후에도 파티션, 복제, 리밸런싱을 관리하지 않으면 장애가 발생할 수 있다. [50:48]

25. 토픽과 물리적 자원을 분리하는 데이터 스트림 구조

• 데이터 스트림은 클러스터 설계보다 토픽 생성을 출발점으로 삼고, 토픽을 스노우플레이크의 카탈로그 자산으로 관리한다. 운영의 중심도 파티션과 리밸런싱에서 데이터 최신성과 파이프라인으로 옮긴다. [51:36]
• 데이터 랜딩 기능을 기본 제공하고, 확장은 클러스터 크기 조정 대신 브로커 그룹 할당으로 처리한다. 컴퓨팅과 스토리지 분리를 스트리밍에 적용하며, 카프카 자체보다 운영 방식을 바꾸는 접근이다. [52:00]

26. 네패스의 정형·비정형 데이터 분석과 사람의 확인

• 네패스는 설비·MES·ERP의 정형 데이터와 매뉴얼·점검 기록의 비정형 데이터를 한곳에 모으고, 그 위에서 AI 에이전트를 활용한다. [53:26]
• 에이전트는 데이터 유형에 따라 정형 데이터 분석 도구와 코텍스 서치를 선택하도록 설계됐다. 데이터의 형태에 맞는 도구를 사용해 분석하는 구조다. [53:52]

27. 제조 AI의 다섯 계층과 의미·거버넌스·비용 통제

• 제조 현장의 데이터가 어디에 있고 어떻게 쓰이는지 먼저 파악한 뒤 업무 의미를 고정해야 한다. 구현 형식보다 AI가 실제 업무 절차를 정확히 이해할 수 있도록 만드는 것이 핵심이다. [54:39]
• 데이터 수집과 의미·저장 기반 위에서 적합한 분석 도구로 해석하고, 해석 결과를 실행으로 연결한 다음 현장 사람이 확인하도록 구성한다. 장비 정지나 품질 저하에 관한 판단도 사람에게 전달하는 단계가 필요하다. [55:31]

28. 실시간 데이터 운영의 책임을 플랫폼으로 이전

• 실시간 데이터 생산자와 소비자 사이에서 신뢰성 있게 데이터를 전달하기 위해 카프카를 사용하지만, 오픈소스 환경에서는 고객이 인프라 설정·관리·튜닝을 직접 담당해야 한다. [56:52]
• 데이터 스트림은 스노우플레이크가 해당 인프라를 제공하고 관리하는 방식이다. 고객이 카프카를 직접 설치하는 부담을 줄여 실시간 데이터를 더 빠르고 안정적으로 처리할 수 있게 한다는 설명이다. [57:31]

29. 기업용 AI 플랫폼의 확장성·개방성·거버넌스

• 기업용 AI 플랫폼은 사용자가 10명일 때나 만 명을 넘을 때나 서로의 업무를 방해하지 않아야 한다. 데이터 수집·처리, BI, AI가 독립적으로 자원을 할당받고 필요에 따라 늘리거나 줄일 수 있는 확장성이 요구된다. [58:31]
• 아파치 아이스버그 같은 개방형 표준을 지원하면 특정 공급업체에 대한 종속을 줄이고 다양한 도구를 조합할 수 있다. 이를 통해 기업별 환경에 맞는 데이터 플랫폼을 구성할 수 있다. [59:15]

30. 사람과 AI 에이전트에 동일하게 필요한 접근 권한 통제

• 데이터에 접근할 수 있는 사람, 실제 접근한 사람, 데이터를 읽는 에이전트를 관리해야 한다. 스노우플레이크의 호라이즌 카탈로그는 민감한 데이터를 자동으로 식별하고, 사용자 권한에 따라 원본 접근이나 마스킹된 데이터 제공을 관리한다. [1:00:43]
• 경영진이 다룬 직원 연봉 정보가 AI를 통해 모든 직원에게 노출될 수 있다는 예시는 정보별 공개 범위를 통제해야 하는 이유를 보여준다. [1:01:15]

31. 토스플레이스의 단일 데이터와 워크로드별 엔진 구성

• 토스플레이스는 아파치 아이스버그를 공통 오픈 포맷으로 선택했다. 스노우플레이크에서 분석하고 스타락스에서 결과를 서비스하면서, 플랫폼 사이에 데이터를 복제하거나 전달하지 않고 실시간으로 활용하는 구조를 구축했다. [1:03:25]
• AI 에이전트는 질문 하나에 SQL 수십 개와 재시도를 발생시킬 수 있고 요청 시점과 규모도 예측하기 어렵다. 서로 다른 워크로드를 하나의 엔진으로 처리하면 비용과 성능 사이에 충돌이 생기지만, 엔진별 전용 포맷으로 복제하면 파이프라인과 저장 비용이 늘고 정합성 문제가 생긴다. 아이스버그를 공통 접점으로 삼아 데이터 한 벌과 워크로드별 최적 엔진을 함께 유지하는 것이 해법이다. [1:05:17]

32. KT의 공통 지표 정의로 해소하는 숫자 불신

• KT의 BI 데이터웨어하우스는 전 직원의 4분의 1 이상이 사용하고 20만 개 이상의 리포트가 활성화된 규모다. 부서마다 매출이나 가입자 수의 집계 항목이 달라 회의가 숫자의 정확성을 따지는 논쟁부터 시작되는 문제가 있었다. [1:07:38]
• KT는 도구가 달라도 지표와 정의는 하나라는 원칙을 세웠다. 개방형 표준을 기반으로 단일 지표 정의 체계를 만들고, 기존 분석 도구와 스노우플레이크가 같은 시맨틱 정의를 참조하도록 설계했다. 도구별 시맨틱 사일로를 막고 숫자에 대한 신뢰를 통일하는 것이 AI 활용 기반을 강화하는 핵심이다. [1:08:30]

33. 여러 AI 플랫폼에서 발생하는 시맨틱 레이어의 파편화

• 전문 업무 분석가들이 AI 에이전트를 적극적으로 활용하면서, 각자의 작업 환경인 스노우플레이크나 데이터브릭스의 네이티브 에이전트를 직접 쓰려는 수요가 커졌다. 이에 따라 기존 도구뿐 아니라 각각의 SaaS 플랫폼에서도 에이전트 기능을 제공해야 했다. [1:09:30]
• 동일한 데이터셋을 사용하더라도 서비스마다 시맨틱 레이어를 별도로 구축하고 관리해야 하는 문제가 생겼다. 현업의 자연어 질문과 데이터베이스 컬럼 정의 사이의 간극을 메우려면 별도의 비즈니스 용어집도 필요해 구축 공수가 커졌다. [1:10:26]

34. 효과가 큰 업무부터 작게 시작하고 성과로 확장하는 AI 도입

• 기업들은 AI를 테스트하는 단계를 넘어 데이터 분석과 업무 자동화에 적용하며 실제 비즈니스 성과를 만들어 가고 있다. [1:12:17]
• 처음부터 전사 프로젝트를 구상하거나 데이터의 충분성·정제 상태를 오래 검토하고, 더 뛰어난 모델을 기다리는 경우가 있다. 반면 일찍 시작한 기업들은 실제 업무에 AI를 적용하며 의미 있는 성과를 만들어 가는 것으로 평가된다. [1:13:04]

35. 데이터 엔지니어의 초점 변화와 플랫폼 선택의 자유

• 데이터 활용의 초점이 비용 효율과 처리 속도에서 비전문가도 데이터를 쉽게 활용하게 만드는 방향으로 이동하고 있다. AI로 데이터 활용의 경계가 빠르게 낮아지면서 엔지니어가 집중할 영역에도 변화가 필요하다. [1:14:31]
• 플랫폼이 기술적 복잡성을 상당 부분 흡수하고, 데이터 엔지니어는 관리된 플랫폼 위에서 AI를 활용해 데이터의 본질적인 가치를 끌어내는 데 더 집중하게 될 것이라는 전망이 드러난다. [1:15:11]

36. 국내 기업의 실제 적용 확대와 향후 관심에 대한 전망

• KB국민은행 사례는 보수적인 금융업에서도 AI 활용에 적합한 데이터를 준비·분석하고 에이전트를 확산하는 과정을 보여주는 사례로 평가된다. [1:16:48]
• 이전 행사에서 개념검증이나 고민 중인 과제가 중심이었다면, 이번 서울 행사에서는 실제로 병목을 돌파한 경험이 늘었다. 국내 기업들도 데이터를 정리해 일반 직원이 AI로 활용하게 하고, 플랫폼을 전사적으로 함께 사용하는 방법을 찾아가는 것으로 평가된다. [1:17:47]

🧾 결론

• 데이터의 위치·품질·업무 의미를 정리하는 작업이 기업 AI 활용의 공통 기반이다. 데이터가 많이 쌓여 있다는 사실만으로 활용 준비가 끝나지는 않는다.
• 데이터 준비, 시멘틱 정의, 자연어 접근, 판단 검증과 거버넌스가 연결돼야 현업의 질문을 신뢰할 수 있는 답과 행동으로 바꿀 수 있다.
• 모든 준비가 끝날 때까지 기다리기보다 효과가 예상되는 업무에서 필요한 데이터와 통제를 마련하고, 검증된 성과를 바탕으로 확장하는 접근이 제안된다.

📈 투자·시사 포인트

• 기업용 AI 플랫폼을 평가할 때 데이터 준비와 업무 의미 관리, 현업 접근성, 보안·거버넌스를 실제로 연결하는 능력을 확인필요가 있다.
• 아이스버그 같은 개방형 표준은 데이터 복제와 공급업체 종속을 줄이고 워크로드에 맞는 엔진을 조합하는 선택지를 제공한다. 사례별 비용·성능 효과는 별도로 확인해야 한다.
• 관리형 플랫폼이 기술적 복잡성을 흡수하면서 데이터 엔지니어의 초점이 품질과 비즈니스 로직으로 이동할 수 있다는 전망이 제시됐다.
• 에이전트는 질문 하나에도 다수의 SQL과 재시도를 발생시킬 수 있다. 도입 효과를 평가할 때 업무 시간 절감뿐 아니라 컴퓨팅·토큰 비용과 운영 부담도 함께 살펴야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• GS건설의 데이터 준비 시간 단축은 소개된 업무 사례의 수치다. 측정 대상과 반복 검증 조건이 제시되지 않아 다른 기업이나 전체 업무에 같은 효과를 적용하기는 어렵다.
• 자연어 분석과 에이전트의 정확도, 판단 검증의 실패율, 권한 통제의 구체적인 설정·검증 절차는 충분히 제시되지 않았다. 기능 소개만으로 운영 안전성을 확정할 수 없다.
• 아이스버그와 관리형 스트리밍의 구조적 장점은 설명됐지만, 전환 비용과 실제 비용·성능 비교 수치는 제시되지 않았다. 코코의 일반 고객사 확산 효과도 전망으로 구분해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 효과가 클 것으로 예상되는 업무 하나를 고르고, 현재 처리 시간·오류·운영 부담을 기록해 도입 후 비교 기준을 마련한다.
• 해당 업무의 데이터 위치, 품질 문제, 컬럼 의미, 값의 범위와 집계 기준을 점검하고 공통 용어 정의를 작성한다.
• 현업의 실제 질문으로 시멘틱 정의와 자연어 조회를 검증하고, 사용 도구가 달라도 같은 지표와 답을 제공하는지 확인한다.
• 에이전트가 읽을 데이터와 수행할 행동의 범위를 정하고, 판단 검증·민감정보 마스킹·사람의 승인 지점을 명시한다.

❓ 열린 질문

• 여러 AI 플랫폼이 같은 업무 의미와 지표 정의를 지속적으로 공유하려면 중앙 메타데이터 관리 체계를 어떻게 운영해야 할까?
• 에이전트의 판단을 즉시 검증하는 기준은 누가 정하고, 발견된 실수를 다음 판단에 반영하는 과정은 어떻게 확인할까?
• 개방형 데이터 포맷과 워크로드별 엔진 구성이 어떤 조건에서 복제·운영 비용을 줄이면서 성능을 유지할 수 있을까?