“같은 AI인데 왜 누구는 잘 쓰고 나는 결과가 별로지?”
같은 ChatGPT를 쓰는데, 누구는 10분 만에 멀쩡한 결과물을 뽑아낸다. 옆 사람은 한 시간을 붙잡고 있어도 어정쩡한 답만 받는다. 같은 AI인데 왜 이렇게 다를까?
대부분은 모델의 차이가 아니다. ‘어떻게 말을 거는가’의 차이다.
이전 글에서 LLM은 ‘다음 토큰을 예측’한다고 설명했다. 예측의 품질은 ‘입력이 얼마나 잘 설계되었는가’에 직접 비례한다. 같은 AI라도 입력이 어떻게 들어오느냐에 따라 전혀 다른 결과를 낸다.
이 글에서는 AI에게 말을 잘 거는 법, 즉 ‘프롬프트와 컨텍스트를 설계하는 법’을 다룬다. 복잡한 기술을 배우자는 이야기가 아니라, 누구나 쓸 수 있는 몇 가지 원칙을 정리해 본다.
먼저 알아둘 점: 같은 모델에 같은 질문을 넣어도 매번 같은 답이 나오지는 않는다. AI는 기본적으로 답변의 무작위성을 가지고 있어서, 유튜버가 보여준 결과와 내 결과가 미세하게 다를 수 있다. 이 글은 ‘같은 답을 보장하는 주문’이 아니라 ‘좋은 결과가 더 자주 나오게 만드는 설계’ 이야기다.
AI에게 주는 말은 세 종류로 나뉜다
‘한 줄 요약: AI에게 주는 말은 “지켜야 할 규칙”, “지금까지 한 대화”, “지금 하는 질문” 세 종류로 나뉜다.’
AI와 대화할 때, 사실 우리는 세 종류의 정보를 함께 던지고 있다. 챗봇 화면에서는 안 보이지만 뒤에서 이렇게 움직인다.
| 종류 | 뭘 담는가 | 예 |
|---|---|---|
| 규칙 | AI가 따라야 할 기본 원칙 | “한국어로 답해, 욕설은 하지 마” |
| 대화 | 지금까지 주고받은 내용 | 이전 메시지들 |
| 질문 | 지금 물어보는 것 | “Transformer가 뭐야?” |
중요한 건 ‘우선순위’다. 보통은 ‘규칙 > 질문’ 순서로 AI가 따른다. 그래서 서비스 개발자가 “욕설 금지”를 규칙으로 박아두면, 사용자가 “욕해줘”라고 해도 AI는 거절한다.
우리가 ChatGPT나 Claude 앱에서 쓰는 건 주로 ‘질문’ 부분이고, ‘규칙’은 서비스 회사가 미리 깔아둔다. 그래서 같은 모델이라도 공식 앱과 직접 API를 쓰는 게 다르게 느껴지는 것이다.
더 깊이 보기: 공급자별 역할 이름
실제 API에서는 이 세 가지가 각각 다른 이름으로 불린다. 개발자가 아니라면 이 부분은 건너뛰어도 된다.
| 공급자 | 규칙 | 대화 | 질문 |
|---|---|---|---|
| OpenAI | developer / system | assistant | user |
| Anthropic | system prompt (별도 필드) | assistant | user |
| Gemini | system instructions (config) | model | user |
OpenAI는 최근 reasoning 계열 모델에서 developer 메시지를 상위 지시 용도로 쓰는 방향으로 이동했고, Anthropic과 Gemini는 각자 다른 방식으로 규칙을 분리한다. 공통점은 ‘규칙을 사용자 입력과 분리해서 관리한다’는 것이다.
용어 먼저 정리: 프롬프트, 컨텍스트, 파라미터
‘한 줄 요약: 프롬프트는 “내가 쓴 지시문”, 컨텍스트는 “AI가 참고하는 전체 입력”, 파라미터는 “AI 동작을 조절하는 설정”.’
이 셋을 섞어 쓰면 계속 혼란스럽다. 구분하면 이렇다.
- ‘프롬프트’: 내가 AI에게 직접 적어 보내는 지시문 (= 우리가 ChatGPT 창에 치는 그것)
- ‘컨텍스트’: 시스템 규칙, 예시, 참고 문서, 대화 이력, 질문 등 AI가 받는 모든 입력의 합
- ‘파라미터’: 응답의 무작위성(temperature), 추론 깊이, 출력 길이 같은 동작 설정
요즘은 “좋은 문장을 쓰는 것”만큼 “좋은 설정을 고르는 것”이 결과에 영향을 미친다.
명확하게 쓰기: “뭘 하라”가 아니라 “어떻게 하라”
‘한 줄 요약: 모호한 요청(“~해줘”)보다 조건·형식·범위까지 쓴 요청이 훨씬 안정적인 결과를 낸다.’
초보 프롬프트와 숙련된 프롬프트의 가장 큰 차이는 ‘제약’의 유무다.
모호한 지시
블로그 글 요약해줘.
결과: 길이가 제각각, 형식도 매번 다르다. 어떤 때는 3줄, 어떤 때는 10문단.
명확한 지시
아래 블로그 글을 요약해 주세요. 출력 형식: - 총 3줄 - 각 줄은 '~다'로 끝나는 평서문 - 전문 용어는 풀어쓰기 글 내용: [블로그 본문]
결과: 매번 비슷한 형태로 나온다.
명확한 지시에는 4가지 요소가 포함된다.
| 요소 | 예시 |
|---|---|
| 역할/페르소나 | “당신은 친절한 IT 선생님입니다.” |
| 작업 | “이 글을 초등학생이 이해하게 설명해 주세요.” |
| 형식 | “제목 + 3개 항목의 불릿” |
| 제약 | “500자 이내, 전문 용어 사용 금지” |
이 4가지를 머릿속에 두고 요청하면 결과가 확 달라진다.
예시로 가르치기: Few-shot
‘한 줄 요약: 말로 설명하는 것보다 “이런 식으로 해줘”라고 예시 2~3개 보여주는 게 훨씬 빠르고 정확하다.’
“이메일 제목을 한 줄로 요약해줘”라고만 하면 AI가 자기 감으로 요약한다. 대신 원하는 형태의 예시 몇 개를 먼저 보여주면 AI가 그 패턴을 따라한다.
이메일 제목을 한 줄 요약으로 변환하세요. 예시: 입력: "회의 일정 변경 안내 - 12월 15일 오후 3시 → 오후 5시" 출력: 회의 오후 5시로 변경 입력: "[긴급] 서버 점검 공지: 주말 02-04시 접속 불가" 출력: 주말 새벽 서버 점검 --- 이제 다음을 처리하세요. 입력: "[리마인드] 내일 오전 10시 팀 회고 회의" 출력:
결과: “내일 10시 팀 회고”처럼 예시의 패턴을 그대로 따른다.
이 기법을 ‘Few-shot(몇 개의 예시)’이라고 부른다. 반대로 예시 없이 설명만 하는 건 ‘Zero-shot’. 요즘 AI는 Zero-shot도 꽤 잘하지만, 특정 형식을 꼭 맞춰야 할 때는 Few-shot이 확실하다.
핵심은 ‘좋은 예시를 고르는 것’이다. 예시가 한 방향으로 치우치면 결과도 치우친다.
정해진 양식으로 답받기
‘한 줄 요약: AI 답변을 프로그램이 자동 처리해야 한다면, “양식을 정해서 답받는 기능”을 쓰는 게 가장 안전하다.’
AI를 혼자 쓰는 게 아니라 프로그램에 연결해서 “결과를 받아 자동 처리”하는 경우가 있다. 이럴 땐 자유 형식 텍스트가 문제다. AI가 기분에 따라 “설명을 추가”하거나 “형식을 바꾸면” 프로그램이 깨진다.
요즘 AI 서비스는 대부분 ‘정해진 양식으로만 답하게 강제하는 기능’을 제공한다. 개발자 용어로는 ‘구조화된 출력(Structured Output)’이라고 부른다.
쉽게 말하면 이런 느낌이다.
“제목(문자), 중요도(상/중/하 중 하나), 태그(여러 개)로 답해. 다른 형태는 안 돼.”
이렇게 지정하면 AI 답이 매번 같은 양식으로 온다. 프로그램이 처리하기 좋다.
주의할 점: 이 기능은 ‘양식 안정성’을 높여주지, ‘값의 정확성’까지 보장하지는 않는다. 형식은 맞아도 분류를 잘못하거나 없는 얘기를 채울 수 있으므로, 결과 검증은 여전히 필요하다.
더 깊이 보기: JSON Schema 예시 (개발자용)
개발자라면 실제로는 JSON Schema로 양식을 지정한다. OpenAI, Anthropic, Gemini 모두 JSON Schema 기반 structured output을 지원한다.
{
“type”: “json_schema”,
“schema”: {
“type”: “object”,
“properties”: {
“title”: { “type”: “string” },
“priority”: { “type”: “string”, “enum”: [“HIGH”, “NORMAL”, “LOW”] },
“tags”: { “type”: “array”, “items”: { “type”: “string” } }
},
“required”: [“title”, “priority”]
}
}
이 스키마로 호출하면 응답은 반드시 JSON이고, priority는 반드시 지정된 세 값 중 하나다.
무엇을, 얼마나 넣을 것인가
‘한 줄 요약: AI가 볼 자료는 많이 넣는다고 좋은 게 아니다. 꼭 필요한 것만, 잘 정리해서 넣자.’
좋은 프롬프트만큼 중요한 것이 ‘좋은 컨텍스트’다. AI가 답을 만들 때 참고하는 모든 것 — 규칙, 예시, 참고 문서, 대화 이력, 질문 — 의 합이다.
흔한 오해는 “많이 넣을수록 좋다”이다. 실제로는 반대에 가깝다. 이전 글에서 언급한 ‘context rot'(입력이 길어지면 AI가 중간 부분을 놓치는 현상) 때문에, 정보가 많다고 품질이 비례해서 올라가지 않는다.
컨텍스트에 넣을 때 확인할 것
| 질문 | 예시 |
|---|---|
| 이 정보가 답에 꼭 필요한가? | 질문이 “결제 방법”인데 “회사 연혁”을 넣을 이유는 없음 |
| 관련 있는 것을 앞에 뒀는가? | 중요한 문서를 앞쪽에 |
| 중복된 정보는 없는가? | 같은 얘기가 여러 번 들어가면 방해 |
| 구조가 읽기 쉬운가? | 제목, 구분선, 표로 구획화 |
그래서 나온 접근: 관련 있는 것만 찾아서 넣기
“가진 모든 문서를 다 넣자”는 현실에서 안 된다. 사내 문서가 1,000개면 한 번에 다 넣을 수 없다. 그래서 ‘질문과 관련된 문서만 먼저 찾아서 넣는’ 방식이 표준이 됐다. 이걸 ‘RAG’라고 부르고, 다음 글에서 자세히 다룬다.
“생각해봐”는 이제 옛말?
‘한 줄 요약: 예전엔 “단계별로 생각해봐”가 비법이었지만, 요즘은 AI가 알아서 생각한다. “이 순서대로 해줘”가 더 중요하다.’
2022~2023년에는 “AI한테 ‘step by step 생각해봐’라고 말하면 답이 좋아진다”는 기법이 유행했다. ‘Chain-of-Thought(CoT)’, 한국어로는 ‘사고 연쇄’라고 불렀다.
2026년 현재는 상황이 달라졌다. 최근 AI 모델들은 ‘생각해봐’라고 말하지 않아도 내부적으로 추론 단계를 돌리도록 설계됐다. 오히려 굳이 “생각해봐”라고 쓰면 혼란을 주는 경우도 있다.
핵심은 두 가지다.
- '프롬프트로 추론을 유도하기'보다 '모델 설정(추론 강도 조절)'을 바꾸는 쪽이 더 강하다.
- “생각해봐”라는 모호한 말보다 “다음 4단계 순서로 분석하라”처럼 명시적 구조가 결과 예측 가능성이 높다.
더 깊이 보기: 공급자별 차이
개발자용 보충: OpenAI reasoning 모델은 “step by step”을 피하라고 공식 안내한다. Gemini는 dynamic thinking과 thinkingLevel 파라미터로 추론 강도를 조절한다. Anthropic은 adaptive thinking이 켜진 모델에서는 수동 CoT보다 일반 추론 지시가 낫다고 안내한다. 다만 thinking이 약하거나 꺼진 모델, 중간 과정을 노출해야 하는 워크플로우에서는 단계 지시가 여전히 유효하다.
실무에서 기억할 세 가지 팁
‘한 줄 요약: 구분선으로 섹션 나누기, 긴 지시는 앞뒤에 반복, 테스트는 여러 번.’
1. 구분선/태그로 섹션을 나눠라
지시, 참고 문서, 예시, 사용자 질문이 한 프롬프트 안에 뒤섞이면 AI가 경계를 헷갈린다. 간단한 태그로 구획을 나눠주자.
<instruction> 아래 문서를 3줄로 요약해 주세요. </instruction> <document> [블로그 본문 전체] </document> <question> 요약에 빠진 게 있을까? </question>
태그 형태는 자유다. 중요한 건 ‘일관성’이다.
2. 긴 문서는 앞뒤에 핵심 지시를 반복하라
매우 긴 입력에서는 AI가 중간을 놓치는 경향이 있다. 중요한 지시는 시작과 끝에 모두 넣어주는 것이 안전하다.
3. 한두 번 테스트로 끝내지 말자
프롬프트를 짜고 한두 번 돌려보고 “된다” 판단하는 건 위험하다. 다양한 입력 여러 개로 결과를 확인한 뒤에야 “쓸 만하다”고 말할 수 있다.
개발자를 위한 추가 메모
일반 독자는 여기까지만 읽어도 된다. 아래는 API로 AI를 쓰는 개발자를 위한 보충이다.
- ‘제약은 don\’t보다 do로’: “욕하지 마라”보다 “정중한 존댓말만 써라”가 더 잘 동작한다.
- ‘캐시 친화적 배치’: 반복되는 시스템 지시와 예시는 앞쪽에, 사용자 입력은 뒤쪽에 두면 프롬프트 캐싱(Gemini에서는 context caching)이 적용되어 비용·속도가 개선된다. OpenAI, Anthropic, Gemini 모두 지원.
- ‘모델/설정이 바뀌면 다시 평가’: 이전 모델에서 잘 되던 프롬프트가 새 모델에서도 최선이라는 보장은 없다. reasoning.effort나 thinkingLevel 같은 설정을 바꿨을 때도 마찬가지다.
- ‘복잡한 작업은 쪼개기(prompt chaining)’: 하나의 거대한 프롬프트로 해결하려 하지 말고, 단계별로 나눠서 호출하는 것이 공식 가이드의 권장 패턴이다.
마치며: 프롬프트도 '설계'하는 것
AI한테 말 거는 법을 다시 한 줄씩 정리하면 이렇다.
- AI에게 주는 말은 ‘규칙 / 대화 / 질문’으로 나뉜다.
- ‘프롬프트’는 지시문, ‘컨텍스트’는 전체 입력, ‘파라미터’는 동작 설정이다.
- 모호하게 말하지 말고 ‘역할, 작업, 형식, 제약’을 담아라.
- 설명보다 ‘예시’가 강하다.
- 프로그램이 처리할 결과라면 ‘정해진 양식으로 답받기’를 쓴다.
- 컨텍스트는 ‘많이’가 아니라 ‘관련 있는 것’을 넣는다.
- “생각해봐”는 이제 옛 기법, ‘구조적 지시 + 모델 설정’이 더 강하다.
- 구분선, 반복, 테스트를 기억하자.
프롬프트를 잘 쓰는 것은 좋은 문서를 쓰는 것과 비슷하다. 의도를 명확히, 구조는 단단히, 필요한 것만.
다음 글에서는 AI를 텍스트 생성에서 끝내지 않고, 실제 외부 세계와 연결하는 이야기를 다룬다. AI가 이메일을 보내고, 파일을 읽고, 계산기를 쓰게 만드는 방법이다.