2026년 UX 디자이너 역량 7가지 - Figma가 전부가 아니죠

역량 목록은 이미 많습니다. 문제는 대부분이 "사용자 공감 능력이 중요합니다" 수준에서 끝난다는 점입니다. 반대할 수 없는 문장은 정보가 없습니다.

그래서 이 글은 역량마다 "이걸 가졌다는 걸 어떻게 보여주나"를 같이 적었습니다. 포트폴리오에 들어갈 수 없는 역량은 채용 과정에서 존재하지 않는 것과 같기 때문입니다.

먼저, 기준선과 역량을 구분해야 합니다

Figma는 프로덕트 디자인 공고의 85% 이상에 등장합니다. 숫자만 보면 가장 중요한 역량 같지만, 해석은 정반대입니다. 모두가 가진 것은 변별력이 없습니다.

이건 운전면허와 비슷합니다. 배달 기사 공고에 운전면허가 100% 등장하지만, 아무도 면허증을 강점으로 적지 않습니다. 없으면 탈락하고 있으면 본전이 시작되는 것, 그게 기준선입니다.

포트폴리오의 절반을 "Figma로 이런 컴포넌트를 만들었습니다"로 채우면 기준선만 여러 번 증명하게 됩니다. 아래 일곱 가지는 그 위에 쌓는 것들입니다.

1. 문제 정의와 리서치 해석

인터뷰 기록과 행동 데이터를 읽고 "어떤 화면이 필요하다"가 아니라 "사용자가 어느 지점에서 무엇을 못 하고 있다"를 말할 수 있어야 합니다.

AI가 리서치 기록을 요약해주는 시대가 되면서 이 역량은 오히려 더 희귀해졌습니다. 요약은 가장 자주 나온 말을 상위로 올립니다. 그런데 제품을 바꾸는 신호는 종종 한 명이 한 번 한 말 중에 있습니다. 빈도로 줄을 세우면 그 신호는 맨 아래로 밀립니다.

실제로 2026년 AI in Design 조사에서 디자이너의 60~70%가 사용자 니즈와 문제 정의만큼은 AI가 아니라 자기 판단을 따른다고 답했습니다. 구현은 맡기면서 질문은 안 맡기는 경계가 여기입니다.

증명하는 법 — 처음 받은 요구사항과 최종 문제 정의가 달라진 사례를 하나 넣으세요. "장바구니 이탈률을 줄여달라는 요청을 받았는데, 로그를 보니 이탈이 아니라 배송비 계산 시점의 놓침이었고, 그래서 문제를 이렇게 다시 정의했습니다." 이 한 단락이 화면 스크린샷 서른 장보다 강합니다.

2. AI 위임 설계

좋은 프롬프트를 쓰는 건 이제 기본기에 가깝습니다. 변별력은 다른 데 있습니다. 무엇을 맡기고 무엇을 직접 볼지 가르는 판단입니다.

대략 이런 선이 생깁니다. 카피 변형, 반복되는 화면, 저장소 탐색, 더미 데이터 생성은 맡깁니다. 목표 설정, 품질 기준, 위험도 판단, 최종 선택은 사람이 들고 있습니다.

경계를 모호하게 두면 이상한 일이 벌어집니다. 같은 조사에서 9%는 AI의 기여와 자기 기여를 구분하기 어렵다고 답했고, 온전한 오너십을 느낀다는 응답은 40%에 그쳤습니다. 자기가 뭐를 했는지 모르는 상태로는 다음 판단이 누적되지 않습니다.

증명하는 법 — AI가 낸 결과를 거절한 사례를 보여주세요. 무엇을 받았고, 어떤 기준으로 버렸고, 대신 무엇을 했는지. AI를 잘 쓴 사례보다 이쪽이 훨씬 강력합니다.

3. 시스템 사고

컴포넌트와 토큰은 라이브러리가 아니라 반복 가능한 판단의 기록입니다. 어떤 상황에서 어떤 버튼을 쓰는지, 위험한 행동은 어떻게 표시하는지, 오류 문구의 말투는 어떤지까지 적혀 있어야 합니다.

AI 시대에 이게 갑자기 중요해진 이유가 있습니다. 지금은 사람만 디자인 시스템을 읽는 게 아니라 에이전트도 읽습니다. 암묵적으로 공유되던 규칙은 AI에게 전달되지 않습니다. 문서화되지 않은 기준은 생성 결과에서 조용히 사라집니다.

그래서 요즘 잘 돌아가는 팀은 디자인 시스템 문서를 사람용과 기계용 두 버전으로 관리합니다. 저장소 안에 규칙을 평문으로 넣어두면 에이전트가 그걸 참조합니다.

증명하는 법 — 컴포넌트 스크린샷 대신 의사결정 기록을 보여주세요. "버튼 변형이 11개까지 늘어나서 4개로 줄였고, 합친 기준은 이거였고, 이 팀은 지금도 그 기준으로 쓰고 있습니다."

4. 코드로 프로토타입하기

가장 많이 바뀐 항목입니다. 수치로만 봐도 분명합니다.

• 디자이너의 76%가 AI 코딩 도구를 써봤고, 앱 빌더까지 포함하면 85%입니다.
• 50%는 AI가 생성한 코드를 프로덕션에 배포한 경험이 있습니다.
• 초기 스타트업은 68%, 성장기 기업은 50%, 상장사는 33%로 갈립니다.
• 회사의 43%가 작동하는 프로토타입을 산출물로 기대합니다.

회사 단계별 차이가 중요합니다. 스타트업으로 갈 생각이라면 코드 프로토타입은 사실상 필수고, 대기업 인하우스라면 아직 선택입니다. 모두에게 같은 조언을 하는 건 정직하지 않습니다.

개발자가 될 필요는 없습니다. 목표는 다릅니다. 정적 시안에서는 보이지 않는 것을 보는 것입니다. 응답이 3초 걸릴 때의 답답함, 긴 이름이 들어왔을 때 무너지는 레이아웃, 키보드가 올라왔을 때 가려지는 버튼 같은 것들입니다. 구체적인 절차는 Claude Code로 UI를 개선하는 워크플로우에 적어두었습니다.

증명하는 법 — 배포된 URL 하나. 심사자가 직접 눌러볼 수 있으면 나머지 설명이 거의 필요 없습니다. 완성도는 중요하지 않습니다. 오류 상태까지 눌러지면 그걸로 충분합니다.

5. UX 라이팅

사용자는 버튼과 오류 문구를 통해 제품을 배웁니다. 확인보다 예약 취소하기가 낫다는 판단, 긴 안내를 필요한 순간에 나누는 판단이 여기에 속합니다.

이게 부가 기술로 치부되기 쉬운데, 실측 지표로 보면 효과가 적지 않습니다. 불필요한 문구를 도려낸 것만으로 전환율이 5% 오른 사례, 온보딩 카피를 다시 써서 완료율이 23% 오르고 문의가 15% 줄어든 사례가 있습니다. 자세한 건 버튼 문구 하나로 사용성을 높이는 방법에 정리했습니다.

AI가 카피 변형을 순식간에 쓰니 이 역량이 필요 없어졌다고 생각할 수 있는데, 오해입니다. 쓰는 일은 싸지고 고르는 일은 그대로입니다. 열 개 중 어느 것이 위험을 줄이고 브랜드 말투에 맞는지는 자동으로 정해지지 않습니다.

증명하는 법 — before/after 문구 표와 그 변경의 근거. 지표가 있으면 가장 좋고, 없으면 고객문의 유형이나 사용성 테스트 관찰이라도 붙입니다.

6. 안목과 비평

생성된 안을 받아들이는 것과 평가하는 것은 다릅니다. 왜 이 레이아웃이 진부한지, 왜 이 카피가 불안을 키우는지, 왜 브랜드에 안 맞는지를 언어로 설명할 수 있어야 합니다.

언어로라는 게 핵심입니다. "느낌이 이상해요"는 팀을 움직이지 못하고, AI에게 전달되지도 않습니다. 응답자의 약 80%가 시각적 완성도는 AI 제안이 아니라 자기 기준으로 판단한다고 답했는데, 그 기준을 말로 풀어내지 못하면 본인 머릿속에서 끝납니다. taste를 안목으로 옮기는 이유를 따로 썼습니다.

증명하는 법 — 남의 제품을 비평한 글 한 편. 단, "이렇게 바꿔봤습니다" 리디자인 연습은 이제 흔해서 약합니다. 오히려 왜 이 디자인이 이렇게 되었을지 제약을 추정하는 글이 드물고 강합니다.

7. 검증·접근성·윤리

사용성 테스트, 보조기기 경험, 개인정보, 편향, 오류의 비용을 릴리스 전까지 챙깁니다. AI가 결과를 만들었다고 책임의 주체가 사라지지는 않습니다.

이 항목은 보통 마지막에 형식적으로 붙는데, 2026년에는 상황이 달라졌습니다. AI로 생성한 인터페이스가 WCAG를 통과하는 비율은 약 3분의 1입니다. 생성 비중이 높아질수록 검수할 줄 아는 사람의 가치가 올라갑니다.

증명하는 법 — 자기 작업물을 키보드만으로 조작한 기록이나 스크린 리더 1회차 점검 결과. 분량은 넣지 않아도 됩니다. 했다는 사실 자체가 드뭅니다.

반론: 일곱 가지를 다 잘하라는 건 결국 아무말도 안 한 것 아닌가

타당한 지적입니다. 이런 목록의 고질적인 문제기도 하고요.

현실적으로는 일곱 개를 균등하게 채우는 사람보다 두세 개가 뚜렷하게 깊은 사람이 뽑힙니다. 업계 전망에서도 설계도를 찍어내는 사람보다 적응형 제너럴리스트가 살아남는다고 보는데, 이건 전부 균등하게 잘하라는 뜻이 아니라 문제에 따라 필요한 쪽으로 옮겨갈 수 있다는 뜻에 가깝습니다.

그래서 읽는 방법을 제안하자면 이렇습니다. 1번과 6번은 모두에게 필요한 핵심입니다. 나머지 다섯은 가고 싶은 회사의 공고를 열 개 뽑아 빈도를 세어보고 고르면 됩니다.

빠지기 쉬운 부작용 하나

역량 얘기만 하면 놓치는 게 있습니다. 2025년에는 응답자의 5%만 "AI 때문에 협업이 줄었다"고 답했는데 2026년에는 20%로 늘었습니다.

각자 AI로 빨라지면 팀이 같이 보는 시간이 줄어듭니다. 예전에는 시안을 받아가려면 서로 말을 섞어야 했는데, 이젠 각자 생성해서 각자 끝냅니다. 생산성 지표는 좋아지는데 기준이 분해됩니다.

여담으로 붙이면, 이게 3번 시스템 사고가 예전보다 중요해진 진짜 이유입니다. 사람들이 말로 맞추던 것을 이젠 문서가 대신해야 합니다.

어디부터 시작할까

일곱 가지를 동시에 손대는 건 불가능합니다. 순서를 제안하자면, 이미 끝난 프로젝트 하나를 골라 작동하는 프로토타입으로 옮기는 일부터 해보세요. 4번을 실습하는 동안 3번과 5번이 자연히 따라옵니다. 버튼 문구를 정하고 상태를 나누다 보면 안 밟을 수가 없으니까요.

Figma는 이 일곱 가지를 연습하기 좋은 장소입니다. 다만 연습장이지 경기장은 아닙니다. 심사는 결국 사용자·코드·조직 쪽에서 벌어집니다.

공고를 역으로 읽는 법

이런 역량 목록은 결국 평균입니다. 본인에게 필요한 건 평균이 아니라 가고 싶은 회사의 기준입니다. 다행히 그건 공개돼 있습니다.

관심 있는 회사의 공고를 열 개만 모아서 동사를 세어보세요. '프로토타입한다'가 많은지, '검증한다'가 많은지, '정렬한다'가 많은지. 빈도가 높은 두세 개가 그 회사군이 실제로 사는 역량입니다. 나머지는 복사해 붙여넣은 문장일 가능성이 높습니다.

이 방법이 유용한 이유는 하나 더 있습니다. 공고의 동사는 그 회사가 지금 메우는 문제를 드러냅니다. '파편화된 경험을 정렬한다'가 반복되면 그 조직은 지금 일관성 문제를 앓고 있다는 뜻입니다. 면접에서 무슨 얘기를 꺼내야 하는지까지 같이 알려줍니다.