---
kind: REFERENCE
slug: verify-at-the-end-of-the-value-journey
title: 한 경계를 고쳤으면 값의 여정 끝에서 확인한다
topic: values-lost-between-boundaries
topicName: 값이 경계에서 사라진다
project: TechLog
status: 게시 전
verifiedOn: 2026-09-04
sourceRevision: tech-log@2026-09-02
source:
  - final/document.md#§17.1
  - final/document.md#§5.2
  - final/document.md#§6.6
---

# 한 경계를 고쳤으면 값의 여정 끝에서 확인한다

값이 여러 경계를 갈아타는 구조에서 한 경계를 고치고 「고쳤다」고 판단해 세 번 틀렸다. 타입 검사도 단위 테스트도 「코드를 읽어 보니 맞다」도 전부 중간 지점이다. 배포본에서 그 값이 실제로 그려지는 곳까지 가서 확인한다.

## 관계

- **관계의 요약이 경계 세 곳을 지나며 사라졌다**
  한 경계를 고치고 판단해 두 번 틀린 사건이다.
- **공개 화면 한 줄이 그려지기까지 값이 지나는 경계 열한 개**
  왜 중간 확인이 부족한지가 그 개념에 있다.
- **TypeScript 가 검사를 놓아 주는 네 곳**
  타입 통과가 반영의 증거가 아닌 이유가 그 개념에 있다.

## 목적

「고쳤다」는 판단이 틀리는 것을 막는다.

값이 열한 경계를 지나는 구조에서 한 경계만 보고 판단하면, 다음 경계가 같은 값을 다시 버려도 알 수 없다. 이 저장소에서 그 판단이 세 번 틀렸다.

## 규칙

**고친 값이 실제로 그려지는 곳까지 가서 본다**
배포본에서 그 화면을 열거나 실제 요청을 보내 응답을 읽는다. 관계 요약은 세 경계에서 연달아 버려졌고, 매번 화면을 보고 나서야 다음 경계가 버리는 것을 알았다.

**타입 검사 통과를 반영의 증거로 쓰지 않는다**
메서드 매개변수의 bivariance, `as` 단언, 검사 대상이 없는 tsconfig 가 각각 통과시킨 사례가 있다. 통과는 「코드가 맞다」가 아니라 「검사가 그 질문을 하지 않았다」를 뜻할 수 있다.

**게이트웨이를 실제로 불러 어떤 연산이 나가는지 확인한다**
등록을 빠뜨린 연산은 옆 분기로 떨어지므로 서버는 정상 응답을 준다. 나가는 경로를 봐야 알 수 있다.

**여정이 끝나는 곳을 먼저 정하고 시작한다**
어디까지 가면 확인이 끝나는지 모르면 중간에서 멈추게 된다. 공개 화면의 한 줄이면 그 줄이 그려지는 화면이 끝이다.

**검사가 덮는 구간을 적어 둔다**
값이 아니라 이름을 지키는 검사를 두면 여정의 한 구간을 그 검사가 대신한다. 그 구간이 어디까지인지 적어 두지 않으면 다음 사람이 검사를 여정 전체로 읽는다.

## 적용 조건

값이 계약·매퍼·포트를 여러 번 갈아타는 구조에서 「고쳤다」를 판단할 때. 계약을 소유한 저장소가 따로 있고 생성기를 지나 들어오면 특히 걸린다.

앞선 커밋이 같은 값을 고치려다 못 고친 이력이 있으면 반드시 건다. 그 커밋이 무엇을 근거로 고쳤다고 판단했는지가 대개 중간 지점이다.

## 예외

경계가 하나뿐이거나 고친 그 곳이 여정의 끝이면 중간 확인으로 충분하다.

배포본을 열 수 없는 변경 — 아직 배포되지 않은 경로 — 은 여정의 끝까지 갈 수 없다. 그때는 어디까지 확인했는지를 적는다.

## 예시

관계 요약을 세 번 고쳤다. 매번 화면을 보고 나서야 다음 경계가 버리는 것을 알았다.

개념 삭제가 계속 질문 삭제 경로로 나갔다. 타입 검사가 통과해서 반영된 줄 알았고, 배포된 번들의 서버 로그에서 404 를 보고 알았다.

CONCEPT 을 질문 삭제로 되돌려 가드가 깨지는 것을 확인했다.

한 경계를 고치고 판단해 세 번 틀렸다. 값이 지나는 경계가 열한 개다.