배포 회의에서 듣습니다. "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-fundamentals]] | ★★ |
| Branch / Feature·Release·Hotfix Branch | 작업선 / 용도별 브랜치 | → [[branch-strategy]] | ★★ |
| Commit / Push / Pull / Fetch | 기록 / 올리기 / 받기·합치기 / 받기만 | 기본 흐름 | ★★ |
| Merge / Rebase / Cherry-pick | 합치기 / 재배치 / 특정 커밋만 가져오기 | 공유 브랜치 rebase 주의 | ★★ |
| Conflict | 같은 부분 다른 수정 충돌 | 정상, 자주 통합하면↓ | ★★ |
| Tag / Release Tag | 버전 표식 | 롤백 기준 → [[semantic-versioning]] | ★★ |
| Pull Request / Merge Request / Code Review | 머지 요청 / 리뷰 | 게이트 → [[code-review-pr]] | ★★ |
핵심: cherry-pick은 "특정 커밋 하나만" 다른 브랜치로 가져오기(핫픽스에 유용). rebase는 공유 브랜치엔 쓰지 않습니다(이력 재작성으로 협업 혼란). 충돌은 오류가 아니라 정상 — 작게 자주 통합하면 줄어듭니다([[branch-strategy]]).
파이프라인 · 빌드 산출물
CI/CD 스테이지와 아티팩트
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Pipeline / CI / CD | 자동화 흐름 / 통합 / 전달·배포 | → [[cicd-pipeline]] | ★★★ |
| Jenkins / GitHub Actions / GitLab CI | 대표 CI/CD 도구 | 파이프라인 정의 | ★★ |
| Runner / Agent | 파이프라인 실행 머신 | 빌드 환경 | ★ |
| Build / Test / Deploy Stage | 단계 | fail fast → [[cicd-pipeline]] | ★★ |
| Artifact / Build Artifact / Build Number | 빌드 산출물 / 빌드 번호 | 롤백 기준 → [[language-runtime-build]] | ★★ |
| Versioning / Semantic Versioning / Snapshot / Release | 버전 관리 / SemVer / 개발본 / 정식본 | → [[semantic-versioning]] | ★★ |
| Rollback Plan / Deployment Script | 롤백 계획 / 배포 스크립트 | 배포 안전 → [[release-strategy]] | ★★ |
핵심: "deploy 스테이지에서 artifact 못 찾음"은 빌드 산출물이 저장소에 없거나 버전 불일치 — 빌드 스테이지 성공 여부와 아티팩트 보관을 확인합니다.
GitOps · 자동화 · 테스트
선언적 배포와 테스트 종류
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Ansible / Playbook / Inventory | 구성 자동화 / 작업정의 / 대상목록 | IaC | ★ |
| ArgoCD / GitOps / Manifest Repo | 선언적 배포 / Git=진실원천 / 매니페스트 저장소 | → [[gitops-argocd]] | ★★ |
| Webhook Trigger | 이벤트로 파이프라인 시작 | push 시 자동 | ★★ |
| Build Failure / Compile Error | 빌드/컴파일 실패 | fail fast | ★★ |
| Unit / Integration / Smoke / Regression Test | 단위/통합/스모크/회귀 | → [[test-strategy]] | ★★ |
핵심: GitOps는 "Git에 선언한 상태 = 실제 상태"가 되도록 도구가 동기화합니다. 배포가 PR·이력으로 추적되고 롤백이 git revert로 가능해집니다([[gitops-argocd]]). 테스트 종류·피라미드는 [[test-strategy]].
배포 실패 해독 — 직접 확인
배포 실패는 어느 스테이지(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로 가기 전 차단"한 것 → 게이트 정상([[test-strategy]])
- deploy에서 "artifact not found"면 빌드 산출물 누락·태그 불일치 → 빌드 성공 여부와 레지스트리의 해당 태그 존재 확인([[semantic-versioning]])
- GitOps에서 OutOfSync가 오래 지속되면 자동 동기화 실패·수동 변경(drift) → argocd 상태와 매니페스트 저장소를 본다([[gitops-argocd]])
상황: 한 개발자가 여러 명이 함께 쓰는 공유 브랜치(develop)를 rebase하고 force push했더니, 다른 사람들의 로컬 이력과 어긋나 충돌이 폭발하고 일부 커밋이 사라진 것처럼 보입니다.
원인: 공유 브랜치에 rebase + force push는 이력을 재작성해, 그 브랜치를 기반으로 작업하던 모두의 히스토리를 깨뜨립니다. rebase는 '아직 공유 안 한 내 로컬 커밋 정리'에만 안전합니다([[branch-strategy]]).
진단:
git reflog # 사라진 듯한 커밋의 흔적(복구 단서)
git log --oneline origin/develop # 원격 이력이 재작성됐는지
해결: (1) reflog로 잃어버린 커밋을 찾아 복구. (2) 규칙 수립 — 공유 브랜치엔 rebase·force push 금지, 보호 규칙으로 force push 차단([[code-review-pr]]). (3) 통합은 merge로, rebase는 로컬 정리용으로만. force push는 거의 항상 위험 신호이며, 인프라/플랫폼팀이 브랜치 보호로 시스템적으로 막아야 합니다.
인프라/플랫폼으로서 CI/CD·GitOps는 당신이 만들고 지키는 배포 시스템입니다 — 파이프라인 스테이지·아티팩트 보관·브랜치 보호·GitOps 동기화를 설계합니다([[cicd-pipeline]]·[[gitops-argocd]]). 깊은 내용은 본론(git-fundamentals·branch-strategy·cicd-pipeline)과 Kubernetes 트랙에 있습니다. PM은 이 용어로 배포 상태("어느 스테이지서 막혔나", "sync 됐나")를 읽고, 릴리스 일정과 리스크를 정확히 가늠합니다. "배포 실패"를 build/test/deploy 중 어디인지 구분하는 것만으로 대응 속도가 달라집니다.
다음 용어사전에서는 배포된 시스템을 들여다보는 관측성·장애 분석 용어를 정리합니다.