기업의 철학을 바꾼 오프소스 커뮤니티

IBM이 리눅스와 운명을 같이하면서 변화한 것은 단순히 사업전략이나 비즈니스 모델뿐만이 아니었다.

오픈소스 커뮤니티가 가지고 있던 문화와 프로세스도 IBM이라는 거대 조직에 대단한 영향력을 행사하게 되었다.

기업의 새로운 문화가 탄생하면서 조직이 변하기 시작한 것이다.

오픈소스 프로젝트를 진행하는 커뮤니티는 빠르고 투명한 의사소통, 끊임없는 개발과 테스트를 통한 업그레이드를 중시한다.

그래서 일단 커뮤니티 멤버들이 구성되면 메신저나 이메일을 활용해서 적극적으로 의사소통을 한다.

사실 한국 개발자들이 오픈소스 프로젝트에 많이 참여하거나 적응하지 못하는 이유 중에는 이러한 의사소통의 어려움 때문인 이유가 상당히 크다.

그에 비해 기업의 의사소통은 여러 가지이유(정치적인 문제나 책임 소재 등)보다 공식적인 루트를 이용하고 기록 남기는 경우가 많다.

서로의 눈치를 보게 되고, 혹시 있을지 몰르 책임을 면하기 위해 회피 활동을 보이기 쉽상이다.

IBM에서 리눅스 개발그룹을 이끄는 댄 프라이에 따르면, 기업의 소통문화가 오픈소스 커뮤니티의 그것에 비해 비효율적이어서 어려움이 많다고 한다.

채팅이나 게시판을 이용하는 데 모두들 눈치를 보거나, 과감하게 의사소통을 하지 않았던 것이다.

그래서 리눅스 그룹의 경우 사내 네트워크를 차단하고 오로지 인터넷을 통한 의사소통만 하도록 했다. 이런 결정이 내려진 이후에야 비로소 팀원들이 게시판과 채팅을 통한 활발한 의사소통을 시작했다.

IBM이 오픈소스 프로젝트를 주도하면서 또 한 가지 배운 것은 소프트웨어의 설계방식이 기존 대기업이 가지고 있던 것과 큰 차이가 있었다는 점이다.

설계 – 구현 – 테스트 – 유지,보수로 이어지는 기본 단계 자체는 동일하지만 시간 분배에 엄청난 차이가 있었다.

오픈 소스 커뮤니티는 설계보다는 구현-테스트에 많은 시간과 노력을 기울이는 경향이 있다.

원래 설계에서 시간을 가장 많이 잡아먹기 때문에 시간의 효율적인 활용이라는 측면에서 이러한 프로세스는 커다란 장점이 있었다.

오픈소스 커뮤니티의 효율성과 개방성은 IBM이라는 기업에 큰 영향을 미쳤다. 리눅스 개발팀에서 시작된 오픈소스 커뮤니티식의 개발형 의사소통 방식은 사내에서도 통하기 시작하였다. 이러한 철학의 변화에 힘입어 IBM은 또 하나의 커다란 결정을 내리게 되는데, 수많은 지적재산을 독점소유하고 이를 바탕으로 이윤을 얻는 대신, 품질을 향상시키고 성장을 촉진하는 쪽으로 많은 프로젝트들이 방향을 선회한 것이다.

IBM의 수많은 특허권이 yet2.com과 같은 기술거래기업을 통해 아웃소싱되기 사작하고 자신들이 가지고 있던 노하우를 외부에 적극적으로 노출시키면서 생태계를 같이 꾸려나가게 되었다. 이러한 노력의 산물 중 하나가 devloper-Works와 alphaWorks와 같은 사이트들이다.

IBM은 오픈소스 진영에 뛰어들기 이전만 하더라도 독점과 수직통합이라는 전통적인 기업문화를 가지고 있던 거대기업이었다. 하지만 오픈소스 커뮤니티가지고 있는 다양한 특징과 수평적 협업이라는 문화를 받아들이면서 개방성에 의한 강한 성장 동력으로 기업을 업그레이드시킬 수 있었다.

IBM도 처음에는 지적재산권 문제를 놓고 많은 고민을 했으며, 경영진에서도 적잖은 저항이 있었다고 한다. 그러나 리눗스 운영위원회를 작동시키면서 매달 위원회를 통해 진행 상황을 평가하는 과정이 몇 달간 지속되자 오픈소스의 마법이 자연스럽게 사내문화로 흡수되었다.

이러한 IBM의 사례는 오픈소스 혁명이 단순한 사회현상에 머물러 있는 것이 아니라 기업의 혁신으로 이어지면서 새로운 가치창출을 할 수 있음을 극명하게 보여준다.

– 거의 모든 인터넷의 역사 p187 ~189 –

그대가 엉터리 개발자라는 신호들

크리스 웨넘은 ‘그대가 엉터리 개발자라는 신호들(Signs that you’re a bad programmer)’이라는 제목의 글에서 여섯 가지 신호를 이야기했다.

스스로 개발자인 저자 자신의 경험을 토대로 쓴 글이라는데, 내가 겪은 경험과도 정확하게 일치한다. 이러한 신호를 이야기하는 것은 우리 주변에서 누가 엉터리 개발자인지 골라내자는 것이 아니다. 오히려 좋은 프로그래머가 되기 위해서 누구나 거쳐 가는 단계라고 보는 편이 정확할 것이다.

우리는 모두 한 때는 (어쩌면 지금도) 엉터리 개발자였다.

첫 번째는 코드를 머리로 돌릴 수 있는 능력의 부재다.

엄청난 분량의 코드를 생각만으로 돌릴 수 있는 사람도 있고, 아주 짧은 코드만 돌릴 수 있는 사람도 있는데, 어쨌든 코드를 머리로 돌리는 능력은 개발자에게 기본이다. 이것은 바둑을 두는 프로기사에게 바둑판 위에 놓이지 않은 미래의 수를 읽어내는 능력이 필요한 것과 마찬가지다.

90년대에 빌 게이츠는 마이크로소프트가 수퍼스마트(Supersmart) 프로그래머만을 고용하기를 원한다고 말한 적이 있다. 그 말을 듣고 한 기자가 게이츠에게 수퍼스마트가 어떤 사람이냐고 물었다.

그러자 그는 자기가 작성한 코드의 내용을 6개월이 지난 시점에서도 컴퓨터 없이 (마치 눈앞에서 코드를 보고 있는 것처럼) 설명할 수 있는 사람이라고 대답했다.  그 정도까지는 아니더라도 회사에서 코드리뷰를 하다보면 자기가 아침에 작성한 코드의 내용을 설명하지 못하는 프로그래머가 있음을 알게 된다. 이런 개발자가 다른 사람이 작성한 코드를 읽을 수 없음은 물론이다. 이러한 능력의 부재는 어떤 면에서 노력으로 해결할 수 있는 것이 아니다.

이것은 개발자에게 필요한 최소한의 재능을 갖추지 못한 사례에 해당하므로 하루라도 빨리 다른 일을 시작하는 것이 더 나을 가능성이 높다.

두 번째는 자기가 사용하는 언어의 프로그래밍 모델을 제대로 이해하지 못하는 것이다.

이런 현상은 오랜 개발 경험을 쌓은 개발자 중에서도 어렵지 않게 발견된다. 객체지향 패러다임이 탑재된 C++가 처음 등장했을 때 많은 개발자들이 C++를 이용해서 C 코드를 작성했다. 마찬가지로 오랫동안 자바 언어를 사용해온 개발자가 객체지향 패러다임을 전혀 이해하지 못하고 있는 경우가 생각보다 많다. 함수 패러다임은 말할 필요도 없다.  오래 전에 자바 개발자를 고용하기 위한 기술인터뷰를 수행했을 때의 일이다. 내가 멀티쓰레딩과 관련한 질문을 하자 쓰레드 같은 것은 EJB 컨테이너가 알아서 관리해 주기 때문에 자기는 그런 것까지 알 필요가 없다고 대답한 사람이 있었다. 이런 사람은 이력서에 개발 경력이 5년이든 10년이든 상관이 없다. 끊임없는 학습과 자유분방한 창의력을 요구하는 프로그래밍이라는 행위를 기계적인 코딩, 단순히 반복되는 잡무, 혹은 하기 싫지만 어쩔 수 없이 하는 회사일로 대하는 사람은 앞으로 20년 동안 경험을 쌓아도 기술적으로 변화가 있을 리 없기 때문이다.

세 번째는 학습능력의 부재다.

요즘처럼 정보가 홍수처럼 쏟아져 나오는 시대에 그 모든 내용을 미리 다 알고 있는 사람이 어디에 있겠는가. 수많은 오픈소스 라이브러리, 새로운 기술, 패턴, 사례를 모두 꿰차고 있는 사람은 어디에도 없다.

많은 것을 알고 있는 것처럼 보이는 사람은 그만큼 열의를 갖고 학습을 하기 때문이다. 인터넷 검색을 하고, 코세라 강의를 듣고, 유투브 채널에 가입하고, 세미나에 참여하고, 책을 구입해서 읽으며 쉬지 않고 공부를 한다.

여기에서 중요한 것은 공부를 통해서 습득한 지식의 분량이 아니다. 중요한 것은 공부를 하는 방법, 즉 메타 지식에 해당하는 학습능력 자체다.  좋은 개발자는 낯선 기술이 등장하면 호기심을 품고 즐거운 심정이 되어 이곳저곳 건드려보지만, 엉터리 개발자는 입을 씰룩거리며 낯을 가린다. 이제 겨우 하나를 익혔더니 또 공부를 해야 하냐며 푸념을 한다. 낯선 대상을 두려워하는 것이 아니라 사실은 학습이라는 행위 자체를 두려워하는 것이다. 프로그래밍이라는 행위가 끝없는 학습으로 이루어져 있음을 이해하지 못하기 때문이다.

웨넘이 네 번째로 거론한 내용은 포인터(pointer)에 대한 이해부족인데, C나 C++를 사용하지 않으면 요즘에는 포인터를 직접 다룰 일이 없으므로 넘어가자. 웨넘의 이야기를 최근의 추세에 맞게 재구성하자면 타입시스템(type system)에 대한 이해부족이라고 이야기해도 좋을 것이다.

다섯 번째는 재귀(recursion) 알고리즘을 이해하는 능력이 없는 것이다.

이것은 맨 처음에 보았던 머리로 코드를 돌리는 능력과 밀접한 관련이 있다. 재귀를 이용해서 정수의 팩토리얼 값을 구하는 정도는 대부분의 개발자가 어렵지 않게 이해한다. 피보나치수열까지도 괜찮다. 트리구조의 노드를 순차적으로 방문하는 알고리즘도 기본적인 것까지는 무리 없이 이해한다.  하지만 하노이의 탑과 같은 알고리즘이 등장하면 숨이 막히기 시작한다. 꼬리재귀(tail recursion)가 왜 효율적인지, 일반적인 재귀 알고리즘을 어떻게 꼬리재귀 알고리즘으로 변환할 수 있는지 등을 이야기하다보면 한계를 느낀다. 이런 사람들은 개발자가 되어서 실전에 배치되어도 운영체제의 루프백(loopback) 주소라는 개념을 이해하지 못해서 애를 먹는다. 재귀라는 알고리즘의 작동방식이 머릿속에서 그려지지 않는 탓이다.

마지막은 코드에 대한 불신이다. 엉터리 개발자들은 정작 믿지 않아야 하는 코드를 신뢰하고, 믿어도 좋은 코드를 불신한다. 유닛테스트 코드를 작성하라고 시키면 실제로 검사되어야 하는 코드를 테스트하는 것이 아니라, 언어자체의 문법이나 라이브러리 코드의 API를 확인하는데 시간을 보낸다. 버그 투성이인 자신의 코드에 애착을 품고, 철저하게 검증된 라이브러리 코드를 의심한다.

전부는 아니더라도 이러한 여섯 가지 중에서 한 두 항목에서 뜨끔한 기분을 느낀 사람이 있을 것이다. 다시 한 번 말하지만 이 글의 목적은 엉터리 개발자를 추궁하자는 것이 아니다.

좋은 프로그래머가 되기 위해서 우리가 밟아온 과정, 혹은 앞으로 밟아야 하는 과정을 환기하여 다 같이 행복한 프로그래밍을 하자는 것이 목적이다. 다음에 기회가 있으면 “그대가 훌륭한 개발자라는 신호들”에 대해서도 이야기하도록 하겠다.

– 임백준 IT칼럼니스트 中 –

IT 역사(2000 ~ 2010)

2000 : 닷컴 버블 붕괴, 7개월간 나스닥 주가 78퍼센트 하락

야후, 구글을 공식 검색엔진으로 사용

구글 전 세계 검색 건수의 40퍼센트 점유

애플, 맥월드에서 맥 OS X 발표

마이크로소프트, 윈도2000 출시

마이크로소프트, MSN 메신저3.0에 인터넷전화 서비스 구현

2001 : 애플, 맥월드에서 ‘디지털 허브’ 전략 발표

마이크로소프트, CES에서 ‘디지털 라이프스타일’ 전략 발표

마이크로소프트 엑스박스 공식 발표

구글, 에릭 슈미트 CEO로 선임

애플, 아이팟과 애플스토어 발표

마이크로소프트, 윈도XP 발표

2002 : 야후, 검색엔진 잉크토미 인수

구글, 검색광고 애드워즈 발표

구글북스 프로젝트 시작

프렌스터, 미국 최초 소셜 웹 서비스 시작

2003 : 야후, 구글과 검색엔진 계약 파기

애플, 아이튠스 뮤직스토어 오픈

마이스페이스 서비스 시작, 음악 커뮤니티를 중심으로 큰 인기

구글, 피라랩스 합볍으로 블로거닷컴 서비스 시작

2004 : 구글 나스닥 상장

마크 주커버그, 페이스북 창업

에반 윌리엄스, 트위터의 전신이 되는 오데오 창업

2005 : 미국 출판인협회와 작가들, 구글북스 프로젝트에 대한 저작권 침해소송 제기

구글, 구글 지도와 구글 어스 서비스 시작

루퍼트 머독의 뉴스코퍼레이션스, 마이스페이스 인수

스티브 첸, 채드 헐리와 조드 카림, 유튜브 창업

구글, 안드로이드 인수

2006 : 구글, 유튜브 인수합병

트위터, 첫 서비스 시작

2007 : 마이크로소프트, 윈도비스타 출시

애플, 아이폰 발표로 스마트폰 시장 장악

구글, 더블클릭 인수로 온라인 광고 분야 독점적 지위 구축

마이크로소프트, 페이스북에 투자

아마존, 킨들 발표

2008 : 쉐릴 샌드버그, 구글을 떠나 페이스북 COO로 취임

2009 : 페이스북, 프렌드피드 인수합병

마이크로소프트, 윈도7 발표

애플, 아이폰 3GS 발표

2010 : 구글, 소셜 웹을 위한 인재 영입

애플, 아이패드 출시

애플, 아이폰4 발표

구글, 구글 TV 계획 발표

IT 역사(1990 ~ 1999)

1990 : 어도비, 매킨토시용 포토샵 발표

마이크로소프트, 윈도3.0 발표

1991 : 애플, 파워북 발표

스티브 잡스, 로렌과 결혼

라누스 토발즈, 리눅스 커널 개발

썬 마이크로시스템즈 제임스 고슬링, 자바 프로그래밍 언어 개발 시작

1992 : 마이크로소프트, 윈도3.1 발표

1993 : 마크 앤드리센, 에릭 비냐, 모자이크 완성

세르게이 브린, 스탠퍼드 대학원 입학

존 스컬리, 애플 CEO에서 사임

마이클 스핀들러의 애플시대 시작

1994 : 빌 게이츠, 멜린다와 결혼

마크 앤드리센, 넷스케이프 커뮤니게이션스 창업

넷스케이프 네비게이터 첫 번째 버전 발표

제리 앙과 데이빗 파일로, 야후의 전신 서비스 시작

IBM, CS/2 운영체제 발표

1995 : 넷스케이프, 기업공개, 닷컴 버블 시작

마이크로소프트, 윈도95 발표

마이크로소프트, 원도95 플러스! 팩에 인터넷 익스플로러 기본 탑재

제리 앙과 데이빗 파일로, 야후 창업

세콰이어 캐피탈, 야후에 투자 결정

제프 베조스, 아마존 창업

피에르 오미디아르, 이베이 창업

썬 마이크로시스템스, 자바 프로그래밍 언어와 개발도구 공개

래리 페이지, 스탠퍼드 대학원에 입학

세르게이 브린과 만남

1996 : 야후, 나스닥 상장

IBM, 로터스 도미노 웹 서버 발표

구글, 스탠퍼드 대학에서 백럽 서비스 시작

애플, 마이클 스핀들러 사임

길 아멜리오 CEO 임명

애플, 스티브 잡스의 넥스트 인수

1997 : 마이크로소프트, IE4.0발표

아마존, 나스닥 상장

애플, 스티브 잡스를 iCEO로 선임

마이크로소프트, 핫메일 인수

1998 : 애플, 아이맥 발표

스티브 잡스, 빌 게이츠 회담 후 협력 약속

마이크로소프트, 윈도 98 발표

익스플로러 브라우저 전쟁에서 승리

넷스케이프, AOL에 매각

이베이, 나스닥 상장

구글, 앤디 벡톨샤임의 창업자금으로 창업

1999 : KPCB와 세콰이어 캐피탈, 한 회사(구글)에 동시 투자

마이크로소프트, 핫메일 계정을 중심으로 패스포트 시스템 시작

마이크로소프트, MSN 메신저 서비스 시작

에반 윌리엄스, 블로거닷컴 서비스 시작

IT 역사(1955 ~ 1989)

1955 : 스티브 잡스, 빌 게이츠, 에릭 슈미트 탄생

1968 : 빌 게이츠, 폴 알렌과 만남

1970 : 스티브 잡스, 스티브 워즈니악과 만남

팔로알토에 제록스 파크 연구소 설림됨

1972 : 스티브 잡스, 오리건 리드 대학에 입학

빌 게이츠, 트래프-오-데이터 창업

1973 : 빌 게이츠, 하버드 대학 입학

스티브 발머와 만남

세르게이 브린, 래리 페이지 탄생

게리 킬달, CP/M 개발

제록스 파크 연구소, GUI가 구현된 컴퓨터 알토 개발

1974 : 스티브 잡스, 아타리에 입사

1975 : 빌 게이츠, 마이크로소프트 창업

1976 : 스티브 잡스, 스티브 워즈니악, 로널드 웨인 애플 컴퓨터 창업

애플I 출시, 200여대 전도 판매 성공

1977 : 애플컴퓨터, 애플II 출시

1978 : 마이크로소프트의 일본 법인 ASCII 마이크로소프트 설립

애플, 애플II와 리사 프로젝트를 시작

1979 : 마이크로소프트, 시애틀로 이전

애플, 애플II+ 출시

애플, 매킨토시 프로젝트 팀 조직

최초의 킬러 소프트웨어, 비지캘크 출시

세르게이 브린, 소련에서 미국으로 이민

1980 : IBM, PC사업에 시작

애플, 기업 공개, 포드의 기업공개 이후 최대의 자금이 몰림

스티브 발머, 마이크로소프트 합류

애플, 애플III 발표

1981 : IBM, 첫 번째 PC발표

스티브 잡스, 매킨토시 팀에 합류

마이크로소프트, 86-DOS 권리를 사들여 MS-DOS 개발

스티브 워즈니악, 비행기 사고 당함

1982 : 최초의 IBM PC호환 클론 제품이 탄생

1983 : 애플, 리사 컴퓨터 출시

스티브 워즈니악, 애플로 복귀

존 스컬리, 펩시콜라를 떠나 애플 CEO 취임

로터스 1-2-3 발표

1984 : 애플, 애플III 공식적으로 생산 중지

애플, 매킨토시 컴퓨터 출시

광고계의 기념비적인 작품 ‘1984’ 상영

IBM AT 기종 출시

마이크로소프트, MS-DOS 3.0 출시

HP, 잉크젯 프린터 상용화에 성공

마이클 델, 델 컴퓨터 창업

1985 : 스티브 잡스, 애플에서 퇴사

마이크로소프트, 윈도1.0 출시

애플, 어도비의 포스트스크립트 기술을 받아들여 레이저라이터 출시

전자출판시대 개막

1986 : 존 스컬리, 전자출판과 그래픽 분야에 매진하여 애플 흑자전환

어도비, 매킨토시용 일러스트레이터 발표

스티브 잡스, 조지루카스로부터 존 래스터 그룹을 인수 후 픽사 창업

1987 : 마이크로소프트 윈도2.0 출시

1988 : 애플, 마이크로소프트를 상대로 윈도에 대한 특허침해 소송 제기

1989 : 워드퍼펙트 5.1 발표

마이크로소프트 오피스 탄생

팀 버너스-리, 웹 구현

훌륭한 엔지니어가 되기 위해서

훌륭한 엔지니어가 되기 위해서는 먼저 뛰어난 엔지니어가 될 필요가 있다. 뛰어난 엔지니어가 되기 위해서는 자신이 좋아하는 일을 할 필요가 있다.

……

공부하는 것이 재미가 있는 이유는 자신이 그 일을 좋아하기 때문이고, 자신이 그 일을 좋아하는 이유는 자신이 그 일을 잘 할 수 있기 때문이다.

잘해야 재미가 있다. 잘하지 못하면 재미도 없다.

….

잘하지 못하는데 재미난 일이 있을까? 그렇다면 이야기하는 사람도 있을 것이다. 가령 악기 연주 같은 일을 예를 들면 언뜻 보기에 악기 연주와 같은 일은 잘하지 못하지만 재미있어하는 사람들이 제법 있는 것 같다. 하지만 그들도 살펴보면 어느 정도 악기 연주를 할 수 있는 사람들이다. 악기 연주를 아예 처음 하는 사람이라면 따분하지만 지루한 악기 연주 기초를 마스터해야만 한다. 재미는 그 이후에 일이다.

이렇듯 재미가 있으려면 자신이 그 일을 잘할 수 있어야 한다. 개발도 마찬가지다.

개발을 잘하려면 개발에 재미가 있어야 하고, 개발이 재미가 있으려면 개발을 잘해야 한다. 참으로 모순이 아닐 수 없다. 풀기 힘들 것 같은 모순이지만 이 모순을 푸는 일은 의외로 간단하다. 잘하든 재미가 있든 둘 중의 하나만 먼저 하면 되는 것이다. 그러데 결국 모든 문제의 핵심은 공부와 직결된다. 우선 재미가 없다면 열심히 공부해서 잘하면 된다. 반대로 잘하지 못한다면 재미를 붙이면 된다. 재미를 붙이기 위해서는 잘하면 되고 잘하기 위해서는 공부하면 된다.

결국 모든 문제를 풀 수 있는 해답은 공부하는 것이다. 그럼 따분한 공부를 언제까지 계속해야만 되는 것인가? 그렇지 않다. 현재 자신의 평균적인 위치에서 다른사람보다 잘 할 수 있으 정도면 된다. 이렇게만 해놓으면 세계적으로도 잘할 가능성이 생긴다.

왜냐하면, 남들보다 잘하기 때문에 재미있게 되고, 재미있기 때문에 더 잘할 수 있고, 더 잘할 수 있기 때문에 더 재미를 느끼게 된다. 이렇게 몇 번의 선순환 사이클을 그리다 보면 어느 순간 세계적으로도 잘할 수 있는 사람이 되는 것이다. 자신이 세계적으로 잘하는 사람이 되었다고 가정해보라 자신이 하는 일이 얼마나 재미가 있겠는가?

이러한 선순환의 첫 시작은 열심히 공부해서 동급 사람보다 잘 하는 것이다. 거기까지만 하면 된다. 이후부터는 선순환의 사이클이 여러분을 성공의 길로 이끌 것이다.

– 프로그래머로 사는 법 #553 ~ 555 백창우