Gus의 오픈 소스 개발 여정은 몇 가지 단계로 나뉩니다.
1. 초기 학습 및 탐색 단계
-
시작: Rails, Active Record, MySQL과 같은 기본적인 웹 프로그래밍 스택으로 시작하며 기존 라이브러리를 소비하는 데 집중했습니다.
-
‘만약 ~라면’ 단계:
access_tagable_redux와 같은 소규모 라이브러리를 직접 작성하거나 기존 라이브러리의 패치를 개발하며 Ruby 생태계를 탐색하기 시작했습니다.
2. 기여 및 프로젝트 생성 단계
-
기여: 초기에는 주목받지 못했지만 도움이 필요한 신생 프로젝트에 기여하며 큰 영향을 미칠 수 있음을 깨달았습니다. 이는 Rails와 같이 이미 많은 개발자가 참여하는 프로젝트에서 시작점을 찾기 어려웠던 경험에서 비롯되었습니다.
-
‘광기’ 단계: 점차 자신만의 프로젝트를 처음부터 작성하기 시작했습니다.
Google Ajax나Simple DB와 같이 기존 라이브러리가 없는 흥미로운 기능을 구현하며, ‘NIH(Not Invented Here)’ 증후군이라는 비판에도 불구하고 학습과 즐거움을 위해 코드를 작성하는 것의 중요성을 강조했습니다. -
도전: 개발 과정에서 발생하는 오류(‘폭발’)나 사용자들의 이해 부족과 같은 어려움에도 불구하고 끈기 있게 지속하는 것이 중요하다고 역설했습니다.
3. 오픈 소스 라이브러리 설계 원칙
Gus는 자신의 경험을 바탕으로 오픈 소스 라이브러리 설계에 대한 여러 원칙을 제시합니다.
-
진입 장벽 낮추기: 라이브러리는 전문가뿐만 아니라 누구나 쉽게 사용할 수 있도록 설계되어야 합니다. 사용자가 ‘조종사’가 아닌 ‘착륙’만을 원한다는 점을 명심해야 합니다.
-
프로토타입 활용:
prototypes와 같은 별도의 프로젝트를 통해 아이디어를 자유롭게 실험하고 학습할 수 있는 ‘샌드박스’를 마련합니다. -
몽키 패치 지양: 몽키 패치는 예측 불가능한 동작을 유발하고 사용자에게 불필요한 복잡성을 강요하므로 피해야 합니다.
-
조기 및 잦은 릴리스: 초기 단계부터 소프트웨어를 릴리스하고 자주 업데이트하여 사용자 피드백을 빠르게 반영하고 라이브러리를 개선합니다. (
Fog프로젝트의 138개 이상의 버전이 좋은 예시입니다). -
문서화의 중요성: 사용자들이 개발자에게 직접 연락할 수 없는 상황을 대비하여 명확하고 이해하기 쉬운 문서를 제공해야 합니다. (스스로도 개선이 필요한 부분으로 언급).
-
기여자 독려: 패치를 제공하는 기여자들에게 감사와 격려를 표현합니다 (예: 스티커, 티셔츠 제공).
-
일관성 유지: 코드의 일관성은 새로운 사용자의 적응을 돕고, 버그 발생 시 문제 해결을 용이하게 합니다.
-
라이브러리 기능 집중: 라이브러리는 명확하고 단일한 목적을 가져야 합니다. (
Fog에서XCON과Matador를 분리한 사례). -
개발 도구 활용: 복잡한 라이브러리 작업을 위해 백트레이스 분석, 테스트 프레임워크, 벤치마킹 도구와 같은 자체 도구를 개발하여 효율성을 높입니다.
-
우아한 실패: 아이디어가 실패했을 때 이를 인정하고 다음 단계로 나아가는 것을 두려워하지 않아야 합니다. 실패를 통해 배우는 것이 많기 때문입니다.