8장. 그럴듯한 프롬프트가 좋은 결과를 보장하지 않는다

프롬프트를 하나 만들었다.

목적이 적혀 있다.

입력 자료도 정리돼 있다.

금지 사항과 출력 형식, 검사 기준까지 들어 있다.

스크롤을 몇 번 내려야 끝나는 제법 근사한 프롬프트다.

읽어보면 안심이 된다.

이 정도면 잘 나오겠지.

바로 이 순간부터 조심해야 한다.

프롬프트의 품질을 프롬프트를 읽고 판단하기 시작했기 때문이다.

정교하게 보이는 프롬프트가 실제 결과도 좋은지는 아직 모른다. 전문용어가 많다고 더 정확한 것도 아니다. 규칙이 열다섯 개 있다고 열다섯 가지 문제가 예방되는 것도 아니다.

역할, 단계, 출력 형식, 금지 사항이 빽빽하게 적혀 있어도 실제 자료를 넣었을 때 중요한 숫자 하나를 빠뜨릴 수 있다. 반대로 한 줄짜리 요청이 놀랄 만큼 좋은 결과를 낼 수도 있다.

이 책의 주간 보고서 실습에서 실제로 그랬다.

한 줄짜리 요청이 예상보다 잘했다

첫 번째 요청은 이것뿐이었다.

이 자료로 이번 주 보고서 좀 잘 써줘.

자료에는 이번 주와 지난주의 주문, 매출, 환불, 광고비, 신규 고객, 고객 문의, 배송 지연률이 있었다.

별도의 품질 기준도 주지 않았다.

그런데 결과는 상당히 좋았다.

주문과 매출의 증감을 계산했다. 환불이 크게 늘었다는 사실도 중요하게 다뤘다. 배송 지연률 상승도 놓치지 않았다. 광고비가 증가했다고 해서 광고 때문에 매출이 늘었다고 단정하지 않았다. 배송 지연과 환불 사이의 인과관계도 함부로 만들지 않았다.

심지어 주문당 평균 매출, 매출 대비 광고비 비중, 주문 100건당 고객 문의처럼 사용자가 요청하지 않은 파생 지표까지 계산했다.

잘못된 결과를 보여주기 위해 일반 요청을 일부러 형편없다고 평가할 이유가 없었다.

결과는 좋았다.

그렇다면 우리가 만든 긴 실행 프롬프트는 쓸모가 없었던 걸까.

이 질문에 답하려면 프롬프트가 아니라 결과를 나란히 놓아야 한다.

프롬프트 이름을 가린다

두 결과가 있다고 해보자.

결과 A

매출과 주문 증가를 보여준다.

환불과 배송 지연의 악화를 강조한다.

주문당 매출, 매출 대비 광고비 비중, 주문 100건당 문의 같은 추가 지표를 계산한다.

운영 문제를 우선 점검하라고 제안한다.

결과 B

매출·주문·신규 고객과 함께 환불·고객 문의·배송 지연을 모두 표시한다.

사실, 해석, 제안을 구역으로 나눈다.

광고비 유지 여부는 현재 자료만으로 확정하지 않는다.

제안 전에 추가 확인이 필요한 정보를 밝힌다.

둘 중 하나는 짧은 일반 요청에서 나온 결과다. 다른 하나는 목적, 필수 정보, 금지 사항, 출력 구조, 검사 기준을 넣은 실행 프롬프트에서 나온 결과다.

어느 쪽이 더 좋은가.

바로 답하기 어렵다. 그게 정상이다.

결과 A에는 사용자가 생각하지 못한 유용한 분석이 있다. 결과 B에는 반복 업무에 쓰기 좋은 구조가 있다. 둘의 장점이 다르다.

따라서 먼저 물어야 한다.

무엇을 기준으로 좋은 결과라고 할 것인가.

결과를 보기 전에 기준을 정한다

5장에서 만든 판정표를 다시 가져온다.

주간 보고서에서 반드시 지켜야 할 조건을 다음처럼 정했다고 해보자.

MUST

• 7개 필수 지표가 빠지지 않는다.
• 원자료의 수치와 계산이 맞는다.
• 확인되지 않은 원인을 사실처럼 쓰지 않는다.
• 사실과 해석을 구분한다.
• 팀장이 판단하기 어려운 정보 부족 상태를 드러낸다.

NICE

• 첫 화면에서 핵심 이슈를 볼 수 있다.
• 불필요하게 길지 않다.
• 다음 행동이 구체적이다.

이제 결과 A와 B를 이 기준으로 읽는다.

둘 다 대부분의 MUST를 통과할 수 있다.

그렇다면 메타 프롬프트를 썼다는 이유만으로 B가 무조건 승리라고 할 수 없다.

“더 잘 썼나”보다 “무엇이 달라졌나”

좋은 비교는 승자를 뽑는 일만이 아니다. 두 결과가 어떻게 달라졌는지 보는 일이다.

일반 요청의 결과는 AI가 도움이 된다고 판단한 방향으로 분석 범위를 넓혔다. 주문당 매출도 계산했다. 광고비 비중도 계산했다. 문의율도 계산했다.

이런 자율적인 확장은 상황에 따라 장점이다. 한 번 보는 분석이라면 사용자가 생각하지 못한 지표를 찾아주는 편이 더 유용할 수 있다.

반면 실행 프롬프트는 범위를 더 명시적으로 고정했다.

어떤 지표가 필수인지. 어떤 계산이 허용되는지. 자료가 부족할 때 어떻게 표시할지. 사실과 해석과 제안을 어떻게 나눌지. 출력 전에 무엇을 검사할지.

결과 한 번의 품질 차이보다 행동 범위가 명시됐다는 차이가 더 크다.

이런 비교를 해야 메타 프롬프트의 실제 가치가 보인다.

좋은 결과가 나왔다고 좋은 프롬프트는 아니다

반대 경우도 있다.

프롬프트가 허술했는데 결과가 훌륭하다.

그렇다면 프롬프트가 좋은 걸까.

아직 모른다.

모델이 문맥을 잘 읽었을 수도 있다. 이번 데이터가 단순했을 수도 있다. 우연히 사용자의 의도와 모델의 기본 판단이 잘 맞았을 수도 있다. 다음 자료에서는 다르게 행동할 수 있다.

그래서 한 번의 성공에는 두 가지 질문이 따라온다.

결과가 좋은가?

그리고 하나가 더 있다.

왜 좋은 결과가 나왔는지 다시 설명할 수 있는가?

두 번째 질문에 답할 수 없으면 반복 업무에서 불안해진다.

결과가 그럴듯하면 오류가 더 안 보인다

문장이 어색한 답은 고치기 쉽다. 읽다가 바로 걸린다.

위험한 것은 반대다. 문장이 매끄럽고 표도 깔끔한데 사실 하나가 잘못된 결과다. 특히 숫자가 많은 업무에서는 더 그렇다.

예를 들어 이런 문장이 나온다.

광고비가 16.7% 증가했고 매출이 7.5% 증가했으므로 광고 효율이 악화됐다.

처음 읽으면 논리적으로 보인다.

하지만 광고 효율을 판단하려면 광고가 실제로 만들어 낸 매출이나 전환, 비용 구조가 필요할 수 있다. 전체 매출과 전체 광고비만 비교해 실제 광고 성과라고 단정하면 안 된다.

결과가 매끄럽다는 사실은 정확성의 증거가 아니다.

읽기 좋은 결과와 사용할 수 있는 결과는 다르다.

프롬프트 문장을 평가하지 말고 산출물을 평가한다

프롬프트를 개선해 달라고 하면 AI는 이런 말을 할 수 있다.

역할을 더 명확히 했습니다.

검증 단계를 강화했습니다.

예외 처리 규칙을 추가했습니다.

좋아 보인다.

하지만 실제 결과를 다시 만들지 않았다면 무엇이 좋아졌는지 확인하지 못한 상태다.

그래서 순서를 바꾼다.

프롬프트를 만든다. 실제 입력을 넣는다. 결과를 판정한다. 문제가 관찰되면 프롬프트를 본다.

프롬프트는 결과에 문제가 생겼을 때 다시 보는 설계도다.

블라인드 비교는 거창한 절차가 아니다

두 프롬프트를 비교하고 싶다면 결과 이름을 잠시 가려도 좋다.

결과 A, 결과 B라고 놓고 먼저 판정한다. 그다음 어떤 프롬프트에서 나온 것인지 확인한다.

이것을 엄밀한 블라인드 실험이라고 부를 필요는 없다. 실용적인 장치다.

“이 프롬프트는 내가 공들여 만들었으니 더 좋아야 한다”는 기대가 판단에 끼어드는 것을 조금 줄여준다.

특히 직접 만든 장문의 프롬프트와 한 줄 요청을 비교할 때 도움이 된다. 사람은 자신이 오래 만든 것을 쉽게 버리지 못한다.

비교표를 간단하게 만든다

복잡한 평가 시스템은 필요 없다.

이 표의 목적은 최종 점수를 만드는 것이 아니다. 무엇이 달라졌는지 드러내는 것이다.

일반 요청이 더 좋으면 그대로 인정한다

특정 업무에서는 한 줄 요청이 더 나을 수 있다.

AI가 예상하지 못한 관점을 넓게 찾아야 하는 초기 아이디어 단계가 그렇다. 규칙을 너무 많이 주면 결과가 좁아질 수도 있다.

그럴 때는 일반 요청을 쓴다.

이 책의 목표는 모든 요청을 거대한 메타 프롬프트로 바꾸는 것이 아니다.

반복과 검증이 필요한 업무에서 필요한 만큼만 구조를 만든다.

일반 요청과 설계된 프롬프트는 경쟁 관계가 아니다. 사용 목적이 다르다.

8장의 실습

자주 하는 업무 하나를 고른다.

평소처럼 짧게 요청한다. 앞 장들에서 만든 실행 프롬프트로 같은 자료를 처리한다. 두 결과를 결과 A, 결과 B로 저장하고 프롬프트 이름은 잠시 가린다.

다섯 가지만 본다.

1. 빠진 정보가 있는가.

2. 틀린 사실이나 계산이 있는가.

3. 자료에 없는 내용을 추가했는가.

4. 내가 정한 목적을 충족하는가.

5. 다시 사용할 때 유지하고 싶은 행동이 무엇인가.

그다음 프롬프트를 공개한다.

어느 쪽이 더 나았는지보다 다음 질문을 남긴다.

다음 실행에서도 반복하고 싶은 차이는 무엇인가.

그 차이가 프롬프트에 남길 규칙이다.

같은 결과를 읽는 순서도 고정할 수 있다

두 결과를 비교할 때 문장 취향부터 보면 판단이 흔들리기 쉽다.

먼저 MUST를 본다.

1. 필수 항목 누락.

2. 사실과 계산 오류.

3. 자료 밖의 창작.

4. 금지 규칙 위반.

그다음 NICE를 본다.

5. 읽기 쉬운가.

6. 반복이 적은가.

7. 다음 행동이 구체적인가.

이 순서를 쓰면 ‘문장이 더 세련돼 보여서 B가 좋다’ 같은 인상을 뒤로 미룰 수 있다.

일반 요청이 만든 추가 지표를 어떻게 볼 것인가

clean baseline은 주문당 평균 매출과 광고비 비중 같은 파생값을 자발적으로 만들었다.

이것을 무조건 ‘범위 이탈’이라고 볼 필요는 없다.

탐색 단계에서는 새로운 관점이 도움이 된다.

반대로 정기 보고서의 공식 지표가 고정돼 있다면 매번 다른 파생값이 생기는 것이 부담이 될 수 있다.

그래서 실행 프롬프트에 다음 중 하나를 선택한다.

지정한 지표 외의 추가 계산은 하지 않는다.

또는 이렇게 정할 수도 있다.

추가로 유용해 보이는 계산이 있으면 ‘추가 관찰’ 구역에 따로 제안하되 공식 지표와 섞지 않는다.

이 결정은 프롬프트의 ‘좋고 나쁨’이 아니라 사용 목적의 차이다.

비교 결과를 규칙으로 바꾸는 마지막 질문

A와 B를 비교한 뒤 바로 “B를 저장”하지 않는다.

다음 질문을 한다.

B의 어떤 행동을 다음 실행에서도 반복하고 싶은가.

예를 들어 답이:

자료가 부족한 의사결정을 ‘추가 확인 필요’로 남긴 점.

이라면 이 행동을 고정 규칙으로 저장한다.

반대로 “문장이 더 마음에 들었다”면 아직 규칙이 아니다. 무엇 때문에 더 마음에 들었는지 분해해야 한다.

이 과정이 결과 비교를 프롬프트 설계로 되돌리는 연결 고리다.

두 결과를 먼저 이름 없이 읽는다

같은 입력으로 짧은 요청과 실행 프롬프트를 각각 사용한다. 결과를 A와 B로 저장하고 어느 프롬프트의 결과인지 표시를 잠시 가린다. MUST부터 판정한 뒤 예상 밖의 유용한 내용과 반복 사용 적합성을 본다. 마지막에 다음 실행에서도 반복하고 싶은 차이를 한 문장으로 적는다.