[LLM] 프롬프트 엔지니어링이란

1, 2일차에서는 LLM의 작동 원리(다음 단어 예측)와 토큰·컨텍스트·temperature가 그 작동을 조절하는 방식을 다뤘습니다. 그런데 실무에서 결과물 품질을 가장 크게 좌우하는 요소는 모델 자체가 아니라 입력을 어떻게 설계하는가입니다. 같은 모델, 같은 temperature로 호출해도 프롬프트 구조에 따라 결과 품질이 크게 달라집니다. 이번 글에서는 이 입력 설계를 체계적으로 다루는 프롬프트 엔지니어링을 정리합니다. 🤖

 

1. 프롬프트 엔지니어링

 

1.1 프롬프트의 정의

 

프롬프트 엔지니어링은 생성형 AI 모델이 원하는 결과를 만들도록 입력을 설계하고 최적화하는 작업입니다. 1일차에서 다룬 대로 LLM은 "주어진 입력 다음에 올 단어를 예측"하는 구조이기 때문에, 입력(프롬프트)이 어떻게 짜여 있는지가 출력의 방향을 거의 결정합니다.

 

짧은 질문 한 줄과 구조화된 프롬프트는 같은 모델에서도 전혀 다른 수준의 답변을 만들어냅니다. "이 데이터 분석해줘"라는 한 줄과, 역할·맥락·출력 형식까지 갖춘 프롬프트는 출력의 정확도와 형식 모두에서 차이가 발생합니다.

 

1.2 프롬프트의 구성 요소

 

잘 구성된 프롬프트는 보통 비슷한 구조를 갖습니다. 역할 지정, 작업 지시, 맥락/예시, 출력 형식이 그 네 가지입니다.

 

 

네 가지가 모든 프롬프트에 필요한 건 아닙니다. 단순한 질문은 작업 지시 한 줄로 충분하고, 복잡하고 정확도가 중요한 작업일수록 네 가지를 모두 채워야 결과가 안정적으로 나옵니다. 다음 섹션부터는 이 구성 요소를 채우는 구체적인 기법을 다룹니다.

 

2. 기본 기법: zero-shot과 few-shot

 

2.1 Zero-shot 프롬프트

 

Zero-shot 프롬프트는 모델에게 예시 없이 질문만 제시해서 답변을 얻는 가장 기본적인 방식입니다. "이 문장 감정 분석해줘", "이 코드 버그 찾아줘"처럼 바로 질문을 던지는 형태입니다.

 

모델 크기가 클수록 zero-shot 성능이 좋습니다. 1일차에서 다룬 창발적 능력과 연결되는 부분으로, 파라미터가 많은 모델은 예시 없이도 작업의 의도를 잘 파악합니다. 반면 작은 모델은 명시적인 예시 없이는 작업의 형식이나 의도를 제대로 잡지 못하는 경우가 많습니다.

 

2.2 Few-shot 프롬프트

 

Few-shot 프롬프트는 본 질문 전에 비슷한 형태의 예시 몇 개를 먼저 제시하는 방식입니다. 프롬프트 안에 예시나 추가 데이터를 포함하면, 모델이 인-컨텍스트 학습(in-context learning)을 통해 특정 작업을 더 잘 이해하고 수행합니다.

 

 

프롬프트 안의 예시는 토큰을 소비합니다. 2일차에서 다룬 토큰·컨텍스트 윈도우 개념이 여기에도 그대로 적용됩니다. 예시를 많이 넣을수록 비용이 늘고 컨텍스트 윈도우도 더 빨리 채워지기 때문에, 적정 예시 개수는 작업 난이도와 비용을 함께 고려해서 정해야 합니다. 보통 2~5개의 예시로 충분한 경우가 많습니다.

 

💡 Tip
few-shot 예시를 고를 때는 해당 작업에서 흔히 헷갈리는 케이스를 골라 넣는 게 효과적입니다. 평이한 예시만 넣으면 모델이 형식만 따라 하고 까다로운 부분은 여전히 틀리는 경우가 많습니다.

 

3. 추론을 끌어내는 기법

 

3.1 Chain of Thought

 

Chain of Thought(CoT)는 모델에게 단계별로 생각하도록 요청해서 중간 추론 과정을 거치게 하는 기법입니다. 2일차에서 다룬 추론 모델이 중간 사고 과정을 거치는 구조와 유사한 효과를, CoT는 일반 모델에게 프롬프트로 유도합니다.

 

"이 분석 결과가 왜 이런 패턴을 보이는지 단계별로 설명해줘"처럼 프롬프트에 "단계별로", "차근차근" 같은 표현을 포함하면, 수학 문제나 복잡한 추론 작업의 정답률이 올라가는 경우가 많습니다. 모델이 결론으로 바로 점프하지 않고 중간 논리를 한 토큰씩 거치면서, 그 중간 논리 자체가 다음 토큰 예측의 맥락이 되어 더 정확한 결론으로 이어지는 구조입니다.

 

다만 CoT에는 한계가 있습니다. 단일 상호작용에 국한되는 기법이라, 프롬프트의 한 단어만 바꿔도 결과가 예측 불가능하게 달라질 수 있습니다. 중요한 작업이라면 같은 프롬프트로 여러 번 테스트해서 결과의 일관성을 확인하는 과정이 필요합니다.

 

3.2 역할 지정

 

"너는 지금부터 데이터 분석 전문가야"처럼 모델에게 특정 역할을 부여하는 기법입니다. 역할을 지정하면 모델이 그 역할에 맞는 어휘, 관점, 깊이로 답변을 조정합니다.

 

이 기법의 작동 원리는 1일차의 사전 학습 내용으로 설명됩니다. 모델은 학습 데이터에서 전문가가 쓴 글과 초보자가 쓴 글의 패턴을 다르게 학습했기 때문에, 역할을 지정하면 모델이 다음 단어를 예측할 때 참조하는 맥락이 전문가 화법 쪽으로 기울게 됩니다. 다만 역할 지정만으로 모델이 실제로 더 많이 "아는" 건 아닙니다. 화법과 깊이는 달라지지만, 모델이 모르는 정보를 알게 되는 효과는 없습니다.

 

4. 출력을 통제하는 기법

 

4.1 형식 지정

 

"표 형태로 답변해줘", "JSON으로 출력해줘"처럼 출력 형식을 명시하는 기법입니다. 데이터 분석 자동화에서는 이 부분이 특히 중요한데, 사람이 읽는 답변과 코드가 파싱해야 하는 답변은 요구되는 형식이 완전히 다르기 때문입니다.

 

실무에서 자주 쓰는 패턴은 "#명령문 #제약조건 #출력형식 #입력문"처럼 항목을 구분해서 항상 같은 틀로 프롬프트를 짜는 방식입니다. 이렇게 템플릿화하면 입력문만 바꿔서 재사용할 수 있고, 결과 형식도 더 일관되게 나옵니다.

 

prompt_template = """
#역할: 데이터 분석 전문가
#작업: 아래 매출 데이터에서 이상치를 찾아줘
#제약조건: 평균에서 2 표준편차 이상 벗어난 값만 이상치로 판단
#출력형식: JSON 배열, 각 항목은 {{"date": ..., "value": ..., "reason": ...}}

#데이터:
{data}
"""

prompt = prompt_template.format(data=sales_data)

 

출력 형식을 JSON처럼 구조화해서 지정하면, 모델의 답변을 코드에서 바로 파싱해서 다음 단계로 넘길 수 있습니다. 분석 자동화 파이프라인에서 LLM 호출 결과를 사람이 읽지 않고 바로 다음 함수에 넘기려면, 이런 형식 지정이 거의 필수적입니다.

 

⚠️ 주의
형식을 JSON으로 지정해도 모델이 형식을 살짝 벗어난 출력(설명 문장을 앞에 덧붙이거나, 마지막 따옴표를 빠뜨리는 등)을 낼 수 있습니다. 파이프라인에 넣을 때는 파싱 실패를 대비한 예외 처리를 함께 넣어야 합니다.

 

4.2 프롬프트 체인

 

하나의 복잡한 작업을 한 번의 프롬프트로 처리하지 않고, 여러 개의 작은 단계로 나눠서 처리하는 기법입니다. 각 단계의 출력이 다음 단계의 입력으로 연결되는 구조입니다.

 

예를 들어 "이 보고서를 요약하고, 핵심 인사이트를 뽑고, 다음 액션을 제안해줘"를 한 프롬프트에 모두 넣으면 모델이 세 가지 작업을 동시에 처리하면서 품질이 떨어지는 경우가 있습니다. 대신 "요약해줘" → "이 요약에서 핵심 인사이트를 뽑아줘" → "이 인사이트를 바탕으로 액션을 제안해줘"처럼 세 번의 호출로 나누면, 각 단계가 이전 단계의 결과에 집중해서 처리하기 때문에 전체적인 품질이 올라갑니다. 다만 호출 횟수가 늘어나는 만큼 토큰 비용과 응답 시간도 함께 증가하는 트레이드오프가 있습니다.

 

5. 컨텍스트 엔지니어링

 

5.1 프롬프트와 컨텍스트의 차이

 

2025년 중반부터 "프롬프트 엔지니어링"보다 "컨텍스트 엔지니어링"이라는 표현이 더 자주 쓰이기 시작했습니다. 프롬프트 엔지니어링이 질문을 잘 던지는 것에 가깝다면, 컨텍스트 엔지니어링은 모델이 작업을 해결할 수 있도록 모델이 보는 모든 정보(시스템 프롬프트, 대화 기록, 검색된 문서, 도구 사용 결과 등)를 설계하는 더 넓은 개념입니다.

 

이 차이는 시험 비유로 설명할 수 있습니다. 프롬프트 엔지니어링은 시험 문제를 잘 내는 것이고, 컨텍스트 엔지니어링은 시험지와 함께 참고 자료, 계산기, 사전을 적절히 배치하는 것에 가깝습니다. 2일차에서 다룬 컨텍스트 윈도우, 그리고 다음 글에서 다룰 RAG가 컨텍스트 엔지니어링의 핵심 도구입니다. 이번 글의 기법들(zero/few-shot, CoT, 역할·형식 지정)은 한 번의 프롬프트를 잘 구성하는 영역이고, 이후 RAG·에이전트 글에서는 모델에게 어떤 정보를 어떻게 가져다줄지라는 더 넓은 문제로 확장됩니다.

 

5.2 정리

 

좋은 프롬프트는 역할 지정, 작업 지시, 맥락/예시, 출력 형식 네 가지로 구성됩니다. Zero-shot과 few-shot은 예시 제공 여부에 대한 기본 선택이고, CoT와 역할 지정은 모델의 추론 과정과 화법을 끌어내는 기법입니다. 형식 지정과 프롬프트 체인은 출력을 통제해서 파이프라인에 바로 넣을 수 있게 만드는 기법입니다.

 

이 기법들은 모두 1일차에서 다룬 다음 단어 예측 구조 위에서 작동합니다. 예시를 주든, 역할을 부여하든, 형식을 지정하든, 모델이 다음 토큰을 예측할 때 참조하는 맥락을 더 좋은 방향으로 설계하는 작업입니다. 다음 글에서는 이 맥락 설계를 모델 외부 정보(문서, 데이터베이스)까지 확장하는 RAG를 다룹니다. 🤖