오픈소스 vs 폐쇄형 AI 스택, LLM부터 앱까지 어떤 조합이 답일까?

AI 챗봇이든, 복잡한 에이전트 시스템이든, 지금 시점에서는 처음부터 끝까지 오픈소스로만 AI 서비스를 구성하는 것도 충분히 가능합니다.

반대로, 모델부터 애플리케이션까지 대부분을 API 기반 폐쇄형 서비스에 의존하는 구성도 흔합니다.

이 글에서는 AI 스택을 네 계층(모델, 데이터, 오케스트레이션, 애플리케이션)으로 쪼개어, 각 계층에서 오픈소스와 폐쇄형 선택이 개발 경험과 운영 방식에 어떤 차이를 만드는지를 정리합니다.

AI 스택 구조 이해: 모델·데이터·오케스트레이션·애플리케이션

AI 제품을 설계할 때, 한 덩어리로 보이면 선택지가 단순해 보이지만, 실제로는 레이어별로 전혀 다른 의사결정을 해야 하는 구조입니다.

여기서 다루는 스택은 크게 네 단계를 포함합니다.

• 모델(Model): LLM, 특화 모델, 추론 엔진

• 데이터(Data): 커넥터, 포맷 변환, RAG 파이프라인, 벡터 DB

• 오케스트레이션(Orchestration): 에이전트, 도구 호출, 루프, 플로우 제어

• 애플리케이션(Application): 사용자가 실제로 만나는 UI/UX

흥미로운 점은, 코드 관점의 오픈소스/폐쇄형 구분은 모델·오케스트레이션·애플리케이션 레이어에서 더 크게 작동하고, 데이터 레이어에서는 구현 방식보다 배치 위치와 통제권이 더 중요한 이슈가 된다는 점입니다.

또 하나 짚고 넘어갈 지점이 있습니다. 하버드 비즈니스 스쿨 연구에 따르면, 공개된 소스 코드로 자유롭게 배포되는 오픈소스 소프트웨어의 경제적 가치는 약 8.8조 달러 수준으로 추정됩니다.

AI에서도 비슷한 현상이 반복됩니다. 상용 AI 도구에서 나오는 새로운 기능 상당수가 곧바로 오픈소스 구현으로 재현되고, 전 세계 커뮤니티에 무료로 공유됩니다. 이 숫자와 흐름을 고려하면, AI 스택에서 오픈소스를 완전히 배제하는 전략은 점점 설득력이 떨어지는 방향으로 가고 있습니다.

LLM 선택: 오픈소스 모델 vs API 기반 폐쇄형 모델

AI 스택의 중심에는 거의 항상 모델이 있습니다. 특히 LLM이 차지하는 비중이 매우 큽니다.

오픈소스 측면에서 보면, 크게 두 종류가 있습니다.

• 기저 LLM(Base LLM): 범용 데이터로 학습된 기본 모델

• 파인 튜닝 LLM: 커뮤니티가 특정 작업이나 도메인에 맞게 추가 학습시킨 모델

예를 들어, 질문·답변(QA)에 최적화된 모델, 법률 문서에 특화된 모델처럼 목적이 분명한 버전들이 이미 광범위하게 공개돼 있습니다. 또한 LLM 외에도 바이오메디컬 이미지 이상 탐지처럼 특정 업무만 잘하는 특화 모델도 다수 존재합니다.

오픈소스 모델을 선택하면, 곧바로 마주치는 주제가 추론(inference)을 어디서 어떻게 돌릴 것인가입니다.

• 로컬 실행: 노트북이나 데스크톱에서 돌리는 방식

  • 대표 도구: Ollama

• 서버/클러스터 추론 엔진: 다수 요청을 처리할 수 있는 서버 측 실행

  • 대표 도구: vLLM, TensorRT-LLM 등

이 경우, 모델 최적화, 배치 전략, 성능 튜닝, 리소스 관리까지 직접 신경 써야 합니다. 대신, 모델 내부가 열려 있으므로 파라미터 교체, 커스텀 파인 튜닝, 프라이버시 제약에 맞춘 온프레미스 배포 같은 높은 수준의 통제권을 확보할 수 있습니다.

반면, 폐쇄형 모델은 대부분 API 호출만 하면 되는 형태로 제공됩니다.

• 추론 엔진, 최적화, 인프라, 확장성 등은 제공사가 관리

• 개발자는 프롬프트 설계, 파라미터 설정, 응답 후처리에 집중

이 방식은 초기 생산성을 극대화하고 운영 복잡도를 줄여 줍니다. 그 대신 모델 버전, 세부 동작, 배포 위치, 비용 구조에 대한 통제권은 크게 줄어듭니다.

결국 모델 레이어에서는,

• 오픈소스: 통제·커스터마이징·온프레미스

• 폐쇄형: 단순성·관리 최소화·높은 초기 품질

사이의 교환 관계를 전제로 설계 방향을 잡게 됩니다.

데이터 계층: 커넥터·RAG·벡터 DB에서 오픈소스가 주는 선택지

데이터 레이어는 흥미롭게도, 오픈소스와 폐쇄형의 구성 요소 자체는 거의 비슷합니다. 다른 점은 코드 공개 여부와 배포·통제 방식입니다.

일반적인 구성 요소는 다음과 같은 흐름으로 이어집니다.

1. 데이터 소스 연결

   • SaaS, 내부 DB, 파일 시스템, 문서 저장소 등에서 데이터 커넥터로 데이터 수집

2. 데이터 변환

   • PDF, 이메일, 슬랙 메시지 같은 비정형 데이터를

   • LLM이 활용하기 좋은 구조화된 텍스트나 청크(Chunk)로 변환

3. RAG 파이프라인 및 벡터 DB

   • 텍스트를 임베딩(embedding)으로 벡터화

   • 벡터 DB에 저장 후, 질의 시 의미 기반 검색으로 컨텍스트를 가져오는 RAG(Retrieval-Augmented Generation) 구성

이 세 단계는 오픈소스든 폐쇄형이든 개념적으로 동일한 역할을 수행합니다. 그러나 선택 기준은 달라집니다.

• 비용

  • 오픈소스: 코드 자체는 무료인 경우가 많지만, 인프라·운영·인력 비용이 뒤따릅니다.

  • 폐쇄형: 기능은 통합되어 있지만, 사용량 기반 과금·구독 비용이 발생합니다.

• 커스터마이징

  • 오픈소스: 소스 코드에 접근 가능하므로 스키마, 파이프라인, 인덱싱 전략을 세밀하게 변경 가능

  • 폐쇄형: 이미 잘 정리된 기능을 제공하지만, 지원하지 않는 패턴은 사실상 못 한다고 보는 편이 안전

• 배포 위치와 데이터 통제

  • 오픈소스: 코드가 손에 있기 때문에 온프레미스, 프라이빗 클라우드, 퍼블릭 클라우드 어디든 배포 가능

  • 폐쇄형: 대부분 SaaS 혹은 완전 관리형 API로 제공되므로, 데이터가 어디를 거쳐 가는지에 대한 제약과 정책 검토가 필요

대부분의 기업·조직에서는 규제, 컴플라이언스, 데이터 민감도에 따라 데이터 레이어에서 오픈소스 비중을 높이거나 낮추게 됩니다. 민감한 사내 문서를 RAG에 연결하는 경우, 이 레이어를 어떻게 구성할지에 따라 프로젝트 전체의 허용 가능성이 달라지는 경우가 많습니다.

에이전트와 오케스트레이션: 오픈소스 프레임워크 vs 관리형 플랫폼

모델과 데이터가 준비되면, 이제 무엇을 언제 어떻게 하게 만들지를 설계하는 단계가 온다. 이 부분을 오케스트레이션 혹은 에이전트 레이어로 볼 수 있습니다.

여기서 다루는 기능은 보통 다음 요소를 포함합니다.

• 문제 분해와 계획: 복잡한 요구를 여러 서브태스크로 나누는 로직

• 도구·함수 호출: API 호출, DB 질의, 파일 조작 등 외부 도구 사용

• 루프와 피드백: 중간 결과를 검토하고, 필요하면 추가 시도나 수정 수행

오픈소스 진영에는 다양한 에이전트/워크플로 프레임워크들이 존재합니다. 이들을 활용하면,

• 태스크 그래프를 세밀하게 설계하거나

• 도구 호출 규칙을 커스터마이징하고

• 반복 루프와 검증 단계를 세밀하게 조정하는 구성이 가능합니다.

장점은 구조를 원하는 대로 설계할 수 있다는 점이고, 단점은 직접 설계하고 유지해야 할 로직이 많아진다는 점입니다.

한편 폐쇄형 스택에서는, 상용 플랫폼이 제공하는 에이전트 기능을 API 한 번으로 사용하는 방식이 많습니다.

• 특정 JSON 스펙에 맞춰 요청을 보내면

• 플랫폼 내부에서 계획 수립, 도구 호출, 반복 등 에이전트 기능을 알아서 수행

이 방식은 도입이 빠르고, 복잡한 에이전트 로직을 일일이 설계하지 않아도 되지만,

• 세부 동작을 변경할 수 있는 여지가 제한되고

• 문제 원인을 분석하거나 디버깅할 때 내부 흐름을 충분히 들여다보기 어렵다는 점이 부담으로 작용할 수 있습니다.

정리하면, 에이전트 레이어에서의 선택은

• 유연성과 가시성(오픈소스)

• 간편성과 추상화 수준(폐쇄형)

사이에 놓인 문제이며, 어느 쪽이 낫다기보다 어느 쪽을 감당할지의 문제에 가깝습니다.

애플리케이션 레이어: 오픈소스 UI 도구 vs 직접 임베딩

AI 모델과 에이전트가 준비되면, 이제 실제 사용자가 만나는 애플리케이션 층을 설계해야 합니다. 이 레이어의 선택은 개발 속도와 제품 완성도에 직접적인 영향을 줍니다.

오픈소스 진영에서는 두 가지 방향이 눈에 띕니다.

첫 번째는 높은 수준의 커스터마이징을 노린 솔루션입니다.

• 예: Open WebUI, AnythingLLM 등 이류 도구를 사용하면,

• 챗 UI, 세션 관리, 프롬프트 프리셋, 사용자별 설정 등을 직접 설계하면서도

• 기본적인 프레임워크는 이미 갖춰진 상태에서 출발할 수 있습니다.

두 번째는 빠른 프로토타이핑에 초점을 맞춘 도구입니다.

• 예: Gradio, Streamlit 이들은 복잡한 프론트엔드 개발 없이도,

• 몇 줄의 파이썬 코드로 웹 기반 UI를 만들고

• LLM 혹은 AI 백엔드에 바로 연결하는 구성을 지원합니다.

폐쇄형 스택을 중심으로 할 경우, 애플리케이션 레이어는 보통 기존 웹/모바일 앱에 AI 기능을 직접 임베딩하는 방식으로 접근하게 됩니다.

• API 호출을 백엔드 혹은 프론트엔드 코드에 직접 통합

• 인증·과금·로깅 등을 기존 시스템과 자연스럽게 연결

이 구조는 자체 제품 안에 AI를 자연스럽게 녹여 넣기 위한 선택에 가깝고, 오픈소스 UI 도구는 독립된 AI 콘솔 혹은 관리자/운영용 인터페이스에 더 적합한 경우가 많습니다.

오픈소스와 폐쇄형 AI 스택 조합에 대한 현실적인 관점

마지막으로, 원본 자료에서 제시된 내용을 한 단계 떨어진 관점에서 정리해 보면, 몇 가지 인상이 분명하게 드러납니다.

첫째, 모든 레이어를 오픈소스로만 구성하는 것은 기술적으로 가능하지만, 실제로는 조합형 접근이 더 현실적입니다.

• 모델: 규제·보안 이슈가 크다면 오픈소스 + 온프레미스, 그렇지 않다면 고성능 API 모델

• 데이터: 민감도에 따라 RAG·벡터DB는 자체 운영, 커넥터는 상용 도구 혼용

• 오케스트레이션: 핵심 로직은 오픈소스 프레임워크, 부가적 워크플로는 상용 플랫폼 활용

• 애플리케이션: 사용자 앱은 직접 임베딩, 내부 운영 도구는 Gradio/Streamlit 계열

둘째, 오픈소스를 선택하면 '무료' 대신 '책임'을 얻게 된다는 점이 특히 강조될 필요가 있습니다. 코드는 무료지만,

• 추론 인프라 비용

• 모니터링·로깅·업데이트

• 내부 역량 구축과 유지

이 전부를 감당해야 하므로, 장기적으로는 총소유비용(TCO) 관점에서 평가해야 합니다.

셋째, 폐쇄형 스택은 여전히 초기 품질과 운영 편의성 면에서 강한 선택지입니다. 그러나

• 데이터 이동 경로가 명확히 통제돼야 하는 환경

• 모델·오케스트레이션의 동작 원리에 대한 가시성이 중요한 환경

에서는 제약이 커질 수밖에 없습니다.

마지막으로, 하버드에서 추산한 8.8조 달러 규모의 오픈소스 가치는 단순한 숫자를 넘어, AI 스택 설계에서 커뮤니티 기반 도구를 기본 옵션으로 검토해야 하는 시대에 들어섰다는 신호로 볼 수 있습니다.

AI 서비스를 설계하는 입장에서는,

• 전 레이어를 둘 다 이해한 뒤

• 레이어별로 어디까지 통제할지, 어디부터 위임할지를 명확히 나누는 전략이 필요해 보입니다.

이 관점에서 보면, 오픈소스 vs 폐쇄형은 어느 한쪽을 선택하는 문제가 아니라, "어디까지를 직접 책임질 것인가"에 대한 조직의 의사결정에 가깝다는 점이 분명해집니다.

출처 및 참고 :