24GB 메모리를 탑재한 MacBook만으로 코딩 AI를 돌릴 수 있을까? 단순한 코드 자동완성을 넘어서 실제 프로젝트의 버그 수정까지 맡길 수 있다면, 유료 AI 코딩 서비스 없이도 개발이 가능할지 궁금해진다.
결론부터 말하면 제한적인 코드 수정에는 충분히 쓸 만했다. 하지만 복잡한 변경을 끝까지 맡기는 수준은 아니었다. 특히 모델이 커지면 성능보다 먼저 메모리와 응답 시간이 문제가 됐다.
이 글은 모델 소개나 벤치마크 점수 모음이 아니다. M4 Pro 24GiB 환경에서 공개 가중치 모델 네 개를 동일한 실제 코드 수정 과제로 테스트한 기록이다. 어느 범위까지 통과했고 왜 중단됐는지, 원격 유료 코딩 에이전트와 비교할 때 무엇이 빠져 있는지 구분해 정리했다.
어떤 MacBook에서 테스트했나?
시험 환경은 M4 Pro, CPU 14코어, 통합 메모리 24GiB의 MacBook Pro였다. macOS 26.5.2에서 VS Code, Chrome, ChatGPT, Slack과 macOS 가상 머신을 함께 실행한 상태로 메모리 실험을 진행했다.
코딩 품질 비교에는 동일한 llama.cpp 빌드와 설정을 적용했다.
| 항목 | 테스트 기준 |
|---|---|
| 장비 | Apple M4 Pro, 통합 메모리 24GiB |
| 추론 엔진 | llama.cpp build 11910 (63b4b303b) |
| 컨텍스트 | 8,192토큰 |
| 최대 출력 | 2,048토큰 |
| Temperature | 0 |
| 수정 시도 | 최대 2회 |
| 요청 제한 | 추론당 120초 |
| Thinking | 지원하는 런타임에서 비활성화 |
| 반복 | 모델별 3회, 실행 순서 교차 |
여기서 중요한 조건은 '24GB 전체를 AI가 독점하는 환경'이 아니라는 점이다. 실제 개발에서는 IDE와 브라우저를 끄고 모델만 켜 놓을 수 없다. 모델 파일이 메모리에 들어간다는 사실과 개발을 계속하면서 쓸 수 있다는 것은 다른 질문이다.
어떤 모델 네 개를 비교했나?
| 모델 | 실험 형식 | 모델 파일 크기 |
|---|---|---|
| NVIDIA Nemotron 3.5 Bolt E4B | BF16 | 비교표에 파일 크기 미기록 |
| Ornith 1.5 9B | Q4_K_M | 5.38GiB |
| Devstral Small 2 24B | Q4_K_M | 13.35GiB |
| Qwen3.8 27B | UD-Q4_K_M | 15.37GiB |
'27B니까 9B보다 코딩을 잘한다'는 식의 가정은 두지 않았다. 네 모델에 같은 과제를 주고, 결과 코드가 숨겨진 테스트를 통과했는지만 확인했다. 모델별로 과제를 유리하게 수정하지 않았다.
참고로 공개 가중치를 내려받을 수 있다는 사실이 실행 비용까지 0원이라는 뜻은 아니다. 노트북 구매비, 전기, 저장공간, 장시간 실행 시간은 별도 비용이다. 각 모델의 사용·재배포 조건도 개별 라이선스로 확인해야 한다.
'코딩 성공'은 무엇으로 판단했나?
테스트는 에이전트에게 '프로젝트를 알아서 완성해 줘'라고 맡기는 방식이 아니다. 상위 작업자가 분석과 계획, 수정할 파일 및 코드 영역을 먼저 정했다고 가정한다. 로컬 모델은 지정된 코드 영역의 교체 소스를 작성한다.
평가는 실제 프로젝트에서 추출한 버그와 수정 작업을 이용했다. 각 과제는 원래 버전이 숨겨진 검증에서 실패하고, 알려진 정상 수정은 통과하는지 미리 확인했다.
- 모델이 첫 번째 수정 코드를 제안한다.
- 타입·구문 검사, 숨겨진 회귀 테스트, 변경 범위 검사를 실행한다.
- 실패하면 검증 결과를 제한적으로 전달해 한 번 더 수정하게 한다.
- 검증을 통과했는지에 따라 첫 시도 성공, 자체 복구 성공, 거절, 추론 오류를 구분한다.
따라서 이 결과는 '계획을 전달받은 모델의 제한적 구현 능력'을 측정한다. 리포지토리 탐색, 설계, 다중 도구 호출, 배포까지 자동화하는 독립형 코딩 에이전트 평가와는 다르다.
실제 결과: 가벼운 작업은 통과했지만, 어려운 작업은 모두 실패했다
먼저 작은 코딩 과제 세 개를 모델마다 세 번 수행한 Core 테스트다. 모델을 과제마다 다시 시작하는 isolated 조건을 사용했다.
| 모델 | 첫 시도 통과 | 재수정 포함 통과 | 평균 작업 종료 시간 |
|---|---|---|---|
| Nemotron | 100.0% | 100.0% | 22.63초 |
| Ornith | 66.7% | 66.7% | 15.79초 |
| Devstral | 66.7% | 66.7% | 46.51초 |
| Qwen3.8 | 66.7% | 100.0% | 72.56초 |
작은 과제만 보면 Nemotron의 안정성이 두드러진다. Qwen3.8도 한 번의 수정 기회를 포함하면 모두 통과했지만 평균 종료 시간은 가장 길었다.
문제는 난도를 높였을 때 나타났다. 실제 구현 이력에서 가져온 8개 과제(Small 1개, Medium 4개, Hard 3개)를 모델마다 세 번 실행한 warm 테스트 결과다.
| 모델 | 첫 시도 통과 | 재수정 포함 통과 | 출력 속도 |
|---|---|---|---|
| Nemotron | 37.5% | 37.5% | 21.60토큰/초 |
| Ornith | 37.5% | 37.5% | 26.55토큰/초 |
| Devstral | 37.5% | 37.5% | 10.52토큰/초 |
| Qwen3.8 | 37.5% | 45.8% | 6.21토큰/초 |
여기서 45.8%는 '모든 개발 작업의 절반을 성공한다'는 뜻이 아니다. 이번에 선정한 8개 과제와 세 번의 반복에서 나온 비율이다.
코딩 작업의 난도에 따라 성공률이 달라진다는 점이 핵심이다. Qwen3.8은 Extended의 Medium 과제에서 75%의 통과율을 보였지만 Hard 과제는 통과하지 못했다. 일부 과제가 잘 풀렸다고 더 큰 변경까지 맡길 근거는 없었다.
실제 작업 속도는 어떨까?
코드를 몇 토큰씩 생성하느냐와 개발자가 결과를 받는 시간은 별개의 숫자다. 모델을 처음 올리는 데 걸리는 시간, 코드를 생성하는 시간, 검증과 재수정까지 합쳐서 봐야 한다.
네 개의 실제 작업형 과제를 모델마다 세 번 반복한 isolated 결과는 다음과 같다.
| 모델 | 최종 통과율 | 평균 콜드 스타트 | 평균 E2E |
|---|---|---|---|
| Nemotron | 75% | 4.23초 | 59.77초 |
| Ornith | 50% | 1.73초 | 23.74초 |
| Devstral | 50% | 4.62초 | 69.99초 |
| Qwen3.8 | 75% | 5.08초 | 63.15초 |
Ornith는 가장 빨랐지만 통과율이 50%였다. Nemotron과 Qwen3.8은 75%를 통과했고, 그중 첫 시도 성공률은 Nemotron이 높았다.
이 수치에서 '가장 좋은 모델'을 하나 고르기 어려운 이유다. 모델을 고를 때는 평균 토큰 속도보다 검증 통과 여부, 실패 후 다시 시도하는 비용, 기다릴 수 있는 시간을 함께 봐야 한다.
24GB에서 가장 큰 장애물은 메모리였다
코딩 품질 테스트와 별도로 '개발 앱을 계속 켜 둔 상태에서 큰 모델을 상시 실행할 수 있는가'도 확인했다.
Qwen3.8 27B의 Q3_K_XL 파일은 실제 12.24GiB였다. 4,096토큰 컨텍스트에서 GPU로 넘기는 레이어 수를 조정했다.
| GPU 레이어 | 서버 준비 | 최저 메모리 압박 여유 지표 | 추가 스왑 | 결과 |
|---|---|---|---|---|
| 전체(999) | 실패 | 13% | 3.898GiB | 메모리 안전 중단 |
| 55 | 실패 | 14% | 1.293GiB | 메모리 안전 중단 |
| 40 | 성공 | 18% | 0.194GiB | 22토큰 응답에 94.43초 |
40레이어로 줄이면 서버는 준비됐지만, 22토큰짜리 짧은 요청에도 약 1분 34초가 걸렸다. 이 설정으로는 반복적인 코드 수정이 답답하다. 그래서 별도의 Medium 코딩 품질 테스트는 실행하지 않았다.
'메모리 압박 여유 18%'는 macOS memory_pressure -Q에서 관찰한 시스템 지표다. 물리 RAM 중 18%가 비었다는 의미로 읽으면 안 된다.
더 작은 양자화를 선택하면 해결될까? IQ3_XXS(약 10.9GB 파일)도 시험했다. 4K 컨텍스트, GPU 50레이어 조건에서는 일부 Medium 수정을 통과했지만 컨텍스트 부족과 추론 제한 문제를 겪었다. 6K 컨텍스트와 GPU 48레이어로 늘린 후속 실험은 메모리 압박 여유가 17%까지 내려가고 스왑이 3.591GiB 증가해 안전 중단됐다. 따라서 IQ3 설정이 '상시 사용 가능'하다는 결론은 내리지 않았다.
그럼 로컬 모델은 어떤 작업에 맡겨야 할까?
이번 결과를 실제 개발 흐름에 적용하면 역할을 나누는 편이 낫다.
| 작업 | 현재 실측으로 판단한 활용 |
|---|---|
| 조건문 수정, 작은 함수 교체 | 시도해 볼 만하다. 숨겨진 테스트나 회귀 검증이 필요하다. |
| 범위가 지정된 Medium 구현 | 검증기와 최대 재시도 횟수를 붙인 제한적 후보 |
| 넓은 범위의 리팩터링·복잡한 상태 변경 | 이번 테스트에서는 신뢰 가능한 성공 근거가 없다. |
| 요구사항 분석, 설계, 파일 탐색, 배포 | 이번 벤치마크의 측정 대상이 아니었다. |
| 개발 앱과 동시에 27B 상시 구동 | 24GiB 장비의 현재 워크로드에서는 메모리·속도 부담이 컸다. |
내가 선택한다면, 코드 수정 대상과 기대 결과가 이미 정해진 작은 작업부터 로컬 모델로 보낸다. 로컬 모델은 변경 후보를 만들고, 실제 완료 판정은 테스트가 맡도록 한다.
이렇게 하면 AI가 만들어 낸 결과를 무조건 수용하는 대신, 실패한 변경을 격리하고 상위 코딩 에이전트가 다시 처리하도록 설계할 수 있다. 다만 이번 측정에서 그런 자동 라우팅을 프로덕션에 연결해 검증한 것은 아니다.
직접 테스트한다면 이 네 가지를 확인하자
처음부터 27B 모델을 내려받아 장시간 돌리기보다는 내 노트북과 실제 코드 작업이 맞는지 짧은 실험부터 권한다.
- 동일한 버그 수정 과제와 통과 기준을 정한다. 모델별로 프롬프트를 바꾸지 않는다.
- 모델 시작 시간, 코드 생성 시간, 테스트 통과 여부를 따로 기록한다.
- IDE와 브라우저를 켠 상태에서 메모리 압박과 스왑 증가량을 측정한다.
- 제한 시간을 둔 뒤 실패·시간 초과·메모리 중단을 각각 다른 결과로 분류한다.
모델 실행을 시작하려면 llama.cpp 또는 Unsloth의 Qwen3.8 실행 안내를 참고할 수 있다. Unsloth의 다음 명령은 설치가 된 환경에서의 공식 실행 예시다.
unsloth run --model unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL
주의할 점은 이 예시의 UD-Q4_K_XL이 위 벤치마크에서 사용한 UD-Q4_K_M과 다른 양자화라는 것이다. 같은 모델 계열이라고 같은 메모리 사용량과 성능을 보장하지 않는다.
결국 작은 코딩 작업의 결과를 보려면 '추론 서버가 켜졌다'가 아니라 '코드가 테스트를 통과했는가'까지 확인해야 한다.
유료 AI 코딩 도구를 대체할 수 있을까?
이 질문에 대한 이번 테스트의 답은 '일부 구현 작업은 대체 후보가 될 수 있지만, 개발 도구 전체를 대체했다고 볼 수 없다'이다.
MacBook 24GB에서도 작고 명확한 코드 수정은 수행했다. 그러나 어려운 과제에서는 모든 모델이 실패했고, 큰 모델을 개발 앱과 상시 실행하는 실험에서는 메모리와 속도의 벽이 나타났다. 로컬 모델만으로 요구사항 해석, 설계, 구현, 테스트, 복구까지 끝냈다는 증거도 없다.
유료 코딩 에이전트와의 비용 대비 성능을 판단하려면 같은 작업, 같은 검증기, 실제 사용량과 사람의 개입 시간을 놓고 직접 비교해야 한다. 이번에는 그 비교를 수행하지 않았다. 따라서 확인된 장점은 '로컬에서 특정 코딩 작업을 처리할 수 있다'는 것이고, 입증되지 않은 주장은 '유료 코딩 도구가 필요 없어졌다'는 것이다.
실험 근거와 참고자료
- 실험 기간: 2026년 10월 27–28일.
- 실험 자료: 로컬 코딩 모델 4종의 Core/Extended/Practical 3회 반복 집계, 24GiB 메모리 압박 및 스왑 기록. 별도 Mac 개발 환경에서 측정한 내부 실험이며 원본 실행 파일을 공개 아카이브로 제공하는 단계는 아니다.
- Unsloth Qwen3.8-27B 모델 및 실행 안내
- Qwen3.8-27B GGUF 모델 저장소
- NVIDIA Nemotron 3.5 Bolt E4B 공식 모델 카드
- llama.cpp 공식 저장소
실험 범위는 단일 M4 Pro 24GiB 장비, 제한된 역사적 구현 과제, 고정된 추론 설정이었다. 다른 하드웨어, 더 넓은 컨텍스트, 도구 호출 에이전트, 클라우드 서비스와의 일대일 비교에는 결과를 그대로 적용할 수 없다.

댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.