Bookworm's Archive

16Oct/120

소스코드를 기트허브(GitHub)에 올리다

Github smoothie

페이스북에서 기트허브(GitHub)에 관한 이야기를 나누다, 문득 가지고 있는 소스 코드를 모두 올려야겠다 생각이 들었다. 한동안 머리 속에 담아두고 있다 얼마 전에야 정리해서 올려놓았다. (https://github.com/bookwormkr)

기트허브에 소스 코드를 올린 것은 가지고 있는 공개하지 못 할 이유가 없기 때문이다. 일 하면서 만든 코드들은 회사의 소유이기 때문에 퇴사 후 개인적으로 가지고 있는 것도 금지된 일이다. 나머지 코드들은 직접 만든 것이거나 오픈소스를 수정한 것들인데 공개를 한다해도 아무런 문제가 없다.

개발자들이 소스 코드를 공개하지 않는 것에는 정리되지 않았다던지, 공개 할만한 수준의 코드가 아니라던지 등의 이유도 있다. 하지만 널리 쓰이는 코드가 아니라면 애써 다른 사람의 소스 코드를 읽고 있을 개발자는 별로 없다. 운이 좋아 누군가로부터 이유있는 비판을 받게 된다면 개선의 기회로 삼으면 될 일이다. 오히려 개선의 피드백을 받지 못하는 상황이 더 안타까운 일이다. 만약 근거없는 악의적 공격을 받게 된다면 그냥 미소지어 주자. :-)

공개를 하면서 개인 라이브러리와 과제물처럼 추억 때문에 남겨두었던 코드들을 삭제했다. 그런 뒤 가진 소스 코드를 다 올려놓았다. 이제 나만 가지고 있는 코드는 없다. 기트허브에서 클론한 작업본을 빼면 말이다.

앞으로 모든 취미 프로젝트나 소소한 장난(?)들도 모두 기트허브를 통해 진행 할 생각이다. 오픈소스로서 의미를 두는 것이 아니라, 공개해서 안 될 이유가 없기 때문이다.

26Nov/110

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

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

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

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

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

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

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

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

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

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

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

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