앞서 발행한 “깃허브(GitHub), 세계 각국에서 리모트로 근무하는 회사”에 이어서 깃허브 두 번째 이야기이다. 

미진: 오! 여긴 정말 디자이너가 있는 층 같아요. 드디어 제임스님이 일하는 걸 볼 수 있는 곳이군요!!

제임스: 우리 회사는 디자이너를 좋아하는 회사예요. 오피스에 art를 많이 녹여내려고 해요. 여기 붙어있는 그림들은 예전에 어떤 직원 어머니가 유치원 선생님 하시면서 아이들과 스케치했던 것들이에요. 

제임스: 여긴 애니메이션 스튜디오예요. 제가 일하는 곳이죠. 

GitHub Animation Studios

미진: 깃허브에서 애니메이션을 만드는 줄 몰랐어요, 어떤 애니메이션을 만들어요?   

제임스: 깃허브 유투브(GitHub Youtube)에 가보시면 애니메이션이 두 개 있어요. 하나는 아마존웹서비스(AWS)에 깃허브 엔터프라이즈(GitHub Enterprise)를 런칭할 때 만든 젯팩(jetpack)이고, 일주일에 한 번씩 진행되는 유니버스 컨퍼런스(Universe conference) 할 때 띄우는 애니메이션이에요. 

제임스: 제가 일하는 방에는 애니메이션 작업하는 사람들이 모여있고, 이쪽은 필름/비디오 작업하는 분들이 주로 이용하세요. 저흰 리모트가 워낙 많으니 작업물을 레코딩 해서 올려두고 커뮤니케이션하려고 만들어둔 공간이에요. 인터넷 마케팅 비디오 같은 것들도 많이 찍어요. 

필름/비디오 작업 공간

미진: 깃허브에서 디자이너로서 일하는 방식을 소개해주실 수 있어요? 아이디어를 내서 디자인하고, 그걸 최종 의사결정 받는 단계까지요. 디자인할 때 처음부터 컴퓨터에서 프로그램을 써서 그림을 예쁘게 만드는 작업보다는 종이에 스케치를 먼저 할 텐데, 깃허브에서는 어떻게 하는지 궁금해요. 

제임스: 제품에 따라서 다르고, 디자이너 역할마다 좀 달라요. 깃허브에서 디자이너는 세 타입으로 분류할 수 있는데, 첫 번째는 UI/UX 하는 사람, 두 번째는 옥토캣 그리는 애니메이터, 마지막이 저처럼 방향성을 제시하는 마케팅 디자이너예요. 

저는 보통 스케치북에 브레인스톰하면서 적고, 스케치하다가 컴퓨터로 옮겨서 디지털화해요. 다른 분들은 와콤(wacom) 태블릿에 그려서 작업하기도 하고, UI/UX는 아이패드에 스케치해서 UI 안을 만들기도 해요. 팀마다, 하는 일에 따라서 방법도 사용하는 프로그램도 달라요.

제임스의 스케치북

제임스: 저는 보통 처음 시작할 때 종이에 브레인스톰을 하기도 하고, 각각의 아이디어를 스케치하다가 맘에 드는 것은 스마트폰으로 찍어서 컴퓨터로 옮기고, 툴로 그려서 보여줘요. 

 

현재는 제 롤이 좀 바뀌어서 다른 디자이너를 감독하는 역할도 하게 됐어요. 다른 디자이너들에게 피드백 주는 역할을 더 하게 돼서 최근엔 그 일에 시간을 많이 할애하고 있어요.  

 

미진: 그럼 작업물을 윗사람에게 보여줄 때 그 사람들은 피드백을 어떤 식으로 줘요? 제 경험을 예로 들면, 저는 각 장면이 넘어가는 것을 시나리오 문서로 만드는데, 실제 제품은 인터랙션이 있는 것이라 윗사람은 동작성을 보여달라고 하시거든요. 시나리오 의사결정을 위해서 문서 말고 움직이는 걸 가져오라고 하시니까 시나리오가 완성되지 않은 채로 개발자가 투입돼서 화면으로 만들어서 보여주면 그때부터 고치는 작업을 해요. 

제임스: 그런 피드백은 많은 회사의 문제점이긴 해요. 그래서 깃허브에서는 그런 문제를 줄이려고 피드백을 가능한 빨리, 자주 하려고 합니다. 개발이 많이 진행된 다음에 피드백을 주면 고치기도 힘들잖아요. 그래서 아까 같은 상황에서는 스토리보드에 아이디어를 네다섯 가지 보여주고, 각각에 찬성/반대 투표를 해요. 그리고 부족하다고 반대가 나온 내용은 보완하고요. 이게 저희 프로세스예요. 

깃허브에서 디자인은 '그냥 이쁘게 하기 위한' 것이 아니고 문제 해결 도구예요. 그래서 피드백을 달라고 할 땐 "이 디자인은 어떤 문제를 해결하는 디자인이다. 그러니 그 부분에 대한 피드백을 달라"고 요구합니다. 

 

미진: 그럼 윗사람에게 이 디자인은 어떤 목적을 해결하기 위한 디자인이고, 어떤 의도와 어떤 철학을 담고 있는지를 잘 커뮤니케이션한다는 거죠?

제임스: 그렇죠. 하지만 모든 사람이 전문가가 아니니까 그 말을 다 알아듣긴 힘들어요. 그렇다고 해서 모두가 이해하기 쉽게 프로토타입을 만들어 주기보다는 ‘어떤 문제가 있었고, 그걸 어떻게 해결했다’고 오픈 커뮤니케이션을 주로 해요.   

 

미진: 아이디어를 구체화하다 보면 다른 의견이 나올 수도 있을 텐데, 그럴 땐 어떻게 해요?

제임스: 만약 두 사람이 동의 못 하고 논쟁이 생기면 매니저가 와서 결정을 해주는 시스템도 있어요. 하지만 모두 동의할 때까지 의견이 왔다 갔다 하면 배포를 못하니깐, 기본적으로 배포를 빨리 해보고 변경하는 것을 권장하죠. 

만약 프로토타입이 있으면 다른 사람이 동의할 때까지 안 하는 게 아니고, 일단 빨리 만들고 보여줘서 예스와 노를 결정할 수 있게 해요. 물론 프로젝트가 많아서 다 다르긴 하지만요.

 

미진: 빨리 배포하자고 하면, 그다음에 바로 따라 나오는 얘기가 품질이잖아요. 품질이 떨어지는 것을 업데이트하면 사용자의 만족도가 떨어진다고요.

제임스: 맞아요. 그런 얘기가 나오죠. 하지만 아무거나 배포하지는 않고, 1.0 버전을 좋게 만들어지길 기다려요. 그 기능의 가장 메인이 되는 것을 골라 1.0 버전으로 만들고, 깃허브를 잘 쓰는 작은 규모의 집단에게 먼저 보내서 '사용하고 피드백을 달라'고 해요. 그 피드백을 바탕으로 좀 더 고도화해서 2.0과 3.0 버전이 나오면 더 큰 집단에게 오픈해요. 이렇게 차츰 사용자 범위를 늘려서 배포하는 방법을 써요. A/B 테스트(버전 A와 다른 버전 B를 비교하여 테스트하는 방법)하듯이요.  

원래 미팅을 잡았던 날은 5월 16일 월요일 2시였다. 30분 정도 일찍 도착해서 한 시 반부터 두 시간가량 회사를 둘러보고, 깃허브에서 디자이너로 사는 삶과 일하는 문화에 대한 이야기를 많이 들을 수 있었다. 

 

헤어질 무렵엔 깃허브의 분위기를 좀 더 느껴보라며 다음날 점심에 다시 초대해주셨다. 그리하여 이튿날엔 사내에서 식사하며 깃허브의 다른 구성원들의 분위기도 느낄 수 있었다.

 

세계 각국의 개발자뿐만 아니라 다양한 일을 하는 많은 사람이 협업할 수 있는 에코 시스템을 만드는 데 기여하고 있는 깃허브. 하루빨리 한국에도 오피스가 생겨서 성장하는 모습을 더 가까이서 볼 수 있었으면 하는 마음을 안고 깃허브 오피스를 나섰다.

 

언제 어디서든 근무할 수 있는 환경과 문화가 정착된 깃허브에 대하여, 그리고 개발회사에서 디자이너로 산다는 게 어떤 것인지, 한국의 개발자를 포함한 직장인들의 궁금증이 풀리고 더 나아가 각자의 업무 환경을 되돌아보는 기회가 됐으면 한다.

 

무엇보다 인터뷰에 흔쾌히 응해주시고 솔직한 이야기를 들려준 제임스 님께 감사의 말을 전한다.