에이전트를 위한 프론티어 AI 추론 클라우드

URL: https://www.youtube.com/watch?v=Hvb2LfMH58c
날짜: 2026-09-20
채널: aiDotEngineer
발표자: Byung-Gon (Gon) Chun, FriendliAI 창업자·CEO

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트 시대의 추론 인프라는 요청(request) 하나의 지연시간이 아니라, 여러 모델 호출과 도구 실행으로 이뤄진 전체 작업(task)의 완료 시간을 최적화해야 한다.==

• 에이전트는 계획·도구 호출·관찰을 반복하고, 관찰 결과가 컨텍스트에 계속 추가되므로 일반 채팅보다 훨씬 긴 실행을 만든다.
• 연속된 에이전트 단계는 거대한 프롬프트 접두부(prefix)를 공유하므로, 매번 다시 계산하면 이미 처리한 작업에 연산을 낭비한다.
• 오픈 웨이트 모델은 프론티어 수준의 에이전트 품질에 도달했고, 적절한 캐시·라우팅·스케줄링을 결합하면 비용·속도·신뢰성을 모두 개선할 수 있다.

FriendliAI가 제시하는 해법은 에이전트의 실행 구조에 맞춰 추론 클라우드 전체를 다시 설계하는 것이다. 핵심은 접두부 캐싱(prefix caching), KV 캐시 관리, 캐시 인식 라우팅(cache-aware routing), 에이전트 인식 최적화(agent-aware optimization) 네 축이며, 그 아래에 긴 컨텍스트를 위한 sparse attention, 빠른 커널, 오류 감소 기법, 복원력 있는 서빙을 배치한다.

1. 에이전트와 오픈 웨이트 모델이 추론 경제성을 바꾸다

에이전트의 대규모 운영과 오픈 웨이트 모델의 프론티어급 품질이 동시에 성숙하면서, 추론 인프라의 중심 단위가 채팅 요청에서 장시간 작업으로 이동한다.

1.1. FriendliAI의 출발점과 포지셔닝

1. 연구에서 시작한 추론 전문성

   1. 서울대학교 연구팀의 뿌리: FriendliAI는 서울대학교에서 나온 연구팀을 기반으로 하며, 연구 중심의 최적화 역량을 제품의 출발점으로 삼는다.
   2. Continuous batching: 팀이 개발한 continuous batching은 현재 업계 전반에서 표준처럼 사용되는 추론 최적화 기법으로 소개된다.
   3. Orca 연구의 영향: 팀의 Orca 관련 연구는 널리 사용되는 오픈소스 모델 서빙 프레임워크에 영향을 줬다. 발표의 자동 자막은 프레임워크 이름을 부정확하게 기록했지만, 핵심은 연구 결과가 산업용 서빙 생태계로 이어졌다는 점이다.

2. 글로벌 에이전트 추론 클라우드

   1. 운영 범위: FriendliAI는 샌프란시스코에 본사를 두고 서울 팀과 함께 글로벌 규모로 프론티어 추론을 운영한다.
   2. 핵심 약속: 에이전트를 대규모로 운영할 때 필요한 속도, 비용 효율, 신뢰성을 하나의 추론 클라우드에서 제공한다.

1.2. 2026년의 두 가지 동시 변화

1. 에이전트 사용량의 폭발

   1. 소프트웨어와 지식 업무의 자동화: AI 에이전트가 소프트웨어 개발, 운영, 지식 업무 전반으로 확산되면서 채택이 기하급수적으로 늘어난다.
   2. 생산 환경 진입: 2026년은 에이전트가 실험 단계를 넘어 대규모 프로덕션에 들어가는 시기로 규정된다.

2. 오픈 웨이트 모델의 프론티어 도달

   1. 품질 임계점 통과: 오픈 웨이트 모델은 폐쇄형 프론티어 모델에 필적하는 능력을 확보해, 실제 에이전트 워크플로에 충분히 쓸 수 있는 수준이 됐다.
   2. 토큰 비용의 변화: 같은 품질의 에이전트를 더 낮은 토큰 비용으로 실행할 수 있어, 모델 선택이 곧 운영 경제성의 레버가 된다.

1.3. 타워 디펜스 게임으로 비교한 모델 경제성

1. 동일한 작업, 서로 다른 모델

   1. 작업 내용: 코딩 에이전트에게 타워 디펜스 게임을 만들라는 정확히 같은 작업을 부여했다.
   2. 비교군: FriendliAI에서 실행한 오픈 웨이트 GLM 5.2와 Anthropic의 폐쇄형 Opus 4.8을 비교했다.
   3. 품질 기준: 두 모델의 결과물이 픽셀 단위로 같다는 주장이 아니라, 둘 다 여러 에이전트 워크플로에서 실제로 사용할 수 있는 수준까지 작업을 완성했다는 점이 비교의 핵심이다.

2. 비용 차이

   1. 폐쇄형 모델 비용: Opus 4.8 실행 비용은 약 1.50달러로 제시됐다.
   2. 오픈 웨이트 비용: GLM 5.2를 FriendliAI에서 실행한 비용은 약 0.27달러였다.
   3. 결과: 동일한 작업을 약 5.6배 낮은 비용으로 수행했다. 오픈 웨이트 모델이 프론티어 수준 에이전트를 훨씬 낮은 비용으로 가능하게 한다는 사례다.

2. 채팅 요청이 아닌 작업 완료를 최적화해야 하는 이유

에이전트 추론은 채팅을 여러 번 호출하는 단순한 확장이 아니라, 상태가 누적되는 프로그램 실행에 가깝다.

2.1. 채팅의 단위와 에이전트의 단위

1. 채팅의 기본 모델

   1. 요청-응답 구조: 사람이 질문하고 모델이 한 번 답하면 사용자가 결과를 읽는다.
   2. 지연시간의 정의: 사용자가 체감하는 핵심 지표는 단일 응답이 얼마나 빨리 오는지, 즉 개별 요청 지연시간이다.

2. 에이전트의 기본 모델

   1. 작업 단위: 에이전트는 여러 모델 호출과 도구 호출을 묶은 하나의 작업을 수행한다.
   2. 사용자 목표: 사용자는 개별 모델 호출 하나가 빠른지보다 전체 작업이 언제 끝나는지를 중요하게 여긴다.
   3. 새로운 최적화 목표: 추론 시스템은 요청 지연시간이 아니라 end-to-end 작업 지연시간을 최적화해야 한다.

2.2. 계획-행동-관찰 루프

1. 반복되는 실행 사이클

   1. 계획(Plan): LLM이 다음 행동을 결정한다.
   2. 행동(Act): 에이전트가 코드 실행, 검색 등 하나 이상의 도구를 호출한다.
   3. 관찰(Observe): 도구 결과를 읽고, 그 결과를 컨텍스트에 추가한 뒤 다음 LLM 호출로 돌아간다.
   4. 종료 조건: 작업이 완료될 때까지 이 루프를 반복한다.

2. 모델 호출 사이의 공백과 병렬성

   1. 비(非)LLM 실행 구간: LLM 호출 사이에는 도구 실행 시간이 존재하므로, 모델 요청만 독립적으로 빠르게 만들어서는 전체 지연시간을 줄일 수 없다.
   2. 하위 에이전트: 하나의 에이전트가 여러 하위 에이전트를 만들고 병렬로 실행할 수 있어, 호출 수와 동시성이 입력에 따라 달라진다.

2.3. 길어지는 입력과 공유 접두부

1. 컨텍스트의 지속적 증가

   1. 관찰 결과의 누적: 각 단계의 도구 결과가 다음 호출의 입력으로 추가되기 때문에 프롬프트와 completion의 길이가 일반 채팅보다 훨씬 길다.
   2. 작업 진행에 따른 성장: 코딩 에이전트의 내부 실행 분포에서도 작업이 진행될수록 입력 컨텍스트가 길어지는 패턴이 확인된다.

2. 거대한 공통 접두부

   1. 반복되는 계산: 인접한 에이전트 단계는 앞부분의 컨텍스트 대부분을 공유한다.
   2. 낭비의 원인: 매 호출마다 같은 접두부를 다시 prefill하면 이미 계산한 내용을 반복 처리하게 된다.
   3. 최적화 기회: 공유 접두부를 한 번 계산하고 재사용하는 것이 에이전트 추론의 가장 큰 개선 지점 중 하나다.

2.4. 장기 실행 작업의 규모

1. Deep Research 사례

   1. 다단계 구성: speculative decoding 프레임워크를 코드로 설명하는 장기 작업처럼, 복수 단계가 이어지는 연구형 작업을 예로 들었다.
   2. 하위 에이전트의 연쇄: 각 단계가 여러 하위 에이전트로 구성되고, 하위 에이전트마다 복수의 추론 및 도구 호출이 발생한다.

2. 분 단위에서 시간 단위로 이어지는 실행

   1. 호출 수: 작업에 따라 수십 회에서 수백 회의 추론 단계가 발생할 수 있다.
   2. 지속 시간: 실행은 수분에서 수시간까지 이어질 수 있고, 공통 컨텍스트는 그동안 계속 유지된다.
   3. 핵심 지표: 사용자가 원하는 것은 토큰 하나나 호출 하나의 속도가 아니라 자신의 연구·코딩 작업이 끝나는 시점이다.

3. 에이전트 중심 추론 클라우드의 네 가지 기둥

FriendliAI는 에이전트의 실행 그래프에 맞춰 캐시, 메모리, 라우팅, 스케줄러를 계층적으로 재구성한다.

3.1. 기둥 1 — Prefix caching

1. 공유 접두부를 한 번만 계산하기

   1. KV 생성: 에이전트 단계들이 공유하는 접두부의 key-value(KV)를 한 번 계산한다.
   2. 접미부만 처리: 이후 단계에서는 캐시된 KV를 재사용하고 새로 늘어난 suffix만 처리한다.

2. 작업 지연시간에 미치는 효과

   1. Prefill 비용 절감: 캐시를 읽는 것이 긴 접두부를 다시 prefill하는 것보다 훨씬 저렴하다.
   2. TTFT 개선: 첫 토큰까지의 시간(time to first token)을 줄인다.
   3. 장기 작업일수록 확대되는 이점: 에이전트 작업이 오래 지속되고 단계가 많아질수록 동일한 접두부를 재사용하는 횟수가 늘어난다.

3.2. 기둥 2 — KV cache management

1. GPU 메모리의 활용도 높이기

   1. 메모리 절약형 관리: 각 GPU 메모리에 더 많은 활성 컨텍스트를 패킹할 수 있도록 frugal memory management를 적용한다.
   2. KV 캐시 양자화: KV 표현의 메모리 풋프린트를 줄이는 양자화 기법을 활용한다.

2. GPU를 넘어선 계층형 캐시

   1. 세 계층: GPU 메모리, 호스트 메모리, 디스크에 걸쳐 캐시를 계층적으로 유지한다.
   2. 용량 확장: GPU만으로 수용할 수 있는 컨텍스트 크기를 넘어 장기 작업을 지원한다.

3. 분산 캐시

   1. 복제본 간 공유: 하나의 접두부를 특정 인스턴스 내부에서만 쓰지 않고 여러 replica가 서비스할 수 있게 한다.
   2. 확장성: 캐시된 상태를 클러스터 전체에서 활용해 작업이 다른 GPU로 이동할 때의 재계산을 줄인다.

3.3. 기둥 3 — Cache-aware routing

1. 균등 분산의 한계

   1. Naive load balancer: 단순한 로드밸런서는 요청을 GPU 클러스터에 균등하게 나눈다.
   2. 지역성 파괴: 균등 분산만 추구하면 필요한 접두부가 이미 캐시된 replica를 피하게 되어 캐시 지역성이 사라진다.

2. 캐시를 보존하는 전역 라우팅

   1. 캐시 보유 파드로 전달: cache-aware router는 올바른 접두부를 이미 보유한 파드로 요청을 보낸다.
   2. Cold prefill을 cache hit으로 전환: 매번 처음부터 계산하는 prefill을 캐시 조회로 바꾼다.
   3. 부하 균형과의 절충: 한 파드가 hot spot이 되지 않도록 캐시 지역성과 전체 부하 사이를 동시에 조정한다.
   4. 작업 A의 예시: 작업 A의 연속된 두 요청을 같은 파드로 보내 첫 요청에서 만든 접두부 캐시를 다음 요청이 재사용하게 한다.

3.4. 기둥 4 — Agent-aware optimization

1. 호출을 독립 사건으로 보지 않기

   1. 기존 스케줄러의 관점: 대부분의 시스템은 각 LLM 호출을 서로 무관한 독립 요청처럼 스케줄링한다.
   2. 에이전트 프로그램의 맥락: 실제 호출은 더 긴 에이전트 프로그램의 한 단계이므로, 다음 단계와 남은 작업을 함께 봐야 한다.

2. 에이전트 수준의 의사결정

   1. 선택적 선점: 어떤 작업을 preempt할지 에이전트 수준의 진행 상황을 보고 결정한다.
   2. 추측성 prefill: 가능성이 높은 다음 단계를 미리 prefill해 도구 실행 뒤의 대기시간을 줄인다.
   3. 지능적 캐시 축출: 개별 호출의 최근 사용 여부가 아니라 에이전트 맥락에 근거해 어떤 캐시를 내보낼지 판단한다.
   4. 최종 목표: 한 번의 호출을 빠르게 보이는 것이 아니라 전체 작업 지연시간을 줄인다.

3.5. 하위 모델·서빙 계층의 보강

네 가지 기둥 아래에는 긴 컨텍스트를 위한 sparse attention, 오류를 줄이는 기법, 빠른 GPU 커널, 복원력 있는(resilient) 서빙 등이 놓인다. 캐시와 라우팅이 좋아도 모델 커널과 장애 대응이 약하면 장기 에이전트 작업의 end-to-end 신뢰성을 확보할 수 없기 때문이다.

4. 벤치마크와 프로덕션 적용

에이전트 중심 설계의 가치는 단일 토큰 지표가 아니라 같은 작업을 처음부터 끝까지 완료하는 속도와 오류율에서 드러난다.

4.1. 동일한 모바일 게임 작업 비교

1. 실험 조건

   1. 모델: GLM 5.2를 사용했다.
   2. 에이전트: Kilo Code로 간단한 모바일 게임을 만드는 동일한 작업을 실행했다.
   3. 비교 대상: FriendliAI 모델 API와 다른 유명 추론 제공자의 API를 비교했다.

2. 관찰된 결과

   1. 작업 완료 속도: FriendliAI의 에이전트 중심 클라우드가 동일한 작업을 end-to-end로 더 빠르게 완료했다.
   2. 측정 관점: 차이는 단일 요청의 토큰 속도가 아니라 도구 호출, 캐시 재사용, 여러 단계의 누적 지연이 합쳐진 최종 완료 시간에서 발생한다.

4.2. 프로덕션 고객과 7배 속도 사례

1. 서로 다른 고객, 같은 요구

   1. AI 네이티브 고객: Kilo는 수백만 명이 사용하는 인기 에이전트형 AI 코딩 도구로 소개된다.
   2. 대기업 고객: LG는 전자, 헬스케어, 에너지 등 다양한 사업을 운영하는 글로벌 기업이다.
   3. 공통 요구: 회사 규모와 업종은 다르지만 빠르고 안정적이며 비용 효율적인 에이전트 추론이 필요하다.

2. Kilo Code의 split test

   1. 비교 범위: Kilo Code는 1년 동안 오픈 모델과 폐쇄형 모델을 호스팅하는 여러 추론 제공자를 시험했고, 모델 연구소의 직접 사용도 비교했다.
   2. GLM5 결과: GLM5 사용량을 나눈 테스트에서 FriendliAI가 다른 제3자 제공자와 모델 연구소 직접 사용보다 일관되게 약 7배 빨랐다.
   3. 오류율: 더 낮은 오류율도 함께 확인됐다.
   4. 제품 내 위치: Kilo는 FriendliAI를 현재 스택의 핵심 구성요소로 사용한다.

4.3. 세 가지 배포 방식

1. Model API

   1. 빠른 시작: 서버리스 API로 GLM 5.2, Minimax, Kimi 같은 프론티어 오픈 웨이트 모델을 바로 호출한다.
   2. 적합한 경우: 인프라를 직접 운영하지 않고 빠르게 프로토타입과 초기 프로덕션을 시작할 때 적합하다.

2. Dedicated endpoint

   1. 격리된 배포: 고객 전용 추론 엔드포인트를 운영한다.
   2. SLA: 프로덕션 워크로드를 위해 보장된 SLA를 제공한다.

3. BYOG(Bring Your Own GPU)

   1. 자체 인프라 실행: 고객이 보유한 GPU에서 FriendliAI 추론 스택을 실행한다.
   2. 동일한 기반: API, 전용 엔드포인트, 자체 GPU 방식 모두 동일한 최적화 스택을 활용한다.

주요 발언 모음

“The user cares about when the whole task is completed.”
사용자가 신경 쓰는 것은 전체 작업이 언제 완료되는가이다.

“Agentic inference is not just chat with more requests.”
에이전트 추론은 채팅 요청을 더 많이 보내는 것에 그치지 않는다.

“The goal is to reduce end-to-end task latency, not just make one call look fast.”
목표는 한 번의 호출을 빨라 보이게 하는 것이 아니라 end-to-end 작업 지연시간을 줄이는 것이다.

“Same stack, three ways to deploy.”
같은 스택을 세 가지 방식으로 배포할 수 있다.

핵심 데이터 & 수치

• 약 5.6배 비용 차이: 타워 디펜스 게임 제작 작업에서 Opus 4.8은 약 1.50달러, FriendliAI의 GLM 5.2는 약 0.27달러였다.
• 수십~수백 회 추론: Deep Research 같은 장기 작업은 여러 하위 에이전트가 분 단위에서 시간 단위로 수십~수백 회의 추론을 실행할 수 있다.
• 약 7배 속도: Kilo Code의 GLM5 split test에서 FriendliAI가 다른 제3자 제공자와 모델 연구소 직접 사용보다 일관되게 약 7배 빨랐다.
• 오류율 개선: Kilo Code 비교에서 속도뿐 아니라 오류율도 유의미하게 낮았다.
• 세 가지 배포 경로: Model API, 전용 엔드포인트, BYOG로 같은 추론 스택을 사용할 수 있다.

결론 및 실행 포인트

1. 모델 선택을 다시 계산한다: 프론티어급 품질이 필요한 에이전트라도 GLM 5.2, Minimax, Kimi 같은 오픈 웨이트 모델의 비용 구조를 먼저 비교한다.
2. 측정 단위를 작업으로 바꾼다: TTFT나 단일 토큰 속도만 보지 말고, 도구 호출과 재시도를 포함한 end-to-end task latency를 측정한다.
3. 접두부 캐싱을 우선 적용한다: 반복되는 시스템 프롬프트와 작업 컨텍스트의 KV를 재사용해 긴 에이전트 루프의 중복 prefill을 줄인다.
4. KV 캐시의 계층을 설계한다: GPU에만 의존하지 말고 호스트 메모리와 디스크까지 활용하며, 양자화·압축·분산 공유를 함께 검토한다.
5. 캐시 지역성을 라우팅 정책에 넣는다: 단순 균등 분산으로 캐시를 깨뜨리지 말고, 접두부를 가진 replica를 우선하되 hot spot을 막도록 부하를 함께 조절한다.
6. 스케줄러에 에이전트 맥락을 전달한다: 각 호출을 독립 요청으로 다루지 않고 다음 단계 예측, 선점, 캐시 축출을 전체 에이전트 프로그램 관점에서 결정한다.
7. 배포 제약에 맞춰 경로를 선택한다: 빠른 시작은 Model API, 강한 격리와 SLA는 dedicated endpoint, 데이터·GPU 통제가 필요하면 BYOG를 선택한다.
8. 운영 검증을 실제 작업으로 한다: 동일한 코딩·리서치 작업을 여러 제공자에 실행해 완료 시간, 오류율, 비용을 한 묶음으로 비교한다.

핵심 요약 (20줄)

1. 2026년 에이전트는 소프트웨어와 지식 업무 전반에서 대규모 프로덕션으로 진입하고 있다.
2. 오픈 웨이트 모델은 폐쇄형 프론티어 모델에 필적하는 에이전트 품질에 도달했다.
3. 오픈 웨이트 모델은 같은 작업을 더 낮은 토큰 비용으로 수행할 수 있게 한다.
4. 타워 디펜스 게임 작업에서 GLM 5.2는 Opus 4.8과 함께 사용 가능한 결과를 완성했다.
5. 해당 작업 비용은 Opus 4.8 약 1.50달러와 GLM 5.2 약 0.27달러로 크게 달랐다.
6. 채팅의 기본 단위가 요청이라면 에이전트의 기본 단위는 여러 호출로 구성된 작업이다.
7. 에이전트 작업은 계획, 도구 행동, 결과 관찰을 반복하는 루프로 실행된다.
8. 도구 결과가 컨텍스트에 누적되면서 후속 요청의 입력은 계속 길어진다.
9. 하위 에이전트가 병렬로 실행되면 모델 호출 수와 동시성은 입력마다 달라진다.
10. 장기 연구 작업은 수십 회에서 수백 회의 추론을 수분에서 수시간 동안 수행할 수 있다.
11. 연속 단계는 거대한 프롬프트 접두부를 공유하므로 반복 계산은 큰 낭비가 된다.
12. Prefix caching은 공유 접두부의 KV를 한 번 계산하고 새 suffix만 처리하게 한다.
13. KV cache management는 GPU, 호스트 메모리, 디스크를 계층적으로 활용한다.
14. KV 캐시 양자화와 메모리 절약형 관리는 GPU마다 더 많은 활성 컨텍스트를 수용하게 한다.
15. 분산 캐시는 하나의 접두부를 여러 replica에서 재사용하게 한다.
16. Cache-aware routing은 캐시된 접두부를 가진 replica로 요청을 보내 지역성을 보존한다.
17. Agent-aware optimization은 개별 호출이 아니라 전체 에이전트 프로그램을 기준으로 스케줄링한다.
18. 추측성 prefill과 에이전트 맥락 기반 캐시 축출은 다음 단계의 대기와 재계산을 줄인다.
19. Kilo Code는 split test에서 FriendliAI가 약 7배 빠르고 오류율도 낮았다고 평가했다.
20. 에이전트 운영자는 모델·인프라·라우팅을 함께 최적화하고 작업 완료 시간을 핵심 지표로 삼아야 한다.