여러 사람이 협업하며 기여한 프롬프트가 있다고 상상해 보세요. 명확한 소유자가 없어요.

https://youtu.be/8S0-C75Yhuc?si=_xpr0Zt6LDNDXNRh

프롬프트에 ‘잘하라’고 써도 모델은 못 한다 (Anthropic)

Imagine that we have a prompt that multiple people have been collaborating on, contributing to. There’s no clear owner. It covers a lot of different areas like policy, like tone, processes. Um, we have some patches for kind of previous models that we’ve migrated to all mixed together. Um, it’s built up and it’s complex. And when we’re migrating to a new model, we’re finding that suddenly a lot of our test cases are no longer working as well as we expected. So what’s actually going on here? Well, in order to start unpacking that question, um we need a starting point. And that starting point is evaluations. We need evaluations to provide that rigor um to understand whether a change to our prompt is actually correlating to an improvement in its performance.
Korean:
여러 사람이 협업하며 기여한 프롬프트가 있다고 상상해 보세요. 명확한 소유자가 없어요. 정책, 톤, 프로세스 등 다양한 영역을 다루고 있습니다. 이전 모델용 패치들이 모두 섞여서 마이그레이션된 상태예요. 쌓이고 복잡해졌죠. 새로운 모델로 마이그레이션할 때, 갑자기 많은 테스트 케이스가 예상만큼 잘 작동하지 않는 걸 발견합니다. 여기서 실제로 무슨 일이 일어나고 있는 걸까요? 이 질문을 풀기 시작하려면 시작점이 필요합니다. 그 시작점은 평가(evaluations)입니다. 프롬프트 변경이 실제로 성능 향상과 상관관계가 있는지 이해하기 위한 엄격함(rigor)을 제공하는 평가가 필요합니다. 
English:
And we have different models which have different capabilities and different behaviors. And when you migrate to a different model, it could be that your system is no longer working as well for two reasons. First of all, if um the new model might be capable, but it’s behaving differently and therefore we can tune our prompting to fix that behavior. The second case is where actually the model that we’re changing to isn’t as capable and no amount of prompting is going to fix that. So we need to have an eval suite to act as a way of testing that regression so that we can apply our prompting best practices to that.
Korean:
그리고 서로 다른 능력과 행동을 가진 다양한 모델이 있습니다. 다른 모델로 마이그레이션할 때 시스템이 더 이상 잘 작동하지 않을 수 있는 두 가지 이유가 있을 수 있어요. 첫째, 새 모델이 능력이 있을 수 있지만 행동이 다르기 때문에 프롬프트를 조정하여 그 행동을 고칠 수 있습니다. 두 번째 경우는 실제로 변경하는 모델의 능력이 부족해서 어떤 프롬프팅으로도 고칠 수 없는 경우입니다. 그래서 그 회귀(regression)를 테스트하는 방법으로 eval suite가 필요하며, 이를 통해 프롬프팅 베스트 프랙티스를 적용할 수 있습니다.
English:
So, so as we mentioned when we look through this prompt, there’s a couple oddities here already. So, for example, first one is we’re telling the bot that it’s um a human, which just isn’t true, right? We can see as we scroll down, there’s clearly some information here that it’s been copied directly from a website. So, the key giveaway here is a reference to a hero image. Um there’s even some references to cookies um at the bottom. So, we need to remove a bit of redundant information.
Korean:
그래서, 이 프롬프트를 살펴보면 이미 몇 가지 이상한 점이 있습니다. 예를 들어 첫 번째로 봇에게 자신이 인간이라고 말하고 있는데, 그건 사실이 아니죠? 아래로 스크롤해 보면 웹사이트에서 직접 복사한 정보가 분명히 보입니다. 핵심 단서는 hero image에 대한 참조예요. 심지어 아래쪽에 cookies 참조도 있습니다. 그래서 약간의 중복 정보를 제거해야 합니다.
English:
When we look at the instructions here, they’re all grouped into one big paragraph. So, we’ve got some reasoning here. We’ve got instructions about the role um some critical instructions as well without a real way of unpacking um policy from guidelines from tone etc. So let me just I’ve preempted some changes we want to make to this prompt and this is just a diff view of some of those changes. So what we’ve done is first of all added some structure. So you can see that we’ve added XML tags here to define the role to separate general guidelines to separate policy to separate tone of voice um etc.
Korean:
여기 지시사항을 보면 모두 하나의 큰 단락으로 묶여 있어요. 여기에는 추론(reasoning)도 있고, 역할에 대한 지시, 중요한 지시사항도 있지만 정책과 가이드라인, 톤 등을 제대로 풀어서 분리할 방법이 없어요. 제가 이 프롬프트에 적용하고 싶은 변경 사항을 미리 준비했는데, 이는 그 변경들의 diff 뷰입니다. 먼저 구조를 추가했습니다. XML 태그를 추가하여 역할을 정의하고, 일반 가이드라인, 정책, tone of voice 등을 분리한 걸 볼 수 있습니다.
English:
So if we run that eval then on this new updated prompt, we should hopefully see an improvement in the output as is. So we can see just by clearing up the prompt, we’ve already improved the model’s performance on this prepaid scenario. There’s an interesting regression there in that fifth hotspot case and I don’t want to worry too much about that now. There’s going to be some natural level of variance in the different runs of the eval and we’ll come back to that case specifically to see if we can make the prompt consistently better in that area.
Korean:
그래서 이 새로 업데이트된 프롬프트로 eval을 실행하면 출력에 개선이 보일 겁니다. 프롬프트를 정리하는 것만으로도 prepaid 시나리오에서 모델 성능이 이미 개선된 걸 볼 수 있어요. 다섯 번째 hotspot 케이스에 흥미로운 회귀가 있지만 지금은 너무 신경 쓰지 않으려 해요. eval의 여러 실행에서 자연스러운 변동성이 있을 테니, 그 케이스로 돌아가서 프롬프트를 그 영역에서 일관되게 더 좋게 만들 수 있는지 보겠습니다.
English:
So what did we learn from this then? Um, simply clearing up the prompt with a better structure, with a better role description has improved the performance. And this is a best practice that you can return to at any stage of writing and maintaining your prompt, especially as your prompts get more detailed and more complex. A general rule of thumb that I like to follow is if you’re reading a prompt and you can’t tell guidelines from policy from data, most likely the model isn’t able to either.
Korean:
그럼 여기서 무엇을 배웠을까요? 더 나은 구조와 더 나은 역할 설명으로 프롬프트를 단순히 정리하는 것만으로도 성능이 향상되었습니다. 이는 프롬프트를 작성하고 유지하는 어떤 단계에서든 돌아갈 수 있는 베스트 프랙티스예요. 특히 프롬프트가 더 상세하고 복잡해질수록요. 제가 좋아하는 일반적인 규칙은, 프롬프트를 읽을 때 가이드라인과 정책, 데이터를 구분할 수 없다면 모델도 아마 구분하지 못할 가능성이 크다는 것입니다.
First of all, then the hotspot question. So the question is how much hotspot data is on my unlimited plan? What we expect the model to do is state directly the amount of hotspot data that the customer has. And the reason this is a slightly complex case is because the customer test case that we’re dealing with is on a legacy plan. So actually the current policy doesn’t apply to them. So if we see what’s going on in the actual test case here, the customer data which we’re feeding uh um to the prompt includes the amount of hotspot data that customer has. They have five gigabytes, right? But they also have a grandfathered plan. So what we’re seeing uh the model is actually telling the customer is the general um the unlimited plan includes 4 GB um but since you’re on a legacy plan you should go check this out yourself.
Korean:
먼저, hotspot 질문입니다. 질문은 내 unlimited plan에 hotspot 데이터가 얼마나 있느냐예요. 모델이 해야 할 일은 고객이 가진 hotspot 데이터 양을 직접 명시하는 것입니다. 이게 약간 복잡한 케이스인 이유는 우리가 다루는 고객 테스트 케이스가 legacy plan에 있기 때문입니다. 그래서 실제 현재 정책은 그들에게 적용되지 않아요. 실제 테스트 케이스에서 무슨 일이 일어나는지 보면, 프롬프트에 입력하는 고객 데이터에 고객이 가진 hotspot 데이터 양이 포함되어 있습니다. 5기가바이트예요, 맞죠? 하지만 grandfathered plan도 가지고 있어요. 그래서 모델이 고객에게 말하는 것은 일반 unlimited plan에는 4GB가 포함되지만, legacy plan이니 직접 확인해 보세요라는 내용입니다.
English:
So let’s have a look at the prompt then to see um why the model is deflecting this question to the customer account URL rather than actually giving the information itself. Now if we read this prompt originally it said we changed our plans recently and the policy doc shows the current plan data and customers on grandfather’s plan have different rates. Never give a customer the wrong plan details. instead point them to the URL. So it’s clear that this instruction, this latter one, never give customer the wrong information, is the instruction that the bot has been optimizing for. And you might recognize this as being very similar to a patch that you might have introduced in a previous model that you were using to avoid where the model was giving the customer the wrong information about that plan.
Korean:
그럼 프롬프트를 살펴보고 모델이 왜 정보를 직접 주지 않고 고객 계정 URL로 질문을 회피하는지 보죠. 원래 프롬프트를 읽어보면 최근 플랜을 변경했으며 정책 문서에 현재 플랜 데이터가 나와 있고, grandfathered plan 고객은 요금이 다르다고 되어 있어요. 고객에게 잘못된 플랜 세부 사항을 절대 주지 말고 대신 URL로 안내하라고요. 그래서 이 지시, 특히 후자의 ‘고객에게 잘못된 정보를 주지 말라’는 것이 봇이 최적화하고 있는 지시라는 게 분명합니다. 이전 모델에서 모델이 고객에게 그 플랜에 대해 잘못된 정보를 주는 것을 피하기 위해 도입했던 패치와 매우 비슷하다는 걸 알아차리실 수 있을 거예요.
English:
Now, as our models have evolved, they have gotten much better at instruction following. So, it’s likely that instructions like these have now become redundant and are actually being overfitted to. So, what we’re going to tell the model instead is give this balanced view uh um where it says, you know, customers on grandfather’s plan have different allowances, but it’s captured in the customer information that’s given and that is the accurate source of truth. So running the eval here we should hopefully be addressing uh um all of the test cases for the hotspot case. Now I am running this live so there could be some variability here but we see here that now clearly all of our test cases are are passing.
Korean:
이제 우리 모델들이 진화하면서 지시 따르기 능력이 훨씬 좋아졌습니다. 그래서 이런 지시사항들이 이제 중복이 되고 실제로 과적합(overfitted)되고 있을 가능성이 큽니다. 대신 모델에게 균형 잡힌 관점을 주려고 해요. grandfathered plan 고객은 허용량이 다르지만, 주어진 고객 정보에 그게 담겨 있고 그것이 정확한 진실의 근원이라고요. 여기서 eval을 실행하면 hotspot 케이스의 모든 테스트 케이스를 다루게 될 겁니다. 지금 라이브로 실행 중이라 약간의 변동성이 있을 수 있지만, 이제 모든 테스트 케이스가 분명히 통과하는 걸 볼 수 있습니다.
English:
So what did we learn from this? Well, we worry a lot about hallucinations or the invention of facts and numbers, but actually the opposite can also happen. The model can withhold information that it actually has access to. Now, we saw here that this is likely a result of a patch that we introduced for a previous model. And a best practice that we could follow here is actually using version control where wherever we are making defensive changes in the prompt, we are tracking the reason why we’ve introduced these. Sometimes they’re necessary, but in the future these kind of changes can produce unwanted effects so that we can backtrack on them.
Korean:
그럼 여기서 무엇을 배웠을까요? 우리는 hallucination이나 사실·숫자 발명에 대해 많이 걱정하지만, 실제로는 반대 현상도 일어날 수 있습니다. 모델이 실제로 접근 가능한 정보를 보류할 수 있어요. 여기서 본 것은 이전 모델용으로 도입한 패치의 결과일 가능성이 큽니다. 여기서 따를 수 있는 베스트 프랙티스는 버전 컨트롤을 사용하는 거예요. 프롬프트에 방어적 변경을 할 때마다 왜 도입했는지 추적하는 것입니다. 때로는 필요하지만, 미래에 이런 변경이 원치 않는 효과를 낼 수 있으니 되돌릴 수 있게요.
English:
The next failing test case then is this proration calculation where a customer asks what if I upgrade to the 30 gigabyte plan? What will my next bill be? And what we want the model to do is to perform some calculation and return exactly uh um what their next bill would be rather than giving some sort of vague output which is what we can see it’s doing right now. Uh um if we look at what the model is returning, it’s clearly reasoning through it. It’s doing a little bit of mental maths here and there, but it’s not really giving the customer a concrete answer. And I wouldn’t rely on this as being able to accurately give the customer a response.
Korean:
다음 실패 테스트 케이스는 proration 계산입니다. 고객이 30기가바이트 플랜으로 업그레이드하면 다음 청구액이 얼마냐고 물어요. 모델이 해야 할 일은 계산을 수행해서 정확한 다음 청구액을 반환하는 것이지, 지금처럼 모호한 출력을 주는 게 아니에요. 모델이 반환하는 걸 보면 분명히 추론하고 있어요. 여기저기 정신 산수를 조금 하지만 고객에게 구체적인 답을 주지는 않습니다. 이걸로 고객에게 정확한 응답을 줄 수 있다고 믿지는 않을 거예요.
So if we look at the prompt then to see how we can fix this in the original prompt. We can see that all the instructions that were given to it is telling it don’t ever give a customer a vague answer. Uh um critical always calculates any pr-rated amounts correctly. Now, telling the model to do a good job isn’t particularly helpful when we don’t give the model the capability to actually do a good job. We want to avoid the model doing mental math. So, what we’re going to introduce is give the model a tool. So, we’re saying in the prompt whenever you’re doing any calculations, please use the calculate proration tool to do so.
Korean:
그럼 원래 프롬프트에서 이걸 어떻게 고칠 수 있는지 보기 위해 프롬프트를 살펴보죠. 주어진 모든 지시사항이 고객에게 모호한 답변을 절대 주지 말라고 하고, pr-rated 금액을 항상 정확하게 계산하라고 되어 있습니다. 모델에게 잘하라고 말하는 건, 실제로 잘할 수 있는 능력을 주지 않았을 때는 별로 도움이 안 됩니다. 모델이 정신 산수를 하는 걸 피하고 싶어요. 그래서 모델에게 도구(tool)를 주려고 합니다. 프롬프트에 계산할 때는 calculate proration tool을 사용하라고 말하는 거예요.
English:
In order to introduce that tool, we need to introduce it into the API to tell the model you have access to this tool. We need to define um the tool schema which tells the model what this tool does and when to use it. And then finally we need to actually implement the tool which is the maths behind how it should be doing that calculation. So running that eval then for another pass we can see that all the test cases are now passing. It’s clearly done uh um the maths using the tool in the background and returning the correct response.
Korean:
그 도구를 도입하려면 API에 도입해서 모델에게 이 도구에 접근할 수 있다고 알려야 합니다. 모델에게 이 도구가 무엇을 하고 언제 사용해야 하는지 알려주는 tool schema를 정의해야 해요. 그리고 마지막으로 그 계산을 어떻게 해야 하는지 수학적 배경을 구현한 도구를 실제로 만들어야 합니다. eval을 한 번 더 실행해 보니 이제 모든 테스트 케이스가 통과합니다. 배경에서 도구를 사용해 수학을 수행하고 정확한 응답을 반환하는 게 분명해요.
English:
So the key lesson to take away here is instructions don’t add capability. Telling the model it’s critical to do a calculation right doesn’t make it better at mental math. So the correct approach was to give it a tool. Overall giving it the ability to reason over a harder problems and using tools to actually execute them reliably. So now we have one final failing test case which we need to address which is this billing error here.
Korean:
여기서 핵심 교훈은 지시사항은 능력을 추가하지 않는다는 것입니다. 계산을 제대로 하라고 강조하는 게 모델의 정신 산수 능력을 더 좋게 만들지 않아요. 올바른 접근은 도구를 주는 것이었습니다. 전체적으로 더 어려운 문제에 대해 추론할 수 있는 능력을 주고, 도구를 사용해 실제로 신뢰성 있게 실행하는 거예요. 이제 마지막으로 해결해야 할 실패 테스트 케이스가 하나 남았는데, 바로 이 billing error입니다.
English:
In this scenario there is a billing conflict and what we really want is the agent to escalate this to a human. And what we’re seeing it doing instead is it’s trying to explain to the customer what the reason behind it might be. and it’s trying to kind of diagnose the problem itself. So in order to fix this behavior, let’s again have a look what it was told in the prompt.
Korean:
이 시나리오에는 billing conflict가 있고, 우리가 정말 원하는 것은 에이전트가 이를 human에게 escalate하는 것입니다. 대신 모델이 하는 것은 고객에게 그 뒤에 있을 수 있는 이유를 설명하려 하고, 문제를 스스로 진단하려 하는 거예요. 이 행동을 고치기 위해 다시 프롬프트에서 무엇을 지시받았는지 살펴보죠.
English:
We see in the initial instructions it was giving, it says, “Avoid escalating or transferring to a care specialist unless absolutely necessary as it cost approximately $8 and it counts against our team’s fast contract resolution.” Now, this is only giving one side of the story, right? We’re telling it what the cost is to escalating, but not the benefit, which means it’s going to overfit again to not escalating this scenario. And second of all, we’ve got this clear conflict between what we’ve defined in the eval in terms of what we want the model to do to do this escalation versus what we’re actually telling it to do.
Korean:
초기 지시사항에서 본 내용은 “절대적으로 필요하지 않으면 care specialist에게 escalate하거나 transfer하지 말라. 비용이 약 $8 들고 우리 팀의 fast contract resolution에 불리하기 때문이다”입니다. 이건 이야기의 한 면만 주는 거예요, 맞죠? escalate 비용만 알려주고 이익은 안 알려주니, 이 시나리오에서 escalate하지 않도록 다시 과적합될 거예요. 둘째로, eval에서 모델이 escalation을 하도록 정의한 것과 실제로 지시한 것 사이에 명확한 충돌이 있습니다.
And the fix that’s relevant here is to give it both sides of the story by saying it costs $8 uh um to escalate a case, but actually if you get this wrong, then it’s going to cost you a refund as well as customer trust. Again, here we observed how the model optimizes for a goal. And this kind of instruction is a common instruction to give. It’s quite similar to the one we saw earlier where we didn’t want it to overfit to a certain type of behavior. But it’s the kind of instruction that can be followed quite differently by different generations of models. And specifically, as models become more intelligent, we need to remember to state both sides of the trade-offs because our models are becoming better themselves at making those tradeoffs themselves.
Korean:
여기서 관련된 수정은 양면을 모두 알려주는 것입니다. 케이스를 escalate하면 $8 비용이 들지만, 잘못하면 환불 비용과 고객 신뢰까지 잃게 된다고요. 여기서 다시 모델이 목표를 어떻게 최적화하는지 관찰했습니다. 이런 종류의 지시는 흔히 주는 지시예요. 이전에 특정 행동으로 과적합되지 않게 하려 했던 것과 꽤 비슷합니다. 하지만 다른 세대의 모델들이 상당히 다르게 따를 수 있는 종류의 지시입니다. 특히 모델이 더 지능적으로 될수록 trade-off의 양면을 모두 명시해야 합니다. 모델들 스스로 trade-off를 더 잘 판단하게 되기 때문이에요.
English:
as a final pass. Then we want to look at doing this a little bit more agentically. So we’re going to use this generate evaluate repair loop where essentially the generator now creates a first draft of the schedule and then we have a separate prompt which reports any specific violations that it made. So not programmatically checking it, but checking it with an LLM. So we’re checking for every rule and we’re providing evidence of every violation. And we then have a third repair prompt which receives uh any violations that were made and tries to make targeted fixes to it. So we have three very simple prompts, but they’re now running independently rather than trying to do everything in one large prompt.
Korean:
최종 패스로요. 그다음에는 좀 더 agentically 하는 걸 살펴보고 싶습니다. generate-evaluate-repair 루프를 사용할 거예요. generator가 스케줄의 첫 초안을 만들고, 별도의 프롬프트가 만든 특정 위반 사항을 보고합니다. 프로그래밍 방식으로 체크하는 게 아니라 LLM으로 체크하는 거예요. 모든 규칙을 확인하고 모든 위반에 대한 증거를 제공합니다. 그리고 세 번째 repair 프롬프트가 발생한 위반을 받아서 목표화된 수정(targeted fixes)을 시도합니다. 그래서 매우 단순한 세 개의 프롬프트가 있지만, 이제 하나의 큰 프롬프트에서 모든 걸 하려 하지 않고 독립적으로 실행됩니다.
English:
So we can see in this case our agentic approach has solved all of our test cases um with a much lower number of tokens and with a lower latency than trying Sonet 46 with a better prompt. So going forward, it seems like there’s two appropriate approaches to take here. Using Opus 47 with adaptive thinking or using this agentic loop. Now moving forward, we’d probably want to do a little bit more optimization on this loop to try and get it to be more efficient. But there’s one key benefit as well from using this generate evaluate repair loop. And that is that you can put in soft requirements at runtime. So in the evaluation prompt, we can say Harry doesn’t like working with Sally. So as much as possible, try and separate them from working together or we need a third shift uh um on Wednesday, for example. So it means that you’re not having to make changes to the um Python function which is doing the evaluation in the back end every time to satisfy for any soft constraints which might depend just on a case-by-case basis.
Korean:
이 경우 agentic 접근 방식이 모든 테스트 케이스를 해결한 걸 볼 수 있습니다. 더 나은 프롬프트로 Sonet 46을 시도하는 것보다 훨씬 적은 토큰 수와 낮은 latency로요. 앞으로 여기서는 두 가지 적절한 접근이 있는 것 같아요. Opus 47을 adaptive thinking과 함께 사용하거나, 이 agentic loop를 사용하는 것입니다. 앞으로 이 loop를 더 최적화해서 효율성을 높이고 싶을 거예요. 하지만 generate-evaluate-repair loop를 사용하는 데 한 가지 핵심 이점도 있습니다. runtime에 soft requirements를 넣을 수 있다는 거예요. evaluation 프롬프트에서 Harry는 Sally와 일하는 걸 싫어하니 최대한 함께 일하지 않게 분리하라고 하거나, 예를 들어 수요일에 third shift가 필요하다고 할 수 있어요. 그래서 case-by-case로 달라질 수 있는 soft constraints를 만족시키기 위해 매번 백엔드에서 evaluation을 하는 Python 함수를 변경할 필요가 없다는 의미입니다.
English:
So, the overall takeaways from this session. Um, one is that when you’re migrating between models, especially to a more capable model, you should expect some amount of regression. And you should have a strong eval suite to catch those regressions. Two is that you should be regularly auditing and maintaining your prompts. As models get better, old patches and defensive instructions can become sources of overfitting. Three, instructions don’t add capability. If the model can’t do something reliably, give it a tool.
Korean:
이 세션의 전체 takeaway입니다. 하나는 모델 간 마이그레이션, 특히 더 능력 있는 모델로 이동할 때 어느 정도 regression을 예상해야 한다는 것입니다. 그리고 그 regression을 잡아낼 강력한 eval suite가 있어야 해요. 둘째, 프롬프트를 정기적으로 감사(auditing)하고 유지해야 합니다. 모델이 좋아질수록 오래된 패치와 방어적 지시가 overfitting의 원인이 될 수 있어요. 셋째, 지시사항은 능력을 추가하지 않습니다. 모델이 무언가를 신뢰성 있게 못 한다면 도구를 주세요.
Four is to use structured outputs and clear separation of concerns in your prompts. XML tags, sections for role, policy, tone, guidelines all help the model parse and follow instructions more reliably. Five, for complex tasks, consider agentic workflows like generate-evaluate-repair loops. They can be more efficient and flexible than cramming everything into one giant prompt. And finally, always state both sides of trade-offs explicitly, especially as models get smarter at reasoning about them.
Korean:
넷째, 프롬프트에서 structured outputs와 명확한 역할 분리를 사용하세요. XML 태그, 역할·정책·톤·가이드라인 섹션은 모델이 지시를 더 신뢰성 있게 파싱하고 따르게 합니다. 다섯째, 복잡한 작업에는 generate-evaluate-repair loop 같은 agentic workflow를 고려하세요. 모든 걸 하나의 거대한 프롬프트에 쑤셔넣는 것보다 더 효율적이고 유연할 수 있습니다. 마지막으로, 특히 모델이 trade-off를 추론하는 데 더 똑똑해질수록 trade-off의 양면을 항상 명시적으로 밝히세요.
English:
These principles help turn fragile, accumulated prompts into robust, maintainable systems as you scale with newer models. The key is treating prompting as an iterative, evaluated engineering process rather than a one-time static artifact.
Korean:
이 원칙들은 새 모델로 스케일업하면서 취약하고 쌓인 프롬프트를 견고하고 유지 가능한 시스템으로 바꾸는 데 도움이 됩니다. 핵심은 프롬프팅을 일회성 정적 산물이 아니라 반복적이고 평가되는 엔지니어링 프로세스로 다루는 것입니다.
English:
(Original video ends around here with closing remarks on applying these in practice at Anthropic.)
Korean:
(원본 영상은 Anthropic에서의 실무 적용에 대한 마무리 발언으로 여기쯤 끝납니다.)