UX 디자이너에게 ‘협업’이 가장 중요한 이유

실력보단 태도의 문제

UX 디자이너로 일하다 보면 한 번쯤은 낯설고 답답한 상황을 마주한다. 디자인에는 하자가 없다. 기획서의 요구사항도 충실히 반영했고, 버튼 크기며 여백, 컬러 토큰까지 빠짐없이 지켰다. 피그마 안에서는 모든 게 완벽하다. 누구보다 열심히, 그리고 정성껏 작업했다. 그런데 이상하게도 일정은 밀리고, 개발 단계에서 계속 막힌다는 이야기가 들려온다. 최종 결과물은 내가 의도한 화면과 어딘가 미묘하게 다르고, 사용성 테스트에서도 기대한 반응이 나오지 않는다.

이럴 땐 자연스레 이런 생각이 든다. “이건 내 잘못은 아니야.” 디자인은 명확하게 정리돼 있었고, 넘길 문서도 충분히 제공했다. 그 이후의 일은 개발 파트에서 꼬인 건 아닐까? 혹은 기획서가 너무 자주 바뀐 탓은 아닐까? 하지만 시간이 지나고 나면 결국 이런 의문으로 돌아온다. 내가 뭔가 놓친 건 아닐까? 겉으로 보이는 성실함과 퀄리티만으로는 설명되지 않는 어긋남. 그 간극 속에는 무엇이 있었을까?

답은 단순하다. 협업이 없었다.

정확히 말하면, 문서나 말로 전달은 했지만, ‘맥락’은 공유하지 못했다. 디자이너가 작업한 화면 하나하나가 어떤 배경과 의도를 가졌는지, 어떤 상황에서 쓰이고 어떤 흐름으로 연결되는지에 대한 공감과 교감이 부족했다. 피그마 안의 완벽은 팀 밖으로 나갔을 때 쉽게 무너진다. 혼자만 알고 있는 디자인은, 결국 팀이 함께 구현하지 못한다.

혼자 할 수 있는 디자인은 없다

디자인은 본질적으로 팀 스포츠다. 디자이너가 아무리 뛰어난 감각으로 결과물을 시각화하더라도, 그것이 실제 제품으로 구현되기 위해서는 기획자, 개발자, 마케터, 운영 등 수많은 사람들의 손을 거쳐야 한다. 처음 디자이너로 일하기 시작했을 땐 이런 현실을 잘 모를 수밖에 없다. ‘예쁘고 논리적인 UI를 만들면 내 일은 끝’이라고 생각하기 쉽다. 요구사항을 충실히 반영한 시안을 피그마에 정리해 넘기고 나면 끝이라고 생각하는 것이다.

하지만 디자인은 결코 혼자 만드는 결과물이 아니다. 좋은 디자인은 협업이 잘 되는 구조 안에서 태어난다. 함께 일하는 사람들과의 이해와 신뢰, 그리고 공유된 맥락이 쌓일 때 비로소 완성도 있는 결과물이 나온다.

협업을 잘하는 디자이너는 단순히 예쁜 화면을 그리는 사람이 아니다. 그 디자인이 왜 필요했고, 어떤 맥락에서 만들어졌는지, 어떤 목적을 위해 작동해야 하는지를 명확히 설명할 수 있어야 한다. ‘왜 이렇게 설계했는가?’라는 질문에 답할 수 있어야 하고, 개발자나 기획자가 막힐 만한 지점을  예측하고, 설계에 반영할 줄 알아야 한다.

예를 들어, 화면의 전체 너비를 차지하는 CTA 버튼을 화면 하단에 고정하도록 디자인했다고 해보자. 사용자가 스크롤 없이 바로 누를 수 있도록 하단에 고정해 두는 건, 분명 사용자 입장에서 편리한 UX일 수 있다. 하지만 이 버튼이 특정 조건에서만 노출되어야 한다면, 이야기가 달라진다. 

로그인 상태, 사용자 등급, 백엔드 API 호출 타이밍 등 다양한 요인에 따라 버튼 노출 여부가 달라진다면, 그 복잡성은 개발자에게 고스란히 전달된다. 이때 디자이너가 사전에 이런 조건을 인지하고 있었다면, 개발자와 함께 로직을 단순화할 수 있는 대안을 논의했을지도 모른다. 이 문제는 디자인이 미흡해서도, 개발 역량이 부족해서도 아니다. 단지 그 버튼이 어떤 맥락에서 필요한지 공유되지 않았기 때문이다. 기능적 요구만 전달되는 것과, 디자인의 배경과 목적이 함께 설명되는 것 사이에는 엄청난 차이가 있다. 전자는 전달이고, 후자는 협업이다.

협업이 어려운 이유

협업이 어렵게 느껴지는 이유는 대부분 기술 부족 때문이 아니다. 실력은 충분한데도 일이 자꾸 꼬인다? 그건 맥락이 단절돼 있기 때문이다. 디자이너는 ‘이건 이렇게 보여야 해요’라고 말하고, 개발자는 ‘그거 구현하려면 하루 더 걸려요’라고 답한다. 둘 다 틀린 말은 아니지만, 말이 오갔다고 해서 대화가 오간 건 아니다. 말은 분명 전달됐지만, 이해는 어긋나 있다.

서로 다른 언어를 쓰고, 서로 다른 기준으로 판단하다 보니 협업은 점점 더 삐걱댄다. 기획자는 사용자의 여정을 기준으로, 개발자는 시스템의 안정성과 성능을 기준으로, 디자이너는 인터랙션과 시각적 흐름을 기준으로 판단한다. 다 옳은 말을 하고 있지만, 공통된 해석 기준이 없으면 구성원 간의 충돌은 피할 수 없다.

그 결과 일정은 밀리고, 재작업은 늘어난다. 슬랙에선 회의를 위한 회의가 자꾸 생겨나고, 피그마엔 수없이 많은 기획 변경과 댓글이 계속 추가된다. 점점 처음 버전이 어떤 형태였는지도 기억나지 않고, 결국 이 작업이 뭐를 위해 하는 거였는지 목적을 잃어버리게 된다. 그러다 보면 디자이너로선 ‘그래, 이렇게 될 줄 알았어’라는 자조 섞인 반응이 나온다. 하지만 누구의 말이 옳았나보다 더 중요한 건 서로를 이해하고 있느냐에 달려있다. 

이럴 때 필요한 건 더 많은 설명이 아니다. 더 친절한 요약도 아니다. 중요한 건 서로가 무엇을 모르고 있는지를 짚어보는 것이다. ‘어? 이건 당연히 알 줄 알았는데?’라는 순간이 반복될수록, 팀워크는 금이 간다. 반대로 서로의 무지를 전제로 대화하면, 예상치 못한 마찰을 줄일 수 있다.

이런 역할을 누가 먼저 해줘야 할까? 이상적으로는 모두가 그러면 좋겠지만, 현실적으로는 디자이너가 먼저 시도하는 게 가장 빠르다. 왜냐하면 디자이너는 기획과 개발의 중간에 서 있기 때문이다. 사용자 흐름도 이해하고, 시각 언어도 다루고, 기술 제약도 어느 정도 인지하는 입장이다. 말하자면, 팀 내의 번역기 역할을 맡기에 가장 좋은 위치다. 기획자의 언어를 번역해 개발자의 언어로, 개발자의 언어를 번역해 기획자의 언어로, 그리고 그 모두를 디자인의 언어로 풀어내기 좋은, 중개자의 역할이 맡기에 적합하다.

실제로 협업이 잘 되는 팀은 아주 작은 기능 하나를 논의할 때도, 각자의 입장을 말로 꺼내 설명하려 한다. ‘이건 디자인에서 이렇게 만든 이유가 있어요.’, ‘이건 기술적으로 이렇게 구현해야 더 안정적이에요.’, ‘유저 플로우 상에서는 이런 조건이 있어야 해요.’ 이런 말들이 오갈 때, 제품은 덜 삐걱거린다. 사용자 경험은 더 단단해진다. 협업이란 결국 ‘내 일’을 끝내는 게 아니라, ‘우리 일’을 끝내는 방법을 함께 찾는 과정이다. 거기엔 정답이 없다. 다만, 함께 풀 수 있는 태도만 있을 뿐이다.

협업에 능숙한 디자이너가 되려면?

조직에서 오래 살아남는 디자이너는 종종 눈에 띄는 포트폴리오보다, 함께 일할 때 일이 덜 꼬이게 만드는 ‘협업의 기술’을 더 잘 갖춘 사람이다. 디자인 실력은 기본이고, 일을 어떻게 풀어나가는지에 따라 태도와 커뮤니케이션 방식이 실력만큼 중요한 경쟁력이 된다. 나 역시 업무 중 ‘디자인이 잘 나왔다’라는 칭찬보다 ‘일이 매끄럽게 흘러간다’라는 말을 들을 때 더 큰 만족감을 느끼곤 한다.

협업이 잘 되면 무엇보다 재작업이 줄어든다. 재작업이 줄면 일정이 흔들리지 않고, 일정이 안정되면 결국 팀은 디자이너를 신뢰하게 된다. 이 단순한 구조를 체감하는 순간, 협업은 단지 사람 좋게 보이기 위한 덕목이 아니라, 생존을 위한 전략으로 자리 잡는다. 말하자면 ‘살아남기 위해 친절해진’ 디자이너가 결국 살아 남는다. 친절함은 나도 이득을 보기 위한 고도의 사회적 지능인 것이다.

예를 들어, 내가 함께 일하는 기획자는 항상 빠듯한 일정 속에서 유저 플로우를 설계해야 했고, 나는 그보다 한발 앞서 플로우를 시각화해 보여주려 했다. 회의 전날, 간단한 사용자 흐름 다이어그램이라도 만들어 두면, 기획자와의 대화가 훨씬 빠르고 생산적으로 흘렀다. 이건 멋진 디자인을 하기 위한 스킬이 아니라, 기획자가 ‘아, 이 디자이너랑 일하면 훨씬 효율적으로 일정을 관리할 수 있다’라는 신뢰를 쌓기 위한 방식이었다.

또 다른 경우엔, 개발자와 함께 피그마 라이브러리 구조를 코드 기준에 맞춰 조정했던 일이 있다. 나는 컴포넌트 네이밍을 코드 변수와 유사하게 바꾸고, Variants 구조를 플랫폼별 인터페이스에 맞게 정리해 두었다. 개발자가 따로 다시 확인하지 않아도 바로 에디터 상에서 이름만으로 같은 UI를 호출해서 쓸 수 있었고, 매우 편리해 생산성이 눈에 띄게 올랐다는 감사 인사까지 받았다. ‘디자인 시스템’이라는 단어가 거창해 보여도, 결국은 ‘이 디자이너는 개발자가 일하는 방식까지 한 걸음 더 고려하는구나’라는 인상을 심어주는 일이다.

또 실무에서는 문서 정리가 큰 힘을 발휘하는 편이다. 리뷰 전에 디자인 설명 문서를 미리 작성해서 공유하거나, 슬랙에서 오간 피드백을 한데 모아 노션 등에 정리해 둔다. 필요할 때마다 업데이트해서 공유하면, 구성원 간에 정보 격차가 생기는 일이 줄고, 기억이 나지 않아 더듬거리는 일도 줄어든다. 어떤 이슈가 언제 나왔고, 어떤 기준으로 결정됐는지 히스토리를 남겨두는 일이다. 말하자면, ‘팀의 기억력’을 디자이너가 대신 챙기는 셈이다. 내 일은 아니지만, 하면 편해지는 일. 이게 바로 협업형 디자이너의 실용주의다.

이런 습관들은 특별한 기술이라기보다는, 결국 ‘일을 내 것처럼만 보지 않는 태도’에서 나온다. 내가 만든 디자인이 팀 전체 흐름에서 어떻게 해석되고, 실제로 구현되는지까지 상상해 보는 것. 개발자의 눈, 기획자의 우선순위, 운영자의 두통까지 가볍게라도 짚어보려는 시도에서 비롯된다. 나는 이걸 ‘디자이너의 참견’이라고 부르기도 한다. 물론 좋은 의미다.

실제로 실무에서는 어떻게 하고 있을까?

그렇다면 실무에서 협업을 잘하는 디자이너는 어떤 방식으로 일할까? 정답은 없지만, 어쩌면 누군가에겐 도움이 될지도 모르니 경험한 몇 가지 방식을 공유해 본다. 

먼저 의견 차이가 생겼을 땐, 공통 목표를 먼저 확인하고 다시 논의한다. 이건 정말 마법 같은 효과가 있다. 나는 어떤 화면의 탭 전환 방식에 대해 기획자와 이견이 있었는데, 서로 “이 방식이 더 좋아요”라는 주장을 반복하다가, 문득 “우리가 이 화면에서 가장 먼저 유도하고 싶은 행동이 뭐였죠?”라고 물었다. 그 순간, 논점이 개인 취향이 아니라 사용자 목표로 바뀌었고, 논의는 훨씬 부드러워졌다. 결국 서로 한발 물러서, 더 나은 UX에 도달할 수 있었다. 너와 나가 아니라, 우리와 문제로 관점을 재조정하는 것이다.

둘째, 일정이 빠듯할 때는 작업 단계를 잘게 나눠 과할 만큼 자주 먼저 공유한다. 이건 특히 스타트업 환경에서 효과가 컸다. 나는 자주 ‘미완성’인 컴포넌트를 공유한다. 피그마에서 완성된 화면을 보여주기보다, 버튼의 상태, 플로우의 골격, 예상 사용자 조건만 정리한 와이어 프레임이나 청사진을 먼저 공유하는 식이다. 

개발자는 그걸 보며 오류가 나거나, 현재 개발 구조와 맞지 않는 부분을 미리 체크한다. ‘이건 지금 API가 없어서 새로 하나 요청해야 할 것 같아요’ 같은 피드백을 미리 줄 수 있다. 마치 드래프트 원고를 편집자에게 먼저 보여주는 것과 같다. 정제되지 않았지만, 방향성은 확실한 초안인데 이게 협업에선 훨씬 유용하다.

셋째, 온라인 협업에서는 소통 채널을 명확히 구분한다. 슬랙에서 모든 대화가 뒤섞이면, 결국 아무도 찾지 못한다. 그래서 나는 슬랙 채널을 기능별로 나누고, 채널 설명란에 채널의 목적을 ‘업무 요청 전용 채널입니다’ 등으로 적어둔다. 심지어 이모지 하나까지도 정했다. 이렇게 하면 팀의 소통 피로도가 확 줄고, 일도 줄어든다.

이건 약간 ‘디자이너의 강박’처럼 보일 수도 있지만, 한 번 경험하면 모두가 고마워한다. 슬랙에선 이모지도 커스텀할 수 있으니 유용하게 사용할 수 있다. 또 업무 요청처럼 양식이 정해져 있다면 노션이나 슬랙 워크플로우를 활용하는 것도 하나의 방법이다. 일반 메시지에 요청 메시지 등이 섞여버리면 곤란하니, 애초에 채널 자체를 분리하는 것이다.

마지막으로, 질문하는 법에도 나름의 팁이 있다. 예전에는 “이거 왜 이렇게 하셨어요?”라고 물었다가 대화가 어색해진 경험이 있다. 지금은 항상 “혹시 이 방식으로 하신 이유가 있을까요?”로 바꿔 묻는다. 말의 구조는 같지만, 전달되는 인상은 천지 차이다. 분위기가 훨씬 부드러워지고, 상대도 더 기꺼이 설명하려고 한다. 사소한 차이지만, 협업에서는 이런 미묘한 배려가 오히려 팀의 리듬을 만든다.

이런 습관들은 거창한 스킬이 아니다. 그냥 협업을 잘하고 싶은 디자이너로서, 작은 마찰을 줄이기 위해 일하는 방식에 신경 쓰는 것뿐이다. 그게 쌓이면 팀은 더 빨라지고, 디자이너는 더 신뢰받는다. 마치 디자인처럼, 협업도 디테일이 전부다.

협업은 더 이상 선택이 아니다

이제 우리는 더 이상 칸막이 안에서 일하지 않는다. 출근 시간에 맞춰 옆자리 팀원에게 말을 걸고, 화이트보드 앞에서 손으로 UI를 그리던 시대는 지났다. 지금의 협업은 그보다 훨씬 더 유연하고, 동시에 훨씬 더 복잡하다. 원격과 비대면이 일상이 되고, 슬랙, 노션, 피그마, 애자일이 기본이 되었다. 모두가 같은 물리적인 공간에 없더라도 하나의 목표를 향해 나아가기 위해 실시간으로 움직이는 구조다. 그리고 이 구조 안에서는 혼자 예쁘게 잘하는 사람보다, 함께 빠르게 해내는 사람이 훨씬 더 중요하다.

특히 요즘처럼 비동기 커뮤니케이션이 기본값이 된 시대에는, 문서와 설명이 곧 협업의 언어다. 말 한마디보다 노션에 적힌 요약 한 줄이 더 오랫동안, 더 많은 사람에게 영향을 준다. 회의에서 누군가 “이렇게 하겠습니다”라고 말한 것보다, 회의록에 “이렇게 정리했습니다”라고 쓰인 문장이 더 중요해진다. UX 디자이너는 단순히 시각을 설계하는 사람이 아니다. 팀 안에서공통 언어를 만드는 설계자다.

내가 말한 ‘이 화면’이 개발자에게는 오류 메시지 위치를, 마케터에게는 CTA 문구를, 기획자에게는 전환 지표를 떠올리게 한다면, 그건 협업이 아니라 혼선이다. 모든 구성원이 같은 단어로 같은 맥락을 이해해야, 제대로 된 전달이 가능하다. 그리고 그런 정렬을 가능하게 만드는 사람이 UX 디자이너여야 한다. 디자인의 언어를 모두가 이해할 수 있게 번역하는 사람, 팀이 나아갈 방향을 시각적으로 먼저 제시하는 사람. 그게 협업 시대에서 디자이너의 역할이다.

UX 디자이너는 팀을 위한 ‘설계자’

협업을 잘하는 디자이너는 단지 사용자 경험만을 설계하지 않는다. 함께 일하는 사람들의 경험까지 함께 설계한다. 개발자가 바로 이해할 수 있는 구조, 기획자가 빠르게 판단할 수 있는 흐름, 마케터가 자유롭게 바꿀 수 있는 컴포넌트 등 이런 배려는 종종 눈에 보이지 않지만, 실력보다 더 강하게 팀에 영향을 준다. 그건 속도가 되고, 신뢰가 되고, 나중엔 디자이너에 대한 평판이 된다.

‘UX’는 결국 ‘경험’이다. 사용자만의 경험이 아니다. 이 제품을 만들기 위해 협력하는 모든 사람의 경험까지 포함한 총체적 경험이다. 그리고 그 경험의 질을 높이는 사람이 있다면, 팀 전체가 더 나은 결과를 낼 수밖에 없다. 협업을 잘하는 디자이너는 혼자 빛나는 사람이 아니라, 팀 전체를 빛나게 만드는 사람이다.

그리고 그런 디자이너는, 오래 기억된다. 포트폴리오나 시안보다 더 오랫동안 남는 건, “그 디자이너랑 일할 때 진짜 편하고 일이 잘 됐어”라는 말 한마디다. 다시 함께 일하고 싶은 사람, 함께 있으면 안심이 되는 사람. 그런 인상을 남긴 디자이너는, 다음 프로젝트에서도 가장 먼저 떠오르는 사람이다.

협업은 오늘의 일정을 지키기 위한 기술이면서, 내일의 기회를 만드는 태도다. 잘하는 디자이너가 되기 위해서가 아니라, 오래 함께하고 싶은 디자이너가 되기 위해 필요한 태도다. 그리고 그건 누구나 연습할 수 있다. 아주 작은 참견에서부터 말이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.