*벤 에반스의 4/19 글을 번역했습니다.
작가 마틴 허니셋(Martin Honeysett)이 1982년 출간한 <마이크로포비아>의 한 장면입니다. 이 책에는 훌륭한 조크가 가득합니다. 그중 거의 대부분의 농담은 여전히 유효합니다. 왜냐하면 그 농담들의 포인트는 모두 한 곳-그 때 막 나온 컴퓨터-을 가리키기 때문입니다. “그래, 그래서 이건 도대체 어디에 쓰는 것일까?”
저는 아버지가 그때 사주신 ZX스펙트럼 컴퓨터에서 고전게임 <사보투어Saboteur>를 하긴 했습니다만, 그 외에 뭘 할 수 있었을까요?
그 몇 년 전, 댄 브릭클린(Dan Bricklin)이 한 가지 답을 찾은 바 있습니다. 그는 교수가 칠판에 스프레드시트를 분필로 그리는 것을 보며, 그걸 ‘소프트웨어’로 구현할 수 있다는 것을 깨닫습니다. 그는 VisiCalc를 개발합니다. 이는 최초로 등장한, 꽤 성공적인 디지털 스프레드시트였습니다.
그가 보여준 VisiCalc를 본 회계사들은 깜짝 놀랐습니다. 일주일 걸려 해야할 일을 반나절 만에 끝낼 수 있게 되었으니까요.
VisiCalc을 실행하기 위한 컴퓨터 애플II는 (그간 인플레이션을 감안하면) 거의 만이천 불 이상이었습니다만, 사람들은 이를 보자마자 수표를 꺼내 들었습니다. 컴퓨터로 구현된 스프레드시트는, 회계사들의 세상을 완전히 바꾸었습니다.
그런데 VisiCalc를 변호사나 그래픽 디자이너에게 보여주었다면, 그들은 대충 이렇게 반응했을 것입니다.
“아 예… 놀랍네요. 저희 회계 담당자에게 보여줘야겠어요. 뭐.. 저는 비록 이걸 쓰지 않겠지만요.”
변호사들에게는 워드 프로세서가 필요했습니다. 그래픽 디자이너들에게는 (예를들어) 포스트스크립트, 페이지메이커, 포토샵 같은게 필요했었죠. 그리고 이들이 등장하기까지는 시간이 꽤 걸렸습니다.
지난 18개월 동안 이 문제에 대해 많이 생각했습니다. 챗지피티, 제미나이, 클로드 등 새롭게 등장한 모든 챗봇들을 써봤습니다. 그리고 생각했죠.
“아, 놀랍네. 그런데 내가 쓸 일이.. 없는 것 같은데?”
2023년에 크게 화제가 되었던 (사실상 유일한) 유스 케이스는 코드를 쓰는 것이었습니다만, 저는 코드를 쓰지 않습니다. 사람들은 브레인스토밍, 체크리스트 작성, 아이디어 정리에 이를 쓰는 것 같던데, 다시 말합니다만 저는 그런 일을 하지 않습니다. 저에겐 필요하지 않아요.
사람들은 이를 사용해서 무언가의 초안을 만들고, 디자이너들은 미드저니를 사용해서 컨셉 기획을 하는 것 같습니다. 역시 이들은 저에게 해당하는 케이스는 아닙니다. 저는 아직 저에게 해당하는 유스 케이스를 찾지 못했습니다.
그런 사람이 저 뿐만은 아니라고 생각합니다. 일부 설문 조사 데이터가 이를 시사합니다. 많은 사람들이 이를 시도했습니다. 새로운 ‘애플 II’를 만이천 불이나 주고 사지 않아도 된다는 것은 대단히 멋진 일입니다만, 우리는 아직 모릅니다. 이를 얼마나 자주, 무엇을 위해 써야하는지 말이죠.
새로운 기술이 자신에게 맞지 않는다고 말하는 사람들이 있을 수 있습니다. 그다지 큰 문제가 아닙니다. 하지만 테크 업계의 많은 이들이 챗지피티나 LLM을 가리켜 ‘범용화의 단계’에 있다고 하는 것은 좀 문제입니다.
스프레드시트는 워드 프로세싱이나 그래픽 디자인에 한계가 있을 수 밖에 없습니다. 그걸 모두 할 수 있는 건 (스프레드시트가 아니라) PC죠.
하지만 이를 위해서는 누군가가 응용 프로그램을 먼저 개발해야합니다. 한 번에 하나의 유스 케이스를 말이죠. 하지만 이 모델들이 점점 좋아지고 멀티모달을 지원하게 되면서, 진정으로 변혁적인 주장- ‘특정 작업을 위한 소프트웨어의 개발 없이 하나의 모델이 모든 유스 케이스에 대응한다’-이 등장했습니다.
가령 이번 달 고객의 환불 건을 분석하거나 주차권에 이의를 제기한다거나 세금을 신고하고 싶다고 가정해봅시다. LLM에 물어보면 필요한 데이터를 알아내고, 적절한 웹사이트를 찾고, 올바른 질문을 하고, 주택 담보 대출의 명세서 이미지를 해석해서 양식을 작성하고 답을 만들어냅니다.
우리는 각각의 작업을 위한 별도 소프트웨어를 작성할 필요 없이 이 수작업들을 소프트웨어로 해낼 수 있습니다. 빌 게이츠가 이것이 GUI 이후 가장 큰 혁명이라고 말한 이유가 여기에 있다고 생각합니다. 이건 단순한 코딩 도우미 이상의 발견입니다.
하지만 여기 두 가지 문제를 생각해볼 필요가 있습니다.
얕은 문제 그리고 상대적으로 ‘약한’ 문제, 이 모델들이 아직 충분히 좋지는 않다라는 점입니다. 제가 위에서 이야기한 시나리오에서 아직 꽤 자주 막힐 것입니다. 그리고 이들은 어떤 결정론적 시스템이라기보다는 확률론적 시스템입니다. 그래서 이들은 (모든 케이스에서 잘 된다기보다는) 특정 유스 케이스에서만 특히 잘 돌아갑니다.
잘 돌아가는 것’처럼 보이는’ 건 곧잘 됩니다. 어떤 경우에는 그것이 우리가 원하는 것이기도 하겠지만, 잘 돌아가는 것처럼 보이는 것은 잘 돌아가는 것과는 완전히 다릅니다.
오류율과 ‘환각hallucinations’ 문제는 앞으로 나아지고 있고 점점 관리될 수 있을 것으로 보이긴 합니다만, 정확히 지금 어떤 상태라고 단언하기는 어렵습니다. 과학적으로 볼 때, 생성형 AI(그리고 AGI)를 둘러싼 논쟁 중 가장 첨예한 것 중 하나가 이것일 겁니다.
한편 수년 내로 이 모델이 어떻게 발전할 것이냐와 관계없이, 아직 구현되지 않는 수많은 케이스들이 있습니다. 아래 스크린샷이 저에게 필요한 유스 케이스입니다. 일견 될법도 한데 되지 않습니다. 적어도 아직은 말이죠.
자 여기서 더 깊고 어려운 문제가 등장합니다. 범용 기술 그 자체와는 관계없이, 우리가 언제 어떻게 써야할지 뾰족하게 유스 케이스를 생각해야만 한다는 것입니다. 우린 우리 업무를 들여다 봐야 합니다. 무엇을 하는데 시간을 많이 쓰는지 생각해보고, 그것이 이런 종류의 도구로 어떻게 자동화될 수 있을지를 생각해봐야합니다.
이 중 어떤 것은 익숙함과 상상력 사이 어딘가에 있습니다. 구글의 초기를 생각해볼까요. 우리가 무언가의 문제 해결을 위해 ‘구글링하다’라는 개념을 체화하기까지는 시간이 꽤 걸렸지 않나요.
한때는 인터넷을 검색하는 법에 대한 책들이 성행했습니다. 요즘 ‘프롬프트 엔지니어링’을 공부하는 것에 대한 책이나 강의 영상이 있는 것처럼 말이죠. 복잡한 논리식을 쿼리로 만들어 버티컬 데이터베이스에 명령어를 내리는 것이 아닌, ‘통합 검색의 형태로 검색창에 무엇이든 필요한 것을 입력할 수 있다’는 걸 알기까지는 시간이 걸렸습니다.
당시엔 검색도 역시 마찬가지였습니다. 새로 등장한 기술과 우리의 기존 패턴이 서로 적응해야 했죠. 우리는 원래 우리가 하고 있던 방식에 기술을 도입합니다. 가장 쉽고 명백한 유스 케이스가 되죠.
이렇게 ‘한번 적응하기 시작하면’, 시간이 지나며 우리는 새로운 기술에 우리가 일하는 방식을 맞춰갑니다.
그런데 여기서 또 하나 생각해야하는 건, 그 새로운 기술이 유용한지 아닌지를 알아내는 건 그 도구를 쓰게 될 사용자의 일이 아니라는 점입니다.
(컴퓨터 스프레드시트를 처음 개발한) 댄 브릭클린의 소프트웨어는 세 가지의 단계로 진화했습니다.
1) 스프레드시트가 소프트웨어로 구현될 수 있다는 것을 깨닫고 2) 그것을 설계하고 코딩해야했으며(그리고 그것이 오류 없이 돌아가게 해야했고) 3) 나가서 실제로 그 소프트웨어를 사용할 회계사들에게 그것이 왜 좋은지 설득해야 했습니다.
댄 브릭클린의 스프레드시트는 (운 좋게도) 등장하자마자 완벽한 프로덕트-마켓 핏을 찾아 제품이 확산되었지만, 그건 굉장히 드문 일입니다. 프로덕트-마켓 핏의 개념은 일반적으로 제품에 대한 아이디어와 유스 케이스와 고객 발굴에 대한 아이디어를 상호 반복적으로 주고받는 이터레이션을 돌린다는 뜻이죠.
그리고, 세일즈가 필요합니다. B2B 테크 스타트업에서 자꾸 발견되는 오류가 여기 있습니다. 고객이 스스로 필요한 것을 원하고 찾을 것이기 때문에 세일즈 인력 없이도 제품이 팔릴 것이라는 생각입니다. 극히 드문 예외를 제외한 현실은 그렇지 않습니다. 타겟 고객 중 정말 소수만이 새로운 도구에 관심을 갖습니다. 대부분의 경우, 우리가 직접 세일즈하지 않으면 안됩니다.
그렇다면 이 가설을 적용해봅시다. 댄 브릭클린의 세 단계 중 가운데- 제품을 개발하는 것-에는 생성형 AI가 큰 도움을 줄 수는 있을 겁니다. 하지만 무엇이 구현되어야 하는지를 생각하고 그것을 손에 잡히는 형태로 만들어 시장의 고객을 발굴하고 설득하는 것은 여전히 별도의 영역입니다.
사람들은 그들이 세무 업무를 하고 있다는 것은 알고 있지만 그것을 어떻게 정의하고 분리해서 자동화하는지 생각하지 못합니다. 누군가가 소프트웨어를 팔려고 접근하기 전까지는 말이죠.
스프레드시트는 PC의 대표적인 유스 케이스이기도 하면서 한때는 그 자체로 범용 프로토콜로 쓰이는 것이었습니다. 이메일이나 SQL처럼 말이죠. 그런데 이제는 이 모든 것들이 분리되었습니다.
오늘날 대부분의 큰 기업들은 수백개의 SaaS 소프트웨어를 사용합니다. 말하자면 무언가 특정 기능에 특화된 엑셀이나 오라클, 아웃룩 같은 것입니다. 이들은 모두 특정한 문제에 대한 정의, 그 문제를 해결하기 위한 워크플로우에 대한 아이디어가 핵심입니다. 물론 모두 ‘엑셀로도 할 수 있는’ 일들입니다. 하지만 SaaS를 쓰는 것이 훨씬 쉽습니다.
이들은 문제와 솔루션을 뾰족한 별도 소프트웨어로 ‘따로 발라내어’, 기업의 CIO에게 판매합니다. 이들은 문제, 즉 유스 케이스를 판매합니다.
한편으로는 이렇게도 생각해볼 수 있겠죠. 미드 <오피스>에 나오는 어수룩한 캐릭터 드와이트나 케빈에게 챗지피티로 송장을 발행하라고 하는 것보다 혹은 SAP 소프트웨어를 쓰게 하는 것보다, 그냥 엑셀을 쓰게 하는 것이 그냥 좋은 것 아닐까?
(역주: 아직 미완의 범용 솔루션인 챗지피티를 쓰게 하는 것은 신뢰도가 너무 낮고, 뾰족한 솔루션인 SAP은 너무 사용이 어려우니, 그 사이 적당한 엑셀이 두루두루 사용하기 편하다는 이야기)
따라서, 생성형 AI에는 인지적으로 두 가지 측면이 상충됩니다. 첫째로는 챗지피티나 클로드가 이야기하는 것처럼 이제 굉장히 복잡한 작업들을 범용으로 처리할 수 있는 만능 자율 에이전트에 매우 가까워졌다는 것입니다.
둘째로, 이 반대쪽에는 AI를 점점 더 뾰족하게 만들어 특정 문제에 집중하는, 스타트업 씬이 대폭발 할 수 있다는 것입니다. 오픈AI나 앤트로픽의 API를 별도의 UI로 감싸 제품으로 만들고, 별도의 파이프라인으로 기업 세일즈를 하는 것입니다. 마치 이전 세대의 SQL이 그랬던 것처럼요.
1982년 저희 집에서 아버지가 쓰던 건 일체형 전기 드릴 하나였습니다. 그런데 그 뒤로 공구 회사들은 ‘배터리로 돌아가는 전동 공구’의 폭을 점점 넓혔고, 어마어마한 전기 드릴 세트가 등장했습니다.
한때 모든 테크 스타트업은 (그들이 인지하든 않든) 내부에 SQL을 갖고 있었습니다. 하지만 그것은 제품이 아니었습니다. 이제 마찬가지로, 모든 스타트업은 그들 내부에 LLM을 가질 것입니다.
저는 종종 지난 머신 러닝의 흐름을 ‘자동화 인턴’에 비유하곤 합니다. 콜센터로 들어오는 모든 전화 내용을 듣고, 화난 고객이나 뭔가 의심스러운 고객을 골라내는 작업에는 전문가가 필요하지 않습니다. 단지 그냥 인간이기만 하면(심지어 개도 가능할지도요) 되죠. 이제 이 문제를 자동화할 수 있습니다.
하지만 이런 문제를 발견하고 소프트웨어를 개발하는 데에는 시간이 걸립니다. 머신 러닝이 어떤 임계를 돌파하기까지 10년이 넘게 걸렸습니다.
여전히 우리는 새로운 유스 케이스를 계속해서 찾아가는 중입니다. 우리는 어떤 문제를 정의하고, 그것이 특정 패턴을 갖고 있다는 것을 발견합니다. 그리고 밖으로 나가 그 문제를 갖고 있는 고객을 찾고, 시장을 개척합니다.
지금의 생성형 AI의 물결은 우리에게 또 다른 종류의 인턴을 제공하는 것이라 볼 수 있습니다. 이들은 무엇이 문제이고 어떤 패턴을 갖고 있는지 인식할 뿐 아니라, 그것에 대한 무언가를 만들 수 있습니다.
그런데 여전히, 우리는 문제가 무엇인지를 먼저 고민해야 하죠. AGI의 담론은 이것을 더 멀리까지 끌고갑니다. 그냥 인턴 이상입니다. 언젠가 우리에게 AGI가 주어진다면, 그것은 단순한 도구를 넘어서긴 하겠죠.
하지만 실제 인간 인턴이라고 치더라도, 제가 위에 붙인 스크린샷 속의 ‘일회성’ 요청 같은 일을 처리하는 것은 대단히 어렵습니다.
제가 연도별로(보통 10년 단위로) 직업 별로 (예를들어 엘리베이터를 단순히 조작하는 사람이 아닌) 직원 수에 대한 시계열 데이터를 찾고 있다는 것을 알고 있어야 합니다. 그리고 이것이 주 단위가 아니라 국가 단위라는 것 역시 알아야 하죠. 그럼 미국 센서스 웹사이트로 가서 이 데이터를 수집하고 있는지를 찾아봐야겠죠.
그런데 센서스 같은 웹사이트는 여러 세부 계층에서 다른 주기로, 서로 다른 기준으로 데이터를 수집합니다. 그리고 어느 시점에 ‘엘리베이터 조작자’ 수 수집을 중단했죠. 센서스 웹사이트에는 수백가지의 데이터 툴과 소스가 있습니다. 이 웹사이트에서 데이터를 찾는 것만으로도 하나의 전문직이 생길 수준이죠.
그렇다면 그 시점에 저는 인턴의 책상으로 갑니다. 그리고 센서스 대신 FRED에 들어가보라고 할 겁니다. 그리고 FRED에서도 시계열 데이터를 검색할 수 없다면 그냥 한번에 한 해씩 데이터를 입력해보라고 하겠죠. 혹은 구글 북스나 오래된 통계 자료의 스캔본을 찾아보라고 할 것입니다. 대학 도서관처럼 통계자료들이 거기에 있으니까요.
개발자가 손으로 하루면 처리할 수 있는 일을, 자동화하는데 일주일을 쓴다는 오래된 조크가 여기서 등장합니다. 아래의 이미지는 제가 ‘저를 자동화해서’ 만드는 차트입니다. 제가 하나하나 타이핑하는데 굉장히 오랜 시간 들이고 있기는 하지만요.
이런 작업을 범용 에이전트에서 하려면 그 모델이 얼마나 더 많은 맥락과 지식을 체화해야 할까요? 모델의 성능이 나아지면 가능할까요? 멀티모달이나 멀티 에이전트가 일반화되면 가능해질까요?
아니면 그냥 해당 분야를 잘 이해하는 – 데이터 추출이라든지, 주차권이라든지, 세금이라든지 – 사람이 사전에 정의한 바에 따라 관련한 지식들을 특정 제품이나 서비스에 때려넣고, 입력할 수 있는 선택지를 GUI로 한정해버리는 것이 더 나을까요?
잘 정의된 GUI는 사용자가 무엇을 해야할지 알려줄 뿐 아니라, 컴퓨터에게 사용자가 문제에 대해 어떻게 이해하고 생각하고 있는지를 전달합니다. 반면 범용 프롬프트에서는 사용자가 매번 그 모든 것들을 스스로 생각해야하거나, 학습된 데이터에 그것이 포함되어 있기를 바래야만 합니다.
자 그래서, GUI가 스스로 모든 것에 대응하는 범용일 수 있을까요? 아니면 문제를 바라보고 제품이나 서비스로 구현하는 이 시대의 ‘댄 브릭클린’들이 우리에게 필요할까요? 백엔드에서 알아서 LLM을 돌리며, 더 뾰족하게 수천개의 문제를 각각 정의하는.
우리는 조만간 차원이 다른 변화들을 마주하게 될 겁니다. 얼마나 많은 것들이 자동화될지 얼마나 많은 유스케이스가 LLM을 통해 개발될지에 지금은 예상조차 할 수 없을 것입니다. 하지만 그들은 앞으로도 한번에 하나씩, 정의되고 발견될 겁니다.
그 변화는 이전처럼 한번에 하나씩 자동화되는 새로운 유스 케이스일 수 있습니다. 그리고 이전과는 차원이 다른 자원과 기술이 등장한 덕분에 가능해진, 완전히 새로운 자동화 케이스일 수도 있습니다.
이 흐름은 LLM을 새로운 SQL로 만들지 않을까요. 새로운 HAL9000이 아니라 말이죠.
- 원문: 베네딕트 에반스 https://www.ben-evans.com/benedictevans/2024/4/19/looking-for-ai-use-cases
- 번역/편집: 뤽
이바닥늬우스 
감사합니다!
좋아요좋아요