임포트한 뒤 Auto Layout이 어긋나는 이유

브라우저에서 나란히 붙어 있던 카드 한 장이 피그마에서 4px 내려가 있습니다. 딱 집어 망가졌다고 할 정도는 아니고요. 무슨 일이 일어난 건지 정리했습니다.

웹 페이지를 피그마로 가져왔습니다. 레이어 패널은 잘 채워졌는데 뭔가 어색해요. 브라우저에서는 나란히 붙어 있던 카드 한 장이 4px쯤 내려가 있고, 가운데 정렬이던 내비게이션이 어중간하게 가운데예요. 딱 집어서 망가졌다고 할 정도는 아닌데, 옆에 띄워 둔 스크린샷하고는 확실히 다릅니다.

이런 경우 범인은 거의 항상 Auto Layout입니다. 붙이면 안 되는 곳에 붙은 거예요. 해결책이 "Auto Layout을 끄자"가 아니기 때문에 이유를 알아둘 값어치가 있습니다. 두 레이아웃 시스템이 진짜로 일치하는 순간과, 도구가 그냥 찍고 있는 순간을 구분하는 게 핵심이거든요.

애초에 맞을 이유가 없는 두 엔진

브라우저는 CSS로 배치합니다. 플렉스박스, 그리드, float, 인라인 흐름, 마진 상쇄, 글자를 제 박스 밖으로 밀어내는 line-height, 플랫폼마다 다른 서브픽셀 반올림까지. 수십 년치 규칙이고 대부분은 한 번쯤 걸리는 예외 상황입니다.

피그마는 Auto Layout으로 배치합니다. 훨씬 작은 시스템이고, 일부러 그렇게 만들었어요. 방향 하나, 간격 하나, 패딩 네 개, 두 축의 정렬, 자식별 grow와 stretch. 이게 거의 전부입니다.

Auto Layout은 플렉스박스를 다시 구현한 게 아닙니다. 자전거와 오토바이가 닮은 정도로 닮았어요. 그래서 변환기가 display: flex를 읽고 layoutMode: "HORIZONTAL"을 넣는 건 하나의 주장을 하는 셈입니다. 이 두 시스템이 모든 자식을 같은 자리에 놓을 것이다라는. 맞을 때도 있어요. 문제는 "거의 맞을" 때가 많다는 거고, 그게 더 나쁩니다.

조용히 어긋나는 지점들

플렉스박스처럼 보이지만 Auto Layout이 재현하지 못하는 경우들입니다.

• 플렉스 아이템의 마진. CSS에서는 자식이 자기 마진을 가질 수 있고, margin-left: auto로 특정 그룹만 오른쪽으로 밀어낼 수도 있습니다. Auto Layout에는 프레임 전체에 적용되는 간격 하나뿐이고 자식별 마진이 아예 없어요.
• space-around와 space-evenly. Auto Layout이 가진 건 SPACE_BETWEEN입니다. 나머지 둘은 남는 공간을 다르게 나누는데, 그걸 재현할 설정이 없습니다.
• align-items: baseline. 크기가 다른 글자들이 같은 기준선에 앉는 배치예요. 제목이나 가격 표시에서 흔하죠. Auto Layout은 박스의 모서리와 중앙으로 맞추지, 기준선으로 맞추지 않습니다.
• 소수점 flex-grow. flex: 1은 layoutGrow: 1로 옮겨집니다. flex: 2나 flex: 0.5는 옮겨갈 곳이 없어요.
• flex-wrap. 줄바꿈된 행은 한 줄짜리 행과 아예 다른 기하 구조이고, 어디서 접히는지는 캡처 시점의 컨테이너 너비에 달려 있습니다.
• 텍스트 재측정. 도구들이 제일 많이 걸리는 부분입니다. 내용에 맞춰 크기가 정해지는 텍스트 레이어는 피그마가 직접 잽니다. 피그마가 가진 폰트로, 피그마가 계산한 크기로요. 그 결과가 브라우저와 1px만 달라도 그 뒤에 있는 형제 요소가 전부 밀립니다.

마지막 항목 때문에 이 문제는 종종 빠진 폰트를 설치한 뒤에야, 혹은 남의 컴퓨터에서만 나타납니다.

그런데도 도구들이 붙이는 이유

Auto Layout 프레임으로 가득한 파일이 절대좌표 사각형으로 가득한 파일보다 좋아 보이니까요. 시연할 때 그럴듯하고, 기능 목록에 한 줄 됩니다. 그리고 흔한 경우에는 실제로 더 좋아요. 간단한 행이나 간격이 일정한 카드 그리드라면 프레임 크기를 바꿔도 제대로 반응하니까요.

문제는 확인해 보지 않고서는 "흔한 경우"와 "간발의 차이로 틀린 경우"를 구분할 수 없다는 점입니다. 그리고 확인하는 건 확인하지 않는 것보다 손이 많이 가고요.

그래서 어떻게 하면 되나

이미 가져온 파일이라면

어긋나 보이는 프레임을 고르고 레이아웃 모드를 없음으로 바꾸세요. 피그마 오른쪽 패널의 레이아웃 항목입니다. 자식들은 지금 위치를 유지하니까, 이미 밀려난 상태라면 그 상태로 고정되는 거지 되돌아오지는 않습니다. 그래서 보통은 고치는 것보다 다시 가져오는 게 낫습니다.

다시 가져오기 전에 하나만 확인하세요. 그 페이지가 쓰던 폰트가 내 컴퓨터에 설치돼 있나요? 폰트가 대체되면 모든 텍스트 레이어가 다시 측정되고, 글자 너비가 틀린 파일은 레이아웃을 아무리 만져도 맞지 않습니다. 어떤 폰트가 없는지는 파일을 열 때 피그마가 알려줍니다.

도구를 고르는 중이라면

두 시스템이 어긋날 때 무엇을 하는지 물어보세요. 답은 세 가지뿐이고 그중 하나만 쓸 만합니다.

1. 플렉스박스가 보이면 전부 Auto Layout을 붙인다. 빠르고, 시연할 때 좋고, 조용히 어긋난 파일을 건네줍니다.
2. 절대 붙이지 않는다. 항상 정확하고 전혀 쓸모없습니다. 정확하지만 편집하기 괴로운 절대좌표 레이어 더미를 받게 되죠.
3. 원본을 재현할 때만 붙인다. 정확하면서 쓸모도 있는데, 도구가 피그마의 동작을 실제로 예측하고 비교해야 합니다.

Snapture는 어떻게 판단하나

세 번째를 택했고, 방식은 한 문단으로 설명될 만큼 단순합니다.

캡처 시점에 이미 모든 요소가 어디 있는지 알고 있습니다. 렌더링된 페이지를 읽었으니 자식마다 브라우저가 계산한 실제 사각형을 가지고 있는 거죠. 레이아웃을 붙이기 전에, 같은 프레임을 피그마 엔진이 어떻게 처리할지 시뮬레이션합니다. 패딩, 간격, 정렬, grow 분배까지 계산해서 자식마다 예상 사각형을 만들어요. 그리고 두 벌을 비교합니다. 모든 자식이 브라우저가 놓은 자리에서 0.5px 이내에 들어오면 레이아웃을 붙입니다. 하나라도 벗어나면 그 프레임은 절대좌표를 그대로 유지합니다.

반대편에도 검사가 하나 더 있습니다. 피그마 플러그인이 레이아웃을 적용한 다음 자식들을 다시 재요. 이번엔 예측이 아니라 진짜 엔진을 상대로요. 같은 0.5px을 넘어 움직인 게 있으면 캡처한 좌표로 되돌립니다. 텍스트 레이어는 임포트 시점에 어떤 시뮬레이션도 예견할 수 없는 방식으로 재측정될 수 있어서 필요한 검사입니다.

실제로는 이런 비율입니다

실제 페이지들에 변환기를 돌려 보면 얼마나 깐깐한지 감이 옵니다. 실측 페이지에 올린 것과 같은 측정 결과입니다.

흥미로운 건 MDN 줄입니다. 253개 노드에 Auto Layout 프레임이 5개면 도구가 실패한 것처럼 보이죠. 제대로 작동한 겁니다. MDN의 본문 레이아웃은 대부분 문서 흐름과 float인데 Auto Layout은 그걸 아예 모델링하지 않아요. 그래서 관문이 거의 전부를 거절하고 정확한 좌표를 유지한 겁니다. 그 페이지에서는 픽셀이 맞고 Auto Layout이 거의 없는 쪽이 옳은 선택이에요.

반대로 Linear는 간격이 균일한 플렉스 행으로 거의 전부가 만들어져 있습니다. 261개 프레임이 비교를 통과했고, 피그마에서 크기를 바꿔도 제대로 반응합니다.

정리하면

임포트한 뒤의 Auto Layout은 뭔가가 검증했을 때만 믿을 수 있습니다. 플렉스박스와 Auto Layout은 변환기를 속일 만큼 닮았고 파일을 밀어낼 만큼 다릅니다. 게다가 그 차이는 눈에 띄게 깨지는 대신 몇 픽셀로 나타나요. 찾는 데 시간이 가장 많이 드는 종류의 오류죠.

어떤 도구가 두 시스템이 어긋날 때 무엇을 하는지 답하지 못한다면, 확인하지 않는다고 보면 됩니다.

English · 한국어 · 日本語 · 简体中文 · 繁體中文 · Español · Português · Français · Deutsch · Русский · Italiano · Bahasa Indonesia