화면 크기를 모른다는 게임의 조건이 제 규칙과 같았습니다: 151개 중 58%만 반응형이었습니다

소개

1주차 사례글에서 저는 제가 만든 HTML을 세어 보고 이렇게 확인했습니다.

읽히려고 만든 것만 138개라는 결론이었습니다.

이번 주 강의에서 스터디장이 타이틀 화면 이야기를 하며 이렇게 말했습니다.

웹 게임들은 브라우저에서 진행되다 보니까 가로형으로 데스크톱에서 플레이될 수도 있고, 모바일에서 세로로 길쭉하게 나올 수도 있습니다. 그러다 보니 타이틀 화면이 어떤 사이즈에서 나올지 잘 몰라요.

이 문장이 제 규칙 파일에 있는 것과 같았습니다. 저는 rules/html-output.md에 이렇게 써 두었습니다.

HTML을 만들 때는 반응형을 기본으로 한다. 하네스로 만들든 손으로 만들든 예외 없다. 고정 픽셀 폭으로 문서를 고정하지 않는다.

게임이 아니어도 화면 크기를 모르는 것은 같습니다. 그래서 제 HTML이 그 조건을 지키고 있는지 세어 봤습니다.

진행 방법

사용 도구: Claude Code, Python 3

Step 1. 개수부터 다시 세기

1주차에는 138개였는데 이번 주에 세니 151개였습니다.

늘어난 13개는 이번 세션에 제가 만든 사례글 HTML입니다. 게시판에 붙여 넣으려고 마크다운을 변환한 것들입니다.

같은 수치를 다른 주에 재면 달라진다는 뜻이니, 비교할 때는 시점을 함께 적어야 합니다.

Step 2. 반응형 조건 네 가지로 검사

FIXED = r'(?<!max-)(?<!min-)width:\s*\d{3,}px'   # max-width/min-width는 제외
MAXW  = r'max-width:\s*\d+'
VP    = r'<meta[^>]+name=["\']viewport'
MQ    = r'@media[^{]*\('

Step 3. 숫자를 읽기

viewport는 99%인데 미디어쿼리는 58%입니다.

viewport 태그는 "모바일에서 보겠다"는 선언이고, 미디어쿼리는 좁은 화면에서 실제로 배치를 바꾸는 동작입니다. 선언은 거의 다 했는데 동작은 절반을 조금 넘습니다.

Step 4. 고정 폭 8개가 규칙 위반인지 확인

규칙에 예외 조항이 있는지 다시 읽었습니다.

캡처 전용 고정 규격이 필요한 경우(예: 4:5·16:9 PNG용 카드)에만 고정 폭을 쓰고, 그때도 웹 링크용 버전은 별도로 반응형으로 함께 낸다.

걸린 8개를 봤습니다.

발표 슬라이드와 원페이지 카드입니다. 규칙의 예외 조항에 해당합니다.

8개는 위반이 아니었습니다. 규칙을 다시 읽지 않았으면 "5%가 규칙을 어겼다"고 쓸 뻔했습니다.

Step 5. 그럼 진짜 문제는

42%가 좁은 화면에서 어떻게 보일지 확인되지 않은 상태입니다.

결과와 배운 점

측정 결과

배운 점

1. 선언과 대응이 갈렸습니다. viewport 99%, 미디어쿼리 58%입니다. 태그 한 줄은 템플릿에 들어 있어 자동으로 붙고, 미디어쿼리는 만들 때마다 따로 써야 합니다. 자동으로 되는 것은 100%에 가깝고 손이 가는 것은 절반입니다.

2. 게임의 조건이 문서에도 그대로 있었습니다. 스터디장은 "타이틀 화면이 어떤 사이즈에서 나올지 모른다"고 했습니다. 제 리포트도 마찬가지입니다. 누가 휴대폰으로 열지 데스크톱으로 열지 저는 모릅니다. 게임만의 문제가 아니라 브라우저에서 도는 모든 것의 문제였습니다.

3. 배경과 로고를 나누라는 해법이 일반적입니다. 화면 크기에 따라 늘어날 부분과 고정될 부분을 미리 나누는 방식입니다. 제 문서로 옮기면 본문은 늘어나고 표는 가로로 스크롤되게 하는 것과 같습니다. 표가 있는 리포트를 휴대폰으로 열면 깨지는 이유가 이 분리를 안 해 둔 탓입니다.

4. 규칙을 다시 읽은 것이 결론을 바꿨습니다. 고정 폭 8개를 발견했을 때 위반이라고 판단했다가, 규칙 원문에 예외 조항이 있는 것을 확인했습니다. 슬라이드와 카드는 고정 규격이 맞습니다. 규칙을 기억으로 적용하면 자기 규칙도 잘못 적용합니다.

시행착오

• 정규식으로 고정 폭을 찾을 때 처음에는 width:\s*\d{3,}px로만 걸러 max-width:800px까지 잡혔습니다. 그러면 규칙을 지킨 파일이 위반으로 나옵니다. (?<!max-)(?<!min-)을 앞에 붙여 제외했습니다. 금지 패턴을 찾을 때 그 패턴을 포함하는 허용 패턴이 있는지 먼저 봐야 합니다.

• 1주차의 138개와 이번 주 151개를 그대로 비교할 뻔했습니다. 늘어난 13개가 제가 이번 세션에 만든 것이라 측정 대상이 측정 중에 늘어난 경우입니다.

앞으로의 계획

• 이번 주 과제인 게임에는 타이틀 화면을 배경과 로고로 나눠 만들겠습니다. 1주차에 목표로 잡은 getContext 사용도 여기서 함께 해 봅니다.

• 미디어쿼리가 없는 62개 중 최근 것부터 확인하려 합니다. 전부 고치기보다 지금도 열어 보는 것들이 우선입니다.

• 사례글 HTML을 만드는 스크립트에 반응형이 이미 들어 있는지 확인하겠습니다. 13개가 한 번에 늘어난 만큼, 그 스크립트가 앞으로 만들 것들의 비율을 좌우합니다.

• 강의에서 말한 게임 제작 하네스의 체크포인트 개념을, 제 HTML 생성 쪽에도 붙여 보려 합니다. 반응형, 표 스크롤, 다크모드 대응을 매번 검토하게 하는 형태입니다.

도움 받은 글 (옵션)

• 23기 게임 바이브코딩 2주차 강의 (토옵이): 웹 게임의 화면 크기가 정해져 있지 않다는 조건과 배경·로고를 분리하는 해법, 브라우저가 자동 재생을 막아 첫 터치를 사운드 동의로 처리하는 방법, 창 전환 시 타이머가 튀는 문제, 점검 항목을 하네스에 넣어 매번 검토하게 하는 방식

• 23기 게임 바이브코딩 1주차 사례글 (본인): HTML 138개 중 사용자 입력을 받는 것이 실질 1개였다는 측정