프롬프트에 `과장하지 마세요`라고 쓰면 정말 과장하지 않을까

프롬프트를 작성할 때 과장하지 마세요, 추측하지 마세요 같은 조건을 자주 붙입니다. 저도 이런 문장을 넣으면 모델이 말할 수 있는 범위를 어느 정도 제한할 수 있다고 생각했습니다. 하지만 모델이 우리 제품의 실제 기능을 모르는 상태라면, 무엇이 과장인지 스스로 구분할 수 있을까요?

이 질문을 사내 AI Fluency 세션의 실습으로 가져가봤습니다. HR 자연어 검색 기능의 소개 문구를 만들면서 행동 조건만 전달했을 때와 제품 스펙을 함께 전달했을 때 결과가 어떻게 달라지는지 살펴봤습니다.

자연스러웠지만 우리 제품 이야기는 아니었다#

먼저 제품 정보나 제한 조건 없이 다음과 같이 글쓰기 작업만 요청했습니다.

AI 자연어 검색 기능을 소개하는 문구를 작성해줘.

모델은 이 요청에 맞춰 여러 문구를 만들었습니다. 문장만 보면 자연스러웠지만, 우리가 소개하려던 기능과는 관계가 없는 내용이었습니다.

결과를 보고 나니 자연스러운 문장과 우리 제품에 맞는 문장은 별개라는 점이 보였습니다. 최초 요청에는 대상 제품과 검색 가능한 필드, 복합 조건 지원 여부가 없었습니다. 모델 입장에서는 특정 제품을 설명하기보다 ‘자연어 검색’이라는 이름에 어울리는 범용적인 예시를 만드는 편이 자연스러웠습니다.

과장하지 마세요보다 먼저 필요했던 컨텍스트#

처음에는 “과장하지 말고 실제로 가능한 것만 써주세요”라는 지시를 더하면 될 것 같았지만 모델은 우리 제품에서 실제로 가능한 것이 무엇인지 알 수 없습니다. 추측하지 말라고 요청하려면 먼저 추측하지 않고 사용할 수 있는 사실을 알려줘야 했습니다.

소개 문구를 작성해줘는 AI에 맡길 작업입니다. 반면 검색 가능한 필드와 제외할 데이터는 모델이 만들어도 되는 내용이 아니라 제품을 아는 사람이 제공해야 할 사실입니다. 세션에서는 이 둘을 구분하기 위해 프롬프트를 작업, 제품 정보, 출력 조건으로 나눠봤습니다.

<instructions>
HR 자연어 검색 기능을 처음 쓰는 인사팀 실무자에게
소개하는 문구를 작성해주세요.
</instructions>
 
<context>
- "2024년 입사한 개발팀 직원" 같은 자연어 검색 지원
- 부서명, 직급, 입사일 기준 필터링 지원
- 복합 조건 조합 지원
- 급여, 인사고과 등 민감 데이터는 검색 제외
</context>
 
<output_format>
200자 이내의 사용 전·후 비교 형식으로 작성해주세요.
전문 용어는 쓰지 마세요.
</output_format>
 
위 스펙에 명시된 기능만 언급하세요.
그 밖의 기능은 추측하지 마세요.

XML 태그를 사용한 이유는 개발자와 기획자가 프롬프트를 함께 볼 때 작업 지시와 제품 정보가 어디에 들어 있는지 찾기 쉬웠고, 빠진 조건도 전보다 눈에 잘 들어오기 때문입니다.

허용 기능과 제외 조건을 같이 적어봤다#

제품 스펙을 넣을 때는 제공하는 기능만 나열하지 않고, 급여나 인사고과처럼 검색에서 제외되는 범위도 같은 수준의 제품 정보로 다뤘습니다.

제외 조건을 소개 문구에 그대로 보여줄 필요는 없지만, 생성 모델에는 알려줘야 했습니다. 모델이 급여 검색 가능 여부를 알지 못하는 상태에서 “민감한 기능은 말하지 마세요”라고만 하면 무엇을 빼야 하는지 판단할 근거가 없기 때문입니다.

이렇게 정리하고 보니 허용 기능과 제외 조건은 단순한 참고 정보가 아니라 모델이 말할 수 있는 제품의 범위를 정하는 입력 계약처럼 느껴졌습니다. 제품 정책이 바뀌면 프롬프트에 들어가는 이 정보도 함께 바뀌어야 합니다.

제품 스펙을 넣자 출력의 범위가 달라졌다#

기능 스펙과 출력 조건을 제공한 뒤에는 부서, 직급, 입사일과 복합 조건을 중심으로 소개 문구가 만들어졌습니다. 민감 데이터 제외 조건은 생성 과정의 경계로만 사용하고, 첫 소개 문구에는 굳이 드러내지 않았습니다.

물론 이 두 화면만으로 프롬프트의 전반적인 품질이 좋아졌다고 말할 수는 없습니다. 다만 제품 정보가 없을 때는 범용적인 사례가 들어갔고, 스펙을 제공한 뒤에는 입력에 포함된 검색 조건이 사용됐다는 차이는 눈으로 확인할 수 있었습니다. 이 실습에서 중요하게 본 것도 점수보다 이 차이였습니다.

결과를 받은 뒤에는 문구에 들어간 기능과 데이터 항목을 다시 제품 스펙과 비교했습니다.

형식이나 금칙어처럼 명확하게 판정할 수 있는 조건은 코드로 확인할 수 있습니다. 반면 제품의 가치를 제대로 설명했는지, 사용자가 자연스럽게 받아들일 표현인지는 제품을 아는 사람이 봐야 했습니다.

결국 프롬프트에는 제품을 아는 사람이 필요했다#

이 실습 전에는 더 강한 금지 문장을 쓰면 없는 기능을 막을 수 있을 거라고 생각했지만 직접 결과를 비교해보니 중요한 것은 경고의 강도가 아니라 모델이 사용할 수 있는 제품 정보의 범위였습니다.

제품을 모르는 모델에게 “알아서 정확하게 써주세요”라고 요청하는 것만으로는 부족했습니다. 제품을 아는 사람이 말해도 되는 범위를 먼저 전달하고, 결과도 같은 기준으로 다시 확인해야 했습니다. 프롬프트는 자연스러운 문장을 얻기 위한 주문이라기보다, 모델에게 제품의 경계를 설명하는 문서에 더 가깝다는 생각이 들었습니다.

이 실습에서 AI와 사람이 맡을 일을 나눈 과정은 AI 협업 기준을 함께 이야기한 사내 세션에서, 프롬프트 변경을 비교할 때 필요한 평가 설계는 프롬프트 점수를 다시 해석해본 글에서 이어집니다.