프롬프트 엔지니어링에 대하여
요약
본 기사는 생성 AI를 업무에 효과적으로 활용하기 위한 핵심 기술인 프롬프트 엔지니어링을 소개합니다. 단순히 지시하는 것을 넘어, One-shot이나 Few-shot처럼 구체적인 예시를 제공하여 원하는 결과의 형식과 품질을 높이는 것이 중요합니다. Zero-shot부터 RAG까지 다양한 기법들을 통해 AI 활용 능력을 향상할 수 있습니다.
핵심 포인트
- 프롬프트 엔지니어링은 목적에 맞는 결과를 얻기 위해 지시를 설계하는 기술입니다.
- One-shot, Few-shot 등 예시 제공 방식이 답변의 형식과 품질을 높이는 핵심 방법입니다.
- CoT(사고 과정), ToT(생각 트리) 등 다양한 기법으로 복잡한 문제 해결 능력을 향상할 수 있습니다.
- ReAct나 RAG처럼 외부 도구와 결합하여 실질적인 업무 활용도를 극대화할 수 있습니다.
생성 AI를 업무에서 활용할 때, 프롬프트 엔지니어링은 중요한 기술 중 하나입니다.
같은 AI 모델이라도 지시하는 방식에 따라 답변의 품질이나 안정성이 달라지는 경우가 있습니다.
프롬프트는 길고 상세하게 작성해야 하는 것이 아니라, 목적에 맞게 필요한 정보를 전달하는 것이 중요합니다.
본 기사에서는 대표적인 기법과 IT 업무에서의 구체적인 활용 방법을 소개합니다.
프롬프트 엔지니어링이란, 생성 AI로부터 목적에 맞는 결과를 얻기 위해 입력하는 지시나 정보를 설계하고 개선하는 기술입니다.
역할·대상자·목적·조건·출력 형식 등을 지정하는 방법이 있지만, 모든 것을 지정할 필요는 없습니다.
예를 들어, '회의 내용을 요약해 줘'라는 단순한 지시만으로도 AI는 회의 내용을 요약해 줍니다.
하지만 회의록으로 활용하고 싶다면, 단순히 요약하는 것이 아니라 결정 사항이나 향후 대응을 정리한 결과가 필요합니다.
그래서 다음과 같이 답변 예시를 첨부하여 지시합니다.
다음과 같은 형식으로 회의 내용을 정리해 주세요.
출력 예:
- 결정 사항: 신규 기능의 출시를 11월에 실시한다
- 향후 대응: 담당자가 10월 말까지 테스트를 완료한다
- 미결정 사항: 출시 후 운영 체제
대상: (여기에 실제 회의 내용을 입력)
이렇게 기대하는 출력 예시를 제시함으로써, AI가 답변의 형식이나 정리 방법을 파악하기 쉬워지고 원하는 결과를 얻을 가능성이 높아집니다.
이것은 후에 설명할 One-shot(원샷)이라는 기법을 사용한 예입니다. One-shot이란, 하나의 구체적인 예시를 제시하여 AI에게 기대하는 답변의 형식이나 경향을 전달하는 방법입니다.
중요한 것은 모든 조건을 세세하게 지정하는 것이 아니라, '목적에 맞게 필요한 정보나 예시를 제공하는 것'입니다.
프롬프트 엔지니어링에는 다양한 기법이 있습니다. 여기서는 그중 대표적인 것들을 소개합니다.
정보량이 많다고 느껴질 수도 있지만, 우선 가볍게 훑어보시는 것이 좋습니다.
기법명이나 세부 절차를 암기할 필요는 없습니다. '이런 식으로 지시하는 방법도 있구나', '이 방법을 사용하면 평소 업무에도 활용할 수 있겠다'라고 AI 사용의 선택지를 아는 것이 목적입니다.
| 기법 | 개요 | 사용 예 |
|---|---|---|
| Zero-shot | 예시를 주지 않고, 그대로 지시한다 | '이 에러 로그의 원인을 설명해 줘' 참고: Zero-shot 실행 예제 |
| One-shot | 하나의 입출력 예시를 준다 | '이 형식을 참고하여 다음 로그도 정리해 줘' |
| Few-shot | 여러 개의 입출력 예시를 준다 | '아래의 3가지 예시와 같은 기준으로 문의를 분류해 줘' |
| Chain-of-Thought(CoT) | 중간적인 추론을 이용해 복잡한 문제를 푼다 | '고려해야 할 조건을 정리하고, 해결 방법을 도출해 줘' |
| Self-Consistency | 여러 개의 추론 경로를 생성하여, 답변의 일치도 등에서 결론을 선택한다 | '여러 번 독립적으로 풀고, 결과를 비교해 줘' |
| Tree-of-Thought(ToT) | 여러 개의 해결 후보를 가지로 나누어 탐색 및 평가한다 | '3가지 구성안을 검토하고, 각각의 발전안을 평가해 줘' 참고: Tree-of-Thought(ToT) 실행 예제 |
| Least-to-Most | 복잡한 문제를 작은 문제로 분해하여 순서대로 해결한다 | '필요한 전제 조건부터 차례대로 문제를 풀어 줘' 참고: Least-to-Most 실행 예제 |
| ReAct | 추론과 외부 도구에 의한 행동을 결합한다 | '공식 문서를 검색하고, 확인 결과에 기초하여 답변해 줘' |
| Self-Refine | 생성 결과를 평가하고, 개선을 반복한다 | '작성한 코드를 리뷰하고, 문제점을 수정해 줘' |
| Generated Knowledge | 답변 전에 관련 지식을 생성하여 활용한다 | '관련 기술 개념을 정리한 후 비교해 줘' |
| Prompt Chaining | 여러 프롬프트를 연결하여 처리한다 | '요건 추출 → 설계 → 리뷰 순서로 처리해 줘' |
| RAG | 외부 정보를 검색하여 답변에 이용한다 | '사내 설계서를 검색하고, 그 내용에 기반하여 답변해 줘' |
※ ReAct는 추론과 외부 도구의 활용을 결합하는 방식이며, RAG는 외부 정보를 검색·참조하여 답변에 활용하는 구조이고, Prompt Chaining은 여러 프롬프트를 단계적으로 연결하는 방법입니다. 또한, Self-Consistency나 ToT는 여러 번의 생성이나 탐색을 조합하여 구현할 수 있는 경우가 있습니다.
IT 업무로서 목적에 맞는 사용법이 있다면 활용하면 좋을 것 같습니다.
예를 들어 IT 업계에서의 SIer 업무라면 대략 다음과 같은 케이스가 존재합니다.
-
사양·설계
-
코딩
-
테스트
-
조사
-
문서 작성
일상적인 업무를 예로 들어, 기술 활용 방법을 소개합니다.
이번에는 '사양/설계'에 대해 다룹니다.
사양서 작성, 요구사항 정리, 시스템 구성 검토 등에서는 여러 안을 비교하거나 작업을 분해하는 기법이 유용합니다.
기존의 구성이 정해져 있지 않은 경우, 여러 설계안을 비교하거나 요구사항을 단계적으로 정리하는 데 활용할 수 있습니다.
어떤 형태로 요구사항을 전달할 수 있는지는 상황에 따라 다르지만...
AI 이용과 관계없이 다음과 같이 정리했다고 가정합니다.
작업 요청 및 현재 파악된 요구사항
【작업 요청】
사내 문의 대응 효율화를 위해 사내 매뉴얼이나 FAQ를 참조하여 답변하는 AI 챗 시스템을 신규 구축하고 싶습니다. 실현 방법을 검토해 주세요.
【현재 파악된 요구사항】
...
요구사항 자체는 어느 정도 정보가 갖춰져 있지만, 어떻게 실현할지는 아직 결정되지 않은 상황입니다.
AI에 읽히게 할 '목적 및 조건'을 정리한 상태입니다. 이것을 활용하면서 프롬프트 기법을 사용하면 효과를 기대할 수 있습니다.
| 추천 기법 | 활용 예시 | 기대할 수 있는 효과 | 지시 예시 |
|---|---|---|---|
| ToT | 여러 시스템 구성안 탐색 및 비교 | 하나의 구성안에 치우치지 않고, 비용・성능・운영 부하 등을 다각적으로 검토 가능 | '구성안을 3가지 작성하고, 각각의 개선안을 검토한 후 비교해 주세요' |
| Least-to-Most | 요구사항 단계적 구체화 | 복잡한 요구사항 정리 용이 및 설계상의 검토 누락 감소 | '업무 요구사항부터 기능 요구사항, 비기능 요구사항, 시스템 구성 순으로 정리해 주세요' |
이번에는 같은 요구사항을 사용하고, ChatGPT (GPT-6)로 Zero-shot・ToT・Least-to-Most 세 가지를 시도합니다.
| 기법 | 지시 진행 방식 | 이번에 주목할 점 |
|---|---|---|
| Zero-shot | 요구사항을 전달하여 그대로 답변을 요청 | 어느 정도까지 구체화되는지 |
| ToT | 여러 안을 제시하고, 평가・개선하여 선택 | 비교・개선의 과정 |
| Least-to-Most | 과제를 작게 나누어 순서대로 해결 | 요구사항에서 구성안으로의 연결성 |
① Zero-shot
② Tree-of-Thought (ToT)
③ Least-to-Most
읽는 법: 각 기법의 '입력 프롬프트'와 'AI 답변 전문'은 기법별 별도 글로 정리했습니다. 실행 결과 비교・분석은 본 장 마지막에 모았습니다.
기법 특징: 답변 예시를 주지 않고, 요구사항에서 직접 답변을 요청하는 방법입니다. 평소 질문에서도 자연스럽게 사용됩니다.
실행 예시 (입력 프롬프트・AI 답변 전문)
기법 특징: 여러 후보를 작성하고, 평가・선택・개선・재평가하는 방법입니다.
실행 예시 (입력 프롬프트・AI 답변 전문)
기법 특징: 큰 과제를 작은 과제로 분해하여, 이전 결과를 이용하면서 순서대로 해결하는 방법입니다.
실행 예시 (입력 프롬프트・AI 답변 전문)
각 기법의 실행 결과를 공통 관점에서 비교합니다.
| 비교 관점 | Zero-shot | ToT | Least-to-Most |
|---|---|---|---|
| 검토 진행 방식 | 요구사항에서 직접 구성안 제시 | 3가지 구성안을 평가・선택하고, 개선・재평가 | 과제를 분해하여 전 단계 결과를 이용하며 순서대로 검토 |
| 구성안 비교・선정 | AWS 서비스나 구성안을 제시했으나, 평가 기준・선정 이유는 불충분 | ||
| 안별 장단점이나 평가 이유를 정리 | |||
| 요구사항을 단계적으로 정리한 후 구성안을 제시 | |||
| 미결정 사항 처리 | 미확정 성능 요구사항에 근거 없는 가상의 수치 설정 | 성능 요구사항이나 예산을 확인 항목으로 정리 | |
| 확정 사항과 부족 정보를 구분하여 정리 | |||
| 검토 근거의 명확성 | 서비스 선정 이유가 충분히 설명되지 않음 | 여러 안의 평가와 개선 과정을 제시 | |
| 각 단계 검토 결과와 구성안 연결성을 제시 |
Zero-shot
특별한 기법을 지정하지 않아도, AWS 서비스 선정, 구성도, 보안 대책, 구축 스케줄 등 폭넓은 제안을 얻었습니다. 한편, 미결정 사항을 가상으로 보충하는 부분이 있어, 제안 내용의 타당성을 확인할 필요가 있습니다.
Tree-of-Thought (ToT)
여러 구성안을 비교하고 각각의 약점을 개선하는 과정이 답변에 나타났습니다. 다만, 평가와 개선이 이루어졌다고 하더라도, 평가 기준이나 최종적인 선정 결과가 적절한지는 별도로 확인이 필요합니다.
Least-to-Most
요구사항이나 과제를 분해하고, 이전 단계의 결과를 활용하면서 구성안을 구체화하는 과정이 답변에 나타났습니다. 다만, 단계적으로 검토했다고 해서 최종 구성의 타당성이 보장되는 것은 아닙니다.
이번 비교에서는 동일한 요구사항을 주었음에도 불구하고, 사용하는 프롬프트 엔지니어링 기법에 따라 답변의 내용이나 검토 진행 방식에 차이가 나타났습니다.
Zero-shot에서는 직접적인 구성안 제시, ToT(Tree of Thought)에서는 여러 안의 비교 및 개선, Least-to-Most에서는 과제의 분해와 단계적인 검토라는 각 기법의 특징이 답변에 나타나고 있습니다.
이처럼 프롬프트 엔지니어링 기법을 변경함으로써, 동일한 과제에 대해서도 다른 관점이나 검토 과정을 가진 답변을 얻을 수 있음을 확인할 수 있었습니다.
실제 업무에서 활용하기 위해서는 추가 정보 수집이나 제안 내용의 타당성을 확인하는 리뷰 및 검증이 필요합니다.
프롬프트 엔지니어링은 답변의 질을 높이는 수단이며, AI의 답변을 그대로 정답으로 여기기보다 인간이 판단하는 것이 중요합니다.
항상 Zero-shot부터 대화를 시작하고 추가 질문이나 조건을 덧붙여 조금씩 설계를 확정해 나가는 방법도 문제없지만, 대화는 첫 번째 답변에 끌릴 수 있다는 점이 우려됩니다.
장기간의 대화를 예상한다면, 이러한 기법을 활용하여 출발하는 것도 시도해 보시기 바랍니다.
'코딩(Coding)·테스트(Test)·조사(Investigation)·문서화(Documentation)'에 대해서는 다음 회차부터 소개하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기