"진짜 문제는 파일럿 다음 단계" 생성형 AI 2일차 배포에 대처하기

모든 IT 프로젝트는 여러 단계를 거쳐 진행되며 생성형 AI도 다르지 않다. 초기 파일럿 프로젝트는 기술 또는 소프트웨어가 어떻게 작동하는지 테스트하면서 달성하고자 하는 결과 또는 업체나 개발자가 약속한 결과를 얻을 수 있는지를 판단하는 데 사용된다.

파일럿 단계가 완료되면 그 다음은 확장할 차례다. 새 프로젝트를 확장한다고 하면 단순히 더 많은 리소스를 투입하는 것이라고 생각할 수 있지만 사실 새로운 문제에 직면하게 된다. 생성형 AI의 경우 이러한 확장 문제의 양상이 매우 다를 수 있다.
 

ⓒ Getty Images Bank

 
IT 운영 분야에서는 이 문제를 흔히 "1일차", "2일차" 문제라고 한다. 1일차 문제는 구현 시에 나타나는 문제다. 생성형 AI에서 검색 증강 생성(RAG)에 사용하기 위해 데이터를 준비하는 작업부터 데이터 청킹과 인덱싱을 위한 접근 방식이 효과적인지 확인하는 것까지 포함된다. RAG에서는 사전 학습된 대규모 언어 모델(LLM)을 회사 자체 데이터와 함께 사용해서 생성형 AI 애플리케이션이 LLM의 초기 학습 내용에만 의존하는 것이 아니라 더 관련성 있고 구체적이며 시기적절한 응답을 제공할 수 있도록 한다.
 

데이터, 청킹, 인덱싱, 임베딩

1일차 관점에서 RAG 배포가 직면하는 문제는 데이터를 준비하는 방식과 관련된다. 예를 들어 데이터 준비의 초기 단계에서는 모든 비구조적 데이터와 구조적 데이터를 생성형 AI 시스템이 다룰 수 있는 하나의 형식으로 변환하는 작업이 포함된다. 이를 위해 모든 회사 데이터를 나타내고 텍스트 및 관련 메타데이터를 포함하는 문서 객체 집합을 만든다.
 
이후 텍스트 데이터는 인덱싱하고 이해할 수 있는 단위인 청크라는 더 작은 부분으로 분할된다. 여기서 청크의 크기에 따라 큰 차이가 발생한다. 예를 들어 문장 또는 단락 수준에서 구현할 수도 있고, 더 복잡한 자체 참조 청크로 구현해서 점점 더 작아지는 요소로 처리할 수도 있다. 어떤 접근 방식을 취하든 이러한 청크는 인덱싱되고 벡터 임베딩으로 변환되어 향후 검색을 위해 저장된다.
 
사용자가 질의를 보내면 이 질의는 가장 관련성 높은 데이터를 검색하는 데 사용되는 벡터로 변환되며, 이후 LLM으로 전달돼 응답에 반영된다. RAG는 AI 환각을 줄이고 응답을 개선하는 데 도움이 될 수 있지만 그 자체로는 충분하지 않다. 잘 맞지 않는 LLM을 선택하거나 데이터 청킹 또는 인덱싱에 대해 잘못된 접근 방식을 사용하는 등의 문제는 RAG 시스템의 작동과 그 응답의 품질에 영향을 미칠 수 있다. 예를 들어 너무 큰 청크를 사용하는 경우 LLM은 구체적인 요청과는 무관한 큰 텍스트 청크를 반환할 수 있다.
 

생성형 AI 애플리케이션 확장

RAG 시스템이 효과적으로 작동하도록 하고 나면 새로운 과제에 직면할 수 있다. 예를 들어 오픈AI의 챗GPT는 학습을 거쳐 사용자의 질문에 대응하는 서비스를 제공한다. 비즈니스 오브 앱(Business of Apps)에 따르면 챗GPT의 사용자 수는 매우 빠르게 증가해서 2개월 만에 1억 명들 돌파했다. 생성형 AI와 RAG를 도입하는 기업 역시 많은 양의 사용자 요청이 들어올 것으로 예상한다.
 
그러나 앱이 크게 성공하는 경우 어떤 일이 벌어지고, 이 인기가 생성형 AI 인프라에 얼만큼 부담이 될지에 대해 고려해본 적이 있는가? 생성형 AI를 통해 창출하고자 하는 매출과 함께 생성형 AI의 비용도 증가할 것인가, 아니면 이를 제품 외의 부가적인 매출로 보고 있는가? 생성형 AI가 끌어들이는 관심도에 따라 어느 지점에서 손익분기점에 이르고 최종적으로 원하는 수익을 달성하게 될지 예상하고 있는가?
 
많은 서비스에서 고품질의 응답을 제공하기 위해서는 초기 구축과 설계 단계만큼 대규모로 실행하기 위한 작업도 중요하다. 이것이 2일차 문제의 한 예다. 즉, 테스트 단계에서는 통했던 것이 수요를 충족할 만큼 확장되지 않는 상황이 발생할 수 있다. 예를 들어 RAG 환경이 동시에 유입되는 수천 또는 수백만 건의 사용자 요청을 어떻게 처리하고, 벡터 데이터베이스와 LLM 통합 구성요소는 이 데이터를 얼마나 빠르게 파싱해서 시스템이 사용자에게 응답을 반환할 수 있도록 하는가?
 
사용자는 새로운 무료 서비스에서는 느린 성능을 감수하지만, 돈을 내고 서비스를 이용하게 되면 느린 응답 시간을 용납하지 않는다. RAG 요청을 분석해 보면 트랜잭션 내의 지연에서 최대 40%가 임베딩 서비스 및 벡터 검색 서비스(RAG가 적절한 데이터를 매칭해서 사용자에게 돌려줌) 호출에서 발생할 수 있다. 따라서 예를 들어 이전의 비슷한 요청을 캐싱하는 등의 방법으로 이 왕복 이동을 최적화하면 사용자 경험을 크게 개선할 수 있다. 또한 각 왕복 이동은 특히 클라우드에서는 컴퓨팅 리소스 비용을 의미한다. 워크로드를 줄여서 기업이 사용한 만큼만 비용을 지불하도록 하면 이러한 비용을 절감하고 지출의 효율성도 높일 수 있다.
 
이와 함께 개발자와 IT 운영 담당자는 생성형 AI 워크로드를 실행하는 위치에 대해서도 생각해야 한다. 자체 LLM을 실행하는 데 따르는 부담을 피하고자 클라우드에서 시작하는 기업이 많겠지만 선택의 폭을 최대한 넓히고 업체 종속을 피하기 위해 자체적인 접근 방식을 선호하는 기업도 있을 것이다. 온프레미스, 클라우드 어디에서 실행하든 여러 위치에 걸쳐 실행하는 것이 좋다.
 
여러 개의 사이트를 사용하면 사이트 하나를 사용할 수 없게 되더라도 서비스 기능이 계속 유지되므로 서비스의 회복탄력성이 확보된다. 온프레미스 사이트에서 이는 필요할 때 언제든 이 데이터를 쿼리할 수 있도록 벡터 데이터 집합을 중심으로 페일오버 및 가용성 기술을 구현하는 것을 의미할 수 있다. 클라우드 환경에서는 여러 클라우드 지역을 사용해 벡터 데이터를 호스팅 및 복제할 수 있으므로 더 간단히 여러 위치에서 실행할 수 있다. 그 외에도 여러 개의 사이트를 사용하면 사용자와 가장 가까운 사이트에서 응답을 제공해 지연을 줄이고, 규정 준수를 위해 특정 위치 또는 지역에 데이터를 보관해야 하는 경우 지리적 데이터 위치도 더 쉽게 지원할 수 있다.
 

지속적인 운영 오버헤드

IT 운영 2일차에는 인프라 운영과 관련된 오버헤드와 문제를 살펴보고 병목 현상을 없애거나 이를 해결하기 위한 접근 방식을 최적화하는 작업이 이뤄진다. 생성형 AI 애플리케이션에는 방대한 데이터, 그리고 서로 통합된 구성요소와 서비스가 사용되므로 지속적으로 발생할 운영 오버헤드를 고려하는 것이 중요하다. 생성형 AI 서비스의 인기가 높아지면서 이러한 통합이 대규모로 이뤄지는 데 따르는 문제가 발생할 수 있다. 더 많은 기능을 추가하거나 더 많은 잠재적 AI 에이전트를 통합하는 경우 통합을 위해 엔터프라이즈급 지원이 필요하다.
 
직접 구성요소를 선택하고 통합하면 애플리케이션에 동종 최고(best of breed) 접근 방식을 취할 수 있다. 또한 마이크로서비스 접근 방식을 사용하면 시간이 지남에 따라 더 많은 통합이나 기능을 더 쉽게 지원할 수 있다. 그러나 DIY는 모든 통합과 관리에 대한 책임이 자신에게 있다는 의미이기도 하며 이 책임은 시간이 갈수록 누적될 수 있다. 그 대안은 다양한 툴 또는 통합에 대한 지원이 사전에 구현된 스택 기반 접근 방식이다. 사전 구축된 스택을 사용하면 팀이 인프라 구현이 아닌 애플리케이션 구축에 집중할 수 있고 운영도 간소화된다.
 
생성형 AI 애플리케이션을 가동한 다음에는 성능과 품질에 대한 사용자 기대치를 충족하도록 서비스를 운영하고 지원해야 한다. 환경 설정을 마치고 나면 RAG 환경에 해당하는 새로운 잠재적 문제는 물론 가용성, 비용과 같은 전통적인 IT 관리 문제도 발견하게 된다. 규모를 확장하면서 관심의 초점도 1일차 문제에서 2일차 과제로 전환해야 한다. 스택 기반 접근 방식이 도움이 되며 이를 통해 사용자에게 가능한 최선의 서비스를 제공하는 데 집중할 수 있다.
editor@itworld.co.kr