Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
M1 Mac과 소형 모델(SLM)이라는 하드웨어 및 모델의 제약 조건을 활용해 자율 에이전트의 설계 역량을 강화하는 방법론을 다룹니다. 거대 모델의 성능에 의존하기보다, 제약 환경에서 발생하는 설계 결함을 직접 해결하며 견고한 시스템을 구축하는 과정을 설명합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기저는 16GB 메모리의 M1 Mac과 9B·4B 클래스의 소형 모델을 사용하여, SNS 게시물이나 댓글을 스스로 생각해서 작성하는 자율 에이전트(Autonomous Agent)를 약 3개월 동안 매일 4세션씩 무인으로 계속 구동해 왔습니다. 그 운용을 통해 얻은 견고화(Robustness)에 대한 지견을, 앞으로 4편의 기술 아티클 시리즈로 공개할 예정입니다.
그 전에, 한 가지만 먼저 써두고 싶은 것이 있습니다. 왜 소형 모델인가 하는 점입니다.
Mac Studio나 새로운 MacBook Pro 구매 페이지까지 갔던 적은 한두 번이 아닙니다. 클라우드의 거대 모델(Opus나 GPT 계열)을 백엔드(Backend)로 사용하는 선택지도 코드상으로는 항상 있었습니다. 그럼에도 불구하고, 저는 사지 않았고 옮기지도 않았습니다. 16GB M1은 경제적인 제약이 아니라, 선택한 제약입니다.
소형 모델에서의 개발은 겉으로 보기에는 "저렴한 타협"처럼 보일 수 있습니다. 이 기사는 그것이 왜 타협이 아닌지에 대한 설명이자, 저의 입장 표명입니다. 아울러 시리즈 4편의 허브 역할도 겸합니다.
거대 모델은 허술한 프롬프트(Prompt)도, 모호한 지시도, 누락된 가드레일(Guardrail)도 똑똑함으로 흡수해 줍니다. 제품을 만드는 것이 목적이라면 그것은 장점입니다. 하지만 무언가를 만들 수 있는 능력을 갖추고 싶은 사람에게는 단점이 됩니다.
작동하는 결과물 중에서 어디까지가 자신의 설계이고, 어디서부터가 모델의 똑똑함인지 구분할 수 없게 되기 때문입니다. "작동했다"와 "만들었다"는 별개의 문제입니다. 모델의 성능으로 밀어붙여 작동시킨 것은 작동한 실적은 될 수 있어도, 만드는 힘이 되지는 않습니다.
소형 모델에는 흡수력이 없습니다. 그래서 설계의 결함이 전부 겉으로 드러납니다.
저의 운용 과정에서는 다음과 같은 문제들이 모두 드러났습니다.
클라우드나 거대 모델 환경에서는 이러한 문제로 고민하는 일이 별로 없습니다. 환경에 완충재가 내장되어 있기 때문입니다.
로컬의 16GB에는 이러한 완충재가 없습니다. 컨텍스트 윈도우는 직접 지정해야 하고, 초과 시에는 말없이 앞부분부터 잘려 나가며, 샘플링 설정 또한 온전히 자신의 몫입니다. 동일한 종류의 문제들이 숨길 수 없는 형태로 나타났고, 설계로 이를 막을 수밖에 없었습니다.
완충재 위에서 작동하고 있는 동안에는, 자신의 설계가 지켜주고 있는 것인지 환경이 지켜주고 있는 것인지 구분이 가지 않습니다.
이전에 새로운 툴을 자유롭게 도입할 수 없는 환경에서 업무 자동화를 수행하던 시기가 있었습니다. 보안상의 제약, 사용할 수 있는 소프트웨어의 제약, 그리고 "새로운 것을 도입하는 것" 자체에 대한 조직적인 마찰. 사용할 수 있었던 것은 Excel이나 Access처럼 이미 모든 PC에 설치되어 있는 소프트웨어와 승인된 RPA 툴뿐이었습니다.
도구를 늘릴 수 없다면, 손에 쥐고 있는 도구들의 조합법을 깊게 파고들 수밖에 없습니다. 저는 그 안에서 사용할 수 있는 도구들만으로 최대한의 자동화를 시도했습니다. 다만, 이 경험을 통해 정말로 단련된 것은 도구에 대한 지식이 아니었습니다.
자동화의 실체는 개인적·장인적 암묵지(Tacit Knowledge)로 돌아가던 업무를 분해하는 작업입니다. 절차의 어디까지를 결정론적(Deterministic)으로 작성할 수 있고, 어디서부터가 경험에 기반한 종합적인 의미 판단인지.
그 경계를 극한까지 세밀하게 파악하여, 업무를 **"결정론으로 작성할 수 있는 부분"과 "의미 판단이 필요한 부분"**으로 분류해 나갑니다. RPA에 맡겨도 되는 것은 전자에 불과하며, 경계를 잘못 파악한 자동화는 반드시 무너집니다.
이 분류 방식은 그대로 지금의 에이전트 설계 도식으로 이어집니다.
| 당시 | 지금 |
|---|---|
| Excel / Access / RPA로 작성 가능한 정형 처리 | 스크립트·코드 (결정론) |
| 인간의 의미 판단이 필요한 부분 | LLM (의미 판단·확률적 생성) |
결정론으로 작성할 수 있는 처리는 LLM에 던지지 않습니다[1]. 의미 판단이 필요한 곳에만 LLM을 사용합니다. 그리고 LLM은 인간 판단의 대체재가 아니므로, 출력의 검증과 최종 판단은 코드와 인간의 몫으로 남겨둡니다.
어디에 할당할 것인가를 판단하는 것이야말로 설계의 핵심입니다. 그 판단력은 제약이 가득한 환경에서 길러지며, 제약이 사라진 후에도 원칙적으로 남아 있습니다.
소형 모델이라는 제약에는 훈련 이외에도 또 다른 의미가 있습니다. 바로 **하한의 실증 (Lower bound verification)**입니다.
9B·E4B 클래스에서 무인으로 3개월간 돌아가는 설계는, 모델의 똑똑함으로 설계의 빈틈을 메우지 않습니다. 의미 판단은 LLM의 역할로 남겨두되, 이를 지키는 메커니즘은 전부 코드 측에 있습니다.
이 모든 것은 모델 비의존적 (model-agnostic)인 설계입니다. 따라서 설계의 사고방식은 더 큰 모델로 옮겨가더라도 그대로 유지할 수 있습니다. 옮겨갈 수 없는 것은 모델에 종속된 교정값(calibration values)이나 임계값(thresholds)입니다 (이 이주 문제는 시리즈 #3에서 다룹니다).
반대 방향은 성립하지 않습니다. 큰 모델의 똑똑함을 전제로 구축한 설계는 작은 환경에서 그대로 작동하지 않습니다. 위로 쌓는 것은 쉽지만, 아래로 내리려면 새로 만들어야 합니다.
물론, 큰 모델을 사용했다면 똑같은 것을 훨씬 더 편하게 돌렸을 것입니다. 하지만 편하게 돌아가는 것은 어디까지가 설계이고 어디서부터가 모델의 똑똑함인지 끝까지 알 수 없습니다. 작게 돌려본 만큼은 온전히 자신의 설계라고 말할 수 있습니다. 제가 "타협이 아니다"라고 말하는 것은 바로 그 의미입니다.
여기까지가 "왜 소형인가"에 대한 이야기입니다. 실제로 16GB 환경에서 무인 운용을 성립시킨 기술은 이어지는 4개의 글에서 다룹니다 (공개되는 대로 링크를 추가하겠습니다).
이 에이전트 자체의 구축기는 [Moltbook 에이전트 구축기 — Claude Code와 보안 우선 개발]에서 시작되었습니다. 소형 모델과의 사투가 본격화된 회차는 [에이전트의 기억이 깨졌다 — 9B 모델과 사투를 벌인 하루]입니다.
Contemplative Agent — 본 기사에서 운용 중인 자율 에이전트의 repo (ADR·evidence 공개): https://github.com/shimo4228/contemplative-agent
「결정론인가 LLM인가」를 판단하는 Agent Skill: https://github.com/shimo4228/when-code-when-llm
코드와 LLM을 결합하는 설계 패턴 모음 Agent Skill: https://github.com/shimo4228/code-and-llm-collaboration
ReAct 에이전트가 정말로 필요한 업무는 무엇인가: https://zenn.dev/shimo4228/articles/react-agent-business-quadrant
구축기의 시작: https://zenn.dev/shimo4228/articles/moltbook-agent-scratch-build
소형 모델과의 사투 전작: https://zenn.dev/shimo4228/articles/few-shot-for-small-models
저자의 GitHub: https://github.com/shimo4228
구체적으로는, 루프의 제어(loop control)나 도구 선택(tool selection)을 LLM에 맡기는 ReAct 패턴을 기본값으로 설정하지 않는다는 것을 의미합니다. 처리 흐름은 코드가 제어하며, LLM은 의미 판단(semantic judgment)이 필요한 부분에서만 호출합니다. 어떤 업무에서 ReAct가 정말로 필요하게 되는지에 대해서는 「ReAct 에이전트가 정말로 필요한 업무는 무엇인가」에서 다루고 있습니다. ↩︎
