Must I run every test suite for every Autofix change?

Use checks appropriate to the affected behavior and deployment risk. Broaden validation when the change or unresolved evidence requires it.

Is the generated PR summary enough for approval?

No. Read the relevant diff and validation evidence, and check assumptions against your application.

Can I roll back by changing the container tag?

Sometimes, but database or data migrations can require a restore. Check the application’s supported recovery process first.

What deployment evidence should I keep?

Keep the reviewed revision, built and running artifact identifier, relevant check result, deployment time, and recovery notes.

홈 서버에 배포하기 전에 에이전트 기반 자동 수정 변경 사항을 검토하고 테스트하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

GitHub Agentic Autofix official announcement cover artwork

Agentic Autofix 변경 사항을 검토할 때는 보고된 문제를 diff에서 관련 동작까지 추적하세요. 생성된 CodeQL 근거를 확인한 다음, 수정의 영향을 받을 수 있는 정상적인 사용 사례도 검증하세요. 비용이 큰 전체 시스템 테스트를 무조건 시작하기보다 해당 변경에 필요한 검사를 실행하세요.

홈 서버에 배포하기 전에 복구할 수 있는 애플리케이션 데이터를 보관하고 이전 이미지나 패키지를 기록해 두세요. 병합 승인, 빌드 성공, 대체 서비스 실행은 각각 별개의 단계입니다. 간결한 배포 기록에는 현재 사용자에게 제공 중인 정확한 아티팩트와 실패 시 복구 방법을 적어야 합니다.

코드를 살펴보기 전에 무엇을 읽어야 하나요?

원래 경고, 영향을 받는 경로, 제안된 설명, 보고된 검증 결과를 읽으세요. 저장소와 브랜치가 배포하려는 애플리케이션과 일치하는지 확인하세요. 인증, 사용자 입력 또는 설치 환경과 다를 수 있는 구성에 관한 가정이 있는지 살펴보세요.

Agentic Autofix 개요에서 제품이 어떤 작업을 시도하는지 설명합니다. 생성된 설명은 검토를 위한 안내일 뿐, 실제 diff를 확인하는 일을 대신하지 않습니다.

어떤 diff 변경 사항을 더 자세히 살펴봐야 하나요?

변경 사항	검토 질문
입력 처리	유효한 입력은 유지하면서 악의적인 입력을 거부하나요?
권한 부여	올바른 신원 및 권한 검사가 유지되나요?
구성	수정으로 노출 범위가 넓어지거나 보호 기능이 비활성화되나요?
종속성	업데이트가 지원되며 필요한가요?
테스트	버그를 받아들이는 대신 의도된 동작을 검증하나요?
관련 없는 편집	수정을 이해하기 쉽도록 삭제할 수 있나요?

패치에 관련 없는 리팩터링이 보안 수정과 뒤섞여 있다면 더 범위가 좁은 수정본을 요청하세요. 관련 부분만 담은 작은 diff가 평가와 복구에 더 쉽습니다.

작은 수정에는 어느 정도의 테스트가 충분한가요?

가장 적절한 검사를 사용하세요. 영향을 받는 파서 입력, 경로 권한, 파일 작업 또는 기존의 집중 테스트를 확인하세요. CodeQL 결과는 별도로 확인하세요. 프로덕션에 중요한 경로나 마이그레이션이라면 더 폭넓은 검증이 타당할 수 있지만, 작고 독립적인 수정에는 그렇지 않을 수 있습니다.

통과 결과를 지어내지 마세요. 실제로 실행한 것과 아직 검증되지 않은 것을 기록하세요. 집중 워크플로 검증 가이드에서도 명시적인 승인 기준이라는 같은 원칙을 따릅니다.

배포 전에 무엇을 준비해야 하나요?

필요한 경우 애플리케이션 일관성이 유지되는 데이터베이스 백업, 복구 가능한 데이터 사본, 구성, 이전 아티팩트 참조를 보관하세요. 마이그레이션을 되돌릴 수 있는지 확인하세요. 데이터 변경 사항을 안전하게 되돌릴 수 없다면, 간단한 이미지 다운그레이드가 가능하다고 약속하는 대신 복원 기반 복구 계획을 문서화하세요.

애플리케이션의 상태에 맞춰 복구할 수 있도록 복구 가능한 파일 가이드와 Docker 애플리케이션 업데이트 안내를 활용하세요.

실행 중인 홈 서버 서비스를 어떻게 검증하나요?

검토된 빌드를 배포하고, 새 서비스가 의도한 아티팩트를 실행 중인지 확인한 다음, 변경 사항의 영향을 받는 핵심 사용자 작업을 수행해 보세요. 리비전, 이미지 다이제스트 또는 패키지 버전, 시간, 결과를 저장하세요. 서비스 프로세스는 디스크의 파일이 업데이트된 뒤에도 계속 실행될 수 있습니다.

보안 권고 및 배포 기록 가이드를 활용하면 추적 가능성이 높아집니다. ZimaCube 2에 복구 기록과 결과물을 저장하고, 업데이트 절차는 실행 중인 애플리케이션에 맞게 유지할 수 있습니다.