전사 반응형 웹 표준으로 팀의 흩어진 디자인 정책 모으기

예전엔 반응형 디자인의 기준이 팀 내에서 명확하지 않았다. 누구는 768px를 기준으로, 누구는 600px로, 누구는 자신의 노트북 해상도 기준으로 대충 맞춰놨다. UI 컴포넌트는 같은 패키지인데 화면 폭에 따라 다르게 동작하고, QA도 "모든 폭에서 테스트하는 게 맞나?"라고 물어봤다. 스타일시트와 미디어 쿼리는 조각난 상태였고, 신입이 들어올 때마다 "이 프로젝트는 어느 폭부터 태블릿으로 봐요?"라는 질문이 반복됐다. 이걸 정리해야 할 필요성을 느껴 전사 표준 문서를 만들었다.

결정: 범위와 검증까지 정한 9개 폭의 사다리

단순한 "대응해주세요" 가이드라인이 아니라 실행 가능한 기준을 문서화했다.

• 폭 범위: 295px ~ 1440px (모바일 소형 ~ 데스크톱 표준)
• 체크포인트: 9개의 구체적 폭 지점
• 완료조건: 오버플로우, 콘솔 에러, 인터랙션 검증 3가지 동시 만족

이 셋을 다 체크하는 개발자가 생각보다 많지 않았다. 레이아웃은 "괜찮아 보여"라고 넘어갔다가, 실제 사용자가 보면 버튼이 누를 수 없는 위치에 있거나 입력값이 텍스트와 겹쳐 보이곤 했다. 코드 리뷰에서 "어, 왜 모바일에선 안 눌려?"라는 버그 리포트가 자주 올라왔다.

회고: 표준화 작업에서 배운 것들

첫째, 정책은 추상적이면 실패한다.
처음엔 "모든 해상도에 대응하세요"라고 쓰려다가 멈췄다. 누구나 아는 말이지만, 실행하는 사람 입장에선 몇 개 폭을 테스트할지 구체적으로 알아야 한다. "우리는 9개 폭을 이렇게 정했다"고 구체적으로 명시해야 개발자도, 리뷰어도 "아, 최소 9개는 확인해야 하는구나"라고 읽힌다. 그리고 "언제 이 표준을 업데이트하나?"라는 질문에도 답할 수 있게 된다.

둘째, "완료"의 정의가 리뷰의 질을 결정한다.
레이아웃만 맞춰도 기술 과제로 끝내는 개발자들도 있고, 좀 더 신경 쓰는 개발자는 인터랙션까지 전부 확인하는 차이가 컸다. 문서에 "완료 = 오버플로우/콘솔/인터랙션 3가지 동시 만족"이라고 명시하니 리뷰가 훨씬 명확해졌다. 리뷰어 입장에선 이 3가지를 체크리스트로 확인하면 되고, 작성자 입장에선 무엇까지 해야 하는지 알 수 있다.

셋째, 표준은 "일회성 문서"가 아니라 "팀 대화의 단위"다.
문서화하고 끝내면 3개월 뒤엔 아무도 안 봤다. 그래서 이 표준을 전사 공통 가이드 문서에 넣으면서, 매 코드 리뷰·설계 세션에서 "우리 표준에 맞나?"라고 의식적으로 환기했다. 신입 온보딩 때도 이 문서를 먼저 읽게 했다. "이게 우리 팀의 약속"이라고.

넷째, 이런 결정은 개발팀 혼자 하면 안 된다.
브레이크포인트 수를 정할 때 디자인팀과도 한 번 만났다. 실제 사용자 기기 분포, 디자인 수정 빈도, 개발 유지보수 비용을 함께 고려했다. 개발 입장에선 적을수록 편하지만, 사용성 입장에선 섬세한 대응이 필요했다. 그래서 9개라는 숫자가 나왔다. 많지도, 적지도 않은 선택.

결국 반응형 디자인 표준화는 기술 결정이 아니라, 팀이 어떤 언어로 대화할지를 정하는 과정이었다. 일관된 정책이 있으면 리뷰어와 작성자가 같은 기준으로 얘기할 수 있고, 새로운 기능을 만들 때도 과거의 논쟁을 반복하지 않는다. 그 결과가 문서에 박혀 있다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.