QA에서 AI 어시스턴트를 위한 테스트 피라미드

QA에서 AI 어시스턴트를 위한 아키텍처 제약으로서의 테스트 피라미드

언어 모델이 테스트 설계자가 되면, 고전적인 테스트 피라미드가 단순한 권장 사항이 아닌 엄격한 기술적 요구사항으로 바뀝니다. 이유는 간단합니다: LLM의 컨텍스트 창은 복잡한 기능(Feature)의 전체 설명, 수십 개의 사용자 스토리(User Stories)와 태스크(Tasks)를 물리적으로 수용할 수 없기 때문입니다. "한 번에 모든 걸 넣어주기" 시도는 품질 저하나 생성 실패로 이어집니다.

왜 피라미드가 컨텍스트 문제를 해결하는가

테스트 피라미드는 태스크를 자연스럽게 분해하는 방법을 제공합니다. 전체 IT 솔루션 설명을 모델에 로드하는 대신, 레벨별로 작업합니다:

• 태스크 레벨 (컴포넌트) — 하나의 마이크로서비스에 대한 API 계약과 비즈니스 규칙만.
• 사용자 스토리 레벨 (시스템) — 단일 정보 시스템 내 프론트엔드와 백엔드 통합.
• 기능 레벨 (E2E) — 시스템 간 상호작용과 엔드투엔드 비즈니스 프로세스.

각 레벨은 고유한 컨텍스트를 필요로 합니다. 그리고 격리된 상태로 제공될 때 LLM 한계 내에 맞습니다. 이건 이론이 아닙니다—실제적인 필수사항입니다.

예시: "주문 결제 시 프로모 코드" 기능은 3개의 사용자 스토리와 9개의 태스크로 구성됩니다. 모형(mockups), API 명세, 테스트 데이터 등을 포함한 전체 설명은 ~150K 토큰을 차지합니다. 200K 토큰 창을 가진 Claude 3 Opus는 기술적으로 처리할 수 있지만—상위 레벨의 "노이즈"로 인해 하위 레벨 테스트 품질이 떨어집니다. 레벨별로 분해하면 요청당 8–15K 토큰으로 줄고, 품질이 극적으로 향상됩니다.

AI 어시스턴트가 피라미드 레벨을 사용하는 방법

QA Assist 시스템에서 각 테스트 레벨은 전담 에이전트가 처리합니다. 아키텍처는 다음과 같습니다:

• Unit/API 에이전트 — 하나의 엔드포인트나 컴포넌트 명세를 받습니다. 경계 값, 부정 시나리오, 하위 호환성 검사를 커버하는 단위 테스트와 API 테스트를 생성합니다.
• 시스템 에이전트 — 관련 컴포넌트 인터페이스와 사용자 스토리 설명을 받습니다. 통합과 사용자 시나리오를 검증하는 시스템 테스트를 생성합니다.
• E2E 에이전트 — 기능 맵과 사용자 스토리 상태를 받습니다. 시스템 간 데이터 일관성을 확인하는 엔드투엔드 테스트를 생성합니다.

핵심은 각 에이전트의 컨텍스트가 자신의 레벨로 엄격히 제한된다는 점입니다. Unit 에이전트는 관리 패널을 모릅니다. 시스템 에이전트는 주문 이력을 보지 않습니다. 이건 제한이 아니라 LLM 능력에 맞춘 최적화입니다.

구체적 예시: 각 레벨에서 AI가 생성하는 것

태스크 예시: 프로모 코드 적용 백엔드 API (POST /orders/apply-promo).

Unit/API 에이전트가 받는 것:

• 엔드포인트 명세 (입력 매개변수, 출력 필드, 오류 코드).
• 할인 계산 비즈니스 규칙 (고정 금액, 퍼센트, 결합 할인).
• 제약 조건 (사용 제한, 만료일, 지리적 제한).

에이전트가 생성하는 것:

# Example sgenerirovannogo test
@pytest.mark.parametrize("promo_code, expected_discount", [
    ("SALE10", 10.0),      # Protsentnaya skidka
    ("FIXED50", 50.0),     # Fiksirovannaya sum
    ("COMBO", 60.0),       # Kombinirovannaya (10% + 50 rubles)
])
def test_valid_promo_codes(api_client, promo_code, expected_discount):
    response = api_client.post("/orders/apply-promo", json={"code": promo_code})
    assert response.status_code == 200
    assert response.json()["discount"] == expected_discount

@pytest.mark.parametrize("invalid_code", ["EXPIRED", "OVERUSED", "INVALID_FORMAT"])
def test_invalid_promo_codes(api_client, invalid_code):
    response = api_client.post("/orders/apply-promo", json={"code": invalid_code})
    assert response.status_code == 400
    assert "error" in response.json()

이제 사용자 스토리 예시: "사용자가 주문 결제 시 프로모 코드 적용".

시스템 에이전트가 받는 것:

• 시나리오 설명 (사용자 아이템 추가, 프로모 코드 입력, 할인 확인, 주문 완료).
• 프론트엔드와 백엔드 인터페이스 (입력 폼, API 호출, 총액 표시).
• UX 요구사항 (클라이언트 측 검증, 오류 메시지, 로딩 상태).

에이전트가 생성하는 것:

// Example Playwright-test
test('User applies valid promo code during checkout', async ({ page }) => {
  await page.goto('/cart');
  await page.fill('#promo-code', 'SALE10');
  await page.click('#apply-promo');
  
  // Checking otobrazhenie skidki
  await expect(page.locator('.discount-amount')).toHaveText('-10%');
  
  // Checking pereschyot itogovoy summy
  const originalTotal = await page.locator('.original-total').innerText();
  const discountedTotal = await page.locator('.final-total').innerText();
  expect(parseFloat(discountedTotal)).toBeLessThan(parseFloat(originalTotal));
  
  // Oformlyaem zakaz
  await page.click('#checkout-button');
  await expect(page).toHaveURL('/order-confirmation');
});

왜 LLM이 상위 레벨에서 더 고전하는가

언어 모델은 고수준 추상화에서 예측 가능한 품질 저하를 보입니다:

• 기능/E2E 레벨 — 명시적으로 형식화되지 않은 비즈니스 로직 이해가 필요합니다. 모델은 잘못된 가정을 할 수 있습니다.
• 시스템/사용자 스토리 레벨 — 더 낫지만, 여러 소스(프론트엔드, 백엔드, UX)의 지식 통합이 요구됩니다.
• 태스크/Unit 레벨 — LLM 강점에 이상적: 명확한 명세, 형식 규칙, 예측 가능한 입력/출력.

경험적 규칙: 피라미드 레벨이 낮을수록 AI 어시스턴트의 테스트 생성 정확도가 높습니다. 실제로 이는:

• Unit/API 테스트—AI를 거의 완전히 신뢰 (90–95% 커버리지).
• 시스템 테스트—복잡한 통합에 대한 검토 실시 (70–80% 커버리지).
• E2E 테스트—상당한 인간 수정이 필요한 초안을 생성만 (50–60% 커버리지).

AI 어시스턴트 아키텍처 교훈

테스트 생성 AI 시스템을 구축한다면 테스트 피라미드를 무시하는 건 실패의 지름길입니다. QA Assist에 적용한 핵심 원칙:

• 레벨별 분해 — 필수. 전체 기능을 한 번에 덤핑하는 프롬프트 금지.
• 격리된 컨텍스트 — 각 에이전트는 자신의 레벨만. 레벨 간 정보는 구조화된 데이터로 전달, 텍스트 컨텍스트 아님.
• 인간 루프 참여 — 특히 상위 레벨. AI가 초안 생성, 인간이 다듬고 승인.
• 피드백 루프 — 테스트 실행 결과를 에이전트 미세 조정에 사용. AI가 경계 케이스를 놓치면 훈련 세트에 추가.

이 원칙 없이 가장 강력한 LLM조차 그럴듯해 보이지만 실제 버그를 잡지 못하는 테스트를 생산합니다.

주요 교훈

• 테스트 피라미드는 단순한 방법론이 아니라 효과적인 AI 어시스턴트의 기술적 요구사항입니다.
• LLM 컨텍스트 창은 복잡한 기능을 전체 처리할 때 품질 손실 없이 불가능합니다.
• 레벨별 분해 (태스크 → 사용자 스토리 → 기능)만 모든 레벨에서 품질 테스트를 생산합니다.
• AI는 하위 피라미드 레벨(Unit/API)에서 탁월하고 상위(E2E)에서 고전합니다.
• 인간은 특히 시스템과 E2E 테스트 검토 및 다듬기에 필수적입니다.

— Editorial Team