
EAS Workflows를 사용하여 몇 분 만에 Expo 앱을 위한 AI QA 에이전트 구축하기
요약
EAS Workflows를 활용하여 Expo 모바일 앱을 위한 AI QA 에이전트를 구축하는 방법을 소개합니다. AI가 생성한 프론트엔드 코드의 품질을 검증하기 위해 Android 및 iOS 환경에서 자동화된 테스트를 수행하는 워크플로우를 제안합니다.
핵심 포인트
- EAS Workflows를 통한 커스텀 작업 실행 및 빌드 재사용
- AI 에이전트 생성 코드의 검증을 위한 모바일 QA 프로세스 구축
- agent-device를 활용한 Android 및 iOS 자동화 구현
- 추가 비용 없이 기존 도구들을 조합한 가벼운 에이전트 구성
Michał Pierzchała가 expo.dev/blog에 처음 게시했습니다.
이 글은 Callstack의 R&D Incubator에서 Principal Engineer로 근무하며 agent-device 및 React Native Testing Library를 만든 Michał Pierzchała의 게스트 포스트입니다.
…
AI 에이전트(AI agents)는 많은 양의 코드를 빠르게 생성하는 데 탁월합니다. 더 많은 코드는 우리 코드베이스를 대상으로 하는 더 많은 PR(Pull Requests)을 의미하며, 에이전트가 생성하는 코드와 함께 작동하고 확장 가능한 코드 품질 보증(QA) 프로세스에 대한 수요도 더욱 증가함을 의미합니다.
백엔드 코드베이스에 기여하는 AI 에이전트는 통합 테스트(integration tests)를 통해 잘 수행되는 경우가 많지만, 프론트엔드 쪽은 상황이 그리 밝지 않습니다. iOS 및 Android 모바일 앱과 같이 UI를 생성하는 코드를 작성할 때, 최신 모델들은 결과를 확인하지 않고도 놀라울 정도로 잘 해내는 경우가 많습니다 (이를 더 쉽게 만들어주는 선언적 UI(declarative UI)를 제공하는 React에게 감사할 따름입니다). 하지만 많은 경우 그들은 목표를 놓치곤 합니다. 모바일 기기에 접근할 수 없고 오직 코드만 읽을 수 있는 하드코어 React Native 개발자를 상상해 보세요. 그들이 코드만 보고 작업을 완벽하게 해낼 것이라고 얼마나 확신할 수 있을까요? 힌트: 그리 높지 않습니다. 검증(Verification)이 핵심입니다.
이것이 바로 우리가 Expo 앱을 위해 메우고자 하는 간극입니다. 그리고 이 글에서, 저는 기존 도구들을 사용하여 추가 비용 없이 이를 수행하는 방법을 보여드리겠습니다. 시작해 봅시다!
EAS Workflows를 사용하면 이미 빌드(builds)를 재사용하고, Android 및 iOS에서 커스텀 작업(custom jobs)을 실행하며, GitHub pull requests에 댓글을 달 수 있습니다. 이는 거대한 커스텀 플랫폼을 도입하지 않고도 오늘 바로 가벼운 QA 에이전트를 구축하기에 충분하다는 것이 밝혀졌습니다.
저는 여기에 최소한의 템플릿을 준비했습니다: callstackincubator/eas-agent-device.
설정은 의도적으로 작게 구성되었습니다:
- CNG (Continuous Native Generation)가 적용된 Expo 앱
- 오케스트레이션 (Orchestration)을 위한 EAS Workflows
- AI SDK를 사용하는 아주 작은 Node.js QA 에이전트
- Android 및 iOS 자동화를 위한
agent-device - Android 및 iOS QA 결과가 포함된 하나의 GitHub 댓글
중요한 점은 "AI"라는 라벨이 아닙니다. 몇 분 만에 작동하는 베이스라인을 시작할 수 있고, 팀에서 더 많은 커버리지가 필요함에 따라 이를 확장할 수 있다는 점입니다.
목표
모든 풀 리퀘스트 (Pull Request)에 대해 우리는 다음을 수행하고자 합니다:
- 가능한 경우 최신 JS가 포함된 기존 모바일 릴리스 빌드 (Release Build) 재사용
- 에뮬레이터 (Emulator) 또는 시뮬레이터 (Simulator) 부팅
- 앱 설치 및 실행
- 에이전트가 UI를 검사하고 스크린샷 촬영
- PR 아래에 짧은 QA 요약 게시
그게 전부입니다. 거대한 테스트 프레임워크가 아닙니다. 모든 E2E (End-to-End) 테스트를 대체하는 것도 아닙니다. 그저 모바일 UI 변경 사항에 대한 실용적인 QA 루프일 뿐입니다.
EAS Workflows가 이 작업에 매우 적합한 이유
가장 큰 이유는 EAS Workflows가 이미 모바일 특화 CI (Continuous Integration)를 이해하고 있기 때문입니다.
쉽게 얻을 수 있는 것들:
- 네이티브 변경 사항을 감지하는
fingerprint - 재사용 가능한 빌드를 찾는
get-build - JS만 변경되었을 때 네이티브 코드를 다시 빌드하지 않도록 하는
repack - Android 및 iOS 기기를 실행할 수 있는 가상화 기능이 포함된
linux및macos러너 (Runners) - 결과를 PR로 다시 보내는
github-comment
따라서 모바일 자동화를 일반적인 CI 시스템에 억지로 끼워 맞추는 대신, 모바일 구성 요소가 이미 존재하는 곳에 전체 파이프라인을 유지할 수 있습니다. 이는 설정을 훨씬 더 이해하기 쉽게 만들어 줍니다.
여기서 언급하자면, Android 에뮬레이터를 열기 위해서는 처음부터 설치해야 하는 linux-medium-nested-virtualization 이미지가 Android 작업에 필요하며, iOS 시뮬레이터의 경우 이미 사용 가능한 macos-medium 이미지(또는 그 이상)가 필요합니다. 머신의 유연성과 제가 이를 스크립트로 작성할 수 있는 범위에 대해 매우 긍정적으로 놀랐다는 점을 말씀드리고 싶습니다.
이 워크플로 구조에서 시작하기
핵심 워크플로는 간단하며 단일 화면에 들어옵니다:
jobs:
fingerprint:
type: fingerprint
...
iOS의 경우도 개념은 동일하며, 시뮬레이터 빌드가 포함된 macOS 워커 (worker)에서 실행될 뿐입니다. Android와 iOS가 병렬로 실행되는 전체 작동 버전은 다음 리포지토리에서 확인할 수 있습니다: .eas/workflows/agent-qa-mobile.yml
핵심 설계 선택: 부트스트랩 (bootstrap)과 QA의 분리
이것은 제가 강력하게 권장하는 한 가지 사항입니다.
언뜻 보기에는 에이전트가 앱 설치, 실행, 탐색, 검사, 보고까지 모든 것을 수행하기를 원할 수도 있습니다. 하지만 실제로 그렇게 하면 시스템이 필요 이상으로 취약해집니다. 에이전트는 우리의 도구를 잘못 사용할 수도 있고, 우리가 요청한 지침을 읽지 않기로 선택할 수도 있으며, 사용하는 CLI (Command Line Interface)의 플래그를 환각 (hallucinate)할 수도 있습니다 (저도 그런 경험이 있습니다).
따라서 우리의 AI 에이전트가 가끔이 아니라 지속적으로 신뢰할 수 있게 작동하도록 만드는 핵심은 워크플로 (workflow)를 가능한 한 결정론적 (deterministic)으로 유지하는 것입니다. agent-device를 사용하면 디바이스에서 앱을 설치하고 실행할 때 항상 정확한 부트스트랩 (bootstrap) 파라미터를 제공하도록 이 과정을 매우 쉽게 스크립트화할 수 있습니다:
#!/usr/bin/env bash
# Phase 1: 결정론적 부트스트랩 (deterministic bootstrap)
...
agent-device는 우리의 작업 (job)에 설정된 AGENT_DEVICE_PLATFORM 환경 변수 (environment variable) 덕분에 어떤 플랫폼을 실행해야 하는지 알고 있습니다.
스크립트화하기 더 어려운 QA 프로세스의 나머지 부분은 에이전트 주도 (agent-driven) 방식으로 남겨둘 수 있습니다. 에이전트는 PR (Pull Request)에서 수락 기준 (acceptance criteria)을 추론하고, 접근성 트리 (accessibility tree)를 통해 토큰 효율적인 방식으로 UI를 검사하며, 약간의 탐색을 수행하고, 스크린샷을 찍고, 발생한 일을 요약합니다.
# Phase 2: 가변적인 에이전트 주도 흐름 (variable agent-driven flow)
npm run agent-qa
지난 한 달 동안 다양한 에이전트를 구축해 온 제 경험에 따르면, 이러한 분리가 워크플로를 훨씬 더 신뢰할 수 있게 만듭니다. 즉, 에이전트가 아티팩트 (artifact) 경로를 추측하거나 설치 명령어를 직접 찾아낼 필요가 없다는 것을 의미합니다.
에이전트는 매우 작게 유지될 수 있습니다
앱이 이미 실행 중이라면, 에이전트에는 몇 가지 도구만 있으면 됩니다:
- PR 컨텍스트 (context) 읽기
agent-device스킬 (skill) 로드agent-device를 통해snapshot,press,screenshot과 같은 UI 액션 (action) 실행- 최종 보고서 작성
간소화된 버전은 다음과 같습니다:
import { ToolLoopAgent } from 'ai';
const agent = new ToolLoopAgent({
...
이것만으로도 빠르게 시작하여 훌륭한 결과물로 반복 개선(iterate)해 나갈 수 있습니다. 저는 제어권과 완성형 도구(batteries-included tools) 사이의 균형이 잘 잡힌 Vercel의 AI SDK를 사용하고 있습니다. 게다가 이들의 AI Gateway 서비스를 통해 제가 선호하는 모든 모델에 접근할 수 있으며(적어도 아직은 추가 비용 없이), 만약 또 다른 구독을 원하지 않는다면 기존의 OPENAI_API_KEY를 사용하여 openai 프로바이더 (provider)를 대신 사용할 수도 있습니다. 이는 OpenAI뿐만 아니라 다른 프로바이더 (providers)에도 적용됩니다.
전체 에이전트 코드는 여기에 있습니다: scripts/agent-qa/index.ts - 최대한 간결하게 유지하려고 노력했습니다.
필요한 것만 보고하기
출력 결과는 작고 유용하게 유지하세요. 저희 템플릿에서는 각 플랫폼이 passed, failed, blocked, unsure 중 하나의 검증 상태 (verification status)를 생성합니다. 그다음 요약, 수행된 체크 항목, 발견된 문제, 스크린샷, 그리고 (주로 실패한 QA 검증 디버깅을 위한) 접이식 블록 내의 전체 JSON 보고서가 포함된 짧은 섹션이 이어집니다.
마지막 상태인 unsure는 중요합니다. 모바일 UI는 구조화된 자동화 출력만으로는 항상 검증하기 쉽지 않습니다. 때로는 접근성 트리 (accessibility trees)가 큰 도움이 되기도 하고, 때로는 스크린샷이 가장 강력한 증거가 되기도 합니다. 만약 에이전트가 결과를 깔끔하게 증명할 수 없다면, 그렇게 말하고 이미지를 첨부해야 합니다.
그것이 아는 척을 하는 것보다 훨씬 낫습니다.
마지막 단계: Pull Request 아래에 댓글 달기
사람이 검증할 때와 마찬가지로, 에이전트가 무엇을 검증할 수 있었는지(또는 없었는지)에 대한 전반적인 개요를 파악하기 위해서는 작업 아래에 짧은 댓글을 남기는 것만으로도 충분한 경우가 많습니다. 또한 변경 사항이 앱을 망가뜨리지 않는지 진정으로 평가하기 위해 자주 필요한 시각적 확인 (visual confirmation)도 함께 제공됩니다. 단일 PR 댓글은 매우 효과적입니다:
## Agent QA
| Platform | Status |
...
이렇게 하면 리뷰어들이 이미 머물고 있는 곳에 필요한 정보와 시각적 피드백을 갖춘 결과를 정확히 배치할 수 있습니다.

💡 GitHub 댓글에 스크린샷을 업로드하는 공식 API는 없으므로, 대신 본 예제에서는 이미지를 저장하기 위한 제3자 클라우드로 Vercel Blob을 사용했습니다. AWS S3와 같이 귀하의 사용 사례에 적합한 솔루션으로 교체하여 사용하세요.
오늘 바로 시도해보고 싶다면 추천하는 방법
- Expo 대시보드에서 GitHub 프로젝트를 EAS Workflows에 연결하세요.
- 먼저 Android와 같이 하나의 플랫폼부터 시작하세요.
- CNG (Continuous Native Generation)를 사용하고 네이티브 빌드 재사용 (native build reuse)을 활성화된 상태로 유지하세요.
- QA 빌드 프로필을 프로덕션 (production)과 분리하여 유지하세요.
- 부트스트랩 (bootstrap)을 결정론적 (deterministic)으로 만드세요.
- 에이전트를 블랙박스 (black-box) 형태로만 유지하세요.
- 10개의 서로 다른 아티팩트 (artifacts) 대신, 하나의 PR (Pull Request) 댓글만 게시하세요.
- 스크린샷을 조기에 추가하세요. 큰 도움이 됩니다.
그다음, 작동하기 시작하면 다음과 같이 확장하세요:
- iOS 추가
- Blob 스토리지에 스크린샷 업로드
- 더 나은 셀렉터 (selectors) 추가
- 성공적인 탐색적 테스트 (exploratory checks)를 더 결정론적인 흐름 (deterministic flows)으로 전환
핵심 요약
유용한 모바일 QA 자동화를 구현하기 위해 거대한 AI 테스트 플랫폼이 반드시 필요한 것은 아닙니다.
Expo는 EAS Workflows와 함께 이미 대부분의 인프라를 제공합니다:
- 빌드 재사용 (build reuse): 빠른 반복 (iteration)과 최신 JS 번들 (JS bundle)을 위한 재포장 (repack)
- 모바일 CI 워커 (mobile CI workers): 스크립팅 및 가상화가 지원되어 시뮬레이터 (simulators) 및 에뮬레이터 (emulators) 사용 가능
- 워크플로 오케스트레이션 (workflow orchestration): 이 모든 것을 하나로 통합
- GitHub 통합 (GitHub integration): 인지 부하 (cognitive load)를 줄이고 검증 과정을 Pull Request 내부에서 유지
이러한 기반 위에서 커스텀 QA 에이전트는 놀라울 정도로 작게 유지될 수 있습니다. 또한 TypeScript 기반의 AI SDK 덕분에 모든 요구 사항에 맞춰 유연하게 조정할 수 있습니다.
이것이 제가 이 설정을 좋아하는 이유입니다. 간단한 템플릿에서 시작하여 오늘 바로 몇 분 만에 구축할 수 있으며, 실제로 더 많은 기능이 필요할 때만 확장해 나가면 됩니다.
여기서 시작하세요: callstackincubator/eas-agent-device
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기