이 글은 [요즘 우아한 AI 개발]에서 발췌했습니다.
글 우아한형제들 / 골든래빗 출판사
[요즘 우아한 AI 개발] 생성형 AI 서비스 : 게이트웨이로 쉽게 시작하기
우아한형제들의 AI플랫폼팀은 생성형 AI 기술을 효율적으로 활용할 수 있는 환경을 제공해 서비스 개발의 생산성과 품질을 향상시키고자 합니다. 그 첫 단계로 AI API 게이트웨이를 개발하게 되었습니다. 본 글에서는 게이트웨이의 개발 경험과 주요 기능, 그리고 향후 계획을 소개합니다.
개발 배경
생성형 AI 도구들의 확산은 크게 두 가지 측면에서 큰 변화를 가져오고 있습니다. 첫째, 생성형 AI 도구들은 AI/ML 기술적 전문 지식이 없는 일반 사용자들도 손쉽게 AI 기술을 활용할 수 있게 해줍니다. 복잡한 프로그래밍이나 데이터 과학 지식 없이도, 간단한 프롬프트 입력만으로 고품질의 텍스트나 이미지를 생성할 수 있게 되었습니다. 이는 수학이나 통계에 대한 깊은 지식 없이도 자동화 도구를 활용해 데이터를 분석하고, 새로운 인사이트를 도출해 결과를 개선할 수 있게 되는 AI 기술의 민주화를 촉진하고 다양한 분야에서 활용 사례를 만들어내고 있습니다. 둘째, 기업들은 자체 모델 개발 또는 사전 훈련된 딥러닝 모델을 새로운 데이터셋이나 특정 작업에 맞게 추가로 학습시키는 파인튜닝 방법에 많은 시간과 비용을 투자하지 않고도, 생성형 AI 도구들을 활용해 빠르게 AI 기반 서비스를 개발하고 출시할 수 있게 되었습니다. 이는 기업의 AI 도입 속도를 가속화하고, 새로운 비즈니스 모델과 서비스 혁신을 촉진하고 있습니다.
우아한형제들 역시 세계적 흐름에 발맞추어 생성형 AI 기술을 도입하고 있습니다. 회사 전반에 걸쳐 다양한 업무와 서비스 개발 영역에서 생성형 AI 도구들을 활용하고 있으며, 이를 사용하는 구성원과 적용 서비스 수는 꾸준히 증가하고 있습니다. 특히 주목할 만한 점은 신규 서비스 기획 단계에서부터 생성형 AI 활용을 적극적으로 검토한다는 점입니다.
대표적인 사례는 ‘저품질 메뉴 이미지의 개선’¹ 기능으로, 과도하게 확대 촬영된 메뉴 이미지의 배경 영역을 확장(아웃 페인팅)하는 기술을 적용하고 있습니다.
생성형 AI 기술의 활용이 늘어나는 상황에서 AI플랫폼은 생성형 AI 기술을 더욱 효율적으로 개발할 수 있는 환경을 제공해 구성원들의 업무 생산성과 서비스 품질을 향상하는 방안을 모색하고자 했습니다. 생성형 AI의 효율적 활용을 위해 가장 필요한 요소를 파악하고자, 구성원들과의 인터뷰를 우선적으로 실시했습니다.
생성형 AI를 잘 활용하려면 무엇이 필요한가?
생성형 AI를 적극 활용하는 구성원들과의 인터뷰를 통해 어떠한 어려움이 있고 AI플랫폼에 우선 제공해야 할 기능이 무엇이 있는지 알아보았습니다. 인터뷰를 통해 도출된 주제들은 다음과 같습니다.
- API 게이트웨이: 생성형 AI 시스템의 핵심 인프라 구성 요소로, 반복적인 개발 작업을 최소화하고 시스템의 안정성과 보안성을 향상시키는 플랫폼
- 실험적 피드백(Experimental Feedback): 생성형 AI의 생성 결과 품질을 지속적으로 개선하기 위해 사용자 피드백을 수집, 반영하기 위한 기능
- LLM 서빙: 사내 자체 대규모 언어 모델(LLM) 또는 공개된 LLM 모델을 효율적으로 운영, 관리, 제공
- 프롬프트 실험(Prompt Experiment): 효과적인 프롬프트 개발과 최적화를 위한 실험 환경 제공
- 하이브리드 검색(Hybrid Search)*: 어휘 검색²과 시맨틱 검색³을 결합한 고급 검색 시스템
- RAG 파이프라인 : 라인의 표준화 제공 외부 지식을 활용해 생성형 AI의 응답 품질을 향상시키는 파이프
우아한형제들의 AI플랫폼 개발자, 데이터 과학자, 프로젝트 매니저 의견을 종합해, AI플랫폼팀은 위의 주제 중 생성형 AI 기술을 사용하기 위한 API 게이트웨이 개발을 최우선으로 하기로 결정했습니다. 우아한형제들에서는 AWS 베드록⁴, 애저 오픈AI, GCP 이마젠⁵ 등 다양한 생성형 AI 서비스들을 적절하게 활용하는 점 역시 게이트웨이 개발의 우선순위 선정에 중요한 고려 사항이 되었습니다.
또한 기존 생성형 AI를 활용한 서비스들의 프롬프트와 호출 로직들이 파편화되어 있었으며, RAG 파이프라인, 프롬프트 실험, 실험적 피드백의 지원에 앞서 자격증명과 프롬프트를 한 곳에 모아 관리할 수 있는 허브 역할이 우선 필요하다고 판단했습니다.
다양한 외부 AI API 서비스를 통합 관리하는 솔루션인 콩⁶, Dify.ai⁷ 등이 이미 존재하지만 다음과 같은 배경으로 직접 개발, 운영하게 되었습니다.
- 맞춤형 요구사항 충족 : 특정 AI 워크로드에 대한 요구사항 발생 시 빠른 지원 필요
- 유연성 확보 : 빠르게 변하는 AI 기술에 맞춰 게이트웨이를 신속하게 수정하고 확장할 수 있는 유연성 확보 필요
- 비용 절감 : 상용 솔루션 대비 장기적으로 비용 절감
- 보안 강화 : AI 모델과 데이터에 대한 특화된 보안 요구사항 충족
- 통합 용이성 : 기존 인프라 및 워크플로와의 원활한 통합
풀어야 할 문제들
자격증명
API 호출 시 자격증명과 같이 필요한 값들을 관리하고, 생성형 AI API에 제공할 필요가 있습니다. 다음과 같이 생성형 AI 서비스별로 기존 인프라 들과 연동하기 위해 필요한 값과 활용 방법이 다릅니다.
- OHT SEAI : AZURE_OPENAL_ENDPOINT, AUZRE_OPENAL_API_KEY
- GCP 버텍스AI : credential json
- AWS 베드록 : IAM Role ARN (+ Security Token Service(STS))
- 네이버 클라우드 플랫폼 : invoke_url, secret_key
AI플랫폼에선 이런 값들을 AWS 시크릿 매니저⁸를 통해 관리/제공하고 있었습니다.
하지만 시크릿 매니저로 관리하면 다음과 같은 문제점이 있습니다.
- 신규 서비스 개발 시, AI플랫폼 개발자가 시크릿 매니저에 신규 보안 암호 생성 요청 필요
- 수정 필요 시, 시크릿 매니저에서 수정 후 즉각적인 익스터널 시크릿 갱신을 위한 배포 필요
- 서비스 단위로 보안 암호를 생성하면서 관리가 필요한 보안 암호 수가 지속적으로 증가
- 자격증명에 대한 히스토리 관리 및 추적이 어려우며, 이에 대한 정책과 시스템의 필요
이를 해결하기 위해 생성형 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( mode l="gpt-35-turbo", messages=[...] )
하지만 실서비스에 적용하려면 다음과 같은 고민과 개발이 필요합니다.
- 개인 식별 정보
이름, 전화번호 등 민감 정보는 외부로 유출되면 안 되며, 민감 정보를 토대로 결과가 생성되면 안 됩니다. 민감 정보가 주입되는 서비스라면 민감 정보를 포함한 요청은 거 부하거나 민감 정보를 마스킹 처리한 후 외부 생성형 API에 전달해야 합니다. - 로깅
생성형 AI의 입출력 데이터는 서비스 디버깅, 결과 품질 향상 루프, 캐싱 등 다양하게 활용될 수 있습니다. 입출력 데이터를 활용하려면 서비스별로 로깅을 위한 저장소를 생성/관리해야 하며, 표준 입출력을 정의하고 적재 로직을 구현해야 합니다. 또한 생 성형 AI는 입력 프롬프트뿐만 아니라, 설정값에 따라 생성 결과가 달라지므로, 파라미 터들도 로깅할 필요가 있습니다. - 제한 (Quota / Call Rate)
다수의 생성형 Al API에선 단일 리소스에 요청량을 무한히 제공하고 있지 않습니다. API 호출은 할당량 제한(Quota Limit) 또는 호출 속도 제한(Call Rate Limit)이 발생 할 수 있으며, 다른 예외 상황과의 구분을 위해 서비스 개발 시 예외 처리와 폴백 로직⁹을 구현해야 합니다. 또한 대용량 트래픽이 예상되는 서비스의 경우, 생성형 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( mode 1="gpt-35-turbo-instruct", prompt=temp late. format**query), temperature=0 ) response = client.chat.completions.create( mode 1="gpt-35-turbo". messages=…・・ )
설정(api_key, api_version, model) 또는 파라미터 값(prompt, temperature)을 수정하거나, 호출하는 생성 AI 서비스가 변경(애저 오픈 AI AWS 베드록)되면 코드 수정 및 배포 작업이 필요합니다. 하지만 외 부 API 호출에 필요한 값들은 시시각각 변할 수 있으며, 프롬프트와 같은 리소스 파일 수정을 위해 재배포가 이루어지는 것은 비효율적입니다. 게이트웨이에서 해당 문제를 해결하기 위해 동적 라우팅과 내부 리소스(예 : 템플릿) 관리 기능을 구현했습니다. 이를 통해 데이터 과학자 또는 생성 형 AI의 비즈니스 로직을 담당하는 개발자는 서버 코드 수정 없이 즉각적 인 수정할 수 있습니다. 관리 기능의 이점을 정리하면 다음과 같습니다.
- 유연성 향상 : 외부 API 호출에 필요한 값들을 실시간으로 수정할 수 있으며, 시시각각 변하는 요구사항에 신속히 대응
- 운영 효율성 : 코드 변경 및 재배포 없이 구성을 변경할 수 있어 운영 부담 감소
- 중앙 관리 : 모든 구성을 게이트웨이에서 관리해 일관성 유지
AI API 게이트웨이
다음은 게이트웨이의 핵심 기능들과 호출 흐름을 나타낸 그림입니다.
게이트웨이는 다양한 사용 사례와 개발 시나리오를 수용하기 위해 HTTP 호출과 AI플랫폼 인프라와의 연동을 도와주는 ML SDK¹⁰를 통한 호출, 두 방식을 지원합니다.
- HTTP 호출 : 간단한 프록시나 파이프라인 호출에 적합하며, 타 서빙 서버에 쉽게 연 동하는 경우
- ML SDK : 복잡한 전후 처리가 필요하거나 랭체인¹¹과 같은 별도 프레임워크와의 결 합이 필요한 경우
서비스 개발자는 필요한 정보만 게이트웨이에 등록하면 적절한 엔드 포인트를 제공받음으로써, 각 구성원의 전문 영역에 집중할 수 있도록 했습 니다. 이를 통해 더 높은 품질의 AI 서비스를 빠르고 효율적으로 개발할 수 있기를 기대 했습니다.
지원 서비스
현재 게이트웨이에서 지원하는 서비스는 다음과 같습니다.
- AWS 베드록
- 애저 오픈AI
- GCP 버텍스AI 이마젠
- 네이버 클라우드 플랫폼(실험적. 현재 OCR 서비스 제공)
지원 기능
게이트웨이에선 프로젝트, 자격증명, 템플릿 관리 기능과 서비스 제공 을 위해 엔드포인트를 제공하며, 프록시 및 파이프라인 기능도 포함하고 있습니다. 또한 널리 활용되고 있는 랭체인과의 호환성도 지원하고 있습 니다. 이제부터 각각을 알아보겠습니다.
프로젝트
게이트웨이에 등록되어 있는 다양한 리소스와 설정에 대한 수정/삭제 권한의 제한과 무분별한 호출을 방지하기 위해, 각 요청에 대해 api_key 의 유효성을 검증할 수 있도록 프로젝트 개념을 제공하고 있습니다. 사용 자는 먼저 프로젝트 생성을 요청하고, 발급받은 api_key를 활용해 게이트 웨이를 사용하게 됩니다. 베타/운영 환경은 독립적으로 프로젝트를 관리 하며, api_key 역시 별도로 발급됩니다.
자격증명 관리
생성형 AI API 호출에 필요한 자격증명 값들을 AWS 시크릿 매니저가 아 닌 게이트웨이에 등록하고 관리할 수 있습니다. 게이트웨이에서 자격증 명 관리 기능을 제공함으로써 사용자는 시크릿 매니저를 직접 다룰 필요 가 없으며, 필요 시 게이트웨이를 통해 수정/삭제해 서비스에 즉각 반영 할 수 있습니다. 또한 게이트웨이 내부적으로 API 호출 시 필요한 AWS 베 드록, 애저 오픈AI, GCP 버텍스AI, NCP 연동을 제공해 사용자는 멀티 클 라우드 환경에 대한 고민을 줄일 수 있습니다(AWS 베드록 경우, SIS를 활 용해 호출을 제어하고 있습니다).
템플릿 관리
프롬프트¹²는 생성형 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 } }
자격증명을 지정하지 않으면 프로젝트에 등록된 자격증명 중 호출 서 비스(위 예시에선 애저 오픈AI)에 해당하는 임의의 자격증명을 선택합니 다. 물론, 사용자가 특정 자격증명을 지정할 수도 있습니다. 위 예시에서 보이는 바와 같이, 등록된 템플릿은 재사용이 가능하며 하나의 템플릿에 대해 다양한 모델, 서비스에 대한 비교 실험을 할 수 있습니다.
프록시 생성/관리
최종적으로 서비스에 생성형 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 } } }
프록시 기능의 이점은 요청 양식 간소화와 엔지니어 도움 없이 데이터 과학자가 즉각 수정/반영할 수 있다는 점과, 다중 자격증명 기능을 제공 한다는 점입니다. 다중 자격증명 기능을 통해 대용량 트래픽 또는 순간 트래픽 쏠림에 의해 발생할 수 있는 호출 속도 제한¹³ 등의 문제를 해소할 수 있습니다. 프록시 생성 시 여러 개의 자격증명을 등록하면 게이트웨이 내부에서 적절한 자격증명을 선택해 사용하며, 사용자는 이에 대한 고민을 하지 않아도 됩니다.
이와 같이 등록한 프록시 호출은 다음과 같이 간소화됩니다.
// 프록시 호출 POST /v1/proxy/auzre_opanai_proxy/chat_completion x-project-name: {{project_name}} x-api-key: {{api_key}} { "queries": { "style": "웃긴", "user_input": "파이썬" } }
애저 오픈AI와 같은 형식으로 AWS 베드록 기본 모델도 프록시로 등록이 가능하며, GCP 버텍스AI 이마젠(Imagen)은 다음과 같이 프록시로 등록해 사용할 수 있습니다.
// 버텍스AI 이마젠에 대한 프록시 생성 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 호출을 위 해 게이트웨이에서 파이프라인 기능을 제공하고 있습니다.
다음은 애저 오픈AI를 활용해 한국어를 영어로 번역하고, 번역된 결과를 프롬프트로 해 이미지를 생성하는 파이프라인 예시입니다.
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": { } }
예시 파이프라인에 대한 게이트웨이 내부 흐름도는 다음과 같습니다.
지금까지 소개한 자격증명, 템플릿, 프록시 그리고 파이프라인은 프로 젝트 내에서 재사용이 가능하며, 프로젝트 내에서 관리하고 사용하는 리소스들의 구조는 다음과 같습니다.
랭체인 호환성 지원
NIP¹⁴ 도메인에선 단순히 생성형 AI API를 호출하는 것이 아니라 추가적 인 방법론(예 : RAG)을 활용하는 경우가 많습니다. 랭체인의 활용도가 높으며, 게이트웨이 호출 역시 랭체인과의 호환성을 지원해야 합니다. 만약 지원하지 않다면 게이트웨이에서 제공하는 기능을 랭체인과 호환되는 코 드로 재차 구현하거나, 게이트웨이를 통해 실험한 프롬프트와 설정값들 을 랭체인과 호환되는 코드에 옮기는 비효율이 발생할 수 있습니다.
이를 방지하기 위해 랭체인의 파이프 연산자(I)와 호환되게 ML SDK에서 게이트웨이 클라이언트를 제공하고 있습니다.
from woowa_ml_sdk.client.ai_api_gateway import 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 제공자를 손 쉽게 변경 할 수도 있습니다. 또한 게이트웨이 클라이언트 클래스는 비동기 호출을 지원해, 파이썬으로 구현된 클라이언트 서버에서도 게이트웨이 호출 용 도로도 사용하기에 적합합니다.
공용 대시보드
외부 생성형 AI API를 활용하는 데 있어 관심과 주의를 기울여야 하는 부분은 비용입니다. 비용은 생성 도메인(NLP, Vision)별로 책정 단위가 다 르며, 사용하는 모델이나 API 제공자에 따라서도 다릅니다. 텍스트 생성 형 AI API의 경우 입출력 토큰 수에 비례해 가격이 책정되며, 이미지 생성형 AI API의 경우 생성된 이미지 수에 비례합니다. 이 둘 다 API 요청 수와 비례하지 않으며, 비용 추세를 한눈에 파악하기 위해선 비용 단위에 맞춘 대시보드 제공이 필요합니다. 게이트웨이에서는 프로젝트 또는 모델 단위로 비용과 비례하는 메트릭을 한눈에 볼 수 있는 대시보드를 제공합니다.
향후 계획
현재 게이트웨이는 API 기반으로만 기능을 제공하고 있어, 게이트웨이 를 사용하려면 포스트맨 같은 별도의 HTTP 클라이언트를 사용하거나 호 출 코드를 구현해야 합니다. 게이트웨이의 사용성 증대를 위해, AI플랫폼 에서 개발 중인 AI 스튜디오(서비스 개발/운영을 위한 웹페이지)에 게이트웨이의 리소스(프로젝트, 자격증명, 템플릿 등)를 관리하고 서비스 요 청 등을 할 수 있는 웹뷰를 제공하고, 생성형 AI 결과 품질의 핵심이 되는 템플릿을 구성원 간 공유할 수 있는 템플릿 허브를 구성할 계획입니다.
마치며
생성형 AI를 활용한 서비스를 개발하는 구성원들의 고민을 듣고, 우리 에게 우선 필요한 것이 무엇인지, 그리고 어떤 문제점들이 있는지를 파악 해 게이트웨이를 개발하게 되었습니다. 이 게이트웨이를 통해 생성형 AI를 활용한 서비스 개발팀의 생산성을 크게 향상시킬 것으로 기대하고 있습니다. 또한 서비스 개발자와의 지속적인 소통을 통해 노코드로 생성형 AI 서비스를 만들 수 있는 환경을 만들고자 노력하고 있습니다.
¹https://cloud.google.com/vertex-ai/docs/vector-search/about-hybrid-search
²Lexical Search: 데이터에서 단어의 철자나 형태를 기준으로 정확히 일치하는 항목을 검색하는 방식으로, 의미보다는 문자 그대로의 매칭에 초점을 둡니다. (예: 키워드 기반 검색)
³Semantic Search(의미 기반 검색): 단순히 키워드가 아니라 문맥과 의미를 분석하여 사용자의 의도와 관련성 높은 결과를 제공하는 검색 방식. (예: 자연어 처리 기반 검색)
⁴AWS Bedrock: 생성형 AI 애플리케이션을 구축하기 위해 여러 기본 모델(Foundation Models)을 API 를 통해 쉽게 통합하고 관리할 수 있는 AWS 서비스
⁵GCP Imagen : 구글 클라우드에서 제공하는 생성형 AI 모델로, 텍스트를 입력받아 고품질 이미지를 생성하는 기술
⁶Kong: API 관리 플랫폼. 세계 유수의 기업과 혁신적인 기술을 지원하며, API 게이트웨이, 서비스 메쉬, 및 마이크로서비스 관리를 제공하는 오픈소스 기반 솔루션
⁷Dify.ai: 사용자 맞춤형 AI 애플리케이션을 빠르게 생성하고 관리할 수 있도록 지원하는 플랫폼. AI 모델 통합, 데이터 관리, 워크플로 자동화를 간소화합니다.
⁸AWS Secrets Manager: 애플리케이션에서 사용하는 데이터베이스 자격 증명, API 키 등 중요한 비밀 정보를 안전하게 저장, 자동으로 회전, 관리할 수 있는 AWS 서비스
⁹Fallback Logic: 시스템이 장애나 오류 상황에서 정상 동작을 유지하거나 최소한의 기능을 제공하기 위해 대체 경로나 기본값을 사용하는 처리 방식(예: API 실패 시 캐싱된 데이터 반환)
¹⁰《요즘 우아한 개발》 4.2절 ‘배민 AI 서비스와 MLOps 도입기’ 참고
¹¹LangChain : LLM(Large Language Model)을 활용한 애플리케이션 개발을 간소화하고 확장하기 위해 제공되는 프레임워크. 체인형 워크플로, 데이터 연결, 모델 간 조정을 지원합니다.
¹²템플릿은 동적인 입력을 받으며, 입력(쿼리)을 토대로 최종 프롬프트를 생성합니다.
¹³Call Rate Limit : 주어진 시간 내에 API 또는 서비스에 대한 요청 횟수를 제한하여 시스템 과부하를 방지 하고 안정성을 유지하는 제어 메커니즘입니다(예: 초당 10회 호출 제한).
¹⁴natural language processing, 자연어 처리
I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
