태그는 이름표일까, 약속일까

클라우드 리소스에 태그를 붙이는 일은 처음엔 아주 사소해 보인다.

env=prod, team=platform, RTS=TRUE.

딱 봐도 이름표 같다. “너는 운영 환경이야.” “너는 플랫폼 팀 소유야.” “너는 특정 네트워크 경로를 타야 해.” 이런 식이다.

그런데 어느 순간 이 작은 이름표가 제품 설계의 어려운 질문으로 변한다.

“이 태그는 처음 붙인 뒤 사용자가 바꿀 수 있어야 할까?”

“Cloud Sync가 다시 돌면 사용자가 바꾼 값을 덮어써도 될까?”

“Cloud Provider의 기본 태그를 바꾸면 이미 만들어진 리소스에도 전부 반영해야 할까?”

사소한 입력칸 하나가 갑자기 제품 철학 시험지가 된다.

기본 태그라는 다정한 함정

Cloud Provider 설정 화면에는 종종 이런 영역이 있다.

Auto Configuration Upon Synchronization
- Default Tags

말 그대로 “동기화할 때 자동으로 설정해줄 기본 태그”다.

예를 들어 사용자가 Cloud Provider에 이렇게 입력했다고 해보자.

RTS = TRUE

그리고 클라우드에서 GKE 클러스터 하나가 발견된다.

cluster: prod-gke-01
labels: env=prod, team=network

동기화가 끝나면 QueryPie 리소스에는 이런 태그가 생긴다.

env=prod
time=network
RTS=TRUE

아, 여기서 time=network가 아니라 team=network다. 태그 이야기를 하다 보면 이런 오타도 태그처럼 오래 살아남는다. 그래서 실제 제품에서는 사람이 고칠 수 있어야 한다.

다시 쓰면 이렇다.

env=prod
team=network
RTS=TRUE

여기까지는 아무 문제 없어 보인다. 기본 태그는 편하다. 매번 리소스마다 같은 값을 손으로 붙이지 않아도 된다.

문제는 그 다음이다.

“한 번 붙인 이름표”와 “계속 강제되는 정책”은 다르다

어느 날 운영자가 prod-gke-01을 살펴보다가 말한다.

“이 클러스터는 Reverse Tunnel 대상이 아니네. RTS=TRUE면 안 되겠다.”

그래서 상세 화면에서 태그를 바꾼다.

RTS=FALSE

여기까지도 자연스럽다. 리소스 태그는 운영자가 현재 상태에 맞게 고칠 수 있어야 한다.

그런데 밤에 Cloud Sync가 다시 돈다. 그리고 시스템이 Cloud Provider의 Default Tag를 다시 읽는다.

Cloud Provider Default Tag: RTS=TRUE

만약 시스템이 이렇게 생각한다면 어떻게 될까?

“기본 태그가 RTS=TRUE니까 모든 리소스에 다시 RTS=TRUE를 발라야지.”

다음 날 운영자는 어제 고친 값이 원래대로 돌아간 것을 본다.

RTS=FALSE  ->  RTS=TRUE

이건 버그처럼 보인다. 사실 구현 입장에서는 “정책을 잘 반영한 것”일 수도 있다. 하지만 사용자 입장에서는 “내가 고친 걸 누가 밤새 되돌렸지?”가 된다.

여기서 중요한 구분이 나온다.

Default Tag는 이름표인가, 약속인가?

• 이름표라면: 리소스가 처음 생길 때 붙여주는 기본값이다.
• 약속이라면: 동기화할 때마다 계속 강제해야 하는 정책이다.

두 의미는 완전히 다르다.

가장 안전한 정의: 처음 한 번만

이번에 정리하면서 가장 설득력 있었던 결론은 이거다.

Cloud Provider Default Tag는 리소스가 처음 동기화되어 생성될 때 한 번만 적용한다.

즉 Default Tag는 “계속 강제되는 정책”이 아니라 “초기값”이다.

흐름은 이렇게 단순해진다.

Cloud Provider Default Tag
  -> 새 리소스가 처음 발견됨
  -> 리소스 생성 시 기본 태그로 병합
  -> 이후에는 일반 태그처럼 관리
  -> 다음 Sync에서 다시 덮어쓰지 않음

이 원칙을 따르면 사용자의 머릿속 모델도 깔끔해진다.

“Cloud Provider에서 Default Tag를 정하면 앞으로 새로 들어오는 리소스에는 붙는다.”

“이미 만들어진 리소스는 각 리소스의 태그를 직접 관리한다.”

“이미 만들어진 리소스를 대량으로 바꾸고 싶으면 별도 API나 운영 기능을 쓴다.”

처음엔 조금 덜 자동화된 것처럼 보이지만, 운영 안정성은 훨씬 좋아진다.

클라우드 라벨과 기본 태그가 충돌하면?

또 하나의 재미있는 문제가 있다.

GCP에서 이미 이런 label을 가진 클러스터가 있다고 하자.

team=network

그런데 Cloud Provider Default Tag에도 같은 key가 있다.

team=platform
RTS=TRUE

최종 결과는 어떻게 되어야 할까?

권장 규칙은 클라우드 원본 값을 우선하는 것이다.

GCP labels:       team=network
Default Tags:     team=platform, RTS=TRUE
QueryPie result:  team=network, RTS=TRUE

이유는 간단하다. 클라우드에 이미 붙어 있는 label은 그 리소스의 원본 메타데이터다. Default Tag는 빈 곳을 채워주는 기본값에 가깝다. 원본이 있는 자리에 기본값이 밀고 들어가면 또 다른 덮어쓰기 문제가 생긴다.

기본값은 친절해야 하지만, 고집이 세면 안 된다.

제품마다 조금씩 다른 행동이 만든 숙제

이런 기능은 제품 안에서도 영역마다 조금씩 다르게 자라기 쉽다.

데이터베이스 접근 제어 쪽에서는 리소스 태그를 상세 화면에서 수정할 수 있다. 서버 접근 제어 쪽도 기본 태그와 포트를 자동 설정하는 흐름이 있다. 쿠버네티스 접근 제어 쪽은 AWS에는 비슷한 기능이 있는데 GCP에는 빠져 있을 수 있다.

각각의 결정은 당시에는 합리적이었을 것이다.

• 이 리소스는 동기화된 값이니까 못 고치게 하자.
• 이쪽은 운영자가 고쳐야 하니까 수정 가능하게 하자.
• 이 Provider는 급해서 먼저 만들고, 다른 Provider는 나중에 맞추자.

하지만 시간이 지나면 사용자는 제품을 도메인별 내부 사정으로 보지 않는다.

사용자에게는 그냥 하나의 제품이다.

그래서 이런 질문이 나온다.

“왜 서버에서는 되는데 쿠버네티스에서는 안 돼요?”

“왜 AWS에서는 보이는데 GCP에서는 안 보이죠?”

“왜 내가 바꾼 태그가 다시 돌아가죠?”

이 질문들은 단순 기능 요청이 아니다. 제품 안의 개념이 아직 하나로 정렬되지 않았다는 신호다.

작은 입력칸 하나가 알려준 것

이번 태그 정책 정리에서 배운 점은 꽤 단순하다.

설정값에는 수명이 있다.

어떤 설정은 매번 강제되어야 한다. 예를 들어 보안 정책이나 접근 차단 규칙은 “한 번 적용하고 끝”이면 곤란하다.

반대로 어떤 설정은 처음 만들 때의 기본값일 뿐이다. Default Tag는 대체로 여기에 가깝다.

이 둘을 구분하지 않으면 제품은 친절해지려다가 사용자의 작업을 덮어쓴다.

마치 집들이 선물로 붙여준 이름표를, 손님이 올 때마다 다시 와서 붙이는 집주인 같다.

처음엔 고맙다.

세 번째부터는 무섭다.

내가 좋아하는 결론

Default Tag의 좋은 정의는 이렇다.

Default Tag는 리소스가 처음 태어날 때 달아주는 이름표다.
그 이후의 이름표 관리는 리소스의 삶에 맡긴다.

제품 문구도 이 방향으로 더 명확해지면 좋다.

Default Tags are applied only when a resource is first synchronized and created.
After creation, resource tags are treated as regular tags and are not overwritten by Default Tags on later synchronizations.

한국어로는 이렇게 말할 수 있다.

Default Tag는 Cloud Provider 동기화로 리소스가 처음 생성될 때만 적용됩니다.
생성된 리소스의 태그는 이후 일반 태그처럼 수정할 수 있으며, 재동기화 시 Default Tag로 다시 덮어쓰지 않습니다.

이 문장 하나가 있으면 사용자는 덜 헷갈린다. 개발자는 구현 기준을 잃지 않는다. 지원팀은 답변을 짧게 할 수 있다.

그리고 무엇보다, 새벽 Sync가 어제의 수정을 몰래 되돌리는 유령 같은 상황을 피할 수 있다.

정리

태그는 작다. 하지만 태그 정책은 작지 않다.

특히 Cloud Sync처럼 “외부 세계의 상태”와 “제품 안에서 사용자가 편집한 상태”가 만나는 곳에서는 더 그렇다.

좋은 기본값은 일을 줄여준다.

나쁜 기본값은 일을 되돌린다.

그래서 Default Tag는 계속 강제되는 약속이 아니라, 처음 붙여주는 이름표로 남기는 편이 낫다.

이름표는 필요하다.

다만 사용자가 새 이름을 붙였을 때, 제품은 그 이름을 존중해야 한다.