반응형홈페이지·웹사이트 제작 홈페이지 발주서에 ‘반응형 제작 포함’이라고만 쓰면 안 되는 이유

홈페이지를 납품받았는데 모바일 화면에서 메뉴가 겹치거나 일부 콘텐츠가 잘린다는 연락이 옵니다. 발주서에는 분명 ‘반응형 제작 포함’이라고 적혀 있습니다. 제작사는 화면 크기에 따라 레이아웃이 바뀌도록 구현했으니 계약대로 작업했다고 설명합니다. 이런 문제가 생기는 이유는 반응형 제작이라는 표현 자체보다 어떤 화면과 사용 환경에서 정상 작동해야 하는지에 대한 기준이 빠져 있기 때문입니다. 반응형 웹은 화면 크기와 사용 환경에 맞춰 레이아웃이 조정되는 설계 방식입니다. 하지만 반응형으로 제작했다는 사실만으로 모든 모바일 기기에서 사용성이 보장되는 것은 아닙니다. 발주 단계에서 지원 범위와 납품 검수 기준을 정해두어야 하는 이유입니다.

고정 헤더도 동작 조건을 정해야 합니다
상단 메뉴를 스크롤해도 보이도록 만드는 고정 헤더는 사용자가 다른 페이지로 이동하거나 문의 버튼에 접근하기 편리하다는 장점이 있습니다. 반면 모바일에서는 헤더가 화면을 지나치게 차지하거나 본문과 입력 요소를 가릴 수 있습니다. 예를 들어 문의 폼을 작성할 때 모바일 키보드가 올라오면서 화면 공간이 줄어드는 상황을 생각해볼 수 있습니다. 고정 헤더가 입력칸이나 제출 버튼을 가린다면 사용자는 정상적으로 작업하기 어렵습니다. W3C의 웹 콘텐츠 접근성 지침(WCAG 2.2)에서도 키보드 포커스를 받은 요소가 작성자가 배치한 콘텐츠에 완전히 가려지지 않도록 하는 기준을 제시합니다. 다만 이 기준을 충족하는 방법이 고정 헤더를 무조건 해제하는 것만은 아닙니다. 발주서에는 고정 헤더 적용 여부뿐 아니라 모바일에서의 높이, 스크롤 시 동작, 키보드가 나타났을 때 입력 요소가 가려지지 않는지 등을 검수 항목으로 정할 수 있습니다.

반응형 제작은 지원 화면 범위까지 확인해야 합니다
‘PC와 모바일 반응형 지원’이라는 문구만으로는 어느 화면 너비까지 검수할 것인지 알기 어렵습니다. 스마트폰 세로 화면에서는 정상적으로 보이지만 가로 방향에서는 메뉴가 겹칠 수 있습니다. 태블릿에서 이미지가 비정상적으로 확대되거나, 화면 너비가 좁아졌을 때 본문에 불필요한 가로 스크롤이 생기기도 합니다. WCAG 2.2의 재배치(Reflow) 기준은 일반적인 세로 스크롤 콘텐츠에서 320 CSS 픽셀에 해당하는 좁은 화면 너비에서도 정보나 기능을 잃지 않고 사용할 수 있도록 하는 것을 요구합니다. 다만 지도나 복잡한 표처럼 의미와 사용을 위해 2차원 배치가 필요한 콘텐츠에는 예외가 적용될 수 있습니다. 여기서 320 CSS 픽셀은 특정 스마트폰 모델의 물리적 화면 크기를 뜻하는 것이 아니라 재배치 가능성을 평가하는 기준입니다. 따라서 발주서에는 PC·태블릿·모바일의 주요 검수 화면 너비, 세로·가로 방향 확인 범위, 콘텐츠 겹침과 잘림 여부 등을 구체적으로 정하는 편이 좋습니다.

모바일 버튼은 크기뿐 아니라 간격도 중요합니다
모바일에서 버튼이 작거나 서로 붙어 있으면 사용자가 원하는 항목을 정확히 누르기 어렵습니다. WCAG 2.2의 AA 수준에 해당하는 ‘Target Size (Minimum)’ 기준은 기본적으로 포인터 입력 대상의 크기를 24×24 CSS 픽셀 이상으로 정하고 있습니다. 다만 대상 간 충분한 간격이 확보된 경우 등 여러 예외가 있어 모든 버튼이 반드시 24×24픽셀 이상이어야 한다는 의미는 아닙니다. 실제 검수에서는 버튼의 표시 크기뿐 아니라 누를 수 있는 영역, 주변 요소와의 간격, 메뉴가 펼쳐졌을 때 다른 버튼을 가리지 않는지도 함께 확인해야 합니다. ‘모바일에서 버튼이 작다’는 주관적인 평가보다 적용하기로 합의한 접근성 기준과 실제 사용 환경을 근거로 확인하면 수정 범위를 판단하기 수월해집니다.

SEO 포함이라는 문구도 작업 범위가 불분명합니다
홈페이지 제작 견적서에서 자주 보이는 표현 중 하나가 ‘검색엔진 최적화 포함’입니다. 하지만 이 문구만으로 어떤 작업이 제공되는지 판단하기는 어렵습니다. 페이지별 제목과 설명 메타데이터를 설정하는지, XML 사이트맵을 생성하는지, robots.txt를 점검하는지, 구조화 데이터를 적용하는지에 따라 작업 범위가 달라집니다. 구조화 데이터 역시 모든 페이지에 동일한 코드를 넣는 방식보다 실제 콘텐츠 유형과 검색엔진의 지원 조건에 맞춰 적용해야 합니다. robots.txt에서 검색엔진이나 특정 AI 크롤러의 접근을 제어할 수는 있지만, 접근을 허용했다고 AI 검색 결과에 반드시 인용되는 것은 아닙니다. Google Search Console의 소유권 확인과 사이트맵 제출, GA4 설치 및 문의 완료 이벤트 설정도 구분할 필요가 있습니다. 특히 GA4가 설치됐다는 사실만으로 문의가 정상적으로 접수된 건수를 측정할 수 있는 것은 아닙니다. 발주서에는 이런 항목 중 무엇을 실제로 수행하고, 어떤 방식으로 납품 검수를 할 것인지 정해두는 편이 명확합니다.

무상 수정과 하자 보수의 범위도 구분해야 합니다
납품 후에는 기능 오류 수정과 콘텐츠 변경 요청이 함께 발생합니다. 문의 폼이 정상적으로 작동하지 않는 문제와 오픈 이후 서비스 소개 문구를 새롭게 바꾸는 작업은 성격이 다릅니다. 계약서에 수정 범위가 불명확하면 발주사는 당연히 무상이라고 생각하고, 제작사는 추가 작업이라고 판단할 수 있습니다. 계약 단계에서는 납품 사양에 맞지 않는 오류를 어떻게 처리할지, 무상 수정 기간과 범위는 어디까지인지, 추가 요청은 어떤 기준으로 견적을 산정하는지 정해두는 것이 좋습니다. 소스코드와 데이터베이스의 인도 여부, 저작재산권의 귀속 또는 이용허락 범위, 유지보수와 계약 종료 시 자료 인도 조건도 함께 확인해야 합니다. 제작비를 지급했다고 모든 소스와 외부 라이선스의 권리가 자동으로 이전되는 것은 아니기 때문입니다. 발주서와 계약서는 실무에서 서로 다른 역할을 맡을 수 있지만 반드시 별도 문서로 작성해야 하는 것은 아닙니다. 중요한 것은 기능·사양·검수 기준과 대금·권리·유지보수 조건이 계약 문서에 빠짐없이 포함되고, 서로 모순되지 않는 것입니다.

홈페이지 제작 분쟁은 기능을 구현했는지에 대한 의견 차이보다, 처음부터 어디까지 구현하기로 했는지가 불분명해서 발생하기도 합니다. ‘반응형 제작 포함’이라는 한 줄보다 실제 모바일 화면에서 무엇을 확인할지 구체적으로 정해두는 편이 납품 이후의 수정 협의와 품질 관리에 도움이 됩니다. 저희 희명웹은 홈페이지제작 계약 단계에서 반응형 지원 범위, 모바일 주요 동작, 검색엔진 및 분석 도구 설정 항목, 납품 검수와 무상 수정 조건을 사전에 확인할 수 있도록 정리해 진행합니다. 감사합니다. 

희명웹 올림

참고할만한 인사이트 칼럼링크 : 홈페이지제작, 성과 보고에서 자주 빠지는 숫자들