핵심 가치: 버그의 조기 검출 (Shift-Left) 및 중장기적인 동작 확인 비용의 제로화

시각적 검증 (Visual Verification)의 필수성: 모바일 개발에서 작성된 Pull Request (PR)를 완벽하게 리뷰하기 위해서는, 코드가 아무리 견고한 아키텍처, 높은 가독성을 가지고 100%의 테스트 커버리지 (Test Coverage)를 달성했더라도, 리뷰어가 실제 UI 동작이나 플로우를 눈으로 확인할 수 있어야 한다. -
현상태의 생산성 병목 현상 극복: 현재의 모바일 앱 개발에서 개발자의 작업 중 가장 병목이 되는 것은 「동작 확인」과 「동영상 촬영·첨부」이다. 동영상 첨부와 「간이적인」 동작 확인이 동시에 해결되는 상태가 이상적이다. -
조기 버그 검출의 경제성 (Shift-Left Testing): 버그는 QA나 테스터 등 여러 사람의 손을 거치기 전에, 개발자 단계에서 가능한 한 조기에 검출하는 것이 가장 비용을 낮게 억제할 수 있다. 자동화 파이프라인을 통해 구현 직후에 비동기 검증이 상시 작동해야 하는 이유가 여기에 있다. -
가치 중심의 속도 제어: 신규 개발에서의 「간이적인」 동작 확인은 코드의 재사용성보다 「확인 완료까지의 속도」가 핵심이다. 이것들은 개발자의 개입 없이 병렬로 자동 실행되기 때문에, 실행 속도가 다소 느리더라도 리스크 테이크 (Risk-taking)가 가능하다. -
비용 복잡도의 제약: 파이프라인의 가동 건수가 증가해도 발생하는 인프라 비용은 항상 선형 미만, 즉 $O(n)$ 미만이어야 한다 (허용되는 느림의 임계값은 팀 내의 공통 인식과 가설에 기반한 ROI 계산을 따른다).

수동 리소스의 최소화와 가시화: 개발자 본인이 직접 동작 확인하는 것과 동등한 동영상을 기존보다 가능한 한 「낮은 비용」으로 녹화 가능하게 하여, 구현한 개발자 본인 및 리뷰어가 즉시 확인할 수 있는 환경을 제공한다. -
신규·추가 개발 비용의 억제 ($O(n ext{ log } n)$의 실현): 기존 기능의 추가 개발 및 신규 개발에 드는 동작 확인 비용의 복잡도가 장기적으로는 **$O(n ext{ log } n)$**으로 수렴하는 설계로 한다. 매번 나무를 처음부터 다시 만드는 것이 아니라, 작은 「가지 (컴포넌트/Assertion) 단위」를 재사용 가능하게 하고, 이것들을 의미 있는 「큰 레이어 (화면·플로우 단위)」로 단계적으로 빌드업 (Layer-up) 해 나가는 구조를 만든다. -
기존 기능 확인 비용의 제로화: 시스템이 고도화됨에 따라 회귀 테스트 (Regression)에 해당하는 기존 기능 확인에 투입되는 개발자의 동작 확인 비용을 중장기적으로 **「0 (Zero)」**으로 만든다.

매번 「나무」를 처음부터 새로 만드는 것이 아니라, 「작은 가지」를 재사용 가능한 에셋 (Asset)으로 스톡(Stock)해 두고, 그것들을 조합하여 큰 레이어 (컴포넌트 ➔ 화면 ➔ 풀 시나리오)로 빌드업해 나갑니다.

【비용 억제의 레이어업 아키텍처】
[ 1. 작은 가지 단위 (Base) ] ➔ 100% 재사용·돌려쓰기
├── 버튼 클릭
...

【핵심 질문】 어떻게 하면 저비용·초고속·안정적인 성능으로 스크립트를 작성할 수 있는가?

판단 기준 유형	요구 사항	상세 및 구현 방법
◆ Required	1시간 이내 작성	AI 에이전트의 스캐폴딩 (Scaffolding) 기술을 적용하여, 초기 골격의 자동 빌드를 통해 작성 속도를 확보.
◆ Required	재사용 가능	작성된 테스트 스크립트를 Repository에서 파일로 관리하여, 회귀 테스트 (Regression Test) 자산화 (중장기 비용 제로의 기반).
◆ Required	AI의 자기 루프	실행 에러 로그나 XML 계층 구조 (Hierarchy)를 피드백하여, AI가 자율적으로 스크립트를 자기 치유 (Self-Healing).
◆ Required	2회 이내 수정으로 성공	엄격한 구문 제약과 템플릿 기반 프롬프팅 (Prompting) 적용을 통해 엔지니어링의 신뢰성을 확보.
◆ Required	개발자가 리뷰 가능	기초 스크립트의 구문 구조를 간결하게 유지하여, 개발자가 직관적으로 판독 및 수정할 수 있도록 설계.
◇ Optional	5분 이내 작성	컨텍스트 (Context)의 경량화 및 최소한의 핵심 로직 자동 추출을 통해 빌드 시간을 최적화.
◇ Optional	멀티 플랫폼 SSOT	단일 진실 공급원 (Single Source of Truth, SSOT) 아키텍처를 통해, 크로스 플랫폼 간에 테스트 코드를 공통화.
◇ Optional	파일의 재수정 없음	초기 1회 생성만으로, 추가적인 수동 핸들링 없이 다이렉트로 실행 성공하는 것을 목표로 함.
◇ Optional	장기적인 토큰 방어	UI 트리 압축 기술 등을 활용하여, 장기적인 토큰 소비량을 $O(n ext{ } \log n)$으로 방어.
◇ Optional	테스터가 리뷰 가능	도메인 지식이 적은 QA·테스터 그룹도 전체 흐름을 쉽게 파악할 수 있는 네이티브 텍스트 포맷.

📂

보조 도구 후보: Figma UI/UX 스펙, 요구 정의서, 프로토타입 영상, Bajutsu, 기존 테스트 설계서 -
🤖

실현 수단: AI 에이전트, 테스트 파일에 의한 생성

【핵심 질문】 어떻게 하면 재현 안정성(Flaky 제로)을 유지한 채로, 인간이 허용할 수 있는 속도로 동작시킬 수 있는가?

판단 기준 유형	요구 사항	상세 및 구현 방법
◆ Required	속도의 상한선	인간이 수동으로 테스트하는 속도의 2.5배 이하(2.5배보다 짧은 시간)로 신속하게 완결될 것.
◆ Required	플래키 제로 (Flaky Zero)	비결정론적 (Non-deterministic) 요소를 배제하고, 완전한 결정론적 (Deterministic) 구동 환경을 보장 (조기 탐지의 정확성을 확보).
◇ Optional	타겟 속도	최적화된 런타임 (Runtime)을 통해, 인간이 수동으로 실행하는 속도의 1.2배 이하 시간까지 단축.
◇ Optional	런타임 제한	파이프라인의 병목을 방지하기 위해, 1개의 시나리오·영상당 재생 시간을 1분 이하로 강제.
◇ Optional	AI 개입의 분리	실행 시점에는 고정형 스크립트 엔진만을 가동하여, 실행 시마다 발생하는 불필요한 AI 호출 비용을 차단.

📂

보조 도구 후보: 애니메이션 속도 조정 (Scale Up) -
🛠️

후보 기술: Appium, Maestro, MobileMCP, Firebase Test Lab

【핵심 질문】 어떻게 하면, 어디에나 쉽게 첨부할 수 있고, 누구나 헤매지 않고 열람할 수 있는가?

◆

Required - GitHub에 표시 가능할 것: PR 코멘트 레이아웃 내에 인라인으로 매끄럽게 렌더링(임베디드 재생)될 것. -
◆

Required - Notion에 표시 가능할 것: 사내 지식 관리 도구인 Notion의 미디어 블록 및 링크 임베딩과 완전히 호환될 것. -
◇

Optional - 비교적 가벼운 용량 및 무변환·무압축: 리뷰어가 별도의 로딩이나 다운로드, 수동 인코딩을 거치지 않고, 다이렉트로 루프 재생하며 확인할 수 있는 구조 확보. -
🛠️

후보 기술: AI 에이전트, Maestro 기능, Playwright, Robolectric + Roborazzi, SwiftSnapshotTesting, Firebase Test Lab, TestPlans, simctl or screenrecord