배포 회의에서 듣습니다. "feature 브랜치를 rebase하다 conflict 났고, cherry-pick으로 핫픽스만 가져왔어요. 파이프라인 deploy 스테이지에서 artifact를 못 찾아 실패했고, ArgoCD가 아직 sync 안 됐어요." PM·인프라인 당신은 이 용어들을 알아야 배포 상태와 문제를 판단할 수 있습니다. 이 사전은 Git·CI/CD 용어를 빠르게 해독합니다. 깊은 개념은 이 트랙의 본론(git-fundamentals·branch-strategy·cicd-pipeline)과 Kubernetes 트랙으로 연결합니다.
- 1Git 흐름 용어(merge/rebase/cherry-pick/conflict/tag)를 구분할 수 있다
- 2파이프라인 스테이지(build/test/deploy)와 아티팩트를 설명할 수 있다
- 3GitOps·ArgoCD·매니페스트 저장소의 개념을 이해할 수 있다
- 4테스트 종류(unit/integration/smoke/regression)의 목적을 구분할 수 있다
Git 흐름
브랜치·커밋·통합 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Repository / Remote / Origin | 저장소 / 원격 / 기본 원격 | → Git 기본 흐름 | ★★ |
| Branch / Feature·Release·Hotfix Branch | 작업선 / 용도별 브랜치 | → 브랜치 전략 | ★★ |
| Commit / Push / Pull / Fetch | 기록 / 올리기 / 받기·합치기 / 받기만 | 기본 흐름 | ★★ |
| Merge / Rebase / Cherry-pick | 합치기 / 재배치 / 특정 커밋만 가져오기 | 공유 브랜치 rebase 주의 | ★★ |
| Conflict | 같은 부분 다른 수정 충돌 | 정상, 자주 통합하면↓ | ★★ |
| Tag / Release Tag | 버전 표식 | 롤백 기준 → 시맨틱 버저닝 | ★★ |
| Pull Request / Merge Request / Code Review | 머지 요청 / 리뷰 | 게이트 → PR과 코드 리뷰 | ★★ |
핵심: cherry-pick은 "특정 커밋 하나만" 다른 브랜치로 가져오기(핫픽스에 유용). rebase는 공유 브랜치엔 쓰지 않습니다(이력 재작성으로 협업 혼란). 충돌은 오류가 아니라 정상 — 작게 자주 통합하면 줄어듭니다(브랜치 전략).
확대
위 그림처럼 merge는 두 브랜치의 이력을 그대로 두고 머지 커밋(M)으로 합치지만, rebase는 feature 커밋(F1·F2)을 main의 최신 끝으로 이동시켜 선형 이력을 만듭니다. 공유 브랜치에 rebase + force push를 하면 다른 협업자의 이력이 꼬이므로 로컬 정리 전용으로만 사용합니다.
파이프라인 · 빌드 산출물
CI/CD 스테이지와 아티팩트
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Pipeline / CI / CD | 자동화 흐름 / 통합 / 전달·배포 | → CI/CD 파이프라인 | ★★★ |
| Jenkins / GitHub Actions / GitLab CI | 대표 CI/CD 도구 | 파이프라인 정의 | ★★ |
| Runner / Agent | 파이프라인 실행 머신 | 빌드 환경 | ★ |
| Build / Test / Deploy Stage | 단계 | fail fast → CI/CD 파이프라인 | ★★ |
| Artifact / Build Artifact / Build Number | 빌드 산출물 / 빌드 번호 | 롤백 기준 → 컴파일·인터프리터·빌드·런타임 | ★★ |
| Versioning / Semantic Versioning / Snapshot / Release | 버전 관리 / SemVer / 개발본 / 정식본 | → 시맨틱 버저닝 | ★★ |
| Rollback Plan / Deployment Script | 롤백 계획 / 배포 스크립트 | 배포 안전 → 릴리스 전략 | ★★ |
핵심: "deploy 스테이지에서 artifact 못 찾음"은 빌드 산출물이 저장소에 없거나 버전 불일치 — 빌드 스테이지 성공 여부와 아티팩트 보관을 확인합니다.
확대
위 그림처럼 파이프라인은 Code Push → Build → Test → Artifact 보관 → Deploy → Prod 순서로 흐릅니다. 초반(Build·Test) 실패는 코드·버그 문제를 빠르게 잡은 것이고, 후반(Deploy) 실패는 인프라·아티팩트·환경 문제로 방향이 다릅니다. Artifact를 버전별로 레지스트리에 보관해야 롤백이 가능합니다.
GitOps · 자동화 · 테스트
선언적 배포와 테스트 종류
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Ansible / Playbook / Inventory | 구성 자동화 / 작업정의 / 대상목록 | IaC | ★ |
| ArgoCD / GitOps / Manifest Repo | 선언적 배포 / Git=진실원천 / 매니페스트 저장소 | → ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기 | ★★ |
| Webhook Trigger | 이벤트로 파이프라인 시작 | push 시 자동 | ★★ |
| Build Failure / Compile Error | 빌드/컴파일 실패 | fail fast | ★★ |
| Unit / Integration / Smoke / Regression Test | 단위/통합/스모크/회귀 | → 테스트 전략 | ★★ |
핵심: GitOps는 "Git에 선언한 상태 = 실제 상태"가 되도록 도구가 동기화합니다. 배포가 PR·이력으로 추적되고 롤백이 git revert로 가능해집니다(ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기). 테스트 종류·피라미드는 테스트 전략.
확대
위 그림처럼 GitOps에서는 개발자가 PR을 머지하면 Git의 매니페스트(원하는 상태)가 바뀌고, ArgoCD가 이를 감지해 Kubernetes 클러스터를 자동으로 동기화합니다. 클러스터가 Git과 달라지면 OutOfSync 상태가 되고, 동기화 완료 시 Synced 상태로 전환됩니다. 롤백은 git revert만으로 가능합니다(ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기).
배포 실패 해독 — 직접 확인
배포 실패는 어느 스테이지(build/test/deploy)에서 났는지로 원인을 가릅니다.
gh run list --limit 5 # 최근 실행 성패
gh run view <run-id> --log-failed | head # 실패 스테이지·로그
# GitOps면 동기화 상태
# argocd app get <app> → Sync/Health 상태
✗ build 스테이지 실패: compile error → 코드 문제(머지 전 잡혔어야)
✗ test 스테이지 실패: 회귀 테스트가 버그 차단 → 게이트 정상 작동([[test-strategy]])
✗ deploy 스테이지 실패: artifact "app:v1.3" not found → 빌드 산출물 누락/태그 불일치
ArgoCD: OutOfSync → Git 매니페스트와 클러스터 상태 불일치, sync 필요
gh run view <run-id> --log-failed | head -30- build/test(초반) 실패면 코드·테스트 문제(fail fast 정상) — 빠르게 잡힌 것. deploy(후반) 실패면 인프라/아티팩트/환경 문제로 방향이 다르다
- test 스테이지에서 회귀 테스트가 막았으면 그 테스트가 "버그를 prod로 가기 전 차단"한 것 → 게이트 정상(테스트 전략)
- deploy에서 "artifact not found"면 빌드 산출물 누락·태그 불일치 → 빌드 성공 여부와 레지스트리의 해당 태그 존재 확인(시맨틱 버저닝)
- GitOps에서 OutOfSync가 오래 지속되면 자동 동기화 실패·수동 변경(drift) → argocd 상태와 매니페스트 저장소를 본다(ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기)
상황: 한 개발자가 여러 명이 함께 쓰는 공유 브랜치(develop)를 rebase하고 force push했더니, 다른 사람들의 로컬 이력과 어긋나 충돌이 폭발하고 일부 커밋이 사라진 것처럼 보입니다.
원인: 공유 브랜치에 rebase + force push는 이력을 재작성해, 그 브랜치를 기반으로 작업하던 모두의 히스토리를 깨뜨립니다. rebase는 '아직 공유 안 한 내 로컬 커밋 정리'에만 안전합니다(브랜치 전략).
진단:
git reflog # 사라진 듯한 커밋의 흔적(복구 단서)
git log --oneline origin/develop # 원격 이력이 재작성됐는지
해결: (1) reflog로 잃어버린 커밋을 찾아 복구. (2) 규칙 수립 — 공유 브랜치엔 rebase·force push 금지, 보호 규칙으로 force push 차단(PR과 코드 리뷰). (3) 통합은 merge로, rebase는 로컬 정리용으로만. force push는 거의 항상 위험 신호이며, 인프라/플랫폼팀이 브랜치 보호로 시스템적으로 막아야 합니다.
심화 — 자동화가 강해질수록 '손 수정'은 사고가 된다
심화: drift 원복·가변 태그·파이프라인 시간 — 자동화 운영의 실전 함정
용어를 알았다면 다음 질문은 '이 자동화가 실제 운영에서 어떻게 뒤통수를 치는가'입니다. CI/CD·GitOps의 함정은 대부분 자동화가 고장 나서가 아니라, 설계대로 잘 작동해서 생깁니다.
- GitOps는 손 수정을 되돌립니다: 자동 동기화(selfHeal)가 켜진 GitOps에서 클러스터를 kubectl로 직접 고치면, 도구는 그것을 drift(Git과 다른 상태)로 보고 원복합니다. 장애 중 급히 올린 설정이 몇 분 뒤 사라지는 '유령 현상'의 정체입니다. GitOps에서의 빠른 길은 콘솔이 아니라 매니페스트 저장소에 올리는 한 줄 커밋이며, 정말 급할 때 auto-sync를 잠시 끄는 절차를 런북에 합의해 둬야 합니다(ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기).
- 가변(mutable) 태그는 롤백을 배신합니다: latest나 재사용되는 v1.3 같은 태그는 시점에 따라 다른 이미지를 가리킬 수 있습니다. '테스트한 것과 배포한 것이 동일'하려면 태그가 아니라 불변 식별자(digest·고유 빌드 태그)로 배포해야 합니다 — '롤백했는데 같은 버그'는 대부분 태그가 덮어써진 경우입니다.
- 파이프라인 시간은 행동을 바꿉니다: CI가 10분이면 작게 자주 커밋하지만, 40분이 되면 커밋을 몰아치고 게이트 우회를 요청하기 시작합니다(CI/CD 파이프라인의 fail fast 붕괴). 파이프라인 소요 시간을 개발 속도 지표로 추적하고 캐시·병렬화로 예산 안에 유지하는 것이 플랫폼팀의 일입니다.
- 캐시는 빠름과 맞바꾼 재현성입니다: 빌드 캐시가 낡으면(stale) '내 로컬은 되는데 CI만 실패' 또는 그 반대가 생깁니다. 원인 불명의 빌드 실패에서 '캐시 없이 클린 빌드'가 표준 1차 격리 수단인 이유입니다.
그래서 성숙한 팀은 배포 규칙을 문서가 아니라 시스템으로 강제합니다 — force push는 보호 규칙으로, 수동 변경은 drift 알람으로, 태그 불변성은 레지스트리 설정으로 막습니다.
상황: 새벽에 서비스 파드가 메모리 부족(OOMKilled)으로 반복 재시작해, 온콜이 kubectl로 메모리 limit을 512Mi에서 1Gi로 올려 안정화했습니다. 그런데 30분 뒤 같은 장애가 재발했고, 다시 올려도 얼마 후 또 재발했습니다. 설정을 보면 limit이 512Mi로 돌아와 있는데, 바꾼 사람이 아무도 없습니다.
원인: ArgoCD의 자동 동기화 + selfHeal입니다. Git 매니페스트에는 여전히 512Mi가 선언돼 있으므로, ArgoCD는 클러스터의 1Gi를 'Git과 다른 drift'로 감지해 Git 상태로 원복했습니다. 도구는 정확히 설계대로 동작했고, 사람이 GitOps의 규칙 — 진실 원천은 클러스터가 아니라 Git — 을 벗어난 것입니다.
진단: ArgoCD의 앱 이벤트·sync 이력에서 자동 sync 시각과 장애 재발 시각이 일치하는지 확인합니다. kubectl 수정 직후마다 OutOfSync → 자동 sync → Synced 기록이 반복돼 있으면 확정입니다.
해결: (1) 당장은 매니페스트 저장소에서 limit을 1Gi로 고치는 한 줄 커밋을 올려 머지합니다 — GitOps에선 이것이 가장 빠르고 안전한 긴급 경로입니다. (2) 런북에 '긴급 시 auto-sync 일시 중지 → 수동 조치 → Git 반영 → sync 재개' 절차를 합의해 두고, drift 발생을 온콜이 알람으로 인지하게 합니다(ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기). (3) 사후에는 메모리 증가의 근본 원인을 분석하고, 이번 임시 상향을 Git에 정식 반영합니다. 자동화된 시스템에서 가장 큰 장애 요인은 시스템의 규칙을 모르는 손입니다.
인프라/플랫폼으로서 CI/CD·GitOps는 당신이 만들고 지키는 배포 시스템입니다 — 파이프라인 스테이지·아티팩트 보관·브랜치 보호·GitOps 동기화를 설계합니다(CI/CD 파이프라인·ArgoCD로 소스 코드 저장소와 클러스터 상태 동기화하기). 깊은 내용은 본론(git-fundamentals·branch-strategy·cicd-pipeline)과 Kubernetes 트랙에 있습니다. PM은 이 용어로 배포 상태("어느 스테이지서 막혔나", "sync 됐나")를 읽고, 릴리스 일정과 리스크를 정확히 가늠합니다. "배포 실패"를 build/test/deploy 중 어디인지 구분하는 것만으로 대응 속도가 달라집니다.
다음 용어사전에서는 배포된 시스템을 들여다보는 관측성·장애 분석 용어를 정리합니다.
용어 식별 실습으로 굳히기: 용어 식별 — CI/CD / Git / 배포 — 증상·문구를 보고 Git·CI·배포 용어를 가려내고 헷갈리는 짝을 구분합니다.