Modelfile로 커스터마이징하기
Ollama를 처음 쓸 때는 보통 ollama run 모델이름으로 시작합니다. 이 단계만으로도 충분히 유용하지만, 진짜 재미는 그다음부터입니다. 같은 베이스 모델이라도 어떤 성격으로 말하게 할지, 얼마나 창의적으로 답하게 할지, 출력 길이와 문맥 길이를 어떻게 조절할지를 정해 주면 완전히 다른 조력자로 바뀝니다. 이때 쓰는 설계도가 바로 Modelfile입니다.1
쉽게 말해 Modelfile은 "이 모델을 어떤 방식으로 굴릴지 적어 둔 조리법"입니다. 베이스 모델을 하나 고르고, 그 위에 시스템 지침과 실행 파라미터를 얹어, 내 작업에 맞는 새 모델 이름으로 저장하는 방식입니다.
이 장에서는 Modelfile의 핵심인 FROM, SYSTEM, PARAMETER를 중심으로 살펴보겠습니다. 여기에 더해 TEMPLATE, MESSAGE, REQUIRES가 언제 필요한지도 가볍게 짚겠습니다.

Modelfile은 무엇을 바꾸는가
먼저 중요한 점부터 짚고 가겠습니다. Modelfile은 보통 모델 가중치 자체를 다시 학습시키는 도구가 아닙니다. 즉, 파인튜닝처럼 모델의 뇌를 새로 훈련하는 것이 아니라, 베이스 모델 위에 실행 규칙과 기본 행동을 덧씌우는 방법에 가깝습니다.1
그래서 장점이 분명합니다. 한 번 잘 만들어 두면 매번 긴 시스템 프롬프트를 붙여 넣지 않아도 됩니다. 프로젝트별로 문체, 역할, 출력 형식, 창의성, 응답 길이를 모델 이름 자체에 담아 둘 수 있습니다. 예를 들어 brief-assistant, code-reviewer, json-extractor 같은 식입니다.
이렇게 생각하면 이해가 쉽습니다.
베이스 모델은 원재료
Modelfile은 레시피
ollama create로 만든 새 모델은 완성된 요리
원재료가 같아도 양념이 다르면 맛이 달라지듯, 베이스 모델이 같아도 Modelfile이 다르면 전혀 다른 조력자가 됩니다.
기본 구조: FROM, SYSTEM, PARAMETER
Modelfile은 텍스트 파일입니다. 보통 파일 이름을 그대로 Modelfile이라고 두고 사용합니다. 가장 기본 구조는 아래와 같습니다.1
FROM llama3.2
SYSTEM """
당신은 간결한 한국어 업무 비서입니다.
답변은 먼저 핵심 결론을 말하고, 필요한 경우에만 짧게 설명하세요.
"""
PARAMETER temperature 0.3
PARAMETER num_ctx 4096
PARAMETER num_predict 512이 파일을 저장한 뒤 다음처럼 새 모델을 만들 수 있습니다.
ollama create brief-assistant -f ./Modelfile그리고 바로 실행합니다.
ollama run brief-assistant이미 여기서 세 가지가 결정됩니다.
FROM: 어떤 베이스 모델을 쓸지SYSTEM: 어떤 역할과 말투로 답할지PARAMETER: 응답의 성격과 실행 방식을 어떻게 조절할지
FROM: 어떤 바탕 모델 위에 설 것인가
FROM은 필수입니다. 커스텀 모델은 반드시 어떤 베이스 모델에서 출발해야 하기 때문입니다.1
가장 흔한 형태는 이미 내려받은 Ollama 모델을 지정하는 것입니다.
FROM llama3.2태그를 붙여 특정 변형을 고를 수도 있습니다.
FROM llama3.2:3b
FROM qwen2.5-coder:7b로컬 파일을 직접 가리키는 것도 가능합니다. 공식 문서는 기존 Ollama 모델뿐 아니라 Safetensors 모델 디렉터리나 GGUF 파일을 FROM 대상으로 쓸 수 있다고 안내합니다.1
FROM ./my-model.gguf여기서 기억할 점은 FROM은 성격이 아니라 체급과 기본 소양을 고르는 단계라는 것입니다. 코드를 잘하는 모델, 범용 설명에 강한 모델, 가벼운 모델, 긴 문맥에 강한 모델은 출발점이 다릅니다. 아무리 SYSTEM을 잘 써도 베이스 모델이 작업과 너무 안 맞으면 한계가 있습니다.
SYSTEM: 모델의 역할과 행동 규칙을 정하는 핵심
Modelfile에서 가장 체감이 큰 것은 보통 SYSTEM입니다. 이 한 덩어리 문장으로 모델에게 "너는 누구인지", "어떻게 말해야 하는지", "무엇을 우선해야 하는지"를 알려 줍니다.1
예를 들어 같은 베이스 모델에 아래처럼 서로 다른 SYSTEM을 주면 완전히 다른 느낌이 납니다.
예시 1: 짧고 실무적인 비서
FROM llama3.2
SYSTEM """
당신은 실무형 비서입니다.
항상 한국어로 답하고, 먼저 한 문장 요약을 제시하세요.
장황한 배경 설명은 줄이고, 바로 실행할 수 있는 답을 주세요.
"""
PARAMETER temperature 0.2예시 2: 친절한 튜터
FROM llama3.2
SYSTEM """
당신은 초보자를 가르치는 튜터입니다.
전문 용어를 쓰면 바로 한 줄 설명을 덧붙이세요.
설명은 쉬운 비유와 짧은 예시를 포함해 주세요.
"""
PARAMETER temperature 0.5예시 3: 코드 리뷰어
FROM qwen2.5-coder:7b
SYSTEM """
당신은 시니어 코드 리뷰어입니다.
문제를 발견하면 먼저 버그와 논리 오류를 지적하고,
그다음 성능과 가독성 개선안을 제시하세요.
가능하면 문제 지점을 인용해 설명하세요.
"""
PARAMETER temperature 0.1좋은 SYSTEM은 추상적인 미사여구보다 구체적인 행동 규칙이 많습니다. 보통 아래 요소를 담으면 안정성이 높아집니다.
역할: 누구처럼 행동하는가
대상: 누구를 위한 답변인가
톤: 간결한지, 친절한지, 분석적인지
우선순위: 정확성, 속도, 형식 중 무엇이 먼저인가
출력 규칙: 표, 문단, JSON, 요약 등 어떤 형식이 필요한가
예를 들어 "친절하게 답해"보다 "초보 개발자에게 설명하듯, 전문 용어는 한 줄 정의를 붙이고, 예제부터 보여 줘"가 훨씬 강합니다.
PARAMETER: 답변의 성격과 실행 감각을 조절하는 손잡이
SYSTEM이 모델의 직업과 말투를 정한다면, PARAMETER는 답변의 온도와 주행 감각을 조절합니다. 공식 문서는 Modelfile에서 여러 실행 파라미터를 설정할 수 있다고 안내합니다.1
처음에는 다 외우려 하지 말고, 아래 몇 개만 익혀도 충분합니다.
temperature: 얼마나 창의적으로 답할까
PARAMETER temperature 0.2값이 낮을수록 답이 더 보수적이고 일관적입니다. 코드, 요약, 정보성 응답에 잘 맞습니다. 값이 높을수록 표현이 다채롭고 예측 가능성이 줄어듭니다. 창작, 브레인스토밍, 역할놀이에 더 어울립니다.
대략 이렇게 기억하면 편합니다.
0.0~0.3: 정확성·재현성 우선
0.4~0.7: 균형형
0.8 이상: 창의성 우선
num_ctx: 얼마나 긴 문맥을 잡을까
PARAMETER num_ctx 8192num_ctx는 컨텍스트 윈도 크기입니다. 대화가 길거나 문서가 길수록 넉넉한 값이 유리하지만, 메모리 사용량도 함께 늘어납니다.1
짧은 질의응답이면 2048이나 4096으로도 충분할 수 있고, 긴 문서 요약이나 복잡한 대화라면 더 크게 잡을 수 있습니다. 다만 성능이 갑자기 무거워졌다면 가장 먼저 의심할 값도 이쪽입니다.
num_predict: 답변 길이를 어디까지 허용할까
PARAMETER num_predict 300모델이 한 번 답할 때 생성할 최대 토큰 수입니다. 짧고 단정한 응답을 원하면 제한을 걸어 두는 편이 좋고, 긴 설명이 필요하면 더 크게 잡으면 됩니다.
seed: 같은 입력에 비슷한 결과를 재현하고 싶을 때
PARAMETER seed 42고정된 seed를 주면 같은 프롬프트에 대해 결과를 비교적 재현하기 쉬워집니다. 테스트, 평가, 자동화에서 특히 유용합니다.1
top_k, top_p, min_p: 단어 선택 폭을 조절하는 보조 손잡이
PARAMETER top_k 40
PARAMETER top_p 0.9
PARAMETER min_p 0.05이 값들은 모델이 다음 토큰을 고를 때 얼마나 넓게 후보를 볼지 정합니다. 초반에는 temperature만으로도 충분하지만, 출력이 너무 들쭉날쭉하거나 너무 뻔할 때 미세 조정용으로 쓰면 좋습니다.
repeat_penalty: 같은 말을 자꾸 반복할 때
PARAMETER repeat_penalty 1.1반복 억제 장치입니다. 모델이 같은 표현을 빙글빙글 되풀이한다면 살짝 올려 볼 만합니다.1
stop: 여기서 말을 멈춰라
PARAMETER stop "<|eot_id|>"특정 문자열이 나오면 생성을 멈추게 하는 규칙입니다. 다만 이 값은 모델 템플릿과 밀접하게 연결되는 경우가 많아서, 함부로 넣기보다 기본 모델의 Modelfile을 먼저 확인한 뒤 복사하는 습관이 좋습니다.1
가장 먼저 따라 해볼 실전 예제
이 장의 목표는 "베이스 모델을 다른 조력자로 바꾸는 감각"을 익히는 것입니다. 아래 예제 셋은 용도가 분명해서 연습에 좋습니다.
예제 1: 말수 적은 요약 비서
FROM llama3.2
SYSTEM """
당신은 한국어 요약 비서입니다.
항상 다음 형식으로 답하세요.
한줄 요약:
핵심 포인트:
다음 행동:
쓸데없는 인사말은 생략하고,
내용이 부족하면 추측하지 말고 부족하다고 말하세요.
"""
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
PARAMETER num_predict 400
PARAMETER repeat_penalty 1.1예제 2: 코드가 먼저 나오는 조력자
FROM qwen2.5-coder:7b
SYSTEM """
당신은 실전형 프로그래밍 도우미입니다.
코드 요청을 받으면 먼저 실행 가능한 예제를 제시하고,
그다음 필요한 설명을 짧게 붙이세요.
애매한 요구사항이면 합리적인 가정을 한 줄로 밝히세요.
"""
PARAMETER temperature 0.1
PARAMETER num_ctx 16384
PARAMETER repeat_penalty 1.15
PARAMETER num_predict 1200예제 3: JSON만 출력하는 깐깐한 도우미
FROM llama3.2
SYSTEM """
당신은 데이터 추출 도우미입니다.
항상 유효한 JSON만 출력하세요.
마크다운, 설명, 머리말은 절대 추가하지 마세요.
정보가 부족하면 error 필드를 포함한 JSON으로 응답하세요.
"""
PARAMETER temperature 0.0
PARAMETER seed 42
PARAMETER num_predict 500만들어 보고, 확인하고, 다시 굽기
Modelfile을 작성했다고 바로 반영되지는 않습니다. 반드시 ollama create를 다시 실행해야 새 설정이 모델에 적용됩니다.1
기본 흐름은 이렇습니다.
# 1) Modelfile 작성 또는 수정
vi Modelfile
# 2) 같은 이름으로 다시 빌드
ollama create brief-assistant -f ./Modelfile
# 3) 실행해서 동작 확인
ollama run brief-assistant기본 모델의 설정을 확인하고 싶다면 ollama show --modelfile이 아주 유용합니다.1
ollama show --modelfile llama3.2이 명령으로 출력된 내용을 보면, 해당 모델이 내부적으로 어떤 TEMPLATE와 stop 설정을 쓰는지 확인할 수 있습니다. 직접 처음부터 다 짜기보다, 기본값에서 출발해 조금씩 바꾸는 방식이 훨씬 안전합니다.
TEMPLATE와 MESSAGE는 언제 필요할까
이번 장의 중심은 FROM, SYSTEM, PARAMETER이지만, Modelfile에는 더 많은 지시어가 있습니다. 그중 초반에 알아 둘 만한 것은 TEMPLATE, MESSAGE, REQUIRES입니다.1
TEMPLATE
TEMPLATE는 실제 프롬프트 포맷 전체를 덮어쓰는 기능입니다. 모델마다 대화 형식이 다를 수 있어서 고급 사용자가 직접 템플릿을 바꿀 때 씁니다. 다만 대부분의 경우에는 기본 템플릿이 이미 잘 설정돼 있으므로, 초반에는 건드리지 않는 편이 좋습니다.
MESSAGE
MESSAGE는 예시 대화를 미리 심어 두는 기능입니다. 일종의 few-shot prompting을 모델 정의 안에 넣어 두는 방식이라고 생각하면 됩니다.1
FROM llama3.2
SYSTEM "당신은 SQL 전문가입니다. SQL만 답하세요."
MESSAGE user "최근 7일간 가입한 사용자 조회"
MESSAGE assistant "SELECT * FROM users WHERE created_at >= NOW() - INTERVAL '7 days';"
MESSAGE user "상태별 주문 수 집계"
MESSAGE assistant "SELECT status, COUNT(*) AS count FROM orders GROUP BY status;"
PARAMETER temperature 0.0이렇게 하면 "아, 이 모델은 설명하지 말고 SQL만 내놓으라는 거구나"를 더 안정적으로 따라가는 경우가 많습니다.
REQUIRES
공식 문서에는 REQUIRES도 있습니다. 이 지시어는 이 Modelfile이 요구하는 최소 Ollama 버전을 명시할 때 씁니다.1
REQUIRES 0.14.0팀이나 배포 환경에서 버전 차이로 혼란이 생길 수 있다면 이런 표시가 의외로 유용합니다.
Modelfile의 SYSTEM과 런타임 system 메시지는 어떻게 다를까
앞 장에서 API를 다뤘다면 이런 의문이 들 수 있습니다. "그냥 요청마다 system 메시지를 보내면 되는 것 아닌가?" 맞습니다. 그 방법도 됩니다.
차이는 지속성입니다.
Modelfile의
SYSTEM은 모델 생성 시점에 기본 동작으로 박아 넣는 방식API나 대화 세션에서 보내는 system 메시지는 현재 요청 또는 현재 세션에만 적용되는 방식
즉, 이런 기준으로 고르면 됩니다.
매번 같아야 하는 규칙이면 Modelfile
작업마다 바뀌는 지시라면 런타임 메시지
팀 단위로 같은 행동을 재현해야 하거나, 프로젝트별 AI 비서를 고정해 두고 싶다면 Modelfile 쪽이 훨씬 편합니다.
자주 겪는 실수
처음 Modelfile을 만지면 비슷한 함정에 자주 빠집니다. 미리 알면 시간을 꽤 아낄 수 있습니다.
1. 파일만 고쳐 놓고 왜 안 바뀌지?
Modelfile은 수정 즉시 자동 반영되지 않습니다. 바꾼 뒤에는 꼭 ollama create를 다시 실행해야 합니다.
2. stop을 대충 넣었다가 출력이 이상해짐
stop은 모델 템플릿과 연결이 깊습니다. 다른 모델 예제를 그대로 복사하면 응답이 중간에 끊기거나 형식이 꼬일 수 있습니다. 이럴 때는 ollama show --modelfile로 기본 설정을 먼저 확인하세요.
3. num_ctx를 너무 크게 잡아 성능이 무거워짐
긴 문맥은 좋지만 공짜가 아닙니다. 메모리 사용량이 늘고 속도가 떨어질 수 있습니다. 느려지거나 메모리가 부족하면 num_ctx부터 줄여 보세요.
4. temperature만 0으로 두고 완전 재현성을 기대함
보다 안정적인 재현이 필요하다면 seed도 함께 고정하는 편이 좋습니다.
추천 시작값: 목적별 프리셋
처음부터 완벽한 값을 찾으려 하지 말고, 목적별 시작점을 정해 두면 편합니다.
문서 요약·정보 정리
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
PARAMETER num_predict 400
PARAMETER repeat_penalty 1.1코드 작성·코드 리뷰
PARAMETER temperature 0.1
PARAMETER num_ctx 16384
PARAMETER num_predict 1200
PARAMETER repeat_penalty 1.15창작·아이디어 발상
PARAMETER temperature 0.9
PARAMETER top_p 0.95
PARAMETER num_ctx 8192
PARAMETER repeat_penalty 1.05처음에는 이 정도 프리셋으로 시작하고, 마음에 안 드는 부분 하나만 바꿔 보세요. 한 번에 다 바꾸면 무엇이 영향을 줬는지 알기 어렵습니다.
마무리
Modelfile은 Ollama를 "그냥 로컬에서 모델 돌리는 도구"에서 내 일에 맞는 조력자를 조립하는 도구로 바꿔 줍니다. 핵심은 복잡한 문법을 외우는 게 아닙니다.
먼저 FROM으로 바탕을 고르고, SYSTEM으로 역할과 성격을 정하고, PARAMETER로 답변 감각을 다듬는 것. 이 세 단계만 익혀도 같은 베이스 모델이 전혀 다른 팀원처럼 느껴질 수 있습니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.