글

구글은 어떻게 일하는가 중에서

에릭 슈미트 등이 쓴 '구글은 어떻게 일하는가'는 구글러들의 기본 판단 방식을 잘 드러내고 있다. 많은 부분들에 공감하고, 또 이들이 하지 못하는 부분은 무엇일까 하는 생각도 든다. 몇 가지 공감한 글들을 옮겨본다. (번역에 문제가 좀 있다고들 하는데 크게 느끼진 못했지만, 역자가 IT를 잘 몰라서 잘못된 역주를 달아둔 경우는 거슬렸다.  최대의 오류는 안드로이드의 파편화fragmentation을 얘기하는데 disk fragmentation을 역주로 단 부분. 본문들도 그런 점에서 모호하거나 반대로 보이는 해석들이 몇가지 있는 것 같다.) "시장조사로는 고객이 이해하지 못하는 문제의 해결 방법을 찾아낼 수 없다 고객이 원하는 것을 제공하는 것보다는 고객 자신에게 필요한데도 아직 몰라서 원하지 못했던 것을 찾아내 제공하는 것이 훨씬 더 중요한 법이다" "제품개발 전략의 토대를 기술혁신에 둔다면 여러분은 단순히 고객이 찾는 것을 공급하는 식의 me-too products를 피할 수 있을 것이다" 기술혁신이 무엇인지 구체적으로 말할수 없는 제품을 만들어서는 안된다. 기술혁신이란 문제를 새로운 방법으로 해결하는 것이며, 여러 기술의 발전을 접합시켜 새롭게 문제를 해결하는 combinational innovation의 시대에 이미 접어들었다. " 두 가지 방법 (오픈을 택한 안드로이드와 폐쇄를 택한 iOS) 모두 승리했다. 그런데 아이폰으로 애플이 성공한 것은 구글의 검색기능과 마찬가지로 급성장하는 업계에서 확실히 우월한 제품을 창조해낸 이례적인 기술혁신에 토대를 두고 있다는 사실을 명심해야 할 것이다. 만일 여러분이 이렇게 폐쇄적인 시스템으로 극단적인 성과를 올릴 수 있다면 한번 시도해보라. 그렇지 않다면 초기 설정을 개방에 맞춰라. "   " 열정적인 사람은 그 열정을 가슴에 품고 있을 뿐 남에게 알리지 않는다. 이들은 열정을 생활 속에 간직하고 있다. 열정이...

해커스 중에서

해커스 - Heroes of the Computer Revolution 해커스는 소프트웨어, 하드웨어 해커의 출현을 추적한 기록이다. 가장 중요한 것은 해커들의 원칙인 "직접 해서 보여라"라는 제일의 원칙이라고 할 수 있다. Access to computers should be unlimited and total. Always yield to the Hands-On Imperative! 컴퓨터가 대중화되기 이전 시기에서 대중화를 이끌었던 여러 뛰어난 해커들의 생각들, 그리고 그들이 추구한 원칙들 중 유의미한 부분이 무엇일까 다시금 생각해볼 필요가 있다. 책에 나오는 대목들 중 인상깊었던 부분들, 그리고 몇 가지 생각들 30시간 단위로 하루를 살아가며 해커로 늙어갈 수 있을까? "저는 정말로 자랑스러웠습니다. 밤낮없이 해킹한다는 사실이 말입니다. 해가 떴는지 달이 떴는지 상관하지 않았죠. 자다 일어나 밖이 어슴푸레해도 새벽인지 초저녁인지 몰랐습니다." 하지만, 이런 생활을 영원히 계속할 수 있을까? 실전 스타일의 해커들이 가장 퍼포먼스가 좋았던 상황은 혼자 있는 방은 아니었던 것 같다. 조금은 웅성대는 까페 같은 분위기랄까? 저는 미적인 목적으로 칩을 줄이려고 애씁니다. 또한 제가 똑똑하다고 생각합니다. 칩 줄이기는 제가 즐기는 퍼즐이며, 제 설계는 지금까지 나온 보드보다 칩을 하나 덜 씁니다. 저는 더 빨리, 더 작게, 혹은 더 영리하게 하는 법을 궁리합니다. 뭔가를 구현할 때 명령 6개가 괜찮다고 여겨지는 수준이라면 저는 5개나 3개에 도전합니다. 정말 잘하고 싶을 때는 2개에 도전합니다. 저는 평범하지 않은 기교를 씁니다. "모든 문제는 평범한 방식 말고 다른 각도에서 생각하면 더 나은 해법이 나옵니다." 그리고 저는 이런 해법을 발견합니다. 매일 여러 문제를 접할 때 우선 하드웨어 문제인지 자문한 후 과거에 썼던 기교를 하나씩 떠올립니다. 카운터와...

[Java] Class.forName 과 ClassLoader.loadClass의 동작 차이

오늘 회의 때 나온 Class.forName 과 ClassLoader.loadClass의 중요한 동작 차이. Class.forName(String clazzName, boolean init, ClassLoader loader) 은 지정한 ClassLoader를 통해 해당 ClassLoader가 define하지 않은 Class라 할지라도 JVM에서 해당 ClassLoader에 캐시하게 되어 있고.. ClassLoader.loadClass(String clazzName) 은 무조건 defineClass를 실행한 ClassLoader에만 해당 Class를 캐시. 아래 블로그 참고. Class.forName caches defined class in the initiating class loader 결과적으로 Class.forName을 사용하면 경우에 따라 효과적인 클래스  캐시를 구현할 수도 있다는 것. (불필요한 user classloader cache 없이..) 참고로 ClassLoader.loadClass(String clazzName, boolean resolve)에서 두번째 인자인 resolve는 원래 의도하기에는 클래스 로딩 시에 참조하는 클래스들에 대한 linking을 실행하기 위한 것이나 (eager linking) 한번도 JVM에서 구현된 적이 없으므로 무시한다. Java에서는 아직까지는 항상 lazy linking만 지원하는 셈. P. S 1) resolveClass 구현 즉, eager linking 구현 코드 ClassLoader에서 resolveClass를 실행해도 아무 일도 일어나지 않길래 왜 그러나 봤더니.. (resolveClass는 지정한 Class의 바이트코드에 선언된 link해야 할 Class들을 모두 link해주는 역할을 해야 함) Hotspot JVM에서 구현을 하지 않았을 뿐임 ㅠ_ㅠ; 즉, Hotspot JVM에서는 link가 해당 클래스를 항상 처음 사용할 때(즉, 메소드 호출을 하는...

역발상보다는 더 근원적인 사고

창의적 혁신을 위해 역발상을 하란 말을 자주 한다. 요즘 생각해보니 역발상 즉, 거꾸로 생각한다는 건 사뭇 형식적 관점이다. 천재들의 혁신은 형식적 발상 전환보다는 언제나 "더 근원적인 사고"에서 나왔던 것 같다. 깊게 파지만 말고 주변을 파보라는 발상의 전환을 얘기하는 "lateral thinking"도 창의를 형식적 기법으로 보는 방법의 하나이긴 한데, 이조차 "수평적 사고"로 번역하면서 권위(수직적?)에 반대하는 사고법으로 오역하기도 하지만... lateral thinking이나 역발상(전환적 사고?)도 결국 사고 방식을 달리 하여 창의를 일으킬 수 있다는 가정을 하고 있다. 하지만, 곰곰히 생각해보건데 형식적인 사고의 전환보다는 진정으로 더 깊게 파는 데서 인류에게 유의미한 진정한 창의와 혁신이 나왔던 것 같다. 더 깊이 파고, 더 뿌리적인 사고를 하다보면 기존의 사고 체계는 무너지게 되어있었던 것 같다. 그게 진정한 파괴적 혁신이고 천재성이 아닌가 싶다.

구글의 창업자 래리와 세르게이가 원하는 구글의 관리 방식

이미지
래리나 세르게이 같은 친구들은 어떻게 구글을 이끌고 싶어할까? 처음엔 관리자가 필요없는 기술 회사를 꿈꿨다. 경험은 중요치 않고 통찰력을 중시하는 기술 회사. 구글에서 매니저의 역할은 엔지니어들을 명령이 아니라 수치를 근거로 어떤 생각하는 방법으로 유혹하는 일이다. 구글은 여전히 매우 강한 동기를 가진, 또 프로젝트에 대한 강한 ownership을 가진 작은 팀으로 나눠 관리하고 싶어한다. 현실적으로 인원이 수만명이 되면서 구글은 하나의 목표 관리 체계를 도입한다. John Doerr가 제시한 OKR(원래 인텔의 창시자인 앤디 그로브가 주장) 관리 체계를 전면 도입한다. 이 Objective & Key Results 방법은 모두가 자신이 하고 있는 일의 우선 순위를 매우 명백하게 확인시켜주기 위한 것이다. 이 책의 일부분을 읽었지만 읽을수록 래리 페이지, 세르게이 브린은 전형적인 천재 기업가 (천재 엔지니어이자 저돌적인 스타일의 기업가) 스타일임을 알게 된다. (nerd!) 이들이 생각하는 방식은 놀랍게도 내가 현재 일하고 있는 회사 창업주의 사고 방식과 유사한 부분이 많다. OKR의 특징을 대충 다음으로 요약할 수 있다. Objective & Key Results : 목표와 이를 이루기 위해 수치로 표현되는 핵심 결과 목록을 나열 개인 OKR, 팀 OKR, 회사 OKR 별도 작성 주로 개인별이 중요하며, 회사나 부서의 특별히 중요한 목표가 있을 때 회사나 부서의 OKR을 작성 분기별 OKR (변경되지 않음), 연간 OKR (지속적으로 변경 가능) 핵심 결과 목록을 채점 채점은 수분만에 바로 이루어져야 함 분기별 OKR의 핵심 결과 목록 채점은 보통 작성 후 두 달 후에 본인이 직접 작성. 점수와 다음 OKR을 공유하기 위해 모두가 참석하는 회의를 개최 (분기별로 OKR 초안을 작성한 다음에) 분기별로, 회사 OKR가 주어진 후에 (개인별 OKR은 회사와 팀 OKR이 만들어진 후에 만들 수 있다. O...

스무살 때 알았으면 좋았을 스물 여섯 가지 시간 관리 기술

시간 관리는 대부분의 사람들한테 어려운 부분이고 시간 관리 능력에 따라 성과가 크게 다를 수 있다. 여러 가지 역할을 해야 하는 사람들은 성격이 다른 업무들 간의 전환을 할 때 어려움을 많이 겪는다. 어떻게 시간을 서로 다른 업무들 간에 효율적으로 배분할 수 있을까? 몰입(flow)이 필요한 창의적인 지적 노동을 하는 사람들에겐 더욱 시간의 관리가 중요한 요소이다. 하나의 생각에 깊이 몰입할 수 있어야만 성과를 얻을 수 있기 때문에 몰입할 수 있는 시간 여건을 만드는 관리가 필요하다. 개인적으로도 하루 종일 예정되어 있는 회의들 속에서 생각을 정리하고 설계할 수 있는 시간은 점점 더 찾아보기 어렵다. 어떻게 몰입하고 정리하는 시간을 만들어야 할까? 늘 고민이다. 육체의 피로와 뇌의 피로는 보통 직접적인 관련은 없다. 육체가 피로할 때에도 뇌는 활발하게 활동할 수 있으며, 반면 육체는 멀쩡할 때에도 뇌가 피로할 경우가 있다. 물론 육체가 활발하게 맑은 혈액을 공급해줘야 뇌의 활동이 보장되는 것은 장기적 관점에서 사실이다. 다음 프레젠테이션은 캐나다의 제품 마케팅 컨설턴트인 Etienne Garbugli라는 사람이 작성한 시간 관리 기술에 대한 것이다. 나름 공감되는 부분도 많아서 하나씩 음미해본다. SlideShare : 26 Time Management Hacks I Wish I'd Known at 20 1. 하루 시간의 배분  시간에 우선순위를 두자.  무의미한 Boring 시간을 줄이고 우선순위가 있는 일들로 바꾸자. 2. 매일 일할 분량 4~5시간만 계획하자. 나머지 시간은 차게 마련이다. 3. 하루 종일 일이 전혀 진행되지 않거나, 12시간 이어서 일이 잘 진행되는 게 정상이다. 일이 잘 될 때 좀더 일을 하고, 일이 안될 때 좀더 여유를 갖도록 하자. 4. 자신의 시간당 비용을 생각해보고 그에 따라 행동하자. 내 시간을 존중하고, 또 내 시간이 존중받을 만큼 가치가 있도록 만들자. 5....

창의적 문제 해결의 경험

창의적으로 ( 소프트웨어)  문제를 푸는 경험은 여러 경로로 만날 수 있다. a. 똑똑하고 적극적인 개인들이 문제를 잘 푸는 경우. b. 문제의 범주를 잘 인지하고 똑똑한 그룹을 형성하여 회의 속에서 토론하여 실마리를 풀어가는 경우. 문제를 푸는 과정이 단순히 a-ha 현상 한 스텝만은 아니므로 사실은 a와 b의 반복을 어느 정도의 긴장감 속에서 만들 수 있는 체계가 가장 효율적이라고 생각한다. management는 이러한 문제를 가려내고 가치로운 문제 해결을 할 수 있도록 개인별 mission과 회의를 통한 아이디어 심화 및 공유를 잘 갖추어주고 회의를 잘 이끄는 것이 중요한 역할이다. 그럼에도 문제를 푸는 (답을 선택하는 게 아니라) 과정을 직접 해야 할 시점은 항상 존재하는데 다른 사람과의 토론 속에서 연상을 통해 풀어내는 경우 외에는 결국 스스로 생각을 다시 정리하면서 풀어야 한다. 개인적으로 이러한 풀이 과정은 자리에 앉아 머리를 싸맬 때보단 계속 생각하면서 걸어다닐 때 해답이 잘 발견되었던 것 같다. 복도를 계속 걸으면서 생각한다거나, 탄천을 헤매면서 생각한다거나... 하나. 문제 해답이 떠오르는 건 문제에 대한 깊이 있는 이해 과정이 거듭되어야 한다. (wicked problem적 특성) 둘. 문제의 인지와 해결 모두 우수하고 적극적인 그룹을 형성하여 논리적 토론을 거치는 것이 가장 중요한 단계이다. A-ha의 한 스텝을 제외하고는 이 과정을 통해 문제의 인지와 심화 그리고 해결의 대부분을 매우 좋은 효율로 이룰 수 있다. 셋. A-ha는 보통 정확하게 problem-solving의 mission을 맡은 사람이 만나게 된다. 그만큼 생각을 많이, 깊게 하는 것이 전제되어야 하기 때문이다. 넷. A-ha 자체의 순간은 몰입이나 이완 등의 과정과 무관한 시점에서 아주 비동기적으로 수많은 생각 중 하나의 한 연결에 이어져서 발생한다.