같은 모델인데 결과가 다른 이유 - 작은 LLM 외부화 실험 노트

며칠 전 다모앙에서 어느 분이 이런 글을 올리셨습니다.

메인 에이전트한테 직접 작업 금지, 무조건 서브에이전트 소환해서 일 시키라고 해도 하루에 한 번은 새 세션으로 리프레시 시켜줘야 할 정도로 오염이 잘 됩니다.

클로드나 GPT, 제미나이처럼 초거대울트라킹왕짱 모델은 수천 명의 전문가들이 모여 관리를 하니 이런 걱정이 덜 하겠죠?

이 글에 답을 달려고 하다가, 댓글로 풀기엔 너무 큰 주제라 글로 정리하는 게 낫겠다 싶어서 적습니다. 답답함이 충분히 이해가 가고, 그 답답함이 사실 요즘 AI 에이전트 연구의 가장 활발한 주제 중 하나와 정확히 맞닿아 있어서요.

저는 이 문제를 측정해보는 실험 노트를 운영하고 있습니다. 이름은 Gemento고, 이 글은 그 노트에서 발견한 것들을 풀어쓰는 글입니다.

일단 "오염" 이라는 표현부터

가장 먼저 짚을 게 - "에이전트 오염" 이라는 표현 자체가 약간 잘못된 프레이밍입니다. 이 단어를 쓰면 마치 외부에서 뭔가 침투해서 에이전트가 더러워진 것 같은 그림이 되는데, 실제로 일어나는 일은 그게 아닙니다.

LLM은 컨텍스트 윈도우에 들어온 토큰들을 보고 다음 토큰을 예측하는 시스템입니다. 그래서 토큰이 길게 쌓이면 모델이 이전 대화의 패턴을 따라가게 됩니다. 이건 침투당한 게 아니라 설계된 대로 작동하는 것입니다.

그리고 "메인 에이전트는 작업 금지, 서브에이전트만 시킴" 이라는 시도 - 이건 효과가 거의 없습니다. 메인이 직접 코드를 짜든, 서브가 짠 코드를 받아오든, 토큰은 똑같이 메인 컨텍스트에 누적되거든요. 결국 "하루에 한 번 새 세션으로 리프레시" 하시는 게 정답에 가깝고, 그게 부족해서 그러시는 게 아니라 정상적인 작업 패턴입니다.

마지막으로 "수천 명 전문가가 관리하는 큰 모델은 이런 걱정이 없을 것" - 이건 안타깝게도 사실이 아닙니다. GPT/Claude/Gemini도 컨텍스트 길어지면 똑같이 이렇게 작동합니다. 오히려 큰 모델일수록 컨텍스트 윈도우가 깁니다(200K, 1M 토큰). 그래서 "길게 쓸 수 있으니까 길게 쓰자" 가 되어 장기 의존성 문제가 더 두드러지기도 합니다.

수천 명 전문가가 해주는 건 모델 자체의 학습이지 사용자 세션 관리가 아닙니다. 즉 이 문제는 모델을 키워서 푸는 문제가 아니라, 모델 밖에서 푸는 문제입니다.

그래서 모델 밖에서 푼다는 게 무엇인가

여기서부터가 본격적인 이야기입니다.

저는 약 한 달 전부터 이 질문을 측정해보고 있었습니다. 작은 로컬 LLM(Gemma 4 E4B, 8B급)이 메모리·도구·역할·통제를 외부화하면 단일 추론보다 얼마나 더 나아지는가.

처음 시작은 단순한 호기심이었습니다. seCall과 tunaFlow를 만들면서 반복적으로 부딪힌 문제가 - 장기 메모리, 컨텍스트 폭증, 세션을 가로지르는 작업의 보존 - 이거 셋이었거든요. 그러다 한 가지 생각을 했습니다.

프롬프트 컨텍스트를 비우고 데이터베이스 검색에 의존하면, 데이터베이스가 거의 무한한 컨텍스트처럼 작동할 수 있을까?

이 사고가 Memento(크리스토퍼 놀란, 2000)와 주인공 레너드의 문신, 폴라로이드, 전화 기록으로 저를 데려갔습니다. 단기 기억을 잃은 사람이 외부 매개체에 기억을 분산시켜서 작업을 이어가는 것 - 이게 작은 LLM이 긴 워크플로우를 견디게 만드는 구조의 비유가 됐습니다.

그래서 만든 게 Gemento입니다.

4축 외부화 프레임

Gemento는 LLM의 인지를 4개 축으로 나누고, 각각을 모델 가중치 밖으로 빼는 실험을 합니다.

여기서 중요한 점은 - A/B/C 역할이 같은 베이스 모델이라는 겁니다. Gemma 4 E4B 하나로 세 역할을 모두 굴립니다. 차이는 프롬프트와 검증 계약뿐이고요. 모델을 키운 게 아니라 구조를 바꿨을 뿐인데도 결과가 달라지는지가 핵심 질문입니다.

첫 번째 발견 - 자기검증은 안 됩니다

가장 먼저 측정한 건 자기검증이었습니다. 일부러 오류가 들어간 답변 15개를 만들어 모델한테 "이 답에 문제 있어?" 라고 물어봤습니다.

검출률 0/15. 자기 답을 자기가 못 봅니다.

그런데 같은 모델한테 다른 역할(Critic) 을 입혀서 같은 답을 다시 보게 했더니 - 12/15(80%)를 잡아냈습니다. 같은 모델, 같은 답, 다른 역할 프롬프트. 이게 다입니다.

이게 의미하는 게 뭐냐면 - "AI한테 네 답 한 번 더 검토해봐" 라는 흔한 워크플로우가 거의 작동하지 않는다는 겁니다. 모델은 자기가 만든 답을 거의 그대로 옹호합니다. 진짜 검증이 일어나려면 역할이 분리되어야 합니다. 같은 모델이라도.

이 결과가 다모앙 그분이 말씀하신 "메인 에이전트가 오염되니까 새 세션으로 리프레시" 라는 직관과 닿아 있습니다. 새 세션이 아니라 새 역할이면 같은 세션 안에서도 효과가 있다는 거니까요.

두 번째 발견 - 더 큰 모델을 위에 얹는다고 좋아지지 않습니다

이게 다모앙 그분의 "수천 명 전문가가 관리하는 모델" 질문에 대한 직접적인 답입니다.

실험 11(H10)에서 - A/B는 Gemma 4 E4B 그대로 두고, Judge C에만 Gemini 2.5 Flash를 붙여봤습니다. 더 강한 모델이 위에서 검증해주면 좋아질 것 같잖아요? 직관적으로는 그렇습니다.

결과: -0.08 (악화). Cohen's d = -0.316, 작지만 음수.

특히 logic-02 케이스가 결정적이었습니다. 베이스라인(Gemma만)은 5번 중 4번 "105 inconsistent" 라는 정답을 포함-배제 원리로 도출했습니다. 그런데 Mixed(Gemini Judge)는 5번 모두 null이거나 키워드를 놓친 답이 나왔습니다. 더 강한 Judge가 더 약한 모델의 자기 발견 사슬을 끊어버린 거예요.

메커니즘은 이렇습니다. 강한 Judge가 작은 모델의 Tattoo 스키마를 자기 식으로 재해석하면서 미스매치가 생깁니다. 그러면 작은 모델 입장에서는 "내가 한 작업이 인정 안 되네" 가 되어 조기 수렴해버립니다.

이게 결정적인 이유 - "더 큰 모델 = 더 좋음" 이라는 직관이 깨지는 자리이기 때문입니다. 수천 명 전문가가 만든 큰 모델을 가져다 붙이는 게 답이 아니라, 구조를 어떻게 짜느냐가 답이라는 겁니다.

세 번째 발견 - 같은 모델인데 1-loop 41% → 8-loop 78%

이건 헤드라인 수치입니다. 같은 Gemma 4 E4B인데, 단일 추론으로 41.3%였던 정답률이 8루프 ABC 오케스트레이션으로 78.1%까지 올라갔습니다. 9개 태스크 × 60 trial = 540 trial로 측정했고요.

같은 벤치마크에서 1-call Gemini 2.5 Flash 베이스라인은 59.1%였습니다. 즉 작은 로컬 모델이 8루프 구조 덕분에 큰 모델 1번 호출보다 +19pp 높았다는 결과입니다.

다만 여기서 함정이 있어서 짚어둡니다.

• 시간 비용은 약 20배 더 듭니다 (8루프니까)
• API 비용은 0이지만 GPU 시간이 들어갑니다
• 9개 태스크 벤치마크에서의 결과이지 일반적인 우월성 주장은 아닙니다

이게 "작은 모델로 큰 모델을 대체할 수 있다" 는 글이 절대 아닙니다. "같은 모델이라도 구조에 따라 결과가 크게 달라진다" 는 사실 자체가 측정 가능하다는 글이고요.

네 번째 발견 - 구조는 모노토닉하지 않습니다

이게 가장 흥미로운 부분입니다. "구조 추가하면 좋아진다" 가 모든 경우에 맞는 게 아닙니다.

같은 시기에 두 가지 역할 추가 실험을 돌렸습니다.

거의 거울처럼 대칭입니다. 둘 다 같은 모델로 추가했는데, 어디에 추가했느냐에 따라 결과가 정확히 반대 방향이 나왔습니다. (둘 다 n=15에서 통계적 유의성은 없음, p=0.198 / 0.180)

여기서 한 가지 짚어두면 - Reducer 결과는 키워드 채점기의 한계 때문일 가능성도 있습니다. Reducer가 다중 출처 답변을 "단일 추정치" 로 압축하다 보니 키워드 매칭이 떨어진 거지, 실제 품질이 떨어진 게 아닐 수도 있거든요. 이거 LLM-as-judge로 재검증할 계획입니다.

다만 "n=15에서 유의하지 않다" 는 점, 그리고 "키워드 채점기의 잠재적 아티팩트" 양쪽 다 명시했으니, 이건 확정된 비대칭이 아니라 cross-model로 재현해봐야 하는 패턴으로 다룹니다.

만약 이 방향이 cross-model에서도 유지된다면 - "역할은 추가가 아니라 위치가 중요하다" 는 결론이 됩니다. 이게 다음 단계의 작업입니다.

다섯 번째 발견 - 도구도 사실 한 종류가 아닙니다

도구 외부화도 몇 차례 측정했는데, 흥미로운 sub-distinction이 나왔습니다.

이 격차가 큰 이유는 - 검색은 모델이 "몇 번 검색해야 하는지" 를 스스로 결정해야 합니다. 다중 hop 태스크에서 모델은 1-hop을 찾고 "문서에 답이 없네" 하고 조기 수렴해버립니다. 5번의 진단 trial에서 tool-call 수가 [1, 2, 2, 3, 0]이었고, 정답률이 정확히 [0, 1, 1, 1, 0]으로 매핑됐습니다. 반복이 부족하면 검색은 안 합쳐집니다.

반면 계산기는 "한 번 부르면 정답" 이라 모델이 결정해야 할 게 별로 없습니다. 그래서 잘 됩니다.

이게 다모앙 그분의 "서브에이전트한테 시킴" 와도 연결됩니다. 서브에이전트한테 작업을 위임할 때, 그게 결정론적인 한 번의 호출로 끝나는 작업이면 효과적인데, 반복적이고 판단이 필요한 작업이면 서브에이전트도 결국 컨텍스트 누적과 조기 수렴 문제를 겪습니다. 외부화의 효과가 작업 종류에 따라 다르다는 겁니다.

통합 발견 - "더 많은 구조가 항상 더 좋은 게 아니다"

H11+H12의 위치 효과 + H13의 도구 sub-distinction을 합치면, 1차 결론이 이렇게 됩니다.

더 많은 구조가 모노토닉하게 더 좋은 게 아니다. 어디에 두느냐, 그리고 그것이 어떻게 반복되느냐가 중요하다.

이게 작은 모델 외부화의 진짜 교훈인 것 같습니다. "외부화하면 좋아진다" 가 아니라 "외부화의 위치와 반복 방식에 따라 정반대 결과가 나올 수 있다" — 이걸 데이터로 보여주는 게 Gemento의 1차 기여라고 생각합니다.

그래서 다모앙 그분의 답답함으로 돌아가면

처음으로 돌아갑니다.

"메인 에이전트가 오염되니까 새 세션으로 리프레시" 하시는 그분의 직관 - 이거 정확합니다. 컨텍스트 누적은 LLM의 정상 작동이고, 그걸 끊어주는 게 정답이고, 부족해서 그러시는 게 아니라 그게 작업 패턴입니다.

그리고 "수천 명 전문가가 관리하는 큰 모델은 다를 것" - 안타깝게도 그렇지 않습니다. 모델을 키워서 푸는 문제가 아니라 모델 밖에서 푸는 문제입니다. Gemento 실험은 그걸 데이터로 측정해본 시도이고, 같은 모델이라도 구조를 바꾸면 41% → 78%가 가능하다는 것 - 그리고 더 큰 모델을 위에 얹는 게 오히려 -8pp 악화로 갈 수 있다는 것 - 이 두 결과가 그 답답함에 대한 가장 직접적인 답입니다.

본인만의 자동화 시스템을 구축하고 싶다고 하셨는데 - 그 방향은 맞습니다. 다만 "오염을 막는 도구" 가 아니라 컨텍스트를 어떻게 분리하고, 역할을 어떻게 나누고, 도구를 어디서 호출하고, 통제를 어디에 둘 것인지 - 이 4축을 본인 워크플로우에 맞게 설계하시는 작업이 됩니다. 큰 모델 가져다 붙이는 게 답이 아니라, 본인이 매일 쓰는 그 모델을 밖에서 어떻게 감싸느냐가 답입니다.

마치며 - 왜 이걸 공개하는가

Gemento는 MIT 라이선스이고, 의도적으로 그렇게 정했습니다. 1인 연구 노트지만 - "작은 로컬 모델 외부화" 라는 방향에서 일하는 분들이 다른 모델로 재현해보고, 다른 결과가 나오면 그걸 공개하고 - 그렇게 측정값이 쌓이는 게 한 사람의 노트보다 훨씬 가치 있다고 봅니다.

특히 cross-model 재현이 시급합니다. 지금 모든 헤드라인 수치가 Gemma 4 E4B 단일 모델 결과인데, 이게 Llama 3.1 8B나 Qwen 2.5 7B에서도 같은 패턴인지 확인해야 합니다. 위치 효과(H11/H12 거울 대칭)도, 검색 도구 음의 효과(H13)도, 모두 "이 모델에서만 나타나는 우연" 일 가능성을 배제할 수 없거든요. 그래서 다음 단계는 다른 모델로 같은 실험을 돌려보는 것입니다.

그리고 한 가지 - 이 노트는 의도적으로 "실패한 가설" 을 그대로 둡니다. H2(자기검증)는 0/15로 완전히 실패했고, H10(강한 Judge)는 -0.08로 거꾸로 갔고, H13(검색 도구)는 -0.22로 통계적으로 유의하게 악화됐습니다. 이걸 "잘 안 된 결과" 로 숨기지 않고 그대로 둡니다. 부정 결과가 사실 가장 큰 정보거든요. "이 방향은 안 됨" 을 알게 되면 다음 시도의 방향이 명확해집니다.

다모앙에서 그분 글을 보고 "어디서부터 풀어야 할지 모르겠다" 는 답답함이 들었던 게 - 사실은 이 4축 외부화 이야기를 어떻게 시작해야 할지 자신이 없었기 때문이었습니다. 그래서 이 글이 나왔고요. 답답함을 가지신 그분께, 그리고 비슷한 자리에 계신 다른 분들께, 이 노트가 작은 좌표 하나가 되면 좋겠습니다.

참고 자료

• Gemento GitHub: https://github.com/hang-in/gemento
• 한국어 README: README.ko.md
• 핵심 분석 보고서들: 레포의 docs/reference/ 폴더 참조
• 관련 연구: Zhou et al. (2026) Externalization in LLM Agents, Wu et al. (2024) StateFlow, Zhang et al. (2024) Chain of Agents
• 영감의 원천: Christopher Nolan, Memento (2000)