생성형 AI를 어느 정도 사용하다 보면 오히려 질문이 더 복잡해질 때가 있다.
처음에는 “이 내용 요약해줘”처럼 간단하게 시작했는데, 활용 범위가 넓어지면서 역할도 지정하고, 독자도 정하고, 분량도 설정하고, 출력 형식과 금지 조건까지 붙이게 된다.
그러다 보면 반대로 이런 고민이 생긴다.
“프롬프트에 뭘 더 넣어야 하지?”
“이 정도면 충분한가?”
“왜 조건을 많이 넣었는데도 결과가 애매하지?”
이럴 때 필요한 것은 새로운 프롬프트 공식보다 지금 작성한 요청에 핵심 정보가 제대로 들어갔는지 확인하는 기준이다.
이번 글에서는 생성형 AI에게 질문을 보내기 전에 확인하면 좋은 항목을 실제 작업 순서에 맞춰 정리해본다.
1. 가장 먼저 ‘최종 결과물’을 한 문장으로 정한다
프롬프트를 작성하기 전에 가장 먼저 확인할 것은 AI에게 무엇을 시킬 것인지다.
당연한 이야기처럼 들리지만, 실제로는 이 부분이 가장 쉽게 흐려진다.
예를 들어,
“아래 자료를 분석해줘.”
라고 요청할 수 있다.
하지만 ‘분석’이라는 말 안에는 여러 작업이 포함될 수 있다.
핵심 내용을 요약하는 것인지, 문제점을 찾는 것인지, 여러 항목을 비교하는 것인지, 개선 아이디어를 만드는 것인지 명확하지 않다.
이럴 때 먼저 자신에게 질문해보면 좋다.
“AI의 답변을 받은 다음 나는 무엇을 하려고 하는가?”
회의 내용을 팀장에게 보고하려는 것이라면 결과물은 ‘회의 결과 보고서’다.
여러 아이디어 중 하나를 고르려는 것이라면 결과물은 ‘비교 평가표’일 수 있다.
블로그 글을 쓰기 전이라면 ‘본문 초안’이 아니라 ‘글의 구성안’만 필요한 상황도 있다.
최종 결과물이 분명하면 프롬프트도 자연스럽게 단순해진다.
예를 들어,
“아래 회의 메모를 분석해줘.”
보다,
“아래 회의 메모에서 확정된 사항과 추가 논의가 필요한 사항을 구분해서 정리해줘.”
가 훨씬 구체적이다.
프롬프트의 첫 번째 점검 항목은 항상 같다.
내가 원하는 최종 결과를 한 문장으로 설명할 수 있는가?
2. AI가 알아야 할 배경을 필요한 만큼만 넣는다
목표를 정했다면 다음에는 AI가 작업을 수행하는 데 필요한 맥락을 제공한다.
여기서 중요한 것은 ‘많이 설명하는 것’이 아니라 ‘필요한 설명을 하는 것’이다.
예를 들어 이메일을 작성한다고 해보자.
AI가 알아야 할 정보는 보통 수신 대상, 전달 목적, 현재 상황, 반드시 포함해야 할 내용 정도다.
반면 해당 업무가 시작된 몇 달 전 이야기까지 모두 설명할 필요는 없을 수 있다.
블로그 글도 비슷하다.
다음 정도의 정보가 있으면 방향을 잡기 쉽다.
“독자는 생성형 AI를 처음 사용하는 직장인이고, 이 글의 목적은 프롬프트의 기본 원리를 쉽게 설명하는 것이다.”
이 한 문장만으로도 설명 수준과 예시의 방향이 상당히 달라질 수 있다.
반대로 아무런 독자 정보 없이,
“프롬프트를 설명해줘.”
라고 요청하면 AI가 어느 정도 수준으로 설명해야 할지 추측해야 한다.
좋은 맥락은 AI에게 많은 자료를 던지는 것이 아니라 결과를 결정하는 데 필요한 배경을 선별해서 제공하는 것이다.
3. 조건은 ‘꼭 필요한 것’부터 넣는다
생성형 AI에 익숙해질수록 조건을 많이 넣고 싶어진다.
하지만 조건이 많다고 항상 좋은 것은 아니다.
먼저 반드시 필요한 조건부터 정하는 것이 좋다.
예를 들어 정보형 블로그 글이라면 핵심 조건은 다음 정도일 수 있다.
초보자가 이해할 수 있어야 함
과장된 표현을 사용하지 않음
확인되지 않은 수치를 만들지 않음
실제 상황을 이해할 수 있는 예시를 포함함
여기에 필요하다면 분량이나 소제목 개수 같은 형식 조건을 추가한다.
반대로,
“전문적이고 자연스럽고 재미있고 친근하고 신뢰감 있고 읽기 쉽고 깊이 있지만 짧게”
처럼 비슷하거나 충돌하는 표현을 한꺼번에 넣으면 오히려 기준이 흐려질 수 있다.
조건을 작성한 뒤에는 한 번 줄여보는 것도 좋다.
각 조건을 보면서,
“이 문장이 없어지면 결과가 실제로 달라질까?”
라고 생각해본다.
큰 차이가 없다면 제거할 수 있다.
프롬프트는 길이가 아니라 우선순위가 명확한지가 중요하다.
4. 원하는 답변 형식을 미리 정한다
AI의 답변 내용이 좋아도 형식이 맞지 않으면 다시 편집해야 한다.
예를 들어 회의 내용을 긴 문단으로 요약받았는데 실제로 필요한 것은 담당자별 액션 아이템일 수 있다.
따라서 반복되는 작업에서는 출력 형식을 미리 지정하는 습관이 유용하다.
예를 들어,
“다음 순서로 정리해줘.
핵심 결론
결정 사항
담당자별 할 일
추가 확인 사항”
처럼 요청할 수 있다.
블로그 기획이라면,
“제목 후보 5개 → 예상 독자 → 핵심 메시지 → 소제목 4개 → 각 소제목의 설명”
순서로 결과를 받도록 정할 수 있다.
형식을 정할 때 중요한 기준은 보기 좋음보다 결과를 받은 뒤 바로 사용할 수 있는가다.
AI가 만든 답변을 매번 다시 표로 바꾸거나 문단을 쪼개고 있다면, 다음부터는 그 편집 작업을 프롬프트 단계에 포함시키는 것이 좋다.
5. 설명하기 어려운 스타일은 예시를 보여준다
원하는 결과를 말로 설명하기 어려울 때는 예시가 매우 유용하다.
예를 들어,
“자연스럽지만 너무 가볍지 않은 정보형 문체로 작성해줘.”
라고 요청할 수 있다.
하지만 여전히 해석의 폭이 넓다.
이럴 때 자신이 마음에 들어 했던 짧은 문단을 보여주고,
“내용은 따라 하지 말고 문장 길이와 설명 방식만 참고해줘.”
라고 요청하면 기준이 훨씬 분명해진다.
예시는 특히 반복 작업에서 효과가 크다.
회의록 형식, 상품 소개 방식, 블로그 도입부, 요약 구조처럼 결과의 패턴이 중요한 경우에 활용하기 좋다.
다만 예시를 사용할 때는 AI가 따라 하지 않았으면 하는 요소도 확인해야 한다.
예시에 이모지가 많다면 이모지까지 따라 할 수 있고, 문장이 지나치게 광고식이라면 그 분위기도 함께 재현될 수 있다.
따라서 좋은 예시는 단순히 ‘마음에 드는 글’이 아니라 새 결과에서도 반복되어도 괜찮은 특징을 가진 샘플이어야 한다.
6. 작업이 복잡하면 한 번에 끝내려고 하지 않는다
프롬프트를 작성하다가 “그리고”, “그다음”, “마지막으로”가 계속 등장한다면 작업을 나눌 필요가 있는지 확인해볼 수 있다.
예를 들어,
“자료를 요약하고, 문제점을 찾고, 개선안을 만들고, 발표 자료까지 작성해줘.”
라는 요청은 최소 네 가지 작업이다.
이럴 때는 다음처럼 나누는 편이 관리하기 쉽다.
먼저 자료를 요약한다.
그다음 문제점을 찾는다.
문제점이 맞는지 확인한 뒤 개선 아이디어를 만든다.
마지막으로 발표용 결과물로 바꾼다.
이 방식의 장점은 중간에 방향을 확인할 수 있다는 것이다.
처음 자료 이해가 잘못됐는데 바로 최종 보고서까지 만들면 오류가 뒤쪽 작업 전체에 이어질 수 있다.
반면 단계별로 진행하면 잘못된 부분을 초기에 수정할 수 있다.
복잡한 작업에서는 좋은 프롬프트 하나보다 좋은 작업 순서가 더 중요할 때도 많다.
7. 결과를 받은 뒤에는 ‘작성’과 ‘검토’를 분리한다
AI 답변이 자연스럽다고 해서 바로 최종 결과로 사용할 필요는 없다.
특히 숫자, 날짜, 인물명, 제품 기능, 정책, 통계처럼 구체적인 사실이 포함되어 있다면 별도의 확인이 필요하다.
AI에게 다음처럼 검토를 요청할 수 있다.
“이 글에서 사실 확인이 필요한 문장을 찾아줘. 날짜, 숫자, 고유명사, 기능 설명을 우선적으로 확인해줘.”
또는,
“원본에는 없는데 새로 추가된 내용이 있는지 찾아줘.”
처럼 요청할 수도 있다.
다만 AI에게 자기 답변을 다시 검토하게 했다고 해서 최종 검증이 끝나는 것은 아니다.
중요한 사실은 공식 문서나 원본 자료를 통해 사람이 직접 확인해야 한다.
AI의 검토 기능은 무엇을 확인해야 할지 찾는 보조 도구로 사용하는 것이 적절하다.
8. 수정할 때는 ‘문제 + 수정 방향’을 함께 말한다
첫 번째 답변이 마음에 들지 않는다면 막연하게 “다시 써줘”라고 하기보다 문제를 구체적으로 알려주는 것이 좋다.
예를 들어,
“현재 도입부가 너무 길어.”
에서 끝내지 않고,
“현재 도입부가 길고 일반적인 AI 설명이 반복돼. 첫 문단을 절반 정도로 줄이고 실제 업무 상황에서 시작하도록 바꿔줘.”
라고 요청할 수 있다.
또 한 가지 중요한 방법은 유지해야 할 부분도 같이 지정하는 것이다.
“제목과 소제목은 그대로 유지하고 도입부만 수정해줘.”
처럼 말이다.
AI를 이용한 수정에서 자주 발생하는 문제는 고치지 않아도 되는 부분까지 달라지는 것이다.
따라서 수정 프롬프트에서는 세 가지를 확인하면 좋다.
무엇이 문제인가?
어떻게 바꿀 것인가?
무엇은 그대로 유지할 것인가?
이 세 가지가 명확하면 반복 수정 과정도 훨씬 안정적이다.
9. 대화가 길어졌다면 현재 기준을 다시 정리한다
AI와 여러 차례 대화를 이어가다 보면 처음에 정했던 조건이 대화 뒤쪽에서 잘 보이지 않게 된다.
이때는 새로운 조건을 계속 추가하기보다 현재 기준을 다시 정리하는 것이 좋다.
예를 들어,
“현재 작업 기준을 다시 정리할게.
목표: AI 초보자를 위한 정보형 블로그 글
독자: 비개발 직장인
유지 조건: 전문 용어는 쉽게 설명, 과장 표현 제외
현재 수정 범위: 세 번째 소제목
유지할 부분: 제목과 나머지 소제목”
처럼 정리할 수 있다.
이 과정은 AI를 위한 것만은 아니다.
사용자도 긴 수정 과정에서 현재 무엇이 확정되었고 무엇을 바꾸고 있는지 다시 확인할 수 있다.
대화가 너무 복잡해졌다면 확정된 기준만 정리해 새 대화에서 시작하는 것도 방법이다.
10. 프롬프트를 보내기 전에 민감한 정보가 없는지 확인한다
실제 업무에서는 내용의 품질보다 먼저 확인해야 할 항목도 있다.
바로 데이터 보안이다.
AI에 회의록이나 이메일을 붙여 넣기 전에 이름, 전화번호, 이메일 주소, 고객 정보, 내부 프로젝트명, 비공개 일정, 계약 조건, 비밀번호나 API 키 같은 정보가 들어 있지 않은지 확인한다.
작업에 필요하지 않은 정보라면 제거하는 것이 좋다.
예를 들어 실제 고객명을 ‘고객 A’, 회사명을 ‘고객사 B’처럼 바꿀 수 있다.
또한 회사에서 외부 AI 서비스 사용에 관한 보안 규칙을 정해두었다면 그 기준을 우선해야 한다.
프롬프트가 아무리 잘 작성되어 있어도 입력해서는 안 되는 정보가 포함되어 있다면 사용해서는 안 된다.
생성형 AI 활용에서 중요한 원칙 하나를 꼽는다면 이것이다.
AI가 처리할 수 있다는 것과 입력해도 된다는 것은 다른 문제다.
실전에서 사용할 수 있는 프롬프트 점검 순서
지금까지 내용을 실제 업무에 적용하기 쉽게 하나의 순서로 줄이면 다음과 같다.
프롬프트를 보내기 전에 먼저 최종 목표를 확인한다.
그다음 AI에게 필요한 배경을 제공한다.
독자와 사용 목적을 지정한다.
반드시 지켜야 할 조건만 남긴다.
필요하면 결과 형식을 정한다.
설명하기 어려운 부분은 예시를 제공한다.
작업이 복잡하면 단계를 나눈다.
결과를 받은 뒤에는 사실, 누락, 반복을 검토한다.
수정할 때는 문제와 원하는 방향, 유지할 부분을 함께 전달한다.
마지막으로 민감한 정보가 포함되어 있지 않은지 확인한다.
이 순서를 항상 모두 사용할 필요는 없다.
짧은 번역이나 간단한 질문에는 한두 문장만으로 충분하다.
반면 블로그 글, 보고서, 회의 정리, 아이디어 평가처럼 결과의 방향이 여러 가지일 수 있는 작업에서는 이 기준이 도움이 된다.
처음부터 모든 항목을 완벽하게 적용할 필요는 없다
프롬프트 관련 내용을 공부하다 보면 오히려 질문을 보내는 데 부담을 느낄 수도 있다.
“역할도 넣어야 하고, 맥락도 넣어야 하고, 예시도 넣어야 하고…”
하지만 모든 프롬프트를 완벽하게 설계할 필요는 없다.
실제로는 짧게 시작한 뒤 부족한 부분을 하나씩 추가하는 방식도 충분히 효과적이다.
예를 들어,
“이 회의 내용을 정리해줘.”
라고 먼저 요청한다.
결과가 너무 장황하다면,
“결정 사항과 담당자별 할 일만 남겨줘.”
라고 수정한다.
담당자가 없는 항목을 AI가 추측했다면,
“원문에 없는 담당자는 추측하지 말고 확인 필요라고 표시해줘.”
라는 조건을 추가한다.
이런 과정 자체가 프롬프트 개선이다.
프롬프트는 시험 문제처럼 한 번에 정답을 맞히는 것이 아니다.
결과를 보면서 필요한 조건을 찾아가는 과정이라고 생각하는 편이 훨씬 실용적이다.
마무리
좋은 프롬프트를 만들기 위해 특별한 문장 공식을 모두 외울 필요는 없다.
가장 중요한 것은 AI가 알아야 할 핵심 정보를 명확하게 전달하고, 불필요한 추측을 줄이는 것이다.
먼저 원하는 결과가 무엇인지 정한다.
그다음 필요한 배경과 독자를 알려주고, 중요한 조건과 출력 형태를 추가한다.
말로 설명하기 어려우면 예시를 사용하고, 복잡한 작업은 여러 단계로 나눈다.
답변을 받은 뒤에는 그대로 사용하기보다 오류와 누락을 검토하고 필요한 부분만 다시 수정한다.
대화가 길어졌다면 기준을 다시 정리하고, 실제 업무 자료를 사용할 때는 개인정보와 내부 정보를 한 번 더 확인한다.
결국 프롬프트 설계는 ‘AI에게 멋진 명령을 내리는 기술’보다 내가 원하는 작업을 구체적으로 정의하고, 결과를 확인하며 조정하는 습관에 가깝다.
이 시리즈에서 다룬 원리를 한 번에 모두 적용하려고 하기보다, 앞으로 AI를 사용할 때 한 가지씩 떠올려보는 것부터 시작하면 된다.
“목적이 분명한가?”
“AI가 알아야 할 정보가 충분한가?”
“결과를 어떤 형태로 받을 것인가?”
“확인해야 할 내용은 무엇인가?”
이 네 가지 질문만 습관적으로 확인해도 생성형 AI를 단순한 질문 도구가 아니라 실제 업무를 돕는 도구로 활용하기가 훨씬 쉬워진다.
FAQ
Q1. 좋은 프롬프트에는 반드시 역할, 맥락, 조건, 예시가 모두 들어가야 하나요?
그렇지 않다. 작업이 단순하다면 짧은 질문만으로도 충분하다. 역할이나 예시는 결과의 방향이 여러 가지로 나뉘거나 원하는 스타일을 말로 설명하기 어려울 때 사용하는 보조 수단이다. 필요한 요소만 골라 사용하는 것이 좋다.
Q2. 프롬프트를 작성할 때 가장 먼저 확인해야 할 한 가지는 무엇인가요?
최종적으로 어떤 결과를 원하는지 확인하는 것이 가장 중요하다. 요약인지, 비교인지, 초안 작성인지, 검토인지 목표가 명확해야 이후에 필요한 맥락과 조건도 결정하기 쉽다.
Q3. 프롬프트 작성 실력을 가장 빠르게 늘리는 방법은 무엇인가요?
자신이 실제로 자주 하는 작업에서 AI의 첫 답변과 수정 결과를 비교해보는 것이 도움이 된다. 마음에 들지 않았던 이유를 구체적인 조건으로 바꾸고, 잘 나왔던 결과의 특징을 다음 프롬프트에 다시 적용하면 자신에게 맞는 기준과 템플릿이 자연스럽게 쌓인다.
0 댓글