---
kind: REFERENCE
slug: verify-runtime-shape-at-runtime
title: 런타임의 모양에 대한 주장은 런타임에서 확인한다
topic: http-failure-classification
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:verify-runtime-shape-at-runtime
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---

# 런타임의 모양에 대한 주장은 런타임에서 확인한다

## 목적

코드를 읽어 얻은 추론이 관측으로 굳어지는 것을 막는다. 특히 실패하는 테스트를 결함의 증거로 읽는 순간을 막는다.

## 규칙

1. 벤더 라이브러리의 런타임 동작은 읽어서 알 수 없다
   이 라이브러리는 예외를 이렇게 감쌀 것이다, 이 게이트가 이 값을 읽을 것이다, 이 경로가 프로덕션 기본값이다. 이런 문장은 전부 가설이며 확인 전까지 판정의 근거가 될 수 없다.

2. 붉은 테스트는 조사의 시작점이지 결론이 아니다
   실패하는 테스트는 무언가 어긋났다는 사실만 말한다. 무엇이 어긋났는지는 별도 측정이다. 테스트 이름이 가리키는 대상이 곧 원인인 경우가 오히려 드물다.

3. 대조는 변수 하나만 바꾼다
   같은 픽스처에서 호스트 문자열만 바꾸는 식의 대조가 가장 값싸고 결정적이다. 두 가지를 함께 바꾸면 결과를 해석할 수 없다.

4. 소스를 고치지 않고 확인할 방법이 대개 있다
   테스트 런타임 클래스패스를 얻어 jshell 로 재현하고, 리플렉션으로 private 메서드를 부르고, 조건만 바꿔 두 번 돌린다. 애플리케이션 소스를 건드리지 않고도 관측이 된다.

5. 확인 비용은 분 단위다
   이 프로젝트에서 판정 번복 한 건과 자기 교정 세 건이 전부 이 형태였고, 넷 다 측정 하나로 갈렸다.

## 적용 조건

프레임워크 드라이버 클라이언트 라이브러리의 런타임 동작에 의존하는 모든 판정

실패하는 테스트를 근거로 결함을 보고하려는 순간

관측 없이 심각도를 P1 으로 올리려는 순간

## 예외

소스가 저장소 안에 있고 그 경로가 테스트로 고정돼 있으면 읽기로 충분하다. 이 규칙은 벤더 코드의 동작에 대한 것이다.

## 예시

분기 순서를 읽고 예외 사슬의 모양을 단정했다. 사슬을 출력하니 달랐다.

레지스트리에 검사가 없다고 단정했다. 빌드 파일의 주석이 가리키는 세 곳을 따라가니 있었다.

전역 승인 게이트가 임계값을 읽을 것이라고 가정했다. 그 가드는 해당 필드를 읽지 않았다.

## 관계

- **붉은 테스트를 제품 결함으로 읽은 오진**
  이 규칙을 끌어낸 사례다. 네 건 중 가장 비쌌던 것이다.
- **분류기는 엔진이 남긴 것만 볼 수 있다**
  같은 사례에서 나온 짝 규칙이다. 이쪽은 방법을, 저쪽은 대상을 다룬다.