클로드 Opus 5.5 잘 쓰는 법: 복사해서 쓰는 요청 예시 7가지

홈페이지 글을 맡길 때 초안이 생긴 것과 공개 페이지에서 읽을 수 있는 것은 달랐습니다. 코드가 고쳐졌다는 답을 받아도 화면 확인이 남아 있을 때가 있었습니다. 그래서 AI에게 요청할 때 결과물과 완료 확인을 따로 적기 시작했습니다.

이 글의 일곱 가지 요청 예시는 그 구분을 글쓰기·디자인·코드 검토에 옮긴 것입니다. Anthropic의 Opus 5.5 안내를 참고했지만, 특정 문장을 쓰면 성능이 몇 배 좋아진다는 실험 결과는 아닙니다. 자신의 파일과 확인 기준을 넣어 쓸 수 있게 정리했습니다.

기준일: 2026년 9월 24일 · James K

Anthropic의 Opus 5.5 공식 프롬프트 가이드를 확인하고, 초보자를 위한 적용 예시를 직접 구성했습니다. 아래의 7개 묶음은 공식 인증 요령이나 성능 실험 결과가 아닙니다.

좋은 요청을 구성하는 세 가지: 결과물, 지킬 조건, 완료 기준
좋은 요청을 구성하는 세 가지: 결과물, 지킬 조건, 완료 기준 · NtoSL 제작

먼저 알아둘 점: 모델과 도구는 다릅니다

Opus 5.5는 답변을 만드는 모델입니다. 파일을 저장하거나 브라우저에서 게시하려면 사용하는 앱에 해당 기능과 접근 권한이 있어야 합니다. 요청 문장만으로 없는 기능이 생기지는 않습니다.

공식 가이드는 완료 조건 명시, 추상적인 사고 지시 점검, 구체적인 디자인 조건, 시각 자료 도구 활용을 안내합니다. API에서는 생각의 강도를 조절하는 effort를 작업별로 시험하도록 권합니다. 특히 “깊이 생각해” 삭제는 지연을 줄이는 문맥의 조언이며, 필요한 검증을 생략하라는 뜻은 아닙니다. 공식 설명 확인

긴 작업은 “언제 끝나는지”부터 알려주세요

숙제를 맡긴다고 생각해 보세요. “과학 발표 준비해”보다 “발표 자료 6장과 발표 대본을 만들고, 출처까지 붙여줘”가 훨씬 분명합니다. AI에게도 결과물의 이름, 포함할 내용, 확인 방법을 함께 적어주는 방식이 유용합니다.

막연한 요청
“블로그 글 좀 써줘”

복사해서 바꿔 쓸 요청

초보자용 블로그 글을 작성해줘.
완료 기준은 다음과 같아.
1) 첫 문단에서 독자의 문제에 답하기
2) 따라 할 수 있는 예시 3개 포함
3) 핵심 설명 그림 2개와 대체 텍스트 준비
4) 공식 출처 링크 확인
5) 최종 원고와 아직 확인하지 못한 내용을 함께 전달
발행은 이번 요청에 포함하지 않아.

함께 기억할 점
완료 기준은 AI가 사용할 수 있는 도구 안에서 정하세요. 초안 작성, 파일 저장, 사이트 발행은 각각 다른 단계입니다. 발행까지 맡길 때는 대상 사이트와 공개 범위를 별도로 명시하세요.

“깊이 생각해”보다 확인할 항목을 적어주세요

“정확하게, 신중하게, 아주 깊이”를 여러 번 적어도 무엇을 확인할지는 여전히 모호할 수 있습니다. 보고서라면 합계와 단위, 글이라면 사실과 출처처럼 점검할 대상을 지정해 보세요.

막연한 요청
“깊이 생각해서 완벽하게 검토해줘”

복사해서 바꿔 쓸 요청

이 표에서 항목별 합계와 총계를 다시 계산해줘.
금액 단위가 원인지 만 원인지 확인하고, 기간이 서로 다른 행은 표시해줘.
오류가 있으면 위치·현재 값·계산 근거·수정 제안을 표로 정리해줘.
확인할 자료가 없으면 추측하지 말고 확인 필요로 남겨줘.

함께 기억할 점
생각을 적게 시키라는 뜻은 아닙니다. 복잡한 검증은 그대로 요청하세요. API의 effort 같은 설정은 사용하는 제품과 버전에 따라 노출 방식이 다르므로, 모든 화면에서 같은 버튼을 찾을 필요는 없습니다.

개요가 필요하면 개요를, 파일이 필요하면 파일을 요청하세요

주제를 정하는 중에는 개요가 적합합니다. 반대로 발표가 내일이라면 목차만 받고 끝나면 곤란하겠죠. 파일 형식, 분량, 사용할 사람을 처음부터 적으면 원하는 결과에 가까워집니다.

막연한 요청
“우리 동아리 소개 자료 만들어줘”

복사해서 바꿔 쓸 요청

신입생에게 보여줄 동아리 소개 PPTX 파일을 만들어줘.
총 6장으로, 활동 소개·준비물·일정·가입 방법을 포함해줘.
한 장에는 핵심 문장 3개 이하로 넣어줘.
첨부한 안내문에 없는 회비와 날짜는 임의로 만들지 마.
파일 생성 기능이 없다면 먼저 알려주고, 슬라이드별 붙여넣기용 원고를 제공해줘.

함께 기억할 점
“PPT를 만들었다”는 답과 다운로드 가능한 PPTX 파일은 다릅니다. 첨부 파일이 실제로 열리는지, 글자와 그림이 잘리지 않는지 마지막에 확인하세요.

디자인은 피할 것과 원하는 모습을 함께 말하세요

“촌스럽지 않게”는 사람마다 뜻이 다릅니다. 독자가 누구인지, 어디에서 볼지, 어떤 요소가 불편한지를 구체적으로 설명해 보세요. 싫은 것만 나열하기보다 대신 원하는 모양을 함께 알려주는 편이 수정 방향을 잡기 쉽습니다.

막연한 요청
“AI 느낌 없이 예쁘게 해줘”

복사해서 바꿔 쓸 요청

중학생이 휴대폰으로 읽는 공부 안내 페이지야.
흰 배경과 진한 글자를 쓰고, 강조색은 파란색 하나만 사용해줘.
큰 배경 영상과 반짝이는 효과는 빼줘.
제목 아래에 오늘 할 일 3개가 바로 보이게 배치해줘.
본문 내용과 숫자는 유지하고, 간격·글자 크기·배치만 바꿔줘.

함께 기억할 점
참고 이미지를 붙일 때는 “이 이미지의 넓은 여백만 참고”처럼 가져올 요소를 짚어주세요. 참고 화면 전체를 그대로 복제하라는 요청과 구분할 수 있습니다.

코드 수정 뒤에는 “검토”와 “실행 확인”을 나눠주세요

코드를 읽고 이상한 부분을 찾는 것과 실제 버튼을 눌러보는 것은 다릅니다. 문법이 맞아도 저장 버튼이 동작하지 않을 수 있습니다. 이번 변경과 연결되는 사용 흐름을 정해주면 확인 결과를 판단하기 쉽습니다.

막연한 요청
“고쳤으면 버그도 봐줘”

복사해서 바꿔 쓸 요청

수정한 저장 기능을 확인해줘.
1) 바뀐 코드에서 오류 가능성을 검토
2) 빈 제목으로 저장할 때 안내가 나오는지 확인
3) 정상 제목으로 저장한 뒤 새로고침해도 남는지 확인
4) 기존 삭제 기능에 영향이 없는지 확인
실제로 실행한 테스트와 코드만 읽고 판단한 내용을 구분해줘.
로그인이나 실행 환경이 없어 못 한 항목은 따로 적어줘.

함께 기억할 점
“문제없어 보인다”만으로 완료 처리하지 마세요. 무엇을 실행했고 어떤 결과가 나왔는지 받는 것이 핵심입니다. 실제 결제나 운영 데이터 변경은 별도 범위를 정해 확인해야 합니다.

계산 검증은 숫자 원본, 디자인 검토는 이미지, 종합 검토는 둘 다
계산 검증은 숫자 원본, 디자인 검토는 이미지, 종합 검토는 둘 다 · NtoSL 제작

차트는 이미지, 계산은 원본 — 목적에 맞게 주세요

“이미지로 주면 더 잘한다”는 문장을 모든 작업에 적용하면 오히려 중요한 정보를 잃습니다. 숫자가 작은 스크린샷에서는 소수점이나 음수 기호를 잘못 읽을 수 있습니다. 합계를 검증하려면 셀 값을 가진 원본이 유리하고, 글자 잘림이나 색상은 화면을 함께 봐야 알 수 있습니다.

막연한 요청
“이 매출 차트 이미지 보고 계산이 맞는지 봐줘”

복사해서 바꿔 쓸 요청

같은 보고서의 CSV와 차트 이미지를 함께 올렸어.
CSV는 합계·증감률 계산의 기준으로 사용해줘.
이미지는 제목·축·범례·글자 잘림을 확인하는 데 사용해줘.
두 자료의 기간과 단위가 같을 때만 숫자를 대조해줘.
서로 다르거나 이미지 숫자가 흐리면 확정하지 말고 알려줘.

함께 기억할 점
공식 문서는 복잡한 시각 자료에 고해상도 이미지와 확대·잘라보기 도구를 활용하는 방법을 설명합니다. 이것이 숫자 원본을 버리라는 뜻은 아닙니다. 회사·개인 자료는 공유 가능한 범위를 확인한 뒤 올리세요.

긴 문서는 오류의 “위치와 근거”까지 받아보세요

긴 문서를 올리고 “틀린 곳 찾아줘”라고만 하면 읽기 좋은 요약을 받을 수도 있습니다. 검토 기준과 출력 칸을 정하면 실제로 고칠 때 필요한 목록을 얻기 좋습니다.

막연한 요청
“이 문서 오류 전부 잡아줘”

복사해서 바꿔 쓸 요청

첨부 문서의 날짜·용어·숫자·앞뒤 모순을 점검해줘.
결과는 위치 / 문제 문장 / 근거 / 수정 제안 / 확인 상태 순서로 정리해줘.
위치는 페이지와 소제목으로 표시하고, 페이지를 알 수 없으면 소제목과 짧은 원문으로 찾아갈 수 있게 해줘.
원문에 없는 사실은 추가하지 마.
읽지 못한 페이지나 외부 확인이 필요한 주장도 따로 알려줘.

함께 기억할 점
목록을 받은 뒤에는 지적된 위치를 직접 대조하세요. AI가 말한 오류가 실제 오류인지도 확인해야 합니다. 분량이 많다면 장별 점검 후 전체 용어와 결론을 다시 대조하는 순서로 나눠볼 수 있습니다.

완료 확인 순서: 결과물 확인, 근거 확인, 다음 사람에게 전달
완료 확인 순서: 결과물 확인, 근거 확인, 다음 사람에게 전달 · NtoSL 제작

길게 쓰기 어렵다면 이 양식 하나면 됩니다

목적: 누구에게 어떤 도움을 줄 것인가?
자료: 무엇을 근거로 사용할 것인가?
결과물: 어떤 형식과 분량으로 만들 것인가?
제약: 유지할 것과 바꾸면 안 되는 것은 무엇인가?
완료 기준: 무엇이 확인되면 끝인가?
막혔을 때: 확인 못 한 내용과 필요한 자료를 알려줘.

처음부터 모든 항목을 채울 필요는 없습니다. 오늘 맡길 일 하나에 결과물과 완료 기준만 추가해보세요. 다음번에는 반복해서 빠지는 조건을 한 줄씩 보태면 됩니다.

자주 묻는 질문

이 예시는 Opus 5.5에서만 쓸 수 있나요?
결과물·제약·확인 방법을 정하는 방식은 다른 AI에도 적용해볼 수 있습니다. 다만 모델별 설정과 사용 가능한 도구는 다릅니다.

“깊이 생각해”를 쓰면 무조건 나쁜가요?
아닙니다. 습관적인 강조 표현을 줄이고 필요한 검증을 구체화하자는 뜻입니다. 삭제 전후에 실제 답변 품질도 비교하세요.

검토를 맡기면 사람은 확인하지 않아도 되나요?
아닙니다. 중요한 수치, 외부 공개 문장, 실제 작동 결과는 원본이나 실행 결과와 대조해야 합니다.

출처와 함께 읽을 글

이 글의 요청 예시와 설명 그림은 NtoSL이 직접 구성했습니다. 제품 기능과 설정은 업데이트에 따라 달라질 수 있습니다.

댓글 남기기