팀은 사양에 완벽하게 일치하는 소프트웨어를 구축하고도 잘못된 제품을 출시할 수 있습니다. 또한 결함으로 가득 찬 코드 위에 정확히 올바른 제품을 구축할 수도 있습니다. 이 두 가지 실패에는 이름이 있습니다. 첫 번째는 검증(verification) 문제이고, 두 번째는 유효성 검사(validation) 문제입니다. 이 둘을 혼동하는 것이 품질 프로세스가 바쁘지만 비효율적으로 끝나는 이유입니다.
이 가이드는 두 용어를 명확히 하고, 차이점을 설명하며, Apidog를 사용한 API 테스트 워크플로우에서 각 용어가 어디에 해당하는지 보여줍니다.
검증(verification)이란 무엇인가?
검증은 "우리가 제품을 올바르게 만들고 있는가?"를 묻습니다.
소프트웨어가 사양, 설계 및 표준에 부합하는지 확인합니다. 검증은 작업이 문서화된 의도에 부합하는지 비교합니다. 그 의도가 올바른지는 묻지 않으며, 구현이 그것과 일치하는지만 묻습니다.
검증은 끝이 아니라 개발 전체에 걸쳐 지속적으로 이루어집니다. 일반적인 검증 활동은 다음과 같습니다:
- 코드 리뷰 및 워크스루
- 정적 분석 및 린팅
- 설계 및 아키텍처 리뷰
- 스키마 및 계약 확인
- 함수가 시그니처에서 약속한 대로 작동하는지 확인하는 단위 테스트
핵심 특징은 검증이 대부분 내부적이라는 것입니다. 이는 하나의 아티팩트와 다른 아티팩트를 비교합니다: 코드와 설계, 응답과 스키마, 구현과 사양. 실제 사용자는 필요하지 않습니다. 사양에 엔드포인트가 Location 헤더와 함께 201을 반환한다고 되어 있다면, 검증은 정확히 그렇게 하는지 확인합니다.
유효성 검사(validation)란 무엇인가?
유효성 검사는 "우리가 올바른 제품을 만들고 있는가?"를 묻습니다.
이는 사양이 무엇을 말했는지와 관계없이 소프트웨어가 실제로 사용자 요구 사항을 충족하고 실제 문제를 해결하는지 확인합니다. 유효성 검사는 작업이 문서가 아닌 현실과 사용 의도에 부합하는지 비교합니다.
유효성 검사는 사용자나 이해관계자가 사용할 수 있는 무언가가 있을 때 나중에 발생하는 경향이 있습니다. 일반적인 유효성 검사 활동은 다음과 같습니다:
- 사용자 인수 테스트
- 베타 프로그램 및 사용성 테스트
- 완전한 워크플로우에 대한 종단 간 테스트
- 이해관계자 데모 및 승인
핵심 특징은 유효성 검사가 외부 지향적이라는 것입니다. 완성된 제품이 맥락에서 유용하고 올바른지 묻습니다. API는 모든 검증 검사를 통과하고, OpenAPI 사양에 완벽하게 부합하더라도, 사양 자체가 잘못된 문제를 해결했기 때문에 유효성 검사에 실패할 수 있습니다. 예를 들어, 페이지네이션 모델을 사용할 수 없거나 인증 흐름이 클라이언트가 실제로 통합하는 방식에 맞지 않는 경우입니다.
유효성 검사 vs 검증: 차이점
| 측면 | 검증(Verification) | 유효성 검사(Validation) |
|---|---|---|
| 핵심 질문 | 올바르게 만들고 있는가? | 올바른 것을 만들고 있는가? |
| 비교 대상 | 사양, 설계, 표준 | 사용자 요구 사항, 실제 사용 |
| 시점 | 개발 전반에 걸쳐 지속적으로 | 나중에, 사용 가능한 것이 있을 때 |
| 일반적인 방법 | 리뷰, 정적 분석, 단위 테스트, 스키마 확인 | 인수 테스트, 베타, 종단 간 테스트, 데모 |
| 방향 | 내부: 아티팩트 vs 아티팩트 | 외부: 제품 vs 현실 |
| 발견하는 것 | 결함, 사양 불일치, 계약 불일치 | 잘못된 요구 사항, 부적합, 사용성 격차 |
| 생략 시 비용 | 좋은 사양과 일치하지만 버그가 있는 코드 | 잘못된 문제를 해결하는 완성도 높은 제품 |
이 둘은 상호 교환될 수 없으며, 어느 하나가 다른 하나를 대체하지도 않습니다. 약한 유효성 검사를 동반한 강력한 검증은 아무도 원하지 않는 결함 없는 제품을 제공합니다. 약한 검증을 동반한 강력한 유효성 검사는 불안정한 코드 위에 구현된 올바른 아이디어를 제공합니다. 둘 다 필요하며, 적시에 적용되어야 합니다.
간단한 기억법: 검증은 문서에 대한 테스트이고, 유효성 검사는 목적에 대한 테스트입니다.
API 테스트에서 이것이 어떻게 적용되는가
API는 명시적이고 기계 판독 가능한 사양(OpenAPI 또는 스키마 정의)을 가지고 있기 때문에 이 구별을 구체적으로 만듭니다. 그 사양은 검증의 기준선입니다.
API 검증은 해당 계약에 대한 구현을 확인하는 것을 의미합니다:
- 각 엔드포인트가 문서화된 상태 코드를 반환하는가? 이들을 일관되게 유지하는 것은 그 자체로 규율입니다. REST API가 사용해야 하는 HTTP 상태 코드를 참조하세요.
- 모든 응답이 올바른 필드 이름과 유형으로 문서화된 스키마와 일치하는가?
- 필수 매개변수가 지정된 대로 정확하게 적용되는가?
- 오류 형식이 문서화된 오류 형태와 일치하는가?
이것은 API 계약 테스트가 적용되는 부분이기도 합니다. 계약 테스트는 순수한 검증입니다. 생산자가 소비자가 의존하는 계약을 여전히 준수하는지 확인합니다. 상태, 스키마 및 헤더에 대한 API 단언은 검증 작업의 단위입니다.
API 유효성 검사는 API가 소비자에게 진정으로 유용한지 확인하는 것을 의미합니다:
- 클라이언트가 어색한 해결 방법 없이 실제 종단 간 워크플로우(로그인, 생성, 업데이트, 삭제)를 완료할 수 있는가?
- API가 반환하는 데이터가 클라이언트 개발자가 묻는 질문에 실제로 답하는가?
- 인증 모델이 기존 통합에 실용적인가?
- 문서화된 예시가 API가 실제로 사용되는 방식을 반영하는가?
여러 요청을 완전한 사용자 여정으로 연결하는 API 테스트 시나리오는 유효성 검사에 더 가깝고, 단일 엔드포인트 스키마 검사는 검증입니다. 둘 다 테스트 스위트에 속해야 합니다. 테스트 시나리오 vs 테스트 케이스를 이해하면 어떤 계층에서 작업하고 있는지 파악하는 데 도움이 됩니다.
Apidog의 역할
Apidog는 API 설계, 테스트 및 문서를 하나의 작업 공간에 보관하므로 두 가지 구별을 모두 지원합니다.
검증의 경우, API 설계 자체가 사양입니다. 테스트를 구축할 때 API를 정의하는 동일한 스키마에 대해 응답을 단언하므로, 검증은 계약이 벗어날 수 있는 두 번째 사본이 없습니다. 스키마 단언, 상태 단언 및 계약 확인은 모두 진실의 원천에 대해 실행됩니다. CI를 통해 모든 커밋에서 실행합니다. CI/CD에서 API 테스트를 자동화하면 검증이 지속적으로 이루어지는데, 이는 정확히 검증이 이루어져야 할 때입니다.
유효성 검사의 경우, Apidog 테스트 시나리오는 여러 엔드포인트를 완전한 워크플로우로 연결합니다. 사용자를 등록하고, 로그인하고, 리소스를 생성하고, 결과를 확인하는 시나리오를 구축한 다음, 실제 클라이언트가 하는 방식으로 실행할 수 있습니다. 이러한 종단 간 실행은 API가 실제 문제를 해결하는지 확인하는 방법이며, 단순히 각 엔드포인트가 사양의 해당 줄과 일치하는지 확인하는 것이 아닙니다.
보고서는 전체 과정을 마무리합니다. Apidog는 단계별 결과를 생성하므로 실패한 검증 확인(스키마 불일치)과 실패한 유효성 검사 확인(손상된 다단계 워크플로우)이 모두 눈에 띄게 구별되고 추적 가능합니다.
자신의 API에 대해 계약 수준 검증과 워크플로우 수준 유효성 검사를 모두 설정하려면 Apidog를 다운로드하세요.
실제 예시
결제 API를 구축하는 팀을 상상해 보십시오. 사양에 따르면 POST /payments는 금액과 통화를 수락하고, payment_id와 함께 201을 반환하며, 유효하지 않은 통화는 400으로 거부합니다.
이 API에 대한 검증은 순조롭게 진행됩니다. 코드 리뷰는 핸들러가 설계와 일치함을 확인합니다. 스키마 단언은 모든 응답이 문서화된 필드와 유형을 가지고 있음을 확인합니다. 계약 테스트는 400 오류 형태가 지정된 대로 정확히 일치함을 확인합니다. 상태 코드 확인은 모든 영역에서 통과합니다. 모든 검증 측정에 따르면, API는 올바르게 구축되었습니다.
그런 다음 첫 번째 실제 클라이언트가 통합됩니다. 그들은 API가 금액을 부동 소수점 숫자로 받아들여 0.1 + 0.2가 고객의 청구서와 일치하지 않는 값으로 반올림되는 것을 발견합니다. 사양은 "amount: number"라고 말했습니다. 구현은 그것을 완벽하게 따랐습니다. 사양이 잘못되었습니다. 돈은 절대 float이 되어서는 안 됩니다. 검증은 이것을 결코 잡아낼 수 없었습니다. 왜냐하면 검증은 구현을 사양과 비교할 뿐이며, 둘 다 동의했기 때문입니다.
유효성 검사는 그것을 잡아냅니다. 클라이언트가 실제 종단 간 결제를 실행하고 청구서와 대조하는 순간, 반올림 오류가 드러납니다. 해결책은 코드 결함 보고서가 아닙니다. 그것은 사양 변경이며, 금액은 정수 최소 단위가 됩니다. 이것이 유효성 검사 결과의 특징입니다. 답변은 "사양에 맞게 코드를 수정하라"가 아니라 "사양 자체가 잘못되었다"입니다.
이것이 둘 다 중요한 이유입니다. 검증은 깨진 계약의 완벽한 구현을 출시했을 것입니다. 실제 소비자가 하는 방식으로 API를 사용하는 유효성 검사만이 계약이 문제임을 드러내는 유일한 것입니다.
실용적인 체크리스트
모든 API 릴리스에 대해 두 열을 모두 실행합니다:
검증 (사양에 대해):
- 모든 엔드포인트는 문서화된 상태 코드를 반환합니다.
- 모든 응답은 해당 스키마를 준수합니다.
- 필수 매개변수가 적용됩니다.
- 오류 응답은 문서화된 형태와 일치합니다.
- 모든 소비자 지향 엔드포인트에 대해 계약 테스트가 통과합니다.
유효성 검사 (목적에 대해):
- 새 클라이언트가 핵심 워크플로우를 종단 간 완료할 수 있습니다.
- 반환된 데이터는 실제 클라이언트 질문에 답합니다.
- 인증 흐름은 실제 통합 패턴에 적합하게 작동합니다.
- 문서화된 예시는 실제 사용과 일치합니다.
- 이해관계자가 API가 의도된 문제를 해결한다고 확인합니다.
첫 번째 열만 통과하면, 아마도 잘못된 설계의 올바른 구현을 가지고 있는 것입니다. 두 번째 열만 통과하면, 불안정한 코드 위에 올바른 아이디어를 가지고 있는 것입니다. 자신 있게 출시하려면 둘 다 필요합니다.
자주 묻는 질문
검증 또는 유효성 검사 중 어느 것이 먼저 이루어지나요? 검증은 코드가 존재하는 즉시 사양에 대해 코드를 확인할 수 있으므로 먼저 시작하여 지속적으로 실행됩니다. 유효성 검사는 실제 요구 사항에 대해 실행할 수 있는 사용 가능한 제품이 있을 때 이루어집니다.
테스트가 유효성 검사와 동일한가요? 아닙니다. 테스트는 둘 다를 아우릅니다. 단위 테스트와 스키마 확인은 검증이고, 인수 테스트와 종단 간 테스트는 유효성 검사입니다. "테스트"라는 용어는 전체 범위를 포함합니다.
소프트웨어가 검증은 통과하지만 유효성 검사는 실패할 수 있나요? 예, 흔한 일입니다. 구현은 사양과 완벽하게 일치하지만, 사양이 잘못된 문제를 해결했습니다. 그 제품은 검증되었지만 유효성 검사는 되지 않았습니다.
이것이 API 계약 테스트에 어떻게 적용되나요? 계약 테스트는 검증입니다. API가 소비자들과의 문서화된 계약을 여전히 준수하는지 확인합니다. 그 계약이 올바른 것이었는지는 확인하지 않습니다. 그것은 유효성 검사의 역할입니다.
어느 것이 더 많은 버그를 찾나요? 검증은 지속적으로 실행되고 작은 불일치를 일찍 포착하기 때문에 수적으로 더 많은 결함을 찾습니다. 유효성 검사는 더 적은 문제를 찾지만 더 비용이 많이 드는 문제를 찾습니다. 유효성 검사 실패는 일반적으로 코드 자체의 문제가 아니라 요구 사항이나 설계가 잘못되었음을 의미하기 때문입니다.
자동화가 둘 다를 다룰 수 있나요? 자동화는 검증을 잘 처리합니다. 스키마 확인, 계약 테스트 및 상태 단언은 모든 커밋에서 실행됩니다. 유효성 검사는 실제 상황에 대한 판단에 의존하기 때문에 완전히 자동화하기가 더 어렵습니다. 하지만 종단 간 워크플로우 테스트는 의미 있는 부분을 자동화합니다.