개발자: "안돼요"
개발자와 소통하는 디자이너의 방법
"안돼요"
회의실이 순간 싸늘해지는 세 글자.
다들 한 번쯤은 있을 것이다. 준비해 온 시안을 설명하고 돌아온 답이 이 세 글자.
다년간의 경력에 내성이 생겼음에도 기운이 빠지는 것은 마찬가지다.
특히 주니어일수록, 많은 디자이너들이 이 말 앞에서 쉽게 얼어붙어 버리는 것 같다. 눈에 보이는 디자인에는 누구나 한마디 하지만, 개발은 전문성에 가려져 있어서 클라이언트조차 쩔쩔매는 경우가 많다.
모든 "안돼요"가 "불가능"은 아니었다. 개발을 하는 디자이너로서, 개발자의 '안돼요' 해석법을 공유한다.
오늘도 이 차가운 대답에 상처받고 지쳤을 디자이너들을 위해
'안돼요'의 다섯 가지 뜻
안돼요
비싸요
기능 자체가 불가능하진 않지만, 작업 비용이 크다는 뜻이다.
디자인에서는 간단해 보이는 수정이, 개발에서는 간단하지 않을 수 있다. 데이터 구조를 변경해야 하거나, 서버까지 바꿔야 하는 식으로 여러 것들이 얽혀있어서 전체를 손봐야 하는 경우가 있다.
안돼요
몰라요
방법을 모르는 경우로, 개발자가 해본 적이 없거나, R&D가 필요한 작업이라는 의미.
진짜로 검증이 필요해서 시간이 드는 경우가 있고, 관심이 없는 분야라서 "안돼요"라고 넘기는 경우도 있다. 왜 안 되는지, 구체적으로 어떤 부분이 문제인지를 물어보면 진짜 이유를 들을 수 있다.
안돼요
귀찮아요
번거로운 작업인 경우나 얽혀있는 이슈.
개발자로부터 공감을 얻지 못했을 때 나오는 회피성 답변에 가깝다. 작은 수정사항인 것 같은데, 막상 건드리면 연쇄적으로 다른 것까지 바꿔야 하는 경우나, 레거시가 많아서 쉽게 수정하기 어려운 경우, 기획 정리가 분명하지 않아서 개발하면서 예외 케이스를 대응하거나 하는 등의 작업이 필요한 경우 등등.
안돼요
이해가 안 가요
스펙 오해로 발생하는 경우.
명백히 되는 것인데도 안된다는 답변이 돌아오기도 하는데, 기획을 텍스트로만 공유할 때 특히 자주 발생한다. 다시 설명하거나, 스펙을 분명히 하면 가능하다고 다시 답변받는 경우가 많다. 나중에 개발 다 되고 발견되는 경우도 많아서... 차라리 오해가 일찍 드러난 것이 다행인 상황이다.
안돼요
진짜 안돼요
기술적으로 아예 불가능한 것, 현실적으로 불가한 것.
물론 시간과 돈이 있으면 안 되는 것이야 이 세상에 없겠지만. 현재의 기술 스택과 환경에서는 근본적으로 다른 접근이 필요한 경우가 있다. 생각보다 이 케이스는 드물다.
서로를 이해할 수 없는 - F와 T같은 관계
"왜 맨날 안 된다고만 할까", "왜 무리한 요구만 할까"
디자이너와 개발자는 마치 F와 T처럼 기질 자체가 다르다. 실제로도 엔지니어는 T가 많고, 디자이너는 NF가 높다고 하니 그냥 비유만은 아니기도 하다.
이런 성격의 차이가 아니더라도 맡은 업무 역할에 있어서 차이가 날 수밖에 없는 관계이다.
요청하는 사람과 구현하는 사람
많은 조직에서 최종 구현 권한은 개발에 있다. 디자이너는 아무리 좋은 설계를 해도 개발이 만들어주지 않으면 세상에 나오지 않는다. 이 구조에서 디자이너는 늘 "부탁하는 쪽"이 된다. 디자이너에게 "안돼요"는 거절이다. 내가 고민한 시간을 부정당하는 느낌. 이 경험이 반복되면 무력감이 쌓인다.
개발자 입장은 다르다. 이미 잘 돌아가고 있는 시스템이 있다. 그런데 누군가 와서 "이걸 바꿔주세요"라고 한다. 안정적으로 작동하는 것을 건드려서 새로운 리스크를 만들어야 하는 것이다. 디자이너가 요청을 가져올 때마다 개발자에게는 일이 늘어난다. "또 일을 만들어 왔다"는 느낌. 이 경험이 반복되면 부담감이 쌓이고, 방어적으로 변한다.
같은 대화인데 한쪽은 "왜 안 해줘?"를 느끼고 다른 한쪽은 "왜 자꾸 일을 줘?"를 느낀다. 누가 나쁜 게 아니라, 서 있는 자리가 다른 것이다.
사용자 관점과 공급자 관점
디자이너는 사람과 맥락을 본다. "이 사용자는 이 상황에서 이렇게 느낄 거예요." 사용성을 높이는 과정에서 예외 케이스와 컨텍스트 대응은 끊임없이 생길 수밖에 없다.
개발자는 시스템과 규칙을 본다. 개발하기 쉬운, 논리적으로 깔끔한, 규칙이 잘 갖춰진 구조. 예외 하나가 추가될 때마다 버그가 숨을 수 있는 표면적이 넓어지고, 유지보수 비용이 기하급수적으로 올라간다. 시스템을 보호하려는 전략이다.
작업 방식도 다르다. 디자이너는 러프에서 시작해서 점점 다듬어가지만, 개발은 처음에 전체 구조를 짠 뒤 구현에 들어간다. 후반에 바뀌면 비용이 급격히 올라간다. 같은 요청이어도 타이밍에 따라 무게가 완전히 다르다.
능숙하게 소통하는 실전 방법
실무에서 부딪히며 직접 터득한 주요 방법
1 질문하기
"어떤 부분이 어려운 건가요?", "비용은 얼마나 드나요"
이 한마디만 더 물으면 어떤 유형의 "안돼요"인지 파악할 수 있게 된다. 거절에 두려워할 필요가 없다. 가장 최악인 것은 안 된다는 말을 듣고, 바로 새 시안을 가져오는 것이다. 왜 안 되는지를 모른 채 다시 만들면, 같은 이유로 또 안 될 수 있고 서로 지치게만 된다.
디자이너로서 혹은 기획자로서 왜 안되는지를 파악해야 다음번에도 어떤 것이 오래 걸리는지, 어려운 작업인지를 감을 익힐 수 있기 때문이다.
프로빙 Probing
UX 기법 중 사용자 인터뷰에서 표면적 답변 뒤에 숨은 진짜 맥락을 꺼내는 질문 기술
사용자에게 하듯, 개발자에게도 "왜"를 한 번 더 물어보는 것
2 같이 풀게 하기
"어떻게 하면 좋을까요?", "좋은 방법이 있을까요?"
디자이너만의 문제가 아닌 모두의 문제로 전환하는 것이 핵심이다. 의사결정에 자기 의견이 반영되었다고 느끼면 수용적으로 바뀐다. 디자이너 혼자서는 도달할 수 없는 답이 나오기도 하고, 맥락을 이해하게 되니 미스커뮤니케이션도 줄어든다.
문제 상황과 목표를 먼저 공유하는 것이 중요하다. 모든 것을 결정해서 통보하기보다, 리뷰나 킥오프를 통해 온도를 맞춰가는 방식이 낫다.
리프레이밍 Reframing
협상학에서 대화의 프레임 자체를 전환하는 기법
'너 vs 나'를 '우리 vs 문제'로 바꾸면 같은 편이 된다.
3 선택을 위임하기
"이런 것이 있는데 검토해보시고 비용 괜찮으면 포함해주세요."
없어도 크리티컬하지 않은 UX 개선 사항이라면, 꼭 요청하기보다 선택권을 주는 것도 방법이다.
필수가 아닌 디테일이 스펙에서 빠지면, 개발자는 심리적으로 비용 부담이 줄었다고 느끼게 된다.
상호성 Reciprocity
설득 심리학에서 상대의 양보에 상응하려는 심리 법칙
내가 먼저 한 발 물러서면 상대도 한 발 나온다.
4 미래를 미리 보여주기
"나중에 이런 기능이 추가 확장될 수 있어요."
디자이너가 당장의 스펙만 전달하면, 개발자는 현재에 최적화된 구조를 짠다. 보이는 범위 안에서 가장 효율적인 방법을 선택하는 것이니까 당연하다.
이런 스펙에 대해 미리 공유를 하게 된다면, 확장성을 고려해서 설계할 수 있을 뿐만 아니라, 비용이 적은 경우 먼저 포함되기도 한다.
당장 대응하지 않더라도, 미리 들은 경우 "그걸 지금 말해?"와 "아, 그때 말한 그거"의 차이다.
한 발 앞서서 공유하는 비용이, 매번 뒤늦게 설명하는 비용보다 훨씬 싸다.
실무에서는 피그마 핸드오프를 공유할 때, 맨 뒤에 Future Plan 파트를 붙여서 라이브에 반영될 스펙과 구분하되 참고할 수 있도록 하고 있다.
확장성 Extensibility
미래의 변경을 수용할 수 있도록 현재 구조를 짜는 것
개발자가 이걸 하려면 미래 정보가 필요하다. 그 재료를 주는 것이 디자이너의 역할.
5 라포 형성
협업은 결국 사람과 사람과의 일
사실 가장 중요한 것인데 가장 어려운 것이기도 하다.
처음 프로젝트에 합류했을 때가 가장 힘든 시기다. 낯선 사람이 갑자기 와서 일을 만들고, 수정해야 한다고 하면 방어적으로 나올 수밖에 없다.
이 신뢰가 쌓이면 재미있는 일이 일어난다. 스펙에 명시하지 않은 회색 영역을 개발자분이 알아서 채워주기도 한다. 서로 어려운 점을 먼저 이야기하고, 기분 좋게 일하게 된다. 손발이 잘 맞는다는 것, 시간이 필요한 일이기도 하다.
심리적 안전감 Psychological Safety
모르는 것을 드러내도 불이익을 받지 않을 거라고 느끼는 것
구글이 밝힌 최고 성과 팀의 1순위 조건
사실 디자이너 본인이 문제일 수도 있다
기획/디자인을 하다가 직접 개발을 맡게 된 적이 있었다. 이때, 가장 놀랐던 건 내 기획과 디자인의 빈틈이었다. 보이지 않았던 예외 케이스들, 정리가 필요한 부분들. 누군가는 해야 하는 일이었고, 그동안은 개발자가 채우고 있었다.
직접 만들어보니 관점이 바뀌었다. 상상을 넓히고, 스펙을 늘리고, 디테일을 높일수록 개발 비용이 올라간다는 걸 체감하게 되면서 설계가 효율적으로 바뀌었다. 기획의 공백도 보이기 시작했다. 반대편에 서보니 개발자의 "안돼요"가 다르게 들렸다.
계속해서 "안돼요"만 듣고 있는 상황이라면, 자신의 역할을 디자인과 기획의 범위 안에만 가두지 않았는지 돌아볼 필요가 있다. 개발 영역을 전문가의 영역으로 존중하되, 어떤 라이브러리를 쓰는지, 어떤 구조로 구현되는지를 가리지 않고 알아가는 것. 그 지식은 결국 자신의 밑거름이 된다. 직접 개발하지 않더라도, 개발자와 소통하는 일을 계속할 것이라면. AI 시대에 에이전트를 활용해 직접 구현하게 될 것이라면 너무나 중요한 역량이다.
그리고 여기에 역설이 있다. 상대의 영역을 이해할수록, 오히려 자신이 원하는 방향으로 디렉팅할 수 있게 된다. 실무에서 개발의 구조를 아는 디자이너의 요청은 무게가 달랐다. 제약을 아는 사람이 제약 안에서 가장 자유롭다.
디자이너는 사용자를 이해하는 전문가다. UX 리서치를 하고, 사용자의 맥락을 파악하고, 판단 기준과 제약 조건을 분석해서 더 나은 경험을 설계한다. 유저 반응의 숨은 맥락을 끄집어내는 것. 그게 직업이고, 그게 전문성이다.
사용자의 "이거 불편해요" 뒤에 숨은 맥락을 찾아내는 건 자신 있었다. 그런데 옆에 앉은 개발자의 숨은 맥락은 찾으려고 하지 않았다. 이 글을 쓰면서야 깨달았다.
참고
1) 프로빙 Probing — Nielsen Norman Group
2) 리프레이밍 Reframing — Fisher & Ury, Getting to Yes (Harvard Negotiation Project)
3) 상호성 Reciprocity — Robert Cialdini, Influence: The Psychology of Persuasion
4) 확장성 Extensibility — 소프트웨어 설계 원칙
5) 심리적 안전감 Psychological Safety — Amy Edmondson, The Fearless Organization / Google Project Aristotle