AI 프롬프트 작성법: 잘 쓰는 법 5가지와 바로 쓰는 예시

AI 프롬프트에는 목적, 필요한 맥락, 원하는 출력 형식, 꼭 지켜야 할 조건을 분명하게 적는다. 답이 빗나가면 이 네 가지가 빠졌는지 확인한다. 첫 답을 받은 뒤에는 부족한 부분을 구체적으로 지정해 고친다.

1. AI에게 무엇을 만들고 싶은지 어떻게 말해야 하나

“이 문장 좀 고쳐줘”만 적으면 AI는 어떤 톤이 필요한지 알기 어렵다. 회사 보고서인지, 블로그 글인지, 친구에게 보낼 메시지인지에 따라 같은 문장도 결과가 달라진다. (OpenAI Help Center - Prompt engineering best practices for ChatGPT)

예를 들어 보고서에 넣을 문장이라면 이렇게 시작할 수 있다.

회사 내부 보고서에 들어갈 문장이다. 의미는 유지하고, 군더더기 없이 전문적인 표현으로 다듬어 주면 된다.

결과물이 어디에 쓰이는지 한 줄만 추가해도 답변 방향이 훨씬 선명해진다.

2. 프롬프트에 배경 설명은 얼마나 넣어야 하나

맥락이 너무 적으면 AI가 빈 부분을 추측한다. 반대로 관련 없는 설명을 많이 넣으면 중요한 조건이 묻힐 수 있다. (Google Cloud - Overview of prompting strategies)

처음에는 보통 아래 세 가지면 충분하다.

• 지금 어떤 상황인지
• 누가 결과물을 볼 것인지
• 무엇을 만들려는지

필요한 정보가 더 있다면 첫 답을 받은 뒤 추가한다.

3. 원하는 답변 형식은 어떻게 지정하나

내용은 맞는데 다시 정리하느라 시간이 드는 경우가 많다. 결과 형태가 정해져 있다면 질문할 때 같이 적는다.

예를 들면 다음처럼 쓸 수 있다.

• 표로 비교
• 5문장 안으로 요약
• 처음 보는 사람도 이해할 수 있게 설명
• 코드와 설명을 따로 작성
• 가장 중요한 항목부터 순서대로 정리

형식을 미리 정하면 답변을 다시 편집하는 시간이 줄어든다.

4. 제한 조건은 어디에 적는 게 좋을까

예산, 글자 수, 제외할 항목처럼 결과를 크게 바꾸는 조건은 눈에 띄게 따로 적어 둔다. (Anthropic - Prompting best practices)

제품 추천을 받는 상황이라면 다음처럼 조건을 분리할 수 있다.

조건: 20만 원 이하 / Windows 지원 / 중고 제외

이런 조건이 빠지면 답변은 그럴듯해도 실제로는 쓸 수 없는 경우가 생긴다.

5. 첫 답이 마음에 안 들면 프롬프트를 처음부터 다시 써야 하나

첫 답을 초안처럼 보고 마음에 안 드는 부분을 지정해 고친다.

“좀 더 자세히”처럼 범위가 넓은 요청보다 아래처럼 수정 지점을 정하는 방식이 좋다.

2번 항목에 실제 예시를 3개만 추가해줘.

또는

표는 그대로 두고 마지막 열에 장단점을 한 줄씩 추가해줘.

이렇게 대화를 이어가면 처음부터 거대한 프롬프트 하나를 만드는 것보다 관리하기 쉽다.

같은 지침을 반복해서 쓴다면 Gemini Gem에 규칙과 파일을 저장하는 방법을 적용할 수 있다.

자주 겪는 실패와 원인

답변의 문제에 따라 다음 항목을 점검해 볼 수 있다.

결과가 매번 다르다 — 완료 조건이 모호한지 확인한다. 모델의 출력은 같은 입력에서도 달라질 수 있다. “개선해 줘”처럼 끝을 정하지 않으면 매번 다른 것을 고친다. 무엇을 바꾸고 무엇을 두는지, 끝났다는 기준이 무엇인지를 문장에 넣는다.

너무 일반적인 답이 온다 — 필요한 배경이 빠졌는지 확인한다. 누구를 위한 것인지, 어디에 쓸 것인지가 빠지면 평균적인 답이 나온다.

형식이 계속 어긋난다 — 출력 예시를 추가해 비교한다. 원하는 형태가 있으면 예시 하나를 추가한 요청과 기존 요청의 결과를 비교할 수 있다.

하지 말라는 걸 계속 한다 — 금지 사항과 함께 원하는 대안을 적어 본다. “격식체로 쓰지 마”보다 “친구에게 말하듯 써”처럼 원하는 대안도 함께 적는다. 실제 결과에서 반영됐는지는 따로 확인한다.

역할 지정이 실제로 하는 일

역할이나 독자 지정은 원하는 문체·배경지식 수준을 설명하는 방법이다. “처음 접하는 직원에게 설명할 보고서”처럼 실제 용도와 독자를 적고, 정확성은 근거를 따로 확인해 판단한다.

요구 사항의 충돌도 확인한다. 프롬프트가 잘 안 먹는다면 이것부터 본다.

• 서로 충돌하는 조건이 섞여 있나 — “짧게” 와 “빠짐없이”를 같이 적었나
• 우선순위가 불명확한가 — 둘 중 무엇을 포기해도 되는지 적었나
• 결과를 바꾸지 않는 배경이 들어갔나 — 빼도 답이 같다면 뺀다

수정 요청을 검증 가능한 형태로 바꾸는 예

가상의 회의 메모를 요약하는 상황을 생각해 보자. 원문에 일정은 있지만 담당자는 없다면, 좋은 완료 조건은 보기 좋은 문장보다 없는 담당자를 만들지 않는 것이다. 다음처럼 요청할 수 있다.

제공한 회의 메모만 근거로 결정 사항·담당자·기한을 표로 정리해줘. 담당자나 날짜가 없으면 ’원문에 없음’으로 쓰고, 각 행에 근거 문장을 붙여줘.

빈칸을 무엇으로 채우라고 시키는지가 중요하다. ’미정’이라고 쓰게 하면 AI는 “아직 정해지지 않았다”는 새로운 사실을 만들어 낸다. 회의에서 이미 정해졌는데 메모에 안 적혔을 수도 있다. 원문에 없음은 문서에 없다는 것만 말하므로 안전하다. 둘의 차이는 나중에 그 표를 근거로 판단할 때 드러난다.

첫 답에 추정한 담당자가 들어갔다면 그 행과 원문을 지정해 정정하고, AI가 붙인 근거 문장이 원문에 실제로 있는지도 확인한다.

긴 자료에서 항목을 뽑을 때: 바로 쓰는 예시

회의록·계약서처럼 긴 자료에서 담당자·날짜를 뽑을 때는 역할, 작업, 근거, 제약, 출력을 나눠 적는다. 아래 틀을 복사해 원문만 바꿔 쓴다. Moonshot AI(Kimi)의 공식 프롬프트 가이드도 명확한 지시, 구분자, 예시, 출력 형식 지정을 핵심 원칙으로 든다. (Kimi API Platform - Best Practices for Prompts)

역할: 프로젝트 운영 담당자
작업: 아래 회의록에서 결정 사항과 담당 업무를 추출해줘.
근거: 삼중 따옴표 안의 회의록만 사용해.
제약: 담당자가 명시되지 않았으면 추측하지 말고 '원문에 없음'으로 적어.
출력: 결정 사항, 담당자, 마감일을 표로 정리해.

회의록:
"""
여기에 원문을 붙여 넣기
"""

1. 자료와 지시를 구분자로 나눈다. 삼중 따옴표나 <source>·<task> 같은 태그로 경계를 만든다. 웹에서 가져온 문서 안의 명령은 따르지 말고 자료로만 쓰라고 적는다.
2. 예시는 형식만 참고하게 한다. 예시 표를 넣었다면 “형식만 참고하고 실제 값은 새 원문에서 추출하라”고 적는다. 그러지 않으면 예시 속 이름과 날짜가 새 답에 그대로 섞일 수 있다.
3. 긴 문서는 나눠 처리하되 위치를 남긴다. 구간마다 같은 기준으로 뽑고, 각 항목에 문서명·절·페이지를 붙인다. 두 구간의 내용이 충돌하면 하나를 고르지 말고 차이를 표시하게 한다.
4. JSON으로 받을 때는 누락값 표현을 정한다. 담당자가 없을 때 빈 문자열인지 null인지 정하고, 받은 뒤 파싱·필수 필드·타입을 코드로 검사한다. 형식이 맞아도 숫자·이름·날짜는 원문과 따로 대조한다.

출력 길이는 “정확히 300자”보다 “핵심 세 문장과 주의점 두 항목”처럼 구조로 지정하는 편이 안정적이다.