생성형 AI를 실제 제품에 적용할 때의 도전과제들
스왈로우즈 인사이트
지난 2년가량 띵스플로우에서 CTO 겸 AI 콘텐츠 랩 본부장을 맡아 조직에 AI 기반의 문화를 안착시키고, 챗봇 및 인터랙티브 소설에 생성형 AI(텍스트 및 멀티미디어)를 접목하기 위한 R&D를 수행했습니다. 이 글에서는 이러한 경험을 바탕으로 생성형 AI 기반(특히 ChatGPT와 같은 대규모 언어모델)의 R&D를 수행하고 이를 제품에 탑재하기 위한 과정에서 경험한 어려움들과 제가 가진 생각들을 공유해보고자 합니다.
AI 애플리케이션을 실제 IT 서비스에 적용할 때 LLM(Large Language Model)과 관련하여 여러 가지 도전 측면들이 존재합니다. 이러한 어려움들은 기술의 빠른 발전과 복잡성, 내부 구성원들의 이해도의 한계, 그리고 실제 적용 과정에서 발생하는 다양한 요인들로 인해 발생합니다.
실제 조직에서는 구성원들의 반발감, 윤리적 문제 등 고려할 부분들이 추가적으로 존재하지만 이 글에서는 이러한 부분은 다루지 않고, 실제 제품에 생성형 AI(이후 AI로 부름)를 적용하는 과정의 기술적인 어려움에 대해서 다룹니다.
전문지식의 필요 및 기능의 불명확성
AI 기술, 특히 LLM의 능력과 한계를 정확히 파악하는 것은 매우 어려운 과제입니다. 이러한 어려움은 AI에 대한 일반적인 이해 부족과 부정확한 정보의 확산으로 인해 더욱 심화됩니다. 많은 사람들이 AI, 특히 LLM에 대해 과대평가하거나 과소평가하는 경향이 있습니다. 누군가는 마법처럼 모든 것이 다 될 것처럼 생각하기도 하고, 누군가는 자신이 하는 영역의 업무를 절대 대체할 수 없다는 확신을 가지기도 합니다. 오늘의 신봉자가 내일의 부정자가 되기도 하죠.
미디어나 마케팅에서 AI의 능력을 과장되게 표현하는 경우가 매우 많습니다. 이는 콘텐츠 생산자들이 자신의 콘텐츠를 판매하기 위해 의도했던 의도하지 않던 Fear Of Missing Out (FOMO)를 조장하는 경우가 많기 때문입니다. 마치 오늘 이걸 하지 않으면 내일 당장 도태될 것처럼 이야기합니다. 반은 맞고 반을 틀리다고 봅니다. 한 번의 혁신적 변화로 바뀌는 게 아니라, 수많은 점진적 변화들이 매우 빠른 속도로 발생할 것입니다.
이는 기술 Hype Cycle을 생각나게 합니다. 실체는 그 둘 사이 어딘가에 존재합니다.
LLM의 작동 원리와 능력을 정확히 이해하려면 상당한 전문 지식이 필요합니다. 꽤 많은 사람들이 ChatGPT, Claude, Perplexity와 같은 웹사이트에서 할 수 있는 일이 AI 기술의 전부인 것처럼 생각하는 경우가 있습니다. 이는 사실이 아니며, 이러한 비전문가에 의한 평가는 종종 AI 기술에 대한 과소평가로 이어지는 트리거 역할을 하는 것 같습니다. 실제로 2024년 말 현재 생성형 AI의 주요 트렌드는 멀티에이전트 협업(Multi-agent collaboration)이며, 이는 실제 코드로 개발해야 하는 영역이기에 비전문가가 하기엔 어려운 작업입니다. (사실 멀티에이전트 협업은 23년 초부터 이미 관련 종사자들에게 상당히 핫했다는 것은 비밀 아닌 비밀입니다.)
이러한 요인들로 인해, AI 애플리케이션을 실제 IT 서비스에 적용할 때 어디까지 가능하고 어디까지 불가능한지 명확히 구분하기가 매우 어려워집니다. 1) 애초에 AI가 필요한 일인지, 2) “생성형” AI 가 필요한 일인지, 3) 현재의 기술로 가능한 일인지, 4) 곧 가능해질 일인지, 5) 자체 데이터를 통해 학습하여 개선이 가능한 일인지 등, 다양한 층위의 질문들이 존재합니다.
이는 프로젝트 계획 수립, 기대치 관리, 그리고 실제 구현 과정에서 큰 도전이 됩니다. 따라서 AI 프로젝트를 성공적으로 수행하기 위해서는 정확한 정보에 기반한 현실적인 평가와 지속적인 팔로업이 필연적입니다.
급격한 기술 발전
AI 기술의 발전 속도가 매우 빠르기 때문에, 오늘의 정답이 내일 오답이 될 수 있습니다. 최신 트렌드를 따라가면서도 실제 비즈니스에 적용할 수 있는 균형점을 찾는 것이 점점 더 어려워지고 있습니다. 현업자들 또한 트렌드를 좇다 보면 금세 피로감을 호소하곤 합니다. 과연 이렇게 최신 기술들을 팔로우 업하는 것이 무슨 의미가 있는가 고민하기도 합니다.
새로운 기술이 나오면, 이를 학습하고 실무에 반영하는 사이클이 제대로 동작하지 않습니다. 오늘 새로운 기술이 나와도 내일 나오는 기술이 훨씬 더 뛰어날 수 있기 때문입니다. 늘 불안합니다. 더 많이 알수록 더 불안해집니다.
이럴 때일수록 일희일비하지 않고 거시 맥락하에서 기술을 바라볼 수 있는 능력이 매우 필요합니다. 많은 소음에서 제대로 된 신호를 찾아내야 하며, 이는 누적된 경험과 상당한 통찰력을 필요로 합니다. 개인과 조직 모두 각자 가진 자원의 한계가 존재함을 인식하고 어떤 것을 받아들이고 어떤 것을 버릴지 선택해야 합니다.
이러한 급격한 변화의 시기에는 리더의 제대로 된 방향성 설정이 가장 중요한 시기일 수밖에 없습니다.
운용 비용 문제
AI 모델, 특히 대규모 LLM의 운용 비용은 여전히 상당히 높은 편입니다. 일반적인 컴퓨팅 비용과 달리 AI 운용에는 더 많은 자원이 필요하며, 이는 프로젝트의 경제성에 큰 영향을 미칠 수 있습니다. 다행히 기술 발전과 함께 비용은 급격하게 낮아지고 있습니다. 그리고 앞으로도 계속 비용이 낮아질 것으로 배팅해도 괜찮다고 생각합니다.
그럼에도 불구하고, 지금까지 운용 비용은 여전히 중요한 고려 사항입니다. 최신 IT 서비스들의 경우 컴퓨팅이나 스토리지 비용이 급격히 낮아졌기에 서비스 인프라 운용비용이 사업적 결정에 핵심적 영향을 주는 일이 많이 적어졌습니다만, AI에 필요한 비용은 그렇지 않습니다. 따라서 ROI를 초기부터 신중히 평가해야 하며, 비즈니스 모델 확립이 매우 중요합니다.
문제의 크기와 복잡성
풀고자 하는 문제의 크기와 복잡도가 증가할수록 LLM 어플리케이션의 고려사항이 증가합니다. 이는 선형적이지 않습니다. 단일 프롬프트로 해결할 수 없는 문제들이 많이 존재하며 이들은 R&D, 엔지니어링을 필연적으로 수반합니다.
LLM 콘텍스트의 크기가 커지면 이 문제는 해결되는 것이 아닌가 질문하시는 분들도 계시지만, 실제로는 제공하는 프롬프트가 길어지면 원하는 결과를 얻지 못할 확률이 높아집니다. 통상 이를 “Lost in the middle” 문제라고 부릅니다. 관련하여 좀 더 자세한 내용을 알고 싶으신 분을 위해 링크도 함께 제공해 봅니다. (집중력 잃은 AI, 정신 차리게 만드는 법)
결국 원하는 결과를 얻어내기 위해서는 다음과 같은 과정이 필요하게 됩니다. (모든 문제를 이렇게 풀어야 한다는 뜻은 아니며, 굉장히 단순화한 스텝입니다.)
1. 풀고자 하는 문제를 성격에 맞게 분할합니다.
2. 각각의 분할된 문제를 성격에 따라 최적화를 수행합니다.
3. 분할한 문제의 결과를 병합하여 최종 결과물을 산출합니다.
그리고 위와 같은 문제를 좀 더 일반적인 방법으로 해결하고자 하는 방식이 앞서 잠깐 소개했던 Multi-agent collaboration 방식이라고 볼 수 있겠습니다.
개인적 경험으로는 이 중 2번의 경우 “고전적 방식의 개발”을 활용하는 게 큰 도움이 되는 경우가 많았습니다. 예를 들어, mermaid 방식으로 분기도를 작성하고자 할 때, 순환(loop)이 없도록 요청하였는데 당시 claude 3.5 sonnet 모델은 꽤 많은 경우 순환을 만들어냈습니다. 이를 해결하기 위해 claude 가 생성한 mermaid 그래프를 실제 코드로 검증하였고, 검증 결과를 claude에게 다시 제공하여 수정을 요청했습니다. 이러한 단계를 통해 안정적으로 문제가 없는 mermaid 그래프를 만들어낼 수 있었습니다.
LLM 모델 자체가 발전하면서 이런 문제들은 점차 모델 레벨에서 해결될 것으로 예상됩니다. 하지만 결국 풀고자 하는 문제의 요구사항의 범위와 복잡도도 함께 커질 것이기에 이러한 과정은 당분간 필요할 것으로 생각합니다.
개발과 적용의 간극
AI 연구와 실제 제품 개발 사이에는 상당한 간극이 존재합니다. AI 엔지니어와 제품 개발 엔지니어의 전문 영역이 다르기 때문에, AI R&D 결과를 실제 제품에 통합하는 과정이 순조롭지 않을 수 있습니다.
가장 간단하게는 사용하는 언어, 도구들이 다를 수 있습니다. AI 엔지니어들은 대부분 파이썬 언어를 사용하는 반면, 제품에서는 파이썬의 사용 비율이 그렇게 높지는 않습니다. Jupyter 노트북으로 개발된 코드를 제품에 사용하려면 어떻게 해야 할까요?
작성한 AI 서버는 Scalable 할까요? 사용자가 늘어나도 문제없이 동작할 수 있을까요?
AI 서버가 RAG 활용을 위해 vector database를 활용한다면 제품에서 사용하는 database와 어떻게 통합해야 할까요? (RAG이란 Retrieval Augmented Generation의 약어로 아주 거칠게 설명하면, AI 가 데이터베이스를 검색할 수 있도록 하는 기술입니다)
하나하나 풀어나가면 될 문제들이긴 하지만, AI 기술을 실제 IT 제품에 탑재하는 것은 예상한 것보다 좀 더 복잡할 수 있습니다. 개인적인 경험상 AI 엔지니어가 제품 개발 영역을 이해하는 것보다는 제품 개발 엔지니어가 키를 잡고 AI 엔지니어와 협업하여 제품을 구성하는 것이 좀 더 효과적이라고 생각합니다.
마무리하며
함께 공유하고 논의해보고 싶은 생각들이 정말 많지만 글로 정리하자니 생각처럼 쉽지 않네요. 막상 긴 시간 들여 글을 작성하고 보니 뾰족한 해결책이 없이 문제점만 나열한 건 아닌가 하는 걱정도 듭니다. 그럼에도 불구하고 누군가에겐 이 글이 도움이 될 수 있다면 쏟은 시간이 아깝지 않을 것 같습니다.
진정한 변화의 시기입니다. 밀려오는 파도 앞에서, 조급해하지 않으면서 제 자신의 스탠스를 확립하는데 최소 1년은 걸린 것 같습니다. 모두들 새로운 시기에 각자의 기회를 발견하실 수 있기를 소망하며 글을 마칩니다.
필자 : 오진웅
스왈로우즈 부스터스
오진웅님은 카이스트에서 컴퓨터 사이언스를 전공하고 다양한 스타트업을 거쳐 띵스플루우 CTO를 역임했고 ODCODE를 창업했습니다. 생성형 AI에 상당한 애정을 가지고 있는 기업가이자, 풀스택 개발자로서 기술과 비즈니스의 균형을 추구합니다. 기술과 창의성의 경계를 탐험하며, AI의 무한한 가능성을 활용해 사용자들에게 새로운 경험을 선사하고 의미 있는 가치를 창출하는 것이 목표입니다.
