생성형 AI 제품 개발: 먼저 알아야 할 사항

소개

생성형 AI는 시도해 보는 것은 쉽지만, 사람들이 신뢰할 수 있는 제품으로 만드는 것은 훨씬 더 어렵습니다. 팀은 며칠 만에 언어 모델을 채팅 인터페이스에 연결할 수 있습니다. 하지만 그 인터페이스가 실제 고객 요청을 처리하고, 접근 권한을 준수하며, 회사 데이터를 활용하고, 잘못된 답변으로부터 복구하도록 만드는 것은 완전히 다른 문제입니다.

비즈니스 애플리케이션에 생성형 AI 도입을 고려하는 기업에게 있어 첫 번째 결정은 어떤 모델을 사용할지가 아닙니다. 그 문제가 과연 새로운 제품을 필요로 하는지 여부입니다. 기성 AI 도구로 대부분의 요구 사항을 충족할 수 있는 반면, 기존 소프트웨어가 필요한 워크플로를 수용할 수 없는 경우에는 맞춤형 구현이 더 합리적입니다. 후자를 검토 중인 기업은 SysGears의 생성형 AI 엔지니어와 상담하여 특정 사용 사례를 기반으로 구축된 제품의 기술적 요구 사항을 탐색할 수 있습니다.

생성형 AI 제품은 단순히 회사 브랜드가 붙은 인터페이스 뒤에 모델을 배치하는 것보다 훨씬 더 많은 요소를 포함합니다. 모델이 언어를 처리할 수는 있겠지만, 애플리케이션의 나머지 부분은 모델이 어떤 정보를 활용할 수 있는지, 다른 소프트웨어와 상호작용할 수 있는지, 그리고 답변이 빗나갔을 때 어떻게 처리될지를 결정합니다. 이러한 결정들은 모델 선택 자체만큼이나 제품의 유용성에 큰 영향을 미칩니다.

사내 비서가 오래된 정책 문서를 검색해 온다면 직원들을 오도할 수 있습니다. 고객 기록에 대한 접근 권한을 부여하면, 답변의 품질만큼이나 접근 권한 관리가 중요해집니다. 애플리케이션이 기록을 수정할 수 있다면, 설득력 있지만 잘못된 답변이 실제 피해를 초래할 수도 있습니다.

이러한 세부 사항들은 출시 후에 대충 보완할 수 있는 문제가 아닙니다. 이는 아키텍처, 필요한 엔지니어링 작업, 그리고 제품 운영 유지에 드는 비용을 포함한 AI 개발 비용에 영향을 미칩니다. 기업은 개발 착수에 앞서, 아직 범위를 좁히거나 기존 도구를 활용하기로 결정할 여지가 있을 때 이러한 사항들을 철저히 검토해야 합니다.

생성형 AI가 필요한 문제부터 시작하세요

설득력 있는 데모는 사실 꽤 평범한 비즈니스 문제를 가려버릴 수 있습니다. 예를 들어, 직원들이 내부 문서를 검색하는 데 너무 많은 시간을 소비한다면, 의미 기반 검색 시스템만으로도 충분할 수 있습니다. 반면, 긴 문서를 해석하고, 구체적인 세부 정보를 추출하며, 여러 출처의 정보를 활용해 답변 초안을 작성해야 한다면, 언어 모델이 더 실질적인 가치를 더할 수 있습니다.

이러한 구분은 초기 단계부터 중요합니다. 생성형 AI는 소프트웨어가 복잡하고 구조화되지 않은 자료를 이해하거나, 문맥에 따라 내용을 작성해야 할 때 그 가치를 발휘합니다. 하지만 고정된 규칙에 따라 수행되는 작업의 경우, 일반적인 스크립트를 실행하는 것이 비용 면에서 더 저렴하고 신뢰하기 쉬운 경우가 많습니다.

끊임없이 쏟아지는 제품 문의를 처리하는 유통업체를 예로 들어보자. 고객들은 같은 품목을 온갖 방식으로 설명하기 때문에, 생성형 AI 애플리케이션이 고객의 요청을 이해하고 관련 사양을 찾아내어 답변 초안을 작성할 수 있다. 재고 수준은 또 다른 문제다. 재고 수준은 실시간 재고 기록에서 가져와야 하며, 제시된 가격은 모델이 우연히 산출한 수치가 아니라 회사의 가격 책정 규칙을 따라야 한다.

이러한 업무 분담을 명확히 하는 것이 중요합니다. 모델은 언어 처리에 집중하게 하고, 예측 가능한 작업은 가능한 한 기존 소프트웨어에 맡겨야 합니다.

개발을 시작하기 전에, 실제로 무엇이 개선되어야 하는지 명확히 파악해야 합니다. 영업 직원이 견적서를 작성하는 데 걸리는 시간이 단축될 수도 있고, 고객이 지원 담당자를 기다리지 않고도 답변을 받을 수 있게 될 수도 있습니다. 어느 쪽이든, 현재 프로세스가 어떻게 작동하는지 기록해 두어야 합니다. 그렇지 않으면, 팀이 업무가 실제로 더 쉬워졌는지조차 모른 채 새로운 AI 인터페이스 도입을 자축하는 상황에 처할 수 있습니다.

자체 개발 대 구매: 실제로 얼마나 많은 통제권이 필요한가?

자체 개발 대 구매 결정은 종종 완전한 소유권과 편의성 사이의 선택으로 제시됩니다. 실제로는 그 중간에 여러 가지 옵션이 존재합니다.

글쓰기 지원, 회의 요약, 문서 분석, 또는 범용 연구와 같은 익숙한 기능이 필요한 경우, 기성 AI 도구는 합리적인 출발점입니다. 이러한 제품은 일반적으로 엔지니어링 작업이 덜 필요하며, 공급업체가 기반 인프라의 상당 부분을 관리합니다. 기업은 별도의 개발 프로젝트에 자금을 투입하지 않고도 직원들이 해당 기능을 유용하게 여기는지 테스트해 볼 수 있습니다.

문제는 범용 도구가 원래 설계된 용도가 아닌 특정 프로세스에 맞춰야 할 때 발생합니다. 예를 들어, 레거시 데이터베이스와 연동되지 않거나, 직원의 역할이 서로 다를 때 적절한 접근 권한을 적용하지 못할 수 있습니다. 또한 다른 비즈니스 시스템에서 해당 출력을 활용하기 전에 형식을 재조정해야 할 수도 있습니다. API와 구성 옵션을 통해 이러한 격차를 해소할 수는 있지만, 기존 워크플로우의 특수한 상황을 반드시 모두 해결할 수 있는 것은 아닙니다.

워크플로우 자체가 경쟁 우위인 경우, 기존 제품이 중요한 요구 사항을 충족하지 못하는 경우, 또는 애플리케이션이 독점 데이터 및 내부 시스템과 긴밀하게 통합되어야 하는 경우, 맞춤형 AI 제품의 필요성은 더욱 확고해집니다.

세 번째 옵션은 외부 공급자가 호스팅하는 모델을 기반으로 자체 애플리케이션을 구축하는 것입니다. 기업은 인터페이스와 그 이면의 로직을 개발하고, 시스템을 기존 소프트웨어에 연동하며, 결과를 테스트할 자체적인 방식을 마련합니다. 모델 자체는 API를 통해 접근되므로 파운데이션 모델을 처음부터 훈련시킬 필요가 없습니다. 이를 통해 기업은 자사의 워크플로우에 맞춰 제품을 설계할 여지를 얻게 되지만, 여전히 제공업체의 가격 정책, 모델 가용성, 서비스 제한 사항에 좌우됩니다.

이 마지막 차이점은 주목할 만합니다. 맞춤형 AI 애플리케이션을 개발하는 것과 새로운 AI 모델을 개발하는 것은 서로 다른 작업입니다. 파운데이션 모델을 훈련하려면 막대한 컴퓨팅 자원, 전문 지식, 적합한 데이터, 그리고 지속적인 실험이 필요합니다. 대부분의 기업은 이러한 부담을 감당할 필요가 없습니다. 회사 문서에서 정보를 검색하거나 신중하게 설계된 도구 접근 기능을 보완한 기존 모델만으로도 충분할 수 있습니다.

업무에 맞춰 아키텍처 선택하기

비즈니스 사례가 명확해지면, 다음 과제는 애플리케이션이 어떻게 작동할지 결정하는 것입니다. 모델은 수많은 구성 요소 중 하나일 뿐이며, 엔지니어링 시간이 가장 많이 소요되는 구성 요소가 아닐 수도 있습니다.

문서 보조 도구의 경우, 검색 강화 생성(RAG) 방식을 고려해 볼 가치가 종종 있습니다. 애플리케이션은 모델이 훈련 과정에서 학습한 내용에만 전적으로 의존하는 대신, 승인된 정보 출처에서 관련 구절을 검색하여 프롬프트에 포함시킵니다. 그런 다음 모델은 해당 자료를 활용하여 답변을 구성합니다.

검색 기능이 제대로 작동한다면, 내부 정책이나 최신 제품 정보에 기반한 답변이 더 관련성이 높을 수 있습니다. 하지만 이는 결코 확실한 일이 아닙니다. 검색 과정에서 구식 문서가 추출되거나, 중요한 주의 사항을 놓치거나, 모델이 잘못 해석할 수 있는 문장을 제공할 수도 있습니다.

검색 기능은 그 자체로 테스트가 필요합니다. 문서를 어떻게 조각으로 나누느냐에 따라 시스템이 찾아내는 결과에 영향을 미칠 수 있으며, 설령 검색 결과가 훌륭하더라도 사용자가 볼 수 없는 출처에서 나온 것이라면 무용지물입니다. 검색 과정에서 우연히 제한된 자료가 노출되었다는 이유로 직원의 접근 권한이 무시되어서는 안 되며, 해당 권한은 검색 과정 전반에 걸쳐 일관되게 적용되어야 합니다. 애플리케이션 자체가 권한 부여를 강제해야 하며, 모델이 이를 판단하도록 신뢰해서는 안 됩니다.

파인튜닝은 다른 목적을 가집니다. 적절한 훈련 예시가 있을 때 모델의 동작, 응답 형식, 또는 반복되는 작업 패턴 처리를 조정하는 데 도움이 될 수 있습니다. 그러나 주요 문제가 변화하는 사실에 대한 접근인 경우, 파인튜닝은 검색을 단순히 대체할 수 있는 수단이 아닙니다. 작년 제품 카탈로그로 파인튜닝된 모델은 오늘 아침에 무엇이 변경되었는지 자동으로 알 수 없습니다.

적어도 초기 단계에서는, 범위가 좁은 애플리케이션에 프롬프트와 모델 API만으로도 충분할 수 있습니다. 이는 입력의 예측 가능성과 시스템이 출력을 통해 수행해야 할 작업에 따라 달라집니다. 모든 응답을 방대한 내부 문서와 대조하여 확인해야 한다면 검색 기능이 필요할 수 있지만, 더 단순한 작업의 경우 이는 단지 부하만 가중시킬 수 있습니다.

첫 번째 버전은 간결하게 유지하고, 다듬어진 데모 입력 자료뿐만 아니라 실제 요청에 적용해 보세요. 모호한 질문이나 누락된 정보를 어떻게 처리하는지 확인해 보세요. 정보의 공백을 인정하기보다는 얼버무린다면, 더 많은 구성 요소를 추가하기 전에 이를 수정해야 합니다.