당신의 서비스에 "오류가 분당 50건을 넘으면 알림"이라는 규칙이 있다고 하자. 방문자가 열 배로 늘면 이 알림은 멀쩡한 날에도 울리고, 방문자가 줄면 절반이 실패하는 날에도 조용하다. 3D 화면에서도 같은 일이 생긴다 — three.js 후처리의 윤곽선(edge detection) 굵기가 창 크기(resolution)에 따라 달라 보이고, 적응형 품질(adaptive quality) 조절이 30Hz 모니터에서 멀쩡한 화면의 화질을 깎는다. 셋 다 오류 메시지는 없다. 값이 기댄 기준이 움직였을 뿐이다.
기준이 따로 있는 값은 어떻게 적어야 하나
어떤 값이 다른 값(화면 높이·주사율·트래픽·기준 거리)을 전제로 정해졌다면, 그 값은 절대 단위가 아니라 그 기준에 대한 비율로 적는다. 픽셀·밀리초·건수·고정 거리로 적은 값은 처음 정한 환경에서만 맞고, 기준이 바뀌는 순간 오류 없이 뜻이 바뀐다.
절대 단위가 위험한 이유는 "처음엔 맞기" 때문이다. 값을 정할 때는 기준이 하나뿐이라 픽셀로 적든 비율로 적든 같은 그림이 나온다. 차이는 창을 줄이거나, 모니터를 바꾸거나, 기준값 하나를 옮길 때 처음 드러난다 — 그리고 그때는 이미 누구도 그 상수를 기억하지 못한다.
어떤 값이 기준에 매여 있나
다음 질문에 "예"면 그 값은 기준에 매여 있다.
- 이 값을 정할 때 다른 값을 보고 정했나? (화면 크기를 보고 선 굵기를, 평소 트래픽을 보고 알림 문턱을)
- 그 다른 값이 사용자·기기·운영 중에 바뀔 수 있나?
- 그 다른 값이 바뀌면, 이 값도 같이 바뀌어야 "같은 뜻"이 되나?
흔한 예:
- 모니터링 알림: "오류 50건/분" → "오류율 2%"(요청 수에 대한 비율)
- 화면 요소: "윤곽선 2px" → "화면 높이에 대한 비율"(그래야 큰 창과 작은 창에서 같은 그림)
- 성능 판정: "프레임 20ms 넘으면 느림" → "주사율 한 프레임 간격의 1.2배 넘으면 느림"
- 연출 상수: "감속 구간 30" → "기준 거리의 0.4배"(기준 거리를 옮기면 같이 따라오게)
- 시간 제한: "일괄 작업 60초 제한" → "항목당 0.5초 × 항목 수"
비율로 바꾸는 순서
- 기준을 하나 이름 붙인다. 화면이면
REF_HEIGHT(기준 높이), 성능이면 측정한 주사율, 운영이면 요청 수. 기준이 이름 없이 숫자 속에 녹아 있으면 바꿀 때 못 찾는다. - 값을 그 기준에서 유도한다.
width = 1.1 * (screenHeight / REF_HEIGHT)처럼 계산식으로 둔다. 상수 표에 결과 숫자만 적지 않는다. - 같은 기준에 매인 값을 한 묶음으로 모은다. 묶음의 일부만 비율이고 일부가 절대값이면, 기준을 옮길 때 절대값 쪽만 남아 어긋난다.
- 기준을 두 값으로 바꿔 보는 시험을 둔다. 창 높이 1444px 와 510px, 주사율 60Hz 와 30Hz, 기준 거리 32 와 70 — 두 경우의 결과가 같은 뜻인지 숫자로 비교한다.
- 기준을 재는 법도 정한다. 주사율처럼 실행 중에 재는 기준은 시작 직후 값에 끌려가니 예열 뒤에 잰다.
에이전트에게 맡긴다면 지침에 이렇게 넣는다:
상수를 새로 넣거나 고칠 때, 그 값이 다른 값(화면 크기·주사율·트래픽·기준 거리)을 보고 정한 것인지 먼저 적어라.
그렇다면 절대 단위(px·ms·건수)로 적지 말고 그 기준에서 계산식으로 유도하라.
같은 기준에 매인 상수는 한곳에 모으고, 기준을 다른 값으로 바꿨을 때 결과가 같은 뜻인지 확인하는 시험을 하나 더하라.
비율로 적으면 놓치는 것은 없나
있다. 사람 눈·손가락처럼 기준과 무관하게 정해진 한계는 절대값이 맞다. 버튼의 최소 터치 영역, 읽을 수 있는 최소 글자 크기가 그렇다. 그래서 비율로 적고 절대 하한·상한을 따로 둔다. 다만 하한을 근거 없이 두지는 않는다 — 셰이더의 1px 아래 커널처럼 "작으면 안 될 것 같아서" 둔 하한은 대개 필요 없다(이중선형 표본이라 1px 아래도 제대로 동작한다).
브라우저의 화면 갱신 박자는 기기마다 다르다. requestAnimationFrame 콜백은 보통 디스플레이 주사율에 맞춰 불린다고 MDN 문서가 적고 있다 — 그래서 "한 프레임에 몇 ms"는 기기에 매인 값이다. 화면 높이와 기기 픽셀 비율도 마찬가지다(devicePixelRatio).
우리가 겪은 일
세 번 모두 오류 없이 화면이나 판정만 틀렸다.
- 선 굵기(three.js 후처리 윤곽선): 에지 검출 커널 폭을 픽셀로 적었더니 버퍼 높이 1444px 와 510px 에서 장면 대비 선 굵기가 2.8배 달랐다(같은 장면을 두 창 크기로 렌더해 비교). 커널·번짐·손떨림을 기준 높이 대비 비율로 바꾸고, 선을 가늘게 하는 손잡이는 커널 폭이 아니라 에지 판정 문턱이라는 것도 그때 알았다.
- 적응형 품질: 프레임 시간 절대값으로 품질을 내리게 했더니 30Hz 화면에서는 멀쩡한데도 화질을 깎았다. 판정을 "그 화면 주사율 대비 얼마나 밀렸나"로 바꾸고, 주사율은 예열 뒤에 잰다.
- 연출 상수 묶음: 카메라 기준 거리를 32 에서 70 으로 옮겼더니 절대값으로 적어 둔 감속 구간만 그대로 남아 비중이 1/3 로 줄었고, 착지 직전에 급정거하고 안개가 얕아져 먼 풍경이 사라졌다. 묶음 전체를 기준 거리에서 유도하게 고쳤다.
확인 목록
- 이 상수는 다른 값을 보고 정했나? 그 값의 이름은 무엇인가
- 그 기준이 기기·사용자·운영 중에 바뀔 수 있나
- 값이 계산식으로 기준에서 유도되나, 결과 숫자만 적혀 있나
- 같은 기준에 매인 상수가 한곳에 모여 있나
- 기준을 두 값으로 바꾼 시험이 있나
- 절대 하한·상한이 있다면 그 근거가 사람·기기의 실제 한계인가