자동화 중지는 전체 변경 금지가 아니다

한 줄 요약

자동 동기화 중지는 모든 변경을 금지하는 잠금이 아닙니다. 무엇을 멈췄고 무엇은 여전히 가능한지 증거와 함께 운영 절차에 적어야 합니다.

왜 이게 필요했나

배포를 잠시 멈춘 뒤 중요한 점검을 시작했습니다. 그런데 누군가 수동 동기화를 눌러 새 설정이 반영됐습니다.
자동 동기화를 껐으니 아무도 변경할 수 없다고 생각했다면 사고의 원인을 잘못 설명하게 됩니다. 자동화 정책은
조정기가 스스로 언제 행동할지를 정합니다. 사용자의 요청 권한이나 다른 배포 경로를 모두 제거하는 장치는 아닙니다.

유지보수 모드라는 말은 팀마다 뜻이 다릅니다. Git 비교는 계속하되 적용만 멈추는 것인지, 수동 적용도
금지하는 것인지, 사용자 트래픽을 막는 것인지가 서로 다릅니다. 화면의 단추 하나에 이 모든 의미를 담으면
사람마다 다른 상태를 상상한 채 작업하게 됩니다. 이번 실습은 비교·자동 적용·수동 적용을 나누어 관측합니다.

어떻게 동작하나

부모 템플릿에서 자식의 자동화를 끈 뒤 Git에 ConfigMap 값 two를 커밋합니다. Application은 새 커밋을
비교하여 OutOfSync를 표시할 수 있지만 실제 ConfigMap에는 이전 값 one이 남을 수 있습니다.
이것은 저장소를 읽지 못했다는 뜻이 아닙니다. sync.revision은 새 커밋을 가리키고, 실제 데이터만 옛 값인
상황이므로 비교와 적용을 분리한 상태입니다. Git 읽기 실패라면 조건과 revision도 따로 조사해야 합니다.

| 질문 | 확인할 근거 | 이것만으로는 알 수 없는 것 |
| --- | --- | --- |
| 새 Git을 읽었나? | 현재 sync.revision | 실제 데이터가 적용됐는지 |
| 자동 적용이 꺼졌나? | enabled=false와 반복 관측 | 수동 적용 권한까지 차단됐는지 |
| 수동 적용이 됐나? | operation 결과와 실제 값 | 이후 자동 적용이 다시 켜졌는지 |
| 정상 자동화로 복귀했나? | 부모·자식 정책과 새 Git의 실제 반영 | 모든 외부 운영 경로가 검증됐는지 |

다음으로 같은 커밋을 명시적으로 수동 동기화합니다. enabled=false를 유지한 채 실제 데이터가 two로
바뀌면 자동화 중지와 변경 금지가 다르다는 것을 직접 확인한 것입니다. operationState의 revision과 phase,
initiatedBy 정보, ConfigMap 데이터와 UID를 함께 봅니다. initiatedBy의 username은 요청에 실을 수 있는
메타데이터이므로 그 문자열만으로 인증된 행위자 신원을 증명했다고 주장하지 않습니다.
사전 실험에서는 수동 요청 뒤 이전 automated=true 표시가 함께 남기도 했습니다. 이 표시에만 기대지 않고
API가 받아들인 operation 영수증, 요청한 revision, 적용 전후 데이터를 연결해 실제 동작을 판단합니다.

kubectl로 Argo CD에 동기화를 요청할 때 operation은 spec 안이 아니라 Application의 최상위 필드입니다.
이 요청도 실제 적용을 일으킵니다. dry-run이나 읽기 조회와 혼동하지 마세요. 이번 실습은 정확한 커밋을
지정하고 prune와 force를 사용하지 않습니다. 비교용 ConfigMap과 Application의 UID는 끝까지 유지됩니다.
운영에서 같은 요청을 허용할지는 RBAC, 승인 절차, 동기화 창과 다른 배포 경로까지 함께 검토해야 합니다.

현장에서 만나는 모습

모든 자식을 멈추는 대신 특정 Application만 잠시 수동 운용해야 할 수도 있습니다. ApplicationSet의
ignoreApplicationDifferences는 부모가 비교에서 제외할 자식 필드를 선언하는 수단입니다. name을
지정하면 특정 자식에 한정할 수 있고 jsonPointers로 대상 필드를 좁힐 수 있습니다. 이번 실습에서는
enabled 한 필드만 예외로 둡니다. 전체 syncPolicy나 source를 무심코 제외하면 훨씬 넓은 드리프트를
놓칠 수 있습니다.

이 예외는 ApplicationSet과 Application 사이의 비교를 바꿉니다. Application과 ConfigMap 사이의 Git
차이를 무시하라는 설정이 아닙니다. 이름에 ignore가 있다고 모든 ignore 계열 설정의 대상이 같지는 않습니다.
누가 누구를 비교할 때 어떤 필드를 보지 않는지 문장으로 풀어 적어 보세요. 대상을 생략한 예외 문서는
문제 해결보다 새 오해를 만들기 쉽습니다.

예외에는 종료 조건도 필요합니다. 누가 해제하는지, 언제까지 유지하는지, 해제 뒤 어떤 새 변경으로 자동
적용을 검증할지 정합니다. 단순히 현재 화면이 Synced라는 이유로 자동화가 복구됐다고 결론 내릴 수 없습니다.
수동으로 이미 맞춰 둔 상태도 Synced이기 때문입니다. 실습에서는 예외를 제거해 자식이 부모의 true를 따르게
한 다음 Git의 세 번째 값 three가 자동으로 반영되는지 확인합니다. 기존 성공을 새 검증의 근거로 재사용하지 않습니다.

리스트 안 필드를 예외로 둘 때는 별도의 함정도 있습니다. ApplicationSet이 사용하는 MergePatch는 변경된
리스트를 통째로 바꿀 수 있어, 다른 항목의 변경으로 예외로 둔 값도 덮일 수 있습니다. 이번 실습은 단일
source와 스칼라 enabled 필드로 범위를 좁힙니다. multi-source 배열의 모든 변경 조합까지 안전하다고
일반화하지 않으며 그 경우는 공식 문서의 제한과 실제 적용 결과를 추가로 확인해야 합니다.

다음 실습에서 할 것

Git이 바뀌어도 자동 적용되지 않는 상태를 세 번 관측하고, 같은 커밋의 수동 적용을 비교합니다. 이름이 있는
좁은 예외를 잠시 사용한 뒤 제거하고 새 Git 변경으로 자동화를 검증합니다. 세 번의 짧은 관측은 학습용 표본이지
무기한 변경 금지의 증명이 아닙니다. 마지막 보고서에는 자동화 중지와 전체 배포 차단, 내부 관측과 운영 보장을
구분하여 적습니다. 전역 컨트롤러를 멈추거나 다른 팀의 권한을 바꾸지 않고도 이 차이를 배울 수 있습니다.

공식 문서

• [kubectl로 동기화 요청](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-kubectl/): operation과 결과 필드의 위치를 확인하세요.
• [ApplicationSet 변경 제어](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Controlling-Resource-Modification/): 특정 자식 예외와 MergePatch의 제한을 읽으세요.