AI Coding.Info
RepositoriesREPORTS
ABOUT

로컬 LLM은 AI Coding에 사용할 수 있습니까? ~데이터로 보는 2026년 7월의 AI Coding의 동향 정리~

저자: @kotauchisunsun

공개일: 2026/08/12

AI Coding Agent의 2026년 8월 동향

AI Coding.Info라는 사이트를 2025년 7월부터 운영하고 있습니다.

https://ai-coding.info/

https://x.com/AICodingInfo

이것은 Claude Code, Codex CLI 또는 Github Copilot, Gemini 등 AI Coding Agent에 대한 이용 동향을 Github의 리포지토리 정보에서 정점 관측하는 사이트입니다. AI Coding Agent의 이용 판정으로서 다음과 같은 조건으로 매일 조사를 실시하고 있습니다.

지난달 동향

https://ai-coding.info/reports/articles/20260703

AI Coding Agent 이용률은 13.0%

**AI Coding Agent의 리포지토리 사용률은 13.0%**이며 지난 12.1%에서 0.9% 증가했습니다.

image.png

image.png

2026/8/1의 AI Coding Agent 이용률

https://ai-coding.info/?date=2026-08-01#adoption-rate

2026/7/1의 AI Coding Agent 이용률

https://ai-coding.info/?date=2026-07-01#adoption-rate

2026/7/1~2026/8/1까지의 AI Coding Agent 이용률 추이

https://ai-coding.info/?date=2026-04-01&since=2026-07-01&until=2026-08-01#share-trend

AI Coding Agent의 제품별 공유

제품별 점유율은 다음과 같습니다.

순위제품명점유율
1위Codex CLI40.8%
2위Claude Code32.0%
3위Copilot Agent15.1%
4위Gemini CLI(Antigravity)5.3%
5위Cursor4.4%

Codex CLI의 점유율이 상승하는 가운데 Claude Code는 그대로. Copilot Agent나 Gemini CLI(Antigravity)에 관해서도 미감소라는 추이를 하고 있습니다. 조금 주목하고 있던 것이 Cursor입니다. Cursor가 SpaceX에 인수된다. 라는 뉴스가있었습니다.

https://www.nikkei.com/article/DGXZQOGN16BC70W6A610C2000000/

그 때문에, 이 Cursor의 쉐어율에도 변화가 있는 것인가. 라고 생각했습니다만, 지난달은 4.7%, 이번 달은 4.4%이므로, 거기까지 큰 변동은 없습니다. 후술하는 리포지토리수를 보면 7/1에 Cursor의 채용 리포지토리는 85건, 8/1 시점에서도 85건으로 바뀌지 않았습니다. 그 때문에, 이 현상에 대해서 말하면, 전체적으로 AI Coding Agent를 이용하고 있는 리포지토리의 모수가 상승했지만, Cursor의 이용수는 증가하지 않았다. 따라서 전체적으로 점유율이 떨어지고 있습니다. 라는 현상이 되고 있습니다. 다만, AI Coding.Info의 조사의 특성상, Cursor 고유의 설정 파일(.cursor)을 가지는 리포지토리수는 변하지 않는다. 라는 이야기이며, Cursor 자신은 AGENTS.md에 대응하고 있습니다. AI Coding.Info에서는 AGENTS.md를 가진 리포지토리 수 = Codex CLI의 채용수로 하고 있기 때문에, Cursor를 이용하고 있지만, Codex CLI로 카운트되고 있을 가능성은 있어, 보이지 않는 부분에서 이용수가 증가하고 있을 가능성이 있습니다.

image.png

2026/8/1의 AI Coding Agent 점유율

https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#agent-share

2026/7/1의 AI Coding Agent 점유율

https://ai-coding.info/?date=2026-07-01&since=2026-07-01&until=2026-08-01#agent-share

프로그래밍 언어별 AI Coding Agent 사용 상황

1번 AI Coding Agent가 이용되고 있는 프로그래밍 언어는 「TypeScript」, 2번째는 「Python」, 3번째는 「Rust」, 4번째는 「Go」, 5번째는 「C#」입니다. 「TypeScript」의 AI Coding의 채용률이 높은 것은 변하지 않고, 한편, 2군으로서의 「Python」・「Rust」・「Go」, 3군으로서 「C#」당의 구도는, 최근 최근의 변함없는 트렌드가 되고 있습니다.

image.png

2026/8/1의 AI Coding Agent 프로그래밍 언어별 순위

https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#language-agent-rank

2026/7/1의 AI Coding Agent 프로그래밍 언어별 순위

https://ai-coding.info/?date=2026-07-01&since=2026-07-01&until=2026-08-01#language-agent-rank

AI Coding Agent 사용 리포지토리 수의 1 개월 추이

2026/07/01 시점에서는 1,794건이었던 리포지토리 수가, 2026/08/01 시점에서는 1,940건이 되어, AI Coding Agent를 이용하고 있는 리포지토리는 146건 증가하고 있습니다.

image.png

2026/7/1에서 2026/8/1까지 AI Coding Agent를 사용하는 리포지토리 수의 변화

https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#time-based-bar-chart

로컬 LLM은 AI Coding에 사용할 수 있습니까?

6월에 Mythos와 Fable 5라는 차세대 LLM이 Claude에서 공개되었으며, 그 성능에 업계가 충격을 받았습니다. 그러나 그 후 중국의 Kimi사로부터 Kimi-K3라는 오픈 웨이트의 모델이 공개되어 그것이 거의 Fable급이다. 라는 것이 화제가 되었습니다. 실제 벤치마크를 봐도 가까운 수치가 되고 있습니다.

image.png

https://artificialanalysis.ai/#intelligence-category-tabs

그렇게 생각했을 때,

** 로컬 LLM도 AI Coding의 선택에 들어오는 것이 아닌가? **

라고 생각할 수도 있다고 생각합니다. 그 근처를 조사했습니다. 앞의 그래프에서 주요 오픈 웨이트의 LLM 모델을 열거한 것이 아래 표입니다.

모델명회사명발표일매개변수 수활성 매개변수 수컨텍스트 길이인텔리전스 색인
Kimi K3(max)Kimi(중국)2026/072,800B104B1M60
GLM-5.2(max)Z AI(중국)2026/06756B40B1M53
DeepSeek V4 Flash 0731DeepSeek(중국)2026/07284B13B1M52
MiMo-V2.5-ProXiaomi(중국)2026/041,023B42B1M43
Muse Glimmer (high)Meta(미국)2026/0830B256K35
Gemma 4 31B (Reasoning)Google(미국)2026/0430.7B256K30

그러나 이들이 실제로 자신이 가지고 있는 PC에서 움직이는 것인가. 라는 것은 잘 모르겠습니다. 그래서, 생각한 판별 방법이,

필요한 VRAM 메모리는

매개 변수 1[B]당 2[GB]

입니다. 자신이 가지고 있는 PC의 VRAM 메모리 용량과, 움직이고 싶은 모델의 파라미터 수로부터 움직일지 어떨지를 추정할 수 있습니다. 그러므로

**Kimi-K3를 움직이려고 하면, 수식상은, 5.6TB(5,600GB)의 메모리가 필요합니다. **

이 이유를 설명합니다. 표준적으로 배포되고 있는 LLM의 모델은 bf16이나 fp16라고 하는 정밀도의 소수를 이용해 가중치가 표현되고 있습니다. 이들은 매개변수당 2Byte 필요합니다. 자세히, 30[B]와 같은 표기는 매개변수의 수이고 B는 Billion의 약자로 10^9를 나타냅니다. 따라서 30[B]와 같은 모델은 30×10^9개의 가중치 데이터가 있음을 알 수 있습니다. 그리고 1[GB]=1*10^9[Byte]입니다. 그렇게 생각하면, 방금전 표준적인 가중치는 2Byte로 격납되고 있다고 하는 것이었습니다. 라는 계산이 됩니다. 이것은 앞에서 설명한 "매개 변수 1 [B] 당 2 [GB]"의 의미입니다. 그러나 이것은 어디까지나 대략적인 것으로, 이것은 가중치를 VRAM에 로드하기 위한 최저 필요 요건이며, 그 이외에 메모리를 사용하는 일도 있기 때문에, 어디까지나 그 이상은 없으면 엄격하다. 라는 VRAM 용량이 됩니다.

여기서 양자화라는 개념이 나옵니다. Q4_0이라든가 Q4_K_M등이 본 적이 있는 것은 아닐까요. 이것은 가중치를 비트 수로 압축하는 기술입니다. 그 때문에 Q4_0의 경우는, 싹둑이라고 하면, 가중의 용량이 4bit(Q4_0의 4의 부분)가 됩니다. 따라서 이 경우에는 1[B]당 0.5[GB]의 용량이 됩니다. 이것들을 조견표로 하면 다음과 같이 됩니다

양자화 방법1[B]당 필요한 메모리 양[GB]
bf16,fp16(표준)2.0
Q8_01.0
Q4_00.5

Q4_K_M이라고 하는 표기를 보겠다고 생각합니다만, 잡히는 것은 Q4_0보다 정밀도를 높이는 대신에, 조금 사용하는 메모리 용량이 많아지는 모델이다. 라고 인식하는 것이 좋습니다. 또 다른 구별 방법이 있으며 단순히 가중치 파일(safetensor나 gguf)의 파일 용량을 봅니다. 이것이, VRAM의 메모리 용량을 넘고 있는 경우, 대체로 움직이지 않는다. 라고 생각해도 좋다고 생각합니다.

여기에서 VRAM의 메모리 양과 양자화 방식과 파라미터 수를 조견표로 했습니다.

VRAM 메모리 용량[GB]파라미터 수(bf16,fp16)[B]파라미터 수(Q8_0)[B]파라미터 수(Q4_0)[B]
84816
1681632
24122448
32163264
643264128
12864128256
256128256512
5122565121024
102451210242048
2048102420484096

대체로 얼마나 할 수 있을까. 라고 하는 것을 생각하면(자) VRAM 8GB의 모델이라고 하면, RTX 5050이 되어, Amazon 가격으로 5.5만엔입니다. 이것은 Q8_0에서 양자화된 8[B]정도의 모델이라면 움직일지도 모른다. 라는 수준입니다.

https://link.amazon/B0brulI9R

VRAM이 16GB가 되면 RTX 5060 Ti당 모델이 되어 10.8만엔 정도입니다. 이 근처에서, Q4_0의 양자화라면 빠듯한 30[B]급의 LLM이 움직이는지 움직이지 않는가. 라는 수준입니다.

https://link.amazon/B0ghUQISo

VRAM이 32GB가 되면 RTX 5090의 플래그십 모델이 되어, 79.5만엔이 됩니다. 이렇게 되면 상당한 각오가 없으면 손이 나오지 않는 수준일까. 라고 생각합니다. 이것은 Q8_0의 양자화로 30[B]급의 모델이 움직이거나 움직이지 않는가. 정도의 레벨이 됩니다.

https://link.amazon/B03EseQp5

이 근처가 민생품 레벨의 최상위 라인입니다. 그럼 업무용 레벨이 되면 RTX PRO 6000 Blackwell이 96GB의 메모리 탑재가 되고 있습니다. ** 가격이 235만엔입니다. ** 여기서 Q4_0의 양자화 레벨에서도, 192[B]의 모델 밖에 움직이지 않기 때문에, 플래그십 모델은 움직이지 않습니다.

https://link.amazon/B0g76ngZz

그리고, 서버에 도입하는 GPU 클러스터용의 데이터가 있었으므로, 참고 정도에 올립니다. NVIDIA B300의 경우, 메모리가 288GB, 가격이 863만엔이 되고 있습니다. 하나라면 Q8_0 양자화 DeepSeek V4 Flash 0731이 움직일지도 모른다. Q4_0이라면 움직일 것입니다. 2개 있으면(1,700만엔 상당), Q4_0 양자화의 MiMo-V2.5-Pro가 움직일지도 모릅니다.

image.png

https://www.nttpc.co.jp/cgi-bin/gpu/simulation/custom/index.cgi

따라서 메모리 양과 파라미터 수를 비교하면 이것 정도의 피부감입니다. 물론 더 이상 논쟁의 여지가 있고, 이것은 메모리를 타거나 타지 않는가. 뿐만 아니라, 당신은, 보통 유효한 tok/s 나오는가? 또 다른 과제가 있습니다. 이 기사에서는 매우 기초적인 이야기를하고 있습니다. LLM에는 Dense나 MoE라는 아키텍처가 있어, MoE에서는 실제로 계산되는 것은 액티브 파라미터만이며, 실행 방법에 따라서는 모든 Expert를 상시 메모리에 올리지 않고, 필요한 Expert를 스토리지 등으로부터 읽어내는 것으로 물리 메모리량을 삭감하는 방법도 있습니다. 그러나 모델을 실행하는 방법에는 특별한 부분이 있으므로 스토리지에서 메모리로의로드가 병목 현상이 될 수 있습니다. 같은 이야기도 있습니다만, 여기에서는, 그러한 세세한 부분은 빼고, 모델의 가중치를 모두 메모리에 싣는 경우의 단순한 용량으로 생각하고 있습니다.

그렇다고 해서, 현행의 Q4_0나 Q8_0로 양자화된 플래그십 모델을 움직이는 것이면, 최저라도 1,000만엔급 정도의 머신이 필요할까. 라는 것이 피부감입니다. 한편, 특수한 하드로 보다 양자화를 다한 경우라면 움직이는 경우가 있습니다. 예를 들어, M4 Mac의 128GB 메모리 탑재판(판매 종료)이라든지 DGX Spark(메모리 128GB)로, 2bit 양자화, 3bit 양자화를 움직이고 있는 사람은 있습니다.

https://zenn.dev/tkhr_sait/articles/20260508_try-local-deepseek-v4

https://dev.classmethod.jp/articles/dgx-spark-deepseek-v4-flash-0731-llama-cpp/

반대로 말하면 개인에서는 이 정도가 한계일까. 라는 피부감입니다. 개인적으로 주목하고 있는 것은 1bit 양자화로, 유명한 곳에서는 모델에서는 Bonsai, 기술로서는 BitNet 등이 있습니다만, 1bit 양자화를 할 때의 노하우가 그다지 공개되어 있지 않기 때문에, 손을 내놓지 않습니다(아마 방대한 시간이 걸릴 것이고, 추론 정도도 내려간다).

그래서 개인적으로는, DeepSeek를 1bit 양자화한 것(약 35.5GB)이 나오면, 궁리에 따라서는 민생용 GPU로 로컬로 움직일 수 있는 세계가 보입니다만, 현재는, 그것이 없기 때문에, 꽤 힘들다. 라는 것이 솔직한 곳입니다.

그러므로

**플래그십 모델을 로컬 LLM으로 이동하는 것은 현실적이지 않다. **

라는 것이 대략적인 감상입니다. 정말로 움직이고 싶다면, 나름대로 검증할 필요가 있다고 생각합니다.

감상

이번에는, 로컬 LLM에 초점을 맞추고, 이야기를 해 보았습니다. Kimi-K3가 나왔을 때, 꽤 충격으로, 로컬 LLM에서 Fable급이 움직인다! 그렇다고 하는 것은, 꽤 인상적이었습니다만, 자신이 가지고 있는 기재에서는 움직이는 것조차 남아 있지 않구나. 라는 것이 솔직한 감상이었습니다. 과거에도 로컬 LLM의 기사를 올려 썼습니다만, 그 때도 그다지 잘 움직이지 않았기 때문에, 좀 더 스스로도 심호리하고 싶다. 라고 생각했습니다.