AI 엔지니어링 리드에게 요즘 가장 골치 아픈 게 뭐냐고 물으면, 의외로 모델 자체를 꼽는 경우는 거의 없습니다. 진짜 문제는 그 아래 인프라, 정확히는 "GPU 용량을 대체 얼마나 확보해둬야 하는가"입니다. 2026년 3월 Akamai가 AI 실무자 200명을 대상으로 진행한 설문에서 이 감각이 숫자로 확인됐습니다. AI 네이티브 팀의 65.9%가 GPU 용량 계획(capacity planning)을 스케일링 과정에서 가장 어려운 과제로 꼽았고, 이는 설문에 포함된 다른 모든 (레이턴시, 비용까지 포함한) 운영 이슈를 제친 1위였습니다. [1] 이건 소수가 겪는 특수한 고충이 아닙니다. 응답자의 75.5%가 엔지니어, 아키텍트, DevOps 실무자였고, 응답자의 76%가 기업의 예산과 방향을 정하는 의사결정권자였습니다. 즉, 실무자와 리더 모두가 공통으로 꼽은 문제라는 뜻입니다. 흥미롭게도, 같은 현상을 다른 곳에서도 확인할 수 있습니다. 202

개발 워크스테이션에도 GPU가 있고 연구실 서버에도 있습니다. 지사의 엣지 장비에도 가속기가 달려 있을 수 있죠. 그런데 막상 모델을 올리려고 하면 이야기가 달라집니다. 드라이버가 맞지 않거나 필요한 SDK가 없을 수 있고, 네트워크 문제로 외부에서 접근하지 못하는 경우도 있습니다. 분명 장비는 있는데 정작 서비스에서는 쓸 수 없는 겁니다. AIEEV Dev Team의 유기태 님은 이렇게 여러 곳에 흩어진 GPU와 NPU를 연결해 실제 AI 추론에 사용할 수 있는 분산 인프라를 개발하고 있습니다. 각 장비가 모델을 실행할 수 있는 상태인지 확인하고, 검증된 자원을 하나의 풀로 묶어 추론 요청을 처리하는 구조를 만들고 운영합니다. 지난 9월 1일에는 KCD x Ceph x OpenInfra Day Korea 2026에서 ‘Ray Serve in the Wild: GPU/NPU 기반 AI 인퍼런스 오토스케일링과 운영 경험’을 주제로 그동안의 경험도

1편에서는 AI 에이전트가 왜 기존 서빙 시스템의 가정을 무너뜨리는 '프로그램형 워크로드'인지, 그리고 세계 최고 시스템 학회들이 이 문제를 어떻게 다루고 있는지 살펴봤습니다. CacheBlend 사례에서 확인했듯, 그 답의 상당 부분은 GPU 메모리 바깥의 자원, 즉 소비자용 PC가 가진 DRAM과 SSD를 어떻게 활용하느냐에 달려 있었습니다. 이제 비용 이야기로 돌아와, 그 흐름이 왜 "소비자용 GPU 클라우드"라는 그림으로 수렴하는지 이어가 보겠습니다. 4. 그 많은 호출, 전부 초거대 모델이어야 할까: SLM이라는 답 NVIDIA Research는 지난해 "Small Language Models are the Future of Agentic AI"라는 도발적인 제목의 논문을 내놓았습니다 [1]. 요지는 이렇습니다. 에이전트 루프에서 실제로 발생하는 일의 상당수는 검색 결과 요약, tool 호출용 JSON 생성, 문서에서 정형 필드 추출,

안녕하세요. AIEEV 개발팀에서 AI 인프라 연구개발을 담당하고 있는 조용래입니다. 분산 시스템 성능 확장성 및 신뢰성을 주제로 컴퓨터 공학과 박사 학위를 받았으며, 지금은 Air Cloud 위에서 LLM 서빙의 효율과 신뢰성, 그리고 AI 에이전트 기술 연구개발에 관심을 두고 일하고 있습니다. AI 에이전트처럼 한 번의 요청에 모델을 수십, 수백 번씩 호출하는 서비스가 늘어날수록, 추론 비용 청구서는 예상보다 훨씬 빠르게 불어납니다. 회사에서 에이전트 기능을 붙여 보신 분이라면 한 번쯤 겪어보셨을 겁니다. AIEEV가 줄곧 붙들고 있는 문제의식도 바로 여기서 출발합니다. 이 글은 그 문제를 연구자의 시선으로 끝까지 파고든 기록입니다. 2부로 나눠, 1편에서는 AI 에이전트가 서빙 인프라에 던지는 도전이 무엇인지 세계 최고 시스템 학회들의 최신 연구로 짚어보고, 2편에서는 그 흐름이 왜 "아주 많은 소비자용 GPU 위에서 돌아가는 작은 모델들"