Anthropic CEO 다리오 아모데이는 최근 AI 스케일링에 대해 "끝은 없다"는 취지의 낙관론을 내놨습니다. 적어도 프런티어 모델 관점에서, 더 많은 연산과 더 큰 시스템이 계속 성능 향상을 만들고 있다는 주장입니다.1
중요한 건 이 발언이 맞느냐 틀리냐보다, 이제 "스케일링"이라는 말을 어떻게 해석해야 하느냐입니다. 지금 많은 팀은 모델을 덜 키워서 실패하는 게 아니라, 잘못된 층을 키워서 실패합니다.
예전엔 스케일링이 거의 곧 파라미터 증가를 뜻했습니다. 하지만 최근 현장에서는 병목이 더 자주 다른 곳에서 나타납니다. 데이터 품질, 메모리, 추론 시 계산량, 보안과 네트워크, 배포 파이프라인, 평가와 거버넌스 같은 운영 레이어입니다.234 같은 "성능 문제"처럼 보여도, 해법은 전혀 다를 수 있습니다.
이제 스케일링은 5가지 질문으로 쪼개서 봐야 한다
실무적으로 AI 스케일링은 적어도 다섯 갈래로 나뉩니다.
첫째, 모델 스케일링입니다. 파라미터, 학습 연산량, 학습 데이터 크기를 늘리는 전통적 방식입니다. 신경망 스케일링 법칙은 이런 투자가 일정 구간까지 예측 가능한 성능 개선을 만든다고 봅니다.5 아모데이의 발언도 기본적으로 이 축에 서 있습니다.1
둘째, 데이터 스케일링입니다. 여기서 중요한 건 양만이 아니라 적합도입니다. 위키피디아 요약에도 나오듯, 더 많은 데이터가 항상 더 좋은 결과를 뜻하진 않습니다. 특히 후속 미세조정 단계에서는 소량의 고품질 데이터가 더 큰 효과를 내는 경우가 있습니다.5
셋째, 메모리 스케일링입니다. Databricks는 에이전트 성능이 모델 가중치가 아니라 외부 메모리 축적에 따라 좋아질 수 있다고 주장합니다. 과거 대화, 피드백, 성공·실패 궤적, 조직 지식을 잘 저장하고 검색하면 정확도와 효율이 함께 오른다는 실험 결과를 제시했습니다.4 즉 "모델이 멍청하다"가 아니라 "필요한 맥락을 못 받는다"가 병목일 수 있습니다.
넷째, 추론 시간 스케일링입니다. 더 오래 생각하게 하거나, 더 많은 테스트 타임 컴퓨트를 쓰는 방식입니다. 최근 고성능 모델 경쟁은 훈련 시점만이 아니라 배포 시점의 계산 예산 배분으로도 이어지고 있습니다.5
다섯째, 인프라와 운영 스케일링입니다. AWS는 AI 스케일링을 조직 전반의 기술·인재·프로세스 문제로 설명하고, MLOps와 표준화, 거버넌스를 핵심으로 봅니다.2 Cisco는 대규모 AI 환경에서 오히려 보안이 병목이 된다고 지적합니다. 예컨대 동서 트래픽 보호나 암호화 트래픽 검사에서 지연과 전력, 공간 비용이 급증할 수 있다는 얘기입니다.3
성능이 안 나올 때, 모델을 키울지 시스템을 고칠지 먼저 구분하라
실무에서 가장 비싼 실수는 "결과가 안 좋다 = 더 큰 모델이 필요하다"로 바로 점프하는 것입니다.
질문이 복잡하고 일반 지능 한계가 명확하다면 모델 업그레이드가 맞을 수 있습니다. 하지만 기업용 에이전트, 사내 검색, 분석 도우미, 업무 자동화처럼 맥락 의존적인 문제는 retrieval 품질, 권한 체계, 도구 호출 실패, 피드백 루프 부재가 더 흔한 원인입니다.
Databricks 실험은 이 점을 잘 보여줍니다. 사용자 로그와 메모리를 축적한 에이전트는 성능이 상승했고, 평균 추론 단계는 약 19~20단계에서 4~5단계 수준으로 줄었습니다.4 같은 모델이라도 "무엇을 기억하고 꺼내오느냐"가 생산성을 크게 바꾼다는 뜻입니다.
반론도 있습니다. 메모리를 키운다고 늘 좋아지는 건 아닙니다. 저품질 기록이 쌓이면 잘못된 습관을 학습하고, 저장소가 커질수록 검색 난도도 올라갑니다.4 그래서 메모리 스케일링은 단순 적재가 아니라 선별, 요약, 권한 관리까지 포함한 설계 문제입니다.
AI 스케일링의 승부처는 점점 연구실 밖으로 이동하고 있다
프런티어 랩은 여전히 더 큰 연산 덩어리를 밀어붙이겠지만, 대부분의 기업에는 다른 현실이 있습니다. 모델 자체보다 배포와 통제가 더 어려운 단계로 들어가고 있습니다.
Meta는 더 강한 AI일수록 더 강한 평가·배포 프레임워크가 필요하다며, 위험 평가 범위를 넓히고 배포 전후 테스트와 보고 체계를 강화했다고 밝혔습니다.6 이건 "좋은 모델을 만들기"에서 "안전하게 반복 운영하기"로 무게중심이 이동하고 있음을 보여줍니다.
AWS의 설명도 비슷합니다. AI를 확장한다는 것은 파일럿 몇 개를 돌리는 게 아니라, 표준화된 배포·모니터링·재학습·거버넌스 루프를 조직 안에 심는 일입니다.2 다시 말해 다음 단계의 경쟁력은 모델 접근권만이 아니라, 평가 체계와 운영 품질에서 나올 가능성이 큽니다.
아모데이의 말은 아마 기술적으로는 한동안 맞을 수 있습니다. 하지만 대부분의 팀에게 더 유용한 질문은 이것입니다. "AI를 얼마나 더 크게 만들 수 있나?"가 아니라 "우리 시스템에서 다음 병목은 어디인가?"
이 질문이 필요한 사람은 분명합니다. 에이전트 제품을 만들고 있는 팀, 사내 AI를 전사 배포하려는 리더, GPU 예산을 늘릴지 워크플로를 다시 설계할지 고민하는 조직입니다. 지금 봐야 할 건 단순한 모델 크기 경쟁이 아니라, 어떤 층을 스케일해야 실제 성능과 사업 성과가 같이 오르는가입니다.
참고
1Anthropic CEO Amodei declares "there is no end to the rainbow" for AI scaling
2AI 스케일링이란 무엇인가요? - AI 스케일링 설명 - AWS
3Designing for What's Next: Securing AI-Scale Infrastructure
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.