생성형 AI 서비스: 게이트웨이로 쉽게 시작하기
생성형 AI는 현재 인공지능 분야에서 가장 주목받는 기술 트렌드 중 하나입니다. 특히 ChatGPT, DALL-E, Midjourney 등의 텍스트 및 이미지 생성 도구들이 대중에게 공개되면서, 전 세계적으로 기업들의 생성형 AI 도입 사례가 급증하고 있습니다.
우아한형제들의 AI플랫폼팀은 생성형 AI 기술을 효율적으로 활용할 수 있는 환경을 제공하여 서비스 개발의 생산성과 품질을 향상시키고자 합니다. 그 첫 단계로 AI API Gateway(이하, 게이트웨이)를 개발하게 되었습니다.
본 글에서는 게이트웨이의 개발 경험과 주요 기능, 그리고 향후 계획에 대해 소개하고자 합니다.
개발 배경
생성형 AI 도구들의 확산은 크게 두 가지 측면에서 큰 변화를 가져오고 있습니다.
- 생성형 AI 도구들은 AI/ML 기술적 전문 지식이 없는 일반 사용자들도 손쉽게 AI 기술을 활용할 수 있게 해줍니다. 복잡한 프로그래밍이나 데이터 과학 지식 없이도, 간단한 프롬프트 입력만으로 고품질의 텍스트나 이미지를 생성할 수 있게 되었습니다. 이는 수학이나 통계에 대한 깊은 지식 없이도 자동화 도구를 활용하여 데이터를 분석하고, 새로운 인사이트를 도출하여 결과를 개선할 수 있게 되는 AI 기술의 민주화를 촉진하고 다양한 분야에서 활용 사례를 만들어내고 있습니다.
- 기업들은 자체 모델 개발 또는 사전 훈련된 딥러닝 모델을 새로운 데이터셋이나 특정 작업에 맞게 추가로 학습시키는 파인튜닝 방법에 많은 시간과 비용을 투자하지 않고도, 생성형 AI 도구들을 활용하여 빠르게 AI 기반 서비스를 개발하고 출시할 수 있게 되었습니다. 이는 기업의 AI 도입 속도를 가속화하고, 새로운 비즈니스 모델과 서비스 혁신을 촉진하고 있습니다.
우아한형제들 역시 세계적 흐름에 발맞추어 생성형 AI 기술을 도입하고 있습니다. 회사 전반에 걸쳐 다양한 업무와 서비스 개발 영역에서 생성형 AI 도구들을 활용하고 있으며, 이를 사용하는 구성원과 적용 서비스 수는 꾸준히 증가하고 있습니다. 특히 주목할 만한 점은 신규 서비스 기획 단계에서부터 생성형 AI 활용을 적극적으로 검토하고 있다는 점입니다.
대표적인 사례는 저품질 메뉴 이미지의 개선기능으로, 과도하게 확대 촬영된 메뉴 이미지에 대해 이미지 생성 AI를 활용하여 배경 영역을 확장(아웃페인팅)하는 기술을 적용하고 있습니다.
생성형 AI 기술의 활용이 늘어나는 상황에서 AI플랫폼은 생성형 AI 기술을 더욱 효율적으로 개발할 수 있는 환경을 제공하여 구성원들의 업무 생산성과 서비스 품질을 향상하는 방안을 모색하고자 했습니다. 생성형 AI의 효율적 활용을 위해 가장 필요한 요소를 파악하고자, 구성원들과의 인터뷰를 우선적으로 실시하였습니다.
생성형 AI를 잘 활용하려면 무엇이 필요한가?
생성형 AI를 적극 활용하고 있는 구성원들과의 인터뷰를 통해 어떠한 어려움이 있고 AI플랫폼에 우선 제공해야 할 기능이 무엇이 있는지 알아보았습니다.
인터뷰를 통해 도출된 주제들은 아래와 같습니다.
- API Gateway : 생성형 AI 시스템의 핵심 인프라 구성 요소로, 반복적인 개발 작업을 최소화하고 시스템의 안정성과 보안성을 향상시키는 플랫폼
- Experimental Feedback : 생성형 AI의 생성 결과 품질을 지속적으로 개선하기 위해 사용자 피드백을 수집, 반영하기 위한 기능
- Hybrid Search : Lexical search와 Semantic Search를 결합한 고급 검색 시스템
- LLM Serving : 사내 자체 대규모 언어 모델(LLM) 또는 공개된 LLM 모델을 효율적으로 운영, 관리, 제공
- Prompt Experiment : 효과적인 프롬프트 개발과 최적화를 위한 실험 환경을 제공
- RAG Pipeline : 외부 지식을 활용하여 생성형 AI의 응답 품질을 향상시키는 파이프라인의 표준화 제공
우아한형제들의 AI플랫폼 개발자, 데이터 과학자, 그리고 프로젝트 매니저분들의 의견을 종합하여, AI플랫폼팀은 위의 주제들 중 API Gateway 개발을 최우선으로 하기로 결정하였습니다. 우아한형제들에서는 AWS Bedrock, Azure OpenAI, GCP Imagen 등 다양한 생성형 AI 서비스들을 적절하게 활용하고 있는 점 역시 게이트웨이 개발의 우선순위 선정에 중요한 고려 사항이 되었습니다.
또한 기존 생성형 AI를 활용한 서비스들의 프롬프트와 호출 로직들이 파편화되어 있었으며, RAG Pipeline, Prompt Experiment, Experiment Feedback의 지원에 앞서 자격증명과 프롬프트를 한곳에 모아 관리할 수 있는 Hub 역할이 우선 필요하다고 판단했습니다.
다양한 외부 AI API 서비스를 통합 관리하는 솔루션인 Kong, Dify.ai 등이 이미 존재하지만, 아래와 같은 배경으로 직접 개발, 운영하게 되었습니다.
- 맞춤형 요구사항 충족: 특정 AI 워크로드에 대한 요구사항 발생 시 빠른 지원 필요
- 유연성 확보 : 빠르게 변하는 AI 기술에 맞춰 게이트웨이를 신속하게 수정하고 확장할 수 있는 유연성 확보 필요
- 비용 절감 : 상용 솔루션 대비 장기적으로 비용 절감
- 보안 강화 : AI 모델과 데이터에 대한 특화된 보안 요구사항 충족
- 통합 용이성 : 기존 인프라 및 워크플로와의 원활한 통합
게이트웨이를 개발하기에 앞서 인터뷰 세부 내용과 관련 레퍼런스들을 참고하여 문제점과 개선이 필요한 부분을 개발 기능 단위로 세분화하였습니다.
풀어야 할 문제들
자격증명
API 호출 시 자격증명과 같이 필요한 값들을 관리하고, 생성형 AI API에 제공할 필요가 있습니다. 아래와 같이 생성형 AI 서비스별로 기존 인프라들과 연동하기 위해 필요한 값과 활용 방법이 다릅니다.
- Azure OpenAI :
AZURE_OPENAI_ENDPOINT,AUZRE_OPENAI_API_KEY - GCP VertexAI :
credential json - AWS Bedrock :
IAM Role ARN(+ Security Token Service(STS)) - Naver Cloud Platform :
invoke_url,secret_key
AI플랫폼에선 이러한 값들을 AWS Secrets Manager를 통해 관리/제공하고 있었습니다.
하지만 Secrets Manager로 관리하면 아래와 같은 문제점이 있습니다.
- 신규 서비스 개발 시, AI플랫폼 개발자가 Secrets Manager에 신규 보안 암호 생성 요청 필요
- 수정 필요시, Secrets Manger에서 수정 후 즉각적인 External Secret 갱신을 위한 Deployment 배포 필요
- 서비스 단위로 보안 암호를 생성하게 되면서 관리가 필요한 보안 암호수가 지속적으로 증가
- 자격증명에 대한 히스토리 관리 및 추적이 어려우며, 이에 대한 정책과 시스템의 필요
이를 해결하기 위해 생성형 AI API 호출에 필요한 자격증명들을 서비스 개발자가 게이트웨이에서 손쉽게 추가/수정/삭제하고, 생성형 AI API별 연동은 게이트웨이 내부에서 처리하도록 했습니다. 이를 통해 개발 프로세스 가속화, 운영 효율성 증대와 자격증명의 관리 정책 수립 및 시스템화를 목표로 했습니다.
중복 개발
생성형 AI를 활용한 개발은 간단히 외부 API를 호출하는 것으로부터 시작합니다.
import os
from openai import AzureOpenAI
client = AzureOpenAI(
azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT"),
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
api_version="2024-02-01"
)
response = client.chat.completions.create(
model="gpt-35-turbo",
messages=[...]
)하지만 실서비스에 적용하려면 아래와 같은 고민과 개발이 필요합니다.
- Personal Identifiable Information (PII)
이름, 전화번호 등 민감 정보는 외부로 유출되면 안 되며, 민감 정보를 토대로 결과가 생성되면 안 됩니다. 민감 정보가 주입될 수 있는 서비스라면 민감 정보를 포함한 요청은 거부하거나 민감 정보를 마스킹 처리한 후 외부 생성형 API에 전달해야 합니다. - Logging
생성형 AI의 입출력 데이터는 서비스 디버깅, 결과 품질 향상 루프, 캐싱 등 다양하게 활용될 수 있습니다. 입출력 데이터를 활용하려면 서비스별로 로깅을 위한 저장소를 생성/관리해야 하며, 표준 입출력을 정의하고 적재 로직을 구현해야 합니다. 또한, 생성형 AI는 입력 프롬프트뿐만 아니라, 설정값(예:temperature)에 따라 생성 결과가 달라지므로, 파라미터들도 로깅할 필요가 있습니다. - Limits (Quota / Call Rate)
다수의 생성형 AI API에선 단일 리소스에 요청량을 무한히 제공하고 있지 않습니다. API 호출은 Quota Limit 또는 Call Rate Limit이 발생할 수 있으며, 다른 예외 상황과의 구분을 위해 서비스 개발 시 예외 처리와 폴백(fallback) 로직을 구현해야 합니다. 또한 대용량 트래픽이 예상되는 서비스의 경우, 생성형 AI API 리소스를 여러개 생성하고 호출 시점에 어떤 리소스를 요청할지에 대한 로직을 구현해야 합니다.
위의 기능들을 게이트웨이에서 제공함으로써, 서비스 개발자들이 핵심 비즈니스 로직에 더 집중할 수 있도록 지원하고, 전반적인 시스템의 안정성, 보안성, 그리고 효율성을 크게 향상시킬 수 있을 것으로 기대하였습니다. 또한, 중앙화된 관리를 통해 일관된 정책 적용과 빠른 문제 해결이 가능할 것으로 기대했습니다.
비효율적인 배포
게이트웨이가 개발되기 전엔 생성형 AI API 호출을 위한 자격증명, 프롬프트, 속성값(모델 배포명, API버전 등), 상세 파라미터들을 코드 또는 리소스 파일로 관리 했습니다.
import os
from openai import AzureOpenAI
with open("/resources/template.txt", "r") as f:
template = f.read()
query = {...}
client = AzureOpenAI(
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
api_version="2024-07-01-preview",
azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT")
)
completion = client.completions.create(
model="gpt-35-turbo-instruct",
prompt=template.format(**query),
temperature=0
)설정(api_key, api_version, model) 또는 파라미터 값(prompt, temperature)을 수정하거나, 호출하는 생성 AI 서비스가 변경(Azure OpenAI -> AWS Bedrock)되면 코드 수정 및 배포 작업이 필요합니다. 하지만 외부 API 호출에 필요한 값들은 시시각각 변할 수 있으며, 프롬프트와 같은 리소스 파일의 수정을 위해 재배포가 이루어지는 것은 비효율적입니다. 게이트웨이에선 해당 문제를 해결하기 위해 동적 라우팅과 내부 리소스(예: 템플릿) 관리기능을 구현했습니다. 이를 통해 데이터 과학자 또는 생성형 AI의 비즈니스 로직을 담당하는 개발자는 서버 코드 수정 없이 즉각적인 수정이 가능합니다. 관리 기능의 이점을 정리하면 아래와 같습니다.
- 유연성 향상 : 외부 API 호출에 필요한 값들을 실시간으로 수정할 수 있으며, 시시각각 변하는 요구 사항에 신속히 대응
- 운영 효율성 : 코드 변경 및 재배포 없이 구성을 변경할 수 있어 운영 부담 감소
- 중앙 관리 : 모든 구성을 게이트웨이에서 관리하여 일관성 유지
AI API Gateway
다음 그림은 게이트웨이의 핵심 기능들과 호출 흐름을 나타낸 것입니다.
게이트웨이는 다양한 사용 사례와 개발 시나리오를 수용하기 위해 HTTP 호출과 AI플랫폼 인프라와의 연동을 도와주는 ML SDK(참고: 배민 앱에도 AI 서비스가? AI 서비스와 MLOps 도입기)를 통한 호출, 두 방식을 지원합니다.
- HTTP 호출 : 간단한 프록시나 파이프라인 호출에 적합하며, 타 서빙 서버에 쉽게 연동하는 경우
- ML SDK : 복잡한 전후 처리가 필요하거나 LangChain과 같은 별도 프레임워크와의 결합이 필요한 경우
서비스 개발자는 필요한 정보만 게이트웨이에 등록하면 적절한 엔드포인트를 제공받음으로써, 각 구성원의 전문 영역에 집중 할 수 있도록 했습니다. 이를 통해 더 높은 품질의 AI 서비스를 빠르고 효율적으로 개발할 수 있기를 기대했습니다.
지원 서비스
현재 게이트웨이에서 지원하고 있는 서비스는 아래와 같습니다.
- AWS Bedrock
- Azure OpenAI
- GCP VertexAI ImageGeneration
- Naver Cloud Platform (실험적. 현재 OCR 서비스 제공)
지원 기능
게이트웨이에선 프로젝트, 자격증명, 템플릿 관리 기능과 서비스 제공을 위해 엔드포인트를 제공하며, 프록시 및 파이프라인 기능도 포함하고 있습니다. 또한, 널리 활용되고 있는 LangChain과의 호환성도 지원하고 있습니다.
프로젝트
게이트웨이에 등록되어 있는 다양한 리소스와 설정에 대한 수정/삭제 권한의 제한과 무분별한 호출을 방지하기 위해, 각 요청에 대해 api_key의 유효성을 검증할 수 있도록 “프로젝트” 개념을 제공하고 있습니다. 사용자는 먼저 프로젝트 생성을 요청하고, 발급받은 api_key를 활용하여 게이트웨이를 사용하게 됩니다. 베타/운영 환경은 독립적으로 프로젝트를 관리하며, api_key 역시 별도로 발급됩니다.
자격증명 관리
생성형 AI API 호출에 필요한 자격증명 값들을 AWS Secrets Manager가 아닌 게이트웨이에 등록하고 관리할 수 있습니다. 게이트웨이에서 자격증명 관리 기능을 제공함으로써 사용자는 Secrets Manager를 직접 다룰 필요가 없으며, 필요시 게이트웨이를 통해 수정/삭제하여 서비스에 즉각 반영할 수 있습니다. 또한 게이트웨이 내부적으로 API 호출 시 필요한 AWS Bedrock, Azure OpenAI, GCP VertexAI, NCP 연동을 제공하여 사용자는 멀티 클라우드 환경에 대한 고민을 줄일 수 있습니다.
(참고: AWS Bedrock의 경우, STS를 활용해 호출을 제어하고 있습니다)
템플릿 관리
프롬프트는 생성형 AI 결과 품질의 주요한 요소입니다. 자체 학습한 초기 모델이 최적(optimal) 모델이 아닌 것처럼 프롬프트 역시 지속적인 개선과 실험이 필요합니다. 프롬프트의 유연한 변경과 체계적인 관리를 위해 게이트웨이에선 템플릿 관리 기능을 제공하며, 게이트웨이에 등록된 템플릿은 구성원들에게 공개하여 프롬프트 엔지니어링의 노하우를 공유를 할 수 있는 허브 역할도 하고자 했습니다.
템플릿과 프롬프트
템플릿은 동적인 입력을 받으며, 입력(쿼리)을 토대로 최종 프롬프트를 생성합니다.
템플릿 생성은 plain text와 message blocks 포맷을 모두 지원하여 간단한 템플릿과 복잡한 템플릿의 등록과 사용을 모두 지원하고 있습니다
// message block 형식의 템플릿
// 정적 프롬프트 템플릿
POST /v1/templates
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"name": "example-message-blocks",
"template": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "2024년 올림픽은 어디서 개최했어?"
},
{
"role": "assistant",
"content": "파리입니다."
},
{
"role": "user",
"content": "가장 많은 메달을 딴 국가는 어디야?"
}
]
}// plain text 형식의 템플릿 (message block형식으로 변환되어 저장)
// 동적 프롬프트 템플릿
POST /v1/templates
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"name": "example-plain-text",
"template": "{style} 스타일로 {user_input}에 대해 설명해줘"
}위와 같이 정적 템플릿뿐만 아니라 요청 시 전달 받은 값(query)을 통해 동적으로 프롬프트를 생성할 수도 있습니다. 동적 템플릿에 주입되는 값은 {key} 형태로 지정하며, 템플릿을 통한 요청 시 {key}에 해당하는 값을 전달하여 최종 프롬프트를 생성하게 됩니다.
// 템플릿 테스트 호출
POST /v1/templates/example-plain-text
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"style": "웃긴",
"user_input": "파이썬"
}// 템플릿 테스트 응답
{
"template": {
"name": "example-plain-text",
"template": [
{
"role": "user",
"content": "{style} 스타일로 {user_input}에 대해 설명해줘"
}
],
"version": "1"
},
"queries": {
"style": "웃긴",
"user_input": "파이썬"
},
"prompt": [
{
"role": "user",
"content": "웃긴 스타일로 파이썬에 대해 설명해줘"
}
]
}신규 템플릿 생성과 더불어 수정 시 기존 내역을 함께 추적할 수 있도록 버저닝을 지원하고 있으며, 특정 버전으로의 복구 또한 지원하고 있습니다.
// 템플릿 업데이트 후의 템플릿 정보
{
"name": "example-plain-text",
"template": [
{
"role": "user",
"content": "{style} 말투로 {user_input}에 대해 알려줘"
}
],
"version": "2",
"versions": {
"1": [
{
"role": "user",
"content": "{style} 스타일로 {user_input}에 대해 알려줘"
}
],
"2": [
{
"role": "user",
"content": "{style} 말투로 {user_input}에 대해 알려줘"
}
]
}
}이렇게 등록한 템플릿은 서비스 호출 시 사용할 수 있으며 최종 요청 양식은 아래와 같습니다.
POST /v1/services/azure_openai/chat_completions
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"deployment_name": "gpt-4o",
"api_version": "2024-02-01",
"template": {
"name": "example-plain-text",
"queries": {
"style": "웃긴",
"user_input": "파이썬"
}
},
"params": {
"temperature": 0.7,
"max_tokens": 50
}
}자격증명을 지정하지 않은 경우, 프로젝트에 등록된 자격증명 중 호출 서비스(위 예시에선 azure openai)에 해당하는 임의의 자격증명을 선택합니다. 물론, 사용자가 특정 자격증명을 지정할 수도 있습니다
위 예시에서 보이는 바와 같이, 등록된 템플릿은 재사용이 가능하며 하나의 템플릿에 대해 다양한 모델, 서비스에 대한 비교 실험을 할 수 있습니다.
프록시 생성/관리
최종적으로 서비스에 생성형 AI API를 적용하기 위해 필요한 것은 자격증명, 프롬프트와 적절한 파라미터 값입니다. 이 요소들을 한데 정의하여 요청 양식을 간소화하며, 생성형 AI API 호출에 필요한 정보를 요청 클라이언트 서버와 독립적으로 관리 할 수 있는 프록시 기능을 제공합니다.
// 프록시 생성 요청
POST /v1/proxy
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"name": "auzre_opanai_proxy",
"credential_names": [
"azure_openai1",
"azure_openai2",
"azure_openai3"
],
"policy": "random",
"service": "auzre_openai",
"template": "tech-blog-example",
"options": {
"deployment_name": "gpt-4o",
"api_version": "2024-02-15-preview",
"params": {
"temperature": 0.7,
"max_tokens": 50
}
}
}프록시 기능의 이점은 요청 양식 간소화와 엔지니어 도움 없이 데이터 과학자가 즉각 수정/반영할 수 있다는 점과, 다중 자격증명 기능을 제공한다는 점입니다. 다중 자격증명 기능을 통해 대용량 트래픽 또는 순간 트래픽 쏠림에 의해 발생할 수 있는 Call rate limit 등의 문제를 해소할 수 있습니다. 프록시 생성 시 여러 개의 자격증명을 등록하면 게이트웨이 내부에서 적절한 자격증명을 선택하여 사용하며, 사용자는 이에 대한 고민을 하지 않아도 됩니다.
이와 같이 등록한 프록시 호출은 아래와 같이 간소화 됩니다.
// 프록시 호출
POST /v1/proxy/auzre_opanai_proxy/chat_completion
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"queries": {
"style": "웃긴",
"user_input": "파이썬"
}
}Azure OpenAI 와 동일한 형식으로 AWS Bedrock Foundation 모델도 프록시로 등록이 가능하며, GCP VertexAI Imagen 은 아래와 같이 프록시로 등록하여 사용 가능합니다.
// VertexAI Imagen에 대한 프록시 생성
POST /v1/proxy
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"name": "vertex-ai-imagegeneration-proxy",
"credential_names": [
"gcp_cred"
],
"service": "gcp_vertex_ai",
"policy": "random",
"options": {
"model_name": "imagen-3.0-generate-001",
"params": {
"negative_prompt": "steam, close up",
"number_of_images": 1,
"aspect_ratio": "1:1",
"language": "en",
"safety_filter_level": "block_few",
"person_generation": "dont_allow"
}
}
}파이프라인 생성/관리
생성형 AI를 기반으로 한 서비스 개발은 생성형 AI API를 단일 호출하는 것만으로 구성되지 않습니다. 생성형 AI 결과 기반으로 동일 생성형 AI API에 재차 요청할 수도 있고, 다른 생성형 AI API에 요청하여 최종 결과를 얻고자 하는 시나리오가 있을 수 있습니다. 전자의 경우는 프롬프트를 고도화하여 해결할 수 있지만 후자는 프롬프트 개선만으로 해결할 수 없습니다.
별도의 서버를 운영 중이라면 연속된 생성형 AI API를 호출하는 시나리오를 위해 게이트웨이에 재차 요청하도록 구현할 수 있겠지만, 만약 별도 서버를 운영하지 않고 게이트웨이 만으로 연속된 생성형 AI API를 호출을 원한다면 프록시 기능만으론 한계가 있습니다. 모든 경우의 수를 지원하고 있진 않지만 간단한 시나리오에 대해 순차적인 생성형 AI API 호출을 위해 게이트웨이에선 파이프라인 기능을 제공하고 있습니다.
아래는 Azure OpenAI를 활용하여 한국어를 영어로 번역하고, 번역된 결과를 프롬프트로 하여 이미지를 생성하는 파이프라인 예시입니다.
POST /v1/pipelines
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"name": "gpt_and_imagen",
"pipeline": [
{
"proxy": "to_eng",
"task": "chat_completion"
},
{
"proxy": "imagen",
"task": "generate_image",
"inputs": {
"prompt": "0.response.choices.0.message.content"
}
}
]
}사용자는 파이프라인 구성 시 후속 프록시에 이전 프록시의 특정 결과 값을 전달하도록 지정할 수 있습니다. 위 예제는 0번째 인덱스(첫 번째) 프록시의 결과에서 특정 필드 값(0.response.choices.0.message.content)을 프롬프트로 하여 이미지를 생성하는 예제입니다. 프록시와 마찬가지로 파이프라인의 요청 양식은 아래와 같이 간소화됩니다.
POST /v1/pipelines/gpt_and_imagen/run
x-project-name: {{project_name}}
x-api-key: {{api_key}}
{
"queries": {
"query": "꽃"
},
"params": {
}
}예시 파이프라인에 대한 게이트웨이 내부 흐름도는 아래와 같습니다.
지금까지 소개한 자격증명, 템플릿, 프록시 그리고 파이프라인은 프로젝트 내에서 재사용이 가능하며, 프로젝트 내에서 관리하고 사용하는 리소스들의 구조는 아래와 같습니다.
LangChain 호환성 지원
NLP(natural language processing, 자연어 처리) 도메인에선 단순히 생성형 AI API를 호출하는 것이 아니라 추가적인 방법론(예: RAG)을 활용하는 경우가 많습니다. LangChain의 활용도가 높으며, 게이트웨이 호출 역시 LangChain과의 호환성을 지원해야 합니다. 만약 지원하지 않는다면 게이트웨이에서 제공하는 기능을 LangChain과 호환되는 코드로 재차 구현하거나, 게이트웨이를 통해 실험한 프롬프트와 설정값들을 LangChain과 호환되는 코드에 옮기는 비효율이 발생 할 수 있습니다.
이를 방지하기 위해 LangChain의 pipe operator(|)와 호환될 수 있도록 ML SDK에서 게이트웨이 클라이언트를 제공하고 있습니다.
from woowa_ml_sdk.client.ai_api_gateway import AiApiGatewayClient
from woowa_ml_sdk.util.config import Config
config = Config("beta", "project_name")
llm = AiApiGatewayClient(
config=config,
api_key=os.getenv("AI_API_GATEWAY_API_KEY"),
service="azure_openai",
credential="azure_openai_cred", # 생략시 게이트웨이에서 임의 선택
template="...",
params={...}
)
prompt = ChatPromptTemplate.from_messages(
[("system", "you are a bot"), ("human", "{input}")]
)
chain = prompt | llm
chain.invoke("hello")위는 ML SDK를 활용하여 게이트웨이를 호출 LLM으로 사용한 예시입니다. 만약 프록시를 적절히 구성했다면 service=auzre_openai를 service=aws_bedrock으로 수정하여 생성형 AI API 제공자를 손 쉽게 변경 할 수도 있습니다. 또한 게이트웨이 클라이언트 클래스는 비동기 호출을 지원하여, Python으로 구현된 클라이언트 서버에서도 게이트웨이 호출 용도로도 사용하기에 적합합니다.
공용 대시보드
외부 생성형 AI API를 활용하는 데 있어 관심과 주의를 기울여야 하는 부분은 비용입니다. 비용은 생성 도메인(NLP, Vision) 별로 책정 단위가 다르며, 사용하는 모델이나 API 제공자에 따라서도 다릅니다. 텍스트 생성형 AI API의 경우 입출력 토큰 수에 비례하여 가격이 책정되며, 이미지 생성형 AI API의 경우 생성된 이미지 수에 비례합니다. 이 둘 다 API 요청 수와 비례하지 않으며, 비용 추세를 한눈에 파악하기 위해선 비용 단위에 맞춘 대시보드 제공이 필요합니다. 게이트웨이에서는 프로젝트 또는 모델 단위로 비용과 비례하는 메트릭을 한눈에 볼 수 있는 대시보드를 제공합니다.
(모델, 작업)별 요청량
LLM 서비스의 (프로젝트, 모델)별 요청량 및 입출력 토큰 수
Vision 서비스의 (프로젝트, 모델)별 생성된 이미지 수
향후 계획
현재 게이트웨이는 API기반으로만 기능을 제공있어, 게이트웨이를 사용하기 위해선 별도의 HTTP Client(예: PostMan)를 사용하거나 호출 코드를 구현해야 합니다.
게이트웨이의 사용성 증대를 위해, AI플랫폼에서 개발 중인 AI Studio(서비스 개발/운영을 위한 웹페이지)에 게이트웨이의 리소스(프로젝트, 자격증명, 템플릿 등)를 관리하고 서비스 요청 등을 할 수 있는 웹뷰를 제공하고, 생성형 AI 결과 품질의 핵심이 되는 템플릿을 구성원들 간 공유할 수 있는 템플릿 허브를 구성할 계획입니다.
마치며
생성형 AI를 활용한 서비스를 개발하는 구성원들의 고민을 듣고, 우리에게 우선 필요한 것이 무엇인지, 그리고 어떤 문제점들이 있는지를 파악하여 게이트웨이를 개발하게 되었습니다. 소개 드린 게이트웨이를 통해 생성형 AI를 활용한 서비스 개발팀의 생산성을 크게 향상시킬 것으로 기대하고 있으며, 서비스 개발자분들과의 지속적인 소통을 통해 NoCode로 생성형 AI 서비스를 만들 수 있는 환경을 만들기 위해 노력하도록 하겠습니다.
우아한형제들에서 AI 서비스 개발 효율화를 위한 다양한 일들을 하고 있습니다🫡