프롬프트 기본기: 명확성·맥락·형식·제약(ROLE–TASK–CONTEXT–FORMAT)

2026-03-22Views 33약 6분

Gemini를 잘 쓰는 사람과 '그냥 대충 질문하는' 사람의 차이는 지식이 아니라 지시서 품질에서 갈립니다. 프롬프트는 기술이기 전에, 동료에게 일을 맡길 때 쓰는 업무 지시서 작성 능력입니다. 지시서가 좋으면 결과가 반복 가능해지고, 반복 가능해지면 생산성이 올라갑니다.

이 챕터의 목표는 한 가지입니다. 오늘 이후로는 "잘 되면 다행"이 아니라, 원하는 결과를 재현할 수 있는 프롬프트 습관을 만드는 것.

프롬프트는 '대화'가 아니라 '브리프(Brief)'다

대화는 분위기와 맥락을 공유하면서 우회적으로도 통합니다. 하지만 AI에게는 대화보다 브리프가 더 안정적입니다. 브리프에는 보통 네 가지가 들어갑니다.

누가(역할), 무엇을(과업), 왜/누구를 위해(맥락), 어떤 형태로(형식). 여기에 "얼마나/어디까지" 같은 제약이 붙으면, 팀원이든 AI든 결과물이 흔들리지 않습니다.¹

즉, 좋은 프롬프트란 질문이 아니라 업무 요청서입니다.

ROLE–TASK–CONTEXT–FORMAT: 가장 단단한 기본 틀

많은 프롬프트 프레임워크가 있지만, 실무에서 가장 자주 쓰고 확장하기 쉬운 뼈대는 다음입니다.

브리프(Brief)는 목적·대상·해야 할 일·형식을 분명히 적어 결과물을 흔들리지 않게 만드는 업무 지시서다.

ROLE(역할): AI가 어떤 관점/전문성으로 답해야 하는가
TASK(과업): 무엇을 만들어야 하는가(동사로 시작)
CONTEXT(맥락): 목적, 독자/사용자, 배경, 입력 자료
FORMAT(형식): 결과물의 구조(표, 항목, 문단 수, JSON 등)

이 구조는 모델이 "추측"하는 영역을 줄이고, 결과를 목표 지향적으로 만듭니다.²

ROLE: '친절한 AI'가 아니라 '직무를 가진 AI'

역할은 톤을 정하는 장식이 아니라, 판단 기준을 정하는 장치입니다. 예를 들어 "마케터"와 "법무 검토자"는 같은 문장을 보고도 우선순위가 달라집니다.³

역할은 구체적일수록 좋습니다.

나쁜 예: "전문가처럼 답해줘"
좋은 예: "B2B SaaS 5년차 그로스 마케터로서, 전환 퍼널 관점에서…"

TASK: '설명해줘'가 아니라 '산출물을 지정'

과업은 동사로 시작하면 흔들림이 줄어듭니다. (요약/비교/분석/작성/추출/검증/정리/변환)

여기서 핵심은 "무엇을"이 아니라 "어떤 산출물을"입니다.

"AI에 대해 알려줘" → 지식 나열로 흐르기 쉽습니다.
"내 발표 자료에 넣을 3문단 개요를 작성해줘" → 결과물이 명확해집니다.

CONTEXT: 모델에게 '판단 재료'를 준다

맥락은 '친절'이 아니라 품질의 재료입니다. 특히 아래 세 가지는 효과가 큽니다.

첫째, 누구를 위한 글인지(대상). 같은 내용도 CEO 보고용, 신입 교육용, 고객 안내용이 다릅니다.

둘째, 목적(의사결정/설득/정리/검증). 목적이 없으면 결과가 예쁘지만 쓸모없어지기 쉽습니다.

셋째, 입력 자료(원문/표/정책/제약 조건). "이 내용만 근거로 써라"라고 범위를 지정하면 헛소리를 줄일 수 있습니다.

FORMAT: 편집 시간을 없애는 가장 쉬운 지름길

형식을 지정하지 않으면, 모델은 매번 다른 모양으로 답합니다. 반대로 형식을 지정하면 "결과를 옮겨 담는 작업"이 사라집니다.¹²

형식 지시는 보통 두 가지 레벨이 있습니다.

구조 레벨: 제목/소제목/순서/섹션 이름
데이터 레벨: 표의 열 이름, JSON 키, 항목 개수, 각 항목의 길이

예: "마크다운 표(열: 기능/장점/주의점)로", "JSON으로 {summary, risks, next_steps} 키를 반드시 포함" 같은 식입니다.⁶

CONSTRAINT(제약): '숫자'로 잠그면 결과가 재현된다

ROLE–TASK–CONTEXT–FORMAT만으로도 좋아지지만, 실무 생산성을 갈라놓는 건 제약을 숫자화하는 습관입니다. 제약은 모델에게 "레일"을 깔아 주는 일이기 때문입니다.⁵

제약은 크게 두 종류입니다.

포함 제약(Requirements): 반드시 들어가야 할 것
배제 제약(Restrictions): 절대 하지 말아야 할 것

그리고 가능하면 정량화합니다.

길이: "150~200자", "문단 3개", "각 항목 20단어 이하"
개수: "정확히 5개", "대안 3개 + 추천 1개"
범위: "2024년 이후 사례만", "첨부한 문서 내용만 근거로"
금지: "이모지 금지", "가격 언급 금지", "추측이면 추측이라고 표시"

제약을 쓸 때는 '부탁'이 아니라 must/금지/정확히(exactly) 같은 강한 표현이 잘 먹힙니다.⁵⁷

제약을 잘 거는 순서: 먼저 '성공 기준', 그다음 '금지 사항'

사람에게 일을 시킬 때도 "뭘 하면 되는지"가 먼저고 "뭘 하면 안 되는지"가 다음입니다. AI도 같습니다.

예를 들어 회의록 정리라면 성공 기준은 "결정사항/담당자/기한이 분리돼 있다"이고, 금지 사항은 "회의에 없던 내용은 만들지 않는다"가 됩니다.

제약은 '많을수록'이 아니라 '중요할수록'

제약을 과도하게 늘리면 모델이 일부를 무시하거나, 전체가 딱딱해질 수 있습니다. 가장 중요한 제약 3~7개 정도를 우선 고정하고, 나머지는 필요할 때 추가하는 편이 안정적입니다.⁵

작업 분해: 한 번에 다 시키지 말고, 단계로 통제한다

실무에서 실패하는 프롬프트의 전형은 "한 번에 모든 걸"입니다. 요약도 하고, 분석도 하고, 전략도 만들고, 이메일까지 완성하라고 하면 작업이 서로 얽혀서(결합도가 올라가서) 작은 실수가 전체를 망칩니다.⁸

이럴 때는 과업을 단계로 분해합니다. 분해의 이점은 두 가지입니다.

첫째, 중간 산출물이 생겨서 검토 지점이 생깁니다. 둘째, 단계마다 형식과 제약을 달리 걸 수 있어 품질이 올라갑니다.⁸¹¹

가장 쉬운 분해 패턴: "1) 먼저 뼈대 2) 그다음 채우기 3) 마지막에 다듬기"

1단계(설계): 목차/구조/핵심 주장
2단계(생성): 본문 작성
3단계(편집): 톤, 분량, 중복, 사실성 점검

이 흐름은 프롬프트 체이닝(순차 프롬프트)으로 만들 수 있고, 단계 사이에 '검증 규칙'을 끼우면 오류 전파를 줄일 수 있습니다.¹⁰

"STOP"은 생각보다 강력한 제약이다

분해를 할 때는 각 단계가 끝나면 멈추게 하는 게 좋습니다. 그래야 다음 단계로 넘어가기 전에 사람이 확인할 수 있습니다.

예: "1단계만 수행하고 STOP. 다음 단계는 내가 '진행'이라고 말하면 시작."

이렇게 하면 모델이 성급하게 결론까지 달려가면서 생기는 누락이 줄어듭니다.¹¹

재현 가능한 프롬프트 습관 6가지

아래 습관은 '센스'가 아니라 작업 표준입니다.

한 문장 목표로 시작한다. "누가/무엇/성공 기준"을 첫 줄에 넣습니다.⁷
ROLE–TASK–CONTEXT–FORMAT 순서로 적는다. 우선순위가 자연스럽게 정리됩니다.²
제약은 숫자로 잠근다. 길이/개수/형식/금지 사항을 정량화합니다.⁵
형식은 스키마처럼 쓴다. 표의 열 이름, 섹션 제목, JSON 키를 고정합니다.⁶
큰 일은 분해한다. 단계별 산출물과 검증 지점을 만듭니다.⁸¹⁰
반복 업무는 템플릿으로 저장한다. 변수(예: {대상}, {목적}, {톤}, {분량})만 바꿔 재사용합니다.

바로 써먹는 프롬프트 템플릿 5개

아래 템플릿은 그대로 복사해서 { }만 채우면 됩니다.

1) 요약(한 장 요약/보고용)

[ROLE] 너는 {업무 분야} 담당자다.
[TASK] 아래 내용을 {요약 종류: 한 장 요약/임원 요약/팀 공유용}으로 요약해라.
[CONTEXT] 대상 독자: {대상}. 목적: {의사결정/공유/보고}.
[FORMAT]
- 제목 1줄
- 핵심 요점 정확히 5개(각 20단어 이하)
- 리스크/불확실성 2개
- 다음 행동 3개(담당 역할 포함)
[CONSTRAINT]
- 전체 250~320자
- 원문에 없는 내용은 '추정'이라고 표시

[INPUT]
{원문 붙여넣기}

2) 이메일/메신저 초안(톤 고정)

[ROLE] 너는 예의 바르고 단호한 프로젝트 매니저다.
[TASK] 아래 상황에 맞는 이메일을 작성해라.
[CONTEXT]
- 수신자: {상대 역할/관계}
- 목적: {요청/리마인드/사과/조율}
- 배경: {상황 2~3줄}
[FORMAT]
- 제목(Subject) 3개 후보
- 본문(인사→맥락→요청→기한/다음 단계→감사)
[CONSTRAINT]
- 본문 120~160자
- '가능하면/아마/대충' 같은 모호한 표현 금지
- 마감 기한은 반드시 날짜 형식(YYYY-MM-DD)으로 1회만 명시

3) 회의록 정리(사실 기반 + 누락 확인)

[ROLE] 너는 회의록 전문 비서다.
[TASK] 아래 회의 텍스트를 실행 가능한 회의록으로 정리해라.
[CONTEXT] 우리 팀은 실행/책임을 명확히 해야 한다.
[FORMAT]
## 요약(3문장)
## 결정사항(항목 3~7개)
## 액션 아이템(표: 담당/할 일/기한/의존성)
## 미확정 질문(정확히 3개)
[CONSTRAINT]
- 텍스트에 없는 정보는 만들지 말 것
- 담당이 불명확하면 '담당 미정'으로 표기
- 액션 아이템 표는 행이 8개를 넘으면 상위 8개만

[INPUT]
{회의 텍스트}

4) 비교/의사결정(표 + 추천 기준 고정)

[ROLE] 너는 객관적인 구매/도입 평가자다.
[TASK] {옵션 A}와 {옵션 B}를 비교하고, 우리 상황에 맞는 추천을 내려라.
[CONTEXT]
- 우리 상황: {예산/일정/인력/기술 수준}
- 우선순위: {예: 비용 40%, 도입 난이도 30%, 확장성 30%}
[FORMAT]
- 비교 표(열: 항목/옵션A/옵션B/비고)
- 결론 3줄(추천 1개 + 이유 2개)
- 리스크 2개와 완화 방안 2개
[CONSTRAINB/비고)
- 결론 3줄(추천 1개 + 이유 2개)
- 리스크 2개와 완화 방안 2개
[CONSTRAIN히 7개
- 결론은 90~120자

5) 큰 작업을 '분해해서' 진행(체이닝용)

[ROLE] 너는 작업을 분해해 진행하는 실행 코치다.
[TASK] 아래 목표를 3~6단계로 분해하고, 1단계만 수행해라.
[CONTEXT] 각 단계는 검증 가능해야 한다.
[FORMAT]
1) 전체 단계 목록(각 단계: 목표/입력/출력/검증 기준)
2) 지금은 1단계 출력만 제공
3) 마지막 줄에: "다음 단계로 진행하려면 '진행'이라고 입력하세요."라고 써라
[CONSTRAINT]
- 각 단계의 출력은 재사용 가능하도록 템플릿 형태로
- 모르는 정보가 있으면 '필요 입력'으로 질문 2~4개만 남기기

[INPUT]
목표: {예: 채용 공고 작성, 리서치 보고서 작성, 발표 자료 구성}
제약: {예: 기간/톤/대상/분량}
자료: {있으면 첨부}