같은 회의록을 AI에 전달해도 한 번은 결정 사항이 잘 정리되고, 다른 한 번은 논의 중인 내용을 확정된 일정처럼 표현할 수 있다. 이런 차이를 줄이려면 요청에 업무 목적, 사용할 자료, 판단 기준, 출력 형식을 담아야 한다. 다만 프롬프트가 명확해져도 원문 오류나 모델의 능력 부족까지 해결되지는 않는다. 결과 품질은 지시문과 함께 입력 자료, 모델, 생성 설정, 검증 방식의 영향을 받는다.
프롬프트는 질문을 넘어 작업 조건을 전달
프롬프트는 생성형 AI가 작업을 수행하도록 전달하는 지시와 입력 정보다. 채팅창에 적는 질문뿐 아니라 애플리케이션이 설정한 지침, 대화 이력, 참고 문서가 함께 작용할 수 있다. 따라서 화면에 같은 질문을 입력했더라도 사용한 서비스와 대화 맥락이 다르면 결과가 달라질 수 있다.
프롬프트를 작성할 때는 AI가 스스로 알아낼 내용과 사용자가 반드시 제공해야 할 내용을 구분해야 한다. 사내 승인 기준이나 아직 공개되지 않은 일정은 모델이 알고 있다고 전제할 수 없다. 역할을 지정하는 문장도 답변 관점과 표현을 정하는 데 도움을 줄 뿐, 실제 전문 자격이나 사실 확인을 보장하지 않는다.
Anthropic은 프롬프트 개선에 앞서 성공 기준과 이를 시험할 방법을 마련하도록 안내한다. 이를 업무에 적용하면 “좋은 요약”이라는 요구를 “결정 사항을 빠뜨리지 않고, 미정인 담당자를 만들어내지 않는 요약”처럼 관찰 가능한 조건으로 바꾸는 것이 출발점이다. Anthropic — 프롬프트 엔지니어링 개요
목적·자료·기준·형식으로 구조화
아래 구분은 업무용 프롬프트를 점검하기 위한 실무적 틀이다. 모든 요청에 같은 길이나 순서로 적용할 필요는 없다.
| 구성 요소 | 전달할 내용 | 회의록 요약 예시 |
|---|---|---|
| 작업과 목적 | 무엇을 누구에게 제공할지 | 참석하지 못한 팀장에게 결정 사항 전달 |
| 입력 자료 | 사용할 원문과 적용 범위 | 제공한 회의록만 근거로 사용 |
| 판단 기준 | 포함·제외 조건과 예외 처리 | 제안과 확정을 구분하고 미정은 미정으로 표시 |
| 출력 형식 | 항목, 분량, 표현 방식 | 결정 사항·담당자·기한·근거를 표로 작성 |
| 예시 | 모호한 기준을 보여주는 사례 | “금요일 검토 예정”을 완료로 분류하지 않음 |
Google의 프롬프트 설계 문서는 명확한 지시, 제약 조건, 응답 형식, 맥락 제공을 주요 요소로 설명한다. 실무적으로는 “자세히 정리해줘”를 반복하기보다 반드시 남겨야 할 정보와 빠져도 되는 정보를 지정하는 편이 수정 방향을 확인하기 쉽다. Google — 프롬프트 설계 전략
지시와 참고자료의 경계도 표시해야 한다. 제목이나 구분자를 사용해 “작업 지시”와 “회의록 원문”을 나누면 읽어야 할 자료와 따라야 할 요구를 구별하는 데 도움이 된다. 다만 구분자만으로 외부 문서의 악의적인 지시를 완전히 차단할 수 있다고 판단해서는 안 된다. 외부 자료를 처리하는 서비스에서는 도구 접근권한과 실행 승인도 별도로 관리해야 한다.
모호한 요청을 검토 가능한 업무 요청으로 변환
“아래 회의록을 잘 요약해줘”에는 무엇을 중요하게 볼지, 빠진 정보를 어떻게 처리할지에 대한 기준이 없다. 다음은 이를 구체화한 작성 예시다. 특정 모델에서 성능을 측정한 결과는 아니다.
[작업과 목적]
참석하지 못한 팀장이 후속 업무를 확인할 수 있도록 회의록을 정리한다.
[판단 기준]
제공된 원문만 근거로 사용한다.
결정 사항과 검토 중인 제안을 구분한다.
담당자와 기한이 명시되지 않았으면 '미정'으로 표시한다.
서로 충돌하는 일정은 하나로 확정하지 말고 '확인 필요'로 표시한다.
[출력 형식]
'구분 / 내용 / 담당자 / 기한 / 근거 문장' 순서의 표로 작성한다.
표 아래에 추가로 확인할 항목을 정리한다.
[회의록 원문]
여기에 실제 회의록을 붙여넣는다.이 요청은 추측을 줄이고 결과를 원문과 대조하기 쉽게 만드는 설계다. 그렇다고 AI가 표시한 근거 문장이 실제 원문에 존재하거나 올바르게 해석됐다는 보장이 생기지는 않는다. 담당자와 기한처럼 업무에 영향을 주는 항목은 원문을 확인해야 한다.
분류 기준을 문장으로 설명하기 어렵다면 입력과 기대 출력을 짝지은 예시를 추가할 수 있다. 이를 few-shot prompting, 즉 소수의 예시를 이용한 프롬프팅이라고 한다. Anthropic은 실제 업무와 관련 있고 다양한 예시를 권고한다. Anthropic — 프롬프팅 모범 사례
예를 들어 “금요일 배포를 제안함 → 검토 중”, “금요일 배포하기로 확정함 → 결정”을 함께 제시할 수 있다. 예시가 한쪽 유형에만 치우치면 다른 상황을 잘못 분류할 수 있으므로, 명확한 사례와 애매한 사례를 구분해 준비하는 것이 좋다.
답변의 근거를 바꾸는 자료의 품질과 배치
정확한 지시를 전달해도 오래된 정책이나 잘못된 수치를 제공하면 결과가 틀릴 수 있다. 여러 버전의 문서를 넣을 때는 문서명, 적용일, 우선 사용할 버전을 표시해야 한다. 최신 문서라는 이유만으로 모든 업무에 적용되는 것도 아니므로 대상 부서나 계약 범위도 확인한다.
자료를 많이 넣는 것이 항상 유리하지는 않다. Liu 등의 2024년 논문 「Lost in the Middle」은 평가한 모델과 과제에서 관련 정보의 위치에 따라 성능이 달라지고, 긴 입력의 중간 정보를 활용할 때 성능이 떨어질 수 있음을 보고했다. 이 결과를 모든 최신 모델의 고정된 특성으로 일반화할 수는 없다. 다만 자료가 입력 범위 안에 들어갔다는 사실만으로 필요한 정보를 정확히 사용했다고 판단해서는 안 된다는 근거가 된다. Liu 외 — Lost in the Middle
운영 환경에서는 관련 자료를 선별하고 문서별 경계를 표시한 뒤, 질문이 요구하는 근거를 찾아 답하도록 구성할 수 있다. 자료 배치는 모델의 공식 권고와 실제 업무 테스트에 맞춰 조정한다. 같은 의미의 지시를 여러 곳에 반복해 길이를 늘리기보다, 서로 충돌하는 규칙과 불필요한 문서를 먼저 정리해야 한다.
모델과 생성 설정은 프롬프트와 함께 점검
프롬프트를 고쳐도 계산 오류가 반복되면 계산 도구를 연결하거나 다른 모델을 시험할 필요가 있다. 최신 정보가 필요한 요청에는 실제 검색이나 최신 자료 제공이 필요하다. “최신 내용으로 답하라”는 문장 자체가 새로운 정보에 대한 접근을 만들어주지는 않는다.
생성 설정도 영향을 준다. temperature는 출력 토큰을 선택할 때의 무작위성과 관련된 설정이며, 사실의 정확도를 직접 조절하는 장치는 아니다. Google은 Gemini 3 계열에서 temperature 등 일부 설정을 기본값으로 유지하도록 권고한다. 따라서 “낮출수록 업무 답변이 좋아진다”는 규칙을 모든 모델에 적용할 수 없다. 모델별 지원 설정과 권고를 확인해야 한다. Google — 생성 설정과 모델별 지침
작업을 자료 추출과 최종 문서 작성으로 나누면 어느 단계에서 오류가 생겼는지 확인하기 쉬워진다. 대신 호출 횟수와 응답 시간이 늘고, 첫 단계의 오류가 다음 단계로 전달될 수 있다. 분리한 단계마다 검증할 이유가 있는지 판단해야 한다.
반복 업무에서는 성공 사례보다 실패 조건을 관리
한 번 마음에 드는 답변을 얻었다고 프롬프트가 안정적이라고 볼 수는 없다. Google Cloud의 생성형 AI 평가 문서는 업무를 반영한 평가 데이터와 기준을 준비하고, 전체 점수와 개별 응답을 함께 검토하는 흐름을 설명한다. Google Cloud — 생성형 AI 평가 서비스 개요
회의록 요약을 반복해서 운영한다면 다음과 같은 자체 평가 기준을 마련할 수 있다.
- 결정 사항이 원문과 일치하고 중요한 항목이 빠지지 않았는지 확인한다.
- 담당자·기한이 없는 경우 미정으로 처리하는지 확인한다.
- 제안, 부정 표현, 상충하는 일정이 섞인 입력을 시험한다.
- 표의 항목이 유지되고 근거 문장을 원문에서 찾을 수 있는지 확인한다.
비교할 때는 모델과 생성 설정, 입력 자료를 가능한 한 같게 두고 프롬프트의 변경 요소를 좁힌다. 수정에 사용한 사례 외에 별도의 사례로도 점검해야 특정 문서에만 잘 맞는 개선을 피할 수 있다. 프롬프트와 모델 버전을 기록하면 서비스 변경 뒤 생긴 품질 저하도 추적하기 쉽다.
기업 환경에서는 평가용 입력과 결과에도 개인정보나 내부정보가 남을 수 있다. 공유할 예시를 비식별화하고, 기록의 접근권한과 보관 범위를 정하는 작업이 필요하다. “비밀을 지켜라”는 지시문이 이러한 관리 조치를 대신할 수는 없다.
프롬프트를 개선할 때 먼저 확인할 것은 실패의 종류다. 기준을 잘못 이해했다면 지시와 예시를, 근거가 부족했다면 자료를, 계산이 틀렸다면 도구와 검증을 손봐야 한다. 반복 업무의 품질은 멋진 문구 하나보다 실패 원인을 구분하고 변경 효과를 확인하는 과정에서 안정된다.