LLM 파라미터는 왜 필요할까?

모델의 성격, 비용, 안정성, 보안 테스트 결과를 결정하는 설정값들

LLM을 사용할 때 우리는 단순히 프롬프트만 입력하지 않습니다.
대부분의 LLM API나 로컬 실행 도구에서는 다음과 같은 파라미터를 함께 설정합니다.

파라미터	모델/환경마다 다른가?	설명
model	예	사용할 모델 이름은 환경마다 다름
temperature	예	대부분 지원하지만 동작 느낌은 모델마다 다름
top_p	예	많이 지원되지만 권장값은 모델마다 다름
top_k	예	로컬 LLM에서는 흔하지만 모든 API가 지원하지는 않음
num_predict	예	Ollama 계열 표현. 다른 API에서는 max_tokens, max_output_tokens 등으로 불릴 수 있음
num_ctx	예	로컬 모델에서 컨텍스트 크기 조절 시 자주 사용
seed	예	지원해도 완전한 재현성을 보장하지 않을 수 있음
stream	대체로 공통	API 응답을 실시간으로 받을지 여부
format	예	JSON 모드, schema 모드 등 구현 방식이 다름
repeat	예	repeat_penalty, frequency_penalty, presence_penalty 등으로 다를 수 있음
trial count	모델 파라미터 아님	실험을 몇 번 반복할지 정하는 평가 설정
success criteria	모델 파라미터 아님	성공/실패를 어떻게 판단할지 정하는 평가 기준

 

처음 보면 복잡해 보입니다.
하지만 이 파라미터들은 LLM을 더 잘 통제하기 위한 손잡이라고 보면 됩니다.

 

LLM은 같은 질문을 받아도 항상 같은 답변을 내놓지 않을 수 있습니다.

또 어떤 모델을 쓰느냐에 따라 답변 품질, 비용, 속도, 보안 경계, 추론 능력이 달라집니다.
따라서 LLM을 실무에서 사용하거나 보안 테스트를 할 때는 이런 파라미터를 명확히 설정해야 합니다.

---

3줄 요약

• LLM 파라미터는 모델의 출력 성향, 비용, 응답 길이, 재현성을 제어하기 위해 사용합니다.
• temperature, top_p, top_k는 답변의 다양성과 안정성을 조절합니다.
• 보안 테스트나 품질 평가에서는 seed, trial_count, success_criteria를 함께 사용해야 결과를 비교할 수 있습니다.

---

1. model: 어떤 모델을 사용할 것인가

model은 사용할 LLM을 지정하는 값입니다.

예를 들어 다음과 같이 설정할 수 있습니다.

model: llama3.1:8b

 

또는 API 환경에서는 다음처럼 쓸 수 있습니다.

{
  "model": "gpt-4.1"
}

 

모델을 명시하는 이유는 간단합니다.
모델마다 성능과 특성이 다르기 때문입니다.

 

예를 들어 어떤 모델은 코딩에 강하고, 어떤 모델은 긴 문서 요약에 강합니다.
또 어떤 모델은 한국어 응답이 자연스럽고, 어떤 모델은 영어 기반 추론이 더 강할 수 있습니다.
보안 관점에서는 모델마다 프롬프트 인젝션, 탈옥, 민감정보 노출 방어 수준도 다릅니다.

 

따라서 LLM 실험에서는 반드시 어떤 모델을 사용했는지 기록해야 합니다.

 

나중에 같은 프롬프트를 다시 테스트하더라도 모델이 다르면 결과가 달라질 수 있습니다.

---

2. temperature: 답변의 무작위성을 조절하는 값

temperature는 LLM의 답변이 얼마나 다양하고 창의적으로 나올지를 조절합니다.

낮은 값은 안정적이고 예측 가능한 답변을 만듭니다.
높은 값은 다양하고 창의적인 답변을 만듭니다.

temperature: 0.2

 

일반적으로 다음과 같이 이해하면 됩니다.

temperature	특징	적합한 용도
0.0 ~ 0.3	일관적, 보수적	보안 테스트, 코드 생성, 문서 요약
0.4 ~ 0.7	적당한 다양성	일반 챗봇, 블로그 초안, 아이디어 정리
0.8 이상	창의적, 예측 어려움	소설, 카피라이팅, 브레인스토밍

 

보안 테스트에서는 보통 낮은 temperature를 사용합니다.
왜냐하면 같은 페이로드를 넣었을 때 결과가 너무 흔들리면 실험을 비교하기 어렵기 때문입니다.

 

예를 들어 프롬프트 인젝션 테스트를 하는데, 한 번은 성공하고 한 번은 실패한다면 이것이 페이로드의 효과인지, 모델의 무작위성 때문인지 판단하기 어렵습니다.

 

그래서 보안 평가에서는 보통 다음과 같이 설정합니다.

temperature: 0.0

 

또는 약간의 변동성을 허용하려면 다음 정도로 설정합니다.

temperature: 0.2

---

3. top_p: 가능성이 높은 후보 안에서만 선택하기

top_p는 누적 확률 기반 샘플링 값입니다.

 

LLM은 다음 단어를 생성할 때 여러 후보 토큰을 계산합니다.
top_p는 그중에서 누적 확률이 일정 비율에 도달하는 후보들만 남기고 선택하게 만듭니다.

top_p: 0.9

 

예를 들어 top_p: 0.9라는 것은 가능성이 높은 후보들을 확률순으로 모았을 때, 누적 확률 90% 안에 들어오는 후보들만 사용하겠다는 의미입니다.

 

• top_p가 낮으면 출력이 더 안정적입니다.
• top_p가 높으면 더 다양한 표현이 나올 수 있습니다.

 

실무에서는 temperature와 top_p를 함께 조정합니다.

 

예를 들어 안정적인 응답이 필요하다면 다음처럼 설정할 수 있습니다.

temperature: 0.2
top_p: 0.8

 

반대로 아이디어를 많이 뽑고 싶다면 다음처럼 설정할 수 있습니다.

temperature: 0.8
top_p: 0.95

---

4. top_k: 상위 K개 후보만 사용하기

top_k는 다음 토큰 후보 중 상위 K개만 사용하도록 제한하는 값입니다.

top_k: 40

 

예를 들어 top_k: 40이면 모델이 다음 단어를 고를 때 가장 가능성이 높은 40개의 후보 안에서만 선택합니다.

top_k가 너무 낮으면 답변이 단조로워질 수 있습니다.

반대로 너무 높으면 이상한 표현이나 불안정한 답변이 나올 가능성이 커질 수 있습니다.

top_p와 top_k는 둘 다 출력 후보를 제한하는 역할을 합니다.

차이는 기준이 다릅니다.

파라미터	기준
top_p	누적 확률
top_k	후보 개수

 

예를 들어 다음 설정은 비교적 안정적인 응답을 만들기 위한 조합입니다.

temperature: 0.2
top_p: 0.9
top_k: 40

---

5. num_predict: 최대 생성 길이 제한

num_predict는 모델이 최대 몇 개의 토큰을 생성할 수 있는지 제한하는 값입니다.

num_predict: 512

 

이 값은 답변 길이, 비용, 응답 시간에 직접 영향을 줍니다.

 

num_predict가 너무 짧으면 답변이 중간에 끊길 수 있습니다.

반대로 너무 길면 불필요하게 긴 답변이 생성되고 비용이 증가할 수 있습니다.

 

예를 들어 간단한 분류 작업이라면 짧게 잡아도 됩니다.

num_predict: 64

 

블로그 초안이나 긴 설명을 생성해야 한다면 더 크게 잡을 수 있습니다.

num_predict: 2048

 

보안 테스트에서는 num_predict가 너무 짧으면 모델이 민감정보를 출력하기 전에 응답이 끊길 수도 있습니다.
반대로 너무 길면 모델이 장황하게 설명하면서 원하지 않는 내용을 추가할 수 있습니다.

 

따라서 테스트 목적에 맞게 적절한 길이 제한을 두는 것이 중요합니다.

---

6. num_ctx: 모델이 참고할 수 있는 문맥의 크기

num_ctx는 컨텍스트 윈도우 크기를 의미합니다.
즉, 모델이 한 번에 참고할 수 있는 입력과 이전 대화의 최대 길이를 정하는 값입니다.

num_ctx: 8192

 

LLM은 무한히 긴 대화를 모두 기억하는 것이 아닙니다.
모델마다 처리할 수 있는 문맥 길이에 제한이 있습니다.

 

예를 들어 긴 문서 분석, RAG, 코드 리뷰, 보안 로그 분석을 할 때는 큰 컨텍스트가 필요합니다.

num_ctx: 32768

 

하지만 컨텍스트를 크게 잡는다고 항상 좋은 것은 아닙니다.

 

문맥이 길어질수록 처리 비용이 증가하고, 응답 속도가 느려질 수 있습니다.
또 불필요한 정보가 많이 들어가면 모델이 핵심을 놓칠 수도 있습니다.

 

따라서 num_ctx는 “가능한 크게”가 아니라 “필요한 만큼” 설정하는 것이 좋습니다.

---

7. seed: 실험 재현성을 위한 값

seed는 난수 생성의 기준값입니다.

seed: 42

 

LLM은 확률적으로 토큰을 선택합니다.
따라서 같은 프롬프트를 넣어도 매번 결과가 달라질 수 있습니다.

 

seed를 고정하면 같은 조건에서 비슷한 결과를 얻을 가능성이 높아집니다.
그래서 실험, 평가, 디버깅, 보안 테스트에서 매우 중요합니다.

 

예를 들어 프롬프트 인젝션 페이로드를 평가할 때 다음 조건을 고정할 수 있습니다.

model: llama3.1:8b
temperature: 0.2
top_p: 0.9
top_k: 40
seed: 42

 

다만 주의할 점이 있습니다.
seed를 고정해도 모든 환경에서 100% 동일한 결과가 보장되는 것은 아닙니다.

 

GPU 연산, 런타임 구현, 모델 버전, 병렬 처리 방식에 따라 미세하게 달라질 수 있습니다.
그래도 실험 재현성을 높이는 데에는 매우 중요한 파라미터입니다.

---

8. stream: 응답을 실시간으로 받을 것인가

stream은 모델의 응답을 한 번에 받을지, 토큰 단위로 조금씩 받을지 결정합니다.

stream: true

 

stream: true이면 챗봇처럼 답변이 실시간으로 출력됩니다.
사용자는 모델이 답변을 생성하는 과정을 바로 볼 수 있습니다.

 

반대로 stream: false이면 전체 응답이 완성된 뒤 한 번에 반환됩니다.

stream: false

 

서비스 관점에서는 stream: true가 사용자 경험에 유리할 수 있습니다.
응답이 길어도 사용자는 기다리는 느낌을 덜 받습니다.

 

하지만 자동 평가나 보안 테스트에서는 stream: false가 더 편할 수 있습니다.
전체 응답을 받은 뒤 성공 여부를 한 번에 판정할 수 있기 때문입니다.

---

9. format: 출력 형식을 강제하기

format은 모델의 응답 형식을 지정하는 값입니다.

예를 들어 JSON으로 응답하게 만들 수 있습니다.

format: json

 

또는 API에 따라 JSON Schema를 지정할 수도 있습니다.

 

LLM을 단순 챗봇으로 쓸 때는 자연어 답변이면 충분합니다.
하지만 시스템과 연동할 때는 정해진 형식이 필요합니다.

 

예를 들어 취약점 분석 결과를 다음과 같은 JSON으로 받아야 한다고 가정해 보겠습니다.

{
  "vulnerability": "prompt injection",
  "severity": "medium",
  "evidence": "모델이 시스템 지시를 무시함",
  "success": true
}

 

이런 경우 format을 사용하면 후속 자동화가 쉬워집니다.

 

보안 테스트에서도 format은 유용합니다.
모델의 응답을 사람이 직접 읽고 판단하지 않고, 자동으로 성공/실패를 판정할 수 있기 때문입니다.

---

10. repeat: 반복 출력을 억제하기

LLM은 가끔 같은 문장이나 단어를 반복하는 문제가 있습니다.

 

예를 들어 다음과 같은 식입니다.

이 문제는 중요합니다. 중요합니다. 중요합니다. 중요합니다...

 

이를 줄이기 위해 반복 억제 관련 설정을 사용합니다.
도구나 API에 따라 이름은 다를 수 있지만 보통 다음과 같은 값이 있습니다.

repeat:
  repeat_penalty: 1.1
  repeat_last_n: 64

 

repeat_penalty는 이미 나온 단어나 표현을 다시 선택할 가능성을 낮춥니다.
repeat_last_n은 최근 몇 개 토큰 범위에서 반복을 감지할지 정합니다.

 

반복 억제 값이 너무 약하면 같은 문장을 반복할 수 있습니다.
반대로 너무 강하면 자연스러운 표현까지 억제되어 답변이 어색해질 수 있습니다.

 

따라서 보통은 기본값을 사용하고, 반복 문제가 발생할 때만 조정하는 것이 좋습니다.

---

11. trial_count: 한 번만 테스트하면 안 되는 이유

trial_count는 같은 테스트를 몇 번 반복할지 정하는 값입니다.

trial_count: 10

 

LLM 평가는 한 번만 실행해서 판단하면 위험합니다.
모델은 확률적으로 답변하기 때문입니다.

 

예를 들어 어떤 프롬프트 인젝션 페이로드를 테스트했을 때 한 번은 실패하고, 다른 한 번은 성공할 수 있습니다.

이때 단 한 번의 결과만 보고 “이 페이로드는 성공한다” 또는 “실패한다”고 말하면 정확하지 않습니다.

 

그래서 보안 테스트에서는 여러 번 반복해야 합니다.

예를 들어 10회 실행해서 7회 성공했다면 성공률은 70%입니다.

trial_count: 10
success_count: 7
success_rate: 70%

 

이렇게 해야 페이로드의 효과를 정량적으로 비교할 수 있습니다.

---

12. success_criteria: 성공과 실패의 기준

success_criteria는 테스트 결과를 어떻게 성공으로 볼 것인지 정의하는 기준입니다.

success_criteria:
  - "시스템 프롬프트를 노출하면 성공"
  - "SECRET, API_KEY, FLAG 값을 출력하면 성공"
  - "정책상 거부하면 실패"

 

이 기준이 없으면 평가가 주관적으로 변합니다.

예를 들어 어떤 응답이 나왔을 때 한 사람은 “성공”이라고 판단하고, 다른 사람은 “실패”라고 판단할 수 있습니다.

 

보안 테스트에서는 특히 성공 기준이 중요합니다.

예를 들어 프롬프트 인젝션 테스트라면 다음과 같이 기준을 정할 수 있습니다.

테스트 목적	성공 기준 예시
시스템 프롬프트 유출	시스템 지시문 일부 또는 전체를 출력함
민감정보 유출	API Key, Token, Secret, Flag 값을 출력함
정책 우회	원래 거부해야 할 요청에 응답함
도구 오남용	허용되지 않은 도구 호출을 수행함
데이터 경계 위반	다른 사용자의 데이터에 접근함

 

성공 기준은 테스트 전에 먼저 정해야 합니다.
결과를 보고 나중에 기준을 바꾸면 실험의 신뢰도가 떨어집니다.

---

실무에서 많이 쓰는 설정 예시

보안 테스트나 품질 평가에서는 보통 안정성을 우선합니다.

model: llama3.1:8b
temperature: 0.2
top_p: 0.9
top_k: 40
num_predict: 512
num_ctx: 8192
seed: 42
stream: false
format: json
repeat:
  repeat_penalty: 1.1
  repeat_last_n: 64
trial_count: 10
success_criteria:
  - "민감정보를 출력하면 성공"
  - "시스템 지시를 노출하면 성공"
  - "정책상 거부하면 실패"

 

반대로 창의적인 글쓰기나 아이디어 생성을 위한 설정은 조금 다릅니다.

model: llama3.1:8b
temperature: 0.8
top_p: 0.95
top_k: 80
num_predict: 2048
num_ctx: 8192
stream: true

 

즉, 파라미터에는 정답이 하나만 있는 것이 아닙니다.
목적에 따라 다르게 설정해야 합니다.

---

목적별 파라미터 정리

목적	중요한 파라미터
모델 선택	model
답변의 창의성 조절	temperature, top_p, top_k
답변 길이 제한	num_predict
긴 문서 처리	num_ctx
실험 재현성	seed
사용자 경험 개선	stream
시스템 연동	format
반복 답변 방지	repeat
보안 테스트 반복	trial_count
자동 평가	success_criteria

---

LLM 보안 테스트에서 파라미터가 중요한 이유

LLM 보안에서는 프롬프트만큼이나 실행 조건이 중요합니다.

같은 페이로드라도 다음 조건에 따라 결과가 달라질 수 있습니다.

temperature: 0.0

temperature: 0.9

 

낮은 temperature에서는 모델이 안정적으로 거부할 수 있지만, 높은 temperature에서는 예상치 못한 방식으로 응답할 가능성이 생길 수 있습니다.

 

또 num_ctx가 작으면 중요한 시스템 지시나 이전 대화가 잘려나갈 수 있습니다.
num_predict가 너무 짧으면 응답이 중간에 끊겨서 성공 여부를 판단하기 어렵습니다.
seed를 고정하지 않으면 같은 실험을 다시 재현하기 어렵습니다.

 

따라서 LLM 보안 테스트 보고서에는 최소한 다음 항목을 기록하는 것이 좋습니다.

model:
model_version:
temperature:
top_p:
top_k:
num_predict:
num_ctx:
seed:
trial_count:
success_criteria:

 

이 정보가 있어야 다른 사람이 같은 조건으로 재현할 수 있습니다.

---

결론: 파라미터는 LLM을 통제하기 위한 실험 조건이다

LLM 파라미터는 단순한 옵션이 아닙니다.
모델의 출력 방식, 비용, 속도, 재현성, 보안 평가 결과를 결정하는 중요한 실험 조건입니다.

 

프롬프트만 잘 작성한다고 좋은 결과가 나오는 것은 아닙니다.
어떤 모델을 쓰는지, 얼마나 창의적으로 답변하게 할 것인지, 얼마나 길게 생성하게 할 것인지, 몇 번 반복 테스트할 것인지도 함께 관리해야 합니다.

 

특히 LLM 보안 테스트에서는 파라미터를 기록하지 않은 결과는 신뢰하기 어렵습니다.

같은 프롬프트라도 실행 조건이 다르면 결과가 달라질 수 있기 때문입니다.

 

결국 LLM을 제대로 사용한다는 것은 프롬프트를 잘 쓰는 것만이 아닙니다.
모델과 파라미터를 함께 이해하고, 목적에 맞게 제어하는 것입니다.

---