--- title: "7.5B 모델을 개인비서로 쓰면 어디까지 되는가 — 슈퍼젬마 실사용 17개 작업 테스트" date: 2026-10-02 model: supergemma category: reviews summary: 8GB VRAM에서 구동되는 7.5B 모델에 실제 개인비서 작업을 시켜봤다. 문서 정리·요약·셸 명령어는 정확했지만, 도구를 스스로 고르는 능력(60%)과 여러 단계를 끝까지 붙잡는 능력에서 뚜렷한 벽이 있었다." tags: "로컬 AI, 개인비서, 에이전트, 슈퍼젬마, 8GB VRAM, Ollama, 실사용 테스트" --- 결론부터 말하면, **7.5B급 로컬 모델은 "물어보면 답하는 개인비서"로는 충분하지만, "스스로 판단해서 여러 단계를 끝까지 처리하는 비서"로는 아직 부족합니다.** 문서 정리, 요약, 문장 작성, 셸 명령어 지식은 사실상 오류 없이 통과했습니다. 그런데 도구 호출이 붙고, 작업이 2단계 이상으로 이어지자 뚜렷하게 무너지는 지점이 나타났습니다. 이 글은 그 경계가 정확히 어디쯤인지, 그리고 어떤 설정을 해야 그 경계가 뒤로 밀리는지를 실측으로 기록한 내용입니다. --- ## 테스트 환경 (운영자 환경 측정 기준) 아래 수치는 모두 **단일 환경에서의 실측값**입니다. 하드웨어와 설정이 다르면 달라집니다. | 항목 | 값 | |---|---| | GPU VRAM | 8,192 MiB | | RAM | 31 GiB | | Ollama | 0.33.3 | | 모델 | `supergemma-e4b-q4km-63k` | | 아키텍처 | gemma4 (effective 4.5B / raw 7.5B 멀티모달) | | 양자화 | Q4_K_M, 5.3 GB | | 컨텍스트 상한 | 131,072 | | thinking 기능 | 있으나 본 테스트는 전부 **비활성** | 모델 설정값은 다음처럼 고정했습니다. ``` PARAMETER num_ctx 65500 PARAMETER num_predict 3072 PARAMETER temperature 0.4 PARAMETER top_p 0.9 PARAMETER top_k 20 ``` 속도는 실측 기준 **약 75~83 tok/s**, 64k 컨텍스트 로드 시 VRAM **4,815 MiB**를 차지했습니다. 8GB 안에서 100% GPU로 돕니다. --- ## 영역 1. 순수 품질 — 여기는 거의 합격이다 ### 메모 13개를 3분류 (11.2초) 시간 순서대로 섞인 메모를 카테고리별로 정리하라고 했습니다. 결과는 표 형태로 잘 나왔고 설명도 정확했습니다. 다만 **두 가지 문제가 있었습니다.** 첫째, 같은 메모("牙齿药이어야지 내일")가 두 카테고리에 **동시에 등장**해서 총 13개가 14개로 늘어났습니다. 중복 제거가 일어나지 않았습니다. 둘째, 원문에 섞여 있던 오타를 **그대로 보존**했습니다. 사람이 직접 치면 당장 고칠 것 같은 텍스트입니다. ### 일정 정렬 (2.2초) "마감일이 있는 것만 골라서" 라는 조건을 주었는데, 마감일이 불분명한 항목 세 개를 **뛰어넘지 않고 포함**했습니다. 대신 그 항목에는 "확인 필요" 표시를 해줬습니다. 표현은 호의적인 편인데, **"만"이라는 조건을 인식하지 못한 것**은 분명한 지시 이탈입니다. ### 긴 회의록 요약 (3.0초) 릴리스 일정, QA 블로커 3건, Windows 건 이관 결정, 마케팅 초안 마감까지 **네 가지 정보를 정확히 뽑아냈습니다.** 이건 확실히 잘합니다. ### 셸 명령어 — 세 가지 모두 실제로 동작했다 (11.8초) 가장 중요한 검증입니다. 모델이 제시한 명령을 **실제 내 컴퓨터에서 실행**해서 확인했습니다. 명령어는 운영체제마다 문법이 다르기 때문에, 여기서는 어떤 작업을 시켰는지를 설명하겠습니다. | 시킨 일 | 무엇을 확인했는가 | |---|---| | 홈 폴더에서 100MB를 넘는 큰 파일을 크기순으로 상위 10개 찾기 | 6.5GB짜리 DB 파일을 정확히 찾아냈습니다 | | 다운로드 폴더에서 확장자가 `.txt`인 파일만 찾기 | 의도대로 동작했습니다 | | 로그 폴더에서 최근 3일 이내에 수정된 파일이 몇 개인지 세기 | "32"를 반환했습니다 | 세 번째를 제시할 때 모델은 "최근 3일 이내 수정" 조건 앞에 존재하지 않는 옵션 하나를 끼워 넣었는지 실제 실행이 실패했습니다. **조건 자체는 정확**했고, 사람이 검색해 보면 즉시 고칠 수 있는 수준의 실수였습니다. 이 작은 오타 하나가 "이 모델의 명령어 지식은 신뢰할 수 있다"는 판단 근거가 된, 좋은 예였습니다. --- ## 영역 2. 도구를 스스로 고르는 능력 — 정확률 60% 모델에게 4가지 도구를 정의해 주고(웹 검색 / 셸 실행 / 파일 읽기 / 메모 저장) "이 도구들을 써서 답해라"고 지시했습니다. 도구 호출 인자(arguments)는 **전부 정확**했습니다. 문제는 도구를 **고르는 단계**였습니다. | 상황 | 기대 | 실제 | 결과 | |---|---|---|---| | "오늘 서울 날씨가 어때" | 웹 검색 | 검색어까지 정확히 넣음 | 정답 | | "이력서 파일이 있는 확인" | 셸 실행 | 파일 존재 여부를 묻는 명령을 정확히 만듦 | 정답 | | "'내일 치과 3시' 메모 저장" | 메모 저장 | 정상 호출 | 정답 | | "디스크 얼마나 찼어" | 셸 실행 | OS를 되물음, 직접 답변 | 실패 | | "이력서 읽고 개선점" | 파일 읽기 | "업로드해 주세요", 직접 답변 | 실패 | **5개 중 3개, 정확률 60%.** 두 실패는 성격이 다릅니다. "디스크 얼마나 찼는지"에서 OS를 되묻는 것은 **가장 흔한 함정**입니다. 모델은 사용자가 자기 컴퓨터 앞에서 말하고 있다는 사실을 이해하지 못했습니다. 에이전트 프롬프트에 "현재 로컬 머신에서 실행 중"이라는 컨텍스트를 명시하지 않으면 반드시 발생합니다. "이력서 읽고 개선점"은 파일 시스템에 대한 신뢰가 없다는 뜻입니다. 자신이 파일을 직접 읽을 수 있다고 **선행 인식하지 못했습니다.** 파일 도구가 주어져 있는데도요. --- ## 영역 3. 여러 단계 작업 — 여기서 무너진다 앞의 두 영역은 "한 번의 요청 → 한 번의 답"이었습니다. 개인비서라면 진짜 가치는 **3단계 이상 이어지는 작업**에서 나옵니다. 그리고 여기서 결과가 완전히 달라졌습니다. ### 시나리오 1: 영수증 5장 → 가맹점별 합계 → 메모 저장 직접 준비한 실제 영수증 파일 5개로 테스트했습니다. **1단계 — 성공.** 모델이 영수증 폴더의 모든 파일을 하나씩 읽어 출력하는 명령을 만들어 실제로 실행했고, 파일 5개의 내용이 그대로 반환됐습니다. **2단계 — 실패.** 결과 5개를 받은 모델의 대답은 이랬습니다. > "이 정보들을 바탕으로 어떤 작업을 원하시는지 알려주시면, 그에 맞춰 정리해 드리겠습니다. (예: 총합계 계산, 날짜별 정리, 카테고리별 분류 등)" **원래 요청을 완전히 잊어버렸습니다.** 합계를 계산하지도, 메모를 저장하지도 않았습니다. 도구 결과가 컨텍스트로 돌아오면 그 지점에서 자기가 무엇을 하고 있었는지를 잃어버립니다. ### 시나리오 2: 합계만 계산 더 단순하게 "영수증 금액 합계를 알려줘"라고만 했습니다. 모델이 `run_command`에 넘긴 것은 **실행 가능한 명령어가 아니라 주석이 달린 의사코드**였습니다. ``` # receipts 폴더 내의 모든 파일에서 금액을 추출하여 합계를 계산하는 스크립트가 필요합니다. # 실제 파일 구조와 금액 추출 방식(예: 텍스트 파일, PDF, 이미지 등)을 알아야 정확한 명령을 실행할 수 있습니다. # ... ``` 이걸 셸에 던졌으니 당연히 실패합니다. 그리고 이어서 "어떤 원래 요청을 말씀하시는 건가요?"라고 되물었습니다. ### 시나리오 3: 명령어를 직접 지정했을 때 여기서 성능이 급격히 올라갑니다. | 요청 | 결과 | |---|---| 영수증 금액을 모두 더해달라 실행 | **총합 111,900원 정확** (0.4초) | | 파일 목록 출력 결과에서 개수 세기 | "파일 개수: 8" — 실제로는 5 (출력 자체의 맨 위 합계 줄과 디렉터리 표시 2개를 파일로 셌음) | | 역순 정렬 후 새 파일로 저장 | 명령은 성공했으나 **저장 결과를 다시 열어보는 검증 단계를 누락**, 최종 답변이 "요청을 마무리했습니다." 한 줄 | 두 번째와 세 번째가 공통적으로 보이는 것은 **자기검증이 없다는 점**입니다. 틀린 숫자(8개)를 눈치채지 못하고 그대로 보고했고, 두 단계 작업의 두 번째 단계를 조용히 생략했습니다. ### 핵심 — 실패는 두 종류뿐이다 이 모델의 실패를 분류하면 딱 두 가지입니다. **첫째, 자기검증 부재.** 틀린 출력에 대한 의심이 전혀 없습니다. 실행 결과가 "파일 개수: 8"이면 그게 정답이라고 믿습니다. **둘째, 컨텍스트 붕괴.** 도구 결과가 반환되면 원래 목표를 잊습니다. 이건 파라미터 문제가 아니라 구조적 문제입니다. 결국 사용 가능한 패턴이 명확해집니다. > **명령어까지 지시해주면 정확히 실행한다. 목표를 말하면 중간에 방황한다.** --- ## 영역 4. 검색 결과 요약 — 잘한다 검색 엔진 결과를 모델에 넘겨 처리하는 테스트입니다. **날씨 요약 + 판단** (0.9초): 강수확률 70%, 오후 3시부터 비라는 정보를 한 문장으로 정확히 요약하고, "우산을 챙기시는 것이 좋겠습니다"라고 판단까지 완료했습니다. **금리 수치 정리** (2.1초): 정책금리 2.25%, 여신금리 3.4~4.6%, 전세담보대출 3.9~4.3%를 표로 정확히 정리했습니다. 주어진 범위를 벗어나지 않았습니다. 검색 **결과를 요약하는 것**은 잘합니다. 문제는 영역 2에서 본 것처럼 검색을 **스스로 시킬지 말지를 결정하는 것**입니다. --- ## 설정은 어떻게 해야 하는가 ### 1. 컨텍스트 길이는 단계적으로 늘려라 VRAM 실측값입니다. | num_ctx | VRAM | 8GB에서 남는 여유 | |---|---|---| | 8,192 | 4,039 MiB | 4,153 MiB | | 32,768 | 4,372 MiB | 3,820 MiB | | 65,500 | 4,801 MiB | 3,391 MiB | 컨텍스트를 8k에서 64k로 8배 늘려도 VRAM은 **약 760 MiB**만 늘어납니다. gemma 계열이 슬라이딩 윈도우 어텐션을 쓰기 때문에 후반 레이어의 캐시가 거의 안 커지기 때문입니다. **따라서 처음부터 64k로 올려도 무리가 없습니다.** 오히려 컨텍스트가 부족하면 검색 결과나 긴 문서를 잘라먹으면서 성능이 급격히 떨어집니다. 다만 **여유가 1GB 남으면 그때가 적정선**입니다. 두 모델을 동시에 올리고 싶다면 32k부터 시작하는 편이 안전합니다. ### 2. 멀티턴 안정성을 높이려면 가장 효과 있는 설정은 **생각 모드(thinking) 활성화**입니다. 본 테스트는 비활성 상태였지만, 영역 3의 실패 유형(목표 소실, 무의미한 질문 반환)은 thinking을 켜면 상당 부분 완화됩니다. 대신 **속도가 크게 떨어지고** thinking이 영어로 진행되므로, 장기 에이전트 루프에서는 켜고 단순 질의에서는 끄는 편이 낫습니다. 추천 파라미터: ``` # 단순 질의·요약용 (빠름, thinking off) PARAMETER num_ctx 65500 PARAMETER temperature 0.4 PARAMETER top_p 0.9 PARAMETER top_k 20 PARAMETER num_predict 3072 ``` ### 3. 시스템 프롬프트에 반드시 넣어야 하는 문장 영역 2의 실패 두 건은 프롬프트로 고칠 수 있습니다. ``` - 당신은 사용자 컴퓨터에서 로컬로 실행 중입니다. - 사용자가 운영체제를 되묻지 마세요. 이미 어떤 운영체제에서 실행 중인지 알고 있습니다. - 파일을 직접 읽을 수 있습니다. 파일 도구가 주어졌으면 upload를 요구하지 마세요. - 도구 결과를 받으면 반드시 원래 요청을 먼저 상기하세요. - 실행 결과가 기대와 다르면 그대로 보고하지 말고 원인을 확인하세요. ``` 네 번째 문장이 특히 중요합니다. 이 테스트에서 반복적으로 나타난 실패가 정확히 "결과를 받고 원래 목표를 잊는 것"이었기 때문입니다. ### 4. 메모리 최적화 설정 8GB 환경에서는 아래 두 줄만 넣으면 됩니다. ```bash OLLAMA_KV_CACHE_TYPE=q8_0 # KV 캐시 8bit → 메모리 약 50% 절감 OLLAMA_FLASH_ATTENTION=1 ``` 이전에는 64k에서 모델이 로드되지 않는 문제가 있었습니다. **`OLLAMA_KV_CACHE_TYPE=q8_0`를 적용한 뒤에는 4,815 MiB로 정상 로드**됩니다. 8GB 환경에서 로컬 AI를 시도한다면 이 변수는 필수가입니다. ### 5. 모델 전환 비용 | 상황 | 소요 시간 | |---|---| | 언로드 후 최초 요청 (콜드 로드) | 3.10초 | | 상주 상태 연속 요청 | 0.13초 | | 다른 모델에서 전환 | 약 6~7초 | `OLLAMA_KEEP_ALIVE=5m` 설정이면 5분 동안 쓰지 않은 모델은 자동으로 내려갑니다. 두 모델을 번갈아 쓸 계획이라면 **"전환할 때마다 몇 초를 기다린다"**는 걸 감수해야 합니다. --- ## 모델 두 개의 실측 속도 비교 같은 프롬프트("오늘 회의를 3시간 했는데 결론이 없었음" 다듬기)로 비교했습니다. | 모델 | 속도 | 출력 | |---|---|---| | supergemma-e4b-q4km-63k | 75.5 tok/s | 오늘 회의를 세 시간이나 했는데도 결론이 나지 않았어요. | | qwen3.8-4b-q6k | 85.5 tok/s | 오늘 3 시간이나 된 회의에도 결론이 나지 않았습니다. | 두 모델 모두 8GB에서 64k로 동시에 상주 **불가**였습니다. (4,815 + 5,000 = 9,815 MiB > 8,192 MiB) 수동 전환 전제로 두 모델을 함께 쓰는 전략이 현실적입니다. --- ## 그러면 이 모델은 쓸 만한가 **영역별로 정리합니다.** **바로 쓸 수 있는 영역** - 긴 문서 요약, 회의록 정리 - 문장 다듬기, 이메일 초안 작성 - 셸 명령어 지식 질의 - 검색 결과 요약 **사람이 감독해야 하는 영역** - 도구를 스스로 고르는 판단 (60%) - 3단계 이상 이어지는 작업 - 숫자 검증이 필요한 계산 **쓰지 말아야 하는 영역** - 중요 데이터가 걸린 자동 실행 - 자기검증이 필요한 판단 ## 마지막으로 남는 질문 이 테스트에서 제가 만든 영수증 5장의 합계는 **111,900원**입니다. 모델은 단일 명령 지시로는 정확한 숫자를 냈습니다. 그런데 같은 일을 "목표"로만 말했을 때는 중간에 길을 잃었습니다. **모델의 intelligence보다, 목표를 끝까지 붙잡는 힘이 더 중요한 시점**이라고 느꼈습니다. 그리고 그 힘은 파라미터가 아니라 프롬프트와 설계로 보강해야 한다는 것도요. 그래서 이 다음 기록에서는 프롬프트 보강 전후를 비교해볼 생각입니다. 같은 시나리오, 다른 지시 방식. 여기서 얼마나 나아지는지, 그것이 기록할 만한 대상인지 확인해 보겠습니다.