===========================
-Ofun
Geoff Broadwell
Oct. 05, 2005 02:05 PM
모든 프로젝트는 개발의 과정에 지향성을 부여하는 목표들이 있게 마련입니다. 어떤 프로젝트들에서는 이런 목표가 코딩 스타일이나 API의 형태들과 같은 묵시적인 방식으로 제시되기도 합니다. Autrijus Tang이 펄6.0 컴파일러를 만들기 위해 Pugs 프로젝트를 시작했을 때 그는 명시적인 목표를 정했습니다: “완전히 재미를 위해서”라는… 어떤 방향으로 최적화를 할 것인지 컴파일러에게 알려주기 위해 사용하는 -O 옵션을 이용해서 -Ofun이라고 재미있게 표현하기도 합니다. 재미를 위해 프로젝트를 옵티마이징 하겠다는 Autrijus의 결심은 아마도 그가 내린 가장 중요한 결정일 것입니다.
어떤 일을 오로지 재미를 위해 하는 것은 많은 이득이 있습니다. Pugs 프로젝트는 시작된지 8개월 만에 100여명의 커미터(committer: 소스를 작업해서 버전관리 시스템에 커밋할수 있는 권한을 가진 사람)가 생겼고, 하루 평균 30회 정도의 커밋이 일어날 정도로 활발한 활동이 생겨났습니다. 다른 많은 프로젝트들과는 달리 이런 커밋들은 몇몇 사람들이 거의 다 해치우는 그런게 아니었습니다. 가장 핵심 프로그래머 3명이 개발해서 커밋한 부분은 겨우 절반 밖에 되지 않습니다. 나머지들은 다양한 사람들이 함께 개발한 것입니다. 50%의 개발자들이 9번 이상의 커밋을, 25%의 개발자가 24회 이상, 10%의 개발자들은 150회 이상의 커밋을 했을 정도로 모두가 신나는 프로젝트였습니다.
팀은 생산적이기만 했던게 아니라 창조적이기까지 했습니다. 처음에는 Haskell로 작성된 단일 인터프리터 기반이었지만 지금은 자바 스크립트, Parrot, Perl 5 등의 컴파일러 기반까지 추가되었습니다. 암호화 알고리즘부터 IRC 로봇까지 수십개의 모듈들이 추가되었습니다. 많은 개발자들이 현재 공식적으로 개발이 진행되고 있는 코드에 다양한 새로운 개념들(continuations, coroutine, self-referential prelude, efficient type inferrence등)을 추가했으며 때로는 그것들이 공식 스펙에까지 들어가게 되기도 하였습니다.
물론 어떤 인지심리학자가 지적했듯이 “재미”야 말로 마음을 집중시키기 위한 가장 좋은 방법이기 때문에 그 결과가 훌륭한건 전혀 놀랄만한게 아닙니다. 개발을 즐기고 있지 않은 개발자들은 작업의 속도가 늦춰지거나 버그 투성이의 코드를 작성하거나, 잘못된 결정을 내리기도 하고 결국에는 프로젝트를 떠나게 되는 경우가 많습니다. 하지만 반대로 이야기 하면 무지막지한 즐거움은 프로그래머들에게 일에 대해 열정을 가지게 하고 결국에는 질적으로나 양적으로 그 결과를 나타나게 됩니다. 그렇기 때문에 재미를 위해 최적화한 작업은 다른 제품들보다 월등한 품질의 것을 만들어 내는데 매우 좋은 방법이 됩니다.
그렇다면 Autrijus의 -Ofun의 비밀은 무엇일까요? 그의 말에 따르면 재미의 핵심요소는 (다소 말초적인) 만족감, 경외감, 탐구심이라고 합니다. 다른 말로 하면 흔히 말하는 이메지니어링(imagineering)입니다. 구체적인 요령을 살펴보도록 하겠습니다.
-Ofun을 유일한 주 목표로 삼아라. - 앞으로 뭔가 비전이나 미션 스테이트먼트를 골라야 할 때 이것을 사용해 봅시다. (만약 관리자들이 허락한다면 당신은 좋은 회사에 다닌다는 의미일 것입니다) 이것 이외의 나머지 목표들은 그냥 부차적인 것으로 치부합니다.
현대적인 버전 콘트롤 시스템을 사용하자. - 이미 버전 콘트롤 시스템을 사용하지 않고 있다면 창피한줄 알기 바랍니다. CVS나 RCS, 소스 세이프와 같은 구식 시스템을 사용중이라면 그보다는 조금 낫지만 어쨌든 창피한 줄 알아야 합니다. 현대적인 버전 콘트롤 시스템은 아토믹 체인지세트를 지원합니다. (한가지의 목표를 위해 이루어진 모든 편집 행위들을 하나의 단위로 묶는 것을 말합니다.), 그리고, 디렉토리 자체나 심볼릭 링크, 태그나 브랜치에 대한 강력한 버전 콘트롤을 지원합니다. (파일이나 디렉토리들이 옮겨지거나 이름이 바뀌어도 변화 사항을 계속 추적이 가능하다는 뜻입니다) 무엇보다 현대적인 버전 콘트롤 시스템이 제공하는 점 중에 가장 좋은 점은 분산화된 환경에서 개발자들이 작업을 진행할 수 있다는 점입니다. 모든 개발자들이 자신의 로컬 컴퓨터나 노트북에 프로젝트에 관련된 파일을 가지고 있으면서 자신이 하고 싶은 작업을 맘대로 할 수 있다는 점입니다. 네트웍에 붙어있지 않은 경우에 오프라인 작업도 가능합니다. 작업한 내용을 합쳐야 하는 경우 개발자들은 중앙 서버나 다른 개발자에게 변화사항들을 보낼수 있습니다. darcs나 git같은 시스템들은 기반부터 분산화되어 있습니다. SVK 클라이언트는 현대적인 버전 관리 시스템인 Subversion 위에서 잘 동작합니다.
혼란스러운 상황을 포용하라 - 현대적인 인터넷 프로젝트들 (보통 Web 2.0이라 지칭합니다)의 경우에 기본 전재는 사용자들을 신뢰할 수 있다고 가정한다는 점입니다. 그리고, 또 한가지는 소수의 불량 사용자들이 입힌 피해를 복구 할 수 있는 도구 또한 사용자들이 가져야만 한다는 점입니다. 개발 프로젝트에 있어서 현대적인 버전 콘트롤 시스템은 “통제된 혼란상황”을 가능하게 해줍니다. 고의든 아니던 뭔가가 잘못되면 다른 개발자가 문제점을 파악해서 수정하기가 수월하게 해줍니다. 이런 안전망이 있기 때문에 사용자들에게 프로젝트의 아주 중요한 부분도 마음대로 건드릴 수 있게 하는 것이 가능한 것입니다.
데드락을 방지할 것 - 프로그래머가 코드를 커밋하는데 방해물이 있어서는 안됩니다. 보통 프로젝트 파일들의 완결성을 위해 사전 코드 리뷰 등의 일들이 행해지기도 합니다. 예를 들어 아토믹 체인지셋을 지원하는 시스템이 있기 전에는 어떤 한가지의 기능추가로 인해 변경된 것들을 취소하기가 매우 어려웠었습니다. 이제는 그런 작업이 쉬워졌습니다. 테스트 수트가 없이 개발을 하는 경우에 한가지 변경점이 어떤 버그를 만들어냈는지 알아내기가 쉽지 않습니다. 하지만 그렇다고 리뷰 과정을 강화하면 결국에는 코드 리뷰 자체 때문에 병목 현상이 발생하게 됩니다. 즉각적인 반응과 즉흥적인 면들이 많이 사라지게 됩니다. 예를 들어 리뷰어들이 너무 바빠지면 프로젝트의 진행이 결과적으로 느려지게 되고, 프로그래머들의 유머이지만 “버스 에러” (프로젝트의 주요 인물이 버스에 치이는 경우를 말합니다)가 일어나면 결국 프로젝트가 영원히 지체되는 경우도 생기게 됩니다.
커미터의 권한을 가능한 광범위하게 부여할 것 - 중앙 핵심 커미터 그룹만으로 프로젝트를 진행한다면 다른 일반 커미터들이 도움을 줄때에 비해서 작업 진행이 더디게 됩니다. 더 많은 커미터들을 얻을수록 프로젝트는 더 빠른 프로젝트 진행과 더 광범위한 아이디어를 얻을 수 있습니다. Autrijus는 다양한 테크니컬 그룹들을 하루 2-3차례 찾으며 커미터를 모으고 사람들의 궁금증을 유발시켜 프로젝트의 인지도를 높이는 활동을 했습니다. 커미터로 등록하는 과정은 쉽고 빨라야만 합니다. Autrijus는 프로젝트가 호스팅 되어 있는 rt.openfoundry.org의 사용자 등록 인터페이스를 수정해서 손쉬운 초대가 가능하도록 했습니다. 이렇게 해서 우연히 만나는 좋은 개발자들로 하여금 프로젝트에 손쉽게 참여해서 공헌할 수 있는 길을 열어 주었습니다. 초대과정이 완전히 자동화 되지 않았더라면 좋은 개발자들을 많이 놓치게 되었을 것입니다. 예를 들어 다른 시간대에 살고 있는 사람들을 초대하는건 힘이 들었을 것입니다.
코드를 가지고 작업하는 것이 아이디어를 가지고 일하는 것보다 재미있다 - 팀이 계속 아이디어를 코드로 녹여내도록 유도해야 합니다. 재빨리 아무렇게나 대충 작성한 코드들도 커밋을 하도록 합니다. 코드가 지저분한 것이 마음에 걸리면 나중에 리팩토링을 통해 깔끔하게 다듬으면 됩니다. 일단은 다른 사람들에게 보여주고 함께 일할 재료를 구비하도록 하는 것이 중요합니다. 현재의 상태에 관계 없이 어쨌거나 가능한 빠른 시점에 사람들에게 공개해서 함께 가지고 놀 수 있도록 해주는 것이 중요합니다. 그런 코드를 사용자들이 손쉽게 다운로드해서 가지고 놀 수 있게 하기 위해서 공개된 버전 콘트롤 서버의 사용이 꼭 필요한 것입니다. Autrijus는 친구들이 대충 작성한 코드를 릴리즈 하기를 주저할 때 그에 대해 토론하고 프로젝트의 홈페이지에 그 링크를 넣을 수 있겠느냐는 말로 용기를 북돋아 주어서 릴리즈를 하도록 한 경우가 많습니다. 프로젝트 전체에 걸쳐 가장 많이 쓰인 말이 바로 “URL?”이라는 질문이었다고 합니다.
두터운 커뮤니티를 만들자 - 이런 일을 하기위해 많은 방법이 존재합니다. 하지만 가장 중요한 점은 솔선수범을 하는 것입니다. 조언을 한다거나 기본적인 질문에 답해주는 것은 항상 해야만 하는 일입니다. IRC와 같이 손쉽게 물어볼 수 있는 채널이 존재해야 합니다. 그리고 또한 질문에 대해 호의적인 태도를 잊지 말아야 합니다. 그리고, 무작위적으로 생기는 재미있는 곁가지들을 인정하고 재미있게 지원해주어야 합니다. 예를 들어 Perl 분야에서의 JAPH, obfu, golf등이 그러한 것들입니다. 그리고, 또 하나의 좋은 방법으로 모든 개발자들이 자신의 이름을 AUTHORS 파일에 넣도록 해주는 것도 효과가 있습니다. (새로 참여한 개발자의 첫번째 커밋으로 이것을 이용하는 것도 좋습니다) 프로젝트가 당신 자신이 들어가서 살고 싶어 마지하지 않는 문화가 되도록 하는 것이 중요합니다.
흥분과 학습은 전염성이다 - Pugs 프로젝트에 일을 한 모든 사람들도 모두 나름대로 학습을 하며 다른 체험을 하며 살고 있는 프로그래머들입니다. 이들끼리 서로간의 지식과 그에 따르는 흥분을 공유하는 것이야말로 재미의 큰 요소입니다. 프로젝트에 참여하는 사람들은 아주 초보자들부터 최고의 테크니션들까지 다양한 사람들이 존재하게 되는데 이런 것들 자체가 재미의 요소입니다. 많이 알수록 더 많이 알고 싶어지는 것이 사람의 기본적인 심성입니다. 역시나 대단한 코드를 만들어내는 중요한 방법중 하나입니다.
많은 프로젝트들은 이런 요소들 중 일부를 “우연히” 성취하게 됩니다. 이것들 모두를 의식적으로 성취하는 프로젝트는 거의 없습니다. Autrijus는 그의 프로젝트를 -Ofun으로 옵티마이징 하기로 결정한 이래로 우리에게 놀라운 선물을 안겨주었습니다. 이제 여러분의 차례입니다.
Geoff Broadwell lives not far from O’Reilly headquarters in Santa Rosa, California, with a wonderful wife and daughter and four extremely spoiled cats. Geoff happily calls Perl the only computer language he ever really loved, having sampled a fair number before and since. He is on a personal mission to prove that dynamic languages are by far the best programming option for almost every purpose, and believes that the ultimate Linux distro of the future will contain little more than a kernel, an OpenGL and X server, the Parrot VM, and many, many Perl scripts.
