에이전트가 작업을 마쳤는데, 운영 화면은 옛날로 돌아갔습니다

main에서 배포했다는 사실만으로 최신 화면을 보존할 수는 없었습니다. 같은 저장소의 다른 작업 폴더에 최신 코드가 있었고, 작업 에이전트가 그보다 오래된 소스를 다시 배포했습니다. 새 배포는 성공했지만 운영 화면은 옛날로 돌아갔습니다.

2026년 10월 5일 Triad 소개 화면에서 실제로 벌어진 일입니다. 소스, 빌드, 공개 화면을 따로 확인한 뒤 최신 화면과 검색 설정을 함께 복구했습니다.

배포 성공과 최신 배포는 달랐습니다

새벽에 최신 화면이 배포됐습니다. 오전에 검색 설정을 정리한 에이전트가 기본 저장소에서 다시 빌드해 배포했습니다. 그 기본 저장소에는 별도 작업 폴더에서 완성한 모션 변경이 아직 합쳐지지 않았습니다.

확인한 것	실제로 보장한 범위
빌드 성공	그 폴더의 코드가 빌드된다는 것
사이트맵과 응답 검사	검색 설정과 일부 주소가 정상이라는 것
배포 성공	새 파일이 운영에 올라갔다는 것
최신 화면 보존	위 검사만으로는 확인하지 못한 것

오류 화면이 뜬 것도 아닙니다. 페이지는 정상으로 열리고, 기능 일부도 동작했습니다. 그래서 최신 화면이 사라졌다는 사실을 뒤늦게 발견했습니다.

같은 저장소라도 작업 폴더의 HEAD는 다릅니다

Git worktree는 같은 저장소를 여러 폴더에서 작업할 수 있게 해줍니다. Git 공식 문서에서도 각 작업 폴더의 HEAD는 별개라고 설명합니다. 한 에이전트의 작업 완료가 다른 폴더의 소스 갱신까지 뜻하지는 않습니다. Git worktree 문서

먼저 어느 폴더에서 어느 브랜치를 보고 있는지 확인했습니다.

pwd
git branch --show-current
git status --short --branch
git worktree list
git log -5 --oneline

문제는 브랜치 이름만이 아니었습니다. 블로그 쪽도 현재 화면에 쓰던 변경이 커밋되지 않은 상태로 오래 남아 있었습니다. 운영에 표시된 커밋 번호와 실제 파일 내용이 달라질 수 있는 상태였습니다.

Cloudflare Pages의 배포 명령에는 미커밋 변경을 표시하는 --commit-dirty 옵션도 있습니다. 따라서 배포 화면의 커밋 번호 하나만으로 파일 내용이 정확히 같다고 단정하지 않았습니다. Wrangler Pages 명령 문서

단순히 이전 버전으로 돌리면 새 설정이 빠집니다

옛 화면을 덮은 배포에는 새 검색 설정이 들어 있었습니다. 정상 화면이었던 이전 배포로만 되돌리면 그 설정이 다시 빠질 수 있었습니다.

그래서 복구 기준을 두 개로 나눴습니다.

• 화면은 최신 모션 작업을 기준으로 복구한다.
• 검색 수집 안내·사이트맵·앱의 검색 제외는 새 설정을 유지한다.

두 변경을 기본 저장소에 합친 뒤 새로 빌드했습니다. 이후 최신 정상 빌드와 운영 소개 문서의 내용이 같음을 확인했습니다. 블로그에서 Triad로 이어지는 이동 주소도 그대로 남겼습니다.

다음 배포 전에 확인하는 네 가지

1. 운영 버전을 먼저 적어 둡니다

어느 배포가 현재 운영인지 확인합니다. 검수 시작과 배포 직전에 같은 버전인지 다시 봅니다. 사이에 다른 배포가 생겼다면, 그 변경을 확인하기 전에는 덮지 않습니다.

2. 현재 수정사항을 보존합니다

브랜치를 바꾸거나 합치기 전에 미커밋 파일과 새 파일을 백업합니다. 필요한 변경을 확인하고 커밋합니다. git reset --hard로 깨끗하게 만드는 것은 최신화가 아닙니다.

3. 확인한 소스에서 새로 빌드합니다

여러 에이전트가 공용 dist를 쓰면 어느 작업에서 만든 결과인지 흐려집니다. 이번에는 검수용 빌드 폴더를 따로 만들어, 소스와 출력물을 함께 확인했습니다.

같은 이름의 폴더라도 빌드 시점이 다르면 다른 파일입니다. 브랜치뿐 아니라 어느 소스로 언제 만든 출력물인지 남겨야 합니다.

4. 공개 파일까지 대조합니다

로컬 파일끼리 같은 것만으로 운영 일치를 증명할 수는 없습니다. 실제 주소를 요청해 문서·스크립트·이동 규칙을 확인합니다.

호스팅이 방문 분석 코드나 이메일 보호 코드를 덧붙이면 HTML이 그대로 같지는 않을 수 있습니다. 그때는 확인한 호스팅 변환만 구분하고 본문과 스크립트가 같은지 봅니다. 차이가 있다는 이유로 내용을 임의로 삭제해 비교하지 않습니다.

블로그의 기본 main을 정리한 뒤에는 전체 공개 파일을 대조했습니다. 내용이 다르게 남은 파일은 없었고, 옛 Triad 소개 주소는 예상대로 체험 사이트로 이동했습니다.

main을 고정해도 확인은 끝나지 않습니다

기본 폴더의 main과 커밋된 소스에서만 배포하도록 검사도 추가했습니다. 그래도 직접 지정한 빌드 폴더가 오래된 것인지, 검수 도중 다른 사람이 배포했는지까지 그 검사 하나가 알아주지는 않습니다.

현재 정한 순서는 운영 버전 확인 → 소스 보존·통합 → 새 빌드 → 공개 파일 대조 → 배포 기록입니다. 에이전트가 “완료”라고 말했을 때 어느 단계까지 확인한 것인지 이 순서로 다시 봅니다.

같은 서비스에서 겪은 다른 운영 문제는 무료 데이터베이스의 읽기 한도를 넘긴 기록에 적었습니다. 현재 Triad 화면과 체험의 범위는 제품 소개에서 확인할 수 있습니다.