🎨 디자이너와 개발자, 굳이 나눠야 할까요?

"왜 이렇게 만든 거지?" 이 말, 기획자라면 누구나 해봤을 겁니다

기획서도 완성됐고, 디자인도 깔끔하게 넘겼는데. 막상 개발 완료된 화면을 보면 뭔가 어색합니다. 버튼 위치가 살짝 달라져 있고, 여백은 어딘가 뭉쳐 있고, 전체 느낌이 원래 의도와 다릅니다.

누구 하나 잘못한 것도 아닌데, 결과물은 이상합니다. 이 경험이 반복된다면, 문제는 사람이 아니라 구조에 있는 겁니다.

최근 웹 디자인 엔지니어 Matthias Ott가 쓴 아티클이 국내 제품팀 사이에서 조용히 화제가 됐습니다. 디자이너와 개발자가 왜 같은 화면을 보면서 전혀 다른 것을 보는지, 그 근원을 무려 1898년까지 거슬러 올라가 설명하거든요. 오늘은 이 이야기를 풀어보겠습니다.

100년 전 공장 논리가 우리 팀 안에 살아 있습니다

1898년, 기계 공학자 프레더릭 윈슬로 테일러는 스톱워치를 들고 베들레헴 철강 공장에 나타났습니다. 그의 결론은 단순했습니다. "생각하는 사람"과 "실행하는 사람"을 분리하면 효율이 올라간다는 것이었죠.

관리자는 설계하고, 노동자는 실행한다. 이른바 '과학적 관리법'입니다.

문제는 이 100년도 넘은 공장 논리가 그대로 디지털 제품 팀에 흘러들어왔다는 겁니다. 기획이 설계하면 디자인이 시각화하고, 개발이 구현한다. 기획, 디자인, 개발의 순차적 흐름이 공장 컨베이어 벨트처럼 돌아갑니다.

쇳덩이를 찍어내는 공장과 복잡한 디지털 제품을 만드는 팀이 다르다는 건 누구나 압니다. 그런데 여전히 많은 팀이 이 19세기 모델로 2025년의 제품을 만들고 있습니다.

디자이너와 개발자는 같은 화면에서 다른 것을 봅니다

디자이너가 화면을 볼 때 보는 것은 구성, 위계, 의도입니다. 이 사용자가 이 순간에 무엇을 느끼고 이해해야 하는지를 생각합니다. 전체 경험을 하나의 내러티브로 머릿속에 담습니다.

개발자가 같은 화면을 볼 때는 완전히 다릅니다. 구조, 상태, 로직, 제약을 봅니다. 데이터가 안 오면 어떻게 되는지, 사용자가 예상 밖의 행동을 하면 어떻게 처리되는지를 생각합니다. 이 컴포넌트가 12가지 다른 컨텍스트에서도 작동해야 한다는 걸 이미 알고 있습니다.

둘 다 틀린 게 아닙니다. 둘 다 필요합니다. 그런데 이 두 관점은 서로 다른 어휘, 다른 직관, 다른 질문을 만들어냅니다.

"좀 더 가볍게 만들어줘"라는 디자이너의 요청을 들었을 때, 개발자는 속으로 묻습니다. '완료 기준이 뭐지? 가볍다는 게 어떤 상태야?' 디자이너는 정확한 의도가 있지만, 개발자에게는 수용 기준 없는 지시처럼 들립니다. 소통 능력의 문제가 아닙니다. 서로 다른 모국어를 쓰는 두 사람이 같은 언어로 말한다고 착각하는 상황입니다.

피그마 2025 스테이트 오브 더 디자이너 보고서에 따르면, 디자이너 중 84%가 적어도 매주 개발자와 협업한다고 답했습니다. 협업 빈도는 높은데 충돌은 줄지 않는다는 게, 이게 단순한 소통 문제가 아니라는 증거입니다.

충돌이 나쁜 게 아니라, 충돌이 없는 게 더 나쁩니다

여기서 흥미로운 역전이 일어납니다. 디자이너와 개발자의 관점 차이 자체는 문제가 아닙니다. 오히려 제대로 활용하면 팀에서 가장 가치 있는 자산이 됩니다.

두 사람은 서로 다른 사각지대를 가지고 있기 때문입니다. 경험과 내러티브에 최적화된 디자이너는 구조적 취약성을 놓치기 쉽습니다. 견고함에 최적화된 개발자는 실제 사용자가 느끼는 경험의 질을 놓치기 쉽습니다.

"좀 더 가볍게"라는 요청에 개발자가 "그건 레이아웃 세 군데가 깨져서 못 해요. 대신 트랜지션 타이밍을 바꾸면 어떨까요?"라고 답한다면, 그 순간 더 나은 해결책이 탄생합니다. 제약이 디자인을 막은 게 아니라, 더 흥미로운 방향으로 전환시킨 겁니다.

제약은 창의성의 적이 아닙니다. 제약이 좋은 결과물의 형태를 만들어줍니다. 이 마찰은 양쪽 모두에게 명확성을 강제하는 함수가 됩니다.

순차적 프로세스가 정말 망치는 것

그런데 대부분의 팀에서는 이 생산적인 마찰이 작동하지 않습니다. 테일러 방식의 순차적 프로세스가 이걸 망칩니다.

디자인 결정이 기술 제약과 충돌할 때 즉각적인 피드백이 없습니다. 개발자의 질문이 디자이너의 생각을 실시간으로 바꿔줄 순간이 없습니다. 남는 건 번역뿐입니다. 그리고 번역은 항상 무언가를 잃어버립니다.

결국 디자인과 개발 사이 공간에 있는 수많은 의사결정들이 마침 그 자리에 있던 사람에게 맡겨집니다. 사양서가 충분히 정확하지 않아서 개발자가 여백을 결정하고, 디자이너는 시스템의 핵심 컴포넌트가 될 것을 모르고 목업에서 그 동작을 바꿉니다. 이런 작은 결정들이 쌓입니다.

결과물은 기술적으로 작동하지만, 마치 맞게 설계되지 않은 부품들로 조립된 것처럼 느껴집니다. 실제로 그렇게 만들어졌으니까요.

실제 재료 안에서 함께 작업하는 것의 힘

구조적 간극을 줄이는 가장 효과적인 방법은 직접적입니다. 디자인 결정을 실제 재료와 가능한 한 일찍 접촉하게 하는 것입니다.

피그마 같은 도구에서 이뤄지는 디자인 결정은 상태, 시간, 뷰포트, 실제 콘텐츠의 예측 불가능성을 전혀 모릅니다. 웹의 픽션을 디자인하는 거죠. 그리고 그 픽션을 개발자에게 넘기면, 원본 픽션 안에 숨어 있던 모든 타협과 가정들을 개발자가 흡수합니다.

브라우저에서 프로토타이핑하면 이게 달라집니다. 브라우저는 제품이 최종적으로 도달하는 곳이면서, 동시에 아이디어를 탐색하고 테스트하는 장소가 됩니다. 실제 재료인 웹 플랫폼의 유연성과 예측 불가능성을 직접 다루게 되니까요.

토스, 카카오, 당근 같은 제품 중심 기업들이 디자인 시스템을 도입하고 코드 기반 컴포넌트를 디자인 툴과 연동하려는 시도를 계속하는 이유가 여기 있습니다. 번역을 줄이고, 실제 재료와 결정을 가까이 붙이기 위해서입니다.

바우하우스가 테일러보다 옳았던 이유

1919년, 테일러가 공장에 등장한 지 21년 후, 건축가 발터 그로피우스는 독일 바이마르에 테일러리즘의 모든 것을 의도적으로 거부하는 학교를 세웠습니다. 바우하우스입니다.

바우하우스는 디자인하는 사람과 만드는 방법을 아는 사람을 분리하지 않았습니다. 예술가와 장인이 함께 배우고, 함께 생각하고, 함께 만들었습니다. 각자가 비전과 재료 둘 다를 이해하도록 기대됐습니다.

그로피우스는 테일러가 이해하지 못한 것을 알고 있었습니다. 최고의 작업은 생각과 실행이 분리될 때가 아니라, 분리될 수 없을 때 나온다는 것을요.

100년이 지난 지금, 이 철학이 다시 제품 팀에서 소환되고 있습니다.

디자인 엔지니어란 무엇인가요?

그렇다면 웹 디자인 엔지니어란 무엇일까요? 코딩하는 디자이너도, 감각 있는 개발자도 아닙니다. 동시에 두 렌즈를 모두 들고, 같은 순간에 구성적으로도 구조적으로도 생각할 수 있는 사람입니다.

레이아웃을 디자인하면서 이미 CSS가 뷰포트가 좁아질 때 어떻게 동작할지를 생각합니다. CSS를 작성하면서 브라우저가 실제로 보여주는 것을 바탕으로 실시간으로 여백과 비율과 타이밍을 조정합니다. 이 두 활동은 번갈아 하는 게 아닙니다. 동시에 두 각도에서 보는 같은 활동입니다.

국내에서도 이런 역할의 필요성은 빠르게 커지고 있습니다. 프론트엔드 개발자 채용 공고에 "디자인 감각 우대" 조건이 붙고, 디자이너 채용 공고에 "HTML/CSS 가능자 우대" 조건이 붙는 이유가 우연이 아닙니다. 팀들이 이 간극을 채울 사람을 본능적으로 찾고 있는 겁니다.

AI 시대에 이 역량이 더 중요해지는 이유

AI가 점점 더 실행을 담당하게 됩니다. 보일러플레이트 코드를 작성하고, 컴포넌트 스캐폴딩을 생성하고, 반복적인 작업을 대신하는 건 이미 AI의 영역이 되고 있습니다.

그렇다면 AI가 대체할 수 없는 것은 무엇일까요? 구성적으로도 구조적으로도 동시에 민감하게 볼 수 있는 능력. 어떤 사양서도 인코딩할 수 없고, 어떤 AI 툴도 자동화할 수 없는 영역 간의 안목입니다.

피그마 보고서에 따르면 응답자의 56%가 AI가 디자인과 개발의 미래를 더 긍정적으로 바라보게 만든다고 답했습니다. AI가 단순 실행을 빠르게 처리해줄수록, 그 위에 올라타는 학제 간 판단력이 더 큰 가치를 가집니다. 학제 간 사고방식은 더 이상 있으면 좋고 없어도 그만인 게 아닙니다. AI가 복제할 수 없는 역량이기 때문에, 바로 그것이 팀의 진짜 경쟁력이 됩니다.

마무리

디자이너와 개발자의 간극은 소통 문제가 아니라 구조 문제입니다. 순차적 프로세스가 생산적 마찰을 없애버리고, 번역 과정에서 의도가 사라집니다.

해결의 방향은 하나입니다. 실제 재료인 브라우저에서 함께 일찍 부딪히게 하고, 두 렌즈를 동시에 가진 사람을 키우거나 채용하는 것. 토스, 카카오, 당근이 디자인 시스템과 코드 연동에 투자하는 이유가 여기에 있습니다.

AI 시대일수록, 기계가 흉내낼 수 없는 이 학제 간 안목이 팀의 진짜 경쟁력입니다. 여러분 팀에서 디자인 의도와 실제 구현 사이의 공간을 누가 소유하고 있나요? 그 공간에 이름이 있는 팀이 더 나은 제품을 만듭니다.