프롬프트의 구성 요소

좋은 프롬프트는 모델이 추측해야 하는 부분을 줄입니다. 어떤 관점으로 판단해야 하는지, 왜 이 작업이 필요한지, 정확히 무엇을 해야 하는지, 어디까지 해도 되는지, 마지막에 어떤 형태로 보고해야 하는지를 알려줍니다. 간단한 요청에는 일부 구성 요소만 있어도 충분합니다. 다만 작업이 복잡하거나 실패 비용이 클수록 구조를 갖춘 프롬프트가 훨씬 안정적입니다.

가장 기본적인 구성 요소는 역할, 맥락, 작업, 제약, 출력 형식, 예시입니다. 이 여섯 가지를 쓰면 모델이 같은 방향으로 판단할 기준을 얻습니다. 프롬프트의 길이보다 판단 기준을 분명히 하는 데 초점이 있습니다.

역할 / 페르소나

역할은 모델이 어떤 관점에서 문제를 바라봐야 하는지 정하는 부분입니다. "너는 친절한 여행 가이드입니다", "너는 초등학생에게 설명하는 과학 선생님입니다", "너는 복잡한 안내문을 쉬운 말로 풀어 쓰는 편집자입니다"처럼 작업에 필요한 판단 기준을 알려주는 것입니다.

역할을 단순한 장식으로 보면 곤란합니다. 같은 문서를 보더라도 편집자, 개발자, 강의자, 보안 리뷰어는 서로 다른 부분을 중요하게 봅니다. 역할을 잘 지정하면 모델은 어떤 기준으로 선택하고 생략하고 강조해야 하는지 더 쉽게 파악합니다.

다만 페르소나를 과하게 꾸미는 것은 별 도움이 되지 않습니다. "세계 최고의 천재 전문가"처럼 실질적인 판단 기준이 없는 표현보다, 실제 작업에 필요한 전문성이나 관점을 지정하는 편이 낫습니다.

약한 예시는 다음과 같습니다.

너는 전문가입니다. 이 여행 계획을 봐 주세요.

이 프롬프트는 전문가라는 말은 있지만, 어떤 종류의 전문가인지 알 수 없습니다. 비용을 봐야 하는지, 이동 동선을 봐야 하는지, 아이와 함께 가기 좋은지 불분명합니다.

더 나은 예시는 다음과 같습니다.

너는 가족 여행 일정을 많이 짜 본 여행 가이드입니다.
아래 제주도 2박 3일 일정을 이동 시간, 아이와 함께 가기 좋은 장소인지,
비가 올 때의 대안이 있는지 관점에서 검토해 주세요.

이렇게 쓰면 모델은 여행 계획 전반을 막연히 훑는 대신, 가족 여행 가이드에게 중요한 기준으로 결과를 좁혀 볼 수 있습니다.

맥락 / 배경

맥락은 모델이 현재 상황을 이해하기 위해 필요한 배경 정보입니다. 프로젝트의 목적, 사용자의 의도, 대상 독자, 현재 문제가 발생한 조건, 이미 시도한 방법, 관련 파일이나 데이터의 위치가 여기에 해당합니다.

모델은 프롬프트에 없는 정보를 자동으로 알 수 없습니다. 저장소 전체를 읽을 수 있는 에이전트라 하더라도, 어떤 파일이 중요한지, 왜 이 변경이 필요한지, 어떤 상황을 우선해야 하는지는 사용자가 알려주는 편이 좋습니다. 맥락이 부족하면 모델은 일반론에 기대거나, 실제 의도와 다른 방향으로 문제를 해결할 수 있습니다.

맥락을 넣을 때는 모든 정보를 한꺼번에 붙여 넣는 것보다, 모델이 결정을 내릴 때 필요한 정보만 넣는 것이 중요합니다. 배경이 너무 길면 핵심 지시가 묻히고, 관련 없는 정보가 판단을 흐릴 수 있습니다.

예를 들어 다음 프롬프트는 맥락이 부족합니다.

이 문서를 자연스럽게 고쳐 주세요.

문서가 강의 자료인지, 블로그 글인지, 고객 안내문인지 알 수 없습니다. 독자가 초보자인지 실무자인지도 알 수 없습니다. 따라서 모델은 어떤 문체와 설명 밀도를 선택해야 하는지 추측해야 합니다.

맥락을 보강하면 다음과 같습니다.

이 문서는 AI 에이전트를 처음 사용하는 개발자를 위한 강의 자료입니다.
독자는 프롬프트 엔지니어링이라는 말은 들어 봤지만, Codex 같은 에이전트에게
실제 작업을 맡겨 본 경험은 많지 않습니다.
기존 문체는 설명형 한국어이며, 문장은 "~입니다" 체로 정리해 주세요.

이렇게 쓰면 모델은 문서를 단순히 매끄럽게 다듬는 데서 멈추지 않고, 독자의 수준과 강의 자료라는 목적에 맞춰 설명을 조절할 수 있습니다.

작업 / 지시

작업은 모델이 실제로 수행해야 하는 핵심 행동입니다. 설명해 달라는 것인지, 코드를 수정해 달라는 것인지, 원인을 조사해 달라는 것인지, 비교표를 만들어 달라는 것인지가 분명해야 합니다.

작업 지시는 가능하면 동사로 끝나야 합니다. "분석", "정리", "개선"처럼 명사만 던지면 모델은 어떤 행동을 해야 하는지 넓게 해석합니다. 반면 "원인을 찾아 주세요", "파일을 수정해 주세요", "세 가지 대안을 비교해 주세요", "테스트 실패를 재현하고 고쳐 주세요"처럼 쓰면 수행할 행동이 분명해집니다.

복잡한 작업에서는 순서도 중요합니다. 먼저 조사하고, 그다음 수정하고, 마지막에 검증해야 한다면 그 순서를 알려주는 것이 좋습니다. 에이전트는 스스로 계획을 세울 수 있지만, 사용자가 원하는 진행 방식이 있다면 프롬프트에 포함해야 합니다.

약한 지시는 다음과 같습니다.

회의록을 정리해 주세요.

이 문장은 너무 넓습니다. 핵심 내용을 요약하라는 뜻일 수도 있고, 결정 사항만 뽑으라는 뜻일 수도 있고, 담당자별 할 일을 정리하라는 뜻일 수도 있습니다.

더 나은 지시는 다음과 같습니다.

아래 회의 메모에서 결정 사항, 담당자별 할 일, 마감일을 구분해 정리해 주세요.
누가 맡기로 했는지 불분명한 항목은 "확인 필요"로 표시하고,
마지막에는 다음 회의 전에 확인해야 할 질문을 따로 모아 주세요.

이 프롬프트는 정리 기준, 불확실한 항목의 처리 방식, 마지막에 포함할 내용을 함께 지정합니다. 모델이 어디서 시작하고 어디서 멈춰야 하는지 훨씬 명확합니다.

제약 조건 / 규칙

제약은 모델이 작업 중 지켜야 하는 경계입니다. 예산을 넘기면 안 된다거나, 원래의 사실관계를 바꾸면 안 된다거나, 개인정보를 포함하지 말아야 한다거나, 기존 문체를 유지해야 한다는 요구가 여기에 들어갑니다.

제약이 없으면 에이전트는 목표를 달성하기 위해 생각보다 넓은 변경을 할 수 있습니다. 안내문을 짧게 만들면서 중요한 날짜를 빼거나, 표현을 부드럽게 고치면서 원래 약속과 다른 의미로 바꾸거나, 요약을 하면서 반드시 남겨야 할 이름과 숫자를 생략할 수 있습니다. 상황에 따라 이런 변경이 도움이 될 수도 있습니다. 하지만 사용자가 원하지 않는 범위라면 미리 막아야 합니다.

좋은 제약은 금지 사항을 적는 데서 끝나지 않습니다. 무엇을 유지해야 하는지, 어떤 선택을 우선해야 하는지도 알려줍니다. 예를 들어 "너무 화려하게 만들지 마세요"보다 "기존 안내문보다 길이는 줄이되, 날짜, 장소, 준비물은 그대로 유지해 주세요"가 더 실행 가능한 규칙입니다.

행사 안내문을 고칠 때는 다음처럼 쓸 수 있습니다.

날짜, 장소, 참가비, 준비물은 원문과 다르게 바꾸지 말아 주세요.
문장은 더 짧게 다듬되, 반드시 알아야 할 정보는 삭제하지 말아 주세요.
초등학생 학부모가 읽는 안내문이므로 딱딱한 행정 문체는 피해 주세요.

요리법을 바꿀 때는 다음처럼 쓸 수 있습니다.

매운맛을 줄이되 조리 시간은 30분을 넘기지 않게 해 주세요.
새로운 조리 도구가 필요한 방법은 쓰지 말고, 프라이팬 하나로 가능한 방식만 제안해 주세요.
알레르기가 있을 수 있으니 견과류를 추가하지 말아 주세요.

제약도 과하면 문제가 됩니다. 서로 충돌하는 규칙이 많으면 모델은 무엇을 우선해야 하는지 판단하기 어려워집니다. 중요한 제약을 먼저 쓰고, 덜 중요한 취향은 작업 후 검토에서 조정하는 편이 안정적입니다.

출력 형식

출력 형식은 작업 결과를 어떤 형태로 받을지 지정하는 부분입니다. 사람이 읽을 설명인지, 표인지, 체크리스트인지, 문자 메시지 초안인지, 스프레드시트에 옮길 데이터인지에 따라 모델의 답변 방식이 달라집니다.

에이전트에게 작업을 맡길 때는 "최종 답변"과 "작업 산출물"을 구분해야 합니다. 예를 들어 독서 기록을 정리해 달라는 요청에서는 실제 산출물이 정리된 독서 목록이고, 최종 답변은 어떤 기준으로 묶었는지 알려주는 짧은 설명입니다. 반대로 의견을 묻는 질문이라면 최종 답변 자체가 산출물입니다.

출력이 사람이 읽는 보고라면 형식은 간단해도 됩니다.

마지막에는 책을 어떤 기준으로 분류했는지와 추천 순서를 어떻게 정했는지만 짧게 알려 주세요.

출력이 스프레드시트에 옮길 데이터라면 더 엄격해야 합니다.

결과는 표로만 작성해 주세요.
열은 제목, 저자, 분야, 평점, 한 줄 메모 순서로 만들어 주세요.
평점은 1점부터 5점까지의 숫자로만 적어 주세요.
한 줄 메모는 한 문장으로만 작성해 주세요.

형식을 명확히 지정하면 나중에 다시 정리하기 쉬워집니다. 특히 스프레드시트에 붙여 넣거나 여러 사람의 답변을 모아 비교해야 할 때는 출력 형식이 작업의 일부라고 보는 것이 좋습니다.

예시 (Few-Shot Learning)

예시는 모델에게 원하는 판단의 기준을 보여주는 방법입니다. 설명으로만 규칙을 적는 것보다, 입력과 출력의 짝을 몇 개 보여주면 모델이 문체, 세부 수준, 예외 처리 방식을 더 잘 따라갑니다.

예시는 특히 변환 작업에서 효과적입니다. 제목을 바꾸거나, 문장을 요약하거나, 상품 후기를 분류하거나, 짧은 메모를 공손한 문장으로 바꾸는 작업이 여기에 해당합니다.

예시를 넣을 때는 양보다 품질이 중요합니다. 서로 다른 상황을 대표하는 예시 두세 개가, 비슷한 예시 열 개보다 더 유용할 수 있습니다. 예시가 너무 많으면 실제 요청보다 예시가 더 큰 비중을 차지해서 모델이 핵심 작업을 놓칠 수 있습니다.

다음은 중고거래 메시지를 더 공손하게 바꾸기 위한 간단한 예시입니다.

입력: 오늘 바로 가지러 갈게요. 좀 깎아 주세요.

출력: 오늘 방문해서 가져갈 수 있습니다. 혹시 가격 조정이 가능할까요?

이 예시는 직접적인 표현을 더 부드럽고 공손한 문장으로 바꾸라는 기준을 보여줍니다. 규칙을 더 명확히 하려면 예시를 더 추가할 수 있습니다.

입력: 사진보다 상태 안 좋으면 안 살 거예요.

출력: 사진과 실제 상태가 많이 다를 경우에는 구매가 어려울 수 있습니다.

이제 모델은 말을 길게 늘리는 데서 그치지 않고, 원래 의미를 유지하면서 상대가 불쾌하게 느낄 수 있는 표현을 줄여야 한다는 점을 이해할 수 있습니다.