김상훈 기자님이 쓰신 글, <카카오와 페이스북이 지루함과 싸우는 법>을 통해 “혁신 주도형 조직”에 대한 멋진 두 개발회사의 사례를 보며 고민고민열매 (..)
부분 인용하자면:
카카오는 물론이고 요즘 잘 나가는 첨단 기술 기업들은 모두 직원들의 지루함과 싸운다. 페이스북과 구글 같은 기업들도 직원들을 지루하게 만들지 않기 위해 ‘해커톤’을 통해 새로운 제품 아이디어를 찾는다. 팀은 최소화한다. 10명 이상의 팀 같은 건 죄악으로 여겨진다. 팀원은 늘 손가락으로 셀 수 있어야 한다. 그렇게 작은 팀이어야 자기 스스로 컨트롤한다는 느낌을 가질 수 있기 때문이다. “위에서 시켰다”는 이유로 큰 팀에서 수직적 의사결정 구조 속에 일하는 건 스스로를 세계 최고의 천재라고 믿는 이런 사람들에게는 포로수용소에서 강제 노역에 동원된 느낌을 갖게 할 수밖에 없다.
지루한 단순 반복 업무가 이들에게도 있지 않겠느냐고 되물을 수 있다. 페이스북에선 “자동화될 수 없는 단순반복작업은 없다”고 주장한다. 그리고 엔지니어들의 과제는 크게 두 가지다.
1. 스스로 정말 하고 싶은 일을 하기,
2. 스스로 하기 싫은 일은 기계가 하도록 만들기.
두 가지 가운데 하나라도 못하면 회사를 떠나야 한다. 그러니까 하고 싶은 일을 맘껏 할 수 있다는 것은 하기 싫은 일을 자동화시킬 수 있을만큼 똑똑해야 한다는 뜻이기도 하다. 그리고 하기 싫은 일을 그냥 좋은 마음으로 기꺼이 받아들이는 식으로도 살아남을 수 없다. 객관적으로 지루한 일은 주관을 바꿔 순응할 게 아니라 객관적 기술로 해결해야만 한다.
이 글을 읽고 난 뒤에 생각난 이야기 두 개.
1. 구글이 사내 보안 문제에 접근하는 방법:
시스템관리, 특히 사내 보안쪽을 담당해보신 분들과 사내 보안의 문제에 대해서 대화를 나눠보면 보안망이 뚫려서 정보를 털리는 ‘외부요인’에 의한 해킹보다, 내부 직원의 부주의로 일어나는 ‘소셜 해킹’의 빈번도와 위험성이 훨씬 크다는 얘기를 종종 듣는다.
아마 구글도 당연히 비슷한 문제를 고민했을 것 같다. 갑작스레 커지는 기업, 그리고 보안처리해야 하는 데이터들. 여기서 구글러들은 본인들만의 방법으로 문제에 접근한다. 이름하여 ‘얼음/땡’ 놀이:
누구든 사무실에서 이동을 하다가 화면잠금(screen-lock)이 걸려있지 않은 동료 PC를 발견하면, 그 자리에서 PC를 잠궈버릴 수 있는 인트라 페이지를 띄운다. 그리곤 몰래 도망간다. /긔엽긔/ 자리에 돌아온 PC주인은 망신을 당하며 관리자 액세스를 받아 PC를 풀어야 하고, 심지어 가장 많은 ‘얼음’을 당한 구글러들은 랭킹보드에 올라가는 ‘명예‘를 얻는다고.
0
2. 페이스북이 웹사이트 번역 문제에 접근하는 방법:
우리 Zoyi 팀에서 페이스북을 방문했던 당시, i18n(internationalization:서비스 국제화) 관련 질문을 했었다. 당시 우리 회사는 일본에 진출을 하는 문제를 갖고 있었는데, 인력 1명을 손 떨며 힘들게 뽑던 스타트업이자 동시에 여러국가로 빠르게 진출하고 싶었던 욕심많은 스타트업에게는 i18n이 항상 고민이었다. 우리 고민을 끝까지 들은 페이스북 개발자 D모 군은 말 없이 자신의 화면을 가리키며 페이스북이 어떻게 i18n 문제를 해결하는지 보여주었는데: 관련 글 참조(영어)
그 화면에는 영어로된 페북 페이지와 함께, 각 문장 옆에 언어별로 사용자들의 입력을 받을 수 있는 기능과 Voting에 의해 번역 퀄리티를 정할 수 있는 번역 플랫폼이 구현되어있었다. 그리곤 이렇게 말했다.
“우린 언어별로 i18n 스페셜리스트를 고용하는 대신, i18n에 관심있는 개발자 2명을 투입해서 플랫폼을 만들었습니다. 이게 페이스북이 i18n 문제를 해결하는 방법입니다. 우린 이게 스마트하게 개발하는 방법이라고 믿습니다.”
0
두 회사의 문제 접근 방법을 관통하는 원칙은 간단하다:
사람의 일은 사람에게, 기계의 일은 기계에게.
(단, 사람은 기계에게 일을 시킬 줄 알아야하며, 스스로의 일을 만들 수 있어야 한다는 대전제)
어떻게 보면 너무 당연하고, 이성적인 얘기인데 왜 못하고 있을까? 왜 우리는 항상 자동화 시켜야 할 문제를 사람으로 때우고 있으며, 설계적 결함을 노가다성 코드로 채우게 되는 걸까? 우린 왜 스마트한 사람이면서도 스마트하게 일하지 않는 걸까? 그 뒤로 쉬지 않고 고민했던 문제다. 어떻게 하면 작은 규모의 (20명 미만) 스타트업 환경에서도 이런 철학을 가지고 문제에 접근 할 수 있을까?
사실 답이 존재하지 않는 문제인 듯 하다. 어떻게 개발 회사답게 문제에 접근한다는 건가.
생각해보면 삽질 속에 효과를 보게된/보고있는 지침들이 있었다. 지침인지 현상인지 구분 조차 애매한 모습들.
정리해본다면 다음과 같다:
0
문제를 재정의 하기
문제를 발견했다면, 냅다 달려들어서 풀 생각부터 하는 것이 공돌이들의 습관이라지만 스마트하게 접근하기 위해서는 오히려 먼저 문제 자체를 재정의 하는데 투자 할 필요가 있다. 무엇이 문제인가? 누구의 문제인가? 진짜 문제인것 맞나?
사실 말이야 쉽지, 많은 ‘습’을 필요로 하는 방법인 것 같다. 위 질문 셋을 반복해서 떠올렸을 때 도움을 얻을 수 있었다.
0
품질을 정량화 시키기
뻔하지만 투자하지 않는 부분 = 높은 품질의 코드 > 유지보수 불필요 > 재밌는 일을 찾아서 할 수 있는 행복한 개발자(?)
품질 정량화라해서 스타트업 입장에서 (TDD같은)부담스럽고, 거창한 것이 아니라 작은 디테일을 정량화 시키고, 끊임없이 피드백을 주어야 품질을 위한 노력들이 지속된다는 것을 배웠다. 커밋 컨벤션에 대한 체크라던지, 코드 리뷰 시 살벌한 Verify 라던지, 심지어 해결된 버그에 대한 내/외적 인정 하나 하나가 전체 서비스를 내가 만들어간다라는 주인의식과 함께 반대로 함부로 커밋하면 안된다는 경각심을 준다는 것을 잠시라도 잊지말자.
0
성장과 혁신의 역학을 설계하기
‘혁신 주도형 개발조직’이라는 키워드에는 현실과 동떨어질 수 밖에 없는 문제가 있다.
바로 현실에서는 항상 A급 동료들과 일하는 상황이 아니라는 것. 특히 개발자 구인난에 시달리는 작은 스타트업일 경우 더 그렇다. 고로 우리는 성장의 역학을 만들고, 조직이 상향 평준화 되는 선순환 구조를 설계해야만 한다. 새로운 것을 배우고 공유하는 장터인 테크토크, 아이디어를 발산하고 협업과 제약 수용을 배우는 해카톤 등. 회사가 새로운 실험(이라고 쓰고 실패라고 읽는다)을 두려워 할 필요가 없는 세이프존으로 느껴지게 하는 것이 핵심이라는 것을 배웠다.
0
모든 직원을 개발자로 만들기
최근 우리 회사에서 가장 핫한 키워드는 Rails 와 R. 거듭되는 해카톤을 통해 개발을 배워보고 싶다는 욕구가(항상 제안되는 아이디어에 비해 개발력이 부족하다보니) 전사적으로 퍼짐과 동시에 테크토크를 통해 기본적인 튜토리얼이 제공되면서 세일즈, C/S, 운영 등 비개발 스킬군들의 동료들이 하나 같이 개발을 배울 수 있는 환경이 점차 제공되고 있다. 당장 개발에 투입시킨다기보다는 Regression Test (회귀테스트) Case 를 공동 작성하고 환경별로 나누어서 맡는 등 점진적으로 부족한 개발군으로 가치를 더하고 있다.
