에이전트 / AI 개발 개념
프롬프트 엔지니어링(Prompt Engineering)
프롬프트 엔지니어링은 AI에 전달할 지시와 예시를 설계하고, 실제 결과를 비교하며 개선하는 작업입니다.
쉬운 설명
AI가 만든 글이 계속 원하는 형식과 다르다면 요청을 바꿔 볼 수 있어요. 목적, 필요한 내용, 출력 형식과 예시를 정리하고 실제 입력으로 결과를 확인하는 과정이 프롬프트 엔지니어링이에요. 멋진 문장이나 긴 지시를 만드는 것만 뜻하지는 않아요. 어떤 결과가 좋아졌는지 판단할 기준도 필요해요.
이런 상황에서 만나요
스터디 회의록을 요약했더니 결정 사항과 잡담이 섞여 나왔어요. 같은 회의록을 두고 요청을 고쳐, 필요한 정보가 더 잘 추려지는지 비교하는 상황이에요.
같은 회의록에 요청만 바꿔 비교해요
이 회의록을 잘 요약해 줘.
결정 사항 / 다음 할 일을 구분해 줘.
원문에 없는 담당자는 “미정”으로 표시해 줘.
중요한 결정 누락 여부
원문에 없는 담당자 생성 여부
- 1무엇을 남겨야 하는지가 분명하지 않은 요청이에요.
- 2결과에 필요한 구분과 정보가 없을 때의 처리를 정해요.
- 3길이나 말투만 보지 않고 원하는 조건을 확인해요.
“잘 요약해 줘”를 “결정 사항과 다음 할 일을 나눠 쓰고, 없는 담당자는 미정으로 표시해 줘”처럼 바꿔 보세요. 원문에 없는 내용이 생기지 않았는지와 중요한 항목이 빠지지 않았는지를 함께 확인해요. 다른 회의록에서도 같은 기준으로 시험해요.
헷갈리기 쉬운 점
프롬프트가 길수록 결과도 좋아지나요?
길이 자체가 품질을 보장하지는 않아요. 서로 충돌하는 규칙이나 불필요한 설명이 늘면 의도가 흐려질 수 있어요. 원하는 동작을 분명히 적고 실제 실패 사례에 필요한 조건을 보강하는 편이 좋아요.
한 번 잘 나온 결과만으로 개선됐다고 판단하지 마세요. 모델이나 설정을 동시에 바꾸면 무엇 때문에 결과가 달라졌는지 알기 어려워요. 비교할 입력과 조건을 맞춰 두세요.
왜 알아야 할까요?
AI에게 막연히 “다시 해 줘”라고 반복하는 대신, 어떤 조건을 고쳐야 하는지 설명할 수 있어요. 팀에서 사용하는 요청문을 개선할 때도 결과를 비교할 기준이 생겨요.
조금 더 자세히
목표와 평가 기준을 먼저 정하고 지시·예시·출력 형식을 조정합니다. 필요한 경우 좋은 결과의 예시를 함께 제공하되, 예시를 그대로 복사하는 것이 목표가 되지 않도록 다양한 입력으로 확인합니다.
모델의 응답에는 변동이 있을 수 있습니다. 대표 입력과 실패하기 쉬운 입력을 모아 비교하고, 수정한 프롬프트와 사용한 모델·설정을 기록하면 어떤 변경이 효과가 있었는지 확인하기 쉽습니다.
직접 사용할 때 확인해 보세요
- 좋은 결과의 기준을 먼저 정한다
- 같은 입력과 모델 조건으로 비교한다
- 다른 입력에서도 개선이 유지되는지 확인한다
관계 지도
