Context Vault

Karpathy의 LiteLLM 의존성 재평가 - Golang 철학과 소프트웨어 공학

6 min read

Karpathy의 LiteLLM 의존성 재평가 - Golang 철학과 소프트웨어 공학

Classicial software engineering은 의존성이 좋은 것(벽돌을 쌓아 올리는)이라 믿지만, 이제 이것을 재평가해야 한다고 주장

LiteLLM 사건 (2026년 3월)

공격 개요

  • 대상: LiteLLM (Python 라이브러리)
  • 공격 방법: 악의 버전(v1.82.7, v1.82.8)이 PyPI에 업로드
  • 피해 사례: API 키, 클라우드 자격증명, Kubernetes 설정, Git 자격증명, 암호화된 월렛
  • 발견 원인: 악의 코드의 메모리 익스플로잇 버그

Karpathy의 평가

“최근 소프트웨어에서 가장 공포스러운 것 중 하나” – “software horror”

Karpathy의 입장 변화

이전: 의존성 숭배

Classicial software engineering에서:

  • 벽돌 쌓기: 의존성이 좋은 것
  • 복용성: 이미 증명된 라이브러리 사용
  • 개발 속도: 빠른 프로토타이핑

현재: 의존성 저항

“저는 점점 더 의존성에 저항하고 있다”

핵심 이유:

  1. SaaS 공격 가능성: 의존성 공격의 피해 범위가 넓어짐
  2. Ouroboros의 경험: LiteLLM 의존성으로 영향받았고, 빠르게 제거했지만, 이미 늦었음
  3. LLM 활용: 필요한 기능만 cherry pick하고 직접 구현 가능

Golang의 철학적 장점

1. 표준 라이브러리

구성요소설명
표준 HTTP 서버net/http
표준 JSONencoding/json
표준 테스트testing
표준 CLIflag, os

2. 외부 의존성 최소화

작업PythonGolang
HTTP 요청requestsnet/http (표준)
JSON 처리jsonencoding/json (표준)
웹 서버Flasknet/http (표준)
데이터베이스 드라이버psycopg2database/sql (표준 인터페이스)

3. import만으로 끝

Python:

# 1. 라이브러리 설치
pip install requests
pip install flask
pip install psycopg2
 
# 2. import
import requests
import flask
import psycopg2
 
# 3. 사용 → 다른 패키지도 필요

Golang:

// import만으로 끝
import "net/http"
import "encoding/json"
import "database/sql"
 
// 표준 라이브러리는 이미 Go에 내장

4. go.mod 의존성 관리

module myapp
 
go 1.21
 
require (
    github.com/example/tool v1.2.3  // 명시적 버전 지정
    github.com/openai/sdk-go v0.26.0
)

Python 생태계의 문제점

의존성 체인

내 앱 → 패키지 A → 패키지 B → 패키지 C → ...
  └─ 템스 → 다른 패키지 → ...
     └─ 테스트 → 또 다른 패키지 → ...

LiteLLM 사례:

LiteLLM → dspy (포함)
  └─ 사용자 프로젝트 → 다른 패키지 → ...
    └─ LiteLLM 한 개만 뚫렸는데 영향 범위 넓음

전염 감염

  • 단일 패키지 취약점 → 전체 생태계 영향
  • 의도치 않더라도 간접적으로 노출
  • 패치 릴리스 후에도 장기간 영향 지속

새로운 패러다임: LLM-First

Karpathy의 제안

“LLM을 이용해서 필요한 기능만 cherry pick하고 의존성을 줄이는 게 맞다”

LLM의 장점

작업전통적 방법LLM 활용
HTTP 요청requests 설치LLM이 직접 구현 가능
데이터베이스 드라이버psycopg2LLM이 SQL 생성 가능
파싱 라이브러리beautifulsoup4LLM이 regex/파싱 가능
복잡한 로직여러 패키지LLM이 한 번에 처리 가능

예시: LiteLLM 기능 재구현

기존 방법:

import litellm
# 36개 LLM 제공자 지원
# LiteLLM의 캐싱, 로깅, 실패 처리 모두 사용

LLM-First 방법:

import http  # 표준 라이브러리
import json   # 표준 라이브러리
 
# OpenAI API 직접 호출
def call_openai(prompt: str) -> str:
    response = http.post("https://api.openai.com/v1/chat", {
        "model": "gpt-4",
        "messages": [{"role": "user", "content": prompt}]
    })
    return json.loads(response.text)

Go 모듈 관리 모범 사례

1. 의존성 최소화

# 사용하지 않는 패키지 제거
go mod tidy
 
# vendor 폴더 (선택 사항)
go mod vendor

2. 버전 고정

require (
    github.com/example/tool v1.2.3  # 명시적 버전
    github.com/another/tool v2.1.0   # @latest 금지
)

3. 보안 검증

# go.sum 무결성성 검증
go mod verify
 
# CVE 스캔
govulncheck ./...

Karpathy의 프로젝트

llm.c / llm.go

  • 언어: Python (llm.c) / Go (llm.go)
  • 목적: 최소한의 LLM 트레이닝 및 추론
  • 의존성: 거의 0에 가까움

Ouroboros의 의존성

  • LiteLLM 제거 전: 빠르게 의존성 제거
  • LiteLLM 제거 후: 새로운 표준 라이브러리로 재구현

결론

Golang의 철학적 우위

  1. 표준화된 생태계 — HTTP, JSON, 테스트 모두 표준
  2. 외부 의존성 최소화 — go.mod로 체계적 관리
  3. 재현성 — go.sum으로 빌드 재현 보장
  4. 보안 — 표준 라이브러리는 더 많은 코드 리뷰 받음

새로운 방법론

의존성 피라미드 → LLM-First 패러다임

  • 필요한 기능만 cherry pick
  • LLM으로 직접 구현
  • 의존성 공격 영향 최소화

관련 자료

Added: 2026-03-31

그래프 뷰