CPN 한국어 자습서 · 러닝패스 2 / 4 — Building with the Claude API
프롬프트 엔지니어링
Structure with XML tags
프롬프트에 많은 내용을 끼워 넣으면 Claude가 어디가 무엇인지 헷갈릴 수 있습니다. 서로 다른 부분을 XML 태그로 감싸면 구조가 또렷해집니다. 이 기법을 운동선수 식단 프롬프트에 적용해 점수가 오르는 것을 확인합니다.
Stephen Grider · Anthropic 기술 스태프
이번에 살펴볼 주제는 프롬프트에 XML 태그로 구조를 부여하는 아이디어입니다. 약간의 배경부터 설명하겠습니다.
프롬프트를 쓸 때 우리는 거의 항상 어느 정도의 내용을 그 안에 끼워 넣습니다. 지금까지도 그렇게 해 왔습니다. 예시 안에서 키·몸무게·목표·제한을 끼워 넣어 왔죠. 이 값들은 꽤 짧지만, 언젠가는 아주 많은 내용을 프롬프트에 넣어야 하는 경우가 생길 수 있습니다. 예를 들어 오른쪽 프롬프트처럼, 20페이지 분량의 판매 기록을 붙여 넣고 Claude에게 분석을 시킬 수도 있습니다.
많은 내용을 프롬프트에 쏟아부으면, Claude가 어떤 텍스트가 정확히 무엇을 뜻하는지, 또는 텍스트가 어떻게 묶이는지 파악하기가 다소 어려워질 수 있습니다. 이때 프롬프트의 구조를 좀 더 분명히 하는 한 가지 방법이 서로 다른 조각을 XML 태그로 감싸는 것입니다.
예를 들어 오른쪽 프롬프트의 판매 기록을 <sales_records> 태그로 감싸 구조를 더해 줄 수 있습니다. 그런데 sales_records라는 공식 XML 태그가 따로 있는 건 아닙니다. 이건 제가 그냥 지어낸 태그 이름으로, 그 안에 든 내용의 성격을 Claude에게 어느 정도 알려 주는 역할입니다. 똑같이 records나 data라고 불러도 됐겠지만, 조금 더 구체적인 편이 분명히 낫습니다. 그래서 sales_records 같은 태그가 가장 좋은 출력을 줄 가능성이 높습니다.
왜 이런 XML 태그가 필요한지 정말 분명히 하고 싶어, 살짝 과장된 예를 보여 드리겠습니다. 왼쪽 프롬프트에는 “아래 코드를 제공된 문서를 사용해 디버그하라”는 머리글 한 줄이 있습니다. 이건 두 가지를 암시합니다 — 그 아래에 제가 쓴 버그 있는 코드가 어느 정도 있고, 문서도 어느 정도 있다는 것이죠. 그런데 여기 나열된 코드만 봐서는 어디까지가 코드이고 어디부터가 실제 문서인지 전혀 분명하지 않습니다.
Claude에게 이를 분명히 해 주는 한 가지 방법은 각 코드 덩어리를 알맞은 XML 태그로 감싸는 것입니다. 오른쪽처럼 제 코드는 아주 직접적이고 분명하게 <my_code> 태그로 감싸고, 문서에 해당하는 코드는 <docs> 태그로 감싸는 거죠. 이제 Claude는 어떤 코드를 디버그해야 하고 어떤 코드가 문서인지 훨씬 쉽게 이해합니다.
이 “XML 태그로 구조 부여” 아이디어를 가져와, 노트북에서 작업 중인 프롬프트를 개선해 봅시다. 다만 이 경우엔 굳이 구분해야 할 큰 내용 덩어리가 없습니다. 키·몸무게·목표·제한 같은 끼워 넣은 값은 충분히 짧아서 Claude가 헷갈릴 일은 없습니다. 그래도 XML 태그를 써서, 이것이 외부 입력이라는 것 — 또는 식단을 만들 때 고려할 선수에 대한 정보라는 것 — 을 분명히 할 수 있습니다.
그래서 이 블록 전체를, 선수 정보임을 분명히 하는 <athlete_information> 여는 태그와 닫는 태그로 감싸기로 합니다. 이제 이게 출력 품질에 어떤 영향을 주는지 측정해 봅시다. 셀을 다시 실행하고 평가 셀로 내려가 실행합니다. 기억하실 텐데, XML 태그를 넣기 전 점수는 7.3이었습니다. 올라갈지 내려갈지 봅시다 — 저는 꽤 많이 올랐습니다.
다만 이렇게 큰 향상은 보통 보기 어렵습니다. 다시 말씀드리지만, 저는 개선 효과를 과장해서 보여 주려고 좀 더 단순하고 기본적인 모델을 쓰고 있습니다. 그러니 이만큼 큰 도약이 보이지 않더라도 전혀 문제없습니다.
이 장에서 배우는 것What you'll learn
약 7분내용을 많이 넣을수록 Claude가 어디가 무엇인지 헷갈릴 수 있다
서로 다른 조각을 XML 태그로 감싸 구조를 또렷이 한다
태그 이름은 <sales_records>처럼 구체적일수록 좋다 (지어내도 됨)
과장된 예: <my_code> vs <docs>로 코드와 문서를 구분
우리 프롬프트엔 입력 블록을 <athlete_information>로 감싼다
같은 평가로 재측정 — 7.3 → 7.94로 점수 상승
<이름>…</이름>처럼 내용 조각을 감싸 구분하는 표식. 공식 규격이 아니라 직접 지어내도 된다.프롬프트에는 거의 항상 어떤 내용을 끼워 넣게 됩니다. 키·몸무게처럼 짧을 때도 있지만, 때로는 20페이지짜리 판매 기록을 통째로 붙여 넣기도 합니다. 내용이 많아질수록 Claude는 어디가 무엇인지 헷갈리기 쉽습니다. 서로 다른 조각을 <태그>로 감싸면 구조가 또렷해집니다.
Write a one page decision report to troubleshoot why a sales team's numbers have dropped 30% last quarter. Here are the last 20 pages of our sales records: <sales_records> ...20 페이지 분량의 판매 기록... </sales_records> Follow these steps: 1. Compare current vs previous market metrics 2. Identify relevant industry changes ...
sales_records라는 공식 XML 태그가 있는 건 아닙니다. 직접 지어낸 이름으로, 안에 든 내용의 성격을 Claude에게 알려 주는 역할입니다. records나 data도 되지만, 구체적일수록 더 좋은 출력을 얻습니다.
왜 태그가 필요한지 분명히 보려고 살짝 과장된 예를 봅니다. “아래 코드를 제공된 문서로 디버그하라”고만 하면, 어디까지가 내 코드이고 어디부터가 문서인지 전혀 분명하지 않습니다.
# Not Great — 어디까지가 코드이고 어디부터가 문서인지 불분명 Debug my code below using the provided documentation. from datavortex import Pipeline, DataSource def process_data(input_file, output_file): pipeline = Pipeline() source = DataSource.from_csv(input_file) # Creating a data source from data vortex csv_source = DataSource.from_csv("data.csv")
각 덩어리를 <my_code>와 <docs>로 감싸면, 디버그할 코드와 참고 문서가 또렷이 갈립니다.
# Better! — 태그로 코드와 문서를 또렷이 구분 Debug my code below using the provided documentation. <my_code> from datavortex import Pipeline, DataSource def process_data(input_file, output_file): pipeline = Pipeline() source = DataSource.from_csv(input_file) </my_code> <docs> # Creating a data source from data vortex csv_source = DataSource.from_csv("data.csv") </docs>
우리 프롬프트엔 구분해야 할 큰 덩어리는 없지만, 입력 블록을 <athlete_information>로 감싸 “이건 선수에 대한 입력”임을 또렷이 할 수 있습니다. 아래에서 전/후를 토글해 보세요.
athlete_information 태그 하나로 “이건 선수에 대한 입력”이라는 경계가 또렷해집니다. 같은 평가 파이프라인에서 7.3 → 7.94. (점수 크기는 모델에 따라 다릅니다 — 핵심은 구조가 또렷해진다는 점입니다.)
노트북의 run_prompt에서는 입력 블록을 다음과 같이 감쌉니다(Guidelines는 이전 레슨에서 추가한 것).
def run_prompt(prompt_inputs): prompt = f""" Generate a one-day meal plan for an athlete that meets their dietary restrictions. <athlete_information> - Height: {prompt_inputs["height"]} - Weight: {prompt_inputs["weight"]} - Goal: {prompt_inputs["goal"]} - Dietary restrictions: {prompt_inputs["restrictions"]} </athlete_information> Guidelines: 1. Include accurate daily calorie amount 2. Show protein, fat, and carb amounts 3. Specify when to eat each meal 4. Use only foods that fit restrictions 5. List all portion sizes in grams 6. Keep budget-friendly if mentioned """ # 프롬프트를 모델에 보내 output을 반환 return output
Average score: 7.94
# XML 태그 적용 후. 직전(7.3)보다 올랐습니다.XML 태그 전 7.3 → 후 7.94. 이렇게 큰 도약은 보통 보기 어렵습니다 — 강사는 개선을 과장해 보여 주려고 단순한 모델을 씁니다. 작게 올라도 괜찮습니다.
<태그>로 구분.sales_records > data).<my_code>, <docs>).<athlete_information>로 감싸 7.3 → 7.94.Q1XML 태그를 쓰는 가장 큰 이유는?
태그는 “어디까지가 무엇인지” 경계를 분명히 해 모델이 각 부분을 또렷이 이해하게 합니다.
Q2태그 이름은 어떻게 정하나요?
sales_records처럼 지어내도 되고, 구체적일수록 내용의 성격이 잘 전달돼 더 좋은 출력을 얻습니다.
Q3이 레슨에서 우리 프롬프트의 입력 블록을 감싼 태그는?
키·몸무게·목표·제한 블록을 <athlete_information>로 감싸 “선수에 대한 입력”임을 또렷이 했습니다.
태그로 구조를 또렷이 했으니, 이제 이상적인 출력 예시를 직접 보여 줄 차례입니다. → 예시 제공하기
전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 76개 레슨을 끝까지 읽을 수 있습니다.
이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.