▲

Anthropic의 프롬프트 엔지니어링 인터랙티브 튜토리얼 [2024]

 (github.com/anthropics)
1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개
  • Anthropic이 제공하는 프롬프트 엔지니어링 튜토리얼로 Claude 모델에 최적화된 프롬프트 작성법을 인터랙티브하게 단계별로 안내
  • 사용자는 좋은 프롬프트의 구조와 실패 사례, 그리고 효율적인 개선 기법을 직접 연습하고 체득할 수 있음
  • 각 장마다 실습 예시와 해설이 포함되어, 실전에 가까운 경험을 제공함
  • 초급부터 고급까지 9개 장과 부록으로 구성되어, 직접 프롬프트 작성 및 문제 해결 능력을 기를 수 있음
  • 이 튜토리얼은 Google Sheets 버전도 함께 제공하여 접근성과 활용도를 높임

Anthropic의 프롬프트 엔지니어링 인터랙티브 튜토리얼

  • 인공지능 모델인 Claude에 최적화된 프롬프트 설계 지식을 제공하는 오픈 소스 학습 자료
  • OpenAI 기반 챗봇 학습 플로우와 유사하지만, Claude 모델의 특장점 및 한계 인지, 그리고 실전 연습 중심의 구성 덕분에, 타 튜토리얼 대비 실제 업무 적용 가능성과 실용성이 뛰어남
  • 특히 실제로 프롬프트 작성과 결과 실험을 병행할 수 있어 초보 엔지니어에게 큰 이점을 제공

코스 소개 및 목표

  • 이 튜토리얼은 Claude 내에서 최적의 프롬프트를 설계하고 활용하는 법을 단계별로 안내함
  • 코스 완료 시 사용자는 아래를 습득할 수 있음
    • 효과적인 프롬프트 구조의 이해
    • 대표적인 실패 패턴 인지 및 우선 개선법(80/20 법칙)
    • Claude 모델의 강점과 약점 파악
    • 다수의 일반 업무에 적용할 프롬프트 구축 능력

코스 구조 및 콘텐츠

  • 9개 장(초급 ~ 고급)과 심화 부록으로 구성되어 있음
  • 각 장은 이론 설명과 직접 실습을 함께 제공함
  • 각 파트 마지막에는 "Example Playground"에서 프롬프트를 직접 입력하고, 응답의 변화를 실험할 수 있는 공간이 마련되어 있음
  • 모든 예시에 대해 해설 키가 포함되어 있음
  • 튜토리얼의 기본 모델은 가장 경량이면서 빠르고 저렴한 Claude 3 Haiku임. 필요시 더 높은 지능의 Sonnet 및 Opus에 대한 언급도 포함됨
  • Google Sheets 확장 버전으로도 활용할 수 있어, 학습 접근성이 높음

커리큘럼 목차

  • 초급
    • Chapter 1: 기본 프롬프트 구조
    • Chapter 2: 명확하고 직접적인 지시 작성법
    • Chapter 3: 역할 부여하기
  • 중급
    • Chapter 4: 데이터와 지시 분리
    • Chapter 5: 출력 포맷 지정 및 Claude를 위한 대화화
    • Chapter 6: 사전 사고(단계별 생각 도출)
    • Chapter 7: 예시 활용법
  • 고급
    • Chapter 8: 환각(Hallucination) 방지
    • Chapter 9: 복잡한 프롬프트 구축(산업별 사례)
      • 예: 챗봇, 법률 서비스, 금융 서비스, 코딩 등 다양한 업무별 실전 적용 문제를 다룸
  • 부록
    • 표준 프롬프트를 넘어선 방법들
      • 프롬프트 체이닝, 도구 사용, 검색/검색 결과 통합 등 심화 기술

활용 안내

  • 튜토리얼은 각 장별로 반드시 차례로 진행하는 것을 권장
  • 실전 중심의 연습과 단계별 해설로, 초보 엔지니어도 실제로 쓸 수 있는 프롬프트 설계 역량을 자연스럽게 익힐 수 있음
  • 모든 프로덕트 및 모델명은 원문 그대로 표기하며, 영어 기반 업무 환경에서도 바로 활용 가능함

추가 특징 및 오픈소스 정보

  • Github 상에서 19,400개 이상의 Stars와 1,900개 Fork를 기록 중임
  • 주 개발 언어는 Jupyter Notebook이며, 일부 Python 코드도 포함됨
  • 별도의 배포 패키지는 없으며, 모든 자료는 오픈소스로 자유롭게 참조 가능함
▲
GN⁺ 20시간전  [-]
Hacker News 의견

  • "engineering"이라는 단어가 이런 맥락에서 쓰이는 것은 매우 거슬림, 진짜 엔지니어링이라고 볼 수 없다고 생각함, 엔지니어링은 오랜 세월 쌓인 지식과 물리 법칙, 규칙 등을 기반으로 예측 가능하게 설계하고 만드는 일인데, 지금 하는 것은 결과가 나올 때까지 무작정 시도하는 것에 불과함

    • 어떤 단어든 여러 의미가 있다고 생각함, "prompt engineering"에서의 "engineering"은 "social engineering"에서처럼 비슷하지만 다른 뉘앙스임, 예를 들면 구글의 engineering 정의 2번은 '술수를 부려 목적을 이루는 행동'임, Merriam-Webster 사전의 3번째 정의나, collins dictionary, yourdictionary 등에서 찾아봐도 “교묘한 조작, 계획을 세움”과 같은 기술적이지 않은 의미가 분명히 존재함, 단어의 확립된 부차적 의미임

    • 나는 시리얼을 먹으면서 시리얼 박스의 스펙을 검토함, 매일 아침 그렇게 하고, 버스 타는 엔지니어링 스킬도 적용함, 왜냐하면 나는 prompt engineering으로 생계를 꾸리는 사람이기 때문임, 요즘은 너무 많은 단어들이 본래 의미를 잃어가고 있다는 생각이 들어서 자신만 짜증나는 게 아니라는 게 다행임

    • 나는 캐나다의 접근 방식, 즉 엔지니어라는 직함을 쓰려면 각 주의 기술인 규제기관에서 면허를 받아야 하는 시스템을 계속 선호함, 미국은 모든 소프트웨어 개발자, 정비공, HVAC 설치기사, 배관공까지도 엔지니어라고 부르는 게 지나치다고 느낌

      1. 소프트웨어 엔지니어들은 컴퓨터 시스템에 대한 깊은 물리적 지식이 거의 없고, 실제 업무는 경험적 과학보다는 철학이나 어느 정도 수학과 더 관련됨, 2) 당신이 AI 발전 동향에 대해 잘 모르는 것 같음, 컴퓨터 공학처럼 prompt 작업을 위한 전문 용어와 레퍼런스, 문서를 이미 만들었음, 이 분야는 어디 학교에서도 배울 수 없는 독립 영역인데, 실무 경험 없으면 채용도 안 한다는 추세임

    • 이런 논란은 사실 많은 "engineering 팀"들이 하는 일에도 똑같이 제기할 수 있다고 생각함, 엔지니어가 하면 그 일이 곧 엔지니어링이란 암묵적 전제가 깔려 있고, 더 나아가서 소프트웨어 자체가 소프트웨어 엔지니어링이라 부를 수 있는 가치가 있는지에 대한 깊은 가정도 있음

  • "Engineering"이라는 말은 사람들에게 그냥 문장 쓰기가 아니라는 인상을 주려는 수사적 장치라는 생각임, 솔직히 "prompt writing"이라고 하면 뭔가 가볍게 여겨질 수 있으니까 "soft" skill이라는 말을 싫어하는 사람들에게는 더욱 거북할 것임

  • 오늘의 "초보자를 위한 연금술" 에피소드 같은 느낌임, 벤치마크 세트에서 랜덤 시드로 7을 주었을 때 알고리즘 속도가 30% 늘었던 사례가 떠오름, 8도 아니고 6도 아닌 7이었음

    • 이렇게 비결정론적이고 복잡해지는 상황을 싫어할 수도 있지만, 이게 이제 우리의 일임, 내가 하지 않으면 누군가는 결국 해야만 할 일임, 나는 AI 응용 프로젝트에서 prompt engineering을 실제 엔지니어링과 분리시키고, 모든 필요 도구(컴포넌트화, 버전관리, 평가도구)를 세팅해서 prompt engineering을 가능한 체계적으로 할 수 있게 한 뒤, 그걸 도메인 전문가에게 넘겼음, prompt 엔지니어링이 시드 고르기 수준이라고 생각하면 프롬프트를 쓰면 안 된다고 보는 입장임

  • 이 글을 읽으면서 나에게 중요한 깨달음은 출력 순서를 어떻게 가져갈지 생각하게 됨, 예를 들어, 답변하기 전에 증거나 인디케이터부터 뽑아내게 요청하는 것임, LLM이 확률적 자동완성인 것은 알았지만 이런 방식으로 프라이밍은 생각하지 못했었음

    • 이 방식은 reasoning 모델에는 해당되지 않을 수 있음, reasoning 모델은 답 내기 전 원하는 방식대로 생각 과정을 거치기 때문에 출력 순서가 정확도에 미치는 영향이 적음, 이게 아마 OpenAI가 reasoning 강제하려는 이유가 아닐까 싶음

    • 나는 보통 온라인에서 찾은 출처의 짧은 인용문부터 뽑아달라고 요청함(연관이 있을 경우), 이렇게 하면 정보의 신뢰도를 어느 정도 보완해 줌, 최근에 우리 조직에서 Cloudflare Zero Trust 구축하면서 매우 필요했던 방식임

    • 반대로 답부터 내고 근거를 대라고 하면, 모델이 임의의 답을 내고 그걸 그럴듯하게 합리화하는 "헛소리 모드"에 들어감, 차라리 객관적으로 장단점부터 뽑게 하고 그 다음 결론을 내리게 하면 훨씬 신중하게 답변해줌

  • 내 생각에 이 제출물 제목에 "(2024)"를 넣는 게 좋겠음

  • 어려운 문제에서 내가 생각하는 최고의 prompt engineering 팁은 "펼치고 좁히기"임, 구체적으로 설명하면, 먼저 문제와 상황을 명확히 제시하고, AI에게 가능한 모든 옵션과 접근방법을 분석하고 찾아보게 해서 정보를 최대한 넓혀놓음, 그런 다음 각 방법의 장단점을 리스트업하고, 가장 적합한 해결책을 선택하게 하는 방식임, 쉬운 문제라면 이런 거 다 생략하고 바로 묻기만 해도 답이 나오지만, 어려운 문제에서 바로 답을 묻는다면 그냥 그럴듯하게 지어내기 때문에, 반드시 현실적인 근거에서 시작해야 함, 그래서 구체적 맥락 - 옵션 분석 - pros & cons - 최종 선택의 흐름이 필요함

    • 이런 방식은 AI 문제 말고 다른 문제 해결에도 적용되는 것 같음

  • 제목에 2024를 추가하라는 의견임

  • 우리가 직접 했던 일을 AI에게 가르치고, 다시 AI가 그 일을 하도록 효과적으로 시키는 방법을 배우는 중이라는 생각이 듦, 만약 이 기술이 미국 전체 경제가 받쳐주지 않으면 마치 뜨거운 공기 풍선처럼 띄었다가 훅 가라앉을 수도 있겠음

  • 다른 댓글들과 비슷하게 이게 정통 엔지니어링처럼 느껴지지 않음, 하지만 Anthropic이 모델 해석 가능성 분야에서 꽤 멋진 연구를 했다고 생각함, 만약 그 도구가 public API로 공개된다면 프롬프트에 따라 모델 내부 상태의 차이를 비교해보고 더 체계적인 튜닝을 할 수 있는 피드백 루프가 만들어질 수도 있을 것 같음

  • 이 튜토리얼은 세 가지 모델(Sonnet, Haiku, Opus 3)을 위해 작성됨, 오늘날에도 적용될 교훈이 일부 있지만 더 똑똑한 RL 모델(Sonnet 4.5 등)에는 그다지 중요하지 않은 내용도 있음, 참고로 Claude 3 Haiku는 가장 작고 빠르며 저렴한 모델이고, Sonnet과 Opus는 더 지능적이며 Opus가 가장 우수함

    • 3장과 6장은 현재 기준에서 덜 중요하다고 생각함, 반복적이거나 정확성이 중요한 prompt를 다루는 사람을 가정할 때 이 외에 덜 중요한 부분이 더 있을지 궁금함
답변달기