Facebook의 개발 문화와 국내 SW 개발 문화
페이스북의 개발 문화가 외부인의 블로그를 통해 일부 알려졌다.
구글에서 많은 인재들이 빠져나와 대부분 페이스북으로 옮겨갔고, 주된 동기가 더 많은 연봉이 아니라 더 나은 성취감이었다고 알려져, 빠르게 빌드하고 새로운 도전을 끊임없이 하는 인재들을 어떻게 관리하는지가 궁금하던 차였는데, 블로그의 내용은 기대를 저버리지 않고 꽤나 독특한 (예상치 못한) 그들의 문화를 보여준다.
원 블로그는 다음에서 읽을 수 있다.
번역하기보다는 관심 있게 본 부분만 일부 요약하면 다음과 같다.
페이스북의 기업 문화는 철저하게 엔지니어 중심 문화이다. 이것은 주커버그도 심지어 회계 담당자도 프로그래머를 뽑은 적이 있으며 분석하고 새로운 것을 빠르게 빌딩하는 문화에 익숙하지 않으면 페이스북에서는 어떤 역할도 맡기 어려움을 내포하고 있다.
페이스북의 문화는 매우 tight하면서도 목적 중심적이고 엄격한 책임이 따르는 독특한 엔지니어 중심 문화이다.
1. 개발 과정에서 Product Manager의 권한은 미약하고, 오히려 개발자들이 자기 프로젝트에 관심을 가지도록 하기 위해 개발자들을 설득, 로비하는 일이 잦다.
2. 모든 엔지니어는 입사 후 4주~6주 과정의 부트 캠프를 거친다. 부트 캠프에서 페이스북 시스템의 버그를 직접 수정하면서 배우고, 시니어 엔지니어들의 강의를 듣는다. 약 10% 정도의 엔지니어들이 이 과정을 완료하지 못하며 이 경우 권고 사직 대상이 된다.
3. 엔지니어는 백엔드부터 프론트엔드까지 보통 혼자서 다 구현을 한다. 클라이언트, UI 일은 기술적 난이도가 낮고 반복이 많아 엔지니어들이 기피한다. 뉴스피드나 광고 알고리즘, memcache 최적화 등 백엔드 구현을 선호한다.
3. 모든 변경된 코드는 의무적으로 내부 리뷰를 거친다. 주커버그는 뉴스피드 관련 코드는 직접 리뷰를 한다. 최소 1명 이상의 리뷰를 거치지 않은 코드를 릴리스해서는 안된다.
4. 페이스북에는 전문 QA가 없다. 모든 개발자가 테스트, 버그 수정, 유지보수까지 자기 코드에 대해 책임진다. 내부 개발자가 사용해보는 테스트는 있다. 서비스 런칭을 위해 거쳐야 하는 자동화된 테스트도 있다. 하지만 기본적으로는 개발자가 UI 구현부터 테스트까지 모두 책임을 지는 구조이다.
"대부분의 엔지니어들은 버그 없는 코드를 작성할 줄 안다"는 믿음도 일부 있는 분위기.
5. 매주 화요일 릴리스하며 그 주중에 릴리스 대상 코드를 커밋한 개발자는 릴리스 시작 시 on-site(특정 IRC 채널)에서 대기해야 한다. 그렇지 않으면 공개 창피당한다. 9레벨 릴리스 중 문제가 생기면 개발자가 수정 후 1레벨부터 다시 시작한다.
6. SVN을 통해 혼나거나 프로젝트를 자주 지연시킨 엔지니어는 해고된다.(매우 뛰어난 퍼포먼스만 허용. 보통 채용 6개월 이내에 해고)
버그나 사이트 다운, 실수 등의 문제로 혼난다고 해서 해고되지는 않는다. 다만 이런 공개 창피를 통해 이슈를 해결하기 위해 매우 열중하며 이 과정에서 모두가 함께 배운다.
페이스북은 분명히 퍼포먼스에 강하게 바이어스된 조직이다. 그리고 가차없는 미국의 노동 유연성은 우리에겐 좀 충격으로 다가오는 부분이다. 넷플릭스도 이와 유사한 형태의 조직 문화를 갖고 있었다.
페이스북 엔지니어는 마치 1인 개발 회사처럼 움직인다. 일도 직접 선택하고, 전 과정에 걸쳐 직접 모든 걸 해야 한다. 개발자들이 내부 테스트에 함께 참가하는 QA 절차 외에 전담 QA 조직이 없다는 것도 상당한 놀라움이다. 물론 릴리스 과정에서 OPS 팀이 엄격하게 체크하고, 또 사전에 코드 리뷰 과정을 통해 체크한다고 하지만, 수억명의 가입자를 가진 서비스 기업에서 공식 QA 과정이 없다니 놀라울 뿐이다.
테스트와 QA
이 부분에 대해서 페이스북은 엔지니어가 QA에게 코드를 던져주는 무책임함을 없애기 위함이라고 한다.
많은 한국의 개발자들에겐 생경하게 들리겠지만, 코드의 버그를 줄이는 가장 최고의 효율적인 방법은 코딩할 때 매우 집중도를 높여 버그 없는 코드를 작성하는 것이다.
버그와 이슈들은 예방이 최선이며, 검출 또한 이르면 이를수록 빠르게 대응할 수 있다. 능력있는 엔지니어가 고도의 집중력을 발휘하여 버그 없는 코드를 작성할 수 있다는 일부 페이스북 엔지니어들의 믿음도 이런 측면에서는 설득력이 있다.
하지만, 개인적으로는 테스트 코드를 통해 검증하는 길이 안전하다고 믿는다. 예외 케이스에 대한 설계 등의 이슈도 상존한다. 대부분 glass-box test를 통해 엔지니어 수준에서 테스트 검증이 완료된다면 QA의 black-box test 필요성은 급속하게 줄어든다.
엔지니어가 예외 케이스를 충분히 고려하고 테스트를 한다면 black box test를 해야 하는 QA보다 더 나은 테스트와 결과를 얻을 수 있는 것도 사실이다. QA와 분화된 조직에서 대부분의 엔지니어들은 이러한 테스트의 책임을 QA에게 떠넘기고 있다. 하지만 QA는 내부 구조를 모르기 때문에 예외 케이스에 대한 테스트 설계도 익숙할 수 없다.
많은 국내 개발자들은 코딩이 초벌 끝나고 빌드가 되면 개발이 끝났다고 생각하고 QA에게 토스한다. 코드의 완성도를 높이기 위해 고민해야 할 당사자는 QA가 아니라 개발자이다. 따라서 그러한 역할 분담은 맞지 않다. QA는 개발자들이 완벽하게 만들었다고 판단한 코드에 대해 미비한 부분을 찾는 역할을 해야 한다. 그조차도 개발자들이 한번 더 검토해야 한다면 페이스북처럼 별도 QA를 두지 않는 것도 또하나의 방법일 것이다.
극단적으로 능동적인 엔지니어
페이스북은 주별로 자신이 해야 할 일들을 선택하고 스스로 스케줄하며 모든 관리 책임이 기본적으로 자신에게 있는 관리 문화이다. 주 단위로 진척을 소설로 작성하여 보고하며 매주 일정 단축의 압박과 근무 시간 감시에 노출되어 있는 많은 국내 개발자들과 비교했을 때 어느쪽이 더 생산성이 높을까?
페이스북은 탁월하지 않으면 매우 견디기 힘든 조직이다. 뒤처지는 엔지니어는 뽑지도 않지만 평범한 엔지니어도 바로 도태되는 구조이다. 뛰어나고 일에 도전하기 좋아하는 엔지니어에게는 매우 흡족한 직장이겠지만. 국내 개발자들은 자기 관리를 자기 스스로 할 수 없는 외부의 업무 외 압박 스트레스와 싸우면서 대부분 단순 노동자화되어 있다. 물론 우수한 사람은 어느 조직에서든 자신의 기량을 어느 정도는 발휘하겠지만, 상대적으로 성취 기회는 적을 수밖에 없다.
외부에서 보기에 신의 직장이라고 부르던 곳이 페이스북이 맞는지 모르겠다. 평이한 결과를 내는 엔지니어에겐 지옥일 수도 있겠다. 다만 관리 형태로 보자면 페이스북은 기본은 자율에 기반한 능동적 업무 모델이지만, 평가는 관리자가 각 개인의 기술적 성취와 성과에 대해 세세히 알고 있어야 가능한 양과 질에 걸친 퍼포먼스 중심의 평가 모델이다. 국내의 많은 소프트웨어 기업들은 평가가 지극히 평이하며 객관적 기준으로 근무 시간을 참고한다. 업적 평가를 질적으로 판단하지 못하기 때문에 눈에 보이는 수치인 시간에 자꾸 눈을 돌리게 되는 것이다. 평가자가 기술적으로나 개발의 상태, 각 개발자들의 상태를 제대로 알고 있어야만 질적 관리가 가능하게 된다. 국내는 평가자 혹은 관리자가 관료화되고 일선에서 손놓은 사람들인 경우가 많다. 조직의 능동성이 불가능해진다.
창의와 혁신
페이스북은 창의적 혁신의 구현 기업으로 자주 언급된다. 특히 빠르게 다양한 것을 도전하는 기업으로 언급된다.
일부 사람들이 오해하고 있는 것과 달리 페이스북도 애플도 넷플릭스도 똑똑한 엔지니어들의 느슨한 창의나 혁신을 기다리는 곳이 아니다. 창의는 외부적인 요인들에 의해 집중을 저해받지 않는 환경 속에서 집중적인 사고의 과정 속에 비동기적으로 떠오른 아이디어들이 대부분이다.
창의가 휴식 속에서 떠오르는 완전히 새로운 아이디어라고 생각하는 경향이 있는데 그렇지 않다. 계속된 생각 속에서 비동기적으로 출력되는 것이며 보통 그 시점이 뇌가 잠시 쉴 때, 즉 방해받지 않을 때가 된다. 휴식이 키가 아니라 계속된 생각을 통해 입력을 잠재화하는 것이 키가 된다.
생각을 집중해서 계속하는 것이 창의의 핵심이며, 명상과 같은 메커니즘을 활용하는 것이 유용한 것도 앞에서 얘기한 데로 뇌의 결과물을 캐치하기 위한 효과적인 수단이기 때문이다. 계속된 생각의 집중에서 잠시 벗어나 뇌에 잡념(noise input이 된다)을 걷어내고 고요를 얻는 휴식을 의식적으로 가지는 것도 좋은 창의의 습관이 된다.
능동적으로 끊임없이 자신의 문제에 집중하고 생각, 또 생각하는 엔지니어들이 창의적 결실을 낼 가능성이 높다는 것이다.
흔히 창의적 혁신 기업이라 부르는 애플도 페이스북도 내부 분위기는 휴양지가 아니라 전위들의 치열한 전투 공간이다. 창의가 잡념 속에서 우연히 얻어지는 게 아니기 때문이다. 물론 페이스북과 애플은 기업 문화에 따라 창의의 성격이 조금 다른 것이 느껴진다.
애플은 디자이너, Product manager, 엔지니어가 모두 결합된 미팅에서 많은 것들이 만들어지는 구조이다. 개인적 창의와 집단적 창의가 많이 결합되는 결과물들을 준다.
페이스북은 조금 극단화된 개인 책임적인 문화 덕분에 철저한 개인적 창의 위주의 결과물들을 내는 것 같다.
두 기업의 창의적 혁신 특성에 대한 시각은 사실 미묘하고 상호 배타적이지도 않긴 하지만, 그것이 각 기업의 제품 혹은 서비스의 개성을 두드러지게 하는 요인 중 하나일 것 같다.
P.S 엔지니어 업무 시간 관리 방식
페이스북도 애플 모두 일단 프로젝트가 시작되면 매우 강하게 드라이브하는 조직임은 알려져 있다. 국내의 일방적인 일정 단축 압박과 전혀 다른 방식으로 빠른 속도의 릴리스를 드라이브하는 것이다.
사실 구글의 문화가 매우 궁금하긴 한데 개인적으로 판단할 때에는 이런 강한 드라이브는 많지 않은 느낌이다. (구글이 매우 큰 회사이므로 각 사업 영역이나 나라별로 다를 수 있을 것 같다.)
한 가지 지적하고 싶은 것은 업무 영역과 특성에 따라 엔지니어가 업무에 투입할 수 있는 시간은 좀 다르다는 것이다.
a. 복잡한 알고리즘이나 수학적 문제 해결이 필요한 영역에서는 고도의 집중과 통찰이 필요하다. 두뇌는 고도의 집중으로 사용할 수 있는 시간이 하루 중 많지 않다.
b. 경험과 패턴을 통해 익숙해져있는 개발을 할 때에도 버그 없이 완벽한 코드를 작성하기 위해 집중한다면 역시 투입할 수 있는 시간에 제약이 생긴다.
c. 단순 반복적인 코딩을 집중하지 않고 한다면 상대적으로 훨씬 많은 시간을 투입할 수 있고 효율의 차이가 크게 나지 않는다.
a 부분은 영역이 조금 다르거나, 업무의 일부분일 수도 있다. 상대적으로 구글이 a 부분의 영역에 다른 회사에 비해 많이 투입하지 않는가 싶다. (순전히 개인적으로 소설을 쓰자면 휴식 시간 제외하고 a 영역은 하루 6,7시간, b 영역은 하루 7,8시간, c 영역은 하루 10시간 정도 최대 투입할 수 있다고 생각한다.)
b와 c는 업무 모델을 어떻게 가져가느냐와 관련있는데 국내는 대부분 c로 개발자들을 내몰고 있다. 기업의 경영 판단은 해당 기업의 SW 제품 혹은 서비스가 b 모델이 맞을지 c 모델이 맞을지를 판단해야 한다. 적어도 더 나은 형질의 제품, 서비스를 만들려는 기업들은 b 모델이 맞을 것이다.
엔지니어들을 질적으로 관리할 것이냐 수동적인 단순 업무자들로 관리할 것이냐의 판단을 하고 그에 맞는 관리 체제, 관리자를 배치할 필요가 있다.
국내 오래된 SW 기업들은 대부분 c 방식을 전제로 관리하고 있는 것 같다. 반면 실리콘밸리의 혁신 기업들은 철저하게 투입 시간이 아닌 성과 위주로 관리한다.
구글에서 많은 인재들이 빠져나와 대부분 페이스북으로 옮겨갔고, 주된 동기가 더 많은 연봉이 아니라 더 나은 성취감이었다고 알려져, 빠르게 빌드하고 새로운 도전을 끊임없이 하는 인재들을 어떻게 관리하는지가 궁금하던 차였는데, 블로그의 내용은 기대를 저버리지 않고 꽤나 독특한 (예상치 못한) 그들의 문화를 보여준다.
원 블로그는 다음에서 읽을 수 있다.
http://framethink.wordpress.com/2011/01/...
I’m fascinated by the way Facebook operates. It’s a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried). These are notes gathered from talking with many friends at Facebook about how the company develops and releases software.번역하기보다는 관심 있게 본 부분만 일부 요약하면 다음과 같다.
페이스북의 기업 문화는 철저하게 엔지니어 중심 문화이다. 이것은 주커버그도 심지어 회계 담당자도 프로그래머를 뽑은 적이 있으며 분석하고 새로운 것을 빠르게 빌딩하는 문화에 익숙하지 않으면 페이스북에서는 어떤 역할도 맡기 어려움을 내포하고 있다.
페이스북의 문화는 매우 tight하면서도 목적 중심적이고 엄격한 책임이 따르는 독특한 엔지니어 중심 문화이다.
1. 개발 과정에서 Product Manager의 권한은 미약하고, 오히려 개발자들이 자기 프로젝트에 관심을 가지도록 하기 위해 개발자들을 설득, 로비하는 일이 잦다.
2. 모든 엔지니어는 입사 후 4주~6주 과정의 부트 캠프를 거친다. 부트 캠프에서 페이스북 시스템의 버그를 직접 수정하면서 배우고, 시니어 엔지니어들의 강의를 듣는다. 약 10% 정도의 엔지니어들이 이 과정을 완료하지 못하며 이 경우 권고 사직 대상이 된다.
3. 엔지니어는 백엔드부터 프론트엔드까지 보통 혼자서 다 구현을 한다. 클라이언트, UI 일은 기술적 난이도가 낮고 반복이 많아 엔지니어들이 기피한다. 뉴스피드나 광고 알고리즘, memcache 최적화 등 백엔드 구현을 선호한다.
3. 모든 변경된 코드는 의무적으로 내부 리뷰를 거친다. 주커버그는 뉴스피드 관련 코드는 직접 리뷰를 한다. 최소 1명 이상의 리뷰를 거치지 않은 코드를 릴리스해서는 안된다.
4. 페이스북에는 전문 QA가 없다. 모든 개발자가 테스트, 버그 수정, 유지보수까지 자기 코드에 대해 책임진다. 내부 개발자가 사용해보는 테스트는 있다. 서비스 런칭을 위해 거쳐야 하는 자동화된 테스트도 있다. 하지만 기본적으로는 개발자가 UI 구현부터 테스트까지 모두 책임을 지는 구조이다.
"대부분의 엔지니어들은 버그 없는 코드를 작성할 줄 안다"는 믿음도 일부 있는 분위기.
5. 매주 화요일 릴리스하며 그 주중에 릴리스 대상 코드를 커밋한 개발자는 릴리스 시작 시 on-site(특정 IRC 채널)에서 대기해야 한다. 그렇지 않으면 공개 창피당한다. 9레벨 릴리스 중 문제가 생기면 개발자가 수정 후 1레벨부터 다시 시작한다.
6. SVN을 통해 혼나거나 프로젝트를 자주 지연시킨 엔지니어는 해고된다.(매우 뛰어난 퍼포먼스만 허용. 보통 채용 6개월 이내에 해고)
버그나 사이트 다운, 실수 등의 문제로 혼난다고 해서 해고되지는 않는다. 다만 이런 공개 창피를 통해 이슈를 해결하기 위해 매우 열중하며 이 과정에서 모두가 함께 배운다.
페이스북은 분명히 퍼포먼스에 강하게 바이어스된 조직이다. 그리고 가차없는 미국의 노동 유연성은 우리에겐 좀 충격으로 다가오는 부분이다. 넷플릭스도 이와 유사한 형태의 조직 문화를 갖고 있었다.
페이스북 엔지니어는 마치 1인 개발 회사처럼 움직인다. 일도 직접 선택하고, 전 과정에 걸쳐 직접 모든 걸 해야 한다. 개발자들이 내부 테스트에 함께 참가하는 QA 절차 외에 전담 QA 조직이 없다는 것도 상당한 놀라움이다. 물론 릴리스 과정에서 OPS 팀이 엄격하게 체크하고, 또 사전에 코드 리뷰 과정을 통해 체크한다고 하지만, 수억명의 가입자를 가진 서비스 기업에서 공식 QA 과정이 없다니 놀라울 뿐이다.
테스트와 QA
이 부분에 대해서 페이스북은 엔지니어가 QA에게 코드를 던져주는 무책임함을 없애기 위함이라고 한다.
많은 한국의 개발자들에겐 생경하게 들리겠지만, 코드의 버그를 줄이는 가장 최고의 효율적인 방법은 코딩할 때 매우 집중도를 높여 버그 없는 코드를 작성하는 것이다.
버그와 이슈들은 예방이 최선이며, 검출 또한 이르면 이를수록 빠르게 대응할 수 있다. 능력있는 엔지니어가 고도의 집중력을 발휘하여 버그 없는 코드를 작성할 수 있다는 일부 페이스북 엔지니어들의 믿음도 이런 측면에서는 설득력이 있다.
하지만, 개인적으로는 테스트 코드를 통해 검증하는 길이 안전하다고 믿는다. 예외 케이스에 대한 설계 등의 이슈도 상존한다. 대부분 glass-box test를 통해 엔지니어 수준에서 테스트 검증이 완료된다면 QA의 black-box test 필요성은 급속하게 줄어든다.
엔지니어가 예외 케이스를 충분히 고려하고 테스트를 한다면 black box test를 해야 하는 QA보다 더 나은 테스트와 결과를 얻을 수 있는 것도 사실이다. QA와 분화된 조직에서 대부분의 엔지니어들은 이러한 테스트의 책임을 QA에게 떠넘기고 있다. 하지만 QA는 내부 구조를 모르기 때문에 예외 케이스에 대한 테스트 설계도 익숙할 수 없다.
많은 국내 개발자들은 코딩이 초벌 끝나고 빌드가 되면 개발이 끝났다고 생각하고 QA에게 토스한다. 코드의 완성도를 높이기 위해 고민해야 할 당사자는 QA가 아니라 개발자이다. 따라서 그러한 역할 분담은 맞지 않다. QA는 개발자들이 완벽하게 만들었다고 판단한 코드에 대해 미비한 부분을 찾는 역할을 해야 한다. 그조차도 개발자들이 한번 더 검토해야 한다면 페이스북처럼 별도 QA를 두지 않는 것도 또하나의 방법일 것이다.
극단적으로 능동적인 엔지니어
페이스북은 주별로 자신이 해야 할 일들을 선택하고 스스로 스케줄하며 모든 관리 책임이 기본적으로 자신에게 있는 관리 문화이다. 주 단위로 진척을 소설로 작성하여 보고하며 매주 일정 단축의 압박과 근무 시간 감시에 노출되어 있는 많은 국내 개발자들과 비교했을 때 어느쪽이 더 생산성이 높을까?
페이스북은 탁월하지 않으면 매우 견디기 힘든 조직이다. 뒤처지는 엔지니어는 뽑지도 않지만 평범한 엔지니어도 바로 도태되는 구조이다. 뛰어나고 일에 도전하기 좋아하는 엔지니어에게는 매우 흡족한 직장이겠지만. 국내 개발자들은 자기 관리를 자기 스스로 할 수 없는 외부의 업무 외 압박 스트레스와 싸우면서 대부분 단순 노동자화되어 있다. 물론 우수한 사람은 어느 조직에서든 자신의 기량을 어느 정도는 발휘하겠지만, 상대적으로 성취 기회는 적을 수밖에 없다.
외부에서 보기에 신의 직장이라고 부르던 곳이 페이스북이 맞는지 모르겠다. 평이한 결과를 내는 엔지니어에겐 지옥일 수도 있겠다. 다만 관리 형태로 보자면 페이스북은 기본은 자율에 기반한 능동적 업무 모델이지만, 평가는 관리자가 각 개인의 기술적 성취와 성과에 대해 세세히 알고 있어야 가능한 양과 질에 걸친 퍼포먼스 중심의 평가 모델이다. 국내의 많은 소프트웨어 기업들은 평가가 지극히 평이하며 객관적 기준으로 근무 시간을 참고한다. 업적 평가를 질적으로 판단하지 못하기 때문에 눈에 보이는 수치인 시간에 자꾸 눈을 돌리게 되는 것이다. 평가자가 기술적으로나 개발의 상태, 각 개발자들의 상태를 제대로 알고 있어야만 질적 관리가 가능하게 된다. 국내는 평가자 혹은 관리자가 관료화되고 일선에서 손놓은 사람들인 경우가 많다. 조직의 능동성이 불가능해진다.
창의와 혁신
페이스북은 창의적 혁신의 구현 기업으로 자주 언급된다. 특히 빠르게 다양한 것을 도전하는 기업으로 언급된다.
일부 사람들이 오해하고 있는 것과 달리 페이스북도 애플도 넷플릭스도 똑똑한 엔지니어들의 느슨한 창의나 혁신을 기다리는 곳이 아니다. 창의는 외부적인 요인들에 의해 집중을 저해받지 않는 환경 속에서 집중적인 사고의 과정 속에 비동기적으로 떠오른 아이디어들이 대부분이다.
창의가 휴식 속에서 떠오르는 완전히 새로운 아이디어라고 생각하는 경향이 있는데 그렇지 않다. 계속된 생각 속에서 비동기적으로 출력되는 것이며 보통 그 시점이 뇌가 잠시 쉴 때, 즉 방해받지 않을 때가 된다. 휴식이 키가 아니라 계속된 생각을 통해 입력을 잠재화하는 것이 키가 된다.
생각을 집중해서 계속하는 것이 창의의 핵심이며, 명상과 같은 메커니즘을 활용하는 것이 유용한 것도 앞에서 얘기한 데로 뇌의 결과물을 캐치하기 위한 효과적인 수단이기 때문이다. 계속된 생각의 집중에서 잠시 벗어나 뇌에 잡념(noise input이 된다)을 걷어내고 고요를 얻는 휴식을 의식적으로 가지는 것도 좋은 창의의 습관이 된다.
능동적으로 끊임없이 자신의 문제에 집중하고 생각, 또 생각하는 엔지니어들이 창의적 결실을 낼 가능성이 높다는 것이다.
흔히 창의적 혁신 기업이라 부르는 애플도 페이스북도 내부 분위기는 휴양지가 아니라 전위들의 치열한 전투 공간이다. 창의가 잡념 속에서 우연히 얻어지는 게 아니기 때문이다. 물론 페이스북과 애플은 기업 문화에 따라 창의의 성격이 조금 다른 것이 느껴진다.
애플은 디자이너, Product manager, 엔지니어가 모두 결합된 미팅에서 많은 것들이 만들어지는 구조이다. 개인적 창의와 집단적 창의가 많이 결합되는 결과물들을 준다.
페이스북은 조금 극단화된 개인 책임적인 문화 덕분에 철저한 개인적 창의 위주의 결과물들을 내는 것 같다.
두 기업의 창의적 혁신 특성에 대한 시각은 사실 미묘하고 상호 배타적이지도 않긴 하지만, 그것이 각 기업의 제품 혹은 서비스의 개성을 두드러지게 하는 요인 중 하나일 것 같다.
P.S 엔지니어 업무 시간 관리 방식
페이스북도 애플 모두 일단 프로젝트가 시작되면 매우 강하게 드라이브하는 조직임은 알려져 있다. 국내의 일방적인 일정 단축 압박과 전혀 다른 방식으로 빠른 속도의 릴리스를 드라이브하는 것이다.
사실 구글의 문화가 매우 궁금하긴 한데 개인적으로 판단할 때에는 이런 강한 드라이브는 많지 않은 느낌이다. (구글이 매우 큰 회사이므로 각 사업 영역이나 나라별로 다를 수 있을 것 같다.)
한 가지 지적하고 싶은 것은 업무 영역과 특성에 따라 엔지니어가 업무에 투입할 수 있는 시간은 좀 다르다는 것이다.
a. 복잡한 알고리즘이나 수학적 문제 해결이 필요한 영역에서는 고도의 집중과 통찰이 필요하다. 두뇌는 고도의 집중으로 사용할 수 있는 시간이 하루 중 많지 않다.
b. 경험과 패턴을 통해 익숙해져있는 개발을 할 때에도 버그 없이 완벽한 코드를 작성하기 위해 집중한다면 역시 투입할 수 있는 시간에 제약이 생긴다.
c. 단순 반복적인 코딩을 집중하지 않고 한다면 상대적으로 훨씬 많은 시간을 투입할 수 있고 효율의 차이가 크게 나지 않는다.
a 부분은 영역이 조금 다르거나, 업무의 일부분일 수도 있다. 상대적으로 구글이 a 부분의 영역에 다른 회사에 비해 많이 투입하지 않는가 싶다. (순전히 개인적으로 소설을 쓰자면 휴식 시간 제외하고 a 영역은 하루 6,7시간, b 영역은 하루 7,8시간, c 영역은 하루 10시간 정도 최대 투입할 수 있다고 생각한다.)
b와 c는 업무 모델을 어떻게 가져가느냐와 관련있는데 국내는 대부분 c로 개발자들을 내몰고 있다. 기업의 경영 판단은 해당 기업의 SW 제품 혹은 서비스가 b 모델이 맞을지 c 모델이 맞을지를 판단해야 한다. 적어도 더 나은 형질의 제품, 서비스를 만들려는 기업들은 b 모델이 맞을 것이다.
엔지니어들을 질적으로 관리할 것이냐 수동적인 단순 업무자들로 관리할 것이냐의 판단을 하고 그에 맞는 관리 체제, 관리자를 배치할 필요가 있다.
국내 오래된 SW 기업들은 대부분 c 방식을 전제로 관리하고 있는 것 같다. 반면 실리콘밸리의 혁신 기업들은 철저하게 투입 시간이 아닌 성과 위주로 관리한다.
댓글
소프트웨어 엔지니어로서의 역량이나 태도에 대해 많은 것을 느끼는 바입니다. 후아....
저들처럼 치열하거나 노련해질 수 없겠지만, 저는 저대로 영역을 확고히 다질 수 있도록 노력해야겠습니다. ^^
C 개발문화에 살고 있지만 B정도 되는 사람이고 싶습니다.
다시한번 자극이 되는 내용이 되었네요..
덕분에 페이스북 개발 문화도 얻고, 소프트웨어 개발 방법에 관해서 다시한번 생각하게끔 하네요.
저도 개발을 하지만 작성된 코드에 대한 기본적인 테스트 이외의 부분은 QA의 몫이라고 여기고 있었습니다.
페이스북의 개발문화를 가진 기업을 만들고 싶습니다.
글 잘 보고 갑니다.