04. 좋은 프롬프트의 공통 속성

세 제공자가 같은 말을 한다

Anthropic, OpenAI, Google의 공식 프롬프팅 가이드를 나란히 놓고 보면, 표현은 달라도 권하는 바가 놀랍도록 겹칩니다. 모델 구조나 브랜드가 달라도, 2장에서 본 "다음 토큰 예측 + 컨텍스트 의존 + 유한한 attention"이라는 토대가 같기 때문입니다. 그래서 특정 모델에 종속되지 않는 공통 속성을 먼저 익히면, 어떤 모델을 쓰든 출발점이 됩니다.

이 장은 그 공통분모를 다섯 가지로 정리합니다. 각각은 2부에서 본격적인 기법으로 펼쳐집니다. 여기서는 "왜 이게 좋은가"를 직관과 연결하는 데 집중합니다.

속성 1: 명확하고 구체적이다

가장 자주, 가장 강하게 반복되는 조언입니다. 모호함을 줄이고, 무엇을·누구를 위해·어떤 형식으로 원하는지를 분명히 합니다.

나쁜 예 ❌                    좋은 예 ✅
"마케팅 글 써줘"        →    "친환경 텀블러 신제품의 인스타그램 캡션을
                              써줘. 2030 직장인 대상, 3문장 이내,
                              마지막에 행동 유도 문구 1개 포함."

왜 나아졌나: 주제·청자·길이·형식·필수 요소를 모두 명시했습니다. 2장의 "컨텍스트가 전부"에 따라, 머릿속에만 있던 정보를 모델이 볼 수 있는 곳으로 옮긴 것입니다.

⚠️ 흔한 실수·미신: "구체적 = 길게"가 아닙니다. 불필요한 미사여구로 길어지면 핵심이 묻혀 오히려 나빠집니다. 구체성은 정보의 밀도이지 글자 수가 아닙니다. 한 제공자는 최신 모델에 "정확하고 직접적으로, 불필요하거나 과도하게 설득적인 표현을 피하라"고 권합니다.

속성 2: 충분한 맥락을 제공한다

모델은 당신의 배경을 모릅니다(2장 컨텍스트 의존). 그러니 답에 필요한 정보는 프롬프트 안에 명시적으로 넣어야 합니다. 특히 모델의 학습 시점 이후이거나 비공개인 정보(회사 내부 규정, 최신 데이터, 특정 문서 내용)는 반드시 직접 제공해야 합니다.

나쁜 예 ❌                          좋은 예 ✅
"환불해줘도 되는지 답변 써줘"   →    "다음 환불 규정에 근거해 고객 답변을 써줘:
                                     [규정 3줄 붙여넣기]
                                     고객 상황: 구매 후 20일, 미개봉."

왜 나아졌나: 판단 기준(규정)과 사실(상황)을 함께 줬습니다. 이게 없으면 모델은 그럴듯하지만 틀린 규정을 "지어낼" 수 있습니다(환각, 4부).

💡 팁: "근거가 될 자료가 있으면, 모델이 추론으로 메우게 두지 말고 직접 주라"는 것이 여러 가이드의 공통 권고입니다. 답의 최종 형태에 가까운 자료일수록 모델이 할 일이 줄고, 오류 여지도 줍니다.

속성 3: 구조가 있다

지시·맥락·자료·예시가 섞이면 모델이 경계를 헷갈립니다. 구분자(delimiter)나 일관된 구조로 "여기는 지시, 여기는 자료"를 분명히 하면 파싱이 쉬워집니다. 세 제공자 모두 일관된 구분자(XML 스타일 태그나 Markdown 제목 등) 사용을 권하며, 중요한 것은 한 형식을 골라 일관되게 쓰는 것이라고 강조합니다.

나쁜 예 ❌
"아래 후기를 긍정/부정으로 분류해줘 배송이 느렸지만 품질은 좋았어요"
  → 어디까지가 지시고 어디부터가 후기인지 모호

좋은 예 ✅
다음 후기를 긍정/부정/중립으로 분류해줘.

<후기>
배송이 느렸지만 품질은 좋았어요
</후기>

왜 나아졌나: 분류 대상(후기)을 태그로 감싸 지시와 분리했습니다. 2장의 "다음 토큰 예측"에서, 명확한 경계는 모델이 각 부분의 역할을 헷갈리지 않게 합니다.

⚠️ 흔한 실수·미신: 구분자는 형식을 섞을 때 오히려 해롭습니다. XML 태그와 Markdown 제목과 따옴표를 한 프롬프트에서 중구난방으로 쓰면 일관성이 깨집니다. 하나를 골라 끝까지 쓰세요.

속성 4: 출력 기대치가 분명하다

원하는 결과의 형식·길이·톤·범위를 미리 정해주면 재현성과 활용도가 올라갑니다. 특히 결과를 다른 곳에 붙이거나(표·목록·JSON), 여러 출력을 비교해야 할 때 중요합니다.

나쁜 예 ❌                    좋은 예 ✅
"장단점 알려줘"          →    "장점 3개, 단점 3개를 각각 한 문장으로.
                              표로, 열은 [항목 | 설명]."

왜 나아졌나: 개수·길이·형식을 못박아 출력이 들쭉날쭉해지는 것(2장 확률성)을 줄였습니다.

💡 팁: 기본적으로 간결하게 답하는 최신 모델이 늘고 있습니다. 더 길거나 대화적인 답을 원하면 명시적으로 요청해야 합니다. "기본값이 간결"인 모델에 "자세히 설명해줘"를 빠뜨리면 기대보다 짧은 답을 받을 수 있습니다.

속성 5: 반복으로 다듬어진다

좋은 프롬프트는 한 번에 완성되지 않습니다. 써보고 → 결과의 부족한 점을 보고 → 그 부분을 겨냥해 고치는 반복이 본질입니다. 세 제공자 모두 "프롬프트 엔지니어링은 반복적·실험적 과정"이라고 입을 모읍니다.

flowchart LR
    draft["초안 작성"] --> run["실행"]
    run --> check["결과 점검<br/>무엇이 부족한가"]
    check --> fix["그 부분만 겨냥해 수정"]
    fix --> run
    check -->|충분| done["완성"]

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class draft,run,check,fix step
    class done good

🧪 직접 검증법: 프롬프트를 고칠 때는 한 번에 하나만 바꾸세요. 여러 곳을 동시에 바꾸면 무엇이 효과를 냈는지 알 수 없습니다. 변수를 하나씩 통제하는 것이 4부에서 다룰 "평가"의 기초이기도 합니다.

🔧 개발자 노트: 반복을 체계화하면 곧 평가(eval)가 됩니다. 대표 입력들을 고정해 두고, 프롬프트를 바꿀 때마다 같은 입력에 돌려 결과를 비교하면 "느낌"이 아니라 "측정"으로 개선할 수 있습니다. 프로덕션에서는 프롬프트도 코드처럼 버전 관리·테스트하라는 것이 공통 권고입니다(6부). 또한 프로덕션 앱은 특정 모델 스냅샷에 고정해 두는 것이 권장되는데, 같은 모델군이라도 버전이 바뀌면 동작이 달라질 수 있기 때문입니다.

다섯 속성 한눈에 — 체크리스트

프롬프트를 쓰고 나서 이 다섯 가지를 스스로 물어보세요.

📌 핵심: 이 다섯은 외울 규칙이 아니라, 2장의 직관(컨텍스트 의존·확률성·유한한 attention)에서 자연히 따라 나오는 결과입니다. 직관을 가지면 체크리스트는 그저 그것을 떠올리는 도구가 됩니다.

한 가지 단서: 공통 속성도 "정도"는 모델마다 다르다

다섯 속성은 방향으로서 보편적이지만, 얼마나·어떻게 적용할지는 모델마다 다릅니다. 예를 들어 어떤 최신 모델은 의도를 잘 추론해 짧은 프롬프트로 충분하고, 과한 지시가 오히려 방해가 됩니다. 반대로 어떤 모델·작업에서는 더 명시적인 구조가 도움이 됩니다.

⚠️ 흔한 실수·미신: "Gemini용 프롬프트는 평균 21단어가 최적"처럼 떠도는 수치들이 있습니다. 이런 것은 대략의 가이드라인이지 법칙이 아닙니다. 복잡한 요청은 당연히 더 길어야 하고, 최적값은 작업마다 다릅니다. 출처가 있는 수치라도 "일반 지침"과 "보편 법칙"을 구분해 받아들이세요.

🧪 직접 검증법: 평소 쓰는 모델에, 같은 작업을 (a) 아주 간결한 프롬프트와 (b) 구조를 갖춘 자세한 프롬프트로 각각 줘보세요. 어느 쪽이 더 나은지는 모델·작업마다 다릅니다. 이 안내서의 모든 조언은 당신의 검증 앞에서 가설일 뿐입니다.

이 장에서 배운 것

• 좋은 프롬프트의 공통 속성은 다섯 가지다: 명확·구체, 충분한 맥락, 구조, 분명한 출력 기대치, 반복적 개선.
• 이 속성들은 제공자가 달라도 겹치는데, 모델의 토대(토큰 예측·컨텍스트 의존·유한한 attention)가 같기 때문이다.
• 구체성은 글자 수가 아니라 정보 밀도이고, 구조는 형식을 일관되게 쓸 때만 도움이 된다.
• 최신 모델은 기본 간결한 경향이 있어, 자세한 답이 필요하면 명시적으로 요청해야 한다.
• 다섯 속성은 방향으로선 보편적이지만, 적용의 정도·방식은 모델마다 다르므로 떠도는 수치는 가이드라인으로만 받아들이고 직접 검증한다.

✍️ 확인 문제

1. 다섯 속성 중, 다음 프롬프트가 가장 크게 위반한 것 두 가지를 고르고 이유를 적어보세요.

> "우리 서비스에 대해 좋은 글 좀 많이 써줘."

1. "구체적으로 쓰라"는 조언을 "무조건 길게 쓰라"로 오해하면 어떤 문제가 생기는지, 2장의 attention 개념과 연결해 설명해보세요.

1. (실습) 아래 프롬프트를 다섯 속성 체크리스트에 따라 개선하고, 각 속성을 어떻게 반영했는지 표로 정리해보세요.

> "이 고객 후기들 분석해줘. [후기 10개 붙여넣음]"

다음 → 2부 · 핵심 프롬프트 기법 (작성 예정)
이전 ← 03. 프롬프트 vs 컨텍스트 엔지니어링 · 목차