개발자와의 갈등, UXer는 어떻게 대응할까
'안 된다'는 말 앞에서 멈추지 않으려면
안녕하세요. 저는 스타트업에서 UXer로 일한 지 6개월 된 주니어입니다. 최근 들어 개발자와의 협업에서 자주 충돌을 겪고 있습니다. 예를 들어 사용성을 고려한 인터랙션을 제안해도 "그건 구현이 어렵다"는 이유로 거절당하곤 합니다. 개발 리소스나 기술적 제약을 고려해야 한다는 것도 이해는 되지만, 때로는 최소한의 UX 배려도 사라지는 것 같아 답답합니다. 매번 ‘안 된다’는 말 앞에서 주저하게 되는데, 이런 상황에서 UXer는 어떤 태도와 전략을 가져야 할까요?
➥ 어쩌면 주니어에서 시니어가 되는 통과의례가 바로 이러한 협업에서 오는 마찰을 어떻게 잘 대응하는지 배우는 것에 있다고도 볼 수 있다고 생각합니다. 그만큼 특별한 일이 아닌 일상인 것이죠. 중요한 건 ‘설계의 언어’를 ‘개발의 언어’로 번역해 내는 능력입니다.
개발자는 왜 ‘안 된다’고 말할까
UXer가 인터랙션이나 기능을 제안했을 때 가장 흔히 듣는 말은 "그건 구현이 어려워요"입니다. 이 말에는 여러 의미가 숨어 있습니다. 정말 기술적으로 불가능할 수도 있고, 일정과 리소스 상 우선순위에서 밀리는 경우일 수도 있습니다. 혹은 구체적인 구현 방식이 부족해 개발자 입장에서 ‘막연함’으로 느껴질 수도 있습니다.
이때 UXer가 먼저 해야 할 일은 단순히 '포기'하거나 '우기기'가 아니라, 제안한 아이디어를 구현 가능한 단위로 분해하고, 왜 그것이 필요한지를 논리적으로 설명하는 것입니다. 사용자의 행동 변화나 경험 가치와 연결된 설명이 있을 때, 개발자도 단순한 감정이 아닌 ‘이해’를 기반으로 협업하게 됩니다.
설득은 ‘공감’보다 ‘번역’이 우선입니다
개발자와의 협업은 종종 서로 다른 언어를 쓰는 두 직군의 조율입니다. UXer든 PM이든 "이게 UX적으로 중요해요"라고 말하지만, 개발자는 "어떤 구조로 돌아가야 하죠?"를 묻습니다. 이 간극을 줄이기 위한 가장 현실적인 방법은 다음과 같습니다:
Flow와 Logic을 정리한 문서 제공: 단순한 와이어프레임이 아니라 인터랙션 흐름, 조건, 예외 상황 등을 로직 중심으로 정리한 문서가 개발자의 신뢰를 이끎
페이퍼 프로토타입 or 코드 근접 프로토타입: ProtoPie, Framer 등으로 만든 인터랙션 데모는 ‘감’이 아닌 ‘구현 레벨’로 대화가 가능하도록 유도 (물론 UX 조직과 담당자 여건이 돼야 진행 가능)
기능 제안 → 우선순위 레이어링: "이건 꼭 필요하고, 이건 있으면 좋습니다"로 나누어 제안하면 협상의 여지 발생
물론 이렇게만 한다고 해서 갑자기 안 되는 일이 되는 것은 아닙니다. 그러나 이러한 노력을 하지 않고서는 아무것도 얻지도, 상대를 움직일 수도 없습니다. 주니어들이 때론 이러한 현실에 좌절하곤 합니다. 저 또한 그랬고요. 하지만 UX 업무의 일상은 이러한 끝없는 조율입니다. 이 실상을 잘 얘기를 안 해주고 맨날 방법론과 멋진 것들만 늘어놓으니 착각할 수밖에 없었던 것입니다. 고로, 여러분들의 당혹스러움은 업계가 아닌 그릇된 멘토나 선배들에게 속은 결과라고 보셔야 옳습니다.
UXer의 협업 태도: 주장보다 조율, 감정보다 맥락
UXer의 핵심 역량은 ‘설계 능력’뿐 아니라 ‘관계 설계’에 있다는 점을 잊지 마세요.
갈등을 겪을수록 ‘상대의 제약 조건’을 이해하고,
상대의 언어로 나의 제안을 바꾸며,
사용자의 문제 해결이 ‘나의 주장’이 아니라 ‘우리의 목표’가 되게 만드는 것이 핵심
그 과정에서 ‘안 된다’는 말을 들었을 때,
한 박자 쉬며 "어느 부분이 가장 어렵나요?"라고 물어보고,
함께 가능한 대안을 찾는 태도가 협업을 ‘대결’이 아닌 ‘공동 설계’로 이끎
사실 이와 같은 이야기에 콧방귀를 뀔 개발자분들도, 작지만 위안이 되는 개발자분들도 계실 것 같습니다. 어떤 정해진 교과서적인 방법론이 없기에, 나와 함께 일하는 동료의 성향과 조직의 맥락을 잘 파악해서 적재적소에 필요로 하는 화법과 제안을 할 줄 아는 것이 결국 시니어로 가는 길임을 이해하셔야 합니다.
작은 성공 경험이 다음 설득의 자산이 됩니다
결국 UXer는 단기적인 완성도보다, 장기적인 관계의 설계를 통해 더 많은 UX를 현실화할 수 있습니다. 작은 성공을 함께 만들어 본 개발자는 다음에는 더 적극적으로 협력해 줄 가능성이 큽니다. 하나를 내주고 하나를 얻고, 작게 이루어 가야지 그렇지 않으면 반발만 사고 비현실적인 주니어로 머물게 됩니다. 이러한 인상이 한 번 박히면 이미지를 바꾸기가 참 어렵기도 하답니다.
무언가를 바꾸는 건 결국 사람이 하는 일입니다. 사용자의 문제를 해결하기 위해 UX를 설계하듯, 협업 관계도 설계의 대상입니다. ‘어떻게 하면 같이 만들 수 있을까?’라는 질문을 중심에 두고, 오늘의 갈등을 내일의 협업 자산으로 바꾸어가시길 바랍니다. 진심으로 응원합니다!
