[STUDYING] 2. Prompt 설계 및 Context Engineering

Prompt 설계 및 Context Engineering

좋은 LLM 활용은 질문을 그럴듯하게 쓰는 일에서 끝나지 않습니다. 모델이 수행할 과업, 사용할 근거, 지켜야 할 제약, 반환 형식, 검증과 승인 절차를 함께 설계해야 합니다. 이 기록은 Prompt Engineering → Context Engineering → Harness Engineering으로 확장되는 관점을 중심으로 정리합니다.

1. 생성형 AI와 Agent의 전환을 이해합니다

생성형 AI가 널리 쓰이면서 “답변하는 AI”에서 “근거를 탐색하고 도구를 사용하며 실행하는 AI Agent”로 관심이 이동하고 있습니다. 이는 모델이 더 긴 문장을 생성한다는 뜻만이 아닙니다. 검색, 요약, 추론, 도구 호출, 메모리, 형식 검증, 사람 승인처럼 모델 주변의 시스템을 함께 설계해야 한다는 뜻입니다.

기업 환경에서는 최신성, 내부 정책, 보안, 비용, 환각, 설명 가능성이 특히 중요합니다. 모델의 일반 지식만으로는 조직의 최신 규칙이나 특정 문서의 사실을 보장할 수 없습니다. 결과가 중요한 업무일수록 “모델이 알고 있을 것”이라는 가정보다 어떤 문서를 근거로 주고 어떤 규칙으로 결과를 검사할지를 먼저 정해야 합니다.

🧭

핵심 전환입니다. Prompt Engineering은 요청 문장을 설계하는 일이고, Context Engineering은 모델이 판단할 때 필요한 정보를 적절히 구성하는 일이며, Harness Engineering은 도구·검증·권한·실패 처리까지 포함해 AI가 안전하게 일하도록 만드는 일입니다.

 

2. LLM의 생성 원리와 한계입니다

LLM은 입력 문맥을 읽고 다음 토큰 후보의 확률 분포를 계산한 뒤 하나를 선택하여, 다시 다음 토큰을 예측하는 과정을 반복합니다. 토큰은 글자나 단어와 항상 일치하지 않는 텍스트 처리 단위입니다. 한국어·영어·숫자·기호는 서로 다른 방식으로 여러 토큰으로 나뉠 수 있으므로 글자 수만으로 비용이나 문맥 길이를 정확히 판단할 수 없습니다.

개념적으로 모델은 문맥 x_<t가 주어졌을 때 다음 토큰 x_t의 조건부 확률 P(x_t | x_<t)를 추정합니다. 자연스럽고 자신감 있는 문장이 사실 검증을 거쳤다는 보장은 없으며, 이것이 환각을 경계해야 하는 이유입니다. 대규모 학습 데이터와 파라미터 규모의 확장은 언어 패턴을 더 잘 다룰 수 있게 하지만, 출처 판별·최신성·내부 사실을 자동으로 보장하지 않습니다.

환각을 사실과 구분합니다

환각은 모델이 그럴듯하지만 근거 없거나 틀린 내용을 생성하는 현상입니다. 최신 정책, 수치, 인용, 법률·의료·금융 판단, 내부 운영 정보는 생성 결과만으로 확정하면 안 됩니다. 검증이 필요한 주장을 식별하고, 신뢰 가능한 원문·데이터·도구 결과를 제공하며, 근거 범위 밖이면 근거 부족으로 표시하도록 요청해야 합니다. 이후 수치·인용·링크·계산·정책 적용을 별도로 검증하고 실패 사례를 평가 세트에 남깁니다.

3. 토큰과 샘플링은 비용·속도·다양성을 함께 조절합니다

입력 토큰과 출력 토큰은 API 비용, 응답 지연, 문맥 창의 크기에 영향을 줍니다. 긴 문서를 전부 붙여 넣으면 필요한 지시가 묻히고 관련 없는 정보가 판단을 흔들 수 있습니다. 반대로 너무 적은 정보는 모델이 추측으로 빈칸을 채우게 합니다. 좋은 컨텍스트의 기준은 “많음”이 아니라 현재 과업에 충분하면서 관련성이 높은 최소 집합입니다.

 

출력 다양성은 Temperature, Top-k, Top-p, Min-p, 최대 출력 길이 같은 설정으로 조절합니다.

• Temperature입니다. 낮을수록 높은 확률 후보에 집중하는 경향이 있고, 높을수록 다양한 후보를 선택할 여지가 커집니다. 코드 생성·추출·정형 JSON에는 낮은 다양성을 우선 검토하고, 발상 업무에는 실험적으로 높일 수 있습니다.
• Top-k입니다. 확률이 높은 상위 k개 후보 안에서만 다음 토큰을 고르게 제한합니다.
• Top-p입니다. 확률이 높은 후보를 누적하여 정한 확률 질량 p 안에서 선택합니다.
• Min-p입니다. 최고 확률 후보와 비교해 지나치게 낮은 후보를 제외하는 방식으로 사용할 수 있습니다.
• Max tokens입니다. 출력 길이의 상한입니다. 너무 작으면 답이 잘리고, 너무 크면 비용·지연·장황함이 늘 수 있습니다.

Reasoning effort와 verbosity는 내부 추론 노력과 표현의 상세도를 구분하는 설정입니다. 긴 추론이나 긴 답변이 항상 더 정확하다는 뜻은 아니므로 과업별 평가가 필요합니다.

같은 업무를 비교할 때는 모델명, 시스템 지시, 입력 문서, 샘플링 값, 도구 결과, 평가 기준을 함께 고정해야 합니다.

---

4. Prompt Engineering은 작업 명세를 작성하는 일입니다

프롬프트는 모델에 주는 텍스트 입력이지만, 실무에서는 자연어로 작성한 작업 명세에 가깝습니다. 시스템 프롬프트는 모델이 따를 초기 규칙과 역할을 정하고, 사용자 프롬프트는 현재 과업과 자료를 제공합니다. 좋은 프롬프트는 모호한 수식어보다 수행 동사, 입력 범위, 실패 시 행동, 출력 계약을 명시합니다.

RICE 프레임워크를 적용합니다

요소	설계 질문	적용 예시
Role입니다.	어떤 관점·전문성·책임 범위로 답해야 하는가입니다.	“당신은 보안 검토를 돕는 Python 코드 리뷰어입니다.”라고 정합니다.
Instruction입니다.	무엇을 수행하고 무엇을 하지 말아야 하는가입니다.	“취약점 후보를 심각도 순으로 분류하고 근거 없는 문제는 만들지 마세요.”라고 정합니다.
Context입니다.	어떤 정책·입력 데이터·제약·도구 결과를 기준으로 판단하는가입니다.	Python 버전, 허용 라이브러리, 코드 조각, 보안 정책을 제공합니다.
Examples입니다.	원하는 판단 기준과 출력 형식은 무엇인가입니다.	좋은 JSON 예시와 근거 부족 반환 예시를 함께 제공합니다.

 

Role은 장식이 아니라 문제를 보는 관점과 책임 범위를 정하는 장치입니다. Instruction은 목표를 구체적 작업으로 쪼개야 합니다. Context는 판단에 필요한 사실과 제약을 제공해야 하며, Examples는 설명만으로 전달하기 어려운 형식·분류·톤을 보여 줍니다. 네 요소가 모두 길어야 좋은 것이 아니라 빠진 계약이 없는지가 중요합니다.

[Role]
당신은 Python 3.11 코드의 입력 검증을 검토하는 리뷰어입니다.

[Instruction]
아래 함수에서 예외 처리, 정규표현식, 비밀정보 노출 위험을 검토합니다.
문제마다 심각도, 코드 위치, 근거, 최소 수정안을 제시합니다.
근거가 없으면 문제라고 단정하지 않습니다.

[Context]
외부 라이브러리는 추가할 수 없고, 함수는 공개 API에서 호출됩니다.

[Output]
Markdown 표로 반환합니다. 열은 severity, location, evidence, recommendation입니다.

5. Policy·Style·Constraint·Format으로 출력 계약을 만듭니다

RICE를 보완하는 요소로 Policy, Style, Constraint와 Format 또는 Structure를 함께 설계합니다. Policy에는 추측 금지, 출처 없는 사실의 처리, 민감 정보 금지 같은 행동 규칙을 둡니다. Style에는 정중함, 전문성, 분량, 독자 수준을 둡니다. Constraint에는 항목 수, 금지 표현, 사용 가능한 자료, 시간 범위를 둡니다. Format에는 Markdown 표, JSON, XML, 목록 같은 반환 형식을 둡니다.

 

Markdown은 제목, 목록, 표, 코드 블록으로 문서 구조를 읽기 쉽게 표현하는 경량 마크업입니다. 사람이 검토할 결과에는 Markdown이 유용하고, 후속 자동 처리에는 JSON 스키마가 유용합니다. 다만 JSON을 요구했다고 해서 자동으로 유효한 JSON이 보장되지는 않으므로 파싱·스키마 검증·재시도 또는 사람 검토가 필요합니다.

{
  "decisions": [
    {
      "decision": "string",
      "owner": "string or null",
      "due_date": "YYYY-MM-DD or null",
      "evidence": "원문 인용 위치"
    }
  ],
  "unknowns": ["근거가 부족한 항목"]
}

출력 계약에는 필수 필드, 허용 값, 빈 값의 표현 방식, 항목 수, 날짜 형식, 근거 필드를 포함합니다.

6. 대표 프롬프팅 기법을 목적에 맞게 선택합니다

• Zero-shot과 Few-shot입니다. Zero-shot은 예시 없이 지시만 주는 방식입니다. Few-shot은 입력과 원하는 출력을 보여 주어 형식과 분류 기준을 전달합니다. 예시는 정상·경계·근거 부족 사례를 함께 포함해야 하며, 잘못된 예시도 모델에 학습 신호가 될 수 있습니다.
• Chain of Thought입니다. 복잡한 문제에서 중간 추론을 유도해 단계적 해결을 돕습니다. 그러나 길게 설명된 추론이 정답의 증거는 아니며, 계산·검색·코드 실행·출처 확인이 필요한 경우 외부 검증 결과를 우선합니다.
• Step-back Prompting입니다. 세부 답변 전 상위 원칙, 정의, 제약을 먼저 확인하게 합니다. 시장 진입 전략이라면 시장 규모 판단 기준, 목표 고객 정의, 경쟁 비교 기준, 데이터 한계를 먼저 정리하게 할 수 있습니다.
• Self-Consistency입니다. 여러 후보 답이나 추론 경로를 비교·집계하는 발상입니다. 여러 번 같은 오류를 생성한다고 진실이 되지는 않으며 비용과 지연도 증가하므로 독립 근거와 채점 기준이 필요합니다.
• Devil’s Advocate Prompting입니다. 반대 근거, 실패 가정, 놓친 위험을 의도적으로 찾습니다. 이는 반대를 위한 반대가 아니라 확증 편향을 줄이고 검증 실험을 설계하는 방법입니다.
• Meta Prompting입니다. 프롬프트 초안의 모호한 표현, 누락된 입력, 충돌하는 제약, 평가 불가능한 조건을 모델에게 점검하게 합니다. 개선안도 사람이 목표와 보안 규칙에 맞는지 검토해야 합니다.

일부 연구 사례는 친절한 표현, 감정적 표현, Temperature와 환각, CoT 성능의 관계를 탐색합니다. 이는 말투와 설정이 출력에 영향을 줄 수 있음을 보여 주는 탐색 자료이며, 특정 문구가 모든 모델·언어·업무에서 성능을 높인다고 일반화해서는 안 됩니다.

---

7. Context Engineering은 정보를 어떻게 조립할지 설계합니다

Context Engineering은 시스템 지시, 사용자 요청, 메모리, 대화 이력, 외부 지식, 도구 결과, few-shot 예시, 출력 형식을 선택·정렬·갱신하는 일입니다. 좋은 컨텍스트의 기준은 “정보를 많이 넣는 것”이 아니라 올바른 결정을 위한 최소 충분 정보를 적절한 순서로 제공하는 것입니다.

구성 요소	담는 내용	설계 주의사항입니다.
System Prompt입니다.	역할, 권한, 금지 행동, 출력 원칙입니다.	짧고 우선순위가 분명해야 하며 사용자 입력으로 덮어쓰이지 않게 설계합니다.
메모리·히스토리입니다.	확정된 선호, 과거 결정, 미해결 과업입니다.	오래된 사실과 추측을 장기 기억으로 저장하지 않으며 갱신 기준을 둡니다.
도구·외부 지식입니다.	RAG 검색 문서, API 응답, 파일, 데이터베이스 결과입니다.	출처, 시점, 권한, 검색 실패 여부를 보존하고 관련 없는 결과를 제거합니다.
Few-shot·포맷입니다.	예시, 스키마, 표·JSON·Markdown 계약입니다.	예시가 정책보다 우선되는 것처럼 보이지 않게 하고 스키마를 후속 검증합니다.

RAG는 외부 문서를 검색해 관련 조각을 컨텍스트에 넣는 접근입니다. 품질은 모델만으로 결정되지 않습니다. 문서 수집과 정제, 청크 분할, 메타데이터, 검색 질의, 재순위화, 인용 표시, 접근 권한, 최신성, 결과가 없을 때의 처리 모두가 결과를 좌우합니다. 검색 결과가 없거나 서로 충돌하면 모델이 억지로 결론을 만들지 않도록 근거 부족 또는 상충하는 근거를 반환하게 합니다.

 

긴 대화에서는 이전 대화를 요약하거나 폐기하고, 새 도구 결과를 추가하며, 현재 단계에 맞지 않는 정보를 제거하는 변환이 필요합니다. 이때 요약본이 원문 사실을 바꾸지 않았는지, 중요한 제약이 빠지지 않았는지 확인해야 합니다.

---

8. Harness Engineering은 AI가 일하는 안전장치입니다

하니스는 AI 시스템이 올바른 방향에서 일하도록 하는 주변 구조입니다. AI Agent가 계획하고 도구를 선택할 수 있어도 권한 확인, 도구 입력 검증, 실행 결과 검사, 재시도 제한, 사람 승인, 감사 로그가 없다면 위험한 행동이나 조용한 실패가 생길 수 있습니다.

하니스는 다음 질문에 답해야 합니다.

• 모델이 어떤 도구를 언제 사용할 수 있는가입니다.
• 도구 호출의 입력과 결과는 어떻게 검증하는가입니다.
• 검색 실패, 시간 초과, 빈 결과, 충돌 근거는 어떻게 처리하는가입니다.
• 어떤 행동은 자동 실행할 수 있고, 어떤 행동은 사람 승인이 필요한가입니다.
• 무엇을 로그로 남기고 실패 사례를 어떻게 평가·개선하는가입니다.

적용할 때는 법적 책임, 연결된 시스템의 기계적 계층, 점진적 공개를 고려합니다. 모델이 데이터베이스·배포·결제 같은 실제 시스템에 닿을수록 입력 검증, 최소 권한, 되돌림 절차가 필요합니다. 처음부터 거대한 규칙을 전부 주입하기보다 과업 단계에 필요한 지침·도구·문서를 순서대로 제공해 문맥 과부하를 줄입니다.

ai-harness/
├── AGENTS.md                 # 목표, 금지 행동, 작업 순서입니다.
├── docs/
│   ├── source_rules.md        # 허용 출처, 인용, 최신성 규칙입니다.
│   ├── style_guide.md         # 문체와 출력 형식 규칙입니다.
│   └── review_checklist.md    # 제출 전 검토 항목입니다.
├── templates/                 # 반복 산출물의 계약입니다.
├── tools/                     # 제한된 자동화 도구입니다.
├── outputs/                   # 버전이 붙은 산출물입니다.
└── logs/                      # 검색·출처·수정 이력입니다.

이 구조의 목적은 파일을 많이 만드는 것이 아니라 모델과 사람이 같은 규칙·근거·검토 기준을 참조하고, 결과가 왜 그렇게 나왔는지 추적 가능하게 만드는 것입니다.

---

9. 검증 가능한 AI 작업 흐름입니다

1. 과업을 정의합니다. 사용자, 산출물, 성공 기준, 시간·비용, 실패 시 행동을 적습니다.
2. 근거를 선별합니다. 원문·데이터·도구 결과의 출처, 날짜, 권한, 관련성을 확인합니다.
3. 요청을 계약으로 작성합니다. RICE와 Policy·Style·Constraint·Format을 사용해 역할, 행동, 제약, 출력 스키마를 명시합니다.
4. 도구 권한을 제한합니다. 읽기·쓰기·외부 전송·배포·결제 행동을 분리하고 위험한 행동에는 승인을 둡니다.
5. 출력을 검증합니다. JSON 스키마, 필수 필드, 인용 존재, 숫자 계산, 코드 테스트, 금지 표현을 프로그램 또는 체크리스트로 검사합니다.
6. 사람이 판단합니다. 고위험 결정, 정책 해석, 외부 발송, 고객 영향 행동은 책임자가 최종 승인합니다.
7. 실패를 자산화합니다. 잘못된 답, 검색 실패, 형식 오류, 거부 사례를 평가 세트와 로그에 남겨 다음 버전을 개선합니다.

• AI 산출물 제출 전 점검 목록입니다.
  • [ ] 과업의 입력·출력·성공 기준이 명시되어 있습니다.
  • [ ] 사실 주장마다 확인 가능한 근거 또는 근거 부족 표시가 있습니다.
  • [ ] 컨텍스트에 비밀값, 개인정보, 불필요한 내부 정보가 포함되지 않았습니다.
  • [ ] 출력 형식이 파싱 또는 사람 검토 기준에 맞습니다.
  • [ ] 실패·빈 검색 결과·충돌 근거의 처리 방식이 정의되어 있습니다.
  • [ ] 위험한 외부 행동에 사람 승인 또는 최소 권한이 적용되어 있습니다.

10. 학습 정리

프롬프트는 모델에게 일을 시키는 문장이고, 컨텍스트는 올바른 판단에 필요한 정보 환경이며, 하니스는 그 판단이 안전하고 검증 가능하게 행동으로 이어지게 하는 운영 구조입니다. 좋은 AI 시스템은 화려한 한 번의 답보다 근거가 있는 입력, 명시된 출력 계약, 제한된 권한, 자동·수동 검증, 실패를 학습하는 피드백 루프를 갖춥니다. 이 관점으로 설계하면 모델의 능력과 한계를 함께 다루면서 재현 가능한 업무 흐름을 만들 수 있습니다.