소프트웨어 엔지니어 (Web / Mobile App) 모집
ViKi(www.viki.com)의 차기 프로젝트 밤비(BalmBees)에 참여하실 소수정예 멤버를 모집하고 있습니다. ViKi는 언어 장벽을 넘어 전세계인이 전세계 TV 컨텐츠를 감상하고 서로를 이해하는 장을 만들겠다는 가치 아래, 하버드와 스탠포드 출신의 벤처 전문가들이 미국 실리콘밸리에서 시작한 글로벌 소셜 TV 프로젝트 입니다. 워너뮤직 소유주를 비롯한 전세계 메이저 엔터테인먼트 기업 및 실리콘밸리의 대표적인 벤처투자자 및 투자회사로부터 투자를 받았고 최근에는 한국 SKT와 영국 BBC로부터 투자를 유치하였을 뿐만 아니라, 월 방문자 천만에 이르는 급격한 성장을 이루고 있는 회사 입니다. ViKi가 자리를 잡아감에따라 ViKi의 창업자들이 새로운 도전을 위해 국내 IT 벤처 인재들과 함께 Balmbees라는 프로젝트를 기획하고 있습니다. 남들보다 한발 빨리 실리콘밸리를 경험하고 이제는 한국의 인재들과 함께 이 소중한 경험을나누면서 한국형 글로벌 벤처 기업의 선례를 만드는데 공헌하겠다는 목표를 가지고 있습니다. ViKi가 언어 장벽을 넘어 전 세계인들이 함께 TV를 시청할 수 있는 곳이었다면, Balmbees는 언어장벽을 넘은 새로운 팬덤 문화를 창조하고자 합니다.

● BalmBees에는 이러한 사람들이 함께 일하고 있습니다.
- 일을 사랑하고, 사람을 사랑하고, 회사를 사랑하는 사람들
- “가늘고 긴” 인생을 계획하는 사람들 보다는 도약을 위해 폭풍같은 열정으로 일하고 싶어 하는 사람들
- 큰 목표, 큰 도전, 큰 성취를 위해 노력과 포기를 할 줄 아는 사람들
- 새로운 것을 만드는데 언제나 가슴 설레이고 세상을 바꾸겠다는 포부를 가진 사람들
- 빨리 배우는 사람들
- 다양한 사람들의 서로 다른 자질과 가치를 인정할 줄 아는 사람들
- 오픈 마인드를 가지고 서로의 리소스를 공유할 줄 아는 사람들
- 내가 이러한 팀의 일원임을 자랑스럽게 여기는 사람들

위치: 서울 서초구 잠원동 37-8 이루진빌딩 1층 (논현역 5번출구 도보 45 초 거리)

ViKi에 대해 자세히 보기
www.news.donga.com/3/all/20110404/36126978/1
www.metroseoul.co.kr/news/articleView.html?idxno=22120
www.bloter.net/archives/48641
www.economy.hankooki.com/lpage/it/201110/e20111021093024117760.htm

모집부분 및 자격요건

Front-end, Back-end, Mobile App 모두 경험해본 분이라면 가장 좋겠지만, 아래 항목중 한가지만 경험해본 경우라도 좋습니다. 저희는 열정이 있는 분이라면 새로운 영역도 즐겁게 배워나갈수 있다고 믿기 때문에 Web / Mobile App Development를 제대로 해보고 싶은 분들이라면 모두 환영합니다.

Front-end (00명)
    • HTML, CSS, and JavaScript 경험
    • jQuery 경험
Back-end (00명)
    • Ruby on Rails 경험
    • 혹은 기타 다른 MVC Framework 경험 (Java Spring, Python Django)
    • 확장성있는 웹 개발에 대한 이해
Mobile App (00명)
    • iOS / Android App 개발 경험
    • UX (사용성) 에 대한 관심
기타:
    • TDD (Test Driven Development) 경험 Plus!
    • postgreSQL 혹은 기타 다른 SQL기반 경험 Plus!
    • Facebook / Twitter / Google API 사용 경험 Plus!

참고 - The Joel Test 점수로 보는 Viki의 개발자 환경:
    • Source Control(소스 컨트롤)을 사용하십니까? Yes!
    • 한번에 빌드를 만들어낼 수 있습니까? Yes!
    • daily build(일별 빌드)를 만드십니까? Yes!
    • 버그 데이타베이스를 가지고 있습니까? Yes!
    • 새로운 코드를 작성하기 전에 버그들을 잡습니까? Yes!
    • up-to-date(최신) 스케줄을 가지고 있습니까? Yes!
    • spec(설계서)를 가지고 있습니까? Yes!
    • 프로그래머들이 조용한 작업환경을 가지고 있습니까? Yes!
    • 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까? Yes!
    • 테스터들을 고용하고 있습니까? Yes!
    • 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까? Yes!
    • hallway usability testing(무작위 사용성 테스팅)을 하십니까? Yes!

복리후생
연봉 + 스톡옵션
4대 보험
조식 및 간식 제공
월 1회 Playday 문화행사
도서 지원

Balmbee의 멤버로서 가질 수 있는 Benefit
각 분야의 "선수"들과 함께 글로벌 기업문화를 경험해볼 수 있으며, 세계적인 수준에서 커리어를 개발할 수 있습니다.  한국 내 서비스가 아닌 서비스 시작부터 전세계인들을 대상으로 하는 진정한 글로벌 웹서비스를 경험할 수 있습니다.
세계 최고의 개발 컨설팅 회사 Pivotal Labs (Pivotal Tracker의 개발사이기도 함)의 컨설팅을 통해 습득한 애자일/TDD(Test Driven Development) 방법론을 경험해보실 수 있습니다. 아래는 Balmbees 개발자 분들의 생생한 경험담 입니다.

● 
레일즈 + 애자일 개발 경험  
from 개발자 Hoon Kang

저는 ViKi 의 시작부터 ViKi 개발의 전반을 경험하였고, 지금은 BalmBees 프로젝트에 합류하게 되었습니다. 초기 ViKi 는 php로 CakPHP를 사용하여서 개발되었습니다. CakePHP는 MVC방식을 따르는 프레임워크였기 때문에 html코드와 php코드가 섞여서 알아보기 힘든 문제점을 개선하기는 하였지만, 사이트의 규모가 커짐에 따라 개발 가이드 라인이 부족해서인지 개발자 마다의 코드나 방법이 달랐고, 작성된 코드를 테스트하는 경험도 부족하고 방법도 까다로웠습니다. 나중에는 한부분을 고치면 다른 부분에서 버그가 발생하는 일이 계속 반복되었습니다.
레일즈 개발을 도입하게 된 계기는 Pivotal Labs 라는 컨설팅 회사와 함께 일하기 시작하면서 부터였고, 레일즈와 애자일 개발 방법론을 함께 전수 받았습니다. 몇년동안 유지보수해서 커질대로 커진 웹사이트를 새로운 언어와 프레임워크를 써서 다시 만든다는게 처음에는 불가능해 보였지만 일이 진행됨에 따라서 레일즈와 애자일을 함께하는 방법이 더 낫다는 확신이 들었고 지금은 기존에 어떻게 개발을 하였나 하는 생각까지 하게 됩니다.
지금까지의 일반적인 개발 방법 하에서는 기획이 나오면 언제까지 개발하겠다는 목표를 세우고 그 기한이 늦어지게 되면 조바심이 생겨서 일을 무조건 많이 하려고만 했었습니다. 하지만 무리한 일정이 지속 되면 얼마 후에는 업무 효율이 떨어져서 개발 속도도 느려지고 버그도 많아 지는 것을 경험하였습니다. 그리고 많은 시간을 들여 기능을 개발하였는데 결과적으로는 기획 의도와 다른 경우도 자주 있었습니다. 
반면, 애자일 개발 방법에서는, 기획이 나오면 그것을 몇시간 내에 구현할 수 있는 단위인 스토리로 나눕니다. 그리고 기획자가 스토리들의 우선 순위를 정하고, 개발자가 각 스토리가 얼마나 걸릴지 예측을 합니다. 이러한 과정에서 자연히 기획자와의 대화가 늘어나고 미스커뮤니케이션이 줄어듭니다. 스토리에 소요되는 시간은 저희가 쓰는 툴이 자동으로 계산합니다. 이전 몇주간의 생산성을 계산해서 어떤 기능이 얼마나 걸릴지 예측하고, 이 개발속도는 매주 업데이트 됩니다. 이로써 개발 일정 관리에 대한 부담이 줄고 현재 개발하고 있는 스토리에 집중할 수 있었습니다. 이런 방법이 빠른 결과를 보려는 일반적인 생각에 반대되는 것 같지만 결과적으로는 생산성이 떨어지는 문제를 해결하는 것 같습니다.
또한, 레일즈는 수많은 개발자와 프로젝트에서 검증된 개발 가이드 라인을 제공합니다. 오픈소스이고 수많은 개발자들이 사용하고 발전시키고 있기 때문에 여러 프로젝트에 사용되면서 개선된 점이 레일즈 프레임워크에 다시 반영됩니다. 따라서 몇달에 한번씩은 주요한 업그레이드가 나옵니다. 또한 다른 개발자들이 제공하는 가이드 라인만 따르더라도 오랫동안 고민해서 얻은 결과를 바로 적용할 수 있습니다.

● 
TDD + Pair-Programming + Ruby on Rails 한달 체험기

from 개발자 Tae Kang

TDD + Pair Programming 이라는 것이 책이나 블로그에서 접해볼 수 있는 막연한 것이었고, BalmBees 이전에 국내 회사중 "공식적으로" 그 방식을 이용한다는 곳을 들어본 적은 없습니다. 팀에서 간헐적으로 활용하는 경우가 있기는 하나 대부분의 지속되지 못하고 흐지부지 되는 것 같았습니다.
일단 지금 이곳에 합류하기 전까지의 제 경력은 대략 이렇습니다.
- 모바일 핸드셋 개발 : 하드웨어 제어하는 API 개발 및 폰에 탑재되는 어플리케이션 개발 (스마트폰 아님); C 사용
- Back-end 시스템 개발 : 리눅스 상에서 대용량 데이테 처리를 위한 분산시스템 개발 및 유지보수; Hadoop / Xen VM hypervisor / 각종 분산파일시스템 오픈소스를 이것저것 가져다 사용하다보니 언어의 제약은 없었음. C, Java, Python, Shell script 등 닥치는대로 사용.
- 웹 서비스 개발 : Spring 기반으로 collaboration 시스템
- 분산처리 시스템 개발 : 대용량 데이터 처리하는 시스템 Hadoop 이용하여 구축 (Java + Python 조합); Front-end는 Python/Django + mySQL 사용.
보시면 아시겠지만, TDD와 Rails는 접해보지 못했습니다. 물론 Rails와 비슷한 Spring과 Django같은 MVC는 깊게는 아니더라도 어느정도 접해보았죠.
저도 이번에 처음 제대로 TDD + Pair-programming 경험을 해 본건데 현재까지의 느낌은 이렇습니다.


- Pair Programming : 

옆 에 누가 있고 컴퓨터 한대로 둘이 함께 작업을 하다보니 딴짓할 겨를이 없다. 사실... 혼자 있으면 딴짓 많이하자나요. 혼자 개발하는게 100명들어가있는 강의실에서 수업받는거라면, Pair-programming은 개인과외 받는 그런 기분입니다. 집중력은 확실히 올라가게 되고, 같이 작업하다보니 코드의 일관성도 생기게되고 어떤 부분에서 어떤코드가 어떤일을 수행하는지 알게됩니다. 만일 따로 작업해야했다면, 나중에 만나서 서로에게 다시 설명해야 하는 성가신 작업에 코드리뷰와 같은 일들이 필요하겠죠. 그리고 대부분의 경우 그 설명하는게 귀찮아서 시간이 지나면 서로 "저인간은 뭐하지?" 아니면 "아니 뭐 코드를 이따구로 짜놨어...?" 그렇게 되는 경우를 많이 보았습니다.
단점이라면... 딴짓할수 없다는것... 옆에 누구 있는데 졸기 어렵다는점 ㅋㅋ 그리고 결정적인건 윗분들이 "아니 혼자하면 되는거 왜 둘이 해서 돈을 두배로 들여야해?" 라고 생각하는 분들이 아직은 많은지라 하고 싶어도 하기 어렵다는것.


- TDD : 

TDD 의 경우에는 문제를 단순화할 수 밖에 없게 만듭니다. 왜? 테스트 케이스를 만들어야 하니까요. 그리고 처음에는 속도가 안나는 듯 하지만 이게 손에 익고 테스트 케이스들이 촘촘하게 쌓이면 "마음의 안정" 이 생기게 됩니다. - "기능 변경을 해야하는데, 라이브러리를 새로운거로 갈아끼고 싶은데, 혹시 바꿧다가 맛탱이 가면 어떡하지?" 했을때 코드 변경을 꺼리게 되죠. 하지만 테스트 케이스가 쌓이고 난 후에는 지금까지 만들어놓은 테스트 케이스를 돌려버리면 되니까, 기획자가 새로운 기능 추가하자 하거나 변경하자고 해도 어느정도 할만한것 같습니다. (아직까지는... ^^)
단점이라면, "이게 정말 속도가 나는건가?" 하고 가끔씩 의문이 들때. 마음은 급한데 마음은 빨리 구현해버리고 싶은데... 하는 충동이 들때. 근데 위에서도 언급했듯이 기능상의 변경들이 요구될때 분명히 pay-off가 있을것 같긴 합니다.


- Ruby on Rails :

MVC Framework를 경험해 보았다면 언어만 틀린거지 Java기반의 Spring이나 Python기반의 Django와 유사하다고 할 수 있지만, 확실히 Java기반보다는 "담백함"이 있습니다. Java기반이 화려한 단어와 미사여구로 진입장벽을 높여 많은이들에게 좌절을 준다면 Rails는 그런게 확실히 적고 코딩하고 결과를 볼때의 반응이 즉각적이어서 좋은것 같습니다. 그리고 Java와는 틀린 이런 즉각적인 반응이 TDD나 Pair-programming을 현실적으로 가능하게 만드는게 아닌가 싶습니다. 물론 성능은 Java기반이 더 좋다고는 하지만, 결국 프로그램을 만드는것은 사람이니까, 일하는 사람이 편해야지 기계들 편하자고 일하는건 아니잖아요. 
단점은... 아직까지는 좋습니다만, 시스템이 커지면 성능이슈가 있을수 있다고들 하더라구요. 그래서 트위터와 같은 RoR로 개발된 사이트들도 성능이 이슈인 부분들은 Java 기반으로 갈아끼고 있다는 이야기도 있구요. 하지만 그런 고민이 드는 상황이라면 행복한 상황이겠죠 ^^; 그리고 전세계의 해커님들께서 불철주야 노력하고 계시고 시스템적으로도 해결할수 있는 방안이 있어보입니다. (물론 그 상황 되어봐야 알겠죠!)

제출 서류
이력서 및 자기 소개서

지원방법
recruit@balmbees.com으로 이력서 및 자기 소개서 제출