25년의 경험을 집약한 최고의 프로세스 읽기
최근 한 글이 눈에 들어왔다.
제목은 이렇다. "나의 완전한 2026년 웹 디자인 & 빌드 워크플로우."
부제는 더 강하다. "25년 경험을 집약한, 현존하는 최고의 프로세스."
폴란드 출신의 디자이너 Michal Malewicz.
25년 경력. 부티크 에이전시 운영자. 유튜버.
Medium에서 상당한 팔로워를 가진 인플루언서.
그가 자신의 스튜디오에서 사용하는 실제 워크플로우를 공개했다.
이 글은 독자에 따라 매우 실무적인 지침을 주는 실용적인 글로 읽힐 수도 있고,
나처럼 그 저변에 깔린 디자인 인식과 패러다임의 변화를 제시하는 글로 읽힐 수도 있을 것이다.
나는 읽고 나서 두 가지 생각이 동시에 들었다.
하나는, 이건 실제로 작동하고 있다.
다른 하나는, 이건 조건 의존적이다.
그 두 생각 사이에 우리가 주목해야 할 것들이 있다.
이 글은 "AI가 빠르게 만들어준다"는 이야기가 아니다.
오히려 반대다.
저자는 세 가지 원칙을 명시한다.
- AI 슬롭을 만들지 말 것.
- 절대 속도를 위해 최적화하지 말 것.
- 오직 퀄리티만을 위해 AI가 작성한 코드를 이해할 것.
그리고 이렇게 덧붙인다.
"절약된 시간을 더 많은 것을 만드는 데 쓰지 않는다. 그 시간을 더 잘 만드는 데 쓴다."
AI로 아낀 시간을 생산량이 아니라 퀄리티에 쓰라는 주장이다.
마이크로 인터랙션. 픽셀 퍼펙션. 카피 다듬기. 종이 스케치부터 다시 시작하는 과정.
그는 "빠른 UX"가 아니라 "더 나은 UX"를 말하고 있다.
이 부분은 인정해야 한다.
그의 워크플로우는 대략 이렇다.
종이에 스케치한다.
Obsidian에서 마크다운으로 콘텐츠 구조를 정리한다.
Sketch로 SVG와 와이어프레임을 만든다.
그걸 Claude에게 넘겨 HTML/CSS로 구현한다.
브라우저 인스펙터로 직접 수정한다.
다시 Claude에게 코드를 정리시킨다.
Figma는 없다. 전통적인 프로토타입 단계도 없다.
디자인과 개발이 사실상 하나의 흐름으로 붙어 있다.
이건 중요한 변화의 신호다. 단순한 툴 교체가 아니다.
작업의 단위와 순서 자체가 바뀌고 있다.
시그널 1. 디자인과 프런트엔드는 다시 붙고 있다
저자는 2001년부터 이 흐름을 지켜봤다고 말한다.
초창기 웹에서 디자이너는 코딩도 했다.
이후 UX라는 이름 아래 역할이 극도로 세분화되었다.
그리고 이제 다시 합쳐지고 있다.
그는 이렇게 말한다.
"Design IS frontend."
도발적이지만, 방향은 맞다.
AI 코딩 도구의 등장으로 디자이너가 직접 구현할 수 있는 범위가 넓어졌다.
그 경계는 앞으로 계속 이동할 것이다.
시그널 2. 디자인 프로세스의 구조가 바뀌고 있다
이것이 이 글에서 가장 중요하게 읽어야 할 변화다.
전통적인 디자인 프로세스는 선형이었다.
리서치 → 정의 → 아이데이션 → 프로토타입 → 테스트 → 개발.
각 단계는 분리되어 있었다.
담당자도 달랐다.
리서처, IA, 비주얼 디자이너, 프로토타이퍼, 개발자.
단계와 단계 사이에는 문서가 있었고, 핸드오프가 있었고, 대기 시간이 있었다.
저자의 워크플로우에서 이 단계들은 하나의 루프로 압축된다.
종이 스케치(아이데이션) → 마크다운(정의) → 코드(프로토타입+개발) → 인스펙터 수정(테스트+반영) → 다시 처음으로.
단계가 사라진 것이 아니다.
단계 사이의 대기 시간이 사라진 것이다.
그리고 그 대기 시간이 사라지면서, 각 단계를 담당하던 역할의 경계도 함께 녹아내리고 있다.
이 변화는 단순한 효율 향상이 아니다.
프로세스의 구조가 바뀌면, 그 안에서 일하는 사람의 역할도 바뀐다.
그리고 역할이 바뀌면, 무엇이 중요한가에 대한 기준도 바뀐다.
시그널 3. "슬롭(slop)"에 대한 저항이 시작되었다
AI로 만든 UI가 범람하면서, 역설적으로 퀄리티에 대한 요구가 높아지고 있다.
저자는 이것을 "슬롭"이라고 부른다.
보더 안에 보더, 과잉된 아이콘, 무의미한 그라데이션.
AI가 학습한 평균값들의 조합.
이건 AI 이전에도 있었다.
저가 템플릿, 무료 클립아트.
다만 지금은 그 속도가 압도적으로 빨라졌다.
슬롭이 더 빠르게 쏟아질수록,
취향과 판단을 가진 디자이너의 가치는 역설적으로 올라간다.
저자의 진짜 주장은 여기에 있다.
여기서 중요한 질문이 등장한다.
이 워크플로우는 누구에게 적용 가능한가?
한계 1. 이건 매우 특수한 조건을 전제한다
저자의 실제 셋업을 들여다보면 놀랍다.
M4 맥북에어 2대, M1 맥미니 서버,
자체 로컬 AI 모델, 32B 파라미터 로컬 모델 서버.
하드웨어 비용만 최소 1,000만 원 안팎이다.
그리고 결정적으로,
코딩도 하는 25년 경력의 디자인-개발 하이브리드 인력 2명.
이걸 "누구나 해봐야 한다"라고 권유하는 것은 맥락 없는 보편화다.
신호는 맞다. 그러나 이 신호를 그대로 따라 하는 것은 다른 문제다.
한계 2. "Design IS frontend" 환원론의 위험
저자는 원문에서 "Design IS frontend."라고 쓰고 있다.
여기서 ‘is’를 대문자 ‘IS’로 쓴 것은 몇 가지 층위로 읽을 수 있다.
첫째, "Design is NOT frontend"라고 수십 년간 주장해 온 UX 업계의 지배적 담론을 저자가 의식하고, "그게 아니라, 디자인은 정말로 프런트엔드다"라는 강조하고 있다고 본다.
둘째, “Design Is Frontend"처럼 타이틀케이스가 아니라 "Design IS frontend"라고 쓴 것은 말하는 사람이 확신을 갖고 발화하는 선언으로써 더 즉각적이고 구어적인 힘이 나타내려는 의도로 보인다.
기사 전체 맥락에서 볼 때, 이 말은 디자인의 본질을 프런트엔드로 환원하려는 선언이라기보다,
실무에서 두 영역의 경계가 빠르게 사라지고 있다는 관찰에 가깝다.
아니 그렇게 되어야 한다는 독백이기도 하다.
그러나, 이 워크플로우가 유효한 맥락은 생각보다 좁다.
랜딩페이지. 소규모 에이전시. 스피드가 생명인 MVP.
그러나 복잡한 서비스 시스템, 공공 서비스, 헬스케어 UX,
장기 사용자 경험 전략에서는 리서치, 전략, 서비스 설계의 층위가 없으면 결과물이 위험해진다.
"디자인 = 프런트엔드"로 환원되는 순간, 삭제되는 것들이 있다.
사용자가 왜 머무르는가.
무엇을 신뢰하는가.
어느 순간 이 서비스를 떠나는가.
이 질문들은 코드로 해결되지 않는다.
그리고 이 질문들을 다루는 것이,
전통적인 디자인 프로세스에서 대기 시간처럼 보였던 단계들의 실제 역할이었다.
한계 3. 판단 기준은 복사되지 않는다
저자는 슬롭을 만들지 않겠다고 말한다.
그 판단의 기준은 자신의 취향과 경험이다.
그 취향은 어디서 왔는가.
25년의 관찰, 반복된 실패, 수천 개의 프로젝트.
대부분의 팀에는 이 경험이 없다.
워크플로우는 복사할 수 있다.
판단 기준은 복사되지 않는다.
이것이 이 글이 조용히 전제하는 가장 큰 조건이다.
이 글은 정답이 아니다. 그러나 신호는 맞다.
그 신호를 어떻게 해석할 것인가.
해석 1. 사라진 것은 단계가 아니라 대기 시간이다
전통적인 프로세스가 나빴던 것이 아니다.
리서치, 아이데이션, 프로토타이핑, 테스트.
이 활동들은 여전히 필요하다.
달라진 것은 이 활동들이 순서대로 기다릴 필요가 없어졌다는 것이다.
생각하면서 동시에 만든다.
만들면서 동시에 테스트한다.
테스트하면서 동시에 수정한다.
이것이 AI가 디자인 프로세스에 가져온 실질적인 변화다.
단계의 삭제가 아니라 단계 사이 마찰의 제거.
이 변화를 "단계가 없어도 된다"로 읽으면 위험하다.
"단계를 더 유연하게 오갈 수 있게 되었다"로 읽어야 한다.
해석 2. "Easy to Use"에서 "Easy to Live"로 가는 과도기의 단면
이 워크플로우가 가장 강력하게 작동하는 것은 화면 중심의 UX다.
랜딩페이지. 컴포넌트. 마이크로 인터랙션.
이 영역에서 AI는 강력하다.
그러나 디자인의 다음 과제는 화면이 아니다.
맥락이다. 삶의 흐름이다. 관계의 설계다.
저자의 워크플로우는 여전히 화면 중심 UX,
즉 “Easy to Use” 패러다임에 강하게 최적화되어 있다.
하지만 "Easy to Live"는 다른 질문을 요구한다.
AI는 화면을 잘 만든다. 그러나 삶을 설계하지는 못한다.
그 경계가 어디인지를 인식하는 것,
그것이 지금 디자이너에게 필요한 판단이다.
해석 3. 워크플로우가 바뀌면, 디자이너에게 남는 것이 달라진다
저자의 워크플로우에서 디자이너는 여전히 핵심이다.
그러나 그 역할이 달라진다.
만드는 사람이 아니라 → 선택하는 사람.
실행하는 사람이 아니라 → 판단하는 사람.
화면을 구성하는 사람이 아니라 → 기준을 설정하는 사람.
AI가 여러 개의 선택지를 내놓을 때,
어느 것이 이 사용자에게, 이 상황에, 이 시점에 맞는가를 결정하는 것.
그것이 디자이너의 역할로 남는다.
이것은 더 쉬운 일이 아니다. 오히려 더 어려운 일이다.
기준이 없으면, 선택할 수 없기 때문이다.
해석 4. 속도가 빨라질수록, 책임은 더 무거워진다
저자는 "빠르게 만드는 것"을 목표로 삼지 않는다고 말한다.
그건 옳다.
그러나 워크플로우 전체가 빨라지는 것은 사실이다.
빠른 실행은 빠른 실수를 만든다.
잘못된 UX, 잘못된 유도, 잘못된 판단이 더 빨리 배포된다.
누가 그 결과에 서명하는가.
AI는 서명하지 않는다.
결국 디자이너가 서명한다.
프로세스가 효율화될수록, 책임 결정자로서의 역할은 더 선명해진다.
저자와 나는 사실 같은 결론에 도달하고 있다.
AI를 도구로 사용하되, 디자이너의 판단이 주도해야 한다.
속도가 아니라 퀄리티.
생산량이 아니라 방향.
그러나 저자는 워크플로우를 말하고, 나는 역할을 말한다.
워크플로우는 따라 할 수 있다.
역할은 내면화해야 한다.
이 글을 읽고 "나도 Claude Code로 코딩해야겠다"라고 생각한다면, 절반만 읽은 것이다.
이 글이 보여주는 진짜 신호는 이것이다.
디자인의 실행 레이어는 AI에게 이동하고 있다. 그 이동은 멈추지 않는다.
그렇다면 디자이너에게 남는 것은 무엇인가. 실행이 아닌 것들이다.
기준을 갖는 것.
맥락을 읽는 것.
책임을 지는 것.
방향을 선택하는 것.
AI는 속도다. 우리는 방향이다.
속도가 빨라질수록, 방향이 더 중요해진다.
그리고 방향은 워크플로우에서 나오지 않는다.
디자이너의 관점에서 나온다.
이 변화 속에서 맥락 설계자로서 디자이너의 역할은 이전 글 “보이지 않는 것을 보여주는 질문(https://brunch.co.kr/@tonysungsik/47)”에서 더 자세히 다루었습니다.