빠르게 만들 수 있어도 바로 적용하지 않은 최적화

적용할 수 있는 아이디어와 적용한 결과를 나눈다

당시 제안은 접힘 아래 선반의 렌더 비용을 미루는 CSS 기능을 검토하는 것이었다. 문서는 후보 속성과 기대하는 역할을 적지만 실제 적용 성과로 표시하지 않는다. 완료된 목록 통합 뒤에 함께 적혀 있다고 두 작업을 모두 수행한 것으로 읽어서는 안 된다.

다른 홈페이지에서도 라이브러리나 속성의 존재가 실제 개선 결과는 아니다. 자신의 화면과 데이터에 붙인 변경, 그 변경을 확인한 환경, 사용자가 하던 동작의 보존을 읽어야 한다. 나는 제안·착수·변경·측정의 상태를 문서에서 같은 성공 표시로 합치지 않는다.

이미 쓰는 선반의 동작을 수용 조건으로 남긴다

보류 이유에는 가로 스크롤 컨테이너의 위치 복원과 스냅, 레이아웃 변화의 상호작용을 확인해야 한다는 걱정이 있다. 여기서 걱정은 당시 판단의 근거이지 그 기능이 반드시 결함을 만든다는 재현 결과가 아니다. 그 가능성을 확인할 환경을 먼저 마련하려던 선택이었다.

나는 새 최적화가 들어갈 요소의 책임부터 적어 본다. 첫 표시만 보지 않고 어느 항목까지 이동했는지, 다른 페이지에서 돌아왔을 때 어디가 보이는지, 내용이 생기면서 주변이 움직이는지 함께 검사한다. 이 작업에서 보존할 동작이 단순히 화면이 뜬다는 조건보다 넓었던 이유다.

실제 기기의 확인을 착수 조건으로 삼았다

문서에는 개발자 화면과 실제 인앱 브라우저가 달랐던 이전 경험 때문에 휴대폰의 전후 화면을 확보한 뒤 착수한다는 조건이 있다. 나는 이를 모든 최적화에 무조건 같은 기기를 요구하는 규칙으로 만들지 않는다. 이 화면에서 문제가 나타났던 환경과 제안의 영향 범위를 맞춘 조건이다.

시험 환경을 당장 사용할 수 없다면 적용하지 않은 상태를 정직하게 남길 수 있다. 나중에 조건이 마련됐을 때 이전 수치를 기준으로 같은 흐름을 검사하면 된다. 확인 절차를 생략한 대신 완료라고 쓰거나, 적용하지 않은 코드의 성능 향상을 문장으로 보태지 않는다.

보류 기록에는 다시 시작할 정보가 필요하다

보류만 적으면 다음 작업자가 위험하다는 막연한 인상을 받거나 같은 제안을 처음부터 다시 조사할 수 있다. 후보 대상, 지킬 동작, 필요한 근거와 아직 없는 측정 결과를 함께 남기는 편이 낫다. 아래는 이 기록에서 발전시킨 새 설명용 판단 장부다.

장부의 값은 실제 실행이나 상태를 자동으로 판정하는 프로그램이 아니다. 실제 사용에서는 비교한 버전·자료·환경을 넣고 결과가 없는 항목은 비워 둔다. 특정 속성이 위험하거나 안전하다는 결론을 문서 형식만으로 만들어 넣지 않도록 범위를 남긴다.

{
  "candidate": "defer offscreen shelf rendering",
  "state": "deferred",
  "reason": "existing scrolling and restoration need device checks",
  "required_evidence": ["same-device before/after", "scroll and return", "layout stability"],
  "measured_improvement": null
}

기존 성과에 미래의 이득을 합치지 않는다

이 프로젝트의 목록 중복 제거는 별도의 완료 작업이고 화면 밖 선반 최적화는 보류 후보였다. 같은 문서에 나란히 있다고 전후 감소 숫자에 두 효과가 모두 들어 있다고 설명하지 않는다. 무엇이 실행됐는지는 실제 변경과 결과로 확인해야 한다.

나는 더 빠르게 만든다는 약속에 지금 할 수 있는 일과 검증 후 할 일을 나누어 남기려 한다. 보류는 목표를 없애는 일이 아니라 다시 착수할 조건을 구체적으로 정하는 일일 수 있다. 다음 제작자가 같은 장면에서 바로 시험하고 더 나은 선택을 이어 갈 수 있는 작업 기록을 남기고 싶다.

문서는 기존 상단 구조와 대상별 같은 표시 노력을 유지한다는 조건도 둔다. 비용을 줄이려고 일부 대상의 자료부터 빼면 화면이 해결하던 질문이 바뀐다. 나는 최적화 뒤에도 같은 내용을 같은 책임으로 찾을 수 있는지를 수용 조건에 함께 적으려 한다.