실행 때 드러나는 API 오용을 앞당겨 찾는다
어도비는 Premiere Pro의 UXP 플러그인 개발을 위한 ESLint 패키지 @adobe/eslint-plugin-premierepro를 공개했다. 액션을 잘못된 범위에서 만들거나 트랜잭션 맥락을 빠뜨리는 실수는 플러그인을 불러올 때 명확하게 드러나지 않을 수 있다. 회사는 실행 취소의 이상, 상태 문제나 특정 조건의 충돌로 나타나는 사용 패턴을 편집 중에 점검하려는 도구라고 설명했다.
검사는 개별 규칙으로 구성돼 팀이 필요한 항목을 설정할 수 있다. 핵심 범주는 Action API의 범위와 사용 방식, 트랜잭션의 실행 취소 설명, 잠금 콜백으로 트랜잭션을 감싸는 패턴이다. 발표는 개발 시점의 정적 분석을 추가한 것이며 실제 편집 작업의 모든 오류나 호스트 앱의 충돌을 제거한다고 보장한 것은 아니다.
잠금과 트랜잭션의 범위를 검사한다
공식 규칙 목록에서 액션 생성 호출은 Project.lockedAccess 또는 Project.executeTransaction의 범위 안에 있어야 한다. CompoundAction의 addAction은 해당 트랜잭션 안에서 호출하고, 잠금·트랜잭션 콜백 내부의 비동기 작업과 액션 객체의 범위 밖 전달을 검사한다. 실행 전에 필요한 비동기 준비와 동기적인 변경 구간을 구분해야 하는 API의 사용 조건을 코드에서 확인하는 방식이다.
실행 취소 기록에 사람이 이해할 설명을 붙이는 prefer-undo-string은 경고 수준의 권장 규칙이다. executeTransaction을 lockedAccess로 감싸는 prefer-locked-access-wrapper도 권장 항목으로 제공한다. 액션의 잘못된 범위를 찾는 오류 규칙과 사용자가 변경을 알아보기 쉽게 만드는 경고를 구분해 적용할 수 있다.
타입 검사 여부에 따라 설정이 달라진다
공식 가이드는 문법 패턴을 보는 recommended 설정과 타입 정보를 사용하는 recommendedTypeChecked 설정을 나눈다. 전자는 일반 JavaScript나 TypeScript 프로젝트에서 쓸 수 있다. 후자는 typescript-eslint, 유효한 tsconfig와 Premiere 타입 정의를 갖춘 환경에서 실제 API와 액션 타입을 확인해 래퍼 함수 같은 간접 사용을 더 정확히 분석하도록 한다.
타입 기반 규칙은 대응하는 문법 기반 규칙을 대체하므로 보통 두 묶음을 모두 켤 필요는 없다. 이전 과정에서 함께 사용하면 같은 문제에 대한 중복 메시지가 나올 수 있다. 가이드는 플러그인과 @adobe/premierepro의 호환 버전을 맞추고, 에디터뿐 아니라 CI나 패키징 전에도 검사를 실행하는 개발 흐름을 제시한다.
추상화한 코드도 검사 대상에 포함한다
팀이 공통 유틸리티로 액션 생성과 변경을 감싸면 코드는 짧아지지만 호출 관계는 덜 직접적으로 보인다. 이름과 구문만 검사하는 도구가 놓칠 수 있는 지점이다. 이미 타입 검사 환경을 운영하는 팀이라면 실제 타입을 사용하는 규칙이 이런 추상화를 검토하는 데 유리할 수 있다. 반대로 간단한 JavaScript 플러그인은 문법 규칙부터 적용해 반복 실수를 줄일 수 있다.
이 선택에는 검사 비용과 설정 유지 부담도 따른다. 타입 정보가 프로젝트 소스를 제대로 포함하는지 확인해야 하고 분석 시간도 문법 검사보다 길 수 있다. 기존 코드에서 경고가 많이 발생한다면 메시지를 일괄 숨기기보다 실제 범위 이탈인지 이름 패턴의 오탐인지 구분하는 과정이 필요하다. 도구의 경고를 호스트 동작과 연결해야 규칙 도입의 효과를 판단할 수 있다.
실행 취소 경험까지 개발 기준으로 만든다
실행 취소 설명을 요구하는 규칙은 사용자 경험을 코드 검사의 대상으로 만든다는 점에서 눈에 띈다. 플러그인이 여러 편집을 한 번에 수행할 때 기록이 모호하면 사용자는 무엇을 되돌리는지 알기 어렵다. 범위와 비동기 사용을 엄격히 검사하는 항목에 더해 작업 의미를 명확하게 남기면, 변경의 정확성과 사용자의 이해를 함께 다룰 수 있다.
정적 분석을 통과한 뒤에도 실제 Premiere에서 편집·실행 취소·반복 실행을 확인하는 과정은 필요하다. ESLint는 코드에 드러난 패턴을 검사하며 문서 상태나 작업 순서가 만드는 모든 문제를 실행해 보는 도구는 아니다. 새 플러그인을 검토하는 팀은 범위 규칙을 공통 기준으로 두고, 자신이 지원하는 호스트 버전과 대표 작업의 결과를 함께 확인하는 흐름을 만들 수 있다.
출처
Adobe Developers Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
New ESLint Plugin Catches Common Premiere UXP Bugs (새 창)
