프레이머 사이트를 인수받으면 화면부터 보지 않습니다. 왼쪽 에셋 패널을 먼저 엽니다. 거기서 앞으로 이 사이트에 얼마나 시간이 들지가 거의 결정됩니다.
작년에 넘겨받은 IT 글로벌 SaaS 랜딩페이지가 그랬습니다. 화면은 훌륭했습니다. 해외 레퍼런스를 참고한 티가 났고 인터랙션도 세련됐습니다.
그런데 컴포넌트가 네 개였습니다. 나머지는 전부 그 자리에서 직접 그려 넣은 것이었습니다.
저희는 국내에서 프레이머를 4년째 다루고 있습니다. 누적 수강생 1,000명이 넘는 교육을 운영하면서 한글 자료가 없어 Framer 위키와 커뮤니티도 직접 만들었습니다. 그동안 남의 손에서 만들어진 사이트를 인수한 경험이 쌓였고, 이 글은 그 과정에서 정리된 판단 기준입니다.
30초 요약
- •컴포넌트 4개짜리 사이트를 32개로 재설계했더니, 수정 요청 처리 시간이 평균 40분에서 8분이 됐습니다.
- •배리언트 24개짜리 컴포넌트를 물려받아 축을 정리하는 데 6시간이 걸렸습니다. 만드는 것보다 푸는 게 오래 걸립니다.
- •두 번 나오면 컴포넌트로 만든다는 규칙은 절반만 맞습니다. 앞으로 각자 달라질 것은 묶으면 안 됩니다.
- •버튼과 스타일까지 에셋으로 등록되어야 정리가 끝난 것입니다.
- •배리언트는 인터랙션의 뼈대입니다. 묶여 있지 않으면 움직임을 이을 대상이 없습니다.
- •정리하지 말아야 할 사이트도 있습니다. 회수가 안 되면 하지 않습니다.
컴포넌트 4개짜리 사이트
그 사이트는 페이지마다 버튼을 새로 그려 놓은 상태였습니다. 모양은 같은데 값이 조금씩 달랐습니다. 어떤 버튼은 모서리가 8이고 어떤 건 10이었습니다. 눈으로는 구분이 안 되지만 코드로는 다른 버튼이었습니다.
문구 하나 바꿔 달라는 요청에 평균 40분이 걸렸습니다. 시간의 대부분은 고치는 데 쓴 게 아니라 어디에 있는지 찾는 데 썼습니다.
고치는 시간은 5분이었고 찾는 시간이 35분이었습니다.
재설계 후 컴포넌트는 32개가 됐습니다. 같은 요청이 이제 평균 8분입니다. 컴포넌트 하나를 열어 고치면 쓰인 곳이 전부 바뀌니까 찾을 일이 없어졌습니다.
32개라는 숫자를 목표로 삼은 건 아닙니다. 반복되는 것을 묶다 보니 그렇게 됐습니다. 중요한 건 개수가 아니라 찾아다니는 일이 사라졌다는 것입니다.
우리가 정리 완료로 보는 상태
컴포넌트를 만들었다고 끝이 아닙니다. 저희가 인수인계 전에 확인하는 기준이 있습니다.
- •페이지의 모든 요소가 컴포넌트로 관리되는가 한 번만 쓰는 큰 덩어리는 예외로 두되, 반복되는 것 중 남아 있는 게 없어야 합니다
- •상태가 배리언트로 묶여 있는가 마우스 오버, 눌림, 비활성이 따로 만들어져 있지 않아야 합니다
- •버튼이 에셋으로 등록되어 있는가 페이지에서 직접 그린 버튼이 하나도 없어야 합니다
- •색과 글자 스타일이 에셋으로 등록되어 있는가 값을 직접 입력한 곳이 남아 있으면 나중에 반드시 어긋납니다
마지막 항목이 가장 자주 빠집니다. 컴포넌트는 잘 만들어 두고 색은 그때그때 입력한 사이트가 많습니다. 그러면 브랜드 색이 바뀔 때 다시 찾아다니게 됩니다.
컴포넌트만 정리하고 스타일을 두면
같은 문제를 절반만 푼 것입니다.
색과 간격에 이름을 붙이는 방식은 디자인 외주에서 받아야 할 것은 시안이 아니라 토큰입니다에 정리했습니다.
배리언트 24개를 푸는 데 6시간
다른 프로젝트에서는 반대 상황을 만났습니다. 컴포넌트는 잘 만들어져 있었는데 버튼 하나에 배리언트가 24개였습니다.
이유는 단순합니다. 축이 세 개였기 때문입니다.
상태 4종 곱하기 크기 3종 곱하기 아이콘 위치 2종 = 24개
만들 때는 하나씩 추가하니 문제가 없어 보입니다. 문제는 수정할 때입니다. 모서리 값을 바꾸기로 하면 스물네 개를 전부 손봐야 합니다. 컴포넌트를 만든 이유가 사라지는 지점입니다.
축을 정리하는 데 6시간이 걸렸습니다. 처음부터 만드는 것보다 오래 걸렸습니다. 이미 여러 페이지에 인스턴스가 흩어져 있어서, 축을 없애면 그 인스턴스들이 어떤 상태로 바뀌는지 하나씩 확인해야 했기 때문입니다.
그래서 지금은 이 기준을 씁니다.
- •축은 두 개까지. 상태와 하나 더
- •배리언트 8개를 넘어가면 축을 하나 뺍니다.
- •크기는 배리언트로 만들지 않습니다. 인스턴스에서 조절하게 열어 둡니다
- •아이콘 유무나 위치도 배리언트로 만들지 않습니다. 켜고 끄게 두는 편이 낫습니다
만들 수 있는 것과 유지할 수 있는 것은 다릅니다. 도구는 24개도 만들게 해 줍니다. 말리지 않습니다.
배리언트가 인터랙션의 뼈대인 이유
여기까지는 정리와 유지보수 이야기였습니다. 그런데 배리언트를 제대로 묶어야 하는 더 큰 이유가 있습니다. 프레이머에서 움직임은 배리언트 사이를 오가는 방식으로 만들어집니다.
상태 A 와 상태 B 를 한 컴포넌트 안에 묶어 두면 프레이머가 그 사이를 알아서 이어 줍니다. 따로 만들어 두면 이을 대상이 없어 화면이 그냥 바뀝니다. 부드럽게 변하느냐 툭 끊기느냐가 여기서 갈립니다.
따로 만든 두 화면 사이에는
프레이머가 이어 줄 것이 없습니다.
자동으로 순회하는 카드
법무법인 사이트에서 업무분야를 보여줄 때 쓴 방식입니다. 분야 카드가 1.1초 간격으로 하나씩 활성화되며 돌고, 마우스를 올리면 그 카드가 우선합니다. 카드가 컴포넌트로 묶여 있고 활성 상태가 배리언트로 정의되어 있어야 가능한 연출입니다.
사례는 서앤율 법무법인 브랜드 웹사이트에서 실제로 움직이는 걸 보실 수 있습니다.
스크롤에 따라 회전하는 제품
식물 브랜드 사이트에서는 제품을 3D 로 만든 뒤 10도 간격 36프레임으로 렌더링해 스크롤 진행률에 매핑했습니다. 내려가는 동안 제품이 한 바퀴 돕니다.
WebGL 로 실시간 렌더링하지 않은 이유는 무게 때문입니다. 초기 로딩이 길어지고 저사양 단말에서 프레임이 떨어지면 각인은커녕 이탈이 먼저 일어납니다. 결과는 같으면서 이미지 디코딩만 하면 되는 쪽을 택했습니다. 초본 브랜드 웹사이트에서 확인하실 수 있습니다.
두 사례의 공통점은 화려한 기술을 쓴 게 아니라는 점입니다. 구조를 먼저 잡아 두었기 때문에 가능했던 연출입니다. 컴포넌트가 흩어져 있으면 애초에 시도할 수 없습니다.
컴포넌트로 만들면 안 되는 것
보통은 무엇을 컴포넌트로 만들지를 이야기합니다. 실무에서 더 자주 문제가 되는 건 반대쪽입니다.
앞으로 각자 달라질 것
지금 모양이 같다고 묶으면 나중에 반드시 풉니다. 서비스 소개 카드 세 개가 지금은 똑같이 생겼는데, 곧 하나에만 배지가 붙고 하나는 이미지가 두 장이 됩니다.
묶어 두면 그때부터 배리언트가 늘어납니다. 그리고 위에서 말씀드린 24개짜리가 됩니다.
한 번만 쓰이는 큰 덩어리
메인 첫 화면처럼 그 페이지에만 있는 구역을 컴포넌트로 올리는 경우가 있습니다. 재사용이 목적이 아니라 정리가 목적이라면 굳이 그럴 필요가 없습니다. 편집할 때 한 겹 더 들어가야 하는 비용만 생깁니다.
아직 확정되지 않은 것
시안이 확정되기 전에 컴포넌트부터 만들면 대부분 버려집니다.
컴포넌트는 반복에서 뽑아내는 것이지
미리 정해 두는 것이 아닙니다.
중첩은 3단계까지
컴포넌트 안에 컴포넌트를 넣을 수 있습니다. 카드 안에 버튼, 버튼 안에 아이콘. 여기까지는 자연스럽습니다.
그런데 섹션 안에 카드 그룹, 그 안에 카드, 그 안에 버튼, 그 안에 아이콘까지 가면 아이콘 하나 바꾸려고 네 번 들어가야 합니다.
저희는 3단계를 한계선으로 둡니다. 넘어가면 중간 한 겹을 없애거나, 그 덩어리를 컴포넌트에서 풀어 일반 요소로 되돌립니다. 구조가 아름다운 것과 편집이 편한 것은 다른 문제입니다.
열 것과 잠글 것
컴포넌트를 만드는 것보다 실무에서 더 중요한 판단이 있습니다. 인스턴스에서 무엇을 바꿀 수 있게 열어 둘 것인가입니다.
클라이언트가 직접 수정하는 사이트라면 특히 그렇습니다. 전부 열면 실수로 레이아웃이 깨지고, 전부 잠그면 문구 하나도 저희를 찾게 됩니다.
여는 것
- •텍스트 내용
- •이미지
- •링크 주소
- •보임 여부 (배지나 태그처럼 있을 수도 없을 수도 있는 것)
잠그는 것
- •여백과 정렬
- •글자 크기와 색
- •모서리 값과 그림자
이 구분을 인수인계 문서에 적어 두면 문의가 확실히 줄어듭니다. 무엇을 만질 수 있는지 모르면 아무것도 안 만지게 되거든요.
이름 규칙은 열 개를 넘기 전에
프레이머는 컴포넌트 이름에 빗금을 넣으면 폴더를 만들어 줍니다. 저희가 쓰는 구분은 세 갈래입니다.
Global / Navigation
UI / Primary Button
Home / Our Cases
규칙 자체는 대단하지 않습니다. 어떤 규칙이든 상관없습니다. 다만 컴포넌트가 열 개를 넘기 전에 정하세요. 나중에 한꺼번에 바꾸는 작업은 위험합니다. 이름을 기준으로 정리해 둔 것들이 흐트러집니다.
CMS 와 컴포넌트가 만나는 자리
컴포넌트를 잘 정리해도 내용을 넣는 구조가 엉키면 같은 문제가 반복됩니다.
자주 겪는 상황이 있습니다. 카드 컴포넌트를 잘 만들어 두었는데 CMS 항목이 카드 구조와 맞지 않는 경우입니다. 카드에는 태그가 하나만 들어가는데 CMS 에서는 여러 개를 넣게 되어 있다든지요.
그래서 순서가 중요합니다. 카드 모양을 정하고 CMS 를 맞추는 게 아니라 어떤 정보를 담을지 정하고 그에 맞춰 카드를 만듭니다. 설계 방식은 Framer CMS 고급 설계 전략에 있습니다.
정리하지 말아야 할 때
여기까지 읽으시면 무조건 정리하는 게 좋다고 들리실 텐데, 그렇지 않습니다.
반년 안에 리뉴얼할 사이트
곧 다시 만들 사이트를 정리하는 건 버릴 것을 닦는 일입니다. 그 시간에 새로 만들 구조를 설계하는 편이 낫습니다.
수정 요청이 거의 없는 사이트
일 년에 두세 번 문구만 바꾸는 사이트라면 정리 비용을 회수하지 못합니다.
정리에 드는 시간 < 앞으로 아낄 시간의 합
이 부등식이 성립할 때만 정리합니다.
앞의 SaaS 랜딩페이지는 수정 요청이 잦았습니다. 40분이 8분이 되는 차이가 매달 쌓이니 금방 회수됐습니다. 요청이 드물었다면 같은 작업을 권하지 않았을 겁니다.
비용 계산 방식은 프레이머 유지보수 비용, 얼마가 적정할까에 정리했습니다.
스파크 케어에서 첫 달에 하는 일
유지보수는 보통 요청을 받아 고쳐 주는 방식으로 시작합니다. 저희는 순서를 반대로 둡니다. 요청을 받기 전에 구조부터 봅니다.
- •구조 진단 컴포넌트 개수, 이름 규칙, 중첩 깊이, 배리언트 개수를 셉니다
- •회수 계산 정리에 드는 시간과 앞으로 아낄 시간을 비교합니다
- •정리 또는 보류 회수가 안 되면 정리하지 않고 그대로 운영합니다
- •인수인계 문서 무엇을 직접 만질 수 있는지 적어 드립니다
정리를 하기로 하면 컴포넌트 재설계, 배리언트 축 정리, 버튼과 스타일 에셋 등록, CMS 구조 개선이 들어갑니다. 별도 비용이 아니라 첫 달 안에 포함됩니다.
이게 저희에게도 이득이라서 그렇습니다. 40분짜리 요청을 매달 받는 것보다 8분짜리로 만들어 두는 편이 낫습니다.
고치는 데 걸리는 시간은 고칠 때가 아니라 만들 때 정해집니다.
자주 묻는 질문
프레이머 컴포넌트와 배리언트, 차이가 뭔가요?
컴포넌트는 반복해서 쓰는 조각 자체이고, 배리언트는 그 조각이 가질 수 있는 여러 상태입니다. 버튼이 컴포넌트라면 기본, 마우스 오버, 눌림, 비활성이 배리언트입니다.
배리언트는 몇 개까지 만드는 게 좋나요?
저희는 8개를 넘어가면 축을 하나 뺍니다. 24개짜리를 물려받아 정리해 본 경험에서 나온 기준입니다. 배리언트는 조합으로 늘어나서 축이 세 개가 되는 순간 관리가 어려워집니다.
컴포넌트가 몇 개면 적당한가요?
정해진 수는 없습니다. 한 랜딩페이지를 32개로 정리한 적이 있지만 그건 결과일 뿐 목표가 아니었습니다. 기준은 개수가 아니라 요청 하나를 처리하는 데 찾아다니는 시간이 있는가입니다.
피그마에서 만든 컴포넌트가 프레이머로 그대로 넘어가나요?
모양은 넘어가지만 배리언트 구조와 동작은 다시 만들어야 하는 경우가 많습니다. 자세한 내용은 피그마에서 프레이머로 옮길 때에 있습니다.
구조를 바꾸는 동안 사이트가 멈추나요?
아닙니다. 프레이머는 작업 중인 내용과 공개된 화면이 분리되어 있어, 정리를 마치고 한 번에 반영합니다.
복잡한 인터랙션도 프레이머로 가능한가요?
가능합니다. 다만 인터랙션의 난이도보다 구조가 잡혀 있는지가 관건입니다. 스크롤 연동 회전이나 자동 순회 같은 연출도 컴포넌트와 배리언트가 정리되어 있으면 어렵지 않고, 흩어져 있으면 아예 시작이 안 됩니다.
정리하면
컴포넌트를 잘 쓰는 것은 많이 만드는 게 아니라 어디서 멈출지 아는 것입니다.
앞으로 달라질 것은 묶지 않고, 배리언트 축은 두 개까지, 중첩은 3단계까지, 버튼과 스타일까지 에셋으로 등록하고, 인스턴스에서 열 것과 잠글 것을 정합니다.
그리고 정리가 회수되지 않는 사이트라면 하지 않습니다. 그 판단까지가 유지보수의 일이라고 봅니다.
덧붙이면 이 정리는 유지보수만을 위한 것이 아닙니다. 제대로 된 인터랙션을 넣으려면 구조가 먼저 서 있어야 합니다. 나중에 무엇을 할 수 있는지가 지금 어떻게 만드느냐로 정해집니다.
함께 읽으면 좋은 글
- •피그마에서 프레이머로 옮길 때 넘어가는 것과 다시 만드는 것
- •방치된 프레이머 사이트를 넘겨받으면 먼저 하는 3가지
- •프레이머 유지보수 비용, 얼마가 적정할까
- •한국에서 프레이머를 가장 많이 가르쳐 온 팀이 만듭니다
지금 사이트가 정리할 값어치가 있는지 궁금하시면 상담 신청을 남겨주세요. 진단만 먼저 해드리고, 회수가 안 된다고 판단되면 그렇게 말씀드립니다. 포함 범위는 요금제 페이지에서 보실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 사이트 규모와 운영 방식에 따라 다를 수 있어 결과를 보장하지 않습니다. 우리 사이트에 맞는 방향이 궁금하시다면 편하게 상담 신청해주세요.
