[번역] Design engineering, a working definition

[번역] Design engineering, a working definition

2025-11-07

Sean Voison의 Design engineering, a working definition를 번역한 글입니다.

디자인 엔지니어링, 실무 관점에서의 정의

2024년 3월 4일

크리스 코이어(Chris Coyier)가 언급했듯이, 디자인 엔지니어링은 지금 주목받는 분야가 되고 있습니다.

단지 ‘빈도 착각(Frequency Illusion)’ 때문일 수도 있지만, 최근 들어 디자인 엔지니어링과 그것이 소프트웨어 디자인 및 개발 프로세스에 미치는 영향에 대해 다루는 블로그 글이 부쩍 늘어난 것 같습니다. 아래는 지난 몇 주 동안 내가 접한 글들 중 일부입니다:

저는 현재 Adobe 디자인 조직에서 디자인 엔지니어 팀을 이끌며 생계를 꾸리고 있고, 이전 커리어의 상당 부분도 디자인 엔지니어로 일해왔습니다. 그래서 이 주제에 대해 나름의 생각이 있습니다. 특히, 우리가 ‘디자인 엔지니어’라는 역할을 어떻게 정의할 것인지에 관해 할 말이 있고, 이 논의에 제 목소리를 보태지 않는다면 아쉬울 것 같다는 생각이 듭니다.

다른 여러 융합·복합 분야의 역할과 마찬가지로, 디자인 엔지니어라는 역할도 명확히 정의하기가 쉽지 않습니다. “Design Engineer”라는 직함이 점점 더 널리 쓰이고 있지만, 정작 이를 무엇이라 불러야 할지에 대한 합의조차 이뤄지지 않은 상태죠. 업계에서는 UI Engineer, UX Engineer, Design Technologist, Experience Developer, Design Prototyper, Creative Technologist 등 거의 동의어나 비슷한 의미로 쓰이는 다양한 직함을 접하게 됩니다.

또 하나의 어려움은 “Design Engineer”라는 명칭이 이미 다른 공학 분야에서도 사용되고 있다는 점인데, 그 분야에서의 의미는 소프트웨어 맥락에서 우리가 정의하고 있는 역할과는 크게 다르다는 것입니다.

그럼에도 불구하고, “Design Engineer”가 가장 강력하게 자리 잡고 있는 이름인 듯합니다. 저는 그걸로 충분히 괜찮다고 생각합니다.

디자인 엔지니어를 설명할 때 흔히 쓰이는 간단한 정의는 이렇습니다: 소프트웨어 디자인과 엔지니어링의 교차점에 전문성을 가진 사람. 종종 “코드를 작성하는 디자이너”, “디자인 역량을 갖춘 엔지니어”라고 표현하기도 하죠.

물론 이런 설명이 완전히 틀린 건 아니지만, 정의로서 보면 다소 자가당착적이고 실질적인 도움이 되지는 않습니다. 디자인 엔지니어 역할을 제대로 설명하려면, 디자인 엔지니어가 실제로 무엇을 하는 사람인지부터 이야기해야 합니다.

그래서 저는 제가 생각하는 **실무적 정의(working definition)**를 가지고 있습니다. 여기서 working이라고 덧붙이는 이유는, 제 정의가 디자인 엔지니어링의 정석적이거나 공식적인 정의라고 말하려는 것이 전혀 아니기 때문입니다. 다만 우리 조직 내에서 제 팀이 어떤 일을 하고 어떤 위치에 있는지를 설명할 때 제가 자주 사용하는 정의이고, 그런 면에서 꽤 유용하다고 느껴왔습니다.

디자인 엔지니어링은 무엇일까요?

제가 생각하는 실무적 정의는 이렇습니다.

디자인 엔지니어링이란, 디자인과 엔지니어링이 맞닿는 지점에서 발생하는 특수한 문제들을 해결하는 역할입니다. 좀 더 구체적으로 말하면, 디자인 엔지니어링은 다음 세 가지 핵심 활동을 통해 사용자 경험(UX) 디자인을 강화하고 개선하며, 뒷받침하는 일입니다:

  1. 새로운 제품 경험을 프로토타이핑하여 디자이너가 디자인을 탐색하고, 가설과 의도를 검증할 수 있도록 돕는 것
  2. 디자인이 확장 가능한 방식으로 운영되도록 지원하는 도구와 인프라를 구축하고, 디자이너–개발자 간의 협업 워크플로우를 매끄럽게 만드는 것 (예: 디자인 시스템)
  3. 일반 엔지니어들이 여러 이유로 구현하기 어렵거나 구현하려 하지 않는 사용자 인터페이스나 제품 경험을, 디자인 의도를 온전히 유지한 채 구현하는 것

이 글의 남은 부분에서는 앞서 언급한 세 가지 핵심 활동에 대해 좀 더 자세히 설명하려고 합니다. 다만 그 전에, 제가 가진 관점과 전제가 어떤 것인지 간단히 짚고 넘어가고자 합니다.

디자인 엔지니어링이 무엇을 다루고, 무엇을 아닌지

디자인 엔지니어링은 디자인을 위한 일이다

“Design Engineer”라는 이름에서 디자인(design) 이 앞에 오는 데에는 이유가 있다고 생각합니다. 디자인 엔지니어링은 디자인을 지원하고, 제품 개발 결과물이 디자인 의도에 충실하게 구현되도록 보장하기 위해 존재합니다.

디자인 엔지니어는 다른 엔지니어들과 긴밀히 협업하며 그들의 업무를 돕기도 합니다 — 즉, 엔지니어링 실무와도 맞닿아 있습니다. 하지만 그렇다고 해서 엔지니어링 그 자체의 발전을 주된 목적으로 삼는 것은 아닙니다. 디자인 엔지니어가 봉사하는 대상은 엔지니어링이 아니라 디자인입니다.

이 점에서 SRE나 DevOps 엔지니어처럼 엔지니어링 프로세스를 개선하고 지원하는 데 초점을 둔 역할과는 분명한 차이가 있습니다.

그렇다고 해서 디자인 엔지니어링이 제품 엔지니어링 과정에 도움이 되지 않는다는 뜻은 아닙니다. 실제로 디자인 엔지니어링은 언제나 — 그리고 종종 매우 큰 폭으로 — 제품 엔지니어링에 기여합니다.

예를 들어, 잘 구축된 UI 컴포넌트 라이브러리는 강력한 프런트엔드 인프라 자산으로, 이를 잘 활용하는 팀의 개발 속도를 확실히 높여줍니다. 디자인 엔지니어는 다른 엔지니어들이 맡기 어렵거나 맡고 싶어 하지 않는 기능을 구현하며, 그렇지 않았다면 놓치기 쉬운 완성도와 정교함을 사용자 경험에 더합니다. 또한 프로토타이핑 과정에서 특정 기술적 문제를 해결하거나, 프로덕션 단계에서 제품 엔지니어들이 참고하거나 재사용할 수 있는 코드 조각을 만들어내기도 합니다.

그럼에도 불구하고, 잘된 디자인 엔지니어링은 언제나 ‘디자인 우선, 엔지니어링은 그 다음’입니다.

디자인 엔지니어링은 웹에만 국한된 역할이 아니다

디자인 엔지니어링을 다루는 많은 글과 블로그 포스트를 보면, 웹과 웹 기술에만 초점을 맞춘 편향이 종종 보입니다. 아마도 “디자인 엔지니어링”이라는 직함이 웹 개발 커뮤니티의 논의 속에서 부상했기 때문일 것입니다. 하지만 디자인 엔지니어링은 특정 기술이나 기술 스택에 제한될 필요가 없습니다.

디자인 엔지니어는 네이티브 모바일 경험, VR/AR 경험, 데스크톱 애플리케이션 경험을 구축할 수도 있습니다. 업계의 뛰어난 디자인 엔지니어 중 상당수는 다양한 플랫폼과 기술 스택을 넘나들 수 있는 역량을 갖추고 있으며, 어떤 이들은 웹 작업만큼이나 Swift로 네이티브 앱을 구현하는 데에도 능숙합니다.

커리어 경로와 조직 구조에 대한 짧은 이야기

디자인 엔지니어링을 디자인 중심 관점에서 바라보면, 이는 조직 설계 측면에서도 몇 가지 시사점을 줍니다. 특히, 디자인 조직이 존재하는 회사라면 디자인 엔지니어가 디자인 조직 소속으로 활동하는 것이 더 적합할 수 있다는 의미입니다.

그 이유는 디자인 엔지니어의 일이 가장 높은 가치를 인정받는 곳이 바로 디자인 팀과 디자이너들이기 때문입니다. 사용자 경험(UX) 프로토타이핑이나 디자인 시스템 구축은 근본적으로 디자인을 더 나아지게 하고, 더 확장 가능하고, 더 효과적으로 만드는 일이니까요.

하지만 이러한 디자인 중심 관점은 동시에 한 가지 난제를 가져옵니다. 디자인 엔지니어링은 엄연히 소프트웨어 엔지니어링의 한 형태이기 때문입니다. 디자인 엔지니어링의 실천에는 코드 작성이 필수적이며, 디자인 엔지니어가 작성한 코드나 구축한 라이브러리가 다른 엔지니어들에게 핵심적으로 활용되는 경우도 많습니다.

문제는 많은 디자인 조직이, 주 업무가 코딩인 구성원의 커리어 성장을 충분히 지원할 수 있는 구조가 아니라는 점입니다. 그렇다면 디자인 엔지니어는 자신의 기술적 업무와 고유한 역량을 완전히 이해하지 못할 수 있는 디자인 리더에게 보고하는 것이 맞을까요? 아니면 엔지니어링 조직 내에서 고립된 전문가 형태로 활동하는 것이 더 나을까요? 그리고 각각의 운영 방식에서, 매니지먼트와 시니어 IC(개인 기여자) 레벨의 디자인 엔지니어 리더십은 어떤 모습이어야 할까요?

이 질문들에 대해 정답은 하나로 정해져 있지 않습니다. 좋은 조직 설계는 언제나 해당 조직의 고유한 맥락에 따라 달라지기 마련입니다. (조직 설계에 관심이 있다면 Org Design for Design Orgs와 Design Engineering Handbook 4장을 추천합니다. 특히 후자는 디자인 엔지니어링을 위한 다양한 조직 모델의 장단점을 이해하는 데 도움이 되는 인사이트를 제공합니다.)

디자인 엔지니어링의 세 가지 활동

프로토타이핑

프로토타이핑은 그 자체로 하나의 글—아니, 어쩌면 한 권의 책이 필요할 정도로 방대한 주제입니다. 여기서는 몇 문단으로만 간단히 다뤄보려고 합니다.

디자이너는 실제로 작동하는 프로토타입이 없이는 자신의 디자인에 대해 알거나 이해할 수 없는 부분이 많습니다. 그리고 Figma에서 만들 수 있는 클릭 기반의 프로토타입만으로는 충분하지 않은 디자인들도 존재합니다. 바로 이 지점에서 프로토타이핑을 수행하는 디자인 엔지니어링의 역할이 중요해집니다. 코드로 구현된 고품질의 실제 동작 프로토타입은 여러 면에서 큰 가치를 제공합니다. 디자인과 엔지니어링 사이에 존재하는 암묵적인 가정을 없애주고, 불필요한 회의 시간을 줄여 팀이 더 빠르게 합의를 이루도록 돕습니다. 또한 제품 개발이 완료된 후에야 드러날 수 있는 비싼 실수를 사전에 방지하고, 기술적으로 가능한 것과 불가능한 것을 파악하는 데 기여하며, 더 나아가 새로운 디자인 방향과 가능성을 발견하게 해줍니다.

새롭거나 즐거움을 주는 사용자 인터랙션을 프로토타이핑하는 작업은, 사람들이 이름 있는 디자인 엔지니어를 떠올릴 때 가장 흔히 연상하는 모습입니다. 예를 들어, Maggie Appleton이 정리한 디자인 엔지니어 모음에 소개된 이들 대부분은 이러한 인터랙션을 직접 디자인하고, 공개적으로 프로토타입까지 만드는 사람들입니다. 이들은 새로운 인터랙션 패턴을 떠올리고, 그것을 실제로 작동하는 형태로 구현해 공개할 만큼의 미감과 디자인 감각, 그리고 프로그래밍 능력을 가진 경우가 많습니다. 그중 일부는 프로토타이핑 단계에서 그치지 않고, 자신이 만든 아이디어를 실제 제품 단계까지 발전시킬 수 있는 엔지니어링 역량까지 갖추고 있습니다.

저는 프로토타이핑의 영역에, 제품 초기 단계에서의 신제품 인큐베이션 업무—David Hoang이 디자인 엔지니어링 글에서 0→1 R&D라고 부르는 과정—도 포함된다고 봅니다. 성공적인 프로토타입을 만들기 위해 필요한 능력은 R&D 단계에서 새로운 제품 아이디어를 출발시키는 데 필요한 역량과 크게 겹칩니다. 즉, 민첩하게 움직일 수 있는 실행력, 좋은 디자인 감각, 새로운 기술을 빠르게 익히는 능력, 그리고 과감히 버릴 수 있는 코드를 많이 작성할 의지 같은 것들입니다.

프로토타이핑 역할이 디자인–엔지니어링 스펙트럼 중 디자인 쪽에 더 치우친 사람들은 “디자인 엔지니어”라는 직함에 거부감을 느낄 수도 있습니다. 어쨌든 프로토타이핑은 전통적인 의미의 엔지니어링이라고 보기 어렵기 때문입니다. 굳이 말하자면, 프로토타이핑은 코드로 디자인하는 일에 가깝습니다. (내 팀의 한 동료는 이를 “타이핑으로 디자인하기”라고 표현하곤 합니다.) 일부 회사에서는 프로토타이핑에 특화된 역할을, 디자인 시스템을 구축하는 디자인 엔지니어와 구분하기 위해 UX 엔지니어, UI 엔지니어, 혹은 경험 개발자(Experience Developer) 등으로 부르기도 합니다. 하지만 솔직히 말해, 이런 직함의 차이가 두 역할을 충분히 분별해준다고 생각하지는 않습니다. 오히려 더 큰 혼란을 낳는 경우가 많다고 봅니다.

툴링과 인프라 구축

디자인을 위한 툴과 인프라를 구축하는 일의 대부분은 디자인 시스템 엔지니어링의 영역에 속합니다. 그리고 프로토타이핑과 마찬가지로, 디자인 시스템 엔지니어링 역시 책 한 권이 필요할 만큼 방대한 주제입니다. 하지만 여기서는 간단히 요약하는 정도로만 다뤄보려 합니다.

디자인 시스템 엔지니어는 일반적으로 다음과 같은 활동을 수행합니다:

  • 디자인 토큰 시스템과 관련 변환 도구 또는 파이프라인 등 디자인 시스템 인프라를 설계하고 구축한다.
  • 디자인 시스템 문서 및 해당 문서를 배포하기 위한 문서화 인프라를 설계·구축·유지한다.
  • 디자이너가 사용하는 디자인 툴 플러그인 또는 기타 커스텀 툴을 설계·구축·유지한다.
  • 디자인 시스템 구현체(예: 컴포넌트 라이브러리)를 구축한다.

그리고 이 밖에도 디자인 엔지니어가 수행하는 접착(glue) 역할의 업무들이 무척 많습니다. 예를 들어 문서를 작성하거나, 다양한 기능 조직과 지속적으로 협업·조율하는 일 등이 있는데, 앞에서 구체적으로 언급하지는 않았지만 암묵적으로 포함되어 있습니다.

디자인 시스템 엔지니어링이 프로토타이핑과 공통으로 가지는 점은 디자이너와 개발자 간의 협업과 워크플로우를 매끄럽게 만든다는 역할입니다. 프로토타입이 디자인 의도를 엔지니어에게 전달하는 데 가장 효과적인 산출물이라면, 디자인 시스템 구현체는 그 의도를 재사용 가능한 컴포넌트로 코드화하여, 제대로 구축되었을 때 다른 엔지니어들의 작업 속도를 크게 높여줍니다.

디자인 시스템 엔지니어링에서는 디테일에 대한 집요한 열정이 빛납니다. 디자인 엔지니어들은 재사용 가능하고, 접근성이 뛰어나며, 즐거운 마이크로 인터랙션을 갖춘 컴포넌트를 만들기 위해 노력합니다. 이러한 컴포넌트는 잘 설계되고, 충분히 테스트되며, 다른 환경에 쉽게 통합될 수 있어야 합니다.

UI 구축

때로는, 특정 UI 요소나 제품 내 전체 경험을 구현하는 데 있어 디자인 엔지니어가 회사에서 가장 적합한 사람일 때가 있습니다. 이러한 작업은 초기에는 프로토타입으로 시작했지만, 출시 단계까지 완전히 구현해내는 과정을 포함하기도 합니다. 또 다른 경우에는, 강한 디자인 감각과 디테일을 섬세하게 다듬는 노력이 필요한 특정 UI 기능을 구현하기 위해 디자인 엔지니어가 투입되기도 합니다. 예를 들어, 사용자가 화면을 직접 조작하는 직접 조작(Direct Manipulation) 인터랙션과 같은 영역에서는 프레임 드롭, 타이밍 미세 오류, 위치의 작은 글리치도 즉시 눈에 띕니다. 이런 종류의 프로젝트는 디자인 엔지니어가 특히 강점을 발휘하는 분야입니다.

UI를 구축하는 디자인 엔지니어와 프런트엔드 엔지니어를 혼동하는 위험이 있습니다. 어찌 되었든 UI를 만든다는 점만 놓고 보면, 두 역할이 하는 일이 거의 동일해 보이지 않나요? 경계가 모호하긴 하지만 분명한 차이가 있습니다. 디자인 엔지니어는 훌륭한 디자인을 실현하기 위해 존재한다는 점입니다. 디자인 엔지니어가 프런트엔드 엔지니어링 팀에 포함되어 있을 수도 있습니다. 그러나 그들의 역할은 단순히 명세서대로 UI를 구현하는 데 그치지 않습니다. 디자이너가 처음부터 명확히 문서화하기 어려운 인터랙션 패턴, 애니메이션의 미묘한 뉘앙스, 다양한 디테일을 함께 정의하고 다듬는 것, 바로 그 사용자 경험 영역에 집중하는 것이 디자인 엔지니어의 역할이어야 합니다.

이 세 가지로 정리한 실무적 정의가 비교적 명확해 보일 수 있음에도, 내가 디자인 엔지니어링에서 가장 좋아하는 점은 학제 간 융합이라는 특성 속의 모호함입니다. 디자인 엔지니어는 이미 각각 확립된 두 분야 사이의 경계 공간(liminal space) 속에서 능력을 발휘할 수 있는 독특한 역량을 지니고 있으며, 그 공간 안에서 두 세계를 잇는 다리 역할을 하며, 디자인과 엔지니어링 간의 협업을 강화합니다. 그리고 궁극적으로, 이는 사용자에게 더 나은 경험을 제공하는 결과로 이어집니다.