[220521] 개발자, 프로덕트(디자인) 팀과 협업

한 회사에서 딱 1년을 채우고 나니까 입이 막 터지네. 매일 하고 싶은 말이 떠오른다. 

 

오늘은 동료 디자이너로부터 고마운 피드백을 받았다. 다음 주부터 본격적으로 개발을 실행할 프로덕트가 있어서 오전에 피그마를 보고 디자인 리뷰를 해서 전달 드렸는데, 그 리뷰를 계기로 피드백을 주신 것 같았다. 나한테 디자인 리뷰를 받으면 아이디어가 정리되고 방향이 선명해져서 도움이 되어 감사하다는 내용이었다. (사실 나도 열심히 숨기려고 하지만 머릿 속은 항상 대혼란이라 피드백을 받고 아주 잠시 몸둘 바를 모르긴 했다.)

 

사실 회사가 소규모다 보니 디자인 팀에서 개발 팀으로 넘어오는 핸드오프가 엄청 체계적이거나 상세하다고는 할 수 없는데, 그래서 디자인에서 개발로 이어지는 흐름에서 중간 단계를 하나 더 놓을 필요성을 느꼈다. 내가 개발하기 전에 우선 디자인 프로토타입을 살펴본 다음 빠진 부분이나 애매한 요구 사항, 예외 케이스 등을 따로 정리해서 디자인 팀에 피드백을 드리는 방식으로 작업하고 있다. 다른 회사나 더 큰 팀에서는 어떻게 하는지 몰라서 어쩌면 아주 당연한 프로세스일지도 모르겠다는 생각도 든다.

 

처음부터 이렇게 작업을 한 건 아니고 올해부터 시작하게 되었다. 그 전까지 개인적으로 개발을 제외한 일 중에 디자인 팀과의 협업이 가장 풀기 까다로운 문제였다. 처음에 디자인 팀과의 협업을 단순하게 생각했다. '프론트엔드 개발자로서 디자인을 넘겨 받으면 그것을 정확하고 디테일하게 구현하는 것'. 이 한 문장만 봐도 알 수 있겠지만 여기에 사실 "협업"과 관련된 내용은 없다. 내가 얼마나 답이 없는 상태였는지 짐작할 수 있을 것이다. 나 스스로도 고통이었지만 디자인 팀은 무슨 죄 (...). 아무튼 처음에 저런 생각으로 일을 하면서 다음과 같은 문제들을 마주쳤다.

 

끝없는 Q&A

디자인을 받아 무작정 개발에 뛰어들면 CSS 한 줄을 추가할 때마다 머리 위에 물음표를 띄우게 된다. 이대로 가다간 분명 무언가 잘못된 결과물이 나오리라는 직감을 느낀다. 그 때부터 디자인 팀에 무한 Q&A를 요청하게 되고, 디자인 -> 개발 -> 디자인 수정 -> 개발 수정 ... 이 과정을 계속 도돌이표처럼 겪게 된다. 기획 세부 사항이나 디자인의 어떤 요소를 하나를 고쳤을 때 사이드 이펙트처럼 그 이후의 디자인도 전부 변경되고, 이미 개발된 사항들이 배포되기도 전에 거듭 수정된다. 이를 반복하면 극도로 의욕과 생산성, 효율이 떨어진다.

내가 초반에 가장 현명하게 풀어내지 못했던 문제이기도 하다. 중간에 디자인이나 기획이 변경되거나 홀딩되면서 개발이 한번에 진행되지 못하고 중단되면서 개인적인 불만이 엄청 쌓였다. 프론트엔드 업무가 프로세스 파이프라인 마지막 단에 위치하다보니 업무 데드라인을 지키지 못할 때도 있었다. 그럴 때마다 아무도 뭐라고 안했는데 괜히 억울해하기도 했고, 나도 모르게 속으로 남탓을 하기도 했다. 이러한 악순환으로 인해 일에 대한 의욕이 엄청 깎였던 시기이기도 하다.

 

지금 생각하면 사실 관점을 조금만 바꿔도 쉽게 기회로 삼을 수 있는 문제였다. 분명 내부에서 발생한 비효율이었고, 이를 해결하면 될 일 이었다. 내가 결정적으로 관점을 바꾼 계기는 인프런 CTO 향로 님의 블로그 글 "엔지니어의 세심함"이었다. 내 상황에 정확하게 들어맞는 글은 아니었지만 스스로 엄청 부끄러웠다. 근본적인 태도에 있어서는 나도 분명 저 글이 비판하는 개발자들과 다를 게 없었기 때문이다. 그래서 디자인 팀과의 협업의 의미 자체를 스스로 다시 정의했고, 나도 디자인 리뷰를 제공하고 협업 방식을 먼저 제안하는 방식 등으로 더 적극적으로 세심함을 보여야겠다고 생각했다.

협업 과정의 생산성과 효율성이 개선되지 않는 문제에 대해서는 앞서 말했듯이 개발 팀에서 먼저 디자인 리뷰를 드리는 것, 디자인 팀에서는 수정 사항과 히스토리를 계속 아카이빙 하는 것으로 해결 방법을 찾아가고 있다. 그리고 더 본격적인 문제 해결을 위해서 스토리북 등을 통한 디자인 시스템 구축 먼저 제안 드렸고, 개발 팀과 디자인 팀에서 각자 천천히 준비하고 있다. 이렇게 일하게 되니 일도 일이지만 무엇보다 내 마음이 엄청 편하다. 지금 디자인 팀원들이 다 커뮤니케이션에 뛰어나고 친절하고 좋은 분들이라 같이 협업하는 게 전보다 훨씬 즐겁고 나도 덕분에 더 많은 것들을 금방 배운다는 느낌이 든다. 

 

디자이너의 뜻

내 편견에서 시작된 또 다른 문제가 있었다. 디자이너들은 다들 예술적 신념과 감수성이 있을 것이기 때문에 UI에 대해서 내가 입을 대는 게 무례할지도 모른다는 편견이었다. 그래서 어떤 디자인을 받았을 때 조금 어색하거나 잘 이해가 되지 않는 구석이 있어도 그냥 디자이너의 큰 뜻이 있겠거니 하고 그대로 만들었다. 지금 생각하면 반은 맞고 반은 틀리다. 분명 디자인 상의 의도나 컨셉, 지향점도 있을 것이다. 그러나 개발자로서 내가 정말 신경써야할 것은 디자이너의 신념이나 철학이 아니라 유저 경험이었다. 디자인의 목적은 디자인 자체에 있는 게 아니라 문제 해결에 있다고들 하지 않던가.

그래서 이제는 나의 전문 분야와 상관없이 오직 유저 입장에서 의문이 드는 디자인이 보이면 바로 디자인 팀에 물어본다. 물론 디자인이 왜 이러냐며 다짜고짜 따지지는 않는다.(인성) 우선 의도와 레퍼런스를 디자인 팀에 물어본 다음, 내가 사전에 찾아본 레퍼런스를 공유한 뒤에 우리 프로덕트의 성격을 고려하여 또 다른 제안을 드리는 편이다. 내 제안이 받아들여질 때도 있고 아닐 때도 있지만 어쨌든 보통 더 나은 디자인을 다시 받아보게 된다.

협업하면서도 이 과정이 좀 더 진정한 의미의 커뮤니케이션에 가깝다고 느꼈다. 처음에는 내가 워낙 UI/UX를 모르니까 따로 <UX/UI의 10가지 심리학 법칙> 같은 관련 책도 읽어보고 아티클도 찾아봤다. 물론 프론트엔드 개발자로서 많은 도움이 된 건 사실인데, 실제로 일을 할 때는 직접 디자이너들과 소통하고 설득 하거나 받는 게 더 효과적이었고 배운 것도 많았던 것 같다. 

 

 

여러 문제가 있었고 해결이 된 것도 있으며 아직 해결 중인 것도 있다. 하지만 처음과 크게 달라진 건 이 문제들을 분명 해결해나갈 수 있겠다는 자신감이 생겼다는 점이다. 이 자신감이 생긴 데에는 협업하면서 디자인, 프로덕트, 개발팀 모두 프로덕트라는 공통의 목표를 바라보고 있음을 느끼게 된 것이 큰 역할을 했다. 협업을 하는 각 팀이 다른 팀을 괴롭히기 위해서가 아니라 유저들에게 정말 더 나은 프로덕트와 서비스를 제공하기 위해 결국 같은 곳을 바라보고 일을 하고 있다. 이 단순하고 당연한 명제를 꽤나 늦게 깨우친 것 같아서, 그리고 그걸 모르고 불필요한 스트레스 받았던 걸 생각하니 엄청 부끄러워졌다. 눈 앞의 일도 중요하지만 결국 동료들이 각자 무엇을 바라보고 있는지, 그 목표가 근본적으로 동일한지 체크하면서 일하는 것도 협업의 질과 각자의 정신 건강을 위해서 아주 중요하다는 생각이 든다.