주인이 되자

책을 읽으면서 눈물이 주루룩 흘렀다.

나는 사실 우리 한국 현대사를 잘 몰랐던 것 같다. 대학 신입생 때 선배들을 따라 정치 학회에 가서, 박정희, 전두환 군사 정권의 탄압에 대한 이야기를 들었지만, 그저 먼나라 이야기 같았고, 가슴이 아닌 머리로만 이해했던 것 같다.

몇 해 전, 고 김대중 전 대통령의 ‘김대중 자서전’을, 베스트 셀러라는 이유로 샀다. 1400페이지에 이르는 분량에 압도되어, 한 보름 동안은 방치했던 것 같다. 어느 일요일 오전이었던가 무심코 책을 폈다. 어렸을 적 섬마을의 똘똘한 김대중 어린이의 이야기가 흥미로웠다. 사업가로서 성공하는 이야기도 참 신났다.

즐거운 이야기는 거기까지였다.

책을 읽다보니 김대중 선생의 입장에서, 6.25 전쟁 중에 공산군에 의해 감옥에 갇혀 언제 죽을 지 모르는 공포를 경험했고, 4.19 혁명으로 잠시나마 민주화된 대한민국을 경험했다. 또, 지역 감정이 없던 시절, 강원도 인제에서 국회의원으로 당선되고 젊은 나이에 당 대변인이되지만, 5.16 쿠테타로 국회에 입성하지 못해 억울해하기도 했다.

유신정권의 탄압을 피해 일본에서 활동하던  중에 중앙정보부 요원에 의해 납치되어 생사의 갈림길에서 겨우 탈출해서 살아 남았고, 트럭이 승용차를 덮치는 의문의 사고로 죽을 뻔한 위기를 넘었다. 박정희 독재 정권 하에서 온갖 죄목을 뒤집어 쓰고 차디찬 형무소에 몇년을 지냈다. 그리고, 전두환 군사정권이 들어서고 내란죄로 사형선고까지 받고서, 사형수로서 집행일만 기다리는 극한의 공포를, 나는 느꼈다.

그렇게 그렇게 우리 선배들은 민주화를 위해 투쟁을 했다. 내가 지금 아무렇지도 않게 누리는 민주주의는 그렇게 얻어진 것이다. 시간이 됐으니 하늘에서 뚝 떨어진 것이 아니라, 인간의 존엄성을 지키고자, 수많은 사람들이 목숨을 걸고 싸워서 얻어낸 것이다. 안타깝지만 많은 사람들이 민주화된 대한민국을 못본채 그렇게 눈을 감았다.

책을 읽으며, 이들이 겪었을 울분을 생각하니 눈물이 주루륵 흘렀다. 거대한 권력앞에 공포를 느끼면서도, 옳은 것을 행하는 용기에 눈물이 주루륵 흘렀다. 나는 과연 이런 상황에 이렇게 행동할 수 있었을까 생각하니 마냥 부끄럽고, 죄송스러운 마음이 들었다.

우리는 민주화를 위해 싸운 기성세대에 빚을 지고 있다. 갚아야 할 빚이다. 빚을 갚는 방법은 단순 명료하다. 민주주의를 지켜내고 후손에게 물려주는 것이다. 아직 우리 사회에 남아 있는, 독재 시대의 반 민주주의적 가치관을 가진 기득권 세력으로부터 민주주의를 지켜내야 한다. 그러나 이것은 기득권에 빌붙은 수구 언론과 양심을 버린 학자들 때문에 쉬운 일은 아니다. 하지만, 우리가 현대사를 공부하고, 시대 정신을 이해하려 노력하면 할 수 있다. 그리고, 최근에는 대안 매체를 통해 옳은 목소리를 내는 언론도 있다. 무엇이 옳은 것인지 깊은 고민을 해야하고, 단호하게 행동 해야 한다.

우리나라의 민주주의는 아직 진행형이다. 냉철한 판단과 뚝심있는 행동으로 스스로 주인이 되자. 우리 선배들이 힘들게 쌓아올린 민주주의를 지켜내서, 우리 후배 세대에게 당당할 수 있도록 역사에 기록되자. 내가 있고, 너가 있으니 우리는 할수있다, 친구야.

Scala 시작하기

요즘 들어서 Scala를 공부하고 있다. 아직 많이 부족하지만, 지금까지 배운 것들 기록해두고, 또 혹시 조금이라도 도움이 되는 분들이 있을 지 몰라 공유해보고자 한다.

1. 들어가며


뭘 또 배워야 한단 말인가? 이미 C++, Java, Python, Ruby, JavaScript 등 많은 프로그래밍 언어들이 있는데, 왜 자꾸 새로운 언어가 나오고 있냐? 기존 걸로 안되냐?

라는 의문을 가질 수 있다. 나 역시 처음에 그런 생각을 했었다. 하지만, Scala에 대해 공부를 하다 보니, 이제는 그런 의문들이 많이 없어졌다. 어떻게 의문을 해소했었는지, 그럼 조금 자세히 이야기 해보겠다.

2. Scala?


Scala는 다음과 같은 특징이 있다.

2.1 Fuctional language이며 또한 object-oriented language이다.

Ruby나 C#을 쓰다가 Java나 C++ 같은 언어를 쓸 때 조금 답답한 것이, lambda와 같은 functioncal language적인 syntax가 없다는 것이다. 이것을 안 쓸때는 몰랐는데, 일단 손에 익으면 생산성이 매우 높아진다. Scala는 lambda를 비롯하여 여러 functional language의 문법을 지원한다. 동시에, object-oriented적인 요소도 지원하기 때문에, objected-oriented language에 익숙한 프로그래머들이 functional language를 배우고자 할 때 쉽게 다가갈 수 있다.

나는 C++이 초기에 다른 object-oriented language들을 제치고 성공할 수 있었던 가장 큰 이유가, C++이 C 문법도 지원했기 때문이라고 생각한다. C++ 컴파일러를 이용하면, C에 익숙한 프로그래머들은 C로 코딩을 하면서도, 부분부분 쉽게 object-oriented적인 요소를 사용할 수 있었다. 마찬가지로 Scala는 기존의 Java나 C++등 object-oriented language에 익숙한 프로그래머들을 functional language로 쉽게 끌어 들일 수 있는 장점이 있다.

2.2 Java Virtual Machine에서 동작한다.

Java Virtual Machine(이하 JVM)은 Java를 컴파일해서 나오는 bytecode가 동작하는 virtual machine이다. Scala는 특이하게도 소스 코드를 컴파일하면 그 결과로 JVM에서 동작하는 bytecode가 결과물로 나온다. 다시 말해 Scala는 JVM상에서 동작한다.

이것은 두 가지 중요한 의미를 갖는다. 하나는 컴파일 된 Scala 코드는 이미 10년 이상 최적화가 되어 있는 JVM 상에서 동작하기 때문에, 성능과 안정성을 어느 정도 보장한다.

또, 기존에 Java로 작성된 소스와 호환이 되기 때문에, 엄청나게 많은 Java 라이브러리들을 Scala에서 그대로 사용할 수 있다. 야호!

3. Who uses Scala?


Scala를 누가 쓰기는 쓰는가? 생각보다 많이 쓰고 있고, 점차 더 도입되는 추세인 것 같다. 대표적으로 다음과 같은 회사들이 사용한다.

3.1 Twitter

Twitter 서비스는 초기에 Ruby on Rails를 이용하여 개발되었다. 그런데 Ruby on Rails를 이용해 빨리 개발할 수는 있었지만, 이후에 traffic이 많아 지면서 성능이 문제가 되었다. 이를 해결하기 위해 Scala를 도입하였다고 한다. 트위터 개발자들의 인터뷰 참고.

3.2 FourSquare

FourSquare 서비스는 초기 버전은 PHP로 작성되었다고 한다. 하지만 사용자가 급증하자 software stack에 변화가 필요했고, Harry Heymann이라는 엔지니어가 이 작업을 주도하면서 Scala로 전면적으로 다시 개발했다고 한다. 이 과정에서 생산성 향상과 성능 향상이 있었다는 이야기도 있다. Scala 공식 홈페이지에 관련된 글이 있으니 참고.

3.3 Tumblr

Tumblr 또한 부분적으로 Scala를 쓰고 있다고 한다. Back-end용으로 쓰이고 있고, Twitter에서 만든 Scala용 라이브러리인 Finagle을 이용해 사용한다고 알려져 있다. Tumblr의 개발 방식에 대해 정리된 페이지 참고.

4. Scala 시작하기


Scala에 대한 흥미가 조금은 생겼으리라 예상해본다. 그럼 다음과 같은 자료를 활용해서 공부를 시작해보자.

4.1 Scala for the impatient

프로그래밍 경험이 어느 정도 있는 분들에게 추천하는 책이다. 제목에서도 알 수 있듯이 빨리 문법을 익혀 코딩해보고자 한다면 좋은 선택이다. 중요한 문법에 대해서 간결하게 잘 설명되어 있다. 공짜다.

4.2 Twitter Scala School

Twitter에서 만든 교육 자료이다. 아마도, 자사의 엔지니어들을 위해 만들지 않았나 생각된다. 내용이 간결하고, 예제 위주로 되어 있어서 빨리 익히기에 좋다.

4.3 Programming Scala

Scala의 동작 원리부터 차근차근 잘 설명한 책이다. Scala에 대해 좀더 깊이 이해를 하고자 하는 경우나 또는  프로그래밍 경험이 많지 않은 분들에게 추천하고 싶다. 역시 공짜다.

Programming language들이 많이 나오면서, 요즘은 각 language community들이 적극적으로 확산에 나서고 있고, 그래서 무료 자료가 참 많다. Scala를 공부하기 위해서, 굳이 돈주고 종이책 살 필요는 없을 듯 하다.

5. 개발 환경


5.1 build

Scala는 컴파일 language이기 때문에, build를 해주어야 한다. 물론 소스 하나씩 compile해서 build하는 방법도 있겠지만, 이것보다는 별도의 build 툴을 쓰면 편하다. 많은 scala 오픈 소스 프로젝트들이 최근에 simple build tool(이하 sbt)를 사용하고 있다. 사용법이 길지 않으니 꼭 사용법을 읽어보는 것이 나중에 수고를 덜어줄 것이다.

5.2 IDE

개발툴로 많이 쓰이는 것이 Eclipse와 IntelliJ IDEA이다. 2개 모두 사용해봤는데, 둘 다 괜찮다. Eclipse는 Scala IDE for Eclispe라는 plugin을 설치해야 하고, IntelliJ IDEA도 JetBrains에서 제공하는 Scala plugin을 설치해야 한다. 둘다 Syntax highlighting, debugging 등의 기능이 있어서 Vim이나 Emacs같은 에디터 보다 낫지 않나 싶다.

6. Hello World


그럼 간단한 프로그램을 만들고, debugging까지 해보겠다. 기본적인 순서는 다음과 같다.

  1. Eclipse 설치
  2. Scala IDE for Eclipse Plug-in 설치
  3. sbt 설치
  4. sbt용 디렉토리 구성
  5. sbt를 이용해 Eclipse 프로젝트 생성
  6. 소스 코드 작성
  7. Debugging

6.1 Eclipse 설치

Eclipse는 3.6(Helios) 버전을 설치한다.

6.2 Scala IDE for Eclipse

Eclipse용 scala plugin인 Scala IDE for Eclipse를 설치한다.

6.3 sbt 설치

이 링크를 이용하여 sbt를 설치한다.

참고로, sbt를 설명하는 wiki 페이지가 길지 않으니, 반드시 읽어보고 sbt의 개념이나 사용 방법을 알아두는 것이 나중에 시간을 줄일 수 있는 방법이다.

6.4 sbt용 디렉토리 구성

프로젝트의 기본 정보 및 사용하는 이 프로젝트에서 사용하는 플러그인을 설정하여 sbt용 디렉토리 및 설정파일을 구성한다. 이 부분은 sbt 메뉴얼을 참고하도록 한다.

6.5 sbt를 이용해 Eclipse 프로젝트 생성

앞에서 만든 sbt용 디렉토리로 들어가서 다음과 같이 입력하면 Eclipse용 프로젝트 파일인 .project와 .classpath가 생긴다.

> sbt eclipse

Ecilpse의 메뉴에서 ‘File’ > ‘‘Import…’를 클릭하고, 앞에서 만든 디렉토리를 선택하면 프로젝트를 열 수 있다.

6.6 소스 코드 작성

Ecilpse에서 앞에서 생성한 프로젝트를 열어보면 이미 ‘src/main/scala’ package가 생성된 것을 확인 할 수 있다. 이 package 밑에 App.scala 파일을 만들고 다음과 같이 입력한다.

object App {
  def main(args: Array[String]) {
    println("Hello, world!")
  }
}

6.7 Debugging 하기

이제 거의 다 되었다. println에 breakpoint를 설정하고, 메뉴의 ‘Run’ > ‘Debug’를 선택한 후에 ‘Scala Application’을 선택하면 프로그램이 시작되고, debugger가 동작해서 breakpoint에서 멈추는 것을 확인할 수 있다. 위 소스 파일은 이 곳에서 다운로드 받을 수 있다.

7. Scala용 Framework


이제 Scala용 프로그램을 만들 준비는 끝났다. 지금부터는 웹서비스 개발을 위해 이용할 수 있는 Framework 중에 개인적으로 제일 괜찮다고 보이는 2가지를 소개하려고 한다.

7.1 Play Framework

Play Framework는 Ruby on Rails의 Java 버전이라고 보면 되겠다. MVC 패턴에 맞춰 개발할 수 있도록 해주고, 여러가지 편리한 library를 제공한다. 실제 대용량 서비스에서 많이 쓰이고 있는 framework이라 안정성에도 문제가 없다고 할 수 있겠다.

현재 stable한 1.x 버전에서는 scala를 부분적으로 지원해서 조금 아쉽다. 하지만, Play 2.0에서는 본격적으로 Scala를 지원한다. 2.0은 현재 RC버전이며, 곧 정식 버전을 release할 것으로 보인다.

7.2 Finagle

Finagle은 Twitter에서 back-end 서비스용으로 만든 framework이다. 서버 간의 통신을 지원하는데 특화 되어 있다. 무엇보다 Twitter에서 실제로 사용되기 때문에 주목 받고 있고, Tumblr등 다른 서비스에서도 이용되는 듯 하다. 기본적인 서버 간 통신 기능 외에 비동기 처리, 분산 처리, 그리고 Memchached, Redis 등을 지원한다. Twitter에서 어떤 식으로 Finagle을 사용하는 지에 대해서는 Twitter Engineering 블로그의 이 포스팅에 잘 설명이 되어 있다.

8. 마치며


당연하겠지만, 소프트웨어 개발에 있어 어떤 언어가 최고인지 정답은 없는 것 같다. 상황에 맞게 언어와 라이브러리 등을 선택해야 할 것이다. 성능과 확장성(scaling)이 매우 중요하고, 비교적 빠르게 개발해야 하는 경우 라면, 내가 생각하기에 Scala가 제일 적합한 선택인 것 같다. 단, Scala 개발자가 많지 않고 언어를 배우는데에 learning curve가 조금 있기 때문에, 개발자가 바뀌는 상황이 되었을 때 향후 유지보수는 조금 어려울 수도 있다는 점은 주의해야 한다.

무엇보다도 Scala의 장점은 succint한 syntax 덕에, 개발자가 프로그래밍 그 자체에 집중할 수 있고 이로 인해 프로그래밍이 재미있다는 점이다. 좀더 많은 개발자들이 Scala를 접해보았으면 하는 바램으로 두서없는 글을 마치겠다.

오픈(open)에 대하여

솔직하게 고백하면서 시작하겠다.

Linux를 비롯한 오픈 소스와 그 개발 방식이 유행하기 시작할 때, 일부 컴퓨터 긱(geek)들의 문화라 치부했고, 주류가 되지 못할 거라고 생각했다. Microsoft나 Oracle이 하는 것처럼 소프트웨어는 과금을 해야 하고, 이 수익을 다시 소프트웨어에 투자해야 제대로 된 소프트웨어가 나올 것이라고 생각했다.

하지만, 틀린 것 같다. 지금 세상을 움직이는 많은 소프트웨어들은 오픈소스 프로젝트이고, 그리고 점점 많은 회사들이 오픈된 개발 문화를 지향하고 있다.

오픈 소스와 오픈 소스 개발 방식 그리고 그 근저의 철학에 대해서 생각해 본 바를 정리하고자 한다. 잘못된 시각일 수도 있고, 편협한 시각일 수도 있다. 그러니 이 글을 읽으신 분께서는 어떤 내용이라도 좋으니 피드백을~

1. Open Source?

간단히 정의하면, 오픈 소스는 소프트웨어의 소스 코드를 공개해 다른 사람이 이용할 수 있도록 하는 것을 말한다. 건축으로 치면 설계도를 공개하는 것이고, 학교 생활로 비유해보면, 열심히 한 숙제를 공개해서 누구나 베낄 수 있게 하는 것이라고 할 수 있겠다.

아, 보통의 사고 방식이라면 참으로 이해할 수 없는 방식이다. 왜 나의 노하우와 노력의 결실을 공개하는 것인가? 왜 다른 사람들이 별다른 노력 없이 내가 만든 걸 쓸 수 있게 하는 것인가? 누가 이렇게 한단 말인가?

놀랍게도 지금의 인터넷 세상을 가능하게 하는 많은 기술들이 사실은 오픈 소스 프로젝트들이다. 서버 OS로 이용되는 Linux, Database 솔루션인 MySQL, 웹서버 솔루션인 Apache, 대용량 처리를 가능하게 해주는 Hadoop 등이 오픈소스다. 거꾸로 이러한 오픈소스가 없었다면 Facebook이나 Twitter, KakakoTalk등이 없었을 지도 모르겠다.

2. Open Source 개발 방식?

오픈 소스 프로젝트들은 소스를 공개하는 것과 더불어서, 자신들의 소스가 많이 쓰일 수 있도록 여러 적극적인 활동을 한다. 익명의 개발자가 코드에 기여(contribution)를 할 수 있도록 프로세스를 갖추고 있고, 소스의 내부 구조(architecture)와 사용 방법에 대해 블로그와 컨퍼런스 등을 통해 알린다. 이러한 활동을 열심히 하는 오픈 소스 프로젝트들이 더욱 많이 사용되고 살아남는다.

요즘은 소프트웨어 회사에서 소스를 꼭 공개하지 않더라도, 이러한 개발 방식을 도입한 사례를 종종 볼 수 있다. 자사가 사용한 오픈소스 솔루션에 대해 사용 경험(best practice)을 블로그나 컨퍼런스 등을 통해 공유하고 있다.

3. 누가하는가?

Facebook이나 Twitter와 같은 회사들이 아이디어를 잘 만들어 성공한 회사라고 생각하면 오산이다. 적어도 내가 아는 한 이 두 회사는 컴퓨터공학에 있어서, 구글과 어깨를 나란히 하는 세계 최고의 기술 회사이다. 많은 오픈 소스 프로젝트들의 스폰서이고, 그리고 이 이 회사들의 엔지니어들이 직접 오픈소스 프로젝트에 참여하고 있다. 그리고, 이 오픈 소스를 자사의 서비스에 이용하고 있다. 특히 최근의 대용량 서비스를 가능하게 해주는 솔루션인 Cassandra, Hadoop 등이 바로 그 예이다.  국내에서도 NHN, Daum, KTH와 같은 회사에서는 컨퍼런스나 블로그를 통해서 노하우를 공유하고, 이따금씩 자사의 솔루션을 오픈 소스화 하고 있다.

누구도 부인하지 못하는 점은, 이 회사들이 이렇게 자사의 엔지니어들이 만든 소스를 오픈하면서도 성공을 하고 있고, 또 그들의 서비스들이 유사한 서비스를 제치고 지속되고 있다는 점이다.

4. Why successful?

솔직히 아직도 잘 모르겠다. 그저 짧은 지식으로 나름 파악해본 바는 다음과 같다.

4.1 집단 지성이 발휘된다

오픈 소스들의 특징은 commitor라 불리는 소스를 직접 컨트롤 하는 사람들외에도 익명의 다수 사람들이 기여할 수 있다는 점이다. 물론 오픈 소스가 지향하는 큰 방향은 commitor들에 의해 결정이 되겠지만, 자잘한 버그들이나 성능 개선 등은 익명의 수많은 프로그래머들에 이루어 지는 듯 하다. 마치 Wikipedia가 수많은 사람들의 참여로 브리태니커(Britannica) 백과 사전보다 그 내용이 우수한 것과 같은 이유가 아닌가 생각 된다.

4.2 참여자의 자기 만족이 크다

오픈 소스 프로젝트들은 저마다 정의한 문제를 각각의 시각으로 풀어내고 있다. 때문에 비슷한 솔루션을 여기 저기서 만드는 것이 아니라, 각각 고유한 솔루션을 만들어 낸다. 프로그래머들 사이에서 많이 쓰이는 말 중에 ‘Don’t reinvent the wheel’이라는 말이 있다. 똑같은 작업을 다시 싫어하기 싫어하는 프로그래머들의 특성을 잘 보여주는 말이 있는데, 오픈 소스에서는 이럴 가능성이 적다. 이것이 참여자의 생산성을 높여주는 것이 아닌가 생각된다.

또, 오픈소스에 참여하는 개발자는 자신이 가치 있는 일에 기여하고 있고, 이것이 오픈 소스를 통해 알려지고 명예를 얻는 것에 만족감을 느끼는 것 같다.

개발자들이 오픈소스에 참여하는 이유에 대해서는 @sm_park님께서 잘 정리해주신 소프트웨어, 잉여와 공포를 참고하기를.

5. 기업 입장에서 Open이란?

그러면 개개의 기업들은 오픈 소스와 오픈 소스 개발 문화를 어떻게 보고 어떻게 접근해야 할까?

기업 입장에서 오픈 소스 솔루션 자체를 도입하는 것은 좋은 점, 나쁜 점 모두 있는 것 같다. 당연히 새로 개발을 안하고, 어느 정도 검증된 솔루션을 쓸 수 있다는 것은 장점이다.

하지만, 간과해서는 안되는 부분이, 기술 회사를 지향한다면 오픈 소스를 도입하는 것과 더불어 자사의 기술 역량을 높이는 것을 게을리 해서는 안되는 것 같다. 오픈 소스를 도입하는 것은 마치 어려운 수학 문제를 푸는 데에 있어서, 답안지를 펴놓고 하는 것과 비슷하다고 생각하기 때문이다. 한 문제의 답을 아는 것이 지금의 상황을 이겨나가기는 좋지만, 나중에 또 다른 어려움이 닥칠 것을 생각해보면 근본적으로 역량(capability)를 키워 놓는 것이 중요하지 않나 생각된다. 마치 숙제를 열심히 베끼다 보면 숙제는 빨리 할 수 있지만, 실력은 늘지 않는 것처럼.

이것을 좀 과장해 표현하자면, 오픈하는 쪽의 마수(?)에 걸리지 않도록 조심해야 한다. 그 방법 중에 하나는 오픈 소스를 도입함과 동시에 자신도 오픈하는 것이 아닌가 생각된다. 회사 입장에서 ‘오픈’은 그 의미가 여러가지 일 수 있는데, 넓은 의미로는 타사에 대한 오픈이고, 좁은 의미로는 개인과 팀의 성과물을 다른 팀에게 오픈하는 것이다. 그러면 이 두 가지 의미를 포괄해서, 회사 입장에서 ‘오픈’이 갖는 의미에 대해서 좀더 자세히 이야기해보겠다.

5.1 사내에서 갖는 의미

1) 품질이 올라간다.

누군가 내 코드를 보고 거기에 대해서 평가한다고 생각하면, 프로그래밍에 임하는 자세가 분명히 다를 것이다. 알면서도 무시했던 여러가지 프로그래밍 원칙들을 지키려고 노력할 것이다. 쪽팔리기 싫으니까.

많은 오픈 소스 코드들과 그동안 내가 회사에서 보았던 코드와 비교해보면, 품질에 있어서는 오픈 소스 코드들이 압도적이다. 프로그래밍의 기본 원칙부터, 그 구조에 있어서 디자인 패턴의 적용 등 모든 부분에 있어서 좋다. 나 스스로는 이런 오픈 소스의 소스를 보면서 많이 배우고 있다고 생각한다.

2) 장기적으로 도움이 된다.

예전에, 오픈 소스의 버그를 고치고, 이것을 오픈 소스 커뮤니티에 알려주지 않고 자기 회사에서만 쓰는 경우를 보았다. 단기적으로는, 이 오픈 소스를 사용하는 다른 제품에 비해 경쟁우위가 생겼을 지 몰라도, 장기적으로 보면 손해 보는 일이다. 오픈 소스 버전이 올라갈 때 마다 수동으로 이 버그의 패치를 따로 해줘야 하면서 생기는 관리 비용이 생기기 때문이다. 또, 결국 이런 버그들은 언젠가 패치가 될 텐데 그때 가서 이것을 반영(merge)하려면 별도의 수고가 들고, 이런 것들이 프로젝트의 위험요소(risk)가 될 수 있다.

5.2 사외적으로 갖는 의미

실력과 자신감을 바탕으로, 자사가 만든 소스를 오픈하거나 또는 자사의 경험을 공유하게 되면, 업계와 개발자 커뮤니티에서 주목을 받게 되고, 기술 리딩(leading)회사로서 입지를 다지게 되는 것 같다. 특히 국내의 경우에 이렇게 하는 회사가 많지 않아, 해외의 솔루션을 잘 이용한 경험을 공유 해도 단번에 주목 받는다.

이렇게 회사가 주목 받으면, 그 회사가 내놓는 서비스나 제품도 초기에 주목 받기가 쉽다. 또 이렇게 기술을 리딩하는 회사로 포지셔닝을 하면 훌륭한 인재를 모으기도 쉽다. 적어도 내 주변만 보아도, 여러 조건이 비슷하면 기술적으로 명망이 있는 회사로 지원하는 개발자들이 꽤 있었다.

5.3 도의적으로 갖는 의미

약간은 이상적인 측면에서도 조금 언급해보고 싶다. 간단히 말하면, 공짜로 받은 것이 있으면 공짜로 줄 줄도 알아야 하는 것이 아닌가 싶다. 매일 친구의 숙제를 베끼지 말고, 한번쯤은 나도 친구들에게 숙제의 소스(source)가 되어주자. 매번 친구들에게 신세만 지면 친구들이 하나 둘 없어질 것이 아닌가. 조금 고상하게 표현하자면, 이것이 회사의 사회적 역할인 것 같다.

마치며

이렇게 장황하게 open에 대해서 썼지만, open을 해야만 성공하는 것인 지에 대해서는 확신이 없다. 적어도 open을 하더라도 꼭 실패하는 것은 아니고,  성공을 할 수는 있다는 점은 이제 배운 것 같다.

아직 open에 대해 확신이 서지 않는 이유는, 여전히 오픈 소스 개발 문화와 정반대에 있으면서도 새롭게 성공하는 회사들이 많기 때문이다. 대표적으로 애플과 아마존이 있는데, 애플은 자사의 주요 프로젝트에 대해서는 사내 직원들도 모르게 진행하고 있고, 아마존도 자사의 소스를 오픈하는 경우는 드물다.

하지만, 적어도 내가 보기에 open을 하는 것이 성공 확률을 높일 수는 있는 것처럼 보인다. 무엇보다, 나는 오픈 소스와 오픈 소스 개발 문화가 더 멋지게 보인다. 그리고, 기업이 커지면 관료화 되고 회사가 재미없어지는, 조직 경영의 문제를 푸는 데에도 오픈 소스 개발 문화가 열쇠가 될 수 있지 않을까 생각하고 있다.

Web Framework Benchmark

최근 각광받고 있는 server-side language 및 그에 따른 web framework들의 성능(performance)이 얼마나 차이가 있는지 궁금해졌다. 보통 Ruby는 생산성(productivity)은 좋지만 성능은 좋지 않다라든지, 대용량 처리에 Erlang이 성능이 좋다라든지 이야기가 많은데, 정량적으로 얼마나 차이가 나는 것인지 실제로 확인해보려고 한다. 성능에 대해 좀더 정확히 알고 있다면, 성능과 개발기간 등의 요구사항에 맞는 language 및 web framework을 선택하는데 유용할 것 같기 때문이다.

1. Language & web frameworks


다음과 같은 기준으로 benchmark를 할 language와 framework를 선정해 보았다.

  • 생산성이 좋다고 알려진 것
  • 성능이 좋다고 알려진 것
  • 요즘 많이 쓰이는 것

1.1 Ruby + Sinatra

Ruby는 생산성이 좋다고 알려져서 최근에 스타트업에서 많이 이용하고 있다. 보통은 Ruby를 사용할 때 Rails를 web framework로 이용하는데, 테스트의 편의를 위해 Sinatra라고 하는 lightweight framework를 이용하였다. 또 Ruby에 기본으로 포함된 web server인 WEBrick이 성능이 좋지 않아서, ApachePassenger 조합의 web server를 이용하였다.

Ruby: v1.9.2

Sinatra: v1.3.2

Web server : Apache + Passenger

1.2 Java + Play framework 1

Java는 PHP와 더불어 가장 많이 쓰이는 server side language인 것 같다. 보통 많이 쓰이는 Spring대신에 최근에 인기 있는 Play framework(이하 Play)를 사용하였다. 실험에 사용된 Play의 버전은 가장 최신의 stable한 버전인 1.2.4이다.

Java: v6

Play: v1.2.4 (netty v3.2.5async-http-client v1.6.5)

1.3 Scala + Play framework 2

Scala는 functional language로 Java Virtual Machine(JVM)상에서 동작한다. 오랫동안 최적화 작업을 거친 JVM 상에서 동작하기 때문에 안정적이라고 알려져 있다. 또, Java와도 호환이 잘되는 것으로 알려져 있다. Scala는 ‘Scalable’에서 따온 이름이라고 하는데, 역시 그 이름처럼 Language 차원에서 병렬 프로그래밍을 지원하고 있어서 대용량 처리 시에 성능이 좋고, scalable 하다고 한다. 또, functional language답게 syntax가 간결해서 개발 생산성이 좋은 듯 하다.

Scala용 framework 중에서는 Lift, Play, Scalatra등이 많이 쓰이는데, 개인적으로 경험이 있는 Play를 선택하였다. 단, Play의 1.x 버전의 경우 Scala의 경우에 비동기(asynchronous) 관련 기능이 지원이 되지 않아서, 현재 개발중인 Play 2를 이용하였다. 소스를 받아 직접 빌드해서 사용했기 때문에 버전이 따로 없고, Beta와 곧 release할 RC1의 사이의 버전 정도로 보면 되겠다.

Scala: v2.9

Play: v2.0 개발 버전 (netty v3.3.0async-http-client v1.7.0)

1.4 Node.js

Client-side language인 JavaScript를 server-side에서 이용할 수 있도록, Chrome의 JavaScript 엔진인 V8을 포팅한 것이 node.js라고 한다. JavaScript가 기본적으로 비동기적으로 동작하기 때문에, node.js를 이용하여 서버에서도 이렇게 프로그래밍하는 경우 병렬 프로그래밍에 유리해 성능이 좋다고 알려져 있다. 최근에 주목을 받고 있어서, 진짜로 얼마나 좋은 지 궁금해서 대상에 포함시켜 보았다.

테스트의 편의를 위해서 Express라는 lightweight framework을 이용하였다.

Node.js: v0.6.7

Express: v2.5.6

1.5 Erlang

Erlang은 1980년대에 Ericsson에 의해 만들어진 functional language다. Erlang이라는 이름도 ‘Ericsson Language’를 줄인 것이라고 한다. CouchDB가 Erlang으로 만들어졌다고 알려져 있고, 최근에 WhatsApp이라는 어플이 Erlang을 이용해서 서버 프로그래밍을 했는데, 서버 1대가 2백만대의 client connection을 관리한다고 해서 깜짝 놀란 적이 있다.

Erlang에는 inets라는 HTTP client/server 모듈이 포함되어 있는데, 이것 대신에 Erlang에서 성능이 좋다고 알려진 Misultin이라는 web server를 이용하였다. Erlang Web Server 비교 자료는 이 글을 참고하였다.

Erlang: R15B

Web server: Misultin v0.8

1.6 Else

참고로, PHP는 초기 생산성은 좋으나 코드가 스파게티화 되는 경우를 많이 봐서 개인적으로 선호하지 않고, ASP는 Windows에서만 동작해서 제외 했다. 또 요즘 Python+Django도 많이 쓰는 것으로 알고 있는데, 생산성과 성능에서 Ruby와  비슷할 것으로 생각되서 제외했다.

2. Test Tools


HP에서 만든 httperf라는 툴로 테스트를 해보았다. autobench라는 통해서 httperf를 이용하면, 부하를 주는 서버를 여러대로 설정할 수 있고, 또 자동으로 부하를 조금씩 늘려가며 테스트를 할 수 있다.

3. Test System Deployment


테스트를 위한 구성은 다음과 같이 3가지의 시스템으로 구성된다.

3.1 Clients

부하를 생성하는 머신이다. 2대로 구성하였고, 스펙은 다음과 같다.

  • CPU: 32 cores (8 Processors(Intel(R) Xeon(R) CPU X3470 @ 2.93GHz), 4 cores per processor)
  • Memory: 8 GB
  • 2대 모두 동일함

3.2 Server

비교 대상이 되는 web framework가 동작하는 서버이다. 이 서버에 비교 대상이 되는 web framework의 서비스를 포트만 달리해서 모두 띄워놓았다.

스펙은 다음과 같다.

  • CPU: 8 cores (2 Processors(Intel(R) Xeon(R) CPU X3470 @ 2.93GHz), 4 cores per processor)
  • Memory: 8 GB

3.3 External Server

web framework가 연동하는 외부 서버이다. web framework이 작업을 수행하는 중에 또 다른 서비스의 결과를 얻어서 처리하는 경우를 가정하고, 이 서버에 request를 요청하도록 하였다.

이 서버에서 처리하는 request가 오래 걸리는 job이라 가정하고, 100 ms를 sleep하고 response를 보내도록 하였다.

이 서비스는 Ruby로 만들었고, 앞서 비교 대상 중 Ruby의 세팅과 동일하다. 서버 스펙은 다음과 같다.

  • CPU: 8 cores (2 Processors(Intel(R) Xeon(R) CPU X3470 @ 2.93GHz), 4 cores per processor)
  • Memory: 16 GB

4. Test Scenario


4.1 Ping Test

Clients에서 Server로 단순 http request을 한다. Server는 http request를 받아서 바로 “Ping”이라는 문자열을 response로 보낸다.

4.2 API Call Test

Clients에서 Server로 http request를 보내면, Server에서 이를 받아 다시 External Server로 http request를 한다. Server는 External Server로부터 response를 받으면, Client에 response를 보낸다.

Ruby의 경우에 API Call을 동기적(synchronous)으로 한다. 나머지는 비동기적(asynchronous)으로 한다.

4.3 Long Ping Test

API Call Test의 경우에 External Server의 performance에 의해 그 결과가 영향을 받을 수 있다. 항상 일정하게 response를 줄 수 있다면, 보다 정확하게 각 web framework의 성능을 비교할 수 있을 거라는 생각이 들었다.

그래서, 항상 일정 시간 후에 response를 주는 가상의 External Server를 생각해보았고, External Server의 API를 호출하는 대신 단순히 일정 시간 sleep해버리면 결국은 항상 일정 시간 후에 response를 주는 External Server일 거라고 가정하고 테스트를 해보았다.

Ruby의 경우에 API Call Test 때와 마찬가지로 synchronous한 sleep을 이용했다.

5. Test Result


X축은 client에서 server로 보내는 request 수이고, Y축은 server에서 request를 받아주는 수이다. 단위는 requests/seconds이다.

5.1 Ping Test

autobench_admin --clients [clients] --single_host --host1 [host] --port1 [port] --uri1 /ping  --low_rate 20 --high_rate 1600 --rate_step 20   --num_call 100 --num_conn 1000 --timeout 5 --file [filename]

ping

자세한 결과보기

5.2 Api Call Test

autobench_admin --clients [clients] --single_host --host1 [host] --port1 [port] --uri1 [path]  --low_rate 10 --high_rate 200 --rate_step 10   --num_call 10 --num_conn 100 --timeout 5 --file [filename]

api

자세한 결과보기

Node.js의 경우에 client의 request를 제대로 받아주지 못하고 있다. 보통 asynchronous하게 동작을 한다고 하면, External Server의 응답이 지연이 되더라도 일단 client의 request를 받아주어야 할 것 같은데 결과가 조금 의아하게 나왔다.

5.3 Long Ping Test

autobench_admin --clients [clients] --single_host --host1 [host] --port1 [port] --uri1 /long_ping  --low_rate 50 --high_rate 2000 --rate_step 50   --num_call 10 --num_conn 100 --timeout 5 --file [filename]

long-ping

자세한 결과보기

Scala의 throughput이 중간 중간 떨어지는 것을 볼 수 있는데, 이것은 garbage collector의 영향인 것으로 보인다. 테스트를 하면서 서버 상태를 보니, Java와는 다르게 Scala에서 메모리를 많이 사용하고 있었는데, 이것이 GC 동작을 하게 한 것으로 보인다. 참고로, Play2가 아직 개발 중인 버전이라 그런 것으로 생각된다.

6. 결과 분석


6.1 Erlang

역시 소문대로 Erlang은 빨랐다. 그런데 많이 사용하지 않는 language라 reference와 라이브러리들을 찾기가 조금 어려웠다. 또, 문법이 익숙하지 않은 개발자에게는 초기에 learning curve가 있을 것으로 예상이 된다. 하지만, 성능이 중요하다면 고려해 볼만하다.

6.2 Java & Scala

같은 JVM 계열인 Java + Play1과 Scala + Play2가 성능차이가 나고 있는 점이 눈에 띈다. 비록 Play 버전이 다르기는 하지만, http를 실제로 핸들링하는 netty와 async http client는 버전 차이가 크게 나지 않기 때문에, 언어적인 특성으로 성능에 차이가 있었던 것으로 짐작된다. (최근에 play framework의 소스를 보게 되었는데, http request 전후로 framework 단에서 해주는 작업이 꽤 되었다. Play2는 Play1과 전혀 다른 구조로 되어 있기 때문에 성능 차이가 있었던 걸로 생각된다.  updated at 2012-05-03)

6.3 Node.js

node.js는 조금은 실망스러운 결과를 보여주고 있는데, 그 이유는 아직 node.js가 multi core를 지원하지 않아서 인 것 같다. 그래도, single core만 쓰는 걸 고려하면 성능이 좋은 편이라 할 수 있다. Core가 2개인 저사양의 서버에서도 테스트를 잠시 했는데, Java + Play 1과 비슷한 성능을 보여주었다. 앞으로 node.js가 multi core가 지원되면 확실히 빨라질 것으로 예상된다.

짚고 넘어가야 할 부분은, JavaScript 문법이 조금 verbose하기 때문에 생산성에 문제가 있을 것으로 생각된다. CoffeeScript 같은 meta language를 써서 JavaScript 코드를 생성하는 방법도 있는데, 이렇게 해보니 debugging이 불편한 단점이 있었다. 요즘 많이 주목받고 있는 만큼 빠르게 발전할 것으로 기대된다.

6.4 Ruby

처음에 Ruby의 default web server인 WEBrick으로 테스트를 했을 때는 성능이 매우 안좋았다. 그래서, Apache web server를 Passenger를 이용하여 연결했더니, 성능이 꽤 좋아졌다. 다른 것에 비교해서 성능이 떨어지기는 하지만, 개발 생산성을 고려해보면 프로젝트의 요구사항에 따라서 선택해볼 여지가 있지 않나 생각된다.

A Viral I’ve experienced thanks to Twitter.

Viral. Really.

We have heard about viral a lot, and we think that we know it. But, experiencing it is totally different from knowing it.

I’ve started to write blogs since last year. One article around a month. I enjoy writing blogs but it also takes quite a lot of time because I am not that good at writing. Every time I finished an article, I wanted to get as much feedback as I could. But there were not much. So I started to introduce my article to my twitter followers and Facebook friends.

Facebook is a good platform to get quick feedback from my friends. If they think it’s meaningful to them, my Facebook friends click the Like button and leave a short comment on it, instantly. And I enjoy the feedback. Good platform! Finally people read my blogs.

By contrast, I did not get as much feedback from Twitter as from Facebook. I once thought twitter is not a good platform to interact with others. In other words, Facebook seemed to be a real SNS.

But, I was wrong.

I posted an article to my blog in Aug. It’s an email that I sent to CEO when I left LG Electronics in April. It’s mainly because I wanted to build a popular web service, which was not part of business LGE does. Working at LG Electronics, I often felt frustrated because of its culture and management. Though leaving LGE, I wished that LGE would overcome the difficulties it faces in the mobile industry. It is because it’s the company that I’d worked for over 5 years and would be listed in my resume forever. And I love the people whom I worked with. So I wrote an email to the CEO who recently took the CEO job. I did not put the blame on him in the email but tried to tell the problems in a very constructive way. But no reply. It seemed that the mail did not reach him. I did not want my email just to disappear. And I thought that LG Electronics was likely to keep its wrong direction without this kind of voice of the field engineers. That’s why I posted the email to my blog. I did it with good cause.

Posting the email to my blog, I also updated my Facebook wall to introduce the post. Many comments and Likes from the Facebook friends. It was good to have feedback on it. But that’s it. It was just talk between me and my friends, which the management of LG Electronics would not acknowledge.

Then, I tweeted about the blog post 2 days after I did it on Facebook. Compared to Facebook, there was no ‘instant’ feedback from my followers, as usual. It was because I had only around 70 followers at that time while over 200 friends are there at Facebook. After a while, one of my followers retweeted it with his quotes. He was not my Facebook friend, therefore he had not read my Facebook update about the email before. The thing is that he had over 1,000 followers. Then after a while, his followers started retweeting his quoted retweet. Push messages from my twitter app bursted notifying that my twitter id was mentioned. I checked out the stats of my blog. The number of visitors soared. I mean compared to the usual visitors. I felt excited and I went to bed.

I woke up next morning, and I checked out the timeline of my twitter account as I usually do in the morning. Reading the tweets from my timeline, I was so surprised to find out that the email to LGE CEO was mentioned by one of the most influential twitter user to Korean users, @estima7. Then that morning, Korean internet news media started to deal with my email and blog. When I got to the office around 11 AM, one of the colleagues said to me, instead of “Hello”, that my story was in the front page of the Korean No.1 portal service, Naver. Over 60,000 people visited my blog that day.

It was the ‘viral’. I experienced viral. I could say all that I want in my blog, but I did not think I could impact on society. But it turned out to be wrong. As long as one can give an opinion that people agree with and sympathize with, we all have the power to speak up to our society. And Twitter plays a key role in that.

프로그래머 전성시대

요즘 프로그래머 정말 귀한 것 같다. 아이폰, 안드로이드폰, 그리고 웹이 HTML5로 바뀌면서 프로그래머 수요는 계속 증가하고 있는데, 개발자 수는 여기에 못미치고 있는 것 같다.

이러한 상황에서 기존 프로그래머야 몸값이 올라가서 좋을 수 있다. 하지만, 사업을 하는 입장이나 프로젝트를 리드하는 입장의 분들에게는 프로그래머를 어떻게 모실(?) 것인가가 사업과 프로젝트의 성패를 가르는 중요한 열쇠가 된 것 같다.

얼마나 프로그래머 구하기가 어려웠으면,  미국에서는 입사하면 연예인을 만나게 해준다는 곳까지 생긴 것 같다. (http://t.co/jNaUbiT via @sm_park)

그래서, 실제로 프로그래머가 부족한 것인지, 그렇다면 이유가 무엇인지 조금 짚어볼까한다.

(이 글은 순전히 좁디 좁은 제 경험에 근거하고 있으니, 틀릴 가능성이 다분히 있습니다. 가차없이 코멘트 부탁드립니다.)

1. 프로그래머는 정말 부족한가?

1.1 전자업계

삼성전자나 LG전자의 경우 과거에는 전자공학도 위주로 신입사원을 채용했다. 하지만, 최근에는 양상이 완전히 바뀌었다. 휴대폰 개발의 경우에 투입되는 리소스의 상당부분이 소프트웨어 관련 인원이다. 이 두 회사만 해도, 1년에 천명 단위로 소프트웨어 개발자를 채용해야  하는 걸로 알고 있다. 그런데, 이것이 어렵다 보니 요즘에는 공대 졸업생을 뽑아 소프트웨어 관련 교육을 몇 달간 시켜 프로그램을 만들게 할 정도이다. 최근에 우리나라 전자회사들이 고전하는 이유가 이와 관련이 없다고 말하기는 힘들 듯 하다.

1.2 웹 & 모바일 서비스 업계

NHN이나 Daum의 경우는, 잘은 모르겠지만 요즘 개발자를 많이 뽑는다. 아마도, 이전 같으면 플래시나 Active-x로 간단히 할 수 있던 것을, 웹표준을 지켜 HTML로만 해야 하니 좀더 리소스가 많이 드는 것이 아닌가 한다. 또, 데이터가 커지면서 이를 잘 scaling하고 안정적으로 서비스 하기 위해 인원이 더 필요할 거라 생각이 든다. 최근 들어서는 웹 관련 개발 뿐 아니라, 모바일 어플리케이션까지 만들어야 하니 프로그래머가 더 필요할 듯 하다.

게다가, 모바일 관련 창업이 늘면서 수요가 많이 늘은 것 같다.

1.3 게임업계

온라인 게임의 경우 하나의 게임을 만드는데 프로그래머 수십에서 백명 이상에, 2~3년에 걸쳐 개발하는 것으로 알고 있다. 예전에 온라인 게임 이전의 캐주얼 게임이나 초기 온라인 게임의 개발과 비교하면 분명히 프로그래머가 정말 많이 필요하다.

1.4 기타업계

최근에 Marc Andreessen이 월스트리트 저널에 기고한 ‘Why Software Is Eating The World’에서도 보듯이 요즘은 세상 모든 것이 소프트웨어다. 우리나라만 보더라도 기업 뿐만 아니라 정부 기관에서도 홍보용 웹사이트는 물론이고, 갖가지 모바일 어플리케이션을 만들어서 내놓고 있다. 보기에는 간단해 보이는 어플리케이션들이지만 상당한 리소스들이 투입되는 것으로 알고있다.

2. 왜 부족할까?

2.1 수요가 갑자기 늘었다.

해마다 대학에서 배출할 수 있는 전산관련 졸업생 수는 한정되어 있는데, 수요가 갑자기 늘었다. 프로그래머의 수요가 늘면 대학의 전산 관련학과 정원도 늘리면 좋겠으나, 정원을 늘리는 건 아마도 교육부 허가도 필요할 것이며, 또 정원만 늘린다고 지원자가 바로 늘지는 않을 것이기 때문에 이것이 쉽지가 않을 것이란 생각이 든다.

2.2 개발 복잡도가 커졌다.

아이폰이나 안드로이드 폰 개발의 경우에 임베디드 환경이고, 다양한 기기를 지원해야 하는 점 때문에 생산성이 그렇게 높지 않은 것 같다. 과거에 윈도우즈 어플리케이션을 만들거나 Active-X를 이용한 웹 프로그램을 만드는 경우에, MFC나 Win32 API만 잘 쓰면 만사 OK였는데, 지금은 그렇지가 않다. 아이폰 개발을 위해서는 Object-C와 iOS 프레임워크를 익혀야 하고, 안드로이드 개발을 위해서는 안드로이드 SDK를 익혀야 한다.

그리고, 웹 개발도 예전보다 많은 traffic을 좀더 빠르게 처리하기 위해, tier가 더 많아져서 해줘야 할 것이 많다. 예전 같으면, LAMP라고 해서 리눅스(L), 아파치(A), MySQL(M), P(PHP or Perl) 정도만 설치하고 웹서비스를 했지만, 요즘은 사용자들 눈높이가 높아져서 이것만으로는 어림도 없다. DB를 빠르게 하기위해 Memcached 같은 cache 서비스를 웹 서버와 DB 사이에 붙이기도 하고, client에서 좀더 화려하고 빠르게 동작하도록 Ajax 형태로 구현하기도 한다. 결론은 예전보다 복잡해서 손이 많이 가고 리소스도 많이 필요하다는 것이다.

2.3 이공계 기피 현상

실리콘 밸리에서도 개발자는 귀하지만, 우리나라의 경우 더 귀한 이유가 10년전쯤 생긴 이공계 기피현상 때문인 것 같다. 10년 전, 그러니까 내가 벤처에서 프로그래머 생활을 시작할 그 즈음에는 26~7살 정도 되면 팀장이 되고, 30이 넘으면 회사 임원이 되면서 슬슬 개발을 놓는 경우가 많았던 것 같다. 새로운 프로그래머가 계속 들어오니 가능했던 일이 아닌가 싶다. 요즘은 어떤 개발팀은 30이 넘은 팀원이 막내인 경우도 있고, 30대 후반의 팀장 아닌 팀원도 쉽게 본다. 긍정적으로 본다면야 프로그래머가 정년(?)이 늘었다고도 볼 수 있지만, 결정적으로 젊은 피가 안들어오는 게 문제다. 환갑된 할아버지가 경로당 가면 ‘막내’소리 듣는 다는 말이 생각난다.

3. 마무리

간단히, 프로그래머가 실제로 부족한지, 그리고 그 이유는 무엇인지 나만의, 그리고 매우 주관적이며, 또한 편협할 수 있는 생각을 적어봤다. 글을 마치면서, 혹시 전공이나 앞으로 무엇을 해야할 지 고민하는 학생이 있다면 이 말을 전해주고 싶다.

컴퓨터와 인터넷을 좋아하고, 창작의 기쁨을 안다면, 컴퓨터공학을 해라~ 팍팍~

Updated at 2012-04-23:
개발자 부족문제를 잘 풀어낸 글이 있네요.  http://allaboutetp.wordpress.com/2012/04/23/developers/

우리 조직문화 바꿀 수 있지 않을까요?

지난 몇 일 동안, Social Network의 위력을 몸소 체험하였습니다. 바위에 계란을 던지는 심정으로, 제가 오랫동안 근무했던 회사가 방향을 제대로 잡고 나아갔으면 하고 CEO에게 보냈던 이메일을 제 블로그에 올렸습니다. 제가 올린 트윗이 조금씩 리트윗 되더니, 금요일(19일)에는 회사에 출근했는데, 동료가 제가 쓴 글이 네이버 첫 화면에 나왔다고 알려주었습니다. 그리고, 블로그 방문객 수는 보통 때와 비교도 안될 만큼 늘었고, 댓글도 엄청나게 달리기 시작했습니다.

많은 분들이 댓글을 통해 의견을 주신 것처럼, 이러한 경직된 조직 문화, 그리고 시대를 반영하지 못하는 경영 체제는 비단 LG만의 문제가 아닌 것 같습니다. 그렇기 때문에, 부족한 제 글이 많은 분들로부터 공감을 얻게 된 것이 아닌가 생각됩니다.

그런데, 앞으로도 기업의 경영 방식은 이렇게 소통이 막히고, 관료적으로 갈 수밖에 없는 걸까요? 50년, 또는 100년이 지난 후에도 지금과 같은 경영 방식으로 기업이 운영될 수밖에 없는 걸까요? 행복하기 위해 살고 있는 우리는 이렇게 스트레스 받으며 경직된 조직 문화에서 일할 수밖에 없는 걸까요?

지금과 같은 관료적인 기업문화는 100여년전에 GE와 같은 대기업들이 나오면서 생겼다고 합니다. GE와 같은 대기업은 그 당시로서는 혁신적이라 할 수 있는, 계층적(hierarchical)인 경영 체제를 도입하여 많은 수의 종업원을 관리(manage)할 수 있게 되었고, 그래서 더 큰 규모로 성장할 수 있었다는 이야기도 있습니다.

하지만, 지금도 그것이 정답이고, 앞으로도 정답일 거라고는 저는 생각하지 않습니다. 제조업 중심의 그 당시와, 지식 산업으로 재편되고 있는 지금은 분명히 다르고, 사람들의 교육 수준, 의식 수준도 그때와는 많이 다릅니다. 이제 새로운 경영 방식이 필요한 때라고 생각합니다. 혁신적인 경영 방식이 없이는 혁신적인 제품과 서비스를 만들 수 없습니다. 그리고, 무엇보다도 우리는 예전과 같은 조직문화 속에서는 행복하지가 않습니다.

그래서, 많은 분들과 여기에 대해 좀더 많은 토론을 해보고, 또 이것을 기업을 운영하시는 분들께도 알릴 수 있는 방법이 없을까 어제, 오늘 고민해보았습니다. 제가 엔지니어인지라, 기술의 도움을 얻어서 한번 다음과 같은 프로젝트를 시작해보려고 합니다.

어떤 의견이라도 좋습니다. 댓글 또는, 제 이메일(ppassa@gmail.com), 트위터(@ppassa)를 통해 의견 부탁드립니다.

PS: 오늘 아침 같이 논의를 한, 그리고 앞으로 같이 할 현균아 고맙다.

프로젝트 명


더 나은 경영 방식을 향해

동기


  1. 많은 기업들의 조직문화에 문제가 있고, 사람들이 이를 공감하고 있다.
  2. 조직문화를 개선하는 데에 사람들은 참여하고 싶어하지만, 토론 공간의 부족하다.

접근 방향


  1. 사람들이 쉽게 우리 조직 문화에 대해 이야기 할 수 있는 장을 만들자.
  2. 재미 있어야 한다.
  3. 무언가 지표화 하여, 기업들간 비교를 하게 하자.

솔루션


사람들이 토론하고 각 기업의 혁신 지수를 볼 수 있는 사이트를 만들자.

  1. 사람들은 자신의 회사의 조직문화, 경영방식에 대해 의견을 제시하고, 점수로 평가한다.
  2. 이것을 보고 다른 사용자들은 찬성 또는 반대 의사를 나타낸다.
  3. 각 기업의 일종의 혁신지수(?)를 사람들의 공감 정도에 따라 계산하여 보여준다. 이때 공감을 많이 받은 의견은 가중이 되어 계산된다.

Prototype 화면

일단은, 정말 간단하게 화면(page)을 prototyping 해보았습니다.

1) 첫 페이지

기업들의 혁신 지수(?)를 보는 페이지 입니다. 클릭을 하면 좀더 상세히 보는 페이지로 넘어갑니다.

2) 기업별 페이지

기업에 경영방식, 조직 문화에 대해서 의견을 제출합니다. 이때 점수도 같이 평가해서 제출합니다.

하단에는 기존의 제출된 의견과 점수가 보이며, 사람들은 우측의 버튼을 클릭하여, 찬성 또는 반대 의사를 나타냅니다. 버튼 옆의 숫자는 다른 사람들의 공감 지수를 나타냅니다.