프론트엔드 개발자들에게 잘 알려진 The State of JavaScript와 비슷한 The State of WebAssembly라는, 개발자들을 대상으로 하는 설문조사를 우연히 알게 되었다. 관련 글과 데이터를 보고 재밌어 보여서 내용과 감상을 글로 남겨본다.
면책 조항
먼저 면책 조항부터 얘기하자. The State of WebAssembly가 WebAssembly에 관한 유일한 설문 조사라서 개인적으로는 나름 재밌게 보았고 이 글을 작성하기도 했지만 표본수가 300명 남짓한, 그리 공신력 있는 조사는 아니다. 아직은 웹 어셈블리에 대한 관심이 적은 게 이유일 것이라 짐작해본다.
WebAssembly는 다양한 언어로 작성할 수 있다. 그렇다면 WebAssembly를 사용하는 개발자들이 가장 많이 사용하는 언어는 무엇일까? 이미 짐작한 분도 있겠지만 정답은 Rust였다.
조금 특이하게 보았던 부분은 의외로 WebAssembly를 작성하는 데 자바스크립트가 많이 사용된다는 것이었다. 방법이 궁금했는데 위에 링크한 글에서는 예시로 Javy를 들면서 자바스크립트 런타임(혹은 엔진)을 웹 어셈블리로 컴파일한 후 그 안에서 JS를 구동한다는 것이었다. 성능 면에서 이점은 없지만 실행 컨텍스트가 완전히 격리되는 만큼 보안 측면에서는 더 나을 거라는 설명이 있었다.
이쯤에서 “굳이?”라는 생각이 들 수 있다. 격리가 필요하다면 Web Worker로 어느 정도 감당이 될 텐데 왜 이런 방법을 사용하는 걸까. 다른 사례의 의도는 잘 모르겠지만 예시로 든 Shopify의 Javy는 Shopify Functions라는 자체 서버리스 플랫폼에 사용되기 위해 QuickJS를 웹 어셈블리로 컴파일하여 작성된 듯하다. 최근 발표한 Ruvy까지 놓고 보면 자사 플랫폼 서비스에서 다양한 백엔드 언어를 지원하는 게 목적인 것으로 보인다. 다시 말해, 이런 플랫폼이 아니라면 JS 런타임을 웹 어셈블리로 사용하는 건 불필요하지 않을까 싶다.
C++은 짐작했던 바이고 Go도 어느 정도는 이해가 되었다. 프론트엔드 개발자에게 상대적으로 친숙한 문법을 내세운 AssemblyScript도 사용한다고 응답은 사람이 생각보다 많아서 의외였다. 새로운 JS 런타임인 Bun 덕분에 유명해진 Zig도 은근히 사용자가 있는 편이었다.
특이한 점은 Zig로 WebAssembly를 사용해보고 싶다는 응답이 현재 사용량에 비해 꽤 높게 나왔다는 것이다. 물론 “WASM으로 사용해보고 싶은 언어” 응답의 양으로 보면 Rust와 JS가 가장 많았다. 하지만 바로 뒤를 이어 Zig가 올라왔다는 점은 눈에 띄었다.
마이너 한 언어를 둘러보는 걸 좋아해서 Zig도 조금씩 맛보고 있었고, 나 역시 WebAssembly 언어로서 Zig를 눈여겨봤기 때문에 나름 반갑기도 한 결과였다. 하지만 Zig라는 언어는, 아직도 발전 중이고 마이너 변경에도 하위 호환성이 깨질 수도 있는 불안정한 언어이다. 이래저래 사용해 보면서 이런 언어로 Bun이라는 결과물을 내놓은 개발자가 대단하다는 생각부터 들었을 정도이다. 이 언어에 대한 감상은 이 글의 주제에서 벗어나므로 나중에 기회가 있을 때 다른 글에서 다루기로 하겠다.
사용 분야를 보면 웹 애플리케이션이 가장 많고 서버리스 애플리케이션과 플러그인, 백엔드 서비스 등이 뒤를 이었다. 다만, 기업에서 사용되고 있거나 사용될 계획 중인 비율은 낮은 수준에 머물러 있었다. 아무래도 아직은 기능 면에서도 부족하고 웹 애플리케이션이 대체로 어마어마한 성능을 필요로 하지 않다보니 JS 정도의 처리 능력이면 충분한 경우가 많아서라고 생각한다.
기능 면에서는 스레드, 예외 처리, 가비지 컬렉션 등에 대한 요구가 높았는데 표준화 단계에서 이미 진척이 많이 된 항목들이라고 하니 조금은 기대가 된다.
마치며
정확한 근거를 들 수는 없지만 머지않은 미래에 WebAssembly는 웹을 구성하는 중요한 요소로 자리매김할 것이라고 생각한다. 섣부른 판단일지 모르나 어쩌면 웹의 유일무이한 언어로서 JS가 지켜온 자리가 조금은 흔들리는 계기가 될 수도 있다. 하지만 이번 설문조사 결과에서 보았듯 WebAssembly의 현재 상태는 아직 갈 길이 멀다. 당장 프로덕션에 적용하기엔 무리겠지만, 조금이라도 더 많은 사람들이 이 기술에 관심을 가졌으면 하는 바람과 함께 글을 마친다.
생성형 AI가 지루한 작업을 처리하고 오류를 찾는 데 능숙하더라도 프로그래머의 전문성과 직관은 항상 필요할 것이다.
ⓒ Getty Images Bank
데이터셋(Datasette)의 설립자 사이먼 윌리슨은 “지금이 프로그래밍을 배우기에 더할 나위 없이 좋은 시기”라고 말했다. AI가 코딩을 대신 해줘서가 아니다. 사실 정반대다. 그는 “대규모 언어 모델은 학습 곡선을 평평하게 만들어 젊은 개발자가 더 쉽게 따라잡을 수 있게 해준다”라고 말했다. 코딩하는 방법을 잊어서는 안 되지만, 생성형 AI를 사용해 경력 수준에 관계없이 개발자 경험을 강화할 수 있다.
‘배움에 대한 의지’를 예찬
필자는 생성형 AI에 대한 윌리슨의 견해를 살피는 것을 즐긴다. 그는 이 주제를 사려 깊게 생각하는 개발자다. 오라일리(O’Reilly Media)의 마이크 루키데스 글도 큰 주제에서 핵심을 압축해 설명했기 때문에 읽어볼 만하다. 루키데스는 생성형 AI와 코딩에 대해 “정말 좋은 프롬프트를 작성하기란 생각보다 어렵다”라는 점을 상기시켜 준다. 그는 “프롬프트를 잘 작성하려면 프롬프트의 목적에 대한 전문 지식을 쌓아야 한다”라고 말했다. 다시 말해, 먼저 ‘좋은’ 프로그래머가 돼야 한다.
루키데스는 “AI를 ‘인간이 얻을 수 없는 전문 지식과 지혜의 보고’로 생각해버리면 이를 생산적으로 사용할 수 없게 된다”라고 조언했다. AWS 코드위스퍼러(CodeWhisperer)나 구글 코디(Codey)와 같은 도구를 효과적으로 사용하기 위해서는 기대하는 결과물을 코칭해야 한다. 그리고 AI에게 개발 문제를 해결하는 방법을 단계별로 알려주려면, 먼저 문제를 깊이 이해하고 AI가 응답하도록 이끌어내야 한다.
또한 개발자는 AI가 틀렸을 때 이를 평가할 수 있어야 한다. 여기엔 일정 수준의 전문성이 필요하다. 윌리슨이 언급한 것처럼 코딩 어시스턴트가 프로젝트에서 더 활발히 일하고 도와줄 것으로 기대되는 상황이지만, 그렇다고 해서 개발자가 코드를 파악해야 할 필요성까지 없애주진 않을 것이다. 그렇게 되기를 바라는 이도 없을 것이다. 다시 윌리슨의 첫 번째 요점으로 돌아가 본다.
AI를 활용한 코딩 학습
특정 언어, 프레임워크, 데이터베이스 등을 처음 접하는 개발자라면 학습 곡선이 가파를 수 있다. 예를 들어 “세미콜론을 놓쳐서 기이한 오류 메시지가 표시되고, 그 오류를 다시 찾는 데 2시간이 걸리는 경우도 있다”라고 윌리슨은 말했다. 당연히 이러한 점 때문에 학생들은 자신이 프로그래밍을 배울 만큼 똑똑하지 않다고 생각해 배움을 포기할 수 있다.
바로 이 부분에서 AI 어시스턴트가 개입할 수 있다. 윌리슨은 “컴퓨터공학 학위가 없어도 컴퓨터가 지루한 일을 대신 해줄 수 있어야 한다”라고 전했다. 챗GPT 같은 LLM 기반 어시스턴트는 지루한 작업을 자동화할 수 있다. 깃허브(GitHub) 엔지니어 자나 도건은 “사람들은 코드 생성에만 너무 집중한 나머지 LLM이 코드 분석에 유용하다는 사실을 완전히 잊고 있다”라고 강조했다. 모든 작업을 AI가 할 필요는 없다. 윌리슨의 주장에 따르면, 애플리케이션을 만들거나 망치지는 않으나 개발자의 자신감을 떨어뜨릴 수 있는, 개별적이고 지루한 작업을 자동화하는 데 AI를 활용할 수 있다. 코딩 어시스턴트가 지루한 작업을 처리할 수 있음에도 개발자가 프로그래밍의 모든 측면을 배우고 수행할 것을 요구받는 경우에 더 그렇다.
언제나 그렇듯 생성형 AI와 함께 소프트웨어 개발을 시작하는 가장 좋은 방법은, 바로 시작하는 것이다. 이해는 했지만 반복해서 작성할 필요는 없는 간단한 작업부터 자동화해 작게 시작하라. 이렇게 절약한 시간으로 더 까다로운 코딩 문제를 해결하는 방법을 배우는 데 집중할 수 있다. 전문성이 높아지면 이러한 작업도 자동화할 수 있게 될 것이다. ciokr@idg.co.kr
웹 3란 무엇일까요? 한마디로 말하면, 웹 3는 모든 자료와 정보가 분산화, 탈중앙화(특정 개인이나 조직이 독점하지 않음) 된 차세대 네트워크 구조를 의미합니다.
1990년대 초, 월드와이드웹(WW)이 정보화 시대를 앞당겨왔습니다. 10년 후, 인터넷은 훨씬 더 성숙하고 프로그래밍 가능한 환경으로 변모했습니다.
우리는 현재 Web2 라고 불리우는 인터넷 환경과 함께하고 있습니다. Web2는 SNS, e-커머스 플랫폼이라는 혁신적인 서비스를 생활 속에 자리잡게 했습니다.
이를 통해 사람들 간의 커뮤니케이션 및 정보의 제공자와 수혜자가 소통하는 방식이 완전히 바뀌었으며, 재화와 서비스들을 조금 더 생활 속에서 가깝게 접근 할 수 있게 되었고, 전세계적으로 P2P 소통이 가능해졌습니다.
하지만 현존하는 인터넷의 대부분 의사소통은 두 대상 ‘A’와 ‘B’ 사이에 서로 알지 못하고 신뢰하기도 어려운 중개인(middleman 또는 intermediary)이 존재합니다.
몇몇 플랫폼들이 놀라운 P2P 경제를 구축하여 유익한 컨텐츠를 제공하고 있기는 하지만, 고객들의 데이터를 수집하고 P2P 거래에 한계가 발생하는 등의 문제점을 내포하고 있습니다.
이러한 상황에서, 블록체인은 다음 세대의 인터넷으로 인류를 이끌어 줄 원동력으로 작용할 것입니다.
분산 웹(또는 Web3)과 함께하는 블록체인은 인류에게 진정한 의미의 중개인 없는 P2P 거래를 가능하게 할 것이며, 비트코인은 이것이 가능함을 수년 동안 보여주어 왔습니다.
비트코인은 은행이나 은행 담당자 없이도 사용할 수 있는 P2P 화폐로 사용되며, 비트코인을 실현한 블록체인 기술은 산업 전반에 응용되고 있습니다.
우버 없는 차량 공유, 에어BNB 없는 주택 공유, 페이스북이나 트위터 없는 SNS 등 중개인을 배제한 진정한 의미의 P2P 경제가 우리 생활로 다가오고 있습니다.
서버의 부재 : 자료 구조를 새롭게 설계하다
우리는 컴퓨터를 작동시키고 인터넷 프로토콜을 통해 인터넷에 접속하게 됩니다. PC 초창기에는 플로피 디스크를 컴퓨터에 집어 넣고, 디스크에 데이터를 저장하여 동료의 컴퓨터에 플로피 디스크를 집어넣은 후 파일을 복사하여 정보를 교환했습니다.
데이터는 복사, 전달을 위해 물리적 장치에 저장되었습니다. 이러한 상황에서 인터넷의 발명은 이러한 과정에서 발생하는 비용과 시간을 획기적으로 줄이는 엄청난 사건이었습니다.
인터넷이 도입 된지 시간이 꽤나 흘렀지만, 현재 데이터 아키텍처는 클라이언트-서버 방식에서 크게 변화하지 못했습니다. 이는 우리들의 데이터가 중앙화 된 서버에 저장되고 인터넷을 통해 검색하여 정보를 탐색하는 방식입니다.
집 안에 있는 냉장고와 토스터까지 인터넷과 연결되는 비교할 수 없을 정도로 연결된 사회에 살고 있음에도 불구하고, 우리의 데이터는 하드디스크, USB, 클라우드와 같은 중앙화 된 저장소에 저장되고 있습니다.
이렇게 중앙화 된 저장소는 ‘데이터 신뢰성’에 문제가 발생합니다. 중앙화 된 저장소에 데이터가 손상된다면? 관리자가 실수를 한다면? 서버 기계가 고장 난다면? 이러한 중앙화 된 자료 구조는 손상되면 복구가 어려운 특정한 지점이 있습니다.
이러한 지점이 공격을 받거나 문제가 생겨 자료에 손상이 간다면 치명적인 피해를 부담해야 할 수 밖에 없습니다.
데이터 왕정에서 데이터 민주주의로
P2P 데이터 아키텍처는 BitTorrent나 Tor browser와 같은 파일 공유 프로그램이 떠오르던 1990년대부터 존재해왔습니다. 암호학과 인센티브 메커니즘 게임 이론이 합쳐진 블록체인은 P2P 아키텍처에 새로운 모델을 제시했습니다.
우리는 모든 데이터가 중앙화 된 컴퓨터에 저장되는 낡은 자료구조에서 벗어나, 분산화 되고 분권화된 새로운 자료구조로 나아가고 있습니다.
웹3는 초연결된 현대 사회의 모든 자료구조를 재정의합니다. 블록체인은 분산 웹 스택 기술들 중 하나로서, 무엇이 언제, 누구에게로부터 발생했는지 기록하는데 유용한 수단이 됩니다.
하지만 현재 블록체인 기술은 2가지 이유로 대용량의 데이터를 저장하는데 한계가 있습니다. (1) 확장성 : 블록체인은 아직까지 매우 느립니다. (2) 블록체인은 설계적으로 개인정보를 저장하지 않습니다.
Web3 기술 스택
평범한 웹, 모바일 어플리케이션을 만드는것과 같이, DApp(분산앱, 댑 또는 디앱으로 읽음)을 만드는 것은 컴퓨팅 자원, 파일 스토리지, 외부 데이터, 통화, 결제 등 어플리케이션을 구성하기 위한 몇가지 요소를 필요로 합니다.
지난 4년동안 커뮤니티는 개발 생태계를 진전시키는 데 큰 성과를 이루었습니다. 2014년까지만 해도 댑을 개발하는 데 어려움들이 있었지만, 현재는 최소한의 컴퓨팅 자원과 파일 스토리지만으로도 댑을 개발할 수 있습니다. 웹3 생태계는 기술스택을 개발하기 위해 오랜 시간 발전해 왔으며, 아래와 같이 구성됩니다.
클라이언트-서버 기반의 전통적인 인터넷에서 분산 웹으로의 전환은 급진적으로 변화하는 것이 아닌, 점진적으로 변화해 나갈 것입니다. 분산 웹 스택이 꾸준히 성숙해 나감에 따라, 이러한 변화는 중앙화 된 형태에서 일부가 분산화 된 형태로, 결국에는 완전히 분산화 된 형태로 변모해 나갈 것입니다.
또한 분산화 된 아키텍처는 네트워크에서 발생할 수 있는 오류에 조금 더 매끄럽게 대처할 수 있으며, 사이버 공격으로부터 공격 받는 구심점이 없기 때문에 보안적으로도 우수합니다.
현재는 속도 면에서 열위가 있지만 꾸준한 개선을 통해 성능을 향상시켜 나갈 것입니다. 미래의 인터넷은 훨씬 더 분산화 되겠지만, 이는 중앙화 된 현재 시스템을 없애버리는 것을 의미하지 않습니다.
중앙화 된 인터넷도 관리, 속도 등의 면에서 장점이 있기 때문에 분산 인터넷과 공존하며 초 연결 사회를 함께 할 것입니다.
[단독] ‘AI 대부’의 경고 “AI 거짓말, 인류는 알아챌 수 없다” | 팩플 / “인류 재앙, 막을 방법 모른다” AI 대부가 AI 미래 경고했다
중앙일보
입력 2023.10.19 05:00
김남영 기자
‘나는 인간보다 멍청해요.’
인간보다 뛰어난 인공지능(AI)이 천연덕스럽게 이런 거짓말을 한다면, 인류는 어떻게 해야 할까. 세계적인 AI 석학 제프리 힌턴 토론토대 명예 교수는 “초지능(Super Intelligence)이 된 AI가 작정하고 우릴 속인다면, 인류는 알아차릴 수도 막을 방법도 없다”며 “그런 상황이 되기 전에 전 세계가 AI 통제에 나서야 한다”고 말했다. 지난 4일(현지시간) 캐나다 토론토에서 중앙일보와 가진 인터뷰에서다. 그는 AI의 위험성을 더 자유롭게 비판하겠다며 지난 4월 구글을 퇴사했다.
‘AI의 대부’로 불리는 힌턴 교수는 현재 AI 기술의 뿌리인 딥러닝(심층학습) 연구의 핵심 기여자다. 구글의 알파고나 오픈AI의 챗GPT는 모두 그의 딥러닝(심층학습) 연구를 기반으로 한다. 지난 5월 뉴욕타임스와 인터뷰로 AI 위험성을 전 세계에 경고한 이후, 그가 한국 언론과 한 대면 인터뷰는 이번이 처음. 그는 AI가 초래할 다양한 위험을 강조하며 “전 세계가 머리를 맞대야 한다”고 말했다.
제프리 힌턴 토론토대 명예교수가 지난 4일(현지시간) 캐나다 토론토에 위치한 벡터연구소에서 중앙일보와 인터뷰를 하고 있다. 김남영 기자
우리가 지금 논의해야 할 AI 문제는 뭔가?
(AI와 관련된) 모든 위험에 관한 생각을 모아야 한다. 나는 AI가 초래할 ‘실존적 위험’에 가장 주목한다. 디지털 지능이 우리 인간보다 더 똑똑해져서 인간을 통제하려 할 상황에 대비해야 한다. 사람보다 똑똑한 디지털 지능(초지능)은 이르면 5년쯤 후에, 늦어도 20년 안에는 나올 것이다.
기술 기업들의 경쟁이 초지능 개발을 앞당길까.
그렇다. 그 개발을 멈추게 할 순 없다. 하지만 (AI가 인류를) 통제하려는 욕구를 갖는 건, 막을 수는 있다. 이 물건(AI)을 만드는 단계일 때, 막아야 한다. 안 그러면 늦는다.
초지능이 ‘자신이 인류에게 위험하다’는 것을 숨기고, 인간을 속인다면 인간이 그걸 알아챌 수 있나?
(초지능이) 우리보다 똑똑해지면 감지하기 어렵다. 자, 두 살짜리 아이에게 “완두콩을 먹을 거니, 브로콜리를 먹을 거니?”라고 묻는다면, 이 아이는 둘 다 먹지 않아도 된다는 사실을 모른다. 당신이 (둘 중 하나라도 먹게끔) 조종하고 있단 것도 아이는 모른다. 초지능은 이런 식으로 인간을 아주 쉽게 조종할 수 있을 것이다.
실존적 위험이 아닌 다른 위험은.
다양한 ‘사회적 위험’이 있다. 우선 일자리가 사라져 실업자가 대량으로 발생할 거다. 가짜뉴스도 있다. 생성 AI로 만든 비디오와 음성, 텍스트는 (진짜와) 구분하기가 훨씬 더 어렵다. 각 나라는 위조 화폐를 직접 찍어내거나, 위조된 걸 알면서도 이를 타인에게 전달하고 거래 수단으로 쓰면 강하게 처벌한다. 가짜뉴스도 비슷한 방식으로 처벌할 수 있을 거다. 또 편향된 데이터로 학습된 AI는 매우 편향된 결정을 내릴 수 있다. 마지막으로 AI의 힘을 악용해 만드는 전투 로봇이 있다.
전투 로봇은 어떻게 우리를 위협할까.
AI의 힘을 악용하려는 ‘악의적 행위자’들이 현실에 존재한다. 전투 로봇이 그 사례다. 나는 미군이 향후 10년 안에 상당수의 인간 병력을 전투 로봇으로 대체할 거라고 믿는다. 세계 각국 군부들도 AI를 무기로 쓰려 한다.
힌턴 교수는 초지능이 인간을 위협할 상황에 대비하기 위해 국제기구를 조직해야 한다고 주장했다. 그는 미국과 갈등하는 중국·러시아도 초지능 통제를 위해선 손잡을 수밖에 없을 거라고 전망했다.
특히 미국과 중국은 AI 기술 전쟁 중인데, 그런 협력이 가능할까.
그들(중‧러)은 디지털 지능이 인류를 장악하는 것을 막는 일에는 참여할 것이다. 러시아, 중국, 이스라엘 그 누구도 디지털 지능이 인류를 장악하길 원하지 않는다. 실존적 위험의 경우 인류 외부로부터의 위험이기 때문에 모두 기꺼이 협력할 것이라고 본다.
제프리 힌턴 토론토대 명예교수가 지난 4일(현지시간) 캐나다 토론토의 마스 디스커버리 스트릭트에서 열린 대담 강연에서 발표하고 있다. 사진 토론토대
힌턴 교수는 오픈소스 AI에 대해 강하게 우려했다. 메타(옛 페이스북)가 개발한 오픈소스 거대언어모델(LLM)인 라마가 지난 2월 공개된 이후 누구나 AI 언어모델을 무료로 내려받아 쓸 수 있게 됐다. 일각에선 이를 테러 집단이나 독재 정권에서 악용될 우려를 제기한다. 힌턴 교수 역시 “오픈소스 AI는 ‘오픈소스 핵 무기’와 같다”며 “사기나 사이버 공격 방법을 AI에 더 쉽게 가르칠 수 있다”고 평가했다. 그러면서도 “막기엔 이미 너무 늦었다”고 토로했다.
힌턴 교수와 같은 우려가 커지면서 각국 정부는 ‘AI 가드레일(안전장치)’ 만들기에 착수했다. 유럽 의회는 지난 6월 세계 최초 AI 규제인 ‘AI법(AI Act)’을 본회의에서 통과시켰다. 미국 바이든 행정부는 지난 7월 생성 AI로 만든 콘텐트에 워터마크를 붙이는 등 AI 안전 장치를 마련하도록 AI 개발을 주도하는 7개 기업에 자율 규제안을 제시했다. 영국에선 다음달 1일 G7 국가를 포함해 전 세계 정상들이 모여 AI 기술의 위험성을 공유하고 이를 완화하기 위한 규제를 논의하는 ‘AI 안전 정상회의’가 열릴 예정이다.
편집자주챗GPT가 등장한 이후 세상이 인공지능(AI)으로 들썩이고 있습니다. 하루가 다르게 기술이 변하고 뉴스가 쏟아집니다. 날고 기는 업계 전문가들조차 정신을 못 차릴 정도라고 해요. 다 먹어 치우기엔 벅차지만 그렇다고 굶을 수도 없겠죠. 주간 AI 이슈 중 핵심만 쏙쏙 골라 먹기 좋게 전달해 드립니다
오픈AI, 매출 50배 ‘폭풍성장’
샘 올트먼 오픈AI 대표가 9일 서울 여의도 63스퀘어에서 중소벤처기업부 주관으로 열린 ‘K-Startups meet OpenAI’에서 대담을 갖고 있다. 사진=강진형 기자aymsdream@
챗GPT 개발사인 오픈AI가 올해 연간 매출 13억달러(약 1조7500억원)를 기록할 전망입니다. 샘 올트먼 오픈AI 최고경영자(CEO)가 회사 직원들에게 이 같은 내용을 공유했다는데요. 지난해 매출 2800만달러(약 3780억원)와 비교하면 50배 가까이 급성장한 겁니다. 올 상반기까지만 해도 연간 매출 10억달러 수준을 달성할 것으로 보인다고 했는데 전망치가 이보다 30% 늘었네요. 현재 오픈AI는 챗GPT 유료 구독 서비스나 대규모언어모델(LLM) 응용프로그램 인터페이스(API) 제공으로 매출을 올리고 있습니다. 오픈AI는 기업 간 거래(B2B) 사업을 강화하며 수익화에 드라이브를 걸고 있는데요. 오는 11월에 열리는 개발자 컨퍼런스에선 AI 모델을 좀 더 저렴하게 이용할 수 있는 기술을 공개해 기업 고객 공략에 나섭니다. 텍스트 외에도 이미지, 오디오, 비디오 등 다양한 정보를 처리하는 AI로 사업 영역을 확대할 계획이라네요.
“생성형 AI 내년엔 거품 꺼진다”
올해 붐이 일었던 생성형 AI 기술이 내년에는 고비를 맞을 것이라는 전망이 나왔습니다. 시장분석기관 CSS 인사이트는 연례보고서를 통해 이 같은 분석을 내놨는데요. 이유는 크게 두 가지입니다. 하나는 생성형 AI를 구동하는 데 필요한 비용 부담이 갈수록 커지고 있다는 건데요. 챗GPT의 경우 하루 9억원가량의 운영 비용이 드는 것으로 알려졌습니다. 또 다른 이유는 생성형 AI 기술을 둘러싼 각국 규제들이 본격화되고 있다는 겁니다. 유럽연합(EU)을 시작으로 여러 국가에서 AI 기술 규제를 도입하려는 움직임을 보이고 있죠.
“구글 바드는 전기 먹는 하마”
사진=픽사베이 [이미지출처=픽사베이]
구글이 모든 검색 서비스를 AI와 결합할 경우 매년 한 국가의 소비량과 맞먹는 전력을 쓰게 된다는 연구 결과가 나왔습니다. 과학 저널 줄(Joule)에 실린 한 논문은 구글이 검색 서비스 전체를 AI 챗봇으로 제공할 경우 에너지 사용량이 10배 이상 늘어날 것으로 전망했는데요. 일반적인 구글 검색은 1회 검색 시 0.3와트시(Wh)의 전력을 소비합니다. 이에 비해 생성형 AI를 활용한 검색은 1회당 3Wh의 전력이 필요하다고 하네요. 연간 단위로 계산하면 아일랜드가 한 해 사용하는 전력량과 맞먹는 전기를 소비하는 겁니다. 전기를 많이 쓴다는 건 탄소 배출량이 늘어난다는 얘기인데요. 생성형 AI 시장을 선점하기 위해 속도전을 벌이는 빅테크(대형 정보기술 기업)들의 고민이 또 하나 늘었네요.
AI로 신호등 제어…배기가스 줄인다
사진=픽사베이 [이미지출처=픽사베이]
그런가 하면 구글은 배기가스를 줄이는 프로젝트에 AI를 활용하고 있습니다. ‘프로젝트 그린 라이트’가 그것인데요. AI를 활용해 교통 신호 체계를 최적화하고 이를 통해 배기가스를 줄이는 프로젝트입니다. 방법은 이렇습니다. AI가 구글 지도 데이터를 학습해 신호등이 있는 곳의 정체 정도와 정차 차량의 평균 대기 시간 등을 계산합니다. 이를 토대로 신호 타이밍을 최적화해 자동차의 대기 시간, 제동·가속 횟수를 줄이는 거죠. 구글은 2021년 이 프로젝트를 이스라엘에서 처음 테스트했는데 연료 소모량이나 신호 대기 시간이 10~20% 감소했다고 합니다. 2024년에는 더 많은 도시로 프로젝트를 확장할 계획입니다. 이를 통해 2030년까지 탄소 배출량을 1Gt(기가톤) 줄이는 게 목표라고 하네요.
AMD, AI 스타트업 인수…엔비디아 독주 막나
[이미지출처=로이터연합뉴스]
미국 반도체 기업 AMD가 AI 스타트업 ‘노드.AI’를 인수한다는 소식입니다. 노드.AI는 오픈소스 기술 기반으로 AI 소프트웨어(SW)를 개발하는 스타트업인데요. 특히 AI 모델 최적화에 전문성이 있다고 합니다. AMD가 노드.AI를 인수한 것은 AI 반도체 시장에서 엔비디아를 따라잡기 위한 전략이죠. 현재 그래픽처리장치(GPU) 등 AI 반도체 시장에서 엔비디아의 점유율은 80% 이상에 달합니다. AMD가 엔비디아의 독주를 막을 수 있을지 주목받고 있습니다.
올해의 단어를 꼽으라면 ‘LLM(대규모언어모델)’을 빼놓고 이야기하기는 힘들 것 같다. 작년 말 오픈AI의 챗GPT가 공개된 이후 LLM은 정보기술(IT) 분야를 넘어서 일상 곳곳에 자리잡았다.
그런데 불과 1년 만에 LLM이라는 단어도 낡은 유산으로 전락할 처지다. LLM을 대신할 새로운 용어가 인공지능(AI) 업계에 등장했기 때문이다. 바로 ‘LMM(대규모멀티모달모델)’이 챗GPT 등장 1년 만에 AI 업계의 판도를 바꿀 새로운 ‘게임 체인저’로 주목받고 있다.
오픈AI가 최근 공개한 LMM ‘GPT-4V’를 이용해 존맛탱이 들어간 이미지에 대해 설명해달라고 했더니 ‘맛있는 음식’을 의미한다고 정확하게 설명해준다.
LLM와 LMM의 차이는 언어와 멀티모달에 있다. LLM이 대규모로 언어 모델을 학습했다면 LMM은 멀티모달을 학습했다고 보면 된다. 멀티모달은 텍스트 외에 이미지와 음성 같은 다양한 방식을 사용하는 AI를 말한다. 챗GPT가 텍스트에 기반해서 이용자와 질문과 대답을 주고 받는 AI였다면 LMM을 적용한 AI는 텍스트뿐만 아니라 이미지와 음성까지도 이용할 수 있게 되는 셈이다.
LMM은 많은 AI전문가들이 챗GPT의 다음으로 주목했던 기술이다. 하지만 이미지와 음성을 인식하고 출력하는 기술은 텍스트를 대상으로 하는 것과는 비교가 안 되게 어려움이 클 것이라는 예상이 많았다. LMM의 시대가 오기까지는 제법 시간이 걸릴 것이라는 전망이 많았다.
그런데 오픈AI가 다시 한 번 그 예상을 깼다. 오픈AI가 지난 9월 25일 공개한 ‘GPT-4V(ision)’는 AI 전문가들을 깜짝 놀라게 했다. GPT-4V는 이용자가 이미지를 올리고 이미지에 대한 질문을 할 수 있는 LMM으로, 사실상 전 세계에서 처음으로 대중화된 LMM 서비스다. 오픈AI는 이미 작년 말 GPT-4V를 위한 학습을 마치고, 올해에는 알파 그룹의 사용자에게 접근 권한을 부여한 뒤 테스트를 진행해 GPT-4V의 신뢰도를 높였다. 공개 직전인 9월 초에는 베타테스터 규모를 1만6000명까지 늘리기도 했다.
이렇게 출시된 GPT-4V는 챗GPT와는 또다른 충격을 주고 있다. 많은 사람들이 GPT-4V가 어떤 이미지까지 인식할 수 있는지 실험에 나서고 있는데, 챗GPT가 처음 나왔을 때 챗GPT에 질문을 던지는 게 일종의 ‘밈’처럼 이뤄진 것과 같은 분위기다.
지난 9월 29일에는 마이크로소프트의 연구자들이 GPT-4V를 이용해 다양한 실험을 진행한 논문이 공개되기도 했다. 단순한 이미지 해석에서부터 스도쿠 같은 게임을 이용한 추리, 인물의 표정을 통해 기분을 유추하는 것 등 다양한 실험이 망라돼 있었다.
특히 인상깊은 건 엑스레이 이미지를 보고 골절 부위를 지목한다거나 영어가 아닌 다른 국가의 언어가 들어간 이미지까지 제대로 해석해서 설명을 내놓는다는 점이었다. 김밥을 만드는 순서를 정확하게 나열하거나 손글씨로 제시된 이미지도 문제 없이 이해하는 모습이었다.
GPT-4V에 김밥을 만드는 과정을 담은 이미지 5개를 제시하고 순서대로 배치하라고 하자 정확하게 나열한 모습.
GPT-4V에 인물의 얼굴을 담은 사진을 제시하자 인물이 어떤 감정 상태인지를 묘사하고 있다.
김진중 원티드랩 생성 AI팀 리더는 자신의 페이스북에 올린 글에서 “GPT-4V는 이미지 판별, 디텍팅, OCR은 물론이고 X-Ray 분석과 밈의 이해와 설명까지 한다”며 “챗GPT가 처음 나왔을 때 정도의 충격”이라고 평가했다. 그는 GPT-3로 AI 업계가 완전히 바뀐 것과 같은 상황이 다시 올 것이라고도 내다봤다.
논문을 작성한 연구진은 “GPT-4V 같은 시각적인 프롬프트를 이용한 방식은 인간과 컴퓨터가 상호 작용하는 새로운 길을 열 수 있다”며 “LMM은 LLM에서 한 단계 더 나아가서 다양한 감각을 갖춘 일반적인 지능을 달성하게 해줄 것”이라고 밝혔다.
오픈AI가 선수를 쳤다면 구글은 반격을 준비하고 있다. 구글이 이르면 다음 달 공개할 예정인 제미니 역시 LMM을 표방하고 있다. 주빈 가라마니 구글 딥마인드 부사장은 지난 5월 열린 구글 연례 개발자 회의에서 “멀티모달은 의료 서비스, 가상 비서, 자율주행 같은 다양한 분야에서 활용도가 높다”며 LMM을 차세대 AI 서비스로 지목한 바 있다.
[인공지능 기술] WebGPU powered machine learning in the browser with Apache TVM : Apache TVM을 사용하여 브라우저에서 WebGPU 기반 기계 학습
By Tianqi Chen, Jared Roesch, and Jason Knight
TL;DR
Easy ML deployment in the browser with near-native GPU performance and WebAssembly
We introduced support for WASM and WebGPU backends to the Apache TVM deep learning compiler Our initial experiments shows that TVM’s WebGPU backend can get close to native GPU performance when deploying models in the browser.
Introduction — faster browser applications
WebGPU and WebAssembly are two up-and-coming browser standards aimed at making browser based applications as efficient as native applications while retaining hardware portability. WebGPU first builds on top of the lower level graphics API movements to enable more full featured GPU accelerated compute capabilities as compared to its predecessor WebGL, and WebAssembly (WASM) is a similar effort for unlocking CPU based compute capabilities. And best of all, WASM is most likely already enabled in the browser you’re reading this in, with WebGPU coming soon.
For some of the exciting capabilities and use cases behind WASM particularly, please check out Lin Clark’s excellent WASM “skill tree”
WASM’s post MVP skill tree
Leveraging more of these WASM capabilities such as SIMD support and multi-threading as they mature is an exciting area of future work, but let’s see how far we can get with WASM and WASI (standard interfaces) to feed WebGPU compute shaders.
Machine learning in the browser
While efforts like TensorFlow.js and ONNX.js attempt to bring machine learning to the browser, there still exist non-trivial gaps in performance between the web versions and native ones. One of the many reasons behind these gaps are the lack of standard and performant access to the GPU on the web. WebGL lacks important features such as compute shaders and generic storage buffers that are necessary for high performance deep learning.
WebGPU offers the potential to bridge this gap with its first-class compute shader support.
To explore the potential of using WebGPU for deploying machine learning in the browser, we enhanced the deep learning compiler Apache (incubating) TVM to target WASM (for host code that computes the launching parameters and calls into the device launch) and WebGPU (for device execution). Our preliminary results are quite positive — for the first time, we can deploy machine learning applications on the web while still getting near native performance on the GPU.
Please check out our companion Apache TVM technical blog post for the technical details, but in short, we were able to achieve near native GPU performance in the browser through WASM and WebGPU by combining:
TVM’s existing LLVM backend for it’s WASM generation support
A new tvmjs TypeScript runtime
WASM’s standard interfaces (WASI) for system library calls (eg malloc, stderr)
Chrome’s nightly WebGPU support
One important advantage of the compilation based approach is the reuse of infrastructure. We are able to effortlessly relative to other approaches target the web by reusing the infrastructure for optimizing GPU kernels for native platforms such as CUDA, Metal and OpenCL. If the mapping of the WebGPU API to native APIs is efficient we can expect similar performance with very little work. More importantly, the AutoTVM infrastructure allows us to specialize the compute shaders for specific models, enabling the generation of the best compute shaders for our specific model of interest.
Performance
We ran a quick experiment comparing the execution of a full Mobilenet execution via TVM’s WebGPU backend and native targets that use native GPU runtimes (Metal and OpenCL). We find that WebGPU get’s quite close to matching the performance of Metal. Assuming Chrome WebGPU’s runtime targets Metal instead of OpenCL on the MacOS, we can safely assume there is little to no performance loss when targeting the GPU through the browser here.
We also expect further performance boosts by applying AutoTVM tuning on the GPU being used by the browser since these results are based off previously auto-tuned schedules from a GTX 1080 Ti, which is quite different from the Intel graphics GPU. To make this easier, we expect our upcoming improvements to the uTVM runtime (stay tuned to this blog for an update in the next 1–2 weeks) for embedded microcontrollers will help make autotuning easier in the browser since WASM targets share many similarities to embedded devices.
Looking to the Future
Our results suggest many interesting opportunities for machine learning on the web. Notably, WebGPU is an API that is still evolving and its implications could go beyond web applications. For example one could target native APIs of WebGPU as it matures and becomes standardized through WASI, enabling standalone WASM applications that make use of WebGPU.
The TVM community is also actively working on a Rust based runtime that would enable much more robust WASM support and enable easier interaction with projects like wgpu, and the Rust WASM ecosystem. As an open source project, we are looking for contributors who can bring in new ideas and help push the project in these exciting directions.
The proposed approach provides effective machine learning support for most WASM’s application scenarios. The close to native performance could also unlock better federated learning capabilities on the browser. The same compiled package should also be able to run on native WASM executors to provide sandbox for the applications.
Show me the Details/Code
Detailed technical version of this blog post
Example project for image classification
Apache TVM on github
Acknowledgement
We would like to thank the emscripten project for providing the WASM compilation infrastructures as well as the JS library support on the web. We would also like to thank the WebGPU community for various helpful discussions. Thanks to Fletcher Haynes for valuable feedback on the post.
Apache TVM 딥 러닝 컴파일러 에 WASM 및 WebGPU 백엔드에 대한 지원을 도입했습니다 . 초기 실험에 따르면 브라우저에 모델을 배포할 때 TVM의 WebGPU 백엔드가 기본 GPU 성능에 근접 할 수 있는 것으로 나타났습니다.
소개 — 더 빠른 브라우저 애플리케이션
WebGPU 와 WebAssembly 는 하드웨어 이식성을 유지하면서 브라우저 기반 애플리케이션을 기본 애플리케이션만큼 효율적으로 만드는 것을 목표로 하는 두 가지 최신 브라우저 표준입니다. WebGPU는 먼저 낮은 수준의 그래픽 API 움직임을 기반으로 구축되어 이전 WebGL에 비해 더 많은 기능을 갖춘 GPU 가속 컴퓨팅 기능을 지원하며 WebAssembly(WASM)는 CPU 기반 컴퓨팅 기능을 잠금 해제하기 위한 유사한 노력입니다. 무엇보다도 WASM은 이 글을 읽고 있는 브라우저에서 이미 활성화되어 있을 가능성이 높으며 WebGPU도 곧 출시될 예정입니다 .
특히 WASM의 흥미로운 기능과 사용 사례에 대해서는 Lin Clark의 우수한 WASM “스킬 트리”를 확인하세요.
WASM의 포스트 MVP 스킬 트리
SIMD 지원 및 멀티스레딩과 같은 WASM 기능이 성숙해짐에 따라 더 많이 활용하는 것은 미래 작업의 흥미로운 영역이지만 WebGPU 컴퓨팅 셰이더에 공급하기 위해 WASM 및 WASI(표준 인터페이스)를 통해 얼마나 멀리까지 갈 수 있는지 살펴보겠습니다.
브라우저에서의 머신러닝
TensorFlow.js 및 ONNX.js와 같은 노력이 기계 학습을 브라우저에 도입하려고 시도하는 동안 웹 버전과 기본 버전 사이에는 여전히 성능 차이가 적지 않습니다. 이러한 격차의 원인 중 하나는 웹에서 GPU에 대한 표준 및 성능 액세스가 부족하기 때문입니다. WebGL에는 고성능 딥 러닝에 필요한 컴퓨팅 셰이더 및 일반 스토리지 버퍼와 같은 중요한 기능이 부족합니다.
WebGPU는 최고 수준의 컴퓨팅 셰이더 지원을 통해 이러한 격차를 해소할 수 있는 잠재력을 제공합니다.
브라우저에 기계 학습을 배포하기 위해 WebGPU를 사용할 수 있는 가능성을 탐색하기 위해 WASM(실행 매개변수를 계산하고 장치 실행을 호출하는 호스트 코드용) 및 WebGPU(장치용)를 대상으로 딥 러닝 컴파일러 Apache(인큐베이팅) TVM을 향상했습니다. 실행). 우리의 예비 결과는 매우 긍정적입니다. 처음으로 GPU에서 기본 성능에 거의 근접하면서 웹에 기계 학습 애플리케이션을 배포할 수 있었습니다.
기술적 세부 사항은 함께 제공되는 Apache TVM 기술 블로그 게시물을 확인하세요 . 간단히 말해서 우리는 다음을 결합하여 WASM 및 WebGPU를 통해 브라우저에서 거의 기본 GPU 성능을 달성할 수 있었습니다.
WebGPU 컴퓨팅 API를 대상으로 하는 TVM의 기존 SPIR-V 코드 생성 기능
WASM 생성 지원을 위한 TVM의 기존 LLVM 백엔드
새로운 tvmjs TypeScript 런타임
시스템 라이브러리 호출(예: malloc, stderr)을 위한 WASM의 표준 인터페이스(WASI)
Chrome의 야간 WebGPU 지원
컴파일 기반 접근 방식의 중요한 이점 중 하나는 인프라를 재사용한다는 것입니다. 우리는 CUDA, Metal 및 OpenCL과 같은 기본 플랫폼에 대해 GPU 커널을 최적화하기 위한 인프라를 재사용함으로써 다른 접근 방식 에 비해 웹을 대상으로 하는 작업을 쉽게 수행할 수 있습니다 . WebGPU API를 네이티브 API로 매핑하는 것이 효율적이라면 거의 작업하지 않고도 비슷한 성능을 기대할 수 있습니다. 더 중요한 것은 AutoTVM 인프라를 통해 특정 모델에 대한 컴퓨팅 셰이더를 전문화하여 특정 관심 모델에 가장 적합한 컴퓨팅 셰이더를 생성할 수 있다는 것입니다.
성능
우리는 TVM의 WebGPU 백엔드와 네이티브 GPU 런타임(Metal 및 OpenCL)을 사용하는 네이티브 대상을 통해 전체 Mobilenet 실행 실행을 비교하는 빠른 실험을 실행했습니다. 우리는 WebGPU가 Metal의 성능과 거의 일치한다는 것을 알았습니다. Chrome WebGPU의 런타임이 MacOS의 OpenCL 대신 Metal을 대상으로 한다고 가정하면 여기에서 브라우저를 통해 GPU를 대상으로 할 때 성능 손실이 거의 또는 전혀 없다고 안전하게 가정할 수 있습니다.
또한 이러한 결과는 Intel 그래픽 GPU와 상당히 다른 GTX 1080 Ti의 이전 자동 조정 일정을 기반으로 하기 때문에 브라우저에서 사용되는 GPU에 AutoTVM 조정을 적용하면 성능이 더욱 향상될 것으로 예상 됩니다 . 이를 더 쉽게 만들기 위해 내장형 마이크로컨트롤러에 대한 uTVM 런타임의 향후 개선 사항(향후 1~2주 내에 업데이트를 위해 이 블로그를 계속 지켜봐 주시기 바랍니다)은 WASM 타겟이 내장형과 많은 유사점을 공유하므로 브라우저에서 자동 조정을 더 쉽게 만드는 데 도움이 될 것으로 기대합니다. 장치.
미래를 바라보며
우리의 결과는 웹에서 기계 학습을 위한 많은 흥미로운 기회를 제시합니다. 특히 WebGPU는 여전히 진화하고 있는 API이며 그 의미는 웹 애플리케이션을 넘어설 수 있습니다. 예를 들어 WebGPU가 성숙해지고 WASI를 통해 표준화됨에 따라 WebGPU의 기본 API를 대상으로 하여 WebGPU를 활용하는 독립형 WASM 애플리케이션을 활성화할 수 있습니다.
TVM 커뮤니티는 또한 훨씬 더 강력한 WASM 지원을 가능하게 하고 wgpu 및 Rust WASM 생태계와 같은 프로젝트와의 더 쉬운 상호 작용을 가능하게 하는 Rust 기반 런타임 에 적극적으로 노력하고 있습니다 . 오픈 소스 프로젝트로서 우리는 새로운 아이디어를 가져오고 프로젝트를 이러한 흥미로운 방향으로 추진하는 데 도움을 줄 수 있는 기여자를 찾고 있습니다.
제안된 접근 방식은 대부분의 WASM 애플리케이션 시나리오에 효과적인 기계 학습 지원을 제공합니다. 기본 성능에 가까워지면 브라우저에서 더 나은 연합 학습 기능을 활용할 수도 있습니다. 동일한 컴파일된 패키지는 기본 WASM 실행기에서도 실행되어 애플리케이션에 샌드박스를 제공할 수 있어야 합니다.
세부정보/코드를 보여주세요.
이 블로그 게시물의 자세한 기술 버전
이미지 분류를 위한 예시 프로젝트
github의 Apache TVM
승인
웹에서 WASM 컴파일 인프라와 JS 라이브러리 지원을 제공한 emscripten 프로젝트에 감사드립니다. 또한 다양한 유용한 토론을 해주신 WebGPU 커뮤니티에도 감사의 말씀을 전하고 싶습니다. 게시물에 귀중한 피드백을 주신 Fletcher Haynes에게 감사드립니다.
여러 대형 기업이 생성형 인공지능(AI) 관련 서비스를 경쟁적으로 출시하고 있지만, 서비스 운영 비용 때문에 골머리를 앓고 있다. 마이크로소프트는 작년 출시한 깃허브 코파일럿 서비스로 사용자당 20달러를 손해보는 것으로 알려졌다.
9일(현지시간) 월스트리트저널(WSJ)에 따르면, 마이크로소프트는 150만명 사용자를 확보한 깃허브 코파일럿 서비스에서 사용자당 월평균 20달러의 손실을 기록중이라고 한다. 일부 사용자는 한달 최대 80달러의 비용을 지출하게 하는 것으로 나타났다.
깃허브 코파일럿은 개발자에게 코드를 생성해주고, 빠르게 수정할 수 있게 해주는 서비스다. 오픈AI의 코드생성모델인 코덱스를 사용한다. 이 서비스 요금은 사용자당 월 10달러다. 산술적으로 1천500만달러를 매월 벌어들이고 있다.
깃허브 코파일럿
그러나 생성 AI는 이용자의 사용량에 따라 운영비용이 증가하는 구조를 보이고 있다. 아직 규모의 경제에 도달하지 못했기 때문에 서비스 공급비용이 수익보다 크다. 특정 사례에서 사용자의 쿼리에 더 막대한 연산비용을 투입해야 할 수 있고, 사용량만큼 운영비용도 선형적으로 증가하는 적자 구조다.
월 10달러란 정액제는 이런 비용 구조에서 서비스제공기업에게 불리하다.
깃허브 코파일럿은 사용자를 개발자로 한정한다. 반면, 윈도나 오피스 제품군의 코파일럿은 일반 대중과 기업 근로자를 대상으로 한다.
마이크로소프트365 코파일럿의 월 이용료는 사용자당 월 30달러다. 마이크로소프트365 기업용 요금제는 최소 월 13달러다. 기업은 매달 최소 43달러를 마이크로소프트에 지불하게 된다.
만약 마이크로소프트가 코파일럿 서비스의 적자구조를 해결하지 못하면 당분간 실적 악화를 피할 수 없다. 이는 자칫 사용자 대상 요금의 인상을 유도할 수 있는 문제다.
월스트리트저널은 마이크로소프트, 구글, 오픈AI, 줌 등의 기업 경영진이 곧 생성 AI 비용을 더 면밀하게 살피게 될 것이라고 전망했다.
데이터는 AI 프로젝트 성과를 가로막는 주요 문제이다. 하지만 생성형 AI 기술이 고도화되면서 데이터 외에도 신경 써야 하는 요소는 더 늘고 있다.
ⓒ Getty Images Bank
지난 6월 뉴질랜드 슈퍼마켓 체인 운영사인 파크앤세이브(Pak’nSave)는 식재료 목록을 업로드하면 챗봇이 레시피를 제안하는 ‘세이비 밀봇(Savey Meal-Bot)’이라는 AI 챗봇을 출시했다. 뉴질랜드에서 버려지는 음식물 쓰레기 규모가 매년 1,500 뉴질랜드달러라는 점을 고려해 파크앤세이브는 세이비 밀봇을 비용을 절약해주는 도구라고 홍보하기도 했다.
18세 이상 사용자만 이용 가능하고, 레시피 내용은 사람이 따로 검토하지 않고, 식품 정보만 챗봇에 입력해야 한다는 경고문이 있었지만, 많은 사용자가 세이비 밀봇을 악용하기 시작했다. 특히 8월에는 다소 끔찍한 이유로 전 세계적으로 입소문이 났다. 세이비 밀봇이 어느 한 사용자에게 ‘놀라운 요리 모험’이란 이름으로 ‘표백제를 넣은 서프라이즈 밥’을 만들 것을 제안했기 때문이다. 여기서 끝이 아니다. 세이비 밀봇이 제안한 또 다른 음식 ‘아로마 워터 믹스’는 인체에 유해한 염소 성분를 배출하는 레시피였지만, ‘갈증을 해소하고 감각을 상쾌하게 해주는 완벽한 무알코올 음료’라고 소개했다. ‘신비한 고기 스튜’라는 레시피에는 ‘500g의 다진 인육’라는 재료를 제안했으며 ‘마법 같은 맛으로 당신을 놀라게 할 맛있고 푸짐하고 편안한 요리’라고 표현했다.
물론 이런 레시피를 보고 실제로 요리를 만든 고객 사례는 보고되지 않았다. 논란 끝에 현재 세이비 밀봇은 식용 가능한 식재료 정보만 입력 가능하도록 업데이트된 상태다. 그럼에도 불구하고 아직도 황당한 레시피 조합이 계속 만들어지고 있다.
이번엔 법률 업계를 살펴보자. 미국 레비도우 & 오버만(Levidow, Levidow & Oberman, P.C.) 소속 변호사는 챗GPT를 사용하여 변론문을 작성한 후 가짜 인용문과 인용으로 가득 찬 법률 의견을 제출하면서 로펌 신뢰도를 크게 하락시켰다.
판사는 6월 판결에서 해당 로펌 변호사에게 벌금 5,000달러를 부과했다. 두 변호사가 ‘변호사로서 책임감을 제대로 갖추지 못하고 존재하지 않는 사법 의견서를 제출하고 사법 명령이 그 존재에 의문을 제기한 후에도 가짜 의견서를 계속 고수했다’고 봤기 때문이다.
컨설팅 기업 pwc는 최근 많은 기업과 협력하여 생성형 AI 프로젝트의 시작을 돕고 있다. pwc는 생성형 AI에 대한 과장 광고 탓에 혹은 과도한 기대감 덕에 관련 프로젝트가 순조롭게 진행되지 않은 현상을 자주 목격하고 있다고 설명했다.
pwc의 파트너 겸 생성형 AI 시장 출시 전략 리더인 브렛 그린스타인(Bret Greenstein)은 “생성형 AI는 기존 AI나 머신러닝보다 훨씬 광범위한 기술이기 때문에 재해 발생 가능성도 크다”라고 설명했다. 기업에서 생성형 AI 도입 후 원하는 결과물을 얻지 못했다면 다음 4가지 실패 사유를 살펴보면 좋다.
실패 이유 1. 거버넌스 부족
생성형 AI 프로젝트가 원하는 대로 진행되지 않았다면 거버넌스나 관리 감독 영역에서 준비가 부족했던 것이 아닌지 알아봐야 한다. 앞서 이야기한 세이비 밀봇과 비슷한 형태로 많은 기업이 내부적으로 비슷한 실수를 저지르고 있다.
가령 그린스타인은 5개월 전에 상용 AI 도구의 프라이빗 클라우드 인스턴스를 사용하여 생성형 AI를 구현한 중견 금융 기업 A와 협력하면서 비슷한 문제를 발견한 적 있다. 일단 A 금융 기관은 기업 사용자가 자체 애플리케이션을 구축할 수 있도록 API를 개방했다. 관련 AI와 API로 구축된 것은 HR 챗봇이었다. 문제는 HR 챗봇이 노출하면 안 되는 복지 프로그램을 추천했던 것이다. HR 챗봇이 잘못된 옵션을 추천하면 직원은 1년 내내 복지 혜택을 놓칠 수 있었다. HR 챗봇을 이용한 직원은 복지 혜택의 진위여부를 확인하지 않았다. 심지어 화를 냈지만 해당 챗봇이 권위 있는 도구라고 믿으며 정확한 정보를 제공한다고 여겼다.
이런 사례를 감안했을 때 그린스타인은 기업이 API를 개방하고 외부에서 원하는 대로 무엇이든 만들도록 내버려 두는 것은 권장하지 않는다. 대신 거버넌스를 통해 사려 깊고 규율 있는 접근 방식을 취하라고 조언한다. 그는 “정확성을 평가하고, 편견을 관리하고, 환각을 처리하는 생성형 AI를 구축하는 체계적인 방법이 있으며, 올바른 것을 추천하는지 확인하기 위해 사람이 개입해야 한다”라고 덧붙였다.
A 금융 기업은 챗봇을 한 달 동안 운영했고, 피드백은 좋지 않았다. 다행히 챗봇 오류가 조기에 발견되어 직원에게 심각한 영향을 미치지 않았지만 경영진에 대한 신뢰가 흔들리기는 했다. 그렇다고 AI 프로젝트를 축소해야 할까? 기업이 생성형 AI를 과도하게 조절하고 적용 규모를 축소하면 경쟁업체에 뒤처지고, 기회를 놓치는 순간을 마주할 수 있다.
실제로 AI 인프라 연합(AI Infrastructure Alliance, AIIA)이 대기업 고위 임원 1,000여 명을 대상으로 7월에 발표한 설문조사에 따르면, 응답자 54%는 AI 또는 ML 애플리케이션 관리 실패로 인해 손실이 발생했다고 답했다. 또한 응답자 63%가 그로 인해 손실 규모가 5,000만 달러 이상이라고 답했다.
실패 이유 2. 급증하는 비용
생성형 AI 관련 인기 챗봇은 대부분 무료로 제공된다. 이런 무료 도구로 기업은 테스트를 진행하면 비즈니스 이점을 제공하는 애플리케이션을 저렴하고 쉽게 찾을 수 있다. 하지만 무료만 쓰다 보면 비용에 대한 문제를 놓칠 수 있다. 기업이 엄격하게 통제된 환경에서 파일럿 프로젝트를 진행해도 비용은 생각보다 적을 수 있다. 하지만 향후 공식 버전으로 프로젝트를 광범위하게 배포할 때가 되면 비용이 파일럿 때와는 달리 매우 높게 청구될 수 있다.
보안 교육 기업 산스 인스티튜트(SANS Institute)의 수석 커리큘럼 디렉터이자 총괄 교수 롭 리(Rob Lee)는 기업이 외부 공급업체를 이용할 때도 비슷한 문제를 겪을 수 있다고 설명했다. 아직 아무도 대규모로 생성형 AI를 배포한 경험이 없어 비용 예측이 어려운 것이다.
롭 리는 “기업은 아직 굳은살이 없다”라며 “이전에 생성형 AI 작업을 수행한 적이 있고 비용을 정확하게 예측할 수 있다면 관련 기업은 이미 엄청난 문의를 받고 있을 것”이라고 설명했다.
롭 리에 따르면, 현재 클라우드를 통해 AI를 배포하는 경우에도 모든 API 호출이 합산된 사용량을 예측하긴 어렵다. 그는 “이전 시스템을 기반으로 인간의 행동을 예측할 수는 없다”라며 “생성형 AI가 만들어낼 인간의 행동은 아무도 모르는 상태”라고 설명했다.
롭 리는 과도기적 상황에서 발생하는 추가 비용도 있다고 지적했다. 예를 들어 새 집을 사야 한다면 현재 살고 있는 집을 팔아야 하는데, 이전 집이 예상보다 빨리 팔리지 않는다면 두 채의 집을 동시에 구입해야 하는 상황에 처할 수 있다. IT도 마찬가지다. 롭 리는 “전환이 생각보다 오래 걸릴 때 그 비용을 기업이 감당할 수 있을지 생각해봐야 한다”라고 설명했다. 특히 생성형 AI는 워낙 새로운 기술이기 때문에 아무도 정확하게 예측할 수 없다.
롭 리는 “데이터 세트의 크기도 고민해야 한다”라며 “스토리지와 해당 스토리지에 대한 호출에 대한 비용이 발생한다. 일부 애플리케이션의 경우 전 세계에 여러 곳에 스토리지를 배포하고 백업도 해야 한다”라고 설명했다.
AIIA 설문조사에 따르면, 대기업이 생성형 AI를 도입하는 데 있어 두 번째로 큰 장애물은 비용이었다.
실패 이유 3. 비현실적인 기대치
생성형 AI에 대한 과대 광고로 인해 일부 비즈니스 리더는 AI를 ‘마법의 총알’처럼 여길 수 있다. 미국의 솔루션 통합업체인 인사이트(Insight)의 제품 혁신 부문 CTO인 아몰 아즈가온카르(Amol Ajgaonkar)는 “현재 업계에서는 AI의 현실적인 부분을 제대로 바라보고 있지 않다”라며 “그럼에도 일부 논의가 이미 기업의 의사 결정 과정에 스며들고 있다”라고 우려했다.
예를 들어, 지난 여름 미국 서부에 위치한 한 글로벌 전자제품 제조 및 유통업체 B는 고객을 위한 가격 정보 문서를 작성하기 위해 콘텐츠 생성 시스템을 구축하고자 했다. 아즈가온카르는 “해당 회사에는 수만 개의 계정을 관리하는 8,000명 이상의 대면 세일즈 담당자가가 있었다”라며 “제품 및 서비스 가격 책정은 새로운 프로젝트에 대한 업무 분장표를 작성하는 데 지속적으로 필요한 자료다. 관련 콘텐츠 생성을 생성형 AI로 쉽게 할 수 있을 것이라고 기대했다”라고 설명했다.
B 기업은 AI가 과거 데이터를 살펴보고 과거의 관련 사례를 찾은 다음 새로운 고객 요청에 적용할 수 있다고 생각했다. 아즈가온카르는 “그들은 생성형 AI가 필요한 결과를 내놓을 것이라고 기대했다. 과거 가격을 제시하면 AI가 이를 검토한 후 비슷한 물건의 가격이 얼마인지 알려줄 수 있지 않을까 했다”라고 설명했다.
막상 프로젝트를 시작해보니 생성형 AI가 실제로 어떻게 작동하는지 B사에 설명하는 것은 끊임없는 도전과제였다.
아즈가온카르는 “B사는 외부 자료를 읽고 와서 우리를 밀어붙였다”라며 “B사의 원하는 아이디어는 매우 간단한 것이었지만 실제로 바라는 비즈니스 가치는 엄청나게 컸다. AI 업계의 과대 광는 실제 결과물을 만드는데 매우 쉽다고 홍보한다. 하지만 현실은 그렇지 않다”라고 설명했다.
이러한 사고방식은 기업에 실망과 실패를 안겨줄 수 있으며, 심지어 AI의 이점에 대한 환멸을 불러일으킬 수도 있다.
아즈가온카르는 프로젝트를 작은 단계로 나누고 각 단계를 달성하기 위한 최선의 방법을 분석하는 것이 해결책이라고 조언했다. 실제로 프로젝트를 진행하다 보면 생성형 AI가 적합하지 않은 경우가 많다. 예를 들어, 과거 문서를 검색하여 관련 사례를 찾는 작업은 기존 접근 방식을 통해 더 효율적으로 수행할 수 있지만, 문서를 요약하는 작업은 생성형 AI가 잘 할 수 있는 작업이라는 것이 그의 설명이다.
한편 미래를 예측하려면 고급 분석 및 ML 모델을 적용해야 한다. 서로 분리된 많은 부분을 하나의 제안서로 모을 수 있다면 비즈니스 로직을 보다 수월하게 처리할 수 있다. 특히 어떤 서비스를 포함해야 구체적으로 명시해 놓으면 더욱 좋다. 단순한 수학적 계산을 위해 생성형 AI를 사용한다면 효과도 떨어지고 결과의 정확도도 낮을 것이다.
아즈가온카르는 “물론 계산을 위한 플러그인을 작성할 수 있다”라며 “하지만 기본적으로 우리 기업은 계산을 위해 생성형 AI에 의존하지 않는다”라고 설명했다.
그렇다면 최종 제안서를 어떻게 구성할 수 있을까? 일부 섹션은 법무팀에서 작성해야 하고 절대 변경되면 안 된다. 그는 “법무팀이 관여한 부분은 늘 기본적으로 반복해서 써야 하는 영역이다”라며 “요약본을 만들 때 생성형 AI을 활용할 수 있다”라고 설명했다.
아즈가온카르에 따르면, 결국 B사는 작업 명세서 작성에 필요한 시간을 크게 단축할 수 있는 솔루션을 얻을 수 있었다. 하지만 그 지점에 도달하기까지 약간의 교육이 필요했다. 교육이 없었다면 이 프로젝트는 실망감만 남기고 끝났을 것이다.
기업은 종종 생성형 AI 프롬프트를 작성할 때 성인 동료에게 설명하는 것처럼 지시 사항을 입력한다. 아즈가온카르는 이를 잘못된 생각이라고 지적했다. 그는 “10대 자녀에게 지시를 내리는 것처럼 생각해야 한다”라며 “때때로 반복해서 말해야 제대로 기억할 수 있다. AI는 지시를 들을 때도 따르지 않을 때도 있다. 마치 다른 언어를 사용하는 것과 같다. 무언가를 운영할 때 이러한 사소한 부분을 이해하는 것이 프로젝트 성공의 큰 부분을 차지한다”라고 밝혔다.
‘생각의 나무(Tree of Thought, ToT)’ 처럼 응답의 품질을 개선하는 방법도 있지만, 응답을 구체화하기 위해서는 여러 번의 프롬프트 입력이 필요하다.
아즈가온카르는 “이러한 방법은 가볍게 조사하는 과정에서는 괜찮다”라며 “하지만 실제로 프로덕션을 운영할 때는 비용을 생각해야 한다. 프롬프트에 입력하는 모든 질문은 비용이다. 각 플랫폼은 자체 기준에 따라 소비 토큰에 대해 비용을 청구한다”라고 밝혔다. 여기에 각 질문에 답변하는 데 걸리는 시간도 어느 정도 필요하다는 것도 잊지 말아야 한다.
아즈가온카르는 “모든 요청에 대해 사고의 생각의 나무 방식을 사용하고 설명을 요청해야 한다면 비용이 매우 많이 들 것이다”라며 “백지 수표가 주어진다면 같은 프롬프트를 다양한 방식으로 수천 번 실행하여 원하는 결과를 정확하게 얻을 수 있다. 하지만 그것이 가치를 창출하는 데 꼭 필요할까? 이것이 바로 솔루션을 구축할 때 균형을 잡아야 하는 이유다”라고 조언했다.
실패 이유 4. 데이터 문제 인사이트의 엔지니어인 카름 타글리엔티(Carm Taglienti)도 최근 비현실적인 기대치로 인해 AI 프로젝트가 좌초될 뻔한 프로젝트를 겪었다.
타글리엔티는 “AI 프로젝트의 실패는 99%가 기대치 때문”이라며 “기술의 실패가 아니라 사람들이 기술로 무엇을 할 수 있을지에 대한 기대치가 달라서 문제가 생긴다”라고 설명했다.
타글리엔티는 미국의 대형 칩 제조 회사 C사의 사례를 공유해 주었다. C사는 공급망 관리 문제를 해결하기 위해 AI를 사용하고자 했다. 문제는 C사가 AI가 할 수 없는 일을 해줄 것으로 기대했을 뿐만 아니라 첫 번째 시도에서 모든 일이 해결되기를 바랐다는 것이다. 하지만 AI 프로젝트에서는 한 단계에서 다른 단계로 넘어갈 때마다 첫 번째 접근 방식이 작동하지 않을 가능성이 높다. 그렇기 때문에 조정이 필요하다. 이러한 장벽을 만날 때마다 기업은 AI 프로젝트를 포기하는 것을 고려한다. 하지만 C사 사례는 조금 특이했다. 기대치 문제 뿐만 아니라 좋은 데이터가 부족하다는 기술적 문제도 있었다.
C사는 과거 특정 칩이나 부품을 구할 수 없을 때 대체품을 찾기 위해 노동 집약적인 수작업 프로세스를 겪었다. 타글리엔티는 “하지만 수작업은 비즈니스에 필요한 수준만큼 민첩하지 못했다”라고 설명했다. 이 프로세스 중 일부는 의사 결정 트리와 전문가 시스템으로 대체할 수 있었지만, 관련 시스템이 견고하진 않았다. 업계에 변화가 생길 때면 전체 의사 결정 트리를 업데이트해야 했다. 그러나 AI를 사용하려면 대량의 깨끗한 데이터가 필요했다. 하지만 학습 데이터로 사용할 수 있는 구성 요소를 철저하게 검색하는 경우는 드물었다.
매번 경쟁력 분석을 할 수는 없는 상황이었기에 C사는 선호 공급업체 목록과 상위 백업 목록을 고수하고 대규모 공급업체 검토는 거의 하지 않았다.
사용할 수 있는 데이터 중에서는 형식이 처리하기 어려운 경우도 있었다. 타글리엔티는 “제조업체라면 사양서를 작성한다”라며 “하지만 신속하게 수집할 수 있는 형식이 아니었다”라고 밝혔다.
제조업체의 시설 위치, 적시 납품에 대한 평판과 같은 미묘한 문제도 있었다. 타글리엔티는 “웹을 스크랩하고 상장 기업이라면 10-K를 살펴보는 등의 작업을 해야”라며 “단순히 작동하는 부품을 찾았다고 말하는 것보다 훨씬 더 많은 것이 있다”라고 설명했다.
타글리엔티에 따르면, 이런 종류의 분석은 생성형 AI가 등장하기 전에도 자동화가 가능했지만, 처음에 사람들이 생각하는 것보다 훨씬 더 복잡한 과정이었다. 드문 일이 아니었다. 사용 가능한 데이터의 부족은 오랫동안 AI 및 ML 프로젝트의 문제였다.
AIIA 설문조사에서도 데이터 문제는 생성형 AI를 배포하는 기업의 84%에게 중요한 과제였다. 실제로 PwC의 그린스타인은 최근 백오피스 처리를 자동화하려는 한 소비재 기업 D와 협력한 경험이 있다.
그린스타인은 “D사는 AI 서비스를 이미 구축해 놓았다”라며 “클라우드 인프라 기반도 갖춰져 있었다. 직원들도 준비비된 상태였다. 하지만 데이터에 접근하는 것이 어렵다는 부분을 D사는 예상하지 못했다”라고 설명했다.
심지어 어떤 데이터는 D 회사에 없는 API 라이선스가 필요했다. 라이선스를 얻기 위해 조달 프로세스를 거쳐야 했는데, 이 프로세스는 몇 달이 걸릴수도 있었다.
그린스타인은 “또 다른 시스템에서는 조직별로 매우 높은 수준의 액세스 제어가 이루어졌다”라며 “세 번째 시스템은 사용자 기반 제어였다. 생성형 AI의 경우 이 모든 것을 조정해야 했지만 빠르게 조정할 수 없었다”라고 밝혔다.
그린스타인은 장기적으로는 해당 기업은 필요한 모든 데이터를 확보할 수 있었지만 몇 달을 허비했을 것이라고 표현했다. 그는 “이 경우에는 다른 사용 사례로 전환했다”라며 “하지만 경영진은 시간과 열정을 잃었다. 생산성이 높아질 것이라는 기대에 부풀어 있던 직원들은 모두 좌절했고, 데이터 관련 사항을 고려하지 않은 IT 팀은 경영진에 대한 신뢰를 잃었다”라고 표현했다.
그린스타인은 기업이 잠재적인 AI 사용 사례의 우선순위를 첫 번째는 영향력, 두 번째는 위험, 세 번째는 데이터로 정해야 한다고 설명했다. 그는 “이 사용 사례를 수행하기 위한 데이터가 있는지, 데이터를 사용할 수 있는 권한이 있는지, 접근 가능한지, 유용할 만큼 깨끗한지를 물어야 한다”라며 “이런 질문에 답을 못한다면 시작하지 않아야 한다. 다른 사용 사례를 찾아야 한다”라고 설명했다.
ciokr@idg.co.kr
뤼튼 등 AI 스타트업 4곳 대표 견해는
“고비용이 문제”라는 점에 대체로 동의
“비용은 언제나 문제였고, 결국엔 해결”
챗GPT와 같은 생성형 인공지능(AI) 기술을 둘러싼 거품이 곧 꺼질 것이라는 관측이 나오고 있다. 거대언어모델(LLM) 기반 생성형 AI 서비스를 개발하고 운영하는 데 드는 비용이 막대하다는 게 주요 이유다. 국내 생성형 AI 스타트업 대표들은 비용 문제에는 공감하면서도 거품 논란에 대해서는 다양한 견해를 내놨다.
11일 글로벌 시장조사업체 CCS인사이트는 2024년 이후 테크 산업의 미래에 관한 연례 보고서에서 내년에 생성형 AI 기술 시장에 관한 우려를 짚었다. 비용과 규제가 대표적인 문제로 꼽혔다. 대규모 언어 모델(LLM)을 구동시키기 위해서는 그래픽처리장치(GPU) 서버 인프라 등이 필요하다. 대규모 컴퓨팅에 들어가는 비용이 막대하다는 의미다.
사진=게티이미지뱅크
◆‘비용 절감’, 생성 AI 업계 최대 화두
이스트소프트, 아티피셜소사이어티, 네오사피엔스의 대표는 세계일보와 통화에서 비용 문제가 업계의 가장 큰 장애물이라는 데 동의했다. 이스트소프트는 AI 서비스 전문기업이며, 아티피셜소사이어티는 생성형 AI를 활용한 에듀테크 스타트업, 네오사피엔스는 AI 성우 서비스를 하는 기업이다. 각 기업이 처한 상황에 따른 차이는 있으나 생성 AI 서비스의 수익화 문제는 스타트업뿐 아니라 오픈AI, 네이버 등도 고민하는 지점이다.
김기영 아티피셜소사이어티 대표는 서비스 이용자들에게 높은 비용을 받지 못하는데 원가는 높은 게 문제라고 지적했다. 누구나 챗GPT를 쓸 수 있는 시대에 챗GPT를 활용한 생성 인공지능(AI) 서비스를 비싸게 팔 수 없다는 뜻이다. 김 대표는 “챗GPT가 나만 쓸 수 있는 서비스면 관련해 개발한 서비스를 고가에 책정할 수 있겠지만, 현재는 그렇지 않기에 기업들이 수익화에 애를 먹고 있는 것”이라고 했다.
김 대표는 이 때문에 현재 AI 스타트업계가 서비스를 정교하게 하는 것보다 비용을 저렴하게 하는 데 집중하고 있다고 설명했다. 혹은 교육, 헬스케어 등 분야를 좁혀 생성 AI 기술을 고도화하는 방안으로 돌파구를 마련하고 있다는 분석이다.
정상원 이스트소프트 대표도 고비용 문제에 대해서는 인정했다. 다만 그는 생성형 AI의 유일한 단점이 비용이기 때문에 역설적으로 구글 등이 공격적으로 서비스에 적용하지 않고 있고 이 때문에 사람들의 관심이 지속하는 것이라고 진단했다. 정 대표는 “혁신의 역사를 돌아보면 초반에는 항상 엄청난 비용이 수반되기 마련”이라며 “그러나 인류는 항상 비용 문제만큼은 극복해 왔다”고 했다.
사진=로이터연합뉴스
◆“동일 성능 대비 효율화되고 있다”
AI 포털 서비스 기업 뤼튼테크놀로지스의 이세영 대표는 고비용이 문제라는 데 동의하지 않았다. 그는 오히려 비용 효율화가 가속하고 있다고 밝혔다. 예컨대 오픈AI의 챗GPT 모델이 발전하면서 이전 모델의 비용은 낮아진다는 의미다. 이 대표는 “동일 기술 대비 가격이 기하급수적으로 떨어지고 있다”고 강조했다.
GPU 역시 마찬가지다. 이 대표는 “성능이 획기적으로 개선되면 비용이 일부 늘 수 있지만, 대체로 빠르게 효율화와 경량화되고 있다”며 “스타트업이 초반에 감당하기 어려운 수준의 비용이 아니냐고 하는 지적이 있지만, 개발사와 협력해 비용 절감 모델도 개발하고 있다”고 했다. 이어 “뤼튼은 2막에서 본격적으로 태동하는 플랫폼 역할을 수행하고 있다”고 덧붙였다.
수익화 문제는 ‘킬러 앱’의 등장으로 넘을 수 있다고 봤다. 이 대표는 오픈AI의 최신 LLM인 GPT-4 출시(올해 3월)까지 1막이라면, 이후 2막이 열렸다고 정의했다. 그는 “2막은 많은 생성형 AI 앱들이 등장하는 시기가 될 것이고, 이미지, 비디오 등 세분화한 영역에서 킬러 앱이 등장해 시장을 이끌 것”이라고 전망했다.
김태수 네오사피엔스 대표도 생성형 AI 서비스 영역이 세분화해 비용 효율화에 성공한 곳과 그렇지 않은 곳이 나뉠 것이라고 봤다. AI 성우 서비스를 하는 네오사피엔스 경우 생성 AI 서비스 비용이 비싸다 한들 실제 성우를 고용하는 비용보다는 저렴하다는 설명이다. 그는 “유스케이스(Use Case)가 있는 데는 소비자들이 기꺼이 돈을 더 지불할 것이고, 관련 시장도 더 커질 것”이라고 내다봤다.
사진=AP연합뉴스
◆“기대 뛰어넘을 것” VS “더 놀랍진 않을 것”
생성형 AI의 진화에 대한 전망도 엇갈렸다. 기대를 넘어서는 서비스가 계속 등장할 것이라는 관측과 더 놀라운 것은 없을 것이라는 비관이 공존하고 있다. CCS인사이트가 제기한 ‘거품 논란’과 이어지는 문제다.
정상원 대표는 LLM 기반 생성형 AI 기술이 메타버스, 블록체인 등과는 다르다고 단언했다. 그는 “거품이라고 하더라도, 그냥 꺼질 거품인지 미래를 담보하는 거품인지는 다르다”며 “거품이 꺼지긴 이르다”고 했다.
아직 공개되지 않은 서비스에 대한 기대도 거품을 부정하는 요소다. 예컨대 오픈AI만 하더라도 지난달 말 한층 사람에 가까워진 챗GPT 기능을 조만간 선보인다고 밝혔다. 마이크로소프트(MS)는 워드·엑셀 같은 소프트웨어(SW)에 AI를 장착한 ‘MS365 코파일럿’을 다음 달 본격 서비스한다. 정 대표는 “챗GPT는 유니버설한 AI를 추구하고 있고, 사람들이 놀랄 거리는 아직 많이 남아 있을 것”이라며 “내년이 움츠러들 시점은 아니다”라고 강조했다.
반면 김기영 대표는 앞으로 나올 기술과 서비스가 기대에 부응하기 어려울 것이라고 예상했다. 그는 “세상의 모든 것이 생성형 AI로 바뀔 것이라고 초반에는 전망했지만, 그 정도는 아닐 것이라는 의미”라고 했다. 사람들의 기대치가 너무 높아졌다는 평가다. 이어 “챗GPT 경우 전혀 생각지 못한 것이어서 파급력이 컸지만, 앞으로 나올 것들은 그 정도의 영향력을 가져오진 않을 것”이라고 덧붙였다.
