0724 프론트엔드 실무 심화 (7/N): 반응형 레이아웃, 모바일 UX와 접근성 기본 설계
✅ 1. 반응형 레이아웃이란 무엇인가?
- 반응형 레이아웃(Responsive Layout)은 화면 크기와 기기 환경에 따라 UI가 자연스럽게 바뀌도록 설계하는 방식입니다.
- PC, 태블릿, 모바일에서 같은 화면을 억지로 줄여 보여주는 것이 아니라, 각 환경에 맞게 정보 배치와 조작 방식을 조정하는 것입니다.
- 고객 화면에서는 전환율에 직접 영향을 주고, 관리자 화면에서는 급하게 모바일로 확인해야 할 때 업무 가능 여부를 결정합니다.
PC:
넓은 화면, 많은 정보 표시 가능
Tablet:
중간 화면, 2열/카드형 조합
Mobile:
좁은 화면, 핵심 정보와 주요 버튼 우선
➕ 1-1. 반응형이 중요한 이유
- 고객 대부분은 모바일에서 상품을 보고 상담 신청을 할 가능성이 높습니다.
- 모바일에서 버튼이 작거나 폼이 불편하면 신청률이 떨어집니다.
- 관리자 화면도 외부에서 상담/주문 상태를 확인해야 할 수 있습니다.
- 화면이 깨지면 서비스 신뢰도가 떨어집니다.
- 반응형 기준이 없으면 페이지마다 모바일 대응 방식이 달라집니다.
나쁜 모바일 화면:
글자가 너무 작음
버튼이 눌리기 어려움
테이블이 화면 밖으로 밀림
상담 신청 버튼이 안 보임
모달이 화면 밖으로 잘림
결과:
고객 이탈, 운영자 불편, 서비스 완성도 하락
✅ 2. 반응형 설계의 기본 원칙
- 반응형은 단순히 CSS
media query를 쓰는 것이 아닙니다.
- 화면 크기별로 어떤 정보가 중요한지 우선순위를 정하는 작업입니다.
➕ 2-1. 기본 원칙
작은 화면부터 생각한다
핵심 행동 버튼을 먼저 배치한다
가로 스크롤을 최소화한다
터치 영역을 충분히 확보한다
이미지와 텍스트가 깨지지 않게 한다
모달은 모바일에서 바텀시트처럼 고려한다
테이블은 카드형 또는 가로 스크롤로 대체한다
➕ 2-2. Mobile First
- Mobile First는 모바일 화면을 먼저 설계하고, 화면이 넓어질수록 정보를 확장하는 방식입니다.
- 고객 화면에서는 Mobile First 접근이 특히 좋습니다.
모바일:
핵심 정보 + CTA
태블릿:
보조 정보 추가
PC:
상세 정보, 비교 영역, 사이드 정보 추가
- PC 화면을 그대로 줄이는 방식은 모바일에서 대부분 실패합니다.
- 좁은 화면에서는 버릴 정보와 남길 정보를 명확히 정해야 합니다.
✅ 3. Breakpoint 기준
- Breakpoint는 화면 크기에 따라 레이아웃을 바꾸는 기준점입니다.
- 프로젝트마다 다를 수 있지만, 일반적으로 모바일/태블릿/데스크탑 기준을 둡니다.
➕ 3-1. 예시 기준
mobile:
~ 767px
tablet:
768px ~ 1023px
desktop:
1024px ~
wide:
1280px ~
➕ 3-2. Tailwind 기준 예시
sm: 640px
md: 768px
lg: 1024px
xl: 1280px
2xl: 1536px
➕ 3-3. 주의할 점
기기명 기준으로만 생각하지 않기
실제 콘텐츠가 깨지는 지점을 기준으로 조정하기
너무 많은 breakpoint 만들지 않기
페이지마다 다른 기준 남발하지 않기
- iPhone, iPad, MacBook 이름으로만 기준을 잡으면 애매해집니다.
- 실제 UI가 깨지는 시점이 더 중요합니다.
✅ 4. Layout 기본 구조
- 화면은 보통 Header, Main, Footer, Sidebar, Content 영역으로 나눌 수 있습니다.
- 관리자 페이지와 고객 페이지는 레이아웃 목적이 다릅니다.
➕ 4-1. 고객 화면 레이아웃
Header
↓
Hero / 상품 핵심 정보
↓
혜택/요금/상세 정보
↓
리뷰/FAQ/안내
↓
Sticky CTA
↓
Footer
➕ 4-2. 관리자 화면 레이아웃
Sidebar
Header
Main Content
├─ PageHeader
├─ Search/Filter
├─ Toolbar
├─ Table/List
└─ Pagination
- 고객 화면은 상담 신청, 구매 전환, 혜택 이해가 중심입니다.
- 관리자 화면은 데이터 조회, 필터링, 처리 액션이 중심입니다.
✅ 5. Flex와 Grid 사용 기준
- 레이아웃을 잡을 때 Flex와 Grid를 구분해서 쓰면 좋습니다.
| 방식 | 적합한 상황 |
|---|
| Flex | 한 줄 정렬, 버튼 그룹, 헤더, 카드 내부 |
| Grid | 카드 목록, 2열/3열 구조, 대시보드 |
| Table | 실제 행/열 데이터 |
| Stack | 모바일에서 세로 배치 |
➕ 5-1. Flex가 좋은 예시
버튼 두 개 나란히 배치
헤더 좌우 정렬
아이콘 + 텍스트 정렬
폼 label/input 정렬
➕ 5-2. Grid가 좋은 예시
상품 카드 목록
요금제 비교 카드
관리자 대시보드 통계 카드
이미지 갤러리
➕ 5-3. 기준
한 방향 정렬:
Flex
행과 열 구조:
Grid
데이터 행/열:
Table
- 레이아웃 도구를 섞어 쓰는 것은 괜찮습니다.
- 중요한 것은 용도에 맞게 쓰는 것입니다.
✅ 6. 고객 상품 상세 화면 반응형 설계
- 온라인 휴대폰 판매몰에서 상품 상세 화면은 전환율에 가장 중요한 화면 중 하나입니다.
- 모바일에서는 핵심 정보와 상담 신청 버튼이 빨리 보여야 합니다.
➕ 6-1. PC 구조
왼쪽:
상품 이미지, 색상 이미지
오른쪽:
상품명, 출고가, 월 예상요금, 지원금, 요금제 선택, 상담 신청 버튼
아래:
혜택 안내, 상세 스펙, 리뷰, FAQ
➕ 6-2. 모바일 구조
상단:
상품 이미지
그 아래:
상품명, 핵심 혜택, 월 예상요금
중간:
요금제/색상/용량 선택
하단:
Sticky 상담 신청 버튼
아래:
상세 정보, 리뷰, FAQ
➕ 6-3. 모바일에서 우선 보여줄 것
상품명
대표 이미지
핵심 혜택
월 예상 요금
지원금
상담 신청 버튼
- 모바일 첫 화면에서 너무 많은 설명을 넣으면 사용자가 핵심을 놓칩니다.
- 상세 설명은 접힘 영역이나 아래 섹션으로 보내도 됩니다.
✅ 7. Sticky CTA
- Sticky CTA는 화면 하단에 고정되는 주요 행동 버튼입니다.
- 모바일 고객 화면에서는 상담 신청, 사전예약 신청, 혜택 확인 같은 버튼을 하단에 고정하면 전환에 도움이 됩니다.
➕ 7-1. 예시
[상담 신청하기]
[사전예약 알림 신청]
[혜택 확인하기]
➕ 7-2. 사용 기준
모바일에서만 노출
주요 행동 1개 또는 최대 2개
하단 안전 영역 고려
너무 많은 버튼 넣지 않기
스크롤 중에도 방해되지 않게 하기
➕ 7-3. 주의할 점
하단 콘텐츠를 가리지 않도록 padding-bottom 확보
iPhone safe-area 고려
채팅 버튼/상담 버튼과 겹치지 않게 배치
모달 열림 시 숨김 처리 고려
- Sticky CTA는 강력하지만 남발하면 화면이 답답해집니다.
- 전환과 방해 사이의 균형을 봐야 합니다.
✅ 8. 모바일 폼 UX
- 모바일 폼은 고객 상담 신청과 사전예약 신청에서 매우 중요합니다.
- 입력이 조금만 불편해도 이탈이 발생할 수 있습니다.
➕ 8-1. 모바일 폼 원칙
입력 필드 수 최소화
필수값만 먼저 받기
전화번호 input은 숫자 키패드
버튼은 충분히 크게
에러 메시지는 필드 바로 아래
제출 중 중복 클릭 방지
완료 메시지는 명확하게
<input
type="tel"
inputMode="numeric"
autoComplete="tel"
placeholder="01012345678"
/>
➕ 8-3. 버튼 높이 기준
모바일 주요 버튼:
최소 44px 이상 권장
터치 영역:
너무 작거나 가까우면 오작동 증가
- 고객용 폼은 “빠르게 신청 완료”가 핵심입니다.
- 운영상 필요한 상세 정보는 해피콜 단계에서 받는 방식도 고려할 수 있습니다.
✅ 9. 모바일 모달과 바텀시트
- PC에서는 중앙 모달이 자연스럽지만, 모바일에서는 하단에서 올라오는 바텀시트(Bottom Sheet) 형태가 더 편할 때가 많습니다.
➕ 9-1. PC 모달
화면 중앙 표시
너비 고정
배경 dim 처리
ESC/닫기 버튼
➕ 9-2. 모바일 바텀시트
화면 하단에서 올라옴
가로 전체 너비 사용
상단에 닫기/핸들
내부 스크롤 가능
하단 버튼 고정 가능
➕ 9-3. 상담 신청 모달 기준
PC:
중앙 모달
Mobile:
바텀시트 또는 전체 화면에 가까운 모달
공통:
제출 버튼은 하단 고정 또는 명확히 보이게
- 모바일에서 중앙 모달이 너무 작거나 화면 밖으로 밀리면 UX가 나빠집니다.
- 긴 폼은 전체 화면 전환도 고려할 수 있습니다.
✅ 10. 관리자 테이블 모바일 대응
- 관리자 테이블은 PC 기준이 기본이지만, 모바일에서도 최소 확인은 가능해야 합니다.
- 모든 컬럼을 그대로 보여주면 가독성이 떨어집니다.
➕ 10-1. 대응 방식
가로 스크롤
핵심 컬럼만 노출
카드형 목록 전환
상세 정보는 펼침 처리
액션 버튼은 더보기 메뉴로 이동
➕ 10-2. 상담 목록 모바일 카드 예시
[대기] 홍길동 / 010****5678
iPhone 17 Pro
네이버광고 · 2026-07-24 10:30
[상세] [상태 변경]
➕ 10-3. 모바일에서 우선 표시할 것
상태
고객명
전화번호
상품명
신청일
핵심 액션
- 내부 ID, 긴 메모, 외부 응답 전문 같은 정보는 모바일 목록에서 숨겨도 됩니다.
- 상세 모달에서 확인하게 하면 됩니다.
- 관리자 페이지의 Sidebar는 PC에서는 고정, 모바일에서는 Drawer 형태가 자연스럽습니다.
왼쪽 고정
메뉴 항상 표시
현재 메뉴 highlight
넓은 화면에서 업무 속도 좋음
➕ 11-2. 모바일 Drawer
햄버거 버튼 클릭
왼쪽 또는 오른쪽에서 열림
메뉴 선택 후 닫힘
배경 dim 처리
➕ 11-3. 주의할 점
권한 없는 메뉴는 표시하지 않기
현재 페이지 표시
모바일에서 메뉴 열림 상태 접근성 고려
ESC 또는 배경 클릭 닫기
- 관리자 모바일 UX는 자주 쓰지 않더라도 깨지면 안 됩니다.
- 최소한 메뉴 이동은 가능해야 합니다.
✅ 12. 이미지 반응형 처리
- 고객 상품 상세와 배너에서는 이미지가 매우 중요합니다.
- 이미지가 깨지거나 비율이 틀어지면 판매 페이지의 신뢰도가 떨어집니다.
➕ 12-1. 이미지 원칙
비율 유지
너비 100% 적용
최대 너비 제한
object-fit 사용
모바일/PC 이미지 비율 고려
불필요하게 큰 원본 이미지 사용 금지
➕ 12-2. CSS 예시
.product-image {
width: 100%;
max-width: 520px;
height: auto;
object-fit: contain;
}
➕ 12-3. 배너 이미지 기준
PC:
가로형 배너 사용
Mobile:
모바일 전용 비율 또는 중앙 핵심 요소가 잘리지 않는 이미지 사용
주의:
텍스트가 이미지 안에 있으면 모바일에서 작아질 수 있음
- 가능하면 중요한 텍스트는 이미지 안에 박아넣기보다 HTML 텍스트로 관리하는 것이 좋습니다.
- 단, 디자인 배너는 예외적으로 이미지 텍스트가 필요할 수 있으므로 모바일 가독성을 따로 확인해야 합니다.
✅ 13. 반응형 Typography
- 화면 크기별로 글자 크기와 줄 간격도 조정해야 합니다.
- PC에서 보기 좋은 큰 제목이 모바일에서는 너무 부담스러울 수 있습니다.
➕ 13-1. 기준 예시
페이지 제목:
PC 32px / Mobile 24px
섹션 제목:
PC 24px / Mobile 20px
본문:
PC 16px / Mobile 15~16px
보조 설명:
PC 14px / Mobile 13~14px
➕ 13-2. 주의할 점
모바일 본문을 너무 작게 하지 않기
줄 간격 확보
긴 문장은 적절히 줄바꿈
중요 정보는 굵기/색상으로 구분
- 모바일에서 글자가 작으면 사용자는 읽지 않습니다.
- 특히 혜택, 요금, 주의사항은 가독성이 중요합니다.
✅ 14. Spacing과 터치 영역
- 모바일에서는 간격과 터치 영역이 매우 중요합니다.
- 버튼이나 링크가 너무 붙어 있으면 오작동이 발생합니다.
➕ 14-1. 터치 영역 기준
주요 버튼:
높이 44px 이상 권장
아이콘 버튼:
터치 영역 40px 이상 확보
버튼 간격:
너무 붙이지 않기
➕ 14-2. 나쁜 예시
삭제 버튼과 저장 버튼이 붙어 있음
작은 텍스트 링크만 클릭 가능
체크박스 터치 영역이 너무 작음
드롭다운 옵션 간격이 좁음
➕ 14-3. 좋은 예시
주요 버튼은 전체 너비 사용
위험 버튼은 보조 위치에 배치
아이콘 버튼에도 충분한 padding
폼 필드 간격 명확히 확보
- 모바일 UX는 손가락으로 누르는 환경을 기준으로 봐야 합니다.
- 마우스 기준으로만 만들면 실사용성이 떨어집니다.
✅ 15. 접근성이란 무엇인가?
- 접근성(Accessibility, a11y)은 다양한 사용자가 서비스를 사용할 수 있도록 만드는 기준입니다.
- 시각, 청각, 운동 능력, 인지 환경이 다른 사용자뿐 아니라, 키보드만 쓰는 사용자, 작은 화면 사용자, 일시적으로 불편한 상황의 사용자에게도 도움이 됩니다.
- 접근성은 별도의 고급 기능이 아니라 좋은 UI의 기본입니다.
좋은 접근성:
라벨이 명확함
키보드로 조작 가능
포커스가 보임
에러 메시지가 연결됨
버튼 역할이 명확함
색상만으로 정보를 전달하지 않음
➕ 15-1. 접근성이 중요한 이유
- UI가 더 명확해집니다.
- 폼 사용성이 좋아집니다.
- 키보드 조작이 가능해집니다.
- 에러 상황을 더 잘 전달할 수 있습니다.
- 검색엔진과 브라우저 기본 동작에도 긍정적입니다.
✅ 16. Semantic HTML
- 접근성의 시작은 올바른 HTML 태그를 사용하는 것입니다.
- 모든 것을
div로 만들면 스크린리더와 키보드 사용성이 떨어집니다.
➕ 16-1. 태그 기준
| 용도 | 권장 태그 |
|---|
| 버튼 동작 | button |
| 링크 이동 | a |
| 폼 라벨 | label |
| 입력 | input, select, textarea |
| 제목 | h1 ~ h6 |
| 주요 영역 | main, section, nav, header |
| 표 데이터 | table, thead, tbody, th, td |
➕ 16-2. 나쁜 예시
<div onClick={handleSubmit}>
저장
</div>
➕ 16-3. 좋은 예시
<button type="button" onClick={handleSubmit}>
저장
</button>
- 버튼은 버튼 태그를 쓰는 것이 가장 좋습니다.
- CSS로 div를 버튼처럼 꾸미는 것은 피해야 합니다.
- 폼 접근성에서 가장 기본은 label과 input을 연결하는 것입니다.
➕ 17-1. 좋은 예시
<label htmlFor="phone">전화번호</label>
<input id="phone" type="tel" />
<label htmlFor="consult-phone">전화번호</label>
<input
id="consult-phone"
type="tel"
inputMode="numeric"
{...form.register('phone')}
/>
- label을 클릭해도 input에 포커스가 가야 합니다.
- placeholder만 label처럼 쓰는 것은 좋지 않습니다.
✅ 18. 포커스 관리
- 키보드 사용자는 Tab 키로 화면을 이동합니다.
- 모달, 드롭다운, 폼 에러에서는 포커스 관리가 중요합니다.
➕ 18-1. 기본 기준
포커스가 눈에 보여야 함
Tab 순서가 자연스러워야 함
모달 열리면 모달 내부로 포커스 이동
모달 닫히면 원래 버튼으로 포커스 복귀
에러 발생 시 첫 번째 에러 필드로 이동 고려
➕ 18-2. 나쁜 포커스 처리
outline 제거
모달 뒤쪽 요소로 Tab 이동 가능
드롭다운이 열렸는데 키보드로 선택 불가
닫기 버튼에 접근 불가
outline: none을 무조건 적용하면 키보드 사용자가 현재 위치를 알 수 없습니다.
- 포커스 스타일은 숨기지 말고 디자인에 맞게 다듬어야 합니다.
✅ 19. aria 속성 기본
- ARIA는 HTML 의미를 보완하는 속성입니다.
- 하지만 기본 HTML 태그를 제대로 쓰는 것이 먼저입니다.
➕ 19-1. 에러 메시지 연결
<input
id="phone"
aria-invalid={!!errors.phone}
aria-describedby={errors.phone ? 'phone-error' : undefined}
/>
{errors.phone && (
<p id="phone-error" role="alert">
{errors.phone.message}
</p>
)}
➕ 19-2. 로딩 상태
<div role="status" aria-live="polite">
데이터를 불러오는 중입니다.
</div>
➕ 19-3. 버튼 처리 중
<button type="submit" disabled={isPending} aria-busy={isPending}>
{isPending ? '저장 중...' : '저장'}
</button>
- ARIA를 과하게 쓰기보다 필요한 곳에 정확히 쓰는 것이 좋습니다.
- 잘못된 ARIA는 없는 것보다 더 혼란스러울 수 있습니다.
✅ 20. 색상만으로 정보 전달하지 않기
- 상태를 색상만으로 구분하면 일부 사용자는 의미를 알기 어렵습니다.
- 관리자 테이블의 상태 배지는 색상과 텍스트를 함께 써야 합니다.
➕ 20-1. 나쁜 예시
빨간 점
노란 점
초록 점
- 색상만 보면 무엇을 의미하는지 알기 어렵습니다.
➕ 20-2. 좋은 예시
[대기]
[상담중]
[완료]
[취소]
[실패]
- 색상은 보조 정보이고, 텍스트가 기본 정보입니다.
- 실패/주의/완료 상태는 반드시 문구로도 표현해야 합니다.
✅ 21. 대비와 가독성
- 글자와 배경의 대비가 낮으면 읽기 어렵습니다.
- 특히 모바일 야외 환경, 밝은 화면, 작은 폰트에서는 대비가 중요합니다.
➕ 21-1. 주의할 UI
회색 배경 위 연한 회색 글자
배너 이미지 위 작은 흰색 글자
버튼 안 낮은 대비 텍스트
비활성화 상태와 일반 상태 구분 부족
상태 Badge 텍스트 대비 부족
➕ 21-2. 실무 기준
본문 텍스트는 충분히 진하게
보조 설명은 너무 연하지 않게
배너 위 텍스트는 그림자/오버레이 활용
중요 CTA는 배경과 명확히 구분
- 예쁜 것보다 읽히는 것이 먼저입니다.
- 휴대폰 판매 페이지는 가격, 지원금, 혜택이 명확히 보여야 합니다.
✅ 22. 접근 가능한 Modal
- 모달은 접근성 문제가 자주 생기는 컴포넌트입니다.
- 열림/닫힘, 포커스 이동, 배경 스크롤 방지, ESC 닫기, 닫기 버튼이 필요합니다.
➕ 22-1. Modal 접근성 기준
role="dialog"
aria-modal="true"
title과 연결
닫기 버튼 제공
ESC 닫기
포커스 trap
닫힌 후 원래 버튼으로 포커스 복귀
배경 스크롤 방지
➕ 22-2. ConfirmDialog 기준
작업 결과를 명확히 설명
취소 버튼 제공
위험 작업 버튼은 명확한 문구
Enter/Escape 동작 주의
- 삭제/상태 변경 confirm은 특히 조작 실수를 막아야 합니다.
- 버튼 문구는 “확인”보다 “삭제하기”, “완료 처리”처럼 구체적으로 쓰는 것이 좋습니다.
✅ 23. 반응형과 접근성 테스트 방법
- 반응형과 접근성은 직접 확인해야 합니다.
- 코드만 봐서는 버튼 크기, 줄바꿈, 포커스 이동, 모달 스크롤 문제를 놓치기 쉽습니다.
➕ 23-1. 브라우저에서 확인할 것
Chrome DevTools 모바일 뷰
iPhone 크기
iPad 크기
좁은 데스크탑
가로/세로 전환
긴 텍스트 입력
빈 데이터/에러 데이터
➕ 23-2. 키보드 테스트
Tab으로 모든 버튼 접근 가능?
Enter/Space로 버튼 동작?
ESC로 모달 닫힘?
포커스 위치가 보임?
드롭다운/모달에서 포커스가 튀지 않음?
➕ 23-3. 실제 모바일 테스트
상담 신청 버튼 누르기 쉬운가?
전화번호 입력 시 숫자 키패드가 뜨는가?
모달이 화면 밖으로 잘리지 않는가?
하단 CTA가 콘텐츠를 가리지 않는가?
이미지가 깨지거나 너무 작지 않은가?
- DevTools만 믿지 말고 실제 휴대폰에서도 확인하는 것이 좋습니다.
- 특히 상담 신청 흐름은 실제 모바일에서 반드시 눌러봐야 합니다.
✅ 24. 고객 화면 반응형 체크리스트
- 모바일 첫 화면에서 상품명, 혜택, CTA가 보이는가?
- 상담 신청 버튼이 찾기 쉬운가?
- Sticky CTA가 콘텐츠를 가리지 않는가?
- 전화번호 입력 시 숫자 키패드가 뜨는가?
- 상담 신청 모달이 모바일에서 잘리지 않는가?
- 배너 이미지의 핵심 문구가 모바일에서 읽히는가?
- 상품 이미지가 비율 깨짐 없이 보이는가?
- 리뷰/FAQ/상세 정보가 너무 길게 늘어지지 않는가?
- 버튼 높이와 터치 영역이 충분한가?
- 에러/완료 메시지가 고객이 이해하기 쉬운가?
✅ 25. 관리자 화면 반응형 체크리스트
- 모바일에서 관리자 메뉴를 열고 닫을 수 있는가?
- 테이블 핵심 정보가 모바일에서도 확인되는가?
- 너무 많은 컬럼이 한 화면에 억지로 들어가지 않는가?
- 검색/필터 영역이 모바일에서 세로로 자연스럽게 배치되는가?
- 상태 변경/상세 보기 버튼이 터치하기 쉬운가?
- 대량 작업 UI가 모바일에서 오작동하지 않는가?
- 상세 모달이 모바일에서 스크롤 가능한가?
- 페이지네이션 버튼이 너무 작지 않은가?
- 권한 없음/에러/빈 상태 메시지가 깨지지 않는가?
- 엑셀 다운로드 같은 위험 작업에 Confirm이 제대로 보이는가?
✅ 26. 접근성 체크리스트
- 버튼은
button, 링크는 a를 사용하는가?
- input에 label이 연결되어 있는가?
- placeholder만 label처럼 쓰고 있지 않은가?
- 에러 메시지가 필드와 연결되어 있는가?
- 포커스 스타일이 보이는가?
- Tab 순서가 자연스러운가?
- 모달에서 포커스가 배경으로 빠지지 않는가?
- ESC 또는 닫기 버튼으로 모달을 닫을 수 있는가?
- 색상만으로 상태를 구분하지 않는가?
- 로딩/에러 상태에 적절한 role/aria 속성이 있는가?
- 텍스트와 배경 대비가 충분한가?
- 아이콘 버튼에 접근 가능한 이름이 있는가?
✅ 27. AI를 활용해 반응형/접근성을 점검할 때 질문법
- AI에게 반응형과 접근성을 점검시킬 때는 화면 목적, 주요 사용자, 모바일에서 반드시 가능한 행동, 폼/모달/테이블 구조를 함께 알려줘야 합니다.
➕ 27-1. 좋은 질문 예시
React 기반 온라인 휴대폰 판매몰의 상품 상세 페이지와 상담 신청 모달을 반응형/접근성 기준으로 점검하고 싶어.
상황:
1. 고객 대부분은 모바일에서 상품을 확인하고 상담 신청을 함
2. 상품 상세에는 상품 이미지, 상품명, 출고가, 지원금, 요금제, 혜택 안내, 리뷰, FAQ가 있음
3. 상담 신청 모달에는 이름, 전화번호, 상품 선택 값이 있음
4. 모바일에서는 상담 신청 버튼을 하단 Sticky CTA로 보여주고 싶음
5. 전화번호 입력 시 숫자 키패드가 떠야 함
6. 모달은 모바일에서 바텀시트 또는 전체 화면에 가깝게 보여도 됨
7. 에러 메시지는 필드 아래 표시하고, 성공 시 완료 안내를 보여줌
8. 접근성상 label, focus, aria-invalid, role="alert"를 챙기고 싶음
요청:
- 모바일/태블릿/PC 레이아웃 기준
- Sticky CTA 설계
- 상담 신청 모달 모바일 UX
- input type과 터치 영역 기준
- 이미지/배너 반응형 기준
- 접근성 체크리스트
- 자주 생기는 UX 문제
- 개선 우선순위
를 실무 기준으로 정리해줘.
➕ 27-2. AI 답변 검증 기준
- PC 화면을 단순 축소하는 방식으로 제안하지 않는가?
- 모바일에서 핵심 CTA를 우선 배치하는가?
- 폼 input type, 터치 영역, 버튼 크기를 고려하는가?
- 모달의 모바일 대응을 설명하는가?
- 테이블 모바일 대응 방식을 제안하는가?
- semantic HTML, label, focus, aria를 언급하는가?
- 색상만으로 상태를 전달하지 말라고 하는가?
- 고객 화면과 관리자 화면의 목적 차이를 구분하는가?
📌 요약
- 반응형 레이아웃은 화면 크기에 따라 UI를 자연스럽게 바꾸는 설계이며, 단순히 PC 화면을 줄여 보여주는 것이 아닙니다.
- 고객 화면은 모바일 사용 비중이 높기 때문에 상품명, 혜택, 월 예상 요금, 상담 신청 버튼 같은 핵심 정보를 먼저 보여줘야 합니다.
- 모바일에서는 Sticky CTA가 전환에 도움이 되지만, 콘텐츠를 가리지 않도록 safe-area와 하단 여백을 고려해야 합니다.
- 상담 신청 폼은 입력 필드를 최소화하고, 전화번호 입력에는
type="tel", inputMode="numeric"을 적용해 모바일 입력을 편하게 해야 합니다.
- PC에서는 중앙 모달이 자연스럽지만, 모바일에서는 바텀시트나 전체 화면에 가까운 모달이 더 적합할 수 있습니다.
- 관리자 테이블은 모바일에서 모든 컬럼을 억지로 보여주기보다 핵심 정보만 카드형으로 보여주거나 가로 스크롤을 허용하는 방식이 좋습니다.
- 접근성은 별도 고급 기능이 아니라 좋은 UI의 기본이며, semantic HTML, label 연결, 포커스 관리, 에러 메시지 연결이 중요합니다.
- 버튼은
button, 링크는 a, 표 데이터는 table을 사용하는 식으로 HTML 의미를 맞춰야 합니다.
- 상태 배지는 색상만으로 구분하지 말고 “대기”, “완료”, “실패”처럼 텍스트를 함께 보여줘야 합니다.
- 반응형과 접근성은 코드만 보고 끝내지 말고 DevTools, 키보드, 실제 모바일 기기에서 직접 확인해야 합니다.