개발만 할 것 같은 회사에서 디자이너로 산다는 것
* 본 내용은 허브줌에 기고한 글입니다.
1편 : http://hub.zum.com/banglab/4554
2편 : http://hub.zum.com/banglab/4555
작년 11월에 다녀온 후 6개월 만에 또 실리콘밸리에 갔다. 다녀온 이야기를 하면 마치 출장 같다는 반응이지만 난 휴가를 간 게 맞다.
지난번엔 출장으로 구글(Google), 링크드인(LinkedIn), 오라클(Oracle), 넷플릭스(Netflix), 아마존(Amazon), 마이크로소프트(MS)를 다녀왔고, 이번엔 휴가를 갔다가 깃허브(GitHub), 우버(Uber), 테슬라(Tesla), 페이스북(Facebook)에 다녀왔다. 이번엔 주로 샌프란시스코의 회사를 방문했다. 아무래도 최근 많은 사람의 관심을 끌고 있거나 스타트업에서 시작해 스케일링하고 있는 회사들은 샌프란시스코에 있으니 말이다.
이번 이야기는, 지난번 발행한 우버(Uber)에 이어 개발자들에게 매우 친숙한 깃허브(GitHub)에 대한 이야기이다.
실리콘밸리는 개발자들의 성지라고 불리는 곳이라 그곳의 회사들을 방문하면 늘 개발자를 만났다. 그러나 이번엔 처음으로 깃허브에서 디자이너로 근무하시는 분을 만났다.
깃허브의 옥토캣(octocat) 스티커는 개발자들의 랩톱에 하나씩은 붙어있을 만큼 인기가 많은데, 개발만 할 것 같은 이 회사에서 이런 귀여운 스티커를 다양한 버전으로 계속 만들어 내는 사람들은 어떻게 일하는지 궁금했다.
또, 최근에 많은 한국 회사들이 재택근무나 유연 근무제를 도입하면서 많은 우려를 하고 불안해하지만 깃허브는 리모트 근무가 원활하게 돌아가는 이유가 궁금했다.
이런 궁금증을 풀기 위해, 깃허브에서 디자이너로 근무하시는 제임스 강(James Kang) 님을 만나 나눈 이야기를 두 편에 걸쳐 인터뷰 형식으로 구성해 보았다.
자율 출퇴근제와 리모트로 일하기
미진: 깃허브 전체 직원은 몇 명이에요?
제임스: 현재 깃허브의 전체 구성원은 540명 정도예요. 회사 안에서는 약 300명 정도 근무하고 있는데, 회사가 일하는 시간을 따로 정해두지는 않아서 그중 매일 들어오는 사람들은 약 200명 정도 돼요.
자율 출근제고, 본인이 해야 할 일 끝내면 몇 시간 일하든 상관없는 곳입니다.
미진: 자율출근제면 성과측정은 어떻게 해요?
제임스: 자기가 할 일을 끝내면 몇 시간 일하든 상관없어요. 결과로만 평가해요.
미진: 혹시 일찍 끝내면 이 사람이 쉬운 것만 했다는 인식은 없나요?
제임스: 무슨 일을 할지는 개인이 일단 생각해서 매니저와 대화해서 정해요. 각각에 점수를 매겨서 잘했다, 못했다를 나누는 것이 아니고, 개인과 팀이 평가해요. 예를 들어, 팀에 어떤 한 명이 게을러서 자꾸 쉬운 것만 한다면 팀원들이 함께 이야기해서 다음 프로젝트는 바꾸든지 자르든지 하지만, 일단 기본적으로 사람을 믿는 시스템이 갖춰져 있는 것 같아요. 그래서 그런 사람이 잘 없긴 하지만, 그런 사람들은 가능하면 일찍 도출해서 자르거나 하죠.
미진: 사람들을 자르기도 해요?
제임스: 아뇨, 지금 깃허브가 5년 됐는데 첫 3년 동안엔 아무도 안 잘랐어요.
최근엔 부득이하게 자르는 사람이 있지만, 손에 꼽을 정도라 거의 없다고 볼 수 있어요.
미진: 그럼 뽑을 때도 까다롭겠네요?
제임스: 네, 첫 단계는 폰스크리닝(phone screening)으로 거르고, 그걸 통과하면 오피스로 초대해서 개인 인터뷰(in person interview)를 진행해요. 채용할 때 까다롭게 봐서 검증된 사람을 뽑으려고 해요.
(참고 : https://github.com/blog/1269-the-github-hiring-experience)
미진: 이 화면이 여기저기 보이는데 직원들이 어디 있는지 나오는 거예요? 한국에도 있네요?
제임스: 워낙 리모트로 일하는 분들이 많으니까 어디에 몇 명 있는지 보여주는 거예요. 마지막으로 체크인한 정보가 나오는 것이라서 여행 가서 일하면 그 장소가 찍혀요. 한국에서 근무하시는 분은 없는데, 아마 여행 가셨나 봐요. 지난 주말에 유럽에서 GitHub Satellite 행사를 해서 지금 유럽에 사람들이 많이 있어요.
미진: 깃허브는 세계 각국에 있는 개발자들이 리모트로 근무하는 것으로 유명한데요, 최근엔 한국에도 소프트웨어 스타트업이 많아지면서 재택근무하는 개발자들이 있지만, 여전히 많은 회사는 직원들이 일을 잘 안 할 거라는 불안감에 온 사이트(on-site) 근무를 선택해요. 깃허브의 직원들이 이렇게 세계 각국에서 리모트로 근무하는 것이 가능한 이유가 뭐라고 생각하세요?
제임스: 같이 일하는 사람들끼리 서로 얘기할 때 깃허브를 사용하거나, 슬랙(slack)으로 채팅, 이메일로 커뮤니케이션을 많이 해서 리모트 문화(remote culture)가 있는 것 같아요. 저희는 가능하면 미팅을 많이 하지 않아요.
물론 미팅이 필요할 때도 있는데, 그럴 때는 Bluejeans 같은 화상 채팅 도구(tool)를 사용하기도 해요.
저희 팀 같은 경우는 커뮤니케이션을 계속, 자주 해서 리모트로 일하고 있어도 평소와 같이 서로 업데이트해주면서 같이 일해요. 오버 커뮤니케이션(over communication)이라고 서로 얘기를 더 자주 하고, 업데이트를 자주 하면서 같이 일을 해왔기 때문에 가능한 것 같아요.
미진: 그럼 개인은 각자 어떤 업무를 해야 하는지 명확하게 인지하고 있는 건가요?
제임스: 네. 아사나(Asana) 같은 프로젝트 관리 도구를 사용하면서 내가 어떤 프로젝트를 해야 하는지 볼 수 있어요. 두세 명이 같이 일하는 프로젝트가 많아서 업무를 명확히 나누는 것보다 서로 자주 얘기하면서 같이 프로젝트를 끝내는 경우가 대부분이에요.
GitHub에서 조직이동의 의미
미진: 이전에 다른 회사에서 일하셨는데, 깃허브에서 일하는 게 어때요?
제임스: 깃허브에서 일한 지 3년 반 됐는데, 제가 깃허브를 좋아하는 이유는 모든 사람의 멘탈이 좋아서예요. 예를 들어, 미국에선 스타트업에서 기업(corporate)으로 가는 걸 싫어해서 스타트업에서 멈추려고 하는 경향이 있어요. 그런데 우리 회사는 "기업으로 가도 된다. 왜냐면 더 잘할 수 있기 때문이다."고 해서 규모가 점점 커지고 있거든요. 커지면 더 좋은 서비스를 할 수 있다고 생각해서 기업으로 가고 있어요. 이처럼 생각하는 게 다른 곳과 달라서 좋아요.
미진: 규모가 커지면 망가지는 경우가 많고 안정적으로 유지되는 회사가 드문데, 안정적으로 운영되고 있는 게 인상적이에요.
제임스: 물론 커지면서 망가지는 부분도 있는데, 그 망가지는 것들에서 배워서 더 나아지자는 분위기예요.
미진: 혹시 입사해서 잘 안 맞아서 다른 팀으로 옮기는 경우도 있어요?
제임스: 네, 이동은 자유로워요. 하지만 자유롭다고 해서 맘대로 옮길 순 없어요. 만약 내가 세일즈로 가고 싶다고 해도 자리가 없으면 못 가요. 세일즈 팀에 자리가 있고 나도 가고 싶을 때 갈 수 있어요. 그렇게 옮긴 사람들도 좀 있어요.
미진: 다른 팀으로 가겠다고 하면 매니저가 잡진 않아요? 일에 구멍 날 수도 있잖아요.
제임스: 우리 회사는 개인의 만족이 더 중요하다고 생각해요. 만약 본인이 다른 일을 더 배우고 싶다고 하면 그걸 격려(encourage)해줘요. 가능하면 개인이 원하는 쪽으로 갈 수 있도록 해주려고 해요.
만약 제가 "깃허브에서 배울 거 다 배웠으니 다른 곳으로 가고 싶다." 고 말하면, 아마 "그래, 제임스. 너 그동안 열심히 했으니 더 배우고 싶은 데로 가."라고 할걸요? 막는 사람이 없을 것으로 생각해요. 물론 모든 팀이 다 같진 않겠지만요.
만약, 옮기겠다고 말한 사람이 그 팀에서 가장 핵심적인 사람이라면 매니저는 다른 팀으로 보내고 싶지 않다는 표현을 할 수는 있지만, 최종적으론 개인의 선택을 더 존중해요. 기본적으로 개인에게 중요한 게 뭐고, 팀에게 중요한 게 뭔지 매니저와 자주 커뮤니케이션하면서 서로 의견을 나눠요.
이전 회사와 깃허브의 차이점은 매니저의 역할이 다르다는 점이에요. 이전 회사에서는 매니저가 일을 주고 시키는 사람이었다면, 깃허브에서는 문제나 장애물을 치워주는 역할이거든요.
GitHub의 수익은 어디에서 나오나?
미진: 최근에 깃허브와 비슷한 서비스를 하는 경쟁자들이 많이 늘어났어요. 깃랩(GitLab)이나 빗버킷(Bitbucket) 같은 회사들이요. 신경 쓰이지 않아요?
제임스: 경쟁자를 신경 쓰기 시작하면 우리가 해야 하는 핵심적인 일에 집중을 못 하는 것 같아요.
깃허브가 다른 회사에 비해 차별점을 가지는 부분이 바로 스케일링이에요. 깃랩은 사용자가 100명 넘어가면 느려지는데 깃허브는 그렇지 않아요. 그래서 우리는 주로 엔터프라이즈에서 돈을 벌어요.
그리고 다른 예로, 깃허브는 오픈소스 커뮤니티 지원을 많이 해요.
학생들에겐 무제한으로 개인 저장소(private repository)를 무료로 주고, 소프트웨어 도구까지도 무료로 주는 GitHub Education 프로그램을 운영하기도 해요.
학교에서 선생님이나 교수들이 학생들 가르칠 때 사용하는 프로그램도 제공하고 있어서 선생님들이 GitHub에 모여 자발적으로 커뮤니케이션이 일어나죠. 이렇게 생태계를 만드는 다양한 프로그램들이 자유롭게 운영되고 있어요.
GitHub에서 디자이너로 살아가기
미진: 오! 여긴 정말 디자이너가 있는 층 같아요. 드디어 제임스님이 일하는 걸 볼 수 있는 곳이군요!!
제임스: 우리 회사는 디자이너를 좋아하는 회사예요. 오피스에 art를 많이 녹여내려고 해요. 여기 붙어있는 그림들은 예전에 어떤 직원 어머니가 유치원 선생님 하시면서 아이들과 스케치했던 것들이에요.
제임스: 여긴 애니메이션 스튜디오예요. 제가 일하는 곳이죠.
미진: 깃허브에서 애니메이션을 만드는 줄 몰랐어요, 어떤 애니메이션을 만들어요?
제임스: 깃허브 유투브(GitHub Youtube)에 가보시면 애니메이션이 두 개 있어요. 하나는 아마존웹서비스(AWS: Amazon Web Service)에 깃허브 엔터프라이즈(GitHub Enterprise)를 런칭할 때 만든 젯팩(jetpack)이고, 일주일에 한 번씩 진행되는 유니버스 컨퍼런스(Universe conference) 할 때 띄우는 애니메이션이에요.
제임스: 제가 일하는 방에는 애니메이션 작업하는 사람들이 모여있고, 이쪽은 필름/비디오 작업하는 분들이 주로 이용하세요. 저흰 리모트가 워낙 많으니 작업물을 레코딩 해서 올려두고 커뮤니케이션하려고 만들어둔 공간이에요. 인터넷 마케팅 비디오 같은 것들도 많이 찍어요.
미진: 깃허브에서 디자이너로서 일하는 방식을 소개해주실 수 있어요? 아이디어를 내서 디자인하고, 그걸 최종 의사결정 받는 단계까지요. 디자인할 때 처음부터 컴퓨터에서 프로그램을 써서 그림을 예쁘게 만드는 작업보다는 종이에 스케치를 먼저 할 텐데, 깃허브에서는 어떻게 하는지 궁금해요.
제임스: 제품에 따라서 다르고, 디자이너 역할마다 좀 달라요.
깃허브에서 디자이너는 세 타입으로 분류할 수 있는데, 첫 번째는 UI/UX 하는 사람, 두 번째는 옥토캣 그리는 애니메이터, 마지막이 저처럼 방향성을 제시하는(physical direction) 마케팅 디자이너예요.
저는 보통 스케치북에 브레인스톰(brainstorm) 하면서 적고, 스케치하다가 컴퓨터로 옮겨서 디지털화해요. 다른 분들은 와콤(wacom) 태블릿에 그려서 작업하기도 하고, UI/UX는 아이패드에 스케치해서 UI 안을 만들기도 해요. 팀마다, 하는 일에 따라서 방법도 사용하는 프로그램도 달라요.
제임스: 저는 보통 처음 시작할 때 종이에 브레인스톰을 하기도 하고, 각각의 아이디어를 스케치하다가 맘에 드는 것은 스마트폰으로 찍어서 컴퓨터로 옮기고, 툴로 그려서 보여줘요.
현재는 제 롤이 좀 바뀌어서 다른 디자이너를 감독(oversee) 하는 역할도 하게 됐어요. 다른 디자이너들에게 피드백 주는 역할을 더 하게 돼서 최근엔 그 일에 시간을 많이 할애하고 있어요.
미진: 그럼 작업물을 윗사람에게 보여줄 때 그 사람들은 피드백을 어떤 식으로 줘요? 제 경험을 예로 들면, 저는 각 장면이 넘어가는 것을 시나리오 문서로 만드는데, 실제 제품은 인터랙션이 있는 것이라 윗사람은 동작성을 보여달라고 하시거든요. 시나리오 의사결정을 위해서 문서 말고 움직이는 걸 가져오라고 하시니까 시나리오가 완성되지 않은 채로 개발자가 투입돼서 화면으로 만들어서 보여주면 그때부터 고치는 작업을 해요.
제임스: 그런 피드백은 많은 회사의 문제점이긴 해요. 그래서 깃허브에서는 그런 문제를 줄이려고 피드백을 가능한 빨리, 자주 하려고 합니다. 개발이 많이 진행된 다음에 피드백을 주면 고치기도 힘들잖아요. 그래서 아까 같은 상황에서는 스토리보드에 아이디어를 네다섯 가지 보여주고, 각각에 찬성/반대(thumbs up/down) 투표를 해요. 그리고 부족하다고 반대가 나온 내용은 보완하고요. 이게 저희 프로세스예요.
깃허브에서 디자인은 '그냥 이쁘게 하기 위한' 것이 아니고 문제 해결(problem solving) 도구예요. 그래서 피드백을 달라고 할 땐 "이 디자인은 어떤 문제를 해결하는 디자인이다. 그러니 그 부분에 대한 피드백을 달라"고 요구합니다.
미진: 그럼 윗사람에게 이 디자인은 어떤 목적을 해결하기 위한 디자인이고, 어떤 의도와 어떤 철학을 담고 있는지를 잘 커뮤니케이션한다는 거죠?
제임스: 그렇죠. 하지만 모든 사람이 전문가가 아니니까 그 말을 다 알아듣긴 힘들어요. 그렇다고 해서 모두가 이해하기 쉽게 프로토타입을 만들어 주기보다는 ‘어떤 문제가 있었고, 그걸 어떻게 해결했다’고 오픈 커뮤니케이션을 주로 해요.
미진: 아이디어를 구체화하다 보면 다른 의견이 나올 수도 있을 텐데, 그럴 땐 어떻게 해요?
제임스: 만약 두 사람이 동의 못 하고 논쟁(argue)이 생기면 매니저가 와서 결정을 해주는 시스템도 있어요. 하지만 모두 동의할 때까지 의견이 왔다 갔다 하면 배포(shipping)를 못하니깐, 기본적으로 배포를 빨리 해보고 변경하는 것(make change after)을 권장하죠.
만약 프로토타입이 있으면 다른 사람이 동의할 때까지 안 하는 게 아니고, 일단 빨리 만들고 보여줘서 예스(yes)와 노(no)를 결정할 수 있게 해요. 물론 프로젝트가 많아서 다 다르긴 하지만요.
미진: 빨리 배포하자고 하면, 그다음에 바로 따라 나오는 얘기가 품질(quality)이잖아요. 품질이 떨어지는 것을 업데이트하면 사용자의 만족도가 떨어진다고요.
제임스: 맞아요. 그런 얘기가 나오죠. 하지만 아무거나 배포하지는 않고, 1.0 버전을 좋게 만들어지길 기다려요. 그 기능의 가장 메인이 되는 것을 골라 1.0 버전으로 만들고, 깃허브를 잘 쓰는 작은 규모의 집단(small audience)에게 먼저 보내서 '사용하고 피드백을 달라'고 해요. 그 피드백을 바탕으로 좀 더 고도화해서 2.0과 3.0 버전이 나오면 더 큰 집단(bigger audience)에게 오픈해요. 이렇게 차츰 사용자 범위를 늘려서 배포하는 방법을 써요. A/B 테스트(버전 A와 다른 버전 B를 비교하여 테스트하는 방법)하듯이요.
원래 미팅을 잡았던 날은 5월 16일 월요일 2시였다. 30분 정도 일찍 도착해서 한 시 반부터 두 시간가량 회사를 둘러보고, 깃허브에서 디자이너로 사는 삶과 일하는 문화에 대한 이야기를 많이 들을 수 있었다.
헤어질 무렵엔 깃허브의 분위기를 좀 더 느껴보라며 다음날 점심에 다시 초대해주셨다. 그리하여 이튿날엔 사내에서 식사하며 깃허브의 다른 구성원들의 분위기도 느낄 수 있었다.
세계 각국의 개발자뿐만 아니라 다양한 일을 하는 많은 사람이 협업할 수 있는 에코 시스템을 만드는 데 기여하고 있는 깃허브. 하루빨리 한국에도 오피스가 생겨서 성장하는 모습을 더 가까이서 볼 수 있었으면 하는 마음을 안고 깃허브 오피스를 나섰다.
언제 어디서든 근무할 수 있는 환경과 문화가 정착된 깃허브에 대하여, 그리고 개발회사에서 디자이너로 산다는 게 어떤 것인지, 한국의 개발자를 포함한 직장인들의 궁금증이 풀리고 더 나아가 각자의 업무 환경을 되돌아보는 기회가 됐으면 한다.
무엇보다 인터뷰에 흔쾌히 응해주시고 솔직한 이야기를 들려준 제임스 님께 감사의 말을 전한다.