Sketch 2026.3 Stacks 사용법: 레이아웃 개편 가이드

Stacks는 내부 항목의 크기나 개수가 변할 때 효과가 큽니다. 제목이 한 줄에서 두 줄로 바뀌거나, 버튼 라벨이 길어지거나, 목록에 항목이 추가되는 카드가 대표적입니다. 반대로 고정된 장식 이미지나 한 번만 납품하는 포스터형 화면은 수동 배치가 더 예측 가능할 수 있습니다.

Sketch 2026.3에는 상대 크기, 최소 크기, 최대 크기, 음수 간격, 겹침 순서, 테두리 계산과 관련된 설정이 추가되었습니다. 세부 동작은 Florence의 Stacks 기능 설명과 공식 도움말을 함께 확인해야 합니다.

새 파일에서 바로 적용해도 되나요?

새 프로젝트라면 컴포넌트의 변화 조건을 먼저 적고 적용하시기 바랍니다. “컨테이너가 넓어지면 본문만 늘어난다”, “버튼은 더 작아지지 않는다”처럼 결과를 문장으로 정하면 설정을 검수하기 쉽습니다. 기존 파일은 원본을 덮어쓰지 말고 복사본 또는 별도 버전으로 시작해야 합니다. 파일이 정상적으로 열렸다는 사실은 레이아웃 검수가 끝났다는 뜻이 아닙니다.

카드 안에서 제목과 설명은 내용에 따라 늘어날 수 있습니다. 이때 콘텐츠에 맞춰 크기가 변하는 영역과 남은 공간을 채우는 영역을 분리해야 합니다. 작업 버튼까지 같은 방식으로 늘리면 짧은 카드에서는 빈 공간이 커지고, 긴 카드에서는 버튼 위치가 밀릴 수 있습니다.

최대 너비는 긴 문장이 지나치게 넓어지는 것을 막는 데 사용합니다. 최소 크기는 버튼이나 태그가 눌려 읽기 어려워지는 상황을 막는 데 유용합니다. 최소와 최대 크기는 임의의 화면 크기를 보장하는 장치가 아니라, 허용할 범위를 정하는 제한선입니다.

Sketch 2026.3의 최소와 최대 크기는 어떻게 설정하나요?

먼저 크기가 변해야 하는 카드 내부 항목을 선택합니다. Stacks 설정에서 해당 항목이 콘텐츠에 맞춰 변할지, 남은 공간을 채울지 정한 뒤 최소 또는 최대 제한을 추가합니다. 카드 전체에 같은 제한을 걸기보다 제목, 설명, 조작 요소의 역할을 나누는 편이 안전합니다. 설정 뒤에는 다음 상태를 각각 확인합니다.

• 짧은 제목과 짧은 설명
• 줄바꿈이 생기는 긴 제목과 설명
• 이미지가 빠진 카드
• 버튼 라벨이 길어진 카드
• 목록 항목이 추가된 카드

이 검수는 이상적인 샘플 한 장만 보는 방식보다 실제 컴포넌트의 실패 지점을 빨리 찾습니다.

내비게이션 바에서는 로고, 아이콘, 버튼처럼 크기를 유지해야 하는 항목이 있습니다. 검색창이나 링크 묶음처럼 남은 공간을 사용할 항목도 있습니다. 모든 항목을 상대 크기로 설정하면 컨테이너가 좁아질 때 텍스트와 버튼이 함께 눌릴 수 있습니다.

공식 Stacks 문서에서 설명하는 상대 크기는 부모 영역에 따라 항목이 변하도록 하는 설정입니다. 어떤 화면에서도 같은 균형을 자동으로 보장하는 백분율 규칙은 아닙니다. 고정해야 할 항목은 고정 크기로 두고, 나머지 공간을 사용할 항목만 채우기 방식으로 분리하시기 바랍니다.

Sketch Stacks로 구성 요소의 너비를 컨테이너에 맞춰 바꾸려면 어떻게 하나요?

부모 컨테이너의 너비를 바꾸는 테스트부터 시작합니다. 좁은 상태에서는 링크가 잘리는지, 버튼이 겹치는지, 로고와 조작 요소의 간격이 유지되는지 확인합니다. 넓은 상태에서는 빈 공간이 특정 항목에 과도하게 몰리지 않는지 봅니다.

검수 순서는 다음과 같습니다.

• 로고와 아이콘을 고정 영역으로 지정합니다.
• 검색창 또는 링크 묶음에 남은 공간 사용을 지정합니다.
• 버튼 그룹은 내부 항목의 최소 크기를 정합니다.
• 컨테이너 너비를 여러 상태로 바꿉니다.
• 텍스트 잘림, 버튼 밀집, 수직 정렬을 기록합니다.

문제 발생 시 전체 Stacks를 다시 만드는 대신 영향을 받은 항목의 크기 규칙부터 되돌리는 것이 수정 범위를 줄입니다.

음수 간격은 아바타를 겹쳐 놓거나, 태그를 서로 붙여 표현하거나, 장식 카드가 일부 포개지는 구성에 알맞습니다. 하지만 시각적으로 겹치는 것과 클릭할 수 있는 영역은 서로 다릅니다. 앞에 보이는 아바타가 뒤의 클릭 영역을 가릴 수도 있습니다.

Sketch 2026.3의 겹침 순서 설정은 어떤 항목이 앞에 표시되는지에 영향을 줍니다. Stacks 기능 설명의 겹침 관련 안내를 확인한 뒤, 원형 아바타와 배지를 실제 순서로 배치하시기 바랍니다.

음수 간격을 적용하면 바로 개발에 넘겨도 되나요?

아닙니다. 프로토타입에서 앞뒤 가림이 의도대로 보이는지 확인해야 합니다. 내보낸 이미지에서도 경계가 잘리지 않는지 살펴야 합니다. 개발 표시에서는 시각적 범위와 터치 또는 클릭 범위를 따로 설명해야 합니다. 특히 마지막 항목이 앞에 오도록 설정하면 디자인 파일과 결과 화면의 읽는 순서가 달라질 수 있습니다.

입력창, 안내 상자, 테두리 버튼은 선의 위치 때문에 간격이 어긋나기 쉽습니다. 레이어의 실제 크기와 테두리가 차지하는 레이아웃 범위를 같은 것으로 보면 내부 여백과 형제 항목 사이 간격이 달라질 수 있습니다.

Sketch 공식 안내에는 테두리를 바깥쪽으로 계산할지, 가운데를 기준으로 계산할지와 관련된 설정이 설명되어 있습니다. 공식 테두리 레이아웃 안내를 기준으로 컴포넌트의 시각적 외곽선과 배치 기준을 구분하시기 바랍니다.

정상 입력 상태만 확인하면 부족합니다. 다음 상태를 같은 크기 규칙으로 비교해야 합니다.

• 기본 입력창
• 오류 문구가 표시된 입력창
• 비활성화된 입력창
• 포커스 테두리가 추가된 입력창
• 테두리 버튼의 짧은 라벨과 긴 라벨

오류 문구가 나타났을 때 다음 필드가 밀리는 것이 의도인지, 고정된 폼 높이가 필요한지 먼저 결정해야 합니다. 자동 배치가 항상 좋은 결과를 내는 것은 아닙니다.

기존 Stacks 레이아웃이 Sketch 2026.3을 열었다고 해서 새로운 동작으로 자동 최적화된다고 단정하면 안 됩니다. 특정 파일에서 어떤 구성 요소가 달라지는지는 파일 구조와 설정에 따라 달라질 수 있습니다. 이상이 보이면 영향을 받은 컴포넌트를 찾고, 해당 영역만 다시 배치한 뒤 원본과 비교하시기 바랍니다.

오래된 Sketch 파일을 새 버전에서 연 뒤 배치가 달라지면 어떻게 하나요?

먼저 복사본에서 문제가 난 컴포넌트와 정상 컴포넌트를 나란히 비교합니다. 텍스트 길이, 부모 너비, 테두리 계산, 겹침 순서를 차례로 확인합니다. 전체 라이브러리를 한 번에 저장하지 말고 대표 상태를 검수한 뒤 범위를 넓혀야 합니다.

윈도우 팀의 역할도 구분해야 합니다. 브라우저에서는 문서 보기, 댓글, 검사와 같은 협업을 할 수 있지만, 맥 앱의 전체 편집 능력과 같다고 보면 안 됩니다. Workspace 편집자와 보기 권한 안내와 문서 권한 설명을 기준으로 원본 편집 담당자를 정하시기 바랍니다. 문서를 여는 조건은 공식 문서 열기 안내에서도 확인할 수 있습니다.

• [ ] 원본 파일을 복사했습니까?
• [ ] 내용이 변하는 컴포넌트만 골랐습니까?
• [ ] 최소 크기와 최대 크기의 목적을 문장으로 적었습니까?
• [ ] 고정 영역과 남은 공간을 채울 영역을 나눴습니까?
• [ ] 짧은 문구와 긴 문구를 모두 넣었습니까?
• [ ] 이미지가 없는 상태를 확인했습니까?
• [ ] 음수 간격의 앞뒤 순서를 확인했습니까?
• [ ] 프로토타입과 내보낸 이미지에서 겹침을 확인했습니까?
• [ ] 폼의 기본, 오류, 비활성화 상태를 비교했습니까?
• [ ] 윈도우 사용자가 맡을 수 있는 작업과 맥 앱 작업을 구분했습니까?

작업 빈도에 따른 선택도 달라집니다. 보기와 댓글 중심이면 웹 협업으로 충분할 수 있습니다. 가끔 원본을 고치는 팀은 프로젝트 단위의 원격 맥을 검토할 수 있습니다. 매일 대형 컴포넌트 라이브러리를 유지한다면 안정적인 맥 편집 환경을 따로 두는 편이 낫습니다.

윈도우에서 Sketch를 편집하는 환경 선택 가이드와 맥 미니 렌탈 가격 및 사용 조건을 함께 비교하면 역할에 맞는 운영 방식을 정하기 쉽습니다.

현재 윈도우 환경만으로 원본을 수정하려 하면 맥 앱 편집 범위가 제한되고, 파일을 주고받는 단계가 늘어나며, 로컬 대체 프로그램과의 호환성도 별도로 확인해야 합니다. 반대로 원격 맥은 네트워크 지연과 파일 이동 방식, 화면 접속 품질을 검수해야 합니다. 따라서 일시적인 Sketch 2026.3 개편이나 특정 컴포넌트 확인이 목적이라면 MESHLAUNCH의 원격 맥을 프로젝트 단위로 사용해 보는 방식이 현실적입니다. 장기간 무거운 작업을 계속하거나 물리 장치 연결이 필요하다면 직접 맥을 마련하는 편이 더 적합합니다. 중요한 것은 대표 컴포넌트 하나를 먼저 시험하고, 결과가 확인된 뒤 환경을 확대하는 순서입니다.