사내에서 LLM 을 이용한 서비스를 개발하고 있다. 그 과정에서 여러 LLM Provider 를 고려한 설계가 필요하게 되었다. 각 회사마다 제공하는 API 스펙, SDK 가 다르기 때문에 이들을 어떻게 한번에 관리할 수 있을까 고민하게 되었다.
multiple LLM provider 에 대한 고민을 하면서 개발을 하고 있는데, 한번씩 그 내용들을 글로 정리하려고 한다. 이번 글에서는 처음했었던 고민과 OpenAI API 기반으로 초기 개발 방향을 선정한 과정을 정리한다.
1. LLM API provider
LLM 서비스를 개발하다보면 다양한 선택지의 provider 들을 만난다. OpenAI, Microsoft Azure, Anthropic, Google, Amazon Bedrock 등등 다양한 회사들에서 각각의 플랫폼을 기반으로 많은 모델들을 제공해준다.
각 플랫폼들은 각자의 특화된 기능이나, 자사에서만 제공해주는 모델들을 가지고 있다. 이때문에 다양한 모델들, 새로 배포되는 좋은 성능의 모델들을 서비스에 적용하기 위해서는 여러개의 provider 를 사용해야 한다.
여러개의 LLM provider 를 사용하기로 결정했다면 이제 이들을 어떻게 연동할 것인지, 관리할 것인지 고민이 따라온다. 각 provider 들이 제공하는 SDK 나 전용 API client 들을 사용해야 하는데, 이들은 인터페이스가 다 제각각이라서 공통적으로 관리하는 것이 쉽지 않다. 그렇다고 이들을 통일시키지 않고 각각의 기능에서 호출하는대로 제각각 만들자니 앞으로의 유지보수가 너무 어려울 것 같다.
이러한 고민들의 끝에 공통 인터페이스 레이어를 고민하게 되었다.
2. 공통 LLM 인터페이스
공통 LLM 인터페이스의 아이디어는 애플리케이션의 LLM 서비스 레이어와 LLM provider 의 SDK, API 를 사용하는 레이어 사이에 공통의 인터페이스 레이어를 하나 더 두고, 각각의 provider 연동은 이 레이어 아래에서 처리하는 것이다.
Application Service ----> LLM Interface ----> Provider Adapter (OpenAI, Azure, Google, Claude ...)
이러한 구조를 염두에 두고 자료를 찾아보던 중, 여러 회사에서 이러한 레이어를 어떻게 다루고 있는지, 어떻게 구축하여 사용하고 있는지 확인할 수 있었다.
우아한 형제들
- https://techblog.woowahan.com/22839/
- https://techblog.woowahan.com/23667/
당근마켓
- https://medium.com/daangn/%EB%8B%B9%EA%B7%BC%EC%9D%98-genai-%ED%94%8C%EB%9E%AB%ED%8F%BC-ee2ac8953046
모두 Gen AI 를 위한 플랫폼을 구축하여 LLM 관련 코드들을 관리하고 있었다. 그 과정에서 여러가지 모듈을 사용하거나 직접 구현하고 있었다.
3. OpenAI API 호환성
자료를 조사하던 중 주요 Provider 대부분이 OpenAI API 호환성을 지원해준다는 것을 발견했다.
OpenAI 와 협력하고 있는 Azure 뿐만 아니라 Anthropic, Google, AWS, Meta 등의 주요 Provider 들도 OpenAI API 를 통해 사용할 수 있다.
- Anthropic Claude: https://platform.claude.com/docs/en/api/openai-sdk
- Google Gemini: https://ai.google.dev/gemini-api/docs/openai
- AWS Bedrock: https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-openai.html
- Meta Llama: https://llama.developer.meta.com/docs/features/compatibility/
각각의 SDK 를 설치할 필요없이, OpenAI 패키지와 해당 Provider 의 API key 만 있다면 LLM 기능을 사용할 수 있다.
물론 각 Provider 들에 종속된 기능들은 사용할 수 없고, 제한적이다는 단점이 있다. 하지만 지금 우리의 상황에서는 그러한 이유들이 큰 문제가 되지 않았다.
현재 우리 서비스에서 사용하고 있는 LLM 기능들은 채팅 기능과 텍스트 임베딩 기능이다. 이러한 기능들은 OpenAI API 만으로도 사용할 수 있는 기본적인 기능들이다.
또한 지금 당장 모든 LLM Provider 들과의 연동이 필요한 경우는 아니다. 그렇기 때문에 굳이 복잡한 인터페이스와 추상화가 필요없다.
이때문에 공통 인터페이스의 설계에는 OpenAI API 스펙을 기반으로 설계하기로 했다. 초기에 너무 많은 공수를 들이지 않으면서 여러 Provider 들을 연동할 수 있도록 하고, 사실상 업계 표준이 된 OpenAI API 를 기반으로 설계하여 이후 수정시에도 최대한 영향을 적게 받도록 개발하려한다.
확장성에 대해서도 고민을 했는데, 향후 여러 Provider 들의 전용 기능을 사용해야 하거나, 각각의 인터페이스를 맞추기 어려운 상황을 맞이하게 될 수도 있다. 이러한 상황들도 고려하여 공통 인터페이스 레이어를 구축하되, 이 레이어에 너무 많은 로직을 두지 않으려고 한다. Provider 에 종속된 기능, 구현 사항들은 각각의 Adapter 에 구현하여 구조를 유지하려고 한다.