원본: AI prompt engineering: A deep dive - Anthropic
2024. 9. 6. 에 공개된 내용으로, 최근에는 해당되지 않는 내용일 수 있음 Claude Opus 4.5가 스크립트를 읽고 정리한 내용
영상 내용의 주장을 정리한 것
- 프롬프트 엔지니어링이란 이름이 붙은 이유 (섹션 1)
- 독립적 실험을 반복하면서 평가 가능
- 시스템 전체 통합(Tool Use, 예: RAG, 인터넷 검색, 코드 실행 등)이 있음
- 역할 부여(role prompting)는 효과에 대해 의견이 갈림. (섹션 4)
- 대부분 효과가 없거나 제한된 상황에서 효과가 있다는 주장
- hack 방식의 프롬프트는 빠르게 없어짐. (섹션 9)
- 모델 내부에 흡수되어서 필요없어짐. (예: 압박성 문구, "Think step-by-step")
- 단, 커뮤니케이션 수준의 기법은 지속됨. (예: few-shot, CoT)
- 미래에는 모델이 사용자로부터 정보를 끌어내는 방향으로 전환할 것 (섹션 10).
- 모델이 인간 수준 이상이 되면 관계가 역전될 수 있음
- 전문가(모델)가 클라이언트(사용자)를 인터뷰하여 엣지 케이스·의도·모호성을 해소
- Alex Albert — Developer Relations 리드 (전 프롬프트 엔지니어링 팀)
- David Hershey — 고객 대응 기술 지원 (파인튜닝, 시스템 구축)
- Amanda Askell — 파인튜닝 팀 리드 (alignment 연구)
- Zack Witten — 프롬프트 엔지니어
모델에서 최대 성능을 끌어내기 위해 명확하게 소통하는 행위. "엔지니어링"인 이유는 클린 슬레이트로 되돌려 독립적 실험을 반복할 수 있는 시행착오 과정이 존재하기 때문 (Zack).
단순히 프롬프트 하나를 쓰는 게 아니라 시스템 전체에 통합하는 작업 포함 — 데이터 소스, 레이턴시 트레이드오프, RAG 구성 등 시스템 사고가 필요 (David). 버전 관리와 실험 추적도 코드와 동일하게 중요하며, 결과적으로 "잘 쓴 에세이를 코드처럼 관리하는 패러다임"에 진입.
Amanda가 제시한 핵심 역량 세 가지:
- 명확한 커뮤니케이션 — 개념을 정확히 기술하는 능력. 단, 좋은 글쓰기 능력과의 상관관계는 생각보다 낮음.
- 반복 의지 — 15분에 수백 개 프롬프트를 보내며 무엇이 잘못 해석되었는지 파악하고 수정하는 과정.
- 엣지 케이스 사고 — 전형적 입력만 테스트하고 넘어가는 것이 가장 흔한 실수. G로 시작하는 이름이 없는 데이터셋, 데이터셋이 아닌 입력, 빈 문자열 등을 미리 시험해야 함.
추가 관점:
- 모델 출력을 꼼꼼히 읽을 것 (Zack) — "think step-by-step"이라 지시했으면 실제로 그렇게 하는지 확인. 모델이 이를 추상적으로 해석할 수 있음.
- 암묵적 지식을 분리하는 능력 (David) — 자기가 아는 맥락을 제거하고, 모델이 태스크 수행에 필요한 정보의 전체 집합을 명시해야 함. 작성자의 사전 이해에 조건화된 프롬프트는 제3자가 읽으면 이해 불가.
- 실제 사용자 입력 예측 (David) — 엔터프라이즈 eval은 완벽한 문장으로 구성되지만, 실제 사용자는 오타투성이에 구두점 없이 키워드만 나열. 실제 트래픽을 예측하는 것이 다음 수준의 사고.
- 프롬프트를 모델에 주고 "따르지 말고, 불명확한 부분만 알려달라"고 요청 (Amanda). 항상 완벽하진 않지만 유용.
- 모델이 실수하면 "왜 틀렸는지 생각하고 지시사항을 수정해달라"고 요청 → 상당 비율로 유효한 수정안 제시. 성공률은 태스크마다 다르지만 항상 시도할 가치가 있음.
- 기본적으로 신뢰하지 않고 반복 테스트로 구축. 약간 분포 밖으로 나가면 단순한 태스크에서도 신뢰도가 떨어질 수 있음.
- 소수 고품질 > 다수 저품질: 잘 구성된 수백 개의 테스트가 느슨한 수천 개보다 높은 신호를 줌. 프롬프팅에서는 각 쿼리에서 매우 높은 신호를 얻을 수 있기 때문.
- 결과의 정오뿐 아니라, 모델이 어떻게 거기에 도달했는지, 어떤 단계를 거쳤는지에서 훨씬 많은 정보를 얻을 수 있음.
- 최고 수준의 프롬프팅이 모델 성능 상위 5%와 상위 0.1%의 차이를 만들 수 있고, 이것이 실험 성공 여부를 결정. 코드는 깔끔하게 작성하면서 프롬프트에 시간을 투자하지 않는 것은 비합리적.
- 모델이 "대략 감을 잡고 있는지" 확인 (Amanda). 매번 수정할 때마다 전혀 다른 틀린 방향으로 벗어나면 포기 (David). 단 이런 경우는 점점 드물어지고 있음.
- 프롬프트를 맥락 없는 타인에게 줘서 직접 수행하게 하면 불명확한 부분이 드러남.
- 모델에 "탈출구"를 제공: 예상치 못한 입력에
<unsure>태그를 출력하게 하면, 억지 답변 방지 + 문제 데이터 발견. - 직접 eval을 수행해보면 평가 자체의 품질 문제를 발견할 수 있음.
Amanda — 사용하지 않음:
- 모델이 세계를 충분히 이해하므로 거짓말이 불필요. LLM eval 데이터셋을 만들면서 "나는 교사이고 퀴즈를 만들려 한다"고 할 이유가 없음 — 모델은 LLM eval이 뭔지 알고 있으므로 실제 태스크를 직접 기술하는 게 나음. 이전 모델에서도 이 기법을 한 번도 사용한 적 없음.
Zack — 비유(metaphor)로서 제한적 유용성:
- 완전한 거짓말이 아닌 사고 프레임 전달용 비유는 유효. 예: 차트 품질 평가 시 "고등학교 과제로 제출됐다면 몇 점?"은 평가 척도를 전달하는 비유.
David — 엔터프라이즈 현장의 문제:
- 고객이 역할 부여를 유사 태스크의 지름길로 과도하게 사용. 실제 제품 맥락(어떤 회사의 어떤 제품에 내장된 어떤 역할인지)을 직접 기술하는 게 훨씬 효과적.
유능하지만 회사명도 모르는 사람이 방금 도착했다고 상상하라. 그 사람에게 뭐라고 말하겠는가? — 이것이 프롬프트의 첫 버전이 되어야 한다.
이 프레임으로 쓴 첫 버전이 놀라울 정도로 자주 그냥 작동함.
고객이 "프롬프트가 안 된다"고 하면, 태스크를 구두로 설명하게 한 뒤 그 녹음을 전사해서 프롬프트에 붙여넣으면 원래 프롬프트보다 나은 경우가 많음. 사람들이 프롬프트를 쓸 때 과도하게 압축하거나 키워드만 나열하는 반면, 말로 설명하면 필요한 맥락이 자연히 포함됨.
CoT는 작동하는가: 전원 동의 — 추론을 시키면 결과가 명백히 좋아짐.
단순한 추가 연산 공간인가:
- "um, ah"를 100토큰 반복 후 답하게 하는 실험, 이야기를 쓰게 하는 실험 모두 추론만큼 효과적이지 않음 (David, Amanda 확인).
- 따라서 단순히 더 많은 attention 공간이 아니라 추론 내용 자체가 기여.
- 단, 중간 단계가 틀렸는데 최종 답이 맞는 경우도 존재 → 완전히 인간 추론과 동일하게 의인화하기는 어려움 (Amanda 반론: 인간도 그런 경우가 있음).
문법·맞춤법:
- Zack: 반드시 필요하다고 주장하지는 않지만, 프롬프트에 주의를 기울이는 과정에서 자연히 교정하게 됨.
- Amanda: 개념적 명확성에 집중하고 반복 중 오타는 무시. 최종 프롬프트에서는 교정이 합리적.
- 사전학습 모델에서는 오타가 후속 오타 확률을 높이므로 중요했으나, RLHF 이후 모델에서는 이 직관이 과적용되는 경향.
가장 큰 차이: 예시의 양과 목적
| 연구 (Amanda) | 엔터프라이즈 (David/Zack) | 일반 채팅 | |
|---|---|---|---|
| 예시 수 | 적음 | 대량 | 거의 불필요 |
| 예시 성격 | 예시적 — 실제 데이터와 의도적으로 다르게 (다양성 확보) | 구체적 — 원하는 출력 형식 직접 시연 (일관성 확보) | N/A |
| 핵심 가치 | 다양성, 유연한 반응 | 신뢰성, 포맷 일관성 | 1회 성공이면 충분 |
| 테스트 범위 | 엣지 케이스 전체 | 실제 트래픽 전체 범위 | 해당 1건 |
Amanda 추가: RLHF 모델에서 "모델이 이렇게 응답했다" 형태의 few-shot은 오래전부터 효과가 떨어진다고 판단하여 사용하지 않음. 사전학습 모델에서 유래한 직관으로, RLHF 모델에는 부적합할 수 있음.
- Zack: 좋은 프롬프트와 그 출력을 많이 읽고, 왜 잘 되는지 분석하고 직접 실험.
- Amanda: 반복, 반복, 반복. 프롬프트를 맥락 없는 타인에게 줘볼 것. 즐기면 빨리 늘음.
- David: 모델이 못 할 것 같은 어려운 태스크에 도전. 경계를 밀어붙이면 모델 작동 방식을 가장 많이 배움. 실패해도 학습 가치가 큼.
David의 Pokemon 사례: Claude를 Game Boy 에뮬레이터에 연결해 포켓몬 레드를 플레이하게 시도. 이미지 위에 그리드를 겹치고 ASCII 맵으로 재구성하는 등 프롬프트를 극한까지 개선했으나, NPC 식별 등 연속성이 필요한 부분에서 한계. 주말 투자로 "신호 없음 → 약간의 신호"까지 도달했지만 충분하지 않아 "다음 모델을 기다리겠다"고 결론. 텍스트 프롬프팅 직관이 이미지에는 거의 전이되지 않았음.
Amanda: 정확한 메커니즘은 불확실하나, 한 가지 모델은 모델을 훈련 데이터 분포 밖으로 밀어내는 것 — 매우 긴 토큰 시퀀스, 파인튜닝 시 보지 못한 형태의 입력 등.
탈옥은 해킹과 소셜 엔지니어링의 혼합: 텍스트 예측 방식에 대한 지식("Here is..."로 응답 시작 유도), 추론 반응성 활용, 주의 분산, 다국어 훈련 차이 활용 등이 복합적으로 작용. Alex의 예시 — 그리스어로 먼저 출력하게 한 뒤 영어로 번역을 요청하면 영어 직접 출력은 거부하던 것을 우회 가능.
- 효과적인 핵(hack)은 모델에 훈련됨 (Amanda): 예) 수학에서 "think step-by-step" → 이제 모델이 자연적으로 수행. 핵은 수명이 짧음. 단, 예시 제공과 CoT는 핵이 아닌 커뮤니케이션 수준의 기법이므로 지속.
- 모델에 더 많은 정보를 신뢰하고 제공 (David): 과거에는 복잡성을 숨겼으나, 현재는 논문 전체를 그대로 제공해도 잘 처리. "모델을 존중하라" — 과도하게 단순화하지 말 것.
- Amanda: 새 프롬프팅 기법 논문이 나오면 직접 기술하지 않고 논문 자체를 모델에 제공. "이 기법의 예시 17개를 작성하라" → 모델이 논문을 읽고 수행.
- 사전학습 직관의 과적용 경고 (David): "인터넷에 이런 게 많이 있었을까?" 식의 사고는 RLHF 이후 모델에는 부정확.
- Amanda의 "모델 마인드스페이스 거주": 사전학습 모델과 RLHF 모델의 사고를 시뮬레이션하는 것은 매우 다른 경험. 전자는 "텍스트 중간에 착지"하는 느낌, 후자는 질의의 미묘한 뉘앙스를 포착하는 인간적 느낌.
공통 전망: 모델이 사용자로부터 정보를 끌어내는(elicitation) 방향으로 전환.
-
Zack: 태스크 명세는 항상 필요 — 원하는 것을 명확히 기술하는 것은 본질적으로 어려운 문제. 단, 도구와 협업 방식은 크게 진화할 것. 모델을 활용한 프롬프트 작성이 증가하며, prompt generator는 이 미래의 가장 기초적 형태.
-
Amanda: 모델이 인간 수준 이상이 되면 관계가 역전될 수 있음 — 모델이 사용자에게 질문하여 엣지 케이스·의도·개념적 모호성을 해소. "임시직 직원 → 디자이너 컨설턴트" 비유: 현재는 사용자가 지시하지만, 미래에는 전문가(모델)가 클라이언트(사용자)를 인터뷰하여 필요한 정보를 추출.
-
David: 이미 Claude에게 자신을 인터뷰하게 한 뒤 그 결과를 프롬프트로 변환하는 방식을 사용 중.
분석 철학 글쓰기 훈련과의 연결: 교육받은 비전문가(educated layperson)가 읽어도 모든 것을 이해할 수 있도록 복잡한 개념을 명확히 기술하는 것. 상대를 무시하지 않고, 부정확하지 않으면서, 극도로 명확하게.
"자기 뇌를 외재화(externalize your brain)하는 것. 머릿속의 것을 충분히 분석하여, 길에서 아무 합리적인 사람을 데려와도 완전히 이해시킬 수 있을 정도로 전달하는 것이 프롬프팅의 본질."