[프롬프트] 프롬프트 엔지니어링이란: Claude 공식 문서가 권하는 순서
같은 Claude에게 더 나은 답을 받는 원리를, Anthropic 공식 문서가 권하는 순서 그대로 정리했습니다.
안녕하세요, muaco입니다.
한 줄로 말하면
같은 Claude에게 비슷한 일을 시켰는데 어떤 날은 쓸 만한 답이 오고 어떤 날은 엉뚱한 답이 옵니다. 모델이 달라진 게 아니라 지시가 달라진 결과입니다. Anthropic 공식 문서는 Claude를 "우리 조직의 규범과 업무 흐름을 모르는, 똑똑하지만 새로 온 직원"으로 생각하라고 적어두었습니다. 원하는 바를 정확히 설명할수록 결과가 좋아진다는 뜻입니다.
문서가 제시한 판별법은 단순합니다. 내 프롬프트를 그 업무를 잘 모르는 동료에게 보여주고 그대로 해보라고 시킵니다. 동료가 헷갈리면 Claude도 헷갈립니다. 문서는 이 문장을 골든 룰이라고 부릅니다.
왜 이런 요령이 필요한가
업무에서 AI가 미끄러지는 자리는 대개 비슷합니다. 보고서 요약을 시켰더니 문체가 사내 양식과 다릅니다. 문의 분류를 시켰더니 어제와 오늘의 기준이 어긋납니다. 표로 달라고 했는데 줄글이 옵니다. 세 경우 모두 모델의 능력이 아니라 지시의 빈칸에서 생깁니다. 빈칸은 모델이 알아서 채우고 알아서 채운 답은 매번 달라집니다.
다만 공식 문서는 반대쪽도 분명히 적어두었습니다. 모든 실패를 프롬프트로 풀려고 하지 말라는 쪽입니다. 문서는 응답 지연과 비용 같은 목표는 다른 모델을 고르는 편이 더 쉬울 때가 있다고 말합니다. 프롬프트로 개선할 수 있는 목표인지 먼저 가려야 합니다.
손대기 전에 갖출 세 가지
문서는 프롬프트를 다듬기 전에 세 가지가 준비돼 있다고 전제합니다. 첫째, 무엇이 성공인지 정의한 기준. 둘째, 그 기준에 맞는지 실제로 시험할 방법. 셋째, 고쳐 나갈 초안 프롬프트입니다. 셋 중 하나라도 없다면 먼저 그 준비부터 하라고 안내합니다.
성공 기준은 SMART 원칙을 따르라고 합니다. 구체적이고 측정 가능하고 달성 가능하고 목적에 맞아야 합니다. 문서가 든 나쁜 예는 "모델이 감성을 잘 분류해야 한다"이고, 좋은 예는 "다양한 트위터 게시물 1만 건을 별도로 떼어둔 평가 세트에서 F1 점수 0.85 이상, 기존 대비 5퍼센트 개선"입니다. 사무 업무로 옮기면 "요약이 자연스러워야 한다" 대신 "A4 반 장 이내, 숫자 오류 0건, 사내 표기 규정 준수"처럼 적습니다.
시험 방법도 거창할 필요는 없습니다. 문서는 실제 업무 분포를 닮게 설계하고 예외 사례를 넣으라고 하며 가능하면 자동 채점을 권합니다. 정답 대조, 임베딩 기반 코사인 유사도, 요약용 ROUGE-L, Claude에게 채점을 맡기는 방식을 예로 듭니다. 문항이 적고 정교한 사람 채점보다, 다소 거칠어도 문항이 많은 자동 채점이 낫다고 적혀 있습니다.
어떻게 굴러가나
분명하고 직접적으로
문서의 비교 예시가 선명합니다. "분석 대시보드를 만들어라" 한 줄과, 여기에 "관련 기능과 상호작용을 가능한 한 많이 넣고, 기본을 넘어 완성된 형태로 구현하라"를 덧붙인 프롬프트를 나란히 놓습니다. 기대 이상의 결과를 원하면 모호한 지시로 모델이 알아서 짐작하게 두지 말고 명시적으로 요청하라고 문서는 말합니다. 순서나 빠짐없음이 중요하면 번호 목록으로 단계를 나눠 적으라는 조언도 함께 있습니다.
이유를 한 줄 붙이기
"말줄임표를 절대 쓰지 마라"보다 "이 답변은 음성 합성 엔진이 소리 내어 읽을 예정이고 엔진이 말줄임표를 어떻게 발음할지 모르니 쓰지 마라"가 낫습니다. 문서는 지시의 배경이나 동기를 알려주면 Claude가 목표를 더 잘 이해하고 그 설명에서 일반화한다고 설명합니다.
예시를 서너 개
예시는 출력 형식과 어조, 구조를 잡는 가장 믿을 만한 방법 중 하나라고 문서는 평가합니다. 조건이 셋입니다. 실제 용례와 닮아야 하고 예외까지 포함해 서로 충분히 달라야 하고 <example> 태그로 감싸 지시문과 구분되어야 합니다. 여러 개일 때는 <examples>로 묶습니다. 권장 개수는 3개에서 5개입니다. 예시가 마땅치 않으면 Claude에게 지금 예시가 적절하고 다양한지 평가시키거나 추가 예시를 만들게 해도 됩니다.
XML 태그로 칸 나누기
XML 태그(꺾쇠로 감싼 이름표)는 지시, 배경, 예시, 그날그날 바뀌는 자료가 한 덩어리로 섞일 때 경계를 그어줍니다. 문서는 종류마다 <instructions>, <context>, <input>처럼 자기 태그를 씌우라고 권합니다. 태그 이름은 프롬프트마다 일관되게 쓰고 자료가 여러 건이면 <documents> 안에 <document index="n">으로 겹쳐 넣습니다.
역할 한 문장
시스템 프롬프트(대화 전체에 걸리는 기본 지시문)에 역할을 정해두면 어조와 판단 기준이 그쪽으로 모입니다. 문서가 든 예는 "You are a helpful coding assistant specializing in Python." 한 문장입니다. 단 한 문장으로도 차이가 난다고 적혀 있습니다.
자료가 길 때
2만 토큰이 넘는 긴 자료를 다룰 때는 배치가 중요합니다. 긴 문서를 프롬프트 위쪽에 두고 질문과 지시, 예시를 그 아래에 둡니다. 문서는 질문을 끝에 두면 응답 품질이 최대 30퍼센트까지 올라갔다는 시험 결과를 언급합니다. 특히 여러 문서를 다루는 복잡한 작업에서 그랬습니다. 그리고 본 작업에 들어가기 전에 관련 대목을 먼저 인용하게 하면 모델이 나머지를 흘려보내고 필요한 데 집중한다고 덧붙입니다.
금지보다 지시로
형식을 잡을 때는 하지 말라는 말보다 하라는 말이 잘 먹힙니다. "마크다운을 쓰지 마라" 대신 "부드럽게 이어지는 산문 문단으로 작성하라"입니다. 프롬프트 자체의 문체를 원하는 출력에 맞추는 방법도 있습니다. 프롬프트에서 마크다운을 걷어내면 답변의 마크다운도 줄어든다고 문서는 설명합니다.
제안이 아니라 실행을 원할 때
최신 모델은 지시를 문자 그대로 따릅니다. "이 함수를 개선할 변경안을 제안해줄래?"라고 물으면 제안만 하고 끝납니다. 실제로 고치길 원한다면 "이 함수의 성능을 개선하도록 수정하라"처럼 동작을 지시해야 한다고 문서는 안내합니다.
언제 쓰고, 언제 손대지 않나
손대지 않을 자리부터 봅니다. 응답이 느리거나 비용이 부담이면 프롬프트를 다듬기 전에 모델 선택을 다시 보는 편이 빠릅니다. 성공 기준과 시험 방법이 없는 상태에서 프롬프트만 만지면 좋아졌는지 나빠졌는지 판단할 근거가 없습니다. 감으로 고치다 처음보다 못한 프롬프트를 붙잡게 됩니다.
과하게 조이는 표현도 이제는 역효과입니다. 문서는 Claude Opus 4.5와 Opus 4.6이 시스템 프롬프트에 더 민감해졌다고 밝힙니다. 예전에 도구 사용을 억지로 끌어내려고 "CRITICAL: You MUST use this tool when..."처럼 썼다면 지금은 "Use this tool when..." 정도로 낮추라고 권합니다.
모델별 차이도 확인이 필요합니다. 공식 문서는 자기가 쓰는 모델의 전용 안내 페이지를 먼저 읽고 공통 기법으로 넘어가라고 순서를 정해두었습니다. 예를 들어 Claude Opus 5는 기본 응답이 이전 세대보다 깁니다. effort 설정을 올리거나 내려도 눈에 보이는 응답 길이가 안정적으로 바뀌지 않으니 짧게 원하면 프롬프트에 직접 적어야 합니다. 이 글은 2026년 9월 4일 기준 공식 문서를 따랐고 문서는 Claude Fable 5.1과 Claude Mythos 5.1까지를 최신 모델로 다룹니다.
한 가지 더 있습니다. Claude 4.6 이후 모델에서는 답변 앞부분을 미리 채워 넣던 프리필 방식이 마지막 어시스턴트 턴에서 지원되지 않고 400 오류를 돌려줍니다. 형식을 강제하려면 구조화 출력 기능이나 태그 지시로 옮기라고 문서가 안내합니다.
첫걸음
오늘 이미 써본 프롬프트 하나를 골라 두 줄만 더해봅니다. 원하는 출력 형식 한 줄, 왜 그 형식이어야 하는지 한 줄입니다. 같은 자료로 다시 돌린 다음 이전 답과 나란히 놓고 봅니다. 차이가 눈에 보이면 예시 세 개를 붙이는 단계로 넘어가면 됩니다. 순서대로 연습하고 싶다면 Anthropic이 공개한 대화형 프롬프트 튜토리얼을 따라가도 좋습니다.
이상으로 글 마치겠습니다.