프롬프트 원칙 19번: 우선순위와 트레이드오프를 명시하라
많은 프롬프트에는 서로 충돌할 수 있는 요구사항이 함께 담겨 있습니다. 예를 들어 “빠르면서도 정확한 분석”, “간결하지만 충분히 자세한 설명” 같은 표현은 언뜻 보면 자연스럽지만, 실제로는 동시에 최대화하기 어려운 목표입니다. 사람이 이런 요청을 받으면 자연스럽게 “무엇을 더 중요하게 볼지”를 묻겠지만, LLM은 질문 대신 평균적인 타협안을 내놓는 경우가 많습니다.
프롬프트 원칙 19번은 바로 이 지점을 다룹니다. 즉, 여러 요구사항이 있을 때 무엇을 우선하고, 무엇은 양보 가능한지, 다시 말해 트레이드오프의 기준를 명확히 하라는 원칙입니다. 이 기준이 명시될수록 결과물은 “무난한 답변”이 아니라 상황에 맞는 “의도된 선택”이 됩니다.
왜 우선순위와 트레이드오프가 중요한가?
업무에서의 의사결정은 거의 항상 트레이드오프를 포함합니다. 정확도를 높이면 시간이 늘어나고, 속도를 높이면 세부 검토가 줄어듭니다. 비용을 줄이면 품질이나 범위가 영향을 받습니다.
프롬프트에서 이 우선순위를 밝히지 않으면, LLM은 “모두를 조금씩 만족시키는 방향”을 선택합니다. 그 결과는 대체로 무난하지만, 특정 목적에는 맞지 않는 산출물이 되기 쉽습니다. 반대로 우선순위가 주어지면, 모델은 어떤 부분을 과감히 덜어내고 어떤 부분에 집중해야 할지를 명확히 알게 됩니다.
원칙 19를 적용할 때의 핵심 질문
- 여러 요구사항 중 가장 중요한 것은 무엇인가?
- 덜 중요하거나 상황에 따라 양보 가능한 것은 무엇인가?
- 충돌이 발생할 경우 어떤 기준으로 선택해야 하는가?
직무별 예시로 보는 원칙 19의 활용
연구개발
연구개발에서는 정확성과 속도가 자주 충돌합니다. 빠른 가설 검증이 필요한 상황과, 재현성과 엄밀성이 중요한 상황은 다릅니다.
프롬프트에서 “이번 분석에서는 속도보다 정확성을 우선하고, 불확실한 부분은 명시적으로 남겨달라”거나, 반대로 “이번 단계에서는 빠른 방향성 도출을 우선하고 세부 검증은 생략해달라”고 명시하면 결과물의 성격이 명확해집니다.
기획
기획 업무에서는 범위와 완성도가 자주 충돌합니다. 모든 요구사항을 담으려 하면 일정이 늘어나고, 일정을 맞추려 하면 범위를 줄여야 합니다.
“이번 기획에서는 일정 준수를 최우선으로 하고, 기능 범위는 최소 단위(MVP)로 제한한다”는 우선순위를 주면, 모델은 자연스럽게 핵심 기능 중심의 기획안을 구성합니다.
영업·마케팅
영업과 마케팅에서는 설득력과 정확성이 충돌할 수 있습니다. 강한 메시지는 주목을 끌지만, 과도하면 신뢰를 해칠 수 있습니다.
이때 “이번 자료에서는 설득력보다 신뢰를 우선하고, 과장 가능성이 있는 표현은 과감히 제외한다”는 기준을 주면, 메시지는 훨씬 안정적인 톤으로 정리됩니다.
생산
생산 현장에서는 완벽한 개선안보다 즉시 실행 가능한 조치가 더 중요한 경우가 많습니다.
“장기적인 최적화보다 오늘 바로 실행 가능한 대응을 최우선으로 정리해달라”는 우선순위를 명시하면, 결과물은 현장 중심의 실용적인 문서가 됩니다.
품질보증
QA 업무에서는 운영 효율과 감사 안전성이 충돌하기도 합니다. 효율적인 프로세스가 반드시 감사에 가장 안전한 것은 아닙니다.
“이번 검토에서는 운영 효율보다 외부 감사 대응 안전성을 우선한다”는 기준을 주면, 모델은 보수적인 관점에서 리스크를 정리하게 됩니다.
경영지원
경영지원 영역에서는 직원 편의성과 제도 일관성이 충돌하는 경우가 많습니다.
“이번 정책 안내에서는 예외 처리 최소화와 제도 일관성을 우선한다”는 우선순위를 제시하면, 불필요하게 복잡한 안내를 줄일 수 있습니다.
정리하며
프롬프트 원칙 19번은 LLM에게 “모두를 만족시키라”고 요구하지 말고, 어떤 선택을 하길 원하는지 분명히 알려주라는 원칙입니다. 우선순위와 트레이드오프가 명시된 프롬프트는, 결과물을 훨씬 의도에 가깝게 만듭니다.
다음번 프롬프트에 이런 문장을 추가해 보세요. “여러 기준이 충돌할 경우, ○○을 최우선으로 판단해줘.” 이 한 문장이 LLM의 답변을 ‘무난한 평균’에서 ‘상황에 맞는 선택’으로 바꿔 줄 것입니다.
'HRD' 카테고리의 다른 글
| 프롬프트 원칙 21번: 결과를 ‘다른 관점·역할’로 다시 검토하게 하라 (0) | 2026.01.13 |
|---|---|
| 프롬프트 원칙 20번: 결과를 ‘검증·활용할 다음 행동’까지 설계하라 (0) | 2026.01.13 |
| “AI가 일을 대신하면 조직은 무엇을 관리해야 할까?”… 리더의 역할이 바뀐다 (0) | 2026.01.13 |
| “AI가 판단해도 될까?”… 생성형 AI의 한계는 기술이 아니라 ‘책임 설계’다 (0) | 2026.01.13 |
| 성과가 쌓이는 팀의 공통점, ‘열심히’가 아니라 ‘기대치 관리’다 (1) | 2026.01.13 |