UI 버그 탐지 시스템 구축: 성공과 실패의 교훈

UI 버그 탐지 시스템을 처음부터 구축한 방법: 성공한 점과 실패한 점

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

개발 툴

대상자

  • 소프트웨어 개발자, QA 엔지니어, 테스트 자동화 담당자
  • 중간~고급 수준의 기술 이해가 필요 (오픈소스 라이선스, 데이터셋 생성, 모델 튜닝 기술 포함)

핵심 요약

  • 데이터는 가장 큰 도전 – 모델 훈련은 쉬우나, 다양한 품질의 데이터셋 생성에 대부분의 시간이 소요됨.
  • 라이선스 문제는 예상보다 더 중요 – YOLO NAS의 프리트레이닝 가중치 사용 시 오픈소스 의무 발생, 이를 회피하기 위해 자체 훈련으로 전환.
  • 합성 데이터 + 실제 데이터 = 최적 결과 – 실제 웹사이트와 합성 레이아웃, 수동 테스트 케이스를 결합하여 60% 이상의 UI 왜곡 상황 커버.
  • UI 버그 탐지는 단일 기능이 아닌 시스템Object DetectionPage-level Classification 두 가지 접근 방식 병행.

섹션별 세부 요약

1. 초기 목표와 접근 방식

  • 전체적인 E2E 테스트 시스템 구축 목표 – 단순한 링크 제공으로 웹사이트 자동 테스트 가능.
  • UI 버그 탐지로 시작 – 저비용, 빠른 결과를 위한 첫 번째 단계 선택.
  • 가볍고 모듈화된 아키텍처 설계 – 클라우드 API 대신 자체 모델 훈련으로 비용 절감.

2. 모델 선택과 라이선스 문제

  • YOLO NAS 선택 – 빠른 처리 속도, 문서화 완비, 객체 탐지에 적합.
  • 라이선스 분쟁 발생 – 프레임워크는 Apache 라이선스지만, 프리트레이닝 가중치 사용 시 코드 오픈소스 의무 발생.
  • 자체 훈련으로 전환 – 라이선스 문제 해결을 위해 자체 데이터와 인프라로 모델 재훈련.

3. 데이터셋 생성의 어려움

  • 실제 웹사이트 크롤링의 한계 – 스크립트 주입, 요소 변형, 스크린샷 캡처 과정에서 시간과 오류 발생.
  • 합성 데이터 도입 – 실제 사이트와 별도의 캐버스 기반 UI 레이아웃 생성으로 데이터 다양성 확보.
  • 합성 데이터의 한계 – UI 왜곡의 60%만 커버, 데이터 유사성 문제 발생.

4. UI 버그 범위 확장

  • 초기 문제 사항 – 불가독 텍스트, 요소 겹침, 레이아웃 파손.
  • 추가 발견 사항 – 글자 간격 불일치, 불필요 스크롤, 폰트 크기 불일치, 팝업 간섭 등.
  • 이미지 분류 기반 탐지 도입 – 전체 페이지 영향을 주는 버그(예: 누락 콘텐츠)는 이미지 분류로 처리.

5. 최종 시스템 설계

  • 두 가지 접근 방식 병행
  • Object Detection: 겹침 요소, 이미지 파손 탐지.
  • Page-level Classification: 레이아웃 문제, 콘텐츠 누락 탐지.
  • UI 버그 목록 확장 – 총 12가지 버그 유형 정의 (예: 오래된 스타일, 색상 일관성 문제 등).

결론

  • 핵심 팁 – 오픈소스 모델 사용 시 라이선스 점검 필수, 데이터셋 생성 시 실제+합성 데이터 혼합 사용, UI 버그 탐지는 복합 시스템으로 접근.
  • 실무 적용 예시 – Treegress 플랫폼에서 실제 도구로 구현, 뉴코딩 테스트 자동화에 시스템 통합.