주제 13개 · Case 28 · Concept 5 · Reference 15 · Question 4 · Decision 4. 계약의 노드마다 종류가 요구하는 칸을 채우고, 본문이 있는 두 종류에는 SSOT 가 이미 그려 둔 도식 셋(value-boundaries · decision-path-404 · topic-variant-model)을 tech-log-studio/ 로 옮겨 붙였다. 새로 그린 그림은 없다. 검사 셋 전부 통과한다. check_body.mjs 56 편 중 본문이 있는 33 편 PASS check_prose.mjs 56 편 error 0 check_evidence.mjs --repo 포함 문제 없음 verify-tech-log-tree.py 프로젝트 5 · error 0 · warn 0 인용한 코드블록은 전부 SSOT 에서 찾아 대조했다. check_evidence.mjs 가 본문의 각 줄과 source 앵커와 계약 제목을 다시 확인한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.8 KiB
kind, slug, title, topic, topicName, project, status, verifiedOn, evidence, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | verifiedOn | evidence | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REFERENCE | measure-what-is-visible-not-a-proxy | 프록시 지표가 아니라 보이는 것을 측정한다 | css-rules-that-leak | CSS 규칙이 구역을 넘어 샌다 | TechLog | 게시 전 | 2026-09-04 |
|
tech-log@2026-09-02 |
|
프록시 지표가 아니라 보이는 것을 측정한다
격자와 열을 재고 「정상」이라고 답했는데, 전체 페이지 스크린샷을 찍으니 제목이 26px 에 굵기 400 이었다. 목록 간격을 바운딩 박스로만 재서 엉뚱한 곳을 결함으로 지목한 적도 있다. 화면이 잘못됐다는 보고는 보이는 것을 재서 확인한다.
관계
- 규칙이 없었던 게 아니라 절반만 있었다 이 기준의 근거 사건이다.
- 구역 전체에 건 격자가 제목까지 잡아 h2 높이가 199px 이 됐다 같은 화면에서 보이는 것을 재서 확인한 사건이다.
- 홈의 비교 구역이 세 번 바뀌었다 폭마다 측정을 남긴 기록이다.
목적
화면이 잘못됐다는 보고를 확인할 때 엉뚱한 값을 재고 「정상」이라 답하는 것을 막는다.
규칙
보고된 증상과 같은 축의 값을 잰다 「제목이 작아 보인다」는 글자 크기와 굵기다. 격자와 열은 다른 축이다.
촬영을 스크립트로 고정한다 손으로 찍으면 뷰포트와 축소 배율이 매번 달라진다.
폭을 고정해 여러 개를 돌고, 폭마다 측정도 함께 남긴다 스크린샷만 남기면 나중에 그 값이 얼마였는지 다시 잴 수 없다.
전체 페이지를 한 장으로 찍지 않는다 축소되어 글자 크기가 실제와 달라진다. 화면 높이만큼 잘라 찍는다.
적용 조건
화면이 잘못됐다는 보고를 확인하는 일. 배포본의 실제 렌더 결과를 판단 근거로 삼을 때.
예외
측정 대상이 좌표나 간격 자체라면 바운딩 박스는 프록시가 아니라 대상이다.
CSS 선언이 정본과 같은지를 보는 검사는 렌더 결과를 재지 않는다. 그 검사가 덮는 범위를 알고 쓰면 된다.
예시
격자와 열만 재고 「정상」이라 답했다. 사용자가 다시 지적한 뒤 전체 페이지 스크린샷을 찍어서야 26px 과 400 을 봤다.
목록 간격을 바운딩 박스로만 재서 엉뚱한 구역을 결함으로 지목한 적이 있다.
브라우저 세션이 리셋되면 창이 약 877px 로 돌아가는데 이 사이트의 분기는 1179·1050·900·767 이라, 방문자 대부분이 보지 않는 배치를 놓고 디자인을 논하게 된다.
전체 페이지를 한 장으로 찍으면 1425x4466 이 638x2000 으로 들어와 17px 글자가 7~8px 이 된다.