자, 주목! 프롬프트 엔지니어링, 어렵다고? 아니야! 기본만 알면 누구나 AI 조련사 될 수 있다! 오늘 딱 10분만 집중해서 기본기 3종 세트 확실하게 뽀개고 가자! 알겠지?

1. 제로샷 (Zero-shot): “야, 알아서 해!” 스타일 [Basic]

• 핵심: 샘플? 없어! 그냥 “이거 해!” 라고 던지는 거야. AI가 눈치껏 알아듣고 해주길 바라는 거지.
• 예시: “영화 리뷰 분류해줘. 긍정, 부정, 중립으로.” 끝!
• 장점: 제일 간단해. 프롬프트 짧아서 좋지.
• 단점: AI가 못 알아들으면? 말짱 꽝이야. 복잡한 건 못 시켜.
• 언제 써? AI가 이미 잘 아는 단순한 작업, 아니면 일단 한번 던져볼 때!

2. 원샷/퓨샷 (One-shot/Few-shot): “자, 보고 따라 해!” 스타일 [Critical]

• 핵심: 제로샷으로 시켰더니 AI가 멍 때린다? 그럼 어떻게 해야 돼? 샘플을 줘야지! “이건 이렇게 하는 거야” 하고 한 개(One-shot) 또는 서너 개(Few-shot) 보여주는 거야.
• 예시: (Few-shot)
  • “피자 주문 분석해서 JSON으로 만들어줘.”
  • (샘플 1) 주문: “작은 피자, 치즈, 토마토소스, 페퍼로니” -> JSON: {"size": "small", ...}
  • (샘플 2) 주문: “큰 피자, 토마토소스, 바질, 모짜렐라” -> JSON: {"size": "large", ...}
  • (이제 진짜 질문) 주문: “큰 피자, 반은 치즈/모짜렐라, 반은 토마토소스/햄/파인애플” -> JSON: ?
• 장점: AI가 뭘 해야 할지 확실히 감 잡게 해줘. 특히 출력 형식 맞출 때 완전 효과 직빵!
• 단점: 샘플 준비하는 게 좀 귀찮지. 프롬프트도 길어지고.
• 언제 써? 제로샷이 안 먹힐 때, 결과물의 특정 패턴이나 스타일을 원할 때 무조건 써야 해! 이게 진짜 중요해! 별표 다섯 개! ★★★★★

3. 시스템 / 맥락 / 역할 프롬프팅: “틀 잡고, 힌트 주고, 역할 부여!” 스타일 [Moderate]

• 이 세 가지는 살짝 겹치기도 하는데, 목적이 조금씩 달라.
  • 시스템 프롬프팅 (System): 이건 AI한테 “너의 기본 임무는 이거야!” 라고 큰 틀을 잡아주는 거야. 약간 ‘설정값’ 같은 느낌?
    • 예시: “영화 리뷰 분류해줘. 결과는 무조건 대문자 라벨 하나만 출력해.” (출력 형식 지정) / “절대로 무례하게 답하지 마.” (안전 가이드라인)
    • 언제 써? 결과물의 형식, 스타일, 안전성 등 전반적인 규칙을 정해주고 싶을 때.
  • 맥락 프롬프팅 (Contextual): 이건 “지금 상황이 이러니까, 이걸 고려해서 답해!” 라고 콕 짚어주는 거야. 주변 정보, 즉 ‘맥락’을 주는 거지.
    • 예시: “맥락: 너는 지금 80년대 복고 아케이드 게임 블로그 글 쓰는 중이야. 주제 3개 추천해줘.”
    • 언제 써? 특정 상황이나 배경지식이 필요한 질문을 할 때. AI가 헛소리 안 하고 딱 맞는 답하게 하려면 필수!
  • 역할 프롬프팅 (Role): 이게 또 꿀잼이야! AI한테 “너 이제부터 OOO야!” 하고 역할을 딱! 부여하는 거지. 페르소나를 입히는 거야.
    • 예시: “너는 이제부터 유머러스한 여행 가이드야. 맨해튼 여행지 3곳 추천해줘.”
    • 언제 써? 특정 말투, 지식 수준, 관점을 가진 답변을 원할 때. 전문가, 선생님, 코미디언 등등 뭐든 시켜봐!

자, 정리!

• 일단 제로샷으로 던져보고!
• 안되면 퓨샷으로 샘플 보여주고!
• 더 디테일하게 조종하고 싶으면 시스템, 맥락, 역할 프롬프팅으로 튜닝!

이 기본기만 제대로 써도 여러분의 AI는 훨씬 더 똑똑해질 거다! 복습 철저히 하고, 다음엔 더 빡센 고급 기술 들어간다! 질문 있나? 없으면 오늘 수업 끝!

자, 이번엔 진짜 실력 끌어올리는 고급 기술 들어간다! 기본기만으로는 풀기 어려운 문제들, 이 6가지 필살기로 정복하는 거야. 정신 바짝 차리고 따라와!

1. 스텝백 (Step-back): “숲을 먼저 보고 나무를 보자!” [Complex]

• 핵심 아이디어: 바로 정답 찾으려 하지 말고, 한 걸음 물러서서 관련된 큰 그림이나 원칙을 먼저 생각하게 하는 거야.
• 작동 방식:
  1. 일반 질문 던지기: 원래 질문과 관련된 더 넓고 일반적인 질문을 먼저 해. (예: “재밌는 1인칭 슈팅 게임 레벨 스토리라인의 핵심 요소 5가지는 뭐야?”)
  2. 답변 활용: 그 답변을 **맥락(Context)**으로 삼아서 원래의 구체적인 질문을 다시 하는 거지. (예: “맥락: [위 답변 내용]. 이 중 하나를 골라서 챌린지 넘치는 1인칭 슈팅 게임 레벨 스토리라인 한 문단 써줘.”)
• 왜 쓰냐고? AI가 가진 방대한 지식 중에서 가장 관련성 높은 배경 지식을 먼저 꺼내 쓰도록 유도하는 거야. 이렇게 하면 더 깊이 있고 정확한 답변이 나오고, 편견도 줄일 수 있어. (백서 25-28p, 테이블 8, 9, 10 참고)

2. 생각의 사슬 (Chain of Thought, CoT): “과정까지 다 보여줘!” [Complex]

• 핵심 아이디어: 답만 툭 던지지 말고, **답변에 도달하기까지의 중간 추론 과정(생각의 흐름)**을 단계별로 설명하게 만드는 거야.
• 작동 방식: 프롬프트 끝에 “단계별로 생각해보자 (Let’s think step by step).” 같은 마법의 주문을 추가해! **퓨샷(Few-shot)**이랑 같이 쓰면 효과 만점! (추론 과정을 보여주는 예시를 함께 주는 거지)
• 왜 쓰냐고? 복잡한 계산, 논리 문제 풀 때 AI의 추론 능력을 비약적으로 향상시켜. 게다가 AI가 왜 그런 답을 냈는지 과정을 볼 수 있으니 해석 가능성까지 확보! (백서 29-32p, 테이블 11, 12, 13 참고)
• 주의: 추론 과정까지 출력하니 당연히 토큰 사용량↑, 시간↑, 비용↑.

3. 자기 일관성 (Self-consistency): “다수결로 정하자!” [Complex]

• 핵심 아이디어: 중요한 문제인데 CoT로도 가끔 틀린다? 그럼 여러 번 물어봐서 가장 많이 나온 답을 믿는 거야. 일종의 집단지성 활용법!
• 작동 방식:
  1. CoT 프롬프트를 준비해.
  2. 온도(Temperature)를 높여서 (랜덤성을 키워서) 똑같은 질문을 여러 번 (최소 3번 이상) 던져. 그럼 다양한 추론 경로와 답변이 나오겠지?
  3. 각 답변에서 최종 결론만 뽑아내.
  4. 가장 자주 등장한 답변을 최종 결과로 채택! (다수결 원칙)
• 왜 쓰냐고? 한번 물어봐서 틀릴 수 있는 답변의 정확도와 신뢰도를 높여줘. 마치 여러 전문가에게 물어보고 가장 일치하는 의견을 따르는 것과 같아. (백서 32-36p, 테이블 14 참고)
• 주의: 여러 번 실행하니 비용과 시간 소모가 커.

4. 생각의 트리 (Tree of Thoughts, ToT): “모든 가능성을 탐색하라!” [Complex]

• 핵심 아이디어: CoT가 외길 인생이라면, ToT는 여러 갈래 길을 동시에 탐색하는 거야. 마치 나무 가지처럼 생각을 뻗어 나가면서 최적의 해답을 찾는 거지.
• 작동 방식: 하나의 생각(노드)에서 다음 단계로 나아갈 때, 여러 가능한 생각(가지)들을 동시에 고려하고 평가하면서 탐색을 진행해. (구현이 단순 프롬프팅보다 복잡함)
• 왜 쓰냐고? 정답 경로가 여러 개일 수 있거나, 다양한 가능성을 탐색하고 비교해야 하는 매우 복잡한 문제 해결에 유리해. CoT의 일반화된 버전이라고 보면 돼. (백서 36-37p, 그림 1 참고)

5. 리액트 (ReAct – Reason & Act): “생각하고, 도구를 써!” [Complex]

• 핵심 아이디어: AI가 스스로 생각(Reason)하고, 필요하면 외부 도구(Act)를 사용해서 정보를 찾거나 작업을 수행하게 만드는 거야. 진짜 ‘에이전트’처럼 만드는 첫걸음!
• 작동 방식: ‘생각 → 행동 → 관찰’ 루프를 반복해.
  1. 생각: “이 질문에 답하려면 OOO 정보가 필요하네.”
  2. 행동: (예: 웹 검색 도구 사용) “OOO 검색해줘.”
  3. 관찰: (예: 검색 결과 확인) “아, OOO라고 나오는구나.”
  4. 다시 생각: “그럼 이제 XXX를 알아봐야겠다.” → 행동 → 관찰 … 최종 답을 찾을 때까지 반복.
• 왜 쓰냐고? AI가 최신 정보가 필요하거나, 외부 시스템과 상호작용해야 하는 복잡한 작업을 수행할 수 있게 돼. 인간이 문제 해결하는 방식과 유사하지. (백서 37-39p, 코드 스니펫 1, 2 참고)
• 주의: 외부 도구 연동 등 별도의 코드 구현이 필요하고, 프롬프트 관리도 복잡해.

6. 자동 프롬프트 엔지니어링 (APE): “프롬프트, 네가 짜!” [Complex]

• 핵심 아이디어: 프롬프트 짜는 것조차 귀찮다? 그럼 AI한테 프롬프트를 만들라고 시키는 거야! 메타인지 능력을 활용하는 거지.
• 작동 방식:
  1. 프롬프트 생성: “A 작업을 위한 좋은 프롬프트 10개 만들어줘.” 라고 AI에게 요청.
  2. 프롬프트 평가: 생성된 프롬프트들을 특정 기준(예: BLEU 점수)이나 다른 AI를 이용해 평가.
  3. 최적 프롬프트 선택: 가장 점수가 높은 프롬프트를 최종 사용. 필요하면 살짝 수정해서 다시 평가.
• 왜 쓰냐고? 사람이 미처 생각 못 한 효과적인 프롬프트를 발견할 수도 있고, 프롬프트 제작 과정을 자동화해서 효율을 높일 수 있어. (백서 40-41p, 테이블 15 참고)

자, 여기까지가 고급 기술 6종 세트다! 쉽지 않지? 하지만 이 기술들을 잘 이해하고 활용하면 AI의 잠재력을 극한까지 끌어낼 수 있을 거야. 각 기술의 장단점을 파악하고 상황에 맞게 적용하는 연습이 필요하다! 질문?

코드 프롬프팅 (백서 42-53p) [Moderate]

이 섹션에서는 LLM, 특히 Gemini 모델을 활용하여 코드 관련 작업을 수행하는 방법에 대해 다룹니다. 단순히 텍스트를 생성하는 것을 넘어, 개발 생산성을 높이는 다양한 코드 관련 프롬프팅 기법과 예시를 보여줍니다.

1. 코드 작성 (Prompts for writing code):

   • 내용: 특정 기능을 수행하는 코드를 생성하도록 요청할 수 있습니다. 예를 들어, “특정 폴더 내 모든 파일 이름 앞에 ‘draft_’를 붙이는 Bash 스크립트”를 작성해달라고 요청할 수 있습니다 (테이블 16).
   • 결과: LLM은 요청된 Bash 스크립트 코드를 주석까지 포함하여 생성해줍니다.
   • 중요: 생성된 코드는 매우 유용하지만, LLM은 실제 추론 능력이 부족하고 학습 데이터를 단순히 반복할 수 있으므로, 반드시 코드를 직접 검토하고 테스트해야 합니다.

2. 코드 설명 (Prompts for explaining code):

   • 내용: 기존 코드(예: 위에서 생성된 Bash 스크립트에서 주석을 제거한 코드)를 제공하고, 해당 코드가 어떤 작업을 수행하는지 단계별로 설명해달라고 요청할 수 있습니다 (테이블 17).
   • 결과: LLM은 코드의 각 부분이 어떤 기능을 하는지 상세하게 설명해줍니다. 이는 다른 사람의 코드를 이해하거나 복잡한 로직을 파악하는 데 도움이 됩니다.

3. 코드 번역 (Prompts for translating code):

   • 내용: 특정 언어로 작성된 코드를 다른 프로그래밍 언어로 변환하도록 요청할 수 있습니다. 예를 들어, 앞서 작성된 Bash 스크립트를 Python 코드로 번역해달라고 요청할 수 있습니다 (테이블 18).
   • 결과: LLM은 기능적으로 동일한 Python 코드를 생성해줍니다. 다른 언어로 마이그레이션하거나, 특정 언어 환경에 맞는 코드가 필요할 때 유용합니다.
   • 주의: 코드 출력 시, 특히 Python과 같이 들여쓰기가 중요한 언어의 경우, 올바른 형식을 유지하는 것이 중요합니다. (Vertex AI Studio에서는 ‘Markdown’ 버튼 사용 권장)

4. 코드 디버깅 및 검토 (Prompts for debugging and reviewing code):

   • 내용: 오류가 발생하는 코드와 해당 오류 메시지(Traceback)를 함께 제공하고, 무엇이 잘못되었는지 분석하고 수정 방안을 제시하도록 요청할 수 있습니다 (테이블 19, 스니펫 3, 4).
   • 결과: LLM은 단순히 오류를 수정하는 것을 넘어, 다음과 같은 놀라운 능력을 보여줍니다.
     • 오류의 원인을 정확히 진단하고 수정된 코드를 제시합니다 (예: toUpperCase 함수 대신 Python의 내장 upper() 메소드 사용 제안).
     • 코드의 다른 잠재적인 문제점(예: 파일 확장자 유지 누락, 공백 처리 미흡)을 지적하고, 이를 개선하는 코드까지 제안합니다.
     • 오류 처리(try...except) 와 같은 코드 견고성을 높이는 방안을 제안합니다.
   • 의미: LLM이 단순한 문법 오류 수정뿐 아니라, 코드 품질 개선과 관련된 심층적인 검토 능력까지 갖추고 있음을 보여줍니다.

핵심 요약: 코드 프롬프팅은 코드 생성, 이해, 번역, 디버깅 및 품질 개선에 매우 유용하게 활용될 수 있습니다. 하지만 LLM이 생성한 코드는 반드시 인간 개발자가 신중하게 검토하고 테스트하는 과정이 필수적입니다.

멀티모달 프롬프팅 (백서 54p) [Basic]

이 섹션에서는 멀티모달 프롬프팅이라는 개념을 간략하게 소개합니다.

• 정의: 기존의 텍스트 기반 프롬프트뿐만 아니라, 이미지, 오디오, 코드 등 다양한 형태의 입력(양식, Modality)을 함께 사용하여 LLM을 가이드하는 기법입니다.
• 백서의 범위: 이 백서는 주로 텍스트(코드 포함) 프롬프팅에 초점을 맞추고 있으며, 멀티모달 프롬프팅은 별개의 주제로 간주하여 이 백서에서는 깊게 다루지 않습니다.

핵심 요약: 멀티모달 프롬프팅은 텍스트 외에 이미지, 오디오 등 다양한 입력을 활용하는 프롬프팅 방식이지만, 이 백서의 주요 논의 대상은 아닙니다.

프롬프트 엔지니어링 모범 사례 (백서 54-65p)

이 섹션은 프롬프트 엔지니어링의 효율성과 결과물의 품질을 높이기 위한 실용적이고 중요한 팁들을 포괄적으로 제시합니다.

1. 예시 제공 (Provide examples) [Critical]

   • 핵심: 프롬프트 내에 원샷(One-shot) 또는 퓨샷(Few-shot) 예시를 포함하는 것이 가장 중요하고 효과적인 방법입니다.
   • 이유: 원하는 결과물이나 유사 응답 예시를 보여줌으로써 모델이 학습하고, 그에 맞춰 정확도, 스타일, 톤 등을 개선하도록 하는 강력한 ‘가르침’ 역할을 합니다. 목표점을 명확히 제시하는 것과 같습니다.

2. 간결하게 디자인 (Design with simplicity) [Basic]

   • 핵심: 프롬프트는 간결하고 명확해야 합니다. 복잡한 언어나 불필요한 정보는 피하세요.
   • 이유: 사람이 이해하기 혼란스러운 프롬프트는 모델에게도 혼란스러울 가능성이 높습니다. 명확한 지시가 좋은 결과를 유도합니다. (예: “OOO 해줘” 와 같은 명확한 동사 사용 권장)

3. 출력에 대해 구체적으로 명시 (Be specific about the output) [Basic]

   • 핵심: 원하는 결과물의 형식, 길이, 스타일 등을 구체적으로 명시하세요.
   • 이유: 단순히 “블로그 글 써줘” 보다는 “비디오 게임 콘솔 Top 5에 대한 3문단짜리 블로그 글을 정보성 있고 재미있게, 대화체 스타일로 써줘” 와 같이 구체적인 지침이 모델이 관련성에 집중하고 정확도를 높이는 데 도움이 됩니다.

4. 제약 조건보다는 지침 사용 (Use Instructions over Constraints) [Critical]

   • 핵심: “OO 하지 마” (제약 조건) 보다는 “OO 해줘” (지침) 방식으로 프롬프트를 작성하는 것이 더 효과적입니다.
   • 이유: 지침은 원하는 결과를 명확히 전달하고 모델에게 유연성과 창의성을 부여하는 반면, 제약 조건은 모델이 무엇을 해야 할지 추측하게 만들거나 잠재력을 제한하고 서로 충돌할 수 있습니다. 긍정적인 지시가 사람에게 더 효과적이듯 모델에게도 마찬가지입니다. (단, 안전, 명확성, 특정 요구사항 등 필요한 경우 제약 조건 사용)

5. 최대 토큰 길이 제어 (Control the max token length) [Moderate]

   • 핵심: 모델 설정에서 최대 출력 토큰 수를 조절하거나, 프롬프트 내에서 원하는 길이를 명시적으로 요청하세요 (예: “트윗 길이로 설명해줘”).
   • 이유: 불필요하게 긴 응답 생성을 막아 비용과 시간을 절약하고, 원하는 간결성을 확보할 수 있습니다.

6. 프롬프트에 변수 사용 (Use variables in prompts) [Moderate]

   • 핵심: 반복적으로 사용되는 정보(예: 도시 이름, 제품명)는 프롬프트 내에 변수 (예: {city}) 로 처리하여 동적으로 값을 변경할 수 있게 하세요.
   • 이유: 프롬프트 재사용성을 높이고, 특히 애플리케이션에 통합할 때 동일한 구조의 프롬프트를 다른 입력값으로 쉽게 활용할 수 있게 해 시간과 노력을 절약합니다. (테이블 20 참고)

7. 입력 형식과 글쓰기 스타일 실험 (Experiment with input formats and writing styles) [Moderate]

   • 핵심: 동일한 목표라도 질문, 서술문, 지시문 등 다양한 프롬프트 형식이나 단어 선택, 스타일 등을 바꿔가며 실험해보세요.
   • 이유: 모델, 설정, 프롬프트 형식 등에 따라 결과가 달라질 수 있으므로, 최적의 결과를 얻기 위해 다양한 시도가 필요합니다.

8. (분류 작업 시) 퓨샷 예시 클래스 섞기 (For few-shot prompting with classification tasks, mix up the classes) [Moderate]

   • 핵심: 분류 작업에서 퓨샷 예시를 사용할 때, 다른 클래스(결과)의 예시들을 무작위 순서로 섞어서 제공하세요.
   • 이유: 특정 순서에 모델이 과적합(overfitting)되는 것을 방지하고, 각 클래스의 핵심 특징을 제대로 학습하여 처음 보는 데이터에 대한 일반화 성능을 높일 수 있습니다. (일반적으로 6개 정도의 예시로 시작 권장)

9. 모델 업데이트에 적응 (Adapt to model updates) [Moderate]

   • 핵심: 사용하는 LLM 모델의 아키텍처 변경, 학습 데이터 추가, 기능 개선 등 업데이트 사항을 주시하고, 필요하면 프롬프트를 조정하여 새로운 기능을 활용하세요.
   • 이유: 모델 성능과 특성이 계속 변하므로, 최신 버전에 맞춰 프롬프트를 최적화해야 최상의 결과를 유지할 수 있습니다. (Vertex AI Studio 같은 도구 활용 권장)

10. 출력 형식 실험 (Experiment with output formats) [Moderate]

    • 핵심: 특히 데이터 추출, 분류, 정렬 등 비창의적인 작업의 경우, 결과물을 JSON이나 XML 같은 구조화된 형식으로 반환하도록 요청하는 것을 고려해보세요.
    • 이유: 항상 일관된 스타일로 결과를 받고, 원하는 데이터에 집중하며, 환각(hallucination) 가능성을 줄이고, 데이터 타입 관리나 정렬 등이 용이해집니다. (테이블 4 참고)

11. JSON 복구 (JSON Repair) [Complex]

    • 핵심: LLM이 JSON 출력을 생성하다가 토큰 제한 등으로 중간에 잘리면 유효하지 않은 JSON이 될 수 있습니다. 이때 json-repair 같은 라이브러리를 사용하여 자동으로 복구를 시도할 수 있습니다.
    • 이유: JSON 형식은 토큰을 많이 소모하여 잘릴 위험이 큰데, 이 라이브러리를 사용하면 불완전하거나 손상된 JSON도 활용 가능하게 만들 수 있어 매우 유용합니다.

12. 스키마 작업 (Working with Schemas) [Complex]

    • 핵심: 출력뿐만 아니라 입력 데이터도 JSON 스키마를 정의하여 구조화하면 LLM의 이해도를 높일 수 있습니다.
    • 이유: 스키마는 LLM에게 기대하는 데이터 구조와 타입을 명확히 알려주어 관련 정보에 집중하게 하고 오해를 줄입니다. 데이터 간 관계 설정이나 날짜/시간 인식 등에도 도움이 됩니다. (스니펫 5, 6 참고)

13. 다른 프롬프트 엔지니어와 함께 실험 (Experiment together with other prompt engineers) [Basic]

    • 핵심: 좋은 프롬프트를 찾는 과정에서 여러 사람이 각자 시도하고 결과를 비교하는 것이 도움이 될 수 있습니다.
    • 이유: 다양한 시각과 접근 방식에서 나온 여러 시도들의 성능 차이를 비교하며 더 나은 프롬프트를 발견할 수 있습니다.

14. CoT 모범 사례 (CoT Best practices) [Complex]

    • 추론 뒤에 답변: 추론 과정이 먼저 나오고 최종 답변이 뒤따르도록 해야 합니다. (추론 과정이 답변 예측에 영향을 주기 때문)
    • 답변 추출 용이성: 생성된 텍스트에서 추론 과정과 최종 답변을 명확히 분리하여 추출할 수 있어야 합니다.
    • 온도 0 사용 권장: CoT는 보통 단일 정답을 찾는 추론 과정이므로, 랜덤성을 최소화하는 온도 0 (Greedy Decoding) 설정이 일반적으로 권장됩니다.

15. 프롬프트 시도 상세히 문서화 (Document the various prompt attempts) [Critical]

    • 핵심: 모든 프롬프트 시도를 이름, 목표, 모델, 설정값, 프롬프트 내용, 결과 등을 포함하여 상세히 기록해야 합니다. (테이블 21 템플릿 활용 권장)
    • 이유: 프롬프트 결과는 모델, 설정, 버전에 따라 달라질 수 있으므로, 기록을 통해 과거 작업 내용을 복기하고, 모델 변경 시 성능을 비교하며, 향후 오류 발생 시 디버깅하는 데 필수적입니다. 자동화된 테스트와 평가 절차를 구축하는 것이 이상적입니다. 프롬프트 엔지니어링은 반복적인 과정이므로 문서화는 매우 중요합니다.

핵심 요약: 이 모범 사례들은 프롬프트의 명확성, 구체성, 효율성을 높이고, 모델의 잠재력을 최대한 활용하며, 작업 과정을 체계적으로 관리하는 데 중점을 둡니다. 특히 예시 제공(퓨샷), 지침 사용, 상세한 문서화는 반복적으로 강조되는 핵심 원칙입니다.