diff --git a/resources/master_data/ref/_검증_화면늦음.md b/resources/master_data/ref/_검증_화면늦음.md
new file mode 100644
index 00000000..799f6a9e
--- /dev/null
+++ b/resources/master_data/ref/_검증_화면늦음.md
@@ -0,0 +1,31 @@
+# 검증 — 화면 늦음 점검 (일감 28)
+
+읽기 전용 · 자기 포트(8000·5173) 서버 · ORCA 로 컨테이너마다 첫 목록·상세 시간과 오간 요청을 잼(`performance.getEntriesByType('resource')`). 고치지 않음 — 제안만.
+
+## 표
+
+| 컨테이너 | 첫 목록 | 상세 | 가장 무거운 요청 |
+|---|---|---|---|
+| 자재품목(3만 줄) | 0.6초 | 해당 없음 — 줄이 곧 상세(칸 바로 고침) | `/api/m01/rows?...자재품목...` 213ms · 2.2KB |
+| 단가산출 로직(1,354) | **6.0초** | 0.5초 | `/api/m01/logics` **5.6초** · 40.7KB |
+| 로직 개선 시험 | **5.9초** | 0.5초 | `/api/m01/logics` **5.4초** · 40.7KB(같은 길) |
+| 일위대가 조합 | 1.6초 | 정본이 빈 채라 잴 줄 없음 | `/api/m01/combos` 1.6초 · 0.3KB(빈 목록인데도) |
+| 소요량(2,535) | 0.8초 | 0.5초 | `/api/m01/tables?group=소요량...` 308ms |
+| 계수 | 0.5초 | 0.5초 | `/api/m01/table?...계수...` 80ms |
+
+굵게 = 2초 넘는 자리(둘 다 같은 길 `/api/m01/logics`).
+
+## 왜 오래 걸리나 (요청인지 그리기인지)
+
+- **오래 걸리는 자리는 전부 「요청」** — 화면 그리기는 어디서도 0.2초를 안 넘음(목록·상세 다 받은 값을 그대로 표에 얹을 뿐).
+- `/api/m01/logics`(`M01_MasterData_Store.py:320` `logics()`) — 1,354 로직 전부를 놓고 줄마다 `cm.mf.check_logic(whole, row)` 를 돌려 「막힘」 표시를 계산함. 화면은 30줄만 보여주는데 검사는 1,354줄 전부를 다 함 — 쪽 나누기 앞에 검사를 함.
+- `whole = cm.mf.Master(files)`(같은 함수 3번째 줄) — 요청마다 마스터 전부(자재품목 3만 줄 포함 8개 그룹)를 새로 읽어 색인을 다시 짬. 빈 조합 목록(`/api/m01/combos`)도 같은 줄을 부르는데 그것만으로 1.6초 걸림 — 이게 모든 M01 목록 요청의 밑바탕 값(줄 계산 없이도 나오는 값)으로 보임.
+- 자재품목·소요량·계수는 검사 없이 쪽(30~50줄)만 읽어 오므로 빠름.
+
+## 고칠 만한 것(제안만 · 안 고침)
+
+1. `Master(files)` 를 요청마다 다시 짜지 않고 서버가 붙어 있는 동안 캐시해 두고 파일이 바뀔 때만 다시 짬 — 모든 목록의 밑바탕 1.5초가 없어짐.
+2. `/api/m01/logics` 의 「막힘」 검사를 쪽 나누기 **뒤**(그 쪽 30줄만)로 옮기거나, 검사 결과를 캐시해 두고 저장할 때만 다시 계산.
+3. 「로직 개선 시험」 은 같은 길을 그대로 쓰므로 1 · 2 를 고치면 같이 빨라짐.
+
+시험 흔적 없음(어떤 파일도 안 고침 · 프론트 개발서버 재시작 1회는 화면이 빌드 오류로 안 뜨던 것을 되살리려 한 것 — 조합 화면 파일이 다른 창에서 편집 중이던 자국으로 보임).