위메이드플레이의 Amazon Bedrock을 사용한 게임 사용자 인터페이스 품질 테스트 자동화 사례

들어가는 글

위메이드플레이는 2009년에 설립된 캐주얼 게임 전문 개발사입니다. 특히 위메이드플레이의 애니팡 시리즈는 누구나 쉽게 즐길 수 있는 모바일 게임으로 1억건 이상의 누적 다운로드를 통해 꾸준히 많은 사랑을 받고 있습니다. 또한 ‘위 베어 베어스 더 퍼즐’과 ‘디즈니 팝 타운’과 같은 글로벌 IP를 활용한 퍼즐 게임들을 통해 글로벌 시장에서도 좋은 성과를 기록하고 있습니다.

매번 새로운 게임 버전을 배포하기 전에 위메이드플레이의 QA(Quality Assurance)팀에서는 일련의 게임 시나리오들에 대해 매번 반복적인 테스트를 수행하게 됩니다. 이때 테스터의 숙련도에 따라 오탐이 발생할 수 있으며, 발견되지 않은 오류들로 인해 게임 유저 경험이 저하될 수 있습니다. 또한 위메이드플레이에서 게임 QA(Qualiity Assurance) 업무의 본질은 기존의 품질에 대한 검증 업무뿐만 아니라 유저들에게 불편을 줄 수 있는 요소들을 없애고 게임 경험을 향상시킬 수 있는 다양한 피드백을 제공하는 것입니다. 예를 들어, 주요 컨텐츠에 대한 접근성이 좋은지, 특정 게임 화면에서 사용자들이 이해하기 어려운 UI요소가 있다든지, 특정 표시 하나만 넣어도 유저들의 동선을 간단하게 만들 수 있다든지 등 다양한 피드백을 주는 업무입니다. 이런 QA 업무를 고도화하려면 반복적이고 정형화된 품질 검증 테스트 항목에 드는 시간을 줄이고 자동화하여 게임 경험 향상을 위한 피드백에 더 많은 시간을 들여야 합니다.

위메이드플레이는 이를 위해 초기에 모바일 앱 테스트 자동화 도구인 Appium을 도입하여 반복적인 테스트 항목들에 대해 품질 테스트의 자동화를 시도하였습니다. 하지만 자동화된 사용자 입력을 위해 게임화면의 버튼 등의 UI 요소들의 좌표를 계산하거나 또는 사용자 입력에 따라 변경된 화면내의 UI 요소들들로 부터 속성값을 확인하기 위해서는 복잡한 테스트 스크립트를 개발해야 했습니다. 특히 다양한 해상도 크기의 모바일 기기들을 고려하여 이를 개발하고 유지 보수하는 데에는 많은 시간이 소모되었습니다.

위메이드플레이는 복잡한 테스트 스크립트 개발을 대체할 수 있는 대안으로 생성형 AI 기술에 주목하였습니다. 특히 최신 생성형 AI 모델들에서 지원하는 비전(Vision) 기능을 통해 게임 화면을 캡처한 이미지를 생성형 AI 모델이 인식하고 이를 분석하여 테스트 결과를 판명할 수 있을 것이라고 기대하였습니다. 이를 위해 다양한 생성형 AI 모델들을 검토하였고 Anthropic사의 Claude 3.5 Sonnet 모델을 채택하였습니다. Claude 3.5 Sonnet 모델은 비전 기능을 통해 차트, 그래프, 기술 도표, 보고서 등의 시각적 콘텐츠를 이해하고 추론하는데 높은 성능과 정확성을 제공합니다.

QA팀에서는 테스트를 수행하는 여러 게임 시나리오들 중 대부분의 게임에 공통적으로 적용되는 테스트 항목들, 예를 들어, 결제, 로그인, 출석부 기능의 테스트에 대해 먼저 Claude 3.5 Sonnet 모델을 활용한 QA 자동화 테스트를 적용하기로 하였습니다. 그중 첫 번째 자동화를 적용한 테스트 항목은 결제 기능입니다. 결제는 모든 게임에서 공통적으로 필요한 기능이며 특히 15개 이상의 현재 서비스 중인 게임들에 대해 적용되어 여러 국가의 사용자들을 대상으로 다양한 언어와 환율로 표기됩니다. 결제 기능에 대한 테스트에서는 기능 동작 여부뿐만 아니라 언어와 환율이 맞게 화면에 표시되는지 실제 아이템을 구매했을 때 아이템의 개수가 정상적으로 업데이트되어 있는지 등 간단하지만 다양한 부분의 확인이 필요합니다. 기존에는 매 게임 당 결제 기능에 대한 테스트에 20분 정도 소요되었으나 이를 생성형 AI를 통해 자동화한다면 모든 게임들에 대한 테스트에 필요한 주당 300분의 시간을 절감할 수 있다고 보았습니다.

본문

이어서 위메이드플레이의 ‘디즈니 팝 타운’ 이라는 모바일 게임에 대한 결제 테스트를 자동화한 방법을 소개하겠습니다. ‘디즈니 팝 타운‘ 게임은 글로벌 시장에 출시되었고 6개의 언어를 지원합니다. 게임 아이템에 대한 상품 패키지가 이벤트로 자주 제공되며, 사용자가 이를 구매할 때 상품의 결제가 정상적으로 이루어지는지 테스트를 수행해야 합니다.

아래는 Amazon Bedrock 서비스에서 제공되는 Claude 3.5 sonnet 모델을 사용하여 QA 자동화를 구현한 아키텍처 다이어그램입니다.

[그림1. QA 자동화 아키텍쳐]

위 아키텍처의 사용자 단말에서는 오픈 소스 테스트 자동화 도구인 Appium 을 이용하여 일련의 결제 과정을 자동으로 진행합니다. 이 때 각 과정의 게임 화면 스크린 샷을 찍어서 이를 Amazon API Gateway 가 제공하는 API를 통해 전달하고 이 때 수행되는 AWS Lambda #1 함수를 통해 스크린 샷을 Amazon S3 저장소로 업로드 합니다. 이 업로드 이벤트에 의해 실행되는 AWS Lambda #2 함수에서는 해당 스크린 샷들을 포함하여 해당 결제 테스트가 성공인지 실패인지 여부를 묻는 프롬프트(prompt)로 Amazon Bedrock이 제공하는 API를 통해 Claude 3.5 Sonnet 모델을 호출합니다. Claude 모델은 각 단계의 스크린 샷으로 부터 구매 결과 팝업 화면과 구매 전/후의 금액의 변화 그리고 해당 아이템의 수의 변화를 분석하여 구매가 성공했는지 실패 했는지를 판단하고 그 결과와 왜 그렇게 판단했는지에 대해 정보를 답변으로 줍니다. 그리고 해당 정보는 Slack을 통해 QA팀 메신저로 보내어집니다.

초기 개발 단계에서는 몇가지 시행착오도 있었습니다. 초기 버전에서는 테스트 성공 여부를 판명하기 위해 결제 과정 이미지뿐만 아니라 결제 데이타베이스에서 결제 정보 파일을 가져와서 같이 LLM 모델에 대한 입력으로 사용하였습니다. 하지만 이러한 추가 데이타로 인해 오히려 정확성이 떨어지고 환각(hallucination)이 발생하여 잘못된 답변을 얻는 경우가 많았습니다. 또한 결제 데이타베이스와의 연동을 위해서는 매번 상품 패키지가 추가되거나 수정될 때마다 결제 정보에 대한 업데이트 작업이 필요했습니다. 프롬프트도 일관된 형식을 적용하기 위한 고도화가 필요했습니다.

이후 정확도 향상을 위해 프롬프트 고도화 작업에서 다음의 주요 개선 사항들이 적용되었습니다.

프롬프트 고도화를 위한 주요 작업들

1. Role prompting

Role prompting은 Claude 모델을 사용할 때 system parameter를 사용하여 모델에게 역할을 부여하여 성능을 높이는 방법입니다. Role prompting을 이용하면 복잡한 시나리오에서 모델에게 도메인 전문가의 역할(Persona)을 부여하여 정확도를 높이고 답변 스타일을 조정하고 또한 특정 요구사항에 대해 보다 집중하도록 할 수 있습니다.

예를 들어 그림을 Claude 모델이 인식할 때 별도의 역할이 부여되지 않았을 때에는 그림에서 숫자를 정확히 인식하는데 문제가 있었습니다. 아래와 같은 예제 그림에서 “QA 테스트 전문가” 라는 역할을 부여 하지 않았을 때에는 왼쪽 상단의 ‘160’이라는 숫자를 ‘760’으로 인식하는 문제가 있었습니다.

[그림2. 위와 같은 이미지 입력에 대한 Claude 모델의 답변: “In Image 1, you have 760 rubies.”]

이 문제를 해결하기 위해 아래와 같은 시스템 프롬프트를 통해 Claude 모델에게 QA 테스트 전문가의 역할을 부여하여 숫자 인식 오류의 문제를 해결할 수 있었습니다.

prompt = ChatPromptTemplate.from_messages(
[
(
"system",
"QA를 전문으로하는 머신으로 자세하게 과정과 설명을하며 정확한 결과를 낸다.
이미지에 대한 설명을 다음과 같이 작성할때, 입력되는 이미지에 대해 각각 답변한다.
숫자를 비교할 때, 명확하게 확인한다."
),

특히 “입력되는 이미지에 대해 각각 답변한다” 및 “숫자를 비교할 때, 명확하게 확인한다” 와 같이 구체적인 사항에 더 집중하도록 하여 각각의 이미지를 따로 분석하여 정확도를 높이고 또한 숫자를 인식하는 정확도를 높일 수 있었습니다.

2. Few-shots 예제 제공

Prompt에 몇가지 예제를 제공하여 정확도를 높이고 일관성 있는 스타일의 답변을 얻을 수 있습니다.
아래 예제와 같이 결제 과정에 대한 일련의 스크린 샷을 정상 일때와 비정상 일때의 예제를 같이 사용자 프롬프트에 제공하여 정확성을 높였습니다.

(
"user",
 [
    {
        "type": "image_url",
        "image_url": {"url": "{image_success}"}
    },
    {
        "type": "text",
        "text": """
        - steps : [
            "사용자가 특정 게임 내 재화를 구매하려고 시도했습니다.",
            "결제 프로세스가 정상 진행됐습니다.",
            "결제가 성공했다는 메시지가 팝업으로 표시되었습니다."
        ]
        - process : "1,200원(0.99달러)을 사용해서 재화1 10개를 구매한다."
        - success_score : "10", 
        - reason : "정상 결제완료 팝업 메시지가 나오며, 결제한 상품에 맞게 재화가 증가되었다.",
        """
    },
    {
        "type": "image_url",
        "image_url": {"url": "{image_fail}"}
    },
    {
        "type": "text",
        "text": """
        - steps : [
            "사용자가 특정 게임 내 재화를 구매하려고 시도했습니다.", 
        "결제 프로세스가 진행되는 중에 문제가 발생했습니다.", 
        "결제가 실패했다는 메시지가 팝업으로 표시되었습니다."
        ]
        - process : "4,900원(3.99달러)을 사용해서 재화1 42개를 구매한다."
        - success_score : "0"
        - reason : "결제 실패 팝업 메시지가 나오며, 결제한 상품에 맞게 재화가 증가되지 않았다."
        """
    },

아래는 정상플로우일때와 비정상 플로우일때의 상황을 각각 캡처한 이미지입니다.

[그림3 정상플로우(결제 성공) 이미지 ]

[그림4. 비정상플로우(결제 실패) 이미지 ]

3. 속성에 대한 명확한 의미 전달 및 반환 형식 지정

이미지만으로 인식하기 모호하거나 환각의 가능성이 예상되는 경우에는 부가 정보를 추가하였습니다. 예를 들어 아래 그림의 상단에 있는 재화들에 대해 각 재화에 대한 명칭을 명확하게 정의하였고 type을 integer로 지정하여 명확하게 숫자값으로 받을 수 있도록 설명을 추가 하였고 답변 형식을 JSON Schema로 정의하여 결제 성공/실패 여부 정보 이외에도 각 결제 단계 별로 성공/실패로 판단한 이유, 성공 점수에 대한 정보도 모델의 답변에 포함되도록 하였습니다.

[그림5. 재화에 대한 답변 형식을 JSON Schema로 정의 ]

프롬프트 고도화 이외에도 다음의 추가 개선 작업들이 있었습니다.

테스트 자동화를 위한 버튼 위치 검출 작업

테스트 자동화를 위해서는 화면상의 입력 버튼 위치를 찾아서 해당 버튼을 클릭하는 이벤트를 발생시켜야 합니다. 이 입력 버튼 위치를 찾기 위해 처음에는 OpenCV를 사용하여 입력 버튼 이미지와의 유사도 검색을 통해 화면에서 입력 버튼의 좌표값을 얻는 방법을 사용하였습니다. 하지만 이를 위해서는 별도의 프로그래밍 작업이 필요하였고 특히 화면 비율에 따라 OpenCV가 참조할 입력 버튼 이미지를 준비해야 하는 번거로움이 있었습니다. 이러한 문제들을 해결하기 위해 해당 작업에서도 Amazon AI/ML 서비스를 활용하기로 했고, OpenCV 대신에 Amazon Textract 서비스를 사용하여 이미지내의 원하는 정보의 좌표값을 찾는 작업을 구현할 수 있었습니다. Amazon Textract는 문서에서 필요한 데이터에 대한 정보를 자동으로 추출해주는 서비스입니다. Amazon Textract 서비스를 통해 게임 화면 이미지에서 특정 텍스트를 포함하는 버튼들의 정확한 위치 정보를 json 파일 형태로 받을 수 있었습니다. 또한 해당 json 파일을 parsing 하는 코딩을 하는 대신, 다시 Amazon Bedrock을 통해 Claude 3.5 Sonnet 모델을 호출하여 해당 버튼의 top, left, width, hight의 pixel값을 손쉽게 얻을 수 있었습니다.

예를 들어 ‘product.png’ 화면 이미지로 부터 “0.99” 금액이 텍스트로 명기된 버튼을 찾기 위해서 아래와 같은 작업을 수행합니다.

1) textract 서비스를 호출하여 이미지에서 텍스트들의 위치값을 추출합니다.

aws textract analyze-id --document-pages \ 
'[{"S3Object":{"Bucket":"qa.ai.test","Name":"temp/product.png"}}]' \ 
--region ap-northeast-2 > textract.txt

2) 아래와 같이 Claude 3.5 Sonnet 모델을 호출하여 특정 텍스트 (‘0.99’)를 가진 버튼의 좌표값을 얻습니다.

[그림6. Claude 3.5 Sonnet모델을 호출하여 $0.99의 좌표값 찾기 ]

최적의 모델 선택(Haiku VS Sonnet)

LLM 모델 선정에 있어서 처음에는 당시 출시되었던 Claude 모델인 Claude 3 Haiku를 선택하여 진행했지만 해당 모델은 한글 지원 부분에서 이슈가 있었고 또한 지정한 JSON schema를 따르지 않는 문제가 발생하였습니다. Claude 3.5 Sonnet이 출시된 이후 해당 모델을 적용하여 문제들을 해결하고 동시에 응답 속도 및 정확도를 높일 수 있었습니다. Claude 모델군에서 계속 모델의 성능이 개선되고 새로운 버전이 출시되고 있기 때문에 추후에도 성능 및 비용을 고려하여 새로운 모델 버전으로 업데이트가 될 것을 예상합니다.

QA 자동화 테스트 범위 제한

Claude 모델을 처음 적용할 때는 게임 화면 이미지 정보만으로는 모델이 품질 테스트 성공, 실패를 판단하기에 정보가 부족하지 않을까 하는 걱정 때문에 모델 입력으로 테스트에 참조할 이미지뿐만 아니라 결제 정보 내역이 담긴 메타 데이터를 결제 데이타베이스로 부터 가져와서 같이 Claude 모델의 입력으로 주었습니다. 하지만 이미지 정보에 추가로 다양한 메타 정보를 주는 것이 오히려 결과의 정확성을 낮추는 현상을 발견하였습니다. 따라서 기존에 제공되던 결제 정보는 없애고 이미지 데이터만 모델 입력으로 제공하여 인식하도록 변경하였습니다. 제공하는 이미지의 수도 기존의 12개에서 4개로 줄였고, 테스트 범위도 단일 재화(루비/잼 등) 상품에만 초점을 맞추었습니다. 결과적으로, Claude 모델에게 결제 과정의 스크린 샷 정보로만 결제 성공/실패를 판단하게 함으로써 오히려 환각을 없애고 정확도를 높이면서도 전체 아키텍쳐를 단순화할 수 있었습니다. 이러한 과정을 통해, 정보의 양보다 꼭 필요한 가치 있는 정보의 품질이 더 중요함을 알 수 있었습니다.

LangChain 적용

마지막으로 오픈소스 기반의 LLM(Large Language Model) 어플리케션의 개발 프레임워크 도구인 랭체인(LangChain)을 적용하여 LangChain의 Prompt Template를 사용함으로써 Prompt의 재사용 및 유지보수성을 높이고 프롬프팅도 더욱 간단하고 명확해지도록 하여 추후 다른 테스트 시나리오로의 확장에도 대비하도록 하였습니다.

아래는 게임 화면 이미지를 통해 Claude 3.5 Sonnet 모델을 사용하여 게임의 결제 기능을 테스트하는 예제입니다.

import os
# langchain
from langchain_aws import ChatBedrock
from langchain_core.prompts import ChatPromptTemplate

def requset_to_bedrock(target_image):
    llm = ChatBedrock(
        credentials_profile_name="bedrock",
        model_id="anthropic.claude-3-5-sonnet-20240620-v1:0",
    )
    prompt = ChatPromptTemplate.from_messages(
[
   (
        "system", 
        "QA를 전문으로하는 머신으로 자세하게 과정과 설명을하며 정확한 결과를 낸다. 이미지에 대한 설명을 다음과 같이 작성할때, 입력되는 이미지에 대해 각각 답변한다. 숫자를 비교할 때, 명확하게 확인한다."
    ),
    (
        "user",
        [
            {
                "type": "image_url",
                "image_url": {"url": "{image_success}"}
            },
            {
                "type": "text",
                "text": """
                - steps : ["사용자가 특정 게임 내 재화를 구매하려고 시도했습니다.", "결제 프로세스가 정상 진행됐습니다.", "결제가 성공했다는 메시지가 팝업으로 표시되었습니다."]
                - process : "1,200원(0.99달러)을 사용해서 재화1 10개를 구매한다."
                - success_score : "10", 
                - reason : "정상 결제완료 팝업 메시지가 나오며, 결제한 상품에 맞게 재화가 증가되었다.",
                """
            },
            {
                "type": "image_url",
                "image_url": {"url": "{image_fail}"}
            },
            {
                "type": "text",
                "text": """
                - steps : ["사용자가 특정 게임 내 재화를 구매하려고 시도했습니다.", "결제 프로세스가 진행되는 중에 문제가 발생했습니다.", "결제가 실패했다는 메시지가 팝업으로 표시되었습니다."]
                - process : "4,900원(3.99달러)을 사용해서 재화1 42개를 구매한다."
                - success_score : "0"
                - reason : "결제 실패 팝업 메시지가 나오며, 결제한 상품에 맞게 재화가 증가되지 않았다."
                
                """
            },
            {
                "type": "image_url",
                "image_url": {"url": "{image_target}"}
            }
        ]
    )
])

결론

Amazon Bedrock 서비스를 이용하여 게임 QA 공정에 생성형 AI를 도입하여 다음과 같은 효과를 얻을 수 있었습니다.

업무 효율성 향상 측면에서는 Claude 3.5 Sonnet 모델을 적용하여 결제 테스트를 자동화하여 기존 결제 테스트에 걸리는 시간을 기존 20분에서 5분으로 단축할 수 있었습니다. 또한 현재 진행 중인 추가 최적화 작업을 통해 1분 이내로 줄이는 것을 목표로 하고 있습니다.

비용 절감 측면에서 살펴보면 Amazon Bedrock이 제공하는 Claude 3.5 Sonnet 모델을 사용하는 비용은 모델 호출 건당 $0.15 입니다. Claude 3.5 Sonnet 모델이 분석하기 위해서 큰 이미지 해상도가 필요하지 않기 때문에 4320 × 1989 해상도의 스크린 샷 크기를 이용하여 입력 토큰 비용을 줄일 수 있었습니다. 또한 Amazon API Gateway, AWS Lambda 등 사용할 때만 비용이 발생하는 서버리스 기반의 서비스들을 사용하여 불필요한 비용을 최소화하였습니다. 실제 적용 시 QA 테스트를 위해 한달 50번 호출 기준으로 약 $8불 정보의 비용이 발생하였습니다. 특히 QA 자동화 서비스의 개발과 최적화에 있어서 AI에 대한 전문 인력 없이도 AWS 서비스들을 이용하여 빠르게 개발이 가능했고 AWS 기술 지원을 통해 이슈들을 빠르게 해결할 수 있었습니다.

QA 결제 테스트에 대한 자동화 시스템은 현재 2개 게임의 QA 과정에 먼저 적용을 하였고 이를 전체 게임으로 확장할 예정입니다. 또한 결제 시나리오 이외에도 로그인 검증, 출석부, 정기적 보상 등 다른 반복적인 QA 테스트 시나리오들에 대해서도 적용 중에 있으며 내년 상반기까지 루틴 한 QA 업무들 중 50%를 자동화하는 것을 목표로 하고 있습니다. 추가로 현재는 QA 팀에서 Prompt Template에 맞추어 수동으로 프롬프트를 작성하고 있지만 누구나 전문 지식 없이 프롬프트를 작성할 수 있도록 자연어 Input에 대해 LLM 모델이 QA 테스트를 위한 프롬프트를 자동으로 생성해 주도록 추가 고도화 작업을 하고 있습니다.

AWS 기술 블로그