2장까지 왔다면 이제 화면의 위치는 대략 잡혔습니다. 이제부터는 실제로 AI가 일하는 조건을 바꿉니다.
이 장에서 다룰 것은 프롬프트를 더 길게 쓰는 방법이 아닙니다. 오히려 반대입니다. 매번 프롬프트에 반복해서 넣던 지시를 따로 빼고, 필요한 설정을 고정하는 방법을 익힙니다.
예를 들어 회의록을 정리할 때마다 이런 말을 붙인다고 해 보겠습니다.
“추정하지 마세요.”
“결론부터 정리하세요.”
“담당자와 기한이 없으면 확인 필요라고 쓰세요.”
마케팅 글에서는 다른 반복이 생깁니다.
“과장하지 마세요.”
“기능보다 고객의 문제를 먼저 쓰세요.”
“30~40대 실무자가 읽는 글입니다.”
한 번의 요청이라면 괜찮습니다. 하지만 같은 일을 매주 반복한다면 계속 다시 쓰는 것 자체가 비효율입니다.
Google AI Studio의 Run settings는 이런 반복을 줄이기 위한 조절판입니다.
그림 3-1에서 중요한 것은 설정의 개수가 아닙니다. 하나의 패널 안에서 모델, System instructions, Temperature, Thinking level, Structured outputs, Grounding 같은 항목을 따로 다룰 수 있다는 점입니다.
이 장에서는 이 설정을 네 가지 질문으로 나눠 봅니다.
누가 일하는가.
어떤 방식으로 답하는가.
결과는 얼마나 일정하거나 다양해야 하는가.
그리고 설정이 꼬였을 때 어디로 돌아갈 것인가.
Structured outputs와 Grounding도 보이지만 여기서는 역할만 확인합니다. 실제 조작은 뒤에서 다룹니다.
3.1 먼저 기준 모델을 맞춘다
이 장의 실습은 Gemini 3.1 Pro Preview로 진행합니다.
모델을 먼저 맞추는 이유는 단순합니다. 모든 모델의 Run settings가 같지 않기 때문입니다.
특히 이 장에서 비교할 Temperature는 모델마다 있고 없을 수 있습니다. 2026년 9월 5일 확인한 화면에서는 무료 모델 가운데 Gemini 3 Flash Preview와 Gemini 3.1 Pro Preview에서 Temperature를 사용할 수 있었습니다. 반면 Gemini 3.8 Flash, 3.7 Flash, 3.5 Flash와 Flash-Lite 계열에는 Temperature 항목이 없습니다. Advanced settings를 펼쳐도 나타나지 않습니다.
그래서 다른 모델을 선택했는데 Temperature가 보이지 않는다면 메뉴를 놓친 것이 아닐 수 있습니다. 모델이 제공하는 설정 자체가 다른 것입니다.
이 장에서는 공식 11, 12, 13을 실제로 비교해야 하므로 Gemini 3.1 Pro Preview를 기준 모델로 둡니다.
작업을 시작할 때는 다음 순서로 확인합니다.
- Playground에서 Run settings를 엽니다.
- 맨 위의 모델 선택 버튼을 봅니다.
- 모델 이름이 Gemini 3.1 Pro Preview인지 확인합니다.
- 다르면 모델 선택 패널에서 Gemini 3.1 Pro Preview를 선택합니다.
이제 같은 조건에서 설정을 비교할 준비가 됐습니다.
3.2 반복되는 역할은 System instructions로 옮긴다
가장 먼저 바꿀 것은 역할입니다.
System instructions는 프롬프트와 분리되어 있습니다. 프롬프트가 “이번에 무엇을 할 것인가”를 적는 곳이라면, System instructions는 “어떤 사람처럼, 어떤 규칙으로 일할 것인가”를 정하는 곳입니다.
예를 들어 출판 기획 업무를 할 때 매번 이런 식으로 시작한다고 해 보겠습니다.
당신은 IT 실용서를 검토하는 출판 기획자입니다. 독자는 개발자가 아닌 직장인입니다. 결론부터 말하고 이유를 뒤에 설명합니다. 근거 없는 수치와 존재하지 않는 기능을 만들지 않습니다.
오늘은 목차를 검토합니다.
내일은 샘플 원고를 봅니다.
다음 주에는 제목 후보를 평가합니다.
작업은 달라져도 역할과 기준은 같습니다.
이런 문장은 매번 프롬프트에 붙일 필요가 없습니다.
공식 08 — AI의 역할은 프롬프트가 아니라 System instructions에 쓴다.
System instructions에 역할을 옮기면 프롬프트에는 그날의 일만 남길 수 있습니다.
아래 목차에서 비개발자 독자가 이탈할 가능성이 높은 장을 찾아 주세요. 이유와 수정 방향을 함께 적어 주세요.
다음 작업에서는 이렇게 바뀝니다.
아래 샘플 원고에서 전문 용어 설명이 부족한 부분을 찾아 주세요.
프롬프트는 짧아졌지만 판단 기준은 유지됩니다.
이 차이는 반복할수록 커집니다. 매번 같은 문장을 다시 붙이지 않아도 되고, 업무 규칙을 빠뜨릴 가능성도 줄어듭니다.
3.3 System instructions는 직무기술서처럼 쓴다
System instructions를 처음 쓰면 길고 거창하게 만들기 쉽습니다.
“최고의 전문가처럼 행동하세요.”
“통찰력 있고 창의적으로 답하세요.”
“완벽하고 정확한 결과를 만들어 주세요.”
이런 문장이 전혀 쓸모없는 것은 아닙니다. 다만 업무 기준으로는 모호합니다.
사람에게 일을 맡길 때를 생각하면 더 쉽습니다. 새 직원에게 “최고의 직원처럼 일하세요”라고만 하지 않습니다. 어떤 역할인지, 누가 결과물을 보는지, 어떤 방식으로 표현해야 하는지, 무엇을 하면 안 되는지를 알려 줍니다.
System instructions도 같은 방식으로 쓰면 됩니다.
공식 09 — System instructions는 직무기술서처럼 쓴다. 역할·대상·말투·금지사항.
처음에는 네 항목이면 충분합니다.
역할 — 어떤 직무의 사람처럼 일하는가.
대상 — 결과물을 누가 읽거나 사용하는가.
말투 — 어떤 방식으로 표현하는가.
금지사항 — 무엇을 하지 않아야 하는가.
출판 기획자
역할: IT 실용서를 검토하는 출판 기획자 대상: 개발자가 아닌 일반 직장인 독자 말투: 결론부터 쓰고 이유를 뒤에 설명한다. 금지사항: 근거 없는 시장 수치와 존재하지 않는 기능을 만들지 않는다.
프롬프트는 작업만 적습니다.
아래 목차에서 기능 설명에 치우친 장을 찾아 주세요.
마케터
역할: B2B 업무용 서비스를 담당하는 콘텐츠 마케터 대상: 업무 자동화에 관심 있는 30~40대 실무자 말투: 기능보다 사용자가 겪는 문제와 업무 변화를 먼저 설명한다. 금지사항: 최고, 완벽, 혁신적 같은 과장 표현을 사용하지 않는다.
프롬프트는 이렇게 짧아집니다.
회의 녹음을 자동으로 정리하는 기능의 소개 메일 초안을 작성해 주세요.
회의록 정리 담당
역할: 사내 회의록 정리 담당자 대상: 회의 참석자와 후속 업무 담당자 말투: 짧고 사실적으로 정리한다. 금지사항: 발언에 없는 담당자, 기한, 숫자를 추정하지 않는다. 확인할 수 없는 항목은 '확인 필요'라고 표시한다.
프롬프트에는 결과 구조와 원문만 넣습니다.
아래 회의 전사를 핵심 논의 / 결정 사항 / 액션 아이템 / 미결 사항 순서로 정리해 주세요.
System instructions에는 Title을 붙일 수 있습니다. 이 기능을 이용하면 직무별 설정을 이름으로 나눌 수 있습니다.
예를 들어 출판 기획자, B2B 마케터, 회의록 정리처럼 이름을 붙입니다.
입력한 내용이 저장되면 Saved가 표시됩니다. 저장한 지시문은 콤보박스에서 다시 불러올 수 있습니다.
사용 흐름은 다음과 같습니다.
- System instructions를 엽니다.
- 역할·대상·말투·금지사항을 입력합니다.
- Title에 알아보기 쉬운 이름을 붙입니다.
Saved상태를 확인합니다.- 다음 작업에서 저장된 지시문을 콤보박스에서 다시 불러옵니다.
이렇게 하면 오전에는 회의록 정리, 오후에는 B2B 마케터, 다음 날에는 출판 기획자를 불러와 사용할 수 있습니다.
다만 한계가 있습니다. 이 저장은 브라우저의 local storage에 남습니다. 같은 브라우저에서는 다시 불러오기 편하지만 브라우저를 바꾸면 저장한 지시문이 그대로 따라오지 않습니다.
중요한 System instructions라면 별도의 문서에도 원본을 보관해 두는 편이 안전합니다.
3.4 말투는 형용사보다 예문으로 고정한다
직무기술서에서 가장 애매한 부분은 말투입니다.
“전문적으로.”
“친근하게.”
“깔끔하게.”
“세련되게.”
사람끼리도 해석이 다를 수 있는 표현입니다.
친근하다는 것이 쉬운 단어를 쓰라는 뜻인지, 말하듯 쓰라는 뜻인지, 문장을 짧게 쓰라는 뜻인지 알기 어렵습니다.
말투를 중요하게 관리해야 한다면 형용사를 더 붙이기보다 원하는 문장의 예를 넣는 편이 낫습니다.
공식 10 — 말투를 지시할 때는 형용사 대신 예문을 넣는다.
앞에서 만든 마케터용 System instructions에 이런 두 문장을 추가할 수 있습니다.
문장 스타일 예시: "문제는 회의를 녹음하는 데 있지 않습니다. 회의가 끝난 뒤 다시 듣고 정리해야 한다는 데 있습니다." "기능부터 보지 마세요. 이 기능을 쓰면 어떤 반복 작업이 사라지는지를 먼저 봅니다."
이 예문에는 몇 가지 기준이 함께 들어 있습니다.
문장이 짧습니다.
문제를 먼저 제시합니다.
기능 설명은 뒤에 둡니다.
과장 표현을 쓰지 않습니다.
“전문적이면서 친근하게”보다 훨씬 구체적입니다.
출판 기획자라면 다음과 같은 예문이 더 잘 맞을 수 있습니다.
문장 스타일 예시: "소재가 부족한 것은 아닙니다. 독자가 이 장에서 무엇을 얻는지가 보이지 않는 것이 문제입니다." "기능 설명은 충분합니다. 이제 실제 업무에서 왜 필요한지를 앞으로 옮겨야 합니다."
회의록 정리에서는 문체 예시보다 결과 표현의 예가 더 유용할 수도 있습니다.
표현 예시: 담당자: 확인 필요 기한: 확인 필요 결정 사항: 광고비는 이번 달 예산 안에서 집행
예문은 길 필요가 없습니다. 문장 길이와 설명 순서, 결과를 표현하는 방식을 보여주는 정도면 됩니다.
3.5 사실 정리는 Temperature를 낮춰 비교한다
역할과 말투를 고정했다면 이제 답의 변동 폭을 조절해 봅니다.
이 장의 기준 모델인 Gemini 3.1 Pro Preview에서 Temperature 기본값은 1입니다.
Temperature를 정확성 점수라고 생각하면 곤란합니다. 업무에서는 답이 얼마나 일정하게 모이거나 여러 방향으로 벌어지는지를 조절하는 값으로 이해하는 편이 쉽습니다.
회의록, 계약서 조항 정리, 주간 보고서 요약처럼 원문에 충실해야 하는 일은 표현의 다양성보다 일관성이 더 중요합니다.
이런 작업에서는 Temperature를 낮춘 결과를 비교해 볼 수 있습니다.
공식 11 — 사실을 정리하는 작업은 Temperature를 낮춘다.
앞에서 만든 회의록 담당자의 System instructions를 그대로 둡니다.
역할: 사내 회의록 정리 담당자 대상: 회의 참석자와 후속 업무 담당자 말투: 짧고 사실적으로 정리한다. 금지사항: 발언에 없는 담당자, 기한, 숫자를 추정하지 않는다. 확인할 수 없는 항목은 '확인 필요'라고 표시한다.
프롬프트도 고정합니다.
아래 메모를 결정 사항과 액션 아이템으로 나눠 정리해 주세요. - 랜딩 페이지 B안의 클릭률이 더 높았음 - 최종안은 금요일까지 확정 - 카피 초안은 목요일까지 - 디자인 수정은 수요일까지 - 광고비 추가 예산은 없음
먼저 Temperature 1에서 실행합니다. 결과를 남겨 둡니다.
그다음 다른 것은 바꾸지 않습니다. Temperature만 0으로 낮춥니다.
같은 System instructions와 같은 프롬프트로 다시 실행합니다.
두 결과에서 볼 것은 “어느 쪽이 더 똑똑한가”가 아닙니다.
원문에 없는 표현을 추가했는지 봅니다.
결정 사항과 액션 아이템의 구분이 얼마나 일정한지 봅니다.
같은 정보가 비슷한 방식으로 정리되는지도 봅니다.
Temperature를 0으로 낮췄다고 사실 오류가 자동으로 사라지는 것은 아닙니다. 없는 담당자나 숫자를 만들지 말라는 조건은 System instructions에 따로 적어야 합니다.
Temperature는 사실 확인 기능이 아닙니다. 사실 정리처럼 결과의 변동을 줄이고 싶은 업무에서 비교해 보는 설정입니다.
3.6 아이디어를 벌릴 때는 Temperature를 높인다
이번에는 업무의 목적을 바꿉니다.
마케팅 담당자가 새로운 웨비나 제목을 찾고 있다고 해 보겠습니다.
회의 녹음을 요약하고 액션 아이템을 정리하는 기능을 소개하는 웨비나 제목을 10개 제안해 주세요. 대상은 30~40대 팀장입니다.
이 작업에서는 회의록처럼 결과가 일정할 필요가 없습니다.
오히려 열 개의 제목이 모두 비슷하면 곤란합니다.
‘회의록 자동화의 시작’
‘회의록 자동화 실무’
‘팀장을 위한 회의록 자동화’
표현만 조금씩 달라진 후보보다 서로 다른 관점이 필요합니다.
시간 절약으로 접근할 수 있습니다.
회의 후속 업무를 줄이는 방향도 있습니다.
팀장의 관리 부담을 소재로 잡을 수도 있습니다.
회의에서 정한 일이 실행되지 않는 문제를 제목으로 끌어올 수도 있습니다.
공식 12 — 아이디어를 벌리는 작업은 Temperature를 높인다.
여기서 ‘높인다’는 무조건 큰 숫자가 좋다는 뜻이 아닙니다.
사실 정리에서는 결과가 일정하게 모이는 것이 중요했습니다.
아이디어 탐색에서는 여러 방향으로 벌어지는 것이 중요합니다.
따라서 Temperature를 정할 때는 먼저 묻습니다.
지금 필요한 것은 일관성인가, 다양성인가.
회의록이라면 일관성에 가깝습니다.
캠페인 콘셉트나 제목 탐색이라면 다양성에 가깝습니다.
같은 AI가 텍스트를 만들어도 업무 목표가 다르면 설정도 달라져야 합니다.
3.7 같은 질문을 두 번 돌려야 설정 효과가 보인다
Temperature를 배울 때 가장 흔한 실수는 설정을 바꾸면서 질문도 함께 바꾸는 것입니다.
Temperature를 낮춥니다.
프롬프트도 조금 고칩니다.
System instructions도 한 문장 추가합니다.
모델까지 바꿉니다.
그 뒤 결과가 좋아져도 무엇 때문인지 알 수 없습니다.
설정의 효과를 보려면 한 번에 하나만 바꿔야 합니다.
공식 13 — 같은 질문을 Temperature만 바꿔 두 번 돌려 비교한다.
순서는 단순합니다.
- Gemini 3.1 Pro Preview를 그대로 둡니다.
- System instructions를 그대로 둡니다.
- 프롬프트도 그대로 둡니다.
- Temperature 1에서 실행합니다.
- Temperature만 0으로 바꿉니다.
- 같은 프롬프트를 다시 실행합니다.
- 두 결과를 비교합니다.
회의록이라면 비교 기준을 미리 정할 수 있습니다.
원문에 없는 내용이 들어갔는가.
결정 사항과 액션 아이템을 같은 기준으로 나눴는가.
담당자와 기한을 임의로 채우지는 않았는가.
표현 방식이 얼마나 달라졌는가.
아이디어 작업에서는 다른 기준을 씁니다.
후보끼리 얼마나 겹치는가.
서로 다른 관점이 나왔는가.
대상 독자와 동떨어진 방향으로 벗어나지는 않았는가.
System instructions의 금지사항을 지켰는가.
이렇게 비교하면 Temperature의 정답 숫자를 외울 필요가 없습니다. 자신의 업무에서 어느 결과가 더 쓸 만한지 직접 판단하면 됩니다.
3.8 단순 반복과 복잡한 판단은 Thinking level을 다르게 본다
Temperature 다음에는 Thinking level을 봅니다.
현재 기준 화면의 기본값은 High입니다.
이름만 보면 High가 늘 좋은 선택처럼 보일 수 있습니다. 하지만 모든 업무에 같은 수준의 판단이 필요한 것은 아닙니다.
다음 두 요청을 비교해 보겠습니다.
아래 고객 문의 20건을 배송 / 결제 / 환불 / 기타 네 가지로 분류해 주세요.
해야 할 일이 명확합니다. 정해진 기준에 따라 분류하면 됩니다.
반면 다음 요청은 다릅니다.
아래 고객 문의 200건에서 반복되는 불만 원인을 묶고, 각 문제가 어느 업무 단계에서 생기는지 가설을 세운 뒤, 먼저 고쳐야 할 세 가지를 이유와 함께 제안해 주세요.
이번에는 여러 문의를 묶고, 원인을 추론하고, 우선순위를 정해야 합니다.
첫 번째와 두 번째 업무가 같은 수준의 판단을 요구하지 않는다는 것은 쉽게 알 수 있습니다.
공식 14 — 단순 반복 작업은 Thinking level을 낮춰 시간을 아낀다.
선택한 모델에서 Thinking level을 조절할 수 있다면 단순 분류나 짧은 형식 변환처럼 판단이 적게 필요한 작업에서 낮춘 상태의 결과를 비교해 볼 수 있습니다.
결과 품질에 큰 차이가 없다면 단순 작업에 항상 높은 수준을 유지할 필요는 적습니다.
반대로 여러 조건을 비교하고 이유를 설명해야 하는 업무에서는 높은 Thinking level의 결과가 어떻게 달라지는지 확인할 수 있습니다.
Thinking level 역시 “높을수록 좋다”가 아니라 업무 난도에 맞추는 설정으로 보는 편이 좋습니다.
3.9 결과의 모양과 근거도 따로 설정한다
Run settings에는 지금까지 다룬 항목 말고도 중요한 설정이 있습니다.
먼저 Structured outputs입니다.
Structured outputs는 결과의 구조를 고정하는 기능입니다.
예를 들어 고객 문의 100건을 정리한다고 해 보겠습니다. 결과를 매번 다음 네 항목으로 받아야 할 수 있습니다.
문의 유형
긴급도
담당 부서
한 줄 요약
채팅창에서 “표로 정리해 주세요”라고 요청하는 방법도 있습니다. 하지만 반복 업무에서는 결과가 따라야 할 구조 자체를 지정하는 방법이 있습니다.
이 장에서는 역할만 확인합니다. Structured outputs를 실제로 어떻게 설정하는지는 여기서 다루지 않습니다.
그림 3-8과 그림 3-9에서는 상태의 차이만 봅니다. Structured outputs가 꺼져 있을 때와 켜져 있을 때 Edit 버튼의 상태가 달라진다는 점까지만 확인합니다.
다음은 Grounding입니다.
촬영한 기준 화면에서는 Grounding with Google Search가 기본으로 켜져 있습니다.
Grounding은 AI가 답을 만들 때 외부 근거를 연결하는 쪽의 설정입니다. 이 역시 여기서는 직접 조작하지 않습니다.
지금은 Run settings 안에서 기능 역할을 나눠 보는 것이 목적입니다.
System instructions는 누가 일하는가를 정합니다.
Temperature와 Thinking level은 어떻게 답할 것인가를 조절합니다.
Structured outputs는 어떤 모양으로 내놓을 것인가를 다룹니다.
Grounding은 무엇을 근거로 답할 것인가와 관계가 있습니다.
이 네 층을 구분하면 Run settings가 기능 목록이 아니라 업무 조건표처럼 보이기 시작합니다.
3.10 설정이 꼬였으면 기준점으로 돌아간다
설정을 배우다 보면 여러 값을 바꾸게 됩니다.
System instructions를 수정합니다.
Temperature를 0으로 바꿉니다.
Thinking level도 조절합니다.
Structured outputs의 상태도 확인합니다.
그러다 어느 순간 결과가 이상해질 수 있습니다.
이때 프롬프트부터 다시 쓰기보다 현재 설정부터 확인해야 합니다. 앞에서 바꾼 조건이 지금 업무와 맞지 않는 상태로 남아 있을 수 있기 때문입니다.
Run settings 상단에는 되돌리기 아이콘이 있습니다. 이 아이콘이 Reset default settings 역할을 합니다. 화면에 긴 텍스트 버튼이 따로 있다고 생각하면 안 됩니다.
공식 15 — 설정이 꼬이면 처음부터 다시 쓰지 말고 기본값으로 되돌린다.
필요할 때는 다음 순서로 정리합니다.
- 보관해야 할 현재 결과를 먼저 남깁니다.
- Run settings 상단의 되돌리기 아이콘을 사용합니다.
- 기본 상태로 돌아온 뒤 필요한 설정만 다시 적용합니다.
- 한 번에 하나씩 바꾸면서 결과를 확인합니다.
예를 들어 오전에는 마케팅 아이디어를 넓게 뽑았습니다. 오후에는 회의록을 정리해야 합니다. 업무 성격이 완전히 달라졌는데 앞에서 사용한 설정을 그대로 들고 갈 이유는 없습니다.
반대로 회의록처럼 결과가 흔들리지 않도록 맞춘 상태에서 캠페인 아이디어를 여러 방향으로 요청하면 결과가 지나치게 비슷하게 느껴질 수 있습니다.
AI가 갑자기 성능이 나빠진 것이 아닐 수 있습니다. 다른 일을 시키면서 이전 작업의 조건을 그대로 입혀 둔 것일 수 있습니다.
설정이 꼬였을 때 기본값으로 돌아가는 것은 실패가 아닙니다. 비교를 다시 시작할 수 있는 기준점을 만드는 일입니다.
정리
Run settings의 핵심은 AI를 복잡하게 조정하는 데 있지 않습니다. 매번 반복하던 업무 조건을 분리하고, 필요한 설정을 한 번 정해 다시 사용하는 데 있습니다.
System instructions에는 역할·대상·말투·금지사항을 둡니다. Temperature는 일관성이 필요한 일과 다양성이 필요한 일을 구분해 비교합니다. Thinking level은 업무의 난도에 맞춰 사용합니다.
Structured outputs와 Grounding은 각각 결과 구조와 근거를 담당합니다. 이 장에서는 두 기능의 역할만 확인했습니다.
이 장의 공식: 08, 09, 10, 11, 12, 13, 14, 15