grok-build 저장소를 처음 보면 “무료 코딩 에이전트인가?”라는 질문이 자연스럽다. 답은 반쯤 그렇다. 도구의 소스코드와 CLI는 무료로 쓸 수 있지만, 기본 xAI 모델을 호출하는 비용과 로컬에서 모델을 실행하는 비용은 별개의 문제다.
이 글은 그 구분을 먼저 세우고, Ryzen AI 9 HX 370·Radeon 890M·메모리 약 28GB인 노트북에서 로컬 모델을 어디까지 현실적으로 쓸 수 있는지 점검한 기록이다.
결론부터. 이 환경에서는 3B–4B급 양자화 모델을 로컬 코딩 보조로 쓰는 선택이 현실적이다. 7B–8B급도 가능은 하지만 응답성과 작업 범위를 낮춰야 하며, 14B 이상을 상시 코딩 에이전트로 쓰는 선택은 권하기 어렵다.
먼저 구분할 것: 도구 비용과 모델 비용
Grok Build는 전체 화면 터미널 UI, 파일 편집, 셸 명령 실행, 웹 검색, 헤드리스 실행을 제공하는 코딩 에이전트다. 저장소의 1차 코드에는 Apache-2.0 라이선스가 적용된다. 즉 도구를 내려받아 실행하거나 구조를 공부하고 포크하는 일 자체에 라이선스 비용은 없다.
하지만 기본 모델을 xAI API로 호출하면 사용량 과금이 발생한다. 2026년 7월 기준 xAI 가격표에는 grok-build-0.1이 입력 100만 토큰당 $1, 출력 100만 토큰당 $2로 표시되어 있다. 다른 모델을 고르면 가격도 달라진다. 모델 요금은 바뀔 수 있으므로 실제 사용 전에는 항상 xAI Pricing을 다시 확인하는 편이 맞다.
| 층위 | 무료 여부 | 실제로 드는 것 |
|---|---|---|
| Grok Build 소스·CLI | 무료 | 설치와 유지 시간 |
| xAI API 모델 | 사용량 과금 | 토큰·도구 호출 비용 |
| 로컬 모델 | API 요금 없음 | 디스크, 전력, 메모리, 응답 시간 |
따라서 “무료로 쓴다”는 말은 보통 두 가지 중 하나다. xAI 모델을 거의 호출하지 않는다는 뜻이거나, 로컬 모델 서버를 연결한다는 뜻이다.
Grok Build를 로컬 모델의 껍데기로 쓸 수 있는가
가능하다. 공식 문서는 ~/.grok/config.toml에 모델 ID, base_url, 환경변수 키를 넣어 커스텀 모델을 등록하는 방식을 안내한다. 그래서 OpenAI 호환 API를 제공하는 로컬 런타임을 붙일 수 있다. Grok Build overview
이 구조는 단순하다.
1 | Grok Build |
다만 “연결된다”와 “쓸 만하다”는 다른 질문이다. 코딩 에이전트는 한 번의 짧은 답변보다 긴 컨텍스트, 파일 읽기, 도구 호출, 반복 수정에 더 많은 자원을 쓴다. 그래서 모델 이름보다 먼저 메모리, GPU 가속, 그리고 기다릴 수 있는 시간을 판단해야 한다.
이 PC에서 확인한 실행 기반
이번 확인에서 읽힌 사양은 다음과 같다.
| 항목 | 값 | 판단에 미치는 의미 |
|---|---|---|
| CPU | AMD Ryzen AI 9 HX 370, 12코어·24스레드 | CPU 추론의 기본 체력은 충분하다. |
| 시스템 메모리 | 약 28GB | 소형·중형 양자화 모델을 메모리에 올릴 여유가 있다. |
| GPU | AMD Radeon 890M 내장 그래픽 | 전용 대용량 VRAM GPU와는 다르게 접근해야 한다. |
| 표시된 그래픽 메모리 | 약 4GB | 대형 모델 전체를 GPU에 상주시킬 여유는 작다. |
여기서 4GB는 전용 GPU의 넉넉한 VRAM을 뜻하지 않는다. 890M은 시스템 메모리를 공유하는 내장 GPU다. 모델이 실행은 되더라도 GPU가 맡는 비율, 드라이버, 런타임 경로에 따라 성능 차이가 크게 난다.
Ollama는 Windows에서 AMD Radeon GPU를 지원한다고 안내한다. 그러나 Windows ROCm 지원 목록은 주로 외장 Radeon RX·Radeon Pro 계열을 열거한다. 추가 GPU 지원은 Vulkan 경로를 통해 제공되며, 이 경로는 하드웨어와 드라이버 조합에 따라 실제 결과를 확인해야 한다. Ollama Windows 문서와 GPU 지원 문서를 함께 보는 이유다.
현실적인 모델 크기
다음 표는 “실행 가능 여부”보다 “코딩 보조로 견딜 만한가”에 초점을 둔다. Q4 같은 양자화 모델을 전제로 한 보수적 출발점이다.
| 모델 규모 | 이 환경에서의 판단 | 권장 용도 |
|---|---|---|
| 1.5B–4B | 권장 | 코드 설명, 짧은 수정, 문서화, 명령어 보조 |
| 7B–8B | 조건부 가능 | 작은 저장소의 단발성 분석, 기다림을 감수한 실험 |
| 14B 이상 | 비권장 | 응답 시간과 컨텍스트 여유가 줄어 상시 에이전트 용도와 맞지 않음 |
이 표는 절대적인 한계선이 아니다. 컨텍스트 길이, 동시 실행 프로그램, 모델 양자화, GPU 가속 여부가 결과를 바꾼다. 그래도 출발점은 분명하다. 처음부터 큰 모델을 내려받아 답답한 에이전트를 만드는 것보다, 3B–4B 모델로 파일 읽기와 짧은 수정이 끊기지 않는지 확인하는 편이 낫다.
가장 작은 실험 순서
- Ollama 같은 로컬 런타임을 설치하고 최신 AMD 그래픽 드라이버를 적용한다.
- 3B–4B급 코드 모델 하나만 내려받는다.
- 짧은 프롬프트로 응답 시간과 메모리 점유를 확인한다.
- Grok Build의 커스텀 모델 설정에 로컬
base_url을 연결한다. - 작은 Git 저장소에서 “파일 설명 → 한 함수 수정 → 테스트 실행”만 시켜 본다.
처음부터 --always-approve 같은 자동 승인 옵션을 켜지는 않는 편이 좋다. 헤드리스 모드에는 해당 옵션이 있지만, 로컬 모델은 코드 지시를 잘못 해석하거나 반복 루프에 빠질 수 있다. 승인 단계를 남기고, 수정 대상과 실행 명령을 좁힌 상태에서 검증하는 것이 안전하다. Headless & Scripting
무엇을 로컬에 맡기고, 무엇을 API에 맡길까
가장 실용적인 방식은 경쟁이 아니라 분업이다.
| 로컬 3B–4B 모델에 맡길 일 | 더 강한 API 모델에 맡길 일 |
|---|---|
| 코드와 로그의 1차 요약 | 대규모 설계 변경 |
| 함수 단위 수정 초안 | 여러 모듈에 걸친 디버깅 |
| 문서화·주석·명령어 초안 | 긴 컨텍스트를 이용한 복잡한 추론 |
| 비공개 파일을 넘기지 않는 단순 작업 | 최종 코드 리뷰와 중요한 의사결정 |
로컬 모델의 강점은 “공짜 대체재”라는 데만 있지 않다. 작은 반복 작업을 가까이에 두고, 어떤 파일을 어디까지 읽힐지 직접 통제할 수 있다는 데 있다. 반대로 복잡한 문제에서는 모델 가격보다 사람의 대기 시간이 더 비싸질 수 있다.
판단의 기준은 모델 크기가 아니라 작업 흐름이다
이 환경은 로컬 AI를 못 쓰는 PC가 아니다. 다만 전용 고성능 GPU 워크스테이션처럼 큰 모델을 빠르게 밀어붙이는 장비도 아니다.
그래서 가장 좋은 출발은 명확하다. 작은 모델로 반복 작업을 맡기고, 실제 프로젝트에서 응답 시간과 수정 품질을 기록한다. 그 기록이 쌓이면 로컬 모델을 계속 유지할지, API를 병행할지, 더 큰 GPU가 필요한지를 비용과 경험을 함께 보며 결정할 수 있다.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.