Prompt Engineering

모델은 같은 질문에도 기준이 모호하면 요약처럼 답할 수도 있고, 분류처럼 답할 수도 있고, 과하게 장황해질 수도 있습니다. 사람끼리는 암묵적으로 아는 규칙도 모델에게는 명시되지 않으면 빠지기 쉽습니다. 그래서 작업 목표, 금지 조건, 예외 처리, 원하는 답변 톤을 드러내지 않으면 결과가 들쭉날쭉해집니다.

초기에는 '질문을 더 잘 쓰는 요령' 정도로 받아들여졌지만, LLM이 검색, 도구 호출, 자동화 흐름 안으로 들어오면서 프롬프트는 사실상 애플리케이션 정책의 일부가 됐습니다. 모델이 범용적일수록 기본값도 넓게 퍼져 있기 때문에, 특정 업무에 맞는 행동을 끌어내려면 지시 설계가 별도 레이어로 필요해졌습니다.

prompt engineering은 여전히 기본기지만, 지금은 '마법 문장'을 찾는 기술보다 시스템 정책과 평가 기준을 모델이 읽을 수 있게 쓰는 층으로 보는 편이 더 정확합니다. 검색, structured output, tool use가 붙을수록 프롬프트 하나가 모든 문제를 해결하지는 못하므로, 지금의 프롬프트는 전체 시스템 계약 중 의미와 우선순위를 맡는 레이어로 읽어야 합니다.

프롬프트는 보통 역할 설명, 해야 할 작업, 판단 기준, 예시, 금지 조건, 출력 요구를 한 묶음으로 전달합니다. 이 요소들이 모델의 주의를 어디에 두게 할지, 무엇을 성공으로 볼지 정합니다. 사소한 표현 하나를 바꾸는 것보다 작업 정의와 예시를 명확히 하는 편이 결과 안정성에 훨씬 큰 영향을 줍니다.

prompt engineering과 structured output은 둘 다 모델 출력을 더 예측 가능하게 만들지만, prompt engineering은 모델이 무엇을 어떤 기준으로 판단할지를 정하고 structured output은 그 판단 결과를 어떤 필드 구조로 받을지 고정합니다. 작업 뜻이나 우선순위가 흔들리면 prompt engineering을 보고, 형식과 파싱이 흔들리면 structured output을 봐야 합니다. 스키마만 세운다고 판단 근거가 자동으로 선명해지지는 않는다는 점이 한계입니다.

실무에서는 추출, 분류, 요약, 고객 응대처럼 반복되는 작업에 프롬프트 템플릿을 둡니다. 이때 프롬프트가 길어질수록 중요한 규칙이 묻히기 쉬우므로, 자주 흔들리는 판단을 예시로 고정하고 나머지는 간결하게 유지하는 편이 낫습니다. 프롬프트 하나에 문서, 정책, 대화, 결과 형식까지 모두 떠안기 시작하면 다음에는 context engineering이나 structured output으로 역할을 나눠야 합니다.