[번역] AI 제품 구축의 고충들
Austin Z. Henley의 The pain points of building a copilot 을 번역한 글입니다.
수 많은 회사들이 LLM을 활용하여 작업을 도와주는 제품들을 출시하고 있습니다. Office Copilot은 Word와 Excel을, GitHub Copilot은 코드 작성을, Intuit Assist는 TurboTax에서 세금 신고를, Adobe Firefly는 이미지 생성 및 편집을, Dropbox AI는 문서에 대한 질문에 답변합니다.
제품에 통합되는 생성 AI가 급증하는 상황에서 소프트웨어 엔지니어가 이러한 제품을 구축하기 위해 어떤 프로세스를 따르고 있는지, 어떤 고충들이 있는지, 그리고 이러한 작업을 도와주는 도구에는 어떤 필요와 가능성들이 있는지 알아봅니다.
AI 제품 구축 프로세스
LLM의 비결정론적 특성으로 인해 전통적인 소프트웨어 개발 프로세스와는 다른 프로세스가 필요합니다. 저희는 인터뷰에 응한 개발자들이 따르는 탐색, 구현, 평가, 제품화라는 높은 수준의 프로세스를 모델링했습니다. 하지만 AI 제품 구축에서 이 프로세스는 선형적이지 않고 서로 얽히고 반복적입니다.
제품팀은 이제 LLM을 사용하여 해결할 수 있다고 생각되는 비즈니스 시나리오를 파악하고, 그것이 정말 가능한지를 다양한 기술(예: LLM, 임베딩, 벡터 데이터베이스)을 활용해서 직접 만들어 보면서 확인해야 하고(tinker), 충분히 좋은지 평가한 다음 실제 사용자에게 제공해야 합니다. 이러한 모든 작업에는 개발자들의 여러 고충이 있습니다.
AI 제품 구축의 고충들
개발자가 AI제품을 제작할 때 직면하는 문제점을 6가지 테마로 분류했습니다:
- 프롬프트 엔지니어링: 프롬프트 엔지니어링은 시간이 많이 걸리고 상당한 시행착오의 반복이 필요합니다. 또한 LLM의 출력을 파싱하는 작업이 필요하고 더 많은 컨텍스트와 더 적은 토큰을 사용하는 것 사이의 균형을 맞춰야 합니다. 또 다른 문제는 프롬프트, 프롬프트 템플릿, 무엇이 효과가 있었는지, 무엇이 효과가 없었는지, 왜 변경이 이루어졌는지 등을 관리하는 것입니다.
- 오케스트레이션: 여러 데이터 소스와 프롬프트를 오케스트레이션하는 것은 결코 간단하지 않습니다. 사용자의 의도를 파악하고(intent classification), 워크플로우를 여러가지의 프롬프트를 통해 진행시키는 시스템을 많이 시도하지만, 이러한 시스템은 실패할 가능성 또한 더 많아집니다. 계획 수립과 멀티턴 워크플로우 역시 많이 찾지만, 이 또한 제어하기가 어렵다고 알려져있습니다. 많은 개발자들이 말했듯이, 상황이 종종 “통제 불능”이 됩니다.
- 테스팅: 소프트웨어 개발에 있어 테스팅은 기본이지만, LLM을 다룰 때 테스팅은 매우 힘들고 불안정합니다. 어떤 개발자들은 단위 테스트를 여러 차례 실행함으로써 합의점을 찾습니다. 프롬프트나 모델이 결과에 미치는 영향을 측정할 수 있는 대규모 벤치마크를 구축하려고 시도하는 사람들도 있지만, 이는 전문 지식이 필요하며 비용이 많이 듭니다. 언제쯤 “충분히 좋은” 상태라고 할 수 있을까요?
- 모범 사례: 많은 개발자들이 LLM을 사용하는 방법에 대한 모범 사례를 찾고 있습니다. 트위터 해시태그를 팔로우하거나 arXiv 논문을 읽으며 배우려고 하지만, 이 방법은 확장성이 없고 어떤 자료가 좋은지 알기가 어렵습니다. 이 분야는 매우 빠르게 발전하고 있고, 개발자들로 하여금 “지금까지 배운 모든 것을 버리고 다시 생각해야 한다”고 요구하고 있습니다.
- 안전: 안전, 개인 정보 보호 및 규정 준수는 모두의 마음에 있는 우려사항입니다. AI가 피해를 입히지 않도록 방지하는 가드레일이 필요하지만, 사용자 데이터에 대한 개인 정보 보호 문제가 발생할 수 있으므로 사용 방식에 대한 원격 측정 데이터를 수집할 수도 없습니다. 안전 검토는 소프트웨어 엔지니어가 수행해야 하는 새롭고 지난한 작업입니다.
- 개발자 경험: 개발자 경험은 AI 제품 구축에 관여하는 모든 사람에게 고통스러운 지점입니다. Langchain과 같은 새로운 도구가 있긴 하지만, 프로토타입 이상으로 확장하기 어려운 경우가 많습니다. 예를 들어, 프롬프트는 소스 코드에서 문자열 변수에 불과한 경우가 많습니다. 개발자들은 수 많은 새로운 도구를 배우고 비교하고 서로 연결하느라 고객의 문제에 집중하기 어렵습니다.
어떤 도구들이 필요할까
전문 도구 제작자들과 진행한 포커스 그룹 세션에서, 개발자들이 AI 제품을 구축하는 데 도움이 될 수 있는 도구와 프로세스에 대한 여러 가능성들을 확인했습니다.
- 프롬프트 작성, 검증, 그리고 디버깅 지원이 필요합니다. 예를 들어, 프롬프트 린터는 빠른 피드백을 제공할 수 있습니다. 개발자들은 일반적인 작업을 위한 프롬프트 스니펫을 제공하는 라이브러리나 툴박스가 필요하다고 했습니다. 또한 프롬프트 변경의 효과를 추적하는 것도 큰 도움이 될 것입니다.
- 투명성과 통제력이 부족하면 사용자는 종종 혼란스러워합니다. 예를 들어 AI가 어떤 정보에 액세스할 수 있는지 또는 어떤 작업을 수행할 수 있는지 사용자에게 명확하지 않은 경우가 많습니다.
- AI를 측정할 수 있는 자동화된 방법이나 사용자 피드백을 수집할 수 있는 도구도 필요합니다. 안타깝게도 BLEU 같은 통계나 머신러닝 지표들을 따로 배우고 싶지 않다는 개발자들이 많았습니다.
- AI를 프로젝트에 통합하기 위한 one-stop shop은 여전히 숙제로 남아 있습니다. 개발자들은 빠르게 시작하고, Playground에서 MVP로 전환하고, 다양한 데이터 소스를 프롬프트에 연결한 다음, AI 구성 요소를 기존 코드베이스로 효율적으로 옮길 수 있는 방법을 찾고 있습니다.
AI 제품 분야는 여전히 야생의 서부 개척지입니다. 향후 몇 년 동안 새로운 프로세스나 도구를 통해 소프트웨어 엔지니어링이 어떻게 발전할지 지켜보는 것은 흥미로운 일이 될 것입니다.
더 자세한 내용은 “Building Your Own Product Copilot: Challenges, Opportunities, and Needs” 논문에서 읽을 수 있습니다.
