내가 만든 게임을 AI에게 플레이시켜봤다 - 에이전트 테스트 자동화 실험기

게임 개발자의 영원한 고민, 플레이테스트

게임을 만들어 본 분이라면 다 아실 거예요. 코드를 짜는 것보다 더 힘든 게 바로 플레이테스트거든요. 내가 만든 퍼즐이 너무 어려운 건 아닌지, 튜토리얼이 친절한지, 중간에 막히는 구간은 없는지를 확인하려면 누군가가 처음부터 끝까지 게임을 해봐야 하잖아요. 그런데 이걸 매번 사람을 구해서 시키기도 어렵고, 본인이 직접 하면 이미 답을 알고 있으니 객관적인 피드백이 안 나와요.

인터랙티브 픽션(텍스트로 진행되는 어드벤처 게임이에요) 개발자인 Jeff Schomay은 이 문제를 좀 색다른 방식으로 풀었습니다. 바로 AI 에이전트한테 자기 게임을 플레이시키는 거죠. 단순히 LLM에게 "이 게임 어때?" 하고 묻는 게 아니라, AI가 진짜 플레이어처럼 게임 화면을 읽고, 명령어를 입력하고, 결과를 보고 다음 행동을 결정하게 만든 거예요.

어떻게 동작하는지 뜯어보기

핵심 아이디어는 의외로 단순해요. 게임은 보통 텍스트나 화면을 출력하고, 플레이어는 그걸 보고 입력을 하잖아요. 이 입출력 루프 사이에 AI를 끼워 넣는 거예요. 게임의 출력을 LLM한테 "지금 화면이 이렇게 생겼어"라고 전달하고, LLM이 "그럼 나는 북쪽으로 가볼게" 같은 명령을 만들어서 다시 게임에 입력하는 식이죠.

여기서 재밌는 건 그냥 시키는 게 아니라 에이전트(agent) 형태로 만들었다는 점이에요. 에이전트가 뭐냐면, 단순히 한 번 답하고 끝나는 챗봇이 아니라 목표를 가지고 여러 단계에 걸쳐 스스로 판단하면서 행동하는 AI를 말해요. 예를 들어 "이 게임을 클리어해"라는 목표를 주면, AI가 매 순간 상황을 파악하고 "지금은 열쇠를 찾아야겠다", "이제 문을 열어보자" 같은 중간 목표를 스스로 세우면서 진행해요.

개발자는 여기에 메모리와 도구 사용 기능을 붙였어요. 메모리는 AI가 지금까지 어디를 갔고 뭘 시도했는지 기억하게 해주는 장치예요. 이게 없으면 AI가 같은 방을 빙빙 돌면서 똑같은 명령만 반복하거든요. 도구는 "인벤토리 확인하기", "지도 그려보기" 같은 보조 기능들이고요. 사람이 게임할 때 종이에 메모하면서 하는 것과 비슷한 역할이에요.

단순한 자동화가 아닌 진짜 테스터

이 시스템의 진짜 가치는 버그와 디자인 문제를 발견하는 능력에 있어요. AI가 게임을 플레이하다가 막히면, 개발자는 그 로그를 보고 "아, 이 지점에서 사람들이 헷갈리겠구나" 하고 알 수 있어요. 또 AI가 의도하지 않은 방식으로 퍼즐을 풀어버리거나, 개발자가 미처 생각 못한 명령어 조합으로 게임을 깨버리면 그게 곧 버그 리포트가 되는 거죠.

특히 인터랙티브 픽션처럼 자연어로 명령을 입력하는 게임에서는 이게 엄청나게 유용해요. 플레이어가 "take key"라고 쓸지 "pick up the key"라고 쓸지, 아니면 "grab key"라고 쓸지 모르거든요. 사람 테스터 한 명이 시도할 수 있는 표현은 한정적인데, AI는 다양한 방식으로 시도하면서 게임의 파서(명령어 해석기)가 어디서 막히는지 빠르게 찾아내요.

업계 흐름 속 위치

사실 AI한테 게임을 시키는 시도는 옛날부터 있었어요. 딥마인드가 알파고 이후에 스타크래프트나 아타리 게임에 강화학습을 적용한 게 대표적이죠. 하지만 그건 게임을 "잘 플레이하기" 위한 거였고, 이번 사례는 게임을 테스트하기 위한 거라는 점에서 결이 달라요.

비슷한 흐름으로 요즘 소프트웨어 업계에서는 LLM 에이전트를 QA 자동화에 쓰려는 시도가 많아요. 예를 들어 웹 앱을 테스트할 때 Playwright 같은 도구로 사람이 시나리오를 짜는 대신, AI가 화면을 보고 알아서 클릭하면서 버그를 찾는 식이죠. Anthropic의 Computer Use나 OpenAI의 Operator 같은 것도 결국 이런 "AI가 화면을 보고 행동하는" 패러다임의 연장선이에요. 게임 플레이테스트는 이런 기술이 자연스럽게 적용될 수 있는 좋은 도메인이고요.

한국 개발자에게 주는 시사점

이 사례에서 우리가 가져갈 수 있는 건 두 가지예요. 첫째, 반복적이고 탐색적인 작업은 LLM 에이전트로 자동화할 만하다는 거예요. 게임 플레이테스트뿐만 아니라 신규 가입 플로우 테스트, 결제 시나리오 검증, 관리자 페이지의 모든 버튼 눌러보기 같은 작업이 다 비슷한 성격이거든요. 인디 게임 개발자라면 당장 자기 게임에 적용해볼 수도 있고, 웹 서비스 개발자라면 E2E 테스트 보조 도구로 응용할 수 있어요.

둘째, AI 에이전트를 만들 때 중요한 건 메모리와 도구 설계라는 점이에요. LLM 자체가 똑똑한 것보다, 그 LLM이 상황을 어떻게 기억하고 어떤 도구를 쓸 수 있는지가 결과 품질을 좌우해요. 사이드 프로젝트로 에이전트를 만들어보고 싶다면, 거창한 모델 파인튜닝보다 "내가 이 일을 사람한테 시킨다면 어떤 정보와 도구를 줘야 할까?"부터 고민해보면 좋아요.

마무리

결국 이 글의 핵심은 AI를 "답을 주는 도구"가 아니라 "행동하는 동료"로 활용하면 새로운 가능성이 열린다는 거예요. 내가 만든 무언가를 AI한테 직접 써보게 하고, 그 과정에서 나온 로그를 보면서 개선점을 찾는 워크플로우는 게임뿐만 아니라 모든 소프트웨어 개발에 적용될 수 있을 거예요.

여러분이 만들고 있는 서비스나 앱에 AI 에이전트를 테스터로 붙인다면, 가장 먼저 어떤 시나리오를 검증해보고 싶으신가요?