글쓰기, 연구, 코딩을 위한 최고의 Claude 프롬프트

글쓰기, 연구, 코딩을 위한 최고의 Claude 프롬프트

가장 훌륭한 Claude 프롬프트는 작업을 쉽게 이해할 수 있게 해줍니다. Claude에 목표, 사용해야 할 자료, 중요한 제약 조건, 그리고 결과를 확인하는 방법을 제시하세요. 글을 작성할 때는 사실 관계와 독자의 다음 행동을 명확히 밝혀주세요. 연구의 경우, 주장을 출처와 연결하십시오. 코딩의 경우, 올바른 동작을 정의하고 테스트를 실행하십시오.

아래에서 필요한 작업부터 시작해 보세요: 이메일 초안 작성, 자료 모음 이해하기, 또는 파이썬 함수 수정하기. 12가지의 유연하게 활용 가능한 템플릿 중에서 선택한 다음, GlobalGPT에서 Claude로 테스트를 거친 세 가지 예제를 살펴보세요. 각 예제에는 완전한 문제 문항과 정답이 포함되어 있으므로, 무엇을 복사하고, 무엇을 수정해야 하며, 자신의 답안을 검토할 때 무엇을 확인해야 하는지 알 수 있습니다.

여러분의 작업이 연구에서 글쓰기로, 그리고 코딩으로 이어진다면, GlobalGPT Claude 및 기타 주요 모델과 다양한 AI 도구를 하나의 합리적인 가격의 구독 서비스와 단일 대시보드에 통합합니다. 전체 워크플로를 한곳에서 관리하면서 다음 단계에 적합한 모델이나 기능을 선택할 수 있습니다.

한눈에 보는 최고의 Claude 프롬프트

필요한 결정 사항이나 산출물에 따라 템플릿을 선택하세요. 제출하기 전에 괄호로 묶인 필드를 적절한 내용으로 대체하세요. 글쓰기 및 연구용 템플릿은 복사해 붙여넣은 텍스트를 사용할 수 있지만, 파일 액세스나 실행을 요구하는 코딩 프롬프트의 경우 해당 작업을 실제로 수행할 수 있는 도구가 필요합니다.

작업여기서 시작하세요가져오기
글쓰기사실에 기반한 개요를 바탕으로 이메일을 작성하세요W1사실 관계 요약, 대상 독자, 회신 조치, 글자 수 제한.
글쓰기자신의 글에 어울리는 어조를 찾아보세요W2작성하신 글 두세 편과 새 기사에 대한 사실 관계.
글쓰기가장 중요한 수정 사항을 찾아보세요W3초안, 대상 독자, 목적, 그리고 보존해야 할 구절.
글쓰기하나의 소스를 두 가지 대상층에 맞게 재구성하기W4승인된 출처 1개와 청중 개요 2개.
연구의견 차이를 희석시키지 않으면서 정보원을 종합한다R1표시가 된 발췌문, 해당 날짜, 결정 질문 및 검토 대상인 주장 사항.
연구인용 출처를 바탕으로 주장을 확인해 보십시오R2단순히 URL뿐만 아니라, 구체적인 주장 내용과 해당 출처의 문구를 제시해 주세요.
연구결정 개요서와 옵션을 비교해 보십시오R3각 대안에 대한 귀하의 기준, 제약 조건 및 신뢰할 수 있는 정보.
연구광범위한 주제를 연구 계획으로 구체화하기R4결정 사항, 대상, 범위, 마감일.
코딩명시적인 동작과 경계 사례를 대상으로 디버깅하기C1코드, 예상 동작, 오류 또는 실패 사례, 실행 시, 제약 조건.
코딩사양을 바탕으로 테스트 작성하기C2행동 요구사항 및 프로젝트 테스트 프레임워크.
코딩작업 범위를 확대하지 않고 리팩토링하기C3코드, 구체적인 유지보수 문제, 그리고 호환성 요구 사항.
코딩구체적인 입력값을 통해 익숙하지 않은 코드를 설명하세요C4실제 코드와 대표적인 입력 예시 하나.

많은 작업의 경우 재사용 가능한 시작 형식만으로도 충분합니다. Anthropic의 프롬프트 엔지니어링 개요 성공 기준과 이를 테스트하는 방법부터 시작합니다. 유용한 답변에 어떤 내용이 포함되어야 하는지 설명하기 위해 정교한 전문가 페르소나를 설정할 필요는 없습니다.

간단한 시작용 템플릿

[대상 또는 목적]을 위해 [작업]을 도와주세요.
이 자료를 사용하세요: [자료 붙여넣기].
다음 제약 사항을 준수해 주세요: [사실, 범위, 길이 또는 규칙].
[출력 형식]으로 결과를 반환해 주세요.
성공적인 결과물은 [검증 가능한 요구 사항]을 충족해야 합니다.
필요한 세부 사항이 누락된 경우, 작업을 방해하는 구체적인 사항을 질문해 주세요.

복잡한 개요를 더 쉽게 구분할 수 있게 해줄 때는 제목이나 태그를 사용하세요. Anthropic의 현재 프롬프트 지침 혼합 자료의 경우 명확한 지침, 유용한 예시, 설명적인 XML 태그를 사용할 것을 권장합니다. 태그는 텍스트를 체계적으로 정리해 줄 뿐, 증거를 생성하거나 도구 접근 권한을 부여하거나 정답을 만들어 주지는 않습니다.

Claude 글쓰기 주제

글을 쓸 때 어려운 점은 표현을 바꾸면서도 요지를 그대로 유지하는 데 있다. 독자가 무엇을 해야 하는지, 그리고 어떤 세부 사항이 고정되어 있는지 명확히 밝혀야 한다. 문장이 아무리 매끄러워도 은근슬쩍 약속을 덧붙인다면 아무 소용이 없다.

1. 사실에 기반한 개요를 바탕으로 이메일을 작성하세요.

내용이 정확히 일치해야 하는 명확한 초대장, 최신 정보 또는 고객 이메일. 준비물: 사실 관계 요약, 대상 독자, 회신 조치, 글자 수 제한.

W1 · 아래에서 테스트된 대표적인 과제

요청서에 명시된 대로 이메일을 작성하십시오. 확인된 사실은 변경할 수 없는 것으로 간주하십시오. 요청 사항과 확인 사항을 명확히 구분하십시오. 명시된 출력 형식과 길이를 준수하십시오. 제공된 세부 정보만 사용하십시오.


대상: [이 이메일을 읽을 사람]
목적: [이 이메일이 달성해야 할 목표]
확인된 사실: [날짜, 시간, 가격, 제한 사항 및 기타 세부 정보]
알 수 없거나 승인되지 않은 세부 사항: [약속할 수 없는 내용]
수신자의 조치: [구체적인 다음 단계]
어조: [어조]
결과물: 제목과 [단어 수 범위]단어 분량의 본문.

결과를 확인해 보세요: 모든 날짜, 숫자, 약속 및 다음 조치 사항을 개요와 대조하여 확인하십시오. 친근한 어조로 덧붙인 한 문장만으로도 의무가 발생할 수 있습니다.

2. 자신의 글쓰기 스타일에 맞춰라

기존 작품과 일관성이 느껴지는 짧은 초안입니다. 준비물: 작성하신 글 두세 편과 새 기사에 대한 사실 관계.

W2 · 유연하게 활용 가능한 템플릿

제 글 샘플을 참고하여 세 가지 관찰 가능한 문체 특징, 즉 문장의 리듬, 격식 수준, 아이디어를 설명하는 방식을 파악하십시오. 이러한 특징들을 [대상 독자]를 위한 새로운 [형식]에 적용하십시오.

작문 샘플은 문체 분석용으로만 활용하십시오. 사실은 새로운 개요를 바탕으로 하십시오. 세 가지 특징을 제시한 후, [단어 수] 단어로 구성된 초안을 작성하십시오.


[본인의 글 붙여넣기]


[주제, 목적, 확인된 사실, 독자의 행동]

결과를 확인해 보세요: 문장의 리듬과 구체성을 살핀 다음, 예시로 든 사실들이 새로운 초안에 그대로 들어가지 않았는지 확인하세요.

유지하고 싶은 스타일이 담긴 예시를 선택하세요. “친근한, 통찰력 있는, 전문적인”과 같은 형용사 목록은 몇 가지 구체적인 예시보다 해석의 여지가 더 큽니다. 새로운 브리프가 사실적인 세부 사항의 근거가 되어야 합니다.

3. 가장 중요한 수정 사항을 찾아보세요

전체적인 재작성을 요구하지는 않지만, 다소 미흡하게 느껴지는 초안. 준비물: 초안, 대상 독자, 목적, 그리고 보존해야 할 구절.

W3 · 유연하게 적용 가능한 템플릿

[독자 대상]이 [독자의 목표]를 달성할 수 있도록 이 초안을 검토해 주십시오. 문장의 명확성이나 유용성을 가장 크게 높일 수 있는 수정 사항을 최대 세 가지까지 제시해 주십시오. 필요한 수정 사항이 세 가지 미만일 경우, 그 사실을 명시해 주십시오.

각 수정 사항에 대해 원문을 인용하고, 독자가 겪는 문제를 설명한 뒤, 대체 문구를 제안해 주십시오. 사실적인 의미와 다음 요소들은 반드시 유지해 주십시오: [반드시 유지해야 할 사항]. 초안 전체를 다시 작성하지 마십시오.


[초안 붙여넣기]

결과를 확인해 보세요: 실제 구절이나 독자가 겪는 실질적인 문제를 지적할 수 없는 연구 결과는 배제해야 한다.

4. 하나의 콘텐츠를 두 가지 대상층에 맞게 재구성하기

승인된 업데이트 내용을 내부 공지와 고객 안내문으로 작성하기. 준비물: 승인된 출처 1개와 청중 개요 2개.

W4 · 유연하게 활용 가능한 템플릿

승인된 원문을 두 가지 짧은 버전으로 수정하십시오:
A. [형식, 대상, 목적, 단어 수 제한]
B. [형식, 대상, 목적, 단어 수 제한]

날짜, 숫자, 기능 제공 여부 및 약속 사항은 일관되게 유지하십시오. 각 대상 독자에 맞게 설명과 강조점을 조정하십시오. 원문에 포함되지 않은 세부 정보가 대상 독자에게 필요한 경우, 초안 뒤에 해당 누락 사항을 나열하십시오.


[원문 붙여넣기]

결과를 확인해 보세요: 동일한 사실 목록을 바탕으로 두 버전을 비교해 보십시오. 새로운 청중이 있다고 해서 새로운 기능이나 약속이 정당화되는 것은 아닙니다.

GlobalGPT에서 다음 과제를 풀어보세요.

요약문을 이메일로, 자료 모음을 추천서로, 버그 보고서를 수정안으로 전환하세요.

세 가지 작업 모두에 Claude Sonnet 5 in GlobalGPT를 사용했습니다. 이메일 초안에는 주요 이벤트 세부 정보가 포함되어 있었고, 조사 결과에서는 출시를 보류해야 할 이유가 확인되었으며, 두 Python 수정 사항 모두 개별적으로 실행했을 때 24가지 검사 항목을 모두 통과했습니다. 이 결과들은 동일한 대시보드에 통합하여 활용할 수 있는 유용한 출발점이 됩니다.

직접 사용해 보시려면 아래 템플릿 중 하나를 선택하고, 예시 내용을 본인의 내용으로 교체해 보세요. GlobalGPT는 글쓰기, 조사, 코딩 및 기타 AI 도구를 하나의 합리적인 가격의 구독 서비스로 통합하므로, 별도의 서비스를 번갈아 가며 사용할 필요 없이 문제 파악 단계에서 다음 결과물 초안 작성 단계로 바로 넘어갈 수 있습니다.

프롬프트 비교 방법

2026년 9월 14일, 각 과제에 동일한 가상의 자료와 요구 사항을 바탕으로 한 두 가지 프롬프트가 제공되었습니다. 하나는 간략한 지침이었고, 다른 하나는 더 체계적인 버전이었습니다. 우리는 각 프롬프트에 대한 첫 번째 완성된 답변을 채택하여 총 6개의 답변을 확보했습니다. 조사 과정에서는 제공된 문장을 활용했으며, 제출된 파이썬 코드는 대화 중에 모델이 직접 실행하지 않고 별도로 검토되었습니다.

이 예시들은 세 가지 과제를 다루며, 각 버전당 한 번씩 다룹니다. 아래에는 전체 입력값과 답안, 그리고 각 결과에 필요한 수정 사항이나 확인 사항이 함께 나와 있습니다. 재사용 가능한 12개의 템플릿은 각각 별도로 테스트되지 않았습니다.

초기 출력 비교 · W

주요 내용을 모두 포함하도록 행사 안내 이메일을 작성하십시오.

확인간단한 지침체계적인 지도
핵심 사실 및 조치 확인 사항8 / 98 / 9
주제와 본문 길이통과 · 126단어통과 · 128단어
승인되지 않은 후속 조치 약속현재현재

두 버전 모두 날짜, 시간, 수용 인원, 가격, 비고 사항, 그리고 예약 요청과 예약 확인의 구분을 그대로 유지했습니다. 덕분에 빈 페이지 대신 편집할 수 있는 초안을 확보하게 되었습니다. 발송하기 전에, 두 브리핑 모두에서 승인되지 않은 후속 조치 약속을 삭제하십시오. 또한 일반 버전에서는 근거 없이 세션을 “동일하다”고 표현했습니다. 본인의 이메일을 작성할 때는 유지해야 할 사실과 약속할 수 있는 사항을 모두 나열하십시오.

8가지 검증 항목은 날짜, 두 가지 시간(현지 시간 및 UTC), 소요 시간, 세션당 정원, 무료 참가, 다운로드 가능한 노트, 녹화 금지, 예약 확인 대신 예약 요청 등을 다룹니다. 아홉 번째 항목은 허위 사실이나 약속이 있는지 확인합니다. 단어 수 계산 시 주제는 제외됩니다.

소요 시간: 9.73초 / 7.02초. 보고된 입력 및 출력 토큰 수: 400 + 617 / 468 + 299. 각각 한 번의 응답; 재시도는 없음.

간결한 지침 — 프롬프트 및 참고 자료 전체
아래 개요에 따라 요청된 이메일을 작성하십시오.

가상의 테스트 시나리오. 이는 실제 제안이 아닌, 가상의 워크숍 세부 정보입니다.

‘Clear Notes’라는 가상의 커뮤니티 워크숍에 대한 초대 이메일을 작성하고 있습니다.
대상: 회의록을 더 깔끔하게 정리하고 싶은 소규모 팀 프로젝트 리더들.
목표: 수신자가 ‘오전’ 또는 ‘오후’라고 답장하여 참가 신청을 하도록 유도하는 것입니다. 답장은 참가 신청을 의미할 뿐, 예약이 확정된 것은 아닙니다.
확정된 사실:
- 날짜: 2026년 10월 8일.
- 두 개의 별도 세션이 UTC 기준 09:00과 16:00에 시작됩니다.
- 각 세션은 40분 동안 진행됩니다.
- 각 세션당 정원은 25명입니다.
- 참가비는 무료입니다.
- 참가자에게는 다운로드 가능한 회의록이 제공됩니다.
- 녹화본은 제공되지 않습니다.
- 등록 마감일은 정해지지 않았습니다.
제출물: 제목과 100~140단어 분량의 이메일 본문. 과장 없이 간결하고 친근한 영어로 작성하십시오. 날짜, 두 시작 시간과 시간대, 소요 시간, 세션당 정원, 가격, 다운로드 가능한 자료, 녹화 미제공, 회신 조치 등을 포함하십시오. 링크, 마감일, 확정된 예약, 연사, 장소 등은 임의로 만들어내지 마십시오. 아직 정해지지 않은 등록 마감일에 대해서는 언급하지 않아도 무방합니다.
간결한 설명 — 원본 답변 그대로
**제목: Clear Notes 워크숍 – 2026년 10월 8일 – 참가 신청에 대한 회신**

안녕하세요,

더 깔끔하고 유용한 회의록을 원하시는 프로젝트 리더분들을 대상으로, 2026년 10월 8일에 열리는 무료 커뮤니티 워크숍인 ‘Clear Notes’에 여러분을 초대합니다.

각 40분 동안 진행되는 동일한 세션이 두 개 마련되어 있습니다. 하나는 UTC 기준 09:00에, 다른 하나는 16:00에 시작됩니다. 각 세션당 25명의 참가자를 모집합니다.

참가는 무료이며, 참가자 모두에게 다운로드하여 보관할 수 있는 회의록을 제공해 드립니다. 녹화본은 제공되지 않으므로, 실시간으로 참석하는 것이 유일한 참여 방법임을 유의해 주시기 바랍니다.

참가를 신청하시려면, 본인에게 가장 적합한 세션에 따라 이 이메일에 ‘MORNING’ 또는 ‘AFTERNOON’이라고 답장해 주시기 바랍니다. 답장하는 것만으로는 신청이 완료된 것이며, 참가가 확정된 것은 아닙니다. 자세한 내용은 곧 안내해 드리겠습니다.

감사합니다. 행사장에서 뵙기를 기대합니다.
체계적인 지도 — 상세한 지침 및 참고 자료
브리프에 요청된 대로 초대 이메일을 작성하십시오. 확인된 사실은 변경할 수 없는 것으로 간주하십시오. 장소 예약 요청과 확정된 예약은 명확히 구분하십시오. 명시된 출력 형식과 분량을 준수하십시오. 제공된 세부 정보만 사용하십시오.


가상의 테스트 시나리오입니다. 이는 실제 제안이 아닌, 꾸며낸 워크숍 세부 정보입니다.

‘Clear Notes’라는 가상의 커뮤니티 워크숍에 대한 초대 이메일을 작성하십시오.
대상: 회의록을 더 간결하게 정리하고자 하는 소규모 팀 프로젝트 리더들.
목표: 독자가 ‘MORNING’ 또는 ‘AFTERNOON’으로 답장하여 참가 신청을 하도록 유도합니다. 답장은 참가 신청을 의미할 뿐, 예약을 확정하는 것은 아닙니다.
확인된 사실:
- 날짜: 2026년 10월 8일.
- 두 개의 별도 세션이 UTC 기준 09:00과 16:00에 시작됩니다.
- 각 세션은 40분 동안 진행됩니다.
- 각 세션당 정원은 25명입니다.
- 참가비는 무료입니다.
- 참가자에게는 다운로드 가능한 자료가 제공됩니다.
- 녹화본은 제공되지 않습니다.
- 등록 마감일은 정해지지 않았습니다.
제출물: 제목과 100~140단어 분량의 이메일 본문. 과장 없이 간결하고 친근한 영어로 작성하십시오. 날짜, 시작 시간 및 시간대, 소요 시간, 세션당 정원, 가격, 다운로드 가능한 강의 자료, 녹화 미제공, 회신 조치 등을 포함하십시오. 링크, 마감일, 예약 확정, 연사, 장소 등은 임의로 추가하지 마십시오. 정해지지 않은 등록 마감일에 대해서는 언급하지 않아도 무방합니다.
체계적인 지도 — 원본 답변 전문
제목: 초대장: Clear Notes 워크숍 – 2026년 10월 8일

안녕하세요,

회의록을 더 깔끔하게 정리하고 싶은 프로젝트 리더이시라면, 2026년 10월 8일에 열리는 Clear Notes 워크숍에 꼭 참석해 주시기를 바랍니다.

각 40분씩 진행되는 두 개의 세션이 마련되어 있습니다. 하나는 UTC 기준 09:00에, 다른 하나는 16:00에 시작됩니다. 각 세션당 정원은 25명이며, 참가비는 전액 무료입니다.

모든 참가자께는 나중에 참고할 수 있도록 다운로드 가능한 회의록을 제공해 드립니다. 녹화본은 제공되지 않으므로, 실시간으로 참석하셔야만 참여하실 수 있습니다.

참가를 신청하시려면, 본인에게 가장 편리한 세션에 따라 ‘MORNING’ 또는 ‘AFTERNOON’이라고 답장해 주시기 바랍니다. 답장은 참가 신청일 뿐, 예약 확정을 의미하지는 않습니다. 자세한 내용은 곧 안내해 드리겠습니다.

그곳에서 뵙기를 기대합니다.

진심을 담아,
Clear Notes 팀

Claude 연구 주제 제안

연구용 프롬프트에는 증거의 범위가 명시되어야 합니다. 출처 ID와 함께 관련 문구를 제공하거나, 해당 내용을 실제로 검색할 수 있는 도구를 사용하십시오. URL만으로는 Claude가 해당 페이지를 열었다는 증거가 되지 않습니다. 이 템플릿들은 출처에 명시된 내용과 사용자가 도출할 수 있는 결론을 구분해 줍니다.

5. 의견 차이를 희석시키지 않으면서 출처를 종합한다

검토할 수 있는 문서를 바탕으로 결정에 관한 질문에 답하기. 준비물: 표시가 된 발췌문, 해당 날짜, 결정 질문 및 검토 대상인 주장 사항.

R1 · 아래에서 테스트된 대표적인 과제

아래의 출처 문장만을 바탕으로 [판단 질문]에 답하십시오. 수치상의 차이를 개선의 증거로 간주하기 전에, 정의, 대상 집단, 분모를 비교하십시오. 가설적 주장과 측정 결과를 구분하십시오. 각 결론을 실제로 이를 뒷받침하는 출처의 정확한 인용문에 연결하고, 근거가 없는 부분은 생략하십시오.

출력 결과: 최대 [LIMIT] 단어 분량의 권고안; 주장(Claim), 판정(Verdict), 출처 ID, 정확한 뒷받침 인용문이 포함된 표; 공정한 비교에 필요한 세 가지 누락된 측정값. ‘뒷받침됨(Supported)’, ‘부분적으로 뒷받침됨(Partly supported)’, ‘뒷받침되지 않음(Unsupported)’, ‘모순됨(Contradicted)’은 증거가 해당 라벨을 정당화할 때만 사용하십시오. 다음 주장들을 검토하십시오: [CLAIMS].


[출처 ID, 날짜 및 관련 발췌문 전문]

결과를 확인해 보세요: 인용된 문구와, 그 문구가 뒷받침하는 주장, 그리고 수량에 동일한 정의와 분모가 사용되었는지 여부를 확인하십시오.

6. 인용 출처를 바탕으로 주장을 확인한다

인용 내용이 증거로 채택되기 전에 초안을 검토한다. 준비물: 단순히 URL뿐만 아니라, 구체적인 주장 내용과 해당 출처의 문구를 제시해 주세요.

R2 · 유연하게 적용 가능한 템플릿

각 주장을 함께 제공된 원문과 대조하여 확인하십시오. 각 주장에 대해 다음 정보를 제공하십시오: 주장, 출처 ID, 정확한 관련 인용문, 판정 결과, 그리고 필요한 경우 수정된 버전.

출처가 주장 전체를 뒷받침할 경우 ‘지지됨(Supported)’을 사용하십시오; 출처가 주장의 일부만 뒷받침할 경우 ‘부분적으로 뒷받침됨(Partly supported)’을, 증거가 없거나 불충분할 경우 ‘뒷받침되지 않음(Unsupported)’을, 출처가 주장과 직접적으로 상충할 경우 ‘반박됨(Contradicted)’을 사용하십시오. 원본 텍스트가 누락된 경우, 뒷받침 여부를 평가할 수 없다고 명시하십시오. 제목이나 URL만으로 원본 내용을 추론하지 마십시오.

[주장–출처 쌍 붙여넣기]

결과를 확인해 보세요: 사실에 근거한 주장이라 해도 그 주장을 뒷받침하지 못할 수는 있다. 증거가 없다고 해서 모순이 되는 것은 아니다.

“입증되지 않음”이란 제시된 증거만으로는 해당 주장을 뒷받침할 수 없음을 의미합니다. “모순됨”이란 증거가 해당 주장과 상충됨을 의미합니다. 이러한 구분은 출처가 아직 결과를 보고하지 않은 경우, 즉 개선이나 악화 중 어느 쪽도 나타나지 않은 상황에서 중요합니다.

7. 각 옵션을 의사결정 개요와 대조해 보십시오

증거의 신빙도가 제각각인 선택지 중에서 결정하기. 준비물: 각 대안에 대한 귀하의 기준, 제약 조건 및 신뢰할 수 있는 정보.

R3 · 유연하게 적용 가능한 템플릿

[결정 사항]에 대한 [선택지]를 비교하십시오. 다음 기준을 우선순위 순서대로 적용하십시오: [기준]. 필수 제약 조건: [제약 조건]. 아래의 선택지 정보만을 사용하십시오.

비교 표, 가장 근거가 확실한 선택지, 그리고 해당 선택지를 바꿀 가능성이 가장 높은 누락된 사실을 제시하십시오. 누락된 값은 ‘알 수 없음’으로 표시하십시오. 사실과 판단을 구분하여 기재하십시오. 가격, 점수 또는 수치적 가중치를 임의로 만들어서는 안 됩니다. 증거를 바탕으로 선택할 수 있는 옵션이 없는 경우, 해결되지 않은 구체적인 상충 관계를 설명하십시오.


[출처 ID와 함께 검증된 정보를 붙여넣기]

결과를 확인해 보세요: 추천 결과가 알 수 없는 값이나 사용자가 선택한 적이 없는 가중치에 의존하는지 확인하십시오.

8. 광범위한 주제를 연구 계획으로 구체화하기

답변을 내리기 위해 충분한 자료가 확보되기 전에 연구를 시작하는 것. 준비물: 결정 사항, 대상, 범위, 마감일.

R4 · 유연하게 적용 가능한 템플릿

[대상]이 [결정]을 내리는 데 도움이 되도록 [질문]에 대한 연구 계획을 수립하십시오. 범위: [지역, 기간 및 제외 사항]. 할당된 시간: [시간].

5개의 핵심적인 하위 질문을 제시하십시오. 각 질문에 대해 필요한 증거, 선호하는 1차 자료 유형, 제안된 검색어, 그리고 결정을 바꾸게 될 만한 연구 결과를 제시하십시오. 가장 우선순위가 높은 두 가지 검색으로 마무리하십시오. 연구를 지어내거나 자료를 읽었다고 주장해서는 안 됩니다. 검색 도구를 사용하는 경우, 실제로 열었던 페이지와 각 페이지가 뒷받침하는 내용을 별도로 명시하십시오.

결과를 확인해 보세요: 그 결과물은 계획입니다. 제안된 검색 방법과 잠재적 정보원을 이미 완료된 연구 결과가 아니라 단서로 삼으십시오.

첫 출력 비교 · R

결과가 나오지 않았다고 해서 그 주장이 반증된 것은 아니다.

확인간단한 지침체계적인 지도
사전 정의된 연구 검증 항목6 / 87 / 8
보관 증거 라벨모순됨 · 너무 강함지원되지 않음 · 적절함
초대 계정 대 온보딩 시작 건수명시적으로 설명되어 있지 않음명시적으로 설명되어 있지 않음

두 답변 모두 전면적인 도입을 거부했으며, 시범 사업이 서로 다른 활성화 기준과 대상 집단을 사용했다는 점을 인정했다. 구조화된 버전은 유지율 주장을 “입증되지 않음”으로 올바르게 분류했다. 반면 일반 버전은 인용문에서 단지 유지율 결과가 존재하지 않는다는 사실만 확인했을 뿐임에도 “모순됨”이라고 기재했다. 두 답변 모두 분모의 차이를 명시적으로 지적하지는 않았다.

비율은 초대 계정 40/50(80%)과 온보딩 시작 54/60(90%)이었습니다. 산술적 계산은 정확하지만, 측정 기준은 서로 대체할 수 없습니다. 체계적인 답변에서는 “활성화”가 동일한 의미를 지칭하는지 여부에 대한 별도의 확인을 추가했습니다. 이는 추가적인 분석적 질문이었을 뿐, 출시 메모에서 제기한 네 번째 주장은 아니었습니다.

메모 주장제공된 소스 코드가 지원하는 내용적절한 치료
B는 활성화율을 10% 포인트 높였다서로 다른 비율, 정의, 분모 및 대상 집단그 격차를 인과적 개선으로 간주해서는 안 됩니다
B. 유지율 향상S3: 아직 30일 보존 기간에 대한 결과가 없습니다입증되지 않음; 반증되지 않음
B는 지원 시간을 6시간으로 단축했다S3: 통합 중앙값, 파일럿별 분류 없음감소 효과가 입증되지 않음
8가지 연구 검증 항목 모두 보기
1. A: 40/50 = 80%, 초대 계정 사용. 둘 다 통과.
2. B: 54/60 = 90%, 온보딩 시작 건수 사용. 둘 다 통과; 출처 인용문에 분모가 포함되어 있음.
3. 서로 다른 활성화 정의와 서로 다른 분모를 명시적으로 표시해야 합니다. 두 사례 모두 분모 부분에서 불합격입니다.
4. 누락된 유지율 결과를 개선의 증거로 취급해서는 안 됩니다. 두 사례 모두 데이터 공백에 대한 설명을 제시했습니다.
5. 통합된 지원 중앙값을 감소가 입증된 것으로 취급해서는 안 됩니다. 두 사례 모두 합격입니다.
6. 이러한 파일럿 결과를 바탕으로 인과적 이점을 추론하거나 전면적인 도입을 정당화해서는 안 됩니다. 둘 다 통과합니다.
7. 각 주장과 증거 라벨을 인용된 문구가 뒷받침하는 내용과 일치시켜야 합니다. 일반 형식은 ‘모순됨’ 항목에서 불합격, 구조화된 형식은 통과합니다.
8. 누락된 세 가지 구체적인 측정 항목을 식별해야 합니다. 둘 다 통과합니다.
일반 형식의 답변에 잘못된 라벨이 붙은 경우, 점검 항목 7에서 한 번만 집계됩니다.

소요 시간: 31.35초 / 31.07초. 보고된 입력 및 출력 토큰 수: 743 + 2822 / 832 + 2837. 각각 한 번의 응답; 재시도 없음.

간결한 지침 — 프롬프트 및 참고 자료 전체
이 자료집 마지막에 있는 과제를 해결하십시오.

# 가상의 연구 자료집

아래에 제시된 모든 조직, 데이터, 인용문 및 문서는 재현 가능한 테스트를 위해 만들어졌습니다. 출처 ID는 본 자료집에만 해당되며, 공개된 연구 자료가 아닙니다.

## S1 — 파일럿 A 종료 보고서, 2026년 9월 2일

"파일럿 A는 50개의 계정을 초대했으며, 그중 40개가 7일 이내에 활성화를 완료했습니다."
"활성화란 워크스페이스를 생성하고 최소 한 명의 팀원을 초대하는 것을 의미합니다."
"계정은 고객 성공 팀이 선정한 기존 고객들이었습니다."
"이 파일럿 프로그램에서는 안내형 온보딩을 사용했습니다."

## S2 — 파일럿 B 대시보드 메모, 2026년 9월 3일

"파일럿 B에서는 60건의 온보딩 시작이 기록되었으며, 54개 계정이 7일 이내에 워크스페이스를 생성했습니다."
"이 대시보드에서는 워크스페이스 생성을 "활성화'로 간주하며, 팀원 초대는 필수 조건이 아닙니다."
"초대 건수는 집계되지 않았습니다."
"계정은 체크리스트를 사용한 신규 셀프 서비스 가입자였습니다."

## S3 — 분석가 검토, 2026년 9월 4일

"파일럿 테스트는 무작위 배정되지 않았으며 서로 다른 계정 집단을 대상으로 진행되었습니다."
"두 파일럿 테스트를 합산한 지원 응답 시간의 중앙값은 6시간이었으며, 파일럿 테스트별로 세분화되지 않았습니다."
"아직 30일 유지율이나 매출 결과는 확인되지 않았습니다."

## S4 — 시범 운영 메모 초안, 2026년 9월 5일

"시범 운영 B는 활성화율을 10% 포인트 높였으며, 유지율을 개선하고 지원 시간을 6시간으로 단축했습니다. 이 체크리스트를 모든 계정에 적용하십시오.”
이는 제안 초안일 뿐, 추가 데이터 출처가 아닙니다. 이 문서의 주장은 S1–S3을 바탕으로 검증해야 합니다.

## 두 프롬프트 버전 모두에 공통된 과제

답변: 이 자료만으로도 파일럿 B를 모든 계정에 적용하는 것이 타당합니까?
S1–S4만을 사용하십시오. (1) 최대 120단어 분량의 권고안, (2) ‘주장’, ‘판결’, ‘출처 ID’, ‘정확한 인용문’ 열로 구성된 표, (3) 공정한 비교를 위해 필요한 세 가지 누락된 측정값을 출력하십시오.
출시 메모에 포함된 세 가지 실증적 주장, 즉 활성화 증가, 유지율 향상, 지원 시간 단축을 모두 검토하십시오. ‘입증됨(Supported)’, ‘부분적으로 입증됨(Partly supported)’, ‘입증되지 않음(Unsupported)’, 또는 ‘모순됨(Contradicted)’으로 판정을 내리고, 필요한 경우 간략한 설명을 덧붙이십시오. 권고문이나 표에는 수치적 비율과 그 분모를 포함시키십시오. 자료집에 없는 인용문, URL, 인과 관계 또는 연구 결과를 임의로 만들어서는 안 됩니다.
간결한 설명 — 원본 답변 그대로
## 권고 사항 (120단어 이하)

아직 파일럿 B를 출시하지 마십시오. 파일럿 B의 원시 활성화율(54/60 = 90%)은 파일럿 A(40/50 = 80%)보다 10퍼센트 포인트 높지만, 하지만 두 파일럿은 "활성화"를 서로 다르게 측정했으며(B는 팀원 초대가 필요하지 않음), 서로 다른 대상 집단(신규 셀프 서비스 가입자 대 기존 고객)을 대상으로 했고, 무작위 배정(S3)이 이루어지지 않았으므로 — 이러한 차이는 체크리스트 때문이라고 볼 수 없습니다. 재이용률에 대한 주장은 근거가 부족합니다: S3에서는 30일 재이용률 데이터가 아직 존재하지 않는다고 명시하고 있습니다. "6시간"이라는 지원 소요 시간 수치는 두 파일럿의 중위값을 합산한 것이며, 파일럿별로 구분되지 않았으므로 파일럿 B에 특화된 감소 효과가 입증되지 않았습니다. 본격적인 도입 전에는 통제되고, 매칭되며, 일관되게 정의된 비교가 필요합니다.

## 주장 검증 표

| 주장 | 판정 | 출처 ID | 정확한 인용문 |
|---|---|---|---|
| "파일럿 B는 활성화율을 10퍼센트 포인트 높였다" | 부분적으로 입증됨 — 원 데이터 비율은 10%포인트 차이(54/60=90% 대 40/50=80%)가 나지만, 정의/대상 집단/설계 방식이 달라 이 차이는 체크리스트에 기인한 것이 아님 | S1 | "파일럿 A는 50개의 계정을 초대했으며, 40개 계정이 7일 이내에 활성화를 완료했다." |
| (동일한 주장, 계속) | | S2 | "파일럿 B는 60건의 온보딩 시작을 기록했으며, 54개 계정이 7일 이내에 작업 공간을 생성했다." / "팀원 초대가 필요하지 않다" |
| (동일한 주장, 계속) | | S3 | "파일럿은 무작위 배정이 되지 않았으며 서로 다른 계정 집단을 사용했다." |
| "유지율 개선" | 모순됨 — 이를 뒷받침할 유지율 데이터가 존재하지 않음 | S3 | "아직 30일 유지율이나 매출 결과는 확인되지 않았다." |
| "지원 소요 시간을 6시간으로 단축" | 근거 없음 — 해당 수치는 두 파일럿을 합산한 중앙값이며, 파일럿 B에 기인한 것이거나 단축된 것으로 표시되지 않음 | S3 | "두 파일럿을 합산한 지원 응답 시간의 중앙값은 6시간이었으며, 파일럿별로 구분되어 제시되지 않았다." |

## 공정한 비교를 위해 필요한 세 가지 누락된 측정 항목

1. 동일한 정의(예: 작업 공간 생성 *및* 팀원 최소 1명 초대)를 적용한 두 파일럿의 활성화율.
2. 파일럿 A와 파일럿 B에 대해 별도로 보고된 지원 응답 시간(합산 중앙값이 아님), 가급적이면 파일럿 실시 전 기준치 포함.
3. 두 파일럿 모두에 대한 30일 유지율(및 매출) 결과로, 비교 가능한(가급적이면 무작위 배정되거나 매칭된) 계정 집단에서 수집된 데이터.
체계적인 지도 — 상세한 지침 및 참고 자료
이 자료집만을 활용하여 과제를 해결하십시오. 두 비율을 개선의 증거로 간주하기 전에, 정의, 모집단 및 분모를 비교하십시오. 초안상의 주장과 측정 결과를 구분하십시오. 각 결론은 이를 실제로 뒷받침하는 정확한 출처 인용문에 연결하고, 근거가 없는 내용은 생략하십시오.


# 가상의 연구 자료 모음

아래의 모든 조직, 데이터, 인용문 및 문서는 재현 가능한 시험을 위해 창작된 것입니다. 출처 ID는 본 자료 모음만을 가리키며, 공개된 연구 자료가 아닙니다.

## S1 — 파일럿 A 종료 보고서, 2026년 9월 2일

"파일럿 A는 50개의 계정을 초대했으며, 40개 계정이 7일 이내에 활성화를 완료했습니다."
"활성화란 작업 공간을 생성하고 최소 한 명의 팀원을 초대하는 것을 의미합니다."
"계정은 고객 성공 팀이 선정한 기존 고객들이었습니다."
"이 파일럿에서는 안내형 온보딩을 사용했습니다."

## S2 — 파일럿 B 대시보드 메모, 2026년 9월 3일

"파일럿 B에서는 60건의 온보딩 시작이 기록되었으며, 54개 계정이 7일 이내에 워크스페이스를 생성했습니다."
"이 대시보드에서는 워크스페이스 생성을 "활성화’로 간주하며, 팀원 초대는 필수 조건이 아닙니다."
"초대 건수는 집계되지 않았습니다."
"계정은 체크리스트를 사용한 신규 셀프 서비스 가입자였습니다."

## S3 — 분석가 검토, 2026년 9월 4일

"파일럿 테스트는 무작위 배정이 이루어지지 않았으며 서로 다른 계정 집단을 대상으로 진행되었습니다."
"두 시범 운영을 합산한 지원 응답 시간의 중앙값은 6시간이었으며, 시범 운영별로 세분화된 수치는 제공되지 않았습니다."
"30일 유지율이나 매출 관련 결과는 아직 확인되지 않았습니다."

## S4 — 출시 메모 초안, 2026년 9월 5일

"파일럿 B는 활성화율을 10% 포인트 높였고, 유지율을 개선했으며, 지원 응답 시간을 6시간으로 단축했습니다. 체크리스트를 모든 계정에 적용하십시오."
이는 제안 초안일 뿐, 추가 데이터 출처가 아닙니다. 이 문서의 주장은 S1–S3을 기준으로 반드시 검증되어야 합니다.

## 두 프롬프트 버전 모두에 공통된 과제

답변: 이 자료만으로도 파일럿 B를 모든 계정에 확대 적용하는 것이 타당합니까?
S1–S4만 사용하십시오. (1) 최대 120단어 분량의 권고안, (2) ‘주장(Claim)’, ‘판결(Verdict)’, ‘출처 ID(Source ID)’, ‘정확한 뒷받침 인용문’ 열로 구성된 표, (3) 공정한 비교에 필요한 세 가지 누락된 측정값을 출력하십시오.
출시 메모에 포함된 세 가지 실증적 주장, 즉 활성화 증가, 재구매율 향상, 지원 시간 단축을 모두 검토하십시오. ‘입증됨(Supported)’, ‘부분적으로 입증됨(Partly supported)’, ‘입증되지 않음(Unsupported)’, ‘반박됨(Contradicted)’ 중 적절한 판정을 내리고, 필요한 경우 간략한 설명을 덧붙이십시오. 권고문이나 표에는 수치적 비율과 그 분모를 포함시키십시오. 자료집에 없는 인용문, URL, 인과 관계 또는 연구 결과를 임의로 만들어서는 안 됩니다.
체계적인 지도 — 원본 답변 전문
## 권고 사항 (120단어 이내)

아니요 — 이 자료만으로는 파일럿 B를 전면적으로 시행할 근거가 부족합니다. 파일럿 A: 기존 고객 중 40/50개 계정(80%)이 "활성화" 기준을 충족했는데, 이는 워크스페이스 생성 *및* 팀원 초대를 모두 완료한 경우를 의미합니다. 파일럿 B: 신규 셀프 서비스 가입자 중 54/60개 계정(90%)이 초대 요건 없이 7일 이내에 워크스페이스를 생성했습니다. 10포인트의 순차이(90%−80%)는 서로 다른 정의와 대상 집단을 혼합한 것이며 무작위 배정(S3)이 이루어지지 않았으므로, 이를 체크리스트가 "활성화율을 높였다"고 해석할 수 없습니다. 아직 30일 유지율이나 매출 데이터가 존재하지 않으므로(S3), "유지율 개선"에 대한 증거는 없습니다. 6시간 지원 수치는 두 파일럿을 *합산*한 중앙값일 뿐, 파일럿별로 구분된 것이 아니므로 "지원 시간 단축"에 대한 기준치나 파일럿별 지원 데이터가 없습니다.

## 표

| 주장 | 판정 | 출처 ID | 정확한 인용문 |
|---|---|---|---|
| "파일럿 B는 활성화율을 10퍼센트 포인트 높였다" | 부분적으로 입증됨 — 산술적 차이는 존재하지만(54/60=90% 대 40/50=80%), 비교에 혼란 요인이 존재하여 인과적 "증가" 주장을 뒷받침할 수 없음 | S1, S2, S3 | S1: "파일럿 A는 50개의 계정을 초대했으며, 그중 40개가 7일 이내에 활성화를 완료했다." / S2: "파일럿 B는 60건의 온보딩 시작을 기록했으며, 54개의 계정이 7일 이내에 워크스페이스를 생성했다." / S3: "파일럿 실험은 무작위 배정이 되지 않았으며 서로 다른 계정 집단을 사용했다." |
| 두 파일럿 모두에서 활성화 측정 방식은 동일했다 | 모순됨 | S1, S2 | S1: "활성화란 워크스페이스를 생성하고 팀원을 최소 한 명 초대하는 것을 의미했다." / S2: "이 대시보드에서는 워크스페이스 생성을 활성화로 간주하며, 팀원 초대는 필수 조건이 아니다." |
| "유지율 향상" | 근거 없음 | S3 | "30일 유지율이나 매출 결과는 아직 확인되지 않았습니다." |
| "지원 처리 시간을 6시간으로 단축" | 근거 없음 | S3 | "두 파일럿을 합산한 지원 응답 시간의 중앙값은 6시간이었으며, 파일럿별로 구분하여 제시되지 않았다." |

## 공정한 비교를 위해 필요한 세 가지 누락된 측정 항목

1. 체크리스트 도입 전후의 파일럿별(통합되지 않은) 지원 응답 시간. 이를 통해 파일럿 B에 기인한 변화를 분리하여 확인할 수 있습니다.
2. 두 파일럿 모두에 대한 30일 유지율(및 매출) 수치. 현재 해당 데이터가 존재하지 않기 때문입니다("아직 30일 유지율이나 매출 결과는 없습니다," S3).
3. 기존 고객(S1)과 새로운 셀프 서비스 가입자(S2)를 혼합하지 않고, 두 파일럿 모두에서 비교 가능하고(이상적으로는 무작위 배정된) 계정 집단에 적용되는 단일하고 공통된 활성화 정의(예: 작업 공간 생성 *및* 팀원 초대).

연구 과제가 초안으로 완성되면, 작성 지침서에 자료 묶음을 첨부해 두십시오. GlobalGPT의 다중 모델 작업 공간 하나의 대시보드에서 연구, 글쓰기, 코딩을 자유롭게 오갈 수 있습니다. 요약본뿐만 아니라 근거 자료도 함께 이어가면, 다음 단계에서 필요한 세부 정보를 확보할 수 있습니다.

Claude 코딩 과제

유용한 코딩 프롬프트는 동작, 환경, 그리고 무엇이 고정된 요소로 간주되는지를 설명해야 합니다. 채팅에서는 관련 코드와 오류 메시지를 붙여넣으세요. Claude 코드에서는 참조 가능한 파일을 명시하고 구체적인 검증 대상을 제시하세요. 같은 텍스트를 붙여넣는다고 해서 채팅창이 터미널로 바뀌지는 않습니다.

Anthropic의 Claude 코드 지침 테스트나 빌드와 같이 어시스턴트가 실행할 수 있는 작업을 부여할 것을 권장합니다. 이는 공식 프롬프트 라이브러리 프롬프트를 결과물, 참고 자료, 작업 검증 방법이 포함된, 응용할 수 있는 출발점으로 간주합니다.

Claude 코드 문서에서는 모델이 실행할 수 있는 테스트를 제공하도록 권장하고 있습니다.
Anthropic는 테스트, 빌드, 육안 비교와 같은 구체적인 점검 방법을 권장합니다.

9. 명시적인 동작과 경계 사례를 기준으로 디버깅하기

동작을 직접 정의할 수 있는 작은 함수를 수정하는 것. 준비물: 코드, 예상 동작, 오류 또는 실패 사례, 실행 시, 제약 조건.

C1 · 아래에서 평가되는 대표적인 과제

전체 사양에 따라 코드를 수정하십시오. 조기 반환 전의 유효성 검사, 경계 포함 여부(포함 또는 제외), 예외가 발생했을 때도 여전히 적용되어야 하는 규칙을 확인하십시오. [PUBLIC INTERFACE]는 그대로 유지하십시오. 사양에서 요구하는 부분만 변경하십시오.


[유효한 입력, 무효한 입력 시 동작, 비즈니스 규칙 및 예상 출력]


[코드 붙여넣기]


[실행 환경, 의존성, 실행 도구 사용 가능 여부]


수정된 코드와 간단한 설명을 제출하십시오. 실제로 수행한 검증 결과만 보고하십시오. 실행이 불가능한 경우 그 사실을 명시하고, 제가 실행해야 할 점검 항목을 제시하십시오.

결과를 확인해 보세요: 독립적인 사례를 실행해 보세요. 설득력 있는 설명은 단순히 프로그램이 정상적으로 실행되는 것과는 다릅니다.

10. 사양을 바탕으로 테스트 작성하기

구현을 신뢰하기 전에 누락된 사례를 찾아내는 것. 준비물: 행동 요구사항 및 프로젝트 테스트 프레임워크.

C2 · 유연하게 활용 가능한 템플릿

[테스트 프레임워크]를 사용하여 [함수 또는 구성 요소]에 대한 테스트를 작성하십시오. 아래의 사양을 계약으로 간주하십시오. 정상적인 경우, 명시된 각 경계 조건, 유효하지 않은 입력, 그리고 중요한 경우 규칙 간의 상호 작용을 모두 포함시키십시오.

각 테스트에 대해, 해당 테스트가 검증하는 요구 사항과 예상 결과를 명시하십시오. 기존 요구 사항은 그대로 유지하십시오. 사양이 모호한 경우, 추측하기보다는 해결해야 할 문제를 명확히 파악하십시오. 실행 도구가 있는 경우 관련 테스트를 실행하고 실제 명령어와 결과를 보고하십시오. 도구가 없는 경우에는 '실행되지 않음'으로 표시하십시오.


[사양 삽입]


[코드 삽입 또는 접근 가능한 파일 참조]

결과를 확인해 보세요: 테스트는 사양을 준수하도록 해야 하며, 현재 구현에서 발생하는 버그를 그대로 재현해서는 안 됩니다.

가능한 한 테스트를 구현과 분리하십시오. 배송비 계산기의 경우, 정확한 중량 기준치와, 그렇지 않으면 무료 배송이 적용될 수 있는 유효하지 않은 입력값을 테스트하십시오. 정상 경로(happy-path) 예시만으로는 규칙 간의 상호작용을 파악할 수 없습니다.

11. 작업 범위를 확대하지 않고 리팩토링하기

동작을 유지하면서 작은 코드 조각을 개선하기. 준비물: 코드, 구체적인 유지보수 문제, 그리고 호환성 요구 사항.

C3 · 유연하게 적용 가능한 템플릿

[CODE OR ACCESSIBLE FILE]을 리팩토링하여 [ONE SPECIFIC MAINTENANCE PROBLEM]을 개선하십시오. [PUBLIC API, RETURN TYPES, ERROR BEHAVIOR, AND OTHER CONTRACTS]는 그대로 유지하십시오. 기존 종속성만 사용하십시오. 관련 없는 기능을 추가하거나 인접한 모듈을 재설계하지 마십시오.

가장 최소한의 유용한 변경 사항만 반영하고, 유지할 수 없었던 동작에 대해서는 설명하며, 호환성을 검증하는 데 필요한 테스트를 명시하십시오. 관련 도구가 있다면 해당 검사를 실행하고 결과를 제시하십시오. 그렇지 않은 경우 제안된 검사 방법을 제시하고 아직 실행되지 않았음을 명시하십시오.

[코드 및 관련 테스트 삽입]

결과를 확인해 보세요: 요청된 범위 외의 변경 사항이 있는지 diff를 검토한 후, 관련 테스트를 다시 실행하십시오.

12. 구체적인 입력값을 통해 익숙하지 않은 코드를 설명하라

함수를 수정하기 전에 그 함수를 이해해야 한다. 준비물: 실제 코드와 대표적인 입력 예시 하나.

C4 · 유연하게 적용 가능한 템플릿

[BACKGROUND]에 대해 알고 있지만 [LANGUAGE OR PROJECT]는 처음 접하는 개발자에게 이 코드를 설명하세요. 다음 예제 입력값을 따르세요: [INPUT]. 입력값, 관련 분기, 상태 변화, 예상 출력 결과를 설명하세요.

실제 함수명과 표현식을 직접 지목해 주십시오. 코드가 보여주는 내용과 누락된 종속성에 대한 가정을 명확히 구분하십시오. 마지막으로 테스트해 볼 만한 경계 사례 하나를 제시하십시오. 코드를 재작성하거나 정의가 없는 함수의 동작을 임의로 가정하지 마십시오.


[코드 붙여넣기]

결과를 확인해 보세요: 설명된 분기와 반환 값을 코드와 대조하여 확인하고, 누락된 종속성은 ‘알 수 없음’으로 표시하십시오.

첫 출력 비교 · C

두 반환 함수 모두 24가지 사례 모두를 통과했습니다.

확인간단한 지침체계적인 지도
지역 내 독립적인 사례들24 / 2424 / 24
작은 함수 내부의 변경 사항예예
도구 기반 테스트에 대한 주장그런 주장은 없다명시적으로 실행하지 않는다고 명시되어 있음

간결한 버전과 구조화된 버전 모두 우리의 고정된 사양에 따른 중량 기준, 무료 기본 배송, 외곽 지역 추가 요금, 유효하지 않은 입력값을 적절히 처리했습니다. 구조화된 답변은 테스트를 실행하지 않았다고 명시적으로 밝혔습니다. 이후 우리가 두 함수를 직접 실행해 본 결과, 간결한 답변 역시 테스트를 실행했다고 주장하지 않았습니다.

총 24개의 입력값과 실제 합격/불합격 결과를 모두 확인하세요
[그램, 소계 센트, 원격]예상 센트 또는 예외일반구조화된
[1, 0, false]500패스패스
[1000, 0, false]500패스패스
[1001, 0, false]900패스패스
[5000, 0, false]900패스패스
[5001, 0, false]1500패스패스
[1, 9999, false]500패스패스
[1, 10000, false]0패스패스
[1000, 10000, true]300패스패스
[5001, 0, true]1800패스패스
[1001, 9999, true]1200패스패스
[5001, 10001, false]0패스패스
[0, 0, false]ValueError패스패스
[-1, 0, false]ValueError패스패스
[1.0, 0, false]ValueError패스패스
["1000", 0, false]ValueError패스패스
[true, 0, false]ValueError패스패스
[null, 0, false]ValueError패스패스
[1, -1, false]ValueError패스패스
[1, false, false]ValueError패스패스
[1, 1.5, false]ValueError패스패스
[1, "0", false]ValueError패스패스
[1, 0, 1]ValueError패스패스
[1, 0, null]ValueError패스패스
[0, 10000, false]ValueError패스패스

생성 전에 입력값과 예상 결과가 고정되었습니다. 반환값은 정확한 정수여야 했으며, 유효하지 않은 입력값이 주어지면 ValueError가 발생해야 했습니다. 두 함수 모두 검토를 거친 후, 네트워크 액세스, 사용자 파일 읽기 및 파일 쓰기가 차단된 로컬 프로세스에서 실행되었습니다. 이러한 테스트 사례를 통과했다는 사실은 해당 함수와 사양에 대한 검증일 뿐, 실제 생산 환경에 즉시 적용할 수 있음을 의미하지는 않습니다.

소요 시간: 12.58초 / 13.30초. 보고된 입력 및 출력 토큰 수: 553 + 735 / 621 + 1015. 각각 1회 응답; 재시도는 없음.

간결한 지침 — 프롬프트 및 참고 자료 전체
아래 사양에 따라 함수를 수정하고 요청된 결과물을 제출하십시오.

# 가상의 배송비 계산기

Python 3. 네트워크나 외부 패키지는 사용할 수 없습니다. 아래 코드의 shipping_cents(weight_grams, subtotal_cents, remote=False) 함수를 수정하십시오.

사양:
- weight_grams는 양의 정수입니다. subtotal_cents는 0 이상의 정수입니다. 이 두 입력값에 대해 파이썬의 bool 값은 유효한 정수로 간주되지 않습니다.
- remote는 반드시 bool이어야 합니다.
- 주문이 기본 무료 배송 조건을 충족하는 경우라도, 유효하지 않은 입력값이 있을 경우 ValueError를 발생시켜야 합니다.
- 기본 배송비는 1~1000그램의 경우 500 센트, 1001~5000그램의 경우 900 센트, 5000그램 초과 시 1500 센트입니다.
- 소계액이 10000 센트 이상일 경우 기본 배송비만 면제됩니다.
- 원격 배송 시 기본 배송비가 무료인 주문을 포함하여 300 센트가 추가됩니다.
- int를 반환하십시오. 함수 시그니처를 유지하십시오. 입력 데이터를 변경하거나, I/O를 수행하거나, 패키지를 임포트해서는 안 됩니다.

오류가 있는 코드:
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
    if subtotal_cents >= 10000:
 return 0
    if weight_grams < 1000:
 fee = 500
    elif weight_grams < 5000:
 fee = 900
    else:
 fee = 1500
    if remote:
 fee += 300
    return fee
```

제출물: 수정된 함수가 포함된 Python 펜스 블록 하나와, 변경 사항에 대한 간략한 설명. 실제로 실행 도구가 없는 한 코드를 실행했다고 주장하지 마십시오. 평가자는 이 사양에 명시된 임계값, 무료 배송 규칙, 원격 배송 추가 요금 및 모든 유효하지 않은 입력 범주를 포괄하는 테스트 케이스를 실행할 것입니다.
간결한 설명 — 원본 답변 그대로
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
    if isinstance(weight_grams, bool) or not isinstance(weight_grams, int):
    raise ValueError("weight_grams는 정수여야 합니다")
    if weight_grams <= 0:
 raise ValueError("weight_grams는 양수여야 합니다")
    if isinstance(subtotal_cents, bool) or not isinstance(subtotal_cents, int):
        raise ValueError("subtotal_cents는 정수여야 합니다")
    if subtotal_cents < 0:
 raise ValueError("subtotal_cents는 0 이상이어야 합니다")
    if not isinstance(remote, bool):
        raise ValueError("remote는 bool형이어야 합니다")

 if weight_grams <= 1000:
 fee = 500
    elif weight_grams = 10000:
 fee = 0

 if remote:
 fee += 300

 return fee
```

변경 사항:
1. **입력 유효성 검사 추가**: `weight_grams`와 `subtotal_cents`가 `int`형인지(`bool`은 `int`의 하위 클래스이므로 `bool`은 제외), `weight_grams`가 양수인지, `subtotal_cents`가 0 이상인지, 그리고 `remote`가 `bool`형인지 확인합니다. 그렇지 않은 경우, 주문이 무료 배송 조건을 충족하더라도 `ValueError`를 발생시킵니다.
2. **중량 기준치 수정**: `< 1000` 및 `< 5000`을 `<= 1000` 및 `<= 5000`으로 변경하여, (1000g, 5000g)가 사양("1–1000그램", "1001–5000그램", "5000그램 초과")에 따라 올바른 등급에 속하도록 수정했습니다.
3. **무료 배송 로직 순서 수정**: 기존 코드는 소계가 무료 배송 조건을 충족하면 즉시 `0`을 반환하여 원격 배송 추가 요금을 완전히 생략했습니다. 이제 기본 배송비가 먼저 계산되고, 소계액이 무료 배송 조건을 충족하면 기본 배송비가 0으로 설정된 후, *그 다음* 원격 지역 추가 요금이 더해집니다. 이를 통해 기본 배송비가 무료인 경우에도 원격 지역 배송 시 300 센트가 추가되도록 보장합니다.
4. **반환 유형**: 모든 요금 값은 `int` 반환 요건을 충족하도록 일반 정수(int)로 유지됩니다.
체계적인 지도 — 상세한 지침 및 참고 자료
전체 사양에 따라 함수를 수정하십시오. 조기 반환 전에 입력 유효성 검사를 적용하고, 임계값을 포함하는 방식을 유지하며, 기본 요금과 원격 추가 요금을 별도로 처리하십시오. 요청된 함수와 설명을 제공하십시오. 실제로 수행한 검증 결과만 보고하십시오.


# 가상의 배송비 계산기

Python 3. 네트워크나 외부 패키지는 사용할 수 없습니다. 아래 코드의 shipping_cents(weight_grams, subtotal_cents, remote=False) 함수를 수정하십시오.

사양:
- weight_grams는 양의 정수입니다. subtotal_cents는 0 이상의 정수입니다. 이 두 입력에 대해 파이썬의 bool 값은 유효한 정수가 아닙니다.
- remote는 반드시 bool이어야 합니다.
- 주문이 무료 기본 배송 조건을 충족하는 경우라도, 유효하지 않은 입력이 있을 경우 ValueError를 발생시켜야 합니다.
- 기본 배송비는 1~1000그램일 경우 500 센트, 1001~5000그램일 경우 900 센트, 5000그램 초과 시 1500 센트입니다.
- 소계액이 10000 센트 이상일 경우 기본 배송비만 면제됩니다.
- 원격 배송 시 300 센트가 추가되며, 기본 배송비가 무료인 주문도 포함됩니다.
- 정수(int)를 반환하십시오. 함수 시그니처를 유지하십시오. 입력 데이터를 변경하거나, I/O 작업을 수행하거나, 패키지를 임포트해서는 안 됩니다.

오류가 있는 코드:
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
    if subtotal_cents >= 10000:
 return 0
    if weight_grams < 1000:
 fee = 500
    elif weight_grams < 5000:
 fee = 900
    else:
 fee = 1500
    if remote:
 fee += 300
    return fee
```

제출물: 수정된 함수가 포함된 Python 펜스 블록 하나와, 변경 사항에 대한 간략한 설명. 실제로 실행 도구가 없는 한 코드를 실행했다고 주장하지 마십시오. 평가자는 이 사양에 명시된 임계값, 무료 배송 규칙, 원격 지역 추가 요금 및 모든 유효하지 않은 입력 범주를 포괄하는 사례들을 실행할 것입니다.
체계적인 지도 — 원본 답변 전문
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
    if isinstance(weight_grams, bool) or not isinstance(weight_grams, int):
        raise ValueError("weight_grams는 int형이어야 합니다 (bool형이 아님)")
    if weight_grams <= 0:
 raise ValueError("weight_grams는 양수여야 합니다")
    if isinstance(subtotal_cents, bool) or not isinstance(subtotal_cents, int):
 raise ValueError("subtotal_cents는 정수여야 합니다 (부울 값이 아님)")
    if subtotal_cents < 0:
 raise ValueError("subtotal_cents는 0 이상이어야 합니다")
    if not isinstance(remote, bool):
 raise ValueError("remote는 bool형이어야 합니다")

    if weight_grams <= 1000:
 base_fee = 500
    elif weight_grams = 10000:
 base_fee = 0

 surcharge = 300 if remote else 0

 return base_fee + surcharge
```

변경 사항 설명:

1. **입력 유효성 검사가 조기 반환 문보다 앞쪽으로 이동되었습니다.** 원래 코드는 먼저 어떤 입력도 검증하지 않은 채 `subtotal_cents >= 10000`일 때 `0`을 반환했습니다. 이제 모든 유효성 검사(`weight_grams`, `subtotal_cents`, `remote`에 대한 타입 검사, 그리고 파이썬에서 `bool`이 `int`의 하위 클래스이므로 두 정수 필드에 대한 명시적인 `bool` 제외 포함)이 수수료 논리나 반환 문보다 먼저 수행되므로, 주문이 무료 기본 배송 조건을 충족하더라도 유효하지 않은 입력은 항상 `ValueError`를 발생시킵니다.

2. **포함 기준값 수정.** 원래 코드에서는 `< 1000` 및 `< 5000`을 사용했는데, 이는 사양의 "1–1000 그램" 및 "1001–5000그램"과 같은 경계값을 포함한 범위에 부합하지 않았습니다. 이를 `<= 1000` 및 `= 10000`일 때 조기 `return 0`을 통해 이를 완전히 0으로 초기화했는데, 이로 인해 무료 배송 주문에 대한 배송비 할증료가 잘못 누락되었습니다. 이제 `base_fee`와 `surcharge`는 독립적으로 계산됩니다: 소계 기준값에 도달하면 `base_fee`는 `0`으로 설정되지만, `surcharge`(`remote`인 경우 300 센트)는 항상 추가로 더하여, "원격 배송 시 300 센트가 추가되며, 기본 배송비가 무료인 주문도 포함"이라는 조건을 충족시킵니다.

4. **반환 유형.** 모든 수수료 구성 요소는 일반 정수(int)이며, `base_fee + surcharge`의 합계는 `int`로 반환되어 요구되는 시그니처 및 반환 유형과 일치합니다.

**실제로 수행한 검증:** 없음 — 이 환경에서는 코드 실행 도구를 사용할 수 없으므로 이 코드를 실행하지 않았습니다. 위 내용은 전적으로 사양을 수동으로 읽고 논리를 직접 추적한 것에 기반한 것이며, 이에 대한 테스트 케이스를 실행하지는 않았습니다.

코드와 텍스트, 이미지 또는 동영상 작업을 결합한 작업의 경우, 다음과 같이 할 수 있습니다. GlobalGPT CLI를 Claude 코드에 연결 그리고 플랫폼의 모델 및 미디어 기능을 터미널 워크플로에 통합합니다. 구체적인 작업과 결과 승인에 사용할 검증 기준부터 시작하세요.

프롬프트를 구체적으로 설정했을 때 무엇이 달라졌나요?

이번 작업에서는 추가적인 구조가 한 가지 연구적 판단에 도움이 되었습니다. 이는 이메일에서 추가된 약속을 제거하지도 않았고, 이미 올바르게 작동하던 배송 기능을 개선하지도 않았습니다. 두 버전 모두 완전한 요구사항을 받았기 때문에, 이번 비교는 유용한 교훈을 줍니다. 즉, 지침을 더 추가하기 전에 브리프의 질이 중요하다는 점입니다.

쌍을 이룬 예시의 결과

작업마다 필요한 확인 사항이 다릅니다.

과제별 측정 기준간단한 지침체계적인 지도결과를 어떻게 처리할 것인가
사실과 약속을 기록하기9개 중 8개9개 중 8개허위로 제시된 후속 조치 약속 삭제
연구 증거 검토8개 중 6개8개 중 7개증거 라벨을 수정하고 분모를 비교하십시오
파이썬 동작 사례24개 중 24번째24개 중 24번째실행 가능한 사양과 독립적인 테스트를 유지하세요

이 수치는 서로 다른 체크리스트에서 집계된 것으로, 비교 가능한 백분율이나 전체 모델 점수가 아닙니다. 각 예시 아래에는 전체 프롬프트, 원본 답변 및 테스트 세부 정보가 나와 있습니다. 단일 실행 소요 시간과 토큰 수는 해당 요청을 설명하는 데 그칠 뿐, 속도나 비용 면에서의 우위를 입증하는 것은 아닙니다.

작업 내용과 참고 자료가 이미 명확한 경우에는 간결한 프롬프트를 사용하세요. 지침, 문서, 예시 또는 상충되는 요구 사항을 구분하기 어려울 때는 구조를 추가하세요. Anthropic의 지침은 모델별 동작 특성도 구분하고 있습니다., 따라서 반복적인 자체 확인을 요구하는 오래된 습관이 모든 요청에 무의식적으로 덧붙여지는 일이 있어서는 안 됩니다.

부실한 답변을 내놓는 프롬프트를 수정하는 방법

문제를 일으킨 부분을 수정하세요. 답변에서 임의로 마감 기한을 정했다면, “이 부분을 더 잘 고쳐주세요”라는 요청은 너무 포괄적입니다. 근거가 부족한 세부 사항을 지적하고, 수정 범위를 명확히 제시한 뒤, 구체적인 수정 사항을 요청하세요. 프롬프트 버전을 비교하는 경우라면, 원본 답변을 조용히 대체하지 말고 그대로 유지하세요.

무엇이 잘못된 것일까준비하거나 변경해야 할 사항유용한 후속 조치
정답은 일반적인 것입니다.독자, 구체적인 과제, 실제 자료[대상]을 위해 다음 정보만 사용하여 글을 다시 작성하십시오: [요약].
그 목소리가 뭔가 이상하게 느껴진다본인이 직접 쓴 글의 예시이 예문의 문장 리듬과 격식을 따르되, 새로운 브리핑의 사실 관계는 그대로 유지하십시오.
약속을 하나 더 추가합니다명시적인 경계와 문제가 된 문장후속 조치를 삭제하십시오. 출처에서는 이를 허용하지 않습니다.
인용 내용이 그럴듯해 보인다실제로 인용된 구절이 문단은 해당 주장을 전적으로 뒷받침하는가, 일부만 뒷받침하는가, 아니면 둘 다 아닌가요?
두 비율은 비슷해 보인다정의, 분모, 모집단, 기간비율을 비교하기 전에 각 백분율이 무엇을 나눈 것인지 명시하십시오.
코드는 괜찮아 보이지만 실행에 실패합니다재현 가능한 오류 발생 입력 및 예상 결과이 입력은 [value]를 반환해야 하지만 [value]를 반환합니다. 규칙을 수정하고 이 사례를 실행해 주세요.

정말로 필요한 정보가 부족한 경우에는 Claude가 핵심을 짚은 질문을 하도록 하세요. 충분한 맥락이 제공되는 일반적인 업무의 경우, 의무적으로 20개 문항을 묻는 인터뷰는 오히려 업무 진행을 지연시킬 뿐입니다. 마찬가지로, 사적인 내부 사고 과정의 기록보다는 간결한 설명, 증거 또는 테스트 결과를 요청하세요.

유용한 프롬프트를 입력 형식과 오류를 감지한 검사 항목과 함께 저장하세요. 해당 작업이 반복 가능한 애플리케이션 워크플로가 된다면, API를 통해 Claude 사용 프롬프트를 버전별로 관리하고 요청 내역을 보관할 수 있는 공간을 제공합니다. 모델이나 작업 요구 사항이 변경될 때 직접 작성한 예시를 다시 확인해 보세요.

자주 묻는 질문

좋은 Claude 프롬프트에는 무엇이 포함되어야 할까요?

작업 내용, 관련 배경 정보나 참고 자료, 중요한 제약 사항, 원하는 결과물, 그리고 성공 여부를 확인하는 방법을 포함하십시오. 간단한 요청의 경우, 한 문장으로 이 중 몇 가지를 다룰 수 있습니다. 문서, 예시, 또는 규칙 등을 결합할 때는 혼동되기 쉬운 부분이 있을 수 있으므로, 더 체계적인 구조를 갖추도록 하십시오.

Claude 프롬프트에는 XML 태그가 필요한가요?

아닙니다. 명확하고 평이한 언어는 유용한 출발점입니다. XML 태그는 복잡한 프롬프트에서 지침, 예시, 원문을 구분하는 데 도움이 될 수 있습니다. 각 부분을 더 쉽게 이해할 수 있도록 설명적인 레이블을 사용하세요. 태그가 사실의 정확성을 보장하는 것은 아니며, 태그가 있다는 사실만으로는 어떤 프롬프트가 더 낫다고 단정할 수 없습니다.

Claude는 열 수 없는 소스 파일을 확인할 수 있나요?

이 도구는 사용자가 제공한 텍스트를 분석할 수 있지만, 출처의 제목이나 URL만으로는 해당 페이지의 내용을 파악하기에는 부족합니다. 관련 문구를 복사하여 붙여넣거나, 제공된 탐색 도구를 사용하여 해당 내용을 찾아보세요. 그런 다음 인용문 자체와, 그 인용문이 해당 주장과 일치하는지 여부를 모두 확인하십시오.

Claude 채팅과 Claude Code에서 같은 프롬프트를 사용할 수 있나요?

작업과 제약 조건은 재사용할 수 있지만, 요청 내용은 사용 가능한 도구에 맞게 조정해야 합니다. 채팅에서는 코드와 관련 맥락을 제공해 주세요. Claude Code에서는 접근 가능한 프로젝트 파일을 참조하고 실행을 요청할 수 있습니다. “테스트를 실행하세요”라는 프롬프트만으로는 테스트가 실제로 실행되었다는 증거가 되지 않습니다.

가장 좋은 Claude 프롬프트는 직접 수정하고 검증해 볼 수 있는 것입니다. 반복되는 작업 하나부터 시작해, 예시 자료를 본인의 자료로 바꾸고, 답을 신뢰하기 전에 템플릿 옆에 있는 확인 항목을 활용해 보세요. GlobalGPT에서 해당 워크플로를 사용해 보세요. 다음 단계에서 동일한 작업 공간 내의 다른 모델이나 AI 도구가 필요할 때.

출처 및 시험일: 2026년 9월 14일에 공식 프롬프트와 Claude 코드 문서를 확인했습니다. 해당 날짜에 GlobalGPT 환경에서 Claude를 사용하여 가상의 자료를 바탕으로 쌍을 이룬 예시들을 생성했습니다. 위에서 전체 프롬프트와 답변을 살펴본 후, 템플릿을 자신의 과제에 맞게 수정해 보세요.

게시물을 공유하세요:

관련 게시물