오픈소스 LLM 을 더 깊게 들여다본 한 달

왜 결제·정산 팀에게 이 문제는 "비용" 이전에 "규정 리스크"인가

우리 팀이 다루는 데이터는 일반 SaaS 서비스와 성격이 다르다. 가맹점 정산 내역, 가상계좌 입금 확인 로그, PG사별 실패 응답 메시지, 수수료율 협약 데이터 — 이것들을 외부 API 서버로 전송하는 행위는 단순한 "비용 대비 편의" 선택이 아니다. 전자금융거래법과 개인정보보호법 해석에 따라 제3자 클라우드 API로 금융 거래 데이터를 내보내는 것은 여전히 회색지대에 있고, 감독 당국의 유권 해석이 고정되어 있지 않다. 상용 LLM API 사업자가 "데이터를 학습에 사용하지 않는다"는 약관을 제공해도, 그것이 국내 금융 감독 기준을 충족한다는 독립적 확인을 얻기까지 작은 팀은 그 시간을 갖지 못한다.

그래서 이번 한 달 테스트의 출발점은 "더 싼 대안 탐색"이 아니었다. 민감도가 높은 파이프라인 일부를 완전히 로컬화할 수 있는지 — 즉, 상용 API를 아예 선택지에서 제외해야 하는 데이터를 자동화할 방법이 있는지를 판단하는 것이었다. 이 질문이 분명하지 않으면 오픈소스 LLM 테스트는 그냥 기술 탐색으로 끝난다.

테스트 설계: 범용 벤치마크 말고 우리 업무로

오픈소스 LLM 비교 글에서 자주 보이는 MMLU, HumanEval 같은 벤치마크는 우리 업무와 거의 무관하다. 우리가 설계한 테스트는 세 가지 실제 태스크였다.

첫째, 구조화 데이터 추출. PG사마다 포맷이 다른 정산 리포트(CSV, PDF, 고정길이 텍스트 혼용)에서 승인 번호·금액·수수료율·취소 여부를 일관된 JSON으로 파싱하는 작업. 규칙 기반 파서가 커버하지 못하는 변형 포맷 처리가 핵심이다. 둘째, 정산 예외 로그 요약. 하루 수백 건의 실패 트랜잭션 로그를 "오늘 주요 이슈 3줄"로 만드는 것. 담당자가 매일 아침 슬랙에서 확인하는 리포트다. 셋째, 자동화 스크립트 코드 생성. 정산 규칙을 Python으로 구현하는 코드 조각 생성. 이건 데이터가 아니라 로직이어서 민감도가 낮다.

서빙 스택은 ollama와 vllm을 병행했다. ollama는 팀원 누구나 맥북에서 ollama run qwen2.5:14b 한 줄로 돌릴 수 있어 프로토타이핑이 빠르다. vllm은 AWS g5.2xlarge(A10G 24GB, 시간당 약 $1.2)를 48시간 운영하며 배치 처리 처리량을 측정했다. 테스트 모델은 Llama 3.1 8B·70B, Qwen2.5-14B, Mistral 7B로 좁혔다.

수치로 본 트레이드오프: "싸다"는 착각을 먼저 걷어내자

비용 비교를 "API 토큰 단가 vs GPU 임대 시간당 단가"로 하면 반드시 잘못된 결론이 나온다. GPT-4o 기준 input $2.50/1M tokens, output $10/1M tokens이다. 우리 정산 예외 로그 요약 1건에 평균 input 2,000 tokens, output 300 tokens이면 건당 약 $0.008. 하루 300건 처리해도 월 $72다. 반면 g5.2xlarge를 24시간 상시 운영하면 월 약 $864, 더 큰 g5.48xlarge(A10G×8, 약 $16/hr)는 월 $11,500을 넘는다. 이 숫자만 보면 자체 운영이 비합리적으로 보인다.

그러나 이 계산에는 빠진 변수가 있다. 우리 파이프라인에서 상용 API로 보낼 수 없는 실거래 데이터가 전체 LLM 호출 후보의 약 40%를 차지한다. 그 40%를 처리하지 못해 발생하는 수동 작업 — 담당자가 예외 건을 하나씩 열어 확인하고 분류하는 시간 — 은 월 20시간 이상이었다. 시간 비용으로 환산하면 GPU 운영비와 다른 결이 된다. 지연 시간도 단순하지 않다. 로컬 네트워크에서 8B 모델의 첫 토큰 응답(TTFT)은 180220ms였지만, 리전 간 통신이 끼면 800ms1.4초로 늘었다. OpenAI API 평균 TTFT 400600ms와 비교하면, 잘 구성된 자체 서버가 반드시 빠른 게 아니었다. 배치 처리에서만 vllm의 연속 배칭이 ollama 대비 처리량 34배 우위를 보였다.

HEDVION 실제 시나리오: 정산 예외 분류 파이프라인에 적용한 결과

구체적인 케이스를 공개한다. 매일 새벽 3시, 전날 정산 결과에서 가맹점 청구액과 PG 입금액 불일치 건을 추출해 슬랙 리포트를 발송하는 파이프라인이 있다. 기존 규칙 기반 분류기는 PG사 응답 메시지가 자연어 형태로 제각각이어서 자동 분류 실패율이 약 18%였다. 실패 건은 담당자가 직접 열어봐야 했고, 하루 평균 30~50건이 쌓였다.

여기에 Qwen2.5-14B를 온프레미스 RTX 4090 1장(초기 구매 약 160만 원, 전기비 월 3~4만 원)에서 운영하면서, PG사 응답 텍스트를 "수수료 오류 / 취소 타이밍 불일치 / 통신 장애 / 기타" 4가지로 분류하는 프롬프트를 붙였다. 결과는 분류 실패율 18%에서 4.3%로 감소. 이 데이터는 실거래 승인 번호와 금액을 포함하고 있어 외부 API 선택지 자체가 없었다. 초기 GPU 비용을 6개월로 분할하면 월 27만 원, 운영비 포함해도 상용 API로 동일 작업을 했을 때 아낄 수 있는 수동 작업 비용보다 낮다.

반면 코드 생성 용도에서는 로컬 모델이 확실히 밀렸다. 복잡한 정산 로직("환율 변환 후 소수점 절사 방식 세 가지를 선택 가능하게 구현하되 일본엔화 예외 처리 포함")을 작성할 때 8B·14B 모델은 엣지 케이스를 놓치는 빈도가 높았고, 코드 리뷰 시간이 오히려 늘었다. 이 용도에는 Claude Sonnet을 그대로 사용한다. 코드는 로직이지 데이터가 아니므로 민감도 분류상 문제가 없다.

하이브리드 아키텍처: 지금 설계해야 나중이 편하다

우리가 선택한 구조는 모든 LLM 호출을 단일 추상 인터페이스로 감싸고, 데이터 민감도 레벨(L1~L3 태그)에 따라 라우팅하는 것이다. L3(실거래 데이터 포함)는 로컬 엔드포인트로, L1·L2는 상용 API로 자동 분기된다. 실제 구현은 llm_call(prompt, sensitivity="L3") 형태의 래퍼 함수 하나다. 환경변수로 엔드포인트만 바꾸면 모델 전체를 교체할 수 있다. 이 구조 덕분에 Llama 3.1에서 Qwen2.5로 교체하는 데 걸린 시간은 실제로 45분이었다.

이 설계의 진짜 가치는 지금의 비용 절감보다 미래 유연성이다. 6개월 뒤 더 나은 오픈소스 모델이 나오거나, 상용 API 요금 구조가 바뀌거나, 금융 감독 해석이 명확해지는 시점이 반드시 온다. 그때 라우팅 테이블 하나만 수정하면 되는 팀과, 각 파이프라인에 API 호출을 직접 박아놓은 팀의 대응 속도는 다르다.

지금 당장 쓸 수 있는 실행 지침

탐색 단계는 끝내고 실행으로 넘어가야 할 팀을 위한 구체적 액션이다.

1. "이 데이터를 외부 서버로 보낼 수 있는가?" 질문을 모든 LLM 도입 후보 작업에 먼저 던져라. 목록을 만들고 각 작업에 민감도 레벨을 붙이는 것이 시작이다. L3 데이터가 단 하나라도 있으면 로컬 모델 검토가 의무다.

2. 비용 판단 기준을 "API 단가"에서 "자동화 불가 공백 비용"으로 바꿔라. 보낼 수 없는 데이터를 처리하지 못해 담당자가 쓰는 수동 처리 시간이 월 몇 시간인지를 먼저 계산하라. 그 수치가 GPU 투자 여부의 실질 기준이다.

3. 단순 추출 작업은 Qwen2.5-14B 또는 Llama 3.1 8B로 먼저 검증하라. 정산 데이터에서 JSON 필드를 뽑는 수준의 작업은 이 모델로 충분할 가능성이 높다. ollama run qwen2.5:14b로 오늘 30분 안에 시작할 수 있다.

4. 추상화 레이어를 처음부터 넣어라. 나중에 모델을 바꿀 때 코드 전체를 뒤지는 일을 막는 래퍼 함수 하나가, 6개월 뒤 수백 줄의 마이그레이션 작업을 대신한다.

5. 복잡한 추론과 코드 생성은 아직 상용 API가 답이다. 이걸 부정하지 마라. 오픈소스를 선택하는 이유가 순수한 "비용 절감"이라면 현시점에서는 득보다 실이 클 수 있다. "데이터 프라이버시"와 "자동화 불가 공백 해소"가 이유라면, 이미 충분히 실용적이다. 그 차이를 팀 내에서 명확히 하는 것이 출발점이다.