필사 모드: 지금 주목받는 오픈소스 (1) AI 에이전트와 LLM 도구

• 들어가며 — 한 덩어리였던 스택이 층으로 갈라졌다
• 스냅숏
• 1층 — 모델을 실제로 돌리는 곳
• 2층 — 제공자를 추상화하는 게이트웨이
• 3층 — 오케스트레이션과 RAG
• 4층 — 에이전트
• 인터페이스 — 라이선스를 꼭 보고 쓰세요
• 도입 전 확인
• 링크

들어가며 — 한 덩어리였던 스택이 층으로 갈라졌다

2023년에 LLM 애플리케이션을 만든다는 말은 프레임워크 하나 골라 API 키 꽂고 체인을 엮는 것이었습니다.

지금은 모델을 어디서 돌릴지, 여러 제공자를 어떻게 한 인터페이스 뒤에 둘지, 검색을 붙일지, 에이전트에게 도구를 얼마나 줄지가 전부 별개의 결정입니다. 결정마다 다른 프로젝트가 자리를 잡았습니다.

아래 목록은 순위가 아닙니다. 역할별로 묶은 지도이고, 같은 층 안의 프로젝트끼리만 실제로 경쟁 관계입니다.

스냅숏

모두 2026-08-12 기준입니다.

1층 — 모델을 실제로 돌리는 곳

ggml-org/llama.cpp는 GGUF 양자화 모델을 CPU와 소비자용 GPU에서 돌리는 C++ 추론 엔진입니다. 위 계층 상당수가 이 프로젝트나 그 파생물 위에 서 있습니다. 저장소가 개인 계정에서 조직 계정으로 옮겨졌으니 오래된 문서의 경로를 그대로 믿지 마세요. GPU 여러 장으로 대규모 동시 요청을 받는 용도는 아닙니다.

ollama/ollama는 그 위에 모델 배포와 수명 주기를 얹어 로컬 실행을 한 줄로 줄였습니다. OpenAI 호환 엔드포인트가 있어 기존 클라이언트 코드를 거의 그대로 붙입니다. 개발 환경과 개인 워크스테이션에는 맞지만 멀티테넌트 프로덕션 서빙을 겨냥한 물건은 아닙니다.

# 예시: 로컬에서 띄우고 OpenAI 호환 경로로 호출
ollama serve &
ollama pull <model-name>
curl http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"<model-name>","messages":[{"role":"user","content":"ping"}]}'

vllm-project/vllm은 반대쪽 끝입니다. PagedAttention과 연속 배칭으로 GPU 처리량을 끌어올리는 서빙 엔진이고, 자체 호스팅 추론의 사실상 기본값에 가장 가깝습니다. 대신 GPU와 드라이버 조합에 민감하고 메모리 튜닝이 필요해, 하루 수백 건 규모라면 과합니다.

sgl-project/sglang은 접두사 캐시 재사용(RadixAttention)에 초점을 맞춰 프롬프트 앞부분이 반복되는 워크로드에서 이점이 큽니다. 2024년 1월에 생긴 젊은 저장소라 운영 경험은 vLLM 쪽이 더 두껍습니다.

2층 — 제공자를 추상화하는 게이트웨이

BerriAI/litellm은 수많은 모델 제공자를 OpenAI 형식 하나로 통일하고, 프록시 모드에서 키 관리와 예산 한도, 폴백, 사용량 로깅을 담당합니다. 제공자를 바꿀 때마다 애플리케이션 코드를 고치는 일을 없애 줍니다.

라이선스는 정확히 보셔야 합니다. 저장소 LICENSE 파일은 enterprise/ 디렉터리가 그 안에 정의된 별도 라이선스를 따르고 그 밖은 MIT라고 선언합니다. 전체가 균일한 MIT가 아닙니다.

3층 — 오케스트레이션과 RAG

langchain-ai/langchain은 통합 표면이 가장 넓은 프레임워크입니다. 초기의 과도한 추상화 비판 이후 구조가 여러 차례 재편되었으니 학습 자료의 작성 시점을 반드시 확인하세요. 호출이 한두 단계뿐인 작업에 얹으면 얻는 것보다 잃는 것이 많습니다.

run-llama/llama_index는 문서 적재, 청킹, 인덱싱, 검색이라는 RAG 축에 더 집중합니다. 검색 품질을 손보는 일이 작업의 대부분이라면 이쪽이 잘 맞습니다.

infiniflow/ragflow는 라이브러리가 아니라 배포해서 쓰는 RAG 엔진이고, 표와 레이아웃이 복잡한 PDF 파싱에 무게를 둡니다. 인프라를 하나 더 운영해야 하니 팀이 작다면 부담을 먼저 계산하세요.

4층 — 에이전트

crewAIInc/crewAI는 역할을 나눈 다중 에이전트 협업을 표준 패턴으로 만들었습니다. 문제를 사람 조직처럼 쪼갤 수 있을 때 잘 맞습니다. 반대로 결정론적 결과가 필요한 파이프라인에 다중 에이전트를 넣는 것은 대개 손해입니다.

browser-use/browser-use는 LLM에게 실제 브라우저를 조작하게 해서, API가 없는 화면을 자동화하는 통로를 엽니다. 다만 저장소가 2024년 10월에 생겼고 스타가 108,900개까지 오르는 동안 인터페이스도 계속 바뀌었습니다. 신뢰성과 프롬프트 인젝션 노출 면에서 아직 조심스럽게 다뤄야 합니다.

Aider-AI/aider는 터미널에서 저장소를 편집하고 커밋까지 만드는 페어 프로그래밍 도구입니다. 활동 신호를 그대로 옮깁니다. 확인 시점의 최근 푸시는 2026-05-22로, 다른 프로젝트가 같은 날 푸시된 것과 대비됩니다. 죽었다는 뜻은 아니지만 도입 전에 최근 커밋과 이슈 응답을 직접 확인하세요.

인터페이스 — 라이선스를 꼭 보고 쓰세요

open-webui/open-webui는 로컬 모델용 채팅 UI로 널리 쓰입니다. 그런데 LICENSE 파일이 중요합니다. BSD 3조항 형태에 조항이 하나 더 붙어 있고, 그 조항은 Open WebUI 브랜딩(이름, 로고 등)의 변경이나 제거를 금지합니다. 사용 제한이 붙어 있으므로 OSI가 정의하는 오픈소스가 아니라 소스 공개 라이선스입니다.

사내 포털에 화이트라벨로 얹으려는 계획이라면 여기서 걸립니다. 예외 조건도 함께 있으니 전문을 직접 읽으세요.

도입 전 확인

라이선스 전문을 직접 확인하고, 상업적 도입은 법무 검토를 거치세요. 이 글은 법률 자문이 아닙니다.

이 영역에만 해당하는 주의도 있습니다. LLM 도구는 인터페이스가 빠르게 바뀌니 버전을 고정하고 업그레이드를 정기 예산에 넣으세요. 에이전트에 도구 실행 권한을 줄 때는 신뢰할 수 없는 입력이 그대로 명령이 되는 경로가 열린다는 점을 설계 단계에서 다루셔야 합니다.

저장소 정보(스타 수·라이선스·최근 활동)는 2026-08-12에 GitHub에서 직접 확인한 시점 값입니다. 수치와 상태는 바뀝니다.

링크

시리즈 다음 글: 지금 주목받는 오픈소스 (2) 개발자 도구

이 블로그의 관련 글:

• RAG 파이프라인과 벡터 데이터베이스 프로덕션 적용
• RAG 파이프라인 최적화 — 청킹, 리랭킹, 하이브리드 검색
• 2026년 오픈소스 라이선스 변화

도구: curl 명령 빌더 · JSON 포매터