e2e 딥다이브
— AI가 조작하고, 테스트가 증명하는 앱 검증

1프로젝트 한줄 요약

e2e는 웹과 모바일 앱의 사용자 흐름을 검사하는 TypeScript 테스트 프레임워크입니다. agent.act()로 목표를 주면 에이전트가 화면을 읽고 조작합니다. 같은 테스트 안에서 expect(screen.getByRole(...))로 결과를 확인할 수 있습니다.

행동을 유연하게 만드는 일과, 행동의 결과가 맞는지 증명하는 일을 분리한 것이 이 프로젝트의 핵심입니다. AI에게 모든 판정을 맡기지 않아도 되고, 반대로 모든 클릭을 사람이 미리 지정할 필요도 없습니다.

1-1. 짧은 테스트로 읽는 역할 분담

아래는 가입 폼을 가진 학습용 앱을 가정한 예시입니다. docs/examples/quickstart/tests/agent.e2e.ts의 API 형태를 바탕으로, 목표와 확인 문구를 한국어로 바꿨습니다. 앱에 맞는 역할·이름·완료 문구가 있어야 합니다.

import { test } from '@e2e-dev/web';
import { expect } from 'e2e';

test('방문자가 체험 계정을 만든다', async ({ app, agent, screen }) => {
  await app.open('/');
  await agent.act('이름 {name}, 이메일 {email}로 무료 체험을 신청해 줘', {
    params: { name: '김배움', email: 'learner@example.test' },
  });
  await expect(screen.getByRole('status')).toContainText('체험 시작');
});

app은 앱의 입구, agent는 목표를 수행하는 조작자, screen은 플랫폼 공통 화면 탐색 창구입니다. 웹 엔진의 test를 가져오면 웹 전용 browser fixture도 사용할 수 있습니다. 공통 API만 쓰는 테스트는 e2e의 test로도 작성합니다.

1-2. AI 없이도 출발할 수 있다

README는 “에이전트 단계가 없는 테스트에는 모델이 필요 없다”고 설명합니다. packages/e2e/package.json에서도 ai와 모델 제공자 패키지를 선택적 peer dependency로 선언합니다. 먼저 locator 기반 테스트를 익히고, 변화가 잦은 조작 부분에만 에이전트를 추가하는 학습 순서가 가능합니다.

2왜 주목받는가

2-1. 짧은 기간에 모인 관심

2026-10-23 GitHub 기준 스타 11,746, 포크 610이며, 2026-07-22 생성되어 약 3개월 만에 TrendShift Monthly #20에 선정됐습니다. 이 숫자는 관심의 규모를 보여 줍니다. 실제 사용자 수, 성공률, 유지보수 비용까지 설명하는 수치는 아닙니다.

공개된 순위만으로 인기가 오른 원인을 확정할 수는 없습니다. 다만 README의 사용 방식과 소스 구조를 보면, 선택자 유지보수 부담을 줄이려는 시도, 반복 실행의 모델 비용을 줄이는 재생, 웹·모바일 공통 작성 방식이 개발자의 관심을 끌 만한 요소입니다. 다음 비교는 이 설계에 근거한 해석입니다.

2-2. 기존 자동화와 무엇이 다른가

비교 근거는 저장소의 docs/migrate/playwright.mdx, docs/migrate/maestro.mdx, packages/web/src/engine.ts입니다. 다른 제품의 전체 기능이나 성능 우열을 평가한 표는 아닙니다.

e2e는 Playwright를 버리는 도구가 아니라, Playwright 기반 웹 엔진과 별도 모바일 엔진을 하나의 테스트 실행 방식으로 묶는 도구입니다.

2-3. “모델 호출 0회”는 어느 범위의 이야기인가

README의 재생 설명은 조건을 충족한 에이전트 행동 단계에 해당합니다. packages/e2e/src/cache/identity.ts의 TraceCacheKind는 'act'만 허용합니다. agent.assert(), agent.waitFor(), agent.extract()는 현재 화면을 모델로 판단하므로 재생하지 않습니다.

2-4. 관심보다 더 유용한 학습 근거

packages/*/src의 TypeScript 계열 구현은 85,397줄, packages/*/tests는 95,892줄입니다. 테스트에는 단위·통합·타입 검사가 포함됩니다. 테스트 줄 수가 많다고 정확성이 증명되는 것은 아니지만, 성공 경로 외에 실패·중단·낡은 캐시를 어떻게 명세하는지 읽을 재료가 풍부합니다.

한편 Playwright 마이그레이션 문서는 fullyParallel의 동등 기능과 HTML 리포터가 없다고 표시합니다. 실제 packages/e2e/src/report/builtin.ts의 기본 리포터도 list, json, junit, markdown 네 가지입니다. 익숙한 도구의 기능을 전부 대체한다고 생각하면 학습과 도입 범위를 잘못 잡게 됩니다.

3기술 스택 전체 지도

3-1. 백엔드에 해당하는 부분: Node.js 실행기

이 저장소의 중심은 상시 운영하는 API 서버나 데이터베이스가 아니라 로컬 또는 CI에서 실행되는 Node.js 프로세스입니다. CLI가 설정과 테스트를 읽고, 워커가 앱·브라우저·기기를 다룹니다. MCP 서버도 이 실행 자원을 연결하는 창구이며, 일반 웹 서비스의 백엔드와 역할이 다릅니다.

e2e 패키지는 0.21.2, 웹 엔진은 0.15.2, 모바일 엔진은 0.12.3입니다. 최신 GitHub 릴리스 표기인 @e2e-dev/testmu@0.0.1을 runner의 버전으로 읽으면 안 됩니다.

3-2. 자동화 엔진과 프론트엔드를 분리해서 보기

따라서 “Next.js와 Expo가 e2e를 구동한다”는 해석은 틀립니다. 이들은 테스트받는 앱의 스택입니다. 프레임워크 자체를 쓸 때 대상 앱이 React나 Expo일 필요는 없습니다. examples/에는 SwiftUI·Compose·Flutter·.NET MAUI 예제도 있습니다.

3-3. 인프라·빌드·품질 검사

pnpm-workspace.yaml에는 allowBuilds로 의존성 빌드 허용 여부를 적고, undici 등의 하위 버전을 overrides로 조정합니다. ignoreWorkspaceCycles: true도 있습니다. 웹 엔진은 runner를 peer로 쓰고 runner 개발 테스트는 웹 엔진을 사용하므로, 루트 빌드는 패키지 순서를 명시합니다.

의존성의 이름을 외우기보다, 실행 제품·테스트 대상·개발 도구 중 어디에 쓰이는지 구분하는 것이 기술 스택을 읽는 첫 단계입니다.

4아키텍처 심화 분석

4-1. 전체 시스템 구조도

사용자가 작성한 e2e.config.ts + tests/*.e2e.ts
                      |
                      v
          e2e CLI / runner 공개 API
                      |
          설정 해석 · 수집 · 대상 선택
                      |
          buildWorkPlans / runUnits
                      |
          +-----------+------------+
          |                        |
     워커 프로세스 A           워커 프로세스 B
     한 target에 연결          한 target에 연결
          |                        |
          +---- 테스트 attempt ----+
                      |
       app / screen / expect / agent
                      |
        +-------------+----------------+
        |                              |
   locator assertion               agent.act
        |                              |
        |                   StepTraceSession.begin
        |                     /              \
        |                 재생 가능          기록 없음·일반 모드 불일치
        |                    |                    |
        |                replayTrace        StepExecutor
        |                    |              기본: AI SDK 도구 루프
        +--------------------+--------------------+
                             |
                 e2e/engine 공통 계약
                  /                    \
    @e2e-dev/web                        @e2e-dev/mobile
    PlaywrightSurface                  AgentDeviceSurface
         |                                  |
    브라우저 / BrowserProvider          기기 / DeviceProvider

  뒤따른 검증 성공 --> 쓰기 허용 시 attempt 종료 때 캐시 확정
  결과·실패 근거   --> JSON / JUnit / Markdown / 터미널
  외부 코딩 에이전트 --> MCP stdio --> 세션·동작 도구

위 도식의 중심은 화면 자체가 아니라 화면을 관찰하고 조작하는 공통 계약입니다. 모델과 재생기, locator가 서로 다른 브라우저를 직접 만지는 대신 같은 실행 계층을 통과합니다. 이 덕분에 예산·정책·기록 규칙을 여러 구현에 반복해서 쓰는 부담을 줄입니다.

4-2. 패턴 ① 계약과 capability로 구현을 교체한다

packages/e2e/src/engine/manifest.ts의 defineEngine()은 이름·버전·spiVersion을 확인하고, 제공된 훅으로 capability 집합을 만듭니다. 일반 객체의 알 수 없는 키는 오류입니다. perform이 있으면 observe와 지원 actions도 있어야 합니다.

// defineEngine()의 실제 검증 중 일부
if (spec.perform !== undefined) {
  if (!capabilities.has('observation')) {
    throw invalid(name, 'declares perform without observe: action targets are observation refs');
  }
  if (spec.actions === undefined) {
    throw invalid(name, 'declares perform without actions: list the action kinds the surface honors');
  }
  capabilities.add('actions');
}

즉 “버튼을 누를 수 있다”는 선언은 “지금 관찰한 버튼을 가리킬 수 있다”는 조건에 기대고 있습니다. TypeScript 타입만으로는 JavaScript 설정이나 외부 패키지의 실제 값을 보장하지 못하므로, 설정을 불러올 때 실제 값도 검증합니다.

4-3. 패턴 ② 기록과 신뢰 확정을 두 단계로 나눈다

packages/e2e/src/agent/step-cache.ts의 StepTraceSession은 캐시 조회·재생·실시간 기록을 맡습니다. stage()는 시작·종료 화면의 차이와 경로를 담은 기록을 준비합니다. 화면·경로 변화가 없거나 안전하게 기록할 수 없으면 저장 후보를 만들지 않습니다.

실시간 act 수행
    |
    +-- TraceRecorder가 확정된 동작 기록
    |
    +-- stage(): 종료 경로·등장/사라진 화면 단서 수집
    |
    +-- 뒤의 검증 단계 통과 여부 기록
    |
    v
settleStagedTraces(): attempt 종료 시, read-write·strict 해제 기준
    |
    +-- 뒤에서 검증됨 --> saved / kept
    +-- 검증 안 됨   --> unconfirmed / 조건에 따라 기존 항목 삭제
    +-- 중단됨       --> 저장·삭제하지 않음

핵심 비교식은 packages/e2e/src/cache/context.ts의 settleStagedTraces()에 있습니다. 현재 기록보다 뒤에 있는 검증 단계가 통과해야 승인됩니다. 테스트가 오류 없이 끝났다는 사실만으로는 충분하지 않습니다.

// 실제 승인 조건. 단계 번호는 시간 순서다.
const confirmed = entry.stepIndex < settlement.lastVerifiedStepIndex;

// 개념 예: act(2) → locator assertion(3)이 통과했다.
// 2 < 3 이므로 act 기록은 확인된 후보가 된다.

packages/e2e/src/cache/identity.ts는 프로젝트·테스트·대상·엔진 이름과 SPI·명령·매개변수·에이전트 문맥 등을 키에 담습니다. 같은 명령을 반복해도 호출 순번으로 구분합니다. 모델 변경과 엔진 패키지 버전 변경은 직접적인 키 변경 사유가 아닙니다. 엔진 이름과 SPI는 키에 들어가며, 실제 화면 적합성은 재생 중 다시 확인합니다.

packages/e2e/src/agent/step-cache.ts의 StepTraceSession은 replayTrace()로 새 관측에서 대상을 다시 찾고, endStateMatches()에서 목표 상태가 재생 전부터 있었는지와 최종 상태가 맞는지를 확인합니다. 일반 모드에서 중간 재생이 어긋나면 진행한 앞부분을 전달하고 현재 화면에서 executor가 이어받습니다.

캐시의 가치는 저장 속도보다, 무엇을 다시 믿어도 되는지 결정하는 승인 규칙에 있습니다. 이 구조는 데이터베이스의 완전한 트랜잭션은 아니지만, 실행 중 준비와 종료 시 확정을 분리하는 사고법을 보여 줍니다.

저장 계층도 학습할 만합니다. packages/e2e/src/cache/store.ts의 FileCacheStore는 항목을 1,048,576바이트로 제한하고 SHA-256 형태의 키만 파일명으로 씁니다. packages/e2e/src/internal/atomic-write.ts의 writeFileAtomic()은 옆 임시 파일에 쓴 뒤 이름을 바꿉니다. 동시 기록은 잠금 없이 마지막 쓰기가 남는 구조이며, 캐시는 복구 가능한 보조 데이터로 취급합니다.

캐시의 기본 모드는 로컬에서 read-write, CI에서는 read-only입니다. 다만 설정으로 명시한 read-write는 CI에서도 유지하며, 사용자 정의 store는 CI의 기본 읽기 전용 전환에서 제외됩니다. strict 모드에서는 설정한 쓰기 모드와 관계없이 항목을 쓰거나 삭제하지 않습니다. packages/e2e/src/config/resolve.ts의 기본값 처리에서, 기본 쓰기 정책과 명시적인 설정을 구분하는 방식을 볼 수 있습니다.

4-4. 패턴 ③ 스케줄러를 상태와 수명으로 설계한다

packages/e2e/src/run/units.ts의 buildWorkPlans()는 setup 작업과 일반 파일 작업을 나눕니다. packages/e2e/src/run/scheduler.ts의 runUnits()가 이를 배분하며, 워커 하나는 한 target에 묶여 한 번에 한 작업 단위를 실행합니다. 같은 파일의 테스트는 선언 순서를 유지하고 파일 사이에서 병렬 실행합니다.

워커 상태: starting --> idle --> busy --> idle
                                  |
                        실패·인프라 문제 등
                                  v
                               retired --> 프로세스 종료

  target별 setup 완료 --> 그 target의 일반 파일 배정
  전체 workers 제한 + 엔진의 workers 제한 + 남은 작업 수

packages/e2e/src/run/worker/handle.ts의 ChildProcessRunner는 fork()와 IPC로 워커를 만들고 통신합니다. 종료 판정에는 exit보다 IPC가 비워진 뒤의 close 이벤트를 사용합니다. 워커가 사라지기 직전에 보낸 결과를 놓치지 않으려는 선택입니다.

plannedSlots()는 실행기 제한·엔진 제한·작업 수의 최솟값을 계산합니다. longestFirst()는 이전 실행에서 오래 걸린 파일을 먼저 배정하고 실행 시간 기록이 없는 파일은 그보다 우선 실행합니다. 워커를 늘리는 것 외에 마지막에 긴 파일 하나가 남는 시간을 줄이는 방법도 있음을 보여 줍니다.

재시도는 packages/e2e/src/run/retry.ts의 isRetryEligible(), runWithRetries(), retryVerdict()가 공유합니다. 시간 초과나 test 범주 오류가 대상이며, 다시 성공한 결과는 단순 passed가 아니라 flaky입니다. 오류가 설정 문제인지, 테스트 실패인지에 따라 대응이 달라집니다.

4-5. 패턴 ④ 모델의 제안을 닫힌 도구와 정책으로 제한한다

packages/e2e/src/agent/tool-loop.ts의 createToolLoopExecutor()는 도구 실행 루프·종료 판정·반복 감지·호출 수 집계를 묶습니다. 모델의 텍스트를 셸이나 임의 코드로 평가하는 방식이 아니라, 허용된 도구 인자를 해석해 실행 계층에 전달합니다.

packages/e2e/src/agent/secrets.ts의 authorizeSecretFill()은 등록된 비밀인지, 대상이 활성화된 편집 필드인지, password 용도의 비밀이 password 필드로 가는지 확인한 다음에야 값을 꺼냅니다. packages/e2e/src/cache/recorder.ts의 TraceRecorder는 typeSecret의 평문 대신 비밀 이름을 기록합니다.

다만 정책을 만능 격리로 읽으면 안 됩니다. packages/e2e/src/internal/urls.ts의 resolveNavigationUrl()은 http:·https:·정확한 about:blank를 허용하지만 호스트 허용 목록은 없습니다. 비밀 입력 승인에도 출처 제한이 없습니다. 테스트·설정·엔진 코드는 실행한 사용자의 OS 권한으로 작동합니다.

5디렉토리 구조 해부

e2e/
├── package.json / pnpm-workspace.yaml / pnpm-lock.yaml
├── tsconfig.base.json
├── packages/
│   ├── e2e/
│   │   ├── src/
│   │   │   ├── cli/ · config/ · collect/
│   │   │   ├── run/worker/
│   │   │   ├── engine/ · locator/ · expect/
│   │   │   ├── agent/ · cache/
│   │   │   └── report/ · mcp/ · oauth/ · telemetry/
│   │   ├── schema/
│   │   └── tests/  (unit/ · integration/ · types/ · live/)
│   ├── web/ · mobile/
│   ├── kernel/ · lightpanda/ · smol/
│   ├── eas/ · limrun/ · testmu/
│   └── decision/ · github/
├── apps/
│   ├── testbed/
│   ├── web-benchmark/
│   └── mobile-benchmark/
├── docs/  (reference/ · migrate/ · integrations/ · examples/)
├── examples/  (with-vite/ · with-next/ · with-expo/ 등)
├── scripts/
├── skills/ · plugins/
└── .github/workflows/

처음부터 모든 디렉토리를 읽기보다 docs/examples/quickstart/ → packages/web/src/engine.ts → packages/e2e/src/engine/manifest.ts → packages/e2e/src/agent/step-cache.ts 순서로 내려가면 사용법에서 계약과 구현으로 자연스럽게 연결됩니다.

처음 보는 모노레포에서는 “배포되는 코드”와 “그 코드를 사용하는 검증 앱”부터 가르면 읽어야 할 범위가 크게 줄어듭니다.

6학습 포인트 (기술별)

6-1. TypeScript: 타입과 실제 값의 경계

tsconfig.base.json은 strict 외에도 두 가지 중요한 옵션을 켭니다. exactOptionalPropertyTypes는 “키가 없음”과 “키는 있고 값이 undefined임”을 구분합니다. noUncheckedIndexedAccess는 배열·사전 조회 결과가 없을 수 있음을 드러냅니다.

// 학습용 축약 예시
type Options = { timeout?: number };
const absent: Options = {};
const present: Options = { timeout: 5000 };
// const wrong: Options = { timeout: undefined }; // 엄격 옵션에서는 오류

const table: Record<string, number> = { web: 1 };
const slots = table['mobile'];
if (slots !== undefined) console.log(slots + 1);

작은 실습: 선택적 설정 키를 세 개 만들고, 누락·undefined·잘못된 문자열을 각각 넣어 보세요. 타입 오류와 defineEngine() 같은 실행 중 오류가 서로 다른 입력 경로를 지킨다는 점을 설명해 봅니다.

6-2. 기술별 읽기와 확장 실험

코드 흐름을 읽을 때는 함수 하나의 구현과 그 함수를 검증하는 테스트 한 개를 짝지으면 이해 부담이 줄어듭니다.

6-3. 폴링은 “계속 기다리기”보다 좁은 개념이다

packages/e2e/src/expect/poll.ts의 pollMatcher()는 읽기 함수를 다시 호출하고 조건을 검사합니다. 개별 마감과 attempt 마감 중 빠른 쪽에서 멈추며, 취소 신호도 함께 받습니다. 읽기 자체가 끝나지 않는 경우에도 시간 제한을 적용합니다.

주의할 세부사항도 있습니다. docs/cache.mdx는 expect.poll()과 일반 값 assertion을 캐시 승인용 검증으로 세지 않는다고 설명합니다. 화면 locator assertion은 packages/e2e/src/expect/async.ts에서 verifies: true로 기록됩니다. “assertion이라는 이름이면 모두 같은 부수 효과가 있다”는 가정을 버리는 좋은 사례입니다.

같은 성공·실패를 표현하는 API라도, 실행 기록에서 맡는 역할은 다를 수 있으므로 호출부와 기록부를 함께 읽어야 합니다.

6-4. 테스트에서 요구사항을 복원하는 법

1. packages/e2e/tests/unit/retry.test.ts에서 재시도 뒤 성공을 무엇이라 부르는지 찾습니다.
2. packages/e2e/tests/unit/step-cache.test.ts에서 저장되는 경우와 저장되지 않는 경우를 나눕니다.
3. packages/e2e/tests/integration/trace-cache-replay.test.ts에서 실제 화면과 재생을 연결하는 검사를 읽습니다.
4. packages/e2e/tests/types/sdk-types.ts에서 @ts-expect-error로 금지하는 API 조합을 봅니다.

이 네 파일은 각각 상태 정책, 캐시 정책, 통합 동작, 공개 타입 계약을 보여 줍니다. 하나의 큰 테스트로 전부 확인하려 하기보다 실패 원인을 어느 층에서 빨리 발견할 수 있는지가 좋은 테스트 분할의 기준입니다.

7하드웨어 / 시스템 요구사항

7-1. 먼저 확인할 소프트웨어 조건

Node 범위의 ^22.22.3은 22 계열의 해당 패치 이상을 뜻하며, 뒤의 >=24.8.0과 합쳐집니다. 범위에 들어간다는 것과 CI에서 모든 버전을 시험했다는 것은 다릅니다. CI에서 명시적으로 검사하는 조합은 3절 표의 다섯 항목입니다.

7-2. 메모리·CPU·GPU는 얼마나 필요할까

핵심 설정 파일과 CI에는 PC용 공식 최소 RAM·디스크 용량이 명시되어 있지 않습니다. 아래 값은 단일 워커로 배우기 위한 보수적인 계획치이며, 프로젝트가 보증하는 최소 사양이나 실측 결과가 아닙니다.

packages/e2e/vitest.config.ts는 실제 브라우저·앱·워커 프로세스를 쓰는 통합 테스트를 maxWorkers: 3으로 제한합니다. CPU가 밀리면 올바른 기능도 시간 초과처럼 보일 수 있기 때문입니다. 내 학습 환경에서는 workers: 1부터 시작하는 편이 원인을 구분하기 쉽습니다.

7-3. 시간 제한도 시스템 자원이다

근거는 packages/e2e/src/config/resolve.ts입니다. 느린 환경에서 모든 timeout을 크게 늘리기 전에 어떤 단계가 밀리는지 확인해야 합니다. 앱 준비 실패, assertion 불일치, 모델 응답 지연은 서로 다른 문제입니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 본인 소유의 학습용 앱과 별도 테스트 프로젝트를 전제로 합니다. 예시의 http://localhost:3000은 앱의 실제 주소에 맞추고, 외부 서비스에 가입·결제하는 시나리오는 로컬 모형으로 대체합니다. 코드는 커밋 7e72ea2의 API 형태를 기준으로 합니다.

// e2e.config.ts
import type { E2EConfig } from 'e2e';
import { web } from '@e2e-dev/web';

export default {
  targets: [{ name: 'web', engine: web(), app: { url: 'http://localhost:3000' } }],
  workers: 1,
} satisfies E2EConfig;

// tests/greeting.e2e.ts
import { test } from '@e2e-dev/web';
import { expect } from 'e2e';

test('이름을 제출하면 인사한다', async ({ app, screen }) => {
  await app.open('/');
  await screen.getByRole('textbox', { name: '이름' }).fill('김배움');
  await screen.getByRole('button', { name: '제출' }).click();
  await expect(screen.getByRole('status')).toContainText('김배움');
});

# 의존성과 Chromium이 준비된 학습 프로젝트에서
npx e2e run tests/greeting.e2e.ts --workers 1 --reporter list,json

// 모델·캐시 설정을 마친 테스트 본문의 일부
await agent.act('이름 {name}을 입력하고 제출해 줘', {
  params: { name: '김배움' },
});
await expect(screen.getByRole('status')).toContainText('김배움');

// applyShard()의 실제 구간 계산
const size = Math.floor(items.length / shard.total);
const remainder = items.length % shard.total;
const from = (shard.index - 1) * size + Math.min(shard.index - 1, remainder);
const to = from + size + (shard.index - 1 < remainder ? 1 : 0);

실습의 완료 기준은 초록색 통과 표시 하나가 아니라, 의도적으로 틀리게 만들었을 때 예상한 층에서 실패하는지까지 확인하는 것입니다.

9관련 기술 심화 학습 로드맵

주당 3~5시간을 가정한 학습 계획입니다. TypeScript·Promise가 처음이면 1주차를 늘리고, 모바일 환경 준비가 어렵다면 웹과 가짜 화면만으로 5주차까지 진행할 수 있습니다.

주마다 소스 한 곳과 테스트 한 곳만 골라도 됩니다. 중요한 것은 읽는 파일 수보다 입력·출력·실패 조건을 본인 말로 다시 설명하는가입니다.

9-1. 관심 분야에 따른 다음 갈림길

• 프론트엔드: 접근성 이름과 역할을 먼저 공부하고, 복잡한 UI를 테스트 가능하게 만드는 컴포넌트 설계로 이어갑니다.
• 백엔드·인프라: 워커 교체·중단·작업 분배를 읽고, 작업 큐의 중복 실행과 정리 책임을 설계해 봅니다.
• AI 애플리케이션: 도구 루프·판정·캐시를 구분하고, 모델을 바꿀 때 캐시를 끈 평가와 실제 재생 운영을 따로 측정합니다.
• 모바일: projectSnapshot()과 golden snapshot 테스트를 읽고, OS별 접근성 차이를 같은 역할로 변환하는 연습을 합니다.

좋은 딥다이브의 끝은 저장소의 모든 파일을 아는 상태가 아니라, 작은 설계 선택의 이유를 다른 문제에 적용할 수 있는 상태입니다.

10핵심 키워드 사전

용어를 다시 읽을 때는 “그 용어가 어떤 실패를 막는가”를 붙여 보세요. revision은 낡은 관측, timeout은 끝나지 않는 대기, postcondition은 동작만 했을 뿐 결과는 틀린 재생, 스키마는 잘못된 데이터 형식을 다루는 장치입니다.

11참고 링크

11-1. 공식 저장소·사용 문서

• 공식 GitHub 저장소 · README, 이슈, 패키지별 변경 기록
• 공식 빠른 시작 · 엔진·모델·인증을 구성하는 현재 사용 안내
• 재생 캐시 문서 · 승인 조건과 캐시 상태의 의미
• 엔진 작성 안내 · 공통 계약을 구현하는 방법
• MCP 서버 안내 · 코딩 에이전트와 실시간 세션 연결
• 보안 경계 · 비밀 입력·화면·실행 권한의 제한
• 사용 정보 수집 안내 · 필드와 비활성화 방법
• @e2e-dev/testmu@0.0.1 릴리스 · 패키지별 릴리스라는 점에 주의

11-2. 이 글의 주요 코드 근거

• defineEngine() 계약 검증 · 웹 엔진 조립 · 모바일 엔진 조립
• 행동 단계의 캐시 수명 · 기록의 지연 확정 · 캐시 키 구성
• 워커 스케줄러 · 재시도 정책 · SDK 실행 옵션 검증
• 비밀 입력 승인 · 탐색 URL 정책 · CI 검사 구성

11-3. 관련 기술의 공식 학습 자료

• TypeScript 핸드북 · 타입·union·제네릭의 기초
• Node.js 자식 프로세스 · fork와 프로세스 이벤트
• Playwright locator 문서 · 역할·이름 기반 요소 찾기
• AI SDK 도구 호출 · 모델의 제안과 실제 함수 실행 연결
• MCP 공식 문서 · 도구·자원·클라이언트와 서버
• Vitest 안내 · 단위·통합 검사의 구성
• pnpm workspace 안내 · 여러 패키지 관리
• Apache License 2.0 원문 · 배포 시 확인할 라이선스
• TrendShift · 프로젝트 탐색과 트렌드 맥락

현재 상태 (2026-10-23 확인)

줄 수는 커밋 7e72ea2의 Git 추적 파일을 확장자별로 세었으며 빈 줄·주석·테스트·예제를 포함합니다. 마지막 개행이 없는 줄도 한 줄로 셉니다. JSON·잠금 파일·이미지·바이너리는 위 코드 합계에서 제외했습니다. 테스트 비중은 코드 커버리지를 뜻하지 않습니다.