이 글은 원래 LLMKube 블로그에 게시되었습니다.

먼저, 확인 가능한 주장을 말씀드리겠습니다: 2026년 5월 21일부터 6월 25일 사이에, 로컬 모델 군단이 **자체 호스팅 추론 (self-hosted inference)을 위한 오픈 소스 Kubernetes 오퍼레이터인 LLMKube에 우리가 병합(merge)한 41개의 pull request (PR)**를 생성했습니다. 코드나 프롬프트(prompt)가 외부로 유출되지 않았습니다. 한계 추론 비용(marginal inference cost)은 몇 센트의 전기료에 불과했습니다. 이 5주 동안 모델이 생성한 PR은 저장소(repo)에 병합된 전체 작업의 약 5분의 1을 차지했으며, 가장 바빴던 최근 기간에는 그 비중이 절반에 가까웠습니다. 이는 같은 기간에 활동한 5명의 인간 기여자(human contributor)가 생성한 pull request와 맞먹는 수준입니다.

만약 여러분이 270억 파라미터(27-billion-parameter) 규모의 오픈 웨이트(open-weight) 모델을 코딩 에이전트(coding agent)로 사용해 보았다면, 여러분의 첫 반응은 당연한 회의론일 것입니다. 그 정도 규모의 모델은 사소하지 않은 문제에 대해 동전 던지기 수준의 결과를 내놓습니다. 모델은 표류(drift)합니다. 아무것도 테스트하지 않는 테스트 코드를 작성합니다. 컴파일되지 않는 코드에 대해 승리를 선언합니다.

그 말은 모두 사실이며, 동시에 논점에서 벗어난 이야기이기도 합니다. 우리는 모델에 도박을 걸지 않았습니다. 우리는 모델을 둘러싼 하네스(harness)에 도박을 걸었습니다. 이 포스트는 실패한 부분들을 포함하여, 그 도박에 대한 증거입니다.

설정: 약한 모델, 엄격한 하네스, 이기종 하드웨어

에이전트형 코더(agentic coder)는 LLMKube의 구성 요소인 Foreman입니다. 이 설계의 전제는 단 한 문장입니다: 모델이 아니라 하네스를 믿으라.

모델은 우리가 로드한 로컬 코더(local coder)가 무엇이든 상관없습니다. 이 5주 동안 모델은 주로 AMD Strix Halo 미니 PC의 Vulkan 환경에서 실행되는 밀집형(dense) 27B (Qwopus-27B-Coder) 모델이었고, Apple Silicon Mac의 Metal 환경에서 실행되는 35B Mixture-of-Experts (Qwen3.6-35B-A3B) 모델이었습니다. Mac Studio에서 실행되는 두 번째의 다른 모델이 리뷰어(reviewer) 역할을 수행합니다. 이들 중 그 어떤 것도 프런티어 모델(frontier model)이 아닙니다. 그 어떤 것도 프런티어 모델에 근접하지 않습니다.

실질적인 작업이 이루어진 곳은 하네스(harness)입니다. 모든 실행 단계에는 결정론적 (deterministic) 체크 스택이 배치되어 있으며, 각 체크는 모델이 얼마나 확신하느냐에 관계없이 모델의 출력을 거부할 수 있습니다.

• 빠른 워크스페이스 내 게이트 (fast in-workspace gate): gofmt, go vet, go build, golangci-lint, 그리고 범위가 지정된 단위 테스트 (unit tests)가 포함됩니다. 만약 하나라도 실패하면, 해당 실패 결과는 최대 3번의 수정 시도까지 코더 (coder)에게 피드백됩니다. 레드 게이트 (red gate, 실패 상태)에서는 PR이 생성되지 않습니다.
• 범위 이탈 방지 (scope-drift guard): 만약 변경 사항 (diff)이 이슈 (issue)에서 의도하지 않은 서브시스템 (subsystem)을 건드린다면, 승인되는 대신 실행이 거부됩니다. 잘못된 패키지에 대한 확신에 찬 잘못된 변경 사항은 절대로 PR에 도달하지 못합니다.
• 바이트 체크 (bite check): 모든 새로운 테스트는 수정 전의 베이스라인 (baseline)을 대상으로 실행됩니다. 만약 수정 없이도 테스트가 통과된다면, 그것은 실제로 수정을 테스트하는 것이 아니므로 실행이 거부됩니다. 이는 LLM이 작성한 테스트에서 발생하는 가장 흔한 실패 모드 (failure mode)이며, 이제는 희망 사항이 아닌 하나의 게이트 (gate)로 작동합니다.
• 이슈 요청 확인 (issueAsk check): 리뷰어 (reviewer)는 실제로 가져온 이슈 본문 (issue body)을 바탕으로, 요청된 내용을 이해했음을 증명해야 합니다. 그럴듯하지만 틀린 요약을 지어내는 리뷰어는 신뢰를 잃고 강등됩니다.
• 별도의 하드웨어에서 실행되는 별도의 리뷰어 모델 (separate reviewer model): 작업을 판단하는 주체가 작업을 생성한 주체와 동일하지 않도록 합니다.

코더 (coder)는 확률적 (stochastic)입니다. 하지만 저 가드레일들은 모두 결정론적 (deterministic)입니다. 그 비대칭성 (asymmetry)이 바로 제품의 핵심입니다.

수치 (The numbers)

5주 동안. 검증 가능한 형태는 다음과 같습니다:

• 41개의 머지된 PR (merged PRs): 5월 21일부터 6월 25일까지 Foreman이 작성했으며, 모두 foreman/issue-* 브랜치에서 생성되었습니다.
• 그 중 39개가 6월에 발생: 하네스 (harness)가 성숙해짐에 따라 더 많은 작업을 신뢰하고 맡기게 되었습니다.
• 41개 중 31개는 인간의 커밋이 전혀 없었습니다: 해당 브랜치의 유일한 작성자는 Foreman입니다. 나머지 10개는 머지 전 인간의 약간의 수정 (touch-up)을 거쳤으며, 이는 이 포스트를 작성하는 필자가 솔직하게 밝히는 것과 같은 수준의 마무리 작업입니다.
• 5주 전체 기간 동안 이 PR들은 전체 머지된 항목의 약 20% (총 201개의 PR)를 차지했습니다. 가장 활발했던 최근 기간에는 절반에 가까웠습니다. 이들은 같은 기간 동안 동일한 리포지토리 (repo)에서 작업한 5명의 인간 기여자 (adebrie, arychj, eleboucher, joryirving, matiasinsaurralde)와 나란히 작업했습니다.
• API 비용 $0.00. 6개의 이슈를 처리하는 대표적인 야간 배치 (overnight batch) 작업의 비용은 약 6센트의 전기료가 들었으며, 이는 동일한 작업을 클라우드 API 토큰으로 수행했을 때 예상되는 18~30센트와 대조됩니다. 몇 센트라는 금액이 핵심이 아닙니다. 핵심은 형태 (shape) 입니다: 호출당 비용이 0이며, 일정하고 반복 가능하며, 타인의 데이터 센터를 거치지 않는다는 점입니다.

이 작업들은 장난스러운 이슈가 아닌 실제 유지보수 작업이었습니다: CLI 플래그 (flags), 컨트롤러 조정 (controller reconciliation) 수정, 메트릭스 배관 (metrics plumbing), 테스트 커버리지 (test-coverage) 분할, 공급망 CI 스캔, 관측성 스팬 (observability spans) 등이 포함되었습니다. 무시하기에는 너무 중요하지만, 우선순위를 두기에는 너무 매력이 없는 종류의 백로그 (backlog)입니다. 바로 지치지 않는 야간 동료가 맡아야 할 바로 그런 작업들입니다.

세 번의 실패 사례 (그리고 이를 잡아낸 것)

성공 사례만 보고하는 것은 마케팅입니다. 여기 모델이 충분히 뛰어나지 않았던 사례들을 상세히 공개합니다. 실패 사례야말로 논거가 되기 때문입니다.

Issue #731은 수렴하는 데 6번의 실행(runs)이 필요했습니다. 기능 구현과 테스트가 결합된 단일 작업이었습니다. Mixture-of-Experts (MoE) 코더는 작업 중간에 계속 멈춰버렸습니다. 우리는 한 번에 한 계층씩 하네스 (harness)를 강화하며 이를 밀어붙였습니다. 예산 가드 (budget guard), 그다음은 편집 연속성 강제 함수 (edit-streak forcing function), 마지막으로 테스트 계층 (test tier) 순이었습니다. 각 계층은 하나의 실패 모드 (failure mode)를 해결했고, 동시에 다음 실패 모드를 드러냈습니다. 가이드라인(rails)은 항상 모델을 제어했습니다. 모델은 결함이 있는 변경 사항을 배포하지 않았습니다. 하지만 30억 개의 활성 파라미터 (active-parameter)를 가진 Mixture-of-Experts는 그 작업을 자율적으로 완수할 수 없었습니다. 결국 이를 해결한 것은 더 날카로운 프롬프트 (prompt)나 인간의 구조가 아니었습니다. 그것은 다른 모델이었습니다. 동일한 AMD 하드웨어에서 구동된 더 밀도 높은 27B 코더는, 이후 동일한 이슈를 약 40분 만에 게이트 검증 (gate-verified)을 거쳐 깨끗하고 자율적으로 해결했습니다. 이것이 다른 각도에서 본 논지입니다. 하네스 (harness)는 상수(constant)입니다. 모델은 현재 가진 모델이 충분하지 않을 때 돌리는 다이얼 (dial)과 같습니다.

Issue #813은 아직 완료되지 않았습니다. 이는 밀폐된 git-fixture 테스트가 필요한 하네스 (harness) 변경 작업입니다. fixture를 명시적으로 요구하고 빠른 폴백 (fallback)을 요구하는 날카로운 프롬프트를 사용한 두 번째 시도를 포함하여, 두 번의 자율적인 시도 모두 '미완료 (INCOMPLETE)' 상태로 돌아왔습니다. 첫 번째 시도는 fixture를 사용하는 대신 실제 I/O를 수행하는 테스트에서 180초 동안 멈춰버렸고, 두 번째 시도는 여전히 게이트 (gate)를 통과하지 못했습니다. 두 번의 정직한 시도 끝에, 우리는 이를 인간의 손길이 필요한 작업으로 분류했습니다. 하네스 (harness)는 실패하는 변경 사항을 반영하지 않음으로써 제 역할을 다했습니다. 모델은 제 역할을 전혀 수행하지 못했습니다.

한 실행이 잘못된 GO(성공)를 생성했고, CI가 워크스페이스 내 게이트 (in-workspace gate)가 잡아내지 못한 것을 포착했습니다. 우리는 하나의 코더 루프 (coder loop)를 클러스터 내 에이전트 (in-cluster agent)로 라우팅했는데, 알고 보니 해당 에이전트에는 Go 툴체인 (Go toolchain)이 설치되어 있지 않았습니다. 빠른 게이트 (fast gate)는 코더의 자체 워크스페이스에서 실행되므로, Go가 없으면 아무 작업도 수행하지 않고 조용히 넘어갔으며 (no-op'd), 해당 실행은 테스트 어설션 (test assertion)이 뒤로 밀려 있고 포맷팅 위반 (formatting violation)이 있는 코드에 대해 확신에 찬 GO를 보고했습니다. 모델은 확신했습니다. 로컬 게이트는 눈이 멀어 있었습니다. 전체 CI 스위트 (CI suite)는 즉시 두 가지 모두를 잡아냈고, 우리는 수동으로 이를 수정했으며, 툴체인 공백 (toolchain gap)을 추적 가능한 이슈 (tracked issue)로 등록했습니다. 교훈은 다시 강조된 논제와 같습니다. 하네스 (harness)는 오직 그 커버리지 (coverage)만큼만 유효하며, 하나의 레일이 어두워지는 순간 당신이 그것에 얼마나 의존하고 있었는지 정확히 알게 된다는 것입니다.

이 세 가지 중 그 어떤 것도 깨진 PR을 배포하지 않았습니다. 그것이 전체 주장입니다. 모델은 신뢰할 수 없지만, 시스템은 그렇지 않습니다.

약한 모델에 대해 "모델이 아닌 하네스"가 올바른 선택인 이유

이 모든 것의 밑바탕에는 깔끔한 직관이 있습니다. 올바른 변경 사항을 생성하는 것은 어렵고 개방적입니다. 반면 이를 검증 (Verifying) 하는 것은 좁고 기계적입니다: 컴파일이 되는가, 테스트가 통과하는가, 디프 (diff)가 범위 내에 머물렀는가, 리뷰어가 실제로 이슈를 읽었는가와 같은 것들입니다. 최근의 검증기 (verifier) 관련 문헌들은 더 공식적으로 동일한 점을 지적합니다. 즉, 약하고 독립적인 검증기들의 스택이 오라클 (oracle)과의 간극 대부분을 메울 수 있으며, 생성기 (generator)가 약할수록 검증기 (verifier)의 하중 부담 (load-bearing)은 더 커진다는 것입니다.

프런티어 클라우드 모델 (frontier cloud model)은 얇은 하네스 (harness)만으로도 충분히 잘 작동할 만큼 성능이 좋습니다. 하지만 로컬 27B 모델은 그렇지 않으며, 이것이 바로 로컬 27B가 당신으로 하여금 어차피 구축했어야 할 하네스를 구축하도록 강제하는 정확한 이유입니다. 우리는 연구 포인트를 증명하기 위해 시작한 것이 아닙니다. 우리는 클라우드 API에 비용을 지불하거나 의존하지 않고 우리 자신의 백로그 (backlog)를 해결하기 위해 시작했으며, 하네스는 그 제약 사항을 진지하게 받아들인 결과로 도출된 것입니다.

클라우드의 또 다른 문제: 예측 불가능해진 비용

코더를 직접 소유한 하드웨어에서 실행해야 하는 두 번째 이유가 있으며, 2025년과 2026년에 걸쳐 이는 더 이상 가설이 아니게 되었습니다.

클라우드 AI 코딩의 정액제 시대는 공개적으로 막을 내렸습니다. OpenAI의 CEO는 2025년 초, 사람들이 예상보다 훨씬 더 많이 사용하기 때문에 월 200달러의 ChatGPT Pro 플랜에서 손실을 보고 있다고 인정했습니다. Cursor는 2025년 6월의 가격 재조정 이후 사용자들이 단 한 번의 에이전트 세션(agentic session)에서 한 달 치 크레딧을 모두 소진하게 만들자 사과하고 환불을 진행했습니다. GitHub은 자사의 제품 책임자가 이전의 프리미엄 요청 모델을

온프레미스(On-prem)는 모델 전체를 뒤집습니다. 하드웨어는 일회성 자본 비용(capital cost)이며, 그 이후의 모든 실행은 한계 토큰 비용(marginal token bill)이 0입니다. 우리의 41개 PR은 그 숫자가 41개든 4,100개든 API 비용 측면에서 동일하며, 이는 사실상 비용이 들지 않는다는 뜻입니다. 이것은 단순한 할인이 아니라, 다른 축(axis)의 문제입니다. 솔직히 말해서 하드웨어, 전력, 운영은 실제 총 소유 비용(TCO, Total Cost of Ownership)에 해당합니다. 하지만 핵심은 더 좁은 범위의 주장이며, 그것이 바로 중요한 지점입니다. Uber의 예산을 폭증시켰던 바로 그 요소인, 다음 에이전트 실행(agentic run)의 '한계(marginal)' 비용이 사라졌다는 것입니다.

클라우드를 전혀 사용할 수 없는 경우 이것이 중요한 이유

대부분의 팀에게 이것은 비용과 통제에 관한 이야기입니다. 어떤 팀들에게는 이것이 유일한 이야기이기도 합니다.

GitHub Copilot과 Amazon Q는 온프레미스에서 실행되지 않습니다. 에어 갭(air gap) 뒤에 있는 GitHub Enterprise Server를 사용하는 조직, 즉 국방, 규제 대상 금융, 보호된 데이터에 접근하는 코드를 다루는 의료 분야의 조직에게 지배적인 에이전트 기반 코딩 도구들은 정책의 문제가 아니라, 아키텍처적으로 사용 불가능한 대상입니다. 소스 코드를 제3자의 추론 엔드포인트(inference endpoint)로 전송하는 행위는 바로 컴플라이언스(compliance, 규제 준수) 체계가 방지하고자 하는 바로 그 일입니다.

전적으로 귀하가 소유한 하드웨어에서 실행되고, 귀하가 호스팅하는 모델하고만 통신하며, 통과한 모든 관문에 대한 감사 가능한 기록(auditable record)을 생성하는 코더는 차원이 다른 존재입니다. 이는 클라우드 에이전트가 들어갈 수 없는 공간을 위한 에이전트 기반 코딩(agentic coding)입니다. 이는 LLMKube가 존재하게 만드는 것과 동일한 제약 조건이 LLMKube를 구축하는 행위에도 적용된 것입니다.

그 감사 가능성(auditability)은 막연한 목표가 아닙니다. 이번 주에 우리는 모든 Foreman 실행에 대해 지속 가능하고 내보낼 수 있는 감사 기록을 출시했습니다. 이 기록은 어떤 모델과 엔드포인트가 서비스를 제공했는지, 판결(verdict)은 무엇이었는지, 어떤 레일(rails)이 작동했는지를 캡처하며, 실제 컴플라이언스 추적(compliance trail)이 될 수 있을 만큼 충분히 오래 보존됩니다. 이제 하네스(harness)는 검사한 내용을 기록합니다.

이미 하드웨어를 소유하고 있는 사람들

이 모든 내용은 한 그룹에게는 새로운 소식이 아닙니다. 바로 수년 동안 자신의 홈 랩(home labs)에서 로컬 모델을 실행해 온 사람들입니다.

그 커뮤니티는 더 이상 비주류가 아닙니다. r/LocalLLaMA는 2026년 6월 기준 757,000명의 멤버를 돌파했으며, 이는 단 1년 만에 267,000명 이상 증가한 수치입니다. 이러한 성장은 진정으로 뛰어난 오픈 웨이트 (open-weight) 코딩 모델들의 등장과 궤를 같이합니다. 이들은 단순히 재미로 쓰는 장난감이 아닙니다. 자체 모델 카드 (model card)에 따르면, 24B 모델인 Devstral Small 2는 SWE-bench Verified에서 68%의 점수를 기록하며, 약 15GB의 VRAM(단일 RTX 4090 또는 32GB Mac)에서 실행됩니다. Qwen의 코더 (coder) 모델들도 동일한 급의 하드웨어에서 작동합니다. 성능이 우선이며, 가격은 그에 따른 결과일 뿐입니다.