Anthropic의 AI 애플리케이션 엔지니어가 공유하는 프롬프트 엔지니어링 실전 사례

Margot Van Laar는 Anthropic의 AI 애플리케이션 팀 엔지니어입니다.

그녀는 Code with Claude 컨퍼런스에서 프롬프트 엔지니어링 (Prompt Engineering) 실전에 관한 발표를 진행했습니다.

핵심 관점은 단 하나입니다: 우리는 프롬프트를 처음부터 쓰는 경우가 드물며, 대부분의 시간은 이미 운영 중인 프로덕션 프롬프트를 디버깅하고 유지보수하는 데 사용한다는 것입니다.

그녀는 두 가지 실제 시나리오를 통해 이 점을 보여주었습니다.

첫 번째 시나리오는 고객 서비스 로봇의 유지보수입니다.

팀은 이미 실행 중인 프롬프트를 인계받았는데, 첫 번째 단계는 내용을 수정하는 것이 아니라 구조화된 정리(Structured Cleaning)를 하는 것이었습니다. 즉, XML 태그를 사용하여 역할(Role), 정책(Policy), 어조(Tone), 가이드라인(Guideline)을 분리하고, 불필요한 패치를 제거하며, 출력 형식을 명확히 하는 작업입니다.

그 후 그녀는 전형적인 함정을 발견했습니다.

팀은 이전에 구형 모델을 위해 특정 정보를 제공하지 말라는 "금지 목록" 지침을 추가했었습니다.

새로운 모델로 교체한 후, 이 지침은 모델의 과적합 (Overfitting)을 유발했습니다. 모델이 실제로 제공할 수 있는 정보까지 숨기기 시작한 것입니다.

구형 모델에는 능력이 부족하여 이 지침이 필요했지만, 신형 모델에는 필요하지 않음에도 지침이 남아 있었던 것입니다.

또 다른 발견은 모델이 정밀한 계산을 수행해야 할 때, 프롬프트에 "주의 깊게 계산해 주세요"라고 적는 것은 소용이 없다는 점이었습니다.

모델에게 도구 (Tool)를 주어야 합니다. 모델이 머릿속으로 계산하게 하는 것보다 계산기를 호출하게 하는 것이 훨씬 더 신뢰할 수 있습니다.

상담원 연결 결정 또한 함정입니다. 만약 프롬프트가 모델에게 "사용자가 불만을 느끼면 상담원에게 연결하라"고만 지시한다면, 모델은 이 측면을 과도하게 최적화하여 모든 대화를 상담원에게 넘겨버릴 것입니다.

올바른 방법은 비용과 이익의 양면을 모두 명확히 설명하는 것입니다. 상담원 연결의 비용은 무엇인지, 연결하지 않았을 때의 리스크는 무엇인지 설명하여 모델이 스스로 균형을 맞추게 해야 합니다.

두 번째 시나리오는 소매업 스케줄링 에이전트 (Agent)를 처음부터 구축하는 것입니다.

팀의 초기 방안은 모든 로직을 하나의 복잡한 프롬프트에 집어넣는 것이었습니다. 결과는 빈번한 실패였습니다.

더 나은 방식은 세 개의 간단한 프롬프트로 나누어 생성-평가-수정 (Generate-Evaluate-Fix) 루프를 구성하는 것입니다.

첫 번째는 스케줄링 안을 생성하고, 두 번째는 안이 규정에 부합하는지 평가하며, 세 번째는 문제를 수정하는 역할을 담당합니다.

각 프롬프트가 한 가지 일만 수행하게 하면, 하나의 거대한 프롬프트를 사용하는 것보다 조합했을 때 훨씬 더 안정적입니다.

그녀는 모델 선택에 대해서도 언급했습니다.

팀의 테스트 결과, 더 강력한 추론 모델 (Opus)에 적응형 사고 (Adaptive Thinking)를 결합하는 것이 소형 모델에 복잡한 프롬프트를 사용하는 것보다 효과적인 경우가 많았습니다. 모든 시나리오에서 비용 최적화가 필요한 것은 아니며, 때로는 더 나은 모델을 사용하는 것이 오히려 가장 간편한 해결책이 될 수 있습니다.

그녀는 한 문장을 반복해서 강조했습니다: 평가 (Evaluation)는 변경 사항이 실제로 효과가 있는지 알려주는 유일하고 엄격한 방법입니다.

평가가 없다면, 그것은 그저 운에 맡기는 것과 같습니다.

이 말은 AI 애플리케이션을 만드는 모든 사람에게 적용됩니다.

대부분의 사람들은 "이렇게 쓰는 게 더 나을 것 같다"는 느낌으로 프롬프트를 수정하고 바로 배포하여 결과를 확인합니다. 하지만 "느낌"은 평가가 아닙니다.

정량화 가능한 기준 (Benchmark)이 필요하며, 변경할 때마다 이를 실행해 보아야만 결과가 좋아졌는지 나빠졌는지를 확신할 수 있습니다.
[IMG:1]