프롬프트 원칙 12번: 포함 범위(In-scope)와 제외 범위(Out-of-scope)를 명확히 하라
많은 사람들이 프롬프트를 작성할 때 “정리해줘”, “기획해줘”, “분석해줘”처럼 포괄적인 표현을 사용합니다. 사람끼리는 어느 정도 맥락을 공유하고 있기 때문에 이런 요청도 통할 수 있지만, LLM은 그렇지 않습니다. 모델은 주어진 텍스트만을 기준으로 “어디까지 답해야 하는지”를 추론해야 하며, 이 과정에서 불필요하게 넓은 범위를 다루거나, 반대로 사용자가 기대한 핵심을 놓치는 일이 자주 발생합니다.
이때 가장 효과적인 방법이 바로 포함 범위(In-scope)와 제외 범위(Out-of-scope)를 명시하는 것입니다. 이는 모델에게 “이번 작업에서 다뤄야 할 영역”과 “이번에는 의도적으로 다루지 않을 영역”을 동시에 알려주는 장치입니다. 범위가 명확해질수록 결과물은 짧아지고, 정확해지며, 실무에서 바로 쓸 수 있는 형태로 수렴합니다.
왜 포함/제외 범위 지정이 중요한가?
LLM은 기본적으로 “도움이 되기 위해” 가능한 많은 정보를 제공하려는 성향이 있습니다. 따라서 범위 지시가 없으면, 사용자가 굳이 원하지 않은 배경 설명, 일반론, 장황한 이론, 혹은 다음 단계까지 앞서 나간 제안이 함께 등장할 수 있습니다. 특히 기획서, 정책 문서, 분석 보고서처럼 주제가 넓은 작업일수록 이 문제는 더 자주 발생합니다.
포함/제외 범위를 지정한다는 것은, 단순히 “하지 말 것”을 적는 행위가 아니라 이번 결과물의 목적과 경계를 선언하는 것에 가깝습니다. 이는 사람에게 업무를 지시할 때 “이번 회의에서는 아이디어 발산까지만 하고, 실행 계획은 다음 회의에서 다루자”고 말하는 것과 같은 효과를 냅니다.
범위 지정의 핵심 포인트
- In-scope: 이번 결과물에 반드시 포함되어야 할 항목
- Out-of-scope: 이번에는 의도적으로 다루지 않을 항목
- 경계 조건: 애매할 경우 어떤 기준으로 판단할지
직무별 예시로 보는 원칙 12의 활용
연구개발
연구개발 업무에서는 분석 범위가 쉽게 넓어집니다. 실험 결과를 정리할 때 포함 범위를 지정하지 않으면, 모델은 알고리즘 설명, 관련 연구, 일반적인 이론까지 확장해 버릴 수 있습니다. 이럴 때는 “이번 문서의 목적은 무엇인지”를 기준으로 범위를 자르는 것이 중요합니다.
예를 들어, 이번 결과물이 내부 공유용 실험 리뷰라면 성능 변화 요약, 원인 가설, 다음 실험 정도만 In-scope로 두고, 논문 수준의 배경 설명이나 제품 적용 논의는 Out-of-scope로 명시하는 것이 효과적입니다.
기획
기획 문서에서는 범위 지정이 곧 “책임 범위”를 명확히 하는 역할을 합니다. PRD를 작성할 때 In-scope와 Out-of-scope를 나누면, 이번 릴리스에서 다룰 것과 다루지 않을 것이 자연스럽게 구분됩니다.
예를 들어, 사용자 문제·목표·요구사항은 In-scope로 두되, 상세 UI 시안이나 기술 스택 선정은 Out-of-scope로 제외하면 문서가 불필요하게 비대해지는 것을 막을 수 있습니다.
영업·마케팅
마케팅 콘텐츠는 범위가 없으면 과장과 확장이 발생하기 쉽습니다. 제품 소개 자료를 만들 때 In-scope를 “고객 이점, 사용 사례, 도입 흐름”으로 제한하고, 경쟁사 비교나 내부 로드맵 공개를 Out-of-scope로 명시하면 메시지가 훨씬 안정적이고 안전해집니다.
생산
생산 현장에서는 실행 가능한 결과물이 가장 중요합니다. 따라서 In-scope를 “오늘 실행 가능한 조치와 점검 항목”으로 두고, 설비 교체나 대규모 투자처럼 당장 실행할 수 없는 내용은 Out-of-scope로 제외하는 것이 좋습니다.
품질보증
QA나 감사 대응 문서에서는 범위 지정이 곧 리스크 관리입니다. In-scope를 누락·모호 표현·증빙 연결로 한정하고, 법률 해석이나 실제 운영 추측을 Out-of-scope로 두면 문서가 불필요한 위험 영역으로 확장되는 것을 막을 수 있습니다.
경영지원
사내 공지나 정책 안내에서는 “직원이 지금 알아야 할 것”만 남기는 것이 핵심입니다. 요약, 변경사항, 적용일, To-do는 In-scope로 포함하고, 장문의 배경 설명이나 개인별 예외 케이스는 Out-of-scope로 제외하면 읽히는 공지가 만들어집니다.
정리하며
포함 범위와 제외 범위를 명확히 하는 것은 프롬프트를 길게 쓰는 기술이 아니라, 오히려 불필요한 것을 과감히 덜어내는 기술입니다. 이 원칙을 적용하면 LLM의 답변은 더 짧아지고, 더 정확해지며, “바로 써먹을 수 있는 결과물”에 가까워집니다.
프롬프트를 작성할 때 한 번만 더 생각해 보세요. “이번 작업에서 꼭 다뤄야 할 것은 무엇이고, 굳이 다루지 않아도 되는 것은 무엇인가?” 이 질문에 대한 답이 바로 원칙 12의 핵심입니다.
'HRD' 카테고리의 다른 글
| 직장인 생존 전략! 생성형 AI 업무 활용 꿀팁 BEST 5 (0) | 2026.01.12 |
|---|---|
| 프롬프트 원칙 13번: 원하는 결과의 ‘활용 목적’을 명확히 하라 (0) | 2026.01.12 |
| 프롬프트 원칙 11번: 원하는 깊이(Level of Detail)를 명확히 하라 (0) | 2026.01.12 |
| 프롬프트 원칙 10번: 제약조건(Do/Don't)을 명확히 선언하라 (1) | 2026.01.10 |
| 프롬프트 원칙 9번: 복잡한 요청은 하위 작업으로 분해하라 (0) | 2026.01.10 |