디자인 의도를 구현에 충실히 반영하는 엔지니어링 역량과 그것을 기르는 방법에 대한 글.
2002년, 나는 새로운 역할을 맡은 지 몇 주 되지 않은 상태였다. 대학을 졸업한 지 2년이 지난 뒤 맡은 두 번째 직무였다. 나는 런던의 크리에이티브 에이전시 AKQA에서 프론트엔드 엔지니어로 일하고 있었다. 막 첫 프로젝트 중 하나를 끝낸 참이었는데, 클라이언트를 위한 새 페이지를 구축했고, 나는 그것이 정말 훌륭해 보인다고 생각했다. 그래서 디자이너에게 작업이 끝났다고 말했다.
잠시 후, 엔지니어링 룸에서 그의 목소리가 들렸다. Den? Where’s Den? 그는 내 자리로 와서 Photoshop을 열었다. 내가 만든 결과물의 스크린샷을 한 레이어에, 자신의 원본 디자인을 다른 레이어에 올린 뒤, 불투명도를 50%로 낮춰 내가 직접 차이를 보게 했다.
모든 것이 어긋나 있었다. 간격, 정렬, 타이포그래피 렌더링, 시각적 무게감. 엄청나게 큰 차이는 아니었지만, 충분히 달랐다. 내가 만든 것은 그가 디자인한 것과 동일하다고 맹세할 수 있을 정도였는데도, 실제로는 느낌 이 달랐다.
나는 당황했다. 나는 정말 끝났다고 확신하고 있었다.
그날 내 머릿속에서 뭔가가 다시 배선된 듯했다. 정확히 새로운 기술이라기보다, 새로운 방식으로 보는 눈이 생긴 것이었다. 나는 내가 만든 것을 내 눈으로만이 아니라, 디자이너의 눈으로도 볼 수 있는 엔지니어가 되어가기 시작했다.
디자이너가 의도한 것과 엔지니어가 실제로 출시하는 것 사이의 간극은 우리 업계에서 가장 오래된 문제 중 하나이며, 그날 이후 내 경력을 규정해 왔다. 나는 이것이 소프트웨어 엔지니어링에서 가장 저평가된 기술이라고 믿게 되었다.
현재 Notion에 있는 Brian Lovin은 최근 자신이 “design-minded frontend engineers”라고 부른 사람들을 채용하는 어려움에 대해 썼다. 그가 묘사한 고충은 널리 공유되고 있다. 코드를 작성할 수 있는 엔지니어는 있고, 디자인할 수 있는 디자이너도 있다. 하지만 실제 제품을 만들면서 디자인 의도에 충실할 수 있는 엔지니어는? 그 인재 풀은 거의 사라질 정도로 작다.
Lovin의 틀은 특히 프론트엔드 엔지니어에 관한 것이었지만, 그가 말하는 간극은 웹만의 문제가 아니라 일반적인 UI 문제다. 모바일 엔지니어는 디자인에서 벗어난 앱을 출시한다. 임베디드 엔지니어는 자동차, 가전제품, ATM, POS 단말기, 의료기기용 인터페이스를 만들며, 그곳에서는 잘못 판단된 터치 타깃이 현실 세계의 결과로 이어질 수 있다. 사람이 소프트웨어를 만지는 모든 곳에서는, 디자인된 것과 실제로 구현된 것 사이의 공간을 누군가가 메워야 하며, 그 사람이 어떤 플랫폼에서 일하든 엔지니어라는 사실은 변하지 않는다.
이 간극에서 인상적인 점은, 이미 그것에 대해 얼마나 많은 글이 쓰였는지, 그리고 실제로 얼마나 적게 변했는지다. 디자이너들은 수년간 이 문제에 이름을 붙여 왔다. 엔지니어가 자신들의 디자인을 망가뜨린다는 글, 핸드오프 과정에 대한 글, 그리고 협업이 무너지는 지점에 대한 컨퍼런스 발표까지. 이 문제에 대한 디자이너의 관점은 이미 잘 정립된 문헌이다. 하지만 그 문헌은 디자이너가 디자이너를 위해 쓴 것이며, 디자이너끼리 이 문제를 아무리 논의해도 해결되지 않았다. 왜냐하면 그것을 해결하는 일은 애초에 디자이너 혼자서 할 수 있는 일이 아니었기 때문이다. 엔지니어는 대화의 다른 절반이고, 변화해야 하는 쪽도 바로 그 절반이다.
그리고 여기서 중요한 점이 있다. 이것은 디자인 시스템이나 컴포넌트 라이브러리의 부상과 함께 새로 생긴 문제가 아니다. 디자이너가 처음으로 목업을 엔지니어에게 건네고, 거의 맞지만 어딘가 부족한 무언가를 돌려받았던 바로 그 순간부터 존재해 온 문제다. 목업과 출시된 제품 사이의 간극은 엔지니어링 문제이며, 해결책이 있는 문제다. 그 간극을 메우는 데 필요한 기술은 가르칠 수 있다.
디자인에 대해 이해해야 할 것은, 디자인이 목업 그 자체가 아니라는 점이다. 디자인은 사람이 출시된 제품을 사용할 때 겪는 경험이다. 그 경험은 디자이너가 설명하고 의도한 것을 바탕으로 엔지니어가 만들어낸다. 목업은 약속이고, 실제로 출시되는 것은 그 느낌 이다.
하나의 구분은 Design Engineer 다. 이들은 하이브리드 역할을 맡는다. 즉, 디자인도 하고 구현도 한다. Matthias Ott는 디자인 엔지니어링을 디자인-구현 간극에 대한 구조적 해결책으로 설득력 있게 설명해 왔다. 두 분야를 동시에 붙들어 간극 자체가 처음부터 생기지 않게 하는 역할이다. Linear와 Vercel 같은 회사들이 이 역할을 유명하게 만들었고, 나는 그 일을 하는 사람들에게 경외심을 느낀다. 그들은 양쪽 모두에 진정한 재능을 가진 사람들이다.
하지만 그것은 동시에 사치스러운 해결책이기도 하다. 대부분의 회사는 그런 채용을 할 수 없고, 설령 그런 역할을 두는 회사라 하더라도 많은 디자인 엔지니어는 보통 디자인 시스템이나 고충실도 컴포넌트에 집중한다. 결국 누군가는 그 컴포넌트를 가져와 실제 제품을 세심하게 만들어야 한다.
Ott의 처방이 역할이라면, 나의 처방은 역량이다. 이것을 민주화된 버전이라고 생각해도 좋다. 우리 모두를 위한 디자인 엔지니어 같은 것이다. 그 역할은 그런 채용이 가능하고 그 정도의 추가 충실도가 필요한 회사에서 가치가 있지만, 이 역량은 사용자 대면 소프트웨어를 만드는 훨씬 더 많은 사람에게 확장될 수 있다.
그 누군가가 바로 디자인 감각을 갖춘 엔지니어 다. 이것은 새로운 직함이 아니다. 제품이 어떻게 보이고 어떻게 느껴지는지에 관심을 갖는 일의 방식이자, 엔지니어링의 방식이다.
디자인 감각을 갖춘 엔지니어는 디자이너가 아니며, 그들의 과제는 디자인 결정을 창안하는 것이 아니라 그것을 적용하고 확장하는 것이다. 목표는 디자이너가 출시된 제품을 보고, 자신의 디자인 파일이 어디서 끝나고 엔지니어의 판단이 어디서 시작되었는지 구분할 수 없게 만드는 것이다. 디자인 감각을 갖춘 엔지니어가 받을 수 있는 최고의 칭찬은 디자이너의 침묵이다. 침묵은 당신이 제대로 해냈다는 뜻이기 때문이다.
이것은 엔지니어가 디자이너가 되라는 이야기도 아니다. 디자이너는 여전히 디자인해야 하고, 엔지니어는 여전히 구현해야 한다. 하지만 디자인 판단을 가지고 구현하는 엔지니어는, 그렇지 않은 엔지니어와는 다른 제품을 출시한다.
창안하지 말고 적용하고 확장하라. 그것이 디자인 감각을 갖춘 엔지니어링이다.
AKQA에서 Nike와 Ferrari를 위한 에이전시 작업을 하던 시절부터, Volvo의 글로벌 이커머스, 그리고 Canva에서의 접근성과 애니메이션 작업에 이르기까지, 나는 엔지니어가 디자인과 어떻게 관계 맺어야 하는지에 대한 하나의 프레임워크를 발전시켜 왔다. 그것은 세 가지 렌즈로 요약된다.
1. 사용자 행동.
사람들은 실제로 이것으로 무엇을 할까? 목업이 가정하는 것이 아니라, 실제 조건에서 무슨 일이 일어날까? 디자이너는 보통 하나의 이상적인 상태에 있는 한 명의 사용자를 위해 디자인하지만, 엔지니어는 현지화된 문자열이 원래 목업이 고려하지 못한 방식으로 레이아웃을 바꾼다는 것을 알고 있다. 오른쪽에서 왼쪽으로 읽는 언어는 모든 것을 뒤집고, 사용자는 체크아웃 흐름 도중 신호가 한 칸밖에 없는 기차 안에서 이 화면에 도달할 것이다. 디자인 감각을 갖춘 엔지니어는 그런 현실을 보고, 그것이 버그가 되기 전에 해결한다.
2. 성능.
목업이 보여줄 수 없는, 사용자가 치르게 되는 숨은 비용은 무엇인가? 프로토타입은 매우 부드러운 인터랙션을 약속할 수 있지만, 실제 출시된 제품의 입력 지연이 16ms가 아니라 80ms라면, 사용자는 그 차이를 말로 설명하지 못하더라도 몸으로 느낀다. Samsung은 Apple의 핀치 투 줌 제스처를 시각 디자인 면에서 거의 똑같이 복제한 것으로 유명하지만, 그 아래의 엔지니어링이 디자인의 약속과 맞지 않았기 때문에 인터랙션의 느낌 은 잘못되어 있었다. 성능은 디자인 결정이며, 그것을 현실로 만드는 사람은 오직 엔지니어뿐이다.
3. 접근성.
누가 배제되는가? 이것은 어떤 디자인 리뷰에서도 제기할 수 있는 가장 방어 가능한 우려이며, 동시에 가장 자주 미뤄지는 것이기도 하다. 접근성은 컴플라이언스 체크박스가 아니라 엔지니어링 품질의 신호이며, 그보다 더 나아가 배려의 신호다. WCAG 점수를 통과했더라도 실제 스크린 리더 경험이 이해 불가능하다면 그것은 의미가 없다. VoiceOver를 켜고, 다양한 입력 방식으로 자기 제품을 직접 탐색해 보는 것이 중요하다.
이 세 가지 렌즈는 일을 막거나 디자이너에게 반대하기 위한 이유가 아니다. 오히려 그 반대다. 이것은 디자이너가 인정하고 존중하는 관점으로 디자인 결과에 관심을 기울임으로써, 엔지니어가 디자인 테이블에 앉을 자리를 얻는 방법이다.
하지만 디자인 감각을 갖춘 엔지니어링은 분석적인 것만은 아니다. 창의적 기여에 관한 또 다른 차원이 있다.
엔지니어는 디자이너가 모르는 것을 안다. 두 분야가 서로 다른 시점을 갖기 때문이다. CSS container queries가 도입되었을 때, 혹은 view transitions가 명세에서 안정화 단계로 넘어갔을 때, 혹은 SwiftUI의 애니메이션 API가 iOS에서 새로운 모션 가능성을 열어주었을 때, 그것들은 단지 엔지니어링의 이정표가 아니었다. 그것들은 창의적 가능성을 여는 계기였다. 각각은 사용자 인터페이스에서 가능한 것의 범위를 넓혔고, 엔지니어는 그 새로운 지형을 가장 먼저 보았다.
AKQA에서 나는 CSS에 사용자 지정 easing 곡선을 위한 cubic-bezier() 함수가 추가된 직후 Ferrari 프로젝트를 맡았다. 우리는 실제 레이스카 텔레메트리 데이터에서 파생한 easing 곡선을 적용한 드롭다운 메뉴를 만들었다. 그런 기여는 엔지니어가 크리에이티브 대화의 현장에 함께 있으면서, 그 대화의 하류에서 핸드오프를 기다리는 것이 아니라 그 안에 직접 입력할 때에만 가능하다.
디자이너는 자신이 가능하다고 생각하는 것 에 의해 제약되고, 디자인 감각을 갖춘 엔지니어는 실제로 가능한 것 을 안다. 새로운 플랫폼 기능을 꾸준히 따라가라. 그러면 모든 브레인스토밍에 가져갈 선택지가 생기고, 팀은 당신 없이는 설계할 수 없었던 무언가를 디자인하게 된다.
이 프레임워크에서 실제로 일하는 엔지니어들에게 가장 즉각적으로 와닿는 단 하나의 아이디어를 꼽는다면, 그것은 간극 상태 일 것이다.
모든 목업은 행복한 경로를 보여준다. 페이지는 로드되었고, 데이터는 도착했으며, 사용자는 로그인했고, 콘텐츠는 완벽하게 들어맞는다. 하지만 출시되는 제품은 로딩 상태, 에러 상태, 빈 상태, 스켈레톤 화면, 오프라인 대체 흐름, 낙관적 업데이트, 만료된 세션, 권한 거부, 로캘별 예외 상황, 그리고 어떤 디자인 파일에도 등장하지 않았던 수많은 다른 조건을 고려해야 한다.
이것들은 나중에 덧붙이는 생각이 아니다. 실제 사용자 세션의 상당한 비율에서 이것들 자체가 곧 제품 이다. 디자인 리뷰를 끝내기 전에 “데이터가 하나도 없을 때 이 화면은 어떻게 보이지?”라고 묻고, 그것들을 일급 디자인 문제로 다루는 엔지니어가 바로 디자인 감각을 갖춘 엔지니어링을 하고 있는 것이다. 이런 중간 순간들에 얼마나 공을 들이느냐가, 매끄럽게 다듬어진 제품과 단지 목업만 보고 만든 듯한 제품을 가르는 차이다.
지금까지 내가 설명한 모든 것은 디자인이 존재한다는 전제 위에 서 있다. 하지만 그것이 없다면 어떻게 될까?
바로 여기서 디자인 감각을 갖춘 엔지니어링은 진짜 시험대에 오른다. 모든 엔지니어는 언젠가 불완전하거나 아예 없는 디자인 방향 속에서 무언가를 구현해야 하는 상황을 만나게 된다. 디자이너가 손댈 시간이 나기 전에 출시해야 하는 기능, 원시 데이터와 비즈니스 요구사항만으로 만든 프로토타입, 혹은 팀에 디자이너가 없는 긴 공백기 같은 상황이다.
나는 그 양극단을 모두 경험해 보았다. 전혀 디자인 입력 없이 원시 데이터만 받아 의도가 느껴지는 무언가를 만들어 달라는 요청을 받은 적도 있다. 그리고 Volvo에서는 디자인 시스템이 존재하기 전, 디자이너 없이 6개월을 보내며 70개 시장에 걸쳐 데이터와 과거 디자인 작업의 파편만을 바탕으로 구현한 적도 있다.
초기의 몇 주가 가장 어려웠다. 참고할 디자인이 있다는 사실에서 얼마나 많은 자신감을 얻고 있었는지는, 그것이 사라지고 나서야 깨닫게 된다. 평소라면 몇 초 만에 끝날 모든 결정이 갑자기 무게를 띤다. 이 텍스트 크기는 어느 정도여야 할까? 여기의 패딩은 어느 정도가 적당할까? 이 위계는 분명한가, 아니면 내가 그냥 익숙해서 그렇게 보이는 것뿐인가? 대조할 목업도 없고, 물어볼 디자이너도 없다. 오직 나와 데이터, 그리고 수년간 축적해 온 디자인 판단만이 남는다.
내가 의지한 것은 그 세 가지 렌즈였다. 먼저 사용자 행동. 실제 시장의 실제 사람들은 이것으로 무엇을 할까? 나는 독일어 문자열이 영어보다 40% 더 길어질 것이라는 점을 알고 있었고, 일부 시장은 오른쪽에서 왼쪽으로 읽는다는 점도 알고 있었다. 데스크톱 브라우저에서 영어 사용자용으로 설계된 체크아웃 흐름은, 사우디아라비아의 사용자가 휴대폰에서 아랍어로 탐색할 때 완전히 다른 마찰 지점을 만나게 된다는 것도 알고 있었다. 나는 수년 동안 그런 예외 사례를 분류해 왔기 때문에 그것들을 알고 있었다. 두 번째는 성능. 우리가 실제로 상대해야 하는 사용자 기기에서 각 결정의 비용은 무엇인가? 내가 개발에 쓰고 있던 고사양 MacBook Pro가 아니라, 자카르타의 중급형 Android나, 노르웨이 시골의 불안정한 연결 환경을 생각해야 했다. 세 번째는 접근성. 내가 이것을 잘못 만들면 누가 배제되는가?
그 렌즈들이 디자이너를 대체해 주지는 않았지만, 원칙 있는 결정을 내릴 수 있는 구조는 제공해 주었다. 좋아 보이는 것을 추측하는 대신, 측정하거나 방어할 수 있는 결과를 목표로 문제를 풀 수 있었다. 시각적 선택 가운데 내가 논리적으로 설명할 수 없는 것들은 보수적으로 유지했다. 새로운 것을 발명하기보다 시스템 안의 기존 패턴에 맞추고, 디자이너가 이미 स्थापित해 놓은 것에서 확장했다.
절제를 발휘하는 것이 역설적인 부분이다. 디자이너가 없을 때의 유혹은, 창의적 공백을 채우고, 대담한 결정을 내리고, 두 역할을 다 해낼 수 있음을 증명하는 것이다. 하지만 그것이야말로 정확히 잘못된 본능이다. 그런 상황에서 디자인 감각을 갖춘 엔지니어의 일은 제품이 디자이너의 기존 의도와 연속성 을 느끼게 만드는 것이지, 새로운 목소리를 들여오는 것이 아니다. 확신이 서지 않는 결정을 내리려 할 때마다, 나는 스스로에게 물었다. 디자이너가 여기 있었다면 이것에 놀랐을까? 대답이 예라면, 나는 한 걸음 물러서서 더 보수적인 길을 택했다. 안전망 없이 일할 때는 틀리느니 지루한 편이 낫다.
디자이너가 결국 돌아와 내가 만든 것을 검토했을 때, 그가 요청한 것은 사소한 수정뿐이었다. “무슨 생각이었어요?”가 아니었다. 단지 디자이너의 본능과 엔지니어의 원칙적 접근을 가르는 미시적 수준의 조정들뿐이었다.
그 결과는 이 프레임워크 전체에 대한 개념 증명이다. 동시에 이것은 디자이너의 본능을 복제하기 가장 어려운 지점이 어디인지를 솔직하게 보여준다. 간격, 무게감, 비율에 관한 미시적 결정들, 즉 그런 본능을 가진 누군가가 지적해 준 뒤에야 자명해 보이는 것들이다. 디자인 감각을 갖춘 엔지니어링은 놀라울 정도로 가까이 갈 수 있게 해 주지만, 그 “가까움”이 부족한 지점을 알아차리는 것 역시 이 기술의 일부다.
디자인에 대한 유창함의 일부는, 어디서 잘못되었는지를 알아보는 법을 배우는 것이다. 업계에는 경계 사례가 넘쳐난다. Snapchat의 2018년 리디자인, 햄버거 메뉴의 유행, 전환율을 최적화하면서 신뢰를 파괴하는 다크 패턴, 그리고 최근에는 그럴듯해 보이지만 일관성 없이 작동하는 AI 생성 UI의 증가까지.
햄버거 메뉴는 특히 교육적인 예다. 당시에는 너무도 우아한 엔지니어링 해결책처럼 느껴졌기 때문이다. 모바일에서는 화면 공간이 제한적이고, 내비게이션은 자리를 차지하니 아이콘 뒤로 접어 넣는다. 문제 해결. 하지만 데이터는 계속 같은 이야기를 들려주었다. 사용자는 보이지 않는 메뉴를 열지 않는다. 햄버거 메뉴 뒤에 숨겨진 기능은, 인터페이스에 드러난 기능보다 참여도가 극적으로 낮았다. 공간 절약 논리는 논리에서는 이겼지만 인간 행동에서는 졌다. 그리고 그 방 안에서 디자인 감각을 갖춘 엔지니어의 기여는 내비게이션에 대해 더 나은 의견을 갖는 것이 아니라, 무언가를 숨기자는 주장에는 사용자가 그것을 다시 찾을 수 있는지에 대한 고려가 포함되어야 한다는 점을 알아차리는 것이었다.
AI는 UI 코드를 생성하는 일을 그 어느 때보다 쉽게 만들고 있으며, 몇 분 만에 프롬프트만으로 동작하는 인터페이스를 얻을 수 있다. 바로 그렇기 때문에 오늘날에는 디자인 판단이 그 어느 때보다 더 중요하다.
AI는 디자인 감각을 갖춘 엔지니어에게 강력한 도구다. 로캘별 변형을 생성하고, 간극 상태를 시뮬레이션하고, 브레인스토밍 중 동작하는 프로토타입을 만들고, 디자인 리뷰 전에 접근성 문제를 찾아낼 수 있다. 하지만 그 결과의 느낌 이 맞는지 평가할 수는 없다. 애니메이션이 인터랙션에 도움이 되는지, 아니면 단지 장식일 뿐인지를 결정할 수는 없다. 빠른 연결에서는 200ms 동안만 보이는 컴포넌트의 로딩 상태가, 포르투갈 시골의 기차 안에서는 4초 동안 멈춘 듯 보일 것이라는 사실을 말해 주지도 못한다.
내가 새롭게 떠오르는 위험으로 보는 것은 “AI가 디자이너를 대체할 것이다”보다 더 미묘하다. 그것은 엔지니어가 AI를 디자인 판단의 대체물로 다루기 시작할 수 있다는 점이다. 로딩 상태가 필요한가? 모델에게 하나 생성하라고 하라. 에러 메시지가 필요한가? 문구를 쓰게 하라. 모바일에서 컴포넌트가 어떻게 동작해야 하는지 결정해야 하는가? 선택지를 프롬프트로 받아 그럴듯해 보이는 것을 고르라. 각각의 결정은 개별적으로는 괜찮을 수 있다. 하지만 누적 효과는 관점도, 일관성도, 실제 사용하는 사람이 무엇을 필요로 하는지 누군가가 신중히 생각했다는 감각도 없는 인터페이스가 된다. 그것은 의도에 의한 디자인이 아니라, 기본값에 의한 디자인이다.
디자인 감각을 갖춘 엔지니어는 그런 표류에 대한 균형추다. 그들은 AI가 생성한 결과물을 보고 세 가지 렌즈를 적용하는 사람이다. 이것이 실제 사용자 행동에 도움이 되는가? 성능 비용은 무엇인가? 누가 뒤처지는가? 그런 질문에는 더 나은 프롬프트가 아니라 인간의 판단이 필요하다. 실행은 가속될 수 있어도, 판단은 그렇지 않다.
나는 업계에서 가장 디자인 요구 수준이 높은 엔지니어링 환경들 속에서 25년에 걸쳐 이 프레임워크를 발전시켜 왔다. 그 과정에서 배운 것은, 디자인 유창성이 타고나는 재능이 아니라는 점이다. 그것은 가르칠 수 있고, 연습할 수 있고, 발전시킬 수 있는 기술이며, 그 성장은 그 순간에는 알아보기 어렵지만 돌아보면 분명하다.
첫해에 간격에 주의를 기울이기 시작한 엔지니어는 3년 차에 타이포그래피 위계를 알아차리기 시작한다. 5년 차가 되면 디자이너보다 먼저 디자인 의도와 맞지 않는 인터랙션 패턴을 포착한다. 10년 차가 되면 어려운 결정을 내려야 할 때 디자이너가 함께 있기를 원하는 엔지니어가 된다. 15년 차가 되면 코드 리뷰에서 망가진 로딩 상태를 잡아내고, 왜 그것이 중요한지 정확히 설명할 수 있는 Staff 엔지니어가 된다. 단지 보기 이상하다고 말하는 것이 아니라, 그것이 사용자의 제품 신뢰에 어떤 영향을 주는지까지 설명할 수 있게 된다.
그 어떤 것도 하룻밤 사이에 일어나지 않는다. 하지만 그것은 하나의 결정에서 시작된다. 단지 작동하느냐를 넘어서, 자신이 만들고 있는 것에 관심을 기울이기로 결정하는 것이다.
지금 내가 코드 리뷰에서 포착하는 어긋남들, 출시되기 전에 보는 예외 사례들, 다른 누구보다 먼저 잘못되었다고 느낄 수 있는 인터랙션들 가운데, 2002년의 나는 단 하나도 알아차리지 못했을 것이다. Photoshop 오버레이를 보여준 AKQA의 그 디자이너가 내게 보는 법을 가르쳐 주었다. 그 기술은 타고난 재능이 아니라, 어떤 엔지니어든 연습을 통해 스스로 보게 될 수 있는 것이다. 그리고 디자인 감각을 갖춘 엔지니어가 되는 사람들은, 디자이너가 더 이상 쫓아다닐 필요가 없는 사람들이 된다.
