화면 방향

화면 방향은 화면을 어느 쪽을 위로 해서 그리는지를 말합니다. 크게 세로와 가로 둘입니다. 휴대폰을 옆으로 눕히면 운영체제가 화면 방향을 바꿔서 글자와 버튼이 다시 똑바로 보입니다. 이때 앱이 받는 화면의 너비와 높이가 서로 바뀝니다.

상세

책을 읽다가 옆으로 누우면 책도 따라 돌려 듭니다. 그래야 글줄이 다시 눈과 나란해집니다.

화면도 같은 일을 합니다. 화면을 어느 쪽을 위로 해서 그리는지가 화면 방향입니다. 기기를 눕혔을 때 운영체제가 이 방향을 따라 바꾸는 동작은 자동 회전이라고 부릅니다. 자동 회전이 없으면 휴대폰을 눕혔을 때 글자도 함께 옆으로 눕습니다.

화면 방향은 기기 방향과 다른 것입니다. 기기를 실제로 어떻게 들었는지가 기기 방향입니다. 둘은 대개 같지만 갈릴 때가 있습니다. 어떤 경우에 갈리는지는 아래 「기기가 방향을 알아채는 길」에서 봅니다.

이 절은 먼저 화면 방향에 어떤 종류가 있는지 봅니다. 그다음 기기가 방향을 알아채는 길, 방향이 바뀔 때 앱에서 일어나는 일, 웹 페이지가 방향을 정하는 법, 방향을 묶어 두는 방법을 차례로 따라갑니다. 끝에서는 그 대가를 봅니다.

세로 방향과 가로 방향

화면 방향은 크게 둘로 나뉩니다. 긴 변이 위아래로 서면 세로 방향입니다. 긴 변이 옆으로 누우면 가로 방향입니다.

영어로는 세로를 portrait, 가로를 landscape 라고 부릅니다. 인물화는 대개 세로로 길고 풍경화는 가로로 길어서 붙은 이름입니다. 개발 문서와 설정 화면에도 이 두 낱말이 손대지 않은 채로 나옵니다.

운영체제는 대개 이 둘을 다시 넷으로 가릅니다. 기기를 똑바로 든 세로, 거꾸로 뒤집은 세로, 왼쪽으로 눕힌 가로, 오른쪽으로 눕힌 가로입니다. 똑바로 든 상태에서 몇 도를 돌렸는지로 셈하면 0도 · 90도 · 180도 · 270도가 됩니다.

기기가 방향을 알아채는 길

기기를 눕혔을 때 화면 방향이 바뀌기까지는 몇 단계를 거칩니다. 출발점은 기기 안의 센서입니다.

기기 안에는 가속도 센서가 들어 있습니다. 가속도 센서는 기기가 받는 힘의 방향을 재는 부품입니다. 가만히 들고 있을 때 이 센서가 재는 힘은 중력뿐이라서, 어느 변이 땅을 향하는지 알 수 있습니다.

운영체제는 이 값을 보고 화면 방향을 바꿀지 정합니다. 조금 기울인 정도로는 바꾸지 않고 충분히 눕혔을 때 바꿉니다. 손이 살짝 떨릴 때마다 화면이 돌면 쓸 수가 없기 때문입니다.

앞에서 기기 방향과 화면 방향이 갈릴 때가 있다고 했습니다. 하나는 사용자가 회전 잠금을 켰을 때입니다. 회전 잠금은 기기를 눕혀도 화면을 돌리지 말라는 사용자 설정입니다. 누워서 휴대폰을 볼 때 화면이 자꾸 돌지 않게 하려고 켭니다.

다른 하나는 앱이 방향을 묶어 두었을 때입니다. 이 경우는 아래 「방향을 묶어 두는 앱」 소절에서 봅니다.

flowchart TD
    A["가속도 센서가 기울기를 잰다"] --> B{"충분히 눕혔나"}
    B -->|아니오| Z["화면 방향을 그대로 둔다"]
    B -->|예| C{"회전 잠금이 켜졌나"}
    C -->|예| Z
    C -->|아니오| D{"앱이 방향을 묶어 두었나"}
    D -->|예| Z
    D -->|아니오| E["화면 방향을 바꾸고 앱에 알린다"]

방향이 바뀔 때 앱에서 일어나는 일

화면 방향이 바뀌는 순간 앱에도 할 일이 생깁니다. 핵심은 앱이 받는 너비와 높이가 서로 바뀐다는 것입니다.

세로로 들었을 때 좁고 길던 화면이 가로로 들면 넓고 낮아집니다. 같은 배치를 손대지 않고 쓰면 버튼이 옆으로 늘어지거나 아래쪽이 잘립니다. 그래서 앱은 새 크기에 맞춰 배치를 다시 고릅니다.

화면 크기나 방향, 언어처럼 앱이 도는 환경이 바뀌는 일이 구성 변경입니다. 운영체제는 화면 방향을 바꾼 뒤 앱에 구성이 바뀌었다고 알립니다. 앱은 이 알림을 받고 배치를 다시 고릅니다.

운영체제가 앱 화면을 아예 다시 만들기도 합니다. 안드로이드가 그렇습니다. 안드로이드는 기본 설정에서 앱 화면 하나(액티비티)를 없앴다가 새 방향으로 다시 만듭니다. 그러면 그 화면을 처음 띄울 때 도는 코드도 처음부터 다시 돕니다.

이때 화면에 들고 있던 값이 함께 사라질 수 있습니다. 입력하던 글이 기기를 돌리자마자 지워지면 사용자는 앱이 고장 났다고 느낍니다. 그래서 앱은 바뀌기 직전에 지금 상태를 적어 두고, 다시 만들어진 뒤에 되살립니다. 이렇게 상태를 챙기는 일이 상태 보존입니다.

아래 그림은 화면을 다시 만드는 운영체제에서 벌어지는 순서입니다. 화면을 다시 만드는 것은 운영체제이고, 배치를 다시 고르는 것은 앱입니다.

sequenceDiagram
    participant 사용자
    participant 운영체제
    participant 앱
    Note over 운영체제,앱: 화면을 다시 만드는 운영체제의 경우
    사용자->>운영체제: 기기를 가로로 눕힌다
    운영체제->>앱: 구성이 바뀐다고 알린다
    앱->>앱: 입력하던 글을 적어 둔다
    운영체제->>앱: 화면을 없애고 다시 만든다
    앱->>앱: 가로 배치를 고르고 글을 되살린다

웹 페이지가 보는 방향

브라우저 안의 웹 페이지는 방향을 조금 다르게 압니다.

웹 페이지는 기기를 어떻게 들었는지를 직접 보지 않습니다. 대신 페이지가 그려지는 창의 너비와 높이를 견줍니다. 창의 높이가 너비보다 크거나 같으면 세로 방향이고, 그 밖에는 가로 방향입니다. 페이지가 그려지는 이 창이 뷰포트입니다.

웹 페이지의 글꼴과 색, 배치는 CSS(Cascading Style Sheets, 캐스케이딩 스타일 시트)라는 스타일 언어로 정합니다.

화면 조건에 따라 다른 스타일을 고르는 CSS 문법이 미디어 쿼리입니다. 조건은 괄호 안에 적습니다. 방향 조건은 (orientation: portrait) 처럼 쓰고, portrait 대신 landscape 를 적으면 가로 조건이 됩니다.

자바스크립트에서도 같은 조건을 물어볼 수 있습니다. 브라우저가 주는 matchMedia 함수에 조건 문자열을 넘기면, 지금 창이 그 조건에 맞는지 알려 줍니다. 아래는 창의 높이가 너비보다 클 때의 값입니다.

const q = "(orientation: portrait)";
matchMedia(q).matches   // true

창이 가로로 넓다면 같은 줄이 false 를 냅니다.

창 크기로 정하기 때문에 기기 방향과 어긋날 때가 있습니다. 가로로 든 태블릿에서 분할 화면으로 브라우저를 절반만 띄우면, 창이 세로로 길어져서 세로 방향으로 잡힙니다. 이것은 고장이 아니라 바른 동작입니다. 페이지가 쓸 수 있는 공간은 그 세로로 긴 창이기 때문입니다.

같은 까닭으로 배치를 고를 때는 방향 조건보다 min-width 같은 너비 조건을 더 흔히 겁니다. 세로냐 가로냐보다 창이 얼마나 넓은지가 배치를 더 직접 정하기 때문입니다.

방향을 묶어 두는 앱

앱이 스스로 방향을 하나로 묶기도 합니다. 앱 설정에 허용할 방향을 적어 두는 식입니다. 그러면 기기를 돌려도 그 앱의 화면은 돌지 않습니다.

묶는 데는 까닭이 있습니다. 넓은 화면이 꼭 필요한 게임은 가로로 묶습니다. 한 손으로 넘기는 목록이 중심인 앱은 세로로 묶습니다. 화면 배치를 한 벌만 만들고 시험하면 되니 개발자의 품도 줄어듭니다.

대신 기기를 돌릴 수 없는 사용자가 곤란해집니다. 휠체어나 책상에 기기를 한 방향으로 고정해 쓰는 사람이 그렇습니다.

이 문제는 웹 접근성 기준에도 들어 있습니다. 웹 접근성은 장애가 있는 사람도 웹 콘텐츠를 쓸 수 있게 만드는 일입니다. 그 기준이 WCAG(Web Content Accessibility Guidelines, 웹 콘텐츠 접근성 지침)입니다. WCAG 는 그 방향이 꼭 필요할 때가 아니면 화면을 한 방향에 묶지 말라고 합니다.

WCAG 는 이름대로 웹 콘텐츠의 기준입니다. 그래도 기기를 고정해 쓰는 사용자가 곤란해지는 것은 앱에서도 같습니다.

방향을 챙기는 데 드는 비용

화면 방향을 챙기면 할 일이 늘어납니다. 대부분 개발자가 지는 짐입니다.

먼저 확인할 화면 모양이 두 벌이 됩니다. 세로에서 멀쩡하던 화면이 가로에서는 아래가 잘리기 쉽습니다. 가로로 든 휴대폰에서 가상 키보드가 올라오면 남는 높이가 아주 좁아지기 때문입니다.

다음으로 돌리는 순간의 버그를 시험해야 합니다. 입력하던 글이나 스크롤 위치가 사라지지 않는지 봅니다. 이런 버그는 기기를 돌려 봐야만 드러나서 놓치기 쉽습니다.

진행 중이던 요청이 두 번 나가지 않는지도 봐야 합니다. 앞에서 본 대로 화면을 다시 만들면, 화면을 띄울 때 요청을 보내는 코드도 다시 돕니다. 첫 요청이 아직 안 끝났으면 같은 요청이 한 번 더 나갑니다.

관련 항목

화면 방향을 알아채는 센서와 설정

가속도 센서 · 자이로스코프 · 센서 · 회전 잠금

화면 방향이 바뀔 때 앱에 일어나는 변화

구성 변경 · 상태 보존 · 액티비티 · 뷰모델 · 생명주기

화면 방향에 맞추는 배치 기법

반응형 레이아웃 · 적응형 레이아웃 · 미디어 쿼리 · 뷰포트 · 화면비 · 화면 밀도

화면 방향처럼 앱의 창 크기를 바꾸는 사건

폴더블 · 접힘 상태 · 분할 화면 · 멀티 윈도 · 가상 키보드

화면 방향 고정을 막는 접근성 기준

웹 접근성 · 접근성 · WCAG · 보조 기술

화면 방향이 속하는 상위 분야

모바일 개발 · 모바일 운영체제 · 프론트엔드 · 디스플레이