Codex에서 GitHub 이미지 업로드 가이드(Codex 첫만남)

> 목적: 향후 사례 글 작성에 활용할 수 있도록 이미지 생성 후 GitHub 게시 과정의 오류와 해결 방법을 정리한다.

작업 목표

한 장의 4컷 스토리보드를 장면별 9:16 세로 이미지 네 장으로 재생성하고, GitHub 저장소의 assets/storyboard/ 폴더에 업로드하려 했다.

ALT

고양이가 있는 채팅창의 스크린샷

전체 흐름

1. 원본 4컷 스토리보드를 확인했다.

2. 각 장면을 독립적인 9:16 이미지로 재생성했다.

3. GitHub 플러그인을 설치하고 연결했다.

4. GitHub CLI 설치 여부와 로그인 상태를 확인했다.

5. 로컬 빈 Git 저장소를 원격 저장소에 연결했다.

6. 별도 브랜치에서 이미지 네 장만 커밋했다.

7. 원격 브랜치로 푸시하고 초안 PR을 생성했다.

결과적으로 작업은 성공했지만, 도구 설치·인증·샌드박스 권한·비공개 저장소 접근에서 여러 시행착오가 있었다.

시행착오와 해결 과정

시행착오 1: GitHub 플러그인만 연결하면 바로 업로드할 수 있다고 생각함

Claude Code

Codex

ALT

중국어 텍스트가 있는 검은색 화면의 스크린샷

처음에는 GitHub 플러그인을 설치하면 이미지 파일을 곧바로 저장소에 업로드할 수 있을 것으로 예상했다. 하지만 시작화면부터 클로드와 코덱스화면이 달라서 낯설어 적응하는데 힘들었다.

(윈도우 쓰다가 맥을 처음봤을때의 느낌이었다.)

ALT

한국어 한국어 한국어 한국어 한국어 한국어 한국어 한국어

클로드코드에선 레포지토리를 만들면 바로 코드를 사용할수 있는데, 코덱스에선 readme.md 파일이라도 커밋해야 시작이 가능했다.

그리고 실제 게시 작업에는 로컬 브랜치 생성, 커밋, 푸시가 필요했고 GitHub CLI도 요구됐다.

확인된 조건:

• GitHub 플러그인: 저장소·PR 등 GitHub 객체를 다루는 데 유용

• 로컬 git: 파일 스테이징, 커밋, 브랜치 작업에 필요

• GitHub CLI gh: 인증 확인, 저장소 정보 조회, PR 생성의 대체 경로에 필요

교훈:

> “GitHub 연결”과 “로컬 파일 게시”는 같은 단계가 아니다. 플러그인 연결 후에도 Git과 GitHub CLI 환경을 별도로 점검해야 한다.

시행착오 2: GitHub CLI가 설치되어 있지 않음

첫 확인에서 다음 오류가 발생했다.

gh : 'gh' 용어가 cmdlet, 함수, 스크립트 파일 또는 실행할 수 있는 프로그램 이름으로 인식되지 않습니다.

해결:

winget install --id GitHub.cli
gh auth login

교훈:

• 게시 워크플로를 시작하기 전에 gh --version을 먼저 실행한다.

• 설치 직후에는 현재 프로세스의 PATH가 갱신되지 않을 수 있다.

시행착오 3: 설치는 됐지만 PATH에 반영되지 않음

GitHub CLI 설치 후에도 gh 명령을 찾지 못했다. 기본 설치 위치를 직접 확인한 결과 실행 파일은 존재했다.

C:\Program Files\GitHub CLI\gh.exe

임시 해결:

& 'C:\Program Files\GitHub CLI\gh.exe' --version

근본 해결:

• 터미널 또는 Codex 앱을 재시작해 변경된 PATH를 반영한다.

교훈:

> “설치 실패”와 “PATH 미반영”을 구분해야 한다. 실행 파일의 기본 설치 위치를 먼저 확인하면 불필요한 재설치를 피할 수 있다.

시행착오 4: 웹 인증을 완료했다고 생각했지만 유효한 토큰이 없었음

GitHub CLI 상태를 확인했을 때 다음과 같이 표시됐다.

You are not logged into any GitHub hosts.

웹 기기 인증을 시작했지만 자동 브라우저 열기가 권한 문제로 실패했다.

Failed opening a web browser at https://github.com/login/device
Access is denied.

해결:

1. 브라우저에서 https://github.com/login/device를 직접 열었다.

2. 터미널에 표시된 일회용 코드를 입력했다.

3. GitHub 계정 접근을 승인했다.

4. gh auth status로 최종 확인했다.

보안을 위해 실제 일회용 인증 코드는 이 문서에 기록하지 않았다.

시행착오 5: 등록된 계정의 토큰이 무효 상태였음

계정은 설정 파일에 남아 있었지만 토큰이 유효하지 않아 API 요청이 거절됐다.

Failed to log in to github.com account [REDACTED]
The token in default is invalid.
HTTP 401: Requires authentication

해결:

gh auth login --hostname github.com --git-protocol https --web

그 후 다음 항목을 확인했다.

Logged in to github.com account [REDACTED]
Git operations protocol: https
Token scopes: 'gist', 'read:org', 'repo', 'workflow'

교훈:

• “계정이 등록되어 있음”은 “토큰이 유효함”과 다르다.

• 작업 직전에 gh auth status와 실제 저장소 조회를 모두 확인한다.

시행착오 6: Codex 샌드박스가 GitHub CLI 설정 파일을 차단함

로그인 정보를 읽으려 할 때 다음 오류가 발생했다.

failed to load config: open [USER_PROFILE]\AppData\Roaming\GitHub CLI\config.yml: Access is denied.

원인:

• GitHub 인증 실패가 아니라 Codex 샌드박스의 파일 접근 제한이었다.

해결:

• GitHub CLI 설정 폴더에 대한 최소 범위의 읽기·쓰기 권한을 승인했다.

• GitHub API 접근을 위한 네트워크 권한도 함께 승인했다.

교훈:

> 인증 오류처럼 보여도 실제 원인은 로컬 설정 파일 접근 권한일 수 있다. 오류 메시지에서 401과 Access is denied를 구분해서 봐야 한다.

시행착오 7: 현재 폴더가 커밋이 없는 빈 Git 저장소였음

초기 상태:

## No commits yet on master

또한 원격 저장소도 연결되어 있지 않았다.

해결 전략:

1. BominSon/v-auto의 기본 브랜치가 main임을 확인했다.

2. 원격 origin을 연결했다.

3. 원격 main을 가져왔다.

4. 안전한 작업 브랜치 agent/add-storyboard-images를 만들었다.

사용한 핵심 명령:

git remote add origin https://github.com/BominSon/v-auto.git
git fetch origin main
git checkout -B main --track origin/main
git checkout -b agent/add-storyboard-images

교훈:

• 로컬 폴더가 이미 원하는 저장소의 체크아웃이라고 가정하지 않는다.

• git status -sb, git remote -v, 기본 브랜치 확인을 먼저 수행한다.

시행착오 8: .git 메타데이터가 읽기 전용으로 제한됨

원격 연결과 브랜치 생성 과정에서 다음 오류가 발생했다.

could not lock config file .git/config: Permission denied
cannot open '.git/FETCH_HEAD': Permission denied
Unable to create '.git/HEAD.lock': Permission denied

원인:

• 작업 폴더에는 쓰기 권한이 있었지만 .git 내부 메타데이터는 별도 제한을 받고 있었다.

해결:

• 정확한 저장소의 .git 작업에 대해서만 권한을 승인했다.

• 이후 원격 연결, fetch, 브랜치 생성이 정상 완료됐다.

교훈:

> 일반 파일 쓰기 권한과 Git 메타데이터 쓰기 권한은 별개일 수 있다.

시행착오 9: 비공개 저장소에서 GitHub 앱의 PR 생성이 404로 실패함

이미지 브랜치 푸시는 성공했지만 GitHub 앱 커넥터로 PR을 생성할 때 다음 오류가 발생했다.

GitHub API error 404
Not Found

저장소가 비공개였고, 커넥터가 해당 PR 생성 경로에서 저장소를 찾지 못한 것으로 판단했다.

해결:

• 이미 인증된 GitHub CLI를 대체 경로로 사용했다.

gh pr create `
  --repo BominSon/v-auto `
  --base main `
  --head agent/add-storyboard-images `
  --draft `
  --title "Add vertical storyboard images" `
  --body-file [TEMP_PR_BODY]

결과:

• 원격 브랜치 푸시 성공

• 초안 PR 생성 성공

• 이미지 네 장만 변경 파일로 포함됨

교훈:

• API의 404는 단순히 저장소가 없다는 뜻뿐 아니라 권한 또는 커넥터 가시성 문제일 수도 있다.

• 커넥터 실패 시 gh를 대체 경로로 준비해 두면 작업을 중단하지 않을 수 있다.

잘된 점

이미지 파일만 명시적으로 스테이징

다음 네 파일만 경로를 지정해 추가했다.

assets/storyboard/storyboard-01-overwhelmed-9x16.png
assets/storyboard/storyboard-02-automation-9x16.png
assets/storyboard/storyboard-03-success-9x16.png
assets/storyboard-04-goodbye-9x16.png

git add -A를 사용하지 않아 기존 파일이나 무관한 변경이 섞일 위험을 줄였다.

기본 브랜치에 직접 푸시하지 않음

main 대신 별도 브랜치를 만들고 초안 PR을 열었다. 덕분에 GitHub에서 파일 목록과 결과를 확인한 후 병합할 수 있었다.

민감정보를 기록에서 제외

다음 정보는 문서에서 제거하거나 마스킹했다.

• GitHub 일회용 기기 인증 코드

• 인증 토큰

• 사용자 로컬 프로필 경로

다음번 권장 체크리스트

환경 확인

git --version
gh --version
gh auth status
git status -sb
git remote -v

저장소 확인

gh repo view OWNER/REPO --json nameWithOwner,defaultBranchRef,url,isPrivate

안전한 게시

1. 원격 기본 브랜치를 가져온다.

2. agent/... 형식의 작업 브랜치를 만든다.

3. 대상 파일만 명시적으로 스테이징한다.

4. git diff --cached --stat으로 범위를 확인한다.

5. 커밋 후 원격 브랜치로 푸시한다.

6. 초안 PR을 만들고 변경 파일 목록을 검증한다.

사례 글에 활용할 핵심 메시지

이번 작업의 핵심은 이미지 생성 자체보다 “생성된 결과물을 안전하게 기존 개발 워크플로에 연결하는 과정”에 있었다.

겉으로는 단순한 파일 업로드였지만 실제로는 다음 계층이 모두 맞아야 했다.

이미지 생성
→ 로컬 파일 정리
→ Git 설치와 저장소 상태
→ GitHub CLI 설치
→ 계정 인증과 토큰
→ 샌드박스 파일·네트워크 권한
→ 원격 저장소와 기본 브랜치
→ 안전한 커밋 범위
→ 브랜치 푸시
→ PR 생성

자동화에서는 성공 경로만 설계하는 것보다, 각 계층의 실패를 구분할 수 있는 진단 순서를 준비하는 것이 중요하다.