Tom Godden:
2023년과 2024년에는 생성형 AI에 대한 뜨거운 관심과 함께 약간의 과대 광고도 경험한 것 같습니다. AWS는 앞으로 언젠가 거의 모든 애플리케이션이 AI, 생성형 AI로 보강될 것이라 확신하고 있다고 생각합니다. 이러한 배경을 고려할 때, 우리는 리더들이 생성형 AI의 비즈니스 사례를 제시할 때 과장하지 않도록 어떻게 도울 수 있을까요? 고객이 올바른 가치를 찾을 수 있도록 말이죠. 이와 관련해 사람들에게 어떤 방향으로 나아가라고 조언하시겠습니까?
Matt Fitzpatrick:
이는 현재 8%만 제대로 하고 있는 이유와 어느 정도 관련이 있습니다. 성공의 불확실성은 비즈니스 사례 개발 프로세스의 까다로운 부분이라고 생각합니다. 제 말은, 비용 처리와 같은 프로세스를 실행하기 위해 새로운 소프트웨어 시스템을 설치하려는 경우를 예로 들어 보겠습니다. 이 경우 비즈니스 사례를 구축하면 어떤 워크플로를 수행할지 정확히 알 수 있어 신뢰도가 매우 높아집니다. 따라서 비즈니스 사례를 매우 간단하게 구축할 수 있습니다. 하지만 여러분의 비즈니스 사례가 조직 내에서 활용할 수 있는 12가지 다른 요소에 좌우된다고 가정해 보세요.
Tom Godden:
N을 구하는 문제군요.
Matt Fitzpatrick:
그 중 다섯 가지는 효과가 있고 일곱 가지는 효과가 없을 수 있는 상황이죠. 사실 비즈니스 사례 개발 방식을 좀 더 벤처 캐피탈처럼 바꿔야 한다고 생각합니다. 그렇다고 해서 10개 중 1개만 효과가 있다는 의미는 아니라고 생각합니다. 제 생각에는 10, 12, 14가지 다른 것들을 시도하면서 실험하는 데 익숙해져야 한다는 뜻이라고 생각합니다. 시간이 지나면 첫 번째 배치에서 효과적인 다섯 가지를 얻게 될 것입니다. 그리고 다음 배치에서는 효과가 있는 10가지를 얻게 됩니다. 또한 각각을 개발하는 데 막대한 금액을 투자하지 않아도 됩니다.
지식 관리를 예로 들어 보겠습니다. 서비스 통화에 사용하는 동일한 데이터를 예로 들면, 그것을 고객 센터에서도 사용할 수 있고, 통화가 어떻게 진행되었는지에 대한 문서를 생성하는 데에도 사용할 수 있을 것입니다. 따라서 결국에는 효과적인 하나의 사용 사례에 연결된 5, 6, 7개의 사용 사례가 생길 것입니다.
Tom Godden:
마음에 듭니다. 그리고 저는 항상 사람들에게 문서 요약 사용 사례가 작동하게 만든 후에는 HR, 재무 등 다른 분야에서도 활용해 보라고 조언합니다. 모델을 약간 수정하고 훈련을 거쳐야 하겠지만, 80% 또는 90%는 완성된 셈입니다.
Matt Fitzpatrick:
이것이 비즈니스 사례에서 어려운 부분이었습니다. 2년이 걸리고 하나의 단일 비즈니스 사례로 끝나는 그런 패러다임을 따르는 것이 아닙니다. 실제로는 ‘이 사용 사례에는 네 가지 다른 데이터 구성 요소가 필요하다’는 패러다임에 더 가깝습니다. 이러한 데이터 구성 요소는 모두 모듈식이므로, 다른 네 가지 사용 사례에도 사용할 수 있습니다. 제게 있어서 비즈니스 사례 개발은 '충분한 기능을 구축하고 반복적으로 유용하게 사용할 수 있을 것이기 때문에 착수할 만한 타당성이 있고, 따라서 가치가 있는 것인가?’라는 질문의 답을 구하는 것입니다. 그리고 장기적으로, 3년, 5년 단위로 보면 투자 금액을 배수로 늘리게 될 것입니다. 첫 번째에서 바로 비즈니스 사례가 확보되지 않을 수도 있습니다.
Tom Godden:
그럼 Matt, 제가 CIO라고 가정해 보겠습니다. 실제로 CIO 출신이라 그렇게 상상하는 게 어려운 일은 아니죠. 그런 상황에서 저는 아주 독특하고 나만을 위한 맞춤형 제품을 원하지만, 동시에 비용도 저렴해야 한다고 생각할 겁니다. 항상 그런 패러다임이 아니겠어요? McKinsey의 경우에는 어떤가요? 사람들에게 구축 vs. 구매 문제에 대해 어떻게 조언하시나요? 구축하면 맞춤화할 수 있습니다. 그렇지만 비용은 훨씬 더 많이 듭니다. 구매하면 이론적으로 저렴하지만 맞춤화할 수 있는 여지가 적습니다. CIO로서 저는 이 두 가지 옵션 사이에서 결정을 못 내리고 있습니다. 저를 위해 어떤 조언을 해주시겠어요?
Matt Fitzpatrick:
아시다시피, 사실 기술 조직이 생각하는 '구축 vs. 구매'의 정의는 상당히 왜곡되어 있다고 생각합니다. 좀 더 자세히 설명하자면, 10년 전에는 '구축 vs. 구매'의 정의가 이랬습니다. 구매는 기성 제품을 하나 가져와서 바로 가동하고, 정해진 비용을 지불하는 것을 의미했습니다. 반면 구축이란, 구축을 하려면 말 그대로 메인프레임 컴퓨터를 설치해야 했습니다. 코드를 대부분 처음부터 새로 작성해야 하죠. 15년 전 이야기일지도 모르겠네요.
Tom Godden:
하나부터 열까지 다 구축하는 거군요.
Matt Fitzpatrick:
정말로 처음부터 새로 다 만들어야 했고 엄청난 투자를 해야 했습니다.
Tom Godden:
반가운 말씀이네요. AWS의 전략이기도 하니까요. 획일적인 작업의 부담을 더는 데 도움이 되죠.
Matt Fitzpatrick:
특정 기술 공급업체가 아닌 좀 더넓은 관점에서 보면 오늘날 ‘구축’이란 클라우드 인스턴스를 가동한다는 의미입니다. 다양한 모듈식 구성 요소를 사용합니다. GitHub 코드, 정보가 있는 코드 리포지토리를 가져옵니다. 6~7개의 다양한 기성 구성 요소를 사용합니다. 그 덕분에 10년 전보다 훨씬 적은 비용으로 정말 유용하고 조직에 적합하도록 맞춤화된 솔루션을 구축할 수 있습니다.
3년 전에 저는 한 대형 자산 운용사와 일했는데, 이 회사는 신용 관리 시스템을 재구축해야 했고, 기성 제품을 구매하는 방안을 두고 고민하고 있었습니다. 이 회사가 고민하던 문제는 ‘기성 신용 플랫폼을 구매할 것인가, 아니면 직접 구축할 것인가?’였습니다. 10년 전만 해도 기술 회사도 아닌 이런 회사가 신용 관리 플랫폼을 직접 구축하겠다는 생각은 완전히 말도 안 되는 것이었습니다.
Tom Godden:
경고음이 울리는 거군요.
Matt Fitzpatrick:
하지만 검토해본 결과 결국 깨닫게 된 것은, 구매할 경우 상용 신용 관리 플랫폼에 맞게 데이터 스키마를 맞춤화하려면 상당한 투자가 필요하다는 것이었습니다. 그리고 스크린이 필요한데... 이 회사가 당시에 교체하려고 했던 자체 제작 시스템이 있었는데, 원하는 형태로 기성 시스템을 맞춤화하려면 엄청난 투자가 필요했습니다. 데이터를 그 시스템에 매핑하는 데에도 막대한 투자가 필요했습니다. 그리고 모든 작업이 끝났을 때...
Tom Godden:
그래서 최종 결론은 무엇이었나요?
Matt Fitzpatrick:
이 회사는 기본적으로 이 기성 시스템을 바탕으로 새로운 시스템을 구축하고 있었습니다. 또 다른 옵션은 현대적인 데이터 도구와 클라우드 인프라 등 모든 최신 도구를 사용하여 시스템을 구축하는 것이었습니다. 그런데 놀랍게도 사용하는 비용보다 더 비싸지 않다는 결론에 도달했습니다.
이런 사례가 갈수록 늘어나고 있습니다. 저는 생성형 AI가 정말 가속화될 것이라고 생각합니다. 제가 생성형 AI 에코시스템에서 마음에 들었던 것 중 하나가 바로 다양한 애플리케이션을 상호 운용할 수 있다는 점이기 때문입니다. 누구도 '우리 것만 사용하세요'라고 하기 위해 생성형 AI를 만들지 않습니다 모두가 최고 수준의 기술에 참여할 수 있다고 말하고 있습니다. 따라서 새로운 기술이 나오면 누구나 참여할 수 있습니다. 여기서 문제는 만약 오늘 새로운 신용 관리 애플리케이션을 만들고 무언가를 구매한 후에 새로운 흥미로운 생성형 AI 도구가 등장한다면, 그 도구를 사용할 수 없다는 것입니다. 실제로 10년 된 상용 크레딧 플랫폼을 사용하면 상호 운영이 가능한 현대적인 영구 스택을 구축하고 모든 최신 구성 요소를 사용할 때보다 더 많은 기술 부채를 떠안게 됩니다.
요즘 우리가 흔히 말하는 ‘구축'에 익숙해진 기업의 수는 5년 전보다 훨씬 많아졌습니다. 그리고 클라우드와 인프라에 대한 투자 덕분에 구축 속도도 훨씬 빨라졌습니다.
Tom Godden:
Matt, 당신은 많은 변화를 이루었고, 많은 프로젝트를 이끌었고, 많은 것을 보았습니다. McKinsey는 이를 해낼 수 있도록 조직을 재배치하는 것에 대해 많이 이야기합니다. 생성형 AI로 성공적으로 전환하는 데 도움이 될 문화적 측면에 접근하는 방식에 있어서, 성공적인 모델은 어떤 것이라고 생각하시나요?
Matt Fitzpatrick:
이와 관련해 몇 가지 중요한 요소들이 있습니다. 하나는 어떤 사용 사례가 실제로 중요하고 변화를 가져올 수 있을지 명확하게 파악해야 한다는 것입니다. 다시 한 번 말씀드리지만, 10년 전의 관점에서 기술 조직이 비즈니스 조직과 대화하지 않았다면 분명히 실패했을 겁니다. 비즈니스 조직의 비전이 무엇인지 명확히 알아야 합니다. 시험해 볼 10가지 사용 사례는 무엇이며, 기술 팀과 비즈니스 팀이 어떻게 협력하여 테스트하고 학습할지 정해야 합니다. 그 전체 과정은 새로운 근육을 키우는 것과 같습니다. 요즘 가장 많은 관심을 받고 있는 기술은 디지털에 대한 이해도가 있으면서도 비즈니스도 이해하는, 소위 ‘번역가 능력’이라고 할 수 있습니다. 예를 들어 저는 많은 부동산 분야의 고객과 함께 일했는데, 기술과 부동산 산업을 모두 이해하는 사람은 둘 중 하나만 이해하는 사람보다 훨씬 더 가치가 있습니다.
기술 조직과 비즈니스 팀 간의 연결이 필요하다고 생각합니다. 그래야 구축 중인 솔루션이 효과가 있고 비즈니스 사용자가 원하는 비전을 실현할 수 있음을 보장할 수 있습니다. 그래서 번역가 능력이 정말 중요하다고 생각합니다.
또한 기술 재교육 또는 최소한 엔지니어링 조직의 기술 역량을 많이 고려해야 한다고 생각합니다. 예를 들어 Python이나 Rust와 같은 최신 기술을 사용하는 방법을 모르는 엔지니어링 조직이 있다면, 현대적 생성형 AI 도구를 많이 활용하기가 상대적으로 어려울 것입니다. 그렇다면 결국 재교육, 재기술 습득 같은 것들이 필요하거나 새로운 인재를 채용해야 할 수도 있습니다. 전통적인 엔지니어링 조직을 보강해야 할 필요성도 있을 테고요.