요약
배포 워크플로는 base path를 빌드 타임에 동적으로 정한다(Pages API의 cname 유무로 / 또는 /{repo}/). 그런데 Next/Vue CLI/SvelteKit/Gatsby/Astro는 config 파일이 이미 존재하면 경고만 출력하고 커밋된 값을 그대로 쓰고, Nuxt는 base 주입 지점이 아예 없다. 이 프레임워크들에서 커스텀 도메인을 연결하면 base가 /여야 하는데 커밋된 /{repo}가 이겨 자산이 전부 404가 된다.
Vite·CRA는 영향이 없다 — Vite는 vite build --base= CLI가 config를 덮어쓰고, CRA는 빌드 전에 package.json의 homepage를 강제로 다시 쓰기 때문이다.
근거 (DeployWorkflowTemplate.java)
config가 있으면 경고만 하는 지점:
:222 ::warning::next.config 파일이 존재합니다. output: 'export' 와 basePath: '$BASE' 가 설정되어 있는지 확인하세요.
:242 ::warning::vue.config 파일이 존재합니다. publicPath: '$BASE' ...
:277 ::warning::svelte.config 파일이 존재합니다. adapter-static 과 paths.base: '$BASE' ...
:302 ::warning::gatsby-config 파일이 존재합니다. pathPrefix: '$BASE' ...
:328 ::warning::astro.config 파일이 존재합니다. base: '$BASE' ...
이들의 빌드 명령에는 base 주입 지점이 없다(pm.runScript("build")):
:337 cra -> pm.runScript("build") // 단, :189-193 에서 homepage 를 강제로 덮어씀 → 안전
:340 vue/vue3 -> pm.execBin("vite build --base=${{ steps.base.outputs.path }}") // 안전
:343 vue-cli -> pm.runScript("build")
:346 nextjs -> pm.runScript("build")
:352 sveltekit -> pm.runScript("build")
:359 astro -> pm.runScript("build")
:362 default -> pm.execBin("vite build --base=${{ steps.base.outputs.path }}") // 안전(Vite)
Nuxt는 resolveConfigStep(:171-181)에 케이스 자체가 없어 default -> ""로 빠지고 빌드도 nuxt generate라 100% 커밋된 nuxt.config 의존이다.
문제가 드러나는 시나리오: create-next-app·npm create astro·SvelteKit·Vue CLI·Nuxt는 스캐폴딩 시 config 파일을 만든다. 즉 현실에서는 생성 분기가 발화하지 않고 커밋된 값이 유일한 진실이다. 여기에 커스텀 도메인을 붙이면 Resolve base path는 cname을 읽어 path=/를 내놓지만(:77-95), 커밋된 config의 /{repo}가 그대로 이겨 자산 경로가 어긋난다.
참고: 이미 마련된 접합점
Build 스텝은 BASE_PATH와 PUBLIC_URL을 env로 주입한다(:111-112). config를 base: process.env.BASE_PATH ?? '/' 형태로 쓰면 모든 프레임워크에서 배포 타임 결정으로 통일할 수 있는 자리는 이미 있다.
수정 방향 (택일 필요)
- config 존재 시에도 base를 덮어쓴다 — CRA의 homepage 처리(
:189-193)와 같은 방식으로 각 config를 빌드 직전에 패치. 사용자 설정을 서버가 덮어쓰는 것이라 신중해야 하지만, base는 배포 대상 URL이 결정하는 값이므로 정당화 가능하다.
- 스캐폴딩 시 config를 env 기반으로 생성하도록 CODE 프롬프트를 고친다(
CodeAgentService.java:65-99에 현재 base 관련 지시 없음). 기존 저장소에는 소급 적용되지 않는다.
- 경고를 실패로 승격 — 최소 조치. 조용히 깨지는 대신 배포가 멈춘다.
Issue #111(프리뷰 base 흡수)과는 별개 층이다 — 그쪽은 프리뷰 게이트웨이, 이쪽은 실제 Pages 배포 결과물이다.
출처
다중 에이전트 조사(2026-08-15, Issue #111 해법 판정 과정). 인용한 코드 라인은 재확인 완료.
요약
배포 워크플로는 base path를 빌드 타임에 동적으로 정한다(Pages API의 cname 유무로
/또는/{repo}/). 그런데 Next/Vue CLI/SvelteKit/Gatsby/Astro는 config 파일이 이미 존재하면 경고만 출력하고 커밋된 값을 그대로 쓰고, Nuxt는 base 주입 지점이 아예 없다. 이 프레임워크들에서 커스텀 도메인을 연결하면 base가/여야 하는데 커밋된/{repo}가 이겨 자산이 전부 404가 된다.Vite·CRA는 영향이 없다 — Vite는
vite build --base=CLI가 config를 덮어쓰고, CRA는 빌드 전에package.json의 homepage를 강제로 다시 쓰기 때문이다.근거 (
DeployWorkflowTemplate.java)config가 있으면 경고만 하는 지점:
이들의 빌드 명령에는 base 주입 지점이 없다(
pm.runScript("build")):Nuxt는
resolveConfigStep(:171-181)에 케이스 자체가 없어default -> ""로 빠지고 빌드도nuxt generate라 100% 커밋된nuxt.config의존이다.문제가 드러나는 시나리오:
create-next-app·npm create astro·SvelteKit·Vue CLI·Nuxt는 스캐폴딩 시 config 파일을 만든다. 즉 현실에서는 생성 분기가 발화하지 않고 커밋된 값이 유일한 진실이다. 여기에 커스텀 도메인을 붙이면Resolve base path는 cname을 읽어path=/를 내놓지만(:77-95), 커밋된 config의/{repo}가 그대로 이겨 자산 경로가 어긋난다.참고: 이미 마련된 접합점
Build 스텝은
BASE_PATH와PUBLIC_URL을 env로 주입한다(:111-112). config를base: process.env.BASE_PATH ?? '/'형태로 쓰면 모든 프레임워크에서 배포 타임 결정으로 통일할 수 있는 자리는 이미 있다.수정 방향 (택일 필요)
:189-193)와 같은 방식으로 각 config를 빌드 직전에 패치. 사용자 설정을 서버가 덮어쓰는 것이라 신중해야 하지만, base는 배포 대상 URL이 결정하는 값이므로 정당화 가능하다.CodeAgentService.java:65-99에 현재 base 관련 지시 없음). 기존 저장소에는 소급 적용되지 않는다.Issue #111(프리뷰 base 흡수)과는 별개 층이다 — 그쪽은 프리뷰 게이트웨이, 이쪽은 실제 Pages 배포 결과물이다.
출처
다중 에이전트 조사(2026-08-15, Issue #111 해법 판정 과정). 인용한 코드 라인은 재확인 완료.