EP.033 판정엔 8초, 실행엔 20초가 필요한 이유

하이퍼-Δ 페이지의 "04 · FIREPOWER CONTROL MAP" 아래에는 상태표와 나란히 작은 문구 몇 줄이 붙어 있다. "스텝 2% 고정", "주기 = 감열 후 20–40초 잠금(lockout) 뒤 재판정", "신호는 8~10초 지속될 때만 믿는다." 언뜻 보면 같은 종류의 안전장치처럼 읽히지만, 실제로는 서로 다른 두 가지 문제를 각각 막기 위한 별개의 타이머다.

첫 번째 타이머는 810초다. 이건 화력을 조절하기 전, 신호를 믿을지 말지 판단하는 기준이다. 06번(화력을 올렸는데 왜 원두 온도는 안 오르나)에서 이미 짧게 언급했듯, ET RoR이나 BT RoR이 방향을 바꾼 것처럼 보여도 12초짜리 흔들림이면 노이즈일 가능성이 크다. 미디언 디스파이크로 튀는 값을 먼저 걸러내긴 하지만, 그 이후에도 신호가 8~10초 이상 같은 방향을 유지해야만 상태 판정에 반영한다는 것이 하이퍼-Δ 페이지가 명시한 기준이다. 이 타이머가 막는 건 오판이다 — 잠깐의 흔들림을 실제 추세로 착각해 엉뚱한 상태로 넘어가는 것.

두 번째 타이머는 2040초다. 이건 화력을 조절한 후 다음 조절까지 기다리는 시간, 즉 잠금(lockout)이다. "03 · THE RULE" 규정 자체가 "불은 올리지 않는다 — 딱 하나, 스톨일 때만 +2% 예외"라고 못박고 감열 위주로만 움직이도록 설계돼 있는데, 이 감열 조치 하나하나 사이에도 최소 2040초의 공백을 둔다. 이유는 "01 · TWO SIGNALS" 섹션이 말하는 시간 지연 때문이다 — ET를 바꿔도 BT는 몇십 초 늦게 반응한다. 감열 조치를 내린 직후에는 아직 그 조치의 결과가 BT RoR에 나타나지 않은 상태이므로, 이 시점에 또 신호를 읽고 또 감열하면 이미 내린 조치의 효과를 보기도 전에 겹쳐서 깎는 셈이 된다. 잠금은 이 과잉수정을 막기 위한 장치다.

두 타이머가 막는 실패는 서로 다른 방향이다. 810초는 너무 빨리 반응해서 노이즈에 흔들리는 것을 막고, 2040초는 너무 자주 반응해서 지연을 무시하는 것을 막는다. 하나는 입력을 늦게 믿고, 하나는 출력을 늦게 낸다. 둘 다 "느리게 가라"는 방향이지만 늦추는 대상이 다르다는 점이 이 구조의 핵심이다.

여기에 스텝 크기(2% 고정)까지 더하면 하이퍼-Δ의 감열 조절 방식이 완성된다. 크기를 매번 바꾸는 대신 고정해두고, 빈도(언제 조치할지)만 두 타이머로 조절하는 구조다. 페이지 문구를 그대로 옮기면 "세기는 빈도로" — 변수를 하나로 좁혀두면, 조절 강도가 세거나 약해서 생기는 오차보다 조절 타이밍이 어긋나서 생기는 오차를 관리하는 쪽이 더 다루기 쉽다는 판단으로 읽힌다.

다만 이 세 숫자(810초, 2040초, 2%) 모두 17번(하이퍼델타는 왜 스스로 수치는 미보정이라고 말하는가)에서 다룬 "08 · VERIFICATION & HONEST LIMITS" 섹션이 명시적으로 경험 등급, 즉 동료심사 문헌이 뒷받침하지 않는 수치로 분류한 값들이다. 페이지는 감열 비율이나 판정 주기, 임계값 같은 구체적인 숫자는 기계·프로브·배치에 의존하는 경험 캘리브레이션이며 로스트 로그로만 확정된다고 스스로 밝힌다. 즉 810초와 2040초라는 구간 자체는 실무에서 통용되는 기본값이지, 물리 법칙에서 유도된 숫자가 아니다.

그렇다면 이 숫자들을 고정으로 둔 게 맞는 선택인지는 이 페이지 텍스트만으로는 답할 수 없다. 29번(θ_flat와 데드밴드는 이론이 정하지 않은 숫자다)에서 확인했듯, 판정 파라미터는 라이브 화면의 칩을 눌러 직접 조정할 수 있게 열려 있다 — θ_flat과 데드밴드가 그 예였고, 지속시간·잠금시간도 같은 성격의 조정 가능 파라미터일 가능성이 있다. 다만 이번 편에서는 공개된 이론 페이지의 텍스트만 근거로 삼았고, 실제 캘리브레이션 화면에서 이 두 타이머가 개별적으로 노출돼 조정 가능한지, 아니면 고정값으로 묶여 있는지는 확인하지 못했다 — 로그인 후 라이브 로스팅 화면을 열어야 확인되는 부분이라 이번 글에서는 단정하지 않는다.

두 개의 타이머를 따로 두는 구조 자체는 정교하다. 노이즈 문제와 지연 문제를 하나의 숫자로 뭉뚱그리지 않고 각각 다른 상수로 다룬다는 점에서다. 하지만 정교한 설계가 정확한 숫자를 보증하지는 않는다. 810초와 2040초라는 구간이 왜 하필 그 범위인지, 다른 로스터기·다른 프로브에서도 같은 값이 그대로 통하는지는 페이지 어디에도 답이 없다. 구조는 이해했고, 숫자는 여전히 각자 로스트 로그로 확인할 몫으로 남는다.