Claude Opus 5.5 사용법: 가격·설정·실전 프롬프트 8개

Claude Opus 5.5를 제대로 쓰려면 무엇부터 바꿔야 할까요? 추론 강도는 medium부터 시작하고, 막연한 “깊게 생각해” 대신 결과물의 완료 기준을 적는 것부터 해보세요.

쇼츠에서 소개한 세 가지 원칙을 실제 업무에 적용할 수 있도록 풀었습니다. 보고서가 개요에서 끝날 때, 디자인이 계속 비슷하게 나올 때, Claude Code가 중간에 “계속할까요?”라고 물을 때 사용할 프롬프트까지 담았습니다.

Claude Opus 5.5란? 핵심 변화부터 확인하세요

Claude Opus 5.5는 Anthropic이 2026년 9월 22일 발표한 Claude 5.5 제품군의 첫 모델입니다. Anthropic은 대부분의 작업에서 Fable 5.1 수준의 성능을 내면서, 기본 설정의 일반적인 작업 비용은 Opus 5보다 약 40% 낮아졌다고 설명합니다. 모든 작업에서 같은 차이가 난다는 뜻은 아닙니다. 공식 출시 발표

사용할 때 기억할 변화는 다음 세 가지입니다.

추론 강도와 생각 기능의 변화는 Opus 5.5 변경 사항에 정리되어 있습니다.

API 가격은 얼마나 내려갔나요?

아래는 일반 모드, 100만 토큰당 미국 달러 기준입니다. 토큰은 모델이 글을 읽고 만드는 데 사용하는 처리 단위입니다.

캐시 읽기는 이전에 처리한 공통 내용을 다시 활용하는 경우의 비용입니다. 입력·출력 단가의 20% 인하와 일반적인 작업 비용의 약 40% 감소는 구분해야 합니다. 작업 비용에는 사용한 토큰 수와 캐시 활용도도 영향을 줍니다. 공식 가격 비교

예를 들어 캐시 없이 입력 1만 토큰과 생각 토큰을 포함한 출력 2천 토큰을 썼다면, 이 두 항목의 비용은 Opus 5에서 $0.10, Opus 5.5에서 $0.08입니다. 같은 토큰 수로 계산하면 20% 차이입니다. 화면에 보이는 답변 길이만으로 계산하면 생각 토큰의 비용을 놓칠 수 있습니다. 실제 청구액에는 별도 도구 요금 등이 추가될 수 있습니다.

API 단가가 내려갔다고 월 구독료가 40% 내려가는 것은 아닙니다. 구독 사용 한도와 API 종량제 비용도 별도로 봐야 합니다.

Claude 앱·Claude Code·API는 무엇이 다른가요?

Opus 5.5는 모델 이름이고, 아래 세 가지는 그 모델을 사용하는 환경입니다. 같은 프롬프트라도 연결된 도구와 파일 권한에 따라 만들 수 있는 결과물이 달라집니다.

모델을 선택하는 것만으로 로컬 파일 접근이나 문서 생성 도구가 자동으로 연결되는 것은 아닙니다.

왜 프롬프트를 바꿔야 할까요?

“이 자료 정리해줘”에는 중요한 정보가 빠져 있습니다. 누가 읽는지, 어떤 형식인지, 어디까지 만들면 끝인지가 없습니다. 결과가 마음에 들지 않으면 다시 설명하고 다시 생성하게 됩니다.

이 글에서 권하는 요청 방식은 간단합니다.

할 일 + 완료 기준 + 질문할 조건 + 검증 방법을 함께 적어보세요.

이렇게 적으면 독자도 결과를 평가하기 쉬워집니다. “답변이 그럴듯한가?” 대신 “요구한 파일이 생겼나?”, “숫자의 근거가 있나?”를 확인할 수 있기 때문입니다.

원칙 1. 추론 강도는 medium부터 시작하세요

Effort는 모델이 응답에 투입하는 작업량을 조절하는 설정입니다. 답변 글자 수만 바꾸는 옵션이나 정확한 토큰 예산은 아닙니다. Opus 5.5는 low, medium, high, xhigh, max를 지원하며 기본값은 medium입니다. 공식 Effort 문서

적응형 생각 기능이 항상 켜져 있다는 말은 매 응답에서 반드시 긴 생각 과정을 보여준다는 뜻이 아닙니다. 실제 생각의 양과 표시되는 내용은 요청·설정에 따라 달라집니다.

처음에는 다음 순서로 확인해보세요. 아래 표는 이 글에서 제안하는 실무 점검 기준입니다.

정보가 부족한 상태에서 설정만 높여도 빠진 자료가 생기지는 않습니다. 반대로 medium에서 완료 기준을 충족했다면 그 작업은 그대로 사용해도 됩니다.

Claude 앱과 Claude Code에서 설정하는 방법

Claude 웹·앱: 전송 버튼 옆 모델 이름을 눌러 Opus 5.5를 선택합니다. 같은 메뉴의 Effort에서 medium을 확인하세요. 모델·Effort 설정 도움말

Claude Code: 실행 중인 입력창에서 아래 명령을 한 줄씩 입력합니다.

/model claude-opus-5-5
/effort medium

새 세션을 시작하면서 지정하려면 터미널에서 실행합니다.

claude --model claude-opus-5-5 --effort medium

위 모델 ID는 Anthropic에 직접 연결하는 환경 기준입니다. 외부 클라우드 제공자는 모델 ID가 다를 수 있으므로 /model에 표시되는 선택지를 확인하세요. 대화형 세션에서 /effort medium으로 지정한 값은 해당 모델의 이후 세션에도 저장되며, 실행 시 --effort medium은 그 세션에 적용됩니다. 조직 제한이나 환경변수가 우선할 수 있으니 세션에 표시되는 실제 모델명과 Effort도 확인하세요. Claude Code 모델 설정 문서

원칙 2. “깊게 생각해” 대신 필요한 검사를 적으세요

Opus 5.5에서는 생각을 유도하는 문구를 습관적으로 덧붙일 필요가 없습니다. Anthropic은 채팅 제품 테스트에서 시스템 프롬프트의 이런 지시를 제거했을 때, 답변이 더 빨리 시작됐고 품질의 뚜렷한 저하는 관찰되지 않았다고 설명합니다. 특정 테스트 결과이며 모든 요청의 속도·품질을 보장하는 법칙은 아닙니다. 공식 프롬프팅 가이드

그렇다고 “근거를 확인해줘”까지 지울 필요는 없습니다. 다음처럼 결과에 필요한 검증을 구체적으로 적어보세요.

• 계산 결과를 입력 데이터의 합계와 대조해줘.
• 제안한 방법을 선택한 이유와 적용하기 어려운 조건을 알려줘.
• 확인하지 못한 정보는 추측으로 채우지 말고 표시해줘.

내부 생각을 길게 출력시키기보다, 내가 확인할 수 있는 근거·검사 결과·남은 문제를 받는 편이 실무에서 유용합니다.

원칙 3. 완료 기준과 멈출 조건을 함께 주세요

“끝까지 해줘”만 적으면 어디까지가 끝인지 불분명합니다. 보고서라면 내용과 파일 형식, 코딩이라면 구현 범위와 검증 방법까지 적어주세요.

두 조건을 구분하면 편합니다.

• 완료 기준: 결과가 어떤 상태이면 작업을 끝낼지 정합니다.
• 멈출 조건: 진행 중 어떤 정보나 결정이 없으면 질문할지 정합니다.

상황별 복사용 프롬프트 8개: 보고서부터 코드 리뷰까지

필요한 예시 하나만 골라 쓰세요. 아래 표의 번호와 각 프롬프트 번호가 같습니다.

프롬프트 1. 어떤 업무에든 쓰는 기본 템플릿

Claude 앱이나 Claude Code의 요청창에 붙여넣고 대괄호 부분을 바꾸세요. 모든 항목을 길게 채울 필요는 없습니다.

목표: [누가 무엇에 사용할 결과물인지]
입력: [첨부 파일, 참고 자료, 작업 폴더]

완료 기준
- [결과물의 형식과 저장 위치]
- [반드시 포함할 내용 또는 동작]
- [완료 여부를 확인하는 방법]

진행 범위
- 위 기준을 충족하는 데 필요한 작업까지 진행해줘.
- 기준을 충족한 뒤에는 요청하지 않은 기능이나 장식을 추가하지 마.

질문할 조건
- 필수 자료나 접근 권한이 없으면 빠진 것을 구체적으로 알려줘.
- 결과를 크게 바꾸는 결정이 필요하면 그 결정만 질문해줘.
- 외부 발송·공개·데이터 삭제는 진행 전에 확인해줘.

마지막에는 결과물 위치, 확인한 항목, 아직 확인하지 못한 항목을 알려줘.

프롬프트 2. 요약을 공유 가능한 보고서로 받기

이럴 때: 요약을 요청했는데 목차나 작성 방법만 받았을 때 사용합니다. 회의록이나 조사 자료를 첨부하고, 파일 생성 기능을 사용할 수 있는 환경에서 실행하세요.

첨부 자료를 팀장의 의사결정에 사용할 보고서로 만들어줘.

완료 기준
- A4 한 페이지짜리 report.docx 파일을 만든다.
- 첫 문단에 결론, 본문에 핵심 3가지와 각각의 근거를 넣는다.
- 근거에는 원본 파일명과 페이지 또는 해당 항목을 적는다.
- 마지막에 다음 행동 2가지와 추가 확인이 필요한 내용을 적는다.
- 렌더링이나 PDF 변환으로 페이지 수와 잘림을 확인한다.
- 화면·페이지 수를 확인할 도구가 없으면 그 한계를 보고한다.

초안 개요만 제안하지 말고 파일 생성과 확인까지 진행해줘.
결론을 정하는 데 필수인 자료가 없거나 파일을 만들 수 없을 때 질문해줘.
확인하지 못한 숫자는 임의로 채우지 마.

확인할 것: 다운로드한 파일을 열어보세요. 파일이 존재하는지, 근거가 실제 자료의 해당 위치에 있는지, 한 장 안에서 읽을 수 있는지를 확인합니다. “파일을 만들었다”는 답변만으로 완료를 판단하지 않습니다.

프롬프트 3. 비슷비슷한 AI 디자인에서 벗어나기

이럴 때: “세련되게”라고 해도 같은 색·버튼·배치만 반복될 때 사용합니다. 공식 가이드도 피할 디자인 요소를 구체적으로 지정하라고 권합니다. 프런트엔드 디자인 지침

온라인 개발 강의 소개 페이지를 index.html 하나로 만들어줘.
처음 배우는 사람이 강의 대상과 실습 결과를 빠르게 파악하는 것이 목적이야.

디자인 방향
- 흰 배경, 검은 본문, 파란색 강조를 사용한다.
- 첫 화면에 강의 대상, 만들 결과물, 수강 안내 버튼을 배치한다.
- 본문은 타이포그래피와 여백으로 구분한다.

피할 요소
- 보라색 그라데이션과 유리처럼 반투명한 카드
- 모든 섹션을 같은 크기의 카드 3개로 나누는 배치
- 내용과 관계없는 장식 아이콘

완료 기준
- 390px와 1440px 너비에서 가로 스크롤이 없다.
- 수강 안내 버튼을 누르면 강의 안내 영역으로 이동한다.
- 키보드로 이동할 때 버튼의 포커스가 보인다.

허구의 후기·수강생 수·판매 실적은 넣지 마.
브라우저로 확인할 수 있다면 검사하고, 못 했다면 그 항목을 알려줘.

확인할 것: 원하는 색을 썼는지만 보지 말고, 처음 보는 사람이 강의 대상을 이해할 수 있는지 확인하세요. 수정할 때도 “더 예쁘게”보다 “첫 화면의 설명을 두 줄로 줄여줘”처럼 한 가지 문제를 집어주는 편이 명확합니다.

프롬프트 4. Claude Code의 “계속할까요?” 줄이기

이럴 때: 이미 맡긴 구현과 확인 작업이 남아 있는데 중간 보고에서 자꾸 멈출 때 사용합니다. 프로젝트의 기존 CLAUDE.md에 필요한 부분을 추가하세요. 기존 규칙 전체를 덮어쓰지는 마세요.

## 작업 완료와 질문 기준

- 승인된 작업 범위 안에서 구현과 검증까지 진행한다.
- 진행 상황을 알린 뒤, 내 답변이 필요 없는 다음 작업을 이어서 한다.
- 선택이 필요한 항목이 있어도 그 결정과 무관한 작업은 진행한다.
- 필수 정보·권한이 없어서 더 진행할 수 없을 때 질문한다.
- 데이터 삭제, 강제 푸시, 외부 공개·발송은 실행 전에 확인한다.
- 완료 기준을 충족하면 추가 작업을 만들지 않고 결과를 보고한다.

## 긴 작업의 기록

- 여러 단계의 작업은 TASKS.md에 할 일과 확인 결과를 기록한다.
- 끝낸 항목과 막힌 항목을 구분한다.
- 같은 문제로 시도가 반복되면 원인과 시도한 방법을 보고한다.

확인할 것: 이 문장은 권한 확인을 해제하는 설정이 아닙니다. 실제로 입력이 필요한 중단과 단순 진행 보고를 구분하려는 규칙입니다. 자동화 프로그램이 응답 종료를 작업 완료로 처리한다면 프롬프트만 바꿔서는 해결되지 않을 수 있습니다. 무인 에이전트 실행 지침

프로젝트 규칙 파일이 처음이라면 Claude Code 폴더 설정 가이드도 함께 읽어보세요.

프롬프트 5. 버그 수정을 재현부터 검증까지 맡기기

이럴 때: “고쳤다”는 답변을 받았는데 같은 문제가 다시 발생할 때 사용합니다. Claude Code에서 프로젝트를 열고 실제 재현 정보를 채워 넣으세요.

장바구니에서 수량을 바꿔도 합계가 갱신되지 않는 문제를 수정해줘.

재현 정보
- 실행 방법: [개발 서버 실행 명령]
- 문제가 생기는 화면: [경로]
- 현재 결과: [예: 수량이 2여도 1개 가격이 표시됨]
- 기대 결과: [예: 단가 10000원, 수량 2이면 합계 20000원]

완료 기준
- 원인을 코드 위치와 함께 설명한다.
- 기존 프로젝트 방식에 맞춰 필요한 범위만 수정한다.
- 위 재현 조건을 다시 검사하고, 관련 기존 검사도 실행한다.
- 입력값이 비어 있거나 0일 때의 기존 정책이 유지되는지 확인한다.

수량 정책이 정의되어 있지 않으면 임의로 바꾸지 말고 질문해줘.
실행하지 못한 검사는 통과했다고 쓰지 말고 이유를 적어줘.

확인할 것: 수정한 코드의 양보다 재현 조건이 해결됐는지 확인하세요. 상품 조회·삭제처럼 주변 기능이 의도치 않게 달라지지 않았는지도 검토합니다.

프롬프트 6. 차트와 원본 데이터의 차이 찾기

이럴 때: 대시보드의 인상과 실제 수치가 맞는지 확인할 때 사용합니다. 아래 대조 프롬프트에는 차트 캡처와 원본 CSV가 모두 필요합니다. CSV가 없으면 원본과 일치하는지는 확인할 수 없으므로, 화면에서 읽을 수 있는 내용만 요청하세요.

첨부한 차트와 원본 CSV를 대조해줘.

확인할 항목
- 차트의 기간·단위·필터와 CSV의 조건이 같은지
- 그래프에 표시된 값과 원본 값이 일치하는지
- 비율 변화가 %인지 퍼센트포인트인지 구분되어 있는지

결과는 '항목 / 차트 값 / 원본 값 / 차이 / 확인 위치' 표로 만들어줘.
화면이 흐리거나 조건이 달라 비교할 수 없으면 확인 불가로 표시해줘.
읽을 수 없는 숫자를 추정해서 계산하지 마.

확인할 것: 10%에서 15%로 변했다면 5퍼센트포인트 상승이고, 상대 증가율은 50%입니다. 이처럼 해석이 달라지는 부분을 직접 대조해보세요. 캡처만으로 안 읽히는 수치는 더 선명한 이미지나 원본 데이터가 필요합니다.

프롬프트 7. 조사 결과를 사실과 추정으로 나누기

이럴 때: 최신 기능·가격·출시일을 조사할 때 사용합니다. 웹 검색이 가능한 환경에서 요청하세요.

[비교할 제품 2개]를 [내 사용 목적] 기준으로 비교해줘.

완료 기준
- 공식 문서를 먼저 확인하고, 확인 날짜를 적는다.
- 가격·사용 한도·지원 기능을 같은 조건으로 비교한다.
- 각 행에 근거 URL을 연결한다.
- 공식적으로 확인한 사실, 자료를 바탕으로 한 해석,
  확인하지 못한 내용을 구분한다.

검색 결과 요약만 보고 단정하지 말고 원문을 확인해줘.
자료가 없으면 어디까지 확인했는지 적어줘.
마지막에는 내 목적에 맞는 선택 기준을 세 문장으로 정리해줘.

확인할 것: 링크를 직접 열어 해당 주장과 일치하는지 확인합니다. 링크가 존재하는 것과 그 링크가 주장을 뒷받침하는 것은 별개입니다. AI 환각을 줄이는 사실 기반 프롬프트에서 확인 기준을 더 살펴볼 수 있습니다.

프롬프트 8. 코드 리뷰에서 중요한 문제만 받기

이럴 때: 코드 리뷰가 취향이나 사소한 스타일 지적으로 길어질 때 사용합니다. 비교할 브랜치와 변경 목적을 함께 알려주세요.

현재 변경을 [기준 브랜치]와 비교해서 리뷰해줘.
변경 목적은 [이번 변경이 해결하려는 문제]야.

기능 오류, 데이터 손실, 접근 제어 문제처럼
병합 전에 해결해야 할 문제를 우선 찾아줘.

각 문제에는 다음을 적어줘.
- 파일 경로와 줄 번호
- 문제가 발생하는 입력이나 사용자 행동
- 실제 영향과 확인 방법
- 직접 재현했는지, 코드만 보고 추정했는지

스타일 취향은 제외하고, 리뷰 중 파일을 수정하지 마.
확인된 문제가 없으면 그 사실과 검토하지 못한 범위를 알려줘.

확인할 것: 지적 개수보다 재현 가능한 문제가 있는지가 중요합니다. AI가 문제를 찾지 못했다고 오류가 없다고 확정할 수는 없습니다.

개발자 실습: API에서 medium으로 호출하기

Claude 앱만 사용한다면 이 부분은 건너뛰어도 됩니다. 아래 예시는 Claude API에 별도로 과금되는 요청이며, API 키와 curl, jq가 필요합니다. curl은 요청을 보내고, jq는 JSON 응답에서 본문을 꺼내는 도구입니다. macOS·Linux의 Bash·Zsh 기준이며, curl --version과 jq --version으로 설치 여부를 먼저 확인하세요. --fail-with-body는 curl 7.76.0 이상에서 지원합니다.

Claude Console에서 발급한 단일 워크스페이스용 API 키를 기준으로 설명합니다. 여러 워크스페이스에 접근하는 키라면 요청에 anthropic-workspace-id 헤더도 필요합니다. 구독 로그인만으로 이 API 예제를 실행할 수는 없습니다. 공식 API 인증 안내

먼저 아래 내용을 request.json으로 저장합니다. 실습 데이터는 가상의 회의 메모입니다.

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [
    {
      "role": "user",
      "content": "가상 회의 메모를 Markdown 보고서로 정리해줘. 메모: 문서 검색이 어렵다는 의견 12건. 이번 주에 검색 필터 시안을 만든다. 담당자는 미정. 다음 회의는 10월 2일이며 연도는 기록에 없다. 완료 기준: 결론 1문장, 핵심 3개, 확인이 필요한 사항을 포함한다. 메모에 없는 담당자·연도·요일은 만들지 않는다. 본문만 출력하고 코드 블록으로 감싸지 않는다."
    }
  ]
}

같은 폴더의 터미널에서 아래 한 줄을 실행하고 API 키를 입력한 다음 Enter를 누르세요. 입력한 키는 화면에 표시되지 않습니다.

read -r -s ANTHROPIC_API_KEY

아래 블록 전체를 한 번에 실행하세요. 요청이 성공하고 텍스트 응답이 정상 종료된 경우에만 report.md를 저장합니다. 예제의 response.json과 report.md는 실습 폴더에서 쓰는 파일명입니다. 정상 저장 시 기존 보고서는 덮어씁니다.

if curl --fail-with-body --silent --show-error \
  https://api.anthropic.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  --data-binary @request.json \
  --output response.json; then
  if jq -e '.stop_reason == "end_turn" and any(.content[]?; .type == "text" and (.text | length) > 0)' response.json > /dev/null; then
    if jq -r '[.content[] | select(.type == "text") | .text] | join("\n\n")' response.json > report.md; then
      printf '%s\n' 'report.md를 저장했습니다. 내용은 직접 확인하세요.'
      jq '.usage' response.json
    fi
  else
    printf '%s\n' '새 보고서를 저장하지 않았습니다. 기존 report.md와 혼동하지 마세요.'
    jq '{stop_reason, error}' response.json
  fi
else
  printf '%s\n' '요청 실패: curl 오류를 확인하세요. 기존 보고서는 이번 실행 결과가 아닙니다.'
fi

핵심은 "output_config": { "effort": "medium" }입니다. max_tokens는 생각 토큰과 응답 텍스트를 포함한 출력 상한이므로, 도중에 한도에 도달하면 결과가 잘릴 수 있습니다. stop_reason이 max_tokens라면 완료로 취급하지 말고 요청 분량과 출력 상한을 검토하세요. Effort 설정 문서

Opus 5.5는 생각 기능을 끄는 "thinking": { "type": "disabled" }를 지원하지 않습니다. 또 응답의 첫 블록이 반드시 본문은 아니므로, 예시처럼 type이 text인 블록을 골라야 합니다. API 변경 사항

이 예시는 문서상의 요청 형식에 맞춘 코드입니다. 실제 API 호출의 성공 여부와 사용량은 자신의 계정에서 실행해 확인하세요. end_turn은 모델의 응답 종료를 뜻하며, 보고서가 내용상의 완료 기준까지 충족했다는 보장은 아닙니다. 생성된 report.md에 핵심 3개가 있는지, 담당자·연도·요일을 임의로 정하지 않았는지도 확인합니다.

사용량을 아끼려면 무엇부터 점검할까요?

한 번의 응답을 짧게 만드는 것과 업무 전체의 사용량을 줄이는 것은 다릅니다. 너무 짧아서 여러 번 재요청하거나, 불필요한 기능을 계속 추가하면 전체 작업이 커질 수 있습니다.

다음은 이 글의 예시를 적용할 때 함께 사용할 운영 기준입니다.

1. 대표 업무 하나로 비교하세요. 같은 자료와 완료 기준으로 설정을 바꿔보고, 정확성·소요 시간·사용량을 기록합니다.
2. 첫 결과물의 범위를 작게 정하세요. 보고서가 필요하면 보고서부터, 기능이 필요하면 핵심 동작부터 완료하게 합니다.
3. 통과하면 끝내세요. 검사가 통과한 뒤 요청하지 않은 확장 작업까지 이어가지 않도록 합니다.
4. 재시도에는 이유를 붙이세요. “다시 해줘” 대신 실패한 조건과 기대 결과를 알려주세요.
5. 동시에 맡기는 작업 수를 관리하세요. 병렬 작업은 기다리는 시간을 줄여도 전체 토큰을 줄인다고 보장하지는 않습니다.

프롬프트에 “10분 안에”, “적당히 사용해”라고 적는 것만으로 실제 시간·과금 상한이 설정되지는 않습니다. 비용 제한이 필요하면 사용하는 제품의 예산·사용량 설정도 확인하세요.

자주 묻는 질문

다음 요청 하나부터 바꿔보세요

새 모델을 쓰기 위해 모든 업무 방식을 한꺼번에 바꿀 필요는 없습니다. 지금 해야 할 일 하나를 고르고 아래 세 가지만 확인해보세요.

• Opus 5.5의 Effort를 medium으로 확인했다.
• 결과물의 형식과 완료 기준을 적었다.
• 질문할 조건과 결과 확인 방법을 적었다.

보고서라면 파일을 열어 근거를 확인하고, 코드라면 문제가 생기던 조건으로 다시 실행해보세요. 좋은 프롬프트의 목표는 긴 답변을 받는 것이 아니라, 내가 확인하고 사용할 수 있는 결과물을 받는 것입니다.

함께 읽으면 좋은 글

• Claude Code 폴더 설정: CLAUDE.md·Skills·Agents·Hooks
• AI 환각을 줄이는 사실 기반 프롬프트