AI 주요 개념 (3)#

이번 장에서는 “어떻게 질문/지시를 구성할지”에 대한 프롬프트 엔지니어링, 그리고 “답을 만들 때 참고할 재료(배경정보)를 어떻게 제공할지”에 대한 컨텍스트 엔지니어링을 다룹니다.

프롬프트 엔지니어링(Prompt Engineering)#

프롬프트는 AI 모델에게 질의(질문/지시)하는 텍스트를 의미합니다. 예를 들어 ChatGPT를 사용할 때 사용자가 입력창에 쓰는 내용이 바로 프롬프트인 것이죠. 그리고 프롬프트 엔지니어링은 AI 모델로부터 원하는 결과를 얻어내기 위해 프롬프트를 작성하는 기술을 의미합니다. 채팅창에 글을 입력하는 것일 뿐인데 이것을 프롬프트 엔지니어링이라고 거창하게 명명한 이유는, 그만큼 어떻게 입력하는가에 따라 AI 모델로부터 얻는 결과물의 품질이 달라지기 때문입니다. 또한 이는 기본적인 원칙을 지키면서도 경험 및 노하우가 필요한 기술이기도 하기에 “엔지니어링”이라 칭하게 된 것이죠.

프롬프트 엔지니어링은 AI 서비스 사용자가 직접적으로 필요로 하는 기술이기 때문에, OpenAI의 공개된 문서를 참조하여 구체적인 전략에 대해 더 설명하도록 하겠습니다.

지침을 명확하게 작성하기(Write clear instructions)#

원하는 결과에 대한 맥락과 필요로 하는 정보에 대해 구체적으로 작성해야 합니다. “Excel에서 숫자를 어떻게 합산하나요?”보다는 “Excel에서 달러 금액 행을 어떻게 합산하나요? ‘Total’ 열의 왼쪽에 있는 모든 시트의 값을 자동으로 합산하여 ‘Total’ 열에 적용되도록 하고 싶습니다.”와 같이 작성하는 편이 좋습니다.

AI 모델에게 페르소나를 설정하는 게 좋습니다. 예를 들어 “당신은 Python 프로그래머입니다. 코드가 주어지면 주석을 추가하고 설명해 주세요. …”처럼 AI 모델의 역할을 미리 설정해 주는 방식입니다.

입력 내용 중 구분이 필요한 내용들은 삼중 따옴표나 XML 태그 등으로 명확하게 구분해 주는 게 좋습니다.

아래의 삼중 따옴표로 구분된 글을 요약해 주세요.
"""
여기에 대상 글이 들어갑니다.
"""

동일한 주제에 대한 한 쌍의 기사(XML 태그로 구분됨)가 제공됩니다.
먼저 각 기사의 주장을 요약해 주세요.
그런 다음 그들 중 어느 것이 더 나은 주장인지 표시하고 그 이유를 설명해 주세요.

<article>첫번째 기사 내용</article>
<article>두번째 기사 내용</article>

경우에 따라, 단계를 구분하여 지침을 작성하는 것이 도움이 될 수 있습니다.

삼중 따옴표로 구분된 글에 대하여 아래의 단계별 지침을 따라 주세요.
Step 1 - “요약:”이라는 접두어를 붙이고, 한 문장으로 요약해 주세요.
Step 2 - “번역:”이라는 접두어를 붙이고, 요약된 내용을 번역해 주세요.
"""
여기에 글이 들어갑니다.
"""

요구사항을 구체적으로 설명하기 어려운 경우, 예시를 제공하고 그와 같은 방식으로 답변해 달라고 지침을 작성할 수 있습니다.

주어진 질문에 대하여 예시와 같은 스타일로 대답해 주세요.
<예시>
질문: 인내심이란 무엇인가요?
답변: 가장 깊은 계곡을 만드는 강은 적당한 샘에서 흘러나옵니다.
      가장 장엄한 교향곡은 단 하나의 음표에서 비롯됩니다.
      가장 복잡한 태피스트리는 하나의 실에서 시작됩니다.
</예시>
<질문>바다란 무엇인가요?</질문>

원하는 결과의 양을 명시적으로 지정해 주는 것이 좋습니다. 예를 들면 다음과 같습니다. “~의 내용을 한 문장으로 요약해 주세요.”, “~에 대한 적당한 제목 3개를 제안해 주세요.”, “~의 내용을 500자 내외로 작성해 주세요.”

참조할 내용 제공하기(Provide reference text)#

참조 내용을 제공하고 응답 생성 시 사용하도록 지시할 수 있습니다.

질문에 답하려면 삼중따옴표로 구분된 기사 내용을 참조하세요.
기사에서 답변을 찾을 수 없는 경우 "답변을 찾을 수 없습니다."라고 기재하세요.
"""
기사 내용
"""
질문: 질문 내용

삼중 따옴표로 구분된 문서와 질문이 제공됩니다.
당신의 임무는 제공된 문서만을 사용하여 질문에 답하고, 질문에 답하는 데 사용된 문서의 구절을 인용하는 것입니다.
문서에 이 질문에 답하는 데 필요한 정보가 포함되어 있지 않으면 "정보가 부족합니다."라고 적어주세요.
질문에 대한 답변이 제공되면 인용 주석을 달아야 합니다.
관련 구절을 인용하려면 다음 형식을 사용해 주세요. ({"citation": …})
"""
문서 내용
"""
질문: 질문 내용

복잡한 작업을 하위 작업으로 나누기(Split complex tasks into simpler subtasks)#

사용자의 질의에 대해 카테고리를 먼저 구분하고, 해당 카테고리에서 구체적으로 지시하도록 프롬프트를 나눠 처리할 수 있습니다.

고객 문의 사항이 제공되면, 기본 카테고리와 보조 카테고리로 분류해 주세요.
기본 카테고리의 키는 "primary", 보조 카테고리의 키는 "secondary"로 하여 JSON 형식으로 출력을 제공해 주세요.

기본 카테고리: 빌링, 기술 지원, 계정 관리, 일반 문의

빌링의 보조 카테고리:
- 구독 취소 또는 업그레이드
- 결제수단 추가
- 요금 설명
- 빌링에 대한 이의 제기

기술 지원의 보조 카테고리:
- 문제 해결
- 기기 호환성
- 소프트웨어 업데이트

계정 관리의 보조 카테고리:
- 비밀번호 초기화
- 개인정보 업데이트
- 계정 삭제
- 계정 보안

일반 문의의 보조 카테고리:
- 제품정보
- 가격
- 피드백
- 상담원 연결

고객 문의: 인터넷 연결이 안됩니다.

기술 지원 카테고리에서 문제 해결이 필요한 고객 문의가 제공됩니다. 다음과 같이 사용자를 도와주세요.
- 라우터와 라우터 사이의 모든 케이블이 연결되어 있는지 확인하도록 요청하세요. 시간이 지남에 따라 케이블이 느슨해지는 것은 흔한 일입니다.
- 모든 케이블이 연결되어 있는데도 문제가 지속되면 어떤 라우터 모델을 사용하고 있는지 물어보세요.
- 이제 기기를 다시 시작하는 방법을 알려줄 것입니다.
  - 모델 번호가 MTD-327J인 경우 빨간색 버튼을 5초 동안 누른 후 5분 정도 기다린 후 연결을 테스트하라고 안내합니다.
  - 모델 번호가 MTD-327S인 경우 플러그를 뽑았다가 다시 연결한 다음 5분 정도 기다린 후 연결을 테스트하도록 안내합니다.
- 기기를 다시 시작하고 5분 동안 기다린 후에도 고객의 문제가 지속되면 {"IT 지원 요청됨"}을 출력하여 IT 지원팀에 연결하세요.
- 사용자가 이 주제와 관련 없는 질문을 하기 시작하면 문제 해결에 대한 현재 채팅을 종료할지 확인하고 다음 구성표에 따라 요청을 분류합니다.
<여기에 위의 기본 및 보조 카테고리 구분 내용 삽입>

고객 문의: 인터넷 연결이 안됩니다.

ChatGPT와 같은 채팅 UI 기반의 대화형 서비스인 경우, 해당 채팅방에서의 이전 대화가 다음 질의 데이터에 포함되어 AI 모델이 맥락을 파악할 수 있도록 합니다. 그런데 대화가 너무 길거나 주제에 부합하지 않는 내용이 많을 때 AI 모델이 맥락을 제대로 파악하지 못할 수 있습니다. 이런 경우에는 이전 대화를 요약해 질의에 포함시키는 것이 좋습니다.

책과 같이 긴 텍스트 데이터를 요약하는 경우, 한 번에 요약하는 것보다 섹션별로 요약한 후 요약된 내용들을 모아 반복적으로 요약하는 방식이 더 효과적입니다.

AI 모델이 먼저 “생각하게” 하기(Give models time to “think”)#

AI 모델이 어떤 솔루션이 맞는지 아닌지를 판단해야 하는 경우, 바로 정답 여부를 묻기보다 AI 모델에게 먼저 해법을 찾도록 한 뒤, 그 해법과 사용자의 해법을 비교하도록 하는 것이 좋습니다.

아래의 문제에 대하여 학생의 해결 방법이 맞는지 알려주세요.

문제 설명: 태양광 발전소를 건설하고 있는데 재정 문제를 해결하는 데 도움이 필요합니다.
- 토지 비용은 $100/평방피트 입니다.
- 평방피트당 250달러에 태양광 패널을 구입할 수 있습니다.
- 연간 고정 $100,000의 비용과 평방피트당 $10의 추가 비용이 드는 유지 관리 계약을 협상했습니다.
평방피트 수에 따른 운영 첫 해의 총 비용은 얼마입니까?

학생의 해결 방법: x를 설치 면적(제곱 피트)이라고 하겠습니다.
1. 토지 비용: 100배
2. 태양광 패널 비용: 250배
3. 유지비용 : 100,000 + 100x
총 비용: 100x + 250x + 100,000 + 100x = 450x + 100,000

위와 같이 바로 맞는지 아닌지를 질의하는 것보다, 아래와 같이 AI 모델이 먼저 솔루션을 찾고 비교하도록 하는 것이 응답의 신뢰도를 높이는 데에 더 효과적입니다. 그래서 “아래의 문제에 대하여 학생의 해결 방법이 맞는지 알려주세요.” 부분을 “먼저 문제에 대한 자신만의 해결책을 찾아보세요. 그런 다음 당신의 해법을 학생의 해법과 비교하고 학생의 해법이 올바른지 평가해 보세요. 문제를 직접 해결하기 전에는 학생의 해결책이 올바른지 결정하지 마세요.”라고 작성하여 질의하는 것이 더 좋습니다.

외부 도구 사용하기(Use external tools)#

RAG에 대한 개념을 설명할 때 언급한 바와 같이, 외부 데이터를 사용하여 AI 모델에 대한 입력 데이터를 보강하도록 지시할 수 있습니다. 특정 URL을 제공하고 해당 내용을 참고하여 질문에 답해 달라고 하거나, 특정 키워드를 제공하고 검색 결과를 요약해 달라는 등의 지시를 할 수 있습니다. 그리고 ChatGPT의 경우 GPTs(커스텀 GPT)를 직접 만들거나, 공개된 GPTs 중 필요에 부합하는 것을 찾아 사용할 수도 있습니다. (API를 통한 도구 연동/검색/파일 기반 질의 등은 OpenAI의 Tools 및 File search 가이드에서 더 자세히 다룹니다.)

위에서 설명한 프롬프트 엔지니어링 전략들은 OpenAI의 공개 문서에 기재된 내용을 기반으로 작성했기 때문에, 모든 AI 모델에 대해 항상 그대로 적용 가능한 전략은 아닙니다. 모델/서비스마다 입력 형식이 다를 수도 있고, 필요로 하는 매개변수(파라미터)가 다를 수도 있기 때문이죠.

또한 실서비스에서는 “프롬프트를 잘 쓰는 것”뿐만 아니라, 모델이 업데이트되면서 결과가 달라질 수 있다는 점을 관리하는 것이 중요합니다. 예를 들어 어제까지는 같은 프롬프트에 대해 항상 비슷한 형식으로 답하던 모델이, 업데이트 이후에는 답변 스타일이나 출력 형식이 미묘하게 달라질 수 있습니다(서비스 입장에서는 갑자기 동작이 바뀐 것처럼 느껴질 수 있죠).

그래서 프로덕션에서는 보통 특정 **모델 스냅샷(버전)**을 고정해 예측 가능성을 높이고, 프롬프트를 수정하거나 모델을 교체할 때는 평가(evals)(= 미리 준비해 둔 “시험 문제 세트”)로 핵심 케이스들이 잘 동작하는지 확인하는 방식이 권장됩니다. (참고로 이 내용은 주로 OpenAI API 등을 이용해 서비스를 개발·운영하는 개발자 관점의 이야기입니다. 일반 사용자는 “업데이트로 결과가 달라질 수 있다”는 점을 인지하고, 중요한 작업은 한 번 더 검증하는 정도로만 참고해도 충분합니다.)

다만 ChatGPT나 구글의 Gemini와 같은 채팅형 AI 서비스를 사용할 때는 비교적 보편적으로 적용 가능한 전략들이고, 해당 전략들을 이해하면 다른 AI 모델에 대한 프롬프트를 작성할 때도 도움이 될 것입니다.

컨텍스트 엔지니어링(Context Engineering)#

프롬프트 엔지니어링이 “무엇을 시킬지(지침/형식)”를 설계하는 일이라면, 컨텍스트 엔지니어링은 “모델이 답을 만들 때 참고할 **재료(배경정보)**를 어떤 방식으로 넣어줄지”를 설계하는 일에 가깝습니다. 같은 프롬프트라도 어떤 컨텍스트를 함께 제공하느냐에 따라 답변의 정확도와 일관성이 크게 달라질 수 있습니다.

컨텍스트는 단순히 긴 글을 많이 붙이는 것이 아니라, 필요한 정보를 필요한 만큼 넣고, 모델이 헷갈리지 않도록 구조화하는 것이 핵심입니다.

컨텍스트에 포함될 수 있는 것들#

• 대화 맥락: 이전 대화 내용(필요 시 요약본)
• 업무/도메인 자료: 정책/매뉴얼/가이드/FAQ 같은 내부 문서
• 사용자/업무 상태: 사용자의 설정, 현재 단계, 입력한 값(단, 개인정보/민감정보는 최소화)
• 도구 실행 결과: Function Calling으로 조회한 데이터, 계산 결과, 시스템 응답
• 작업 목표/제약: “반드시 지켜야 하는 규칙”, “금지 사항”, “출력 형식”

잘 되는 컨텍스트 구성 팁#

• 우선순위를 정해 정리해서 넣기: 중요한 것부터, 그리고 “무엇이 정답 근거인지”가 드러나게
• 길이를 관리하기: 너무 길면 핵심을 놓치고, 컨텍스트 윈도우 한계를 빨리 소진합니다
• 섹션을 나눠 구분하기: Markdown 헤더나 XML 태그처럼 경계가 명확한 형식이 도움이 됩니다
• 최신성/정합성 확인하기: 오래된 정책 문서가 섞이면 오히려 품질이 떨어질 수 있습니다
• 근거 기반으로 답하게 만들기: “아래 문서만 근거로 답하고, 없으면 모른다고 말하기” 같은 규칙을 함께 주면 할루시네이션을 줄이는 데 도움이 됩니다

RAG와 Function Calling도 컨텍스트 엔지니어링의 한 형태#

RAG는 “필요한 문서를 자동으로 찾아 컨텍스트에 붙여 주는 방식”이고, 프롬프트에 사람이 직접 문서를 포함시키는 것도 컨텍스트 엔지니어링의 한 방법입니다. 또한 Function Calling으로 DB 조회/계산/API 호출 등을 수행한 뒤, 그 결과를 컨텍스트로 제공해 답변에 반영하게 만드는 것 역시 컨텍스트 엔지니어링의 중요한 부분이라 볼 수 있습니다. 즉, 컨텍스트 엔지니어링은 RAG뿐 아니라 “도구 실행 결과를 컨텍스트로 붙여 활용하는 방식”까지 포함하는 더 넓은 개념이라고 할 수 있습니다.