개발자들이 AI 인프라를 선택할 때 가장 많이 고민하는 질문은 의외로 단순합니다. 유연성을 위해서는 서버리스, 통제력을 위해서는 전용 인프라, 즉 편의성과 성능 사이에서 무엇을 택해야 하는가입니다.
하지만 실무에서 추론(inference) 인프라는 한 번 '올바르게' 선택하는 것이 아닙니다. 제품과 트래픽, 사용자 기대치가 변화함에 따라 어느 순간 조용히 맞지 않게 되는 존재입니다.
AI 회의 어시스턴트를 예로 들어보겠습니다. 초기 버전은 하루에 몇 건의 회의를 처리하며, 한 번에 하나씩 전사(transcription)와 요약을 수행합니다. 사용량도 불규칙하고, 우선순위는 그저 기능이 작동하게 만드는 것입니다. 이 단계에서는 서버리스 추론이 자연스럽게 잘 맞습니다.
제품이 자리 잡으면 일상 업무 흐름의 일부가 됩니다. 팀들은 하루 종일 회의 처리를 위해 이 도구에 의존하기 시작하고, 응답 속도에 대한 기대치도 높아집니다. 전체적인 성능이 괜찮더라도 간헐적인 지연 스파이크는 더 이상 무시할 수 없게 됩니다.
결국 시스템은 예측 가능한 일일 패턴을 가진 대량의 회의를 처리하는 지점에 도달합니다. 이 단계에서 요구사항은 일관성과 비용 효율성으로 이동합니다. 전용 추론이 논리적인 기반이 되는 것이죠. 이전 방식이 틀렸기 때문이 아니라, 시스템이 그 규모를 넘어섰기 때문입니다.
흥미로운 점은 서버리스가 사라지지 않는다는 것입니다. 예상치 못한 트래픽 급증 대응, 실험적 기능 실행, 저빈도 작업 처리 같은 엣지 케이스에는 여전히 유용합니다. 고정된 계획이 아니라 시스템의 필요에 따라 두 방식이 자연스럽게 혼합되는 형태가 되는 것입니다.
이 글에서는 시스템이 성장함에 따라 서버리스와 전용 추론 사이의 선택이 어떻게 변화하는지 살펴봅니다. 또한 널리 사용되는 두 플랫폼인 Modal과 Together.ai를 예시로 들어, 서버리스 추론이 언제 한계에 부딪히는지, 워크로드 패턴이 어떻게 올바른 선택을 좌우하는지, 그리고 시스템이 확장될수록 전용 인프라로의 전환이 왜 불가피한지 알아봅니다.
초기 단계
AI 제품을 만들기 시작한 초기에는 가장 큰 제약이 성능, 특히 지연 시간 일관성(각 요청이 얼마나 빨리 응답하는가)이나 처리량(동시에 몇 개의 요청을 처리할 수 있는가)이 아닙니다. 진짜 제약은 얼마나 빨리 출시하고, 반복 개선하고, 실제 사용으로부터 배울 수 있는가입니다.
초기에는 워크로드 특성도 파악되지 않았고, 트래픽은 들쭉날쭉하며, 모델은 계속 바뀌고, 제품 자체도 아직 다듬어지는 중입니다. 이런 상황에서 서버리스 플랫폼은 개발자의 니즈에 거의 완벽하게 부합합니다.
서버리스는 개발 속도를 늦추는 결정들을 대신 내려줍니다. GPU 프로비저닝, 스케일링 정책, 용량 계획을 고민할 필요가 없습니다. 코드를 작성하고 배포하면 시스템이 어떤 수요든 알아서 대응합니다. 프로토타입 챗봇, 문서 요약기, 사내 AI 도구 같은 초기 애플리케이션에게 이것은 단순한 편의가 아니라 출시 여부를 가르는 차이입니다.
이 단계에서는 사용량 자체가 불확실하기 때문에 비효율은 문제가 되지 않습니다. 우리는 인프라 효율이 아니라 반복(iteration) 속도에 최적화하고 있는 것입니다.
첫 번째 전환점: 지연 시간이 제품 문제가 되는 순간
인프라 선택이 어긋나기 시작했다는 첫 번째 신호는 청구서 대시보드가 아니라 사용자 경험에서 나타납니다. 사용량이 조금씩 늘어나면 지연 시간은 이론적인 지표에서 눈에 보이는 현실이 됩니다.
서버리스 시스템은 탄력성(elasticity)을 기반으로 설계되었고, 탄력성에는 곧잘 변동성이 따릅니다. 환경이 이미 웜업(warm) 상태라면 요청은 즉시 반환되지만, 콜드 스타트나 모델 로딩이 발생하면 상당히 오래 걸릴 수 있습니다. 단건으로 보면 감수할 만하지만, 사용자를 마주하는 시스템에서는 평균 성능보다 일관성 없음이 훨씬 더 도드라집니다.
고객 지원 워크플로우에 내장된 AI 어시스턴트나 IDE 안의 코드 생성 기능을 생각해보세요. 두 경우 모두 사용자는 반응이 즉각적이고 예측 가능하기를 기대합니다. 몇 번의 느린 응답은 평균으로 상쇄되지 않고 오히려 돋보입니다. 인프라 세부 사항이던 것이 제품 결함이 되어버리는 순간입니다.
두 번째 전환점: 비용이 누적되기 시작할 때
시스템이 커지면 사용 패턴이 규칙적으로 변합니다. 가끔 들어오던 요청은 꾸준한 트래픽이 되고, 실험이던 기능은 일상적인 사용의 일부가 됩니다. 바로 이 시점부터 서버리스 가격 구조가 다르게 느껴지기 시작합니다.
서버리스는 사용량을 예측할 수 없을 때 빛을 발합니다. 실행될 때만 비용을 지불하면 되니까요. 하지만 시스템이 항상 활성 상태가 되어 연속적인 요청을 처리하거나 백그라운드 작업을 돌리기 시작하면, 같은 작업에 대해 계속해서 비용을 지불하게 됩니다. 시간이 지나면 그 편리함이 점점 비싸집니다.
이 지점에서 고정된 GPU 위에 모델을 올려두는 전용 인프라가 더 합리적으로 보이기 시작합니다. 비용에 대한 통제권이 생기고, 리소스를 효율적으로 사용한다면 성능도 더 안정적입니다.
여기서 뭔가 잘못된 것은 없습니다. 단지 시스템이 성장하여 이전 설정이 더 이상 가장 비용 효율적인 선택이 아니게 된 것뿐입니다.
결정을 좌우하는 것은 플랫폼이 아니라 워크로드의 형태다
시간이 지나면 분명해지는 사실이 있습니다. 이 결정은 본질적으로 두 플랫폼 중 하나를 고르는 문제가 아니라, 우리 워크로드가 어떻게 동작하는지, 그리고 그 동작이 어떻게 변하는지를 이해하는 문제라는 점입니다.
많은 팀이 범하는 실수는 현재의 워크로드 형태가 영원할 것이라고 가정하는 것입니다. 실제로 대부분의 시스템은 여러 상태를 거칩니다. 애플리케이션은 급변하는(spike) 사용 패턴으로 시작해, 반예측적인 일일 주기를 거쳐, 결국 안정적인 고처리량 패턴으로 정착하는 경우가 많습니다. 각 단계마다 유리한 접근 방식이 다릅니다.
중간 단계: 가장 험난한 구간
가장 어려운 단계는 시작도 끝도 아니라 그 사이의 전환기입니다. 이 구간에서는 아무것도 고장 나지 않았는데도 시스템이 뭔가 '어긋나 있는' 느낌이 듭니다. 지연 문제가 간헐적으로 나타나지만 항상 그런 것은 아니고, 비용도 오르기 시작하지만 아키텍처 전면 개편을 정당화할 만큼은 아닙니다. 개발자들은 응답 캐싱, 환경 프리워밍(pre-warming), 동시성 조정 같은 우회책을 추가하기 시작합니다. 이런 변경은 일시적으로 도움이 되지만, 동시에 시스템이 원래 설계된 용도 이상으로 밀어붙여지고 있다는 신호이기도 합니다.
성장 중인 AI 고객 지원 어시스턴트를 다시 예로 들어보겠습니다. 초기에는 소수의 문의를 처리할 수 있었지만, 사용자가 늘면서 피크 타임에 수백 건의 요청을 처리하게 됩니다. 대부분의 응답은 여전히 빠르지만, 콜드 스타트나 스케일링 지연 때문에 눈에 띄게 느린 응답이 섞입니다. 팀은 반복 질문에 대한 캐싱을 추가하고 지연 스파이크를 줄이기 위해 프리워밍을 시도합니다. 동시에 시스템이 더 일관되게 돌아가면서 월간 비용도 증가합니다. 그러나 트래픽이 아직 충분히 안정적이지 않아, 심야 시간에 놀고 있을 수도 있는 전용 GPU로 넘어가기는 애매합니다. 기술적으로는 작동하지만 끊임없는 튜닝이 필요하고, 서버리스도 전용 인프라도 완벽하게 맞지 않는 답답한 중간지대가 만들어지는 것입니다.
대규모 운영 단계
어느 시점이 되면 시스템은 더 이상 예측 불가능하지 않습니다. 대략 얼마나 많은 요청이 들어오는지, 피크 타임이 언제인지 알게 됩니다. 추측이 사라지는 순간입니다.
이제 당신은 멈추지 않고 돌아가는 시스템에 대해 요청 건당 비용을 지불하고 있습니다. 한때 간헐적이던 콜드 스타트는 이제 용납할 수 없는 수준이 됩니다. 사용자는 빠르고 일관된 응답에 익숙해졌고, 조금의 변동도 눈에 띕니다. 초반에 빠른 개발을 가능하게 해준 인프라가 이제는 발목을 잡는 존재가 된 것입니다.
전용 추론은 이 문제를 깔끔하게 해결합니다. GPU를 확보하면 모델은 항상 로드된 상태를 유지하고, 모든 요청이 동일한 경험을 받습니다. 공유도, 기동 지연도, 변수도 없습니다.
경제성도 달라집니다. 시스템이 항상 활성 상태라면 예약형 컴퓨팅에 대한 지불이 종량제보다 저렴해집니다. Together.ai의 전용 엔드포인트를 예로 들면, H100 기준 시간당 약 $3.99부터 시작합니다. 꾸준한 트래픽이라면 서버리스에서 지출하던 금액보다 적은 경우가 많고, 성능까지 더 좋습니다.
얻는 것은 낮은 비용이나 빠른 응답만이 아닙니다. 바로 안정성입니다. 인프라를 계속 튜닝하는 대신 신뢰할 수 있게 되고, 그제서야 하부 레이어 관리가 아닌 제품 자체에 온전히 집중할 수 있습니다.
물론 서버리스가 완전히 사라지는 것은 아닙니다. 예상치 못한 트래픽 급증, 실험적 기능, 저빈도 작업 같은 엣지 케이스는 여전히 서버리스가 담당합니다. 다만 더 이상 핵심 워크로드를 짊어지지 않을 뿐입니다. 이제 그 역할은 전용 인프라가 맡습니다.
개발자가 실제로 경험하는 서버리스 추론 플랫폼
이런 시스템들의 실제 동작을 이해하는 좋은 방법은 개발자들이 널리 쓰는 두 플랫폼, Modal과 Together.ai를 어떻게 사용하는지 살펴보는 것입니다. 두 플랫폼 모두 인프라를 추상화한다는 비슷한 철학에서 출발하지만, 그 추상화가 실무에서 어떻게 드러나는지(특히 가격과 스케일링 측면에서)를 보면 잘 작동하는 부분과 트레이드오프가 시작되는 지점이 드러납니다.
Modal
Modal은 컴퓨팅 시간에 대해서만 지불하는 서버리스 모델을 중심으로 설계되었습니다. GPU 사용량은 초 단위로 과금되며, L4 같은 소형 GPU는 초당 약 $0.0002, H100 같은 고성능 GPU는 초당 약 $0.0011 수준입니다. 이를 시간당으로 환산하면 하드웨어에 따라 대략 $0.8~$4입니다. 월 약 $30 상당의 무료 크레딧이 제공되는 프리티어도 있어 초기 비용 없이 쉽게 시작할 수 있습니다. 실제로 이 모델은 버스트성 워크로드에 매우 잘 맞습니다. 사용자가 트리거할 때만 트래픽이 들어오는 이미지 생성 API나 하루 몇 번 실행되는 백그라운드 작업이 좋은 예입니다. 유휴 GPU에 대한 비용을 지불하지 않고, 스케일링도 자동으로 이루어집니다. 하지만 사용이 연속적으로 이어지면 상황이 달라집니다. 하루 종일 이미지를 처리하는 실시간 객체 탐지 모델을 운영한다고 가정해보세요. 시스템이 항상 사용 중이므로 '사용할 때만 지불'의 이점은 사라집니다. 대신 같은 GPU를 작은 단위로 계속 반복해서 임대하는 셈인데, 누적 비용은 하나를 상시 가동하는 것보다 오히려 높아지는 경우가 많습니다. 동시에 콜드 스타트와 컨테이너 재사용 같은 성능 특성이 만들어내는 변동성도 프로덕션 환경에서는 점점 더 무시하기 어려워집니다.
Together.ai
Together.ai는 서버리스 API에서 출발하지만, 성장하는 시스템에 흥미로운 점은 니즈가 변해도 플랫폼을 강제로 바꿀 필요가 없다는 것입니다. 기본 API 사용에서 전용 GPU 엔드포인트로 이동하더라도 코드를 변경할 필요가 없습니다.
입문 단계에서는 토큰 단위로 지불합니다. 모델에 따라 백만 토큰당 약 $0.10~$3 수준으로, 트래픽이 적거나 예측 불가능할 때 적합합니다. 오토스케일링이 기본 제공되고 관리할 인프라도 없습니다. 대부분의 사용 사례에 합리적인 출발점입니다.
트래픽이 늘고 지연 시간이 중요해지면, Together.ai는 전용 엔드포인트로 전환할 수 있게 해줍니다. 하드웨어를 직접 선택합니다. H100은 시간당 약 $3.99, H200은 시간당 약 $5.49 수준이며, 해당 GPU는 온전히 당신의 것입니다. 공유 컴퓨팅도, 다른 워크로드의 간섭도 없습니다. 모델은 항상 로드된 상태를 유지하고, 지연 프로파일은 일관성을 갖게 됩니다.
트레이드오프는 모든 전용 설정에서 마주하는 것과 같습니다. 심야 시간대에 트래픽이 줄어도 GPU는 계속 돌아갑니다. 사용 여부와 관계없이 용량에 대한 비용을 지불하는 것이죠. 워크로드가 꾸준하다면 이는 문제가 되지 않습니다.
확장 중인 팀 입장에서 Together.ai의 실질적인 장점은 마이그레이션 경로가 플랫폼 내부에 있다는 점입니다. 전용 성능을 얻기 위해 통합 코드를 다시 만들 필요 없이, 엔드포인트 설정만 바꾸면 됩니다. 전환이 너무 번거롭다는 이유로 미루지 않고 적절한 시점에 전환할 수 있게 해주는, 실질적인 장벽 제거입니다.
예를 들어 중형 모델을 실행하는 비용은 백만 입력 토큰당 약 $0.10~$0.60 수준이며, 출력 토큰은 모델에 따라 더 높아질 수 있습니다. 비용이 사용량에 비례하기 때문에 챗봇이나 텍스트 생성 API 같은 사용 사례에서 직관적입니다. 하루 수백만 토큰을 생성하는 고객 지원 봇이라면 볼륨에 따라 월 수십~수백 달러의 비용이 들 수 있습니다. 한편 워크로드가 안정화되면 Together.ai는 H100 기준 시간당 약 $3.99부터 시작하는 전용 GPU 엔드포인트를 제공합니다. 이는 흔히 나타나는 패턴을 보여줍니다. 개발자는 간단한 API 기반 사용으로 시작하지만, 트래픽이 안정화되고 지연 기대치가 높아지면 더 예측 가능한 성능과 비용을 위해 전용 구성으로 이동하는 경우가 많습니다.
중요한 전환은 플랫폼이 아니라 시간에 따른 사용 방식에 있습니다:
- 초기 단계 → 단순한 API처럼 사용
- 성장 단계 → 지연 시간과 비용이 고민거리가 되기 시작
- 확장 단계 → 같은 플랫폼 안에서 전용 엔드포인트로 전환
즉, 순수 서버리스 플랫폼과 달리 반드시 공급자를 바꿀 필요가 없습니다. 모드(mode)를 바꾸는 것입니다.
결정하기 전에 고려할 사항
- 비용은 생각과 다르게 누적됩니다: 서버리스 플랫폼은 컴퓨팅이 사용된 매 초마다 고정된 온디맨드 요율을 부과합니다. 시스템이 유휴 상태일 때는 이 모델이 효율적입니다. 하지만 시스템이 연속적으로 돌아가면 같은 요율이 하루 24시간, 할인 없이 적용됩니다. 예약 용량(reserved capacity)을 지원하는 인프라는 실효 시간당 비용을 크게, 경우에 따라 절반 이상 낮출 수 있습니다. 워크로드가 예측 가능한 상태로 오래 유지될수록 그 격차는 커집니다.
- 관리형 기본값은 시간이 지나면 제약이 됩니다: 관리형 추론 플랫폼은 때때로 설정 결정을 대신 내려줍니다. 어떤 최적화를 적용할지, 메모리를 어떻게 처리할지, 요청을 어떻게 배치(batching)할지 말입니다. 초기에는 이런 기본값이 시간을 절약해주지만, 나중에 자신의 워크로드에 맞게 추론 레이어를 튜닝해야 할 때 같은 기본값이 발목을 잡습니다. 설정에 접근할 수 없다면 변경할 수도 없습니다. 인프라를 소유한다는 것은 그 설정들이 당신의 것임을 의미합니다.
- 가시성은 플랫폼이 보여주는 범위로 제한됩니다: 관리형 플랫폼에서 장애가 발생하거나 비용이 예기치 않게 급등했을 때, 조사 능력은 플랫폼이 만든 대시보드 범위 안에 머뭅니다. 무엇이 느리고 비싼지는 볼 수 있지만, 인프라 레이어에 손이 닿지 않으면 정확한 원인을 추적하기 어렵습니다. 전용 인프라는 컴퓨팅, 네트워킹, 스토리지 전반에 걸친 완전한 관찰 가능성(observability)을 제공합니다. 모든 것을 보고, 그에 따라 행동할 수 있습니다.
- 더 많은 통제는 더 많은 책임을 의미합니다: 인프라를 직접 소유하면 낮은 비용, 깊은 통제권, 완전한 가시성을 얻습니다. 하지만 그만큼 관리형 플랫폼이 대신 처리해주던 설치와 운영 업무를 떠안게 됩니다. 팀이 작거나 워크로드가 아직 변화 중이라면 항상 옳은 선택은 아닙니다. 다만 좋은 플랫폼은 관리형과 자체 관리형 사이의 간격을 좁혀주는 균형점을 찾아줍니다. 일부 인프라 플랫폼은 사전 구성된 추론 이미지, 원클릭 GPU 배포, 기본 제공되는 Kubernetes 지원 등을 함께 제공하여 처음부터 전부 직접 만들 필요가 없게 해줍니다. 운영 부담은 여전히 존재하지만, 예전보다 훨씬 가벼워졌습니다.
결론
서버리스 추론은 빠르게 시작하고, 실험하고, 마찰 없이 출시할 수 있는 속도를 제공합니다. 하지만 시스템이 성장하면, 한때 당신을 빠르게 만들어주던 그 추상화가 가장 중요한 것들—지연 시간 일관성, 처리량, 비용 효율성—을 가리기 시작합니다. Modal과 Together.ai 같은 플랫폼은 초기에 쉽게 만들고 확장할 수 있게 해주며, 많은 경우 이후에도 아키텍처의 일부로 남습니다. 그러나 워크로드가 예측 가능해지고 기대치가 높아지면, 더 많은 통제에 대한 필요는 피할 수 없게 됩니다. 현실의 시스템은 정적이지 않습니다. 불확실성에서 예측 가능성으로, 실험에서 프로덕션으로 이동합니다. 그리고 그 과정에서 '올바른' 인프라 선택 역시 함께 이동합니다. 팀이 저지르는 진짜 실수는 서버리스를 장기적인 기본값으로 취급하는 것입니다. 서버리스의 본질은 하나의 '단계(phase)'라는 점을 기억해야 합니다. 워크로드가 안정화된 후 전용 인프라로의 전환을 미룰수록, 비용과 성능, 혹은 그 양쪽에서 더 많은 대가를 치르게 됩니다.
이 저작물은 Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License에 따라 라이선스가 부여됩니다.