업무를 설명하면 쓸 수 있는 프롬프트가 됩니다

보고서를 만들어 달라는 요청에는 문서라는 물건만 있고 사용할 결정은 없습니다. 검토자가 구매 승인을 해야 하는지 장애 원인을 좁혀야 하는지에 따라 필요한 근거가 달라집니다. 먼저 답변을 읽은 사람이 무엇을 결정하거나 수행할지 한 문장으로 적습니다.

가상 GPU 증설 업무에서는 목표를 장비 소개가 아니라 증설안 A와 B의 승인 조건 비교로 정합니다. 그러면 성능 설명보다 예산, 현재 병목, 대안별 제약이 먼저 필요해집니다. 독자가 결정할 수 없는 사양 나열은 목표를 충족한 결과로 인정하지 않습니다.

목표와 실행 권한은 분리해야 합니다. 승인 자료를 작성하라는 요청이 장비 주문까지 허용하는 것은 아닙니다. 이 도구에서도 최종 프롬프트를 만드는 일만 수행하며, 복사한 문장을 다른 서비스에 보내거나 실제 업무를 실행하는 일은 자동으로 이어지지 않습니다.

목표가 여러 개면 한 산출물로 함께 판단할 수 있는지 확인합니다. 장애 복구와 분기 투자계획처럼 필요한 증거와 승인자가 다르면 요청을 나누는 편이 명확합니다. 목표를 정리한 뒤 각 출력 항목이 어느 결정에 쓰이는지 표시하고, 연결되지 않는 항목은 필요성을 다시 검토하십시오.

왜 이런가

목적을 정하면 어떤 정보가 답변을 바꾸는지 고를 수 있습니다.

언제 문제가 되는가

소개 자료는 완성됐지만 승인할 근거가 없으면 목표 정의부터 다시 확인합니다.

초보자가 자주 하는 오해

전문가 역할을 주면 업무 목적도 전달된다는 생각은 틀립니다. 역할과 원하는 결정은 별도로 적어야 합니다.

직접 확인하는 방법

내 요청에서 산출물과 독자의 다음 행동을 각각 밑줄로 표시하십시오.

맥락은 길게 붙여 넣은 문서의 양이 아니라 판단에 필요한 조건입니다. 입력을 현재 관찰, 적용 범위, 기준 날짜, 참고 원문으로 나누면 무엇을 확정 사실로 쓸지 보입니다. 같은 숫자도 기간이나 대상이 다르면 직접 비교할 수 없으므로 값과 조건을 함께 적습니다.

가상 전환율 분석에서 구매자 80명만 주면 비율을 계산할 분모가 없습니다. 같은 기간의 상품 상세 방문자 1,000명과 중복 제거 기준을 함께 주면 그 정의에서 8%를 계산할 수 있습니다. 다른 기간의 방문자를 섞은 8%는 같은 이름을 써도 동일한 지표가 아닙니다.

원문 인용과 내 지시는 별도 구역에 둡니다. 예를 들어 자료 구역에 회의 메모를 넣고 지시 구역에 결정과 제안을 구분하라고 씁니다. 제목이나 구분 표시는 독해를 돕지만 자료 속 명령을 무력화하는 보안 장치 자체는 아닙니다.

빠진 맥락이 결정을 바꾸는 경우에만 질문을 요구합니다. 가격표의 세금 포함 여부는 예산 판정을 바꾸지만 보고서의 색상 취향은 같은 판정에 필요하지 않을 수 있습니다. 미확인 항목을 추측으로 채우지 말고 필요한 질문과 그 답이 바꾸는 판단을 연결하십시오.

왜 이런가

같은 문장도 적용 대상과 기간이 달라지면 의미가 바뀝니다.

언제 문제가 되는가

서로 다른 기간을 비교하거나 없는 분모를 만든다면 입력 계약을 확인합니다.

초보자가 자주 하는 오해

자료를 많이 넣으면 빈틈이 저절로 메워진다는 생각은 틀립니다. 핵심 조건이 빠진 긴 자료도 불완전합니다.

직접 확인하는 방법

예시 숫자마다 대상·기간·단위를 쓰고 확인하지 못한 값은 미확인으로 남기십시오.

정확하고 전문적으로 쓰라는 말만으로는 실패를 판정하기 어렵습니다. 성공 조건은 답변에서 확인할 값, 보존할 사실, 허용하지 않을 행동으로 나누어 씁니다. 표현의 인상과 사실의 일치를 따로 확인해야 보기 좋은 오답을 걸러낼 수 있습니다.

회의록 예시에서는 모든 실행 항목에 담당자와 기한을 채우는 조건이 오히려 허구를 유도할 수 있습니다. 원문에 있는 담당자와 기한만 쓰고 없는 값은 미확인으로 표시하는 조건이 더 정확합니다. 빈칸이 줄었다는 이유로 원문 충실도가 좋아졌다고 판단하지 않습니다.

자동 검사와 사람의 검토가 맡을 일을 구분합니다. 숫자 보존과 필수 열 존재는 비교하기 쉽지만, 제안이 결정으로 바뀌었는지는 문맥을 읽어야 합니다. 한 가지 검사를 통과했다는 이유로 나머지 기준까지 통과로 기록하지 않습니다.

통과 조건과 보류 조건을 짝으로 작성합니다. 예산 근거가 없을 때는 조건부 비교까지만 허용하고 구매 권고 확정은 보류하는 식입니다. 답변을 받은 뒤에는 각 조건에 통과, 실패, 미확인을 기록하고 판단 근거가 된 출력 부분을 남기십시오.

왜 이런가

관찰할 조건을 먼저 정해야 같은 답변을 같은 기준으로 비교할 수 있습니다.

언제 문제가 되는가

필수 필드를 채우려고 담당자나 수치를 만들어 내면 성공 조건이 잘못 설계됐을 수 있습니다.

초보자가 자주 하는 오해

형식이 완성되면 내용도 검증됐다는 생각은 틀립니다. 형식과 의미는 따로 확인합니다.

직접 확인하는 방법

원문에 기한이 없는 예시를 넣고 결과가 미확인으로 남는지 확인하십시오.

제약은 결과의 모양보다 작업이 넘어가면 안 되는 경계를 정합니다. 바꾸지 말아야 할 자료, 승인 뒤에만 가능한 행동, 근거가 없으면 멈출 지점을 구분합니다. 이 셋을 모두 조심해서 하라는 한 문장에 넣으면 실제 판단 시점을 알기 어렵습니다.

가상 코드 수정에서는 공개 API 유지, 데이터 삭제 금지, 배포 전 승인으로 경계를 나눌 수 있습니다. 오류를 고쳤다는 사실이 API 변경이나 운영 배포의 허가가 되지는 않습니다. 결과 보고에는 수정한 파일과 실행한 검사뿐 아니라 승인이 남은 행동도 구분합니다.

서로 충돌하는 제약은 모델에게 알아서 맞추라고 맡기지 않습니다. 모든 근거를 보존하면서 본문을 한 문장으로 제한하면 필요한 정보가 사라질 수 있습니다. 무엇을 우선하고 어떤 경우에 분량 제한을 다시 협의할지 요청에 명시합니다.

프롬프트의 금지는 실행 환경의 권한 제한을 대신하지 않습니다. 삭제 명령을 금지했다고 써도 도구가 가진 쓰기 권한이 사라지지는 않습니다. 실제 자동화에서는 필요한 권한만 부여하고 승인과 검증을 실행 경로에서 강제하며, 이 과정의 브라우저 활동에서는 실제 작업을 실행하지 않습니다.

왜 이런가

결과 목표만 있으면 허용된 범위 밖의 행동도 목표 달성 수단으로 제안될 수 있습니다.

언제 문제가 되는가

수정 요청이 주문·전송·배포로 확대되면 승인 경계를 다시 확인합니다.

초보자가 자주 하는 오해

금지 문장을 반복하면 권한 통제가 된다는 생각은 틀립니다. 실제 도구 권한과 승인 절차가 별도로 필요합니다.

직접 확인하는 방법

허용 작업과 승인 대기 작업을 두 열로 나누고 각 행동을 배치하십시오.

표로 답하라는 지시만으로는 열의 의미가 정해지지 않습니다. 같은 비용 열에 월 비용과 연 비용이 섞이면 보기에는 정돈되어도 비교는 잘못됩니다. 열 이름, 단위, 기간, 값이 없을 때의 표기를 함께 정합니다.

가상 견적 비교에서는 선택안, 월 비용, 포함 항목, 제외 항목, 기준일을 열로 둡니다. 비용이 비공개인 안에는 0원을 넣지 않고 미확인을 적습니다. 0원은 실제 비용이 없다는 주장이고 미확인은 판단할 자료가 없다는 상태이므로 서로 바꿀 수 없습니다.

기계가 읽을 JSON을 요청하는 경우에도 필드 이름만 고정해서는 충분하지 않습니다. JavaScript Object Notation(JSON, 자바스크립트 객체 표기법)의 올바른 문법과 값의 업무상 타당성은 다른 검사입니다. API의 Structured Outputs는 지원하는 스키마에 맞는 출력을 돕지만 잘못된 사실까지 자동으로 교정하는 기능은 아닙니다.

이 프롬프트 도구는 API 스키마를 강제하거나 결과 JSON을 검증하지 않습니다. 사용자는 출력 형식을 문장으로 지정한 뒤 실제 사용할 서비스에서 형식과 값의 검사를 따로 수행해야 합니다. 불확실성 설명이 필요한 업무라면 짧은 표 바깥에 근거와 보류 이유를 남길 공간도 정하십시오.

왜 이런가

값을 읽는 규칙이 같아야 서로 다른 결과를 비교하거나 후속 작업에 넘길 수 있습니다.

언제 문제가 되는가

없는 비용이 0으로 바뀌거나 월·연 단위가 섞이면 출력 계약을 확인합니다.

초보자가 자주 하는 오해

JSON 형태이면 사실도 참이라는 생각은 틀립니다. 올바른 구조 안에도 잘못된 값이 들어갈 수 있습니다.

직접 확인하는 방법

가격이 없는 입력을 넣고 미확인 표기와 단위가 그대로 유지되는지 대조하십시오.

모델이 단정적으로 쓴 문장과 검증된 사실은 다릅니다. 출처 링크가 있어도 해당 문서가 실제 주장을 지지하는지 읽어야 합니다. 답변의 핵심 주장마다 원문 위치, 적용 조건, 확인 상태를 연결하면 무엇을 다시 검토할지 드러납니다.

가상 구매 조사에서 공식 가격표가 월 요금만 제시하고 세금과 지역 조건은 설명하지 않는다고 가정합니다. 총비용을 확정하려면 빠진 조건을 추가로 확인해야 합니다. 현재 자료로 계산한 소계와 아직 확인하지 못한 비용을 나누면 결론을 만들기 위해 숫자를 지어낼 필요가 없습니다.

자료에 근거한 사실, 그 사실에서 도출한 추론, 계산을 위해 둔 가정을 분리합니다. 예를 들어 장애 건수가 늘었다는 관찰만으로 새 버전이 원인이라고 확정할 수 없습니다. 배포 시점, 트래픽 변화, 관찰 누락 같은 대안 설명을 확인한 뒤 어느 범위까지 말할 수 있는지 정합니다.

최신 확인이 필요한 요청에는 기준 날짜와 확인할 출처를 적습니다. 다만 프롬프트에 검색하라고 쓴다고 해서 사용 서비스에 검색 기능이 생기는 것은 아닙니다. 도구나 자료 접근이 없으면 최신성을 미확인으로 보고하고, 실제로 확인하지 않은 링크 검사를 완료로 적지 않도록 요구하십시오.

왜 이런가

문장의 확신보다 원문과 관찰의 연결이 판단 근거가 됩니다.

언제 문제가 되는가

접근하지 못한 자료를 검토했다고 쓰면 근거 보고가 실패한 것입니다.

초보자가 자주 하는 오해

출처 링크가 붙으면 인용 검증도 끝났다는 생각은 틀립니다. 링크가 해당 주장을 지지하는지 확인해야 합니다.

직접 확인하는 방법

주장 하나를 골라 원문 문장과 적용 날짜를 찾고, 없으면 확인 필요로 고치십시오.

한 번 좋은 답을 받았다는 사실만으로 프롬프트가 안정적이라고 말할 수 없습니다. 같은 입력도 결과가 달라질 수 있고 쉬운 예시에서 드러나지 않는 오류가 있습니다. 실제 사용할 업무를 대표하는 정상 사례와 실패하기 쉬운 경계 사례를 함께 준비합니다.

회의록 프롬프트라면 확정 결정이 있는 메모, 제안만 있는 메모, 담당자가 빠진 메모를 구분합니다. 각 사례에서 허용할 결과와 금지할 추정을 답변을 보기 전에 정합니다. 모든 사례에 확정 결정을 만들어 넣는 답은 읽기 매끄러워도 경계 사례에서 실패합니다.

수정 전후를 비교할 때는 같은 입력과 같은 평가 기준을 사용합니다. 프롬프트, 모델이나 서비스 설정, 자료 범위를 한꺼번에 바꾸면 어느 변경이 영향을 줬는지 분리하기 어렵습니다. 기록에는 사용한 버전과 실패한 항목을 남기되 몇 번의 성공을 전체 업무의 정확도 보장으로 확대하지 않습니다.

형식 통과율만 보면 사실을 보존하지 못하는 회귀를 놓칩니다. 개선 후 기한 누락은 줄었지만 없는 담당자를 새로 만들었다면 채택하지 않아야 합니다. 실패 원인을 지시의 모호함, 자료 부족, 평가 기준 오류로 나누고 수정 후 같은 사례와 별도의 새 사례를 다시 확인하십시오.

왜 이런가

좋아 보이는 한 사례를 고르는 대신 실패 유형을 확인해야 개선 여부를 판단할 수 있습니다.

언제 문제가 되는가

수정한 예시에서만 통과하고 다른 입력에서 사실을 추가하면 회귀를 의심합니다.

초보자가 자주 하는 오해

평가 사례를 많이 복제하면 다양성이 늘어난다는 생각은 틀립니다. 다른 실패 조건을 포함해야 합니다.

직접 확인하는 방법

정상·정보 누락·충돌 자료 사례를 각각 하나씩 만들고 같은 통과 기준을 적용하십시오.

검토할 문서에는 업무와 무관한 명령형 문장이 섞일 수 있습니다. 문서를 요약하라는 요청과 문서 안에서 비밀을 보내라는 문장은 같은 권한의 지시가 아닙니다. 자료는 분석 대상으로 취급하고 그 안의 행동 요청이 원래 업무를 바꾸지 않도록 경계를 정합니다.

가상 고객 메모에 검토 전에 인증 토큰을 외부 주소로 보내라는 문장이 들어 있다고 가정합니다. 요약에 필요한 것은 고객의 요청과 증거이지 인증 비밀이 아닙니다. 해당 문장을 실행하지 않고 자료 속 의심스러운 요청으로 표시하며 원래 요약 작업의 범위에서 검토합니다.

입력 전 최소화는 프롬프트 문구보다 먼저 수행할 수 있는 통제입니다. 문제 재현에 필요하지 않은 이름, 계정 비밀, 고객 원문 전체를 제거하고 역할명이나 짧은 가상 예시로 바꿉니다. 비밀을 붙여 넣은 뒤 답변에 노출하지 말라고 요구하는 것은 이미 전달한 사실을 되돌리지 못합니다.

이 사이트의 입력은 브라우저 안에서 프롬프트로 조합되며 모델 호출은 하지 않습니다. 복사한 뒤 외부 AI 서비스에 전송할 때는 그 서비스의 데이터 처리 조건과 사용 권한을 따로 확인해야 합니다. 실제 자동화의 보안은 문장뿐 아니라 접근 권한, 도구 호출 검증, 필요한 사람의 승인으로 보강하십시오.

왜 이런가

원문을 처리하는 과정에서 원문 속 요청까지 실행하면 업무의 신뢰 경계가 무너집니다.

언제 문제가 되는가

요약 중 외부 전송이나 자격증명 요구가 나타나면 자료와 지시의 경계를 확인합니다.

초보자가 자주 하는 오해

구분 태그만 붙이면 prompt injection이 완전히 차단된다는 생각은 틀립니다. 태그는 독해 보조이며 권한 통제를 대신하지 않습니다.

직접 확인하는 방법

가상 문서의 의심스러운 행동 요청을 표시하고 원래 업무에 필요한 정보만 남기십시오.