← 모든 글

오픈소스 LLM 을 더 깊게 들여다본 한 달

상용 LLM API 대신 오픈소스 모델을 직접 운영해보면서 느낀 현실적인 한계와 가능성, 그리고 우리가 내린 판단을 기록한다.

시작한 이유

상용 LLM API에 대한 의존도가 높아지면서 두 가지 고민이 생겼다. 하나는 비용이고, 다른 하나는 데이터 유출 가능성이었다. 운영 중인 서비스에서 민감한 데이터를 외부 API에 보내는 것에 대한 불확실성이 있었다.

그래서 한 달 동안 오픈소스 모델을 로컬 또는 자체 서버에서 운영하면서 실제로 쓸 수 있는지를 직접 테스트했다.

테스트한 것들

우리가 실제로 필요한 기능은 크게 세 가지였다. 텍스트 요약, 구조화된 데이터 추출, 코드 생성 보조. 각 용도에 맞는 오픈소스 모델을 선택해 동일한 입력으로 상용 API와 비교했다.

모델 서빙은 ollamavllm을 각각 시도했다. ollama는 설치와 실행이 단순하다는 장점이 있었고, vllm은 처리량이 높을 때 더 안정적이었다.

발견한 현실

성능 격차는 분명히 존재한다. 특히 복잡한 지시를 따르거나 긴 컨텍스트를 처리하는 능력에서 차이가 났다. 단순한 작업에서는 체감이 크지 않았지만, 조금만 복잡해져도 출력 품질이 떨어졌다.

인프라 부담이 생각보다 크다. GPU 서버를 운영하거나 임대하는 비용, 모델 버전 관리, 서빙 스택 유지보수까지 포함하면 순수 API 호출 비용과 비교가 필요하다. 단순히 API 단가만 비교하면 잘못된 결론이 나온다.

지연 시간 문제: 자체 서버에서 소형 모델을 쓰면 응답이 빠를 수 있다. 하지만 네트워크 지연이 없는 로컬 환경이 아니라면 상용 API가 더 빠른 경우도 많았다.

결론적으로 선택한 방향

우리는 하이브리드 방식을 선택했다. 민감한 데이터나 내부 업무 자동화에는 로컬 모델을 사용하고, 사용자 대면 기능에서는 상용 API를 유지한다. 두 가지를 추상화 레이어로 감싸서 나중에 교체가 용이하도록 했다.

오픈소스 LLM이 상용을 완전히 대체할 수 있는 수준에 도달했다고 보기는 어렵다. 그러나 특정 용도에서는 이미 충분하고, 발전 속도를 고려하면 방향 자체는 맞다.

작은 팀에 주는 시사점

LLM을 실무에 도입하려는 소규모 팀이라면, “지금 당장 상용 API가 더 빠르게 결과를 낸다”는 점을 솔직하게 인정하는 것이 출발점이라고 생각한다. 오픈소스를 선택해야 한다면 그 이유가 명확해야 한다. 비용, 데이터 프라이버시, 커스터마이징 요구 중 어느 것인지.

— by slecs