프롬프트 작성법은 AI에게 원하는 답을 얻기 위해 질문을 설계하는 방법이다. 같은 AI를 써도 어떤 사람은 한 번에 원하는 답을 받고, 어떤 사람은 같은 질문을 몇 번씩 다시 고친다. 차이는 대부분 프롬프트에 들어 있는 정보량과 구조에서 나온다.
AI가 좋다는 이야기는 많이 들리는데, 막상 처음 써 보면 어디서부터 어떻게 물어야 할지 막막하다. 어느 정도 익숙해진 뒤에도 답이 애매하거나 너무 평범해서 다시 질문을 수정하는 일이 자주 생긴다. 처음 AI를 쓰는 사람부터, 답이 잘 안 나온다고 느끼는 사람까지 모두에게 도움이 될 만한 프롬프트 작성법의 핵심을 짚어 본다.
역할·맥락·제약·형식, 좋은 프롬프트의 핵심 요소 네 가지
역할 지정은 답변의 방향과 톤을 결정하는 출발점
프롬프트 작성법에서 가장 먼저 신경 써야 하는 건 역할 지정이다. 프롬프트 첫 줄에서 AI에게 어떤 입장으로 답할지 알려 주면 답변 방향이 훨씬 안정적으로 잡힌다.
예를 들어 아래 두 문장은 비슷해 보여도 결과 차이가 꽤 크다.
- 당신은 10년 차 백엔드 개발자입니다.
- 당신은 초등학생도 이해할 수 있게 설명하는 강사입니다.
같은 질문을 넣어도 첫 번째는 기술 용어와 코드 중심으로 설명하고, 두 번째는 비유와 쉬운 표현 위주로 답하는 경우가 많다.
AI는 질문 속 맥락을 기준으로 답변 스타일을 바꾸기 때문에, 역할만 잘 정해도 원하는 분위기에 훨씬 가까워진다.
필요한 맥락을 구체적으로 설명하기
맥락은 답의 정확도를 결정한다. 많은 사람이 이 부분을 너무 짧게 적는다.
예를 들어 아래 두 요청은 결과 차이가 크다.
- 이메일 작성해 주세요.
- 신입사원 환영 이메일을 작성해 주세요. 너무 가볍지 않은 톤으로, 다섯 문장 정도로 부탁합니다.
두 번째처럼 상황과 목적이 들어가면 AI가 훨씬 구체적으로 답할 수 있다.
프롬프트 작성법에서 맥락은 “누구에게”, “왜”, “어떤 상황에서” 쓰는지를 설명하는 부분이라고 보면 된다. 한 줄로 부족하면 여러 줄로 나눠 적는 편이 오히려 낫다.
제약 조건으로 불필요하거나 엉뚱한 답변 줄이기
AI는 제약이 없으면 대체로 무난하고 긴 답변을 내놓는다. 그래서 하지 말아야 할 조건도 같이 적어 두는 편이 좋다.
예를 들면 이런 식이다.
- 300자 이내
- 전문 용어 최소화
- 코드 예시는 제외
- 표 대신 목록 형태 사용
이런 조건이 들어가면 답변 범위가 자연스럽게 좁아진다.
처음부터 완벽하게 다 적으려고 하기보다는, 이전 답변에서 아쉬웠던 점을 하나씩 추가하는 방식이 부담이 적다. 실제로 프롬프트 작성법은 한 번에 완성하는 기술보다, 조금씩 수정하면서 다듬는 습관에 더 가깝다.
출력 형식을 지정해 후처리 시간 줄이기
출력 형식을 지정하는 것도 생각보다 중요하다.
예를 들어 아래처럼 요청할 수 있다.
- 표로 정리해 주세요.
- 마크다운 형식으로 작성해 주세요.
- JSON 형태로 반환해 주세요.
형식 지정이 없으면 결과를 다시 정리하는 시간이 꽤 오래 걸린다. 특히 문서 작업이나 개발 작업처럼 결과를 다른 곳에 바로 붙여 넣어야 할 때 차이가 크다.
위 내용을 한 번에 묶으면 보통 이런 형태가 된다.
당신은 10년 차 백엔드 엔지니어입니다.
[맥락]
신입 개발자에게 REST API와 GraphQL 차이를 설명하려고 합니다.
대상은 백엔드를 처음 배우는 사람입니다.
[제약]
- 분량 600자 내외
- 어려운 용어는 처음 등장할 때 설명 추가
- 예시 최소 1개 포함
[출력 형식]
- 정의 → 차이점 → 사용 사례 순서
- 마크다운 헤딩 사용이런 식으로 구조를 나눠 적으면 AI도 이해하기 쉽고, 나중에 다시 수정하기도 편하다.
예시와 단계별 추론에 따라 달라지는 답변 품질
예시 없이 바로 요청하는 제로샷 방식
제로샷(Zero-Shot)은 예시 없이 바로 질문하는 방식이다.
예를 들어 아래처럼 묻는 경우다.
이 문장을 영어로 번역해 주세요.
번역이나 간단한 요약처럼 이미 많이 학습된 작업은 제로샷만으로도 충분한 경우가 많다.
대부분의 사람들이 처음 사용하는 프롬프트 작성법도 여기에 가깝다. 다만 원하는 톤이나 형식이 아주 구체적이라면 한계가 생길 수 있다.
예시를 함께 제공하는 퓨샷 방식
퓨샷(Few-Shot)은 예시를 같이 보여 주는 방식이다.
예를 들어 아래처럼 입력과 결과를 함께 넣는다.
예시 1: “포장 깔끔하고 맛도 좋아요” → 긍정
예시 2: “배달이 한 시간 늦었다” → 부정
이렇게 예시를 보여 주면 AI가 원하는 형식을 더 쉽게 따라간다.
특히 아래 같은 작업에서 효과가 좋다.
- 리뷰 분류
- 일정한 말투 유지
- 데이터 정리
- 문장 패턴 맞추기
말로 길게 설명하는 것보다 예시 한두 개가 더 강력한 경우가 많다.
단계별 사고를 유도하는 사고의 사슬 기법
사고의 사슬(Chain of Thought)은 문제를 단계별로 풀게 만드는 방식이다.
예를 들어 이렇게 요청한다.
단계별로 생각 과정을 설명하면서 답해 주세요.
복잡한 문제에서는 이 방식이 꽤 도움이 된다. 특히 계산, 논리, 비교 분석처럼 중간 과정이 중요한 작업에서 안정적인 답이 나오는 경우가 많다.
최근 AI 모델은 별도 요청 없이도 어느 정도 단계별 설명을 하긴 하지만, 복잡한 문제일수록 명시적으로 적어 주는 편이 결과가 더 일정하다.
아래처럼 비교하면 차이가 쉽게 보인다.
# 제로샷
다음 리뷰의 감정을 긍정·부정·중립 중 하나로 분류해 주세요.
"배송이 너무 느려서 실망했다."
# 퓨샷
예시 1: "포장 깔끔하고 맛도 좋아요" → 긍정
예시 2: "배달이 한 시간 늦었다" → 부정
다음 리뷰를 같은 방식으로 분류해 주세요.
"배송이 너무 느려서 실망했다."
# 사고의 사슬
다음 리뷰 감정을 단계별로 분석해 주세요.
1) 핵심 표현 찾기
2) 표현 톤 분석
3) 최종 감정 분류
리뷰:
"배송이 너무 느려서 실망했다."프롬프트 작성 시 자주 하는 실수
너무 짧고 모호하게 요청하는 실수
가장 흔한 실수는 너무 짧게 쓰는 것이다.
- 글 좀 써 주세요.
- 코드 만들어 주세요.
- 발표 자료 정리해 주세요.
이런 요청은 너무 넓다. AI 입장에서는 어떤 방향으로 답해야 할지 판단하기 어렵다.
누구를 위한 글인지, 어느 정도 길이인지, 어떤 분위기인지 정도만 추가해도 결과가 훨씬 달라진다.
짧게 쓰는 게 빠를 것 같지만, 실제로는 다시 수정 요청하는 시간이 더 오래 걸리는 경우가 많다.
한 번에 여러 작업을 동시에 요청하는 패턴
한 프롬프트 안에 너무 많은 작업을 넣는 것도 흔한 실수다.
예를 들어 이런 식이다.
이 코드 리팩토링하고,
테스트 코드도 작성하고,
영문 문서까지 같이 만들어 주세요.
이렇게 되면 어느 하나도 깊게 처리되지 않는 경우가 많다.
차라리 아래처럼 나누는 편이 결과가 좋다.
- 구조 개선
- 테스트 코드 작성
- 문서 정리
프롬프트 작성법은 결국 AI에게 작업 우선순위를 명확하게 전달하는 과정에 가깝다.
출력 형식을 지정하지 않아 후처리 작업이 늘어나는 경우
처음에는 그냥 답만 받고, 이후에 다시 이런 요청을 하는 경우가 많다.
- 표로 다시 정리해 주세요.
- 마크다운으로 바꿔 주세요.
- JSON으로 다시 출력해 주세요.
이런 작업은 처음 요청할 때 같이 적는 편이 훨씬 효율적이다.
특히 반복 작업에서는 형식을 미리 정해 두면 같은 프롬프트를 재사용하기도 편해진다.
코드 작업과 글 작업에서 달라지는 프롬프트 작성 방식
코드 작업은 구현 전에 설계와 구조부터 요청하기
코드 작업에서는 바로 구현부터 시키지 않는 편이 좋다.
보통은 먼저 아래처럼 물어본다.
이 기능을 어떤 구조로 설계하면 좋을지 먼저 설명해 주세요.
그다음에 함수 분리, 데이터 흐름, 예외 처리 같은 부분을 정리한 뒤 구현 단계로 넘어간다.
이 과정을 거치면 구조가 꼬인 상태로 코드를 계속 덧붙이는 일을 줄일 수 있다. 처음에는 시간이 더 걸려 보이지만, 나중에 전체 구조를 다시 뜯어고치는 비용보다 훨씬 적다.
글 작업은 초안을 먼저 받고 이후 수정 요청하기
글 작업은 반대로 접근하는 경우가 많다.
머릿속 정리가 안 될 때는 AI에게 초안을 먼저 받아 보는 편이 훨씬 빠르다. 다만 초안을 그대로 쓰기보다는 아래처럼 단계적으로 수정하는 게 좋다.
- 말투 다듬기
- 사실 관계 확인
- 표현 자연스럽게 수정
- 중복 문장 제거
한 번에 모든 수정을 요청하기보다, 한 단계씩 나눠서 수정하면 전체 흐름이 덜 흔들린다.
공통 원칙은 충분한 맥락 제공과 구조화
코드든 글이든 결국 중요한 건 두 가지다.
- 맥락 충분히 설명하기
- 프롬프트를 구조적으로 나누기
예를 들면 아래처럼 구분할 수 있다.
[역할]
[맥락]
[작업]
[제약]
[출력 형식]한 덩어리로 길게 쓰는 것보다 훨씬 읽기 쉽고, 나중에 수정하기도 편하다.
좋은 프롬프트는 결국 구조와 맥락에서 시작된다
프롬프트 작성법은 어렵고 거창한 기술이라기보다, 원하는 결과를 얻기 위해 질문을 정리하는 습관에 가깝다.
중요한 건 결국 두 가지다.
- 충분한 맥락 제공
- 보기 쉽게 구조화
퓨샷이나 사고의 사슬 같은 기법은 그다음 단계다. 먼저 “내가 지금 무엇을 요청하고 있는가”를 명확하게 정리하는 것만으로도 답변 품질은 크게 달라진다.
처음부터 완벽한 프롬프트를 만들 필요는 없다. 답을 받아 보고 한 줄씩 수정하다 보면, 자연스럽게 자신만의 프롬프트 작성법이 자리 잡기 시작한다. (출처)