새로운 유형의 제품이 나타나기 시작했습니다.

이 제품들은 AI를 사용하지만, 우리가 익숙해진 방식과는 다릅니다. 클라우드에 있는 거대 모델, API 키, 토큰 예산, 또는 가격, 접근성, 지연 시간(latency), 정책을 언제든 변경할 수 있는 벤더(vendor)에 의존하지 않습니다.

대신, 이러한 제품들은 매우 구체적인 작업을 위해 훈련되거나 최적화된 작고 로컬한 모델(small, local models)을 사용합니다. 이들은 당신의 노트북, 휴대폰, 브라우저, 또는 기업 자체의 인프라 내부에서 실행됩니다. 이들은 모든 것을 하려고 하지 않습니다. 사용자 근처에서, 더 적은 마찰과 더 많은 제어권을 가지고, 단 한 가지 일을 잘 해내려고 노력합니다.

저는 이것이 현재 AI 분야에서 일어나고 있는 가장 흥미로운 제품 트렌드 중 하나라고 생각합니다.

지난 몇 년 동안 업계는 규모(scale)에 집착해 왔습니다. 더 큰 모델, 더 큰 컨텍스트 윈도우(context windows), 더 큰 데이터 센터, 더 큰 데모, 더 큰 약속들 말입니다. 대부분의 대화는 프론티어(frontier)에 집중되었습니다. 어떤 모델이 더 똑똑한지, 어떤 벤치마크(benchmark)가 깨졌는지, 그리고 어떤 회사가 앞서 나가고 있는지에 대해서 말이죠.

그 부분도 중요합니다. 중요하지 않다고 부정하는 것이 아닙니다. 프론티어 모델(Frontier models)은 인상적이며, 많은 복잡한 작업에서 여전히 최선의 선택지입니다. 하지만 규모에 대한 집착이 우리로 하여금 똑같이 중요할 수 있는 또 다른 방향을 간과하게 만들었다고 생각합니다. 그것은 바로 더 나은 소프트웨어에 내장된 더 작은 모델들입니다.

대부분의 사람들은 모든 상호작용에 있어 가능한 가장 큰 모델을 필요로 하지 않습니다. 그들에게 필요한 것은 워크플로(workflow)를 이해하고, 모든 작은 동작을 클라우드 요청으로 전환하지 않으면서 일상적인 업무를 처리하는 소프트웨어입니다.

그 지점에서 작은 AI(small AI)가 흥미로워집니다. 일반적인 프론티어 AI보다 더 강력하기 때문이 아니라, 더 적절할(appropriate) 수 있기 때문입니다.

그리고 제품 디자인에서, '적절함'은 종종 '강력함'을 이깁니다.

모든 AI 제품이 챗봇이어야 한다고 생각하는 실수

오늘날 많은 AI 소프트웨어는 마치 다른 옷을 입은 똑같은 제품처럼 느껴집니다. 텍스트 박스, 반짝이는 아이콘, 사이드바, 구독 모델, 그리고 어쨌든 어시스턴트가 모든 것을 더 좋게 만들어 줄 것이라는 약속이 존재합니다.

때로는 그럴 때도 있습니다. 하지만 종종 AI가 제품에 실제로 필요해서가 아니라, 시장이 기대하기 때문에 추가된 것처럼 느껴질 때가 많습니다.

더 흥미로운 형태의 AI는 워크플로 (workflow) 옆에 앉아 있는 챗봇 (chatbot)이 아닙니다. 그것은 워크플로 내부에 존재하는 지능입니다. 즉, 제품이 사용자가 이미 무엇을 하려고 하는지 이해하고, 마찰 (friction)이 발생하는 정확한 순간에 그 요소를 제거하는 것입니다.

이를 위해서는 거대한 범용 모델 (general-purpose model)이 필요하지 않습니다. 사실, 거대한 모델은 잘못된 추상화 (abstraction)가 될 수 있습니다. 작업이 좁고, 반복적이며, 비공개적이고, 구조화되어 있다면, 더 작은 로컬 모델 (local model)이 더 빠르고, 저렴하며, 안전하고, 신뢰하기 쉬울 수 있습니다.

이 부분이 사람들이 과소평가하고 있다고 생각하는 지점입니다. AI 제품의 미래는 단순히 모델을 더 똑똑하게 만드는 것에 그치지 않을 것입니다. 또한 지능이 어디에 머물러야 하는지를 결정하는 것에 관한 것이 될 것입니다. 클라우드 (cloud)에 둘 것인지, 기업의 프라이빗 인프라 (private infrastructure)에 둘 것인지, 아니면 사용자 기기 (device) 위에서 제품 전체를 플랫폼 (platform)으로 바꾸지 않으면서 조용히 유용한 작업을 수행하게 할 것인지 말입니다.

로컬 AI는 더 이상 장난감이 아니다

몇 년 전만 해도 로컬 모델은 쉽게 무시될 수 있었습니다. 데모 (demo)나 오픈 소스 (open-source) 실험용으로는 재미있었지만, 사용자 경험은 대개 클라우드보다 좋지 않았습니다. 모델은 더 작고, 느리고, 능력이 떨어졌으며, 실행하기도 더 어려웠습니다. 잠재력은 볼 수 있었지만, 많은 미숙한 부분들을 감내해야 했습니다.

그 상황이 변하고 있습니다. 완전히 그렇다거나 마법처럼 하룻밤 사이에 일어나는 일은 아니지만, 제품 기획자들이 주목해야 할 만큼은 변했습니다.

Google의 Gemini Nano documentation은 온디바이스 AI (on-device AI)가 개인정보 보호, 저비용, 오프라인 작동이 중요한 사례에 유용하다고 설명합니다. Microsoft 또한 Edge의 Prompt API와 Writing Assistance APIs를 포함하여, 개인정보 보호와 지연 시간 (latency) 감소를 강점으로 내세우며 더 많은 AI 기능을 브라우저와 기기 내부로 옮기고 있습니다.

그것이 바로 신호입니다. 로컬 AI (Local AI)는 더 이상 단순한 취미 활동의 이야기가 아닙니다. 그것은 하나의 플랫폼 방향성 (platform direction)이 되고 있습니다.

중요한 점은 모든 로컬 모델이 갑자기 최고의 클라우드 모델을 이기는 것이 아닙니다. 그것은 사실이 아니며, 사실일 필요도 없습니다. 중요한 점은 많은 워크플로우 (workflows)가 적절한 제품에 담긴 '충분히 괜찮은 (good-enough)' 모델만을 필요로 한다는 것입니다. 특히 그 모델이 프라이빗 (private)하고, 빠르며, 저렴하고, 오프라인 상태에서 사용자의 통제 하에 있을 때 더욱 그렇습니다.

클라우드 의존성 문제의 명확화

현재의 AI 스택 (AI stack)에는 많은 기업이 말하고 싶어 하지 않는 약점이 있습니다. 바로 많은 제품이 타인의 모델 위에 구축된 얇은 계층 (thin layers)에 불과하다는 점입니다.

첫 번째 파도 동안에는 그것이 이해할 수 있는 일이었습니다. 덕분에 사람들은 빠르게 구축하고, 아이디어를 검증하며, 이전에는 불가능했을 것들을 출시할 수 있었습니다. 거기서 시작하는 것 자체에는 아무런 문제가 없습니다.

하지만 시간이 흐르면서, 그러한 의존성은 **제품의 리스크 (product's risk)**의 일부가 됩니다.

만약 당신의 제품이 전적으로 클라우드 모델에 의존한다면, 당신의 제품은 해당 벤더 (vendor)의 가격 책정, 속도 제한 (rate limits), 지연 시간 (latency), 서비스 중단 (outages), 모델 업데이트, 정책 변경, 액세스 규칙, 그리고 데이터 경계 (data boundaries)에도 의존하게 됩니다. 당신은 단순히 기능을 구매하는 것이 아닙니다. 당신은 타인의 제약 사항을 당신 제품의 일부로 받아들이고 있는 것입니다.

이것은 더 이상 이론적인 이야기가 아닙니다. 가장 유능한 모델에 대한 접근은 고객 등급, 지역적 가용성, 안전 검토 (safety reviews), 엔터프라이즈 계약, 사용 정책, 또는 규제 압력에 의해 조건부로 결정될 수 있습니다. 제품 개발 측면에서의 교훈은 간단합니다. 프런티어 역량 (frontier capability)은 단순한 기술적 의존성이 아닙니다. 그것은 **정책적 의존성 (policy dependency)**이 될 수도 있습니다.

이것은 빌더 (builders)들이 생각하는 방식을 변화시킵니다.

만약 당신 제품의 가장 중요한 부분이 다른 회사나 정부 프로세스에 의해 제한되거나, 지연되거나, 가격이 재조정되거나, 형태가 바뀔 수 있다면, 당신의 제품은 온전히 당신의 것이 아닙니다. 민감한 정보, 기업 내부 데이터, 또는 전문적인 신뢰가 포함된 워크플로우 (workflows)의 경우, 이는 실질적인 약점이 됩니다.

작은 로컬 모델 (Small local models)이 이 문제의 모든 버전을 해결해 주는 것은 아닙니다. 하지만 이는 모든 의사결정을 클라우드로부터 빌려오는 대신, 일부 지능을 제품 자체로 다시 이동시키는 것을 가능하게 합니다.

비용이 문제를 강제할 것입니다

개인정보 보호 (Privacy)는 사람들이 공개적으로 내세우기 좋아하는 논거입니다. 하지만 기업 내부의 아키텍처 (architectures)를 변화시킬 논거는 바로 비용입니다.

AI 파도의 초창기에는 그저 무언가를 작동시키는 것이 목표였습니다. 가장 강력한 모델을 사용하고, 전체 컨텍스트 (context)를 전송하며, 프롬프트 체이닝 (chain prompts)을 수행하고, 재시도 (retries)를 추가하고, 에이전트 (agents)를 도입한 뒤, 비용 문제는 나중에 걱정하는 식이었습니다.

모두가 탐색 단계에 있을 때는 그것이 합리적이었습니다. 하지만 비용은 무시하기 점점 어려워지고 있으며, 기업들은 모든 작업에 값비싼 모델이 필요하지 않다는 사실을 깨닫기 시작했습니다.

많은 제품의 첫 번째 버전은 가장 빠른 경로라는 이유로 너무 많은 작업을 클라우드로 보냈습니다. 다음 버전은 더 명확한 작업들을 사용자에게 더 가깝게 이동시킬 것입니다. 즉, 전송 전 비식별화 (redacting), 더 깨끗한 컨텍스트 준비, 공격적인 캐싱 (caching), 그리고 제품이 원격 모델 호출을 필요로 하지 않을 때 좁은 범위의 작업을 로컬에서 처리하는 방식입니다.

이것은 "에이전트가 모든 것을 할 것이다"라고 말하는 것만큼 흥미롭지는 않지만, 아마도 지속 가능한 AI 제품이 나아갈 모습에 더 가까울 것입니다.

많은 유용한 작업은 최첨단 추론 (frontier reasoning)이 아닙니다. 그것은 제약 조건이 있는 패턴 인식 (pattern recognition)입니다. 지저분한 입력을 구조화된 출력 (structured output)으로 변환하거나, 정보가 유출되기 전에 민감한 정보를 찾아내거나, 사용자가 동일한 작은 워크플로우 (workflow)를 백 번째 반복하고 있다는 것을 인식하는 것과 같은 작업들입니다.

이것들은 약한 유스케이스 (use cases)가 아닙니다.

이것들이 바로 소프트웨어의 대부분입니다.

오픈 모델 (Open Models)이 최첨단에 가까워지고 있습니다

이 트렌드가 보이는 것보다 더 크게 느껴지는 또 다른 이유는 모델 생태계가 여러 계층에서 동시에 개선되고 있기 때문입니다.

상위 계층에서는 오픈 모델 (open models)이 기업들이 진지하게 고려해야 할 만큼 강력해지고 있습니다. GLM-5.2는 이러한 발전 방향을 보여주는 좋은 사례입니다: 더 강력한 코딩 (coding) 능력, 장기적 과제 (long-horizon task) 지원, 1M-토큰 컨텍스트 윈도우 (context window), 그리고 허용 범위가 넓은 라이선스 (permissive license)를 갖추고 있습니다.

흥미로운 점은 GLM-5.2가 작다는 것이 아닙니다. 그렇지 않습니다. 흥미로운 점은 오픈 모델이 OpenAI, Anthropic, Google과 같은 폐쇄형 프런티어 연구소 (proprietary frontier labs)와 연관된 최첨단 (state of the art) 기술 수준에 점점 더 가까워지고 있다는 사실입니다. Z.ai는 여러 장기적 코딩 벤치마크 (long-horizon coding benchmarks)에서 GLM-5.2를 Anthropic의 플래그십 모델인 Opus 4.8 근처에 위치시키고 있으며, 벤더 벤치마크 (vendor benchmarks)를 통상적인 주의를 기울여 다루더라도 그 방향성은 무시하기 어렵습니다.

이는 시장의 형태를 변화시킵니다. 상단에서는 오픈 모델이 폐쇄형 프런티어 시스템 (proprietary frontier systems)에 대한 의존도를 낮춥니다. 하단에서는 특화된 로컬 모델 (specialized local models)이 좁은 범위의 워크플로 (workflows)를 위해 클라우드 호출 (cloud calls)에 의존하는 것을 줄여줍니다.

이것이 제가 미래가 단순히 "폐쇄형 클라우드 모델 대 로컬 모델"이라고 생각하지 않는 이유입니다. 그러한 프레임워크는 너무 단순합니다. 더 유용한 질문은 워크플로의 어느 부분이 사용자 근처에 머물러야 하며, 어느 부분이 다른 곳으로 보낼 가치가 있는가 하는 점입니다.

작은 AI는 진정한 안티 블로트 (Anti-Bloat) 소프트웨어입니다

제가 이 트렌드를 좋아하는 이유는 기술적인 이유뿐만이 아닙니다. 미학적인 이유이기도 합니다.

A lot of software has become too big for what it does. SaaS는 확장을 보상했고, 그래서 모든 제품은 플랫폼 (platform)이 되고 싶어 했습니다. 모든 집중된 도구 (focused tool)는 서서히 워크스페이스 (workspace)로 변했습니다. 모든 워크스페이스는 스위트 (suite)가 되었습니다. 모든 스위트는 AI를 추가했습니다. 그리고 이제 모든 AI 기능은 어시스턴트 (assistant)가 되고 싶어 합니다.

그 결과는 너무 많은 기능, 너무 많은 설정, 너무 심한 락인 (lock-in), 그리고 너무 부족한 미적 감각을 가진 비싼 소프트웨어입니다.

작은 로컬 AI (Small local AI)는 정반대 방향으로 나아갑니다. 모델이 곧 제품일 필요는 없습니다. 모델은 제품의 작은 부분으로서, 도움이 필요한 정확한 위치에 배치될 수 있습니다. 즉, 전체 경험을 대화형으로 바꾸지 않으면서도 좁은 범위의 워크플로 (workflow)를 더 빠르게 만들고, 사용자가 또 다른 카테고리의 개인 데이터를 또 다른 클라우드 서비스에 맡기도록 요구하지 않으면서 소프트웨어를 개선하는 것입니다.

이는 모델이 아니라 워크플로에서 시작됩니다. 사용자가 무엇을 하려고 하는지, 어디에서 마찰 (friction)이 반복되는지, 어떤 프라이버시 경계가 중요한지, 그리고 역량을 갖춘 가장 작은 시스템은 어떤 모습인지가 핵심입니다. AI는 장식이 아닌 지렛대 (leverage)가 됩니다.

이것이 "AI를 추가했다"와 "제품이 더 좋아졌다"의 차이입니다.

진짜 변화는 통제권에 있다

작은 로컬 AI의 가장 큰 영향은 성능이 아닐 수도 있습니다. 그것은 바로 통제권 (control)입니다. 모델이 어디에서 실행되는지, 어떤 데이터가 기기를 떠나는지, 시스템 비용이 얼마나 드는지, 그리고 벤더 (vendor), 정책 변경, 서비스 중단, 또는 가격 업데이트가 워크플로를 망가뜨릴 수 있는지 여부입니다.

우리는 맥락 (context)을 내어주는 것에 너무 무심했습니다. 소셜 네트워크는 사람들이 자신의 삶을 업로드하도록 훈련시켰습니다. SaaS는 기업들이 자신들의 운영 체제를 타인의 데이터베이스로 옮기도록 훈련시켰습니다. 분석 도구들은 제품 팀이 모든 것을 캡처하도록 훈련시켰습니다. 이제 AI는 훨씬 더 많은 것을 요구하고 있습니다. 우리의 문서, 회의, 소스 코드, 고객 대화, 재무 데이터, 의료 기록, 개인적인 생각, 내부 전략, 그리고 미완성된 작업물까지 말입니다.

어쩌면 기본값은 가능한 경우 로컬에서 처리하고, 필요한 경우에만 상위 단계로 넘기며(escalate), 사용자가 경계를 통제할 수 있도록 유지하는 것이어야 할지도 모릅니다.

이것이 생산성보다 더 크게 느껴지는 이 트렌드의 핵심입니다. 이는 우리가 지능형 소프트웨어와 어떤 종류의 관계를 맺고 싶은지를 결정하는 문제입니다.

우리는 지능이 몇몇 중앙 집중식 시스템으로부터 빌려 쓰는 것이 되기를 원합니까, 아니면 우리 자신의 기기, 우리 자신의 도구, 그리고 우리 자신의 조직 내부에서도 살아 숨 쉴 수 있는 것이 되기를 원합니까?

정답은 아마도 둘 다일 것입니다.

하지만 현재 업계는 한쪽 측면에 과도하게 치우쳐 있습니다.

이것은 제품의 미적 감각 (Product Taste)으로의 귀환이다

작은 모델은 당신이 수행할 작업을 이해하도록 강제합니다. 범용 지능 (General Intelligence) 뒤에 숨을 수 없습니다. 당신은 워크플로우 (Workflow), 입력 (Input), 출력 (Output), 실패 모드 (Failure mode), 프라이버시 경계 (Privacy boundary), 그리고 사용자 상호작용 (User interaction)을 정의해야만 합니다. 또한 무엇을 자동화할지, 무엇에 확인 절차가 필요할지, 그리고 모델이 마법처럼 작동하지 않을 때 제품이 어떻게 유용함을 유지할지도 결정해야 합니다.

그러한 제약은 유익합니다.

그것은 프로세스에 미적 감각 (Taste)을 다시 가져다줍니다. 단순히 텍스트 박스를 API에 연결하는 대신 사용자의 워크플로우를 이해하는 빌더 (Builder)들에게 보상을 주며, 복잡성이 적절한 곳에서 처리되어 단순하게 느껴지는 제품들에게 보상을 줍니다. 무엇보다도, 그것은 절제 (Restraint)에 보상을 줍니다.

이것이 제가 흥미롭다고 느끼는 지점입니다. 모든 곳에 AI가 있고, 모든 곳에 챗봇이 있으며, 전체 워크플로우를 대체하는 척하는 거대 시스템이 있는 것이 아닙니다. 그저 더 작은 지능이, 신중하게 배치되어, 사용자와 가까운 곳에서 유용한 일을 수행하는 것입니다.