• HackerNews에서 「Claude/GPT를 로컬 모델로 완전히 대체하여 일상적인 코딩을 하고 있는 사람이 있는가?」라는 질문이 780pts를 모았으며, 약 50건의 실무자 보고가 수집되었다.
• 2026년 6월 시점의 결론은
  「전면 교체는 아직 이르지만, 용도를 구분하면 상용 드라이버가 된다」.
  보고자 중 다수가 Qwen3.6 27B (dense)

또는 35B-A3B (MoE)

,
Gemma 4 31B

,
DeepSeek V4 Flash

를 llama.cpp

• OpenCode

로 구동하고 있다. - 핵심은 「
dense와 MoE 중 어느 것을 선택할 것인가」 「하네스 (에이전트 실행 기반)의 완성도」 「프론티어 모델과의 역할 분담」의 3가지 포인트다. 본 기사는 이 생생한 논의를 일본 엔지니어의 의사결정 프레임워크로 재구성한다.

「로컬 LLM으로 코딩하기」는 2024~2025년에는 취미의 영역이었다. 작동은 하지만, 프론티어 모델 (Claude / GPT / Gemini)과의 격차가 너무 커서 본업의 상용 드라이버로는 사용할 수 없다 —— 라는 것이 공통된 인식이었다.

그 전제가 2026년에 들어서며 조용히 무너지기 시작하고 있다. 상징적인 것이 2026년 6월 15일에 HackerNews에서 780pts를 모은 다음 질문이다.

Has anyone here fully swapped Claude/GPT for a local model as their main coding tool, not just for side experiments? (실험이 아니라 메인 코딩 툴로서 Claude/GPT를 로컬 모델로 완전히 교체한 사람이 있는가?)

수집된 약 50건의 답변은 「Yes」가 예상외로 많다. 게다가 「돌려보았다」 수준이 아니라, 월 100달러의 Claude 구독을 해지했다, 자동차용 C/C++ 본업 코드를 3~4개월째 작성하고 있다와 같이 생활과 업무에 편입시킨 보고가 이어진다.

일본 엔지니어에게 이것이 중요한 이유는 3가지다.

비용: 프론티어 모델의 종량제 과금 및 구독료는 엔저 상황에서 부담스럽다. 팀원 전체 분량이라면 무시할 수 없는 고정비가 된다. -
데이터 주권 / 코드 비전송: 수탁, 금융, 공공, 제조 등 소스 코드나 설계 정보를 외부 API로 보낼 수 없는 현장이 일본에는 많다. 로컬 실행은 「코드가 머신 밖으로 나가지 않는다」를 기술적으로 담보할 수 있다. -
가용성 리스크: 특정 모델이나 특정 벤더에 대한 의존은 요금 개정, 모델 폐지, 속도 제한(Rate Limit)으로 인해 업무가 중단될 리스크를 안고 있다.

문제는 「로컬에서 돌아간다」와 「프론티어를 대체할 수 있다」 사이의 거대한 간극이다. 본 기사는 Qiita에서 흔히 보이는 「VRAM ◯GB로 돌려보았다」 「과금 0원으로 만들 수 있는가」와는 다른 각도 —— 실무의 상용 드라이버로서 대체 가능한 경계선은 어디인가 —— 를 HN 실무자 보고라는 1차 정보를 통해 실증적으로 도출한다.

HN의 답변을 정리하면 구성이 놀라울 정도로 수렴하고 있다.

모델	종별	보고자의 평가 (요약)
Qwen3.6 27B	dense	「느리지만 정밀도가 한 단계 위". 본업 C/C++・Python에 사용한다는 목소리가 복수
...

중고 GPU 2장 장착: RTX 3090 ×2

(5년 전 게이밍 PC에 증설)로 150 tok/s, 300k 컨텍스트를 VRAM 내에 수용하는 사례. -
단일 GPU: RTX 3090 ×1

으로 Qwen3.6-35B를 「많은 클라우드보다 빠르다」고 평가하는 사례. -
통합 메모리 기기: Mac Studio 128GB/512GB

,
Strix Halo 128GB

(랩톱 계열 칩, 유휴 소비 전력 거의 제로). -
차세대: RTX Pro 6000 Blackwell

로 Gemma 4 31B / DeepSeek를 고속 구동.

tok/s는 구성에 따라 25~160 사이로 나뉜다. 「속도 = 쾌적함」이 아니라는 점도 반복해서 지적된다 (후술).

OpenCode

, llama.cpp

, Ollama

, LM Studio

, 그리고 "Pi"라고 불리는 하네스가 빈번하게 등장한다. 대부분이 **「llama.cpp로 모델을 서빙하고, OpenCode 등의 에이전트로부터 OpenAI 호환 API로 호출한다」**는 동일한 구성이다.

보고는 단순한 찬양이 아니라 명확한 대립축을 포함하고 있다.

긍정파: 「Claude 구독을 해지했다」, 「실무에서 상용 중이다」(Qwen3.6 27B / Gemma 4 31B).
회의파: 「최신 최량(State-of-the-art) 모델을 사용하지 못해 발생하는 기회비용이 너무 크다. 매달 조사하고 있지만, 로컬을 Claude Code(Sonnet/Opus) 수준으로 끌어올리는 데 드는 수고와 비용은 현재로서는 맞지 않는다」.
핵심을 찌르는 목소리: "현재의 병목(Bottleneck)은 모델이 아니라, 대체 하네스(Harness)의 미숙함이다——큐 관리, 인터럽트(Interrupt), 서브 에이전트(Sub-agent), 목표 관리(Goal management)와 같은 기능과 사용 편의성이 약하다".

이 세 번째 지적이 본 기사에서 가장 주목해야 할 부분이다.

2026년 로컬 코딩에서 가장 먼저 직면하게 될 선택이 바로 이것이다.

MoE (예: Qwen3.6 35B-A3B): 총 파라미터 수는 크지만, 추론 시 활성화되는 것은 일부(3B)이다. 빠르며 VRAM을 적게 사용한다.
Dense (예: Qwen3.6 27B): 모든 파라미터가 매 토큰 계산에 관여한다. 느리지만 정밀도가 높다.

HN(Hacker News)에서는 여러 독립적인 보고자들이 "35B-A3B(MoE)보다 27B(Dense)의 코딩 정밀도가 명확하게 높다"라고 언급하고 있다. 자동차용 소프트웨어를 작성하는 보고자는 Dense 모델을 선택했으며, 25~40 tok/s의 느린 속도를 높은 정밀도로 정당화하고 있다.

교훈: 벤치마크의 토큰 속도에 현혹되어 MoE를 선택하면, 에이전트적인 다단계 태스크에서 "빠르지만 틀리는" 상태에 빠지기 쉽다.

코딩은 정확도가 레이턴시(Latency)보다 더 중요한 영역이라는 점을 현장의 선택이 말해주고 있다.

로컬에서는 GGUF 형식의 양자화(Quantization) 모델(Q4_K_M, UD-Q4_K_XL, Q6_K, Q8 등)을 사용한다. 양자화 수준을 낮출수록 메모리 사용량은 줄어들지만 품질은 떨어진다. 또한 컨텍스트 길이(Context length)가 VRAM을 크게 점유한다. 에이전트는 방대한 파일과 도구 출력값을 문맥에 쌓아야 하므로, 이 부분이 병목이 되기 쉽다.

llama.cpp로 서빙하는 전형적인 구성은 다음과 같다 (OpenAI 호환 서버로 구동).

# Qwen3.6-35B-A3B(MoE)를 4bit 양자화 및 256k 컨텍스트로 서빙
# --n-gpu-layers로 GPU에 올릴 레이어 수, -c로 컨텍스트 길이를 제어
./llama-server \
...

에이전트 측(OpenCode)에서는 로컬 서버를 "프로바이더(Provider)"로 지정하기만 하면 된다.

// opencode 설정 예시: 로컬의 llama.cpp를 OpenAI 호환 엔드포인트로 등록
{
"provider": {
...

VRAM이 부족할 경우의 정석적인 테크닉은 "MoE의 전문가 레이어(Expert layer)를 일부러 GPU에 올리지 않고 CPU/RAM으로 넘기는" 배치 방식이다. Qiita에도 "VRAM 12GB로 Qwen 35B를 구동하기"와 같은 계열의 기사가 있지만, 본 기사의 관심사는 단순히 "구동하는 것"이 아니라 "업무에 사용할 수 있는 컨텍스트 길이를 확보하면서 정밀도를 유지할 수 있는가"에 있다.

가장 냉철한 평가는 이것이다. 한 보고자는 Qwen3.6-35B + OpenCode의 품질을 **"8~12개월 전의 에지(Edge, 최첨단) 모델 수준"**이라고 표현했다.

이는 중요한 상대화이다. 2026년의 31B 클래스 로컬 모델은 2025년의 프론티어(Frontier)급 모델을 따라잡았다. 하지만 프론티어 모델 자체도 계속 진보하고 있기 때문에 최전선과의 격차(약 1년)는 메워지지 않는다. 즉——

• "1년 전의 Claude/GPT로 충분했던 작업"은 로컬로 대체 가능하다.
• "최전선이 아니면 풀 수 없었던 난제" (복잡한 SIMD 최적화 등)는 여전히 프론티어 모델이 필요하다. HN에서도 Kimi 2.6/GLM 5.1이 AVX512의 bit 행렬 전치(bit matrix transposition) 작업에서 "참패"한 사례가 언급된다.

그리고 핵심. 여러 보고자가 입을 모아 말하는 것은, 막히는 지점은 이제 모델의 지능이 아니라 에이전트 실행 기반(Harness)의 성숙도라는 점이다. 인터럽트, 큐 관리, 서브 에이전트, 목표 구동 루프(Goal-driven loop)——Claude Code나 Codex가 다듬어 놓은 UX를 OSS 하네스(OpenCode 등)는 아직 완전히 재현하지 못하고 있다.

역설적으로 말하면, 로컬 모델의 실력을 끌어낼 수 있느냐는 **"어떤 모델을 선택하느냐"보다 "어떤 하네스로 어떻게 운용 설계를 하느냐"**에 달려 있다.

여기까지를 종합해 보면, 일본의 현장에서 취해야 할 태도는 "전부 로컬"도 "전부 프론티어"도 아닌, 하이브리드 설계다. HN에서도 실제로 이 패턴이 가장 많았다.

보고에서 반복적으로 나타난 구성은 다음과 같다.

[Opus/Codex] 계획 수립 (설계·태스크 분해·수락 조건)
│ 플랜을 전달
▼
...

• 프론티어(Frontier) 모델에 보내는 것은 「계획」 「리뷰 대상 차분(diff)」 등
  추상도가 높은 정보로 한정하여, 코드 전체의 유출을 억제한다. - 반복 구현이라는
  토큰 소모가 가장 큰 공정을 로컬로 돌려, 비용을 극적으로 낮춘다. - 다른 보고자는 「여러 에이전트를 연쇄시켜, 로컬 모델이 작성한 코드를 다른 역할(Role)이 리뷰하고, Playwright로 에러를 검출하여,
  에러가 없는 차분만을 다음 공정으로 전달하는」 오케스트레이션(Orchestration)을 통해 품질을 끌어올리고 있다.

관점	로컬 (Qwen/Gemma 31B 클래스) 적합	프론티어 적합
태스크 유형	스코프가 명확하고 정의된 구현, 리팩토링, 정형화된 작업	모호한 사양으로부터의 설계, 최전선의 난제, UI 마무리
...

요건의 분리: 「외부 전송 금지 코드」를 전수 조사하여, 로컬 필수 영역을 정의한다. 이것이 투자 대비 효과(ROI)의 근거가 된다. -
모델 선정: 우선 dense 모델인 27~31B 클래스(Qwen3.6 27B / Gemma 4 31B)를 기준으로 한다. 속도가 필요한 국면에서만 MoE를 병용한다. -
하드웨어: 단일 RTX 3090 (중고)로도 31B 클래스 + 실용적인 컨텍스트(Context)는 현실적이다. 팀 공용이라면 통합 메모리 기기(Mac Studio / Strix Halo)나 다중 GPU도 선택지에 있다. -
하네스 (Harness): llama.cpp (서빙) + OpenCode를 기점으로 한다. 하네스의 권한 설정을 반드시 확인한다 (OpenCode는 자율적으로 파일 삭제 등 파괴적인 조작을 수행할 수 있다고 공식 절차에서도 경고하고 있다. 권한 요청 및 백업을 설정할 것). -
거버넌스 (Governance): 로컬에서도 「무엇을 외부 API로 보낼 것인가」에 대한 정책을 명문화한다. 하이브리드 운용에서는 경계 관리가 핵심이다. -
철수 라인 (Exit Line): 「최신 최상의 모델을 사용하지 않음으로써 발생하는 기회비용」을 정기적으로 재평가한다. 회의론자들의 지적대로 상황은 매달 변한다.

또한, 공급망(Supply Chain) 관점은 별도로 경계해야 한다. 모델이나 GGUF, 양자화된 가중치(Weights), 하네스의 플러그인을 출처가 불분명한 배포처로부터 취득하지 말 것 —— IPA의 「정보 보안 10대 위협 2026」에서도 공급망 공격은 조직 대상 위협의 상위에 위치한다. 로컬화는 외부 전송 리스크를 낮추는 한편, 도입물의 검증 책임은 자신에게 옮겨온다.

2026년 6월 시점의 현실적인 해답은, 「프론티어냐, 로컬이냐」의 이지선다가 아니라, 양자의 역할 분담을 어떻게 설계할 것인가이다.

지금 바로 시도하기: 수중에 RTX 3090 클래스가 있다면, llama.cpp + Qwen3.6 27B (dense) + OpenCode로 「정의된 구현 태스크」를 하나 맡겨본다. 「8~12개월 전의 프론티어급 성능」이 어디까지 통하는지 체감한다. -
dense를 기준으로 하기: 속도에 현혹되어 MoE부터 시작하지 않는다. 코딩은 정확성이 중요하다. -
하이브리드로 구성하기: 설계·검증은 프론티어, 반복 구현은 로컬. 비용과 데이터 주권을 동시에 확보한다. -
하네스에 투자하기: 병목 구간은 모델이 아니라 하네스다. 권한·중단(Interrupt)·서브 에이전트의 운용 설계가 성패를 가른다. 파괴적 조작 권한은 초기에 제한한다. -
기밀 영역에서 역산하기: 「외부로 내보낼 수 없는 코드」를 기점으로 로컬화의 스코프를 정하면, 투자 판단이 흔들리지 않는다.

로컬 모델은 「프론티어의 완전한 대체재」가 아니다. 하지만 「보낼 수 없는 코드를, 멈추지 않는 환경에서, 충분한 품질로 작성한다」는, 일본의 많은 현장이 안고 있는 고유한 제약에 대해서는, 2026년에 이르러서야 비로소 실용적인 해답이 되었다. 경계선을 올바르게 그을 수 있느냐가 앞으로 엔지니어의 차이를 만들 것이다.

• Ask HN: 일상적인 코딩을 위해 Claude/GPT를 로컬 모델로 대체한 사람이 있나요? (HN 토론 · 본 기사의 1차 정보)
• pierotofy/LocalCodingLLM (llama.cpp + Qwen + OpenCode 로컬 구성 절차 · 파괴적 작업에 대한 경고)
• OpenCode 공식 (로컬/셀프 호스팅 모델 대응 OSS 코딩 에이전트)
• llama.cpp 공식 리포지토리 (OpenAI 호환 서버 · GGUF 추론 엔진)
• Ollama 공식 (로컬 모델 실행 런타임)
• LM Studio 공식 (로컬 LLM 실행 GUI)
• Qwen 공식 리포지토리 (Qwen 시리즈)
• IPA 정보 보안 10대 위협 2026 (공급망 공격의 위치)