프롬프트 엔지니어링

여섯 단계 파이프라인

프롬프트는 즉석에서 만들어지지 않습니다. 여섯 단계를 거치며 요청 주변의 모든 사실을 수집·정리·검증한 뒤에야 LLM 에 전달됩니다. 각 단계는 독립된 패키지로 구현되어 있고, 이전 단계의 출력이 다음 단계의 입력이 됩니다.

Stage 1 · 수집

요청이 Spring Security 필터 체인(Filter Chain)에 들어오면 AuthBridge 구현체가 헤더·세션·속성 등 다양한 출처에서 주체를 추출합니다. 추출된 정보는 세 종류의 증거 도장(Stamp) 으로 포장됩니다. 이 세 도장이 이후 모든 단계의 원천 입력입니다.

증거 품질 다섯 등급

모든 증거가 같은 신뢰도를 가지지는 않습니다. 고객이 명시적으로 보낸 신호가 가장 강하고, 플랫폼이 구조적으로 관찰한 신호가 그 다음, 런타임 연속성으로 추정한 신호는 약합니다. BridgeSemanticBoundaryPolicy 는 모든 수집 시점에 다음 다섯 등급 중 하나를 붙입니다.

Stage 2 · 가공

수집된 증거만으로는 LLM 이 이 사람이 평소와 다르게 행동하는지 판단할 수 없습니다. 2 단계는 세 종류의 구성요소가 원시 증거를 관찰 가능한 패턴으로 확장합니다.

Stage 3 · 정제

프롬프트 주입(Prompt Injection) · 필드 스푸핑 · 신호 위조는 LLM 기반 보안 시스템이 가장 경계해야 할 위협입니다. CanonicalSecurityContextHardener 는 모든 필드를 LLM 에 넘기기 전에 필드별 정규화 절차를 거칩니다.

Stage 4 · 표준화

3 단계를 거친 모든 정보는 CanonicalSecurityContext 라는 단일 표준 컨텍스트 모델로 집약됩니다. 현재 구현은 Lombok 기반의 클래스이며, hardener가 필드 정규화와 기본값 보정을 수행한 뒤 프롬프트 조립 단계에 전달합니다. 22 개 필드와 7 개 프로필이 정해진 자리에 담기므로, 이후 프롬프트 조립 단계는 어떤 필드가 어디 있는지 예측 가능합니다.

정보 완성도 네 단계

채워진 필드 수와 프로필 유무를 종합해 ContextCoverageEvaluator 가 완성도 등급을 매깁니다. 등급이 낮으면 LLM 에게 업무 패턴 기반 결론을 내리지 말라는 경고 문구가 자동 삽입됩니다.

Stage 5 · 조립

표준화된 컨텍스트는 이제 프롬프트가 됩니다. SecurityDecisionPromptSections 가 오케스트레이션하며, 2 개 시스템 섹션과 15 개 사용자 섹션(총 17 개 섹션 계획)을 렌더링합니다. 필드가 없으면 해당 빌더는 자기 섹션을 아예 출력하지 않습니다.

시스템 영역과 사용자 영역

17 개 섹션 계획

명시적 누락 지식

명시적 누락 지식(내부 섹션 키: EXPLICIT_MISSING_KNOWLEDGE)은 LLM 이 증거 공백을 확신으로 오해하지 않도록 만드는 P0 필수 품질 지표 섹션입니다. SecurityContextQualityUserSectionBuilder 가 PromptContextComposer.composeMissingKnowledgeSection() 을 호출해 만들며, 커버리지 공백이나 신뢰 프로필의 evidence caution 이 있을 때만 출력됩니다. 결핍 신호가 없으면 섹션을 비워 두며, 이는 누락이 아니라 “명시할 지식 공백 없음”을 의미합니다.

• 커버리지 공백 — missingCriticalFacts, remediationHints, confidenceWarnings 가 있으면 누락 지식 섹션을 생성합니다.
• 신뢰 한계 — ContextEvidenceLimitation, ContextTrustLimitation, ContextTrustWarning, ContextFieldCoverage, ContextFieldLimitation 을 별도 항목으로 노출합니다.
• 오탐 방지 — authorization effect 가 이미 해소된 경우 오래된 AUTHORIZATION_EFFECT 누락 경고는 출력하지 않습니다.
• Baseline 보강 — 개인/조직 baseline 이 희박하면 BaselineGapSupport 를 같은 섹션에 붙여 “증거 부족은 위험 또는 정상의 증거가 아니다”라는 제약을 전달합니다.
• 압축 보존 — compact budget 에서도 BaselineGapSupport, ConfidenceWarning, ContextEvidenceLimitation, ContextTrustLimitation, ContextTrustWarning 을 우선 보존합니다. 그래도 예산을 넘으면 요약/생략 내역을 compression ledger 에 남깁니다.

Stage 6 · 보정

LLM 이 응답을 돌려주면 끝이 아닙니다. 두 개의 안전장치가 순서대로 결과를 재조정합니다. 첫째는 자율성 제약, 둘째는 런타임 보정 입니다.

자율성 제약 (Autonomy Guardrail)

LLM 의 confidence 가 임계값 미만이거나 출력이 스키마를 벗어나면, PromptConfidenceGuardrail 이 최종 실행 액션을 더 안전한 상위 단계로 강제합니다. 제안 액션과 실행 액션이 분리 기록되어 감사 추적이 가능합니다.

런타임 보정 (Calibration)

제약이 적용되지 않은 결정은 SecurityDecisionCalibrationService 가 학습된 프로필로 미세 조정합니다. 과거 관찰 데이터에 근거해 신뢰도 가감과 액션 편향을 적용합니다.

• 시나리오 분류 — 현재 요청을 과거 유사 시나리오로 분류 (예: 낯선 위치 + 평소와 다른 리소스)
• 프로필 선택 — 최대 샘플 수와 운영자 검토가 완료된 프로필만 선택 (가장 강한 근거)
• 액션 편향 적용 — INCREASE_CHALLENGE · DECREASE_CHALLENGE · NONE 중 하나
• BLOCK 불변 보장 — BLOCK 액션은 어떤 편향으로도 변경 불가 (안전 원칙)
• 제약 우선 — 자율성 제약이 걸린 결정은 보정을 무시 (이중 개입 방지)

최종 결정 레코드

모든 단계를 통과한 뒤 만들어지는 SecurityDecision 은 단순히 ALLOW · BLOCK 한 값이 아닙니다. LLM 의 원시 판단, 정책 개입, 학습 보정이 모두 기록된 감사 가능한 레코드입니다.

사람과 Agent 의 프롬프트 차이

같은 파이프라인을 통과해도 주체 유형에 따라 프롬프트의 무게 중심이 달라집니다. 사람은 평소 행동 기준과의 편차가 핵심이고, Agent 는 허용된 목표 범위의 이탈이 핵심입니다.

관련 문서