윤경구의 Log on Java

에릭 슈미트 등이 쓴 '구글은 어떻게 일하는가'는 구글러들의 기본 판단 방식을 잘 드러내고 있다. 많은 부분들에 공감하고, 또 이들이 하지 못하는 부분은 무엇일까 하는 생각도 든다. 몇 가지 공감한 글들을 옮겨본다. (번역에 문제가 좀 있다고들 하는데 크게 느끼진 못했지만, 역자가 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개에 도전합니다. 저는 평범하지 않은 기교를 씁니다. "모든 문제는 평범한 방식 말고 다른 각도에서 생각하면 더 나은 해법이 나옵니다." 그리고 저는 이런 해법을 발견합니다. 매일 여러 문제를 접할 때 우선 하드웨어 문제인지 자문한 후 과거에 썼던 기교를 하나씩 떠올립니다. 카운터와

오늘 회의 때 나온 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