월요일, 9월 26, 2016

맥북프로 13인치 2010년 버전의 하드웨어 업그레이드 산전수전 경험기

혼돈의 시작
2010년에 구입한 맥북프로 13인치.

메모리 4GB,  하드디스크 256GB

2013년에 맥북프로 레티나 13인치를 사면서 아내와 딸이 함께 구형 맥북프로를 사용했다.

2016년에 또다시 맥북프로 레티나 13인치를 딸에게 사주면서 버려질 위기에 처한 맥북프로를 아내가 논문 작성용으로 쓰고 싶다고 해서 고민하다가 하드웨어 업그레이드를 결심.
메모리를 좀 늘리고 HDD를 SSD로 바꾸면 충분히 빨라질 것이라고 당연한 판단.

먼저 여기저기 뒤져서 애플에서는 공식 지원하지 않는 맥북프로 업그레이드 방법을 찾아냈다.
기종을 정확하게 아는 게 핵심.
우리 집 맥북프로의 공식 버전명은 MacBooPro 7.1 혹은 MacBook Pro Mid 2010 이었다.

먼저 메모리를 찾아봤다. 16GB까지 업그레이드 가능하다는 주장도 있었으나 주장들이 좀 엇갈려서 안정적으로 4GB 두 개 즉, 8GB로 업그레이드하기로 했다.

8.0GB OWC Memory Upgrade Kit - 2x 4.0GB PC8500 1066MHz 204 Pin (gmarket에서 9만 2천원. 배송비 포함)

다음은 HDD를 대체할 SSD.
이것도 여기저기 찾아봐서 호환이 확실히 되는 걸 찾았다.

MICRON Crucial MX300 275GB SSD (gmarket에서 9만 7천 2백원. 배송비 포함)

한국에서 구매하는 방법은 G-Market 뿐이었던듯.
아마존은 대부분 한국에서는 구매할 수 없는 곳 뿐이었다.

그리고, 마지막으로 맥북을 분해 조립하기 위한 드라이버들.
메모리와 HDD 교체에 필요한 드라이버는 작은 십자 드라이버 하나였다.
(하지만, 종류별로 다 구매했다는 ㅠ_ㅠ 나중에 나오지만 배터리를 교체하려면 Y자 드라이버도 필요하다. 드라이버는 한 개당 gmarket에서 1800원 정도.)

2016년 8월 10일
자, 이제 20만원 가까운 금액을 gmarket에 입금!

2016년 8월 24일
주문한 부품들이 도착한 것은 2주 후

분해와 조립, 무한 반복...
이제 이 맥북도 곧 날라다니겠지?
자, 이제 분해해보자!!!

2016년 8월 30일
맥북프로 mid 2010을 메모리를 8GB, SSD 257GB 교체하다가 부팅이 안되어
맥앱스토어 통해 MacOS X 옛날 버전인 마운틴 라이언 인스톨러 다운받고
디스크 유틸리티로 restore해 설치 usb 만들고 해서
드디어 설치 화면까지 도달. ㅠㅠ
제발 설치 좀 되어다오. 설치화면도 분해 후 처음 봄 ㅠㅠ

뭐라도 보이니까 반갑긴 한데 몇일만에 부팅이 되는 건 뭐냐?


이때까지는 왜 설치가 안되는지 전혀 감을 못잡았음.

2016년 9월 9일
2010년형 맥북프로를 3년 전에 따님에게 물려줬는데 맥북프로 레티나를 이번에 사주면서 엄마에게 물려(?)줌.
쓰기에 사양이 좀 딸려 메모리를 4에서 8GB로, 하드디스크를 SSD로 교체하였는데 계속 문제가 있어 몇주째 고생 중.
Safe mode로 부팅하면 속도가 멀쩡한데 Normal boot 하면 엄청나게 느리다.
바쁜 와중에 새벽에 집에 들어오면 계속 OS 설치에 업글에 SMC 리셋에 NVRAM 리셋에 ...
속도 문제를 해결하기 위해 엄청 고생 중 ㅠㅠ
이 맥북 모델이 SATA 연결 케이블이 절연에 문제가 있다는 글이 있어 덜연을 위해 플라스틱을 잘라넣기도 하고..

이렇게 정성인데 ㅠ_ㅠ


지금은 Apple Hardware Test를 다운받아 실행해보는 중.

Download and run Apple Hardware Test (AHT) from a USB drive.

아내는 옛날 하드디스크로라도 돌려달라고 ㅠㅠ
도대체 원인이 뭐냐?!!!
제발 뭐라도 알려주라


AHT테스트 결과는 Ts0P열센서오류.
맥북은 상당히 많은 열 센서를 곳곳에 두고 있고 기종마다 많이 다르다고 함.
아래 사이트를 뒤져보니 이 기종의 열 센서는 총 9개가 있고
로직 보드에 4개(로직보드는 약 50만원 가까운 가격 ㅠ_ㅠ)
배터리에 4개
그리고 하나는 트랙패드 flex cable이라고 함.
Ts0P는 바로 이 아홉번째 Trackpad flex cable에 위치.

http://www.spumonte.com/files/PDFs/_PC%20Books_/MacBook%20Pro%20Service%20Manuals%20(2010)/MacBook%20Pro%20(13-inch).pdf

이게 무슨 암호야?


이때쯤 깨달았던 것은 열 감지 센서에 문제가 있어서인지 Normal Boot을 하면 엄청나게 Fan이 시끄럽게 돈다는 것.
뭔가 커널이 뜨겁다고 판단한 배터리나 트랙패드를 식히기 위해 팬을 열심히 돌리고, 또 다른 일들은 과열을 막기 위해 지연시키고 있는 듯.
나중에 Activity Monitor를 통해 알았지만 kernel_task가 CPU를 수백%씩 먹으면서 딴짓거리를 하고 있었다.

2016년 9월 11일
어쨌거나 터치패드의 열감지 센서가 이상인데 센서만 바꿀 수 있는 방법은 아무리 찾아봐도 없는 듯했다.
여기저기 뒤져봐서 터치패드를 사는 걸로 결정.
맥북 기종에 맞는 걸 gmarket에 찾아보니 다행히 하나가 있었다.

SEENIGHT Touchpad Trackpad fits MacBook Pro 13 Unibody A1278 821-0831-A Year 2009 2010 (5만 9천 9백원. 배송료 포함)

여기까지 온 노력이 아까워 바로 주문! (이제 들어간 비용이 26만원이 넘어간다 ㅠ_ㅠ)
트랙패드 교체할 때 배터리도 들어내야 한다고 해서 Y자 드라이버도 주문 ㅠ_ㅠ

2016년 9월 21일
주문한 트랙패드 도착.
트랙패드 교체 시도. 제발...!!!
트랙패드 교체하는 youtube 동영상을 찾아 보면서...

https://www.youtube.com/watch?v=9H1dirfooZA&app=desktop

교체는 잘 했고..
조립도 잘 했음.





하지만 다시 부팅 후 한번은 괜찮더니 잠시 후 팬이 다시 돌기 시작 ㅠ_ㅠ
실패!!! (어쨌거나 원래 트랙패드가 약간 클릭이 잘 안되었었기 때문에 트랙패드 구매가 무의미한 건 아니었음. 다만 트랙패드의 열 센서 문제가 아니었다는 것..)

2016년 9월 24일
맥북프로가 아무 이유없이 엄청나게 느려질 때... (Safe mode에서는 정상 속도)
증상은 Activity Monitor에서 보면 kernel_task 프로세스가 100%를 훨씬 넘어서 (500%를 넘는 것도 보임) 실행되고 있고 fan이 계속 실행됨.
AHT를 다시 실행했더니 다시 Ts0P 에러라고 뜬다.

아, 또야?! ㅠ_ㅠ


이젠 AHT를 신뢰하더라도 해결책이 아니다. 터치패드를 또 주문할 수는 없으니.. ㅠ_ㅠ

다시 한번 구글링 시작.
thermal sensor쪽 오류일 수도 있겠지만 정말 발열이 발생하는 상황은 아니지 않나?
왜 팬이 이렇게 바쁘게 돌면서 커널이 엉뚱한 일을 하고 있을까?
결국 찾아낸 이 정보.

How to solve kernel_task high CPU usage?

1. Go to About this mac under the apple in the upper left and click on More info
2. Click on system report
3. make a note of what it says after Model Identifier
4. go to your master drive – System -Library – Extensions – IOPlatformPluginFamily.kext -Contents – Plugins – ACPI_SMC_PlatformPlugin.kext – Contents – Resources – find the name from step 3 and move it to a folder that you can find again if needed.
3. Restart and you’re done
I hope this helps.
Only problem now is the battery won't register, new or old and the fan is running 100% of the time.
우리말로 옮기면

1&2. 메뉴 맨 왼쪽의 '이 Mac에 관하여'를 실행한 후 '시스템 리포트...' 버튼을 누른다.
3. 여기에서 하드웨어 개요 중 모델 식별자를 기억해둔다. (내 맥북프로는 MacBookPro7,1)
4. 이제 터미널 앱을 실행한 후 여기에서 /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/Plugins/ACPI_SMC_PlatformPlugin.kext/Contents/Resources 디렉토리로 이동한다.
이 디렉토리에 리스트 업된 파일들 중 3에서 확인한 모델 식별자에 해당하는 파일을 어딘가에 복사해두고 삭제해버린다.
5. 리부팅한다.

ACPI SMC Platform Plugin 정보가 모델별로 열감지 센서와 관련되어서 cpu가 과열되었다고 생각되면 이를 cooling시키기 위해 단순한 일을 반복(Fan을 풀 가동?)하는 게 kernel_task의 일이다. 따라서, 열 감지 센서는 맥북 모델별로 갯수와 위치가 모두 다르므로 해당 정보들은 모델 식별자별로 .plist 파일이 따로 만들어져 있는데 이를 찾지 못하면 해당 kernel_task가 그 일을 skip하거나 fallback으로 불필요한 loop 없이 fan을 실행하는 게 아닌가 싶다.

어쨌든 정확한 동작 방식은 확인이 안되지만 비슷한 정보는 다음에 있다.

“Fixing” kernel_task CPU Problems in MacOS 10.7/10.8

이제 끝?

아직 끝이 아니다
아니다. 아직 이 혼돈은 끝나지 않았다.
계속 OS 리커버리와 재설치를 반복하면서 어느새 9월 21일 macOS Sierra가 출시되었다.
맥북프로도 macOS Sierra로 업그레이드를 했다.

그랬더니, 바로 위의 파일 삭제가 실행되지 않는다.

"Operation not permitted"

루트인데도 불구하고!!!

이것은 Mac OS X El Capitan 버전부터 적용된 통합 보안 체계 때문이다.

Mac OS X Operation not Permitted 발생시

리커버리 모드로 부팅 후 (부팅 시에 Command+R)  터미널을 열어 "csrutil disable"을 실행하고 리부팅.
그리고 위에서 언급한 방식대로 해당 디렉토리에 가서 "sudo rm MacBookPro7_1.plist" 를 실행.

콩닥거리는 마음을 억누르고 평소에 하지 않던 sync 를 터미널에서 몇 번 실행 ㅠ_ㅠ
이제 마지막 리부팅... (이 되길 ...)

Ending
마침내.. happy ending....
한달 보름이 걸린 기나긴 맥북프로 하드웨어 업그레이드 스토리... ㅠ_ㅠ

Epilog
이후로도 한 가지 문제가 더 남았는데 열 감지 센서 문제 탓인지 cpu fan이 최고 속도인 6000rpm으로 계속 돌아서 너무 시끄러운 문제 ㅠ_ㅠ

이 문제를 어떻게 해결할지 여러 군데를 찾아봤지만 해결책을 못 찾았는데..

무료로 제공되는 다음 프로그램을 사용하니 다른 맥북의 열 센서와 연동하여 fan 속도를 자동 조정할 수가 있다!!!

Macs Fan Control - control fans of any Mac & Boot Camp!

오옷.. 3000rpm 정도로만 돌아도 소음을 느낄 수도 없다!!!
이제사 완전히 해결!!!

Macs Fan Control을 설치하고 조용해진 MBP. 빠르고 조용하다!


토요일, 8월 13, 2016

[Java] IBM JDK에서 native out of memory가 발생하는 이유와 해결책

IBM JDK를 사용할 때 (gc policy는 보통 gencon) 물리 메모리가 많이 남아있는 경우에도 native out of memory (NOOM)가 발생하는 경우가 있다.
NOOM이 발생하지 않았더라도 global gc 가 자주 발생하여 성능에 영향을 주기도 한다.
verbose gc 로그를 보면 sys-start reason="native out of memory" 라는 이유로 global gc가  실행되는 것을 볼 수 있다.

이렇게 global gc가 자주 발생하면 자바의 가장 큰 골치거리인 Stop-The-World 현상이 발생하여 순간적으로 멈춰서게 되어 매우 불안정하게 되는데 이 문제의 원인은 무엇인지 알아보자.

이 문제가 발생하는 경우는 IBM JDK (버전 6 이후)를 사용하고 64비트 JVM, 전체 Java Heap 크기를 4GB 이상 25GB 이하로 줬을 때이다.

-Xmx 값이 4GB~25GB이면 IBM 64bit JVM은 기본값으로 -XcompressedRefs 옵션을 켠 것과 동일한 방식으로 동작한다.
자바의 객체들은 JVM 내부에서 2-word 크기의 헤더를 가지는데 32bit JVM에서는 2-word는 8byte이며, 64bit JVM에서는 2-word가 16byte가 된다.

64bit 방식으로 자바 객체를 addressing하게 되면 사용할 수 있는 메모리 영역은 훨씬 더 커지겠지만 메모리를 과다 사용하고 OS의 page cache fault 등의 문제로 성능적으로도 느려질 수밖에 없다.

그래서 64bit JVM에서도 32bit 방식으로 자바 객체 주소를 addressing하는 방식이 바로 compressed reference라는 개념이다.

compressed reference 방식으로는 최대 32GB까지 주소를 나타낼 수 있다.
이 경우 Java Heap에 있는 자바 객체들에 대한 주소는 shift 연산을 통해 32bit 주소의 한계인 4GB를 넘어서 최대 32GB까지 참조할 수 있게 되지만, Java Heap 밖에 (즉, native 영역에) 존재하는 클래스 객체, 모니터 객체, 쓰레드 객체 등은 여전히 4GB 주소 안에 있어야 한다. 자바 객체 헤더에서 참조하는 클래스, 모니터, 락 등에 대한 포인터가 32비트로 표현되기 때문이다. (테스트를 해보면 live class 객체들만 4gb 크기에 들어있으면 된다. Unloading을 안해서 전체 클래스 객체가 8~9gb인 경우에도 live 객체들 크기가 4gb 범위 안에 있으면 noom warning이 나질 않는다. 아마도 live pointer들을 간접 포인팅하는 식으로 구현된 것 같다.)

native OOM이 발생하는 원인 중 하나는 주로 클래스 객체가 너무 많이 사용되어 이 영역이 4GB를 다 차게 되는 경우이다.
일반적으로 복잡한 자바 업무들을 구현하면 자바 코드들이 1GB를 차지하는 경우는 종종 볼 수 있다.
좀 지나치게 많은 업무 코드들을 모두 하나의 JVM에서 올리려고 하면 2.5GB를 넘어서게 될 수 있는데 이렇게 되면 일반적으로 다른 모니터와 쓰레드가 차지하는 영역까지 합쳐서 4GB를 육박하게 된다.


<그림 : JVM 프로세스 메모리 맵> "Using -Xgc:preferredHeapBase with -Xcompressedrefs"에서 인용
이런 경우에는 코드들을 효과적으로 서로 다른 JVM으로 분리하여야 불필요한 global gc를 막을 수가 있다.

참조 :


태양의 유산

태양과 두 가지 사건

얼마 전인 6월 16일 삼성전자가 미국 실리콘밸리에 있는 클라우드 스타트업인 Joyent를 인수했다는 소식이 들려왔다.
국내에서는 소프트웨어 조직을 축소하고 있는 삼성전자가 실리콘밸리의 기업을 인수하고 현지 연구소를 강화하는 모습을 보이는 교차하면서 우리나라 소프트웨어 산업의 문제는 과연 무엇일까 하는 생각이 들었다.

그보다 조금 앞선 5월 26일 구글과 오라클의 자바 저작권 침해 소송에서 캘리포니아 북부 연방지원 배심원단은 구글이 자바 저작권을 침해한 것은 API 호환을 통한 기술 경쟁 보장이라는 공정 사용(Fair Use)에 해당한다고 구글의 손을 들어줬다. 이전 저작권 침해 심의 항소심에서는 미 법무부에서 안드로이드의 자바 API 부분 사용은 호환을 목적으로 한 것이 아니므로 공정 사용에 해당하지 않는다는 의견을 제출한 바 있다.

언뜻 상관없어 보이는 두 개의 사건은 모두 지금은 오라클에 인수되어 사라진 기술회사인 선마이크로시스템즈의 기술 유산을 둘러싼 사건이라는 점에서 공통점이 있다.

선마이크로시스템즈 사(이하 선 사)는 '네트웍이 컴퓨터'(The Network is The Computer)라는 캐치프레이즈로 운영체제로부터 가상머신, 미들웨어 등 시스템 소프트웨어와 네트웍 기반 컴퓨팅 하드웨어를 만드는 회사였다.

네트웍이 바로 컴퓨터라는 사상은 지금 전 세계를 휩쓸고 있는 클라우드 컴퓨팅의 현실을 예언한 핵심 아이디어이다.

프로세서 칩과 스토리지 장비, 유닉스 머신 등과 솔라리스 운영체제, 자바 언어 등 핵심 기술을 보유했던 이 회사는 닷컴 버블 이후 점점 더 심해지는 유닉스 시장의 경쟁을 이기지 못하고 또, 미래 가치를 크게 평가받았던 자바 기술로 별다른 수익을 창출할 방법을 찾지 못해 결국 소프트웨어 전문 기업인 오라클에게 인수되고 말았다.

구글은 자바 기술을 안드로이드 플랫폼에 일부를 무단 복제하여 사용하여 엄청난 흥행을 거둠으로써 사실상 선 사가 자바 기술로 수익을 내지 못하는 직접적인 원인을 제공하는 역할을 하였다.
자바 언어를 만든 제임스 고슬링을 비롯한 당시 선의 엔지니어들이나 경영진은 실리콘밸리의 해커 출신들과 오픈의 정신을 공유하고 있었기에 또다른 해커 정신을 공유한 기업인 구글의 이러한 비신사적 행위에 대해 매우 힘들어하고 있었다. 또 오라클은 선을 인수할 때 이 법적 소송의 가치를 매우 중요시했던 것으로 알려져있다.
선은 대단한 기술을 만들었지만 수익을 내지 못하고 역사 속으로 사라지고 말았다.

선 사는 프로그래밍 언어로서 대단한 혁명을 가져왔던 자바를 만들고도 별다른 수익을 내지 못하였다. 모바일 환경에서는 자바 언어를 사용하지만 선에 로열티를 내지 않는 안드로이드 플랫폼이 엄청나게 빠른 속도로 지배적 플랫폼으로 성장하는 사이, 선 사의 자바 표준이었던 J2ME (자바 2 마이크로 에디션)은 성능과 기능 모두에서 문제를 드러내며 대중화에 실패하였다. 엔터프라이즈 환경에서는 선 사보다는 오라클에 먼저 인수되었던 BEA 같은 미들웨어 전문 기업의 솔루션이 시장을 지배하였다. 데스크탑 환경에서는 자바가 크게 강세를 보이지 못하였을 뿐 아니라 선은 데스크탑 버전에 대해서는 무료 정책을 고수하였다.

기술과 공유의 정신을 모두 갖춘 선 사는 핵심 기술을 보유하고도 수익 창출 능력에 큰 한계를 보이며 더 이상 성장하지 못했던 것이다.

네트웍이 컴퓨터
클라우드 컴퓨팅을 단적으로 표현해주는 '네트웍이 컴퓨터'라는 슬로건으로 기술을 개발했던 선 사의 기술 유산은 자바 뿐만이 아니다.
해커 정신을 공유했던 엔지니어들이 세운 선 사는 오라클에 기업을 넘기기 전에 핵심 기술을 오픈소스화하여 공유하려고 했다.

자바를 GPL 라이센스로 이중 라이센스화하여 OpenJDK라는 오픈 소스 프로젝트를 출범시켰으며, 자바와 더불어 핵심 소프트웨어 기술 중 하나였던 솔라리스 운영체제도 비슷한 형태로 오픈소스화하였다.
다만 GPL 라이센스 기반의 리눅스 운영 체제에 솔라리스 핵심 기술이 병합되는 것을 경계하여 GPL과 함께 사용할 수 없는 CDDL이라는 오픈소스 라이센스를 고안하여 CDDL 기반으로 솔라리스 운영체제의 소스를 공개하여 OpenSolaris 프로젝트를 출범시켰다.

솔라리스의 핵심 기술로 지금도 각광받고 있는 기술은 운영체제 자체 외에도 새로운 개념의 파일 시스템인 ZFS, 커널에서부터 사용자 레벨까지 API 추적이 가능한 D-Trace, 그리고 솔라리스 운영체제의 멀티테넌트 기술인 Zone 등이 있다.
ZFS는 파일 시스템 내부에 볼륨 관리 기능을 포함시킨 새로운 개념의 파일 시스템으로 동적 확장이 쉽고, 현실적으로는 파일 시스템 크기 한계가 없으며, COW 방식으로 트랜잭션과 스냅샷을 지원하여 클라우드의 컨테이너 기술에 최적인 파일 시스템이다.
D-Trace는 OS의 커널 내부 함수 수준으로부터 사용자 함수 수준까지 모두 트레이스 할 수 있도록 하며, 또 필요할 때만 트레이스 오버헤드를 가져가도록 설계된 매우 독특하면서도 유용한 트레이스 방식이다.
Zone은 리눅스 컨테이너 기술에 해당하는 솔라리스의 OS 가상화 기술이다. 리눅스 컨테이너에 비해 보안 관점에서 좀더 잘 격리하고 있어서 상대적으로 리눅스 컨테이너의 취약점인 보안 이슈를 좀더 잘 다룰 수 있다.

이 솔라리스의 핵심기술들을 기반으로 클라우드 서비스를 구현한 회사가 바로 삼성전자가 인수한 Joyent라는 회사이다.
이 회사의 핵심 기술 인력들은 대부분 선 사에서 솔라리스를 개발하던 엔지니어들이며, 이들이 클라우드 구현에 사용한 핵심 운영 체제는 바로 OpenSolaris이다.
선 사가 오라클에 인수되기 직전에 이 솔라리스 엔지니어들은 여러 채널을 통해 보유 기술을 수익화하려고 노력했던 것으로 보인다. 이 당시 애플의 맥OS와 iOS에 ZFS 기술을 팔려고 엔지니어들이 다방면으로 만나 기술 설명을 했던 기록들이 남아있는데 오라클에 인수되면서 몇 년에 거친 노력이 모두 취소되고 말았다고 한다.

선이란 기업은 해가 지듯 저물고 말았지만 핵심 기술과 엔지니어는 아직도 네트웍은 컴퓨터라는 아이디어를 유지하고 있다.
해가 지는 것이 조금 안타깝게 느껴졌었지만 지금 보면 핵심 소프트웨어 기술과 사상은 기업보다 더 오래 지속된다.

소프트웨어에 대한 반성
태양의 후예인 Joyent를 인수한 삼성전자는 최근 소프트웨어를 통한 문제 해결 능력이 구글의 1~2% 밖에 되지 않는다는 뉘앙스의 자기 반성을 하여 화제가 되었다.

이 반성과 삼성전자 내 기존 소프트웨어 조직의 축소 그리고 실리콘밸리 내에 소프트웨어 역량을 구축하겠다는 전략이 겹쳐보여서 씁쓸하기도 하다.

국내는 축적된 기반 소프트웨어 역량이 거의 없다.
태양의 후예들처럼 운영 체제 기술과 핵심 커널 기술들을 발전시킬 인력이 현실적으로 찾기 어렵다.
그리고 국내의 소프트웨어 인력 수준과 실리콘밸리의 소프트웨어 인력 수준이 결코 비슷하지 않다는 현실도 인정해야 한다.

소프트웨어 핵심 기술은 하루 아침에 만들어지거나 갖춰지지 않는다.
핵심 인력 한두명의 역할도 매우 중요하지만 함께 유기적으로 움직여줘야 할 고급 인력들도 확충되어야 한다. 반면, 한번 갖춰진 핵심 기술과 인력은 쉽게 사라지지 않는 것도 사실이다.
기업은 가도 기술과 해커는 남는 것이다.

분명 지금 당장의 국내 인력들은 많이 부족하다.
대학의 수준도 기업의 수준도 모두 부족한 상황이다. 하지만 그 어느때보다 경험들을 많이 축적해왔다.
핵심 소프트웨어 기술을 개발할 인력을 대학에서 길러낼 수 있어야 하고, 기업은 지지 않는 태양을 만들 수 있는 능력을 갖춰야 한다.

반성이 지금까지의 고민과 성과를 모두 포기하는 것이면 안될 것이다. 그보다는 대학과 기업 모두 정말 문제 설정을 잘할 수 있도록 가르치고, 핵심 소프트웨어 기술을 활용하여 난제들을 해결하는 엔지니어들의 시스템을 구축하는 데 결과물들을 응집할 시기가 아닌가 싶다.
핵심 기술을 만들어내지 못하는 한, 소프트웨어에 투입된 사람 수도 구글에 입사할 역량을 가진 사람 수도 아무 의미가 없다. 뛰어난 개인이 혼자서 해결할 수 있는 문제들이 아니다.


토요일, 6월 25, 2016

저커버그가 말하는 '기업가가 된다는 것'

"기업가가 된다는 것은 단순히 회사를 만든다는 것이 아니라 변화를 만든다는 것이다."



프랑스 혁명이 자유, 평등, 박애를 외친 이래

미국은 자유와 기회 균등, 능력주의 원리 위에 세워진 나라이다.



물론 현실은 그렇지 않겠지만 적어도 미국인들은 이러한 이상을 이야기한다. (트럼프류를 제외한다면 말이다)



실리콘밸리의 젊은 기업가들이 기회 균등과 능력주의에 기반한 사회 구성 원리를 외치는 모습을 종종 보게 된다.



페이스북과 구글이 바로 그 전형인 것 같다.



그들은 미국 내 기회 균등을 외치지 않는다.

지구촌 영역에서의 기회 균등을 외친다.



인터넷이 사업적으로 글로벌하기 때문일수도 있겠지만 그들의 실천은 감동적이다.



기업을 함께 할 사람들을 어떻게 구성할 것인가에 대해서도 다시 생각해보게 된다.



저커버그의 논리에 따르면 그의 기업은 변화를 위한 운동이다.

구성원들은 변화라는 사회 운동을 이끄는 운동원들이며,

이 변화를 성과적으로 이룰 수 있는지 능력에 따라 자격과 권한을 부여하게 된다.



성과주의적 시각을 좀 벗어나면 기업이 목표를 이루는 집단이 되려면 구성원별로 역할이 필요하다.

방향에 근거하고 성과와 역할에 따라 성원들 스스로 방향을 함께 할 수 있도록 셋업해야 한다.