모델을 업그레이드하기 전에 프롬프트를 먼저 반복 개선하세요

이 영상의 데모는 2026년 8월에 녹화되었습니다. Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5에서 실행되었습니다. 최신 모델에서는 결과가 다를 수 있습니다. 각 레슨의 데모는 별도의 평가 실행이므로 점수와 비용이 다른 레슨과 일치하지 않을 수 있습니다.

낮은 평가 점수는 모델이 너무 많은 사례를 틀렸다는 것을 알려주지만, 모델과 프롬프트 중 무엇이 원인인지는 알려주지 않습니다.

먼저 프롬프트를 확인하세요. 더 큰 모델로 전환하면 이후 보내는 모든 요청의 비용이 올라가기 때문입니다. 프롬프트를 변경하는 데는 몇 분밖에 걸리지 않으며, 변경 사항을 바로 테스트할 수 있습니다.

가상의 엔지니어링 컨설팅 회사인 Meridian은 매월 프로젝트 보고서에서 세 가지 필드, 즉 프로젝트 ID, 일정 상태, 최상위 리스크를 추출하는 프롬프트 하나를 사용합니다. 이 평가는 50개 사례로 구성된 테스트이며, 각 사례는 보고서와 예상 답변이 짝을 이룹니다.

Claude Sonnet 5와 Claude Opus 5는 50개를 모두 맞혔습니다. 세 모델 중 비용이 가장 적게 드는 Claude Haiku 4.5는 84%만 맞혀, Meridian이 모델을 사용하기 전에 요구하는 정확도 기준선인 90%에 미치지 못했습니다.

Meridian은 더 큰 모델에 더 많은 비용을 지불하기 전에 다섯 단계를 거칩니다:

1. 실패한 사례를 읽고 공통점을 찾습니다.
2. 근거 없는 답변에 대한 수정 방법을 선택합니다.
3. 프롬프트에 변경 사항을 반영합니다.
4. 세 모델 모두에서 50개 사례를 다시 실행합니다.
5. 모든 열을 확인한 후 업그레이드 여부를 결정합니다.

실패한 사례를 읽고 공통점 찾기

실패한 사례를 보고서 종류와 틀린 필드별로 정렬하세요. 점수는 실패 건수를 세지만 그 이유를 설명해주지는 않습니다. 무엇이 실패했는지 읽어보면 무엇이 잘못되었는지, 왜 잘못되었는지 알 수 있으며, 이를 통해 모델과 프롬프트 중 무엇을 탓해야 할지 알 수 있습니다.

Meridian의 50개 사례는 일반 보고서 30개, 여러 프로젝트를 다루는 보고서 10개, 리스크 섹션이 없는 리스크 누락 사례 10개로 구성됩니다. 표는 Meridian이 처음 사용했던 기존 프롬프트로 Haiku 4.5가 어떤 성과를 냈는지 보여줍니다.

기존 프롬프트를 사용한 Haiku 4.5는 50개 사례 중 8개를 실패했습니다.

여덟 번의 실패 중 다섯 건은 리스크 누락 사례이며, 모두 top_risk에서 발생했습니다. 각 사례는 null로 돌아와야 했지만, 모델은 매번 리스크를 지목하는 문장을 작성했습니다. r045 사례가 그중 하나입니다.

허가 문제는 일상적인 메모로만 언급되었고, 보고서 자체도 문제가 예상되지 않는다고 말하고 있지만, 모델은 이를 최상위 리스크로 선택했습니다.

기존 프롬프트의 top_risk 줄은 "or null"로 끝나, null을 허용하기는 했지만 언제 이를 적용해야 하는지는 모델에게 전혀 알려주지 않았습니다. 실패가 특정 보고서 종류와 특정 필드에 몰려 있을 때는 대개 공통된 원인이 있으며, 여기서는 프롬프트가 무언가를 빠뜨린 것입니다.

근거 없는 답변에 대한 수정 방법 선택하기

근거 없는 답변을 줄이는 다섯 가지 표준적인 방법 중에서 수정 방법을 선택하세요. 문서가 뒷받침하지 않는 답변인 근거 없는 답변은 할루시네이션이라고도 합니다. 아래의 처음 세 가지 방법은 할루시네이션을 줄이는 기본 단계입니다.

1. "모른다"라고 말할 수 있게 하세요. 문서에 답이 없을 때 무엇을 반환해야 하는지 모델에게 알려주세요. Meridian의 경우 이는 null입니다.
2. 답변하기 전에 인용하세요. 모델이 먼저 답변을 뒷받침하는 문장을 찾아내게 한 다음, 그 문장을 바탕으로 답변하게 하세요.
3. 문서를 다시 인용해 확인하세요. 모델이 답변한 후, 각 주장을 뒷받침하는 인용문을 찾게 하고 뒷받침할 수 없는 주장은 철회하게 하세요. 그러면 사람이 남아 있는 모든 주장을 확인할 수 있습니다.
4. 검증 단계를 추가하세요. 첫 번째 요청이 내놓은 답변을 확인하는 역할을 하는 두 번째 요청을 보내세요.
5. 외부 지식을 제한하세요. 모델이 오직 문서만을 바탕으로 답변하고, 학습 과정에서 익힌 내용은 배제하도록 지시하세요.

Meridian은 처음 두 가지 방법을 사용합니다. 첫 번째 방법은 1단계에서 발견한 공백을 정확히 메워주기 때문입니다. 두 번째 방법은 모든 답변이 보고서의 한 문장과 일치하도록 만듭니다. 두 방법 모두 Meridian이 이미 가지고 있는 프롬프트에 한두 줄만 추가하면 됩니다.

프롬프트에 변경 사항 반영하기

null이 올바른 답변이 되는 경우를 프롬프트에 명시하고, 답변에 앞서 인용문을 요청하세요. 아래 상자에는 두 가지 변경 사항이 모두 반영된 Meridian의 새 프롬프트가 들어 있습니다. 각 역할을 수행하는 줄을 찾아보세요. 주석에 무엇이 바뀌었는지 설명되어 있습니다.

r045 사례를 다시 살펴보겠습니다. 이제 모델은 리스크를 보여주는 문장을 가리켜야 하는데, 보고서 자체의 문장에는 그런 내용이 없습니다: "팀은 갱신과 관련해 어떠한 문제도 예상하지 않습니다." 보고서에 그런 문장이 없을 때, 새 프롬프트는 무엇을 반환해야 하는지 알려줍니다: <source>none</source>, 그 다음 null입니다.

여러분의 코드에도 새로운 역할이 하나 생깁니다. 이제 응답에서 인용문이 먼저 나오기 때문에, 전체 텍스트는 더 이상 유효한 JSON이 아니며 json.loads를 실행하면 실패합니다. 닫는 </source> 태그 뒤에 오는 부분만 파싱하세요.

answer = json.loads(text.split("</source>")[-1])

세 모델 모두에서 50개 사례 다시 실행하기

같은 50개 사례와 같은 세 모델을 유지한 채 새 프롬프트로 평가를 다시 실행하세요.

기존 프롬프트와 새 프롬프트를 사용했을 때 Haiku 4.5가 맞힌 사례의 비율입니다.

근거 없는 답변 다섯 건 중 단 한 건도 다시 나타나지 않았으며, 이제 Haiku 4.5는 정확도 기준선을 웃도는 점수를 기록합니다.

다음 표에서 실행 비용은 한 모델이 50개 사례를 모두 처리하는 데 드는 비용이며, 완료 작업당 비용은 이를 정답 수로 나눈 값입니다.

2026년 8월 표준 가격 기준으로, 90% 정확도 기준선에 대해 50개 사례 전체에서 새 프롬프트를 사용한 세 모델입니다. 현재 가격을 참조하세요.

이제 모든 모델이 기준선을 넘었으므로, 완료 작업당 비용을 기준으로 선택하면 Haiku 4.5가 가장 저렴합니다.

모든 열을 확인한 후 업그레이드 여부 결정하기

두 실행 결과에서 고치려던 열 하나만이 아니라 모든 열을 살펴보세요. 한 종류의 사례에 도움이 되는 변경이 다른 사례를 망칠 수 있으므로, 변경할 때마다 이를 확인하세요.

근거 없는 답변과, 정답이었다가 오답으로 바뀐 답변의 수를 세어보세요. Meridian은 정답을 하나도 잃지 않았습니다.

schedule_status에서 실패했던 세 건의 일반 사례는, 해당 필드 줄을 전혀 건드리지 않았음에도 이번에는 통과했습니다. 모델은 같은 사례에 대해 실행할 때마다 다른 답을 낼 수 있으므로, 점수를 신뢰하기 전에 모든 설정을 두 번 이상 실행하세요.

점수가 계속 변하는 동안에는 프롬프트 변경과 재실행을 계속하세요. 정확도 기준선에 미치지 못한 채 점수가 더 이상 움직이지 않는다면, 모델에 필요한 역량이 부족한 것이므로 이때가 업그레이드할 시점입니다.

핵심 요약

1. 먼저 실패한 사례를 보고서 종류와 틀린 필드별로 묶어서 읽어보세요.
2. 문서에 답이 없을 때 무엇을 반환할지 명시하고 인용문을 먼저 요청하여, 프롬프트가 놓친 부분을 수정하세요.
3. 같은 사례를 두 번 이상 다시 실행하여, 근거 없는 답변이 줄어들고 정답이 오답으로 바뀌지 않는지 확인하세요.
4. 프롬프트 변경이 더 이상 점수를 움직이지 않을 때만 더 큰 모델로 업그레이드하세요.