더 나은 AI 응답을 얻기 위한 Claude 팀의 프롬프트 엔지니어링 기법

컨텍스트 엔지니어링은 LLM을 활용할 때 점점 더 중요해지고 있으며, 그 핵심 구성 요소가 바로 프롬프트 엔지니어링입니다.

프롬프트 엔지니어링은 AI 모델로부터 더 나은 출력을 얻기 위해 지시문을 구조화하는 기술입니다.
질문을 어떻게 표현할지, 스타일을 어떻게 지정할지, 어떤 컨텍스트를 제공할지, 모델의 행동을 어떻게 안내할지 등을 설계해 원하는 목표를 달성하는 일입니다.

애매한 지시와 잘 설계된 프롬프트의 차이는, 평범하고 일반적인 출력과 정확히 내가 필요로 하는 출력 사이의 차이만큼 큽니다.
구조가 엉성한 프롬프트는 의도를 명확히 하기 위해 여러 번 주고받아야 할 수 있는 반면, 잘 설계된 프롬프트는 한 번에 원하는 결과에 가까워지게 해 줍니다.

여기서는 바로 효과를 체감할 수 있도록, 팀에서 사용하는 베스트 프랙티스를 정리했습니다.
먼저 당장 오늘부터 쓸 수 있는 간단한 습관부터 시작해, 이후 복잡한 프로젝트에 유용한 고급 기법까지 확장해 보겠습니다.

쉬운 목차

프롬프트 엔지니어링을 어떻게 활용할까

가장 단순하게 보면, 프롬프트 엔지니어링은 LLM에 전달하는 질문(쿼리)을 수정하는 것입니다.
대부분의 경우 실제 요청 전에 여기에 추가 정보를 붙이는 정도지만,
어떤 정보가 “정말로 필요한 정보인지”를 고르는 것이 좋은 프롬프트를 설계하는 비밀입니다.

핵심 기법

아래 기법들은 효과적인 AI 상호작용의 기초가 됩니다.
이것만 꾸준히 지켜도 응답 품질이 눈에 띄게 좋아집니다.

1. 명확하고 구체적으로 말하기

최신 AI 모델은 명확하고 구체적인 지시에 특히 잘 반응합니다.
모델이 알아서 의도를 눈치챌 거라 기대하지 말고, 원하는 바를 직접 말해 주세요.
애매함 없이, 간단한 언어로 “내가 정확히 무엇을 원하는지”를 적어 주는 것이 좋습니다.

핵심 원칙:
모델에게 보고 싶은 결과를 정확히 말해 주세요.
포괄적인 결과가 필요하다면 “포괄적으로 작성해 달라”고 명시하고,
원하는 기능이나 요소가 있다면 하나하나 나열하세요.
Claude 같은 최신 모델일수록 이런 명시적인 지시에서 더 큰 효과를 냅니다.

예시: 애널리틱스 대시보드 만들기

애매한 요청:

“애널리틱스 대시보드를 만들어줘.”
명확한 요청:

“애널리틱스 대시보드를 만들어줘. 가능한 한 많은 관련 기능과 인터랙션을 포함해 줘. 기본적인 수준을 넘어서, 완성도 높은 풀 기능 구현을 목표로 해줘.”

두 번째 버전은 포괄적인 기능을 원한다는 점과, 최소한이 아니라 한 단계 더 나아간 결과를 기대한다는 신호를 분명히 줍니다.

베스트 프랙티스

“작성해줘, 분석해줘, 생성해줘, 만들어줘” 같은 직접적인 동사로 시작하기
불필요한 서론은 생략하고 곧바로 요청부터 말하기
“무엇을 작업할지”뿐 아니라 “출력에 무엇이 포함되어야 하는지”를 적기
기대하는 깊이와 퀄리티를 명시적으로 써 주기

2. 컨텍스트와 동기를 설명하기

어떤 작업이 왜 중요한지, 왜 필요한지를 설명하면
AI가 목표를 더 잘 이해하고, 그에 맞게 결과를 조정할 수 있습니다.
최신 모델일수록 이런 “목적·의도” 정보를 잘 활용합니다.

예시: 포맷팅 선호도

덜 효과적인 요청:

“절대 글머리 기호 쓰지 마.”
더 효과적인 요청:

“나는 글머리 기호보다는 자연스럽게 이어지는 문단 형식을 선호해. 그런 형식이 더 읽기 편하고 대화하는 느낌이라 좋아. 글머리 기호는 너무 형식적이고 리스트 같아서, 편하게 공부할 때는 잘 안 맞는 것 같아.”

두 번째 버전은 ‘왜 그런 규칙을 원하는지’까지 알려 주기 때문에,
모델이 다른 관련 형식 선택(예: 표, 긴 목록 등)까지 더 잘 판단할 수 있습니다.

컨텍스트를 추가하면 좋은 상황

결과물이 누구를 위한 것인지, 어떤 용도인지 설명할 때
특정 제약 조건이 존재하는 이유를 밝힐 때
결과물을 어떤 방식으로 활용할 계획인지 설명할 때
어떤 문제를 해결하려고 하는지 말해 줄 때

3. 구체적으로 요구하기

“구체적이다”라는 것은, 요구 사항을 명시적인 규칙과 조건으로 풀어 쓰는 것입니다.
원하는 것을 자세히 적을수록 결과가 더 좋아집니다.

예시: 식단 계획

애매한 요청:

“지중해식 식단으로 식단표 만들어줘.”
구체적인 요청:

“당뇨 전 단계 관리용 지중해식 식단 계획을 만들어줘.
하루 1,800kcal 기준, 저혈당지수 식품 위주로 구성해 줘.
아침·점심·저녁·간식 1회씩을 제시하고, 각 식사의 영양 성분을 상세히 적어줘.”

프롬프트가 충분히 구체적인지 확인하는 체크리스트

다음 항목들을 포함해 보세요.

명확한 제약: 글자 수/단어 수, 형식, 기간, 시간 범위 등
관련 있는 컨텍스트: 대상 독자, 목적, 상황
원하는 출력 구조: 표, 목록, 문단, JSON 등
필수 조건/제한 사항: 예산, 식단 제한, 기술적 제약 등

4. 예시를 활용하기

예시는 항상 필요한 것은 아니지만,
설명하기 애매한 포맷이나 스타일을 지정할 때 특히 효과적입니다.
이른바 “원샷(one-shot) / 퓨샷(few-shot) 프롬프트”로,
말로 설명하기 어려운 미묘한 규칙을 보여 줌으로써 전달하는 방법입니다.

중요한 점(최신 모델 기준):
Claude 4.x와 같은 모델은 예시 속 세부 패턴까지 매우 주의 깊게 따라갑니다.
예시에는 원하는 패턴만 넣고, 피하고 싶은 패턴은 최대한 줄이세요.

예시: 기사 요약 스타일 지정

예시 없이:

“이 기사를 요약해줘.”
예시를 포함한 프롬프트:

제가 원하는 요약 스타일의 예시는 아래와 같습니다.

기사: [AI 규제 관련 기사 링크]
요약: EU가 고위험 시스템을 겨냥한 포괄적인 AI 법안을 통과시켰습니다. 핵심 조항에는 투명성 요구 사항과 인간의 감독 의무가 포함됩니다. 2026년 발효 예정입니다.

이제, 아래 기사를 위 요약 스타일과 같은 형식으로 정리해 주세요: [새 기사 링크]

예시를 쓰면 좋은 경우

원하는 형식이 설명보다 보여 주는 것이 쉬울 때
특정한 톤이나 목소리를 맞춰야 할 때
미묘한 패턴·관례가 중요한 작업일 때
단순한 지시만으로는 결과가 일정하게 나오지 않을 때

팁:
처음에는 **예시 1개(원샷)**로 시작하고,
그래도 안 맞으면 그때 **퓨샷(여러 예시)**을 추가하는 식으로 단계적으로 늘려 보세요.

5. “모르겠다”고 말해도 된다고 허용하기

모델이 모르는 내용을 억지로 추측하기보다는,
불확실하면 솔직하게 말하도록 허용하는 문장을 넣어 주세요.
이렇게 하면 환각(hallucination)이 줄고 신뢰도가 올라갑니다.

예시

“이 금융 데이터를 분석해서 트렌드를 찾아줘.
만약 결론을 내리기에 데이터가 충분하지 않다면, 억지로 추측하지 말고 ‘판단하기 어렵다’고 말해줘.”

이 한 줄만 있어도, 모델이 “알 수 없다”는 답을 선택하는 비율이 올라가며
전체 응답이 더 믿을 만해집니다.

👉 Claude에서 바로 시도해 보기

고급 프롬프트 엔지니어링 기법

위의 핵심 습관만으로도 꽤 멀리 갈 수 있지만,
에이전트 솔루션, 복잡한 데이터 구조, 여러 단계로 나뉜 문제를 다루다 보면
좀 더 고급 기법이 필요해집니다.

1. AI의 응답을 ‘미리 채워 넣기(Prefill)’

프리필(prefill)은 AI의 답변을 중간부터 시작하게 하는 기법입니다.
첫 몇 글자나 구조를 미리 써 주어,
포맷·톤·구조를 더 정확히 통제할 수 있습니다.

주로 다음 상황에서 유용합니다.

JSON, XML 같은 엄격한 구조로 출력을 강제할 때
“먼저 인사말을 길게 하지 말고 바로 본론만” 원할 때
특정한 화자/캐릭터의 말투를 유지해야 할 때
응답의 시작을 강하게 통제하고 싶을 때

예시: JSON 출력 강제

프리필 없이 요청하면, Claude가 이렇게 말할 수 있습니다.

“요청하신 JSON은 다음과 같습니다: { … }”

프리필을 사용한 API 예시:

messages = [
    {"role": "user", "content": "이 제품 설명에서 이름과 가격을 추출해 JSON으로 만들어줘."},
    {"role": "assistant", "content": "{"}
]

이렇게 하면 모델은 이미 열려 있는 { 뒤를 이어 작성하면서
유효한 JSON만 출력하려고 합니다.

채팅 UI에서의 대체 방법

API 프리필을 못 쓰는 환경이라면,

“앞부분 설명 없이, 유효한 JSON만 출력해 줘. 응답은 여는 중괄호 {로 시작해.”
처럼 아주 명시적으로 적어 주면 비슷한 효과를 얻을 수 있습니다.

2. 체인 오브 쏘트(Chain-of-thought, CoT) 프롬프트

체인 오브 쏘트는 모델이 답을 내기 전에 단계별 reasoning을 하도록 유도하는 기법입니다.
복잡한 분석 작업에 특히 효과적입니다.

현대적인 접근:
Claude에는 extended thinking 기능이 있어,
이런 구조화된 사고 과정을 자동으로 처리해 줍니다.
이 기능을 쓸 수 있을 때는 기본적으로 extended thinking이 더 편리하지만,
그렇지 못한 환경(무료 플랜 등)에서는 여전히 직접 CoT를 적어 주는 것이 유용합니다.
또, reasoning 과정을 눈으로 검토해야 할 때는 명시적인 CoT가 필요합니다.

체인 오브 쏘트가 유용한 경우

extended thinking을 사용할 수 없을 때 (예: 무료 Claude.ai 플랜)
모델의 추론 과정을 직접 검토해야 할 때
여러 분석 단계를 거치는 복잡한 과제일 때
모델이 특정 요소들을 반드시 고려하게 만들고 싶을 때

체인 오브 쏘트 구현 방식은 크게 세 가지입니다.

기본 CoT (간단 지시)

Care for Kids 프로그램에 대한 후원 요청 이메일을 후원자별로 개인화해서 작성해줘.

프로그램 정보:
<program>
{{PROGRAM_DETAILS}}
</program>

후원자 정보:
<donor>
{{DONOR_DETAILS}}
</donor>

이메일을 쓰기 전에, 먼저 단계별로 생각해 보고 작성해줘.

가이드를 제공하는 CoT

이메일을 쓰기 전에 먼저 생각해 줘.  
먼저, 이 후원자의 기부 이력을 바탕으로 어떤 메시지가 이 사람에게 잘 먹힐지 정리해 줘.  
그 다음, Care for Kids 프로그램 중 이 후원자에게 특히 공감될 만한 부분이 무엇인지 생각해 줘.  
마지막으로, 그 분석 내용을 활용해 개인화된 후원 요청 이메일을 작성해 줘.

구조화된 CoT (태그로 분리)

이메일을 쓰기 전에 <thinking> 태그 안에서 먼저 생각해 줘.  
먼저 이 후원자에게 어필할 메시지 포인트를 분석하고,  
그 다음 프로그램의 어떤 측면을 강조할지 정리해.  
마지막으로, 분석 내용을 바탕으로 <email> 태그 안에 개인화된 이메일을 작성해 줘.

extended thinking 기능이 있더라도,
아주 복잡한 작업에서는 이렇게 명시적인 CoT를 함께 사용하는 것이
추론 과정을 이해하고 검증하는 데 여전히 도움이 됩니다.

3. 출력 형식 통제하기

최신 AI 모델에서는 여러 가지 방식으로 결과 형식을 제어할 수 있습니다.

1) 하지 말아야 할 것보다, 해야 할 것을 말하기

이렇게 말하기보다는:

“마크다운 쓰지 마.”
이렇게 말하는 편이 더 좋습니다:

“응답은 부드럽게 이어지는 문단 형태의 산문으로 작성해 줘.”

2) 원하는 출력 스타일과 프롬프트 스타일을 맞추기

프롬프트에 마크다운을 많이 쓰면,
모델도 마크다운을 많이 사용하는 경향이 있습니다.
따라서 “최소한의 마크다운”을 원한다면
프롬프트 자체도 단순한 텍스트 위주로 작성하는 것이 도움이 됩니다.

3) 형식 선호도를 구체적으로 적기

보고서나 분석을 작성할 때는, 명확하고 읽기 쉬운 문장으로 구성된 문단 형식으로 써 줘.
문단 사이에는 적절한 줄바꿈을 사용해 구조를 나눠 줘.

마크다운은 주로 인라인 코드, 코드 블록, 간단한 제목에만 사용해 줘.

번호 목록이나 글머리 기호 목록은
정말 ‘리스트’가 가장 활용도 높은 경우이거나,
사용자가 명시적으로 요청했을 때만 사용해 줘.

항목을 나열해야 할 때도, 가능하면 문장 안에 자연스럽게 녹여서 표현해 줘.
목표는 독자가 자연스럽게 따라갈 수 있는 흐름 있는 글이 되도록 하는 거야.

4. 프롬프트 체이닝 (Prompt chaining)

프롬프트 체이닝은 앞서 설명한 기법들과 달리,
하나의 프롬프트로 끝낼 수 없는 작업을 여러 단계로 나누는 방식입니다.

복잡한 문제를 작은 작업 단위로 쪼개
각 단계를 별도의 프롬프트로 처리하고,
이전 단계의 출력을 다음 단계 입력으로 넘겨 줍니다.

이 방식은 호출 횟수가 늘어나 성능(지연 시간)을 조금 희생하는 대신,
각 단계의 난도를 낮춰 전체 정확도와 안정성을 올리는 전략입니다.
보통은 워크플로우나 코드로 구현하지만,
손으로도 “1번 질문 → 답 → 2번 질문…” 형태로 직접 진행할 수 있습니다.

예시: 리서치 요약

첫 번째 프롬프트“이 의학 논문을 요약해줘.
연구 방법, 주요 결과, 임상적 시사점을 포함해서 정리해줘.”

두 번째 프롬프트“위 요약이 정확성, 명확성, 완결성 측면에서 어떤지 검토해 줘.
각 항목을 등급으로 평가하고 피드백을 적어줘.”

세 번째 프롬프트“다음 피드백을 바탕으로 요약을 개선해줘: [2단계 피드백]”

각 단계가 한 가지 역할에 집중하기 때문에
전체 결과물이 더 안정적이고 품질도 높아집니다.

프롬프트 체이닝을 고려할 때

한 번에 해결하기엔 요청이 너무 복잡할 때
여러 차례 다듬어야 하는 작업일 때
다단계 분석(요약 → 검토 → 개선 등)이 필요할 때
중간 검증·피드백이 가치 있을 때
한 번에 시키면 결과가 들쭉날쭉할 때

트레이드오프

호출 수가 늘어나 지연 시간은 커지지만,
복잡한 작업에서 정확성과 신뢰도를 크게 개선합니다.

많이 들어봤을 수 있는 기법들

예전 세대 모델에서 유행했던 일부 기법들은
Claude 같은 최신 모델에서는 꼭 필요하지 않을 수 있습니다.
그래도 기존 문서나 예제에서 종종 등장하므로,
언제 유용할 수 있는지 정도는 알고 있으면 좋습니다.

1. XML 태그로 구조 표현하기

과거에는 프롬프트에 많은 정보를 넣을 때
XML 태그를 써서 구조를 명확히 구분하는 것이 권장되곤 했습니다.

지금은 모델들이 구조 이해 능력이 좋아져서
꼭 XML을 쓰지 않아도 상당 부분 잘 처리하지만,
특정 상황에서는 여전히 도움이 될 수 있습니다.

예시

<athlete_information>
- 키: 6'2"
- 몸무게: 180 lbs
- 목표: 근육 증가
- 식단 제한: 채식주의
</athlete_information>

위 운동선수 정보를 바탕으로 식단 계획을 만들어줘.

XML 태그가 아직 유용한 경우

여러 종류의 콘텐츠가 섞인 매우 복잡한 프롬프트일 때
각 블록의 경계를 절대적으로 헷갈리면 안 될 때
구버전 모델을 사용해야 할 때

현대적인 대안

대부분의 경우,
명확한 제목, 공백, “아래 정보를 사용해…” 같은 문장만으로도
충분히 좋은 구조를 전달할 수 있습니다.

2. 롤 프롬프트(Role prompting)

롤 프롬프트는 모델에게 특정 “역할”을 부여해
그 관점에서 답하게 만드는 기법입니다.

“당신은 금융 자문가입니다. 이 투자 포트폴리오를 분석해 주세요…”

와 같은 식이죠.

하지만 최신 모델들은 역할을 지나치게 세세하게 정의하지 않아도
상당히 잘 대응합니다.
너무 과하게 제한하면 오히려 유연성이 떨어질 수 있습니다.

주의할 점

“당신은 세계적으로 유명한 전문가이며 절대 실수하지 않는다…”

처럼 과하게 강한 설정은 모델의 답변을
지나치게 딱딱하고 협소하게 만들 수 있습니다.

롤 프롬프트가 유용한 경우

대량의 결과물에서 일관된 톤과 캐릭터를 유지해야 할 때
특정 앱에서 고정된 페르소나를 구현해야 할 때
복잡한 도메인에 대해 “전문가 관점”을 강조하고 싶을 때

현대적인 대안

단순히 역할을 지정하기보다는,

“이 포트폴리오를 분석하되, 위험 허용도와 장기 성장 가능성에 초점을 맞춰줘.”

처럼 무엇을 중점적으로 볼지를 구체적으로 적어 주는 편이
실제 결과에는 더 도움이 되는 경우가 많습니다.

👉 Claude에서 직접 시도해 보기

모든 기법을 합쳐 보기

지금까지는 개별 기법만 봤지만,
실제 힘은 여러 기법을 상황에 맞게 조합할 때 나옵니다.

중요한 점은,
“쓸 수 있는 기법을 전부 넣는 것”이 아니라
현재 문제에 필요한 것만 선택하는 것입니다.

여러 기법을 조합한 예시

이 분기 보고서에서 핵심 재무 지표만 추출해서 JSON 형식으로 정리해줘.

이 데이터는 자동 처리 파이프라인에서 사용할 예정이기 때문에,
응답에는 설명 없이 **유효한 JSON만** 포함되어야 해.

구조는 아래를 사용해줘:
{
  "revenue": "값 + 단위",
  "profit_margin": "퍼센트 값",
  "growth_rate": "퍼센트 값"
}

어떤 지표가 보고서에 명확히 적혀 있지 않다면
추측하지 말고 null을 사용해줘.

응답은 여는 중괄호 { 로 시작해줘.

이 프롬프트에는 다음 요소들이 결합되어 있습니다.

무엇을 추출할지에 대한 명시적 지시
왜 형식이 중요한지에 대한 컨텍스트
원하는 출력 구조에 대한 예시
불확실할 때는 null을 사용하라는 명시적 허용
응답은 {로 시작하라는 형식 통제

어떤 기법을 언제 쓸까

모든 프롬프트에 모든 기법이 필요한 것은 아닙니다.
아래와 같은 흐름으로 생각해 볼 수 있습니다.

내 요청이 충분히 명확하고 구체적인가?
→ 아니라면, 먼저 명확성부터 다듬기
작업이 단순한가?
→ 단순하면 기본 기법(명확성, 구체성, 컨텍스트)만으로 시작
특정 형식(JSON, 표 등)이 꼭 필요한가?
→ 예시나 프리필 활용
작업이 복잡한가?
→ 여러 단계로 쪼개는 체이닝 고려
추론 과정이 중요한가?
→ extended thinking 또는 CoT 활용

자주 발생하는 문제와 해결법

프롬프트를 잘 짰다고 생각해도, 예상 밖의 결과가 나올 수 있습니다.
아래는 흔한 문제와 그에 대한 해결 전략입니다.

문제: 응답이 너무 범용적이다
→ 해결: 더 구체적인 조건·예시를 추가하고,
“기본 수준을 넘어 한 단계 더 나아가 달라”고 명시적으로 요청하기
문제: 주제에서 벗어나거나 핵심을 놓친다
→ 해결: 내가 실제로 달성하고 싶은 목표를 더 명확히 설명하고,
“왜 이 질문을 하는지” 컨텍스트를 추가하기
문제: 응답 형식이 매번 다르다
→ 해결: 예시(퓨샷)를 추가하거나,
프리필로 응답 시작 부분을 강하게 통제하기
문제: 작업이 너무 복잡해서 결과가 불안정하다
→ 해결: 여러 단계로 나누어 프롬프트 체이닝 적용.
각 단계는 한 가지 일만 잘하게 설계하기
문제: 필요 없는 서론·인사·설명이 길게 붙는다
→ 해결: “서론 없이 바로 핵심부터 답해줘.” 또는 프리필을 활용
문제: 모델이 사실이 아닌 내용을 지어낸다
→ 해결: “불확실할 때는 ‘모르겠다’고 말해줘.”를 명시적으로 넣기
문제: 코드·문서에서 ‘변경을 제안’만 하고 실제 구현은 안 한다
→ 해결: “변경을 제안해줘.”가 아니라
“이 함수를 직접 수정해줘.”처럼 행동을 명확히 요구하기

팁:
항상 단순한 버전부터 시작하고, 필요할 때만 조금씩 복잡도를 올리면서
각 추가 요소가 실제로 결과를 개선하는지 확인해 보세요.

자주 하는 실수

다음 실수들을 피하면 시간을 많이 아낄 수 있습니다.

과도하게 복잡한 프롬프트 만들기
→ 길고 복잡하다고 항상 좋은 것은 아닙니다.
기본기를 무시하고 고급 기법부터 쓰기
→ 프롬프트가 애매하면, 어떤 고급 기법도 효과가 떨어집니다.
모델이 알아서 다 이해할 거라고 생각하기
→ 원하는 것을 구체적으로 말해 주지 않으면, 모델이 임의로 해석합니다.
모든 기법을 한 번에 다 쓰려고 하기
→ 지금 겪는 문제를 해결하는 데 필요한 것만 선택하세요.
한 번에 완벽한 프롬프트를 기대하기
→ 처음 시도는 대개 조정이 필요합니다. 실험과 반복이 당연합니다.
예전 세대 모델 기준 기법만 고집하기
→ XML 태그, 과도한 롤 프롬프트 등은 최신 모델에선 필수가 아닙니다.
먼저 “명확한 지시 + 컨텍스트”부터 시도해 보세요.

프롬프트 엔지니어링 시 유의할 점

긴 컨텍스트를 다룰 때

고급 기법을 쓰다 보면,
예시·여러 단계의 프롬프트·상세 지시 등으로 인해
토큰 사용량(컨텍스트 길이)이 많이 늘어날 수 있습니다.

따라서 “이 정도 복잡도를 쓸 만한 가치가 있는 상황인지”를 고민하는 것이 중요합니다.

긴 컨텍스트를 다루는 법과 관련해서는
컨텍스트 엔지니어링 가이드를 참고할 수 있습니다.

컨텍스트 인식 능력 향상

Claude 4.x를 포함한 최신 모델들은
과거의 “중간 내용은 잘 못 본다(lost-in-the-middle)” 문제를 많이 개선해,
긴 문맥도 더 균형 있게 참조할 수 있습니다.

그래도 작업 분할이 여전히 도움이 되는 이유

컨텍스트 한계를 보완하기 위해서뿐 아니라,
각 작업 단위를 더 선명하게 만들기 위해서
큰 문제를 작은 문제들로 쪼개는 전략은 여전히 유효합니다.

범위가 뚜렷한 작은 작업일 때,
모델이 낼 수 있는 최고의 품질을 끌어내기 쉬워집니다.

전략

긴 컨텍스트를 다룰 때는 중요한 정보를
앞부분이나 뒷부분에 배치하고 구조를 명확히 나누기
과제가 복잡할수록,
“몇 개의 더 작은 과제로 쪼개면 좋을까?”를 먼저 생각해 보기

좋은 프롬프트란 무엇인가?

프롬프트 엔지니어링은 결국 연습으로 익히는 기술입니다.
처음부터 완벽하게 할 수 있는 사람은 없습니다.

가장 빠른 방법은 직접 써 보고 비교해 보는 것입니다.
동일한 작업을 “아무 생각 없이 한 줄로 요청한 경우”와
“여기서 배운 기법들을 조금씩 적용한 경우”를 비교해 보면
차이가 바로 보일 것입니다.

좀 더 실력을 갈고닦으려면,
프롬프트의 효과를 객관적으로 평가하는 기준이 필요합니다.
이 부분은 anthropic.skilljar.com의
프롬프트 엔지니어링 강의에서 자세히 다룹니다.

간단한 평가 체크리스트

출력이 내가 지정한 요구 사항을 충족하는가?
한 번에 원하는 결과가 나왔는가, 여러 번 시도해야 했는가?
여러 번 반복해도 형식과 톤이 일관되는가?
위에서 소개한 “흔한 오류”들을 잘 피하고 있는가?

마무리 조언

프롬프트 엔지니어링은 궁극적으로
AI가 내 의도를 명확하게 이해하도록 돕는 ‘커뮤니케이션 기술’입니다.

먼저 이 글 앞부분에서 다룬 핵심 기법들을 꾸준히 사용해 보세요.
그러다 부족한 부분이 보일 때,
그때그때 필요한 고급 기법을 얹어 가는 방식이 좋습니다.

중요한 점은,
“가장 길고 복잡한 프롬프트”가 아니라
최소한의 구조로, 가장 안정적으로 목표를 달성하는 프롬프트라는 것입니다.

컨텍스트 엔지니어링이 중요해지고 있지만,
프롬프트 엔지니어링의 중요성이 줄어드는 것은 아닙니다.
오히려 프롬프트는 컨텍스트 엔지니어링을 구성하는
기본 단위라고 볼 수 있습니다.

잘 설계된 프롬프트 하나하나가
대화 기록, 첨부 파일, 시스템 지시 등과 함께
AI의 행동을 형성하는 전체 컨텍스트의 일부가 되어
더 나은 결과를 끌어냅니다.

추가 자료

출처: https://www.claude.com/blog/best-practices-for-prompt-engineering