기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 피해야 할 태그 지정 방법
AWS에서 객체 또는 인프라에 태그를 지정할 경우 구현해야 할 사례가 있지만 피해야 할 사례도 있습니다.
## 일관되지 않은 태그 지정
[목표](objectives.md) 섹션에 설명된 대로 태그 지정 없이는 높은 수준의 자동화, 정리 또는 모니터링을 수행할 수 없습니다. 마찬가지로 불완전하거나 일관되지 않은 태그로 인해 자동화 또는 모니터링에 필요한 정보가 완전하지 않아 신뢰할 수 없는 결과가 발생합니다.
태그 지정 전략을 사용하여 모든 프로젝트의 총 비용을 계산하는 시나리오를 가정합니다. 이 전략은 개념 증명(PoC) 단계에서 시작하여 프로덕션 단계로 끝납니다. 프로젝트 판매 예측 P1, D1, Pr1 예제와 프로젝트 사후 판매 유지 관리 P2, D2, Pr2 예제의 경우 데이터 및 리소스에 태그가 적용된 다음 시나리오를 고려합니다.
**판매 예측**
P1 예제: PoC 프로젝트(도메인 및 타임스탬프 누락).
```
env: "poc"
project: "sales forecasting"
```
D1 예제: 개발 단계(도메인 누락).
```
env: "dev"
project: "sales forecasting"
timestamp: 20210505T12:34:55
```
Pr1 예제: 프로덕션 단계(모든 값 존재).
```
env: "prod"
project: "sales forecasting"
domain: "machine learning"
timestamp: 20210505T12:34:55
```
판매 예측 프로젝트의 경우:
+ P1 예제에서는 객체의 도메인 또는 타임스탬프를 언급하지 않습니다.
+ D1 예제에서도 프로젝트의 도메인을 언급하지 않습니다.
+ Pr1 예제에는 필요한 모든 데이터가 있습니다.
P1 및 D1 예제에서는 도메인이 정의되지 않았기 때문에 계획에 대한 잘못된 보고 또는 추정이 발생합니다.
**사후 영업 유지 관리**
P2 예제: PoC 프로젝트(모든 태그 누락).
D2 예제: 개발 단계(프로젝트 누락).
```
env: "dev"
domain: "machine learning"
timestamp: 20210505T12:34:55
```
Pr2 예제: 프로덕션 단계(모든 값 존재).
```
env: "prod"
project: "post sales maintenance"
domain: "machine learning"
timestamp: 20210505T12:34:55
```
프로젝트에서 사후 영업 유지 관리의 경우:
+ P2 예제에는 정보가 없으므로 추적할 수 없습니다.
+ D2 예제에서는 프로젝트 이름을 언급하지 않으므로 추적할 수 없습니다.
+ Pr2 예제에는 필요한 모든 데이터가 있습니다.
P2 및 D2 예제에서는 누락되거나 일관되지 않은 태그로 인해 보고가 잘못되거나 계획이 진행 중이거나 과소 보고가 발생합니다.
따라서 태그 지정 전략을 일관된 방식으로 구현하는 것이 중요합니다.
## 태그의 잘못된 데이터 및 민감한 데이터
태그 지정은 부정확하거나 민감한 정보 또는 프라이빗 정보와 함께 사용하는 경우 생산성을 저해할 수 있습니다. 잘못된 태그는 오해의 소지가 있는 결과를 초래할 수 있습니다. 개인 식별 정보(PII)와 같은 민감한 데이터가 포함된 태그를 사용하면 고객과 직원의 보안이 위험에 처할 수 있습니다.
**태그의 잘못된 정보**
태그 지정 전략을 사용하여 각 도메인 또는 부서의 총 비용을 계산하는 시나리오를 가정합니다. 방금 데이터 수집 단계를 완료했으며 기계 학습으로 진행 중입니다. 다음 예제에는 프로젝트의 이전 단계에서 복사된 사용자 지정 태그가 포함되어 있습니다.
```
env: "development"
project: "sales prediction"
domain: "data ingestion"
timestamp: 20210505T12:34:55
```
도메인에 올바른 도메인(`machine learning`) 대신 이전 프로젝트 단계에서 레이블이 `data ingestion`으로 잘못 지정되었습니다. 이제 `data ingestion` 도메인에 대한 보고서에 더 높은 비용, 시간 범위 및 리소스 할당이 표시됩니다. `machine learning` 도메인은 이러한 보고서에 대해 더 낮은 값을 표시합니다. 이로 인해 계획, 예산 할당 및 기한 추정이 잘못 생성될 수 있습니다.
기능 시스템에는 올바른 태그를 보유하는 것이 중요합니다.
**태그의 민감한 정보**
AWS에서는 객체에서 PII를 식별하기 위한 여러 도구를 제공합니다. 이러한 도구에는 개인을 식별하는 데 사용할 수 있는 데이터를 찾기 위한 [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) 및 [AWS Glue 민감한 데이터 감지](https://docs.aws.amazon.com/glue/latest/ug/detect-PII.html)가 포함됩니다. 그러나 PII 또는 민감한 데이터를 태그에 사용하지 않는 것이 중요합니다.
PII가 수정되거나 익명화된 Amazon S3의 다음 파일 예제를 고려합니다.
```
{
firstName: "67A1790DCA55B8803AD024EE28F616A2",
lastName: "DRG54654DFHJGDYYRD",
age: 21,
city : "Frankfurt",
probability_of_purchase: 48.858093,
veggieName: "broccoli",
creditcard: false
}
```
고객 이름과 성이 해시 처리된 것을 확인할 수 있습니다. 그러나 이 예제에서 레코드에는 다음과 같은 사용자 지정 태그가 있습니다.
```
owner: "Company XYZ"
about: "John Doe"
contact: "johnthegreat@email.com"
timestamp: 20210505T12:34:55
```
이 경우 파일 자체에는 PII가 없지만 태그에는 민감한 정보가 포함되어 있습니다. 이 경우 파일 또는 객체를 공유하거나 전송할 때 메타데이터도 공유하거나 전송할 수 있으므로 정보 유출 가능성이 커집니다. 데이터베이스, 테이블, 작업 및 함수와 같은 다른 AWS 리소스에서도 마찬가지입니다.
따라서 태그에 프라이빗 정보를 사용하지 않는 것이 매우 중요합니다. 이 동일한 개념은 중요한 정보 또는 비공개 정보에도 확장 적용됩니다.