웹디자인 수정 요청에 지친 실무자라면 피그마 변수부터

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

화면마다 같은 색을 고치고 있었다면

변수를 쓰기 전 제 작업 방식

웹디자인 시안을 넘긴 뒤 “메인 컬러를 조금만 어둡게 바꿔 주세요”라는 요청을 받으면 마음부터 무거워졌습니다. 버튼, 링크, 배지, 입력창 테두리에 같은 색이 들어갔지만 레이어마다 색상값을 직접 지정해 두었기 때문입니다. 페이지가 열 장을 넘으면 빠뜨린 요소가 생겼고, 수정본에 이전 색이 남아 다시 피드백을 받는 일도 잦았습니다.

피그마 변수를 실제 프로젝트에 적용한 뒤 가장 크게 달라진 점은 작업 속도보다 수정 범위를 예측할 수 있게 된 것이었습니다. 변수는 자주 쓰는 색상, 숫자, 문자열 등을 이름이 있는 값으로 관리하는 기능입니다. 예를 들어 버튼 배경에 특정 HEX 값을 직접 넣는 대신 color/action/primary라는 변수를 연결하면, 원본 값 한 번의 변경으로 연결된 요소를 함께 바꿀 수 있습니다.

처음에는 스타일과 변수가 비슷해 보여 굳이 옮겨야 하나 싶었습니다. 하지만 밝은 화면과 어두운 화면을 오가거나 브랜드별 테마를 만들어 보니 차이가 분명했습니다. 디자인을 단순히 보기 좋게 만드는 활동이 아니라 조건과 목적에 맞게 관계를 설계하는 일로 이해하면 좋습니다. 디자인의 넓은 개념은 지식백과의 디자인 정의도 함께 참고할 만합니다.

• 장점: 반복 수정이 빨라지고 화면 사이의 색상 불일치가 줄었습니다.
• 단점: 초기에 이름과 계층을 정하는 시간이 필요하며, 급하게 만들면 변수 목록이 더 복잡해집니다.
• 추천 대상: 랜딩 페이지 한 장보다 여러 화면을 운영하거나 수정 요청을 자주 받는 디자이너에게 효과가 큽니다.
• 체감 비용: 작은 파일은 무료 플랜으로도 연습할 수 있지만, 조직 단위 라이브러리와 고급 관리 기능은 유료 플랜 범위를 확인해야 합니다.

처음부터 모든 색을 변수로 만들지 마세요. 한 프로젝트에서 세 번 이상 반복되고, 바뀔 가능성이 높은 값부터 연결해야 관리 효과를 체감할 수 있습니다.

일주일 동안 작은 프로젝트에 적용한 순서

원시값과 역할값을 나누니 이름이 읽혔습니다

저는 쇼핑몰 모바일 화면 여섯 장을 복제해 일주일 동안 변수 구조를 시험했습니다. 첫날에는 blue-500, gray-100처럼 실제 색상값에 가까운 원시 변수를 만들었습니다. 그다음 버튼, 본문, 배경처럼 사용 목적을 드러내는 역할 변수를 만들고 원시 변수와 연결했습니다. color/text/primary라는 이름만 읽어도 어디에 쓰는 값인지 판단할 수 있어 인수인계가 한결 편했습니다.

처음부터 색상 칩을 수십 개 등록했을 때는 오히려 선택 시간이 늘었습니다. 실제 화면을 살펴보니 반복 사용되는 핵심값은 생각보다 적었습니다. 배경, 기본 글자, 보조 글자, 경계선, 강조색, 오류색부터 만들고 나머지는 필요할 때 추가하니 목록이 안정적으로 유지됐습니다. 그래픽 요소의 시각적 전달 원리를 다시 확인하고 싶다면 그래픽 디자인의 개념 설명을 읽어 두는 것도 도움이 됩니다.

셋째 날부터 간격과 모서리 반경에도 숫자 변수를 적용했습니다. 카드 간격을 16에서 20으로 바꾸는 테스트가 몇 초 만에 끝났지만, 모든 숫자를 변수화하면 오히려 무엇을 선택해야 할지 모호해졌습니다. 그래서 4의 배수를 기본 간격으로 정하고 4, 8, 12, 16, 24, 32만 남겼습니다. 여러분의 파일에도 13px, 15px, 17px처럼 이유 없이 늘어난 값이 있나요? 그렇다면 색상보다 간격 변수부터 정리하는 편이 즉각적인 효과를 낼 수 있습니다.

1. 자주 수정되는 색상과 간격을 화면에서 직접 표시합니다.
2. 원시값은 color/blue/500처럼 값의 계열로 이름을 붙입니다.
3. 역할값은 color/text/primary처럼 용도를 중심으로 만듭니다.
4. 컴포넌트에 역할 변수를 연결하고 일반 레이어의 직접 지정값을 줄입니다.
5. 변수를 하나 바꾼 뒤 예상한 화면만 변하는지 검수합니다.

기존 파일을 한꺼번에 바꾸지 않았습니다

운영 중인 대형 파일에 바로 적용하는 것은 추천하지 않습니다. 저는 복사본에서 헤더와 상품 카드 두 종류만 먼저 바꿨고, 팀원이 변수 이름을 이해하는지 확인한 뒤 범위를 늘렸습니다. 이 작은 시험 덕분에 primary라는 모호한 이름을 text/primary와 action/primary로 일찍 분리할 수 있었습니다.

이름을 보고 사용 위치를 설명할 수 없다면 좋은 변수가 아닙니다. 색이 어떻게 보이는지보다 어떤 역할을 하는지 먼저 적어 보세요.

다크 모드와 브랜드 테마에서 드러난 장단점

모드를 바꾸자 시안 복제가 크게 줄었습니다

변수를 계속 사용하게 된 결정적 이유는 다크 모드였습니다. 예전에는 밝은 화면을 복제한 뒤 배경색과 글자색을 일일이 교체했습니다. 화면 수정이 생길 때 두 버전을 함께 고쳐야 했고, 어느 한쪽에서 컴포넌트가 빠지는 문제가 생겼습니다. 변수 컬렉션에 Light와 Dark 모드를 만든 뒤에는 같은 화면 구조를 유지하면서 값의 묶음만 전환할 수 있었습니다.

여기서 중요한 점은 흰색을 검은색으로 단순 반전하지 않는 것입니다. 밝은 모드의 진한 회색 본문을 어두운 배경 위에 그대로 대응시키면 눈부심이나 대비 부족이 나타날 수 있습니다. 저는 배경을 세 단계, 텍스트를 세 단계로 나누고 실제 휴대전화에서 야간 밝기로 확인했습니다. 모니터에서 선명했던 경계선이 작은 화면에서는 거의 보이지 않는 경우가 있어, 기기 검수 후 변수값을 두 차례 조정했습니다.

두 번째 실험은 하나의 예약 서비스 화면에 서로 다른 두 브랜드 색을 적용하는 일이었습니다. 구조와 컴포넌트는 같고 강조색, 로고 주변 배경, 링크 색상만 달랐는데, Brand A와 Brand B 모드를 나누니 별도의 시안 파일을 복제할 필요가 없었습니다. 이 방식은 여러 지점이나 하위 브랜드를 운영하는 웹디자인 프로젝트에서 특히 유용했습니다. 다만 테마마다 예외값이 계속 생긴다면 공통 구조가 실제로 같은지부터 의심해야 합니다.

• 다크 모드 장점: 같은 프레임에서 테마를 전환해 누락된 색상 연결을 빠르게 찾을 수 있습니다.
• 브랜드 모드 장점: 공통 UI를 유지하면서 제안 시안을 여러 분위기로 보여주기 쉽습니다.
• 실사용 단점: 모드 이름과 변수 범위가 정리되지 않으면 팀원이 잘못된 컬렉션을 적용할 수 있습니다.
• 주의할 점: 이미지, 그림자, 투명도는 단순 색상 교체만으로 자연스럽게 대응되지 않아 별도 검수가 필요합니다.

디자인과 개발의 대화도 조금 달라졌습니다

개발자에게 “이 파란색을 바꿔 주세요”라고 말할 때보다 action-primary 값을 변경했다고 전달할 때 수정 의도가 분명했습니다. 이름이 완전히 동일하지 않더라도 디자인 토큰과 CSS 변수의 대응표를 짧게 만들어 두면 색상값 복사 과정에서 생기는 실수를 줄일 수 있습니다. 시각 요소를 정보 전달 체계로 다룬다는 관점은 그래픽 디자인 관련 설명과도 자연스럽게 이어집니다.

반면 개발 환경과 맞추지 않은 채 디자이너 혼자 거대한 변수 체계를 만드는 것은 효율이 낮았습니다. 실제 구현에는 없는 단계와 상태를 세밀하게 나누면 문서만 복잡해졌습니다. 저는 개발자가 바로 대응할 수 있는 기본, 호버, 비활성, 오류 상태부터 합의하고 확장했습니다. 이 순서가 협업 속도와 디자인 일관성을 동시에 지키는 데 가장 현실적이었습니다.

변수보다 파일을 더 복잡하게 만든 세 가지 실수

이름 욕심과 과도한 등록이 첫 번째 함정이었습니다

가장 먼저 저지른 실수는 완벽한 체계를 만들겠다며 실제로 쓰지 않는 변수까지 등록한 것입니다. 온라인에서 본 대형 디자인 시스템을 그대로 흉내 내 색상 단계를 열 개씩 만들었지만, 작은 프로젝트에서는 목록만 길어졌습니다. 필요한 값을 찾느라 검색하는 시간이 늘고 팀원은 비슷한 회색 중 무엇을 써야 할지 계속 물었습니다. 결국 최근 두 주간 한 번도 사용하지 않은 값은 후보 목록으로 옮기고 핵심 변수만 남겼습니다.

두 번째 실수는 변수만 연결하면 접근성도 자동으로 해결된다고 생각한 것입니다. 역할 이름이 잘 정리되어도 전경과 배경의 명도 대비가 부족할 수 있습니다. 특히 비활성 버튼, 보조 문구, 입력창 안내문은 보기 좋게 연하게 만드는 과정에서 읽기 어려워졌습니다. 저는 대표 화면만 확인하지 않고 오류, 비활성, 선택, 호버 등 상태별 조합을 따로 점검했습니다.

세 번째는 컴포넌트 구조가 불안정한 상태에서 변수를 먼저 늘린 일이었습니다. 같은 기능의 버튼이 파일 안에 네 종류로 흩어져 있으면 변수를 연결해도 수정 지점 자체는 줄지 않습니다. 먼저 중복 컴포넌트를 합치고 속성과 변형을 정리한 뒤 변수를 붙였을 때 비로소 효과가 나타났습니다. 변수는 어수선한 파일을 자동으로 정돈하는 기능이 아니라, 합의된 규칙을 반복 적용하는 도구라는 점을 체감했습니다.

• 한 번만 등장하는 장식 색상까지 무조건 변수로 만들지 않습니다.
• gray-1, gray-2처럼 맥락 없는 이름을 팀 공용 역할값으로 사용하지 않습니다.
• 색상 모드를 바꾼 뒤 대비와 그림자를 실제 기기에서 다시 봅니다.
• 사용 중인 변수를 삭제하거나 이름을 바꾸기 전 연결된 컴포넌트 범위를 확인합니다.
• 유료 기능이 필요한 협업 규모라면 결제 전에 좌석 정책과 라이브러리 권한을 공식 가격 페이지에서 확인합니다.

제가 지금도 사용하는 20분 점검법

금요일마다 변수 목록을 오래 정리하는 대신 20분만 사용 기록을 살펴봅니다. 직접 지정된 핵심 색이 새로 생겼는지, 비슷한 역할 변수가 중복됐는지, 모드 전환 때 예상 밖으로 변하는 레이어가 있는지를 확인합니다. 문제가 보이면 즉시 전체 체계를 뜯어고치지 않고 다음 작업부터 사용할 이름을 먼저 합의합니다.

특히 실무에서는 “변수를 많이 만들수록 전문적이다”라는 생각이 가장 위험했습니다. 작은 웹디자인 파일이라면 열 개 안팎의 명확한 색상 역할과 제한된 간격 단계만으로도 충분할 수 있습니다. 반대로 여러 브랜드와 제품을 함께 운영한다면 컬렉션 소유자와 변경 기록이 필요합니다. 화면 수보다 값이 얼마나 자주 반복되고 누구와 공유되는지를 기준으로 범위를 정하면, 도구를 위한 관리 업무가 디자인 시간을 삼키는 실수를 피할 수 있습니다.