반갑습니다 SKT AI Fellowship 5기 12팀 슼나무입니다!

저희는 그동안 ‘APP 서비스 및 5G 성능 분석을 위한 영상/이미지 분석 기술’을 위해 Object Detection모델과 서버 인프라를 열심히 개발하였는데요,

이번 포스트를 통해 연구 과정과 현황을 공유해 드리고자 합니다.

• 연구 계획

1. 개요

우선 저희가 해결하고자 하는 문제를 다시 한번 소개해 드리고, 지금까지의 연구를 통해 구체화된 목표까지 말씀드리겠습니다!

1.1 문제 정의

실생활에서, 그리고 업무 환경에서 다양한 App을 사용하시죠?

App을 통해 좋은 경험을 하실 수 있도록, 개발뿐만 아니라 테스트까지, 그리고 출시 전부터 출시 후까지 많은 사람들이 고민하고 열심히 노력합니다.

그런데 App을 업데이트할 때마다 신규 기능에 문제는 없는지, 기존 기능과 충돌을 일으키지는 않는지 확인할 필요가 있습니다. 자연스럽게 테스트 항목도 함께 증가하지요.

이를 도와 빠르고 정확하게 테스트를 진행하도록, 다양한 자동화 테스팅 Tool이 존재합니다.

하지만 App 서비스를 개발할 때 사용하는 환경이 다양하다면요? 서로 다른 개발환경에서 개발된 기능을 테스트해야 하므로,

App이 만들어진 다양한 과정도 이해해야 하고, 다양한 도구도 사용할 줄 알아야 정상적인 테스트가 가능합니다.

여전히 테스트를 향한 길이 멀고도 험합니다.

그래서 저희는 Object Detection Model을 도입하여 App의 개발 환경이나 테스트 도구에 의존하지 않는,

독립적인 테스트 환경을 구축하려고 합니다. 이를 통해 쉽고, 편하고, 빠른 테스트 환경을 만드는 것이 목표입니다.

1.2 연구 목표

1.2.1 자동화 테스트 진행 과정

연구에 대한 설명에 앞서, 자동화 테스트가 어떻게 진행되는지 알려드리고자 합니다.

테스트 관련 용어를 먼저 정리하면 다음과 같습니다.

• 테스트 케이스

  • *메뉴를 누르면 프로필 사진이 나오는지 확인하자”와 같이, 테스트해야 하는 기능을 나타냅니다.

• 테스트 시나리오

  • 테스트 케이스를 직접 수행할 때, 구체적으로 무슨 행동을 해야 하는지를 나타냅니다.

  • 위와 같은 테스트 케이스의 경우 앱 실행 → 메뉴 버튼 클릭 → 프로필 사진 존재하는지 확인 과 같은 시나리오를 작성할 수 있습니다.

• STEP

  • 앱 실행 , 메뉴 버튼 클릭 등 테스트 시나리오를 구성하는 개별 항목 하나하나를 나타냅니다.

  • 터치하기, 사진 확인하기, 글 읽기 등 여러분들이 App을 사용하실 때 직접 하는 하는 행동 하나하나에 해당한다고 이해할 수 있습니다.

그래서 자동화 테스트는 위 사진과 같이

1. 각 STEP이 정확히 어떻게 동작해야 하는지를 입력하여 하나의 시나리오를 작성하고,

2. 시나리오를 실행시켜,

3. 하나의 테스트 케이스가 원하는 결과를 보이는지 자동으로 확인하는 과정

이라고 정의할 수 있습니다.

1.2.2 목표 구체화

테스트를 자동화하기 위해서는 STEP을 작성하는 일부터 시작해야겠지요? 그래서 저희가 개발한 것은 한 마디로 STEP을 아주 쉽고 직관적으로 작성할 수 있는 방법입니다.

이는 Appium Inspector를 통해 확인한, T전화 내부 키패드 탭의 구조입니다. 단순한 구조의 App인 것 같아도 실제 구조는 꽤 복잡하지요?

테스트 과정에서 버튼을 클릭하기 위해서는 최소한

• 코드 구조를 직접 이해하거나 위와 같은 도구를 이용한 App의 구조 파악,

• 버튼 위치를 조회,

• 이를 각 테스팅 도구가 요구하는 대로 입력하는 과정이 필요합니다.

이때 당연히 App을 제작한 환경에 따라 구조는 천차만별로 달라지며, 특히 게임 엔진 등으로 개발된 환경에서 버튼을 인식조차 하지 못하는 경우도 발생합니다.

단순히 물체의 이미지만 입력하는 방식으로 STEP을 작성할 수 있다면 얼마나 편할까?

그래서 저희가 도입할 서비스에서는 이미지를 입력하면 Object Detection Model이 스마트폰 화면에 해당 물체가 존재하는지 / 존재하지 않는지, 존재한다면 그 위치는 어디인지를 판단합니다.

이때 위치 좌표는 곧바로 클릭에 활용할 수 있습니다.

보다 쉬운 방법으로 물체가 존재하는지 확인, 특정 물체 / 버튼 클릭, 물체 변화 확인 등 일반적으로 여러분들이 App을 사용할 때 하는 대부분의 행동들을 충분히 표현할 수 있겠죠?

또한 특정한 물체가 등장하기까지 걸린 시간 역시 측정하는데, 이는 로딩 시간이나 렌더링 시간을 측정하는 등 성능을 테스트하는 여러 테스트에 사용할 수 있습니다.

2. 연구 현황

2.1 Detection Model

2.1.1 Model 목표

테스트에 사용할 모델의 필수 요건으로, 저희는 다음과 같은 세 가지 사항을 고려했습니다.

첫째, App내 신규 기능 업데이트 시 학습 비용 최소화하기

SK Telecom에는 다양한 Family App이 있고, 이를 담당하는 수많은 개발자님들과 테스터님들이 항상 더 좋은 사용자 경험을 여러분들께 제공하기 위해 노력하십니다.

이때 일반적인 인공지능 Model을 학습할 때처럼, 업데이트마다 매번 변화된 App의 이미지를 모두 레이블링해서 학습시켜야 한다면 아주 비효율적일 수밖에 없습니다.

그러므로 이 작업이 필요하지 않도록, 학습에 들어가는 비용을 최소화해야 했습니다.

둘째, App내 가상 물체를 정확하게 인식하기

App에는 그림이나 3D 모델링으로 생성된 가상 세계 물체가 많이 사용되지만, 일반적인 Vision Model들은 실세계의 물체로 학습되었기에 이를 인식하는 데 어려움이 있습니다.

그러므로 가상 세계의 물체까지 잘 인식할 수 있는 Model을 개발해야 했습니다.

셋째, App 내 물체가 존재하지 않는다는 정보도 인식하기

”메시지가 등장하고 3초 이후 정상적으로 사라지는지 확인” 등 테스트 과정에서는 물체가 존재하지 않는다는 판단이 필요한 경우가 있습니다.

이러한 테스트를 문제없이 수행할 수 있는 모델이 필요했습니다.

2.1.2 Model 결정 과정

위 목표를 기준삼으니 연구 계획에서 말씀드린 CFOCNet 뿐만 아니라,

Object Detection에 가장 널리 사용되는 Yolo, One-Shot Task에서 뛰어난 성능을 기록한 OwlViT 등 수많은 모델을 직접 실험해 본 결과 대부분 목표를 달성하지 못했습니다.

이를 해결하기 위해 연구 계획을 세울 때 판단했던 대로, 객체들이 보다 정적이고, 크기의 범위 역시 한정되어 있으며, 상황 및 배경이 제한적이라는 조건에 집중했습니다.

그래서 ViT Model을 사용한 Sliding Window 기반 유사도 비교 방식을 고안했습니다.

2.1.3 Sliding Window ViT

Sliding Window는 물체의 크기를 고정한 결과, 크기에 대한 추론을 할 필요가 없도록 만들어 그만큼 추론의 정확도를 올리는 방식입니다. 자세한 작동 과정은 다음과 같습니다.

먼저 위 사진의 “고양이”와 같이, 탐지하고자 하는 물체의 사진을 제공합니다. 이때 모델은 사진을 통해 고양이를 구분할 수 있는 특징(Attention)을 추출합니다.

다음으로 고양이가 있는지, 있다면 어디에 있는지 확인해야 하는 이미지를 제공합니다. 모델은 미리 지정된 작은 네모 박스 크기로 하나하나 잘라가면서, 앞서 추출한 고양이의 특징을 가진 부분과 비교합니다.

• 그 결과

  • “유사도가 미리 설정한 임계값 이상이기 때문에 고양이가 존재하고,

  • 그 위치는 가장 큰 유사도를 보이는 네모 박스의 위치이다”

  라는 결과를 도출합니다.

Sliding Window ViT를 기반으로 실제 테스트 케이스로 실험한 결과, 추가적인 학습 없이도 68%의 테스트 케이스 Coverage를 확보할 수 있었습니다.

기존 모델들이 대부분 50%에도 못 미치는, 심지어 30%에 가까운 성능을 보인 것에 비해 독보적인 결과였으므로, Sliding Window ViT를 사용하기로 결정하였습니다.

2.1.4 개선하기

Sliding Window ViT 모델이 가장 성능이 좋았으나, 68%라면 현업에 적용하기는 무리가 있는 성능이지요. 따라서 실패한 테스트 케이스를 분석해 보았습니다.

그 결과, “뒤로 가기 버튼”과 같이 물체의 특성이 뚜렷하지 않은 경우를 제대로 인식하지 못한다는 사실을 확인했습니다.

이것이 일반적인 문제인지 확인하기 위해 Attention Map, 즉 Model이 중요하게 생각하는 영역을 확인해 보니

확실히 사용자가 누를 수 있는 버튼이나 움직일 수 있는 물체에 집중하지 못하는 문제가 있었습니다.

2.1.5 Self-Supervised Learning

개선점을 달성하기 위해서는 학습이 필요하겠지요. 그런데 학습 과정에서 레이블링 등 학습 비용이 과도하게 요구된다면,

App내 신규 기능 업데이트 시 학습 비용 최소화하기라는 목표를 달성할 수 없습니다.

그러므로 레이블링이 필요하지 않은, Self-Supervised Learning을 도입하였습니다.

DINO(self-DIstillation with NO labels)

DINO는 Model을 두 개 가동하여, “산양” 전체와 같이 물체 전체를 보는 Teacher Model과, 뿔이나 얼굴 등 물체의 세부 내용을 보는 Student Model로 가정한 후,

두 모델이 서로 피드백을 하면서 물체 전체뿐만 아니라 세부적인 특징까지 스스로 파악하도록 하는 학습 방법입니다.

MIM(Masked Image Modeling)

MIM은 이미지에 의도적으로 구멍을 내고, 구멍이 나지 않은 다른 부분들을 참조해 모델이 스스로 원본을 복원하도록 합니다.

이를 통해 모델이 물체를 구성하는 픽셀들의 관계를 스스로 파악하도록 하는 것이지요.

곧바로 게시할 “Self-Supervised Learning, DINO / MIM” 포스트에서 각 학습을 보다 자세하고 전문적으로 설명드리겠습니다. 이것 역시 기대해 주세요!

2.1.6 학습 결과

Self-Supervised Learning 이후 뭉쳐져 있던 픽셀이 확실히 분리되면서, 각 버튼과 물체를 선명하게 구분하고 있음을 확인할 수 있습니다.

2.2 Development

이후로 엔지니어링적인 관점에서 모델을 테스트에 어떻게 적용했는지, 어떤 인프라를 사용하였는지 등에 대해 설명드리겠습니다.

2.2.1 Spec

사용한 Tech Stack과 Infra Spec은 다음과 같습니다.

2.2.2 Infrastructure

실제로 구현한 Server 등 인프라 구조는 다음과 같습니다.

• WatchMAN+ Server

  • 테스터가 입력한 테스트 시나리오를 바탕으로, 자동화 테스트를 실행시키는 서버입니다.

  • 현재 SKT에서 테스팅 오토메이션에 활발히 사용되는 WatchMAN+의 이름을 차용했습니다.

• Agent PC

  • 스마트폰 단말들과 USB로 연결되어, 각 단말의 조작을 담당하면서 스마트폰 화면의 영상을 Model에게 전송하는 기능을 담당합니다.

• Model Server

  • Model을 실행시키고, 그 결과를 제공하는 서버입니다.

2.2.3 Idea #1 단말 화면 영상 전송

지금까지 말씀드린 과정대로 테스트를 진행하기 위해 무엇보다 중요한 것은, 테스트가 진행되는 단말의 화면 영상을 적은 Delay로 받아오는 것입니다.

이를 위해 화면 미러링 오픈소스 scrcpy를 열심히 튜닝해 다음과 같은 기능을 개발하였습니다.

2.2.4 Idea #2 Sliding Window 추론 속도 개선

Sliding Window 방식은, 필연적으로 작은 네모 박스(Window)가 이동해야 하는 범위만큼 Model의 추론 과정이 필요합니다.

그만큼 작동 시간이 늘어나지요. 이를 개선하기 위해 물체가 나타날 위치가 명확하다면, 영역을 제한하여 보다 작은 영역을 Window 이동 범위로 설정하는 방식을 도입했습니다.

3. 시연

3.1 물체 등장 여부 확인 + 물체 터치하기

클릭하시면 Youtube로 연결됩니다!

3.2 로딩 시간 측정하기

클릭하시면 Youtube로 연결됩니다!

위 영상은 최대 오차, 즉 Worst Case에 대한 것입니다.

초당 프레임 수(FPS)가 5이기 때문에 물리적으로 최대 5분의 1초, 그리고 시스템 오차정도의 오차가 발생하여 최대 0.22초의 오차가 발생함을 확인할 수 있습니다.

이렇게 FPS에 따른 오차 외에는 큰 오차가 발생하지 않음을 확인할 수 있습니다!

추론하는 프레임을 늘린다면 더 정확한 결과를 얻을 수 있을 것입니다.

4. 결론

4.1 성능 평가

멘토님과 꾸준히 소통하면서, 실제 QA시 사용하는 기능 테스트의 테스트 케이스 271개를 바탕으로 각 모델의 성능을 평가했습니다.

Sliding Window ViT를 제외하고, 가장 좋은 성능을 보인 Model은 OwlViT였는데, 약 52%의 테스트 케이스 Coverage를 보여주었습니다.

52%에 만족하지 않고 방식을 바꾸며 추가적인 학습을 거친 결과, Coverage 85%의 성능을 달성하였습니다!

4.2 진행 상황

연구 계획을 작성할 당시 저희의 중간 결과물 목표는

WatchMAN+와 API로 정확히 통신할 수 있는 Agent Server & ifland 기준 원활한 Testing이 가능한 Model 완성

이었으며, 현재 Server 인프라와 API, 그리고 모델 학습까지 진행하였으므로 목표한 바를 달성하였습니다!

4.3 이후 계획

이후 계획은 서비스에 바로 적용할 수 있도록 구체화하자! 입니다.

자세한 계획은 다음과 같습니다.

1. Test Cases Coverage 85% → 90%대로 향상

대표적으로 불가능한 테스트는, 활성 여부에 따른 텍스트의 색상을 구분하기 와 같은 것입니다. 이를 해결할 수 있는 Model 개선 방안, 혹은 엔지니어링적 해법을 연구하겠습니다.

2. 학습 Platform 구축

App 테스트 담당자님께서 업데이트를 Model에 쉽게 반영하실 수 있도록, 직관적이고 사용하기 편리한 Platform을 구축하고자 합니다.

3. Inference Time 등 Model 사용 비용 최소화

Target Image Size에 맞는 최적의 Stride 자동 계산하기, Sliding Window 없이 진행할 수 있는 Task에 대해서는 보다 효율적인 방법 도입하기 등을 목표로 연구하겠습니다.

4. Model 일반화 성능 향상

오류 없는 자동화 테스트를 위해 추가적인 Self-Supervised Learning 데이터셋을 확보하고, 새로운 방법을 도입하는 등 Model 성능 향상을 위해 연구를 지속하겠습니다.

마지막까지 열심히 달리겠습니다! 이상 팀 슼나무였습니다.

• 보다 자세한 연구 과정은 Github Organization Wiki를 통해 확인하실 수 있습니다!