[나만의 LLM 환경 구축] 현재 바이브 코딩 세팅 변경점 공유 및 정리

안녕하세요! 
현재 보안 프로젝트를 진행하면서 공개 API를 받아서 사용하는 LLM은 한계가 명확해서 저 스스로 보안 프로젝트에 맞는 모델들로 설정 중입니다. 아래는 현재 진행중인 변경사항 개인 기록용입니다.

 

1. 바이브 코딩 chat 기본 모델 Q5로 업그레이드

기존에는 Q4 기반 모델을 사용했는데, 코드 생성이나 긴 응답 과정에서 출력이 중간에 끊기는 문제가 반복적으로 발생했다. 특히 긴 파일 생성이나 구조 설명을 시킬 때 안정성이 떨어졌다.

FROM ./Qwen3.6-35B-A3B-UD-Q5_K_M.gguf

TEMPLATE """{{- if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}
{{- range .Messages }}
<|im_start|>{{ .Role }}
{{ .Content }}<|im_end|>
{{ end }}
<|im_start|>assistant
"""

PARAMETER temperature 0.6
PARAMETER top_p 0.95
PARAMETER top_k 20
PARAMETER min_p 0

PARAMETER presence_penalty 0.0
PARAMETER repeat_penalty 1.0

PARAMETER num_ctx 262144
PARAMETER num_predict 32768

PARAMETER stop "<|im_start|>"
PARAMETER stop "<|im_end|>"
PARAMETER stop "<|endoftext|>"

SYSTEM """You are the user's main local engineering assistant running on Qwen3.6-35B-A3B.

Core responsibilities:
- Read code, architecture, and repository structure accurately before answering.
- Build a correct mental model of project layout, module boundaries, data flow, and execution path.
- Explain large codebases clearly in Korean or English.
- Produce implementation plans, debugging guidance, refactors, and code with minimal ambiguity.
- When the user describes a project at a high level, infer the likely architecture, missing pieces, and operational flow.

Working rules:
- Prioritize correct structure understanding over shallow speed.
- If the codebase is large, summarize it in layers: entrypoints, services, storage, integrations, deployment.
- When writing code, prefer safe, maintainable, production-practical solutions.
- When uncertain, state the assumption briefly and continue.
- Do not output hidden reasoning or tags like <think>.
- Default to complete answers instead of clipped short replies when needed.

Style:
- Concise, precise, technical.
- No filler.
- Match the user's language.
"""

변경 이후 확실히 체감되는 부분은 있다. 응답이 더 안정적으로 이어지고, 중간에 잘리는 현상이 거의 사라졌다. 대신 속도는 더 느려졌다.

 

VS코드: yaml 파일 설정

name: Local Config
version: 1.0.0
schema: v1

models:
  - name: Goni Qwen
    provider: ollama
    model: goni_qwen
    roles:
      - chat
      - edit
      - apply

  - name: Qwen Coder
    provider: ollama
    model: qwen-coder:latest
    roles:
      - autocomplete

  - name: Hauhau Qwen
    provider: ollama
    model: hauhau-qwen:latest
    roles:
      - chat
      - edit
      - apply

contextProviders:
  - provider: code
  - provider: terminal

embeddingsProvider:
  provider: ollama
  model: nomic-embed-text:latest

하지만 명확한거는 보안 관련해서 코드분석이나, 결과 분석을 했을 때 무검열 버전 LLM을 사용하기 때문에 거부하는 로직이 없어졌다.

2. Ollama 모델 로딩 방식 변경 (핵심)

초기에는 GGUF 파일을 직접 다운로드해서 Modelfile로 연결하는 구조를 사용했다.

FROM ./Qwen3.6-27B.Q4_K_M.gguf

 

이 방식의 문제는 생각보다 많았다.

• huggingface-cli → hf 전환 이후 다운로드 문제 발생
• 캐시 꼬임
• 파일 경로 문제
• 재빌드 반복

그래서 방식을 바꿨다.

FROM hf.co/unsloth/Qwen3.6-27B-GGUF:UD-Q4_K_XL

 

이렇게 Ollama가 HuggingFace 모델을 직접 관리하도록 변경. 이 방식으로 바꾸고 나서 체감된 변화는 명확했다.

모델 로딩 자체가 훨씬 안정적으로 동작하기 시작했고, 이전처럼 캐시가 꼬이거나 재다운로드를 반복하는 문제가 사라졌다. 또한 Modelfile을 다시 빌드할 때 걸리는 시간도 줄어들어서, 전체적인 개발 흐름이 끊기지 않게 되었다. 결국 GGUF 파일을 직접 관리하면서 발생하던 경로 문제, 캐시 충돌, 다운로드 이슈들을 생각하면, HuggingFace 경로를 그대로 사용하는 방식이 훨씬 실용적이다.

 

로컬 파일 직접 관리 → 제어는 되는데 계속 깨짐
hf.co 연결 → 제어는 줄지만 안정성 훨씬 높음

---

3. Modelfile 구조 재정리 (바이브 코딩 기준)

이번 작업에서 가장 크게 건드린 부분은 템플릿과 출력 구조다. Qwen 계열 모델은 채팅 포맷을 제대로 맞춰주지 않으면 성능이 눈에 띄게 떨어진다. 단순히 프롬프트만 잘 쓴다고 해결되는 문제가 아니라, 내부적으로 role을 어떻게 구분하느냐가 응답 품질에 직접적으로 영향을 준다.

 

그래서 TEMPLATE를 명시적으로 정의했다.

TEMPLATE """{{- if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}
{{- range .Messages }}
<|im_start|>{{ .Role }}
{{ .Content }}<|im_end|>
{{ end }}
<|im_start|>assistant
"""

 

이걸 넣고 나면 모델이 system / user / assistant 역할을 명확하게 구분해서 처리한다. 반대로 이걸 생략하면 역할 경계가 흐려지면서 reasoning 흐름이 깨지고, 결과적으로 답변 품질 자체가 흔들린다. 출력 길이도 크게 늘렸다.

PARAMETER num_predict 32768

이 설정은 단순히 “길게 말하게 한다”는 의미가 아니라, 실제로는 코드 생성 안정성을 위한 조치다. 이전에는 긴 코드나 구조 설명을 시키면 중간에 끊기는 경우가 많았는데, 출력 길이를 늘리면서 이런 문제가 상당 부분 사라졌다. 대신 당연하게도 속도는 더 느려진다. 길게 뽑을수록 latency가 증가하는 건 피할 수 없다.

컨텍스트 길이도 최대치로 열어놨다.

PARAMETER num_ctx 262144

 

이론적으로는 매우 큰 컨텍스트를 사용할 수 있는 설정이지만, 실제 Mac 환경에서는 이 값을 전부 활용하지는 못한다. 메모리와 KV cache 한계 때문에 체감 가능한 컨텍스트는 훨씬 작다. 그럼에도 불구하고 일부라도 더 읽히는 게 낫기 때문에, 짧게 제한하는 것보다는 최대치로 열어두는 방향을 선택했다.

---

4. Continue (VSCode) 모델 구조 정리

기존에는 여러 모델을 섞어서 사용하고 있었다. goni_qwen, hauhau-qwen, qwen-coder 같은 식으로 역할을 나눴는데, 이 구조가 생각보다 문제를 많이 만들었다. 모델마다 답변 스타일과 판단 기준이 다르기 때문에, 하나의 작업 흐름 안에서 컨텍스트가 끊기는 현상이 발생했다. 특히 코드 분석이나 리팩토링처럼 맥락 유지가 중요한 작업에서는 결과의 일관성이 크게 떨어졌다. 그래서 구조를 단순화했다.

 

메인 분석과 채팅은 Qwen3.6 하나로 통일하고, 자동완성만 qwen-coder를 유지하는 방식이다. 결과적으로 “생각하는 모델 하나 + 보조 모델 하나” 구조로 정리된 셈이다. 이 방식이 훨씬 안정적으로 동작한다.

---

5. 성능 체감

가장 크게 느껴지는 차이는 속도다. 이건 체감이 아니라 거의 구조적인 차이다.

API 기반 모델은 응답이 빠르고, 첫 토큰 생성 속도도 안정적이며, 긴 출력에서도 latency가 크게 튀지 않는다. 반면 로컬 Qwen 모델은 첫 토큰 생성부터 느리고, 출력이 길어질수록 지연이 눈에 띄게 증가한다. 특히 컨텍스트를 크게 잡을수록 성능 저하는 더 심해진다.

이 부분은 단순 설정으로 해결되는 문제가 아니라 구조적인 한계에 가깝다.

 

결국 지금 기준에서는 이렇게 나뉜다.

속도는 API 모델이 확실히 우위에 있고, 대신 코드 이해력이나 자유도, 제약 없는 분석은 로컬 모델이 더 낫다.

---

6. 보안 관점에서의 변화

이건 실제로 작업하면서 가장 크게 체감된 부분이다.

API 모델은 특정 키워드나 상황에서 응답을 제한하거나 아예 거부하는 경우가 있다. 특히 취약점 분석이나 공격 흐름 설명 같은 영역에서는 중간에 막히는 경우가 자주 발생한다.

반면 로컬 모델은 이런 제한이 없다. 필터링이 없기 때문에 코드 분석이든, 취약점이든, 내부 로직이든 그대로 끝까지 밀고 나간다.

보안 프로젝트에서는 이 차이가 꽤 크다. 단순한 편의성 문제가 아니라, 작업 가능 범위 자체가 달라진다.

---

7. 현재 상태 정리 및 방향

현재 기준으로 보면, 로컬 Qwen3.6 기반으로 엔지니어링용 모델 구성은 어느 정도 완료된 상태다. Ollama와 Continue 연동도 안정적으로 동작하고, 대형 코드베이스를 읽고 분석하는 수준까지는 올라왔다. 출력이 중간에 끊기던 문제도 상당 부분 해결된 상태다.

다만 아직 남아있는 문제는 명확하다. 속도 최적화, 컨텍스트를 실제로 효율적으로 활용하는 방법, 그리고 모델 구조를 더 단순하게 가져갈 수 있는지에 대한 고민이 필요하다.

 

결론적으로 지금 구조는 빠른 모델이 아니라, 제대로 읽고 이해하는 모델에 가깝다. 속도를 일부 포기하는 대신 전체 코드 이해, 구조 분석, 제약 없는 응답을 얻는 방향이다.