LLM은 붙이는 순간이 아니라, 운영할 때부터 진짜다

요즘 서비스에 AI를 붙이는 건 쉽습니다. API 키 하나 발급받아 몇 줄이면 그럴듯한 답이 돌아옵니다. 그래서 "AI 붙였다"는 말은 이제 자랑이 못 됩니다. 진짜 일은 붙인 다음부터 시작되더군요.

아래는 정답이 아니라, 여러 AI 서비스를 직접 만들고 운영하며 저희가 부딪히고 정리한 생각입니다. 상황에 따라 얼마든지 다를 수 있습니다.

1. AI의 진짜 비용은 'API 요금'이 아니라 '설계'다

데모에선 한 번의 호출이지만, 서비스에선 같은 종류의 질문이 하루에도 수천 번 들어옵니다. 그대로 매번 모델에 보내면 요금이 사용량에 그대로 비례해 쌓입니다. 그래서 저희는 비용을 "요금제 고르기"가 아니라 "어떻게 안 부르느냐의 설계 문제"로 봅니다.

핵심은 두 가지였습니다. 하나, 같은 답을 두 번 만들지 않는 것 — 입력이 본질적으로 같으면(같은 사용자·같은 조건·같은 기간) 결과를 재사용합니다. 둘, 프롬프트를 자산처럼 구조화하는 것 — 모든 요청에 공통으로 들어가는 부분을 앞에, 매번 달라지는 부분을 뒤에 둡니다. 그러면 반복되는 앞부분의 처리 비용이 크게 줄어듭니다(요즘 모델들이 긴 공통 접두부를 캐싱해 주거든요).

저희 한 서비스에선 이 방식(요청별 재사용 + 공통 접두부 캐싱 + 중간 결과 캐싱)을 겹겹이 쌓아, 실제 모델 호출을 10분의 1 수준까지 줄였습니다. 같은 품질을 유지하면서요. 비용 절감의 대부분은 더 싼 모델을 고른 게 아니라, "안 불러도 되는 호출을 안 부른" 설계에서 나왔습니다.

물론 이건 같은 질문이 반복되는 서비스에서의 이야기입니다. 보고서·분석·운세·검색처럼 입력이 자주 겹치는 곳은 캐싱이 크게 먹지만, 자유 대화·상담 챗봇·개인 비서처럼 매번 입력이 다른 서비스는 효과가 작습니다. 그럴 땐 캐싱 대신 아래의 지렛대(결정론·검색·특화)가 더 중요해집니다. "캐싱하면 무조건 90% 절감"이 아니라, 도메인의 반복성을 먼저 보는 것이 순서입니다.

2. 모델이 '사실'을 지어내지 않게 — 결정론 코어와 검색(RAG)

LLM의 가장 위험한 점은 모르는 걸 그럴듯하게 지어낸다는 것입니다. 그래서 저희는 사실 판단을 LLM에게 맡기지 않습니다. 규칙·수치로 정해지는 부분은 우리가 만든 결정론적 엔진이 먼저 확정하고, LLM에게는 그 확정된 사실을 "사람이 읽을 말로 풀어내는 일"만 맡깁니다.

예를 들어 어떤 해석 서비스에서는, 결과를 좌우하는 핵심 판정을 코드가 규칙대로 계산해 못 박은 뒤, 그 결과를 LLM이 서술하게 합니다. 이렇게 역할을 나누면 두 가지를 동시에 얻습니다 — 사실은 항상 정확하고(엔진이 보장), 표현은 자연스럽다(LLM이 담당). 한마디로 비즈니스 로직은 코드로, AI는 표현 계층으로. 이 경계가 흐려지면 그럴듯하지만 틀린 답이 사용자에게 그대로 나갑니다.

같은 이유로, 모델이 모르는 '지식'은 머릿속에서 꺼내게 하지 않고 검색해서 넣습니다(RAG). 우리 문서·자료를 먼저 찾아 근거로 붙이고, 모델은 그 근거 안에서만 답하게 하는 거죠. 그러면 "아는 척 지어낸 답"이 아니라 "출처 있는 답"이 됩니다. 저희는 이 지식베이스를 도메인별로 분리해 둡니다 — 서비스마다, 또 고객 납품 건마다 섞이면 검색이 오염되고 민감정보가 새니까요. 정리하면 사실은 두 군데서 옵니다. 계산으로 정해지는 건 결정론 엔진이, 문서에 있는 건 검색(RAG)이 책임지고, 모델은 그 위에서 '말'만 합니다.

3. 한 업체에 너무 묶이지 않기 — 그리고 우리 GPU(케이스 바이 케이스)

특정 모델 회사의 API에 깊이 박아 넣으면, 가격이 오르거나 정책이 바뀔 때 서비스가 통째로 흔들립니다. 그래서 저희는 모델 호출을 한 겹 추상화해 두어, 설정 하나로 공급자를 바꿀 수 있게 합니다.

단, 정직하게 말하면 "버튼 하나로 무손실 교체"는 환상에 가깝습니다. 모델마다 프롬프트가 먹히는 방식, 도구 호출 방식, 출력 성향이 달라서 추상화는 충격을 줄여줄 뿐, 완전한 교체는 생각보다 손이 많이 갑니다. 그래도 한 곳에 완전히 종속되지 않는 것만으로 협상력과 안전판이 생깁니다.

일부 작업은 아예 우리 GPU 서버에서 직접 돌립니다. 검색용 임베딩, 대량 리포트 생성처럼 외부로 보내면 비용·프라이버시가 걸리는 작업이 그렇습니다. 다만 자체 GPU가 늘 정답은 아닙니다. 모델 배포·모니터링·장애 대응·스케일링 같은 운영 비용이 따라붙어서, 트래픽이 크거나·프라이버시 규제가 세거나·대량 배치일 때라야 경제적이고, 규모가 작으면 외려 API가 더 쌉니다. 그래서 "무엇을 자체로, 무엇을 API로"를 작업마다 따로 저울질합니다.

4. 결국, 데이터를 모아 — 단, '우리 GPT'를 만들겠다는 게 아니다

여기서 오해부터 끊고 가야 합니다. 저희가 노리는 건 범용 모델(OpenAI 같은)을 이기는 '우리만의 파운데이션 모델'이 아닙니다. 그건 못 합니다. 데이터를 아무리 모아도, 세상 모든 주제를 다 아는 최전선 모델의 규모는 따라갈 수 없습니다. 이건 분명히 인정하고 갑니다.

핵심은 방향이 다르다는 데 있습니다. 범용 모델은 '모든 걸 다 알아야' 하기에 거대하고 비쌉니다 — 우리가 쓰지도 않는 광범위함의 값까지 치르는 셈이죠. 반대로 우리가 푸는 문제는 아주 좁고 명확합니다. 그 좁은 영역만 잘하면 되는 특화 엔진은 같은 일을 훨씬 작고 싸게 해낼 수 있습니다. "모든 걸 아는 거대한 모델에게 매번 묻는 비용" 대 "한 가지만 잘하도록 길들인 작은 모델의 비용" — 특화된 작업일수록 후자가 싸지는 지점이 옵니다.

그래서 '우리 모델'은 새 파운데이션 모델이 아니라, 우리 데이터로 좁게 길들인(파인튜닝·도메인 특화) 모델에 가깝습니다. 목표는 GPT를 이기는 게 아니라, 우리 도메인에서 '충분히 좋게, 그리고 더 싸게'입니다.

물론 이것도 아무 때나 답은 아닙니다. 실제로 학습되지 않은 공개 모델을 그대로 써봤더니, 우리 엔진이 못 박아 둔 사실조차 무시하고 엉뚱한 판정을 내놨습니다. 자체 모델의 성패는 모델을 '받는' 데 있지 않고 데이터의 '질'을 모으는 규율에 있더군요. 그리고 여기서 양과 질을 헷갈리면 안 됩니다 — 검수 안 된 수천 건보다, 포맷이 통일되고 편향을 걸러낸 정제된 수백 건이 더 낫습니다. 수십 건으론 어림없지만, 핵심은 '많이'가 아니라 '깨끗하게'더군요. 그래서 이 전략은 일정 규모·일정 특화도를 넘은 서비스에서야 수지가 맞습니다.

그래서 저희가 택한 방식은 이렇습니다. 지금은 최전선 모델로 서비스를 운영하면서, 그 과정에서 나오는 (정제된) 데이터를 차곡차곡 모읍니다. 결정론 엔진이 정답을 보장하니 "정답 + 좋은 서술"의 쌍이 운영하는 동안 자연히 쌓입니다. 그 데이터가 임계점을 넘고, 그 도메인에서 특화 모델이 범용 모델보다 싸지는 순간 — 그때 갈아탑니다. 자체 모델은 목표가 아니라, 데이터가 익고 계산이 맞아떨어진 결과여야 한다고 봅니다.

정리하며

AI를 붙이는 건 하루면 됩니다. 하지만 싸게(설계로) · 정확하게(결정론 코어) · 묶이지 않게(추상화와, 맞는 곳엔 우리 GPU) · 필요하면 우리 것으로(특화 모델) 운영하는 건 전혀 다른 일이더군요. 화려한 데모와 매일 굴러가는 서비스 사이의 거리가, 사실은 거기에 있었습니다.

결국 하고 싶은 말은 하나입니다 — AI 서비스의 경쟁력은 모델 그 자체보다, 운영 아키텍처와 데이터에 있다. 정답표는 없지만, "AI 붙였다"에서 멈추지 않고 이걸 계속 저울질하는 것 — 여러 서비스를 만들고 운영하며 저희가 도달한 생각입니다.

그리고 한 가지 더. AI가 코드를 대신 써주는 시대일수록, 역설적으로 더 절실해지는 건 "만들어줘"가 아니라 "왜·무엇을·어떻게"를 사고하는 개발자인 것 같습니다. 무엇을 캐싱하고, 어디까지 모델에 맡기고, 어떤 데이터를 모을지 — 이건 코드를 치는 일이 아니라 판단하는 일이거든요. 도구가 좋아질수록, 그 도구를 어디에 어떻게 쓸지 생각하는 사람의 값어치가 오릅니다. 좋은 개발이 결국 사람의 문제였던 건, AI 시대에도 그대로인 것 같습니다.

---

로동은 여러 AI 서비스를 직접 만들고 운영하며, 이렇게 '오래 가는' AI를 고민합니다. — lodong.co.kr