㈜ 노매드커넥션 개발자 채용

Posted 2007. 10. 26. 16:06
 

㈜ 노매드커넥션 개발자 채용

 

노매드커넥션(http://www.nomadconnection.com)에서 동영상 미디어 플랫폼 까멜레오 프로젝트를 함께 개발할 역량 있는 개발자를 구합니다.

 

까멜레오 프로젝트(http://www.chameleo.org)?

 

까멜레오가 동영상 미디어 플랫폼이란 다소 생소한 용어를 사용하는 이유는 미디어 플레이어와 응용 소프트웨어 개발 플랫폼을 접목하였기 때문입니다. 까멜레오는 동영상 플레이어 위에서 다양한 응용 프로그램을 구동할 수 있도록 API를 제공합니다. 아래 스크린샷은 몇 가지 동영상 응용 프로그램(동영상 위젯)의 예를 보여주고 있습니다.

 

사용자 삽입 이미지

 

 

위젯 외에 까멜레오는 기존 미디어 플레이어와 무엇이 다른가요?

 

1)    플러그인 아키텍처

 

까멜레오는 플러그인 아키텍처를 지향하고 있습니다. 까멜레오의 모든 기능은 플러그 인으로 구현되어 있으며 적은 양의 코드로도 쉽게 까멜레오 플레이어에 자신이 원하는 기능을 추가할 수 있습니다. 예를 들어, 새로운 콘텐트를 얻어올 채널(웹의 경우 YouTube, Veoh이고 P2P나 포드캐스팅 등 어떤 채널이든)을 추가하고 싶다면 Channel 인터페이스를 구현해주기만 하면 됩니다.

 

2)    메타데이터

 

까멜레오는 사용자의 참여를 통해 동영상에 다양한 메타데이터를 추가하고 이를 활용한 응용 프로그램을 쉽게 개발할 수 있는 환경을 제공하고 있습니다. 메타데이터는 각 장면에 감상평, 인물정보, 위치, BGM 등 다양한 정보를 포괄하며 메타데이터 자체의 포맷을 공개해 개발자가 원하면 얼마든지 추가적인 정보를 남길 수 있도록 하고 있습니다.

 

기존의 메타데이터를 다양한 응용 프로그램이 이용할 수도 있는데, 일례로 자막 API를 이용하면 단순히 자막을 화면에 보여줄 뿐만 아니라, 여러 단어를 추출한 후 영어 사전을 검색해 단어와 뜻을 실시간으로 화면에 뿌려줄 수 있습니다. 혹은 영어 자막의 일부를 비워서 사용자가 채우게 만드는, 받아쓰기 위젯을 만들어낼 수도 있습니다.

 

3)   웹과 연동

 

까멜레오 플랫폼은 미디어플레이어이면서 웹 브라우저를 내장하고 있습니다. 기존 웹 브라우저 내장 방식처럼 웹 따라 비디오 따로 노는 방식이 아니라, 까멜레오는 동영상 위에 웹을 반투명하게 보여주게 됩니다. 상당수의 까멜레오 위젯은 웹 연동 위젯이며 웹에 존재하는 다양한 콘텐트를 동영상과 접목하는 연결 고리를 제공합니다. 동영상+웹 위젯은 쉽게 위젯을 만들 수 있는 환경을 제공하면서도, 풍부한 동영상 감상 환경을 제공한다는 측면에서 사용자들에게 특별한 가치를 제공합니다.

 

 

까멜레오 개발자가 하는 일?

 

까멜레오 개발자는 단순한 응용 프로그램 개발자가 아닙니다. 까멜레오 개발자는 3차원 공간을 사용하고 화려한 효과를 보여줄 수 있는 UI 툴킷을 만듭니다. 동영상 응용 프로그램을 개발할 수 있는 API를 설계하고 구현합니다. 비디오와 메타데이터의 결합과 검색이라는 분야를 다루게 됩니다. 웹과 데스크톱의 연동을 고민해야 합니다.

 

까멜레오 개발자는 동영상을 이용한 전혀 새로운 서비스를 고민하고 있습니다. 기존의 수동적 감상으로는 생각할 수 없었던 다양한 서비스가 까멜레오 내에서는 가능하며, 동영상을 이용한 새로운 서비스를 어렵지 않게 해낼 수 있습니다. 동영상 서비스에 대한 수 많은 아이디어를 고민하고 실험해서 확인해보는 것이 까멜레오 개발자의 일입니다.

 

 

까멜레오 개발자를 하면 뭐가 좋을까요?

 

저희 노매드커넥션은 까멜레오 개발자가 뛰어난 개발자로 성장하는데 필요한 모든 자원을 지원하고 있습니다. 까멜레오 개발팀은 전형적인 학습하는 개발 조직입니다. 까멜레오 개발팀은 세미나, 강의, 스터디 등을 병행하고 있으며 까멜레오 팀원은 누구나 다른 팀원에 대한 교육 책임을 지게 됩니다. 까멜레오 개발자는 하루에 30분에서 1시간은 항상 개발, 미디어, 플랫폼에 대한 지식을 얻는 데 사용하고 있습니다.

 

까멜레오 개발자는 원하는 도서를 얼마든지 구입할 수 있습니다. 개발자에게 있어 연구 개발비의 전부는 도서 구입이며 까멜레오 프로젝트에 직접 혹은 간접적으로 관련된 모든 주제의 도서 구입비는 노매드커넥션에서 지원해 드립니다. 다만, 도서를 구입했으면 반드시 해당 도서를 읽고 그 내용을 팀원들에게 전파해야 하는 책임이 뒤따르고 있습니다.

 

까멜레오 개발자는 외부 활동이 적극적으로 장려됩니다. 까멜레오 개발팀의 철학은 작은 회사일수록 개발자 개인이 스스로 발전해야 하고 또 알려져야 한다는 생각입니다. 외부 강연, 집필, 번역 등의 개발자 역량 개발에 대해서는 회사 차원에서 적극적으로 지지하고 있으며, 개인의 발전과 프로젝트의 발전을 조화롭게 도모하고 있습니다. 자기 일에 자부심을 가지고 외부에도 적극적으로 말할 수 있는 개발자를 환영합니다.

 

 

까멜레오 개발팀의 조직 문화는 어떤가요?

 

위에서 시키는 일만 하느라 회사 일이 재미가 없으십니까? 자신의 창조성, 창의력이 회사의 조직 문화에 묻혀 빛을 발휘하지 못하고 있다고 생각하십니까? 까멜레오 개발팀은 수평적인 개발 조직을 자랑합니다. 까멜레오 프로젝트는 누군가가 시켜서 억지로 하는 프로젝트가 아닙니다. 모든 아이디어를 개발팀 개개인에서 출발하고, 개발팀의 검증을 거쳐서 실현됩니다. 까멜레오 개발팀에서는 여러분의 상상력을 현실로 바꿀 수 있습니다.

 

또한, 까멜레오 개발 팀은 외부로 열려있습니다. 까멜레오 개발자는 곧바로 오픈 소스 개발자입니다. 까멜레오 프로젝트는 처음부터 오픈 소스화를 계획하고 개발되고 있으며, 까멜레오 개발자는 자연스럽게 오픈 소스 개발자가 됩니다. 또한 까멜레오 프로젝트 자체도 GTK, Gecko, PIL, Cairo, Twisted, Spring Python, GStreamer 등 셀 수 없이 다양한 오픈 소스 프로젝트를 활용해 개발되고 있습니다.

 

 

까멜레오 개발자가 갖춰야 될 역량은?

 

까멜레오 프로젝트는 다양한 오픈 소스 프로젝트 기반 위에 구축되어 있기 때문에, 까멜레오 개발자는 오픈 소스 사용 경험이 풍부하고 여러 오픈 소스를 가져다가 수정할 수 있는 능력이 있어야 합니다. 물론, 이런 경험은 까멜레오 프로젝트에 참여하시면 지속적으로 쌓으실 수 있으며 개발팀에 지원하실 때는 최소한의 역량만 갖추고 있으시면 됩니다.

 

까멜레오 플랫폼의 공식 개발 언어는 C/C++, 파이썬, 자바스크립트입니다. C/C++은 미디어 플레이어와 관련된 코덱 및 필터 개발에 사용되고, UI와 로직은 대부분 파이썬으로 구현되어 있습니다. 또한 웹 위젯과의 연동 및 웹 어플리케이션 개발과 관련하여 자바스크립트, HTML, CSS 등도 어느 정도 지식이 있으시면 좋습니다.

 

 

채용 절차는 어떻게 되나요?

 

일단 간단한 이력서(영문/국문 상관 없음)와 연락처를 서광열(skyul@nomadconnection.com)으로 보내주시면 됩니다. 간단한 서류 면접을 통과하면 곧바로 면접을 보시게 됩니다. 채용 기간은 정해져 있지 않습니다. 원하는 자리가 채워지면 마감 공고를 올릴 생각입니다. 기다리지 마시고 지원해 주시길 바랍니다.

 

개발자의 시행 착오

Posted 2007. 10. 22. 23:20
스티브 맥코넬의 [Professional 소프트웨어 개발]에도 나오는 이야기지만 프로그래머들은 보통 다음과 같은 시행 착오를 겪습니다.

1. "내가 이 프로그램의 문법 에러를 모두 잡아내고 컴파일이 될 때쯤이면, 컴퓨터 프로그래밍 도대체 무엇인지 알게 될 거야."
(코딩)

2. "내가 이 프로그램을 완벽히 디버깅할 때쯤이면, 프로그래밍이 무엇인지 알게 될 거야."
(디버깅, 테스팅)

3. "멋진 설계를 어떻게 하는지 알게 될 때쯤, 소프트웨어 개발이 뭔지 알게 될 거야."
(설계)

4. "내가 요구사항을 잘 뽑아내는 방법을 알게 될 떄쯤, 나는 소프트웨어 개발이 뭔지 알게 될 거야."
(요구사항 분석)

사람마다 차이는 있겠지만 대부분의 개발자는 위와 같은 순서대로 필요한 기술을 익혀나가는 것 같습니다.  근데 꼭 이 순서대로 학습하는 방법 밖에 없는 것인지, 이게 올바른 방법인지는 잘 모르겠네요.


API 스터디 참여하실 분.

Posted 2007. 10. 17. 09:52
블로그 방문하신 분 중에 API 스터디에 관심을 가지셨다 이미 끝난 줄 알고 안타까워 하시는 분들이 많이 계십니다. API 스터디는 현재 일주일에 한 번(조정 가능) 정기적으로 열리고 있습니다. 모든 분들에게 열려 있는 모임이니 관심 있는 분들은 참여 의사를 밝혀주시면 됩니다.

현재 구글그룹스를 통해 메일링 리스트를 운영하고 있습니다. 참여 의사가 있으신 분은 아래 주소로 가셔서 가입하시고, 간단히 자기 소개를 해주시면 됩니다. 메일링 리스트에 가입하시면 모임 관련해서 각종 공지를 받아보실 수 있습니다.

http://groups.google.com/group/apistudy

원래 모임은 매주 화요일에 열리는데, 이번주는 Google Developer Night 행사 관계로 일정이 조정되서 목요일 오후 8시 서울 파이낸스 센터 22층 구글코리아에서 모임을 갖습니다. (벌써 내일이네요.)




Google Developer Night 후기

Posted 2007. 10. 17. 09:43
어제 많은 분들이 참석했던 Google Devloper Night 2007에 다녀왔습니다. 사실 업무에 바빠 그런 행사가 있는지도 모르고 있다 월요일에 프로그래머 류님의 도움으로 급히 신청을 했습니다.

행사 이름만 보고는 지난 5월 전세계적으로 펼쳐진 Google Develop Day의 연장선으로 봤는데, 실제 행사는 개발자의 밤이라기 보다는 '구글 인재모집'에 더 어울렸던 것 같습니다. 구글 입사에 관심을 가지고 계셨던 분은 실제 구글러분들을 만나보고 이런 저런 질문을 할 수 있는 유익한 기회였겠지만, 저처럼 구글 본사에서 온 엔지니어가 뭔가 재미난 이야기를 해주지 않을까라는 생각에 참여한 사람들은 조금 실망했을 것 같습니다.

Vint Cerf 부사장의 카리스마가 뿜어져 나오던 '인터넷의 미래' 세션(사실 내용은 학부 때 네트워크 강의 첫 수업 느낌)은 유명한 사람 직접 볼 수 있다는 것만으로 충분했습니다. 하지만 Google Gadget이나 Google Map API 등의 소개는 거의 튜토리얼 수준에 그쳤던 것 같습니다. 같은 시간에 기술 문서를 읽어도 알 수 있을 수준으로 말이죠.

예전 메릴랜드 대학 있을 때 구글 리쿠르팅에 가본 적이 있는데, 그때는 메릴랜드 졸업한 구글 1-2년 차 엔지니어가 와서 자기가 하고 있는 일 위주로 소개를 하고 구글에 대해 여러 가지 질문을 방식으로 진행되었습니다. 그때 발표한 내용이 차라리 어제 개발자의 밤보다는 더 깊이 있는 내용을 다루지 않았나 라는 생각이 들었습니다.

어쨌던 좋은 인재 많이 채용하셔서, 다음에는 정말 얻어갈 것이 많은 정식 Google Developer Day를 한국에서 개최하기를 기대해 봅니다. 연어 샌드위치 잘 먹었어요. 프로그래머 류님에게 감사. 행사 세트장도 신경을 많이 쓴 것 같고, 기념품도 마음에 듭니다.

API 스터디 2차 모임 후기

Posted 2007. 10. 3. 22:31
어제 API 스터디 2차 모임이 있었습니다. 1차 모임에 비해 2배가 넘는 인원이 참가해 주셨네요. 모두들 바쁘신 와중에도 참석해 주셔서 감사 드립니다. 첫 모임 때 친해질 기회도 없이 간단히 모임만 하고 헤어져서 아쉬웠는데, 어제는 간단히 뒤풀이도 할 수 있어서 좋았습니다.

어제 모임에서 크게 두 가지를 이야기했습니다. 제가 API 사용성(Usability)에 대한 내용을 발표했고, 이어서 타마짱님이 API 디자인에 대한 케이스 스터디를 진행해 주셨습니다.

API 사용성은 올해 ICSE(International Conference on Software Engineering)에 발표된 <The factory Pattern in API Design: A Usability Evaluation>이라는 논문을 중심으로 이야기를 진행했습니다. 논문은 결론은 팩토리 패턴이 여러 장점에도 불구하고 API 사용성 측면에서는 사용자들에게 큰 불편을 초래한다는 것입니다.

일례로 실험에 참가한 개발자들에게 자바를 사용해 MulticastSocket과 SSLSocket을 생성해 보라는 과제를 냅니다. MulticastSocket는 생성자를 이용해 바로 인스턴스를 생성해 낼 수 있는데 비해, SSLSocket은 SocketFactory의 서브클래스인 SSLSocketFactory를 이용해 인스턴스를 생성해야 합니다.  결과는 MulticastSocket은 대부분 쉽게 생성할 수 있었지만, SSLSocket 생성에는 상당히 시행 착오가 발생했습니다.

마이크로소프 사의 경우 .NET 프레임워크 개발과 함께 API 사용성를 상당히 강조하고 있습니다. MS가 API 사용성 검증을 위해 어떤 절차를 밟고 있는지 보시려면 <Designing .NET Class Libraries: API Usability>를 참조하시기 바랍니다. 우측 상단에 보시면 강연 비디오를 다운받으실 수 있습니다. 더불어<Windows Workflow Foundation API Usability Lab Video>도 참고하시기 바랍니다.

디자인 시 고려할 점.

Posted 2007. 9. 18. 04:27

모듈이 할 수 있는 일을 클라이언트가 하게 하지 말아야 한다.

사용자가 단순 반복되는 코드(boilerplate code)를 작성하지 않도록 해야 한다. 반복되는 코드는 주로 잘라 붙이기(cut-and-paste)를 통해 구현되며, 이렇게 작성된 코드는 실수를 범하기가 쉽다. 따라서 API를 사용해 여러 유스 케이스를 구현해보고, 동일한 코드가 반복된다면 해당 코드를 API 안으로 집어넣어서 사용자가 쉽게 사용할 수 있어야 한다.

사용자가 놀라게 하지 말아야 한다(The Principle of Least Astonishment).

API는 사용자가 예상치 못했던 행동을 해서 놀라게 하는 일이 없어야 한다. 대표적인 예가 Thread 클래스에서 interrupted() 메서드를 불렀을 때 인터럽트 되었는지 여부를 리턴할 뿐만 아니라, 인터럽트 플래그를 클리어시키는 것이다. interrupted() 메서드 이름만 봤을 때는 이진 플래그를 리턴하는 간단한 질의 메서드를 떠올리게 되는데, 사용자가 예상치 못하게 플래그를 클리어하는 부작용이 있다. 이 메서드가 하는 중요한 역할은 인터럽트 플래그를 리턴하는 것이 아니라 인터럽트 플러그를 클리어하는 데 있으므로, clearInterrupt()라고 명명하는 것이 나았을 것이다.

빨리 실패해야 한다.

문제가 있으면 최대한 빨리 발견되는 것이 좋다. 타입 검사를 통해 컴파일 타임에 발견되면 제일 좋고, 런타임의 경우 잘못된 메서드가 호출되었을 때 즉시 이상이 있음을 알리는 것이 좋다. 문제가 중첩되고 있는데, 나중에서야 알려주면 문제가 시작된 지점이 언제인지 찾기가 어려워진다. 결국 디버깅이 불가능해진다.


역시 마소 원고 쓰다가 남은 부분입니다. 전체 리스트는 아니고 고려해야할 사항 중에 일부입니다.

SPI(Service Provider Interface) 디자인

Posted 2007. 9. 18. 04:20

SPI는 보통 플러그인(plugin) 형태로 같은 기능을 여러 벤더에서 제공할 수 있도록 만든 특수한 프로그래밍 인터페이스(API)이다. 일례로 JCE(Java Cryptography Extension)의 경우 암호 알고리즘에 대한 일반적인 인터페이스만 정의하고, 실제 구현은 암호 알고리즘을 가지고 있는 벤더들이 제공할 수 있도록 되어 있다. 또 다른 예로, 자바 XML 파서의 경우도 인터페이스만 제공하고, 실제 XML 파서는 여러 벤더의 파서를 사용할 수 있도록 SPI를 제공하고 있다.

SPI 디자인은 API 디자인보다 더 까다롭다. 흔히 하는 실수 중에 하나가 하나의 벤더만 살펴보고, 그 벤더에 맞춰서 SPI를 디자인하는 경우다. 이렇게 디자인하면 특정 벤더는 매우 쉽게 통합할 수 있지만, 다른 벤더의 지원이 어렵거나 불가능해질 수도 있다. SPI 디자인은 3의 법칙(The Rule of Threes)을 따른다. 최소한 3개 이상의 벤더를 살펴보고, 이들을 고루 지원할 수 있는 SPI를 만들어야 한다는 뜻이다. 1개만 보고 만든 SPI는 다른 벤더를 지원하는 것이 불가능할 가능성이 크고, 2개 벤더만 참조한 SPI는 제3의 벤더 지원이 까다로울 수 있다는 경험에서 나온 법칙이다.


API 디자인에 대한 9월 마소 원고 작성하다가 분량 때문에 짤린 내용입니다^^...

API 디자인 공부하실 분?

Posted 2007. 9. 15. 10:18

어떤 분야에 종사하는 개발자든 피해갈 수 없는 관문이 있으니 바로 API 디자인입니다. 임베디드 시스템부터 웹 프로그래밍까지 어느 직군에 종사하던 자신의 작성한 소스 코드를 다른 사람이 사용할 수 있는 형태로 만드려면 어떤 식으로든 API 디자인이 빠질 수 없습니다.

저도 프로그래밍 언어와 더불어 항상 관심을 가지고 보고 있는 쪽이 API 디자인입니다. 특정 도메인 기술과 달리 API 디자인은 상당히 일반적이면서도 잘 하기가 힘듭니다. 일반적으로 상당한 지식과 경험, 운이 따라야만 제대로 된 API가 나올 수 있다고 합니다. 좋은 API를 어떻게 디자인하고 왜 그렇게 해야 하는지 알고 싶으면 Joshua Bloch의 <How To Design a Good API and Why it Matters> 강연을 꼭 들어보시기 바랍니다. 제가 개인적으로 제일 좋아하는 강연 비디오입니다.

개인적으로 API 디자인과 관련된 글은 빠짐없이 찾아읽는 편인데, 이것만으로는 부족하다는 생각이 많이 듭니다. 실제로 좋은 라이브러리나 프레임워크를 많이 분석하고 왜 이렇게 디자인했는지, 다른 방법은 없었는지 등을 논의해보는 자리가 있으면 좋을 것 같다는 생각이 듭니다.

API 디자인을 조금 더 공부해보겠다는 욕심이 있으신 분은 같이 공부해 보면 좋겠다는 생각이 듭니다. 제 블로그에 오시는 분들은 저랑 관심사가 비슷할 것이라는 생각에 스터디 공고를 내봅니다. 4-5명만 모여도 충분히 케이스 스터디가 될 것 같은데 여러분 생각은 어떠신지요?




주중에 바빠서 한 동안 블로그 확인을 못하고 있었습니다. 신청자가 한 명도 없을 줄 알았는데 생각보다 많은 분들이 리플 달아주셨네요. API 디자인을 어떻게 공부해야 한다는 방법은 없기 때문에 각자 맡은 분야에서 인상 깊게 사용한 라이브러리나 프레임워크를 중심으로 케이스 스터디를 하는 것이 좋다는 게 기본적인 아이디어입니다. 다양한 백그라운드를 가진 분들이 나오시면 더욱 좋겠죠.

일단 첫 모임을 가지고 이야기를 해보는 게 좋을 것 같습니다. 첫모임에는 제가 간단히 좋은 API 디자인이란 무엇인가를 주제로 원칙적인 이야기만 간략히 소개하고, 진행 방향에 대해 이야기했으면 합니다. 다만 시간이 언제가 제일 좋을지 모르겠네요. 영어 스터디 모임처럼 일요일 아침 10시에 하면 아무도 안 나오시겠죠? ^^....  생각해보니 참석 의사를 밝히신 분의 연락처를 못 받아서 일단 연락처가 있는 G모사 근무중인 류준호님과 이야기하고 첫모임 시간 및 장소를 잡아보도록 하겠습니다.


참여하실 의지가 있으신  분은 댓글에 이메일 주소를 남겨주세요!



첫 모임 장소와 시간을 확정했습니다. 대망의 첫 모임은 9월 18일 화요일 오후 8시 강남 파이낸스 센터(구 스타타워) 22층 구글코리아에서 열립니다. 장소를 제공해주신 프로그래머 류님에게 감사^^.
그리고 9월말부터 참석하실 수 있다는 분들도 괜찮습니다. 첫 모임 다음주가 추석이라서 9월에는 한 번 밖에 모일 수가 없을 듯 싶네요. 첫 모임에서는 모임의 진행 방향을 결정하고 친분을 쌓는 시간을 가졌으면 합니다!

API 디자인 스터디

장소: 서울 파이낸스 센터(구 스타타워 22층) 구글코리아 사무실


시간: 2007년 9월 18일 화요일 오후 8시


최재훈 님이 번역하신 [Ship It: 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드]를 읽었습니다. 특정 방법론에 치우치지 않고 소프트웨어 개발에 있어서 베스트 프랙티스라고 할 수 있는 요소인 빌드 자동화, 이슈 추적, 기능 추적, 테스트, 할 일 관리, 코드 검토, 코드 변경 통지 등을 간략히 설명하고 있습니다.

과거와 달리 요즘은 방법론 책도 많고 프로젝트 관리에 대한 책도 많아서 일반 개발자가 전혀 모를 새로운 내용은 없습니다. 하지만 각각의 베스트 프랙티스를 간단 명료하게 잘 설명하고 있어서 현재 프로젝트를 진행하고 계신 분은 체크리스트로 활용하실 수 있으리라 생각합니다. 저도 책 읽고 나서 차일 파일 미루고 있었던 지속적인 통합(Continuous Integration)나 코드 변경 통지 같은 작업을 했습니다.


빌드 스크립트

Posted 2007. 9. 11. 01:26
오늘은 빌드 스크립트를 만드는 데 하루를 소진해 버렸습니다. 파이썬 프로젝트는 distutils를 사용하는 것이 일반적이지만 윈도 EXE 파일을 생성할 필요도 있고, 당장 의존성이 없는 모듈도 상당 부분 포함시켜야 하는 데다가 setuptools, pkg_resources 등이 얽혀 있어서 다른 도구를 찾아보기 시작했습니다.

윈도 환경에서 가장 많이 쓰는 패키징 도구인 py2exe는 setuptools와 호환되지 않고 DLL 의존성 검사하는 방식도 제어를 할 수가 없어서 포기하고, bbfreeze, PyInstaller, cx_Freeze 등 여러가지를 조사해봤는데 요구사항이 딱 떨어지는 게 없어서 좌절했습니다. EXE 파일을 직접 Python C API 임베딩해서 생성하고 나머지 작업을 하려고 해도 또 애매하더군요. 루비의 rake와 유사한 도구가 있지 않을까 해서 좀 찾아봤으나 역시 마땅한 게 없더군요.

결국 별로 한 것도 하루 하루가... 이럴 때가 제일 허무합니다.



지난 번에 공지드린 노매드커넥션 지원이 마감 되었습니다. 하지만 실력있는 인재들을 위한 문은 언제나 열려있습디다.


사용자 삽입 이미지


좋은 분들이 많은 관심을
가져 주셔서 우선 감사드립니다.

저희에게 메일을 보내주셨던 분들은
저희의 개발 철학이나 방향에 대해서 관심을 가져주시고
메일을 보내주셔서 더욱 감사드립니다.

새로운 방식으로의 접근, 창의적인 사고 등 기존과는 다른
형태로의 소프트웨어의 개발 및 전개에 대해서
공통된 관심을 가진 것으로 보고 저도 놀랐습니다.

약속한 대로, 9월 7일까지 도착한 메일에 한에서
주중(9월 10일-14일)에 개별적으로 연락을 드리도록 하겠습니다.
그리고, 개별적인 미팅을 진행할 예정입니다.

혹시나, 마감은 되었지만, 이후에도 저희 까멜레오 또는 (주)노매드커넥션에
관심을 가지고 계신 이 땅위에 열정이 있는 개발자분들은 언제든지
join@nomadconnection.com으로 지원해주시면
차후에 연락을 드리도록 하겠습니다.

관심을 가져 주신 모든 분들께
감사드립니다.

Buildbot 설치

Posted 2007. 9. 7. 17:34
어제 하루 시간을 할애해서 파이썬으로 작성된 CI(Continuous Integration, 지속적인 통합) 도구인 Buildbot을 설치하고, 설정을 마쳤습니다. Buildbot은 파이썬 네트웍 라이브러리인 Twisted 프로젝트에 사용되고 있고, 그 외에도 여러 파이썬 프로젝트의 CI 도구로 많이 사용되고 있습니다. Buildbot: Twisted 페이지는 실제 Buildbot의 수행 결과인데, 여러 빌드가 시간 별로 어떤 상태에 있는지를 쉽게 확인할 수 있습니다.

CI 도구의 핵심은 빌드와 테스트를 자동으로 수행해 빌드를 깨먹거나 기능을 망가뜨리는 범인을 빠른 시간을 색출하는데 있습니다. XP(eXtreme Programming)의 베스트 프랙티스로 많이 알려져 있는데, 사실 그 이전부터 있었던 아이디어로 보이고, 마틴 파울러(Martin Fowler), 스티브 맥코넬(Steve McConnell) (Smoke Test라는 용어를 사용)등의 전문가들도 지속적으로 CI의 중요성을 강조하고 있습니다. 마소 필자이신 최재훈 님도 <지속적인 통합 (Continuous Integration) 소스코드 커밋과 수정과정 확인하기>라는 글에서 CI의 개념과 중요성을 잘 정리해 주셨습니다.

파이썬 디자인 패턴

Posted 2007. 8. 31. 18:19
구글 개발자의 날 US(Google Developer Day US)에서 Alex Martelli가 발표한 Python Design Patterns를 봤습니다. (광식님께 감사.) 새로운 디자인 패턴을 소개하거나 깊이 있는 내용을 다룬 건 아니지만, 기존 디자인 패턴 책들이 대게  C++, 자바 위주로 서술된 것에 비해 이 발표에서는 파이썬을 중심으로 디자인 패턴을 간결하게 설명하고 있습니다. 기억이 가물가물 하신 분은 시간 내서 한 번 보시면 좋을 듯 합니다. 참고로 발표자인 Alex Martelli는 <Python in a Nutshell>의 저자이고, <Python Cookbok>의 에디터이기도 합니다.

그런데 발표  중에 소개된 Singleton 예제를 보면 __init__  메서드가 반복적으로 불리는 문제가 있습니다.

class Singleton(object):
    def __new__(cls, *a, **k):
        if not hasattr(cls, '_inst'):
            cls._inst = super(Singleton, cls).__new__(cls, *a, **k)
        return cls._inst

    def __init__(self):
        print "__init__"


$ python -i a.py
>>> s = Singleton()
__init__
>>> s
<__main__.Singleton object at 0x00C8FC70>
>>> s = Singleton()
__init__
>>> s
<__main__.Singleton object at 0x00C8FC70>
>>>


왜냐하면 파이썬은 다음과 같이 2단계 생성(2-phase construction)이라고 해서 생성과 초기화를 구분하고 있기 때문이죠.

def__call__(cls,*a,**k):
    nu = cls.__new__(cls,*a,**k)
    if isinstance(nu, cls):
        cls.__init__(nu,*a,**k)
    return nu

전 이 문제를 해결하기 위해 메타클래스(metaclass)에서 __init__ 메서드를 초기화 여부를 확인하는 메서드로 바꿔치기 하고 그 안에서 원래 __init__을 부르는 수법을 썼는데, 다른 해결책이 있을까요?


Google Singleton Detector

Posted 2007. 8. 30. 16:27
구글이 Google Singleton Detector(이하 GSD)라는 재미있는 프로젝트를 내놨더군요. GSD는 자바 바이트코드를 분석해 싱글톤 패턴을 찾아주는 프로그램입니다. 싱글톤을 식별해 내고, 싱글톤에 의존적인 클래스를 그래프 형태로 뿌려주기 때문에 프로그램 내의 글로벌 상태와 이에 의존적인 코드를 쉽게 찾아낼 수 있게 됩니다.

GSD는 싱글톤을 타입에 따라서 Singleton(우리가 일반적으로 알고 있는 자바의 singleton 패턴), Hingleton(helper 클래스를 이용하면 singleton), Mingleton(method signleton), Fingleton(public static field 사용하는 field singleton)으로 구분하고 있습니다. 관련된 내용은 Understanding the Graph를 참고하세요.

이 프로그램의 목적은 싱글톤 패턴을 찾아서 제거하려는 데 있습니다. 구글에서는 싱글톤 패턴을 제거해야 하는 아주 해로운 패턴으로 판단했나 봅니다. 프로젝트 페이지를 읽어보시면, 싱글톤은 테스트를 어렵게 만들고, 디자인의 문제를 숨기는 역할을 한다고 이야기하고 있습니다. 사실 싱글톤 패턴은 처음 디자인 패턴을 접한 분들이 이해하기도 쉽고, 기존 코드에 적용하기도 쉬워서 애용(혹은 오용) 되어 왔는데, 이제는 자동화된 도구를 만들어서라도 제거하려는 안티 패턴(anti pattern)이 되고 말았군요.

결국 어떤 패턴이던지 어떻게 사용하느냐의 문제인데, xxxManager, xxxRegistry 등의 클래스가 범람하고 모든 클래스가 싱글톤이 되어서 복잡하게 얽혀 있으면 전역 변수 사용과 다를 바가 없겠지요. 반대로 정말 시스템이 하나만 존재해야 하는 인스턴스의 경우 싱글톤이 필요할 것입니다. Bruce Eckel은 자신의 웹로그에 남긴 Singleton Considered Harmful?이라는 글에서 싱글톤 패턴 자체는 나쁘지 않다는 견해를 밝혔군요.

어쨌거나, 자바로 프로젝트 하시는 분들은 한 번 돌려보시고, 프로그램 내에 전역 변수가 어떻게 얽혀 있는지 한 번 보시는 것도 좋을 것 같습니다.



프레임워크와 개발자의 상상력

Posted 2007. 8. 30. 15:59
요즘은 프레임워크 없는 개발은 상상하기 힘든 세상이 되어 버렸습니다. 예를 들어 웹 개발을 한다고 하면 프로젝트의 성격에 따라 J2EE 급의 프레임워크를 쓸 것인지 Django나 Ruby on Rails처럼 간단한 프레임워크를 사용할 것인지 결정하는 일이 제일 중요합니다. 그리고 이렇게 결정된 프레임워크를 습득하고 사용하는 일이 프로젝트의 대부분을 차지하고 있습니다.

오늘 Artima.com을 보니 Overstock.com의 Chris Maki와의 인터뷰가 Do Frameworks and APIs Limit Developers' Imagination? 라는 제목으로 올라왔던데, 결론은 제목 그대로입니다. 프레임워크가 생산성을 비약적으로 발전시켜 주기는 했지만, 프로그래머의 상상력을 제한하는 부정적인 측면도 있다는 것이죠. 복잡한 것 생각할 필요 없이 프레임워크가 다 해주니깐 편하긴 한데, 프레임워크에 익숙해질수록 내가 하는 일이 없다는 생각이 드는 게 문제입니다.

제가 일하고 있는 노매드커넥션에서 저와 함께 일할 개발자를 뽑습니다^^. 실력과 열정은 있지만, 재미있는 일을 찾지 못해서 헤매고 있는 개발자 분들은 반드시 한 번 고려해 보시기 바랍니다.

노매드커넥션에 합류하시면, 현재 열심히 개발 중에 있는 까멜레오 프로젝트(http://www.chameleo.org) 개발에 참여하게 됩니다. 이미 다 만들어진 제품의 유지보수나 일회성 프로젝트가 아닌, 신제품을 함께 만들어 나갈 수 있는 기회를 얻으실 수 있습니다. 더불어 국내에서는 보기 드물게 오픈소스 프로젝트의 즐거움을 함께 하실 수 있습니다.

구체적인 일정과 지원 방법은 자세한 내용은 아래 채용 공고를 참고하시기 바랍니다. 아래 내용에 기술 스펙은 나와 있지 않은데, 까멜레오는 C/C++과 파이썬으로 작성되어 있습니다. 하지만 파이썬 경험이 없더라도 기본기에 충실한 정통파 개발자라면 누구나 환영합니다. 더불어 웹관련 기술을 습득하고 계시면 더욱 환영합니다.

혹 궁금한 내용 있으면 질문 주세요!



사용자 삽입 이미지


저는 (주)노매드커넥션의 대표입니다.
 
대표가 관리비도 직접 내고,
회식 장소도 알아보는 작은 기업이지만,
채용 공고와 면접은 회사가 커가더라도
본인이 직접 계속하겠다고 하는 대표입니다.
이유는, 소프트웨어 회사에서의 핵심은 기술이 아닙니다.
소프트웨어 회사에서의 핵심은 유일하게 '사람'입니다. 
즉, 핵심은 기술을 담고 있는 '사람'입니다.
 
추구하는( 선발하고자 하는) 인재를 말하기 이전에  
우선, (주)노매드커넥션이라는 회사에 대해서 말해보도록 하겠습니다.
 
(주)노매드커넥션은 설립 3년차에 들어섰으며,
설립 2년만에 Break-even Point에 도달했습니다.
Dr.NET (닥터넷)이라는 네트웍 보안 제품
을 판매하고 있으며,
Chameleo (까멜레오)라는 동영상 미디어 플랫폼을 만들고 있습니다.

매년 새로운 컨셉의 Product을 내놓을 정도로
새로운 분야에 새로운 방식으로 도전하고 있는 젊은 기업입니다.
무엇을 하더라도 기존과는 다른 방식으로 도전하려고 하고 있고,
단기적인 목표는 우리의 손으로 만든 원천 기술로 실리콘밸리에 진출하는 것입니다.
 
그럼, 추구하는 인재를 말해보도록 하겠습니다.
▷ 개발에 자신있는 자
다른 조건이 없습니다.
나이가 젊든 나이가 많든,

고등학생이든 대학생이든 또는 쉬고있는 분이든,
환영입니다. 개발을 좋아하고 신나게 할 수 있으면 됩니다.

개발에 자신없는 자
단 한 가지, 열정이 있으면 됩니다.
추제할  수 없는 열정이 있고, 그 열정이 지칠줄 모르면 됩니다.
(제가 최고라고 생각하는 두 분의 개발자분들과 Co-Work 하면 됩니다.)
 
그러면서, 저희는 디자인적인 감각이 있는 인재를 추구합니다.
전문적이지는 않더라도 (최소한)추구합니다.^^ 
, 좌뇌도 중요하지만, 우뇌도 충분히 중요하게 생각합니다.
 
이런 인재를 찾고 있습니다.
본인이 그럴 수도 있고, 주변에
이런 분이 계시다면 join@nomadconnection.com 으로
간단하게 자유 형식으로 의견을 피력해주신다면 감사하겠습니다.
 
※ 참고1
1차로 8월 20일부터 9월 7일까지 join 메일을 받도록 하겠습니다.
메일이 오는 순서대로 저와 개발자분들이 직접 가서 또는 지원자가
방문하여 인터뷰를 할 예정입니다.

※ 참고2
큰 뜻이 맞다면, 상세한 사항들은 언제든지
join 메일로 또는 직접 대면하여 문의해주시면 감사하겠습니다.

벤처와 인재

Posted 2007. 8. 20. 03:40
요즘 가는 가는 곳마다 좋은 인재 없냐고 난리입니다. 최근 노매드커넥션에서도 인력 충원을 준비하고 있습니다. 까멜레오 개발에 속도를 보태려는 개발자 인력 충원 계획입니다. 이전에 "A급 인재를 어떻게 잡을 것인가?"라는 글을 쓴 적도 있는데, 그때의 결론은 좋은 인재에게는 그에 상응하는 보상을 해줘야 한다는 것이었습니다. 여러 요소가 있지만 물질적인 요소를 무시해서는 안 된다는 것이 논지였죠.

그런데 정작 벤처에 몸담으면서 사람을 뽑으려니 이게 말처럼 쉬운 게 아니긴 합니다. 우리 회사도 그렇지만, 사실 달라는 데로 돈 다 줄 수 있으면 벤처 기업을 할 이유가 없습니다. 벤처는 결국 아직 돈을 잘 못 버는 배고픈 회사이기 때문입니다.

최근 화두는 작은 기업에서 연봉 외에 열정적인 개발자에게 제시할 수 있는 가장 매력적인 요소가 무엇일까 하는 점이었습니다. 오랜 고민 끝에 내린 결론은 가치 있는 프로젝트에 참여할 수 있다는 사실과, 그 프로젝트를 통해 성장할 수 있는 경험을 주는 것입니다. 이력서에 한 줄 적었을 때 이력서가 빛날 수 있는 멋진 프로젝트 말이죠.

회사에 뼈를 묻어 충성할 사람보다는 열정과 야망이 너무 커서 몇 년 후에는 더 큰 프로젝트를 찾아 떠나갈 수 있는 사람이 더 좋습니다. 그런 개발자들이 성장할 수 있는 곳, 또 적극적으로 개발자를 키우고 후원해 줄 수 있는 배짱 있는 회사가 되는 것이 제가 일하는 노매드커넥션의 목표입니다.

실제 구인 공고가 나오면 제가 생각하는 인재와 그 인재를 위해 우리가 해줄 수 있는 일을 더 구체적으로 글을 쓰겠습니다.


벤처 기업을 한다는 것

Posted 2007. 8. 20. 03:06
요즘은 까멜레오(http://www.chameleo.org 현재 제가 개발 중인 미디어 플레이어입니다) 알파 릴리즈(클로즈드)를 위한 마무리 작업을 열심히 하고 있습니다. 원래 알파 버전 릴리즈 계획을 8월 중순으로 잡았는데, 생각보다 사소한 문제들이 많은 관계로 일정이 조금 지연되고 있어서 속이 탑니다.

오늘 회사에 모여서 회사의 존재 이유, 까멜레오라는 제품을 통해 무엇을 이루고 싶은지를 진지하게 이야기하는 시간을 가졌습니다. 분명 회사를 시작하고, 제품을 기획할 때 어느 정도 이야기를 나눈 사안임에도 불구하고, 그 동안 구체적인 제품의 형태를 만들어 나가는 데 정신을 팔려서 왜 이 제품을 만들기 시작했는지를 잊고 있었다는 사실을 깨달았습니다.

1년 앞을 내다볼 수 없는 게 신생 벤처 기업인데, 그동안 너무 안이한 마음을 가지고 있었던 게 아닌가라는 생각을 해봅니다. 작은 회사에서 대기업처럼 명확히 일을 구분해서 할 수 있는 것도 아닌데, 막연히 내 역할을 '기술', '개발', 구현'이라고 한정하고 그 울타리 속에서만 활동했다는 생각도 들었습니다. 물론 각자의 전문 분야가 있지만, 좁은 시야에서 구현하는 데만 치중해 정작 본질을 놓치고 있는 건 아닌가라는 생각도 들었고요.

벤처 기업은 좀 더 능동적으로 행동해야 합니다. 주어진 일을 해내는 것은 당연하고, 나 스스로 끊임 없이 일을 찾아서 만들어 내는 능력이 필요합니다. 벤처 기업은 더 열정적이어야 합니다. 정량적으로 계산하고 최적화된 효율을 찾는 것도 좋지만, 벤처의 마인드는 다소 비효율적이더라도 밤을 새며 비전을 얘기하고 기술을 개발하며 즐거워할 수 있어야 합니다.

제품 개발 4개월, 알파 버전이긴 하지만 첫 릴리즈를 앞둔 시점에서 가장 중요한 것은 초심을 되찾는 게 아닌가 합니다.

마소 정기 구독

Posted 2007. 8. 20. 02:03
금요일에 마이크로소프트웨어(일명 마소) 편집장님에게 전화가 왔습니다. 조심스레 정기 구독 이벤트 홍보를 부탁하셨는데 일에 치이다 보니 이제서야 올리게 되었습니다. 마소를 사랑하는 독자이자 필자로서 흔쾌히 수락하긴 했지만 블로그에 광고성은 글을 올린 적도 애드센스 같은 광고를 달아 본적도 없기 때문에 조금 조심스럽긴 합니다. 사실 광고 달만큼 별로 잘 나가는 블로그도 아니긴 하지만 말이죠.

저는 어린 시절 장래 희망에 줄곧 컴퓨터 프로그래머라고 적어냈습니다. 초등학교 3학년 때 정한 꿈은 그 뒤로 한 번도 바뀐 적 없었고 결국 지금 개발자로 밥을 먹고 살게 되었네요. 그 시절 작은 동네 컴퓨터 학원 말고 최신 기술을 배울 수 있는 유일한 창구가 컴퓨터 잡지였죠. 잡지에 소개된 베이직 코드를 한 줄 한 줄 입력해서 프로그램을 실행해보고 신기해 하던 기억이 떠오릅니다.

지금은 인터넷 기술도 발달하고 많은 정보가 웹에 올려져 있지만, 그래도 국내 개발자 분들의 따끈따끈한 글들을 매달 읽을 수 있어 좋습니다. 하지만 마소와 함께 개발 잡지의 양대 산맥이었던 프로그램 세계가 폐간했고, 한때 마소도 폐간 한다는 이야기가 있었습니다. 다행히 주인을 바꾸고 현재까지 그 명맥을 이어가고 있지만, 인력도 많이 줄고 지금은 작은 규모로 운영하고 있는 상황이고요.

개인적으로는 마소도 잘 되고, 마소 같은 잡지가 더 많이 생겨서 더 많은 실력 있는 개발자들을 발굴하고 그들의 지식을 다른 분들에게 전파할 기회를 만들었으면 좋겠습니다. 인터넷 웹진이든 기존의 종이 잡지든 상관 없이 이렇게 지식을 교류할 수 있는 장이 많다는 것 만으로 우리 모두가 얻을 수 있는 이익이 많다고 생각하거든요.

아래는 편집장님이 주신 정기 구독 이벤트입니다. 마소 보실 분들은 정기 구독하셔서 집에서 편히 잡지 받아 보시고, 선물도 받으시면 좋을 듯 합니다^^... 편집장님 돈 많이 버셔서 필자 원고료도 좀 올려주세요. 물가는 치솟는데 원고료는 매년 그대로인 듯 합니다. 흑흑.



월간 마이크로소프트웨어가 8 한달간 정기구독 신청자를 위한 Summer Cool Event 진행합니다.

자세한 내용은 아래를 참고하시기 바랍니다(http://imaso.co.kr/?doc=v2/promotion.php).

 

 

기간 | 2007 8 1일부터 8 31일까지

대상 | 마소 독자, 아이마소 회원

 

Event 1. 무더운 여름을 시원하게

독자의 마소 사랑에 보답하기 위해 이번 정기구독 이벤트 기간 1 이상 정기구독을 신청한 모든 독자 여러분에게 USB 방식의 미니 선풍기를 무료로 드립니다.

Event 2. 미니 선풍기 받고 마음에 드는 패키지 제품도 골라 갖자

패키지 1. 토마토 비디오 2GB + 마소 1 정기구독료

-> 162,000

 

패키지 2. 제닉스 스코프리우스-N2T + 마소 1 정기구독료

 -> 145,000

 

패키지 3. 에이콘소프트웨어 아키텍처: 이론과 실제’ + 마소 1 정기구독료

-> 128,000


파이썬 마을 번개 후기

Posted 2007. 8. 11. 01:37
오늘 오후 8시 야후 10층에서 있었던 파이썬 마을 입추 기념 번개에 다녀왔습니다. 파이썬 모임에는 처음 참석했는데, 퍼키님이 파이썬 3000에 어떤 변화가 있을지 슬라이드와 함께 직접 파이썬 3.0a1을 시연하면서 보여주셨습니다. (퍼키님 수고하셨어요.) 뒷풀이도 참석했으면 좋았을 텐데, 다음주 제품 데모도 있고 일정이 빡빡해서 아쉬움을 뒤로 하고 돌아왔습니다.

파이썬 3000의 의도는 펄6처럼 거대한 변화를 시도하기 보다는 파이썬 초창기 디자인 실수를 하위 호환성을 포기하는 한이 있더라도 수정하겠다는 것입니다. 언어 전반에 걸쳐서 다양한 변화가 일어나지만, 개인적으로 가장 큰 변화라고 생각하는 부분은 str과 unicode 타입의 구분을 없애고 모든 문자열이 unicode가 된 부분입니다. 대신에 bytes 타입을 도입해서 raw data를 처리할 수 있는 방법은 열어 두었습니다. 최근에 유니코드 관련 구현이 완료되었다고 하는군요.

이번 달 말이면 파이썬 3.0 첫 알파 릴리즈가 나온다고 하니 관심 있으신 분은 미리 받아서 조금씩 익숙해지는 것도 좋을 듯 합니다. 파이썬 3000의 변화에 대해 궁금하신 분은 올해 초에 PyCon에서 귀도가 발표한 동영상을 참조하시기 바랍니다.
« PREV : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ··· : 13 : NEXT »