name: deploy-production
description: 애플리케이션을 검증하고 프로덕션 환경에 배포합니다.

프롬프트를 넘어서: Anthropic의 에이전트 메모리, 꿈, 그래프 워크플로우 접근법

1. checklist.md를 읽으세요.
2. 전체 테스트 스위트를 실행하세요.
3. 마이그레이션 계획을 확인하세요.
4. scripts/verify-release.sh를 실행하세요.
5. 배포 전에 중지하고 인간의 승인을 요청하세요.

중요한 메커니즘은 점진적 공개입니다.

Claude는 스킬이 관련이 있는지 판단하는 데 도움이 되는 짧은 설명을 봅니다. 전체 스킬 본문과 지원 파일은 해당 프로세스가 필요할 때만 로드됩니다.

Mukta는 이를 책장에 비유합니다.

사람은 대화를 시작하기 전에 모든 책을 기억할 필요가 없습니다. 어떤 책에 관련 정보가 포함되어 있을지 알면 적절한 시기에 꺼내면 됩니다.

스킬은 "컨텍스트 파일이 계속 커지는 문제"를 해결하는 데 도움이 됩니다:

• 안정적이고 높은 수준의 사실은 CLAUDE.md에 유지할 수 있습니다.
• 상세한 프로세스는 스킬로 옮길 수 있습니다.
• 지원 자료는 필요하기 전까지 활성 컨텍스트 밖에 보관할 수 있습니다.

Anthropic 공식 스킬 문서는 팀이 동일한 지침, 체크리스트 또는 다단계 프로세스를 대화에 반복적으로 붙여넣을 때, 또는 CLAUDE.md의 일부 섹션이 간결한 사실이 아닌 프로세스로 발전했을 때 스킬을 만들 것을 권장합니다.

스킬은 여전히 인간의 관리가 필요합니다

스킬은 재사용 가능하지만 여전히 누군가가 결정해야 합니다:

• 어떤 워크플로우가 스킬을 만들 가치가 있는지
• 프로세스를 어떻게 구성할지
• 어떤 파일을 포함할지
• 스킬이 언제 구식이 되는지
• 누가 편집 권한을 가지는지

에이전트는 스킬 작성과 유지 관리를 도울 수 있지만, 이 시스템은 여전히 부분적으로 인간의 관리에 의존합니다.

이것이 네 번째 접근 방식으로 이어집니다.

4세대: 파일 시스템을 메모리로 취급하기

Mukta는 파일 시스템 기반 메모리를 Anthropic이 현재 많은 에이전트 메모리 시스템에서 선호하는 패턴으로 설명합니다.

그 근거는 매우 실용적입니다.

에이전트는 이미 다음에 능숙합니다:

• 파일 나열
• 파일 이름 검색
• grep 실행
• Markdown 읽기
• 디렉터리 탐색
• 텍스트 편집
• 버전 비교

고도로 전문화된 메모리 인터페이스를 발명하는 대신, 팀은 메모리를 파일로 구성하고 에이전트에게 일반적인 파일 시스템 도구를 제공할 수 있습니다.

가능한 레이아웃은 다음과 같습니다:

memory/
├── organization/
│   ├── principles.md
│   ├── terminology.md
│   └── security-policy.md
├── teams/
│   ├── engineering/
│   │   ├── architecture.md
│   │   └── release-process.md
│   └── support/
│       ├── escalation-rules.md
│       └── response-style.md
├── projects/
│   └── billing-redesign/
│       ├── decisions.md
│       ├── known-issues.md
│       └── current-status.md
└── agents/
    └── agent-104/
        └── scratchpad.md

이 레이아웃은 다양한 수준의 메모리를 지원합니다:

• 조직 수준 규칙
• 팀 지식
• 프로젝트 컨텍스트
• 사용자 선호도
• 특정 에이전트의 작업 노트

또한 점진적 공개를 구현합니다.

에이전트는 디렉터리를 검색하여 현재 작업과 관련된 파일만 로드할 수 있습니다.

파일은 인터페이스이지 반드시 물리적 저장소가 아닙니다

파일 시스템 스타일 인터페이스는 모든 기업 메모리가 노트북에 관리되지 않는 파일로 존재해야 한다는 것을 의미하지 않습니다.

기본 구현은 여전히 다음을 사용할 수 있습니다:

• 데이터베이스
• 버전 관리 객체 스토리지
• 접근 제어 서비스
• 검색 인덱스
• 감사 로그
• 트랜잭션 API

핵심은 에이전트가 단순하고 탐색 가능한 추상화를 얻는다는 것입니다.

질의응답 세션에서 한 청중이 이것이 데이터베이스를 재발명하는 것과 같은지 물었습니다.

Mukta는 이 아키텍처가 친숙한 소프트웨어 엔지니어링 원칙으로 회귀한 것이라고 인정했습니다. 팀이 어떤 동작이 결정적이어야 하는지 이해하면 그 동작을 제어 프레임워크로 옮겨 모델이 매번 즉흥적으로 처리하게 하는 대신 표준화할 수 있습니다.

프로덕션급 메모리를 위한 네 가지 가드레일

Markdown 파일로 가득 찬 폴더는 단일 사용자에게는 효과적일 수 있습니다.

하지만 수천 개의 에이전트가 공유 조직 메모리를 업데이트할 수 있을 때는 위험해집니다.

Mukta는 네 가지 프로덕션 원칙을 강조했습니다:

1. 버전 관리
2. 동시성 제어
3. 권한 관리
4. 이식성

1. 모든 메모리 변경에 버전 기록 설정

모든 메모리 업데이트에는 기록이 있어야 합니다.

유용한 메타데이터는 다음과 같습니다:

• 이전 버전
• 새 버전
• 타임스탬프
• 인간 또는 에이전트 작성자
• 출처 세션
• 지원 대화 기록
• 변경 이유
• 승인 상태

출처 추적이 없는 메모리 항목은 신뢰를 얻기 어렵습니다.

에이전트가 다음을 추가했다고 가정해 보겠습니다:

- 금요일 프로덕션 배포는 승인이 필요 없습니다.

출처, 검토자, 수정 기록이 없으면 다른 에이전트가 이 진술을 권위 있는 것으로 간주할 수 있습니다.

버전 관리는 다음을 지원합니다:

• 검토
• 롤백
• 감사
• 비교
• 근본 원인 분석

버전 관리 메모리 시스템은 다음 질문에 쉽게 답할 수 있어야 합니다:

어떤 상호작용이 이 규칙을 생성했습니까?

2. 동시 에이전트가 서로의 변경을 덮어쓰지 못하게 방지

두 에이전트가 10:00에 동일한 메모리를 읽을 수 있습니다.

에이전트 A는 10:02에 업데이트를 작성합니다.

에이전트 B는 이 변경을 알지 못한 채 10:03에 자신의 버전을 작성하고 에이전트 A의 업데이트를 실수로 삭제합니다.

Mukta는 해시 기반 동시성 패턴을 설명했습니다:

에이전트가 메모리를 읽고 해시 A를 기록
        ↓
에이전트가 업데이트 초안 작성
        ↓
에이전트가 메모리를 다시 읽고 해시 B를 기록
        ↓
해시 A == 해시 B이면:
    업데이트 커밋
아니면:
    다시 로드하고, 다시 기반을 잡고, 재시도

이것이 낙관적 동시성 제어입니다.

모델은 어떤 변경을 제안할지 결정할 수 있지만, 제어 프레임워크는 오래된 쓰기가 최신 버전을 덮어쓰지 못하도록 결정적인 방식으로 방지해야 합니다.

3. 읽기 및 쓰기 권한 구분

모든 에이전트가 모든 메모리를 편집할 수 있어서는 안 됩니다.

합리적인 권한 모델은 다음과 같습니다:

메모리 범위	일반적인 접근 방식
조직 원칙	대부분 에이전트는 읽기 전용, 승인 프로세스를 통해서만 쓰기
보안 정책	관련 에이전트는 읽기 전용, 제한된 인간 제어 쓰기
팀 프로세스	팀 읽기 전용, 지정된 관리자 쓰기
프로젝트 결정	프로젝트 에이전트는 읽기 전용, 제안된 편집은 승인 필요
에이전트 초안 영역	단일 에이전트 읽기/쓰기
사용자 선호도	사용자 범위 에이전트 접근
민감한 고객 컨텍스트	엄격한 역할 기반 접근

에이전트는 불확실한 관찰을 조직 전체 규칙으로 전환할 수 없어야 합니다.

권한 경계는 Dreaming에도 적용되어야 합니다. 통합 작업은 자신의 신원이 접근 권한을 가진 대화 기록과 메모리만 수신할 수 있습니다.

4. 메모리 이식성 확보

메모리는 조직의 가장 가치 있는 AI 자산 중 하나가 될 수 있습니다.

여기에는 다음이 포함됩니다:

• 결정 사항
• 수정 사항
• 워크플로우
• 선호도
• 실패 패턴
• 도구 지식
• 도메인별 지침

Mukta는 팀이 이 자산을 단일 제품 내에서만 실행되도록 설계하는 것을 피해야 한다고 생각합니다.

이식 가능한 메모리 시스템은 다음을 갖추어야 합니다:

• 명확한 API
• 내보내기 가능한 형식
• 문서화된 스키마
• 안정적인 식별자
• 표준 접근 제어
• 도구에 독립적인 출처 추적

이식성은 동일한 잘 정리된 컨텍스트가 다음을 지원할 수 있게 합니다:

• Claude Code
• Claude 호스팅 에이전트
• 내부 도구
• 다른 에이전트 시스템
• 인간 문서 워크플로우

세션 내 메모리가 충분하지 않은 이유

잘 설계된 메모리 도구조차도 두 가지 구조적 한계가 있습니다.

한계 1: 에이전트가 쉽게 산만해짐

에이전트는 작업을 완료하면서 동시에 메모리를 정리해야 합니다.

메모리 쓰기는 현재 목표에 사용할 수 있는 리소스를 소모합니다.

에이전트는 다음을 할 수 있습니다:

• 너무 많이 저장
• 너무 적게 저장
• 검증되지 않은 결론 저장
• 시간 압박 속에서 메모리 작업 건너뛰기
• 더 큰 패턴보다 지역적 세부 사항에만 집중

제한 2: 에이전트는 하나의 세션만 볼 수 있음

에이전트는 특정 명령이 한 번 실패한 것을 확인할 수 있습니다.

하지만 동일한 명령이 다른 300개의 세션에서도 모두 실패했다는 사실은 볼 수 없습니다.

지원 에이전트는 특정 고객이 어떤 정책에 대해 혼란스러워하는 것을 볼 수 있습니다.

하지만 동일한 혼란이 지역 전체에서 반복적으로 발생하고 있다는 사실은 볼 수 없습니다.

시스템 전반에 걸친 학습 메커니즘은 더 넓은 가시성을 갖춘 프로세스를 필요로 합니다.

이 프로세스가 바로 Anthropic이 말하는 "드리밍"(Dreaming) 입니다.

드리밍: 메모리를 정리하기 위한 대역 외 프로세스

드리밍은 정상적인 작업이 완료된 후 에이전트 기록을 검토하는 비동기 프로세스입니다.

Anthropic의 현재 API 릴리스 노트에서는 Claude 호스팅 에이전트의 "드리밍" 기능을 연구 미리보기로 설명하고 있습니다.

드리밍은 다음을 읽습니다:

• 기존 메모리 저장소
• 과거 세션 기록

그런 다음 재구성된 출력 메모리 저장소를 생성하며, 여기에서 다음을 수행할 수 있습니다:

• 중복 항목 병합
• 오래된 정보 교체
• 누락된 통찰력 발견
• 콘텐츠 재구성
• 개선된 메모리 제안

이는 모델 재학습이 아닙니다.

기저 모델의 가중치는 변경되지 않습니다.

개선은 미래 세션이 검색할 수 있도록 영구 컨텍스트를 변경함으로써 이루어집니다.

학교 비유

Mukta는 학교를 사용하여 일반 메모리와 "드리밍"의 차이점을 설명했습니다.

상상해 보세요:

• 학생들이 숙제를 완료합니다.
• 교사가 각 숙제를 채점합니다.
• 교무처장이 학교 전체의 전반적인 결과를 검토합니다.

교사는 한 학생이 실수를 고치도록 도울 수 있습니다.

교무처장은 모든 지리 수업 학생들이 동일한 지식 포인트에서 실수를 한다는 것을 알 수 있습니다. 교과 과정에 해당 내용이 포함되어 있지 않기 때문입니다.

시스템 수준의 수정은 각 시험지를 개별적으로 채점하는 것이 아닙니다.

교과 과정을 업데이트하는 것입니다.

에이전트 용어:

• 학생 숙제 = 개별 세션
• 교사 피드백 = 세션 내 메모리 업데이트
• 학교 교과 과정 = 공유 메모리 저장소
• 교장 검토 = 드리밍 처리
• 교과 과정 업데이트 = 제안된 메모리 변경

이를 통해 시스템은 개별 에이전트가 인지하지 못하는 패턴을 학습할 수 있습니다.

드리밍 처리의 작동 원리

단순화된 드리밍 처리 파이프라인은 다음과 같습니다:

플로우차트 TD
    A[기존 메모리 저장소] --> D[드리밍 오케스트레이터]
    B[세션 기록] --> D
    C[도구 호출 및 메타데이터] --> D
    D --> E1[검토 에이전트 1]
    D --> E2[검토 에이전트 2]
    D --> E3[검토 에이전트 3]
    E1 --> F[패턴 집계기]
    E2 --> F
    E3 --> F
    F --> G[제안된 메모리 변경]
    G --> H{인간 승인}
    H -->|수락| I[업데이트된 메모리 저장소]
    H -->|거부| J[기존 메모리 유지]

검토 프로세스는 사용자 및 어시스턴트 메시지 이상의 내용을 검사할 수 있습니다.

유용한 증거에는 다음이 포함됩니다:

• 도구 호출
• 도구 실패
• 재시도 횟수
• 실행 메타데이터
• 인간의 수정
• 평가 점수
• 수락 및 거부된 출력
• 스킬 사용 현황
• 모델 버전
• 지연 시간 및 비용

드리밍 에이전트는 다음과 같은 패턴을 찾습니다:

• 동일한 명령이 반복적으로 실패하는 경우
• 여러 에이전트가 특정 내부 용어를 오해하는 경우
• 특정 메모리 항목이 더 이상 유효하지 않은 경우
• 두 파일에 중복된 규칙이 포함된 경우
• 팀이 동일한 형식 문제를 반복적으로 수정하는 경우
• 특정 도구 구성이 여러 프로젝트에서 오류를 유발하는 경우
• 특정 정책이 누락되어 에이전트가 추측해야 하는 경우

Mukta는 Anthropic의 설계에 관련 세션 기록의 예시와 패턴 발생 빈도를 보여주는 통계가 포함될 수 있다고 언급했습니다.

이러한 증거는 인간이 제안된 메모리 변경이 합리적인지 판단하는 데 도움이 됩니다.

드리밍 처리는 제안을 해야 하며, 조용히 모든 것을 다시 쓰면 안 됨

드리밍 처리는 광범위한 접근 권한을 가지며 에이전트 클러스터 전체의 미래 동작에 영향을 미칠 수 있습니다.

따라서 자동화되고 심사되지 않은 업데이트는 위험합니다.

더 안전한 작업 흐름은 다음과 같습니다:

1. 승인된 세션 기록을 분석합니다.
2. 반복되는 패턴을 식별합니다.
3. 패턴을 뒷받침하는 세션에 연결합니다.
4. 제안된 메모리 변경 초안을 작성합니다.
5. 문제의 보급 범위를 추정합니다.
6. 인간 또는 정책 기반 검토자의 승인을 요청합니다.
7. 출처 기록이 포함된 승인된 업데이트를 제출합니다.
8. 향후 성능 개선 여부를 측정합니다.

예를 들어:

## 제안된 메모리 업데이트

**대상:** `teams/engineering/test-process.md`

**관찰된 문제:**  
에이전트가 관련 63개 세션 중 18개 세션에서 단위 테스트 명령을 사용하여 통합 테스트를 실행했습니다.

**증거:**  
세션 `s-102`, `s-111`, `s-118`, `s-124`, ...

**제안된 추가 내용:**  
- 데이터베이스 컨테이너가 필요한 모든 테스트에 `npm run test:integration`을 사용합니다.
- `tests/integration/` 아래의 파일에 대해서는 `npm test`를 사용하지 마십시오.

**신뢰도:** 높음

**인간 결정:** 대기 중

이렇게 하면 인간의 감독을 유지하면서 에이전트 클러스터가 분석 작업의 대부분을 수행할 수 있습니다.

드리밍 처리가 더 많은 토큰을 사용하면서도 비용을 절감하는 이유

드리밍 처리는 추가 모델 호출이 필요합니다.

언뜻 보기에는 불필요한 오버헤드처럼 보일 수 있습니다.

Mukta는 더 깨끗한 메모리 저장소가 총 비용을 절감할 수 있다고 생각합니다. 미래의 에이전트가 첫 시도에서 올바르게 작업을 완료할 가능성이 높아지기 때문입니다.

첫 번째 시도.

유용한 경제성 비교는 다음과 같습니다:

드리밍 비용
대비
반복 실패, 재시도, 재작업 및 과도한 컨텍스트 비용

잠재적 절감 효과는 다음에서 발생할 수 있습니다:

• 더 적은 재시도
• 더 적은 반복 설명
• 더 적은 관련 없는 컨텍스트
• 더 나은 도구 선택
• 더 높은 첫 시도 정확도
• 새 에이전트의 더 빠른 온보딩
• 더 적은 인간의 반복 수정

Anthropic은 각 조직이 얼마나 절감할 수 있는지 보여주는 일반적인 벤치마크를 아직 발표하지 않았습니다. 구체적인 가치는 다음에 따라 달라집니다:

• 작업 반복 정도
• 메모리 품질
• 오류 비용
• 세션 수
• 검토 설계
• 모델 및 도구 가격

대량의 에이전트가 관련 작업을 수행하고 동일한 패턴을 반복적으로 만날 때 "드리밍"이 가장 효과적입니다.

호스팅 에이전트 없이 간단한 주간 드리밍 프로세스

팀은 완전한 플랫폼 통합을 기다리지 않고도 이 개념을 테스트할 수 있습니다.

수동 버전은 주 1회 실행할 수 있습니다.

1단계: 관련 세션 내보내기

검토자가 볼 권한이 있는 대화 기록만 수집합니다.

다음과 같이 구성합니다:

• 프로젝트
• 팀
• 워크플로우
• 권한 범위
• 기간

2단계: 현재 메모리 제공

다음을 포함합니다:

• CLAUDE.md
• 관련 스킬
• 프로젝트 메모리 파일
• 팀 설명
• 알려진 문제 문서

3단계: 증거 기반 제안 요청

프롬프트는 다음과 같이 작성할 수 있습니다:

승인된 세션 기록과 현재 메모리 파일을 검토하십시오.

반복되는 실패, 사용자의 반복 수정, 오래된 지침,
누락된 프로세스 및 중복 항목을 식별하십시오.

각 제안된 수정 사항에 대해:
1. 대상 파일을 지정하십시오.
2. 뒷받침하는 세션 ID를 제공하십시오.
3.

해당 패턴이 발생하는 빈도를 설명합니다.
4. 최소한의 유효한 수정안을 초안합니다.
5. 파일을 직접 편집하지 마십시오.

4단계: 제안 검토

다음 수정 사항은 거부합니다:

• 단일 모호한 사건에 기반한 경우
• 증거 부족으로 뒷받침되지 않는 경우
• 범위가 지나치게 광범위한 경우
• 보안 민감 사항을 포함하는 경우
• 검토자 권한 범위를 벗어나는 경우
• 결정적 코드로 구현하는 것이 더 적합한 경우

5단계: 승인된 수정 사항 제출

버전 관리를 사용하고, 커밋 또는 감사 기록에 출처 증거를 포함하십시오.

6단계: 결과 측정

후속 세션에서 동일한 실패가 감소하는지 추적하십시오.

측정이 없으면 "꿈꾸기"는 학습 시스템이 아닌 문서 생성 작업이 되어버립니다.

시간에 따라 축적된 기억에서 작업 내 구조로

기억이 답하는 질문은 다음과 같습니다:

에이전트는 이전 작업에서 무엇을 기억해야 하는가?

그래프 구조 엔지니어링은 다른 질문에 답합니다:

현재 작업의 어떤 부분이 실제로 서로 의존하는가?

BAAI 원문 기사는 기억 주제를 AI 개발 커뮤니티에서 유통되는 그래프 구조 엔지니어링 가이드와 연결합니다.

해당 가이드의 핵심 주장은 많은 "워크플로우"가 본질적으로 이미 그래프라는 것입니다 — 단지 설계가 형편없을 뿐입니다.

목록 형태로 작성된 워크플로우는 종종 인위적으로 직렬 프로세스로 변형됩니다:

연구
    ↓
요약
    ↓
비교
    ↓
사실 확인
    ↓
작성

이러한 단계 중 일부는 실제로 이전 단계의 출력에 의존할 수 있습니다.

다른 단계는 불필요하게 대기 중일 수 있습니다.

노드, 엣지 및 실제 데이터 흐름

워크플로우 그래프에서:

• 노드는 하나의 작업을 나타냅니다.
• 엣지는 실제 의존 관계를 나타냅니다.
• 데이터는 엣지를 따라 흐릅니다.

예를 들어:

연구 노드는 연구 결과물을 산출합니다.

작성 노드는 이러한 연구 결과물을 소비하여 초안을 산출합니다.

검증 노드는 초안을 소비하여 검증된 결과물을 산출합니다.

이러한 화살표는 합리적입니다. 각 하류 노드가 상류 노드의 출력을 필요로 하기 때문입니다.

의사 엣지 테스트

커뮤니티 그래프 가이드는 각 화살표에 대해 간단한 테스트를 제시합니다:

다음 작업이 정말로 이전 작업의 출력을 필요로 하는가?

대답이 아니오라면, 그 의존 관계는 의사 의존 관계입니다.

다음 워크플로우를 고려해 보십시오:

경쟁사 A 연구
    ↓
경쟁사 B 연구
    ↓
경쟁사 C 연구
    ↓
비교 보고서 작성

경쟁사 B 연구는 일반적으로 경쟁사 A 연구의 출력을 필요로 하지 않습니다.

경쟁사 C 연구는 일반적으로 경쟁사 B 연구의 출력을 필요로 하지 않습니다.

이러한 작업은 병렬로 실행될 수 있습니다:

flowchart TD
    A[비교 기준 정의] --> B1[경쟁사 A 연구]
    A --> B2[경쟁사 B 연구]
    A --> B3[경쟁사 C 연구]
    B1 --> C[비교 보고서 작성]
    B2 --> C
    B3 --> C

의사 엣지를 제거하면 대기 시간을 줄일 수 있습니다.

세 개의 연구 작업이 각각 10, 12, 15분이 걸린다면:

• 순차 실행은 약 37분이 걸립니다.
• 병렬 실행은 약 15분의 대기 시간에 오케스트레이션 오버헤드가 추가됩니다.

그래프는 개별 에이전트를 더 빠르게 만들지 않습니다.

변경하는 것은 스케줄링 방식입니다.

다이아몬드 패턴

의사 엣지를 제거하면 일반적인 형태가 나타납니다:

1. 하나의 작업이 여러 독립 분기로 나뉩니다.
2. 이러한 분기가 병렬로 실행됩니다.
3. 결과가 모입니다.
4. 최종 노드가 결과를 종합합니다.

이를 일반적으로 다이아몬드라고 부릅니다.

연구 예시는 다음과 같을 수 있습니다:

flowchart TD
    A[연구 질문] --> B1[시장 데이터]
    A --> B2[고객 증거]
    A --> B3[경쟁사 분석]
    B1 --> C[검증자]
    B2 --> C
    B3 --> C
    C --> D[최종 종합]

총 소요 시간은 모든 분기의 합이 아닌 가장 느린 분기에 의해 주로 결정됩니다.

병렬 작업에는 검증자가 필요합니다

병렬화는 새로운

위험을 도입합니다.

하나의 작업 스레드가 취약하거나, 오래되었거나, 뒷받침되지 않는 출력을 생성할 수 있습니다.

시스템이 검증 없이 모든 것을 병합하면, 하나의 나쁜 분기가 최종 답변을 오염시킬 수 있습니다.

따라서 그래프 가이드는 종합 전에 검사기를 배치합니다.

검사기는 다음과 같은 질문을 할 수 있습니다:

• 이 주장이 뒷받침되는가?
• 출처가 최신인가?

출력이 요청된 형식을 충족하는가?

• 작업 스레드가 할당된 작업을 완료했는가?
• 코드가 테스트를 통과했는가?
• 결과가 다른 브랜치와 충돌하는가?
• 민감한 데이터가 존재하는가?
• 이 출력으로 안전하게 계속 진행할 수 있는가?

유용한 검사기에는 명확한 승인 기준이 있어야 한다.

예를 들어: