jihun's study log

Prompt Engineering

10 min read

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

AI에 무엇을 어떻게 지시할지 설계하는 기술

  1. Prompt : AI에 주는 자연어 지시나 질문
  2. 목표 : 모델이 사용자 의도와 일치하는 답을 내도록 하는 것
  3. 엔지니어링 : 단순 질의 작성이 아니라 구조적 설계와 반복적 개선

프롬프트가 필요한 이유

  • 프롬프트는 단순한 입력이 아니라 AI 출력을 안내하는 인터페이스
  • 모델의 응답 품질은 프롬프트의 구조, 명료성, 맥락 정보에 크게 영향을 받는다.
    • 모델이 의도를 정확히 이해하게 함
    • 불명확, 모호한 응답을 줄임
    • 결과의 일관성과 정확성을 높임

좋은 프롬프트의 기본 구조

  1. 역할과 맥락 지정 : 모델이 어떤 역할을 수행하는지 명시 (ex. “너는 10년차 백엔드 개발자로서…”)

  2. 명확하고 구체적 지시 : 목표와 조건을 분명히 기술하고 모호한 요청은 결과를 불명확하게 함

  3. 예시 제공 (Few-shot): 예상되는 응답 형식을 전달하는 예시를 포함하고, 모델이 패턴을 이해하도록 유도

  4. 맥락과 입력 정보 제공 : 필요한 배경이나 자료를 포함해 모델이 충분히 이해하게 함

  5. 검증 기준 명시 : 모델이 생성한 결과를 평가할 기준을 프롬프트에 넣음

좋은 프롬프트 vs 나쁜 프롬프트

좋은 프롬프트

"10년 경력 소프트웨어 아키텍트 관점으로, 마이크로서비스 아키텍처의 장단점을 비교하는 800자 기사 작성"

"파이썬 언어 10년차 경력의 개발자 관점으로, 현재 이 알고리즘 코드에서 발생할 수 있는 예외 상황이 무엇이 있을지 분석하여 주석으로 설명. 입력 조건은..."

나쁜 프롬프트

"기술 블로그 글 써줘"

"이거 왜 안돼?"

"이거 왜 이래?"

좋은 프롬프트의 기본 구조

역할, 맥락 , 목적, 길이 모두 지정

역할 : 10년 경력 소프트웨어 아키텍트 관점으로,

맥락 : 마이크로서비스 아키텍처의

목적 : 장단점을 비교하는

길이 : 800자 기사 작성

프롬프트 엔지니어링 기법

Zero-shot Prompting : 예시 없이 지시

다음 문장을 더 정중한 비즈니스 메일 문체로 바꿔줘: ;내일까지 자료 보내주세요."

"아래 로그를 보고 가장 가능성 높은 에러 원인 3가지를 bullet로 정리해줘 (로그 붙여넣기)"

"이 SQL 쿼리의 실행 계획을 개선할 수 있는 인덱스 후보를 제안해줘. (테이블/쿼리 제공)"

Few-shot Prompting : 예시로 패턴을 보여줌

예시 : 요구사항을 테스트 케이스로 변환하는 패턴

입력 : 사용자는 이메일로 회원가입 할 수 있다
출력 : Given 이메일이 유효함 When 회원가입 요청 Then 계정 생성됨

입력 : 비밀번호는 8자 이상이어야 한다.
출력 : Given 7자 비밀번호 When 회원가입 요청 Then 400 에러 반환

이제 아래 요구사항도 같은 형식으로 5개 테스트로 만들어줘 : (요구사항 붙여넣기)

Chain-of-Thought : 단계적 사고를 유도하는 구조

예시 : 알고리즘 문제 풀이

1. 핵심 아이디어
2. 복잡도 분석
3. 엣지 케이스 3개
4. 의사코드

순서로 작성해줘. (문제 제공)

역할 분리

LLM은 계획, 검증이 내장된 엔진이 아니라, 다음 토큰을 예측하는 모델이다.

LLM은 내부적으로 역할이 구분되어 있지 않다. 따라서, 단계 분리는 성능을 높인다.

생성과 검증을 분리하면 정확도가 높아진다.

  1. 계획 (Planner)
  2. 생성 (Generator)
  3. 검증 (Reviewer)

역할 프롬프트에 반드시 포함되어야 할 요소

1. 역할 선언 (Role Declaration) : 이 모델은 무엇을 하는 존재인가 / 무엇을 하지 않는가

2. 목표 정의 (Objective) : 이 역할의 산출물은 무엇인가 / 성공 기준은 무엇인가

3. 입력 명시 (Input Contract) : 무엇을 받아서 작업하는가 / 이전 단계 산출물인가, 원 요구사항인가

4. 금지사항 (Constraints / Prohibitions) : 절대 해서는 안 되는 행동 / 역할을 침범하는 행동

5. 출력 구조 (Output Format) : 반드시 어떤 구조로 답해야 하는가 / 자유 서술 금지 여부

계획 (Planner) 단계

- 역할 선언 (Role Declaration) : 만드는 역할이 아니라 정리하는 역할 (요구사항을 구조화하는 단계 / 모호한 요구사항은 정리하거나 질문으로 반환)
- 목표 정의 (Objective) : 코드가 아니라 구조화된 계획 (작업 순서를 명시 / 제약 조건을 명확히 함 / 성공 기준은 구현 가능한 명확한 계획이 존재하는 것)
- 입력 명시 (Input Contract) : 결과가 아니라 요구를 입력으로 받음 (원 요구사항 / 추가 설명 또는 제약 조건 / 기존 시스템 맥락(있는 경우)
- 금지사항 (Constraints / Prohibitions) : 계획 단계는 판단과 구조화까지만 (코드 작성 금지 / 추정 기반 기능 추가 금지 / 검증 단계로 넘어가는 판단 수행 금지)
- 출력 구조 (Output Format) : 자유 서술이 아니라 구조화된 목록 (요구사항 요약 / 작업 단계 목록 (순서 포함) / 제약 조건)

생성 (Generator) 단계

- 역할 선언 (Role Declaration) : 계획을 직접 수행 (계획을 기반으로 산출물을 만듦 / 계획을 수정하지 않음)
- 목표 정의 (Objective) : 코드 혹은 산출물 직접 구현 (Planner가 정의한 단계에 따라 구현 / 성공 기준은 계획에 명시된 범위를 정확히 구현하는 것)
- 입력 명시 (Input Contract) : 정리된 계획을 입력 받음 (Planner의 계획 문서 / 원 요구사항 (참고용) / 기존 코드베이스 (있는 경우)
- 금지사항 (Constraints / Prohibitions) : 계획에 따른 역할 수행까지만 (계획에 없는 기능 추가 금지 / 전체 재작성 금지 / 검증 역할 수행 금지)
- 출력 구조 (Output Format) : 다음 단계가 검증할 수 있어야 함 (구현 결과 / 변경 범위 명시 (어디를 수정했는지) / 계획 단계와의 대응 관계)

검증 (Reviewer) 단계

- 역할 선언 (Role Declaration) : 수행 결과를 검증하는 단계 (산출물을 평가 / 새 기능을 추가하지 않음)
- 목표 정의 (Objective) : 요구사항 충족 여부 판단 (계획 대비 구현 일치 여부 판단 / 리스크 및 영향 범위 분석/ 성공 기준은 판단 근거가 명확한 검토 결과)
- 입력 명시 (Input Contract) : (Planner의 계획 / Generator의 결과 / 원 요구사항)
- 금지사항 (Constraints / Prohibitions) : (코드 수정 금지 / 재구현 금지 / 새로운 계획 제안 금지)
- 출력 구조 (Output Format) : 보고서 형식 (요구 충족 여부 (Yes/No + 근거) / 논리적 오류 / 잠재적 리스크 / 개선 제안 (선택 사항)

그래프 뷰