메인 페이지의 가장 위 영상 왼쪽이 비어 있다는 질문이 반복됐다. 한국 시간 8월 5일 새벽의 요청에는 여전히 그렇다며 자신의 휴대폰이 문제인지 묻는 말도 있었다. 나는 이 기록을 읽을 때 개발 화면에서 괜찮아 보였다는 설명보다 사용자가 보고 있는 위치를 먼저 맞춰야 한다고 생각했다.

실제 수정은 하나의 계산식을 고르는 일로 끝나지 않았다. 홈과 기사·대상 페이지의 플레이어, 부모의 여백, 미디어 조건과 배포된 파일을 차례로 확인했다. 같은 날 아침 사용자는 이제 잘 되었다고 알려 주었다. 여기서는 그 작업의 경로와 남아 있는 진단의 한계를 함께 읽는다.

영상이라는 이름 아래 서로 다른 컨테이너가 있었다

처음에는 메인의 가장 위 영상이라는 위치를 다시 확인해야 했다. 다른 페이지의 플레이어가 같은 모습으로 보인다고 같은 CSS 조건을 쓰는 것은 아니었다. 당시 홈 리드와 기사 본문, 아티스트 허브의 래퍼를 따로 읽은 기록이 남아 있다.

나는 증상을 받을 때 주소, 상단 영역인지 본문인지, 방향과 브라우저 환경을 함께 남기려 한다. 다른 영역을 고쳐 놓고 같은 영상 문제를 해결했다고 보고하지 않기 위한 기준이다. 사용자가 기기를 의심하게 된 시점에 아직 같은 영역을 보고 있는지도 다시 확인한다.

본문의 열 전환과 영상의 폭 조건이 어긋났다

당시 수정 기록은 홈 본문이 한 칼럼인 구간과 영상 여백을 없애는 미디어 조건이 달랐다는 점을 짚는다. 기존 조건은 768픽셀까지였고 홈의 한 칼럼 구간은 980픽셀까지 이어졌다. 경계 사이의 폭에서는 다른 페이지와 달리 홈 리드가 부모 안의 여백을 남길 수 있었다.

이것은 특정 레이아웃의 조건 비교다. 기기의 이름만 보고 하나의 폭으로 가정하지 않고 실제 부모 크기와 적용된 규칙을 읽어야 한다. 콘텐츠 열 수를 바꾸는 조건과 가장자리까지 넓히는 조건을 따로 관리하면 같은 빈 공간이 어느 구간에서 나오는지 찾기 쉬워진다.

계산식의 변경과 실제 전달된 파일을 구별했다

수정 중에는 뷰포트 폭 계산을 부모 여백에 맞춘 값으로 바꾸고, 이후 고정 픽셀의 왼쪽·오른쪽 음수 마진을 사용한 단계가 있다. 당시 입력은 작은 구간의 14픽셀과 다음 구간의 20픽셀을 따로 처리했다. 한 화면에서 얻은 값이 모든 폭의 부모 여백과 같지는 않았기 때문이다.

기록에는 HTML의 CSS 버전과 공개된 CSS 규칙을 다시 읽은 출력도 있다. 파일을 저장한 상태와 사용자가 새 파일을 받는 상태는 다르다. 나는 이 확인을 실제 휴대폰의 최종 화면 확인과도 나누어 남긴다. 배포 파일이 맞다는 검사만으로 영상의 좌우 모양이 맞았다고 끝내지 않는다.

당시 주석의 원인 설명은 일반 법칙이 아니다

후속 코드 주석은 특정 인앱 WebView에서 계산식이 기대대로 적용되지 않았다고 설명한다. 그러나 지금 내가 확보한 것은 당시 주석·수정·전달 결과와 사용자 확인이다. 엔진의 속성 지원을 따로 추적한 진단 결과까지 읽은 것은 아니다. calc나 논리 속성이 모든 인앱 브라우저에서 실패한다는 규칙으로 넓힐 수 없다.

나는 우회책과 확정된 기전을 구별하고 싶다. 해당 환경에서 문제를 피하려고 단순한 값을 쓴 판단은 기록할 수 있지만, 그 효과를 다른 브라우저의 호환성 결론으로 바꾸지 않는다. 다음 사이트에서는 부모의 실제 여백과 적용된 스타일을 다시 읽고 자신의 기기에서 확인해야 한다.

값을 복사하기보다 부모와의 관계를 가져간다

아래는 부모 여백과 영상 마진의 관계를 보여 주는 새 LTR 설명용 CSS다. 원본 사이트의 전체 스타일이나 현재 기기 검수 결과가 아니다. 값이 맞는 부모 안에 있을 때를 전제로 하며 다른 중첩 여백, 폭 제한과 오버플로를 함께 살펴야 한다.

내가 공유하고 싶은 것은 마이너스14라는 숫자만이 아니다. 어디에 있는 요소인지, 어느 폭에서 어느 부모 값을 상쇄하는지, 다른 페이지에도 같은 조건을 적용해도 되는지를 함께 기록하는 방법이다. 전체 페이지의 가로 넘침을 숨겨 빈 공간의 원인을 덮는 것으로 검사하지 않는다.

코드와 구현 살펴보기

새 LTR 설명 예시. 부모의 실제 여백·폭·넘침을 대조한 뒤 적용한다.

/* Explanatory LTR example: these values must match the parent's actual padding. */
@media (max-width: 760px) {
  .content-shell { padding-left:14px; padding-right:14px; }
  .edge-video { margin-left:-14px; margin-right:-14px; }
}
/* Re-evaluate the parent, breakpoint and other overflow before integration. */

마지막 확인의 주체와 시점을 남긴다

한국 시간 8월 5일 아침에는 이제 잘 되었다는 사용자 메시지가 있고 곧이어 메뉴 스크롤 위치라는 다른 문제가 제기된다. 나는 이 답을 당시 사용자의 화면 확인으로 읽는다. 현재 모든 휴대폰에서 다시 검수한 결과나 원본 스타일 전체의 무결함 인증으로 쓰지는 않는다.

다른 작업에도 실제 기기의 실패 장면, 시도한 변경, 전달된 파일, 같은 영역의 재확인을 연결해 남긴다. 데스크톱의 작은 창은 유용한 검사지만 사용자가 문제를 본 환경을 모두 대신하지 않는다. 내가 해결했다고 말하는 범위가 사용자가 확인한 범위와 맞도록 기록을 이어 간다.