오픈소스 개발자가 말하는 프로젝트 성공비법

개발자들이 오픈소스를 많이 쓰게 되면서 최근엔 사용자에 머물지 않고 프로젝트에 참여하는 경우도 늘었다고 한다. 여기서 한 발 더 나아가 본인이 평소에 개발하던 작은 프로그램을 새 오픈소스 프로젝트로 만들어보면 어떨까.

오픈소스 개발자 이희승씨는 운이 따라준다면 프로젝트가 성공해서 유명해지고 좋은 직장에 들어갈 수 있는 커리어가 될 수도 있지만 꼭 그렇지 않더라도 오픈소스 프로젝트를 통해 더 나은 개발자로 거듭날 수 있는 좋은 경험이 될 것이라고 애기한다.

이씨는 최근 양재동 L타워에서 열린 오픈소스개발자행사 '2014 오픈테크넷 서밋 Fall' 연사로 나와 자신의 경험을 바탕으로 새 오픈소스 프로젝트를 시작할 때 염두에 둬야 할 점들을 공유했다.

그는 '네티(Netty)'라는 오픈소스 프로젝트를 시작했고 이후 아파치소프트웨어재단(ASF)의 인큐베이팅을 받아 아파치 미나 프로젝트로 발전시켰다. 아파치 미나 프로젝트는 톱레벨프로젝트(TLP)로 승급됐고 그는 국내 1호 ASF 멤버로 인정받았다.

그의 경험에서 우러나온 오픈소스 프로젝트를 시작할 때 명심해야할 점들을 6가지로 정리해 봤다.

■ 최대한 자유로운 라이선스로 시작하자

오픈소스 프로젝트를 시작하기로 처음 마음 먹었으면 먼저 소스코드에 어떤 라이선스를 적용할지 생각해 봐야 한다. 소스코드는 저작권이 있는 것이기 때문에 향후 프로젝트 사용자들 입장에서 라이선스는 중요한 문제가 될 수 있다.

이희승씨는 프로젝트가 처음 시작하는 단계에서 아파치라이선스처럼 자유로운 형태의 라이선스를 사용하는 걸 추천했다. 제약이 많은 라이선스를 적용했을 때 기업들이 프로젝트를 사용하기 꺼리게 되고 프로젝트가 성장하는데 방해 요인이 될 수 있기 때문이다.

그는 프로젝트를 처음 시작할 때는 커뮤니티의 크기, 컨트리뷰터의 크기가 더 중요하다고 강조했다.

나중에 프로젝트가 성장하게 되면 라이선스를 변경할 수도 있다. 또 프로젝트를 특정 재단에 맡겨서 재단 소속의 프로젝트로 만들 수도 있다.

단, 전세계에서 컨트리뷰션을 받아 소스코드 저작자가 여러 명일 경우, 모두에게 라이선스 변경 동의를 받기 어려울 수 있다. 그는 이를 대비하기 위해 최초 컨트리뷰션을 받을 때 컨트리뷰터에게 내부에서 작성된 코드 소유권은 원저작자에게 귀속된다는 약속을 받아두면 더 쉽게 라이선스 변경이 가능하다고 설명했다.

■ 소스코드는 더 많은 사람이 볼 수 있는 곳에 두자

소스코드는 더 많은 사람들이 볼 수 있는 곳에 둬야 한다는 것이 그의 두 번째 조언이다. 이희승씨는 최근엔 개발자들이 많이 관심을 보이는 깃허브를 통해 호스팅할 것을 추천했다.

이때 중요한 건 그냥 소스코드만 깃허브에 넣는 게 아니라, 깃허브에서 제공하는 기능을 최대한 활용할 수 있어야 한다는 거다.

그는 오픈소스 프로젝트는 모든 사람이 보는 것이기 때문에 이 프로젝트를 처음 보는 사람도 잘 이해할 수 있도록 깃허브가 제공하는 이슈 트레킹, 풀 리퀘스트, 이슈 레이블 기능, 마일스톤 기능 등을 이용해 프로젝트를 깔끔하게 정리해 둬야 한다 강조했다.

■ 적당히 하려다가는 큰 코 다친다

프로젝트를 깃허브에 올리는 순간 검색엔진 등을 통해 누군가는 그 프로젝트에 유입될 가능성이 생긴다. 따라서 지금은 비록 혼자 프로젝트를 하고 있다 해도 항상 누군가 보고 있다는 점을 잊어선 안 된다고 그는 조언했다.

이 씨는 내가 혼자 한다고 적당히 코드를 짜면 어떻게 될까? 누군가 엉망인 코드를 보고 ‘이 프로젝트를 쓰면 큰일나겠다’고 생각할 것이다. 그럼 그 사람은 다른 프로젝트를 찾아 가버린다며 코드에 정성들일 것을 주문했다.

또 변경 사항이 어떤 맥락에서 나온 것인지 커밋 메시지에 상세하게 기록하는 것도 중요하다고 강조했다.

그는 모든 사람은 그 프로젝트를 처음 보기 때문에 변경 사항에 대한 커밋 메시지가 구체적이지 않으면 기본이 안 됐다고 생각하기 쉽다고 지적했다.

이런 디테일에서 프로젝트 전체 미래비전은 물론 저작자가 이 프로젝트를 꾸준히 업데이트해 나갈 의지가 있는지도 엿보인다는 점을 잊어선 안된다. 그는 지나가는 누군가는 프로젝트에 신뢰를 가지고 써보게 되고 또 그 중 누군가는 프로젝트에 관심을 가지고 팀원이 될 수도 다고 강조했다.

■ 프로젝트를 홍보해 보자

1.0버전을 내놓을 정도로 준비가 됐다면 이제 홍보가 필요한 시점이다. 프로젝트 공식 트위터 계정이나 공식 블로그를 만들어도 좋고 관련 기술 커뮤니티에 프로젝트에 소식을 올릴 수도 있다. 레딧(Reddit), 해커뉴스(hacker news), 디존(Dzone) 같이 사용자들이 직접 올릴 수 있는 뉴스사이트를 통해 홍보할 수도 있다.

그는 야심차게 1.0버전을 내놓고 홍보를 열심히 해도 반응은 빨리 오지 않을 가능성이 높다며 그래도 좌절하지 말고 꾸준히 할 것을 주문했다.

■ 사용자를 항상 최우선에 둬라

코드 뿐만 아니라 오픈소스 프로젝트 자체도 최대한 디테일해야 한다. 그렇지 않으면 커뮤니티가 커질 수 없다는 것이 그의 조언이다.

예를 들어 라이브러리를 개발한다고 생각해보자. 사용자가 이 라이브러리를 사용해서 만든 개발 최종 코드의 모습을 어떨까를 상상하며 개발해야 한다.

사용자가 프로젝트 사이트에 방문해서 다운로드 하는 과정, IDE 설정, 문서를 열람하고, 최종 실행하고 디버그하는 과정까지 신경써야 한다.

그는 프로젝트 초기에 커뮤니티 규모 작다는 장점을 살려야 한다고도 조언했다. 스프링프레임워크 프로젝트에 버그리포트를 하면 실제 고쳐지는 건 한달은 족히 걸린다. 하지만 소규모 프로젝트의 경우 버그리포트를 했는데 3시간만에 해결 된다면 그 프로젝트에 애정도 상승하게 된다. 커뮤니티는 이렇게 형성되고 성장하게 되는 계기가 마련된다고 그는 말했다.

프로젝트에 대해 좋은 인상을 심어주다 보면 사용자 중에서 개발자에 참여하는 팀원이 나올 수도 있다.

■ 지속가능한 의지가 가장 중요하다

커뮤니티 기반인 오픈소스 프로젝트에서 코드를 만드는 것만큼이나 사람과의 관계를 만들어 가는 것이 중요하다. 누가 프로젝트를 비방하는 경우도 생길 수 있다. 특히 버그가 있으면 이 버그 때문에 문제가 생겼다고 욕도 먹을 수 있다.

그는 이때 “이 비난이 자신에게 하는 것이 아니라 자기가 만든 버그에 대한 이야기라고 분리시켜 생각하라”고 조언한다. 안 좋은 말이 오가게 되는 상황이 일어날 수 있지만 항상 예의를 지키는 게 프로젝트가 좋은 결과로 이어질 수 있는 길임을 잊지 말라는 얘기다.