대부분의 API 테스트 비교는 기능 체크리스트 수준에서 멈춥니다.

OpenAPI 지원 여부? ✓

CLI 사용 가능 여부? ✓

CI 통합 여부? ✓

AI 지원 여부? ✓

도구를 쇼핑할 때는 유용하지만, 엔지니어들이 실제로 궁금해하는 질문에는 답을 주지 못합니다:

이 도구들이 실제 OpenAPI 명세(specifications)를 대상으로 어떻게 동작하는가?

그래서 우리는 동일한 데이터셋을 사용하여 API 계약 테스트 (contract testing)에 대한 세 가지 서로 다른 접근 방식을 벤치마킹하기로 결정했습니다.

목표는 만능 승자를 가리는 것이 아니었습니다.

각 접근 방식이 어디에서 잘 작동하고, 어디에서 어려움을 겪으며, 어떤 종류의 팀에 각 도구가 가장 적합한지를 이해하는 것이었습니다.

세 가지 러너(runners)는 다음과 같습니다:

• Schemathesis
• Dredd
• 자체 내부 계약 러너 (Total Shift Left API)

이 글은 전체 방법론, 가공되지 않은 수치, 그리고—아마도 가장 중요한—우리 자신의 러너가 대안들보다 성능이 떨어졌던 영역들을 기록합니다.

만약 방법론에 동의하지 않는다면, 그것은 유용한 피드백이 될 것입니다. 벤치마크를 재현하는 데 필요한 모든 정보가 포함되어 있습니다.

이 벤치마크를 실행한 이유

모든 API 테스트 도구는 수동 작업을 줄여준다고 주장합니다.

대부분은 실제로 그렇습니다.

차이점은 API가 커지기 시작할 때 나타납니다.

우리가 답을 얻고자 했던 질문들은 다음과 같습니다:

• 초기 테스트 생성에 시간이 얼마나 걸리는가?
• 얼마나 많은 수동 설정이 필요한가?
• 얼마나 많은 유용한 테스트가 생성되는가?
• 계약 커버리지 (contract coverage)는 얼마나 달성되는가?
• 실패 알림(failures)이 얼마나 소란스러운가 (noisy)?
• 출력 결과를 이해하기 얼마나 쉬운가?

특정 도구가 좋아 보이도록 설계된 합성 API (synthetic APIs)를 만드는 대신, 우리는 내부 프로젝트, 공개 API, 그리고 샘플 엔터프라이즈 서비스에서 수집한 실제 OpenAPI 명세들을 사용했습니다.

데이터셋

벤치마크에는 30개의 OpenAPI 명세가 포함되었습니다.

매우 작은 서비스부터 중간 정도의 복잡성을 가진 엔터프라이즈 API까지 다양했습니다.

명세 크기는 다음과 같은 범위였습니다:

• 8개 엔드포인트 (endpoints)
• 220개 엔드포인트

평균:

• 61개 엔드포인트

평균 스키마 (schema) 개수:

• 84개 컴포넌트 (components)

인증(Authentication)에는 다음과 같은 항목이 포함되었습니다:

• 없음 (None)
• API 키 (API Keys)
• OAuth2
• 베어러 토큰 (Bearer Tokens)

우리는 이 벤치마크가 OpenAPI 기반의 계약 테스트 (Contract Testing)에만 독점적으로 집중했기 때문에 GraphQL과 gRPC는 의도적으로 제외했습니다.

테스트 환경 (Test Environment)

모든 도구는 동일한 하드웨어에서 실행되었습니다.

가상 머신 (Virtual Machines)은 사용하지 않았습니다.

클라우드 실행 (Cloud execution)도 없었습니다.

모든 벤치마크는 매번 새로운 로컬 실행 (Fresh local runs)으로 진행되었습니다.

설정 (Configuration)

각 도구는 권장되는 문서에 따라 설정되었습니다.

우리는 의도적으로 커스텀 튜닝 (Custom tuning)을 피했습니다.

목표는 공식 문서를 읽은 후 적절한 경험을 가진 엔지니어가 달성할 수 있는 수준을 나타내는 것이었습니다.

모든 벤치마크는 5회씩 반복되었습니다.

실행 시간의 중앙값 (Median execution time)을 기록했습니다.

측정 항목 (What We Measured)

단순히 실행 속도만을 측정하는 대신, 6가지 차원을 평가했습니다.

모든 지표가 자동화에 유리한 것은 아닙니다.

어떤 지표는 개발자 경험 (Developer experience)에 유리합니다.

다른 지표는 정확성 (Correctness)에 유리합니다.

결과 (Results)

임포트 속도 (Import Speed)

이것이 첫 번째 놀라운 결과였습니다.

우리의 러너 (Runner)는 더 큰 명세를 임포트할 때 일관되게 더 오래 걸렸습니다.

차이가 극적이지는 않았지만, 측정 가능한 수준이었습니다.

주된 이유는 실행 전에 더 풍부한 메타데이터 (Metadata)를 구축하는 추가적인 전처리 (Preprocessing) 과정 때문입니다.

매우 작은 API의 경우, 이 오버헤드 (Overhead)는 무시할 수 있는 수준입니다.

하지만 대규모 명세의 경우, 이는 눈에 띄게 됩니다.

승자: Dredd

초기 설정 (Initial Setup)

가장 큰 감소는 자동 환경 감지 (Automatic environment detection)와 테스트 생성 (Test generation)에서 나타났습니다.

하지만 이는 명세 자체가 어느 정도 완전하다는 것을 전제로 합니다.

부실한 OpenAPI 문서는 도구와 상관없이 수동 개입 (Manual intervention)이 필요했습니다.

승자: TSL Runner

계약 커버리지 (Contract Coverage)

Schemathesis는 속성 기반 탐색 (Property-based exploration)을 통한 네거티브 테스트 (Negative testing)에서 특히 뛰어난 성능을 보였습니다.

그것은 여전히 이 도구의 가장 강력한 장점 중 하나로 남아 있습니다.

우리의 러너(runner)는 명세 분석(specification analysis)과 추가로 생성된 어설션(assertions)을 결합했기 때문에 전반적인 계약 커버리지(contract coverage)가 약간 더 높게 나타났습니다.

하지만 그 차이는 우리가 예상했던 것보다 작았습니다.

실패 가독성 (Failure Readability)

이 카테고리는 주관적입니다.

우리는 해당 API에 익숙하지 않은 엔지니어가 테스트가 실패한 이유를 빠르게 이해할 수 있는지 평가했습니다.

점수 (1–10):

우리의 러너가 생성한 더 풍부한 진단 정보(diagnostics)가 이 부분에서 도움이 되었습니다.

하지만 일부 엔지니어들은 출력 결과가 생성된 테스트 케이스(test cases)와 더 직접적으로 매핑되는 Schemathesis를 선호했습니다.

보편적으로 정답이라고 할 수 있는 것은 없습니다.

TSL이 뒤처진 부분

약점 없는 벤치마크를 발표하는 것은 유용하지 않습니다.

다음은 우리의 자체 러너가 지속적으로 성능이 떨어졌던 분야들입니다.

시작 시간 (Startup Time)

전처리(Preprocessing) 과정으로 인해 임포트(imports) 속도가 느려집니다.

빠른 개발 과정 중에 아주 작은 API를 검증하고 있다면, 추가적인 시작 비용(startup cost)이 그만한 가치가 없을 수도 있습니다.

속성 기반 탐색 (Property-Based Exploration)

Schemathesis는 이 분야에서 여전히 매우 강력합니다.

방대한 양의 예상치 못한 입력값을 생성하는 능력은 결정론적 생성(deterministic generation) 방식이 때때로 놓치는 결함 클래스(classes of defects)를 찾아냅니다.

퍼징(fuzzing)과 속성 기반 테스트(property-based testing)가 주요 목표라면, Schemathesis가 확실한 우위를 점합니다.

커뮤니티 생태계 (Community Ecosystem)

Dredd와 Schemathesis는 성숙한 오픈 소스 커뮤니티를 보유하고 있습니다.

이는 다음을 의미합니다:

• 더 많은 예제
• 더 많은 커뮤니티 논의
• 더 많은 통합(integrations)
• 더 빠른 문제 해결(troubleshooting)

상용 도구(Commercial tooling)는 이 분야에서 기성 오픈 소스 생태계보다 뒤처진 상태로 시작할 수밖에 없습니다.

CLI 단순성 (CLI Simplicity)

단순한 계약 검증(contract verification)에 있어서는 Dredd를 이기기가 여전히 어렵습니다.

단 하나의 명령.

즉각적인 피드백.

매우 간결한 절차.

직관적인 문서 검증을 위해서는 여전히 훌륭한 선택입니다.

TSL이 더 나았던 부분

우리의 러너가 지속적으로 좋은 성능을 보였던 분야는 단순한 실행 속도보다는 워크플로(workflow)에 관한 것이었습니다.

구체적으로는:

• 자동 어설션 생성 (Automatic assertion generation)
• 더 풍부한 진단 (Richer diagnostics)
• 수동 설정 감소 (Reduced manual configuration)
• CI/CD 파이프라인 통합 (Integration into CI/CD pipelines)
• AI 지원 계약 검증 (AI-assisted contract validation)

이러한 요소들은 API 포트폴리오가 성장함에 따라 점점 더 가치 있어집니다.

수십 개 또는 수백 개의 API를 관리하는 팀의 경우, 실행 시간을 몇 초 단축하는 것보다 수동 유지보수를 줄이는 것이 더 중요한 경우가 많습니다.

만약 귀하의 팀이 수동 유지보수를 줄이면서 API 계약 검증 (API contract validation)을 자동화하고자 한다면, API 계약 테스트 (API contract testing)에 관한 당사의 가이드에서 AI 지원 계약 검증이 현대적인 CI/CD 파이프라인에 어떻게 부합하는지를 포함하여 해당 접근 방식을 자세히 설명합니다.

타당성에 대한 위협 (Threats to Validity)

완벽한 벤치마크는 없습니다.

몇 가지 요인이 이러한 결과에 영향을 미칠 수 있습니다.

OpenAPI 품질 (OpenAPI Quality)

일부 명세는 다른 명세보다 현저히 더 깔끔했습니다.

세 가지 도구 모두 고품질 명세에 대해 더 나은 성능을 보였습니다.

데이터셋 크기 (Dataset Size)

30개의 API는 유용한 신호를 제공합니다.

하지만 이들이 모든 API 아키텍처를 대표하지는 않습니다.

설정 선택 (Configuration Choices)

우리는 의도적으로 공격적인 튜닝을 피했습니다.

숙련된 사용자는 다른 결과를 얻을 수 있습니다.

하드웨어 (Hardware)

모든 벤치마크는 로컬에서 실행되었습니다.

클라우드 기반 실행은 다른 결과를 생성할 수 있습니다.

원시 타이밍 요약 (Raw Timing Summary)

벤치마크 재현 (Reproducing the Benchmark)

모든 벤치마크는 다음을 사용하여 재현할 수 있습니다:

• 동일한 OpenAPI 명세
• 도구 기본 설정
• 공개된 하드웨어 구성
• 다수의 실행 횟수
• 중앙값 타이밍 (Median timing)

추가적인 API나 다른 도구를 사용하여 실험을 반복하는 데 관심이 있다면, 저는 진심으로 그 결과를 보고 싶습니다.

데이터셋이 달라지면 결론도 달라질 수 있습니다.

마치며 (Final Thoughts)

이번 벤치마크의 가장 큰 교훈은 특정 도구가 "승리"했다는 것이 아니었습니다.

그것은 서로 다른 도구들이 서로 다른 우선순위에 최적화되어 있다는 점이었습니다.

최소한의 설정으로 가벼운 계약 검증 (contract verification)을 원한다면, Dredd는 여전히 견고한 선택지입니다.

심도 있는 속성 기반 탐색 (property-based exploration) 및 퍼징 (fuzzing)이 목표라면, Schemathesis는 여전히 사용 가능한 가장 강력한 오픈 소스 옵션 중 하나입니다.

수동 테스트 작성 (manual test authoring)을 줄이고, 진단 (diagnostics) 기능을 강화하며, AI 지원 계약 검증 (AI-assisted contract validation)을 더 큰 엔지니어링 워크플로우에 통합하고자 한다면, 저희의 자체 러너 (runner)가 좋은 성능을 보였습니다. 하지만 시작 시간 (startup time)과 생태계 성숙도 측면에서의 트레이드오프 (trade-offs)도 존재합니다.

벤치마크 (benchmarks)는 강점과 약점을 솔직하게 드러낼 때 가장 가치가 있습니다.

만약 유사한 비교를 수행해 보셨거나, 저희의 방법론이 개선될 수 있다고 생각하신다면 여러분의 피드백을 듣고 싶습니다. 엔지니어링 벤치마크는 그것이 결정적이라고 가장하는 것이 아니라, 토론을 통해 더 나아집니다.

부록 A — 원시 벤치마크 데이터 (Raw Benchmark Data)

투명성을 위해, 벤치마크에는 다음이 포함되었습니다:

• 30개의 OpenAPI 명세 (specifications)
• 총 150회의 벤치마크 실행 (도구당, 명세당 5회)
• 보고된 모든 지표에 대한 중앙값 (median) 시간
• 별도 언급이 없는 한 도구의 기본 설정 (default configurations)

향후 반복 작업에서는 더 큰 엔터프라이즈 명세, 광범위한 다형성 (oneOf/anyOf)을 가진 API, 그리고 이상적인 조건이 아닌 상황에서의 도구 회복탄력성 (resilience)을 평가하기 위해 의도적으로 잘못된 스키마 (malformed schemas)를 가진 명세 등을 포함하여 데이터셋을 확장할 예정입니다.