---
kind: REFERENCE
slug: a-missing-contract-field-has-a-signature
title: Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다
topic: values-lost-between-boundaries
topicName: 값이 경계에서 사라진다
project: TechLog
status: 게시 전
verifiedOn: 2026-09-04
sourceRevision: tech-log@2026-09-02
source:
  - final/document.md#§5.6
  - final/document.md#§5.5
---

# Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다

Studio 편집기에서는 값이 다 보이는데 공개 화면만 비어 있으면, 두 화면이 같은 DB 를 보고 있으므로 그 사이의 계약에 칸이 없다. 이 저장소에서 같은 신호가 여덟 번 같은 원인을 가리켰다.

## 관계

- **공개 Reference 가 통째로 비어 있었다 — 이름이 어긋났고 본문은 다른 테이블에 있었다**
  이 신호가 처음 잡힌 사건이다.
- **결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다**
  화면 쪽에서 역으로 확인해야 했던 사건이다.
- **한 경계를 고쳤으면 값의 여정 끝에서 확인한다**
  칸을 더한 뒤 무엇을 확인할지가 그 기준에 있다.

## 목적

DB 에 값이 있는데 화면이 비어 있을 때, 어디를 먼저 볼지 정한다. 이 부류는 오류를 내지 않으므로 로그에서 출발하면 아무것도 나오지 않는다.

## 규칙

**Studio 에서는 보이고 공개 쪽만 비면 그 사이의 계약을 먼저 본다**
두 화면이 같은 DB 를 보는데 한쪽만 비면, 다른 것은 그 사이에 놓인 계약이다.

**화면이 그리는 칸을 먼저 적고 응답에 있는지 하나씩 맞춘다**
응답에서 출발하면 없는 칸은 보이지 않는다. 상세 endpoint 가 없는 종류에서 특히 그렇다 — 목록 항목이 문서 전체를 실어야 한다.

**칸을 더할 때 required 로 올릴지는 따로 판단한다**
이미 나가 있는 응답에는 그 칸이 없다. required 로 올리면 배포 순서에 따라 검증이 깨진다.

**값이 아니라 이름을 지키는 검사를 둔다**
게이트웨이가 읽는 이름이 계약의 타입에 있는지를 묻는다. 값을 비교하는 검사는 픽스처를 게이트웨이가 읽는 이름으로 만들면 그대로 통과한다.

## 적용 조건

같은 데이터를 두 표면이 각자의 계약으로 읽고, 한쪽만 비어 보이는 화면. 작성 계약과 조회 계약이 나뉜 구조에서 걸린다.

## 예외

두 표면이 같은 계약을 쓰면 이 신호는 성립하지 않는다. 그때는 매퍼나 질의를 먼저 본다.

저장 구조가 종류마다 다르면 계약이 아니라 조회가 원인일 수 있다. Reference 의 본문이 문서 본문 칸이 아니라 별도 테이블에 있던 것이 그 예다.

## 예시

공개 Reference 가 통째로 비었을 때 게이트웨이가 읽던 네 이름이 전부 계약에 없었다.

프로젝트의 「주요 주제」는 테이블도 조인도 가능했는데 응답에 실을 칸이 없었다.

질문 목록만 주제가 빠져 있어서 질문 줄의 맥락이 「· 프로젝트」로 시작했다. 지식 목록은 처음부터 그 칸을 싣고 있었다.

프로젝트 목록 행에 slug 가 없었다. 다른 목록이 프로젝트를 가리킬 때 쓰는 것은 id 가 아니라 slug 다.