PAT 발급 → CDE Credential 생성 → Repository 등록 세 단계다. 여기서 가장 흔한 함정은 CDE UI 에 자격 증명을 만드는 화면이 없고 CLI 로만 만들 수 있다는 점이다.
CDE 는 표준 HTTPS Git clone 만 수행하므로 토큰 종류를 가리지 않는다. 연동 용도라면 classic PAT 이 호환성이 좋고 단순하다. GitHub 이면 repo 스코프 하나만, GitLab 이면 read_repository 하나면 충분하다. workflow · admin:* · delete_repo · write:packages 는 체크하지 않는다. Org 가 SSO 를 강제하면 발급 직후 Configure SSO → Authorize 를 눌러야 Org 저장소 호출이 통과한다.
저장소가 그룹 소속이라면 Project access token 이나 Group access token 이 더 깔끔하다. 사용자가 조직을 떠나도 영향이 없고 bot user 로 동작한다.
토큰 자체의 유효성과 저장소 접근 권한을 분리해서 확인해야 원인이 빨리 좁혀진다.
read -s GH_PAT && export GH_PAT
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer ${GH_PAT}" \
https://api.github.com/user # 200 이면 토큰 살아 있음
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer ${GH_PAT}" \
https://api.github.com/repos/<OWNER>/<REPO> # 200 권한 OK / 404 권한 없음 / 401 SSO 미인가
git ls-remote https://x-access-token:${GH_PAT}@github.com/<OWNER>/<REPO>.git
cde credential create --name git-myproject-cred --type basic --username <git-username>
# password 프롬프트에 Git 로그인 암호가 아니라 PAT 문자열을 붙여 넣는다
cde repository create --name my-project-repo \
--repository-url https://github.com/<OWNER>/<REPO>.git \
--branch main --credential git-myproject-cred
cde repository list
cde repository sync --name my-project-repo
토큰에 write 권한이 있든 없든 CDE Repository 화면은 read-only 로 강제된다. 파일 트리는 보이지만 편집 · 업로드 · 삭제 버튼 자체가 노출되지 않는다. CDE 가 Git 에 하는 동작은 clone 과 fetch 뿐이고 push 경로가 아예 없다. Git 이 유일한 정본이고 CDE 는 미러라는 설계다. 따라서 토큰은 read-only 로 충분하고, write 를 줘도 쓰이지 않는 잉여 권한이다.
CDE 는 주기적 polling 이나 sync 스케줄 설정을 제공하지 않는다. push 후 누군가 cde repository sync 를 불러야 반영된다. 실행 중인 job 의 코드가 바뀌거나 검토되지 않은 커밋이 자동 반영되는 것을 막으려는 의도적 설계로 보인다. 자동화하려면 push 이벤트에 붙은 CI 에서 sync 를 호출하거나 사내 cron 으로 주기 호출한다.
그리고 job 타입에 따라 이후 절차가 다르다. Spark job 은 실행 시점에 파일 경로를 그때그때 읽으므로 sync 만 하면 다음 run 부터 새 코드를 쓴다. 반면 Airflow job 은 DAG 폴더에 파일이 배포돼야 하므로 강제 업데이트가 필요하다. 공식 문서도 "Unlike a Spark job, the Airflow job does not automatically pull in the updated resource" 라고 명시한다.
git push
cde repository sync --name my-project-repo
cde job update --name my-airflow-job --dag-file <path> # Airflow job 만
| Repository (Git 연동) | Files Resource | |
|---|---|---|
| 출처 | 외부 Git | 직접 업로드 |
| UI 편집 | 불가 | 가능 |
| 갱신 | cde repository sync |
UI · CLI 업로드 |
| 정본 | Git | CDE 내부 스토리지 |
| 이력 | commit · blame · diff | 없음(덮어쓰기) |
| 롤백 | git revert 후 sync |
로컬 백업이 없으면 불가 |
Repository 의 실익은 이력 · 롤백 · 코드 리뷰 · 환경 간 승격이다. dev · staging · prod 를 브랜치로 나눠 각 클러스터가 자기 브랜치를 보게 하면 같은 코드를 환경마다 따로 올릴 필요가 없다.
각 CDE 클러스터는 독립적으로 Git 에 접근해 자기 미러를 갱신하므로, PC 가 Git 원격과 각 클러스터의 JOBS API 두 경로만 닿으면 여러 클러스터에 동시 배포할 수 있다. 클러스터끼리 서로 알 필요도, 네트워크로 연결될 필요도 없다.