Anthropic 응용 AI 팀의 Hannah와 Christian이 프롬프트 엔지니어링의 기본기를 실제 사례 하나로 보여 주는 발표다. Hannah는 프롬프트 엔지니어링을 모델에게 명확한 지시와 작업에 필요한 맥락을 주고, 그 정보를 어떤 순서로 배치해야 가장 좋은 결과가 나오는지 고민하는 일로 정의한다. 그리고 이것을 배우는 가장 좋은 방법은 직접 해 보는 것이라며, 실제 고객 사례를 변형한 시나리오에서 프롬프트를 한 단계씩 함께 작성해 간다.
시나리오는 스웨덴의 자동차 보험사에서 사고 청구를 처리하는 상황이다. Claude는 스웨덴어로 작성된 사고 신고서와 사람이 손으로 그린 사고 스케치를 받아, 무슨 일이 있었고 누구에게 과실이 있는지 판단해야 한다. Hannah는 자신은 이 언어를 모르지만 Christian과 Claude는 안다고 말한다.
발표가 답하려는 질문은 프롬프트의 어떤 요소가 Claude의 판단을 실제로 바꾸는가이다. 두 사람은 Anthropic 콘솔에서 프롬프트를 버전별로 고쳐 가며 결과를 비교한다. 첫 버전에서 Claude는 이 사고를 스키 사고로 읽었지만, 마지막 버전에서는 B 차량에 과실이 있다는 판정을 정해진 XML 태그에 담아 내놓는다. 그 사이에 작업 맥락, 변하지 않는 배경 정보, 분석 순서, 출력 형식이 각각 무엇을 바꾸었는지가 발표의 내용이다.
맥락 없는 프롬프트를 받은 Claude는 상황을 추측할 수밖에 없다
Christian이 설명하는 입력은 두 가지다. 하나는 사고 직전에 무슨 일이 있었는지 체크박스로 표시하는 자동차 사고 신고서이고, 다른 하나는 사고 경위를 사람이 직접 그린 스케치다. 그는 우선 이 두 이미지를 콘솔에 그대로 넣고 어떤 결과가 나오는지 확인한다.
Christian은 temperature를 0으로 두고 최대 토큰 예산을 넉넉하게 잡아, Claude가 출력하는 데 제약이 없게 했다. 프롬프트는 사고 신고서를 검토해 무슨 일이 있었고 누구 과실인지 판단하라는 내용이 전부였다. 그러자 Claude는 이것을 Köpmangatan이라는 거리에서 일어난 스키 사고로 해석했다. Christian은 이 거리 이름이 스웨덴에서 아주 흔하다고 덧붙인다.
Christian은 이 실수를 충분히 이해할 만하다고 본다. 프롬프트에서 지금 어떤 상황인지 전혀 알려 주지 않았기 때문이다. 그는 여기서 프롬프트 엔지니어링이 반복적이고 경험적인 과학이라고 강조한다. 예를 들어 Claude가 이 상황을 스키가 아니라 차량 사고로 이해하는지 확인하는 테스트 케이스를 두고, 결과를 보며 프롬프트를 고쳐 나가는 식이다. 첫 결과도 아주 나쁘지는 않았지만, 사람이 가진 직관을 프롬프트에 반영할 여지가 아직 많이 남아 있었다.
API로 처리하는 작업은 메시지 한 번에 끝나도록 프롬프트를 구성하는 순서를 정해 둔다
Hannah는 이 작업을 챗봇과 대화하듯 주고받는 방식과 구분한다. 이런 작업은 대개 API로 처리하기 때문에, 개발자는 메시지 하나만 보내면 Claude가 추가로 대화를 주고받지 않고 첫 시도에 작업을 끝내기를 바란다.
그래서 Anthropic이 권하는 구조는 작업 설명으로 시작한다. Claude가 어떤 목적으로 쓰이는지, 어떤 역할을 맡았는지, 오늘 어떤 작업을 해내야 하는지 알려 준다. 다음은 콘텐츠다. 이 사례에서는 신고서와 스케치 이미지가 여기에 해당하며, 사용 사례에 따라서는 다른 시스템에서 가져온 동적 데이터일 수도 있다. 그다음에는 Claude가 작업을 어떤 단계로 진행하고 어떻게 추론할지 적은 상세한 지시를 준다. 필요하면 이런 콘텐츠를 받았을 때 이렇게 답하라는 예시를 넣는다. 마지막에는 이 작업에서 정말 중요한 내용을 다시 한번 강조한 다음, 이제 작업을 시작하라고 말한다.
Hannah는 이 구조를 10개 항목으로 더 세분한 슬라이드도 보여 준다. 발표의 나머지 부분은 이 항목들을 하나씩 콘솔에서 프롬프트에 추가해 가는 과정이다.
작업 맥락과 어조를 밝히면 Claude는 상황을 바로 읽고 확신 없는 판정을 삼간다
Christian은 첫 데모에서 Claude가 어떤 상황에서 일하는지 거의 설명하지 않았기 때문에, 사용자가 원하는 바를 Claude가 추측해야 했다고 짚는다. 그래서 두 번째 버전에서는 작업 맥락을 풀어 쓰고 어조에 관한 지침을 더한다. 어조의 핵심은 사실에 근거하고 확신 있게 말하는 것이다. Claude가 무엇을 보고 있는지 이해하지 못한다면 추측으로 사람을 오도해서는 안 되며, 누구 과실인지는 가능한 한 명확하게, 확신을 갖고 판단해야 한다.
두 번째 버전을 실행하기 전에 Christian은 데이터를 자세히 보여 준다. 신고서는 17개의 체크박스로 사고 경위를 기록하는 양식이고, 왼쪽과 오른쪽에 A 차량과 B 차량의 칸이 있다. 스케치는 같은 사고를 다른 방식으로 담은 또 하나의 데이터다. 사람이 직접 작성한 이 데이터를 Claude가 이해하고 실제 상황을 판단하게 하는 것이 목표다.
두 번째 버전의 프롬프트는 이 AI 어시스턴트가 스웨덴어로 된 자동차 사고 신고서를 검토하는 손해사정사를 돕는다고 명시한다. 스케치는 사람이 손으로 그린 것이라는 점과, 완전히 확신하지 못하면 판정을 내리지 말라는 점도 적었다.
같은 설정으로 실행하자 Claude는 이제 스키가 아니라 자동차 사고라는 점을 알아차렸다. A 차량은 1번 체크박스, B 차량은 12번 체크박스에 표시되었다는 것도 읽어 냈다. 그러나 누구 과실인지 확신 있게 판정하기에는 정보가 부족하다고 답했다. Christian은 이것을 좋은 결과로 본다. 사실이 아닌 주장은 하지 말고 확신할 때만 판단하라는 지시를 그대로 따랐기 때문이다. 다만 신고서가 무엇을 담고 있는지에 대한 정보가 여전히 빠져 있었고, 그는 그 정보를 보충하려면 시스템 프롬프트에 넣는 것이 가장 좋다고 말한다.
매번 같은 배경 정보는 시스템 프롬프트에 넣어 Claude가 양식을 미리 알게 한다
Hannah는 프롬프트를 작성하는 사람이 신고서 양식에 대해 이미 많은 것을 알고 있다는 점에 주목한다. 양식을 채우는 내용은 매번 달라지지만 양식 자체는 절대 바뀌지 않는다. 이런 정보는 시스템 프롬프트에 넣기 좋고, 항상 같으므로 프롬프트 캐싱을 고려한다면 캐싱하기에도 좋다. 양식의 구조를 미리 알려 주면 Claude는 양식을 볼 때마다 그것이 무엇인지 파악하느라 시간을 쓰지 않으며, 양식에 어떤 내용이 나올지 미리 알기 때문에 양식을 더 잘 읽어 낸다.
세 번째 버전에서는 사용자 프롬프트를 그대로 두고 시스템 프롬프트에 양식 정보를 넣었다. Hannah는 다른 방식도 시도해 볼 수 있지만 여기서는 시스템 프롬프트를 택했다고 말한다. 이 문서가 스웨덴 자동차 사고 신고서이고 스웨덴어로 작성되며, 어떤 제목이 붙고, 두 열이 각각 다른 차량을 나타낸다는 것을 알려 준다. 17개 행이 각각 무슨 뜻인지도 설명한다. 이전 실행에서 Claude가 각 줄을 하나씩 읽으며 의미를 파악하던 일을 미리 해 둔 것이다.
양식을 어떻게 채우는지도 알려 준다. 사람이 채우는 양식이므로 완벽하지 않다. 박스에 X 표시를 하지 않고 동그라미를 치거나 낙서하듯 표시할 수도 있으므로, 여러 종류의 표시를 찾아봐야 한다. 이 양식의 목적과 의미를 어떻게 해석해야 하는지도 함께 적었다.
결과는 달라졌다. Claude는 양식이 무엇인지 이미 알기 때문에 그것을 설명하는 데 말을 덜 쓰고, 체크된 항목과 스케치 내용을 목록으로 정리했다. 그리고 이번에는 정리한 목록과 스케치를 근거로 B 차량에 과실이 있다고 말할 만큼 확신을 갖게 되었다. Hannah는 그림과 목록을 보면 누구나 B 차량의 과실이라는 데 동의할 것이라고 말한다.
XML 태그로 정보를 감싸면 Claude가 그 정보의 성격을 알고 다시 참조할 수 있다
Hannah는 Claude가 구조화되고 잘 정리된 정보를 아주 좋아한다고 말한다. 프롬프트에서 표준적인 구조를 따르라고 권하는 이유도 이것이다. 정보를 더 잘 이해하도록 돕는 도구로는 구분자도 있다. 마크다운도 Claude에게 꽤 유용하지만, XML 태그는 그 안에 무엇이 들어 있는지 명시할 수 있다는 장점이 있다. 예를 들어 사용자 선호를 XML 태그로 감싸 두면, Claude는 태그 안의 내용이 모두 사용자 선호와 관련된다는 것을 알고 프롬프트 뒷부분에서 그 정보를 다시 참조할 수 있다.
Christian도 예시를 설명하면서 XML 태그가 Claude에게 명확한 구조를 제공하며, Claude를 파인튜닝할 때 사용한 형식이기도 하다고 말한다. Hannah는 이 내용이 모두 Anthropic 문서에 예시와 함께 정리되어 있다고 덧붙인다.
사람이 판단한 어려운 사례를 예시로 넣으면 Claude의 판단을 효과적으로 유도할 수 있다
Christian은 예시, 즉 퓨샷이 Claude를 조종하는 강력한 수단이라고 말한다. Claude가 맞히기 어렵지만 사람의 직관과 사람이 붙인 레이블로는 올바른 결론에 이를 수 있는 실제 사고 사례가 있다면, 그 데이터와 판단을 명확한 예시로 시스템 프롬프트에 넣을 수 있다. 이미지를 base64로 인코딩해 예시 데이터에 포함하고, 그 사례를 어떻게 분해하고 이해해야 하는지 설명을 붙이는 식이다.
그는 이것을 프롬프트 엔지니어링의 경험적 성격과 연결한다. 애플리케이션이 어디서 틀리는지 피드백을 받아 그 사례를 시스템 프롬프트에 추가하면, 다음에 비슷한 사례가 들어왔을 때 Claude가 예시 모음에서 참조할 수 있다. 이번 데모는 단순해서 예시를 넣지 않았지만, 실제 보험사가 쓸 애플리케이션을 만든다면 판단이 애매한 어려운 예시를 수십 개, 많게는 수백 개 넣게 될 것이라고 그는 말한다.
대화 기록도 같은 맥락에서 활용할 수 있다. 이 사례는 사용자를 직접 상대하는 애플리케이션이 아니다. 백그라운드에서 자동으로 데이터를 만들고 마지막에 사람이 검토하는 시스템이므로 대화 기록을 넣지 않았다. 반면 긴 대화 기록이 의미 있는 사용자 대면 애플리케이션이라면, 대화 기록은 Claude가 일하는 맥락을 풍부하게 해 주므로 시스템 프롬프트에 넣기 좋은 정보다.
마지막에 작업과 지침을 다시 일러 주면 Claude가 없는 내용을 지어내지 않는다
Hannah는 프롬프트의 마지막 부분을 당장 해야 할 작업과 따라야 할 중요한 지침을 상기시키는 데 쓴다. 그 이유 중 하나는 환각을 막는 것이다. 어떤 박스가 체크되었는지 알 수 없을 때 Claude가 짐작으로 답하거나, 체크되지 않은 박스를 체크되었다고 지어내서는 안 된다. 스케치를 너무 엉망으로 그려 사람도 알아볼 수 없다면 Claude도 그렇다고 말할 수 있어야 한다.
그래서 마지막 단계에서는 아주 확신할 때만 답하라고 일러 둔다. 사실을 주장할 때마다 양식에서 본 근거를 대라고 요구할 수도 있다. 예를 들어 B 차량이 우회전했다고 말하려면, 2번 박스에 분명히 체크되어 있으므로 그렇게 판단한다고 근거를 덧붙이게 하는 식이다.
신고서를 먼저 읽고 스케치를 나중에 보게 하는 분석 순서가 판정을 좌우한다
네 번째 버전에서는 시스템 프롬프트에 넣은 배경 정보와 역할, 맥락을 모두 그대로 두고, Claude가 분석을 진행할 상세한 작업 목록만 추가했다. Hannah는 이 데모와 고객 사례를 만들면서 Claude가 정보를 분석하는 순서가 매우 중요하다는 것을 발견했다고 말한다.
Hannah는 사람이 이 일을 한다고 생각해 보라고 한다. 사람이라면 그림부터 보지는 않을 것이다. 스케치는 상자와 선 몇 개에 불과해서 다른 맥락 없이는 무엇을 뜻하는지 알기 어렵다. 반면 신고서를 먼저 읽고 이것이 자동차 사고이며 각 차량이 어떤 행동을 했는지 체크박스로 파악하고 나면, 그림을 어떻게 읽어야 할지 더 잘 알게 된다.
그래서 프롬프트는 먼저 양식을 아주 주의 깊게 살펴 어떤 박스가 체크되었는지 빠짐없이 확인하고, 본 것을 목록으로 정리하라고 지시한다. 양식에서 사실을 확신 있게 뽑아낸 뒤에야 스케치로 넘어가서, 지금까지 이해한 사고 경위와 스케치를 맞춰 보며 최종 판단에 이르게 한다.
실행 결과에서 Hannah는 새 지시 때문에 나타난 동작 하나를 짚는다. 양식을 아주 꼼꼼히 살피라고 했더니, Claude가 박스 하나하나의 체크 여부를 모두 보여 주며 작업 과정을 드러냈다. 이전 버전에서는 양식에서 본 것을 얼마나 이야기할지 Claude가 정하게 두었기 때문에 나타나지 않던 동작이다. Hannah는 이것이 최종적으로 원하는 모습이 아닐 수 있으므로 바꿀 수도 있다고 말한다. 요청한 대로 양식 분석, 지금까지의 사고 요약, 스케치 분석이 XML 태그에 담겨 나왔고, 판정은 여전히 B 차량의 명백한 과실이었다.
Hannah는 이 예시가 꽤 단순한 편이라고 인정한다. 다만 그림이 더 복잡하고 양식이 덜 명확한 사례라면, 이런 단계적 사고가 Claude가 정확하게 판단하는 데 큰 영향을 미친다고 말한다.
출력 형식을 지정하거나 응답 첫머리를 채워 두면 애플리케이션이 쓸 결과만 받아 낼 수 있다
Christian은 데이터 엔지니어의 관점에서 출력을 바라본다. 화려한 서두도 좋지만, 결국 필요한 것은 SQL 데이터베이스처럼 데이터를 저장할 곳에 넣을 핵심 정보다. Claude가 판정에 이르는 데 필요한 나머지 내용은 애플리케이션에는 그다지 필요하지 않다.
다섯 번째 버전에는 중요 지침 부분을 간단히 추가했다. 요약은 명확하고 간결하고 정확해야 하며, 분석 대상인 데이터 외에는 어떤 것도 Claude의 판단에 끼어들지 않아야 한다는 내용이다. 그리고 출력 형식으로는 최종 판정을 final verdict XML 태그로 감싸라고 요구했다. Christian은 애플리케이션이 나머지 출력은 모두 무시하고 이 태그만 읽으면, 나중에 분석 도구를 만들거나 명확한 판정만 뽑아 쓸 수 있다고 말한다. 실행하자 Claude는 같은 과정을 거치면서도 결과를 훨씬 간결하게 요약했고, 마지막에 판정을 final verdict 태그로 감쌌다.
Christian은 데모 전체를 이렇게 돌아본다. 데모는 스키 사고로 잘못 읽은 첫 버전에서 시작해, 자동차 사고임은 알지만 확신이 없던 두 번째 버전을 거쳐, 이제는 실제 자동차 보험사를 돕는 애플리케이션을 바로 구축할 수 있을 만큼 형식이 엄격하고 확신 있는 출력에 이르렀다.
그는 출력을 다듬는 또 하나의 방법으로 응답 미리 채우기를 소개한다. Claude의 입에 말을 넣어 준다고도 부르는 기법이다. XML 태그를 파싱하는 것도 좋지만, 다음 호출에서 쓰려면 JSON으로 직렬화할 수 있는 구조화된 출력이 필요할 수 있다. 방법은 간단하다. Claude의 출력이 특정 형식으로 시작하도록 응답 앞부분을 미리 넣어 두면 된다. JSON이라면 여는 대괄호나 중괄호를, 슬라이드의 예처럼 여행 일정이라면 itinerary XML 태그를, 이 사례라면 final verdict 태그를 넣을 수 있다.
다만 서두를 없애는 데에는 대가가 따른다. Christian은 서두도 Claude가 의도한 단계대로 추론하게 만드는 데 중요하다고 짚는다. 이 사례에서는 판정을 final verdict 태그로 감싼 뒤 파싱하는 방식을 택했지만, 미리 채우기도 쓸 수 있다고 그는 말한다.
확장 사고 기록은 시스템 프롬프트를 개선할 단서가 된다
Christian은 마지막으로 Claude 3.7과 특히 Claude 4가 하이브리드 추론 모델이어서 확장 사고를 쓸 수 있다는 점을 강조한다. 그는 확장 사고를 프롬프트 엔지니어링의 보조 수단으로 쓸 수 있다고 말한다. 확장 사고를 켜면 Claude는 thinking 태그와 스크래치패드에서 생각할 시간을 갖게 되고, 그 기록을 분석하면 Claude가 데이터를 어떻게 다루는지 이해할 수 있다.
예를 들어 이 데모에서 Claude는 체크박스를 하나씩 확인하며 사고 경위를 단계별로 짚었다. 확장 사고 기록에서 이런 과정을 발견하면, 그 과정을 시스템 프롬프트 자체에 넣어 Claude를 도울 수 있다. Christian은 이 방법이 토큰 측면에서 더 효율적일 뿐 아니라, 우리와 같은 직관이 없는 지능형 모델이 주어진 데이터를 실제로 어떻게 다루는지 이해하는 데에도 좋다고 말한다. 그래서 확장 사고 기록은 시스템 프롬프트를 어떻게 개선할지 분석하는 데 핵심적인 역할을 한다는 것이다.
발표는 시간 관계상 Q&A 없이 끝났고, 몇 가지는 확인되지 않은 채 남았다. 예시와 대화 기록, 응답 미리 채우기, 확장 사고는 설명만 했을 뿐 이 데모에 적용해 결과를 보여 주지 않았다. 또한 데모의 사고는 누구나 B 차량의 과실이라고 동의할 만큼 단순한 사례였기 때문에, 판단이 애매한 사례에서 같은 프롬프트가 얼마나 잘 작동하는지는 확인할 수 없었다.