Page History
...
이 짧은 코드에 액터 모델의 안전 패턴 두 개가 들어 있다. Sender 캡처 — await 너머로 Sender를 그대로 쓰면 그땐 다른 메시지의 sender로 바뀌어 있을 수 있다. 로컬 변수에 먼저 받아 둬야 한다. 개별 실패 격리 — 한 워크스페이스의 Ask가 타임아웃 나도 나머지는 정상 응답한다. 액터 하나의 사고가 시스템 전체 응답을 막지 않는다.
4.2 패러다임 전환 — "똑똑한 제어기"를 자기 옆에 둘 수 있게 된 시대
위의 §4.1은 코드 몇 줄로 끝나는 작은 사례처럼 보이지만, 사실 이 안에 최근 1~2년 사이에 일어난 큰 패러다임 전환이 겹쳐 있다. 이 글에서 한 번은 짚고 넘어가야 하는 지점이다.
예전의 그림은 이랬다. "자연어로 시스템을 제어하는 똑똑한 컨트롤러"가 필요하면, 사실상 선택지는 OpenAI/Anthropic/Google의 클라우드 API 하나뿐이었다. 모델이 크고 정교한 펑션콜(Tool Use)을 안정적으로 해낼 수 있는 곳이 거기밖에 없었기 때문이다. 결과적으로 "고차원 추론"과 "자잘한 기능 호출" 같은 결의 업무가 둘 다 같은 비싼 API 한 곳을 거쳐야 했다. 내부 도구 하나 호출할 때마다 토큰 비용이 붙고, rate limit이 붙고, 사용자 데이터가 밖으로 나가고, 네트워크 지연이 붙었다.
2025년 말~2026년에 이 전제가 무너졌다. 그 중심에 Google이 Apache 2.0으로 오픈한 Gemma 계열 모델들이 있다.
| 모델 | 역할 | 핵심 스펙 |
|---|---|---|
| Gemma 4 (E2B / E4B) | 경량 범용 온디바이스 모델. 펑션콜·구조화 JSON·시스템 프롬프트·멀티모달까지 네이티브 지원 | Apache 2.0 · 140개 이상 언어 · 128K 컨텍스트 · E2B는 일부 장치에서 1.5GB 메모리 미만으로 구동 |
| FunctionGemma (270M) | 펑션콜 전용으로 파인튜닝된 초경량 엣지 모델. 자연어 ↔ 구조화 함수 호출 변환에 특화 | Apache 2.0 (상업적 사용 가능) · 모바일/Jetson Nano급 디바이스 실행 · "unified action and chat" |
성능도 "장난감" 수준이 아니다. Google이 공개한 LiteRT-LM 벤치마크에 따르면 라즈베리 파이 5 CPU에서도 Gemma 4 E2B가 prefill 133 tokens/s, decode 7.6 tokens/s를 찍고, Qualcomm Dragonwing IQ8 NPU에서는 prefill 3,700 tokens/s, decode 31 tokens/s까지 올라간다 (Google Developers Blog). 4,000 입력 토큰을 2개 스킬에 분배하는 에이전트 시나리오가 GPU 가속 환경에서 3초 이내로 끝난다. 로컬에서 실용적 에이전트가 돌아갈 수 있다는 말이다.
이 변화가 AgentWin 같은 시스템에 주는 의미는 분명하다.
| 측면 | 클라우드 API 시대 | 온디바이스 Gemma 시대 |
|---|---|---|
| 비용 | 토큰당 과금, rate limit, 예산 천장 | 제로 API 비용, 하드웨어가 허락하는 만큼 무한 호출 |
| 프라이버시 | 사용자 입력·터미널 출력이 외부 서버 경유 | 데이터가 네트워크를 떠나지 않음 — "own the entire stack" |
| 응답 레이턴시 | 네트워크 RTT가 본격 병목 | 로컬 추론 — ms 단위 |
| 오프라인 동작 | 불가 | 가능 — 비행기, 망분리 환경 포함 |
| 상업적 사용 | 벤더 약관에 묶임 | Apache 2.0으로 자유 (사용 제한 조항 별도 확인) |
AgentWin이 지금까지 써 온 gemma-4-26b-a4b류 모델이 바로 이 흐름 위에 서 있다. 사회자 봇의 펑션콜 루프 — stage_status로 시스템 전체 상태를 읽고, memory_note로 계획을 쓰고, stage_send로 3개 터미널에 메시지를 뿌리는 — 이 모든 것이 사용자 PC의 로컬 모델만으로 닫혀 돌아간다. 앞서 §5에서 길게 얘기한 진단 로깅, 멤돔 가드, 세션 메모리, 함수 호출 오염 차단도 바로 이 "로컬 온디바이스 컨트롤러를 쓸 만하게 길들이는" 작업의 일부였다.
또 하나 주목할 만한 포지셔닝은 FunctionGemma가 Google 스스로 "intelligent traffic controller"라고 부르는 지점이다 (InfoQ, 2026-01). 쉬운 제어·필터링은 초경량 엣지 모델이 로컬에서 처리하고, 정말 추론이 필요한 요청만 큰 원격 모델로 라우팅하는 2단 구조 — 이건 AgentWin이 지금 봇(로컬 Gemma) + 터미널 AI(더 큰 Claude Code)로 풀고 있는 구조와 거의 같다. 업계가 그 패턴에 이제 이름을 붙이고 있는 중이다.
정리: "추론"과 "자잘한 기능 제어" 중 최소한 후자는 더 이상 비싼 클라우드에 의존할 필요가 없다. 똑똑한 컨트롤러를 직접 구축해서 자기 옆에 둘 수 있는 시대가 왔다는 것 — 그리고 그 컨트롤러를 Akka.NET 같은 메시지 기반 인프라에 꽂아 두면, 액터 트리 안의 모든 부품이 자연어로 제어 가능해진다. AgentWin의 §4.1 20줄짜리 펑션콜 핸들러는 바로 이 "제어기의 자가 보유"가 실제로 가능해진 순간의 증거다.
5. 개선 — 실패 데이터로 다시 만든 도구들
...
- Akka.NET 공식 사이트
- Petabridge — Akka.NET 부트캠프와 OSS 거버넌스
- Petabridge 부트캠프 — Why Akka.NET?
- Akka.NET Actors' Hidden Super Power: Behavior Switching
- Akka.NET GitHub
- Akka Agents — 고수준 에이전트 프레임워크 (Agent/Memory/Tools/Prompts/Endpoints)
- The Definitive Guide to Agentic Design Patterns in 2026 — Sitepoint
- AI Agent Orchestration Patterns — Microsoft Azure Architecture Center
- Gemma 4 — Google Blog (Apache 2.0, 온디바이스 에이전틱)
- Bring state-of-the-art agentic skills to the edge with Gemma 4 — Google Developers Blog
- FunctionGemma model overview — Google AI for Developers
- Google Releases Gemma 3 270M Variant Optimized for Function Calling — InfoQ
이 글의 사례는 모두 AgentWin(개발 중)의 실제 코드/로그/평가 보고서에서 나왔다. 다이어그램 안의 텍스트는 모두 영문으로 되어 있다 — 모델은 언어와 무관해야 하고, 개발자라면 언어와 무관하게 읽혀야 한다는 의도다.