확장 프로그램을 안전하게 관리해보자 — UI 변경 시 에러로 드러내기

확장 프로그램을 안전하게 관리해보자 — UI 변경 시 에러로 드러내기

앞 글 두 편을 거치며 VPN 확장 자동화를 완성했다. 그런데 확장이 업데이트되면 선택자가 바뀌어 자동화가 조용히 실패한다. 버전마다 선택자를 관리하고, UI가 바뀌면 즉시 에러로 드러내도록 해보자.

1. 서론 (Introduction)

• 문제/상황 (Problem):
  • 확장 v3.x → v4.x 전환 때 .location-country가 .simple-location으로 바뀌었다. 선택자 오류는 조용히 None으로 삼켜지고, 자동화는 국가를 선택하지 못한 채 연결을 시도한다.
  • 현재 선택자가 코드에 하드코딩되어 있어, 확장이 업데이트되면 어디서 무엇이 깨졌는지 바로 알 수 없다.
• 목적 (Purpose):
  • 버전별 선택자를 한 곳에서 관리하고, 팝업을 열어 핵심 선택자가 실제로 존재하는지 확인해 업데이트가 자동화를 조용히 죽이지 않도록 한다.
• 대상 (Target Audience):
  • 크롬 확장 자동화를 운영 중이고, 확장 업데이트 후 갑자기 실패하는 경험을 한 개발자

2. 방법 및 과정 (Methods & Process)

• 배경 조사 및 데이터 (Data Collection):
  • v3.x → v4.x 선택자 변경 내역:

역할	v3.x	v4.x
국가 행(단일 지역)	.location-country	.simple-location
국가명 텍스트	.location-country__header	.simple-location__country-name
프리미엄 잠금	.location-country--blocked	.simple-location__crown
복수 지역 국가 행	(없음)	.multi-region-location__country
검색 필터	(없음)	.search-input__input
온보딩 버튼	.intro-steps__btn (1단계)	4단계로 증가

바뀐 선택자를 하드코딩으로 추적하면 결국 같은 문제를 반복한다. 버전 → 선택자 매핑 테이블을 분리해 관리하는 것이 핵심이다.

• 접근 방법 (Approach Methods):
  • [방법 1]: 버전 핀 — manifest.json에서 major 버전을 읽어 선택자 테이블에서 해당 버전의 집합을 꺼낸다. 모르는 버전이면 즉시 RuntimeError — 실패가 표면으로 드러난다.
  • [방법 2]: UI 검증 — Playwright로 팝업을 열고 온보딩을 건너뛴 뒤, 필수 선택자(.connect-region__location, .connect-button)가 실제로 존재하는지 확인한다. 없으면 즉시 에러와 안내 메시지를 출력한다.
• 분석 및 해결 프로세스 (Analysis Flow):
  • 도구/기술: Python, playwright, pyvirtualdisplay
  • 주요 단계: manifest.json 버전 읽기 $\rightarrow$ major 버전으로 선택자 테이블 조회 $\rightarrow$ 모르는 버전 즉시 에러 $\rightarrow$ (선택) 팝업 열기 $\rightarrow$ 온보딩 건너뛰기 $\rightarrow$ 필수 선택자 존재 확인 $\rightarrow$ 누락 시 에러 + 안내
  • 선택자 테이블 구조: _SELECTOR_TABLE은 major 버전 문자열(“4”, “3”)을 키로, 온보딩 순서(onboarding)·지역 버튼(region_btn)·연결 버튼(connect_btn) 등 선택자 묶음을 값으로 갖는 딕셔너리다. get_selectors(version)은 version.split(".")[0]으로 major를 뽑아 테이블에서 조회하고, 없는 major면 그 자리에서 RuntimeError를 던진다.
  • 결과 도출 및 검증: python ext_manager.py → 버전 4.0.0 읽기, 선택자 테이블 출력 정상. python ext_manager.py --verify → 팝업 열어 필수 선택자 확인: UI 검증 통과: 모든 필수 선택자 확인됨.

3. 결과 (Results)

• 분석 결과 요약:
  • 확장 버전을 manifest.json에서 읽어 선택자 테이블과 대조하면, 모르는 버전이 배포되는 순간 자동화가 즉시 멈추고 “테이블 업데이트 필요”를 알린다.
  • UI 검증 모드(--verify)는 팝업을 실제로 열어 핵심 선택자의 존재를 확인한다. 새 버전을 테이블에 추가한 뒤 검증을 통과해야 배포할 수 있는 게이트 역할을 한다.
  • v3.x 선택자도 테이블에 남아있다. 이전 환경에서 구버전 확장을 쓰더라도 그대로 동작하고, 히스토리도 코드로 남는다.

4. 인사이트 및 액션 (Insights & Action)

• 인사이트 (Insight):
  • 선택자를 코드에 직접 박으면 버전이 바뀔 때 어디서 깨졌는지 알기 어렵다. 버전 → 선택자 매핑을 테이블로 분리하면 차이가 한눈에 보이고, 추가·수정이 한 곳에서 끝난다.
  • manifest.json은 확장이 설치된 폴더에 항상 존재한다. 코드에 버전을 하드코딩하지 말고, 런타임에 읽어 비교하는 것이 유지보수에 유리하다.
  • 조용한 실패(None 반환, 빈 배열 무시)가 쌓이면 어디서 문제가 생겼는지 추적하기 어렵다. 모르는 버전은 즉시 에러, 선택자 누락도 즉시 에러로 드러내는 것이 낫다.
• 실행 방안 (Action Plan):
  • 확장이 자동 업데이트된 뒤 첫 실행 전에 python ext_manager.py --verify를 한 번 돌린다. 통과하면 배포, 실패하면 테이블을 먼저 업데이트한다.
• 한 줄 결론 (Key Takeaway):
  • 버전 → 선택자 테이블을 분리하고, 팝업 UI를 검증하면 확장 업데이트가 자동화를 조용히 죽이지 않는다. 샘플 코드
• 다음 스텝 (Next Step):
  • 지금은 major 버전 단위로만 선택자를 나눈다. 같은 major 안에서 minor 업데이트로 일부 선택자만 바뀌면 표에 반영되지 않은 채 그대로 통과된다. 검증 항목도 region_btn·connect_btn 두 개뿐이라, 온보딩 중간 단계의 선택자가 바뀌는 경우까지는 잡아내지 못한다.