어떤 LLM을 도입할 것인가

“무슨 모델을 쓰지?”는 잘못된 질문이었습니다. 옳은 질문은 “어떤 작업에 어떤 모델을 붙이고, 그 선택을 나중에 코드 수정 없이 바꿀 수 있게 어떻게 만들지?”였습니다. 모델 하나를 코드에 박는 순간, 그 시스템은 한 회사에 인질로 잡힙니다. 이 글은 그 함정을 피하려고 어떻게 설계했는지의 기록입니다.

실제 연결 관리 센터. "어떤 작업에 어떤 모델"이 그대로 보입니다 — 분류·요약·추출·RAG는 DeepSeek, 고난도 추론·에이전트는 Claude, 임베딩은 OpenAI. 코드가 아니라 이 표에서 모델이 갈립니다. 모든 키는 한곳에 모아 두고(🔒 = 교체 시 복구 불가), 키 값 자체는 가렸습니다.

LLM·임베딩·게이트웨이

본론에 들어가기 전에 세 단어만 정리하겠습니다. 이 글은 이 셋의 관계로 거의 다 설명됩니다.

용어: LLM (대규모 언어 모델)

글을 읽고 쓰고 판단하는 “두뇌” 역할의 AI입니다. 대화하고, 요약하고, 도구를 골라 호출합니다. 요청할 때마다 글자(토큰)를 처리하므로 쓸수록 비용이 듭니다.

용어: 임베딩(embedding) 모델

글을 의미를 담은 숫자 묶음(벡터)으로 바꾸는 모델입니다. “비슷한 뜻인지”를 계산할 때 씁니다. 문서를 한 번만 변환해 두면 끝이라 LLM 대화보다 훨씬 저렴합니다.

용어: LLM 게이트웨이

여러 모델을 코드 곳곳에 직접 부르지 않고, “어떤 작업엔 어떤 모델”이라는 표 한 장으로 중계하는 중간 계층입니다. 이 표만 바꾸면 모델이 갈립니다.

한 모델로 다 되지 않는다 — 역할 분담

처음엔 막연히 “제일 좋은 모델 하나 쓰면 되지”라고 생각했습니다. 실제로 붙여 보니 작업마다 필요한 능력이 완전히 달랐습니다. 대화하고 판단하고 도구를 호출하는 “두뇌” 역할과, 문서를 벡터로 바꿔 의미 유사도를 계산하는 “임베딩” 역할은 아예 다른 종류의 일입니다. 같은 모델에 둘 다 시키는 건, 변호사에게 번역까지 시키는 것과 비슷합니다 — 되긴 되지만 비싸고 어색합니다.

예를 들어 회사 규정을 검색해 답하는 기능(RAG)은 두 모델의 협업으로 돌아갑니다. 한 모델이 질문과 규정 문서를 벡터로 바꿔 비슷한 조각을 찾고(임베딩), 다른 모델이 그 조각을 읽어 자연스러운 답을 만듭니다(LLM 추론). 둘은 경쟁이 아니라 분업입니다. 비용 구조도 정반대입니다 — 추론은 요청마다 토큰을 태우고, 임베딩은 문서를 한 번만 변환하면 끝입니다.

작업 유형별로 요구가 갈린다

요약·분류·추출 같은 일반 텍스트 작업, 회계 분개처럼 정확도가 생명인 작업, SLA 서술형 진단처럼 추론이 깊어야 하는 작업, 도구를 호출하는 에이전트 대화, 임베딩 검색 — 각각 요구하는 성능·비용·지연이 다릅니다. “하나로 통일”은 비싸거나, 약하거나, 둘 다였습니다. 작업마다 최적 모델이 다르다는 게 출발점이었습니다.

표로 정리하면 “왜 한 모델로 안 되는가”가 한눈에 보입니다.

작업	가장 중요한 것	비용 성격
요약·분류·추출	적당한 품질·낮은 비용	요청마다 토큰 소모 (자주 호출)
회계 분개	정확도(틀리면 안 됨)	요청마다 토큰 소모
SLA 서술형 진단	깊은 추론	요청마다 토큰 소모 (드물게 호출)
임베딩 검색	일관된 벡터	한 번 색인하면 끝 (매우 저렴)

모델이 아니라 “작업”에 모델을 붙인다 — capability 라우팅

그래서 모델을 코드 곳곳에 박는 대신, 작업(capability) → 제공자/모델 매핑을 한 곳에 모은 게이트웨이를 설계했습니다. 호출하는 코드는 “이건 요약 작업이야”라고만 말하고, 어떤 모델이 그 요약을 처리할지는 라우팅 표가 결정합니다.

용어: capability 라우팅

“어떤 모델을 부를까”를 호출하는 코드가 정하지 않고, “이건 무슨 종류의 작업인가(capability)“만 선언하면 중앙 표가 모델을 골라 주는 방식입니다. 코드는 작업의 종류만 알고, 모델 선택은 표가 책임집니다.

호출하는 코드는 작업의 종류만 말합니다. 가운데 라우팅 표가 그 작업을 어떤 모델로 보낼지 결정하고, 모델은 표 뒤에서 부품처럼 갈아 끼워집니다. 코드는 모델 이름을 모릅니다.

구체적인 운영 방식은 이렇습니다.

• 각 작업은 미리 정해진 허용 조합 목록(제공자 + 모델)을 가집니다. 아무 모델이나 꽂히지 않습니다.
• 운영자는 화면에서 작업별 모델을 골라 바꿉니다. 코드 수정도, 재배포도 없습니다.
• 한 제공자가 죽으면 다음 후보로 넘어가는 폴백 경로를 둡니다.

”표가 진짜로 호출을 통제하는가” — 왕복 검증

이런 표를 만들 때 가장 흔한 함정은 **“되는 척하는 표”**입니다. 화면에는 모델 선택 드롭다운이 있는데, 실제 호출부는 여전히 코드에 박힌 모델을 부르는 경우입니다. 표는 장식이고 아무것도 통제하지 못합니다. 이게 가장 위험합니다 — 바꿨다고 믿었는데 안 바뀌었기 때문입니다.

그래서 결정적 증거를 확인하는 절차를 거쳤습니다. 어떤 작업의 모델을 화면에서 A에서 B로 바꾼 뒤, 같은 API를 호출하고, 그 호출 기록에 남은 모델 이름이 A에서 B로 바뀌어 있는지 확인했습니다. 바뀌어 있으면 표가 실제 호출을 통제한다는 뜻입니다. 이 왕복(round-trip) 검증 — 바꾸고 → 호출하고 → 기록을 되읽어 확인 — 없이는 “라우팅이 된다”고 말할 수 없었습니다.

실제로 확인한 것

회계 분개와 SLA 진단 같은 실제 기능의 호출부를 라우팅 표 통제 아래로 옮겼고, 화면에서 모델을 바꾸면 그 변경이 실제 호출에 반영되는 것을 확인했습니다. 여러 종류의 LLM을 화면에서 골라 교체할 수 있도록 묶었습니다. “표가 곧 진실”임을 왕복으로 증명한 셈입니다.

벤더에 인질 잡히지 않기 — 그러나 작업마다 자유는 다르다

모델을 코드에 박으면 그 회사의 가격 인상·정책 변경·서비스 중단에 그대로 끌려갑니다. 게이트웨이의 진짜 가치는 편의가 아니라 협상력입니다. 비싼 모델은 정말 필요한 작업(정확도가 생명인 회계, 추론이 깊은 진단)에만 쓰고, 나머지는 저렴한 모델로 내립니다. 예산을 넘기면 자동으로 더 싼 모델로 강등하는 정책도 같은 표 위에서 돌릴 수 있습니다.

다만 모든 작업을 똑같이 자유롭게 바꿀 수 있는 건 아니었습니다. 여기서 솔직해야 합니다.

작업	모델 교체 자유도	이유
요약·분류·추출	높음 — 자유 교체	출력 형식이 단순해 호환성 걱정이 적다
에이전트 대화	중간 — 후보 제한	도구 호출 형식이 모델마다 달라 호환 모델로만 좁힌다
임베딩 검색	낮음 — 사실상 고정	제공자를 바꾸면 전체 문서를 다시 색인해야 한다

자유와 제약을 작업 단위로 다르게 둔 것이 핵심이었습니다. “전부 자유롭게 교체 가능”은 거짓말이고, “전부 고정”은 벤더 종속입니다. 그 사이에서 작업마다 선을 다르게 그었습니다. 키는 코드가 아니라 환경설정과 암호화된 저장소로 분리해, 코드에는 어떤 비밀도 남기지 않았습니다.

교훈

LLM 도입의 첫 질문은 “어떤 모델?”이 아니라 **“모델 선택을 어디에 두는가?”**입니다. 모델을 코드에 박으면 한 벤더에 종속되고, 작업마다 최적 모델이 다르다는 현실도 담지 못합니다. 작업(capability)을 단위로 라우팅 표를 만들고, 그 표가 실제 호출을 통제하는지 왕복으로 검증하세요(되는 척하는 표가 가장 흔한 함정입니다). 작업마다 교체 자유도를 다르게 두되, 비싼 모델은 꼭 필요한 곳에만. 그래야 모델은 언제든 갈아 끼울 수 있는 부품이 되고, 회사는 한 회사의 인질이 되지 않습니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.