Claude와 작업할 때 좋은 프롬프트를 작성하는 것은 시작일 뿐입니다. 신뢰할 수 있는 AI 애플리케이션을 구축하려면 두 가지 핵심 개념을 이해해야 합니다: 프롬프트 엔지니어링과 프롬프트 평가입니다. 프롬프트 엔지니어링은 더 나은 프롬프트를 작성하는 기법을 제공하며, 프롬프트 평가는 그 프롬프트가 실제로 얼마나 잘 작동하는지 측정하는 데 도움을 줍니다.
프롬프트 엔지니어링 vs 프롬프트 평가
프롬프트 엔지니어링은 프롬프트를 작성하고 개선하기 위한 도구 모음입니다. 이는 Claude가 여러분이 요청하는 내용과 원하는 응답 방식을 정확히 이해하도록 돕는 모범 사례 모음입니다. 멀티샷 프롬프팅, XML 태그를 사용한 구조화 등 앞으로 살펴볼 다양한 접근 방식처럼, 프롬프트 작성의 기술이라고 생각하면 됩니다.
반면 프롬프트 평가는 측정에 관한 것입니다. 이는 프롬프트가 실제로 효과적인지에 대한 객관적인 지표를 제공하는 자동화된 테스트입니다. 프롬프트가 잘 작동하는지 추측하는 대신, 평가를 통해 다음을 할 수 있습니다:
- 예상 답변과 비교하여 테스트
- 동일한 프롬프트의 다른 버전 비교
- 오류에 대한 출력 검토
프롬프트 작성 후의 세 가지 경로
프롬프트를 작성한 후에는 일반적으로 다음에 무엇을 할지에 대해 세 가지 선택지에 직면합니다:
옵션 1: 프롬프트를 한 번 테스트하고 충분히 좋다고 판단합니다. 이는 사용자가 예상치 못한 입력을 제공할 때 프로덕션 환경에서 문제가 발생할 위험이 상당히 큽니다.
옵션 2: 프롬프트를 몇 번 테스트하고 한두 가지 예외 상황을 처리하도록 조정합니다. 옵션 1보다는 낫지만, 이 접근 방식도 여전히 취약합니다. 사용자는 여러분이 고려하지 못한 매우 예상치 못한 결과를 자주 만들어낼 것이기 때문입니다.
옵션 3: 프롬프트를 평가 파이프라인에 통과시켜 점수를 매긴 다음, 객관적인 데이터를 기반으로 프롬프트를 반복적으로 개선합니다. 이는 사전에 더 많은 작업과 비용이 필요하지만, 프롬프트의 신뢰성에 대해 훨씬 더 큰 확신을 줍니다.
대부분의 엔지니어가 테스트 함정에 빠지는 이유
옵션 1과 옵션 2는 저를 포함한 모든 엔지니어가 빠지는 함정입니다. 중요한 애플리케이션을 위해 프롬프트를 작성하고 충분히 철저하게 테스트하지 않는 것은 자연스러운 일입니다. 우리는 우리에게 명백해 보이는 입력으로 테스트하는 경향이 있지만, 실제 사용자는 여러분이 전혀 예상하지 못한 방식으로 프롬프트와 상호작용할 것입니다.
해결책은 옵션 3, 즉 체계적인 평가를 받아들이는 것입니다. 프롬프트를 적절한 평가 파이프라인에 통과시킴으로써, 다양한 시나리오에서 프롬프트가 얼마나 잘 작동하는지 알려주는 객관적인 점수를 얻을 수 있습니다. 이러한 데이터 기반 접근 방식을 통해 자신 있게 반복 개선하고 프로덕션에 도달하기 전에 문제를 포착할 수 있습니다.
평가를 먼저 이해하면 프롬프트 엔지니어링 기법을 적용하면서 개선 사항을 측정할 수 있는 기반을 갖추게 됩니다. 프롬프트 효과를 신뢰성 있게 측정할 수 있게 되면, 다양한 접근 방식을 실험하고 어떤 방식이 더 잘 작동하는지 확실하게 알 수 있습니다.