[UI/반응형] 앱 화면 최적화를 위한 문서와 테스트 체크리스트 작성 방법

앱 화면은 개발 기기 하나에서만 잘 보인다고 끝나지 않습니다. 작은 모바일, 큰 모바일, 태블릿, 가로 모드, 세로 모드에서 같은 화면이 다르게 보일 수 있습니다. 버튼이 화면 밖으로 밀리거나, 리스트 높이가 부족하거나, 지도와 상세 영역이 겹치는 문제도 생길 수 있습니다.

화면 최적화는 눈으로 보면 바로 알 수 있는 문제처럼 느껴지지만, 확인 기준을 기록하지 않으면 나중에 다시 검증하기 어렵습니다. 특히 profile이 많거나 화면 종류가 많아지면 어떤 기기에서 무엇을 확인했는지 금방 헷갈릴 수 있습니다.\ 이번 글에서는 앱 화면 최적화를 할 때 문서와 테스트 체크리스트를 어떻게 만들면 좋은지 정리해보겠습니다.

왜 화면 체크리스트가 필요한가

반응형 UI 문제는 바로 눈에 보이는 경우가 많습니다. 그래서 오히려 기록을 남기지 않고 넘어가기 쉽습니다. 다만 화면이 많아질수록 기억에 의존한 확인은 금방 한계가 생깁니다.

예를 들어 홈 화면은 작은 모바일에서 정상인데, 상세 화면은 태블릿 가로 모드에서 여백이 과하게 생길 수 있습니다. 지도 화면은 세로 모드에서는 괜찮지만, 가로 모드에서 목록과 겹칠 수도 있습니다. 이런 문제는 확인 조건을 적어두지 않으면 다시 재현하기 어렵습니다.

문제	원인	체크 기준
버튼 잘림	고정 높이/너비	작은 화면 캡처
태블릿 여백 과다	모바일 기준 레이아웃만 적용	breakpoint 확인
가로 모드 깨짐	orientation 미고려	landscape smoke
텍스트 겹침	긴 문자열 테스트 부족	긴 제목/다국어 샘플
지도 영역 오류	높이 계산 고정	목록+지도 조합 확인

화면 체크리스트는 단순히 확인했다는 표시를 남기는 문서가 아닙니다. 어떤 조건에서 확인했는지, 어떤 상태는 아직 남아 있는지 추적하기 위한 기준표로 보는 편이 좋습니다.

체크리스트에 넣을 항목

화면 최적화 체크리스트는 너무 추상적이면 도움이 되지 않습니다. 반응형 확인이라고만 쓰기보다 어떤 화면을 어떤 조건에서 봤는지 적어야 합니다.

항목	확인 내용
기기 크기	small phone, normal phone, tablet
방향	portrait, landscape
주요 화면	홈, 목록, 상세, 지도, 설정
데이터 상태	로딩, 성공, 빈 데이터, 에러
텍스트 길이	짧은 제목, 긴 제목, 줄바꿈
입력 요소	키보드 표시 시 가려짐 여부
캡처 근거	실제 캡처 파일 또는 확인 메모

막상 체크리스트를 만들어보면 정상 화면만으로는 부족하다는 점이 보입니다. 로딩 중 화면, 빈 데이터 화면, 에러 화면처럼 예외 상태도 함께 확인해야 실제 사용자 환경에 더 가까워집니다.

breakpoint 기준 잡기

React Native나 Android 앱에서 정확한 breakpoint 값은 프로젝트마다 다를 수 있습니다. 중요한 것은 숫자 자체보다 왜 이 기준에서 레이아웃을 바꾸는지입니다.

type ScreenClass = 'compact' | 'medium' | 'expanded';

export function getScreenClass(width: number): ScreenClass {
  if (width < 600) return 'compact';
  if (width < 900) return 'medium';
  return 'expanded';
}

예를 들어 compact에서는 단일 컬럼, medium에서는 카드 간격 확대, expanded에서는 목록과 상세를 나란히 배치하는 식으로 규칙을 만들 수 있습니다.

감으로 기준을 잡으면 당장은 빠르게 적용할 수 있습니다. 다만 화면이 늘어나면 왜 600에서 바뀌는지, 왜 900에서 다시 나뉘는지 설명하기 어려워집니다. 그래서 breakpoint 값과 레이아웃 변경 이유를 함께 문서화해두는 편이 좋습니다.

orientation 확인 기준

가로 모드는 단순히 화면이 넓어지는 상태가 아닙니다. 세로 높이가 줄어들기 때문에 하단 버튼, 입력창, 지도 영역, 모달이 잘릴 수 있습니다.

가로 모드에서는 아래 항목을 우선 확인해볼 수 있습니다.

• 상단 헤더가 지나치게 높지 않은지 확인한다.
• 하단 고정 버튼이 콘텐츠를 가리지 않는지 확인한다.
• 모달 높이가 화면보다 커지지 않는지 확인한다.
• 키보드가 입력 필드를 가리지 않는지 확인한다.
• 지도와 목록이 같은 화면에서 겹치지 않는지 확인한다.

가로 모드는 태블릿 대응과도 다르게 봐야 합니다. 태블릿은 넓은 화면을 어떻게 활용할지가 중요하고, 모바일 가로 모드는 줄어든 세로 공간을 어떻게 보장할지가 더 중요해질 수 있습니다.

smoke capture를 남기는 이유

화면 최적화는 말로만 완료했다고 적으면 검증하기 어렵습니다. 대표 화면의 캡처를 남겨두면 나중에 변경 전후를 비교하기 쉽습니다.

다만 실제 캡처를 하지 않았다면 캡처 완료라고 쓰면 안 됩니다. 문서에는 예정, 확인 필요, 캡처 완료, 수정 필요처럼 상태를 나눠두는 편이 안전합니다.

상태	의미
예정	아직 확인 전
확인 필요	기기 또는 데이터 조건 부족
캡처 완료	실제 화면 근거 있음
수정 필요	깨짐 확인됨

실제 캡처가 있으면 화면 수정 후 비교가 훨씬 쉬워집니다. 

profile별 대표 화면 정하기

통합 앱에서는 모든 profile의 모든 화면을 매번 확인하기 어렵습니다. 그래서 profile group별로 대표 화면을 정해두는 방식이 현실적입니다.

profile 유형	우선 확인 화면	주의할 점
지도 중심 앱	홈, 지도, 상세	지도 높이와 상세 영역 겹침 확인
목록 중심 앱	목록, 상세, 검색	긴 제목과 빈 데이터 확인
설정/안내 중심 앱	홈, 안내, 설정	텍스트 길이와 스크롤 확인
입력 중심 앱	폼, 키보드, 제출 결과	키보드 표시 시 입력 필드 가림 확인

대표 화면을 정해두면 체크 범위가 명확해집니다. 모든 화면을 매번 확인하지 못하더라도, 최소한 어떤 화면을 기준으로 회귀를 볼지 정해둘 수 있습니다.

테스트 기준

화면 최적화 체크리스트를 만들었다면 아래 기준을 함께 확인해보는 것이 좋습니다. 문서와 실제 확인 상태가 어긋나지 않는지가 중요합니다.

• 실제 사용자 데이터가 캡처에 노출되지 않는지 확인한다.
• 내부 관리자 화면이 캡처에 포함되지 않는지 확인한다.
• 캡처 전 완료로 표시하지 않았는지 확인한다.
• profile별 대표 화면을 최소 1개 이상 정했는지 확인한다.
• 빈 데이터와 에러 화면도 확인 대상에 포함했는지 확인한다.
• 태블릿과 landscape 기준이 문서화되어 있는지 확인한다.
• 긴 제목, 줄바꿈, 다국어 텍스트 샘플을 확인했는지 확인한다.

자주 하는 실수

1. 본인이 쓰는 기기 한 대에서만 보고 화면 최적화가 끝났다고 판단하는 경우가 있습니다. 개발 기기에서는 정상이어도 작은 화면이나 태블릿에서는 버튼이 잘리거나 여백이 과하게 보일 수 있습니다.

2. 정상 데이터가 있을 때만 화면을 확인하는 경우도 있습니다. 빈 데이터, 긴 제목, 네트워크 실패 화면은 정상 화면보다 더 쉽게 깨질 수 있습니다.

3. 가로 모드를 넓은 화면으로만 보는 경우가 있습니다. 실제로는 세로 높이가 줄어들기 때문에 모달, 키보드, 하단 버튼이 더 먼저 문제가 될 수 있습니다.

4. 확인하지 않은 항목을 완료로 표시하는 경우도 있습니다. 캡처나 확인 메모 없이 완료로 남기면 나중에 회귀가 생겼을 때 기준을 신뢰하기 어렵습니다.

결론

화면 최적화 체크리스트는 디자인 문서라기보다 회귀를 줄이는 개발 문서에 가깝습니다. 기기 크기, 방향, 주요 화면, 데이터 상태, 캡처 근거를 함께 기록해야 나중에 화면을 수정해도 기준이 흔들리지 않습니다.

좋은 체크리스트는 추상적인 확인 문구보다 구체적인 조건을 담고 있어야 합니다. small phone, tablet, portrait, landscape, 로딩, 빈 데이터, 에러 상태처럼 실제로 확인할 수 있는 기준을 적어두면 리뷰와 QA가 훨씬 쉬워집니다.

확인하지 않은 항목은 완료로 표시하지 않는 것이 가장 안전합니다. 화면 최적화는 한 번에 끝나는 작업이 아니라, 변경 전후를 비교하고 근거를 남기면서 조금씩 안정화해가는 과정으로 보는 편이 좋습니다.