프레이머를 배우기 시작하면 가장 먼저 벽에 부딪히는 게 배리언트입니다. 버튼 하나를 만들었는데 마우스를 올렸을 때 색이 바뀌게 하고 싶고, 눌렀을 때 살짝 작아지게 하고 싶습니다.
이걸 요소마다 따로 만들면 화면이 금방 지저분해집니다. 배리언트는 하나의 컴포넌트 안에 여러 상태를 넣어두고 필요할 때 갈아끼우는 방식입니다. 개념만 잡으면 그다음은 빠릅니다.
프레이머 전문 에이전시가 알려주는 꿀팁 시리즈입니다. 저희가 실제 프로젝트에서 쓰는 방법을 그대로 공개합니다. 검색해도 한글 자료가 잘 안 나오는 것들 위주로 매주 한 편씩 올립니다.
- •1편. 커스텀 마우스 커서 만들기
- •2편. 배리언트로 상태 나누기 (지금 보는 글)
- •3편. 스크롤을 천천히 따라오게 만들기
- •4편. 웹플로우 스크롤 인터랙션 두 가지
30초 요약
- •배리언트는 컴포넌트 하나가 가질 수 있는 여러 상태입니다. 기본, 호버, 클릭처럼요.
- •컴포넌트로 만드는 단축키는 맥 옵션 커맨드 K, 윈도우 컨트롤 알트 K입니다.
- •상태를 이어주는 것은 인터랙션입니다. 레이어를 고르고 L을 누르면 시작됩니다.
- •전환 애니메이션은 직접 만들지 않습니다. 두 상태의 차이를 프레이머가 계산합니다.
- •인터랙션은 기본 배리언트에 걸어두면 나머지가 물려받습니다. 한 번만 설정하면 됩니다.
- •모습이 다르면 배리언트, 내용만 다르면 속성. 이 기준 하나가 파일의 수명을 정합니다.
배리언트가 필요한 이유
버튼 하나를 예로 들겠습니다. 평소 모습, 마우스를 올렸을 때, 누르고 있을 때. 최소 세 가지 모습이 필요합니다. 여기에 비활성 상태까지 더하면 네 가지입니다.
배리언트를 모르면 이 네 개를 캔버스에 나란히 그려두고 필요할 때마다 복사합니다. 문제는 나중에 생깁니다. 버튼 색을 바꾸라는 요청이 오면 네 개를 전부 찾아 고쳐야 합니다. 페이지가 열 개면 마흔 개입니다.
배리언트로 묶으면 하나만 고치면 전부 반영됩니다. 배리언트는 애니메이션 기능이 아니라 관리 기능이라고 생각하시는 편이 정확합니다. 애니메이션은 그 결과로 따라옵니다.
상태를 나누는 일은 디자인이 아니라 설계입니다.
만드는 순서
1. 컴포넌트로 만듭니다
버튼을 그리고 선택한 뒤 컴포넌트로 만듭니다. 맥은 옵션과 커맨드를 누른 채 K, 윈도우는 컨트롤과 알트를 누른 채 K입니다. 우클릭 메뉴에서 컴포넌트 만들기를 골라도 됩니다.
컴포넌트로 만들면 별도의 캔버스가 열립니다. 여기가 배리언트를 관리하는 공간입니다. 페이지 캔버스와 분리되어 있어서 헷갈리지 않습니다.
2. 배리언트를 추가합니다
컴포넌트 캔버스에서 배리언트를 추가합니다. 호버와 프레스처럼 자주 쓰는 상태는 미리 준비되어 있고, 직접 이름을 붙여 만들 수도 있습니다.
이름을 붙일 때 규칙을 하나 정하시면 좋습니다. 저희는 상태 이름은 영문 소문자, 용도는 한글로 메모하는 방식을 씁니다. 협업할 때 default, hover, active처럼 통일해두면 다른 사람이 열어봐도 바로 이해합니다.
3. 인터랙션으로 이어줍니다
상태를 만들었다고 자동으로 바뀌지는 않습니다. 언제 어느 상태로 갈지 알려줘야 합니다. 이걸 인터랙션이라고 부릅니다.
트리거로 쓸 레이어를 선택하고 번개 모양 아이콘을 누르거나 키보드에서 L을 누릅니다. 그다음 어느 배리언트로 갈지 연결하고, 어떤 동작에서 실행할지 고릅니다. 클릭, 마우스 진입, 마우스 이탈 같은 선택지가 있습니다.
전환 애니메이션은 만들지 않습니다. 시작 상태와 도착 상태의 차이를 프레이머가 계산해서 이어줍니다. 색이 다르면 색이 서서히 바뀌고, 크기가 다르면 부드럽게 커집니다.
4. 기본 배리언트에 걸어둡니다
이게 시간을 가장 많이 아껴주는 부분입니다. 인터랙션을 기본 배리언트에 설정해두면 나머지 배리언트가 물려받습니다. 상태가 여섯 개여도 인터랙션은 한 번만 만들면 됩니다.
모르고 상태마다 인터랙션을 따로 걸면 나중에 하나만 수정해도 여섯 군데를 찾아다녀야 합니다. 처음부터 기본 배리언트에 거는 습관을 들이시는 게 좋습니다.
실전 예제, 카드 하나로 여섯 화면 만들기
실무에서 가장 자주 쓰는 형태입니다. 포트폴리오 목록, 블로그 목록, 서비스 소개가 전부 카드입니다. 이걸 페이지마다 새로 만들면 사이트가 통일되지 않습니다.
컴포넌트 하나에 담을 것
- •배리언트 두 개 default 와 hover. 그림자와 이미지 확대 정도만 다르게
- •속성 네 개 이미지, 제목, 설명, 링크
여기서 핵심은 카드 종류마다 배리언트를 만들지 않는다는 것입니다. 포트폴리오 카드와 블로그 카드는 담는 내용이 다를 뿐 모습은 같습니다. 내용은 속성으로 넘기면 됩니다.
여섯 화면이 나오는 방식
이 카드 하나에 CMS를 연결하면 항목 수만큼 자동으로 늘어납니다. 페이지마다 다른 CMS를 연결하면 같은 카드가 여섯 페이지에서 각각 다른 내용을 보여줍니다.
나중에 카드 모서리를 둥글게 바꾸라는 요청이 오면 컴포넌트 하나만 고치면 여섯 페이지가 함께 바뀝니다. 이게 배리언트와 속성을 나눠 쓰는 진짜 이유입니다. CMS 구조를 어떻게 짜야 이런 게 가능한지는 Framer CMS 설계 글에 정리해두었습니다.
상태를 몇 개로 나눌 것인가
이 질문이 실무에서 제일 어렵습니다. 저희 기준은 이렇습니다.
- •보이는 모습이 다르면 배리언트 색, 크기, 그림자가 달라진다면 상태로 나눕니다
- •글자만 다르면 속성 버튼 안 문구만 바뀐다면 배리언트가 아니라 텍스트 속성으로 뺍니다
- •쓰는 자리가 다르면 별도 컴포넌트 헤더 버튼과 히어로 버튼은 크기 체계가 아예 다르면 나누는 편이 낫습니다
두 번째가 중요합니다. 문구만 다른 버튼을 배리언트로 만들면 버튼 종류가 늘어날 때마다 상태가 늘어납니다. 글자는 속성으로 빼두면 하나의 배리언트로 무한히 씁니다.
컴포넌트를 몇 개로 쪼갤지에 대한 더 긴 이야기는 컴포넌트 4개를 32개로 다시 짠 사례에 정리해두었습니다.
배리언트로 만들면 안 되는 세 가지
배리언트가 편해지면 모든 걸 상태로 만들려는 시기가 옵니다. 여기서 파일이 무너집니다.
1. 반응형
데스크톱용 배리언트와 모바일용 배리언트를 따로 만드는 경우가 있습니다. 반응형은 브레이크포인트로 처리하는 영역입니다. 배리언트로 만들면 화면 크기에 따라 자동으로 바뀌지 않아 직접 전환을 걸어야 하고, 곧 관리가 불가능해집니다.
2. 다국어
한국어 배리언트와 영어 배리언트를 나누는 경우입니다. 언어는 프레이머의 로컬라이제이션 기능으로 처리합니다. 배리언트로 나누면 문구를 고칠 때마다 언어 수만큼 작업이 늘어납니다.
3. 내용이 다른 것
가장 흔합니다. 서비스 A 카드, 서비스 B 카드, 서비스 C 카드를 배리언트로 만듭니다. 이건 상태가 아니라 데이터입니다. 속성이나 CMS로 빼야 합니다. 서비스가 하나 늘 때마다 컴포넌트를 열어야 한다면 잘못 만든 것입니다.
배리언트는 같은 것이 달라 보이는 순간을 담습니다. 다른 것을 담는 그릇이 아닙니다.
자주 겪는 문제와 해결
호버가 모바일에서 남아 있습니다
터치 기기에서는 마우스를 올린다는 개념이 없습니다. 손가락을 뗀 뒤에도 호버 상태가 유지되어 보이는 일이 생깁니다.
중요한 정보를 호버 상태에만 넣지 않는 것이 해법입니다. 호버는 강조 수단이지 정보 전달 수단이 아니라고 정해두시면 이 문제가 대부분 사라집니다.
전환이 뚝뚝 끊깁니다
두 배리언트의 레이어 구조가 다르면 프레이머가 무엇과 무엇을 이어야 할지 판단하지 못합니다. 그러면 애니메이션 대신 그냥 바뀝니다.
레이어 이름과 구조를 두 상태에서 똑같이 맞추세요. 이름이 같은 레이어끼리 연결되기 때문에, 이름만 통일해도 대부분 해결됩니다. 커스텀 커서를 만들 때도 같은 문제가 생기는데, 1편에서 그 사례를 다뤘습니다.
배리언트가 너무 많아졌습니다
상태가 열 개를 넘어가면 관리가 안 됩니다. 이럴 때는 두 가지를 확인합니다. 글자나 아이콘만 다른 상태가 섞여 있는지, 그리고 서로 다른 용도의 버튼이 한 컴포넌트에 들어와 있는지입니다.
앞엣것은 속성으로 빼고, 뒤엣것은 컴포넌트를 나눕니다. 배리언트는 상태를 담는 그릇이지 종류를 담는 그릇이 아닙니다.
수정했는데 일부 화면만 안 바뀝니다
인스턴스에서 값을 직접 덮어쓴 경우입니다. 컴포넌트를 고쳐도 덮어쓴 값이 우선합니다. 해당 인스턴스를 선택해 재설정하면 원본 값을 다시 따라옵니다.
협업할 때 정해두면 좋은 규칙
혼자 만들 때는 문제가 없다가 사람이 늘면 무너집니다. 저희가 프로젝트 시작 전에 정하는 것들입니다.
- 1.상태 이름 통일 default, hover, pressed, disabled 네 개는 고정입니다
- 2.레이어 이름 규칙 배리언트 사이에서 같은 요소는 반드시 같은 이름
- 3.속성 이름은 한글로 클라이언트가 직접 편집할 부분이라 한글이 낫습니다
- 4.컴포넌트 폴더 나누기 공통, 섹션, 페이지 전용으로 세 갈래
- 5.실험용은 이름 앞에 표시 임시로 만든 것을 나중에 구분할 수 있게
네 번째가 은근히 큽니다. 컴포넌트가 서른 개를 넘어가면 목록에서 찾는 시간이 만드는 시간보다 길어집니다. 인수인계까지 생각하면 처음부터 나눠두는 편이 낫습니다.
자주 묻는 질문
배리언트와 컴포넌트 속성은 무엇이 다른가요?
배리언트는 모습이 달라지는 상태이고, 속성은 같은 모습 안에서 내용만 달라지는 값입니다. 색이 바뀌면 배리언트, 문구가 바뀌면 속성이라고 기억하시면 대부분 맞습니다.
피그마의 배리언트와 같은 개념인가요?
개념은 비슷하지만 프레이머는 상태 사이의 전환을 자동으로 애니메이션합니다. 피그마에서 프로토타입으로 연결하던 작업이 프레이머에서는 실제 사이트 동작이 됩니다. 옮길 때 무엇이 넘어가고 무엇을 다시 만들어야 하는지는 따로 정리한 글을 참고하세요.
배리언트를 CMS와 연결할 수 있나요?
컴포넌트 속성을 CMS 필드에 연결하는 방식으로 씁니다. 상태 자체를 CMS로 바꾸기보다는 내용만 CMS에서 받아오는 구조가 관리하기 편합니다.
전환 속도는 어디서 조정하나요?
컴포넌트 안의 트랜지션 설정에서 조정합니다. 버튼처럼 작은 요소는 0.2초 안쪽, 섹션처럼 큰 요소는 0.4초 정도가 자연스럽습니다.
배리언트가 많으면 사이트가 느려지나요?
개수 자체보다 각 상태에 들어간 요소의 무게가 영향을 줍니다. 그림자와 블러를 겹겹이 쓴 상태가 여러 개라면 체감이 생깁니다.
반응형은 배리언트로 만들면 안 되나요?
권하지 않습니다. 화면 크기에 따른 변화는 브레이크포인트가 담당합니다. 배리언트로 만들면 자동 전환이 되지 않아 직접 조건을 걸어야 합니다.
클라이언트가 직접 수정할 수 있게 하려면요?
바뀔 가능성이 있는 내용을 전부 속성으로 빼두시면 됩니다. 그러면 컴포넌트를 열지 않고 오른쪽 패널에서 값만 바꿔 수정할 수 있습니다.
배리언트 이름을 나중에 바꿔도 되나요?
가능합니다. 다만 인터랙션에서 그 이름을 참조하고 있다면 연결을 다시 확인하셔야 합니다. 이름은 초반에 정해두는 편이 안전합니다.
정리하면
배리언트는 하나의 컴포넌트에 여러 상태를 넣고 갈아끼우는 방식입니다. 컴포넌트로 만들고, 상태를 추가하고, 인터랙션으로 잇고, 기본 배리언트에 걸어두면 끝입니다.
핵심은 상태를 나누는 기준입니다. 모습이 달라지면 배리언트, 내용만 달라지면 속성. 이 하나만 지켜도 나중에 파일이 무너지지 않습니다.
다음 편에서는 스크롤을 다룹니다. 배리언트가 상태의 변화라면 스크롤 효과는 위치의 변화입니다. 두 가지를 함께 쓸 때 주의할 점까지 정리했습니다.
배리언트로 만드는 대표 컴포넌트 다섯 개
실무에서 반복해서 만드는 것들입니다. 구성만 정리해두었으니 그대로 만들어 쓰셔도 됩니다.
1. 버튼
배리언트는 default, hover, pressed, disabled 네 개. 속성은 문구와 아이콘 표시 여부. 크기는 별도 컴포넌트로 나누기보다 속성으로 두는 편이 관리하기 쉽습니다.
2. 카드
배리언트는 default 와 hover 두 개면 충분합니다. 속성으로 이미지, 제목, 설명, 링크를 빼둡니다. CMS를 붙이면 항목 수만큼 자동으로 늘어납니다.
3. 아코디언
배리언트는 closed 와 open 두 개. 전환은 클릭 트리거로 잇습니다. 높이가 변하는 컴포넌트라 레이어 구조를 두 상태에서 똑같이 유지하는 것이 특히 중요합니다. 자주 묻는 질문 섹션이 대부분 이 구조입니다.
4. 탭
탭 버튼과 내용 영역을 하나의 컴포넌트로 묶고 탭 개수만큼 배리언트를 만듭니다. 세 개까지는 괜찮지만 다섯 개를 넘어가면 관리가 어려워지니 그때는 구조를 다시 보셔야 합니다.
5. 토글과 스위치
on 과 off 두 개. 단순해 보이지만 전환 속도가 인상을 크게 좌우합니다. 0.15초 정도로 짧게 두면 반응이 빠르게 느껴집니다.
인수인계까지 생각한 정리
프로젝트가 끝나면 파일은 클라이언트에게 넘어갑니다. 그때부터가 진짜입니다. 저희가 넘기기 전에 하는 정리입니다.
- 1.안 쓰는 배리언트 삭제 만들다 만 상태가 남아 있으면 혼란만 줍니다
- 2.컴포넌트 이름 정리 Component 1 같은 이름이 남아 있지 않게
- 3.속성 이름을 한글로 직접 수정할 사람이 읽을 이름입니다
- 4.수정하면 안 되는 것 표시 이름 앞에 기호를 붙여 구분해둡니다
- 5.짧은 안내 문서 어느 컴포넌트를 어디서 고치는지 한 장이면 충분합니다
이 정리를 안 하면 몇 달 뒤에 연락이 옵니다. 버튼 색을 바꾸려는데 어디를 고쳐야 하는지 모르겠다는 내용입니다. 잘 만든 파일의 기준은 만든 사람이 없어도 굴러가는가입니다. 어디까지 직접 수정해도 되는지에 대한 기준은 따로 정리한 글에 있습니다.
함께 읽으면 좋은 글
지금 사이트를 어디부터 손봐야 할지 정리해 드립니다. 상담 신청을 남겨주시면 화면을 먼저 보고 말씀드립니다. 범위와 비용은 요금제 페이지에서 확인하실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 각 도구의 기능과 화면 구성은 업데이트에 따라 달라질 수 있어 진행 전 공식 문서를 함께 확인하시길 권합니다. 우리 사이트에 맞는 방향이 궁금하시다면 편하게 상담 신청해주세요.
