반응형
프롬프트 원칙 8번: 필요한 맥락(Context)을 먼저 제공하라
LLM은 당신의 업무 배경을 “자동으로” 알고 있지 않습니다. 그래서 맥락이 부족하면 모델은 빈칸을 추측으로 채우기 쉽습니다. 반대로 목표·환경·제약·전제를 먼저 주면, 답변은 훨씬 정확해집니다.
왜 맥락이 중요할까?
같은 질문이라도 “어떤 상황에서 쓰는지”가 다르면 정답이 달라집니다. 예를 들어 “공지문 작성”도 사내 전 직원용인지, 특정 부서용인지에 따라 톤과 구성은 달라집니다. 맥락을 주는 것은 LLM에게 정답의 범위를 알려주는 일입니다.
간단한 적용 템플릿
상황: 지금 어떤 일이 일어났는지 ·
목표: 무엇을 달성하려는지 ·
대상: 누가 읽거나 쓰는지 ·
제약: 금지/톤/기한/형식 ·
자료: 참고할 원문/데이터
연구개발: 실험 환경/제약을 먼저 제공
연구 분석은 데이터만 주면 부족합니다. 환경(버전/데이터셋/목표)이 맥락입니다.
비권장맥락 부족
모델 성능이 떨어졌는데 원인을 분석해줘. [로그] ...
권장(원칙 8 적용)맥락 제공
상황: 어제 배포한 모델 v2에서 정확도가 2%p 하락. 목표: 원인 가설을 3개로 좁히고 재현 실험안을 만들기. 환경: 데이터셋 A(최근 1개월), GPU T4, 배치 64, lr 1e-4. 제약: 추측 금지, 로그에서 근거를 인용. 자료: 아래 로그/지표. [로그] ...
기획: 비즈니스 목표/제약을 먼저 제공
기획은 “기능”보다 왜 하는지가 핵심입니다. 목표가 맥락입니다.
비권장상황/목표 불명확
이 기능 기획안을 개선해줘. [기획안] ...
권장(원칙 8 적용)목표/제약 제공
상황: 신규 고객 온보딩 이탈률이 높음. 목표: 가입 후 7일 내 활성화율 +10%p. 대상: B2B 관리자 사용자. 제약: 개발 기간 4주, 기존 화면 2개만 수정 가능. 자료: 현재 플로우/기획안. [기획안] ...
영업/마케팅: 캠페인 목적/채널/타깃을 먼저 제공
마케팅 문구는 “무엇을”보다 “어디서/누구에게/왜”가 결과를 좌우합니다.
비권장상황 미제공
제품 홍보 문구를 만들어줘.
권장(원칙 8 적용)캠페인 맥락 제공
상황: 전시회 방문자에게 후속 연락 메일 발송. 목표: 데모 미팅 예약(회신률 8% 이상). 타깃: 병원 구매 담당자. 채널: 이메일(모바일에서 읽음), 150자 내외. 톤/제약: 과장 금지, 숫자는 근거 있을 때만. 자료: 제품 포인트/경쟁사 대비 강점. [제품 포인트] ...
생산: 공정/설비/라인 정보를 먼저 제공
생산 이슈는 “어느 공정에서, 어떤 조건에서”가 맥락입니다.
비권장현장 정보 부족
불량이 늘었는데 원인과 조치안을 정리해줘. [데이터] ...
권장(원칙 8 적용)현장 맥락 제공
상황: 3번 라인에서 스크래치 불량이 0.8%→2.4%로 증가. 목표: 오늘 중 불량률을 1% 이하로 낮추는 즉시 조치 도출. 맥락: 설비 A, 소재 LOT 변경(어제), 작업자 교대(주간→야간). 제약: 라인 중단은 30분 이내만 가능. 자료: 불량 유형/시간대/LOT/설비 로그. [데이터] ...
품질보증: 규정/감사 맥락을 먼저 제공
QA는 “어떤 기준에 맞추는가”가 맥락입니다.
비권장기준 불명확
아래 절차를 검토해줘. [절차] ...
권장(원칙 8 적용)기준/목표 제공
상황: 다음 달 외부 감사 예정. 목표: 지적 가능 항목을 사전에 찾아 보완하기. 기준: 사내 SOP + ISO 9001 준수 관점. 제약: 근거 없는 추측 금지, 절차의 누락/모호 표현을 지적. 자료: 아래 절차서(개정 이력 포함). [절차] ...
경영지원: 공지 대상/전달 채널/톤을 먼저 제공
정책 안내는 대상과 채널이 맥락입니다. 같은 내용도 전달 방식이 달라집니다.
비권장대상/채널 미지정
제도 변경 공지문을 작성해줘. [변경 내용] ...
권장(원칙 8 적용)대상/채널/톤 제공
상황: 복리후생 제도 일부 변경. 목표: 직원이 오해 없이 이해하고 문의를 줄이기. 대상: 전 직원(신입 포함). 채널: 사내 게시판 공지(1분 내 읽기). 톤: 담백/명확, 법무 표현 과다 금지. 자료: 변경 전/후 내용, 적용일, 문의처. [변경 내용] ...
반응형
'HRD' 카테고리의 다른 글
| 프롬프트 원칙 10번: 제약조건(Do/Don't)을 명확히 선언하라 (1) | 2026.01.10 |
|---|---|
| 프롬프트 원칙 9번: 복잡한 요청은 하위 작업으로 분해하라 (0) | 2026.01.10 |
| 프롬프트 원칙 7번: 문제 해결 과정을 단계적으로 요청하라 (0) | 2026.01.10 |
| 프롬프트 원칙 6번: 작업의 ‘평가기준(성공 조건)’을 명시하라 (0) | 2026.01.10 |
| 프롬프트 원칙 5번: 예시(Few-shot)를 제공하라 (0) | 2026.01.10 |