디자이너 프리랜서 시작하는 법 – 준비부터 첫 수주까지 직접 겪은 것들

디자이너 프리랜서 이렇게 시작하세요!

회사를 다니면서 “나도 외주 한번 받아볼까”라는 생각을 한 번쯤 한다.

이유는 사람마다 다르다. 부업으로 수입을 더 만들고 싶거나, 회사 밖의 프로젝트를 해보고 싶거나, 언젠가 완전히 독립하고 싶거나.

그런데 막상 시작하려면 막막하다. 포트폴리오는 있는데 어디에 올려야 하는지. 단가는 어떻게 잡는지. 계약은 어떻게 하는지. 클라이언트가 이상하면 어떻게 하는지.

이 글은 디자이너가 프리랜서를 시작할 때 실제로 필요한 것들을 순서대로 정리한 것이다.


시작 전에 먼저 정해야 할 것

어떤 형태로 할 것인가

프리랜서에는 두 가지 형태가 있다.

부업(사이드잡) – 현 직장을 유지하면서 외주를 받는 것. 수입이 추가되고 리스크가 없다. 하지만 시간이 제한적이고, 회사 규정에 따라 겸업 금지 조항이 있을 수 있다. 시작 전에 고용 계약서의 겸업 금지 조항을 반드시 확인해야 한다.

전업 프리랜서 – 회사를 그만두고 완전히 독립하는 것. 자유도가 높지만 수입이 불안정하다. 최소 3~6개월 생활비를 확보한 상태에서 시작하는 게 맞다.

처음이라면 부업으로 시작해서 감을 잡고, 수입이 안정되면 전업으로 전환하는 루트가 현실적이다.


어떤 작업을 받을 것인가

모든 걸 다 한다고 하면 포지셔닝이 흐려진다. 처음엔 잘 할 수 있는 것, 설명하기 쉬운 것으로 좁히는 게 낫다.

디자이너 프리랜서가 주로 받는 작업들.

  • 앱/웹 UI 디자인
  • 랜딩 페이지 디자인
  • 브랜드 아이덴티티 (로고, 가이드라인)
  • 디자인 시스템 구축
  • UX 컨설팅 / 사용성 개선
  • 피그마 작업물 정리 (기존 파일 개선, 핸드오프 세팅)

처음엔 2~3가지로 좁혀서 “이것만큼은 확실히 한다”는 인상을 주는 게 유리하다.


포트폴리오 – 프리랜서용으로 따로 준비해야 하는가

취업용 포트폴리오와 프리랜서용 포트폴리오는 강조점이 다르다.

취업용은 과정과 사고방식을 보여주는 것이 중심이다. 프리랜서용은 클라이언트가 원하는 결과물을 만들 수 있다는 것을 빠르게 보여줘야 한다.

클라이언트는 대부분 디자인 전문가가 아니다. 케이스 스터디 10장보다 완성된 화면 3장이 더 빠르게 신뢰를 준다.

프리랜서 포트폴리오 체크리스트:

  • 결과물 이미지가 첫 페이지에 바로 나오는가
  • 어떤 유형의 프로젝트를 하는지 한 줄로 설명되는가
  • 연락 방법이 명확하게 있는가
  • 모바일에서도 잘 보이는가 (클라이언트가 스마트폰으로 보는 경우 많음)

링크 하나로 공유할 수 있는 형태면 된다. 노션, 비핸스, 개인 웹사이트 모두 가능하다.


단가 – 얼마를 받아야 하는가

프리랜서를 시작할 때 가장 많이 막히는 부분이다. 너무 낮게 잡으면 손해고, 너무 높으면 수주가 안 될 것 같다.

단가 책정 기준

일반적인 기준은 두 가지다.

시간 기반 (시급) 내 연봉을 시간으로 환산해서 기준점을 잡는다. 연봉 4,800만 원 = 월 400만 원 = 일 약 18만 원 (22일 기준) = 시간당 약 2.2만 원. 프리랜서는 세금, 보험, 영업 시간까지 감안해야 하니 여기서 1.5~2배를 적용하는 게 맞다. 시급 3~5만 원이 국내 UI/UX 프리랜서 기준으로 현실적인 범위다.

프로젝트 기반 (건당) 앱 UI 디자인 전체, 랜딩 페이지 1개처럼 범위가 정해진 경우. 범위를 명확하게 정의하고, 예상 작업 시간을 계산해서 금액을 산출한다. 범위를 명확히 하지 않으면 나중에 “이것도 해주세요”가 무한정 늘어난다.

처음 단가를 너무 낮게 잡지 마라

경험 없으니 낮게 받겠다는 심리가 생긴다. 그런데 낮은 단가로 시작하면 두 가지 문제가 생긴다.

첫째, 그 단가가 기준이 되어버린다. 올리기 어려워진다. 둘째, 낮은 단가에 오는 클라이언트는 기대치가 높고 요구가 많은 경우가 많다.

처음부터 적정 단가를 받는 게 장기적으로 낫다.


어디서 일감을 구하는가

플랫폼

국내에서 많이 쓰는 플랫폼들.

크몽 – 국내 1위 프리랜서 플랫폼. 서비스를 등록하고 클라이언트가 구매하는 방식. 시작하기 쉽고 첫 수주가 빠르다. 단 수수료가 있고, 가격 경쟁이 있다.

숨고 – 견적 요청 기반. 클라이언트가 의뢰를 올리면 프리랜서가 견적을 보낸다. 다양한 유형의 의뢰가 들어온다. 초반 포인트 비용이 발생한다.

라우드소싱 – 디자인 특화 플랫폼. 공모전 형태의 작업도 있다. 포트폴리오 노출과 수주를 동시에 할 수 있다.

프리모아, 위시켓 – IT 기반 프로젝트 중심. 규모 있는 프로젝트가 많다. 경력이 어느 정도 쌓인 후에 진입하는 게 유리하다.


플랫폼 외 채널

플랫폼보다 더 좋은 클라이언트가 오는 채널이 있다.

지인 네트워크 첫 수주의 상당수는 아는 사람을 통해 온다. “저 요즘 외주 받고 있어요”라는 말을 주변에 해두는 것만으로도 기회가 생긴다.

LinkedIn 프리랜서 활동을 게시하고, 작업물을 공유하면 인바운드 문의가 온다. 국내외 클라이언트 모두 가능하다.

SNS (인스타그램, 브런치, 블로그) 작업물을 꾸준히 올리면 포트폴리오 노출과 문의가 같이 온다. 이 블로그처럼 전문성을 보여주는 콘텐츠가 장기적으로 가장 강한 채널이다.

커뮤니티 디자인 커뮤니티, 스타트업 커뮤니티에서 “디자이너 구함” 글이 종종 올라온다. UXKR, 디자이너 리그, 스타트업 슬랙 채널 등.


클라이언트 미팅과 계약

미팅 전에 확인할 것들

무조건 미팅부터 잡지 않는 게 낫다. 사전에 이것들을 확인하면 시간 낭비를 줄일 수 있다.

  • 어떤 작업인가 (범위)
  • 예산 범위는 어느 정도인가
  • 일정은 언제까지인가
  • 의사결정자가 누구인가

예산이 전혀 맞지 않거나, 일정이 비현실적이면 미팅 전에 알 수 있다.


계약서는 반드시 써야 한다

구두 계약이나 카톡으로 협의만 하고 시작하면 나중에 문제가 생긴다.

계약서에 들어가야 할 것들.

  • 작업 범위 (무엇을 / 몇 페이지 / 어떤 형식으로)
  • 납기 일정
  • 금액과 지급 방식 (선금 비율, 잔금 시점)
  • 수정 횟수 제한
  • 저작권 귀속
  • 계약 해지 조건

수정 횟수 제한은 특히 중요하다. 명시하지 않으면 “조금만 더 바꿔주세요”가 무한 반복된다. 보통 2~3회 수정을 포함하고, 이후 추가 수정은 별도 청구로 계약한다.

간단한 계약서 템플릿은 크몽, 위시켓 등 플랫폼에서 제공하거나, 변호사 자문 없이 쓸 수 있는 표준 계약서 양식을 온라인에서 찾을 수 있다.


선금을 받아라

작업 시작 전에 선금을 받는 게 기본이다. 통상 30~50% 선금, 납품 후 잔금 지급.

선금 없이 시작하면 납품 후 잔금 지급이 늦어지거나 안 되는 경우가 생긴다. 선금을 꺼리는 클라이언트는 처음부터 리스크 신호다.


어렵고 힘든 클라이언트 대처법

프리랜서를 하다 보면 반드시 마주치는 유형들이 있다.

범위를 계속 넓히는 경우 “이것도 해주세요, 저것도 좀 추가로” 계약서에 명시된 범위를 기준으로 정중하게 선을 긋는다. “해당 작업은 계약 범위 외라 별도 견적이 필요합니다”라고 말하면 된다.

피드백이 추상적인 경우 “왠지 좀 아쉬운 느낌이에요”, “더 예쁘게 해주세요” 구체적인 레퍼런스나 방향을 요청한다. “어떤 부분이 아쉬우신지, 좋아하시는 레퍼런스가 있으시면 공유해 주시면 방향을 더 잡기 쉬울 것 같습니다”

잠수를 타는 경우 피드백도 없고 연락도 안 되는 상황. 일정 기간 이후 자동으로 프로젝트가 종료되는 조건을 계약서에 넣어두면 대비가 된다.


세금과 사업자 문제

프리랜서 수입은 소득세 신고 대상이다.

연 수입 3.3% 원천징수 클라이언트가 세금을 떼고 지급하는 방식. 플랫폼 수수료와 별개다. 이 경우 다음 해 5월에 종합소득세 신고를 해야 한다.

사업자 등록 연 수입이 일정 수준 이상이거나, 지속적으로 프리랜서를 할 계획이라면 사업자 등록이 유리하다. 경비 처리가 가능해져서 세금 부담이 줄어든다. 홈택스에서 개인사업자 등록은 어렵지 않다.

처음엔 세금 관련 감이 없어서 나중에 놀라는 경우가 많다. 수입이 생기기 시작하면 세금 얼마가 나오는지를 미리 계산해두는 게 낫다.

디자이너 프리랜서 이렇게 시작하세요!
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

마무리

프리랜서 첫 수주가 가장 어렵다. 두 번째부터는 레퍼런스가 생기고, 소개가 생기고, 흐름이 붙는다.

시작은 완벽하게 준비된 후가 아니라, 80% 준비된 상태에서 하는 게 맞다. 나머지 20%는 실제로 해보면서 채워진다.

단가, 계약, 클라이언트 관리 – 이 세 가지만 처음부터 제대로 잡으면 프리랜서 디자이너로 꾸준히 일하는 건 충분히 가능하다.


함께 읽으면 좋은 글

디자이너 연봉 현실 – 신입부터 시니어까지 직접 겪은 것들

디자이너연봉, 어느정도 인가

“디자이너 연봉이 어느 정도예요?”

이 질문은 생각보다 대답하기 어렵다. 개발자처럼 스택으로 연봉이 정해지는 구조도 아니고, 직함이 같아도 회사마다 기대 역할이 다르다.

그래서 인터넷에 있는 평균 숫자들이 별로 도움이 안 된다. 평균이 3500만 원이라는 걸 알아봐야, 내가 어디에 있는지를 모르면 쓸모가 없다.

이 글은 숫자를 나열하는 게 목적이 아니다. 연봉이 어떤 요소로 결정되는지, 어떻게 올릴 수 있는지를 현직 디자이너 시점에서 정리한다.


연봉을 결정하는 요소가 뭔가

연봉은 연차로만 결정되지 않는다. 이 요소들이 복합적으로 작용한다.

1. 회사 규모와 업종 대기업 계열사, 유니콘 스타트업, 중소 스타트업, 에이전시는 같은 연차라도 연봉 차이가 크다. 대기업·대형 IT는 복리후생까지 합산하면 중소 스타트업의 1.5~2배가 나오는 경우도 있다.

2. 도메인 핀테크, 헬스케어, 커머스, B2B SaaS 같은 도메인은 산업 자체의 단가가 다르다. B2B SaaS 쪽은 사용자 수가 적어도 계약 단가가 높아서, 디자이너 처우도 상대적으로 좋은 편이다.

3. 스킬셋 UI만 하는 디자이너보다 UX 리서치, 데이터 분석, 콘텐츠 전략까지 커버하는 디자이너가 협상력이 높다. 피그마 실력은 기본이고, 사용자 인터뷰 설계, A/B 테스트 해석, 개발자와의 스펙 협의 능력이 연봉에 영향을 준다.

4. 포트폴리오 퀄리티 같은 연차라도 포트폴리오 임팩트가 다르면 협상 출발점이 달라진다. “화면을 잘 만든다”보다 “이 결정으로 어떤 변화가 있었다”를 보여줄 수 있는 사람이 유리하다.

5. 협상을 하느냐 안 하느냐 제시된 금액을 그냥 받는 경우가 생각보다 많다. 연봉 협상을 안 하는 것 자체가 기회 손실이다.


연차별 현실적인 연봉 범위

숫자는 2024~2025년 기준, 서울 기준이다. 회사 규모에 따라 범위가 넓다.

신입 (0~1년차)

  • 중소 스타트업·에이전시: 2,400만~3,000만 원
  • 중견·중형 스타트업: 3,000만~3,600만 원
  • 대기업·대형 IT: 3,500만~4,500만 원

신입 연봉은 협상 여지가 상대적으로 적다. 회사 규모와 공고 조건이 거의 결정한다. 그래도 포트폴리오가 강하면 밴드 상단을 요청할 수 있다.


주니어 (2~3년차)

  • 중소 스타트업·에이전시: 3,000만~3,800만 원
  • 중견·중형 스타트업: 3,600만~4,500만 원
  • 대기업·대형 IT: 4,500만~6,000만 원

이 시점부터 이직이 연봉 점프의 가장 빠른 루트가 된다. 현 직장에서 연봉 인상을 기다리는 것보다, 이직 오퍼를 받아서 협상하는 게 현실적으로 더 빠르다.

2~3년차는 포트폴리오에 “내가 주도한 것”이 얼마나 있는지가 연봉 협상력을 결정한다. 시킨 것만 한 2년과, 기획부터 출시까지 리드한 2년은 다르게 평가된다.


미드레벨 (4~6년차)

  • 중소 스타트업·에이전시: 4,000만~5,000만 원
  • 중견·중형 스타트업: 4,500만~6,000만 원
  • 대기업·대형 IT: 6,000만~8,000만 원 이상

이 구간부터 연봉 격차가 벌어지기 시작한다. 같은 5년차라도 어떤 도메인에서 어떤 역할을 했느냐에 따라 천만 원 이상 차이가 난다.

미드레벨부터는 단순 실행보다 의사결정에 어떻게 기여했는지를 봐야 협상이 된다.


시니어 (7년차 이상)

  • 중소·중견: 5,500만~7,000만 원
  • 대형 스타트업·IT: 7,000만~1억 원 이상
  • 외국계·글로벌 테크: 1억 원 이상 가능

시니어부터는 연봉보다 스톡옵션, RSU 같은 비현금 보상이 중요해진다. 특히 스타트업에서 시니어 포지션으로 가면, 기본 연봉은 낮아도 주식 가치가 큰 경우가 있다.

시니어는 팀을 어떻게 이끌었는지, 조직에 어떤 영향을 줬는지가 협상 테이블에 올라온다. 개인 작업 퀄리티만으로는 시니어 연봉을 받기 어렵다.


연봉을 높이는 현실적인 방법

1. 이직이 가장 빠르다

현실적으로 연봉을 빠르게 올리는 가장 확실한 방법은 이직이다. 내부 인상은 통상 5~10% 수준이다. 이직을 통한 연봉 점프는 20~40%도 가능하다.

이직 오퍼를 받으면 현 직장에 카운터 오퍼를 요청할 수도 있다. 이직 의사가 명확하다면 협상 도구로 쓸 수 있다. 다만 카운터 오퍼로 잡힌 뒤 계속 있으면 신뢰 문제가 생기는 경우도 있어서, 상황을 잘 판단해야 한다.


2. 협상은 필수다

연봉 협상을 안 하는 이유를 들어보면 두 가지다. “민폐가 될 것 같아서”와 “어차피 안 된다고 할 것 같아서”.

둘 다 근거가 없다. 회사는 협상 여지를 항상 갖고 있다. 제시 금액이 협상 불가라고 명시된 게 아니라면 시도해야 한다.

협상할 때 쓸 수 있는 근거들.

  • 시장 평균 데이터 (잡플래닛, 크레딧잡, 링크드인 인사이트)
  • 받은 다른 오퍼 금액
  • 현재 내가 기여한 구체적인 성과

“시장 평균을 기준으로 OO 정도를 희망합니다”는 가장 무난한 협상 문구다. 감정이 아니라 데이터 기반으로 말하면 거절도 나쁘지 않게 받아들여진다.


3. 스킬을 넓혀라

UI 실행만 하는 디자이너는 대체 가능성이 높다.

반면 이런 걸 할 수 있는 디자이너는 포지션이 달라진다.

  • 사용자 인터뷰 설계와 인사이트 도출
  • 데이터 기반으로 가설 세우기
  • 개발자와 스펙을 정의하고 조율하기
  • 디자인 시스템 구축과 관리

이 중 하나라도 잘한다는 게 명확하면, 연봉 협상 테이블에서 위치가 달라진다.


4. 도메인을 전략적으로 선택해라

모든 도메인이 같은 연봉을 주지 않는다.

연봉 단가가 높은 편인 도메인은 이렇다. 핀테크, B2B SaaS, 헬스테크, 글로벌 서비스.

에이전시, 게임, 커머스는 상대적으로 낮은 경우가 많다.

지금 있는 도메인이 성장에 한계가 느껴진다면, 도메인 이동도 전략이다.


연봉 말고 봐야 할 것들

연봉 숫자만 보다가 놓치는 게 있다.

스톡옵션 스타트업에서 스톡옵션을 받는다면, 기업 가치 상승 시 수익이 연봉을 훨씬 초과할 수 있다. 반대로 회사가 망하면 휴지 조각이다. 벨류에이션, 최근 투자 라운드, 비즈니스 모델을 보고 판단해야 한다.

복리후생 식대 지원, 건강보험, 교육비 지원, 재택 가능 여부 등. 현금으로 환산하면 연 300만~600만 원 차이가 나는 경우도 있다. 연봉만 비교하면 안 되는 이유다.

성장 가능성 현재 연봉이 조금 낮더라도, 빠르게 성장할 수 있는 환경이라면 2~3년 후 협상력이 달라진다. 좋은 팀에서 2년이, 높은 연봉에서 방치된 3년보다 나을 수 있다.

디자이너연봉, 어느정도 인가
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

처음 연봉 협상을 앞두고 있다면

신입이거나 첫 이직이라면 협상이 낯설다. 이것만 기억해두면 된다.

희망 연봉을 먼저 말하지 마라. “연봉은 어느 정도 생각하세요?”라는 질문에 먼저 숫자를 말하면 협상의 시작점이 낮아진다. “회사 내부 밴드가 어느 정도인지 먼저 여쭤봐도 될까요?”로 상대방이 먼저 말하게 하는 게 유리하다.

범위를 말하면 낮은 쪽으로 간다. “3500만~4000만 원을 희망합니다”라고 하면 3500을 받게 될 가능성이 높다. 가능하면 단일 숫자로 말하는 게 낫다.

오퍼를 받고 바로 수락하지 마라. “검토 후 연락드리겠습니다”는 당연한 말이다. 24~48시간 이내에 답하면 된다. 그 시간 동안 다른 오퍼와 비교하거나, 한 번 더 협상 시도를 할 수 있다.


마무리

연봉은 실력만으로 결정되지 않는다. 협상을 하느냐, 어떤 회사를 타겟으로 하느냐, 어떤 도메인에 있느냐가 함께 작용한다.

숫자에 대한 감이 없으면 손해를 본다. 시장을 알고, 나의 위치를 알고, 협상을 해야 한다.

그게 디자이너도 마찬가지다.


함께 읽으면 좋은 글

비전공자 UI 디자이너 되는 법 – 현직자가 말하는 현실적인 루트

비전공자도 UI디자이너 될수 있다! 카드뉴스 이미지

“비전공자인데 UI 디자이너 될 수 있을까요?”

이 질문을 받은 게 한두 번이 아니다. 커뮤니티에도 많고, 지인한테도 종종 온다.

대답은 항상 같다. 된다. 단, 방법이 맞아야 한다.

디자인은 전공보다 포트폴리오로 평가받는 직군이다. 채용 담당자는 졸업장보다 포트폴리오를 먼저 본다. 이 말은 곧, 비전공자도 포트폴리오만 제대로 만들면 문이 열린다는 뜻이다.

다만 “어떻게 배울 것인가”에서 방향을 잘못 잡으면 시간을 많이 잃는다. 이 글은 그 방향을 잡는 데 도움이 되는 내용을 담았다.


UI 디자이너가 하는 일이 뭔가

먼저 이걸 명확히 해야 한다. 직함이 많다. UI 디자이너, UX 디자이너, 프로덕트 디자이너. 회사마다 부르는 이름이 다르고, 하는 일의 범위도 다르다.

공통적으로 하는 것들은 이렇다.

  • 앱이나 웹의 화면을 디자인한다
  • 사용자가 어떻게 움직일지 흐름(플로우)을 설계한다
  • 개발자에게 스펙을 전달한다
  • 기획자, PM과 함께 기능과 화면을 정의한다

UI는 화면을 만드는 것이고, UX는 경험을 설계하는 것이다. 요즘 대부분의 회사는 이 두 가지를 한 사람이 함께 한다. “UI만 잘 그리면 되는 거 아닌가요?”라는 질문은, 실무에서 맞지 않는 경우가 많다.


비전공자가 가장 많이 하는 실수

시작하기 전에 이것부터 짚는다. 시간을 아끼는 가장 빠른 방법은 실수를 피하는 것이다.

실수 1 – 툴부터 배운다 피그마, 어도비XD를 먼저 배우려는 경우가 많다. 툴은 수단이다. 툴을 아무리 잘 써도 “무엇을 왜 이렇게 만들었는가”가 없으면 포트폴리오가 약하다. UX 사고 방식을 먼저 배우고, 툴은 그다음이다.

실수 2 – 예쁜 것만 따라 만든다 드리블이나 핀터레스트 보고 따라 만드는 연습만 한다. 보기엔 예쁜데 실제로 쓸 수 없는 디자인이 되기 쉽다. 실무는 예쁜 화면이 아니라 문제를 푸는 화면을 요구한다.

실수 3 – 포트폴리오를 너무 늦게 시작한다 공부를 충분히 하고 나서 포트폴리오를 만들겠다고 생각한다. 그 “충분히”는 오지 않는다. 배우면서 동시에 만드는 게 맞다.


독학 vs 부트캠프 – 뭐가 나을까

이것도 자주 받는 질문이다.

독학이 맞는 사람

  • 이미 디자인 관련 경험이 어느 정도 있는 경우
  • 자기 관리가 잘 되고, 혼자 계획 세워서 실행하는 게 자연스러운 경우
  • 시간과 비용을 최소화하고 싶은 경우

독학 루트는 이렇게 잡을 수 있다.

  1. UX 기초 개념 공부 (유튜브, 책, 구글 UX 디자인 인증 과정)
  2. 피그마 기초 익히기
  3. 사이드 프로젝트 또는 리디자인 프로젝트로 포트폴리오 만들기
  4. 피드백 받으며 수정

시간이 더 걸리지만, 방향만 맞으면 충분히 가능하다.

부트캠프가 맞는 사람

  • 처음 시작이라 뭐부터 해야 할지 모르는 경우
  • 커리큘럼이 있어야 공부가 되는 경우
  • 네트워크(함께 공부하는 사람, 멘토)가 필요한 경우
  • 취업 연계가 중요한 경우

부트캠프의 진짜 장점은 커리큘럼보다 구조와 마감이다. 혼자 하면 흐지부지되기 쉬운 것들이, 마감이 있으면 완성이 된다.

단점은 비용이다. 300만 원에서 600만 원 이상인 경우도 있다. 부트캠프 선택할 때는 취업률, 포트폴리오 결과물, 수료생 후기를 직접 확인해야 한다. 홈페이지에 있는 수치는 그대로 믿으면 안 된다.


뭘 배워야 하는가 – 순서대로

1단계 – UX 기초 개념

툴보다 먼저다.

  • 사용자 리서치란 무엇인가
  • 정보 구조(IA)란 무엇인가
  • 사용자 플로우를 어떻게 그리는가
  • 와이어프레임이 왜 필요한가

이 개념들이 없으면 피그마를 아무리 잘 써도 “화면만 잘 그리는 사람”이 된다. 실무에서 기획자나 PM과 일할 때 이 언어를 공유하지 못하면 협업이 어렵다.

책 하나 추천한다면 《사용자를 생각하게 하지 마》(스티브 크룩)다. 얇고 읽기 쉬운데, 사용성의 핵심을 제대로 짚는다.


2단계 – 피그마 기초

툴은 피그마 하나만 제대로 익히면 된다. 어도비XD나 스케치를 먼저 배울 필요 없다. 현재 업계 표준은 피그마다.

배워야 할 순서.

  1. 기본 도형과 레이어 구조
  2. 오토레이아웃 (이게 핵심이다)
  3. 컴포넌트와 베리언트
  4. 프로토타이핑
  5. 팀 라이브러리 개념

유튜브에 무료 강의가 많다. 피그마 공식 튜토리얼도 잘 만들어져 있다. 툴을 익히는 데 2~4주면 기본은 된다.


3단계 – 포트폴리오 프로젝트

공부하면서 동시에 시작해야 한다.

프로젝트 유형은 두 가지다.

리디자인 프로젝트 기존 앱의 특정 부분을 문제 정의 → 개선안 제안하는 방식. “배달의민족 장바구니 플로우에서 이 부분이 불편하다. 왜냐하면. 이렇게 바꿨다. 근거는.” 이런 구조로 만들면 된다.

처음엔 실제 서비스를 건드리는 게 어색하다. 그래도 해야 한다. 리디자인 프로젝트는 실무 관점을 증명하는 가장 빠른 방법이다.

사이드 프로젝트 없는 서비스를 처음부터 기획하고 디자인하는 것. 리디자인보다 난이도가 높지만, 처음부터 끝까지 스스로 결정했다는 것을 보여줄 수 있다.


4단계 – 피드백 받고 수정하기

혼자 만든 포트폴리오는 맹점이 있다. 내가 아는 것만 설명하고, 모르는 것은 설명하지 않는다.

피드백을 받을 수 있는 채널을 찾아야 한다.

  • 디자인 커뮤니티 (UXKR, 디자이너 리그 등)
  • 부트캠프 수료생 네트워크
  • 링크드인에서 현직자에게 직접 연락

피드백 없이 제출하면 안 된다는 게 기본이다. 포트폴리오는 내가 만족하는 게 아니라, 채용 담당자가 이해하는 게 목적이다.

비전공자도 UI디자이너 될수 있다! 카드뉴스 이미지
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

취업까지 현실적으로 얼마나 걸리나

개인 차가 크다. 하지만 현실적으로 보면.

  • 완전 처음 시작 → 취업까지 보통 6개월~1년
  • 관련 경험이 있거나 빠르게 흡수하는 경우 → 4~6개월
  • 부트캠프 수료 후 취업 연계 → 3~6개월 (연계 퀄리티에 따라 차이 큼)

빠르게 가려면 포트폴리오 완성도에 올인해야 한다. 공부를 더 하겠다고 취업을 미루는 것보다, 포트폴리오를 완성하고 지원하면서 배우는 게 낫다.

지원하고 면접에서 떨어지는 경험 자체가 배움이다. 어디서 막히는지를 알아야 뭘 보완해야 할지 보인다.


처음 지원할 때 타겟을 어디로 잡아야 하는가

대기업, 스타트업, 에이전시. 선택지가 많아 보이지만, 비전공자 첫 취업이라면 타겟을 좁혀야 한다.

스타트업이 진입 장벽이 낮고 성장 속도가 빠르다. 대기업은 경쟁률이 높고, 포트폴리오 요구 수준도 높다. 에이전시는 다양한 프로젝트를 빠르게 경험할 수 있지만, 빠른 납기 중심이라 UX 사고 훈련보다 실행 속도에 집중하는 경향이 있다.

첫 직장은 성장할 수 있는 환경인가를 기준으로 고르는 게 맞다. 연봉이나 브랜드보다 어떤 팀에서 배울 수 있는가가 더 중요하다.


마무리

비전공자 UI 디자이너 취업은 가능하다. 단, 방향을 맞게 잡고, 포트폴리오에 집중하고, 피드백을 받아야 한다.

길이 없는 게 아니라 방법을 모르는 것이다. 지금 이 글을 읽고 있다면, 그 방향을 찾는 중이라는 뜻이다.

시작하는 것이 완벽한 준비보다 낫다.


함께 읽으면 좋은 글

디자이너 이직 준비 – 포트폴리오부터 면접까지 직접 겪은 것들

프로덕트디자이너 이직 완벽 가이드 이미지

이직을 처음 생각한 건 사소한 계기였다.

일은 익숙해졌고, 배우는 게 줄었다. 새 프로젝트가 시작돼도 결과가 어느 정도 보이는 느낌. 그 익숙함이 불안해지기 시작했다.

그렇게 이직을 준비했다. 처음엔 포트폴리오 정리하면 되겠지 싶었다. 그런데 막상 시작하니 생각보다 훨씬 복잡했다.

이 글은 디자이너가 이직을 준비할 때 실제로 무엇을 해야 하는지를 정리한 것이다. 잘됐던 것, 안됐던 것, 다시 한다면 다르게 할 것들을 포함해서.


먼저 – 지금 이직할 타이밍인지 생각해봐야 한다

이직 준비를 시작하기 전에 한 가지 먼저 따져봐야 한다. 지금 이직하는 게 맞는 타이밍인가.

이직 이유가 불명확하면 면접에서 반드시 걸린다. “연봉을 높이고 싶어서”는 솔직한 이유지만 그것만으로는 약하다. 면접관 입장에서는 “여기서도 연봉 문제가 생기면 또 나갈 사람”으로 보인다.

이직 이유는 자기 자신에게 먼저 명확해야 한다.

  • 성장 환경이 부족한가
  • 다루고 싶은 도메인이 다른가
  • 팀 문화가 안 맞는가
  • 규모가 다른 조직을 경험하고 싶은가

이 질문에 구체적으로 답할 수 있으면, 어떤 회사에 지원해야 하는지도 보인다. 이직 이유가 선명할수록 지원 방향도 선명해지고, 면접도 편해진다.


이직 전 현실 점검

이직 시장은 경기에 영향을 많이 받는다. 특히 프로덕트 디자이너 포지션은 회사마다 요구하는 게 다르다.

지원하기 전에 이것들을 확인해두는 게 낫다.

경력 연차 대비 포지션이 맞는가 주니어와 미드레벨, 시니어가 기대하는 역량이 다르다. JD(Job Description)를 꼼꼼히 읽으면 그 회사가 어떤 사람을 원하는지 윤곽이 나온다.

도메인 이동이 가능한가 커머스에서 핀테크, B2B SaaS로 넘어가는 경우처럼 도메인이 크게 바뀌면 포트폴리오 어필 방식도 달라진다. “도메인은 다르지만 UX 문제 해결 방식은 같다”는 걸 설득할 수 있어야 한다.

현재 회사에서 떠날 수 있는 시점이 언제인가 합격하고 나서 입사 일정이 안 맞으면 기회를 놓친다. 대략적인 퇴사 가능 시점을 미리 생각해두는 게 필요하다.


포트폴리오 – 가장 많은 시간이 걸리는 것

이직 준비의 80%는 포트폴리오다. 그리고 포트폴리오에서 대부분 막힌다.

케이스 스터디 구성이 핵심이다

포트폴리오는 예쁜 화면 모음이 아니다. 문제를 어떻게 정의하고, 어떻게 풀었고, 결과가 어땠는지를 보여주는 것이다.

회사마다 조금씩 다르지만, 케이스 스터디 하나의 기본 구조는 이렇다.

  1. 배경 – 어떤 서비스, 어떤 팀에서
  2. 문제 – 무엇이 문제였나 (사용자 문제 또는 비즈니스 문제)
  3. 과정 – 어떻게 접근했나 (리서치, 탐색, 결정 이유)
  4. 결과물 – 최종 디자인
  5. 성과 – 어떤 변화가 있었나 (정성적 또는 정량적)

화면이 아무리 예뻐도 “왜 이렇게 결정했는가”가 없으면 약하다. 반대로 과정이 탄탄하면 결과물이 완벽하지 않아도 설득이 된다.


성과 수치를 어떻게 쓸 것인가

이직 포트폴리오에서 가장 많이 고민하는 게 이 부분이다.

수치가 있으면 쓰는 게 당연히 낫다. 전환율 몇 % 개선, 이탈률 몇 % 감소 같은 것들.

하지만 대부분의 경우 디자이너가 수치 데이터에 직접 접근하기 어렵다. 또는 디자인만의 기여를 정확하게 뽑아내기 어렵다.

이럴 때는 정성적인 성과를 구체적으로 쓰는 게 낫다.

“개발팀과의 스펙 조율 횟수가 줄었다” “사용자 인터뷰에서 특정 문제 언급이 사라졌다” “출시 후 CS 문의에서 해당 플로우 관련 내용이 감소했다”

이런 표현은 수치는 아니지만 거짓이 아니고, 설득력도 있다. 없는 수치를 만들어내는 것보다, 있는 사실을 구체적으로 쓰는 게 훨씬 낫다.


케이스 스터디 몇 개가 적당한가

많다고 좋지 않다. 3~4개가 적당하다.

하나를 깊게 파는 게 열 개를 얕게 나열하는 것보다 낫다. 면접관은 포트폴리오 전체를 꼼꼼히 보지 않는다. 두세 개를 집중해서 보고, 그게 마음에 들면 나머지를 훑는다.

첫 번째 케이스 스터디가 가장 중요하다. 가장 자신 있는 것, 가장 잘 설명할 수 있는 것을 첫 번째에 놓아라.


포트폴리오 형식

PDF와 웹사이트 두 가지 선택지가 있다.

PDF는 이메일 제출에 편하고, 채용 담당자가 바로 열어볼 수 있다. 웹사이트는 더 인터랙티브하게 보여줄 수 있고, 링크 하나로 공유가 된다.

둘 다 준비하는 게 이상적이다. 기본은 PDF로, 여유가 있으면 노션이나 포트폴리오 플랫폼으로 웹 버전도 만든다.

노션으로 만드는 사람도 많다. 빠르게 만들 수 있고, 링크 공유가 편하다. 다만 노션 특유의 레이아웃 한계가 있어서, 디자인적으로 차별화하기는 어렵다.


이력서

이력서는 포트폴리오보다 빨리 만들 수 있다. 하지만 간과하기 쉬운 부분이 있다.

JD에 맞게 이력서를 조정해야 한다. 모든 회사에 같은 이력서를 보내는 건 비효율적이다. 회사마다 원하는 역량이 다르기 때문에, 강조하는 포인트를 바꿔야 한다.

이력서에서 디자이너가 자주 실수하는 것들.

  • “다양한 디자인 작업을 수행했다” 같은 모호한 표현
  • 툴 나열만 있고 어떤 역할을 했는지 없는 경우
  • 프로젝트 이름만 있고 어떤 서비스인지 설명이 없는 경우

무엇을 했냐보다 어떤 영향을 만들었냐를 쓰는 게 낫다. “온보딩 플로우 리디자인 담당”보다 “온보딩 플로우 리디자인으로 신규 사용자 첫 행동 완료율 개선에 기여”가 훨씬 낫다.


지원 – 어디에, 얼마나

처음 이직을 준비하면 지원을 너무 많이 하거나, 너무 적게 하는 경향이 있다.

선택과 집중이 맞다. 많이 지원한다고 합격 확률이 올라가지 않는다. 포트폴리오를 제출하고 나서 면접이 동시에 여러 개 겹치면 준비가 흐트러진다.

한 번에 5~7개 정도가 적당하다. 그 안에서 우선순위를 정해두고, 가고 싶은 회사는 준비를 더 들인다.

공고가 없는 회사에도 지원할 수 있다. 채용 공고 없이 직접 메일로 포트폴리오를 보내는 방식이다. 회신 확률은 낮지만, 가고 싶은 회사가 명확하다면 시도해볼 만하다.


면접 – 포트폴리오 발표와 질문

디자이너 면접은 크게 두 가지다. 포트폴리오 발표와 인성/컬처핏 면접.

포트폴리오 발표

시간 제한이 있는 경우가 많다. 보통 20~30분. 준비 없이 들어가면 시간 조절을 못 한다.

적어도 3번은 소리 내어 발표 연습을 해야 한다. 혼자 해보고, 가능하면 다른 사람 앞에서도 해본다. 말하다 보면 어색한 부분, 설명이 부족한 부분이 보인다.

발표할 때 주의할 것들.

  • 결과물 자랑보다 과정의 선택과 이유에 집중한다.
  • “예쁘게 만들었습니다”보다 “이 결정을 한 이유는”이 훨씬 낫다.
  • 협업한 부분은 “저는 이 부분을 담당했고”로 명확하게 역할을 구분한다.

자주 나오는 면접 질문들

이것들은 거의 항상 나온다고 봐도 된다.

“지금까지 한 작업 중 가장 힘들었던 프로젝트는?” 실패 경험을 묻는 것이다. 잘됐다는 얘기보다 어떻게 극복했는지가 핵심이다. 잘 안된 프로젝트를 솔직하게 말하되, 거기서 뭘 배웠는지를 같이 말해야 한다.

“팀원과 의견 충돌이 있었던 경험은?” 협업 방식을 보는 질문이다. 내가 옳았다는 결론이 아니라, 어떻게 조율했는지가 중요하다.

“이 회사에 왜 지원했나?” 이 질문에 “성장하고 싶어서”만 있으면 약하다. 그 회사의 서비스를 실제로 써봤는지, 어떤 부분이 흥미로웠는지를 구체적으로 말해야 한다.

“5년 후에 어떤 디자이너가 되고 싶은가?” 커리어 방향을 보는 질문이다. 정답은 없지만, 생각해본 적 없는 것처럼 보이면 안 된다.


면접 후 – 피드백을 요청해도 된다

불합격 통보를 받으면 피드백을 요청할 수 있다. 모든 회사가 답해주진 않지만, 일부는 구체적인 피드백을 준다.

같은 실수를 다음 면접에서 반복하지 않으려면 피드백이 필요하다. 자존심 문제가 아니라 정보 수집의 문제다.


이직 준비 기간은 얼마나 걸리나

사람마다 다르지만, 현실적으로 보면.

  • 포트폴리오 준비: 1~2개월
  • 지원 및 서류 통과: 2~4주
  • 면접 프로세스: 회사마다 2주~1개월
  • 합격 후 퇴사 준비: 1개월 (보통 인수인계 포함)

빠르게 잡아도 3~4개월, 길면 6개월 이상 걸린다. 현재 직장을 다니면서 준비한다면 체력 관리가 중요하다. 포트폴리오 작업은 퇴근 후에 하게 되는데, 이 시간이 생각보다 빨리 소진된다.

처음부터 너무 빠듯하게 잡지 말고, 여유 있게 일정을 잡는 게 낫다.

프로덕트디자이너 이직 완벽 가이드 이미지
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

이직 준비하면서 놓치기 쉬운 것들

LinkedIn 프로필 정리 국내 채용도 LinkedIn으로 연락 오는 경우가 늘고 있다. 포트폴리오 링크, 경력 요약, 최근 프로젝트 설명을 업데이트해두면 수동적으로도 기회가 온다.

현재 회사 프로젝트 기록 남기기 이직 준비를 결심했다면 지금 하고 있는 프로젝트를 기록해두는 게 좋다. 퇴사하고 나서 과거 자료를 꺼내오는 건 어렵다. 스크린샷, 플로우, 결정 이유 같은 것들을 지금부터 정리해두면 포트폴리오 작업이 훨씬 수월해진다.

커뮤니티와 네트워크 이직 기회의 상당수는 공고가 아니라 아는 사람을 통해 온다. 같은 직군의 사람들과 교류하는 것, 디자인 커뮤니티에 꾸준히 얼굴을 비추는 것이 장기적으로는 훨씬 강력한 채널이다.


마무리

이직은 준비가 전부다. 포트폴리오를 잘 만드는 것, 면접을 잘 보는 것도 결국 준비한 만큼 나온다.

그리고 한 가지.

이직은 현재 회사에서 못 버텨서 도망가는 게 아니라, 더 잘 맞는 환경을 찾아가는 거라는 관점이 필요하다.

그 관점이 있을 때 면접에서도 흔들리지 않는다. 면접관이 “왜 이직하려고 해요?”라고 물었을 때, 도망가는 사람과 나아가는 사람의 대답은 다르다.

준비를 잘 하면, 합격보다 더 중요한 것도 얻는다. 나 자신의 커리어를 한 번 제대로 들여다보는 시간. 그게 이직 준비의 진짜 가치다.


함께 읽으면 좋은 글

피그마 자동 레이아웃(Auto Layout) 사용법 – 이것만 알면 실무에서 안 막힌다

피그마 자동레이아웃 완벽정리 이미지

피그마를 처음 배울 때 자동 레이아웃을 건너뛰는 경우가 많다. 사각형 그리고, 텍스트 얹고, 색 칠하는 것부터 시작하다 보면 자동 레이아웃은 “나중에 배울 것”으로 밀리기 쉽다.

그런데 실무에 들어가면 이야기가 달라진다.

버튼 텍스트가 바뀌었는데 버튼 크기를 일일이 손으로 늘려야 한다. 리스트 아이템을 하나 추가했는데 아래 요소들을 전부 다시 정렬해야 한다. 이런 상황이 반복되면 자동 레이아웃 없이 작업한 대가를 치르는 것이다.

이 글은 자동 레이아웃을 처음 쓰는 사람부터, 쓰긴 쓰는데 제대로 쓰는지 모르겠는 사람까지 한 번에 정리한다.


자동 레이아웃이 뭔가

자동 레이아웃은 프레임 안의 요소들이 규칙에 따라 자동으로 정렬되고 크기가 조절되는 기능이다.

CSS의 Flexbox와 개념이 거의 같다. 개발자와 이야기할 때 “이거 flex로 구현하면 돼요”라고 말할 수 있는 구조가 자동 레이아웃이다.

자동 레이아웃이 적용된 프레임은 이렇게 동작한다.

  • 안에 있는 요소가 늘어나면 프레임도 같이 늘어난다.
  • 요소를 추가하면 자동으로 배치된다.
  • 요소를 삭제하면 나머지가 알아서 채워진다.
  • 패딩과 간격이 고정되어 있어서 수동으로 맞출 필요가 없다.

텍스트 내용이 바뀌어도, 언어가 바뀌어도, 요소가 늘어나도 레이아웃이 유지된다. 디자인 시스템을 만들거나 컴포넌트를 관리할 때 자동 레이아웃 없이는 제대로 된 구조를 만들기 어렵다.


자동 레이아웃 적용하는 방법

적용 방법은 간단하다.

방법 1 – 단축키 오브젝트를 선택하고 Shift + A를 누른다. 바로 자동 레이아웃이 적용된다.

방법 2 – 오른쪽 패널 오브젝트를 선택하면 오른쪽 디자인 패널에 Auto Layout 항목이 보인다. + 버튼을 클릭하면 적용된다.

자동 레이아웃이 적용되면 프레임 이름 옆에 작은 아이콘이 생긴다. 그리고 오른쪽 패널이 바뀐다.


자동 레이아웃 패널 구조 이해하기

적용하고 나면 오른쪽 패널에 여러 옵션이 생긴다. 하나씩 보자.

방향 (Direction)

수평(Horizontal) 또는 수직(Vertical) 중 하나를 선택한다.

  • 수평: 요소들이 가로로 나열된다. 버튼 아이콘 + 텍스트 조합 등에 쓴다.
  • 수직: 요소들이 세로로 쌓인다. 리스트, 카드 내부 구조 등에 쓴다.

Wrap 옵션도 있다. 요소가 넘치면 다음 줄로 자동으로 내려간다. 태그 목록, 뱃지 모음 같은 걸 만들 때 유용하다.


간격 (Gap)

요소 사이의 간격이다. 숫자를 입력하면 모든 요소 사이의 간격이 동일하게 유지된다.

Auto로 설정하면 요소들이 프레임 양쪽 끝으로 밀리면서 균등하게 배치된다. CSS의 justify-content: space-between과 같은 동작이다. 헤더에서 로고와 메뉴를 양쪽 끝에 배치할 때 이 방식을 쓴다.


패딩 (Padding)

프레임의 안쪽 여백이다. 상하좌우를 각각 설정할 수도 있고, 한꺼번에 설정할 수도 있다.

버튼을 만들 때 이게 핵심이다. 텍스트 길이가 달라져도 패딩이 고정되어 있으면 버튼 크기가 자동으로 따라온다. 텍스트를 수정할 때마다 버튼 크기를 손으로 조절할 필요가 없어진다.


크기 조절 방식 (Resizing)

자동 레이아웃 안의 각 요소, 그리고 프레임 자체의 크기를 어떻게 결정할지 설정한다.

세 가지 옵션이 있다.

Fixed – 크기를 고정한다. 내용이 바뀌어도 프레임 크기는 변하지 않는다.

Hug Contents – 안에 있는 내용에 맞게 크기가 결정된다. 텍스트가 늘어나면 프레임도 같이 늘어난다. 버튼, 배지, 태그처럼 내용이 크기를 결정하는 요소에 쓴다.

Fill Container – 부모 프레임의 나머지 공간을 채운다. CSS의 flex: 1과 같다. 좌우로 요소를 배치할 때 한쪽이 고정이고 다른 쪽이 남은 공간을 채워야 할 때 쓴다.

이 세 가지를 언제 쓰는지 모르면 자동 레이아웃이 왜 이상하게 동작하는지 이해하기 어렵다. Hug, Fill, Fixed – 이 세 개 개념을 먼저 잡는 게 자동 레이아웃의 핵심이다.


정렬 (Alignment)

자동 레이아웃 안의 요소들이 어디에 정렬될지 설정한다.

수직 방향 레이아웃이라면 좌/중앙/우 정렬을 선택한다. 수평 방향 레이아웃이라면 상/중앙/하 정렬을 선택한다.

아이콘과 텍스트를 가로로 나란히 둘 때 높이가 다르면 정렬이 어색해 보인다. 이럴 때 중앙 정렬로 맞추면 깔끔해진다.


실무에서 자주 만드는 것들 – 예시로 배우는 자동 레이아웃

예시 1 – 버튼

가장 기본이다.

  1. 텍스트를 먼저 만든다.
  2. 텍스트를 선택하고 Shift + A로 자동 레이아웃 적용.
  3. 패딩 설정. (예: 상하 12, 좌우 20)
  4. 프레임 크기를 Hug Contents로 설정.
  5. 배경색, 모서리 둥글기 설정.

텍스트가 “확인”이든 “결제하기”든 “Submit”이든 버튼이 알아서 맞춰진다. 버튼 크기를 손으로 조절하는 건 이제 과거의 일이다.

아이콘 + 텍스트 버튼이라면? 아이콘과 텍스트를 둘 다 선택하고 Shift + A를 누른다. 방향은 수평, 정렬은 중앙, 간격은 8 정도. 여기에 패딩을 더하면 완성이다.


예시 2 – 리스트 아이템

SNS 피드, 알림 목록, 설정 메뉴 같은 반복되는 아이템 구조다.

  1. 아이템 하나를 먼저 만든다. (아이콘 + 텍스트 + 우측 화살표 등)
  2. 전체를 선택하고 자동 레이아웃 적용.
  3. 방향 수평, 정렬 중앙.
  4. 텍스트 영역은 Fill Container로 설정해서 남은 공간을 채우게 한다.
  5. 패딩 설정 후 완성.

이렇게 만든 아이템을 컴포넌트로 만들면, 텍스트 길이가 달라져도 레이아웃이 흐트러지지 않는다.


예시 3 – 카드 컴포넌트

이미지 + 텍스트 + 버튼이 세로로 쌓이는 구조다.

  1. 이미지 영역, 텍스트 영역, 버튼을 각각 만든다.
  2. 세 요소를 선택하고 자동 레이아웃 적용.
  3. 방향 수직, 간격 설정.
  4. 카드 전체 프레임에 패딩 추가.
  5. 카드 너비를 Fixed로 고정하고, 높이는 Hug로 설정.

이제 텍스트가 길어지면 카드 높이가 알아서 늘어난다. 같은 카드 여러 개를 만들어도 높이가 제각각이 되지 않는다.


예시 4 – 헤더 (로고 + 메뉴)

좌측에 로고, 우측에 메뉴 버튼이 있는 구조.

  1. 로고와 메뉴를 선택하고 자동 레이아웃 적용.
  2. 방향 수평.
  3. 간격을 Auto로 설정. (space-between 효과)
  4. 높이는 Fixed, 너비는 Fill Container 또는 Fixed로.

중간에 뭘 추가해도 양쪽이 자동으로 밀려서 자리를 잡는다.


자동 레이아웃 중첩 (Nested Auto Layout)

실무에서 레이아웃은 단순하지 않다. 자동 레이아웃 안에 자동 레이아웃이 들어가는 구조가 대부분이다.

예를 들어, 카드 그리드를 만든다고 하면.

  • 카드 1개: 내부가 자동 레이아웃 (수직)
  • 카드 가로 한 줄: 카드들이 자동 레이아웃 (수평)
  • 전체 그리드: 줄들이 자동 레이아웃 (수직)

이런 식으로 레이어가 쌓인다. 중첩 구조를 이해하면 아무리 복잡한 레이아웃도 결국 자동 레이아웃의 조합으로 풀린다.

처음엔 복잡해 보이지만, 가장 작은 단위부터 자동 레이아웃을 적용하고 위로 쌓아 올라가는 방식이 맞다.


자동 레이아웃에서 특정 요소만 고정하기

자동 레이아웃 안에 있어도 특정 요소를 고정 위치에 두고 싶을 때가 있다. 예를 들어, 카드 위에 배지나 라벨을 겹쳐 올리는 경우.

해당 레이어를 선택하고 오른쪽 패널에서 Position → Absolute로 설정하면 된다. 자동 레이아웃의 흐름에서 벗어나서 부모 프레임 기준으로 자유롭게 위치를 잡을 수 있다.

이 기능을 모르면 “자동 레이아웃 쓰면 겹쳐 놓을 수가 없다”는 오해를 하게 된다. Absolute 포지션을 알면 자동 레이아웃의 활용 범위가 확 넓어진다.

피그마 자동레이아웃 완벽정리 이미지
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

자주 하는 실수

실수 1 – 그룹에 자동 레이아웃을 적용하려 한다 자동 레이아웃은 프레임에만 적용된다. 그룹을 선택하고 Shift + A를 누르면 자동으로 프레임으로 변환되긴 하지만, 처음부터 프레임으로 작업하는 습관을 들이는 게 낫다.

실수 2 – Hug와 Fill을 반대로 쓴다 버튼에 Fill을 쓰면 버튼이 부모 크기에 맞춰 늘어난다. 텍스트에 Hug를 쓰면 텍스트 크기가 내용에 맞게 고정된다. 어느 요소가 크기를 결정하고, 어느 요소가 따라오는지를 먼저 생각하면 덜 헷갈린다.

실수 3 – 자동 레이아웃 안에서 요소를 드래그로 위치를 바꾸려 한다 자동 레이아웃 안의 요소는 드래그로 위치를 바꿀 수 없다. 레이어 패널에서 순서를 바꾸거나, Absolute 포지션으로 설정해야 한다. 이걸 모르면 “왜 안 움직이지?”로 한참 고생한다.


개발 핸드오프에서 자동 레이아웃이 왜 중요한가

자동 레이아웃으로 만든 컴포넌트는 개발자가 구현하기 쉽다.

피그마에서 자동 레이아웃이 적용된 프레임을 선택하면, Inspect 탭에서 Flexbox 방향, 간격, 패딩 값이 그대로 나온다.

개발자 입장에서는 CSS로 옮기는 게 직관적이다. 자동 레이아웃 없이 손으로 배치한 디자인은 “이 간격이 몇 px이에요?”를 계속 물어봐야 한다.

자동 레이아웃으로 만든 컴포넌트는 그 질문이 줄어든다. 수치가 구조 안에 이미 녹아 있기 때문이다.


처음 쓴다면 이것부터

자동 레이아웃의 모든 옵션을 한꺼번에 외우려 하면 오래 못 간다.

오늘 당장 이것만 해봐라.

버튼 하나를 자동 레이아웃으로 만들어봐라. 텍스트 하나 만들고, Shift + A, 패딩 넣고, Hug로 설정. 그리고 텍스트를 바꿔봐라.

버튼이 따라오는 순간, 감이 온다. 그게 자동 레이아웃이 왜 필요한지를 알게 되는 순간이다.


마무리

자동 레이아웃은 처음엔 번거롭게 느껴진다. 그냥 사각형 그리고 올려두는 게 더 빠른 것 같은 느낌.

그런데 수정이 시작되면 달라진다. 텍스트 바꾸고, 아이템 추가하고, 화면 크기 조정하는 순간부터 자동 레이아웃으로 만든 것과 그냥 만든 것의 차이가 벌어진다.

자동 레이아웃은 처음 만드는 속도를 위한 기능이 아니다. 수정하고 유지하는 비용을 줄이는 기능이다.

한 번만 제대로 익혀두면, 그다음부터는 없이는 못 쓴다.


함께 읽으면 좋은 글

피그마 프로토타입 만들기 – 처음부터 실무까지 한 번에 정리

피그마 프로토타입 완전정복 가이드 이미지

기획서만 보고 개발하면 안 된다는 걸 처음 알게 된 건, 실제로 만들어보고 나서였다.

텍스트로 쓴 플로우와 실제로 화면을 넘기며 경험하는 플로우는 다르다. 버튼을 눌렀을 때 어디로 가야 하는지, 모달이 어떻게 떠야 하는지. 이런 것들은 프로토타입으로 직접 보여줘야 커뮤니케이션 오류가 줄어든다.

피그마에는 프로토타입 기능이 내장돼 있다. 별도 툴 없이, 디자인 파일 안에서 바로 만들 수 있다.

이 글은 피그마 프로토타입을 처음 만드는 사람도 따라올 수 있게 기초부터 정리했다. 그리고 실무에서 자주 쓰는 패턴도 함께 담았다.


프로토타입이란 무엇인가

프로토타입은 실제 서비스처럼 동작하는 것처럼 보이게 만든 시뮬레이션이다.

코드로 만든 게 아니라서 실제로 작동하지는 않는다. 하지만 화면 이동, 버튼 반응, 모달 팝업 같은 인터랙션을 시각적으로 표현할 수 있다.

프로토타입이 필요한 이유는 세 가지다.

첫째, 이해관계자 설득이다. 기획서나 와이어프레임보다 훨씬 직관적으로 전달된다.

둘째, 사용성 검증이다. 실제로 눌러보면 어색한 흐름이 눈에 띈다.

셋째, 개발 커뮤니케이션이다. 개발자가 어떻게 동작해야 하는지 바로 확인할 수 있다.


피그마 프로토타입 기본 구조 이해하기

시작 전에 개념 하나를 잡고 가야 한다.

피그마의 프로토타입은 트리거(Trigger) → 액션(Action) → 애니메이션(Animation) 세 가지로 구성된다.

  • 트리거: 어떤 동작이 인터랙션을 시작하는가 (클릭, 호버, 드래그 등)
  • 액션: 그 동작으로 무슨 일이 일어나는가 (화면 이동, 오버레이 열기 등)
  • 애니메이션: 전환이 어떻게 보이는가 (슬라이드, 페이드 등)

이 세 가지를 조합해서 인터랙션을 만든다.


피그마 프로토타입 패널 열기

디자인 파일에서 오른쪽 상단을 보면 탭이 세 개 있다. Design / Prototype / Inspect

여기서 Prototype 탭을 클릭하면 프로토타입 패널이 열린다.

이 상태에서 레이어나 오브젝트를 선택하면 파란 점(핸들)이 나타난다. 그 점을 드래그해서 다른 프레임에 연결하면 기본 인터랙션이 만들어진다.


Step 1 – 화면 연결하기 (기본 페이지 이동)

가장 기본적인 프로토타입이다. 버튼을 누르면 다음 화면으로 넘어가는 것.

순서:

  1. Prototype 탭을 연다.
  2. 연결할 버튼이나 오브젝트를 선택한다.
  3. 오른쪽에 파란 핸들이 생기면, 그걸 드래그해서 이동할 프레임에 연결한다.
  4. 연결되면 화살표가 생기고, 트리거/액션/애니메이션 설정 창이 뜬다.

기본값은 On Click → Navigate To → Instant다. 대부분의 단순 화면 이동은 이걸로 충분하다.


Step 2 – 트리거 설정하기

트리거는 인터랙션을 시작하는 조건이다. 실무에서 자주 쓰는 트리거는 이 정도다.

트리거설명
On Click클릭(탭)했을 때
On Hover마우스를 올렸을 때
On Drag드래그했을 때
After Delay일정 시간 후 자동으로
Mouse Enter / Leave마우스가 진입/이탈할 때

On Click이 기본이고 가장 많이 쓴다. After Delay는 스플래시 화면처럼 자동으로 넘어가는 화면에 쓴다.


Step 3 – 액션 설정하기

트리거가 발생했을 때 어떤 일이 일어날지 설정한다.

액션설명
Navigate To다른 프레임으로 이동
Open Overlay현재 화면 위에 레이어를 띄움
Swap Overlay열려 있는 오버레이를 다른 것으로 교체
Close Overlay오버레이 닫기
Back이전 화면으로 돌아가기
Scroll To특정 위치로 스크롤

실무에서 가장 많이 쓰는 건 Navigate ToOpen Overlay다.

모달, 바텀시트, 팝업은 전부 Open Overlay로 만든다. 현재 화면을 유지하면서 위에 레이어를 올리는 방식이라 자연스럽다.


Step 4 – 애니메이션 설정하기

화면 전환이 어떻게 보일지 결정한다. 실무에서 주로 쓰는 것만 정리했다.

애니메이션어울리는 상황
Instant빠른 전환이 필요할 때, 혹은 애니메이션 없이 확인할 때
Dissolve페이드 인/아웃. 모달 등장에 자주 씀
Smart Animate두 프레임 간 요소 변화를 자동으로 애니메이션 처리
Slide In/Out화면 좌우 슬라이드 전환. 탭 이동에 적합
Push새 화면이 밀고 들어오는 효과. 앱 뎁스 이동에 씀
Move In/Out방향 지정 가능한 슬라이드

Smart Animate는 피그마 프로토타입의 핵심 기능이다. 두 프레임에 같은 이름의 레이어가 있으면, 그 레이어의 위치/크기/색상 변화를 자동으로 부드럽게 이어준다. 별도 설정 없이 레이어 이름만 맞춰도 꽤 그럴싸한 인터랙션이 만들어진다.


실무에서 자주 쓰는 프로토타입 패턴

패턴 1 – 모달(팝업) 띄우기

  1. 모달 디자인을 별도 프레임으로 만든다.
  2. 모달을 띄울 버튼을 선택하고 → Open Overlay → 모달 프레임 선택.
  3. Position을 Center로 설정.
  4. 배경 딤 처리를 원하면 Background 옵션에서 색상과 투명도 설정.
  5. 모달 닫기 버튼에는 → Close Overlay 연결.

이렇게 하면 모달이 현재 화면 위에 뜨고, 닫기 누르면 사라진다. 배경 화면은 그대로 유지된다.


패턴 2 – 바텀시트 (Bottom Sheet)

모달과 구조는 같다. 위치만 다르다.

  1. 바텀시트 프레임을 화면 하단에 맞게 디자인한다.
  2. Open Overlay → Position을 Bottom으로 설정.
  3. 애니메이션은 **Move In (Bottom)**으로 설정하면 아래서 올라오는 느낌이 난다.

바텀시트는 모바일 앱에서 옵션 선택, 공유 등에 많이 쓰는 패턴이라 자주 만들게 된다.


패턴 3 – 탭(Tab) 전환

하단 탭바를 클릭하면 콘텐츠 영역만 바뀌는 것처럼 보이게 만드는 패턴이다.

방법 1 – 각 탭 상태를 별도 프레임으로 만들고 Navigate To로 연결. 방법 2 – Smart Animate를 활용해 탭 전환 시 요소가 자연스럽게 바뀌도록.

두 프레임에서 탭바를 같은 위치·같은 레이어 이름으로 유지하면, Smart Animate가 탭바는 그대로 두고 콘텐츠만 바뀌는 것처럼 처리해준다.


패턴 4 – 스크롤 프로토타입

콘텐츠가 긴 화면은 스크롤이 되어야 자연스럽다.

  1. 프레임 높이를 실제 콘텐츠 높이로 설정한다 (예: 1200px).
  2. 프레임 선택 후 오른쪽 Prototype 탭에서 Overflow Behavior → Vertical Scrolling 선택.
  3. 프리뷰 모드에서 실제로 스크롤이 된다.

고정 헤더나 하단 탭바를 만들려면, 해당 레이어를 선택하고 Fix position when scrolling 옵션을 켠다.


패턴 5 – 스플래시 화면 자동 전환

앱 시작 시 로고가 보이다가 자동으로 홈 화면으로 넘어가는 것.

  1. 스플래시 프레임을 선택.
  2. 트리거를 After Delay로 설정.
  3. 딜레이 시간을 설정 (보통 2000ms = 2초).
  4. Navigate To → 홈 화면 프레임 연결.

Smart Animate 제대로 쓰는 법

Smart Animate를 쓸 때 잘 안 된다면 대부분 이 두 가지 이유 중 하나다.

1. 레이어 이름이 다르다. Smart Animate는 두 프레임에서 이름이 같은 레이어의 변화를 감지한다. 이름이 다르면 그냥 잘라내고 붙이는 것처럼 처리된다. 레이어 이름을 통일하는 것이 먼저다.

2. 레이어가 그룹이 아니라 프레임이어야 한다. 그룹보다 프레임 안에 레이어를 구성해야 Smart Animate가 더 잘 작동한다. 컴포넌트로 만들어두면 더욱 안정적이다.


프로토타입 미리보기와 공유

미리보기

오른쪽 상단 ▶ 버튼(Present)을 누르면 프로토타입 프리뷰 창이 열린다. 실제로 클릭해보면서 흐름을 확인할 수 있다.

시작 프레임을 지정하려면, 해당 프레임을 선택하고 Prototype 탭 상단 Starting Frame에서 설정한다.

공유

피그마 프로토타입은 링크 하나로 공유할 수 있다.

상단 Share 버튼 → Copy Link → 공유. 링크를 받은 사람은 피그마 계정 없이도 브라우저에서 프로토타입을 볼 수 있다.

기획자나 PM에게 “이 링크 눌러보세요”라고 하면 바로 확인 가능하다. 파일 전달이나 별도 설치 없이 된다는 게 피그마 프로토타입의 큰 장점이다.

피그마 프로토타입 완전정복 가이드 이미지
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

프로토타입 피드백 받기

공유 링크에서 관찰자가 특정 위치에 코멘트를 달 수 있다. 기획자나 개발자가 “이 버튼 눌렀을 때 어디로 가야 해요?”라고 직접 코멘트를 남기면 디자이너가 피그마에서 바로 확인하고 수정할 수 있다.

이메일로 화면 캡처를 주고받던 방식과 비교하면 속도 차이가 크다.


피그마 프로토타입의 한계

솔직하게 짚어두는 게 맞다.

피그마 프로토타입으로 못 하는 것들이 있다.

  • 조건부 로직 (로그인 성공/실패에 따라 다른 화면으로)
  • 실제 데이터 연동
  • 복잡한 제스처 인터랙션 (스와이프, 핀치 줌 등 정밀한 것)
  • 애니메이션 타이밍 세밀한 조정

이런 고도화된 인터랙션이 필요하다면 ProtopieFramer를 쓰는 게 낫다.

하지만 일반적인 앱/웹 서비스의 플로우 검증, 팀 내 커뮤니케이션, 사용성 테스트 수준에서는 피그마 프로토타입으로 충분히 된다.

처음부터 Protopie를 배울 필요는 없다. 피그마 프로토타입부터 익히고, 필요한 순간이 오면 그때 넓혀가는 게 효율적이다.


처음 만든다면 이렇게 시작해라

이것저것 한꺼번에 하려고 하면 오히려 더디다.

첫 번째 프로토타입은 딱 이 세 가지만 한다.

  1. 화면 3~4개 준비한다.
  2. 버튼마다 Navigate To로 다음 화면 연결한다.
  3. 애니메이션은 Slide In으로 통일한다.

이것만 해도 흐름이 보인다. 모달, Smart Animate, 스크롤은 그다음에 하나씩 추가하면 된다.

프로토타입은 완성도가 목적이 아니다. “이렇게 동작합니다”를 빠르게 보여주는 게 목적이다.


마무리

피그마 프로토타입은 배우는 데 오래 걸리지 않는다. 하루면 기본 흐름은 만들 수 있고, 일주일이면 실무에서 쓸 수 있는 수준이 된다.

처음엔 연결하는 것만으로도 충분하다. 거기서 하나씩 쌓아가면 된다.

프로토타입 하나가 회의 시간을 줄이고, 수정 횟수를 줄인다. 그게 프로토타입을 만드는 이유다.

함께 읽으면 좋은 글

어도비 XD vs 피그마 – 실무 디자이너가 직접 비교한다

피그마 VS 어도비XD 핵심비교 이미지

디자인 툴을 처음 고를 때 고민하게 된다. 어도비 XD냐, 피그마냐.

둘 다 UI/UX 디자인 툴이고, 둘 다 프로토타이핑이 된다. 겉으로만 보면 비슷해 보인다.

나는 XD로 시작했다. 어도비 제품군을 쓰고 있었고, 연동이 편할 것 같아서였다. 그리고 1년 정도 쓰다가 피그마로 넘어왔다.

이 글은 두 툴을 모두 실무에서 써본 경험을 바탕으로 쓴다. 어느 쪽이 무조건 낫다는 게 아니라, 어떤 상황에서 어떤 툴이 더 맞는지 정리하는 게 목적이다.


먼저 알아야 할 것 – 어도비 XD의 현재 상황

비교를 시작하기 전에 짚고 넘어가야 할 게 있다.

어도비는 2023년에 XD의 신규 기능 개발을 사실상 중단했다.

어도비가 피그마 인수를 시도했다가 규제 문제로 무산된 이후, XD의 방향성이 애매해졌다. 지금도 쓸 수는 있지만, 업데이트가 멈춘 툴이다.

이 사실 하나만으로도 신규 디자이너에게 XD를 추천하기 어렵다. 하지만 현재 XD를 쓰고 있거나, 팀에서 XD를 쓰는 경우라면 이 비교가 여전히 의미 있다.


1. 협업 – 가장 큰 차이

피그마

피그마는 처음부터 웹 기반 협업 툴로 설계됐다. 설치 없이 브라우저에서 바로 열린다. 링크 하나 공유하면 팀원 모두가 같은 파일을 실시간으로 볼 수 있다.

실무에서 어떤 의미냐면, 개발자한테 “피그마 링크 여기 있어요” 한 마디로 끝난다. 별도 에셋 내보내기, 파일 전달 없이 링크 하나로 스펙 확인이 가능하다.

같은 파일에서 여러 명이 동시에 작업하는 것도 된다. 커서가 보이고, 누가 어디를 보고 있는지 실시간으로 표시된다. 리모트 작업이 많은 팀이라면 이게 결정적이다.

어도비 XD

XD는 기본적으로 로컬 파일 기반이다. 공유 기능이 없는 건 아니지만, 피그마처럼 실시간 동시 편집은 안 된다.

코멘트 기능도 있고, 공유 링크도 만들 수 있다. 하지만 파일을 직접 넘기거나 클라우드 문서로 저장해서 공유하는 방식이라 팀이 커질수록 버전 관리가 복잡해진다.

결론: 협업 관점에서는 피그마가 압도적으로 편하다. 팀 단위로 일한다면 이것만으로도 피그마를 선택할 이유가 충분하다.


2. 학습 곡선 – 처음 쓰는 사람 기준

어도비 XD

어도비 제품을 쓴 경험이 있다면 XD는 진입이 쉽다. 포토샵, 일러스트레이터의 인터페이스 구조와 비슷한 부분이 많다. 단축키도 어도비 계열과 겹치는 게 있어서 손에 익는 속도가 빠르다.

UI 자체도 심플하고, 처음 켜도 뭘 어디서 찾아야 할지 직관적으로 파악된다.

피그마

피그마는 처음엔 낯설 수 있다. 특히 컴포넌트, 오토레이아웃, 베리언트 개념은 처음 접하면 헷갈린다. 익숙해지는 데 시간이 걸린다.

그런데 한 번 익히면 이야기가 달라진다. 오토레이아웃 하나만 제대로 써도 작업 속도가 눈에 띄게 빨라진다. 초반 진입 비용을 내고 나면, 그다음부터는 피그마가 더 효율적이다.

결론: 단기적으로는 XD가 쉽다. 하지만 장기적으로 실무 효율은 피그마가 높다.


3. 컴포넌트와 디자인 시스템

실무에서 디자인 시스템을 만들거나 관리하는 작업이 많다면 이 부분이 중요하다.

피그마

피그마의 컴포넌트 시스템은 현재 디자인 툴 중에서 가장 완성도가 높다.

베리언트(Variants) 기능으로 하나의 컴포넌트 안에 여러 상태를 묶을 수 있다. 버튼 하나를 만들 때 Default, Hover, Disabled, Active를 한 컴포넌트 안에 구성하고, 인스턴스에서 속성 하나만 바꿔서 상태를 전환할 수 있다.

팀 라이브러리 기능도 강력하다. 공통 컴포넌트를 라이브러리로 발행하면 팀 전체가 같은 컴포넌트를 끌어다 쓸 수 있다. 라이브러리에서 컴포넌트를 수정하면 사용하는 파일에 업데이트 알림이 간다.

디자인 시스템을 만들고 팀 전체가 쓴다면, 피그마가 훨씬 유리하다.

어도비 XD

XD도 컴포넌트 개념이 있다. 마스터 컴포넌트를 수정하면 인스턴스가 같이 바뀐다. 하지만 피그마의 베리언트처럼 여러 상태를 한 컴포넌트 안에 묶는 기능은 제한적이다. 상태별로 컴포넌트를 따로 만들어야 하는 경우가 많아서, 파일이 복잡해지면 관리가 어려워진다.

결론: 컴포넌트와 디자인 시스템 관리는 피그마가 훨씬 체계적이다.


4. 프로토타이핑

둘 다 프로토타이핑 기능이 있다. 화면 간 연결, 트랜지션 설정, 인터랙션 구성이 가능하다.

어도비 XD

XD의 프로토타이핑은 직관적이다. Auto-animate 기능이 있어서, 두 화면 사이의 요소 변화를 자동으로 애니메이션으로 만들어준다. 별도 설정 없이도 꽤 그럴싸한 인터랙션이 나온다.

처음 프로토타입을 만드는 사람에게는 XD가 더 쉽게 느껴질 수 있다.

피그마

피그마도 프로토타이핑이 된다. 스마트 애니메이트 기능이 있어서 XD의 Auto-animate와 비슷한 결과를 낼 수 있다. 인터랙션 트리거 설정이 더 세밀하고, 조건부 인터랙션도 가능하다.

하지만 복잡한 인터랙션을 구현하다 보면 한계가 있다. 피그마든 XD든, 고도화된 프로토타입은 Protopie 같은 전문 툴을 쓰는 게 낫다.

결론: 간단한 프로토타입은 둘 다 비슷하다. XD가 약간 더 쉽고, 피그마가 더 세밀하다.


5. 플러그인과 확장성

피그마

피그마의 플러그인 생태계는 압도적이다. 커뮤니티에 수천 개의 플러그인이 있고, 무료인 것도 많다.

자주 쓰는 것들만 꼽아도:

  • Unsplash – 이미지 바로 삽입
  • Iconify – 아이콘 라이브러리 전체 접근
  • Figma to Code – 코드 추출
  • Content Reel – 더미 텍스트/이미지 자동 채우기
  • Stark – 접근성(Accessibility) 검사

혼자 쓰든 팀이 쓰든, 작업에 필요한 기능 대부분을 플러그인으로 보완할 수 있다.

어도비 XD

XD도 플러그인이 있다. 하지만 피그마에 비하면 수도 적고, 업데이트도 느리다. XD 개발이 멈추면서 플러그인 생태계도 같이 정체됐다.

결론: 확장성은 피그마가 압도적으로 유리하다.


6. 가격

피그마

  • 무료 플랜: 파일 3개 제한, 협업자 무제한
  • Professional: 월 $12 (연간 결제 기준)
  • Organization: 월 $45

무료 플랜만으로도 개인 작업이나 소규모 프로젝트는 충분하다. 처음 써보는 사람이라면 돈 들이지 않고 시작할 수 있다.

어도비 XD

XD는 크리에이티브 클라우드 구독에 포함돼 있다. 어도비 전체 구독을 쓰고 있다면 추가 비용 없이 쓸 수 있다.

반대로, XD만 단독으로 쓰려면 별도 구독이 필요하고 가성비가 떨어진다. 포토샵이나 일러스트레이터를 같이 쓰는 사람이라면 XD도 함께 쓰는 게 나쁘지 않다.

결론: 개인이라면 피그마 무료 플랜이 낫다. 어도비 전체 구독을 쓰는 사람이라면 XD도 선택지가 된다.


7. 개발 핸드오프

디자이너가 개발자에게 스펙을 전달하는 과정이다. 실무에서 빈번하게 일어나는 일이고, 여기서 마찰이 생기면 프로젝트 전체가 느려진다.

피그마

피그마는 링크 하나로 끝난다. 개발자가 링크를 열면 레이어 클릭만으로 폰트 크기, 색상, 간격, CSS 값이 다 나온다. 별도 에셋 내보내기 없이도 이미지, 아이콘을 개발자가 직접 추출할 수 있다.

개발자가 피그마 링크를 받으면 “여기 다 있네요”라고 한다. 그게 피그마 핸드오프의 실제 경험이다.

어도비 XD

XD도 공유 링크로 스펙을 전달할 수 있다. 하지만 실시간 업데이트 구조가 아니라서, 디자인이 바뀔 때마다 다시 공유해야 한다. 개발자 입장에서는 “최신 파일이 맞나요?”를 확인해야 하는 상황이 생긴다.

결론: 핸드오프 효율도 피그마가 낫다. 특히 수정이 잦은 프로젝트라면 차이가 크다.


그래서 나는 왜 XD에서 피그마로 넘어왔나

처음에 XD를 쓴 건 어도비를 이미 쓰고 있었기 때문이다. 진입 장벽이 낮았고, 혼자 작업할 땐 불편함을 못 느꼈다.

전환점은 팀 프로젝트였다. 개발자한테 파일 전달하고, 수정되면 다시 전달하고, 버전이 뒤섞이는 상황이 반복됐다. 그 과정에서 “피그마는 링크 하나로 된다”는 말을 듣고 써봤다.

처음 한 달은 어색했다. 오토레이아웃 개념이 낯설었고, 단축키도 다시 외워야 했다.

그런데 한 달 지나고 나서는 XD로 돌아가고 싶지 않았다.

핸드오프가 쉬워졌고, 팀원이 같은 파일에서 같이 작업하는 게 당연해졌다. 컴포넌트를 한 번 만들어두면 수정이 전체에 적용됐다.

툴이 바뀌면 작업 방식이 바뀐다. 그리고 작업 방식이 바뀌면 결과물의 속도와 품질도 달라진다.


XD를 계속 써도 괜찮은 경우

피그마가 무조건 낫다고 말하지는 않겠다. 이런 경우라면 XD도 선택지가 된다.

  • 어도비 전체 구독을 이미 쓰고 있고, 일러스트레이터·포토샵 연동이 중요한 경우
  • 혼자 작업하고 협업이 거의 없는 경우
  • 현재 팀 전체가 XD를 쓰고, 전환 비용이 큰 경우
  • 어도비 XD로 이미 구축된 디자인 시스템이 있는 경우

다만 신규 프로젝트를 새로 시작하거나, 툴을 처음 배우는 상황이라면 피그마부터 시작하는 게 맞다.

피그마 VS 어도비XD 핵심비교 이미지
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

정리

항목어도비 XD피그마
협업△ 파일 공유 방식✅ 실시간 동시 편집
학습 난이도✅ 어도비 사용자에게 쉬움△ 초반 진입 비용 있음
컴포넌트/디자인 시스템△ 기본 수준✅ 베리언트, 팀 라이브러리
프로토타이핑✅ 직관적✅ 세밀함
플러그인△ 제한적✅ 생태계 압도적
가격△ 어도비 구독 포함✅ 무료 플랜 있음
개발 핸드오프△ 수동 공유 방식✅ 링크 하나로 완결
향후 업데이트❌ 사실상 중단✅ 지속 개발 중

결론은 하나다. 지금 새로 시작한다면 피그마를 쓰는 게 맞다. XD는 이미 쓰고 있는 사람에게는 당장 버릴 이유가 없지만, 앞으로를 생각하면 피그마로 옮기는 게 낫다.

툴은 수단이다. 하지만 어떤 수단을 쓰느냐는 결과에 영향을 준다.


함께 읽으면 좋은 글

피그마 단축키 총정리 – 실무에서 진짜 쓰는 것만 모았다

피그마 실무단축기 모음 이미지

피그마를 처음 쓸 때는 마우스로 하나하나 메뉴를 눌렀다. 그게 자연스럽다고 생각했다.

그런데 옆자리 시니어 디자이너 화면을 보다가 충격을 받았다. 손이 거의 안 움직이는데 작업이 쌓이고 있었다.

단축키를 아는 사람과 모르는 사람의 속도 차이는, 실력 차이보다 먼저 눈에 보인다.


왜 단축키가 중요한가

디자인 작업은 반복의 연속이다. 레이어 선택, 이름 바꾸기, 컴포넌트 복사, 프레임 만들기. 이 동작을 하루에 수백 번 한다.

마우스를 움직이고 메뉴를 찾는 0.5초가 쌓이면, 하루 기준으로 꽤 많은 시간이 날아간다.

단축키는 그 흐름을 지키는 도구다. 생각하면서 손이 따라오는 상태, 그게 목표다.


실무에서 진짜 자주 쓰는 단축키만 모았다

전체 단축키 목록은 피그마 공식 문서에 다 있다. 하지만 그걸 처음부터 외우려 하면 오래 못 간다.

여기서는 실제 작업 흐름에서 반복되는 동작 위주로 정리했다.


1. 기본 조작 – 가장 먼저 익혀야 할 것들

단축키기능
V선택 도구 (Select)
F프레임 만들기
R사각형
T텍스트
K스케일 도구
H핸드 도구 (화면 이동)
Ctrl + Z / Cmd + Z실행 취소
Ctrl + Shift + Z / Cmd + Shift + Z다시 실행

이 정도는 첫날부터 외워두는 게 맞다. 특히 F로 프레임 만드는 것, 처음엔 사각형이랑 헷갈리는데 프레임은 컴포넌트와 오토레이아웃의 기반이라 개념부터 구분해두는 게 중요하다.


2. 선택과 이동 – 레이어 다루는 속도를 높이는 단축키

단축키기능
Ctrl + A / Cmd + A전체 선택
Enter그룹/프레임 내부 진입
Esc선택 해제 / 상위 레이어로 이동
Ctrl + Click / Cmd + Click중첩된 레이어 직접 선택
Alt + 드래그복사하면서 이동
Ctrl + D / Cmd + D마지막 복사 반복

Ctrl + D는 아는 사람만 쓰는 단축키다. 같은 간격으로 요소를 반복 배치할 때 진가가 드러난다. 한 번 복사해서 위치 잡고, Ctrl + D 계속 누르면 된다.


3. 정렬과 배치 – 픽셀 맞추는 시간을 줄여준다

단축키기능
Alt + A왼쪽 정렬
Alt + D오른쪽 정렬
Alt + W상단 정렬
Alt + S하단 정렬
Alt + H수평 중앙 정렬
Alt + V수직 중앙 정렬

마우스로 정렬 패널 눌러서 맞추던 방식에서 벗어나면 여러 오브젝트 정렬이 1초도 안 걸린다.


4. 컴포넌트와 스타일 – 실무 핵심 영역

단축키기능
Ctrl + Alt + K / Cmd + Option + K컴포넌트 만들기
Ctrl + Alt + B / Cmd + Option + B오토레이아웃 적용
Ctrl + G / Cmd + G그룹 만들기
Ctrl + Shift + G / Cmd + Shift + G그룹 해제
Ctrl + E / Cmd + E선택한 레이어 병합 (flatten)

오토레이아웃(Ctrl + Alt + B)은 외워두면 무조건 쓴다. 버튼 패딩 맞추거나, 카드 컴포넌트 만들 때 손이 먼저 가야 하는 단축키다.


5. 뷰 조작 – 화면을 빠르게 다루는 방법

단축키기능
Ctrl + 0 / Cmd + 0전체 보기 (줌 아웃 맞춤)
Ctrl + 1 / Cmd + 1100% 줌
Ctrl + Shift + H / Cmd + Shift + H선택 오브젝트에 맞게 줌
Space + 드래그캔버스 이동
Ctrl + \`` / Cmd + “UI 패널 숨기기/보이기

`Ctrl + “는 프레젠테이션 모드 바로 전에 쓰기 좋다. 패널 숨기면 실제 디자인만 보여서 리뷰할 때 깔끔하다.


6. 텍스트 작업 – 타이포 잡을 때 쓰는 단축키

단축키기능
Ctrl + B / Cmd + B볼드
Ctrl + I / Cmd + I이탤릭
Ctrl + U / Cmd + U밑줄
Alt + 방향키 좌/우자간(tracking) 조절
Alt + 방향키 상/하행간(leading) 조절

텍스트 속성은 오른쪽 패널에서 직접 수치 입력하는 경우가 많지만, 자간·행간 조절은 Alt+방향키로 감각적으로 잡는 게 더 빠를 때가 많다.


7. 검사와 측정 – 개발 핸드오프 전에 확인할 때

단축키기능
Alt (오브젝트 위에 호버)오브젝트 간 거리 측정
Ctrl + P / Cmd + PQuick actions (전체 검색)
Ctrl + Shift + E / Cmd + Shift + E에셋 내보내기
Ctrl + Shift + C / Cmd + Shift + C링크 복사

Alt 키 호버는 처음 알았을 때 진짜 편했다. 레이어 선택하고 다른 오브젝트 위에 Alt 올려두면 거리가 바로 나온다. 개발자한테 스펙 전달할 때 캡처해서 붙이기 딱 좋다.


8. 플러그인과 퀵 액션 – 속도를 한 단계 올리는 기능

단축키기능
Ctrl + / / Cmd + /퀵 액션 (메뉴 검색)
Ctrl + Alt + P / Cmd + Option + P마지막 플러그인 다시 실행

Ctrl + /는 단축키를 모를 때 쓰는 단축키다. 텍스트로 원하는 기능을 검색할 수 있어서, 처음 피그마 쓸 때 특히 유용하다.


실무에서 이렇게 쓴다 – 작업 흐름 예시

주니어 시절에 가장 많이 하는 작업 중 하나가 카드 컴포넌트 반복 배치다.

예전 방식: 사각형 그리기 → 복사 → 위치 맞추기 → 복사 → 위치 맞추기…

지금 방식:

  1. F로 프레임 만들기
  2. 내부 요소 배치 후 Ctrl + Alt + B로 오토레이아웃 적용
  3. Alt + 드래그로 하나 복사 후 Ctrl + D 반복
  4. Alt + H로 수평 정렬 끝

이렇게 하면 시간도 줄지만, 수정도 쉬워진다. 오토레이아웃이 걸려 있으면 안에 내용이 바뀌어도 레이아웃이 알아서 따라온다.

피그마 실무단축기 모음 이미지
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

자주 하는 실수 – 주의할 것

그룹과 프레임을 섞어 쓰는 경우 처음에 Ctrl + G로 그룹만 쓰다 보면, 나중에 오토레이아웃이나 컴포넌트로 전환할 때 손이 더 간다. 프레임(F)으로 만드는 습관을 처음부터 들이는 게 낫다.

레이어 이름을 안 바꾸는 경우 단축키는 아니지만, 더블클릭으로 레이어 이름 바꾸는 걸 귀찮다고 미루면 파일이 조금만 커져도 못 찾는다. 핸드오프할 때도 개발자가 레이어 이름 보고 구조를 파악하기 때문에, 이름 정리는 습관이 되어야 한다.


단축키 빠르게 외우는 방법

한꺼번에 외우려 하면 안 된다.

1단계 – 오늘부터 이것만 V, F, T, R, Ctrl + D, Ctrl + Alt + B 이 여섯 개만 일주일 써보면 손에 붙는다.

2단계 – 익숙해지면 추가 정렬 단축키(Alt + A/D/W/S/H/V)와 Alt 호버 측정 추가.

3단계 – 워크플로우에 맞게 개발 핸드오프 작업이 많다면 내보내기, 링크 복사 위주로. 컴포넌트 작업이 많다면 컴포넌트·오토레이아웃 단축키 중심으로.


마무리

단축키는 피그마를 잘하는 게 아니라, 방해받지 않고 생각에 집중하기 위한 도구다.

처음부터 다 외울 필요는 없다. 오늘 작업하면서 한 번이라도 쓴 단축키, 거기서부터 시작하면 된다.

쌓이면 달라진다.


함께 읽으면 좋은 글

클로드 AI 무료로 이런 것까지 된다고? 진짜 쓸 수 있는 핵심 기능 4가지

클로드 무료플랜 핵심기능 4가지

무료라서 얕보다가 놀랐다

AI 툴을 꾸준히 써온 지 꽤 됐다. 디자이너로 25년을 일하면서 새로운 툴이 나올 때마다 일단 써보는 편인데, 클로드는 처음에 그냥 “또 다른 챗봇이겠지” 하고 넘겼다.

그런데 어느 날 클라이언트가 “클로드로 작업 정리해봤는데 괜찮더라”고 해서 다시 들여다봤다. 무료 플랜으로 시작해서 이것저것 눌러봤는데, 생각보다 훨씬 많은 게 됐다.

특히 2026년 초에 무료 플랜에도 커넥터 기능이 풀리면서 쓸 수 있는 폭이 넓어졌다. 유료 전환을 고민 중이라면, 이 기능들부터 제대로 써보고 결정해도 늦지 않는다.


1. 커넥터 기능 — 외부 앱을 연결해 실제 업무를 처리한다

커넥터가 뭔가

커넥터는 클로드와 외부 앱을 연결하는 기능이다. 노션, 피그마, 구글 드라이브, 지라 같은 툴을 연결해두면, 클로드가 그 안에 있는 데이터를 읽거나 작업을 수행할 수 있다.

쉽게 말하면, 클로드가 내 업무 툴에 직접 접근할 수 있게 되는 것이다. 이전에는 챗봇에 내용을 복붙해서 넣고, 결과를 다시 복붙해서 써야 했다면, 커넥터가 연결되면 그 중간 과정이 줄어든다.

디자이너 입장에서 이렇게 쓴다

피그마 커넥터를 연결하면, 피그마 파일 구조를 클로드가 읽을 수 있다. 예를 들어 “이 피그마 파일에서 컴포넌트 구조 분석해줘”, “이 화면의 UX 흐름 정리해줘” 같은 요청을 할 수 있다.

노션 커넥터를 연결하면 더 직접적으로 쓸 수 있다. 나는 클라이언트별로 노션에 프로젝트 문서를 관리하는데, “이 프로젝트 노션 페이지 보고 다음 미팅 안건 정리해줘”가 된다.

25년 일하면서 가장 피곤했던 게 반복되는 문서 작업이었다. 커넥터가 생기면서 그 부분이 실질적으로 줄었다.

무료 플랜에서 쓸 수 있는 커넥터

2026년 초 업데이트로 무료 플랜에도 커넥터 기능이 열렸다. 연결 가능한 앱의 종류나 사용 횟수에는 제한이 있을 수 있지만, 핵심 기능 자체는 무료로 쓸 수 있다.


2. 아티팩트 기능 — 결과물을 바로 눈으로 확인한다

아티팩트가 뭔가

클로드가 뭔가를 만들었을 때, 그걸 채팅창 텍스트로만 보여주는 게 아니라 별도 창에서 바로 렌더링해서 보여주는 기능이다.

HTML 코드를 짜달라고 하면, 코드 텍스트와 함께 실제로 어떻게 보이는지 미리보기가 오른쪽에 뜬다. 인터랙티브 차트를 만들면 실제로 클릭해볼 수 있다. 마크다운 문서를 작성하면 실제 레이아웃으로 바로 확인된다.

디자이너 입장에서 이렇게 쓴다

나는 클라이언트 제안서를 빠르게 초안 잡을 때 많이 쓴다. “이 서비스 랜딩페이지 와이어프레임 HTML로 만들어줘”라고 하면, 아티팩트로 바로 확인이 된다. 완성본은 아니지만 방향성 확인용으로는 충분하다.

프리랜서 특성상 빠른 제안이 수주에 직결된다. 클라이언트 미팅 전에 러프한 방향 시안을 보여주는 용도로 쓰면 속도가 확 달라진다.

코드를 직접 짜는 디자이너가 아니더라도, 아티팩트로 인터랙션 프로토타입을 빠르게 만들어볼 수 있다는 게 꽤 실용적이다. 피그마로 넘어가기 전에 로직 검증용으로 쓰기 좋다.

실제로 만들 수 있는 것들

  • 인터랙티브 HTML 페이지
  • 데이터 시각화 차트
  • SVG 일러스트
  • 마크다운 문서
  • 간단한 계산기나 폼

3. 프로젝트 기능 — 클로드가 내 업무 맥락을 기억한다

프로젝트가 뭔가

일반 채팅은 대화가 끝나면 맥락이 초기화된다. 다음에 또 클로드에게 뭔가를 물어보면, 처음부터 설명을 다시 해야 한다.

프로젝트 기능은 이 문제를 해결한다. 프로젝트 안에서는 내가 설정해둔 지침과 업로드한 문서가 모든 대화에 유지된다. 클로드가 내 업무 방식, 클라이언트 특성, 자주 쓰는 표현 등을 매번 설명하지 않아도 되는 것이다.

디자이너 입장에서 이렇게 쓴다

나는 클라이언트별로 프로젝트를 만들어 쓴다.

예를 들어 금융 앱 클라이언트 프로젝트를 만들면, 그 안에 이런 것들을 설정해둔다.

  • 클라이언트 업종과 타깃 유저 정보
  • 브랜드 톤앤매너 가이드
  • 이 클라이언트가 자주 쓰는 용어
  • 이전 피드백에서 중요했던 포인트

그러면 그 프로젝트 안에서 “이 화면 카피 써줘”라고 하면, 금융 서비스에 맞는 신뢰감 있는 말투로, 이 클라이언트의 톤에 맞게 써준다.

매번 컨텍스트를 다시 세팅하는 시간이 없어진다. 25년 동안 클라이언트 관리를 해오면서 가장 시간을 많이 잡아먹은 게 “이 클라이언트는 어떤 사람이었지, 뭘 중요하게 봤지”를 매번 다시 정리하는 것이었다. 프로젝트 기능이 그걸 대신해준다.

이렇게 세팅하면 효과가 더 좋다

  • 클라이언트 브리프 PDF를 문서로 업로드해두기
  • 내가 자주 쓰는 UX 원칙이나 판단 기준을 지침에 적어두기
  • 피드백 히스토리를 메모로 추가해두기

세팅이 잘 될수록 결과물 퀄리티가 올라간다.


4. 확장 사고 기능 — 복잡한 문제를 깊게 파고든다

확장 사고가 뭔가

일반적인 AI 응답은 질문을 받으면 바로 대답한다. 빠르지만, 복잡한 문제에는 얕게 답할 때가 있다.

확장 사고(Extended Thinking)는 대답하기 전에 먼저 생각을 충분히 전개한다. 시간이 조금 더 걸리지만, 결과가 다르다. 단순한 답이 아니라 여러 가능성을 검토하고, 맥락을 고려하고, 반례까지 생각한 다음에 답이 나온다.

디자이너 입장에서 이렇게 쓴다

일상적인 카피 작업이나 간단한 정보 정리는 일반 모드로 충분하다. 그런데 아래 같은 상황에서는 확장 사고를 켠다.

UX 의사결정 검토가 필요할 때. “이 결제 플로우에서 단계를 줄이면 전환율이 올라갈 텐데, 반대로 어떤 리스크가 있을까?”처럼 복합적인 판단이 필요한 질문에 확장 사고로 물어보면, 트레이드오프를 꽤 정교하게 정리해준다.

클라이언트 설득 논리가 필요할 때. 디자인 결정을 클라이언트에게 설명해야 할 때, “왜 이 방향이 맞는가”를 논리적으로 풀어야 한다. 확장 사고로 “이 디자인 결정의 근거를 UX 원칙 기반으로 설명해줘”라고 하면, 단순 설명이 아니라 반박을 예상한 구조로 나온다.

경쟁사 분석 정리가 필요할 때. 여러 앱의 패턴을 비교 분석하고 인사이트를 도출하는 작업에서 확장 사고를 쓰면, 표면적인 비교가 아니라 구조적인 차이까지 짚어준다.


네 가지 기능 정리

기능핵심 역할쓸 때효과
커넥터외부 앱 연결노션·피그마·드라이브 연동복붙 작업 제거
아티팩트결과물 즉시 렌더링HTML·차트·문서 생성바로 보고 수정 가능
프로젝트업무 맥락 유지클라이언트별 세팅설명 반복 없음
확장 사고깊은 분석복잡한 판단·전략정교한 결과

클로드 무료플랜 핵심기능 4가지

유료로 넘어가야 할 시점

솔직하게 말하면, 무료 플랜에도 제약은 있다. 메시지 사용량에 제한이 있고, 사용량이 많은 시간대에는 응답이 느려질 수 있다. 하루에 가볍게 몇 번 쓰는 수준이라면 무료로 충분하지만, 업무에 적극적으로 통합하기 시작하면 금방 한계가 온다.

커넥터 기능도 무료 플랜에서는 연결 가능한 앱의 종류나 사용 횟수가 제한될 수 있다.

그래도 일단 무료로 써보고 판단하는 게 맞다. 유료 전환 전에 이 기능들을 충분히 써봐야 어디가 병목인지 보인다.


마치며

25년 동안 디자인 툴의 변화를 봐왔다. 포토샵이 나왔을 때, 일러스트레이터가 나왔을 때, 피그마가 나왔을 때, 그리고 지금 AI 툴이 나온 것까지.

매번 “이게 진짜 디자이너 일을 바꿀까?”라는 질문이 있었다. 피그마는 정말 바꿨다. AI도 비슷한 변곡점에 있다고 느낀다.

클로드 무료 플랜의 이 네 가지 기능은, 단순히 “AI한테 물어보는 것” 수준이 아니다. 업무 흐름 자체를 바꿀 수 있는 것들이다. 가볍게 시작해보고, 어디에 잘 맞는지 직접 확인해보는 걸 권한다.


이 글이 도움이 됐다면, AI 툴을 업무에 도입하려는 동료 디자이너에게 공유해 주세요.

함께 읽으면 좋은 글

피그마 쓰면서 진짜 몰랐으면 손해였을 플러그인 3가지

피그마 플러그인 추천

피그마 플러그인, 제대로 쓰고 있나

피그마를 쓰고 있지만, 솔직히 기본 기능만 썼다. 컴포넌트 만들고, 오토레이아웃 쓰고, 프로토타입 연결하는 정도. 플러그인은 뭔가 복잡할 것 같고, 배우기 귀찮다는 생각이 앞섰다.

그런데 어느 순간부터 해외 디자이너들 작업물을 보면서 의문이 생기기 시작했다. 분명히 나보다 속도가 빠른데, 퀄리티도 높다. 어떻게 하는 건지 파고들었더니 대부분 플러그인 활용 차이였다.

20년 넘게 디자이너로 일하면서 배운 게 하나 있다면, 시간이 곧 돈이라는 것이다. 반복 작업에 시간을 쏟을수록 정작 중요한 의사결정과 크리에이티브에 쓸 에너지가 줄어든다. 이 글에서 소개하는 플러그인 3가지는 그 반복을 대신 해주는 도구들이다.


1. Maps to Design — 주소 하나로 지도를 바로 피그마에 넣는다

이게 왜 필요한가

부동산 서비스, 배달 앱, 여행 플랫폼, 로컬 커머스. 지도가 들어가는 UI는 생각보다 훨씬 많다. 그런데 지금까지 디자인에 지도를 넣으려면 어떻게 했나? 구글 맵 캡처해서 넣거나, 스크린샷 잘라서 넣거나, 그냥 회색 직사각형으로 때웠다.

Maps to Design은 그 과정을 없애버린다.

어떻게 작동하나

사용 방법은 단순하다.

  1. 피그마에서 Maps to Design 플러그인 실행
  2. 원하는 주소 또는 좌표 입력
  3. 지도 스타일 선택 (라이트, 다크, 새틀라이트 등)
  4. 피그마 캔버스에 바로 삽입

결과물은 그냥 이미지가 아니라 실제 지도 데이터 기반의 벡터 레이어에 가깝게 들어온다. 줌 레벨도 조정 가능하고, 스타일도 커스터마이즈할 수 있다.

실무에서 이렇게 썼다

얼마 전에 부동산 스타트업 랜딩페이지 작업을 했다. 매물 위치를 보여주는 섹션이 있었는데, 클라이언트가 “실제 동네 느낌이 나야 한다”고 했다. 예전이라면 구글 맵 캡처를 여러 장 찍어서 포토샵에서 색 보정하고, 피그마에 옮기고, 다시 맥락에 맞게 자르고 하는 과정을 거쳤을 것이다.

Maps to Design을 쓰니까 주소 입력하고 스타일 선택하는 데 3분이면 됐다. 다크 모드 버전도 바로 만들었다.

특히 유용한 케이스

  • 배달/라이드헤일링 앱: 출발지-도착지 경로 UI 목업
  • 부동산/숙박 서비스: 매물 위치 표시 디자인
  • 로컬 이벤트 페이지: 행사 장소 지도 삽입
  • 투자 유치용 덱: 서비스 커버리지 시각화

2. HTML to Design — URL 하나면 웹사이트 전체가 레이어로

이게 왜 필요한가

경쟁사 분석을 해야 할 때, 레퍼런스를 정리해야 할 때, 클라이언트가 “이 사이트 참고해서 비슷하게 만들어줘”라고 할 때.

지금까지는 스크린샷 찍고, 잘라내고, 레이어 위에 올려놓고, 투명도 낮춰서 트레이싱하거나 참고했다. 번거롭고, 해상도도 안 맞고, 반응형은 따로 캡처해야 했다.

HTML to Design은 URL만 넣으면 그 웹사이트의 HTML과 CSS 구조를 피그마 레이어로 변환해준다.

어떻게 작동하나

  1. HTML to Design 플러그인 실행
  2. URL 입력
  3. 변환 옵션 선택 (페이지 전체 / 섹션 지정)
  4. 피그마 레이어 트리로 가져오기

가져온 결과를 보면 꽤 놀랍다. 텍스트는 텍스트 레이어로, 이미지는 이미지 레이어로, 컨테이너는 프레임으로 분리되어 들어온다. 완벽하게 1:1로 옮겨지진 않지만, 작업 출발점으로 쓰기엔 충분하다.

실무에서 이렇게 썼다

클라이언트가 “글로벌 SaaS 사이트들처럼 만들어달라”고 했다. 레퍼런스가 영어 사이트 5개였는데, 각 사이트의 히어로 섹션, 피처 섹션, 프라이싱 섹션을 HTML to Design으로 가져와서 나란히 놓고 비교 분석했다. 그리드 간격, 폰트 사이즈 비율, 버튼 크기 패턴을 비교하니까 클라이언트한테 설명할 때도 훨씬 설득력이 생겼다.

디자인 방향 잡는 데 반나절도 안 걸렸다.

특히 유용한 케이스

  • 경쟁사 벤치마킹: 여러 사이트 한 캔버스에서 비교
  • 레퍼런스 분석: 그리드 시스템, 타이포그래피 스케일 파악
  • 리디자인 작업: 기존 사이트 구조를 베이스로 수정
  • 클라이언트 설득: 레퍼런스를 실제 레이어로 분리해 설명

주의할 점

퍼블릭하게 공개된 웹사이트에서만 사용하는 게 맞다. 저작권 이슈가 있는 소스를 그대로 납품하면 문제가 생기니까, 어디까지나 분석과 참고 용도로만 써야 한다.


3. Wanna This — 클릭 몇 번으로 실제 같은 목업 완성

이게 왜 필요한가

디자인을 다 했는데, 클라이언트한테 보여줄 때 플랫 화면으로만 보여주면 임팩트가 약하다. 특히 앱 디자인의 경우, 실제 폰에 올라가 있는 모습을 보여줘야 “아, 이런 느낌이구나” 하고 실감한다.

기존에는 목업 만들려면 Mockup World 같은 곳에서 PSD 파일 받고, 포토샵에서 스마트 오브젝트에 디자인 끼워넣고, 피그마로 다시 가져오는 과정을 거쳤다. 한 번 만들고 끝나면 괜찮은데, 수정이 생기면 이 과정을 반복해야 한다.

Wanna This는 이 과정을 피그마 안에서 끝낸다.

어떻게 작동하나

  1. 내 디자인 프레임 선택
  2. Wanna This 플러그인 실행
  3. 원하는 디바이스 목업 선택 (아이폰, 맥북, 아이패드 등)
  4. 자동으로 해당 화면에 디자인이 삽입된 목업 생성

고퀄리티 디바이스 이미지에 내 디자인이 자연스럽게 합성되어 나온다. 조명, 그림자, 화면 반사까지 이미 잘 처리되어 있어서 별도 후작업이 거의 필요 없다.

실무에서 이렇게 썼다

포트폴리오를 정리할 때 제일 많이 쓴다. 작업물마다 목업 이미지 하나씩 만들어야 하는데, 예전에는 작업물 10개면 목업 만드는 데만 반나절이 걸렸다. 지금은 Wanna This로 작업물 10개 목업을 1시간 안에 만든다.

클라이언트 제안 덱에 넣을 때도 마찬가지다. “이렇게 만들면 실제로 이렇게 보입니다”를 보여주는 데 목업이 결정적인 역할을 한다.

특히 유용한 케이스

  • 포트폴리오 정리: 일관된 스타일로 작업물 목업 제작
  • 클라이언트 제안서: 실사 느낌의 프레젠테이션
  • 소셜 미디어 공유: 비핸스, 드리블 업로드용 이미지
  • 앱 스토어 스크린샷: 실제 디바이스 화면 합성

세 가지 플러그인 한눈에 비교

플러그인핵심 기능가장 유용한 상황난이도
Maps to Design주소 → 지도 레이어위치 기반 서비스 디자인쉬움
HTML to DesignURL → 피그마 레이어경쟁사 분석, 레퍼런스 정리보통
Wanna This디자인 → 고퀄 목업포트폴리오, 제안서, 발표쉬움

피그마 플러그인 추천
본 카드뉴스는 AI 이미지 생성 기술을 활용해 제작되었습니다

플러그인 도입할 때 고려할 것들

플러그인이 편리하다고 무조건 쓰라는 게 아니다. 실무에서 몇 가지 기준을 가지고 있다.

학습 비용 대비 시간 절감 효과를 먼저 따진다. 쓸 때마다 설정이 복잡하고 결과를 많이 수정해야 한다면, 그냥 직접 하는 게 나을 때도 있다. 위 세 가지는 처음 써보는 사람도 10분 안에 익힐 수 있는 수준이라 진입 장벽이 낮다.

팀 작업이라면 공유 가능한지 확인한다. 플러그인 결과물이 피그마 네이티브 레이어로 들어오는지, 외부 연동이 필요한지에 따라 팀 협업 시 복잡해질 수 있다. 위 세 플러그인은 모두 피그마 레이어로 결과가 떨어져서 핸드오프나 협업에 무리가 없다.

개발자 핸드오프 시 주의점도 있다. HTML to Design으로 가져온 레이어는 구조가 지저분할 수 있다. 참고용으로만 쓰고, 실제 개발에 전달할 파일은 따로 정리해서 만드는 게 맞다. Wanna This로 만든 목업도 마찬가지—최종 납품 파일에는 목업이 아닌 실제 디자인 프레임을 전달해야 한다.


마치며

20년 넘게 디자인하면서 가장 크게 든 생각 중 하나는, 도구를 잘 쓰는 것도 실력이라는 것이다. 처음엔 툴에 의존하는 게 실력을 감추는 것처럼 느껴졌는데, 지금은 반대로 생각한다. 반복 작업을 빠르게 처리할 수 있어야 진짜 중요한 판단과 결정에 에너지를 쓸 수 있다.

이 세 가지 플러그인이 모든 프로젝트에 다 맞지는 않는다. 하지만 위치 기반 서비스 디자인하거나, 레퍼런스 분석하거나, 포트폴리오 정리할 일이 있다면 한 번은 써보길 권한다.

한 번 써보면 왜 해외 디자이너들이 이걸 쓰는지 바로 이해가 된다.


이 글이 도움이 됐다면 북마크 해두고, 비슷한 고민을 하는 디자이너 동료에게 공유해 주세요.

함께 읽으면 좋은 글