software

만약 당신의 agent가 user data를 삭제할 수 있다면, 당신의 prompt는 prompt가 아니라 contract이다

발행: (2025년 12월 27일 오전 07:46 GMT+9)
8 분 소요
원문: Dev.to

Source: Dev.to

위 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

좋은 프롬프트 설계가 여전히 무너지는 경우

제가 아는 대부분의 AI 엔지니어들은 이미 “당연한” 작업들을 수행하고 있습니다:

  • 시스템 지시와 사용자 지시를 구분하기
  • 출력 제한 (JSON / 스키마)
  • 검증자 추가하기
  • 자유 텍스트 추측 대신 도구 사용하기
  • 안전성 문구 포함하기

그럼에도 에이전트는 불공정하게 느껴지는 방식으로 여전히 실패합니다:

  • 범위가 점점 확대됨 (“당신에 대한 모든 정보”가 시간이 지남에 따라 늘어남)
  • 도구 출력이 의도하지 않은 필드를 누출함
  • “도움이 되는” 행동이 경계 상황에서 정책을 무시함
  • 삭제가 너무 일찍 혹은 너무 자신 있게 계획됨
  • 문제가 발생했을 때 감사 가능성이 결여됨

프롬프트가 나쁘기 때문이 아닙니다. 지시가 실행 가능한 계약서처럼 작성되지 않았기 때문입니다. DSAR은 그 격차가 즉시 드러나는 영역입니다.

모든 것을 바꾸는 디자인 움직임

Instruction Contract 작성 (행동에 대한 API 사양과 같은)
아래는 제가 실제로 사용하는 디자인 프로세스이며, 예시가 포함되어 있습니다.

1. Non‑negotiables (절대 양보할 수 없는 제약, 분위기가 아니라)

이것은 “안전하게 하라”는 것이 아닙니다.

예시 제약

  • 사용자가 타인에 대한 데이터를 요청하면 → 거부.
  • 원시 로그를 절대 내보내지 않으며; 편집된 요약만 반환.
  • 신원 확인 및 명시적인 확인 토큰이 제공되지 않으면 삭제를 절대 실행하지 않음.

이러한 제약은 해석 레이어를 없애고, 드리프트가 발생하는 여지를 차단합니다.

2. Scope definition (범위 확장을 방지, 단순 명확성 이상의 것)

대부분의 팀은 한 번만 범위를 정의하지만, 에이전트가 “더 능력 있어 보인다”고 생각하면 범위가 늘어납니다.
범위를 다음과 같이 정의합니다:

  • 포함되는 것
  • 제외되는 것
  • 모호할 때 행동 규칙

예시 범위

포함

  • 프로필 필드 (이름, 이메일, 전화)
  • 주문 및 청구서
  • 지원 티켓 / 채팅 기록
  • 마케팅 선호도
  • 수집된 경우 디바이스 식별자

제외

  • 내부 직원 메모
  • 집계된 분석 대시보드
  • 다른 사용자의 식별자를 포함한 레코드
  • 시스템 내부를 노출하는 내부 보안 로그

모호성 규칙 예시: 시스템이 혼합 사용자 레코드를 반환하면 → 중단하고 에스컬레이션.

이 규칙은 에이전트가 “임무를 확장”하는 것을 방지합니다.

3. Tool boundaries (도구가 요청보다 더 많은 정보를 반환할 수 있음을 가정)

허용된 필드만 요청하더라도 도구가 추가 필드를 반환하는 경우가 많습니다.
계약서에 반드시 명시해야 할 내용:

  • 허용된 필드
  • 비허용 필드
  • 비허용 필드가 나타났을 때 수행할 작업

예시: CRM 정책

허용비허용
name, email, phone, created_at, last_loginnotes, internal_tags, fraud_flags

필수 행동: 비허용 필드가 나타나면 → 버리고 위반을 로그.

예시: 로그 정책

  • 카테고리 + 날짜 범위 + 편집된 스니펫만 반환
  • 원시 로그는 절대 반환하지 않음

도구 경계는 우발적인 유출과 “조용한 정책 위반”을 방지합니다.

4. Output shape (감사 가능성을 기본값으로, 선택 사항이 아니라)

대부분의 엔지니어는 출력 형식을 제한하지만, 진정한 승리는 감사 친화적으로 만드는 것입니다.

예시 출력 골격 (JSON)

{
  "identity_verification": {
    "method": "string",
    "confidence": 0.0,
    "matched_fields": ["field1", "field2"]
  },
  "data_found": [
    {
      "system": "string",
      "records_found": 0,
      "date_range": "YYYY‑MM‑DD to YYYY‑MM‑DD"
    }
  ],
  "redactions_applied": [
    {
      "field": "string",
      "reason": "string"
    }
  ],
  "deletion_plan": [
    {
      "item": "string",
      "dependencies": ["string"]
    }
  ],
  "user_summary": "Plain‑language summary of actions taken."
}

이제 에이전트는 검토 및 차이점을 비교할 수 있는 아티팩트를 생성합니다.

5. Stop rules (신뢰성을 확보하는 시점)

언제 중단할지 아는 것은 고급 프롬프트 디자인 기술입니다.

예시

  • 신원 신뢰도 < 0.9 → 중단; 추가 증명을 요청.
  • 일치하는 사용자 계정이 다수일 경우 → 중단; 에스컬레이션.
  • 삭제 요청이 있었지만 명시적인 확인 토큰이 없을 경우 → 중단; 사용자에게 확인 요청.
  • 요청자가 자신의 신원을 초과하는 범위로 요청하면 → 거부.

중단 규칙은 시스템이 “창의적으로” 행동하는 것을 방지합니다.

Why this is hard (and why it’s worth showing)

This isn’t prompt‑writing as copywriting. It’s prompt‑writing as system design:

  1. Policies → constraints
  2. Constraints → predictable behavior
  3. Predictable behavior → auditable output

That’s the difference between an “agent that looks smart” and an “agent you can trust.”

자동화해야 할 부분 (판단은 제거하지 않음)

생각은 인간이 해야 하지만 반복적인 골격은 자동화하지 않아도 됩니다.

자동화할 가치가 있는 것

  • 워크플로우별 instruction‑contract 템플릿 생성
  • 단계별 프롬프트 + 출력 스키마 생성
  • 도구 전반에 걸친 일관된 경계 규칙 적용
  • 버전 관리 + diff (“무엇이 바뀌었나요?”)
  • “골든 요청” 회귀 검사 실행

규칙은 여전히 당신이 정합니다. 자동화는 반복하면서 시스템을 일관되게 유지해 줍니다.

Back to Blog

관련 글

더 보기 »