프롬프트 잘 쓰는 법

AI 답변이 뜬구름 같을 때, 모델을 탓하기 전에 확인할 게 있습니다. 같은 모델이라도 질문의 꼴에 따라 결과가 크게 달라지고, 그 꼴을 만드는 규칙은 다섯 개면 충분합니다. 아래 원칙마다 흔히 쓰는 프롬프트와 고친 프롬프트를 나란히 놓았습니다.

기준일: 2026-07-15 — 원칙은 잘 안 변하지만, 예시 속 완성형 링크는 라이브러리를 따라 늘어납니다.

원칙 1 — 상황 먼저 주기

AI는 내 사정을 모릅니다. 누가, 누구에게, 왜 쓰는 글인지가 빠지면 어디에나 맞는 평균적인 답이 옵니다.

흔한 프롬프트공지문 써줘. 다음 주부터 재택근무 제도 바뀜.

고친 프롬프트사내 공지문 초안을 써주세요. 대상은 전 직원 80명, 내용은 다음 주 월요일부터 재택이 주 2회로 줄어드는 변경입니다. 불만이 예상되는 공지라서, 변경 이유(사무실 협업 문제)를 먼저 설명하고 톤은 사무적이되 딱딱하지 않게 해주세요.

바뀐 건 정보 세 가지입니다: 읽는 사람, 배경, 원하는 톤. 사내 공지문 초안 만들기가 이 구조로 짜여 있습니다.

원칙 2 — 결과물의 꼴 정하기

"정리해줘"는 AI에게 형식 결정권을 넘기는 말입니다. 표인지, 다섯 줄인지, 항목별인지를 정하면 받은 걸 그대로 쓸 수 있습니다.

흔한 프롬프트이 회의 메모 정리해줘.

고친 프롬프트이 회의 메모를 공유용 회의록으로 정리해주세요. 형식은 세 부분 — 결정된 것 / 할 일(담당자·기한 포함) / 아직 논의 중인 것.

회의 메모를 회의록으로 바꾸기가 이 형식을 조건까지 포함해 갖춰둔 완성형입니다.

원칙 3 — 하지 말 것을 조건으로 걸기

AI는 빈칸을 그럴듯하게 채우려는 성질이 있습니다. 이걸 막는 건 요청이 아니라 조건입니다.

흔한 프롬프트(위 회의록 요청에 이어서) 빠진 내용은 알아서 채워줘.

고친 프롬프트메모에 없는 내용은 추측해서 채우지 마세요. 담당자나 기한이 안 적힌 항목은 [확인 필요]로 표시해주세요.

지어내는 대신 모른다고 표시하게 만드는 것 — 업무용 프롬프트에서 가장 값어치 있는 한 줄입니다.

원칙 4 — 예시로 원하는 톤 보여주기

원하는 결과의 느낌을 말로 설명하기 어려우면, 잘된 사례 하나를 붙이는 쪽이 빠릅니다.

흔한 프롬프트우리 서비스 소개 문장을 좀 세련되게 써줘.

고친 프롬프트우리 서비스 소개 문장을 써주세요. 톤은 아래 예시처럼 — 기능 나열 대신 사용자가 얻는 것 하나로 시작하는 방식입니다. 예시: "회의가 끝나면 회의록도 끝나 있습니다."

원칙 5 — 결과 검증시키기

프롬프트는 보내는 데서 끝나지 않습니다. 결과를 그대로 믿는 대신, 검토를 한 번 더 시키는 게 기본기의 마지막 조각입니다.

고친 프롬프트(후속으로)방금 결과에서 사실 확인이 필요한 부분과 논리가 약한 부분을 스스로 지적해주세요.

제출 직전이라면 제출 전 마지막 검토시키기, 계획 단계라면 내 계획, 반박시켜 보기가 이 용도의 완성형입니다. 질문 자체가 애매한 것 같을 땐 내 질문을 좋은 질문으로 바꾸기로 질문부터 고칠 수 있습니다.

다섯 원칙을 자동으로 쓰는 방법

다섯 원칙을 매번 손으로 조립할 필요는 없습니다. 자주 하는 일이면 원칙이 이미 적용된 완성형 라이브러리에서 골라 쓰고, 내 업무에 맞는 걸 처음부터 만들고 싶으면 프롬프트 메이커가 문진으로 물어가며 대신 조립합니다. 매주 반복되는 일이라면 결과에서 클로드 프로젝트 세팅까지 만들어줍니다.

자주 묻는 질문

역할 부여("너는 전문 마케터야")는 안 넣나요? 필요할 때만 넣는 게 요즘 기준입니다. 결과물의 시선이 중요한 작업(전문가 관점 검토 등)엔 효과가 있지만, 요약·정리 같은 일엔 상황·형식·조건이 훨씬 크게 작동합니다.

정중하게 부탁하면 답이 좋아지나요? 유의미한 차이는 없습니다. 예의 문장을 늘리는 것보다 정보 한 줄을 더 주는 쪽이 낫습니다.

길게 쓸수록 좋은 프롬프트인가요? 아닙니다. 기준은 길이가 아니라 위 다섯 가지가 들어 있는가입니다. 필요한 정보 없이 길기만 한 프롬프트가 제일 나쁜 경우입니다.