Bookworm’s Archive 잡동사니 속에 숨겨진 보물 찾기

9Dec/11

개발자 컨퍼런스에서 바라는 점

최근에 개발자 세미나 또는 컨퍼런스를 몇 번 다녀 왔습니다. 좋은 컨퍼런스를 준비하고 진행하신 분들께 깊이 감사 드립니다.

컨퍼런스 마다 특색이 있고 잘 된 점과 아쉬운 점이 있기 마련인데, 저는 그런 자세한 부분이 아닌 좀 더 크게 보아 국내 개발자 컨퍼런스에 이런 방향성이 추가 됐으면 좋겠다는 생각입니다.

우리나라의 개발자들에서 제일 부족하다고 느끼는 부분은 바로 네트워킹 입니다. 외국 컨퍼런스를 다녀오신 분들께 전해 들은 이야기로 해외에서는 이 사람들이 세션을 들으러온 것인지 아니면 명함 돌리러 온 것인지 알 수 없을 정도로 네트워크를 만드는 일이 활발하다고 합니다.

그에 비해 우리나라 컨퍼런스는 직장 동료나 친구, 동호회 사람들끼리 와서 세션 듣고 자기들끼리 수다 떨다 집에 돌아가는 모양새가 대부분입니다. 약간 발이 넓으신 분들은 유명하신 분들과의 네트워킹을 위해 움직이기도 하시지만 그게 개발자들끼리의 네트워크 구축이라고 보기는 어려울 듯 합니다.

그래서 저는 컨퍼런스의 주 방향과는 별도로 참석자들의 네트워크 구성을 위한 시스템이 필요하다고 생각합니다. 그래서 한가지 방법을 제안 해봅니다.

미리 사전 등록시 태그를 몇개 등록하도록 합니다. 이 태그를 활용해서 주요 관심사가 같은 약 8 - 10명 정도의 소규모 그룹을 미리 구성 해놓습니다. 불참자를 대비해서 약간 그룹이 더 커도 될 것 같습니다. 그리고 등록시 이메일, 트위터, 블로그 주소 등을 담은 스티커를 만들어서 나눠줍니다.

자. 컨퍼런스 중간에 1 시간 정도 네트워킹 시간을 별도로 할당하고 네트워킹을 위해 모여서 앉도록 합니다. 물론 각 그룹별로 리딩을 위해 미리 주최 측에서 준비한 사람이 리더로 참여하거나 미리 자원봉사자 형태의 리더를 지원 받아 둡니다. 자원봉사자 같은 경우 약간의 선물을 주는 것도 좋겠습니다. 이 사람이 사람들을 모으고 소개하며 관심사 및 여러 가지 이야기를 나눌 수 있도록 이끌어 나갑니다. 이런 행사 중에 아까 스티커를 롤링 페이퍼 식으로 하나씩 나눠서 받도록 합니다.

마지막으로 이런 네트워크 시간을 통해서 해당 그룹의 스티커를 일정 수 이상 모은 사람만 경품 행사에 당첨 자격을 주는 것입니다.

이렇게 손이 많이 가는 시스템을 마련해야 하는 이유는 현재로서는 자발적으로 네트워킹을 하는 분위기가 만들어질 것 같지 않고, 개발자들이란 시스템이 주어지면 금새 이해하고 거기에 맞춰 행동하는 훌륭한 적응력을 가지고 있는 사람들이기 때문입니다. :-)

앞으로 우리나라의 컨퍼런스들도 지식의 공유나 비전 습득과 더불어 이 땅에 사는 모든 개발자들이 서로를 이해하고 도와주는 그런 또 하나의 장이 되었으면 합니다.

26Nov/11

한국 오픈소스 프로젝트에 바라는 점

한국은 오픈소스의 불모지라고 불리지만 뜻 있는 분들과 일부 기업들의 후원으로 몇몇 규모 있고 주목 받는 프로젝트들도 있습니다. 그 중 저는 TextCube, XpressEngine, nFORGE를 유심히 보고 있습니다. 이 프로젝트들에서 아쉽게 느껴지는 부분이 있어 어떻게 하면 더 좋게 개선 할 수 있을까 궁리를 해 보았습니다. 여기서 말하는 것이 무조건 정답이라 하고 싶지는 않습니다. 다만 오픈소스를 좋아하고 관심 있게 보고 있는 한 개발자가 내놓은 진정어린 의견이라 봐 주었으면 합니다.

우선 세 프로젝트 모두 큰 판올림을 할 때 종종 근본부터 싹 다 갈아엎는 방식으로 개발하고 있는 점이 문제라고 생각됩니다. 개발자의 입장에서 기존 코드가 스파게티처럼 느껴질 수 있고, 신기술이나 새로운 모델을 도입하기도 쉽지 않을뿐더러, 이거 고칠 시간이면 새로 개발하는 것이 더 빠르겠다고 느껴질 수 있습니다. 그러나 전 두 가지 점에서 이런 방식으로 개발하지 않았으면 합니다.

첫 번째로 사용자들에게 부담이 됩니다. 아무리 좋은 소프트웨어라도 쓰는 사람이 없으면 버틸 수 없습니다. 특히 오픈소스처럼 사용자들의 피드백에서 나오는 보람이 참여의 큰 동기가 되는 경우는 더 중요하다고 생각합니다. 다 갈아엎음으로 생기는 업데이트의 부담을 비롯해 기존 플러그인이나 테마 개발자들의 재학습 비용과 능률 저하 문제 등을 감안하지 않는 것은 단순히 오픈소스 프로젝트가 개발자 그룹만의 것이 아니라 커다란 생태계로 구성되어 있다는 점을 간과한 결정이라고 생각합니다.

더구나 새로 재개발을 하면서 기존 버전에 충분한 관심이 기울여지지 않아 생기는 문제 또한 무시 할 수 없습니다. 이런 공백이 발생하는 동안 기존 사용자나 플러그인, 테마 개발자들은 지쳐서 좀 더 흥미 있는 프로젝트로 관심을 돌릴 가능성이 높습니다. 오픈소스에 사람들이 관심이 없는 것이 아니라 2 미터짜리 담장을 세우고 그 담장 너머로 지켜 볼 수 있을 만큼 키 큰 사람만 우리에게 관심을 가지라는 식으로는 한국의 오픈소스 규모를 키울 수 없다고 봅니다.

반복 개발과 빠른 릴리즈, 그리고 측정을 통한 테스트, 활발한 피드백을 통한 점진적인 개발과 지속적인 리팩토링 방식으로 프로젝트를 진행해야 한다고 생각합니다. 거기에 시간이 더 걸리더라도 하위 호환성을 유지하는 것이 매우 중요합니다.

제가 보는 또 다른 문제는 오픈소스 프로젝트의 커뮤니티를 관리하는 능력이 부족하다는 것입니다. 대부분의 국내 오픈소스 프로젝트를 보면 소수의 개발자, 디자이너, 번역자, 테스터 등으로 구성된 그룹이 있습니다. 안타까운 점은 이런 그룹의 구성이 대부분 현실 속의 관계로 구성된다는 점입니다. 프로젝트의 생태계라는 큰 그림으로 보았을 때 오히려 그 그룹은 소수에 불과한데도 말입니다.

저는 여기서 커뮤니티 관리자(Community Manager, 이하 CM)를 두어야 한다고 주장합니다. 한두 명이 개발하고 사용자도 수십 수백 정도라면 굳이 CM을 둘 필요는 없다고 봅니다. 하지만 위에서 예로 든 프로젝트 정도가 되면 CM은 꼭 필요하다고 봅니다.

이 CM은 사용자들의 피드백을 정리하는 것은 물론이고 공헌자 명단들을 작성하고 오프라인 행사를 기획/준비하는 일을 하게 됩니다. 즉, 프로젝트의 핵심 그룹만이 아니라 해당 프로젝트와 직간접적으로 관련된 모든 사람들이 보다 프로젝트에 관심을 갖고 긍정적인 인상과 참여에 대한 욕구를 고취시키는 일을 기획 및 운영하는 것입니다.

세계적인 프로젝트라면 단지 프로젝트의 품질만으로도 충분한 규모의 자생적인 커뮤니티를 만드는 것이 가능 할 수 있다고 봅니다. 그러나 한국을 중심으로 하는 프로젝트에서 자체 인력으로 모든 것을 완벽하게 해낼 수 없다면 외부의 많은 도움이 필요한데, 이런 것을 해결하기 위해서는 한국 사람들은 자신을 대접 해주지 않는 곳에 굳이 헌신하려들지 않는 습성을 이해 할 필요가 있습니다. 바꿔 말해 오픈소스 프로젝트로서 보다 많은 사람들의 도움을 받고 싶다면 아주 자세를 낮추고 과도하리만큼 친절해질 필요가 있다는 점입니다. 마치 내 월급을 주는 고객님을 모신다는 그런 정도의 태도 말입니다.

그동안 국내 오픈소스 프로젝트가 잘 안 되는 문제가 거론되면 주로 외부에서 원인을 찾고 정리했으나, 저는 몇 년 동안 국내 오픈소스 프로젝트를 지켜본 바로 프로젝트 내부 요인도 무시 할 수는 없다고 판단했습니다.

버그픽스 패치를 보냈더니 그것을 보고 따라 고쳐 놓은 후 마치 자신이 버그를 발견해서 수정한 것처럼 올라오는 오픈소스 프로젝트를 보면서 과연 그 사람이 다시 그 프로젝트에 버그픽스 패치를 보낼지 곰곰이 한 번 생각 해 봐 주셨으면 합니다.

12Nov/11

개발자에게 좋은 회사인지 간단하게 판단하는 방법

벌써 11월이고 이제 본격적인 취업 시즌이 오는 것 같습니다. 졸업 후 취직을 하려는 분도 계실 것이고, 이직을 하려는 분도 계실 겁니다. 취직이나 이직을 불문하고 회사를 고르는데는 많은 고민이 들게 마련입니다.

아무래도 외부인으로서 회사 내부 사정을 잘 알기 어렵고 겉과 속이 전혀 딴판인 회사들이 많기 때문입니다. 연봉, 복지 수준, 비전 등과 같은 외부 요인을 다 고려하지 않고, 오직 개발자라는 직종만을 고려했을 때 손쉽게 좋은 회사인지 판단 할 수 있는 기준을 하나 소개 할까 합니다.

반팔 면 티셔츠, 반바지, 그리고 맨 발 또는 양말에 샌달을 신고 근무가 가능한 회사면 개발자에게 좋은 회사일 가능성이 매우 높습니다.

제가 이 조건을 만족시키는 회사들도 다녀봤고, 아닌 회사들도 다녀봤습니다. 확실히 개발자의 입장에서 이 조건을 만족시킬 때 즐겁게 일 할 수 있었습니다. 여기서 즐겁다는 것은 근무 시간이 적절하다거나 연봉이 많다거나의 의미가 아니라 개발자로서 열정을 가지고 일을 할 수 있었다는 의미입니다.

복장 한가지로 어떻게 이런 판단이 가능할 까 하는 부분에 대해서는 전 이렇게 설명합니다.

리누스 토발즈첫번째로 다른 뛰어난 개발자가 존재 할 가능성이 있습니다. 뛰어난 개발자는 어차피 귀한 몸이기 때문에 본인이 이직 하고 싶은대로 이직을 쉽게 할 수 있습니다. 그렇기에 이런 개발자들은 본인이 일하기 편한 곳에 주로 머물기 마련인데, 초특급 개발자일수록 복장이 위 조건과 비슷한 경우가 많습니다.

뛰어난 개발자와 함께 일한다는 것은 매우 행복한 일입니다. 본인 또한 뛰어나다면 최고의 결과물을 낼 수 있을 것이고, 그렇지 않다고 해도 엄청나게 많은 것을 배울 수 있습니다. 개발자에게 배움이란 기쁨이죠.

두번째로 조직 문화가 딱딱하지 않을 가능성이 높습니다. 개발자들이 가진 성향 자체가 뭔가 좀 이것저것 들쑤시고 이런 것들을 좋아합니다. 음. 개발자 보다는 해커의 성향일 수도 있네요. 하지만 최고의 개발자들은 다 해커들이죠. 하하.

조직 문화가 경직되어 이런 욕구가 억눌려진다면 연봉이나 복지, 야근이 많지 않아도 열정을 불사르거나 즐겁게 일 한다는 것은 어렵다고 봅니다.

이런 점 때문에 복장에 대한 회사의 태도만으로도 어느 정도 개발자들이 열정을 가지고 즐겁게 일 할 수 있는 회사인지 판단하는 것이 가능합니다.

아무쪼록 좋은 회사에서 즐겁게 일 하실 수 있는 개발자분들이 많아졌으면 합니다.