여름 들어 DeepSeek 얘기가 여기저기서 계속 올라오길래 한번 진지하게 붙여봤다. DeepSeek-V3(2024년 12월말 공개)와 DeepSeek-R1(2025년 1월 공개) 이후 내부 AI 플랫폼 설계에서 GPT-4o/Claude 3.5 Sonnet을 밀어낼 수 있는가 관점에서 보는 사람들이 많아서, 직접 PoC 돌려본 결과를 정리. RAG 파이프라인에 붙여서 현업 문서 질의에 사용하는 패턴이 목표였다.
DeepSeek을 보는 관점
DeepSeek이 주목받는 이유는 세 가지다.
- 가격. V3 기준 input $0.27/1M tok, output $1.10/1M tok. GPT-4o(input $2.5, output $10)의 1/10 수준. R1도 유사.
- 성능. 벤치에서 GPT-4o/Claude 3.5 Sonnet에 근접. 영어 코딩 bench, 수학 bench(MATH, AIME)에서는 경쟁력 강함. 한국어는 약간 처짐.
- 오픈 가중치. V3는 671B MoE(활성 37B) 가중치가 공개. 자체 서빙도 가능(H800 급 노드 다수 필요).
내가 개인적으로 가장 관심있던 건 2번과 3번의 조합이다. 내부 데이터가 밖으로 나가면 안 되는 조직에서 "온프렘/자체 호스팅"이 가능한 준-frontier 모델이 필요했고, Llama 3 시리즈보다 DeepSeek이 코딩/RAG 답변 품질에서 앞선다는 내부 소견이 여럿 있었다.
아키텍처 (MoE)
DeepSeek-V3는 Mixture-of-Experts 아키텍처다. Transformer block 안의 FFN layer를 여러 "expert" 서브 네트워크로 쪼개고, 각 토큰마다 router가 소수(보통 8개)의 expert만 활성화. 총 파라미터는 671B이지만 한 토큰이 거치는 실제 연산은 37B 수준이라 같은 총 용량 대비 추론 cost가 훨씬 낮다.
MoE의 대가는 메모리. GPU VRAM에 전체 expert가 올라가 있어야 해서 671B × 8bit만 해도 ~671GB VRAM이 필요. H800 80GB × 8 노드 정도가 최소. 자체 호스팅이 비싼 이유.
내부 RAG 구성
DeepSeek API + 자체 RAG 파이프라인의 현재 구조.
[User query]
│
▼
[Query rewriter (LLM)]
│
▼
┌───────────────────────────────┐
│ 1) Dense retrieve (bge-m3) │
│ 2) BM25 sparse (opensearch) │
└───────────────────────────────┘
│
▼
[Reciprocal Rank Fusion]
│
▼
[Cross-encoder rerank]
│
▼
[Context building (top 8)]
│
▼
[DeepSeek-V3 / R1 (answer + citation)]
│
▼
[Answer]
핵심 선택:
- Hybrid retrieval (dense + sparse). 도메인 용어가 들어간 쿼리는 BM25가 잘 잡고, 의미 기반 질의는 dense가 좋다. 둘 합치면 recall이 체감 10~15%p 올라간다.
- bge-m3(embedding). 다국어 + 8K 토큰 컨텍스트 지원. 한국어/영어 혼용 문서에 강하다.
- Cross-encoder rerank. bge-reranker-v2-m3로 top 50 → top 8 재정렬. 응답 품질에 가장 큰 영향.
- citation. 프롬프트에 "각 주장 뒤에 [chunk_id] 형태로 인용 표시"를 강제. 내부 감사/검증이 편함.
프롬프트 설계
SYSTEM = """
당신은 사내 문서 Q&A 어시스턴트다.
규칙:
1) 제공된 context 밖의 지식으로 답하지 말 것. 모르는 건 '제공된 문서에서 찾을 수 없음'이라 말할 것.
2) 답변 문장 말미에 근거 chunk id를 [c:12, c:17] 형태로 표기.
3) 숫자/날짜는 context에 있는 값만 그대로 쓸 것. 임의 추정 금지.
4) 한국어 질문엔 한국어로, 영어 질문엔 영어로.
"""
USER = f"""
[context]
{context_chunks_with_ids}
[question]
{user_query}
"""
규칙 1(hallucination 방지)은 프롬프트만으로 완벽하진 않지만, 이 한 줄 유무로 "모르는 걸 지어내는" 빈도가 확실히 달라진다. R1의 경우 Chain-of-Thought가 기본으로 흘러나와서 답변이 장황해지기 쉽다. 사내 문서 QA에선 답을 간결하게 요구하는 게 맞아서 <think> 블록을 후처리로 제거.
pandas/DataFrame 결합 질의
현업에서 "지난 분기 매출 추이"나 "거래처 별 상위 SKU" 같은 구조화 데이터 질의가 많아서 RAG만으로는 부족하다. 두 가지 패턴을 병행.
- SQL agent. DeepSeek에게 스키마 DDL과 질문을 주고 SQL을 생성하게 함. 생성된 SQL을 read-only DB에서 실행하고 결과를 다시 요약.
- pandas agent. 이미 DataFrame으로 관리되는 보고서는 pandas query를 생성. LangChain의 create_pandas_dataframe_agent 비슷한 식이지만, 실제 실행은 sandbox(pyodide 또는 restrictedpython)에서.
둘 다 보안이 핵심. 생성된 쿼리/코드를 그대로 실행하면 SQL injection 유사 위험. read-only user + row-level 권한 + sandbox는 기본.
# DeepSeek으로 SQL 생성
import openai # DeepSeek API는 OpenAI SDK 호환
client = openai.OpenAI(
api_key=DS_KEY,
base_url="https://api.deepseek.com/v1",
)
schema_ddl = load_ddl("sales")
resp = client.chat.completions.create(
model="deepseek-chat", # v3
messages=[
{"role":"system","content": f"주어진 DDL에서 유효한 SQL만 생성. SELECT만. DDL:\n{schema_ddl}"},
{"role":"user","content": question},
],
temperature=0,
)
sql = extract_sql(resp.choices[0].message.content)
validate_read_only(sql) # DDL 체크 + LIMIT 강제
rows = db.execute_readonly(sql)
성능 체감 (내 환경)
- RAG QA 품질: GPT-4o와 비교할 만. 한국어 전문용어(관세, HS코드 등) 해석은 GPT-4o가 조금 더 부드러움.
- SQL 생성: 단순 쿼리는 동등. JOIN 3개 넘고 서브쿼리 들어가면 DeepSeek이 실수 확률이 조금 높음.
- 수학/논리: R1이 강함. 수치 계산 포함된 질의에는 V3보다 R1이 정확.
- latency: API 기준 V3 평균 1.5~2.5초, R1은 reasoning 때문에 4~8초. streaming 켜는 게 UX상 필수.
운영에서 걸린 것들
1) API rate limit. 초기 토크너스 per minute가 비교적 낮게 잡혀있다. 동시 요청 수가 많은 내부 도구라면 pool + queue 설계 필요.
2) API 안정성. 지난 겨울 한 번 1시간 다운. GPT/Claude에 비해 가용성 SLA가 덜 성숙. Multi-provider fallback(예: OpenRouter, Together)을 붙이는 게 안전하다.
3) 데이터 소재지. DeepSeek API는 중국 본토에서 운영. 국내 조직의 개인정보/영업비밀 데이터를 보낼 수 있는지 법무 검토 필수. 어떤 조직은 "내부 문서 절대 반출 금지"라 결국 자체 호스팅으로 가야 했다.
4) 자체 호스팅 비용. H800 8장짜리 노드 기준 월 수천만원. 트래픽 적으면 비효율. 일정 규모 이상일 때만 의미 있다.
비용 계산 예시
하루 10만 질의, 평균 input 4,000 토큰(RAG context 포함), output 300 토큰이라 가정.
- GPT-4o: input $2.5 × 400M = $1000, output $10 × 30M = $300. 하루 $1,300.
- DeepSeek V3: input $0.27 × 400M = $108, output $1.10 × 30M = $33. 하루 $141.
한 달이면 $39,000 vs $4,200. 결코 무시할 수 없는 차이. 품질이 95% 수준이면 대부분의 내부 워크로드엔 DeepSeek이 합리적 선택.
하이브리드 라우팅
결국 내가 정착한 구조는 질문 난이도에 따라 라우팅. 단순 조회/요약은 DeepSeek V3, 복잡한 추론(법률 해석, 다중 조건 수치 분석)은 R1 또는 Claude 3.5 Sonnet. 앞단에 작은 분류 모델(사실 프롬프트로 3단 분류하는 작은 LLM)을 두고, cost/품질 trade-off를 자동 최적화.
결론
DeepSeek은 준-frontier 성능을 1/10 가격으로 가져다주는 실제 옵션이 됐다. 내부 AI 플랫폼을 새로 설계하는 조직이라면 반드시 PoC 해볼 만한 선택지. 단, 데이터 반출/법무 검토는 선행 필수이고, GPT/Claude만큼 인프라 안정성이 검증되진 않아 fallback은 마련해야 한다. 로컬 호스팅은 현재 시점에서 H급 GPU 8장 규모부터 의미있다. 국내 중소기업 환경에선 API 경로가 더 현실적이고, 중요한 문서는 필터링해서 API에 보내는 하이브리드가 최선의 타협이라고 본다.
다음 단계로는 DeepSeek-R1을 RAG 쪽 reranker로 두고, 최종 답변은 V3에게 맡기는 조합을 실험 중. reasoning 깊이는 R1, 출력 속도는 V3로. 결과 나오면 한 번 더 쓸 것이다.
