묻는 법을 바꾸면 무엇이 달라지나
고객센터의 «Introduction to prompt design» 문서는 클로드를 «새로 고용한 계약자»처럼 생각하라고 권한다. 계약자는 일솜씨는 있지만 묻는 사람이 누구인지, 무슨 일을 하는지, 회사가 어떤 곳인지는 전혀 모른다는 뜻이다. 개발자 문서의 표현도 같다. 클로드를 «뛰어나지만 막 입사해서 우리 쪽 규칙과 일하는 방식을 모르는 직원»으로 보라고 하고, 원하는 것을 정확히 설명할수록 결과가 좋아진다고 적었다.
이 비유를 받아들이면 왜 짧은 질문이 뻔한 답을 부르는지 이해가 된다. «보고서 요약해 줘»라는 말만 들은 새 직원은 누가 읽을 요약인지, 몇 줄이면 되는지, 숫자를 남겨야 하는지 알 수 없다. 그러니 무난하고 평균적인 요약을 내놓는다. 틀린 것은 아니지만 바로 쓰기는 어렵다. 같은 직원에게 «부장님 보고용, 다섯 줄, 비용 숫자는 그대로, 결정할 것 하나를 맨 위에»라고 말하면 결과가 달라진다. 클로드도 마찬가지다.
공식 문서가 권하는 것을 한 문장으로 줄이면 «사람 동료에게 일을 넘길 때 하는 설명을 그대로 적으라»는 것이다. 개발자 문서는 이것을 «황금률(Golden rule)»이라 부르며 시험 방법까지 제시한다. 쓴 프롬프트를 이 일에 대해 아는 것이 거의 없는 동료에게 보여 주고 그대로 따라 해 보라고 했을 때, 그 동료가 헷갈려 한다면 클로드도 헷갈린다는 것이다.
특별한 주문 문구를 외울 필요는 없다. 고객센터 문서는 클로드에게 평범한 영어로 대화하듯 지시하면 된다고 적었고, 시작 안내는 클로드가 영어로 폭넓게 학습했고 다른 여러 흔한 언어에서도 잘 동작한다고 밝힌다. 한국어로 물어도 된다. 원칙은 말투가 아니라 «빠진 정보가 없게 설명하기»에 있다.
손보기 전에 정해 둘 것
개발자 문서의 개요 페이지는 프롬프트를 고치기 전에 세 가지를 갖추라고 한다. 이 일에서 무엇이 «성공»인지에 대한 분명한 기준, 그 기준에 맞는지 확인할 방법, 고쳐 나갈 첫 초안이다. 원래는 개발자가 서비스용 프롬프트를 다듬을 때를 위한 말이지만, 채팅에서도 그대로 통한다. «다섯 줄 안에, 결정할 것이 맨 위에 오면 성공»처럼 기준을 먼저 정해 두면, 답을 보고 무엇을 고쳐 달라고 할지도 바로 보인다.
같은 페이지는 모든 문제를 프롬프트로 풀 수는 없다는 점도 짚는다. 예를 들어 답이 느리거나 비용이 큰 문제는 다른 모델을 고르는 편이 더 쉬울 때가 있다고 적었다. 질문을 아무리 고쳐도 안 되는 일이 있다는 것을 알아 두면, 같은 질문을 붙잡고 오래 씨름하는 일을 줄일 수 있다. 모델 고르기는 이 시리즈 마지막 편에서 따로 다룬다.
공식 문서가 꼽는 기본 원칙 여섯 가지
«Prompting best practices»의 «General principles(일반 원칙)» 절과 «Output and formatting(출력과 형식)» 절, 고객센터 문서와 블로그 글을 겹쳐 보면 처음 쓰는 사람이 챙길 원칙은 여섯 가지로 모인다. 각 원칙 아래에는 문서가 든 예를 우리말로 옮기고, 회사에서 쓰는 장면으로 바꾼 예를 덧붙였다.
원칙 1 — 분명하고 직접적으로, 원하는 수준까지 적는다
문서는 클로드가 분명하고 명시적인 지시에 잘 반응하고, 원하는 결과를 구체적으로 적을수록 결과가 좋아진다고 쓴다. 눈여겨볼 대목은 «기대 이상»을 원할 때다. 막연한 질문에서 클로드가 알아서 더 해 주기를 바라지 말고, 더 해 달라고 직접 적으라고 한다. 문서의 예는 이렇다.
- 덜 효과적: «분석 대시보드를 만들어 줘»
- 더 효과적: «분석 대시보드를 만들어 줘. 관련 기능과 상호작용을 되도록 많이 넣고, 기본을 넘어 완성도 있게 구현해 줘»
같은 절은 출력 형식과 제약을 구체적으로 적고, 순서나 빠짐없음이 중요한 지시는 번호 목록이나 글머리표로 단계를 나눠 주라고 덧붙인다. 고객센터의 시작 안내도 처음 쓰는 사람에게 «구체적으로 요청할수록 더 잘 도울 수 있다»고 적었다.
원칙 2 — 지시에 이유를 붙인다
두 번째 원칙은 «왜»를 함께 적는 것이다. 문서는 지시 뒤에 있는 맥락이나 동기, 곧 그 행동이 왜 중요한지를 설명하면 클로드가 목표를 더 잘 이해하고 더 겨냥한 답을 낸다고 적었다. 문서의 예가 이 원칙을 잘 보여 준다.
- 덜 효과적: «말줄임표를 절대 쓰지 마»
- 더 효과적: «이 답은 음성 합성 엔진이 소리 내어 읽을 거야. 엔진이 말줄임표를 어떻게 읽을지 모르니 말줄임표는 쓰지 마»
문서는 이유를 들은 클로드가 그 설명에서 일반화할 만큼 똑똑하다고 덧붙인다. 이유를 알면 말줄임표뿐 아니라 소리 내어 읽기 어려운 다른 기호도 알아서 피한다는 뜻이다. 회사 일로 바꾸면 «표로 정리해 줘»보다 «이 내용을 메신저에 붙여 넣을 거라 표가 깨져. 표 대신 짧은 줄로 정리해 줘»가 낫다. 고객센터 문서도 주제를 전혀 모르는 사람에게 쓰듯 배경을 되도록 많이 넣으라고 권한다.
원칙 3 — 말로 설명하기 어려우면 예시를 보여 준다
원하는 형식 · 어투 · 짜임을 말로 다 설명하기 어렵다면 예시가 빠르다. 문서는 예시를 클로드의 출력 형식 · 어투 · 구조를 이끄는 가장 믿을 만한 방법 가운데 하나로 꼽고, 잘 만든 예시 몇 개가 정확도와 일관성을 높인다고 적었다. 예시를 넣을 때 지킬 점은 셋이다.
- 실제 일과 닮게: 쓰려는 장면과 가까운 예를 고른다.
- 다양하게: 비슷한 예만 넣으면 클로드가 의도하지 않은 버릇까지 따라 할 수 있으니 조금씩 다른 예를 섞는다.
- 구분되게: 예시를 지시문과 섞지 말고 따로 묶는다. 문서는 example 태그로 감싸라고 권한다.
개수에 대해서는 문서가 3~5개를 넣으면 가장 좋은 결과를 얻는다고 적었다. 블로그 글은 하나로 시작하고 필요할 때만 늘리라고 권한다. 두 말을 합치면 «하나로 시작해서, 형식이 계속 흔들리면 3~5개까지»가 된다. 블로그 글은 클로드가 예시를 아주 꼼꼼히 따라 하므로 예시에 원하지 않는 버릇이 섞이지 않게 하라고도 경고한다.
원칙 4 — 형식은 «하지 말 것»보다 «할 것»으로 적는다
형식 지시에서 가장 흔한 실수는 금지만 적는 것이다. 문서는 형식을 이끄는 효과적인 방법 첫째로 «하지 말아야 할 것 대신 해야 할 것을 말하라»를 든다. «답에 마크다운을 쓰지 마» 대신 «답은 매끄럽게 이어지는 문단으로 써 줘»라고 적는 식이다. 블로그 글도 같은 예를 들어 같은 권고를 한다.
둘째로 문서는 질문의 문체를 원하는 답의 문체에 맞추라고 한다. 질문에 쓴 형식이 답의 형식에 영향을 줄 수 있어서, 질문에서 마크다운을 빼면 답의 마크다운도 줄어든다는 설명이다. 글머리표로 잔뜩 쪼갠 질문을 보내면 글머리표로 쪼갠 답이 돌아오기 쉽다는 뜻이기도 하다. 줄글 보고서를 원한다면 질문도 줄글로 적는 편이 낫다.
원칙 5 — 긴 자료는 위에, 질문은 맨 아래에
긴 문서를 붙여 넣고 묻는 일이 많다면 이 원칙의 효과가 크다. 문서는 2만 토큰이 넘는 긴 자료를 다룰 때 자료를 질문 · 지시 · 예시보다 위, 곧 프롬프트 앞쪽에 두라고 한다. 질문을 끝에 두면 시험에서 답의 품질이 최대 30%까지 좋아졌고, 특히 여러 문서가 섞인 복잡한 입력에서 그랬다고 적었다. 이 수치는 Anthropic이 문서에 밝힌 내부 시험값이고, 모든 질문에서 같은 폭으로 좋아진다는 뜻은 아니다.
같은 절에는 긴 문서를 다룰 때 쓸 만한 요령이 하나 더 있다. 일을 시키기 전에 문서에서 관련 있는 대목을 먼저 인용해 뽑게 하는 것이다. 문서는 이렇게 하면 클로드가 관련 내용에 집중하고 나머지는 걸러 낸다고 설명한다. 계약서나 긴 규정에서 답을 찾을 때 «먼저 관련 조항을 그대로 옮겨 적고, 그다음 그 조항만 근거로 답해 줘»라고 적으면 답과 근거를 함께 대조할 수 있어 확인이 쉬워진다.
여러 자료를 한 번에 넣을 때는 자료마다 이름표를 붙이면 덜 섞인다. 문서는 지시 · 맥락 · 예시 · 입력이 섞인 복잡한 프롬프트에서 각 내용을 instructions · context · input 같은 XML 태그(꺾쇠 괄호로 감싼 이름표)로 나누면 잘못 읽는 일이 줄어든다고 적었다. 다만 블로그 글은 지금의 모델은 분명한 제목 · 빈 줄 · 명시적인 말만으로도 충분한 경우가 많고, 태그는 복잡하거나 섞인 내용에서 여전히 도움이 된다고 정리했다. 채팅에서는 «자료 1 — 회의록», «자료 2 — 예산표»처럼 제목만 달아도 된다.
원칙 6 — 큰 일은 나누고, 첫 답은 초안으로 본다
복잡한 요청은 한 번에 다 시키지 말고 작은 단계로 나누라는 것이 고객센터 문서의 권고다. 개발자 문서는 이것을 «프롬프트 연결(chaining)»으로 설명하는데, 가장 흔한 모양은 초안 만들기 → 기준에 맞춰 검토하기 → 검토를 바탕으로 고치기다. 채팅에서는 세 메시지로 나눠 보내면 된다. 첫 메시지로 초안을 받고, 둘째 메시지로 «이 초안을 아래 기준으로 검토해 줘», 셋째 메시지로 «검토한 대로 고쳐 줘»를 보낸다.
첫 답이 마음에 들지 않는 것은 실패가 아니다. 블로그 글은 첫 프롬프트가 한 번에 완벽하게 맞는 일은 드물다며 시험하고 고치라고 적었고, 고객센터의 시작 안내도 프롬프트를 고쳐 보거나 이어서 묻는 것을 망설이지 말라고 권한다. 답이 빗나가면 이어서 묻거나, 설명을 더 해 달라거나, 다시 써 달라고 요청하라는 것이 고객센터 문서의 안내다.
원칙을 다 넣으려다 질문이 길어지는 것도 흔한 실수다. 블로그 글은 길고 복잡한 프롬프트가 늘 더 낫지는 않다고 못 박고, 간단하게 시작해서 필요할 때만 복잡하게 만들라고 권한다. 짧은 질문으로 답이 충분하면 거기서 멈추면 된다.
질문 틀 다섯 칸 — 보내기 전 순서
여섯 원칙을 매번 떠올리기는 어렵다. 그래서 회사 일에 쓰는 질문을 보내기 전에 아래 다섯 칸을 순서대로 채워 보는 방법을 권한다. 칸 이름은 이 글에서 붙인 것이고, 각 칸의 근거는 위 원칙과 공식 문서 문장이다.
- 목표와 이유. 무엇을 만들어야 하고, 그것을 왜 · 어디에 쓰는지 적는다. 이유가 있으면 클로드가 그 설명에서 일반화해 맞는 선택을 한다.
- 배경. 읽을 사람이 누구인지, 지금 어떤 상황인지 적는다. 주제를 모르는 사람에게 쓰듯 배경을 넣으라는 것이 고객센터 문서의 권고다.
- 자료. 붙여 넣을 자료가 길면 질문보다 위에 두고, 자료가 여럿이면 이름표를 붙인다.
- 형식. 분량 · 짜임 · 어투를 «할 것»으로 적는다. 말로 설명하기 어렵다면 예시를 하나 붙인다.
- 확인. 자료로 확인할 수 없는 것은 모른다고 말해도 된다고 적고, 끝내기 전에 기준에 맞는지 스스로 점검하게 한다.
다섯 칸을 채운 질문의 예는 다음과 같다. 회의록을 상사 보고용 요약으로 바꾸는 장면이다.
[자료 — 회의록]
(회의록 전문을 여기에 붙여 넣기)
[요청]
위 회의록을 팀장 보고용으로 요약해 줘.
팀장은 회의에 들어오지 않았고, 이 요약만 보고 다음 주 일정을 정할 거야.
[형식]
- 맨 위 한 줄: 팀장이 결정해야 할 것
- 그다음 다섯 줄 이내: 합의된 것, 아직 안 정해진 것, 담당자
- 회의록에 나온 날짜와 숫자는 바꾸지 말고 그대로 옮겨 줘
[확인]
회의록에 없는 내용은 지어내지 말고 «회의록에 없음»이라고 적어 줘.
끝내기 전에 위 형식을 지켰는지 한 번 점검해 줘.이 예에서 «팀장은 회의에 들어오지 않았고»는 배경, «이 요약만 보고 다음 주 일정을 정할 거야»는 이유다. 둘이 들어가면 클로드는 회의 분위기나 잡담 대신 결정과 일정에 무게를 둔다. «날짜와 숫자는 그대로»는 형식 칸에서 «할 것»으로 적은 제약이다.
확인 칸이 왜 필요한가
블로그 글은 클로드가 짐작하는 대신 불확실하다고 말해도 된다고 명시적으로 허락하라고 권한다. 자료가 부족할 때 그렇다고 말하게 하면 그럴듯하게 지어낸 답이 줄어든다는 취지다. 개발자 문서는 «끝내기 전에 이 기준에 맞는지 답을 확인해 줘» 같은 문장을 덧붙이면 특히 코드와 계산에서 실수를 잘 잡아낸다고 적었다. 같은 문서는 일부 모델은 시키지 않아도 스스로 확인을 잘해서 이런 지시가 오히려 군더더기가 될 수 있다고도 밝혔다. 확인 문장은 짧게 한 줄이면 충분하다.
일 종류별 예시 — 메일 · 표 · 긴 문서 · 실행 요청
원칙을 실제 질문으로 바꾼 예를 일 종류별로 모았다. 왼쪽은 흔히 보내는 짧은 질문, 오른쪽은 원칙을 적용해 고친 질문이다. 답의 내용은 쓰는 모델과 자료에 따라 달라지므로 여기서는 질문 쪽만 비교한다.
| 일 | 흔한 질문 | 고친 질문 | 적용한 원칙 |
|---|---|---|---|
| 메일 다듬기 | 이 메일 다듬어 줘 | 거래처 담당자에게 납기 지연을 알리는 메일이야. 사과는 한 번만, 새 납기와 대안 두 가지를 분명하게. 존댓말, 본문은 짧게 | 목표 · 배경 · 형식 |
| 표 만들기 | 이거 표로 정리해 줘 | 아래 출장비 메모를 날짜 · 항목 · 금액 · 비고 네 칸 표로. 금액은 원문 그대로, 합계 줄을 맨 아래에 | 형식을 «할 것»으로 |
| 긴 문서 묻기 | (질문 먼저 쓰고 문서를 뒤에 붙임) | 문서를 먼저 붙이고 맨 아래에 질문. 답하기 전에 관련 조항을 그대로 옮겨 적고 그 조항만 근거로 답하게 | 긴 자료는 위에 · 인용 먼저 |
| 같은 형식 반복 | 보고서 양식대로 써 줘 | 앞서 쓴 보고서 한 편을 예시로 붙이고 «이 짜임과 어투로, 아래 새 메모를 바탕으로» | 예시 |
| 고쳐 달라는 일 | 이 문장 좀 개선할 점 있어? | 이 문장을 더 짧게 고쳐서 고친 문장만 보여 줘 | 제안 대신 실행 요청 |
마지막 줄은 개발자 문서의 «Tool usage(도구 사용)» 절에 나오는 원칙을 채팅으로 옮긴 것이다. 문서는 «바꿀 점을 제안해 줄 수 있어?»라고 물으면 실제로 바꾸기를 원했더라도 클로드가 제안만 하는 경우가 있다며, 행동을 원하면 «이 함수를 바꿔서 성능을 높여 줘»처럼 직접 적으라고 한다. 원래 코드를 고치는 예지만, 문서나 메일을 다듬을 때도 같다. 제안 목록이 아니라 고친 결과물이 필요하면 그렇게 적는다.
역할을 줄 때
개발자 문서는 시스템 프롬프트에 역할을 정해 두면 클로드의 행동과 어투가 그 쓰임에 맞춰진다며, 한 문장만으로도 차이가 난다고 적었다. 시스템 프롬프트는 API에서 대화 전체에 깔리는 지시를 넣는 칸이다. 블로그 글은 역할을 너무 좁게 묶기보다 원하는 관점을 직접 말하는 편이 낫다고 덧붙였다. 채팅에서는 «너는 20년 차 회계사야» 같은 역할극보다 «회계를 모르는 영업팀 사람이 읽을 거라, 용어는 풀어서 설명해 줘»처럼 관점과 독자를 적는 쪽이 이 권고에 가깝다. 매번 같은 지시를 반복하지 않고 저장해 두는 방법(프로젝트 · 스타일 · 개인 설정)은 시리즈 4번째와 8번째 글에서 다룬다.
같이 읽을 글
일을 프롬프트로 시킬지, 에이전트(스스로 여러 단계를 처리하는 AI)에게 맡길지 가르는 기준은 AI에게 일 시키기 — 프롬프트로 시킬 때와 에이전트에게 맡길 때에 따로 정리했다. 글쓰기 · 업무 자동화에 클로드를 쓰는 장면별 예는 Claude Sonnet 실전 활용법에, 다른 AI와 어떤 일을 나눠 맡길지는 Claude vs ChatGPT 비교에 있다.
답이 마음에 안 들 때 — 증상별로 고치기
답이 빗나갈 때 무엇을 고칠지는 증상마다 다르다. 블로그 글의 문제 해결 목록과 개발자 문서 · 고객센터 문서의 권고를 증상별로 묶으면 다음과 같다.
| 증상 | 먼저 해 볼 것 | 근거 |
|---|---|---|
| 답이 뻔하고 평범하다 | «기본을 넘어서»처럼 원하는 수준을 직접 적는다 | 기대 이상은 직접 요청 |
| 묻는 것과 엉뚱한 답이 온다 | 목표와 그 이유를 적는다 | 맥락 · 동기 더하기 |
| 형식이 매번 다르다 | 원하는 결과의 예시를 하나 붙인다 | 예시가 형식을 가장 잘 이끔 |
| 답이 너무 짧거나 중간에 끊긴다 | 앞 질문과 답을 다음 질문에 붙여 이어 쓰게 한다 | 고객센터 «too brief» 문서 |
| 그럴듯하게 지어낸 것 같다 | 모르면 모른다고 해도 된다고 적고, 근거 대목을 먼저 인용하게 한다 | 불확실성 허락 · 인용 먼저 |
| 바꿔 달랬는데 제안만 한다 | «고쳐서 결과만 보여 줘»처럼 행동으로 적는다 | 제안 대신 실행 요청 |
| 머리말 인사가 길다 | 서론 없이 바로 답하라고 적는다 | 블로그 문제 해결 목록 |
답이 짧거나 끊길 때
고객센터의 «Claude's response to my prompt is too brief» 문서는 컨텍스트 창(context window — 대화 하나에서 다룰 수 있는 분량)이 사용자가 보낸 질문에 적용되는 것이고 클로드가 만드는 출력에 적용되는 것이 아니라고 설명한다. 그래서 답이 너무 짧거나 일부만 나왔다면 질문을 고치라는 것이 이 문서의 권고다. 끊긴 답을 이어 받으려면 앞의 질문과 답을 다음 질문에 함께 넣어 이어 쓰게 하라고 권한다. 분량이 중요한 일이라면 처음부터 «항목마다 세 문단씩»처럼 길이를 «할 것»으로 적어 두는 편이 낫다.
한 번에 하나씩 바꾼다
증상이 여럿이어도 처방은 하나씩 바꿔 보는 편이 좋다. 블로그 글은 모든 기법을 한꺼번에 쓰는 것을 흔한 실수로 꼽고, 간단하게 시작해서 필요할 때만 복잡하게 만들라고 권한다. 예시도 붙이고, 역할도 주고, 형식도 바꾸고, 확인 문장도 넣은 질문이 좋은 답을 냈다면 무엇이 효과였는지 알기 어렵다. 다음에 비슷한 일을 할 때 다시 쓸 수 있는 것은 효과를 확인한 한 가지다.
같은 대화에서 고칠까, 새 대화를 열까
답이 빗나간 대화에서 계속 고쳐 묻는 것이 늘 좋은 것은 아니다. 고쳐 묻기가 몇 번 쌓이면 대화가 길어지고, 긴 대화는 사용량을 더 쓴다. 이럴 때는 지금까지 알게 된 조건을 한 메시지로 정리해서 새 대화에 다시 보내는 편이 깔끔하다. 고객센터의 한도 아끼기 문서도 관련 질문을 한 메시지에 묶고, 보내기 전에 한 번 읽고 고쳐 덧붙이는 메시지를 줄이라고 권한다.
노력 수준 · 한도 · 회사 자료 — 알아 둘 주의
노력 수준을 올리기 전에 질문부터
질문을 고치는 것과 별개로, 클로드가 답에 얼마나 공을 들일지 정하는 «노력 수준(effort)» 설정이 있다. 고객센터 문서에 따르면 모델 메뉴는 보내기 버튼 옆에 있고, 노력 수준은 Low · Medium · High · Extra high · Max 다섯 단계이며, 모델마다 권장 수준에 «Default» 표시가 붙는다. 대화 중에 바꾸면 다음 답부터 적용된다.
같은 문서는 노력 수준을 높이면 답이 더 꼼꼼해지지만 더 오래 걸리고 토큰을 더 써서 사용 한도에 더 빨리 닿는다고 적었다. 답이 얕다고 느낄 때 노력 수준부터 올리면 한도가 먼저 닳는다. 앞의 원칙대로 목표 · 이유 · 형식을 먼저 채워 보고, 그래도 깊이가 부족할 때 올리는 순서가 한도를 아끼는 길이다. 사용 한도가 어떻게 계산되고 언제 다시 채워지는지는 시작 글의 한도 절에 정리해 두었다.
원칙이 모든 모델에 같은 폭으로 통하지는 않는다
개발자 문서는 모델마다 따로 프롬프트 안내 페이지를 두고, 어느 모델이 어떤 지시에 다르게 반응하는지를 적어 두었다. 일반 원칙 절에서도 특정 모델 이름이 붙은 기법은 그 모델에서 잰 것으로 보고, 다른 모델에 쓰기 전에 다시 확인하라고 적었다. 채팅 사용자에게 이 말은 «모델을 바꿨더니 같은 질문의 답이 달라졌다»가 이상한 일이 아니라는 뜻이다. 자주 쓰는 질문이 있다면 모델을 바꿀 때 한 번 다시 돌려 보고 결과를 확인한다.
회사 일에 쓸 때 지킬 것
좋은 질문은 자료를 많이 넣는 질문이기도 해서, 회사 일에 쓸 때는 넣는 자료를 먼저 고른다. 고객 정보 · 사내 기밀 · 개인 정보가 든 자료를 개인 계정에 넣어도 되는지는 질문 기술이 아니라 회사 규정이 정한다. 또 원칙을 잘 지킨 질문이라도 답이 틀릴 수 있다. 수치 · 날짜 · 법규 · 고유명사처럼 틀리면 곤란한 것은 원문과 대조한 뒤에 쓴다. 앞에서 본 «관련 대목 먼저 인용하기»와 «모르면 모른다고 허락하기»는 이 대조를 쉽게 만드는 장치다.
이 글의 예시 질문을 회사 일에 옮길 때는 괄호 안 자리에 실제 회의록이나 메일을 붙이게 된다. 붙이기 전에 이름 · 연락처 · 계약 금액처럼 빼도 되는 정보는 지우거나 바꿔 넣는 습관을 들이면, 규정이 허용하는 범위 안에서 더 편하게 쓸 수 있다.
자주 묻는 것
클로드에게는 영어로 물어야 답이 더 좋은가요?
한국어로 물어도 됩니다. 고객센터의 시작 안내는 클로드가 영어로 폭넓게 학습했고 다른 여러 흔한 언어에서도 잘 동작한다고 적었으며, 화면 언어를 고르는 방법은 설정 안내 문서로 따로 안내합니다. 답의 질을 가르는 것은 언어보다 목표 · 배경 · 형식이 빠짐없이 들어갔는지입니다.
프롬프트는 길게 쓸수록 좋은가요?
그렇지 않습니다. Claude 블로그의 프롬프트 글은 길고 복잡한 프롬프트가 늘 더 낫지는 않다고 적고, 간단하게 시작해서 필요할 때만 복잡하게 만들라고 권합니다. 짧은 질문으로 원하는 답이 나오면 거기서 멈추면 됩니다.
예시는 몇 개를 넣어야 하나요?
Anthropic 개발자 문서는 예시 3~5개를 넣으면 가장 좋은 결과를 얻는다고 적었고, 블로그 글은 하나로 시작해서 필요할 때만 늘리라고 권합니다. 형식이 계속 흔들릴 때 조금씩 다른 예시를 더하고, 예시는 지시문과 섞이지 않게 따로 묶습니다.
긴 문서를 붙여 넣을 때 질문은 어디에 쓰나요?
문서를 먼저 붙이고 질문은 맨 아래에 씁니다. 개발자 문서는 긴 자료를 프롬프트 앞쪽에 두고 질문을 끝에 두면 시험에서 답의 품질이 최대 30%까지 좋아졌다고 적었습니다. 답하기 전에 관련 대목을 먼저 인용하게 하면 근거를 대조하기도 쉬워집니다.
답이 중간에 끊기면 어떻게 하나요?
고객센터 문서는 컨텍스트 창이 질문에 적용되고 출력에는 적용되지 않는다고 설명하며, 답이 짧거나 끊기면 질문을 고치고 앞의 질문과 답을 다음 질문에 붙여 이어 쓰게 하라고 권합니다. 처음부터 원하는 분량을 적어 두는 것도 방법입니다.
참고 자료
- Anthropic. Prompting best practices — Be clear and direct(새로 온 직원 비유 · 동료 시험 «Golden rule»), Add context(말줄임표 예시), 예시 3–5개 · example 태그, XML 태그, 역할, 2만 토큰 이상 긴 자료는 위에 · 질문을 끝에 두면 시험에서 최대 30% 향상, 인용 먼저 뽑기, 형식 조절 네 가지, 제안 대신 실행 요청, 스스로 확인 요청, 초안 → 검토 → 고치기 연결(2026-10-14 확인). platform.claude.com
- Anthropic. Prompt engineering overview — 프롬프트 손보기 전에 갖출 세 가지(성공 기준 · 시험 방법 · 첫 초안), 모든 문제가 프롬프트로 풀리지는 않음(지연 · 비용은 모델 바꾸기가 쉬울 때 있음). platform.claude.com
- Claude Help Center. Introduction to prompt design — «새로 고용한 계약자» 비유, 나 · 일 · 조직에 대한 맥락이 없다는 설명, 아주 구체적으로 지시하라는 권고(2026-03-16 갱신). support.claude.com
- Claude Help Center. My prompt isn't giving me a helpful answer — 간단하고 분명하게 · 맥락 더하기 · 단계로 나누기 · 다시 써 달라고 피드백(2026-03-16 갱신). support.claude.com
- Claude Help Center. Claude's response to my prompt is too brief — 컨텍스트 창은 질문에 적용되고 출력에는 아님, 답이 짧거나 끊기면 앞 질문과 답을 다음 질문에 붙이라는 권고(2026-03-16 갱신). support.claude.com
- Claude Help Center. Get started with Claude — 시작 팁 네 가지(간단하게 시작 · 구체적으로 · 고쳐 묻기 · 여러 일 시도). support.claude.com
- Claude Help Center. Change the model, effort, and thinking settings — 모델 메뉴 위치(보내기 버튼 옆), 노력 수준 Low · Medium · High · Extra high · Max, Default 표시, 높은 노력은 더 오래 걸리고 토큰을 더 써 한도에 빨리 닿음, 대화 중 바꾸면 다음 답부터 적용. support.claude.com
- Claude Blog. Best practices for prompt engineering — 불확실하면 그렇다고 말해도 된다고 허락하기, 예시는 하나부터, 긴 프롬프트가 늘 낫지 않음, 첫 프롬프트는 거의 한 번에 맞지 않음 · 시험하고 고치기, 지중해식 식단 예시(2025-11-10 자 글). claude.com
- Claude Help Center. Usage limit best practices — 관련 질문을 한 메시지에 묶기, 보내기 전 한 번 읽고 고치기. support.claude.com
