Skip to content

ADR-01: 정적 분석 기반 즉시 분석

🇺🇸 English Version

날짜작성자영향 리포지토리
2024-12-17@KubrickCode전체

Context

문제 정의

기존 테스트 관리 도구들의 높은 도입 장벽:

  1. 높은 설정 복잡도: CI/CD 파이프라인 연동에 인증, 환경 변수, 인프라 구성 필요
  2. 지연된 가치 제공: 설정 완료 전까지 결과 확인 불가 (수 시간~수 일)
  3. 기술 전문성 요구: DevOps 지식 필수 → 비기술 직군(PM, QA 매니저) 접근 제한
  4. 테스트 실행 의존: 대부분 도구가 실제 테스트 실행 필요 → 환경 구성, 테스트 통과 전제

시장 현황

경쟁사접근 방식진입 장벽첫 가치까지 시간
TestRail수동 입력중간수 분 (수동)
QaseAI 지원중간수 분 (수동)
Testomat.ioCI/CD 연동높음수 시간~수 일
PractiTest엔터프라이즈 워크플로우매우 높음수 일~수 주

핵심 질문

도입 마찰을 최소화하면서 사용자에게 즉각적 가치를 제공하는 방법은?

Decision

CI/CD 연동 없이 정적 분석 기반 즉시 분석을 채택한다.

핵심 구현:

  • 사용자는 GitHub 리포지토리 URL만 제공
  • 시스템이 Tree-sitter 기반 AST 코드 분석 수행
  • 테스트 실행 없이 테스트 인벤토리 생성
  • 제출 후 수 초 내 결과 제공

Options Considered

Option A: 정적 분석 기반 즉시 분석 (선택됨)

URL 입력 → 코드 가져오기 → AST 파싱 → 결과 생성

장점:

  • Zero-friction 온보딩 (Time-to-Value: 수 초)
  • Public 리포지토리는 인증 불필요
  • 테스트 실행 환경 불필요
  • 비기술 사용자 접근 가능
  • PLG(Product-Led Growth) 전략 실현
  • 비용 효율적 (테스트 실행 인프라 불필요)

단점:

  • 동적 생성 테스트 케이스 감지 불가
  • pass/fail 실행 결과 없음
  • 프레임워크 복잡도에 따른 AST 파싱 정확도 차이

Option B: CI/CD 파이프라인 연동 필수

CI 파이프라인 연동 → 테스트 실행 → 결과 보고

장점:

  • 완전한 테스트 실행 데이터 (pass/fail, 시간, 커버리지)
  • 동적/파라미터화 테스트 완전 지원
  • Private 리포지토리 자연스럽게 지원
  • 업계 표준 접근법

단점:

  • 높은 설정 마찰 (설정 파일, 시크릿, 권한)
  • Time-to-Value: 수 시간~수 일
  • DevOps 전문성 필요
  • 테스트 환경 의존성
  • 높은 인프라 비용

Option C: AI 기반 테스트 추론

LLM으로 테스트 구조 분석 및 추론

장점:

  • 비관습적 패턴 처리 가능
  • 자연어 설명 가능

단점:

  • 정확도 불확실성 (false positive/negative)
  • 높은 컴퓨팅 비용
  • 지연 시간 문제
  • 환각(hallucination) 리스크
  • 정적 분석으로 충분한 정확도 달성 가능

Consequences

Positive

  1. Zero-Friction 온보딩

    • Time-to-Value: ~5초 vs 수 시간/수 일
    • 바이럴 잠재력: 쉬운 공유 및 시연
  2. PLG(Product-Led Growth) 실현

    • "Try before you buy" 경험
    • 영업 개입 없이 셀프서비스 도입
  3. 광범위한 접근성

    • 비개발자도 테스트 인사이트 접근 가능
    • DevOps 지식 불필요
  4. 비용 효율성

    • 테스트 실행 인프라 불필요
  5. 경쟁 차별화

    • 고유 포지션: 즉시 정적 분석
    • CI/CD 기능으로 경쟁하지 않음

Negative

  1. 동적 테스트 한계

    • 파라미터화 테스트 불완전한 카운트 가능
    • 데이터 주입 테스트 완전 캡처 불가
    • 완화: 한계 명확히 문서화, "추정" 라벨 표시
  2. 실행 결과 없음

    • pass/fail 상태 표시 불가
    • 시간, 커버리지 데이터 없음
    • 완화: "테스트 결과"가 아닌 "테스트 인벤토리"로 포지셔닝
  3. 프레임워크 커버리지

    • 각 프레임워크별 파서 구현 필요
    • 복잡한 테스트 구조의 엣지 케이스
    • 완화: 인기 프레임워크 우선, 커뮤니티 기여

기술적 함의

측면함의
아키텍처Core 라이브러리는 프레임워크 무관, 플러그인 파서 구조
성능Shallow clone + 병렬 파싱 (대규모 리포지토리)
확장성분석 부하를 위한 비동기 큐 처리
확장새 프레임워크 지원을 위한 플러그인 아키텍처

References

Open-source test coverage insights