2013.02.20

칼럼 | ‘사람이 먼저다’ 리브레오피스 오픈소스 협업의 성공비결

Simon Phipps | InfoWorld
방대한 레거시 코드 베이스를 가져다가 더 좋게 개조하는 일은 누구에게나 어려운 일이다. 여러 곳에 분산된 자발적 지원자들로 구성된 팀이라면 이 문제를 어떻게 해결할까?

오라클이 OpenOffice.org에서 발을 빼면서 뒤에 남겨진 방대한 리브레오피스 코드 베이스에 도큐먼트 재단(The Document Foundation)의 대규모 팀이 어떻게 접근했는지, FOSDEM에서의 한 대담을 통해 들어볼 수 있었다.

이 팀은 정확히 일정에 맞춰 순차적으로 릴리스하고 있을 뿐만 아니라 여러 혁신까지 이뤘다. 특히 이들이 개발한 '이진-이등분(bi-bisect)' 기법은 복잡한 대규모 코드 베이스를 다루는 다른 이들에게도 좋은 접근법이 될 수 있다.
 
'리브레오피스: 방대한 코드 베이스 정리와 리팩터링'이라는 주제로 열린 이 대담은 수세(Suse) 소속의 개발자로 2000년부터 리브레오피스(그 전에는 OpenOffice.org) 작업을 해온 마이클 믹스의 이야기로 진행됐다. 믹스는 리브레오피스 개발의 어려운 점과 4.0 릴리스의 새로운 기능에 대한 이야기를 전했다. 특히 개발의 어려운 점에 대한 이야기는 유익하고 고무적이었으며 깊이 생각해볼 여지를 남겼다.
 
장벽 낮추기
최초에 어떻게 개발 커뮤니티가 구성됐을까. 핵심 개발진은 과거 OpenOffice.org 커뮤니티에서 자신이 작업한 부분을 들고 참여했다. 그러나 중요한 것은 쉽게, 그리고 재미있게 개발에 참여할 수 있도록 해 프로젝트 참여에 대한 장벽을 없앴다는 점이다. 메일링 리스트의 초점도 기존 개발자다보다 새로 참여한 사람들을 환대하는 데 맞춰졌다. 신규 참여자를 위해 제작된 '쉬운 해킹' 페이지에는 소소한 재밋거리를 넣었고 포괄적인 README 파일을 쉽게 찾아볼 수 있도록 했다.
 
깃(Git)을 프로젝트의 버전 제어 시스템으로 도입해서 가장 잘 알려지고 널리 사용되는 오픈 소스 도구를 통해 손쉽게 자신의 작업을 기여할 수 있도록 했다. 여기에 게릿(Gerrit)을 추가해 과정을 더욱 간소화했다. 믹스의 설명에 따르면 게릿을 통해 이제 허락을 받지 않고도 커밋할 수 있게 됐다.
 
코드 베이스를 빌드하기가 어려웠기 때문에 자동화된 틴더박스(Tinderbox) 연속 통합 빌드 서버스를 구축해서 모든 개발자들이 각자 여러 운영 체제 환경에서 복잡한 빌드 환경을 구성할 필요 없이 코드 작업을 수행할 수 있도록 했다. 코드에서 많은 부분이 정리됐고 글로벌 접근성을 높이기 위해 주석은 독일어에서 영어로 번역됐다(대부분의 개발자가 적어도 영어를 제2 외국어로 사용하므로).

이 정리 작업에는 이전의 접근 방법을 최신 방법으로 바꾸는 리팩터링 작업과, 구 플랫폼부터 전해진 사용되지 않는 코드를 없애는 작업도 포함됐다(어쨌든 20년이나 된 코드다).
 
최근에는 마이크로소프트 문서 필터를 재구현하고 하드코딩된 옵션 대신 레이아웃 기반 대화 상자를 도입하는 것과 같은 대대적인 리팩터링도 이루어졌다. 믹스는 현재 진행 중인 여러 가지 작업에 대해 설명했는데 믹스의 슬라이드 파일에서 전체 내용을 볼 수 있다.
 
품질 높이기
복잡하고 부서지기 쉬운 레거시 코드를 변경하다 보면 어떤 부분이 망가질 가능성이 상존한다. 실제로 리브레오피스에서는 회귀(regression)가 항상 문제였다. 이 문제에 대처하기 위해 안정성을 이유로 진행의 발목을 잡지 않으면서 코드 품질을 높이기 위한 여러 가지 방법이 동원됐다. 새로운 기여자들의 참여가 계속 증가하자 프로젝트 팀은 단위 테스트의 수를 대폭 늘려 더 많은 변화를 더 신속하게 구현할 수 있도록 했다.
 
여기서는 두 가지 '문화적인' 개선이 많은 도움이 됐다. 첫째, 버그질라(Bugzilla) 버그 트래커에 대한 인터페이스가 대폭 향상된 덕분에 최종 사용자가 충분한 세부 정보를 첨부해 문제를 보고하기가 더 쉬워졌다. 버그질라 어시스턴트(Bugzilla Assistant)는 그래픽 방식의 워크플로우 기반 툴로, 버그를 보고하는 복잡한 절차를 편리하게 수행할 수 있게 안내해준다.

둘째, 규칙적인 일정에 따라 릴리스 시점이 정해졌다. 이는 개발자들이 자신의 작업물이(품질 기준을 충족한 경우) 언제 제품에 반영되는지 알 수 있음을 의미하는 것으로, 유명한 사람들의 작업에 맞추어 릴리스 시기를 정하는 ‘정치적인 행위’를 할 수 없도록 방지하는 역할을 했다. 이 두 가지 개선이 리브레오피스에 큰 도움이 됐다.
 
문제는 언제나 생기는 법이지만, 팀원인 캐너니컬의 비욘 미켈슨이 고안한 간단한 발명품 덕분에 QA 팀의 누구나 회귀를 유발하는 버그를 찾을 수 있게 됐다.

깃에는 git bisect 명령이 포함되어 있는데, 이 명령은 회귀를 찾는 데 유용하다. 개발자는 문제가 있는 코드의 버전과 그 문제가 나타나지 않은 과거 버전을 함께 확인할 수 있다. 그런 다음 깃은 이 두 가지 코드에 대한 커밋을 제시하며 해당 버전에 문제가 나타나는지 묻는다. 깃은 이렇게 커밋 목록을 반복적으로 이등분하는 방법으로 문제가 발생한 지점을 신속하게 분리해 나갈 수 있게 해준다.
 
깃의 새로운 기능 향상
리브레오피스는 거대하고 복잡한 코드 베이스로, 하루 커밋 수만 50회를 넘는 경우가 다반사다. 이를 빌드하는 작업에는 몇 시간이 걸릴 수 있고 이 경우 이등분 프로세스는 실행이 불가능해진다.
 
미켈슨은 각 커밋 후 틴더박스가 생성하는 바이너리 빌드를 저장하는 방법으로 이 문제를 극복할 수 있음을 발견했다. 미켈슨은 바이너리 빌드를 위한 저장소를 구축했고 덕분에 이제 git bisect 명령으로 테스트할 각 커밋에 일치하는, 완전히 빌드된 리브레오피스 버전을 손쉽게 체크아웃할 수 있게 됐다.

이 '바이너리 이등분' 방법(또는 '이진 이등분') 방법을 사용하면 코드를 구축하는 방법을 모르는 비교적 경험이 적은 테스터라도 짧은 시간 안에 문제의 위치를 파악할 수 있다. 세부적인 조사가 필요한 모호한 버그도 이진 이등분으로 잡아낼 수 있었다. 필자가 보고한 문제 하나도 바로 이 방법으로 수정됐다.
 
이러한 모든 혁신이 그에 상응하는 결과로 이어졌을까. 믹스는 이를 뒷받침하는 통계 수치를 제시했다. 복잡한 리팩터링과 기술 수준의 편차가 큰 혼잡한 개발자 커뮤니티에도 불구하고 안정성은 개선되고 있으며 버그도 적정 수준으로 통제되고 있다.
 
믹스는 이 모든 과정을 통해 얻은 교훈에 대해 말했다. 믹스는 변화가 많으면 품질은 떨어진다는 통념으로 인해 전통적인 기업 개발 작업에서는 품질을 확보하기 위해 느리고 보수적인 프로세스를 사용한다고 말했다. 그러나 믹스는 여기에는 두 가지 측면이 있다고 말했다. TDF가 사용하는 접근 방법은 공개되어 있고 속도가 빠르다. 따라서 코드의 변경률이 높음에도 불구하고 간소한 프로세스 환경, 빠른 빌드 접근 방식, 그리고 빠른 릴리스 타임라인이 조합되어 새로운 버그가 신속하게 수정된다는 것이다.
 
이 경험에서는 배울 점이 많다. 여러분의 개발 팀이 초고속 반복법을 도입하기를 꺼리더라도, 이진 이등분, 연속 통합, 간소화된 버그 보고, 허가 없는 커밋과 같은 기법을 부분적으로 도입할 수 있다.
 
사람이 먼저
이 이야기에서 가장 중요한 점은 바로 대담의 시작 부분에 나온 내용이다. 믹스는 오픈 소스 프로젝트의 중심이 코드처럼 생각될 수 있지만 사실은 사람이라고 강조했다. 개발자와 최종 사용자들은 각자 자신의 관심사와 필요로 인해 오픈 소스 커뮤니티에 모인다. 커뮤니티가 성공하려면 바로 에토스(ethos), 편취가 아닌 상호 이익, 커뮤니티를 위한 규약으로서의 라이선싱, 우호적인 관계, 그리고 특히 재미에 집중해야 한다.
 
따라서 리브레오피스 성공의 바탕은 코드가 아니라 사람들이 참여하는 방법에 있다. 스스로 조직화하고, 상호 존중하고, 신뢰와 권한 이양을 바탕으로 일하는 방법이다. 모든 오픈 소스 커뮤니티가 새겨야 할 교훈이다. editor@idg.co.kr



2013.02.20

칼럼 | ‘사람이 먼저다’ 리브레오피스 오픈소스 협업의 성공비결

Simon Phipps | InfoWorld
방대한 레거시 코드 베이스를 가져다가 더 좋게 개조하는 일은 누구에게나 어려운 일이다. 여러 곳에 분산된 자발적 지원자들로 구성된 팀이라면 이 문제를 어떻게 해결할까?

오라클이 OpenOffice.org에서 발을 빼면서 뒤에 남겨진 방대한 리브레오피스 코드 베이스에 도큐먼트 재단(The Document Foundation)의 대규모 팀이 어떻게 접근했는지, FOSDEM에서의 한 대담을 통해 들어볼 수 있었다.

이 팀은 정확히 일정에 맞춰 순차적으로 릴리스하고 있을 뿐만 아니라 여러 혁신까지 이뤘다. 특히 이들이 개발한 '이진-이등분(bi-bisect)' 기법은 복잡한 대규모 코드 베이스를 다루는 다른 이들에게도 좋은 접근법이 될 수 있다.
 
'리브레오피스: 방대한 코드 베이스 정리와 리팩터링'이라는 주제로 열린 이 대담은 수세(Suse) 소속의 개발자로 2000년부터 리브레오피스(그 전에는 OpenOffice.org) 작업을 해온 마이클 믹스의 이야기로 진행됐다. 믹스는 리브레오피스 개발의 어려운 점과 4.0 릴리스의 새로운 기능에 대한 이야기를 전했다. 특히 개발의 어려운 점에 대한 이야기는 유익하고 고무적이었으며 깊이 생각해볼 여지를 남겼다.
 
장벽 낮추기
최초에 어떻게 개발 커뮤니티가 구성됐을까. 핵심 개발진은 과거 OpenOffice.org 커뮤니티에서 자신이 작업한 부분을 들고 참여했다. 그러나 중요한 것은 쉽게, 그리고 재미있게 개발에 참여할 수 있도록 해 프로젝트 참여에 대한 장벽을 없앴다는 점이다. 메일링 리스트의 초점도 기존 개발자다보다 새로 참여한 사람들을 환대하는 데 맞춰졌다. 신규 참여자를 위해 제작된 '쉬운 해킹' 페이지에는 소소한 재밋거리를 넣었고 포괄적인 README 파일을 쉽게 찾아볼 수 있도록 했다.
 
깃(Git)을 프로젝트의 버전 제어 시스템으로 도입해서 가장 잘 알려지고 널리 사용되는 오픈 소스 도구를 통해 손쉽게 자신의 작업을 기여할 수 있도록 했다. 여기에 게릿(Gerrit)을 추가해 과정을 더욱 간소화했다. 믹스의 설명에 따르면 게릿을 통해 이제 허락을 받지 않고도 커밋할 수 있게 됐다.
 
코드 베이스를 빌드하기가 어려웠기 때문에 자동화된 틴더박스(Tinderbox) 연속 통합 빌드 서버스를 구축해서 모든 개발자들이 각자 여러 운영 체제 환경에서 복잡한 빌드 환경을 구성할 필요 없이 코드 작업을 수행할 수 있도록 했다. 코드에서 많은 부분이 정리됐고 글로벌 접근성을 높이기 위해 주석은 독일어에서 영어로 번역됐다(대부분의 개발자가 적어도 영어를 제2 외국어로 사용하므로).

이 정리 작업에는 이전의 접근 방법을 최신 방법으로 바꾸는 리팩터링 작업과, 구 플랫폼부터 전해진 사용되지 않는 코드를 없애는 작업도 포함됐다(어쨌든 20년이나 된 코드다).
 
최근에는 마이크로소프트 문서 필터를 재구현하고 하드코딩된 옵션 대신 레이아웃 기반 대화 상자를 도입하는 것과 같은 대대적인 리팩터링도 이루어졌다. 믹스는 현재 진행 중인 여러 가지 작업에 대해 설명했는데 믹스의 슬라이드 파일에서 전체 내용을 볼 수 있다.
 
품질 높이기
복잡하고 부서지기 쉬운 레거시 코드를 변경하다 보면 어떤 부분이 망가질 가능성이 상존한다. 실제로 리브레오피스에서는 회귀(regression)가 항상 문제였다. 이 문제에 대처하기 위해 안정성을 이유로 진행의 발목을 잡지 않으면서 코드 품질을 높이기 위한 여러 가지 방법이 동원됐다. 새로운 기여자들의 참여가 계속 증가하자 프로젝트 팀은 단위 테스트의 수를 대폭 늘려 더 많은 변화를 더 신속하게 구현할 수 있도록 했다.
 
여기서는 두 가지 '문화적인' 개선이 많은 도움이 됐다. 첫째, 버그질라(Bugzilla) 버그 트래커에 대한 인터페이스가 대폭 향상된 덕분에 최종 사용자가 충분한 세부 정보를 첨부해 문제를 보고하기가 더 쉬워졌다. 버그질라 어시스턴트(Bugzilla Assistant)는 그래픽 방식의 워크플로우 기반 툴로, 버그를 보고하는 복잡한 절차를 편리하게 수행할 수 있게 안내해준다.

둘째, 규칙적인 일정에 따라 릴리스 시점이 정해졌다. 이는 개발자들이 자신의 작업물이(품질 기준을 충족한 경우) 언제 제품에 반영되는지 알 수 있음을 의미하는 것으로, 유명한 사람들의 작업에 맞추어 릴리스 시기를 정하는 ‘정치적인 행위’를 할 수 없도록 방지하는 역할을 했다. 이 두 가지 개선이 리브레오피스에 큰 도움이 됐다.
 
문제는 언제나 생기는 법이지만, 팀원인 캐너니컬의 비욘 미켈슨이 고안한 간단한 발명품 덕분에 QA 팀의 누구나 회귀를 유발하는 버그를 찾을 수 있게 됐다.

깃에는 git bisect 명령이 포함되어 있는데, 이 명령은 회귀를 찾는 데 유용하다. 개발자는 문제가 있는 코드의 버전과 그 문제가 나타나지 않은 과거 버전을 함께 확인할 수 있다. 그런 다음 깃은 이 두 가지 코드에 대한 커밋을 제시하며 해당 버전에 문제가 나타나는지 묻는다. 깃은 이렇게 커밋 목록을 반복적으로 이등분하는 방법으로 문제가 발생한 지점을 신속하게 분리해 나갈 수 있게 해준다.
 
깃의 새로운 기능 향상
리브레오피스는 거대하고 복잡한 코드 베이스로, 하루 커밋 수만 50회를 넘는 경우가 다반사다. 이를 빌드하는 작업에는 몇 시간이 걸릴 수 있고 이 경우 이등분 프로세스는 실행이 불가능해진다.
 
미켈슨은 각 커밋 후 틴더박스가 생성하는 바이너리 빌드를 저장하는 방법으로 이 문제를 극복할 수 있음을 발견했다. 미켈슨은 바이너리 빌드를 위한 저장소를 구축했고 덕분에 이제 git bisect 명령으로 테스트할 각 커밋에 일치하는, 완전히 빌드된 리브레오피스 버전을 손쉽게 체크아웃할 수 있게 됐다.

이 '바이너리 이등분' 방법(또는 '이진 이등분') 방법을 사용하면 코드를 구축하는 방법을 모르는 비교적 경험이 적은 테스터라도 짧은 시간 안에 문제의 위치를 파악할 수 있다. 세부적인 조사가 필요한 모호한 버그도 이진 이등분으로 잡아낼 수 있었다. 필자가 보고한 문제 하나도 바로 이 방법으로 수정됐다.
 
이러한 모든 혁신이 그에 상응하는 결과로 이어졌을까. 믹스는 이를 뒷받침하는 통계 수치를 제시했다. 복잡한 리팩터링과 기술 수준의 편차가 큰 혼잡한 개발자 커뮤니티에도 불구하고 안정성은 개선되고 있으며 버그도 적정 수준으로 통제되고 있다.
 
믹스는 이 모든 과정을 통해 얻은 교훈에 대해 말했다. 믹스는 변화가 많으면 품질은 떨어진다는 통념으로 인해 전통적인 기업 개발 작업에서는 품질을 확보하기 위해 느리고 보수적인 프로세스를 사용한다고 말했다. 그러나 믹스는 여기에는 두 가지 측면이 있다고 말했다. TDF가 사용하는 접근 방법은 공개되어 있고 속도가 빠르다. 따라서 코드의 변경률이 높음에도 불구하고 간소한 프로세스 환경, 빠른 빌드 접근 방식, 그리고 빠른 릴리스 타임라인이 조합되어 새로운 버그가 신속하게 수정된다는 것이다.
 
이 경험에서는 배울 점이 많다. 여러분의 개발 팀이 초고속 반복법을 도입하기를 꺼리더라도, 이진 이등분, 연속 통합, 간소화된 버그 보고, 허가 없는 커밋과 같은 기법을 부분적으로 도입할 수 있다.
 
사람이 먼저
이 이야기에서 가장 중요한 점은 바로 대담의 시작 부분에 나온 내용이다. 믹스는 오픈 소스 프로젝트의 중심이 코드처럼 생각될 수 있지만 사실은 사람이라고 강조했다. 개발자와 최종 사용자들은 각자 자신의 관심사와 필요로 인해 오픈 소스 커뮤니티에 모인다. 커뮤니티가 성공하려면 바로 에토스(ethos), 편취가 아닌 상호 이익, 커뮤니티를 위한 규약으로서의 라이선싱, 우호적인 관계, 그리고 특히 재미에 집중해야 한다.
 
따라서 리브레오피스 성공의 바탕은 코드가 아니라 사람들이 참여하는 방법에 있다. 스스로 조직화하고, 상호 존중하고, 신뢰와 권한 이양을 바탕으로 일하는 방법이다. 모든 오픈 소스 커뮤니티가 새겨야 할 교훈이다. editor@idg.co.kr

X