프롬프트는 "지시서"가 아니라 "설계도"다

비유: 가공 도면과 프롬프트

제조 엔지니어라면 알 것이다. 도면이 부정확하면 제품도 부정확하다.

[가공 도면의 세계]

나쁜 도면: "구멍 뚫어주세요"
→ 어디에? 몇mm? 공차는? 표면 거칠기는?

좋은 도면: "X=50.0mm, Y=30.0mm 위치에
           직경 10H7 관통홀 가공
           표면 거칠기 Ra 1.6
           모따기 C0.5"
→ 정확한 제품이 나온다

프롬프트도 똑같다.

[프롬프트의 세계]

나쁜 프롬프트: "설비 고장 원인 알려줘"
→ 뭐에 대해? 어떤 설비? 증상은? 형식은?

좋은 프롬프트: 역할 + 상황 + 지시 + 형식 + 제약
→ 실무에 바로 쓸 수 있는 답변

프롬프트 품질이 비용으로 돌아오는 자리

모호한 프롬프트는 한 번에 끝나지 않는다. 답이 일반론으로 나오면 다시 묻게 되고, 다시 물을 때마다 앞의 대화가 통째로 함께 전송되어 입력 토큰이 쌓인다. 답이 나빠서 드는 비용보다 다시 묻느라 드는 비용이 크다.

배수를 숫자로 적지 않은 데는 이유가 있다. 절감 폭은 질문의 종류와 모델에 따라 달라서 하나의 값으로 말할 수 없다. 직접 재는 방법은 Day 3에서 배운다. 같은 질문을 두 프롬프트로 던지고 usage.prompt_tokens를 비교하면 내 업무에서의 배수가 나온다.

왜 "엔지니어링"인가

프롬프트 엔지니어링은 반복 실험의 과정이다.

1. 프롬프트 초안 작성
2. 실행 & 결과 확인
3. 부족한 부분 분석
4. 프롬프트 수정
5. 재실행 & 비교
6. 최적 프롬프트 확정

공정 최적화와 똑같다. 파라미터를 바꿔가며 최적 조건을 찾는 것. 그래서 "프롬프트 엔지니어링"이다.