서빙 비용 최적화 로직 확인
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
LLM 인프라 비용 최적화를 고민할 때 가장 먼저 든 생각은 모든 요청에 같은 모델을 쓸 필요가 없다는 것이었습니다. 사이드 프로젝트에서 gpt-4o를 모든 요청에 쓰다가 비용이 예상보다 3배 이상 나온 경험이 있었습니다. 그래서 요청 유형을 분류해서, 단순 분류·요약 작업은 가벼운 모델로, 복잡한 추론이 필요한 요청만 고성능 모델로 라우팅하는 구조로 바꿨습니다.
처음에는 품질이 떨어질까 걱정했는데, 단순 작업의 경우 가벼운 모델도 충분하다는 걸 100건 샘플로 비교 검증했습니다. 비용은 이전 대비 40% 줄었고 사용자가 체감하는 품질 차이는 거의 없었습니다. 팀 협업에서는 어느 요청을 어느 모델로 보낼지 기준을 문서화해서 공유했는데, 기준이 없으면 나중에 유지보수할 때 혼선이 생긴다는 걸 그때 배웠습니다. 아직 대규모 프로덕션 경험은 없어 더 배워야 할 부분이 많습니다.
LLM 비용 최적화에서 모델 라우팅 다음으로 효과가 컸던 것은 캐싱이었습니다. 사이드 프로젝트에서 같은 입력이 반복적으로 들어오는 케이스가 있었는데, 매번 API를 호출하면 동일한 결과에 비용이 계속 쌓였습니다. 응답을 캐시에 저장해두고 동일 입력이 들어오면 캐시를 반환하는 구조로 바꾸니, API 호출 수가 눈에 띄게 줄었습니다. 배치 처리도 비슷한 원리인데, 실시간 응답이 필요 없는 작업은 묶어서 처리하면 레이턴시 부담 없이 비용을 낮출 수 있었습니다.
캐싱·배치·라우팅 세 가지를 조합하면 각각 단독으로 쓰는 것보다 절감 효과가 큽니다 — 이 구조를 직접 구현해보면서 배웠습니다. 비용 최적화는 어느 한 방법이 아니라 패턴을 조합하는 것에서 나왔습니다. LLM 비용은 구조적으로 줄이는 방법이 있습니다.
멀티 LLM 설계에서 가장 어려웠던 것은 품질을 어떻게 측정하는가였습니다. 공개 벤치마크 점수가 높아도 실제 서비스에서 원하는 응답이 나오지 않는 경우가 있었기 때문입니다. 사이드 프로젝트에서 100건의 실제 요청 샘플을 직접 평가하는 방식으로 모델을 비교했는데, 벤치마크와 다른 순위가 나온 경우가 있었습니다.
실 사용 케이스 기준의 품질 평가가 벤치마크보다 더 실용적이라는 것을 그때 경험했습니다. 팀 협업에서는 어떤 응답을 좋은 응답으로 볼 것인가 — 이 기준을 팀원과 합의하고 문서화하는 것이 중요했습니다. 기준이 없으면 각자 다른 기준으로 모델을 평가하게 되고, 의사결정이 일관되지 않습니다. 품질 측정은 기준을 만드는 것이 먼저입니다. 평가는 기준이 있을 때 재현 가능합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 채널톡 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.