오픈소스 LLM 을 우리는 왜 안 쓰는가

왜 결제·정산 현장에서 이 선택이 더 예민한가

"오픈소스 LLM 써보는 거 어때요?" 이 질문을 팀 안팎에서 여러 번 받았다. 표면적으로는 합리적인 제안이다. 데이터를 외부 서버로 내보내지 않아도 되고, 비용 구조를 직접 통제할 수 있고, 도메인 특화 파인튜닝도 가능하다. 오픈소스를 지지하는 논리 자체가 틀렸다고 생각하지 않는다. 다만 우리가 다루는 영역이 결제·정산·자동화라는 점에서, 이 선택지는 다른 업종보다 훨씬 엄격하게 따져야 한다.

정산 자동화를 한 문장으로 정의하면 이렇다. 날마다 PG사·카드사·가맹점 데이터를 매핑하고, 수수료 로직을 적용하고, 오차를 잡아내는 일이다. 우리 파이프라인에서 LLM이 개입하는 지점은 주로 두 가지다. 첫째, 복잡한 정산 규칙을 코드로 변환하거나 설명하는 것. 둘째, 이상 건을 분류하고 원인을 서술하는 것. 이 두 태스크 모두 오답의 비용이 크다. 오분류된 정산 건 하나가 수십만 원짜리 클레임으로 이어질 수 있고, 잘못 생성된 코드는 배포 전까지 발견되지 않으면 실제 정산 결과에 직접 영향을 준다. 일반적인 정보 검색이나 요약 태스크와 달리, 오답을 용인할 수 있는 품질 마진이 매우 좁다. 이 전제 아래에서 LLM 도입 결정을 내려야 한다.

GPU 비용 계산: "쓸 만한 모델"의 실제 가격표

오픈소스 LLM을 도입하는 가장 현실적인 시나리오는 클라우드 GPU 인스턴스를 직접 운영하는 것이다. Llama 3 70B 수준 — 우리가 사용하는 태스크에서 쓸 만한 품질이 나오는 최소 라인이라고 봤을 때 — 은 FP16 기준 4×A100 80GB GPU가 필요하다. AWS p4d.24xlarge 온디맨드 가격은 시간당 약 32달러, 월 720시간 상시 운영하면 약 23,000달러(약 3,100만 원)다. 1년 Reserved 약정으로 약 11,000달러(약 1,500만 원)까지 내려가지만, 이건 3인 팀이 1년치를 선불로 묶는 결정이다. 트래픽이 없는 새벽에도 인스턴스는 돌고 있고, 운영·모니터링은 누군가가 챙겨야 한다.

반면 우리가 현재 쓰는 클로즈드 API 비용은 어떤가. 내부 자동화 파이프라인, 코드 리뷰 보조, 정산 이상 건 분류 등 전 용도 합산 기준으로 월 청구액은 100~~300만 원 수준이다. GPU Reserved 고정비와 비교하면 5~~15배 차이가 난다. 물론 API 비용은 호출량에 따라 선형으로 늘고, GPU는 고정비라는 구조적 차이가 있다. 이 차이를 감안해 손익분기를 역산하면, 현재 우리 사용 패턴에서 GPU가 유리해지려면 월 API 비용이 지금의 7~10배 — 최소 700만 원 이상 — 가 돼야 한다. 그 시점에는 팀 구조와 운영 방식 자체가 달라져 있을 가능성이 높다.

품질 격차: 벤치마크와 실제 사이의 거리

"오픈소스가 GPT-4 급에 근접했다"는 말은 사실이다. 하지만 벤치마크는 균등하게 설계된 테스트 분포에서의 정확도를 측정하지, 우리의 실제 입력 분포를 반영하지 않는다. 오픈소스 모델과 클로즈드 최상위 모델 간의 격차는 표준 단답형 태스크에서는 빠르게 줄고 있다. 반면 긴 컨텍스트를 요구하는 복합 추론에서는 2026년 현재에도 체감 차이가 남아 있다.

우리 팀이 LLM에 던지는 질문은 이런 형태다. "이 정산 명세서에서 수수료 계산 기준이 전월과 달라진 이유를 설명하고, 해당 변경이 코드 어느 부분에 영향을 주는지 찾아줘." 긴 명세서 테이블, 코드 스니펫, 정책 문서를 동시에 이해한 뒤 인과 관계를 추론하는 태스크다. 오픈소스 70B 모델과 클로즈드 모델을 동일 입력으로 비교 테스트했을 때 체감 차이는 벤치마크 수치보다 훨씬 컸다. 오픈소스 모델은 명세서 수치를 읽었지만 코드와 연결하는 추론 단계에서 헛돌거나, 없는 함수명을 생성하거나, 핵심 인과 고리를 생략했다. 틀린 답이 나왔을 때 이를 잡아내려면 결국 사람이 검수해야 하고, 그 검수 비용이 "저렴한 GPU 비용"을 상쇄한다. 인프라 비용보다 인건비가 더 비싼 작은 팀에서 이 함정은 치명적이다.

파인튜닝과 데이터 보안: 장점은 맞지만 지금은 아니다

"오픈소스면 우리 도메인에 맞게 파인튜닝할 수 있잖아요"는 가장 흔한 반론이다. LoRA 같은 방법으로 비교적 가볍게 할 수 있다는 것도 안다. 문제는 파인튜닝이 '한 번 하고 끝나는 프로젝트'가 아니라 '계속 돌아야 하는 파이프라인'이라는 점이다. 비용 구조를 순서대로 나열하면 이렇다. 학습 데이터 정제·라벨링(1차), 학습 실행과 평가(2차), 배포 및 버전 관리(3차). 그리고 가장 과소평가되는 비용 — 베이스 모델이 업데이트되거나, 우리 정산 로직이 개편되거나, 외부 규제가 바뀔 때마다 이 전 과정을 반복해야 한다는 것이다. 결제·정산 영역에서 이런 변경은 잦다. 카드 수수료 체계 개편, PG사 정책 변경, 세금계산서 처리 규칙 변화. 이런 변경이 있을 때마다 파인튜닝 사이클을 돌릴 수 있는가? 3인 팀에서는 현실적으로 불가능하다. 프롬프트 업데이트 한 번으로 대응할 수 있는 클로즈드 API 방식이 유지보수 부담 면에서 압도적으로 가볍다.

데이터 보안 역시 오픈소스의 명백한 장점이다. 온프레미스에서 돌리면 거래 데이터가 외부로 나가지 않는다. 이론적으로 맞는 말이고, 결제 도메인에서 이 장점이 더 크게 부각된다는 것도 안다. 다만 현재 우리 구성을 따져보면, LLM에 들어가는 데이터는 실제 거래 원문이 아니라 집계·가공된 형태다. 카드번호, 주민번호, 계좌번호가 프롬프트에 직접 포함되지 않도록 파이프라인 설계 단계에서 이미 처리해 뒀다. 추가로 클로즈드 API 공급사들은 API 사용 데이터를 학습에 활용하지 않는다는 조항을 계약으로 명문화하고 있다. 이 두 조건이 충족되는 한, 보안만을 이유로 오픈소스를 선택할 필요성은 낮다. 단, 금융당국의 개인정보 처리 가이드라인이 강화되어 집계 데이터조차 외부로 내보낼 수 없게 되는 규제 시나리오가 오면 이 판단은 즉시 뒤집어야 한다. 그래서 우리는 현재 어떤 데이터가 LLM에 들어가는지를 분기마다 내부 문서로 갱신하고 있다.

언제 다시 검토할 것인가: 세 가지 구체적 트리거

"지금 안 쓴다"는 판단에는 세 가지 트리거가 붙어 있다. 조건 없이 "나중에 다시 보자"는 결정 보류지, 판단이 아니다. 기준이 없으면 재검토 시점을 놓치거나, 반대로 습관적으로 현상 유지를 고수하게 된다.

트리거 1 — 월 API 비용 200만 원 이상 3개월 연속. GPU Reserved 비용과 손익분기가 역전되기 시작하는 구간이다. 이 시점에서는 전면 전환이 아니라 특정 태스크 — 낮은 품질 허용 범위를 가진 대량 배치 분류 작업 — 를 먼저 오픈소스로 이관하는 하이브리드 전략을 검토한다. 트리거 2 — 규제 요건 변화로 외부 API 사용 불가. 금융 규제 강화로 처리 데이터를 온프레미스에서만 다뤄야 하는 상황이 오면 선택지가 없어진다. 이 경우를 대비해 LLM 입력 데이터 분류 문서를 분기마다 갱신하고, 전환이 필요해지는 순간에 어떤 파이프라인부터 이관해야 하는지 바로 알 수 있도록 준비해 두고 있다. 트리거 3 — 오픈소스 모델이 우리 실제 태스크에서 실질적 우위를 보이는 경우. 벤치마크가 아니라 우리 입력 데이터로 직접 비교했을 때다. 정산 이상 건 분류, 코드 설명, 규칙 추출 세 가지 태스크에 대해 6개월 주기로 주요 오픈소스 모델을 내부 테스트셋으로 평가한다. 최근 평가에서 Qwen2.5 72B가 코드 설명 태스크에서 클로즈드 모델 대비 약 85% 수준의 품질을 보였다. 아직 전환 기준에는 미치지 못하지만, 격차는 좁혀지고 있다. 오픈소스 생태계가 성숙하는 속도를 보면, 우리가 다음 글을 쓸 시점은 생각보다 빨리 올 수 있다.

바로 써먹을 실행 시사점

이 글에서 말하고자 한 것은 오픈소스 LLM이 나쁘다는 게 아니다. 팀 규모·도메인·현재 사용량에 따라 판단 기준이 달라져야 한다는 것이다. 비슷한 고민을 하는 팀이라면 아래 순서로 점검해 보길 권한다.

1. 현재 월 API 비용을 수치로 측정하라. "비싸다"는 느낌이 아니라 실제 청구 내역을 뽑아라. GPU 운영 비용과 정확히 비교할 수 있어야 결정이 근거를 가진다. 손익분기 호출량은 (GPU 월 고정비) ÷ (API 토큰당 단가 × 평균 요청당 토큰 수)로 역산할 수 있다. 2. LLM에 어떤 데이터가 들어가는지 먼저 파악하라. 민감 데이터가 프롬프트에 직접 포함되고 있다면 데이터 마스킹 파이프라인이 먼저다. 오픈소스냐 클로즈드냐를 따지기 전에 해결해야 할 구조적 문제다. 3. "전면 전환"이 아니라 "어떤 태스크에서"를 먼저 정해라. 품질 허용 범위가 넓고 호출량이 많은 배치 태스크부터 오픈소스로 이관하는 하이브리드가 현실적이다. 처음부터 전체를 바꾸는 건 리스크만 키운다. 4. 파인튜닝을 계획한다면 유지보수 반복 비용을 포함해 추정하라. 최초 학습 비용보다 재학습·평가·배포 반복 비용이 훨씬 크다. 도메인 변화 빈도가 높은 결제·정산 영역에서는 특히 그렇다. 프롬프트 기반 컨트롤이 유지보수 측면에서 선택지가 되는 이유가 여기 있다. 5. 재검토 트리거를 미리 정해 두라. "언젠가 다시 보자"가 아니라, 어떤 수치나 조건이 충족되면 재검토할 것인지를 지금 문서화해 둬라. 그래야 관성이 아니라 근거로 결정을 유지하거나 바꿀 수 있다.

— by slecs