리다이렉트로만 살아 있던 주소: alpine/k8s 이미지 빌드 PR 이 7시간 37분 만에 병합되기까지

결과: 병합 (2026-10-17 11:30, alpine-docker/k8s#99). 사실은 GitHub 의 PR·댓글·타임라인·검사 기록, alpine-docker/k8s 소스(PR 의 바탕 커밋 4a10aa07), 기여 원장의 실측 원자료(리다이렉트·태그 선택 재현)와 초안, TT Lab 저장소의 파이프라인 정의에서 가져왔습니다. 시각은 한국 시간입니다.

목차

• 한 줄 요약
• 1. 무엇이 문제였나: 아직 깨지지 않은 것
• 2. 원인: 옮긴 저장소와 남은 주소
• 3. 무엇을 바꿨나: diff 요지
• 4. 반응: 「Thanks.」
  • 덤으로 찾은 우리 쪽 개선점
• 5. 배운 것: 오픈소스 기여 요령
• 링크

한 줄 요약

1. 무엇이 문제였나: 아직 깨지지 않은 것

이번에도 솔직히 적습니다. 무엇이 깨져서 고친 것이 아닙니다. 옛 주소는 리다이렉트를 따라가면 지금도 받아지고, 이 이미지의 빌드도 잘 돌고 있었습니다. 「언젠가 깨질 수 있는 것」을 미리 고친 PR 입니다.

TT Lab 과의 관계는 이렇습니다. TT Lab 저장소의 Jenkinsfile 은 파이프라인의 kubectl 컨테이너로 alpine/k8s:1.31.2 를 씁니다. 주석에 따르면 셸과 kubectl·helm 이 모두 있어서 「잠들어 기다리다 명령을 받는」 컨테이너 모양에 맞기 때문에 골랐습니다. 우리가 쓰는 이미지이기도 한 이 저장소의 빌드 스크립트를 2026-10-17 에 작은 프로젝트들을 훑는 묶음에서 읽다가 옛 주소 둘을 봤습니다.

PR 을 올리기 5분 전(10-17 03:48)에 curl 로 리다이렉트를 따라가며 상태 코드만 찍었습니다. 원자료는 기여 원장의 redirects.txt 이고, 서명이 붙은 자산 주소의 쿼리는 지우고 남겼습니다.

301 -> https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_Linux_amd64.tar.gz
302 -> https://github.com/eksctl-io/eksctl/releases/download/v0.231.0/eksctl_Linux_amd64.tar.gz
301 -> https://github.com/jqlang/jq/releases/download/jq-1.6/jq-linux64
302 -> https://release-assets.githubusercontent.com/…(서명 쿼리 지움)
API repos/weaveworks/eksctl -> eksctl-io/eksctl
API repos/stedolan/jq -> jqlang/jq

첫 줄의 301 이 옛 조직에서 새 조직으로 넘겨주는 단계이고, 그다음 302 는 GitHub 릴리스가 원래 하는 일(「최신판」을 실제 판으로, 판 주소를 자산 서버로)입니다. GitHub API 도 옛 저장소 이름을 물으면 새 이름을 돌려줍니다.

같은 자리에서 build.sh 가 어떤 태그를 굽는지도 그대로 돌려 봤습니다(tags.sh, 빌드·푸시 없이 목록만). 쿠버네티스 릴리스를 기본 페이지로 받아도, 100개씩 받아도 고르는 태그는 1.37.1 1.36.5 1.35.9 1.34.12 로 같았습니다. 의심했던 페이지 문제는 없어서 이 부분은 PR 로 만들지 않았습니다.

2. 원인: 옮긴 저장소와 남은 주소

줄 번호는 PR 의 바탕 커밋 4a10aa07 기준입니다.

• eksctl. AWS 오픈소스 블로그(2023-07-13)는 eksctl 을 Weaveworks 의 GitHub 조직에서 새 최상위 조직 eksctl-io 로 옮겼고, 옛 주소는 새 위치로 자동으로 넘겨준다고 적었습니다. 그래서 Dockerfile 58행 의 curl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/…" 는 3년 넘게 아무 일 없이 돌았습니다. README.md 25행 의 도구 목록 링크도 옛 주소였습니다.
• jq. build.sh 16행 과 latest_versions.sh 6행 이 jq 1.6 바이너리를 stedolan/jq 의 릴리스에서 받습니다. 이 jq 는 이미지 안에 들어가는 것이 아니라, 빌드 스크립트가 각 도구의 최신판을 GitHub API 로 물어볼 때 쓰는 도구입니다. 그래서 이 줄이 깨지면 이미지 하나가 아니라 빌드 스크립트의 판 조회 전체가 영향을 받습니다.

리다이렉트가 있으니 지금 당장 문제는 없습니다. 그래도 고칠 이유는 둘이었습니다. GitHub 의 저장소 이전 문서에 따르면 옛 자리에 같은 이름의 저장소나 포크가 새로 생기면 리다이렉트는 영구히 지워집니다(사용량이 많은 저장소는 옛 이름을 아예 은퇴시켜 다시 못 쓰게도 합니다). 리다이렉트는 남이 지켜 주는 약속이라 우리가 확인할 길이 없습니다. 그리고 curl -sL 은 실패해도 HTTP 오류를 종료 코드로 돌려주지 않으므로(-f 가 없음), 리다이렉트가 끊기면 빌드는 엉뚱한 응답 본문을 바이너리로 저장한 채 다음 단계에서야 이상하게 실패할 것으로 보입니다. 마지막 문장은 플래그로 따져 본 것이고 직접 끊어 보지는 않았습니다(미실측).

선례도 있었습니다. 같은 저장소의 #94(2026-09-01 병합)가 옮겨 간 sealed-secrets 저장소 주소를 똑같은 방식으로 고쳤습니다. 이번 PR 은 그 일을 남은 두 도구에 이어서 한 것입니다.

3. 무엇을 바꿨나: diff 요지

주소만 바꿨습니다. jq 의 판(1.6)도, 내려받는 방식도 그대로입니다.

 # Dockerfile
-    curl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_${ARCH}.tar.gz" | tar xz -C /tmp && \
+    curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$(uname -s)_${ARCH}.tar.gz" | tar xz -C /tmp && \
 # README.md
-- [eksctl](https://github.com/weaveworks/eksctl) (latest version when run the build)
+- [eksctl](https://github.com/eksctl-io/eksctl) (latest version when run the build)
 # build.sh, latest_versions.sh (같은 줄)
-curl -sL https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -o jq
+curl -sL https://github.com/jqlang/jq/releases/download/jq-1.6/jq-linux64 -o jq

jq 를 새 판으로 올리고 싶은 유혹이 있었지만, 판을 바꾸면 「주소만 바꿨다」는 이 PR 의 주장이 흐려지고 메인테이너가 확인할 것이 늘어납니다. 그래서 PR 본문에 「jq 판은 1.6 그대로 둔다」고 적었습니다. 본문에는 위 표, 「두 옛 주소 모두 301, GitHub API 도 옮긴 것으로 보고」라는 실측, #94 를 잇는다는 설명, AI 도움을 받아 찾고 쓰고 직접 검토했다는 문장을 넣었습니다.

이 저장소에는 CONTRIBUTING·AI 정책·CLA 가 없습니다. 그래도 다른 PR 과 같게 커밋에 DCO 서명과 SSH 서명을 붙였습니다. 이미지를 직접 빌드해 보지는 않았습니다. 멀티 아키텍처 빌더와 여러 도구를 새로 내려받아야 하는 일이라 이번에는 하지 않았고, 원장에도 「301 실측, 빌드 미실측」으로 적었습니다. 바뀐 것이 주소 넷뿐이고, 새 주소가 끝까지 받아지는 것은 위 리다이렉트 사슬로 확인했습니다.

4. 반응: 「Thanks.」

이 저장소의 CI 는 CircleCI 이고 빌드 작업은 master·main 브랜치에서만 돕니다. 그래서 PR 단계에는 검사가 하나도 없었고, 병합 직후에야 master 에서 빌드가 한 번 돌았습니다. 다만 build.sh 는 Docker Hub 에 이미 있는 태그는 다시 굽지 않습니다. 1분 22초라는 짧은 시간으로 보아 이번 빌드는 jq 를 받고 태그를 확인하는 데서 끝났고, Dockerfile 의 eksctl 줄까지는 가지 않은 것으로 보입니다. CircleCI 로그는 열어 보지 않았습니다(미확인). 새 쿠버네티스 패치 판이 나와 실제로 이미지를 굽는 날 eksctl 줄이 쓰입니다.

메인테이너는 저장소 기여자 목록에서 커밋 64개로 둘째(6개)와 크게 차이 나는, 사실상 혼자 저장소를 돌보는 사람입니다. 초안을 쓸 때 본 최근 외부 PR 의 병합 시간은 #94 가 당일(약 2시간 14분), #86 이 하루 안, #88 이 5일이었습니다. 이번 7시간 37분은 그 사이에 있습니다. 병합 커밋 cf424d4c 의 저자는 우리 계정이고, 메시지는 우리 커밋 메시지 제목 끝에 PR 번호가 붙은 것입니다. 우리가 따로 대응할 일은 없었습니다.

덤으로 찾은 우리 쪽 개선점

1절의 태그 선택 재현 결과를 다시 보면, 이 저장소는 쿠버네티스의 최신 부 판 넷(지금은 1.37·1.36·1.35·1.34)만 새로 굽습니다. TT Lab 이 쓰는 1.31.2 는 이 목록에 없어서, 이번 수정을 포함해 앞으로의 도구 갱신이 들어가지 않습니다. 업스트림을 고친 것과 별개로, 우리 파이프라인의 이미지 태그를 지금 굽는 판으로 올리는 것이 다음 할 일입니다.

5. 배운 것: 오픈소스 기여 요령

• 리다이렉트는 고장이 아니라 유예입니다. 옮긴 쪽이 「옛 주소는 자동으로 넘겨준다」고 약속해도, 그 약속은 옛 이름 공간이 비어 있는 동안만 지켜집니다. 빌드 스크립트·Dockerfile 처럼 사람이 잘 다시 읽지 않는 곳일수록 오래 남습니다. curl -sIL 한 번이면 확인됩니다.
• 선례를 찾아 같은 모양으로 냅니다. #94 가 같은 종류의 수정을 이미 받아 준 것을 보고, 커밋 메시지에도 「#94 처럼」이라고 적었습니다. 메인테이너는 처음 보는 제안이 아니라 이미 받은 일의 후속을 보게 됩니다.
• 범위를 일부러 좁힙니다. jq 판 올리기, curl -f 더하기처럼 같이 하고 싶은 일이 있었지만 하나도 넣지 않았습니다. 「주소만」이라는 한 문장으로 설명되는 PR 은 검사가 없는 저장소에서도 메인테이너가 눈으로 바로 확인할 수 있습니다.
• 쓰는 이미지의 업스트림을 읽으면 우리 쪽 문제도 보입니다. 이번에 업스트림에 돌려준 것은 주소 넷이지만, 같은 조사에서 우리 파이프라인이 더는 갱신되지 않는 판을 쓰고 있다는 것을 알았습니다. 기여는 남을 위한 일이면서 우리 운영을 다시 보는 기회이기도 합니다.

티티 한마디. 친구가 이사를 가면서 「옛집으로 오는 편지는 새집으로 보내 줄게」 하고 약속했대요. 그래서 다들 3년 동안 옛 주소로 편지를 보냈죠. 그런데 그 옛집에 누가 새로 이사 오면 어떡해요? 주소록 네 줄을 새 주소로 고쳤더니 「고마워.」 한 마디가 돌아왔어요. 그러다 우리 집 주소록에도 아주 오래된 번호가 하나 있다는 걸 알았어요. 그것도 곧 고칠게요.

링크

모든 자료는 2026-10-17 에 열람했습니다.

• PR: alpine-docker/k8s#99 (병합 커밋 cf424d4c)
• GitHub 저장소 이전과 리다이렉트: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
• 선례: alpine-docker/k8s#94 sealed-secrets 저장소 주소
• 고친 파일(바탕 커밋): Dockerfile, README.md, build.sh, latest_versions.sh, .circleci/config.yml
• eksctl 저장소 이전 발표: AWS 오픈소스 블로그, 2023-07-13
• 새 저장소: eksctl-io/eksctl, jqlang/jq