오랫동안 저는 그것이 권력 문제라고 생각했습니다. 이해관계자가 더 많은 권한을 가지고 있거나, 조직이 디자인을 우선시하지 않거나, 아니면 단순히 UX에 관심이 없다는 식으로요. 그런 관점은 일리가 있었지만, 권력 역학 관계는 제가 혼자서 해결할 수 있는 문제가 아니었기에 계속 제자리에 머물러 있었습니다.

왜 이런 일이 일어날까요?

대부분의 이해관계자들은 적어도 원칙적으로는 사용자 경험에 관심을 갖고 있습니다. 하지만 진짜 문제는 “더 나은 사용자 경험”이 그들이 일상적으로 측정하는 어떤 지표와도 연결되지 않는다는 점입니다.

모든 사람은 수익, 고객 유지, 비용, 위험 감소 등 여러 가지에 대해 책임을 져야 합니다. 이러한 사항들을 언급하지 않은 권고안은 설령 상대방이 당신의 의견에 동의하더라도 실행하기 어렵습니다.

PM은 전환율과 기능 채택률로 평가받습니다. 엔지니어링 리더는 개발 속도와 기술 부채 최적화에 집중합니다. 최고 경영진은 성장 지표와 경쟁력 있는 위치 확보에 관심을 갖습니다.

그들은 훌륭한 UX에 반대하는 것이 아닙니다. 단지 사용자 행동에서 비즈니스 성과로 이어지는 인과 관계를 알고 싶어 할 뿐입니다. 그 연결 고리가 없으면 당신의 제안은 출시되지 않는 수십 개의 다른 “좋은 아이디어”들과 함께 백로그에 묻혀 있게 될 것입니다.

[다음 내용 읽기]

다들 그런 헤드라인을 한 번쯤 보셨을 겁니다. 격주 간격으로 누군가는 AI가 디자인이라는 직업의 종말을 불러왔다고 선언합니다. 같은 주에 또 다른 누군가는 디자이너 없이 40분 만에 그럴싸한 랜딩 페이지를 완성한 창업자의 성공담을 공유합니다. 그 뒤에는 예상대로 트위터의 수많은 디자이너들이 불안과 부정을 쏟아냅니다.

저는 이 사실을 바로잡고 싶습니다. “디자인은 끝났다”라는 프레임 자체가 완전히 잘못되었다고 생각합니다. 이런 자극적인 말들은 커리어를 완전히 전환해야 할지 고민하는 주니어 디자이너들에게 실질적인 피해를 줍니다. 이 업계에서 15년 이상 일했습니다. 특히 지난 18개월 동안 협업 기업들이 실시간으로 변화하는 모습을 지켜보았습니다. 이제 제가 목격한 진짜 현실을 공유합니다.

UX 디자인은 죽지 않았습니다. 전혀 아닙니다. 다만 실무 방식의 거의 모든 요소가 바뀌었을 뿐입니다. 툴과 산출물 그리고 일상적인 업무 리듬과 역량 기준까지 모두 포함하고 심지어 커리어 패스도 변했습니다. 대중의 논평은 아직 이 변화의 속도를 따라잡지 못했습니다.

지금 살아남는 디자이너들은 이 변화를 빠르게 알아챈 사람들인 반면에 여전히 2022년에 머물러 있는 디자이너들은 힘든 시기를 보내고 있습니다. 이 글로 무엇이 변했는지 솔직하게 짚어내고 여러분이 올바른 방향으로 나아가기 위한 전략 지침서가 되길 바랍니다.

[다음 내용 읽기]

생각이 복잡해지는 이유

대부분의 사람들은 지능이 부족해서 어려움을 겪는 것이 아닙니다. 생각이 너무 복잡하게 뒤섞여 있기 때문입니다. 너무 많은 입력 정보, 너무 많은 의견, 그리고 동시에 주의를 끌어당기는 너무 많은 우선순위 때문입니다.

그 결과는 단순한 혼란에 그치지 않습니다. 바로 인지적 마찰(Cognitive friction)이 발생합니다. 바쁘긴 한데 머릿속은 뿌옇고, 활동적이긴 한데 방향성이 없으며, 아는 건 많은데 결정은 내리지 못하는 상태가 되는 것입니다. 아시아 여러 지역에서 16년간 시각적 사고를 가르치며, 저는 명료함이 갑자기 나타나는 경우는 거의 없다는 사실을 알게 되었습니다. 대개는 어떤 프로세스를 통해 서서히 드러납니다.

바로 눈에 보이는 프로세스를 통해서입니다. 복잡하지도, 이론적이지도 않으며, 예술적 기술이 필요한 것도 아닙니다. 그저 머릿속 소음을 눈에 보이는 구조로 바꿔주는 네 가지 의도적인 단계가 있을 뿐입니다.

이 4단계는 제가 접해본 시각적 사고 프레임워크 중 가장 실용적인 댄 로암(Dan Roam)의 저서 『생각이 막힐 땐 나프킨에 그려라(The Back of the Napkin)』에서 가져온 것입니다. 저는 팀워크를 촉진하고, 워크숍을 준비하고, 전략 회의를 구성할 때 이 단계를 꾸준히 활용합니다. 보고, 관찰하고, 상상하고, 보여주는 것입니다.

[다음 내용 읽기]

“당신의 스마트폰에서 모든 버튼을 없앤 그 남자가 페라리를 버튼으로 가득 채웠다.”

2026년 초 이런 헤드라인이 등장하기 시작했습니다.

아이브의 스튜디오 ‘러브프롬(LoveFrom)’이 디자인한 페라리 최초의 전기차 ‘페라리 루체(Luce)’. 이 차량은 물리적인 스위치와 토글 그리고 버튼을 중심으로 설계되었습니다. 자동차 제조사들이 대시보드의 모든 요소를 커다란 터치스크린 하나로 대체하던 시기에 나타난 변화입니다.

아이브의 이번 결정은 모바일 기기가 걸어온 정반대의 여정을 떠올리게 합니다. 과거 모바일 기기는 물리 버튼이 멀티 터치스크린으로 대체되는 과정을 거쳤습니다. 사용자들은 이때부터 제스처를 통해 기기와 상호작용하기 시작했습니다.

이러한 진화 과정을 이해하려면 역사를 살펴볼 필요가 있습니다. 1965년 엔지니어 에릭 아서 존슨은 영국 말번의 왕립 레이더 연구소에서 최초의 손가락 구동 방식 터치스크린을 개발했습니다. 이 장치는 항공 관제용으로 고안되었습니다. 해당 정전식 화면은 압력이 아닌 사람 손가락의 전하를 감지하여 작동하는 원리입니다.

정전식 터치스크린이 먼저 등장했지만 곧 감압식 터치스크린이 더 큰 인기를 얻었습니다. 미국 발명가 G. 사무엘 허스트 박사는 켄터키 대학교에서 감압식 터치스크린을 개발했습니다. 대학교 측은 그를 위해 특허 출원을 시도했지만 많은 이들은 이 기술이 실험실에서나 유용할 것이라고 생각했습니다.

허스트의 생각은 달랐습니다. 1970년 그는 오크리지 국립연구소로 돌아갔습니다. 그는 여가 시간을 활용해 아이디어를 발전시켰습니다. 그는 화면에 전도성 시트만 있으면 된다는 사실을 발견했습니다. 이는 ‘엘로그라픽스(Elographics)’라 불리는 감압식 터치 기술로 이어졌습니다. 이후 그의 팀은 최초의 곡면 유리 터치 인터페이스 특허를 획득했습니다.

[다음 내용 읽기]

라이트 UI 디자인에는 조용하지만 분명한 아이러니가 존재합니다. 겉보기에는 단순해 보이죠. 하지만 실제로 디자인을 시도해 본 적이 있다면, 이것이 얼마나 망치기 쉬운 작업인지 잘 아실 겁니다.

너무 밝게 설정하면 모든 요소가 평평하고 밋밋하게 느껴지거나, 심지어 눈이 아플 수도 있습니다. 우리는 종종 ‘설탕이 곧 디저트’라고 생각하듯, ‘흰색이 곧 라이트 모드’라고 단정 짓곤 합니다. 하지만 상황은 그리 간단하지 않습니다.

SaaS 제품, 모바일 앱, 비즈니스 플랫폼을 11년 넘게 디자인해 오면서, 저는 라이트 테마가 다크 테마만큼, 때로는 그보다 더 세밀한 의도가 필요하다는 것을 배웠습니다.

제대로 구현된 가벼운 사용자 인터페이스는 다음과 같은 이점을 제공합니다.

• 명확성

• 구조적 안정감

• 평온함

• 신뢰감

제가 어떻게 접근하는지 설명해 드리겠습니다.

[다음 내용 읽기]

몇 주 전 빨간색 계열의 컬러를 찾으려고 Tailwind v4 문서를 훑어보고 있었습니다. 그때 이 코드를 발견했습니다.

--color-red-500: oklch(0.637 0.237 25.331);

Hex도 HSL도 아닌 완전히 처음 보는 형식이었습니다. 저는 잠시 멈춰 서서 제가 무엇을 보고 있는지 분석해 보았습니다. 당시 10년 넘게 디자인 토큰을 만들어 왔음에도 이 구문은 전혀 알아볼 수 없었습니다.

전에도 OKLCH라는 이름을 들어본 적은 있었습니다. 냉장고에 냉동실이 있다는 사실을 무의식적으로 인지하듯 딱히 깊게 생각해 본 적 없는 정보였습니다. 그런데 이제 세계에서 가장 인기 있는 CSS 프레임워크가 모든 팔레트 컬러의 기본값으로 이 형식을 채택했습니다. 공지사항이나 트위터 게시글은 없었습니다. 변화에 대해 양해를 구하는 마이그레이션 가이드조차 없었습니다. 그저 새로운 값들이 원래 그 자리에 있었던 것처럼 무심하게 놓여 있을 뿐이었습니다. 저는 페이지를 닫고 커피 한 잔을 내렸습니다. 그러고는 다음 3일 동안 이 형식에 대해 찾을 수 있는 모든 자료를 탐독했습니다.

모든 디자이너가 알고 있지만 아무도 입 밖으로 내지 않는 사실이 있습니다.

HSL은 결함이 있는 컬러 모델입니다.

밝기(Lightness) 50%의 노란색을 고르고, 똑같은 밝기 50%의 파란색을 골라 두 색을 비교해 보십시오. 노란색은 밝게 빛납니다. 반면 파란색은 거의 검은색에 가깝습니다. 두 색상 모두 L값은 동일합니다.

모니터 고장이 아닙니다. 이것이 바로 설계된 대로 작동하는 HSL의 본모습입니다. HSL의 밝기 척도는 R, G, B 채널의 최솟값과 최댓값 사이를 수학적으로 계산한 중간 지점일 뿐입니다. 실제 우리 눈에 색이 얼마나 밝게 보이는지와는 아무런 상관이 없습니다.

[다음 내용 읽기]

새로운 Claude 세션을 열고 컴포넌트 감사를 요청했는데, 점심시간이 되기도 전에 사용량 제한에 걸려버린 경험이 있을 것입니다. Claude Code와 Figma의 MCP 연동 기능을 사용해 보셨다면 아마 공감하실 겁니다. 토큰은 예상보다 훨씬 빨리 사라지고 , Anthropic은 이 토큰들이 다 어디로 소모되는지 친절하게 알려주지 않습니다.

다행인 점은 이러한 낭비의 대부분을 예방할 수 있다는 것입니다. 큰 차이를 만들어낼 수 있는 몇 가지 습관을 소개합니다.

1. 프롬프트를 나누지 말고 하나로 합치세요

Claude의 가장 의외라고 생각하는 점 중 하나는, 복잡하고 단계가 많은 프롬프트를 다른 모델들보다 더 잘 처리한다는 사실입니다. 즉, 세 가지 작업을 수행하기 위해 메시지를 세 번 따로 보낼 필요가 없다는 뜻입니다. 컴포넌트 감사, 리포트 작성, 변경 이력 업데이트를 하나의 구조화된 프롬프트로 요청하면, 각각 따로 수행하는 것보다 토큰을 덜 쓰고 결과도 더 좋아지는 경우가 많습니다.

매번 맥락을 조금씩 나눠주는 대신, 처음부터 전체 그림을 한 번에 전달한다고 생각하면 됩니다.

[다음 내용 읽기]

이번 글은 아이콘 디자인 심화 팁 시리즈의 첫 번째 순서입니다. 타이포그래피 디자인 원리를 적극 활용해 아이콘 완성도를 한 차원 높여주는 시각적 효과들을 살펴보겠습니다. 먼저 가장 기본적인 스마일 아이콘을 통해 점을 어떻게 다루어야 하는지 알아보겠습니다.

점은 선 굵기보다 약간 더 커야 시각적 균형이 맞습니다.

선과 동일한 두께를 그대로 적용하면 눈 모양이 너무 작아 보일 수 있습니다.

[다음 내용 읽기]

생성형 AI가 디자인 실무에 스며드는 지금, 핵심 과제는 단지 “프롬프트를 어떻게 잘 쓰느냐”가 아닙니다. 실제 사용자와의 리서치를 포함하는, 더 넓고 인간 중심적인 프로세스 안에 AI를 어디에 놓을지가 더 중요한 문제입니다.

이 글은 디자이너와 AI의 협업을 다섯 단계, 즉 발상(Ideation) → 언어화(Articulation) → 대화(Dialogue) → 반복(Iteration) → 저작권(Authorship) 으로 제안합니다. 그리고 이 흐름의 앞쪽을 생성 연구(generative research), 뒤쪽을 평가 연구(evaluative research)가 감싸는 구조로 봅니다.

이 모델에서 발상, 언어화, 저작 책임은 본질적으로 사람이 주도하는 단계입니다. 참여자와 함께하는 생성연구는 앞의 두 단계를 풍부하게 하고 깊이를 더합니다. 반복 단계 중간과 그 이후의 평가연구는 의사결정을 ‘기계 출력의 그럴듯함’이 아니라 실제 사용자의 경험 위에 올려 둡니다.

AI가 가장 활발히 움직이는 곳은 가운데의 두 단계, 대화와 반복입니다. 여기서 AI는 사람의 판단과 책임을 대체하지 않으면서도 선택지의 폭을 크게 넓혀 줍니다.

1. 발상(Ideation): 생성 연구를 통해 파악한 인간의 의도

발상은 사람이 이끄는 단계이지만, 혼자 하는 일이어야 한다는 뜻은 아닙니다. 인터뷰, 현장 방문, 기록, 문화 탐구, 참여형 워크숍 같은 생성 연구는 디자이너의 상상만이 아니라 실제 삶에서 길어 올린 이야기, 긴장(tension), 열망을 발상 단계에 공급해 줍니다. 목표는 무엇이 중요한지, 누구를 위한 것인지, 그리고 어떤 맥락에서 중요한지를 드러내는 것입니다.

AI에게 아이디어부터 달라고 하기 전에, 디자이너는 먼저 사용자들의 세계 안으로 몰입합니다. 이 과정에서 디자이너는 표면적으로 드러나는 요구와 실제 행동 사이의 모순, 참여자들이 명확하게 표현하기 어려운 잠재적 욕구, 일상적 선택을 제약하는 구조적 조건들과 마주칩니다. 이러한 경험들이 디자인 작업의 초기 질문과 방향을 제시해 줍니다.

이 단계에서 AI는 기존 연구 자료를 요약하거나 현장 기록을 정리해 주는 정도의 보조 역할을 할 수는 있습니다. 하지만 연구의 목적을 만들어내는 것은 아닙니다. 생성연구에 뿌리를 둔 발상은, 어떤 모델에게든 콘텐츠 생성을 요청하기 전에 의미 있는 문제 영역을 먼저 정의해 둡니다.

[다음 내용 읽기]

오늘날 대부분의 디자인 시스템은 업계 표준인 피그마를 기반으로 구축됩니다. 컴포넌트나 스타일 그리고 패턴을 포함하는 UI 키트는 여전히 디자이너가 가장 신뢰하는 핵심 도구 중 하나입니다.

클로드 디자인 시작하기

1. 클로드 디자인 접속

이 새로운 도구를 사용하려면 우선 프로(Pro), 맥스(Max), 팀(Team) 또는 엔터프라이즈(Enterprise) 중 하나 이상의 유료 플랜을 구독해야 합니다.

웹사이트(https://claude.ai/design)에 접속하거나 클로드 데스크톱 앱의 디자인 탭을 열면 여기서 설명하는 것과 동일한 화면을 확인할 수 있습니다.

메인 화면 왼쪽에는 결과물을 생성할 수 있는 카드가 보입니다. 그 바로 아래에는 ‘디자인 시스템 설정(Set up design system)’ 버튼이 위치해 있습니다.

2. 디자인 시스템 설정하기

새로운 디자인 시스템을 추가하기 위해 워크플로우를 시작하면 다양한 옵션이 포함된 화면이 나타납니다. 저는 여기서 브랜드와 제품 유형 그리고 타겟 시장에 대한 간략한 정보를 입력했습니다.

저는 깃허브(Github)나 컴퓨터의 코드를 직접 활용하는 대신 피그마 파일의 로컬 복사본을 업로드했습니다. 그중에서 잘 정리된 컴포넌트들을 선별하여 등록하고 폰트를 몇 가지 추가했습니다. 로고와 아이콘 설정은 우선 제외하고 진행했습니다.

[다음 내용 읽기]

906명의 디자이너를 대상으로 한 피그마의 ‘2026 디자이너 현황 리포트’. AI, 디자인 완성도, 그리고 채용 시장에 대해 데이터가 말해주는 실상을 정리했습니다.

피그마 2026 디자이너 현황 리포트

매년 트위터(X)의 디자인 커뮤니티에서는 적어도 세 번쯤 ‘디자인의 종말’을 선언하곤 합니다. 올해 그 주인공은 AI였습니다. 지난번엔 ‘노코드(No-code)’였고, 그전엔 ‘부트캠프’였죠. 디자인의 장례식은 매번 이렇게 날짜가 미뤄지곤 합니다.

그래서 전 세계 906명의 디자이너를 대상으로 한 피그마의 ‘2026 디자이너 현황 리포트’가 발표되었을 때, 실제 데이터가 우리가 느끼는 공포와 일치하는지 확인해보고 싶었습니다. 결론부터 말하자면, 그렇지 않았습니다.

오히려 데이터는 업계가 양분되고 있음을 보여줍니다. 어떤 디자이너들은 낙관적이고 활력이 넘치는 반면, 어떤 이들은 정체되어 있고 불안해합니다. 이 차이는 재능 때문이 아닙니다. 동시에 일어나고 있는 몇 가지 구조적 변화에 어떻게 대응하느냐의 차이입니다.

그 변화들을 하나씩 살펴봅시다.

[다음 내용 읽기]

Andrej Karpathy가 ‘바이브 코딩’이라는 용어를 만든 지 1년이 조금 넘었습니다. 자연어만으로 누구나 앱을 만들 수 있다는 아이디어는 지난 2025년 들불처럼 빠르게 번져 나갔습니다.

당시 우리는 직관과 챗봇 프롬프트로 개발된 코드에 대해 다뤘습니다. 그렇다면 지금은 어떻게 변했을까요? 이번 호에서는 우리가 마주한 ‘멋진 신세계’인 바이브 코딩의 현실을 점검해 봅니다.

양인가 질인가. 속도인가 장인정신인가

바이브 코딩이 내걸었던 위대한 약속은 누구나 (그렇습니다. 정말 누구나) 앱을 출시할 수 있다는 것이었습니다. 바이브 코딩 덕분에 앱이나 웹사이트를 구축할 때 더 이상 고액 연봉의 전문가 팀이 필요하지 않게 되었습니다.

낙관적인 이론에 따르면 전문 지식 없이도 일제히 코딩을 수행하는 가상 에이전트 팀과 함께 모든 것을 직접 할 수 있었습니다. 프롬프트로 원하는 내용을 AI에게 말하기만 하면 마법처럼 이루어진다는 것이 꿈만 같은 이야기였습니다. 하지만 실제 결과는 이상과는 거리가 멀었습니다. 멀티 에이전트 기술 선언문인 ‘Welcome to Gas Town’의 저자이자 개발자인 Steve Yegge는 AI가 생성한 ‘PR(풀 리퀘스트) 폭풍’이 오픈 소스 소프트웨어 프로젝트에 범람하고 있다고 말합니다.

바이브 코딩으로 인한 보안 사고 의혹부터 취약한 인프라를 통한 계정 해킹 증거까지 매일 눈살을 찌푸리게 만드는 사건들이 발생합니다. 바이브 코딩은 아마존의 웹사이트와 클라우드 서비스에서 발생한 일련의 중단 사태에 원인을 제공했을 가능성이 있습니다. 이로 인해 코드 리뷰 과정에서 인간의 감시를 더욱 강화해야 한다는 목소리가 커지고 있습니다.

하지만 세간의 주목을 받는 실패 사례보다 더 심각한 것은 철학적인 타락입니다. 작가 Michal Malewicz는 대다수 평범한 AI 프로젝트의 제작자들로 인해 생기는 창의성과 집중력 그리고 예술성의 현저한 저하가 더 치명적이라고 지적합니다.

그는 자신의 글 ‘Vibe Coding is OVER’에서 “모든 이들의 결과물이 이케아의 유명한 LACK 커피 테이블처럼 천편일률적으로 변하고 있다. 숙련도와 호기심 그리고 열정과 휴리스틱이 사라지면 우리에게 남는 것은 개성 없는 보편성뿐이다”라고 덧붙였습니다.

[다음 내용 읽기]

요즘 계속 반복해서 보게 되는 장면이 하나 있습니다.

디자이너가 Figma를 열고, 간격을 조정하고, 그라데이션을 완벽하게 적용하여 정말 고급스러워 보이는 화면을 완성합니다. 그러고는 노트북을 닫았지만… 아무런 느낌도 없습니다.

뿌듯하지도 않고, 자신감이 생긴 것도 아닙니다. 그냥 끝냈을 뿐이에요. 만약 당신이 그런 사람이라면, 제가 한 가지 분명히 말씀드리고 싶은 게 있습니다. 그건 재능의 문제가 아닙니다.

저는 수많은 포트폴리오를 살펴보고, 수많은 팀과 협업하고, 저 스스로도 오랫동안 정체된 상태를 겪어봤기 때문에 그 패턴을 파악할 수 있습니다.

재능 있는 디자이너들이 계속 주니어에 머무는 건 픽셀 하나하나가 정확하지 않아서가 아닙니다. 그들이 잘못된 사고방식에 갇혀 있기 때문이고, 아무도 그들에게 올바른 사고방식이 무엇인지 알려주지 않았기 때문입니다.

자, 여기 다섯 가지 단계가 있습니다. 각 단계에서 디자이너들이 빠지기 쉬운 실수와 그로 인해 조용히 발생하는 비용에 대해 알아보겠습니다.

[다음 내용 읽기]

공감은 프로덕트 디자인의 기초입니다. 우리는 공감을 기르고 지도로 만들며 이를 바탕으로 설계하는 일에 관해 끊임없이 이야기합니다. 하지만 공감이 자연스럽게 일어나지 않을 때는 어떻게 해야 할까요? 사용자와 공통점을 찾기 어렵고 그들의 행동이 낯설거나 심지어 답답하게 느껴질 때 우리는 무엇을 해야 할까요?

최근 피트니스 앱을 디자인하며 이런 문제에 부딪혔습니다. 고민에 빠져 있던 중 이 문제를 처음으로 극복했던 기억이 떠올랐습니다. 바로 뜬금없게도 만화 속 뱀 캐릭터의 대사를 쓰던 때였습니다.

방 안의 뱀

2012년 저는 니켈로디언의 새로운 핵심 프로그램인 <산제이 앤 크레이그>에 스토리보드 디렉터로 합류했습니다. 시나리오 집필부터 스토리보드 제작 그리고 유머와 캐릭터를 다듬는 일까지 모든 것을 아우르는 역할이었습니다. 줄거리는 간단합니다. 한 소년과 말하는 애완용 뱀의 이야기입니다. 분위기는 거칠고 황당하며 생리 현상을 활용한 유머로 가득했습니다. 당시 어린이 TV 채널을 보셨다면 아마 기억하실지도 모르겠네요.

에피소드를 구상하기 시작했을 때 난관에 봉착했습니다. 주인공 중 하나인 말하는 뱀 ‘크레이그 슬리더스’의 대사를 도저히 쓸 수 없었습니다. 그가 어떤 캐릭터인지 전혀 이해할 수 없었기 때문입니다.

크레이그는 대담하고 성급하며 주목받기를 즐기는 캐릭터였습니다. 반면 저는 니켈로디언에 오기 전 겪은 힘든 프로젝트 때문에 자신감이 떨어진 상태였고 조용히 일어서려 애쓰고 있었습니다. 그는 소란스럽고 자신감이 넘쳤지만 당시에 저는 주변에 눈에 띄지 않으려 노력했습니다.

그럼에도 저는 그를 위해 글을 써야 했습니다. 그의 사고방식과 본능 그리고 목소리를 이해해야만 했습니다. 캐릭터의 특징을 정리해 보고 대본을 다시 읽으며 그의 서사를 그려보기도 했습니다. 하지만 그 어떤 것도 도움이 되지 않았습니다. 캐릭터는 여전히 평면적이고 가짜처럼 느껴졌습니다.

[다음 내용 읽기]

인공지능(AI)이 디자인 워크플로의 필수적인 부분이 되고 있습니다. 이제 도구들은 Figma 파일을 읽고, UI 레이아웃을 생성하며, 심지어 디자인을 코드로 변환할 수도 있습니다.

하지만 한계가 있습니다.

오늘날 대부분의 디자인 시스템은 오직 사람만을 위해 만들어졌기 때문입니다. 시각적으로는 잘 정리되어 있을지 몰라도, 기계가 보기에는 구조적으로 불분명한 상태입니다. AI의 입장에서 보면 많은 피그마 파일들은 그저 프레임과 사각형, 그룹들이 무작위로 뒤섞인 집합체에 불과합니다.

AI가 디자인 과정에서 진정한 협업 파트너가 되길 원한다면, 우리의 디자인 시스템도 진화해야 합니다.

단순한 비주얼 라이브러리를 넘어 구조화된 시스템으로 거듭나야 합니다.

이 글에서는 디자이너와 엔지니어 모두에게 직관적인 경험을 유지하면서도,

AI가 이해할 수 있는 Figma 디자인 시스템을 설계하는 실질적인 방법을 살펴보겠습니다.

[다음 내용 읽기]

Lovable을 활용할 때 프롬프트를 길게 쓰는 것은 중요하지 않습니다. AI가 코딩을 시작하기 전 디자이너처럼 사고하는 과정이 핵심입니다. 저는 수백 개의 프로젝트 성패를 지켜보며 반복되는 특정 패턴을 발견했습니다. 뛰어난 빌더는 단순히 지시어를 입력하지 않습니다. 이들은 협업자를 대하듯 AI를 계획하고 구조화하며 가이드합니다. 본 가이드에서는 꾸준히 더 나은 결과를 만들어내는 습관을 자세히 분석해 드립니다.

Lovable이 먼저 질문하게 만드세요

결과물의 퀄리티를 높이는 방법은 놀라울 정도로 간단합니다. Lovable이 여러분을 인터뷰하게 하세요. 곧바로 결과물을 생성하지 마세요. 프롬프트 마지막에 다음과 같은 요청을 덧붙여 보시기 바랍니다.

“이 기능에서 내가 원하는 바를 완벽히 이해하기 위해 필요한 질문을 무엇이든 해줘.”

이 방식을 사용하면(특히 Plan 모드에서) Lovable은 여러분이 미처 정의하지 못한 부분을 질문하곤 합니다.

• 타겟 사용자는 누구인지

• 클릭 후 어떤 화면이 보이는지

• 모바일 우선 디자인인지

• 데이터가 없는 상황은 어떻게 처리할지

이런 질문은 코드가 작성되기 전 기획의 공백을 메워줍니다. 결과적으로 나중에 발생할 끝없는 수정 작업을 방지합니다. 피그마를 켜기 전 디자이너가 PRD를 요청하는 과정과 같다고 생각하면 이해가 쉽습니다.

1단계: 기초 다지기

Lovable을 실행하기 전 잠시 계획하는 시간을 가지세요. 단 5분의 투자가 프롬프트의 품질을 극적으로 높여줍니다.

프롬프트 입력 전 계획하기

생각 없이 프롬프트를 만드는 과정은 무엇을 그릴지 모르는 상태에서 캔버스에 붓을 대는 것과 같습니다. 네 가지 질문에 먼저 답해 보시기 바랍니다.

이 제품이나 기능은 무엇인가요? 누구를 위한 것인가요? 왜 사용하나요? 사용자가 취해야 할 단 하나의 핵심 행동은 무엇인가요?

거창한 기획서를 쓸 필요는 없습니다. AI에게 명확한 방향만 제시하면 충분합니다.

[다음 내용 읽기]

즐거운 토요일입니다. 며칠 전 스티치(Stitch)가 대규모 업데이트를 발표했는데요, 제 소셜 미디어 피드는 온통 이런 반응들이었습니다.

“구글 스티치 대 피그마(Figma), 이제 끝났네.”

“구글의 새로운 바이브 디자인 툴은 진짜 미쳤다.”

“이제 디자이너들 다 망한 건가?”

저는 구글이 인수하기 전, 갈릴레오 AI(Galileo AI) 시절부터 스티치를 사용해 왔습니다. 지난 12월부터 지금까지 Stitch가 진화하는 속도를 지켜보는 것만으로도 정말 놀라울 따름입니다. 다른 글에서 Stitch의 디자인 워크플로우를 설명해 드린 적이 있지만, 이번 업데이트를 계기로 오늘은 더 상세한 가이드와 함께 제 소감을 공유해 보려 합니다. 자, 그럼 시작해 볼까요?

개요

Google Stitch는 프롬프트를 입력하면 고해상도(High-fidelity) 인터페이스를 생성해 주는 AI 기반 디자인 플랫폼입니다. 구글 계정만 있다면 무료로 이용할 수 있습니다.

저는 Stitch를 영감을 주는 아주 훌륭한 ‘바이브 디자인’ 툴이라고 생각합니다. 현재 시장에 나와 있는 제품 중 Stitch만큼의 퍼포먼스를 보여주는 도구는 거의 없죠. 특히 디자인 브레인스토밍 단계에서 활용하기가 매우 좋습니다.

하지만 디자이너 입장에서는 실무에 쓰기에 스티치가 조금 더 정교했으면 하는 아쉬움이 늘 있었습니다. 다행히 이번 업데이트를 통해 결과물을 더 세밀하게 제어할 수 있는 엄청난 가능성이 열렸습니다.

이 글에서는 특히 흥미로운 업데이트들을 중심으로 살펴보겠습니다.

[다음 내용 읽기]

연휴 시즌이 코앞으로 다가오면서 한참 온라인 쇼핑에 빠져 지내던 중, 최근 아마존에서 매우 불쾌한 트렌드를 하나 목격했습니다. 상품 가격 바로 옆에 강렬한 빨간색으로 ‘-25%’ 할인 문구가 강조되어 있었죠. 여기까지는 딱히 이상할 게 없어 보였습니다.

‘할인 가격’이 알고보니 제가 며칠 전 확인했던 가격과 소름 돋을 정도로 똑같았다는 점만 아니었다면요. 가격 추적기를 통해 확인한 실상은 더 가관이었습니다. 오직 25% 할인 배지를 붙이려는 목적으로 일시적으로 가격을 올려 재입고시킨 기록이 선명했기 때문입니다.

UI는 “지금 사지 않으면 손해”라고 요란하게 외치고 있었지만, 사실 변한 것은 아무것도 없었고 단지 제 착각만이 그 자리를 채우고 있었습니다.

과거 1800년대의 쇼핑은 가게 주인의 기분에 따라 가격이 널뛰는 지극히 주관적인 방식이었기에, 판매자와 구매자 사이의 치열한 눈치 싸움과도 같았습니다. 특정 물건의 수요가 몰리기 시작하면 주인은 그 자리에서 가격을 올리거나 깎아주며 협상을 주도하곤 했습니다.

이러한 관행은 ‘퀘이커 오츠’로 잘 알려진 퀘이커 가문이 소위 ‘정가제‘라 불리는 옵션을 도입하면서 완전히 뒤바뀌게 됩니다. 그들이 상품 가격을 대중에게 공개하기 시작하면서 소비자들은 비로소 여러 매장의 가격을 비교할 수 있게 되었고, 이는 시장의 새로운 균형을 형성하며 오늘날 우리에게 익숙한 가격표가 탄생하는 결정적인 계기가 되었습니다.

[다음 내용 읽기]

AI는 우리가 미처 필요성을 깨닫기도 전에 어느덧 우리 팀의 일원으로 자리 잡았습니다. 특히 디자인 시스템 구축 분야에서 AI의 활약이 두드러집니다. 과거 몇 주가 걸리던 컴포넌트, 토큰, 문서화 작업을 자동화하여 프로세스를 획기적으로 단축하고 있죠.

하지만 이제 우리는 단순히 ‘속도’에만 감탄하던 단계를 지나가고 있습니다.

이제 중요한 것은 AI 도구가 결과를 몇 초 만에 만들어내느냐가 아니라, 그 결과물이 얼마나 가치 있는가입니다. 결국 몇 분 만에 디자인 시스템을 만든다 해도 실제로 사용되지 않는다면 아무 의미가 없습니다. 디자인 시스템 생성 도구의 진짜 가치는 그 결과물이 실제로 활용 가능한지에 달려 있습니다.

AI가 생성한 디자인 시스템이 실효성을 갖추기 위해 필요한 요건은 무엇일까요?

디자이너들에게 선택받는 시스템이 되기 위한 세 가지 핵심 요소를 짚어봅니다.

1. 사용성

팀원들이 시스템을 즉시 이해하고 자신 있게 활용할 수 있어야 합니다. 이는 시스템이 팀의 실제 작업 환경과 맞닿아 있을 때만 가능합니다.

맥락 파악: 여기서 중요한 것이 바로 맥락을 이해하는 능력입니다. 컴포넌트는 실제 제품이 빌드되는 방식을 반영해야 하며, 디자인 토큰은 엔지니어가 이해할 수 있는 언어여야 합니다.

간결함: 팀이 실제로 필요로 하는 요소만 담아야 합니다. 쓰이지 않을 요소로 가득 찬, 지나치게 비대한 디자인 시스템을 만드는 것은 큰 의미가 없습니다.

친숙함: 결국 아무리 완성도 높아 보이는 디자인 시스템이라도, 실제 작업 맥락과 동떨어져 있다면 아무도 사용하지 않습니다.

[다음 내용 읽기]

고도화 단계에 접어든 피그마 컴포넌트의 속성 패널을 살펴보면 이른바 ‘부끄러운 스크롤바’를 마주하게 될지도 모릅니다. 아이콘 노출 여부나 레이아웃 방향(상하/좌우)처럼 요소를 미세하게 조정하는 수많은 속성이 끝없이 나열되어 있기 때문입니다. 이 속성들은 하나하나가 모두 실무의 특정 케이스를 해결하기 위해 선의로 추가된 것들입니다.

하지만 사용자를 돕기 위해 만든 이 속성들은 어느덧 거대한 ‘역설’로 변해버립니다. 컴포넌트의 베리언트 개수가 폭발하거나 사소한 변경만으로도 상속된 스타일이 깨진다면 그것은 디자인 시스템 자체의 결함이라기보다 도구를 잘못 활용하고 있기 때문입니다. 시스템은 더 많은 기능을 문서화하고 테스트하며 유지보수해야 하는 짐을 떠안게 되고 결국 스스로 만든 틀 안에 갇히고 맙니다.

하나의 컴포넌트가 모든 사람의 모든 요구사항을 해결할 필요는 없습니다.

피그마의 네이티브 슬롯 기능은 기존의 복잡한 설정용 속성들을 대체하고 상당수를 제거할 것입니다. 디자인 시스템의 진정한 힘은 수많은 스위치와 변형이 아니라 창의적이고 제약 없는 조합에서 나옵니다. 이를 위해서는 컴포넌트를 취약하게 만드는 속성들을 과감히 덜어내는 ‘설정의 붕괴’가 필요합니다.

이 글에서는 속성 중심의 사고방식에서 벗어나 순수한 컴포지션으로 나아가는 변화를 살펴봅니다. Pill, Alert, Card 컴포넌트의 구체적인 사례를 통해 그 과정을 함께 짚어보겠습니다.

[다음 내용 읽기]