디자인 엔지니어가 되어야 할까?

디자인 업계에는 오랫동안 같은 질문이 반복됐다. 디자이너는 코딩을 배워야 하나?

찬성하는 쪽은 디자이너가 자신이 설계하는 매체, 즉 실제 인터페이스 기술을 이해하면 그 매체의 제약을 활용하는 화면과 워크플로우를 만들 수 있다고 말한다. 제품을 구현하는 엔지니어와 더 잘 대화할 수 있다는 주장도 붙는다. 반대하는 쪽은 디자이너에게 이미 할 일이 충분하며, 코드를 배우다가 본래의 책임을 놓칠 수 있다고 본다. 유지보수 가능하고 프로덕션에 넣을 수 있는 코드를 만들기 어렵다는 현실적인 우려도 있음.

하지만 “디자이너는 코딩해야 한다”는 질문은 정답이 없는 문제를 이분법으로 만든다. 더 쓸모 있는 질문은 이쪽에 가깝다. 나는 협업하는 다른 분야의 기술을 얼마나 배울 것인가? 디자이너라면 코딩을, 개발자라면 디자인을 배울 것인가. 어느 정도까지 분야의 경계를 넘을지는 커리어와 선호에 따라 달라진다.

Adobe는 디자인과 엔지니어링이 겹치는 지점에서 일하는 사람들을 디자인 엔지니어(design engineer)라고 부른다. UX 엔지니어, UI 엔지니어, 디자인 테크놀로지스트, 경험 개발자, 디자인 프로토타이퍼, 크리에이티브 테크놀로지스트 등 여러 이름이 있지만, 공통점은 디자이너와 개발자 어느 한쪽의 상자에도 깔끔하게 들어맞지 않는다는 데 있다. 한때는 이런 사람들을 “유니콘”이라고 부르기도 했음.

디자인 엔지니어가 실제로 하는 일

Adobe가 설명하는 역할은 세 가지다.

• 새로운 제품 경험을 프로토타이핑함 — 디자이너가 자신의 디자인을 더 잘 이해하고, 디자인 가정을 검증하도록 도움
• 디자인 시스템과 인프라를 만듦 — 디자이너와 개발자의 협업을 매끄럽게 하고, 디자인 조직이 규모 있게 움직이도록 함
• 제품 경험에 완성도와 섬세함을 더함 — 특정 기술이나 전문성, 디테일을 끝까지 다듬는 태도가 필요한 부분을 맡음

이 가운데 무엇인가가 끌린다면 디자인 엔지니어링이 맞을 수 있다는 설명이다.

프로토타입은 말하지 않은 가정을 드러낸다

디자인 도구에서 만드는 클릭형 프로토타입만으로는 알 수 없는 것이 많다. 실제로 작동하는 고해상도 프로토타입은 디자인과 엔지니어링 사이의 말하지 않은 가정을 줄이고, 회의 시간을 낮추며, 합의를 빠르게 만든다. 개발 도중이나 출시 뒤에야 발견할 값비싼 실수를 미리 찾고, 기술적 가능성과 한계, 새로운 디자인 방향도 확인할 수 있음.

출처: Adobe Design. Photoshop의 Generative Fill용 Reference Image 기능은 작동하는 프로토타입으로 시작했고, 사용자 연구의 피드백을 반영하며 다듬어졌다.

Adobe에는 고해상도 프로토타이핑을 별도 분야로 맡는 디자인 엔지니어와 매니저가 24명 넘게 있다. 이 팀은 디자이너와 UX 리서처와 함께 문제를 이해하고, 프로토타입을 설계·구현한 뒤 실제 사용자에게 테스트한다. 배운 내용을 디자인에 반영하고 다시 만들고 검증하는 과정을 반복함.

이 일에는 엔지니어링 역량과 디자인 감각뿐 아니라, 언제든 만든 것을 버리고 처음부터 다시 시작할 수 있는 태도가 필요하다. 프로토타이퍼는 보안·확장성·프로덕션 코드 같은 엔지니어링 팀의 제약에 묶이지 않기 때문에 짧은 시간 안에 만들고 빠르게 피드백을 받는다. 버려도 되는 코드를 편하게 쓰고, 초기 탐색 단계에서 디자이너와 제품 파트너가 만들고 싶은 경험을 더 잘 이해하도록 돕는 역할임.

디자인 시스템은 의도를 재사용 가능한 코드로 만든다

반대로 버리는 프로토타입보다 오래 유지되는 고품질 코드를 만드는 데 끌리는 사람도 있다. 디자인 시스템 엔지니어링이 그 경로다.

출처: Adobe Design. Adobe Spectrum의 도구·컴포넌트·인프라가 여러 제품의 경험을 일관되게 만드는 방식.

프로토타입이 디자인 의도를 엔지니어에게 보여줘 모호함을 없앤다면, 디자인 시스템 구현은 그 의도를 재사용 가능한 컴포넌트로 고정한다. 좋은 컴포넌트는 접근 가능하고, 테스트되어 있으며, 통합하기 쉽고, 작은 상호작용까지 세심하게 다듬어져야 한다.

구체적으로는 다음과 같은 일을 한다.

• 토큰 시스템과 변환 도구·파이프라인 같은 디자인 시스템 인프라 구축
• 디자인 시스템 문서 작성과 유지보수
• 디자이너가 사용하는 디자인 도구 플러그인과 맞춤형 도구 개발
• 고품질·접근성·성능을 갖춘 UI 컴포넌트 라이브러리 구축

여기에 문서 작성, 여러 제품 팀의 디자인 시스템 도입 지원, 접근성 자문 같은 조직의 연결 작업(glue work)도 포함된다. Adobe의 Spectrum 팀은 여러 제품에서 일관된 경험을 가능하게 하는 프런트엔드 인프라를 돌보는 역할까지 맡고 있음.

UI의 디테일을 끝까지 다루는 사람

어떤 UI의 한 부분이나 제품 전체의 경험을 완성하려면 특별한 집중력과 만드는 감각이 필요할 때가 있다. 거친 프로토타입을 프로덕션 수준으로 다듬기도 하고, 기존 엔지니어링 방식만으로는 까다로운 UI 기능을 구현하기도 한다.

디자인 엔지니어는 소프트웨어라는 재료의 성질과 그 매체가 제공하는 구체적인 가능성, 그것을 다루는 도구를 깊이 이해한다. 디자인에 대한 감각과 기술적 독립성을 함께 키우면서, 아름답고 의도적인 결과를 만들려는 집착이 이 역할을 움직인다는 설명이다.

출처: Adobe Design. Apple Vision Pro용 Adobe Firefly 개발에는 UI 엔지니어링과 공간 컴퓨팅 역량이 필요했다.

이들은 넓게는 디자인을 이해하고, 깊게는 렌더링·애니메이션·레이아웃 같은 UI 엔지니어링을 다루는 T자형 인재다. 직접 조작하는 화면에서 프레임이 떨어지거나 타이밍이 어긋나거나 위치가 조금만 틀어져도 사용자가 바로 알아채는 프로젝트에 강하다. 스크롤에 반응하는 마케팅 페이지의 애니메이션이나 제품의 작은 상호작용을 만드는 일도 여기에 들어간다.

Adobe가 제시한 전문 분야만 해도 2D 기하학, 3D 셰이더와 렌더링, SVG, 타이포그래피 레이아웃, 웹 프런트엔드, 머신러닝, SwiftUI와 iOS 개발까지 폭이 넓다. 모든 사람이 이 기술을 다 배워야 한다는 뜻은 아니다. 필요한 프로젝트에 맞는 사람을 연결해 원래의 디자인 의도를 살리는 구조에 가깝다.

디자인 엔지니어링을 시작하는 방법

디자이너나 개발자 중 하나로만 남는 대신, 새로운 사용자 경험을 설계하고 만드는 다분야 소프트웨어 메이커가 되고 싶다면 시작해볼 수 있다.

1. 프로토타이핑에 뛰어들기 — 코드가 익숙하지 않아도 노코드·로우코드 도구로 작동하는 프로토타입을 만들 수 있다. 생성형 AI는 자연어로 프로그래밍을 배우고 디자인을 작동하는 결과물로 옮기는 진입장벽도 낮추고 있음.
2. 회사 디자인 시스템에 기여하기 — 버그를 고치고, 문서를 쓰고, 토큰 시스템을 배우고, 컴포넌트를 추가한다. 사내 디자인 시스템은 내부 오픈소스 프로젝트처럼 운영되는 경우가 많음.
3. 작은 UI 엔지니어링 프로젝트 맡기 — 핵심 경로 밖에서 직접 고치거나 만들 수 있는 UI를 찾는다. 엔지니어라면 프로토타입으로 새 디자인에 대한 조직의 동의를 만들고, 디자이너라면 작은 UI부터 직접 개선한다. 자율성은 대개 먼저 움직이는 데서 시작된다는 조언이다.

crit의 관점

이 글은 “모든 디자이너가 코딩을 배워야 한다”는 선언이 아니라, 디자인과 엔지니어링 사이에서 어떤 일을 맡고 싶은지 구체화한다. 다만 Adobe의 사례는 24명이 넘는 전담 인력과 Spectrum 같은 큰 조직을 전제로 하므로, 작은 팀에서 디자인 엔지니어에게 프로토타이핑·시스템 관리·프로덕션 품질을 한꺼번에 요구하는 근거로 읽어서는 곤란하다. 생성형 AI가 진입장벽을 낮춰도, 버려도 되는 실험 코드와 오래 책임져야 하는 제품 코드를 누가 구분하고 평가할지는 여전히 남아 있다.