변화하는 UI를 따라가는 LinkedIn의 AI 테스트 자동화

서비스가 커지고 복잡해질수록
사용자가 마주할 수 있는 화면과 경로도 늘어난다.

같은 기능이라도 사용자의 상태와 환경에 따라
서로 다른 화면이 나타날 수 있다.

그렇다면 사람이 미리 작성한 테스트만으로 어디까지 확인할 수 있을까?
LinkedIn의 사례를 통해 
복잡해지는 서비스 환경에서 AI를 활용한 테스트 방식은 어떻게 달라지고 있는지 살펴본다.

 

테스트해야 할 경우의 수가 계속 늘어난다면
모든 사용자 경로를 미리 정의하는 것도 어려워진다.

LinkedIn도 이 문제를 마주했다.

 

LinkedIn은 그 답을

단순히 테스트 케이스를 더 많이 만드는 데서 찾지 않았다.

 

 

AI가 실제 애플리케이션의 상태를 파악하고
테스트를 진행하는 QA Agent를 만들기 시작했다.

 

 

---

 

[목차]

---

 

 

 

1. LinkedIn은 복잡한 서비스 환경을 어떻게 테스트할까

1) 수천 가지 UI가 만들어지는 LinkedIn

전 세계 13억 명 이상이 사용하는 LinkedIn.

 

서비스는 iOS, Android, Web에 걸쳐 제공되며
지원하는 언어만 36개가 넘는다.

 

여기에 사용자 유형과 멤버십,

동시에 진행되는 A/B 테스트까지 더해진다.

 

이 조건들이 서로 조합되면

모든 사용자가 같은 LinkedIn을 경험하는 것은 아니다.

 

사용자의 상태와 접속 환경,

어떤 실험에 포함되어 있는지에 따라
같은 기능에서도 서로 다른 화면과 경로가 나타날 수 있기 때문이다.

 

 

예를 들어 같은 '메시지 보내기' 기능이라도

한 환경에서 문제없이 동작했다는 사실만으로

모든 사용자에게 문제가 없다고 판단하기는 어렵다.

 

여러 조건이 조합되면서 LinkedIn에는

수천 가지의 서로 다른 UI가 만들어진다.

 

문제는 이 UI가 고정되어 있지 않다는 것이다.

 

새로운 기능이 추가되고 기존 화면이 변경되면
테스트해야 할 사용자 경로 역시 함께 달라진다.

 

LinkedIn이 해결해야 했던 것은
단순히 더 많은 테스트를 실행하는 문제가 아니었다.

 

계속 달라지는 사용자 환경을
어떻게 반복적으로 검증할 것인가?

 

 

 

2) LinkedIn은 정해진 경로에 AI의 판단을 더했다

기존 UI 자동화는

사람이 미리 작성한 경로를 따라 테스트를 수행한다.

 

특정 화면에 들어가 버튼을 누르고,
다음 화면으로 이동한 뒤
예상한 결과가 나타나는지 확인하는 방식이다.

 

경로가 명확하고 화면이 예상대로 유지된다면
같은 테스트를 빠르고 일관되게 반복할 수 있다.

 

문제는 예상했던 화면이 나타나지 않을 때다.

 

 

버튼의 위치가 달라지거나,
중간에 새로운 화면이 추가되거나,
사용자 상태에 따라 다른 UI가 나타나면
기존에 작성된 경로만으로 테스트를 이어가기 어려워진다.

 

LinkedIn은 이 문제를 해결하기 위해
기존 자동화를 AI로 대체하지 않았다.

 

대신 기존 경로를 반복하는 자동화와
현재 화면을 보고 판단하는 AI를 함께 사용하는 방식을 선택했다.

 

이를 위해 만든 것이 Quality Assurance Agent(QA Agent)​다.

 

QA Agent는 Vision-Language Model을 활용해
실제 애플리케이션의 화면을 인식하고,
테스트 목표에 따라 필요한 행동을 판단할 수 있다.

 

하지만 모든 단계에서 AI가 판단하는 것은 아니다.

 

LinkedIn은 QA Agent의 동작을
System 1과 System 2로 나누었다.

 

 

System 1 — 알고 있는 경로는 그대로 실행한다

이미 정상적으로 실행된 경로라면
기존 자동화처럼 저장된 행동을 다시 실행한다.

 

어떤 화면에서 무엇을 해야 하는지 알고 있다면

매번 AI가 화면을 다시 해석할 필요가 없다.

 

이를 통해 반복되는 테스트는
빠르고 일관된 방식으로 실행할 수 있다.

 

System 2 — 경로가 달라지면 다시 판단한다

기존 경로를 그대로 실행할 수 없는 상황에서는
Vision-Language Model이 개입한다.

 

예상했던 요소가 나타나지 않거나
이전에 없던 화면을 만나면,

 

현재 화면이 어떤 상태인지 파악하고
테스트 목표를 이어가기 위해 다음에 무엇을 해야 하는지 판단한다.

 

새로운 경로를 찾으면
그 행동은 다시 실행할 수 있는 경로로 남는다.

 

 

QA Agent의 흐름을 정리하면 다음과 같다.

알고 있는 경로는 그대로 실행하고,
경로가 달라지는 순간에만 다시 판단한다.

 

LinkedIn이 AI를 활용한 지점은
기존 자동화를 없애는 데 있지 않았다.

 

정해진 경로의 속도와 반복성은 유지하면서,
그 경로만으로 대응하기 어려운 순간에 판단할 수 있는 능력을 더한 것이다.

 

3) 예상했던 화면이 달라져도 테스트는 계속된다

 

QA Agent가 실제 테스트에서 어떻게 움직이는지 살펴보자.

 

예를 들어 프로필 화면에서
메시지를 보내는 기능을 테스트한다고 해보자.

 

처음에는 이전에 정상적으로 실행했던 경로를 사용한다.

 

프로필에 들어가 메시지 버튼을 누르고,
내용을 입력한 뒤 전송 결과를 확인한다.

 

이미 알고 있는 경로이기 때문에
각 단계마다 AI가 다시 판단할 필요는 없다.

 

 

 

그런데 서비스가 업데이트되면서
기존 위치에서 메시지 버튼을 찾을 수 없게 됐다면 상황이 달라진다.

 

기존 자동화에서는
예상한 요소를 찾지 못한 시점에서 테스트가 실패하고,
변경된 화면에 맞춰 테스트 경로를 수정해야 한다.

 

QA Agent는 이 지점에서
현재 화면을 다시 확인한다.

 

처음 기록된 위치에서 버튼을 계속 찾는 대신,
현재 화면에서 테스트 목표를 이어갈 방법을 탐색한다.

 

 

메시지 기능으로 이동할 수 있는 요소를 찾았다면
새로운 경로를 따라 테스트를 계속 진행한다.

 

처음 정해둔 경로를 완성하는 것이 아니라,
주어진 테스트 목표를 완성하는 것이 기준이 되는 것이다.

 

여기서 중요한 것은
화면이 바뀌어도 무조건 테스트를 성공시키는 것이 아니다.

 

QA Agent가 확인하려는 것은 여전히 동일하다.

 

사용자가 프로필에서 메시지를 보내고
정상적으로 전송을 완료할 수 있는가.

 

화면의 구성이나 도달 경로가 달라져도
검증해야 할 사용자 행동의 목적은 유지된다.

 

이 차이는 테스트를 정의하는 기준에도 영향을 준다.

 

기존 자동화가
‘어떤 순서로 무엇을 누를 것인가’​를 중심으로 동작했다면,

 

QA Agent는 여기에
‘결국 무엇을 확인해야 하는가’​라는 목표를 함께 활용한다.

 

LinkedIn은 이러한 방식으로
미리 작성한 경로와 실제 서비스의 상태가 달라졌을 때도
테스트를 이어갈 수 있는 범위를 넓혔다.

 

 

2. QA Agent는 테스트를 어떻게 바꿨을까 

1) 테스트를 만드는 방법도 달라졌다

QA Agent가 바꾼 것은
테스트를 실행하는 방식만이 아니다.

 

테스트를 처음 만드는 과정에도 변화가 생겼다.

 

기존 UI 자동화에서는
검증할 사용자 흐름을 정한 뒤,

 

어떤 화면에서 어떤 요소를 누르고,
무엇을 입력하고, 어떤 결과가 나타나야 하는지를
자동화 코드로 작성해야 했다.

 

테스트할 경로가 늘어나면
작성하고 관리해야 할 코드도 함께 늘어난다.

 

 

LinkedIn은 이 과정을 줄이기 위해
Recorder를 활용했다.

 

테스트를 만들고 싶은 사람이
실제 애플리케이션에서 검증할 동작을 직접 수행하면
Recorder가 그 과정을 기록한다.

 

예를 들어 메시지 기능을 테스트한다면,

프로필로 이동하고
→ 메시지 기능을 선택하고
→ 내용을 입력하고
→ 전송 결과를 확인하는 과정을

실제 사용자가 서비스를 이용하듯 직접 보여주는 방식이다.

 

 

Recorder는 이렇게 기록한 행동을
QA Agent가 이해할 수 있는 자연어 형태의 테스트 지시로 변환한다.

 

사용자 조작
→ Recorder로 행동 기록
→ 테스트 지시 생성
→ QA Agent가 반복 실행

 

이 방식에서는 테스트를 만들기 위해
각 UI 동작을 처음부터 자동화 코드로 작성할 필요가 줄어든다.

 

검증하고 싶은 흐름을 알고 있다면
엔지니어가 아닌 사람도 실제 동작을 보여주는 방식으로

테스트 작성에 참여할 수 있다.

 

여기서 달라지는 것은 단순히
테스트 작성 시간이 줄어든다는 것만은 아니다.

 

기존에는 사람이 수행하던 테스트를 자동화하려면
실제 사용자 행동을 다시 자동화 코드로 옮기는 과정이 필요했다.

 

Recorder는 이 사이의 단계를 줄인다.

 

사람이 검증하고 싶은 사용자 흐름을 보여주면,
그 행동을 반복 가능한 테스트로 연결할 수 있게 된 것이다.

 

LinkedIn의 QA Agent는
테스트 실행뿐 아니라 테스트를 만드는 과정까지 자동화의 범위를 넓히고 있다.

 

 

 

2) AI가 찾은 것은 화면의 오류만이 아니었다

이렇게 만들어진 QA Agent는
실제 LinkedIn 환경에서 반복적으로 테스트를 수행하고 있다.

 

현재 iOS, Android, Web에서
350개 이상의 테스트가 30분 간격으로 실행되며,
이를 통해 200건 이상의 유효한 버그를 발견했다.

 

 

발견한 문제도 단순히
버튼이 보이지 않거나 화면이 깨지는 것에 그치지 않았다.

 

LinkedIn이 공개한 사례 중 하나는
메시지 전송 기능에서 발생한 회귀 문제다.

 

QA Agent가 실제 사용자 흐름을 따라
메시지 기능을 테스트하는 과정에서
전송 과정에 문제가 있다는 것을 발견했다.

 

테스트 중 앱이 충돌하거나
예상하지 못한 오류가 발생하면
해당 세션의 영상과 로그 등 관련 정보를 수집한다.

 

문제가 실제로 다시 발생하는지 확인한 뒤에는
재현에 필요한 정보와 함께 버그 리포트를 남긴다.

 

하지만 QA Agent가 발견한 문제는
사용자 화면에서 확인할 수 있는 오류만이 아니었다.

 

LinkedIn의 Profile 팀은
비즈니스 지표에서 발생한 session loss의 원인을 추적하고 있었다.

 

그 과정에서 QA Agent가 해당 사용자 흐름에서
잘못된 Tracking Event가 일관되지 않게 발생하는 현상을
이미 포착했다는 사실을 확인했다.

 

 

화면에서는 사용자가 기능을 정상적으로 완료한 것처럼 보여도
그 과정에서 기록되어야 할 데이터에는
문제가 발생할 수 있다는 것이다.

 

이 사례에서 QA Agent가 확인한 것은
단순히 ‘화면이 정상적으로 보이는가’​만이 아니었다.

 

사용자가 기능을 정상적으로 완료할 수 있는가
그 과정에서 애플리케이션은 정상적으로 동작하는가
필요한 데이터와 이벤트는 올바르게 기록되고 있는가

 

테스트의 대상이 사용자에게 보이는 화면을 넘어
사용자 행동과 그 뒤에서 발생하는 시스템의 동작까지 이어진 것이다.

 

LinkedIn의 사례는
AI를 활용한 테스트가 더 많은 화면을 실행하는 것뿐 아니라,

 

하나의 사용자 흐름에서 확인할 수 있는 문제의 범위 역시
넓힐 수 있다는 점을 보여준다.

 

 

3) 많이 찾는 것보다, 틀리지 않는 것을 선택했다

 

200건 이상의 유효한 버그를 발견했다는 결과만 보면
QA Agent의 성능은 얼마나 많은 문제를 찾아내는가로 평가해야 할 것처럼 보인다.

 

하지만 LinkedIn이 더 중요하게 본 기준은 따로 있었다.

 

버그라고 판단한 결과를
얼마나 신뢰할 수 있는가.

 

AI가 조금이라도 이상한 상황을 모두 버그로 판단한다면
더 많은 문제를 찾아낼 수는 있다.

 

 

대신 정상적인 동작까지 문제로 보고하는
False Positive도 함께 늘어날 수 있다.

 

이렇게 잘못된 리포트가 반복되면
결국 사람이 하나씩 다시 확인해야 한다.

 

자동화가 더 많은 문제를 찾아내더라도
그 결과를 확인하는 데 사람의 시간이 계속 필요하다면
자동화의 효과도 줄어들 수밖에 없다.

 

그래서 LinkedIn은 QA Agent를 평가할 때
Recall보다 Precision을 우선했다.

 

• Recall — 실제 존재하는 문제를 얼마나 놓치지 않고 찾아내는가
• Precision — 문제라고 판단한 결과 중 실제 문제가 얼마나 많은가

 

LinkedIn이 선택한 것은
가능한 모든 문제를 빠짐없이 찾아내는 방향보다,

 

한 번 문제라고 보고한 결과를
개발자가 신뢰할 수 있도록 만드는 방향에 가까웠다.

 

이를 위해 QA Agent는
이상을 발견했다고 해서 곧바로 버그로 확정하지 않는다.

 

발견한 현상이 실제로 다시 발생하는지 확인하고,
재현 결과와 관련 정보를 바탕으로
보고할 문제를 구분한다.

 

즉, 자동화의 역할은
이상한 상황을 최대한 많이 수집하는 것에서 끝나지 않는다.

 

실제 대응이 필요한 문제를 가려내
사람에게 전달하는 과정까지 포함된다.

더 많은 결과를 만드는 것보다,
믿고 확인할 수 있는 결과를 남기는 것.

 

 

AI가 테스트에 더 많은 판단을 맡게 될수록
그 판단을 얼마나 신뢰할 수 있는지도 함께 중요해진다.

 

LinkedIn이 QA Agent에서 Precision을 우선한 이유도
단순히 테스트의 정확도를 높이기 위해서만은 아니다.

 

자동화가 발견한 결과를
실제 개발과 QA 과정에서 사용할 수 있게 만들기 위해서다.

 

 

3. QA Agent는 어디까지 활용할 수 있을까

1) QA Agent는 어디까지 확장될까

현재 LinkedIn의 QA Agent는
실제 서비스 환경에서 사용자 흐름을 반복적으로 검증하고
발견한 문제를 확인하는 데 활용되고 있다.

 

하지만 LinkedIn이 그리고 있는 범위는
여기서 끝나지 않는다.

 

현재 운영 중인 서비스를 반복해서 확인하는 것에서 나아가
문제가 실제 서비스에 반영되기 전에 발견하는 방향으로
QA Agent의 활용 범위를 넓히고 있다.

 

코드가 머지되기 전에 확인한다

 

현재의 반복 테스트는
이미 실행 가능한 애플리케이션을 대상으로
기능이 정상적으로 동작하는지 확인하는 데 활용된다.

 

LinkedIn은 이를 더 앞선 단계로 가져가
코드가 머지되기 전에 변경으로 인한 문제를 확인하는 방식을
QA Agent의 확장 방향으로 제시하고 있다.

 

테스트가 개발 과정의 더 앞단으로 이동하면
문제를 발견하는 시점도 함께 앞당길 수 있다.

 

서비스에 변경사항이 반영된 뒤 문제를 발견하는 것이 아니라,
변경사항이 기존 사용자 흐름에 어떤 영향을 주는지
더 이른 시점에 확인하는 것이다.

 

정해진 경로 밖도 탐색한다

또 다른 확장 방향은
Exploratory Testing, 탐색적 테스트​다.

 

지금까지 살펴본 테스트에는
메시지 전송처럼 확인하려는 목표가 존재했다.

 

하지만 실제 사용자가 서비스를 이용하는 방식이
항상 미리 작성된 테스트 목록 안에 있는 것은 아니다.

 

여러 기능을 오가거나,
예상하지 않았던 순서로 기능을 사용하거나,
테스트를 설계할 당시 고려하지 않았던 상태에 도달할 수도 있다.

 

LinkedIn은 QA Agent가
이처럼 미리 정해진 테스트 경로 밖을 탐색하며
새로운 문제를 찾는 방향으로도 발전할 수 있다고 보고 있다.

 

기존 자동화가
이미 알고 있는 문제와 경로를 반복적으로 확인하는 데 강했다면,

 

탐색적 테스트는
아직 테스트 케이스로 만들어지지 않은 영역에서
무엇이 문제가 될 수 있는지 찾는 과정에 가깝다.

 

이미 만들어진 테스트를 자동으로 실행하는 것에서,
아직 테스트로 정의되지 않은 영역을 찾아보는 것까지.

 

QA Agent의 적용 범위가 넓어진다면
자동화의 대상도 함께 달라진다.

 

반복적인 회귀 테스트를 수행하는 도구를 넘어,

변경사항을 더 이른 시점에 검증하고
사람이 미리 작성하지 않은 영역까지 살펴보는 방향으로
테스트 자동화의 범위가 확장되고 있는 것이다.

 

 

 

2) 그렇다고 모든 테스트를 AI에게 맡길 수 있을까

 

QA Agent가 테스트할 수 있는 범위가 넓어진다고 해서
모든 검증에 AI의 판단이 필요한 것은 아니다.

 

AI가 화면을 이해하고 다음 행동을 결정하는 방식에는

기존 자동화와는 다른 고려사항이 생긴다.

 

AI의 판단이 항상 같은 결과를 보장하지는 않는다

VLM은 현재 화면과 테스트 목표를 바탕으로
다음에 어떤 행동을 해야 할지 판단한다.

 

하지만 화면에 비슷한 의미의 요소가 여러 개 있거나
현재 상태를 다르게 해석할 여지가 있다면
테스트 의도와 다른 행동을 선택할 가능성도 고려해야 한다.

 

예를 들어 메시지 기능을 확인하는 과정에서
비슷한 역할을 하는 여러 버튼이 나타난다면,

 

Agent가 선택한 경로로 테스트 자체는 완료됐더라도

처음 확인하려던 사용자 흐름을 제대로 검증했는지는
별도로 확인해야 할 수 있다.

 

즉, 테스트가 중단되지 않았다는 것만으로
올바른 검증이 이루어졌다고 판단하기는 어렵다.

 

판단이 필요한 만큼 비용과 시간도 고려해야 한다

 

정해진 행동을 그대로 반복하는 것과
현재 화면을 해석하고 다음 행동을 결정하는 것은 다르다.

 

AI가 개입하는 과정에서는
화면을 이해하고 판단하는 단계가 추가된다.

 

따라서 반복적이고 결과가 명확한 테스트까지
모두 AI의 판단으로 처리하는 것이
항상 효율적이라고 단정하기는 어렵다.

 

장기간 운영했을 때의 효과도 더 지켜봐야 한다

 

현재 공개된 사례에서는
350개 이상의 테스트를 반복적으로 실행하고
200건 이상의 유효한 버그를 발견한 결과를 확인할 수 있다.

 

하지만 이것만으로 모든 운영 조건을 판단할 수 있는 것은 아니다.

 

 

복잡한 테스트를 장기간 반복했을 때도
일관된 수준의 판단을 유지할 수 있는지,

 

서비스 UI가 계속 변경될 때
Agent를 관리하는 데 어느 정도의 작업이 필요한지,

 

사람이 직접 확인하고 관리하던 업무를
실제로 얼마나 줄일 수 있는지 등은
공개된 내용만으로 판단하기 어렵다.

 

따라서 중요한 것은
AI를 얼마나 많은 테스트에 적용할 것인가가 아니다.

 

반복적이고 결과가 명확한 검증과
상황에 따라 새로운 판단이 필요한 검증을 구분하고,

 

어떤 영역에서 AI의 판단이 실제로 필요한지를 정하는 것이 먼저다.

 

자동화할 수 있다는 것과
AI로 자동화해야 한다는 것은 같은 의미가 아니다.

 

LinkedIn의 사례가 보여주는 가능성만큼,
그 기술을 어떤 검증에 적용할 것인지에 대한 판단도 함께 필요하다.

 

 

 

 

 

4. 우리 서비스의 테스트는 어디까지 확인하고 있는가

 

LinkedIn처럼 13억 명이 사용하는 서비스가 아니더라도
실제 사용자가 경험하는 상황은 하나로 정해지지 않는다.

 

사용자 권한에 따라 사용할 수 있는 기능이 달라지고,
디바이스와 브라우저에 따라 환경이 달라지며,
업데이트가 반복되면서 기존 화면과 기능도 계속 바뀐다.

 

여기에 사용자가 서비스를 이용하는 순서까지 고려하면
작성해 둔 테스트 케이스가 실제 사용 환경의 모든 경우를
포함한다고 보기는 어렵다.

 

그래서 먼저 살펴볼 것은
현재 테스트가 어디까지 확인하고 있는가다.

 

예를 들어 다음과 같은 질문을 해볼 수 있다.

서비스의 핵심 사용자 흐름은 빠짐없이 확인하고 있는가?
사용자 권한이나 환경이 달라져도 같은 기능을 검증하고 있는가?
화면의 동작뿐 아니라 필요한 데이터와 이벤트도 정상적으로 기록되는가?
테스트 케이스에 없는 방식으로 사용했을 때 발생하는 문제는 어떻게 확인하고 있는가?

 

모든 상황을 하나의 테스트 방식으로 확인할 필요는 없다.

 

하지만 어떤 영역을 이미 검증하고 있고,

어떤 영역이 현재 테스트 범위 밖에 있는지는 구분할 필요가 있다.

 

 

LinkedIn의 사례가 보여주는 것도
단순히 AI를 테스트에 적용했다는 사실만은 아니다.

 

서비스가 복잡해질수록
미리 작성한 경로와 조건만으로 실제 사용자 환경을
어디까지 확인할 수 있는지 다시 살펴볼 필요가 있다는 점이다.

 

결국 검증해야 하는 것은
작성해 둔 테스트 목록 자체가 아니다.

 

실제 사용자는 테스트 케이스에 적힌 조건과 순서대로만
서비스를 이용하지 않기 때문이다.

 

테스트가 모두 통과했다는 것과,
사용자가 문제를 만나지 않는다는 것은 같은 의미일까?

 

테스트 범위를 정할 때는
우리가 확인하고 있는 것뿐 아니라
아직 확인하지 못하고 있는 것이 무엇인지도 함께 살펴봐야 한다.