디자이너와 개발자는 서로의 성장동력이 됩니다
개발자와 함께 성장하기 위한 디자이너의 소통법
안녕하세요! 오늘도 제 흑역사로 글의 시작을 열어보겠습니다~. 약 2년 전, 지금 재직 중인 회사에 입사했을 때 전 ‘성장병’에 걸려있었어요.
다른 동료 디자이너보다 실력이 뒤쳐진 것 같다는 생각에 마음이 아주 조급한 상태였어요. 그런데 아무리 ”성장! 성장“을 외쳐봤자 앞으로 나아가기는커녕 점점 더 뒤처지는 결과가 나오는 거예요. 너무 분하고 속상했었죠.
돌이켜 생각해 보니, 제가 성장을 위해 보냈던 시간들 대부분이 입 꾹 닫고 피그마 화면만 보면서 텍스트 크기 바꾸고 배치 바꾸는 시간들이었어요.
그 사이에 디자인 팀 동료들은 서로 피드백도 주고받고 개발자와 소통하면서 시야를 넓히고 있었고요.
제 성장이 더뎠던 건 오히려 성장하려고 싶다는 욕심에 발목을 잡혀 제 시야를 좁게 만든 탓이었습니다. 지금은 이유를 알지만 그때는 그저 속상하기만 했어요. 그렇게 약 일 년 정도를 “성장! 성장!” 외쳤으나 남은 것은 송장이 된 저 자신만 남았습니다.
송장의 시간을 지나, 저는 웹툰 주인공처럼 나 혼자만 레벨업 할 수 있는 상황은 오지 않는다는 것을 인정하게 됐어요. 게다가, 저 혼자 잘해봤자 결국 일은 팀 단위로 굴러가기 때문에 아무 소용없다는 것도 깨닫게 되었습니다. 그래서 팀이 함께 퍼포먼스를 업그레이드할 수 있도록 동기부여를 주는 팀원이 되고 싶었고, 그런 역할을 하는 저를 상상하니 굉장히 두근거렸어요!
결과적으로, 회사에 가서 “우리 같이 성장합시다!”라고 외치는 것은 실패했다는 걸 먼저 말씀드려요.
누군가 성장! 하고 외쳤다고 다 같이 오오! 하면서 의욕을 활활 불태우는 건 만화책 속 일이라는 걸 덕분에 깨달았어요. 생각해 보면 누군가 와서 앞뒤 없이 함께 성장하자고 말하면 저도 이 사람 뭐지, 싶겠더라고요. 이렇게 제 첫 시도인 <대화를 통해 상대방에게 동기부여 주기>는 깔끔하게 망했습니다.
그래서 제 새로운 방법은 <업무적 대화 속에 당신과 함께 성장하고 싶다는 메시지 넣기>입니다. 그리고 이 방법은 꽤 효과적이어서, 제로에 수렴했던 개발자와의 소통 시간이 훌쩍 높아졌어요. 그 효과로 개발 지식에 대한 제 이해도도 높아졌고요. 개발 빼고 뭐든 심드렁한 개발자의 관심을 어떻게 끌면 좋을지 이제부터 알려드리겠습니다!
저희 회사는 디자인 툴로 Figma를 쓰고 있어요. 피그마 정말 좋은 툴이죠! 특히 개발자들이 개발 작업을 하는 환경과 비슷하게 Branch를 딸 수 있다는 점이 가장 훌륭한 부분입니다.
개발자들은 로컬에서 작업하고 마스터로 코드를 PR(Pull Request)하는데요, 코드리뷰가 완료되면 마스터에 로컬 코드가 Merge 됩니다. 이 과정을 피그마로 똑같이 따라 할 수 있어요. 피그마 역시 원본인 마스터 파일을 그대로 유지한 채 Create Branch를 하면 마스터가 그대로 옮겨져 온 복제 파일이 생깁니다. 여기서 디자인을 수정한 다음에 Merge 버튼을 누르면 수정한 디자인대로 원본에 덮어쓰기가 됩니다.
그런데 많은 개발자들이 피그마도 개발처럼 Branch를 딸 수 있다는 것을 모르세요. 당연합니다. 디자이너도 개발자들이 쓰는 git이나 터미널을 잘 모르잖아요. 저는 이 점을 공략하기로 했어요. 여기서부터 개발자에게 <함께 성장해요 소통법>을 실험하기로 했습니다.
저는 앱의 프런트를 담당하시는 개발자 J님에게 슬쩍 다가간 뒤 이렇게 업무 요청을 드렸어요.
J 님, 이번 유저스토리 작업을 시작하기 위해 피그마에 브랜치를 새로 만들려고 하는데, 이 브랜치 파일의 타이틀을 함께 정하고 싶습니다.
사실 브랜치 타이틀 규칙은 어느 정도 정답이 정해져 있지만, J님에게 피그마의 구조를 알려주면서 ‘코드와 피그마는 꽤 비슷하게 접근할 수 있어요’라는 점을 넌지시 알렸어요. 그리고 몇 가지 오류를 섞은 타이틀 규칙을 소개하면서 점차 J님이 정답에 접근하도록 유도했습니다.
J : 테스크 단위로 브랜치 타이틀을 정하면 브랜치가 엄청 많을 수도 있을 텐데, 그러면 너무 많아서 오히려 찾기 힘들지 않아요?
소피 : 그렇겠네요. 그럼 타이틀은 여러 테스크가 묶여있는 유저 스토리로 정할까요?
J : 그러면 테스크에 따라 화면 이곳저곳 자잘하게 수정된 게 많을 때는, 어디가 어떻게 바뀌었는지 제가 일일이 확인해야 하나요?
소피 : 피그마에 ‘코멘트’라는 기능이 있는데, 링크 복사가 가능해요. 시안에 코멘트를 달아서 어디가 어떻게 바뀌었는지 쓰고, 코멘트 링크를 지라 테스크 티켓에 달아놓을게요. 링크 클릭하시면 디자인 수정된 곳으로 바로 이동할 수 있어요.
J : 유저 스토리는 너무 길어서 타이틀로 부적합해 보이는데요? 글자가 잘려서 안 보이는데?
소피: 그러면 해당 유저스토리를 담은 지라 테스크 티켓 넘버를 브랜치 타이틀 앞에 붙여놓도록 할게요.
몇 번의 핑퐁 끝에 J님은 만족의 ‘Good’을 말했습니다. 이렇게까지 핑퐁 하면서 협업 방식을 논의하고, 은근슬쩍 피그마의 브랜치 기능과 코멘트 기능을 알려준 이유는 개발자 J님의 성장이 제 성장과도 이어진다고 생각했기 때문이에요.
저는 J님이 다른 디자이너와 협업하게 되었을 때 지금의 경험치를 디폴트로 삼을 수 있을 만큼 좋은 협업 경험을 쌓아주고 싶었어요. 그럼 J님은 점점 디자이너가 함께 일하기 좋은 프런트엔드 개발자가 될 거고, 그게 J님의 차별화된 강점이 되길 바랐습니다. (아구몬을 스컬그레이몬 말고 메탈그레이몬으로 키우고 싶은 신태일의 마음이랄까요)
그리고 이 과정에서 저 역시 개발자가 일하기 좋은 디자이너가 될 수 있겠다 싶었어요. 제 성장과 동료의 성장이 일치하도록 뒤에서 노력하고 있다는 사실은 저에게 큰 동기부여가 되었습니다. 이렇게 흑심을 품고 일하던 와중, 스프린트의 마지막 시점이 되자 J님이 오셨어요.
J : 언제까지 디자인 QA 해줄 거예요?
갑자기 툭 튀어나온 디자인 QA 요청에 혼란스러워지기 시작했습니다. 전 사실 디자인 QA를 아직 할 필요가 없다고 생각했거든요. 왜냐하면 이번 스프린트에서 구현된 디자인은 확정된 디자인이 아니고, 벌써 다음 스프린트 개발 진행을 위한 디자인 수정을 하고 있었거든요. 그래서 저는 J님께 아래처럼 말씀드렸어요.
J님, 우리 유저스토리 기준으로 디자인 QA 하는 게 좋지 않을까요? 왜냐면 아시다시피, 유저스토리를 충족하기 위한 디자인 시안이 계속 바뀌고 있잖아요. 더 이상 디자인이 변경되지 않고 해당 유저스토리가 PM 기준으로 완료가 되면 그때 디자인 QA를 통해 세세하게 디자인 오류를 잡고 배포하는 룰 어떠세요?
하지만 이 소통은 J님을 설득하지 못했습니다...ㅠ
J : 소피님 말에는 오류가 있는 게, 그렇게 따지면 스프린트 진행 동안 디자인 마크업 작업은 필요 없고 기능이 제대로 굴러가는지만 확인하면 된다는 말이네요?
그런데 PM님이 남겨주시는 요청들 보면 어떤 건 ‘디자인 시안대로 개발해 주세요’ 같은 코멘트도 있단 말이죠.
그리고 디자인 시안이 언제 완료되는지 물어보면 소피님도 잘 모르겠다고 하시잖아요. 그래서 저는 거의 실시간으로 디자인 마크업 작업을 하고 있는 거고.
PM이 요청하고 스프린트 안에 디자인 마크업 작업을 진행했으니까 디자인 QA도 스프린트 단위로 QA 시점을 잡아가야 한다고 생각해요.
J님과의 대화는 솔직히 앞이 캄캄했습니다. J님의 말씀을 듣는 순간 이 문제는 개발 구현과 디자인 작업의 시간차가 원인이라는 게 바로 떠올랐어요.
개발 구현과 디자인 시안에는 언제나 시간차가 있기 마련인데, 디자인이 나와있어야 퍼블리싱이라도 시작할 수 있기 때문에 시안이 한 발 빠르게 나와있는 게 프로세스 상 자연스럽죠. 이 상황의 경우는 2주간의 스프린트 동안 디자인 branch ver.1이 나왔고 J님은 이걸 보면서 작업하고 있었어요.
그런데 스프린트 중에 유저스토리의 우선순위가 변경되면서 동일한 디자인 마스터 파일에 branch ver.2가 나와버린 것이죠.
J님은 branch ver.1의 구현이 끝났으니 디자인 QA를 하고 브랜치를 마스터에 합치는 것을 원했던 것이고요, 제 입장에서는 그럴 필요 없이 branch ver.2 구현이 끝나면 그때 디자인 QA를 하겠다는 의견이었어요. 그리고 파일 합치기는 좀 더 신중하게 가져가서 실제 서비스가 출시되면 그때 합쳐서 ‘출시된 앱 = 브랜치 원본 파일’을 만들자는 입장이었죠.
문제는 이 긴 설명을 어떻게 전달할지 생각이 잘 정리가 되지 않더라고요. 게다가 눈앞에서 실시간으로 말을 뱉는 속도가 점점 빨라지는 J님을 보면서 머릿속은 적색 신호가 삐용삐용 울리기 시작했어요. 결국 멀찍이 상황을 보고 있던 사수 디자이너님이 나서서 상황을 정리해 주셨습니다.
1. 스프린트의 유저스토리가 정해지면 디자이너가 먼저 브랜치 파일을 만들고 작업을 시작한다.
2. 디자이너는 유저스토리 별로 디자인 핸드오프 일정을 개발자에게 알리고 그 일정이 되면 약속했던 대로 지라의 태스크 티켓에 피그마 링크를 붙인다.
3. 그보다 조금 더 늦게, 개발자도 브랜치를 만들어 작업을 시작한다.
4. 개발 진행 중 변경된 디자인 사항은 디자이너가 피그마 코멘트로 적고 개발자에게 노티를 준다.
5. 스프린트 종료 3일 전 개발자가 PR을 올리고 디자인 QA를 시작한다.
6. 디자인 QA 후 찾은 에러들을 개발자에게 전달한다.
7. 개발자는 에러를 수정한 뒤 다시 PR 한다.
8. 스프린트 종료 후 개발 코드와 디자인 파일은 동시에 마스터 파일에 Merge 한다.
9. 만약 유저스토리가 끝나지 않아서 다음 스프린트에서도 이어지게 된다면 다시 동일한 이름의 브랜치를 따서 작업한다.
사수님의 아홉 가지 프로세스는 얼핏 보면 꽤 복잡해 보이지만, 이 프로세스가 제대로 뿌리내리게 된다면 몇 가지 장점이 예상됩니다.
첫 번째, 팀원이 업무의 전체 흐름을 쉽게 파악할 수 있고 따라서 능동적으로 일할 수 있게 됩니다.
디자이너가 먼저 일정에 따라 디자인 QA를 요청할 수도 있고, 혹시 업무에 딜레이가 발생하고 있는지 PM이 체크하기도 쉽습니다. 점점 손발이 맞아가면서 서로를 마크해 줄 수 있는 원팀이 될 수 있을 거예요.
두 번째, 디자이너와 개발자, PM까지 높은 협업 경험치를 쌓는 시간이 될 수 있어요.
이 프로세스를 기준으로 일하는 모두가 프로세스의 기여자가 되고 나중에는 이 경험치를 가지고 다른 곳에 적용할 때 보다 능숙하게 협업 문화를 만들 수 있을 것입니다.
세 번째, 협업 기간 동안 보완점과 개선점을 찾기 쉬워요.
프로세스를 기준으로 보다 상세하게 회고가 가능하기 때문이에요. 단순히 스프린트가 끝난 후 애매한 감상으로 “뭔가 아쉬웠어요”를 말하기보단, “프로세스 기준으로 4번 과정에서 디자인 수정에 대한 노티가 잘 이루어지지 않았다”같이, 보다 구체적이고 세세하게 문제를 정의할 수 있습니다. 구체적인 문제 정의는 정확한 해결 방법을 찾는데 늘 도움이 되지요.
다시 처음으로 돌아와서, ‘함께 성장하기’에 대해 솔직히 말씀드리면 남 성장을 돕다가 정작 내가 뒤쳐지면 어떡하지?라는 불안감이 엄청 많았어요. 함께 성장하는 길이 제 성장에 도움이 된다는 교훈을 얻었을 때에도 ‘내가 능력이 있어야 남의 성장을 도울 수 있을 텐데, 난 아무것도 없는 걸’라고 생각했고요. 이런 생각 때문에 처음에는 같이 협업하는 동료에게 말 걸기도 어려웠습니다ㅠㅠ
그래도 지식을 공유하는 첫 삽을 위해 출근길에서도 공부했고, 그날 새롭게 배운 것을 동료에게 얘기하거나 회사의 리서치 채널에 공유했어요. 공유하면서도 이 정도 내용은 다들 알고 있는 건데 괜히 공유하다가 오히려 내 낮은 수준만 들키는 것 아닐까, 하고 수십 번을 고민했답니다.
제 걱정과는 달리, 이미 알고 있는 내용이더라도 다시 정리가 된다며 좋아해 주셨고 동료들로부터 공유 감사하다는 피드백을 받으면서 점차 자신감이 생겼습니다. 무엇보다 공유하면 공유한 날짜와 시간, 내용이 남는 게 좋았어요. 함께 성장하기 위한 제 노력이 막연히 실체 없는 게 아니라 측정될 수 있는 노력이란 점이 특히요.
그래서 저는 동료들과 함께 성장하기 위해 앞으로도 아등바등하면서 공유하고, 소통하려고 합니다. 특히 제 업무에 개발자를 초대하면서 함께 협업하는 방법을 맞춰가는 과정이 저를 더 성장시켜 줄 거란 확신이 들어요.
오늘 소개해드린 이야기 말고도 J님과의 에피소드는 정말 많은데요, 다음에 또 살포시 이야기 들고 찾아올게요.
긴 글 읽어주셔서 감사합니다. 다음에 또 만나요~!
