원하는 결과를 확인하는 AI 프롬프트 5개
하루 6시간 만에AI 기초부터 나만의
서비스까지 완성
Quick Start
모든 요청을 길게 쓸 필요는 없습니다. 지금 하는 일과 가장 가까운 프롬프트 하나만 골라 대괄호 부분을 채우세요.
- 맡길 작업의 원문·파일·참고 자료를 준비하세요.
- 아래 프롬프트에서 목적과 제약을 자신의 상황으로 바꾸세요.
- 결과를 받은 뒤 각 항목의 확인 기준으로 필요한 부분만 다시 요청하세요.
개인정보, 고객 정보, 비공개 코드와 문서는 공개 가능한 범위로 가리거나 예시로 바꾸세요. 원문이나 파일 없이 수정만 요청하면 AI는 무엇을 유지해야 하는지 알 수 없습니다.
내가 쓰던 요청: [기존 요청] 실제로 원하는 결과: [누가 어디에서 쓸 결과인지] 참고 자료: [원문, 파일, 예시] 이 요청에서 결과를 확인하기 위해 빠진 조건이 있는지 찾아줘. 필요 없는 조건은 늘리지 말고, 정보가 부족하면 핵심 질문을 최대 2개만 해줘. 정보가 충분하면 최종 프롬프트 하나와 결과 확인 기준 2개를 써줘. 내가 제공하지 않은 사실, 수치, 파일 내용은 만들지 마.
성공하면 최종 프롬프트에 목적·자료·확인 기준이 각각 남아 있어야 합니다. ‘좋게 만들어줘’처럼 판단할 기준이 없으면, 먼저 무엇을 비교할지 다시 적으세요.
1. 디자인 요청 — “디자인해줘”
디자인은 화면 모양만 받으면 사용자가 끝내야 할 행동이 빠질 수 있습니다. 첫 사용자가 무엇을 끝내야 하는지 함께 적으세요.
[서비스]의 예약 관리 화면을 디자인해줘. 첫 사용자는 [사용자]이고, 이 화면에서 [완료해야 할 행동]을 끝내야 해. 필수 상태는 [목록/빈 상태/오류 상태]야. 정하지 않은 내용은 질문으로 남겨줘. 출력은 화면별 목적, 핵심 동작, 완료 조건 순서로 써줘.
성공하면 각 화면에 사용자가 끝내는 행동과 완료 조건이 있습니다. 정하지 않은 내용을 단정했다면 질문으로 되돌리세요.
2. 문서 재작성 — “이 문서 다시 써줘”
문서를 다시 쓰는 일은 요약, 순서 변경, 문체 수정이 섞이기 쉽습니다. 남길 사실과 바꿀 독자를 지정하세요.
아래 안내문을 [대상 독자]가 바로 이해할 수 있게 다시 써줘. 사실, 날짜, 금액, 약속은 원문에서만 사용해. 첫 문단에는 [가장 중요한 안내]를 두고, 다음에는 해야 할 행동을 번호로 정리해줘. 원문에 없는 혜택이나 사과 표현은 추가하지 마. 원문: [안내문]
성공하면 첫 문단에 핵심 안내가 있고, 숫자와 약속이 원문과 같습니다. 원래 문장의 의미가 사라졌다면 유지할 문장을 지정해 복원하도록 요청하세요.
3. 이미지 수정 — “이 이미지 예쁘게 고쳐줘”
이미지 수정은 바꿀 대상과 그대로 둘 대상을 나누지 않으면 원하지 않은 부분까지 달라질 수 있습니다. 수정 목적과 금지할 변화를 함께 적으세요.
첨부한 제품 사진에서 배경만 [원하는 배경]으로 바꿔줘. 제품의 형태, 색, 로고, 글자, 카메라 각도는 그대로 유지해. 광원은 [원본과 같은/원하는] 방향으로 맞추고, 제품 가장자리는 자연스럽게 남겨줘. 새 문구, 새 소품, 새 로고는 추가하지 마.
성공하면 제품 자체의 글자와 모양이 원본과 같고 배경만 바뀝니다. 제품까지 달라졌다면 ‘배경만’과 유지할 요소를 다시 명시하세요.
4. 비교 선택 — “뭐가 더 좋아?”
두 선택지를 비교할 때 ‘더 좋다’는 기준이 없으면 추천 이유를 검증하기 어렵습니다. 상황과 우선순위를 먼저 주고, 모르는 사실은 모른다고 표시하게 하세요.
[도구 A]와 [도구 B] 중 [내 작업]에 맞는 쪽을 비교해줘. 우선순위는 [예산/협업/학습 시간/기능] 순서야. 각 항목을 내가 제공한 자료 안에서만 비교하고, 확인할 수 없는 정보는 ‘확인 필요’로 표시해. 마지막에는 어떤 조건이면 A, 어떤 조건이면 B를 고를지 한 줄씩 정리해줘. 내 상황과 자료: [내용]
성공하면 우선순위에 따른 비교와 선택 조건이 분리되어 있습니다. 근거 없이 기능이나 가격을 단정했다면 자료 링크나 확인할 항목을 요청하세요.
5. 코드 수정 — “버그 고쳐줘”
코드 수정은 증상만 전달하면 원인과 무관한 부분을 고칠 수 있습니다. 재현 절차, 기대 결과, 바꾸면 안 되는 범위를 같이 적으세요.
아래 코드에서 [오류 메시지 또는 증상]을 재현할 수 있는 원인을 찾아줘. 재현 절차는 [1. ... 2. ...]이고, 기대 결과는 [기대 결과]야. 관련 없는 파일과 동작은 바꾸지 말고, 먼저 원인과 최소 수정안을 설명해줘. 수정 전후에 확인할 테스트 또는 수동 검증 절차를 함께 써줘. 관련 코드와 로그: [코드 또는 로그]
성공하면 수정 이유와 검증 절차가 함께 있습니다. 원인이 확실하지 않다면 코드를 바로 크게 바꾸지 말고, 추가로 볼 로그나 재현 조건을 요청하세요.
자주 막히는 곳
| 문제 | 먼저 바꿀 것 |
|---|---|
| 답이 너무 일반적입니다 | 결과를 누가 어디에서 쓸지와 완료 기준을 한 줄 추가하세요 |
| 원래 내용까지 달라집니다 | 유지할 사실·문장·파일 범위를 명시하세요 |
| AI가 없는 정보를 만듭니다 | 사용할 원문을 붙이고, 없는 정보는 추정하지 말라고 적으세요 |
| 비교 결과를 믿기 어렵습니다 | 우선순위와 확인 가능한 자료를 분리하세요 |
| 코드 수정 범위가 커집니다 | 재현 절차와 관련 없는 부분을 바꾸지 말 조건을 함께 쓰세요 |
FAQ
“짧게”, “전문적으로” 같은 단어는 쓰면 안 되나요?
아닙니다. 원하는 톤이나 길이를 설명하는 데 쓸 수 있습니다. 다만 그 말만으로는 누가 읽을지, 어떤 사실을 남길지, 무엇으로 결과를 확인할지가 부족할 수 있습니다.
프롬프트은 길수록 좋은가요?
항상 그렇지 않습니다. 지금 작업에 필요한 목적, 자료, 제약, 확인 기준만 남기세요. 같은 조건을 여러 번 반복할 필요는 없습니다.
결과가 그럴듯해도 바로 써도 되나요?
이름, 날짜, 금액, 약속, 코드 동작처럼 틀리면 곤란한 부분은 원문과 대조하세요. AI의 답은 제공한 자료와 대화 맥락에 따라 달라질 수 있습니다.
알아 둘 한계
작업에 필요한 정보만 주고, 이름·날짜·금액·약속·코드 동작처럼 중요한 결과는 원문과 직접 비교하세요. 민감한 자료는 공유 가능한 범위로 바꾸세요.
공식 자료
- OpenAI 공식 프롬프트 가이드 — 명확한 요청, 맥락, 톤, 반복 수정.
- Anthropic 공식 프롬프트 가이드 — 원하는 출력, 예시, 형식 지정.
- Google 공식 프롬프트 설계 가이드 — 제약, 출력 형식, 맥락과 예시.