오픈소스 프로젝트에 코드를 업스트리밍하는 방법

코드는 일반적으로 다운스트림으로, 즉 오픈소스 프로젝트에서 조직의 제품으로 흐른다. 업스트리밍은 이 흐름을 뒤바꾸어 오픈소스 프로젝트로 코드를 기여하는 프로세스다. 업스트리밍은 오픈소스 커뮤니티의 힘을 활용해 코드를 점검하고 문제를 찾아서 해결하고 모든 코드 사용자에게 더 가치 있는 코드로 만들어주는 자체 기능을 추가하는 등의 가치를 제공한다.
 
오랜 세월 오픈소스 프로젝트에 깊이 관여해온 필자는 10년 이상 오픈소스 프리BSD(FreeBSD) 운영체제 프로젝트에 코드를 기여하면서 두 차례 프로젝트 코어 팀에서 활동했고 오픈소스 ZFS에 기여했으며 ZFS에 대한 두 편의 책에도 공동 저자로 참여했다. 그리고 수많은 조직이 업스트리밍의 과제를 극복하고 큰 혜택을 얻는 모습을 지켜봤다. 간단히 설명하면, 기여된 코드가 메인라인 오픈소스 프로젝트에 편입되면 그 코드는 공동 유지보수와 활발한 개발, 확장의 대상이 되며 커뮤니티 전반의 다른 구성원이 초기 기여를 뛰어넘는 가치를 더하는 경우가 많다.
 

사실 업스트리밍은 프리BSD, ZFS를 비롯한 많은 오픈소스 프로젝트에서 새로운 기능이 추가되는 주된 경로다. 업스트리밍의 구체적인 이점과 즉시 활용할 방법을 알아보자.
 

업스트리밍의 혜택

업스트리밍에 집중하면 더 고품질의 코드, 더 간편한 개발 프로세스, 유지보수 부담 경감, 프로젝트 지속가능성 증대로 이어진다.

더 품질이 뛰어난 코드
업스트리밍을 목적으로 코드를 개발할 경우 그 자체가 품질의 역함수(forcing function) 역할을 한다. "이정도 코드로 대충 마무리하자", "코드가 엉망이라도 아무도 안 보니까 괜찮다"는 사고방식에 빠지지 않기 위해 끊임없이 노력해야 하는 개발 팀과 리더에게는 코드를 업스트리밍하고 업스트림 검토 프로세스를 이행하겠다는 서약은 강력한 가드레일 역할을 한다.
 
또한 코드 개발을 시작하는 시점에서는 내부 시선과 내부 사용만 의식했다가 나중에 일반성을 덧붙여야 하는 경우 이후 기능의 만족도가 떨어지고 유지보수 부담이 증가하는 것이 일반적이다. 개발 과정 전반에서 업스트림 코딩 방식과 스타일 요구사항을 따르면 훨씬 더 높은 품질의 코드, 조직 내부뿐 아니라 모두에게 가치를 제공하는 코드를 얻게 된다.


더 쉬운 개발
오픈소스 기술 사용과 관련해 가장 큰 어려움은 조직이 오픈소스 소프트웨어의 최신 버전이 아니라 현재 조직에서 사용 중인 버전(몇 년 전 버전일 수도 있음)에 맞춰 개발을 진행하는 실수를 범하는 데서 발생한다. 이 비효율적인 관행은 곧 새로운 기능에 영향을 미칠 수 있는 다른 모든 소프트웨어 변경을 따라잡기 위한 리베이스, 그리고 뒤쳐짐으로 인해 발생하는 모든 기술 부채를 감당한다는 것을 의미한다.
 
오픈소스 소프트웨어의 최신 메인 버전을 기준으로 개발한 다음 필요에 따라 백포팅하는 방식을 사용하면 개발 도중에 업스트림에서 발생하는 변경으로 인해 업스트리밍 프로세스가 멈추는 일이 없고, 빠르게 움직이는 표적을 기준으로 리베이스하려고 애쓸 일이 없으므로 작업의 양도 최종적으로 훨씬 더 줄어든다.


유지보수 경감
오픈소스 소프트웨어의 오래된 로컬 브랜치에서 새로운 기능을 구축한 다음 더 새로운 버전으로 이를 업스트리밍하려고 시도하는 조직은 이 기간 동안 변경된 모든 소프트웨어 영역에 대한 주제별 전문 지식이 필요하므로 난관에 처하는 경우가 많다. 전문 지식은 업스트리밍의 핵심적인 과제다. 예를 들어 개발 팀이 패치 변경 사항을 업스트리밍하려면 그 전에 코드를 메인라인에 맞춰야 하는데, 아직 프리BSD 운영체제에 충분히 익숙하지 않은 상태라면 이를 위해 리베이스해야 하는 모든 업스트림 변경 사항을 처리하는 데 어려움을 겪게 된다.
 
시작 단계부터 업스트리밍을 상정하면 패치가 실제로 하는 일(대체로 개발자의 전문 분야)에 훨씬 더 집중할 수 있다. 변경 사항이 업스트림에 통합되어 메인라인 오픈소스 소프트웨어의 일부가 되면 유지보수는 더 이상 혼자만의 문제가 아니라 공동의 작업이 된다.


프로젝트 지속가능성
업스트림 기여가 커뮤니티에 의해 유지보수되면 새로운 기능은 더 많은 사용자와 더 많은 기여를 유도한다. 이 선순환이 오픈소스 프로젝트와 커뮤니티, 효과적인 소프트웨어 기능을 성장시키고, 이를 통해 더 큰 혜택을 얻을 수 있다.
 

패치 업스트리밍을 위한 최선의 방법

아래 설명된 프로세스는 오픈소스 프로젝트에 패치를 업스트리밍해온 필자의 경험을 바탕으로 기능을 성공적으로 업스트리밍하는 방법을 정리한 것이다.

1단계 : 후보 패치 만들기
패치는 내가 기여하는 프로젝트의 다른 보편 사용자에게 유용하고 가치가 있어야 한다. 내 애플리케이션에만 해당하는, 지나치게 지엽적이고 다른 사람에게는 가치가 거의 없는 코드를 업스트리밍하는 것은 좋지 않다. 벽 너머로 코드를 집어 던지고 누군가가 그 코드를 받아 유지보수해주기를 바라는 격이다. 보편적인 가체를 제공하도록 기능을 확장하려면 얼마간의 부가적인 작업이 필요할 수 있지만, 그 유용함은 기여의 품질과 커뮤니티의 호응을 위해 필수적이다.
 
이는 또 하나의 주요 업스트리밍 과제인 지지(advocacy)로 이어진다. 기여한 기능이 성공적이 되기 위해서는 커뮤니티의 열띤 반응이 필요하다. 커뮤니티는 이 기능을 왜 채택해야 하는지, 그리고 거기서 어떤 혜택을 얻을 수 있는지 이해할 수 있어야 한다. 커뮤니티를 잘 파악하고 조기에(개발보다 앞서) 접촉해서 다른 사람의 요구사항을 이해하면 이 과제를 극복하는 데 큰 도움이 된다. 업스트리밍된 코드는 많이 사용될수록 번성하고 확장될 가능성이 높아진다(그 반대의 경우는 시간이 지나 제거되거나 지원 중단됨). 커뮤니티와의 접촉은 커뮤니티의 유지보수 노력이 향하는 곳을 결정하는 가장 중요한 요소인 경우가 많다.
 
2단계 : 다른 업스트림 기여자가 검토할 수 있도록 패치 제출
다른 사람이 코드를 활용할 수 있도록 충분한 문서와 함께 코드가 다른 기능을 망가뜨리지 않는지 확인하고 다른 변경으로 인해 기능의 퇴보가 발생하는지 파악하기 위한 테스트를 제공한다. 검토자를 위해 패치의 목적과 가치에 대한 명확한 설명도 당연히 제공해야 한다.
 
이후 다른 업스트림 기여자가 패치를 검토하고 피드백을 제공하면 그에 따라 적절히 대처한다.

3단계 : 검토자가 패치를 업스트림 브랜치에 통합
패치가 스테이블 브랜치 또는 오픈소스 소프트웨어의 브랜치에 병합될 수도 있다. 업스트림 소프트웨어의 이후 출시본에는 내 변경 사항이 포함된다. 스테이블 브랜치로의 백포트를 지지하고 이를 유지보수하는 데 도움을 주면 해당 스테이블 브랜치를 사용하는 내 제품에서 이러한 백포트를 사용할 수 있고 이후 쉬운 업그레이드 경로를 확보하는 데 도움이 된다.
 

'업스트림 우선' 사고방식 갖기

업스트리밍은 조직이 내부 용도로 좋은 코드에 그치지 않고 전체 오픈소스 커뮤니티 관점에서 충분히 좋은 코드를 만들어 커뮤니티의 오랜 지지를 끌어낼 수 있게 해준다. 내 문제만이 아니라 커뮤니티의 요구사항에 효과적으로 대응하는 기능을 설계하면 업스트리밍과 검토 프로세스가 훨씬 더 쉬워지고 조직이 의존하는 기능은 팀이 단독으로 달성 가능한 수준을 훨씬 뛰어넘게 성장하고 번성할 수 있다. 이것이 오픈소스가 가진 힘이다.
editor@itworld.co.kr