9장 체계적인 프롬프트 엔지니어링과 에이전트 프로필

개요

프롬프트 엔지니어링은 "한 번에 완벽한 문장 쓰기"가 아니라, 질문을 계속 다듬고 결과를 평가하면서 개선해 가는 반복(iteration)·수정·평가의 과정이다. 모호한 요청보다는 구체적인 지시를 줄수록, 그리고 그 지시를 체계적으로 실험하고 비교할수록 LLM이 내놓는 답변의 품질은 눈에 띄게 좋아진다.

또한 오늘날의 LLM 활용은 단순 질의응답을 넘어, 특정 역할과 성격을 가진 '에이전트'를 설계하는 방향으로 발전하고 있다. 이를 위해 시스템 메시지(시스템 프롬프트)를 사용해 모델의 역할과 페르소나를 정의하고, 루브릭(rubric)·그라운딩(grounding) 같은 교육 평가 기법을 적용해 에이전트 프로필의 품질을 점검·개선하는 접근이 중요해지고 있다.

프롬프트 엔지니어링은 왜 '과정'인가?

프롬프트 엔지니어링의 핵심은 "한 번에 좋은 프롬프트를 쓰자"가 아니라, "조금 쓰고, 결과를 보고, 다시 고쳐 쓰자"에 있다. LLM의 답변은 입력된 프롬프트에 매우 민감하기 때문에, 작은 표현 수정이나 정보 추가만으로도 결과가 크게 달라지는 경우가 많다.

실제로 "can you recommend something"처럼 두루뭉술한 질문을 했을 때 LLM은 추가 정보를 요구하지만, "중세 시대를 배경으로 한 타임 트래블 영화 하나 추천해 줘"처럼 구체적으로 요청하면 바로 원하는 유형의 추천을 제공한다. 이처럼 프롬프트 엔지니어링은 "질문 → 답변 확인 → 질문 수정"이라는 짧은 루프를 계속 돌며, 점점 더 적합한 프롬프트를 찾아가는 작업이다.

이 과정은 감(감각)에만 의존하면 한계가 있다. 결국 어느 지점에서 "지금 프롬프트가 이전보다 더 낫다"고 판단해야 하고, 이 판단을 돕기 위해 명시적인 기준과 절차, 즉 체계적인 평가 방법이 필요하다. 그래서 프롬프트 엔지니어링은 본질적으로 "반복과 평가를 기반으로 한 엔지니어링 프로세스"로 보는 것이 적절하다.

불분명한 질문 vs 구체적인 질문

모호한 프롬프트의 한계

"추천 좀 해줘", "설명해줘", "이거 개선해줘"처럼 맥락과 기준이 없는 요청은, 인간에게도 막연한 질문이지만 LLM에게도 마찬가지로 애매하다. 이런 질문에 LLM은 보통 다음과 같이 반응한다.

• 추가 질문을 던져 맥락을 캐내려 하거나

• 가장 일반적인 상황을 가정해 무난한, 그러나 종종 엇나간 답변을 생성한다

결과적으로 사용자는 "생각보다 별로인데?"라는 인상을 받기 쉽고, 모델의 능력을 과소평가하게 된다.

구체적인 프롬프트가 만드는 차이

반대로, 아래 요소들을 포함해 질문을 구체화하면 답변 품질이 크게 향상된다.

• 목표: "블로그 글 초안을 쓸 수 있게 도와줘"

• 대상 독자: "개발 입문자를 대상으로"

• 형식: "소제목 3~5개로 나눠서"

• 제한/조건: "예시는 자바스크립트 기준으로", "2000자 이내로"

• 톤: "친절하지만 과하게 가볍지 않게"

예컨대 "타임 트래블 영화 추천해 줘"보다는 "중세 시대를 배경으로 한 타임 트래블 영화를 1편만 추천해 주고, 간단한 줄거리와 추천 이유를 3줄 이내로 설명해 줘"라고 하면, 사용자는 원하는 맥락에서 원하는 분량의 답변을 얻을 수 있다.

핵심은 "내 머릿속 기준"을 가능한 한 많이 텍스트로 꺼내 적어주는 것이다. 이것이 곧 "명확한 지시 작성"이며, 프롬프트 엔지니어링에서 답변 품질을 좌우하는 가장 기본적인 기술이다.

시스템 메시지로 역할과 페르소나 설정하기

시스템 메시지/프롬프트의 역할

LLM과 대화할 때 보통 우리는 사용자 메시지만 신경 쓰지만, 실제로는 그 위에 시스템 메시지가 존재한다. 시스템 메시지는 모델에게 다음과 같은 상위 지침을 준다.

• 어떤 역할을 맡을 것인지 (예: "너는 시니어 백엔드 개발자다")

• 어떤 스타일로 답변할 것인지 (예: "항상 예제 코드를 포함해라")

• 어떤 제한을 지킬 것인지 (예: "보안 관련 내용은 절대 추측하지 마라")

예를 들어, 시스템 메시지에 "You are an expert on time travel movies."라고 선언한 뒤, 같은 "can you recommend something"이라는 모호한 질문을 던지면, 모델은 더 이상 모든 세계의 모든 추천을 고민하지 않고 "타임 트래블 영화 전문가의 관점에서 추천"이라는 좁혀진 역할 안에서 생각하게 된다. 그 결과, 같은 모호한 문장이라도 컨텍스트가 명확해져 답변이 훨씬 타깃을 잘 맞추게 된다.

페르소나 설정의 의미

시스템 메시지를 활용하면 LLM의 페르소나(persona)를 설계할 수 있다. 페르소나는 단순히 말투만 정하는 것이 아니라, 다음 요소들을 포함하는 폭넓은 개념이다.

• 전문 분야: "클라우드 아키텍처 전문가", "학습 코치", "법률 문서 요약가" 등

• 지식 수준: "대학생 수준", "현업 10년차 수준" 등

• 소통 방식: "비전문가에게 쉽게 설명", "간결하고 포인트 위주로", "반말/존댓말" 등

• 태도·가치관: "항상 보수적으로 위험을 경고", "학습자의 자율성을 우선시" 등

이렇게 정의된 페르소나는 여러 세션에 걸쳐 일관된 답변 스타일과 관점을 유지하도록 돕고, 팀이나 조직에서 "하나의 에이전트"를 재사용 가능하게 만든다.

Test Changes Systematically: 체계적 프롬프트 개선 전략

"감으로 튜닝"에서 "실험으로 튜닝"으로

프롬프트를 조금 바꾸고, "이게 낫나?" 감으로 판단하는 단계는 초반에는 유효하지만, 실제 업무나 서비스에 쓰려면 훨씬 더 체계적인 접근이 필요하다. 여기서 중요한 전략이 바로 Test Changes Systematically다.

이 전략의 요지는 다음과 같다.

1. 변수 통제: 한 번에 한 가지 요소만 바꾸기

   • 예: "역할 설명만 바꾼 버전" vs "출력 형식만 바꾼 버전"

2. 동일한 테스트 셋으로 비교

   • 같은 질문·입력 데이터에 대해 두 프롬프트를 모두 실행

3. 명시적인 평가 기준으로 점수 매기기

   • 사람이 직접 평가하거나, 별도의 평가 프롬프트·평가 모델을 사용

이를 반복하면, 어떤 변경이 실제로 성능 향상에 기여했고 어떤 것은 의미가 없었는지를 객관적으로 파악할 수 있다. 프롬프트 엔지니어링이 "튜닝 놀이"가 아니라 "실험 기반 최적화"에 가까워지는 지점이다.

도구의 역할: 예시로 보는 Prompt Flow

이런 체계적 실험을 돕기 위해, 마이크로소프트는 Azure Machine Learning Studio 안에서 Prompt Flow라는 도구를 만들었다. Prompt Flow는 다음과 같은 특징을 가진다.

• 입력-LLM 호출-후처리-출력 등으로 구성된 프롬프트 흐름(flow)을 블록 단위로 정의

• 같은 입력에 대해 여러 프롬프트 버전을 배치(batch)로 돌려 비교

• 결과를 모아 품질을 평가하는 과정을 자동화·반복

이처럼 도구를 활용하면, "프롬프트 A와 프롬프트 B 중 어느 쪽이 더 좋은가?"를 수십·수백 개의 테스트 케이스로 평가하고 분석할 수 있으며, 이는 곧 에이전트 프로필의 지속적인 개선으로 이어진다.

루브릭과 그라운딩: 교육 평가 기법의 응용

루브릭(rubric)으로 답변 품질 정의하기

교육에서 루브릭은 "어떤 과제를 어떤 기준으로 어느 정도면 잘한 것인가"를 구체적으로 정의한 평가표를 의미한다. 프롬프트와 에이전트 프로필을 평가할 때도 이 개념을 그대로 가져올 수 있다.

예를 들어 "설명형 답변"을 평가하는 루브릭을 만든다면, 다음과 같이 항목을 정의할 수 있다.

• 정확성: 사실 오류가 없는가? (0~3점)

• 명료성: 비전문가도 이해할 수 있는가? (0~3점)

• 구조화: 논리적 순서와 단락 구성이 잘 되었는가? (0~2점)

• 관련성: 질문의 핵심에 집중했는가? (0~2점)

각 항목별로 수준(예: 0점: 부족, 1점: 미흡, 2점: 양호, 3점: 탁월)을 정의해 두면, 사람이든 모델이든 이 기준에 따라 답변을 정량적으로 평가할 수 있다. 이렇게 루브릭을 명문화해야 "이 프롬프트가 더 나은 이유"를 팀 단위로 공유하고 재현할 수 있다.

그라운딩(grounding)으로 현실과의 연결 강화

그라운딩은 LLM의 답변이 실제 데이터·지식 기반과 얼마나 잘 연결되어 있는지를 평가·보정하는 개념이다. 교육에서는 학습자의 답이 교과서나 수업 내용에 잘 근거하고 있는지를 보는 것과 비슷하다.

프롬프트/에이전트 평가에서의 그라운딩은 예를 들어 다음과 같은 방식으로 활용된다.

• 모델에게 특정 문서·지식 베이스를 제공하고, 답변이 그 범위를 벗어나지 않도록 유도

• 답변 생성 후, "이 답변이 어떤 근거에 기반했는지"를 설명하게 하여 검증

• 평가 단계에서 "주어진 자료와 얼마나 잘 일치하는지"를 채점 기준에 포함

이렇게 하면 에이전트가 사실에 없는 내용을 그럴듯하게 지어내는 헬루시네이션(환각)을 줄이고, 신뢰할 수 있는 답변을 제공하게 만들 수 있다. 프롬프트 설계와 프로필 설계에서 그라운딩은 특히 업무·도메인 시스템과의 연계에서 중요하다.

에이전트 프로필과 페르소나의 개념

에이전트 프로필이란?

에이전트 프로필은 "이 에이전트가 누구이며, 무엇을 어떻게 하는지"를 정의하는 구성요소들의 묶음이다. 단순한 한 줄의 시스템 프롬프트를 넘어서, 여러 종류의 프롬프트와 설정, 외부 요소가 결합된 전체적인 설계라고 볼 수 있다.

일반적으로 에이전트 프로필은 다음과 같은 요소들을 포함할 수 있다.

• 페르소나(Persona): 역할, 전문성, 말투, 태도 등

• 특별 지시사항: 반드시 지켜야 할 규칙, 해야 할 것/하지 말아야 할 것

• 도구/액션(actions/tools): 검색, 코드 실행, 외부 API 호출 등

• 지식/메모리(knowledge & memory): 참조할 문서, 지속적으로 유지할 정보

• 추론/계획(reasoning & planning): 단계별 사고 요구, 계획 수립 여부

• 평가/피드백(evaluation & feedback): 자신의 답변을 점검·수정하는 절차

이 중 핵심은 여전히 "프롬프트"다. 각 요소를 동작시키는 것은 결국 그에 맞는 프롬프트이며, 프롬프트를 어떻게 설계하느냐에 따라 에이전트의 행동이 달라진다.

페르소나 vs 에이전트 프로필

페르소나는 에이전트 프로필의 일부로, 주로 "겉으로 드러나는 캐릭터와 소통 방식"을 담당한다.

• 예: "당신은 10년 경력의 데이터 분석가이며, 초보자에게 친절하게 설명합니다. 항상 예시를 들어 설명하고, 지나치게 전문용어 사용을 피합니다."

반면 에이전트 프로필은 이 페르소나를 포함하면서도, 도구 사용, 지식 소스, 평가 방식까지 포괄하는 전체 설계도에 가깝다.

• 예: "이 에이전트는 회사 내부 위키를 우선적으로 참조하고, 검색 도구를 통해 최신 정보를 보완하며, 답변 후에는 루브릭에 따라 스스로 답변 품질을 점검한 뒤 요약 결과만 사용자에게 보여준다."

즉, 페르소나는 "에이전트의 사람 같은 얼굴"이고, 에이전트 프로필은 "그 얼굴을 포함한 전체 시스템 구조"라고 이해하면 된다.

에이전트 프로필을 구성할 때 고려할 주요 요소들

에이전트를 설계할 때 체계적으로 생각해야 할 대표 요소들을 정리하면 다음과 같다.

1. 역할 정의 (Role & Persona)

   • 이 에이전트는 무엇을 잘해야 하는가? (예: 코드 리뷰, 글쓰기 코치, 법률 문서 요약)

   • 누구에게 말하는가? (입문자, 전문가, 일반 사용자 등)

   • 어떤 태도와 말투를 가질 것인가? (친근, 엄격, 공식적 등)

2. 입·출력 형식 (I/O Format)

   • 사용자는 어떤 형태로 질문을 주는가? (자연어, 템플릿, JSON 등)

   • 에이전트는 어떤 형식으로 결과를 내놓아야 하는가? (목록, 표, 마크다운, JSON 등)

3. 도구·지식 소스 설정 (Tools & Knowledge)

   • 외부 API, 검색, 데이터베이스, 사내 문서 등 무엇을 활용할 수 있는가?

   • 그라운딩을 위해 어떤 자료를 우선적으로 참조해야 하는가?

4. 추론·계획 전략 (Reasoning & Planning)

   • 단계별 사고(Chain-of-Thought)를 사용할지 여부

   • 복잡한 작업을 여러 하위 작업으로 쪼개 계획할지 여부

5. 평가·개선 메커니즘 (Evaluation & Improvement)

   • 어떤 루브릭으로 답변을 평가할 것인가?

   • Test Changes Systematically 전략을 어떻게 적용해 버전을 개선할 것인가?

   • 사용자 피드백을 어떻게 수집·반영할 것인가?

6. 안전·제한 규칙 (Safety & Constraints)

   • 어떤 주제는 답변하지 않거나, 반드시 주의를 표시해야 하는가?

   • 추측이 필요한 상황에서의 태도 (추측 금지, 추측임을 명시 등)

이 항목들을 문서화하고, 관련 프롬프트를 한 세트로 관리하면, "에이전트가 무엇을 할 수 있고 어떤 품질을 내야 하는지"를 팀 전체가 공유하기 쉬워진다. 동시에 Prompt Flow 같은 도구를 통해 이 프로필을 지속적으로 실험·개선하는 것이 가능해진다.

마무리: 잘 묻고, 잘 실험하고, 잘 설계하기

정리하면, 체계적인 프롬프트 엔지니어링과 에이전트 프로필 설계는 다음 세 가지 축을 중심으로 돌아간다.

1. 잘 묻기

   • 모호한 질문 대신 구체적이고 명확한 지시 작성

   • 시스템 메시지로 역할·페르소나를 미리 정의

2. 잘 실험하기

   • Test Changes Systematically 전략으로 한 번에 한 요소씩 바꾸어 실험

   • 동일한 테스트 셋과 루브릭을 사용해 객관적으로 비교·평가

3. 잘 설계하기

   • 에이전트 프로필을 페르소나, 도구, 지식, 추론, 평가, 안전 규칙 등으로 구조화

   • 그라운딩을 통해 실제 데이터·지식과의 연결을 강화하고 헬루시네이션을 줄이기

이 관점을 가지고 LLM을 사용할 때, 단순한 "대화형 검색" 수준을 넘어서, 실제 업무와 서비스를 돕는 신뢰할 수 있는 AI 에이전트를 만드는 데 한 걸음 더 다가갈 수 있다.