기본 콘텐츠로 건너뛰기

태양의 유산

태양과 두 가지 사건

얼마 전인 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% 밖에 되지 않는다는 뉘앙스의 자기 반성을 하여 화제가 되었다.

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

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

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

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

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


댓글

이 블로그의 인기 게시물

Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다.

일단 생소하기 때문에 어렵다.

그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다.

먼저 G1GC를 이해하는 데 유용한 사이트이다.

Garbage-First CollectorGetting Started with the G1 Garbage CollectorUnderstanding G1 GC LogsTuning Garbage Collection for Mission-Critical Java ApplicationsControlling GC pauses with the GarbageFirst CollectorG1: One Garbage Collector To Rule Them AllGarbage First (G1) Garbage Collection Optionscompare JVM options for public메일 : G1 GC clean up time is too long
JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다.
(새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.)

지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다.
즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다.
앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다.

둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한 처리는 아직 최적화되지 않았다. 보통 한 region의 50% …

Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class…

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

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

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

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

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

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

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

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

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

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

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