새로운 관리자 모델은 훌륭한 코칭 능력을 필요로 한다.

이미지
"직원의 학습과 개발 70%는 일 자체에서 일어나지, 정형화된 교육 프로그램을 통해 일어나지 않는다."
관리는 많은 부분 코칭의 스킬을 필요로 하게 되었고, 코칭의 출발점은 Listening이다.
물론 관리자들도 코칭 및 관리 스킬을 개선하기 위해 코칭을 받을 필요가 있다.

코칭이 이루어지지 않거나 코칭 스킬이 개선되지 않는 회사는 미래 지향적 회사가 되지 못할 것이다.
시간을 이유로 좀처럼 사람들에게 귀기울이지 않는 기업은 결국 진보하지 못할 것이다.
Listening을 통한 Coaching과 Insight가 개선되는 조직이 지속적인 경쟁에서 성공할 수 있다고 할까.
그런 측면에서 위기는 listening을 징후로 하고 식별자로 리더의 코칭 능력 개선과 insight 능력을 들 수 있다.

그런데 듣기만 하고 insight가 없어서 코칭을 못한다면 이러한 기업은 정체할 뿐, 성장을 이끌지 못할 것이다.
코칭의 핵심은 멤버들과 코칭하는 관리자의 동반 성장이기 때문이고, 이를 통해 insight를 더 구체화하고 공유하는 것이기 때문이다.

코칭과 insight를 잘하는 리더 후보를 다수 보유한 기업이 진화하는 미래 지향 기업이라고 볼 수 있다.

관리자에 대해 코칭의 중요성을 지적한 아래 하바드 비즈니스 리뷰 글은 상당히 공감이 간다.

HBR 기사 원문 : 좋은 코치가 아니면 훌륭한 관리자가 될 수 없다.

아래는 기사를 대충 번역해본 것이다.

좋은 코치가 아니면 훌륭한 관리자가 될 수 없다. 2014년 7월 17일 Monique Valcour 글

가장 우선적으로 생각해야 할 리더십 덕목은 '사람들이 직장에서 경험하는 가장 강력하게 동기 부여하는 조건은 개인적으로 의미있는 무언가에서 진전을 이루는 것'임을 아는 것입니다.
당신이 누군가를 리딩하는 일을 하고 있다면 매일 해야 할 가장 중요한 일은 팀원들이 의미있는 일에서 진척을 경험하는 것을 것을 돕는 것입니다.

그렇게 하려면 각 멤버의 동인을 이해하고 각자의 일과 조직의 미션 및 전…

소프트웨어 조직의 관리에 대한 단상

관리라는 말은 정말 싫어하던 말이다.
스스로 자기 일을 잘 하면 되지, 왜 관리가 필요할까?
그런 생각이 강했다.

나이가 들어 관리자의 역할을 맡게 되어서도 관리에 대해 충분히 고민하지 못했다.
관리가 얼마나 중요한가에 대해 깨닫지 못했다.
아마도 내가 속한 팀의 팀원들은 무관리(?)한 관리자에 어이없어했을 것이다.

지금은 생각이 많이 바뀌었다.

"혼자서도 잘해야 하겠지만 함께 해야 무엇이든 이룰 수 있다"

혼자서도 잘해야 하는 게 바뀌는 건 아니겠지만, 혼자만의 힘으로 이룰 수 있는 건 거의 없다.
함께 해야 하는 것이라면 모두 관리의 영역에 포함된다.

뒤늦게 관리에 대해 생각을 하게 되었다.
수많은 시행착오를 뒤늦게 하게 된 것이다.

관리라는 말을 싫어하는 이유는 관리라는 말 자체가 정태적인 관료 조직을 떠올리기 때문이다. 특히 한국의 대기업 문화에서 보이는 관리자들은 전문성 없는 단순 관리자들이다.
자신의 역할이 기업 내 정치랄까 줄서기가 핵심인 가부장적인 존재들이다.

목적이 분명한 조직은 목적에 맞는 관리 체계를 가져야 한다.

관리자로서 가장 큰 실패는 관리자가 없어도 된다는 생각이다.
예를 들어, 구글과 같은 인재들이 모인 조직은 당연히 관리를 싫어한다.
스스로 일을 잘하는 사람들이 굳이 관리를 받으면서 일하려고 하지 않기 때문이다.

하지만, 구글도 목적을 가진 기업이고 이에 따라 사람들을 조직화해야 하기 때문에 관리가 없을 수가 없다.
불필요한 형식에 얽매이지 않고 좀더 목적에 필요한 부분으로 관리를 최소화하려고 노력을 할 뿐이다.

관리의 출발점은 목표 설정(goal setting)이라고 생각한다.
목적 조직에서 관리자들은 틀에 박힌 형식을 중시해서는 안된다.
항상 뚜렷한 목적을 가져야 한다.
목적에 따라 여러 가지 시도를 하면 된다.
물론 경험과 조언 등이 있으면 더 나은 시도를 할 수 있고 시행착오를 줄일 수 있겠지만.

목적 조직은 결과만으로 평가해서는 안된다.
시행 착오로 결과가 나쁘게 나오더라도 목적이 뚜렷한 행위는 개선 가…

맥북프로 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주 후

분해와 조립, 무한 반복...
이제 이 맥북도 곧 날라다니겠…

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 H…

태양의 유산

태양과 두 가지 사건

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

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

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

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

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

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

구글은 자바 기술을 안드로이드 플랫폼에 일부를 무단 복제하여 사용하여 엄청난 흥행을 거둠으로써 사실상 선 사가 자바 기술로 수익을 내지 못하는 직접적인 원인을 제공하는 역할을…

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

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



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

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



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



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



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



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

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



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



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



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

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

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



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

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





소프트웨어 전문 기업에서 연구 방법

최근 신입 연구원 지망자들을 면접하면서 소프트웨어를 직업으로 삼으려는 학생들 수준이 예전보다 많이 높아졌음을 느낀다.
국민적으로 소프트웨어의 중요성에 대한 평가가 그만큼 올라갔고, 또 소프트웨어를 통한 자기 실현의 기회가 상대적으로 많아졌기 때문인 것 같다.
아래는 소프트웨어 전문 기업의 연구소를 이끌면서 느끼는 개인적 감흥이라고 할 수 있겠다.
너무 당연한 이야기일지 모르지만, 실제로는 잘 되지 않는 것들에 대한 기록이다.

연구원별 과제 선정

소프트웨어 기업의 연구소는 어느 수준 이상의 연구개발 능력이 필요한 곳이다.
연구원들은 모두 동일한 능력을 갖지 않는다. 지적 노동을 하는 연구원들은 수준이 천차만별이지만, 일단 연구원으로서 연구개발 업무를 수행하기 위해서 필요한 기본 수준은 만족해야 한다.

우수한 인재
매우 우수한 사람은 흥미를 잃지 않을 주제를 주면 알아서 잘 한다. 이런 경우에는 어떤 가치 있는 주제를 기업 차원에서 연구해야 하는지 고민하고 이를 연구원과 잘 컨센서스를 이루는 것이 중요하다. 연구 주제에 흥미를 잃거나 포커스를 놓치게 되면 동기 부여에 실패하여 퍼포먼스가 급격하게 떨어지고, 타 회사로 이직을 고민하게 되는 경우가 있다.
연구의 가치와 방향에 대해서 항상 잘 조율이 되어 있어야 하고 초기에 궤도에 오를 때까지 주제와 방향을 잘 공유해야 한다.

평범한 인재
반면 상대적으로 평범한 연구원들도 많이 있다.
보통의 연구원들은 주제를 정해준다고 해서 충분히 방향을 잘 정하지 못하는 경우가 많다.
연구원의 능력에 따라 주제와 범위, 그리고 해결에 대한 방향까지 제시해줘야 하는 경우가 종종 생긴다. 이런 연구원들은 코칭이 늘 필요하고, 수준에 맞게 연구 수준과 범위를 좁혀줄 필요가 있다.
잠깐만 방향을 잃어도 퍼포먼스가 급격하게 떨어지는 경우가 많으므로 관리는 시간적으로 더 자주 일어나야 한다.

매니저와 연구원
연구 과제는 연구소에서는 누구나 진행할 필요가 있다.
단순 관리자가 필요하지 않은 연구소의 특성 상, 상위 관리자도 역시 기본적으로는 연구를 …

Java 관련한 간단한 테스트

문득 생각나서 몇 가지 간단한 Java  테스트

1. private static method의 코드 블록 크기가 작을 경우 javac는 가볍게 inline 시켜줌.
(즉, 해당 method는 바이트코드에서 사라져버리고 caller method에 inline됨.)

2. instanceof 연산자가 getClass()를 ==비교하는 것보다 훨씬 빠름.
(instanceof는 child class여부까지 체크해야 함에도 불구하고)

3. instanceof 연산을 할 때 exact class에 대해 호출하는 것이 parent class나 interface에 대해 호출하는 것보다 더 빠름. (당연!)

4. java.lang.Object의 clone() 메소드를 사용하여 객체를 shallow copy하는 것은 그다지 효율적으로 구현되지 않아서 직접 copy() 메소드를 구현하여 멤버값들을 복사해주는 것이 대부분 더 빠름. (자바는 C의 struct처럼value object 개념이 없어 메모리 복사만으로 clone할 수 없으므로)