업그레이드 재감사는 이전 감사의 이름을 이어 쓰는 것으로 충분하지 않습니다. 무엇이 바뀌었는지, 어느 두 버전 사이를 검토했는지, 기존 상태와 새 코드의 상호작용까지 포함했는지 확인해야 합니다. 차이 감사는 지정된 변경 범위를 검토하는 방식이므로 전체 코드와 운영 설정을 모두 다시 감사했다는 의미로 확대하면 안 됩니다.
예전 감사 배지가 새 버전까지 설명하지는 않습니다
프로젝트 소개 페이지에 감사 로고가 여러 개 있어도 최신 업그레이드가 그 감사 대상에 포함됐는지는 별도입니다. 저장소 이름이 같다는 이유만으로 서로 다른 커밋에 대한 검토가 이어진다고 볼 수 없습니다. 재감사 공지를 읽을 때는 이전 버전과 새 버전의 경계부터 찾습니다.
변경은 새 함수 추가만을 뜻하지 않습니다. 수수료 계산, 권한 검사, 외부 오라클 주소, 라이브러리 버전이나 초기화 순서가 바뀌어도 동작 조건은 달라질 수 있습니다. 코드 줄 수가 적다고 영향도 작다고 판단하기 어렵기 때문에 공지의 변경 요약과 실제 감사 범위를 연결해야 합니다.
새 버전의 안전성 주장은 이전 감사의 명성보다 이번에 검토한 경계에서 출발합니다.
JOBCOIN 편집 기준
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 예전 감사 배지가 새 버전까지 설명하지는 않습니다
프로젝트 소개 페이지에 감사 로고가 여러 개 있어도 최신 업그레이드가 그 감사 대상에 포함됐는지는 별도입니다.
- 차이 감사는 시작 커밋과 끝 커밋을 함께 읽습니다
차이 감사는 정해진 기준 버전에서 새 버전으로 바뀐 부분을 중심으로 검토합니다.
- 변경 내용을 네 가지 검토 대상으로 나눕니다
독자는 상세 코드를 모두 해석하지 못해도 변경 목록을 분류할 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
차이 감사는 시작 커밋과 끝 커밋을 함께 읽습니다
차이 감사는 정해진 기준 버전에서 새 버전으로 바뀐 부분을 중심으로 검토합니다. OpenZeppelin이 2026년 3월 2일 공개한 UMA and Across Incremental Audit은 세 저장소의 서로 다른 범위를 나누고 기준 커밋과 대상 커밋을 제시합니다. 이는 ‘재감사’라는 말 뒤에 어떤 범위 설명이 있어야 하는지를 보여 주는 사례입니다.
해당 보고서는 각 범위의 변경 개요와 신뢰 가정도 분리합니다. 독자가 알아야 할 점은 세 범위가 있다는 사실이 프로토콜의 모든 구성 요소를 한꺼번에 다시 감사했다는 뜻은 아니라는 것입니다. 이 글은 보고서 형식을 설명하며, 그 이후 운영 버전의 상태를 독립적으로 보증하지 않습니다.
기준 커밋이 이전 감사의 최종 수정본과 연결되는지도 확인합니다. 사이에 다른 변경이 들어갔다면 그 구간이 검토되지 않았을 가능성이 있습니다. 단순히 날짜순으로 보고서를 나열하기보다 버전 사이를 이어 그려 보면 어떤 변경 구간의 설명이 빠졌는지 찾기 쉽습니다.
변경 내용을 네 가지 검토 대상으로 나눕니다
독자는 상세 코드를 모두 해석하지 못해도 변경 목록을 분류할 수 있습니다. 계산식과 호출 경로는 실행 로직, 변수 구조는 상태 호환성, 역할과 주소는 설정·권한, 오라클과 브리지는 외부 의존성으로 나눠 봅니다. 한 항목이 여러 범주에 걸칠 수 있으므로 겹치는 검토도 표시합니다.
예를 들어 가격 오라클을 교체하는 가상 업그레이드에서는 새 계약 호출만 검토해도 충분하지 않을 수 있습니다. 가격의 소수점 자리, 갱신 지연 처리, 예전 캐시 상태, 관리자 설정이 함께 영향을 줍니다. 이 예시는 특정 서비스 결함을 주장하는 사례가 아니라 검토 질문을 만드는 방법입니다.
| 변경 종류 | 검토 질문 | 함께 볼 자료 |
|---|---|---|
| 함수·계산식 | 실패 조건과 경계값이 바뀌는가 | 변경 커밋·회귀 시험 |
| 저장 상태 | 이전 값이 새 코드에서 같은 뜻인가 | 저장소 배치 비교·이전 시험 |
| 초기화·권한 | 누가 어떤 순서로 실행하는가 | 배포 스크립트·권한 목록 |
| 외부 의존성 | 새 응답·장애 조건을 처리하는가 | 인터페이스·설정·신뢰 가정 |
기존 상태를 가진 계약의 이전 시험을 확인합니다
새 계약을 빈 상태로 배포한 시험과 오래 운영한 계약을 업그레이드한 시험은 출발점이 다릅니다. 잔액, 대기 중인 출금, 이미 부여된 역할 같은 기존 값이 새 코드에서 어떻게 해석되는지 확인해야 합니다. 새 기능이 정상 실행됐다는 시험만으로 이 모든 이전 경로를 검증했다고 볼 수 없습니다.
OpenZeppelin의 Writing Upgradeable Contracts는 상태 변수의 순서와 타입 변경이 기존 저장값의 해석을 깨뜨릴 수 있다고 설명합니다. 상속 구조 변경도 영향을 줄 수 있습니다. 저장소 배치 충돌 해설에서 다루는 것처럼, 코드에서 보이는 이름보다 실제 슬롯과 값의 대응이 중요합니다.
초기화 역시 별도 확인 대상입니다. 새 구현의 필요한 초기화가 실행됐는지, 중복 실행이 막히는지, 설정 주소와 권한이 올바른지 봅니다. 공식 도구의 검증 항목이 있다고 해서 모든 사용자 정의 초기화 경로가 자동으로 확인되는 것은 아니므로 재감사 범위에 포함된 시험과 제외 조건을 읽습니다.
공개된 범위 밖 가정을 운영 조건으로 연결합니다
감사 보고서에는 관리자가 올바른 주소를 설정하고 외부 오라클이 정상 응답한다는 식의 신뢰 가정이 있을 수 있습니다. 이는 불필요한 부록이 아니라 코드가 성립하는 환경을 설명하는 부분입니다. 새 업그레이드가 그 가정을 바꿨다면 후속 검토나 운영 통제가 어떻게 달라지는지 확인합니다.
라이브러리를 최신 버전으로 바꿨다는 사실만으로 모든 위험이 줄었다고 단정하지 않습니다. 인터페이스, 저장소 구조, 반환값 처리처럼 통합 지점이 달라질 수 있기 때문입니다. 외부 의존성 자체의 감사와 이를 연결한 애플리케이션의 감사는 대상이 다르다는 점도 남겨야 합니다.
- 변경 전후 커밋과 감사 대상 파일을 대조합니다.
- 이전 최종 수정본에서 새 기준 버전까지 빈 구간이 없는지 확인합니다.
- 기존 운영 상태를 사용하는 이전 시험의 유무를 찾습니다.
- 설정값·관리자·외부 시스템에 관한 신뢰 가정을 읽습니다.
- 미검토 변경과 후속 감사 계획을 완료 항목과 구분합니다.
재감사 완료와 업그레이드 실행을 이어 확인합니다
재감사 보고서가 공개된 시점에는 업그레이드 제안이 아직 대기 중일 수 있습니다. 실행됐더라도 일부 네트워크나 계약만 대상일 수 있습니다. 그래서 공지에는 체인, 구현 주소, 적용 거래와 날짜가 연결돼야 운영 상태에 대한 설명이 됩니다. 같은 프록시 주소만으로 버전을 판단하지 않습니다.
수정 검토가 완료됐다는 문구 뒤에는 배포 과정의 변경이 없었는지도 남는 질문입니다. 보안 감사 후 조치 보고서의 항목 추적 방법을 함께 사용하면 지적 해결부터 운영 적용까지 근거가 이어집니다. 확인하지 못한 배포 단계는 미확인으로 적어야 감사 사실과 실행 사실이 섞이지 않습니다.
독자를 위한 결론은 ‘재감사를 또 받았다’보다 ‘어떤 변경 구간과 상태 이전을 검토했고, 어떤 설정과 외부 의존성은 가정으로 남았는가’에 답해야 합니다. 감사 횟수는 이 질문을 대신할 수 없습니다. 재감사 자료를 거래 판단의 신호로 쓰기보다 사용 중인 서비스의 기술 공시를 읽는 근거로 활용합니다.
자주 묻는 질문
차이 감사는 전체 감사보다 무조건 부족한가요?
목적과 기준 상태가 다릅니다. 안정된 기준 버전의 명확한 변경을 검토하는 데 사용할 수 있지만 기준 밖 코드와 중간 변경을 모두 포함했다고 주장하면 안 됩니다.
새 코드가 감사받았으면 이전 데이터도 안전하게 옮겨지나요?
코드 검토와 상태 이전 검증은 구분해야 합니다. 저장소 배치, 초기화, 대기 작업과 기존 권한을 포함한 시험이 어떤 범위로 수행됐는지 확인해야 합니다.
감사 보고서에 계약 주소가 없으면 거짓 자료인가요?
배포 전 검토일 수 있어 주소가 없다는 사실만으로 허위라고 볼 수 없습니다. 다만 운영 적용을 확인하려면 대상 커밋과 실제 배포를 연결하는 후속 자료가 필요합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
