저는 16GB 메모리의 M1 Mac과 9B·4B 클래스의 소형 모델을 사용하여, SNS 게시물이나 댓글을 스스로 생각해서 작성하는 자율 에이전트(Autonomous Agent)를 약 3개월 동안 매일 4세션씩 무인으로 계속 구동해 왔습니다. 그 운용을 통해 얻은 견고화(Robustness)에 대한 지견을, 앞으로 4편의 기술 아티클 시리즈로 공개할 예정입니다.

그 전에, 한 가지만 먼저 써두고 싶은 것이 있습니다. 왜 소형 모델인가 하는 점입니다.

Mac Studio나 새로운 MacBook Pro 구매 페이지까지 갔던 적은 한두 번이 아닙니다. 클라우드의 거대 모델(Opus나 GPT 계열)을 백엔드(Backend)로 사용하는 선택지도 코드상으로는 항상 있었습니다. 그럼에도 불구하고, 저는 사지 않았고 옮기지도 않았습니다. 16GB M1은 경제적인 제약이 아니라, 선택한 제약입니다.

소형 모델에서의 개발은 겉으로 보기에는 "저렴한 타협"처럼 보일 수 있습니다. 이 기사는 그것이 왜 타협이 아닌지에 대한 설명이자, 저의 입장 표명입니다. 아울러 시리즈 4편의 허브 역할도 겸합니다.

모델의 똑똑함은 설계의 거칠음을 숨긴다

거대 모델은 허술한 프롬프트(Prompt)도, 모호한 지시도, 누락된 가드레일(Guardrail)도 똑똑함으로 흡수해 줍니다. 제품을 만드는 것이 목적이라면 그것은 장점입니다. 하지만 무언가를 만들 수 있는 능력을 갖추고 싶은 사람에게는 단점이 됩니다.

작동하는 결과물 중에서 어디까지가 자신의 설계이고, 어디서부터가 모델의 똑똑함인지 구분할 수 없게 되기 때문입니다. "작동했다"와 "만들었다"는 별개의 문제입니다. 모델의 성능으로 밀어붙여 작동시킨 것은 작동한 실적은 될 수 있어도, 만드는 힘이 되지는 않습니다.

소형 모델에는 흡수력이 없습니다. 그래서 설계의 결함이 전부 겉으로 드러납니다.

저의 운용 과정에서는 다음과 같은 문제들이 모두 드러났습니다.

• 컨텍스트 윈도우(Context Window)가 말없이 잘려 나가는 문제
• 출력의 중간 끊김
• 샘플링 파라미터(Sampling Parameter) 하나가 누락되어 발생하는 폭주

클라우드나 거대 모델 환경에서는 이러한 문제로 고민하는 일이 별로 없습니다. 환경에 완충재가 내장되어 있기 때문입니다.

• 컨텍스트 윈도우는 20만~100만 토큰급으로, 잘리는 현상 자체가 거의 일어나지 않습니다. 초과하더라도 말없이 잘리는 것이 아니라 명시적인 에러가 반환됩니다.
• 샘플링의 기본값은 API 측에서 관리하고 있어, 파라미터를 놓칠 여지가 구조적으로 없습니다.
• 다소 이상한 출력이 나오더라도, 똑똑한 모델의 ReAct 패턴(LLM이 결과를 보면서 다음 수를 선택하며 순환하는 방식)이라면 다음 단계에서 바로잡아 그럴싸하게 완수해 버립니다.

로컬의 16GB에는 이러한 완충재가 없습니다. 컨텍스트 윈도우는 직접 지정해야 하고, 초과 시에는 말없이 앞부분부터 잘려 나가며, 샘플링 설정 또한 온전히 자신의 몫입니다. 동일한 종류의 문제들이 숨길 수 없는 형태로 나타났고, 설계로 이를 막을 수밖에 없었습니다.

완충재 위에서 작동하고 있는 동안에는, 자신의 설계가 지켜주고 있는 것인지 환경이 지켜주고 있는 것인지 구분이 가지 않습니다.

제약 속에서 구축하는 훈련은 환경이 바뀌어도 남는다

이전에 새로운 툴을 자유롭게 도입할 수 없는 환경에서 업무 자동화를 수행하던 시기가 있었습니다. 보안상의 제약, 사용할 수 있는 소프트웨어의 제약, 그리고 "새로운 것을 도입하는 것" 자체에 대한 조직적인 마찰. 사용할 수 있었던 것은 Excel이나 Access처럼 이미 모든 PC에 설치되어 있는 소프트웨어와 승인된 RPA 툴뿐이었습니다.

도구를 늘릴 수 없다면, 손에 쥐고 있는 도구들의 조합법을 깊게 파고들 수밖에 없습니다. 저는 그 안에서 사용할 수 있는 도구들만으로 최대한의 자동화를 시도했습니다. 다만, 이 경험을 통해 정말로 단련된 것은 도구에 대한 지식이 아니었습니다.

자동화의 실체는 개인적·장인적 암묵지(Tacit Knowledge)로 돌아가던 업무를 분해하는 작업입니다. 절차의 어디까지를 결정론적(Deterministic)으로 작성할 수 있고, 어디서부터가 경험에 기반한 종합적인 의미 판단인지.

그 경계를 극한까지 세밀하게 파악하여, 업무를 **"결정론으로 작성할 수 있는 부분"과 "의미 판단이 필요한 부분"**으로 분류해 나갑니다. RPA에 맡겨도 되는 것은 전자에 불과하며, 경계를 잘못 파악한 자동화는 반드시 무너집니다.

이 분류 방식은 그대로 지금의 에이전트 설계 도식으로 이어집니다.

결정론으로 작성할 수 있는 처리는 LLM에 던지지 않습니다[1]. 의미 판단이 필요한 곳에만 LLM을 사용합니다. 그리고 LLM은 인간 판단의 대체재가 아니므로, 출력의 검증과 최종 판단은 코드와 인간의 몫으로 남겨둡니다.

어디에 할당할 것인가를 판단하는 것이야말로 설계의 핵심입니다. 그 판단력은 제약이 가득한 환경에서 길러지며, 제약이 사라진 후에도 원칙적으로 남아 있습니다.

작게 돌아가는 설계는 모델에 의존하지 않는다

소형 모델이라는 제약에는 훈련 이외에도 또 다른 의미가 있습니다. 바로 **하한의 실증 (Lower bound verification)**입니다.

9B·E4B 클래스에서 무인으로 3개월간 돌아가는 설계는, 모델의 똑똑함으로 설계의 빈틈을 메우지 않습니다. 의미 판단은 LLM의 역할로 남겨두되, 이를 지키는 메커니즘은 전부 코드 측에 있습니다.

• 입력은 보내기 전에 예측하여 방어한다
• 출력의 잘림(truncation)은 감지하여 폐기한다
• 실패는 telemetry (동작 기록 메커니즘)가 구조적으로 기록한다

이 모든 것은 모델 비의존적 (model-agnostic)인 설계입니다. 따라서 설계의 사고방식은 더 큰 모델로 옮겨가더라도 그대로 유지할 수 있습니다. 옮겨갈 수 없는 것은 모델에 종속된 교정값(calibration values)이나 임계값(thresholds)입니다 (이 이주 문제는 시리즈 #3에서 다룹니다).

반대 방향은 성립하지 않습니다. 큰 모델의 똑똑함을 전제로 구축한 설계는 작은 환경에서 그대로 작동하지 않습니다. 위로 쌓는 것은 쉽지만, 아래로 내리려면 새로 만들어야 합니다.

물론, 큰 모델을 사용했다면 똑같은 것을 훨씬 더 편하게 돌렸을 것입니다. 하지만 편하게 돌아가는 것은 어디까지가 설계이고 어디서부터가 모델의 똑똑함인지 끝까지 알 수 없습니다. 작게 돌려본 만큼은 온전히 자신의 설계라고 말할 수 있습니다. 제가 "타협이 아니다"라고 말하는 것은 바로 그 의미입니다.

이 시리즈에서 다루는 기술적인 내용

여기까지가 "왜 소형인가"에 대한 이야기입니다. 실제로 16GB 환경에서 무인 운용을 성립시킨 기술은 이어지는 4개의 글에서 다룹니다 (공개되는 대로 링크를 추가하겠습니다).

• 로컬 LLM의 실패는 조용히 일어난다 — 입력이 말없이 잘리는 문제 (silent truncation)의 진단과, 보내기 전에 방어하는 budget guard 설계
• 1.8배 빠른 백엔드를 버린 날 — 벤치마크에서 빨랐던 MLX 도입과, 실전 24시간 만에 철수한 기록
• 모델을 바꾸는 날 — Blind A/B 테스트와, 모델에 종속된 교정값의 이주 문제
• 관측할 수 없는 것은 고칠 수 없다 — telemetry, replay, 테스트가 조용히 거짓말을 하는 이야기

이 에이전트 자체의 구축기는 [Moltbook 에이전트 구축기 — Claude Code와 보안 우선 개발]에서 시작되었습니다. 소형 모델과의 사투가 본격화된 회차는 [에이전트의 기억이 깨졌다 — 9B 모델과 사투를 벌인 하루]입니다.

요약

• 소형 모델의 선택은 경제적인 타협이 아니라, 설계의 결함을 노출시키기 위해 선택한 제약입니다.
• 제약 하에서 단련되는 것은 도구에 대한 지식이 아니라, 결정론 (determinism)과 의미 판단을 분별하는 능력입니다. 이 분별은 코드와 LLM의 분담이라는 에이전트 설계의 핵심으로 그대로 이어집니다.
• 소형 모델로 무인 운용이 성립하는 설계 방식은 모델 비의존적이며, 큰 모델로의 이주 시에도 그대로 적용할 수 있습니다 (교정값만 재측정).
• 계속할지 옮겨갈지는 목적에 달려 있습니다. 최단 시간에 돌아가는 것이 필요하다면 클라우드가 적합합니다. 만드는 힘을 원한다면 소형 모델로 계속할 가치가 있습니다.

관련 링크

• 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 에이전트가 정말로 필요한 업무는 무엇인가」에서 다루고 있습니다. ↩︎

Discussion