2020.07.08

칼럼 | '나 그냥 코딩하게 해주세요'··· 오픈소스 프로젝트 관리자의 딜레마

Matt Asay | InfoWorld
오픈소스 프로젝트를 유지한다는 것은 코딩과 전혀 다른 이야기다. 관심사가 코딩인 사람이 프로젝트를 유지해야 하다면 문제가 될 수 있다는 의미다. 

레디스(Redis) 설립자인 살바토르 샌필리포에게는 임기 제한이 없었다. 그의 리더 지위에 제동을 건 사람도 없었고, 그가 레디스의 혁신을 지속하는 데 다른 걸림돌이 있지도 않았다. 그러나 2020년 6월 30일 샌필리포는 레디스 직무의 종료를 발표했다. 이 프로젝트의 최고 관리자 역할을 그만두겠다는 것이다. 

그는 다음과 같이 말했다. “앞날이 어떨지 정말이지 모르겠다. 이렇다 할 일도 없이 그냥 두리번거리기만 하는 것 같다.”
 
10년이 넘는 기간 동안 레디스의 간판 역할을 해온 샌필리포는 한계에 도달했다. 그는 휴식이 필요했다. 샌필리포의 이탈이 초래할 영향은 레디스 커뮤니티에 한정될 것이 유력하지만, 좀더 살펴보면 더 넓은 함의를 갖는다.  

여기서는 오픈소스 관리자에 대해 이야기할 것이다. 그리고 샌필리포의 사례가 기업에게 어떤 교훈을 주는지 살펴본다.
 
ⓒ Image Credit : Getty Images Bank

또 다른 종류의 ‘로우 코드’
오픈소스 커뮤니티가 어떻게 돌아가는지 아는 사람이라면 아마 이 사실을 알고 있을 것이다. 즉, 관리자는 코드를 많이 쓰지 않는다는 사실이다. 기트허브 오픈소스 가이드에서 보듯이 “수많은 사람이 사용하는 오픈소스 프로젝트를 관리한다면 코드를 작성하는 것보다 문제에 대응하는 데 더 많은 일을 한다.” 

코드를 쓰는 대신 기여자가 자신의 코드를 오픈소스 프로젝트에 유용하게 만드는 데 도움을 주거나, 프로세스와 비전을 문서로 정리하거나, 그 밖의 여러 일을 해야 한다. 그리고 코딩을 하는 경우는 그렇게 많지 않다. 

OBS 프로젝트의 설립자 겸 관리자인 짐 베일리는 “프로젝트를 관리할 때 골칫거리 가운데 하나는 유입되는 소프트웨어가 그다지 양호하지 않은 경우가 흔하다는 점이다”라고 말했다. 

그는 “사람들의 코드를 리뷰하는 것은 매우 어려울 수 있다. 프로젝트 내의 모든 것이 일관적이어야 하기 때문이다. 사람들이 기고하는 코드 가운데 수준 미달의 코드가 많다”라고 말했다. 

물론 모든 코드가 수준 미달이라는 것은 아니다. 그러나 코드의 품질 자체를 떠나 협소하고 자기 중심적이라는 이유로 수준에 부합하지 않는 경우가 흔하다. 

베일리는 “사람들은 거의 예외 없이 자신에게 유용한 코드만을 기고한다. 항상 그렇다는 것은 아니지만 모두에게 유익한 코드를 기고하는 경우는 드물다. 거의 80%의 경우 무언가에 대한 풀 리퀘스트(pull request), 코드 병합 요청이 있다면 이는 거의 언제나 협소한 자기 이익 때문이다”라고 설명했다. 

이에 대응하기 위해 관리자는 코드를 교정하기 위해 기고자와 대화하며 수많은 시간을 소비해야 한다. 베일리에 따르면 그는 이 때문에 여러 차례 번아웃 증상을 겪었다. 현재에도 자신이 리뷰해야 할 115개의 풀 리퀘스트가 대기 중이다. 

그러나 그는 코드를 작성하고 싶다고 전했다. 베일리는 “해야 할 일이 수 없이 많고, 한 가지 일에만 집중해야 한다. 코드를 작성할 수 없다. 코딩이 아니라 프로젝트를 관리하는 데 집중해야 한다. 그러다 보면 번아웃이 쉽게 찾아온다”라고 말했다. 

샌필리포의 사례로 돌아가보자. 

“소프트웨어 관리자가 되고 싶었던 적이 한번도 없었다” 
샌필리포가 한 인터뷰에서 말한 것처럼 그는 관계형 데이터베이스의 안락한 세계에 정착할 생각이 없었다. 그는 그저 마이SQL을 이용해 실시간 애널리틱스 엔진을 비용 효율적으로 제작할 수 없었고, 그래서 모든 데이터베이스 규칙을 타파하며 인-메모리 데이터베이스를 완성했다. 이는 세계에서 가장 사랑받고 10번째로 유명한 데이터베이스로 성장했다. 

그리고 이는 문제가 되었다. 샌필리포는 다음과 같이 말했다.  
 
“레디스는 놀랍게도 여러 분야에서 주역이 되었다. 시간이 지나면서 나의 일은 코드를 제작하는 것으로부터 코드가 최대한 유용하고 안정적임을 보장하는 쪽으로 변화했다. 그리고 최근 몇 해 동안 내가 매일 하는 일이 완전히 달라졌다. 다른 개발자가 레디스 코드에 관해, 이를 향상시키는 방법에 관해, 보다 정확하거나 보다 빠르거나 보다 안전하기 위해 필요한 변화에 관해 말한 것을 검토하면서 대부분의 시간을 보냈다. 그렇지만 나는 소프트웨어 관리자가 되기를 원한 적이 전혀 없었다.”

그러나 프로젝트 관리는 오픈소스 소프트웨어 개발의 정점이 아닌가? 그럴 수도 있지만 샌필리노의 경우는 그렇지 않다. 그는 “나 자신을 표현하기 위해 코드를 쓴다. 나의 첫째 목표는 아름다운 무언가를 만드는 것이다. 유능한 프로그래머보다 무능한 예술가로 기억되는 것이 차라리 낫다”라고 말했다. 

갈등이 느껴지는가? 이어서 그는 “현재는 나 자신을 표출하는 것보다 프로젝트를 관리하는 쪽으로 더 많은 요청을 받는다. 그리고 실제로 이게 레디스에게 현재 필요한 것이다. 그러나 이는 내가 하고 싶은 것이 아니다”라고 말했다. 

오픈소스 권위자인 팀 브레이는 오픈소스 소프트웨어 개발과 클라우드 서비스의 교차점에 대해 이야기하면서 “탁월한 소프트웨어를 무로부터 창출하는 재능이 있는 사람이 반드시 운영에서도 뛰어난 것은 아니다”라고 말했다. 

그는 이어 “오픈소스 프로젝트 관리도 예외가 아니다. 유능한 소프트웨어 개발자라고 해서 반드시 우수한 소프트웨어 관리자가 된다는 것은 아니고, 그 반대도 마찬가지이다”라고 말했다. 

샌필리포의 사례는 개발자가 두 가지를 전부 잘할 수 있지만 두 가지 모두에 관심이 있지는 않은 사례로 보는 것이 더 적절하다(어떤 식으로 보든 샌필리포는 유능한 관리자였다. 그러나 스스로가 프로젝트에 걸림돌이 될 수 있다고 말한 드문 사람이기도 하다.) 

샌필리포는 행보는 오픈소스 커뮤니티에게 참고할 만한 선례를 남겼지만, 이는 기업에게도 적용된다. 일부 개발자는 사람 또는 코드에 대한 관리자로 성공할 수 있겠지만, 모두가 그럴 수는 없다. 따라서 기업은 엔지니어에게 관리 작업 이외의 경로를 개발해 제시하는 것이 좋다. 그렇다면 개발자는 좋아하는 코드에 전념하면서 경력을 개척할 수 있을 것이다. 그렇지 않은 경우 불만스러운 개발자의 벗아웃과 이탈 가능성이 있다. 샌필리포 사례에서 알 수 있듯이 얼마든지 더 나은 길이 존재할 수 있다. ciokr@idg.co.kr



2020.07.08

칼럼 | '나 그냥 코딩하게 해주세요'··· 오픈소스 프로젝트 관리자의 딜레마

Matt Asay | InfoWorld
오픈소스 프로젝트를 유지한다는 것은 코딩과 전혀 다른 이야기다. 관심사가 코딩인 사람이 프로젝트를 유지해야 하다면 문제가 될 수 있다는 의미다. 

레디스(Redis) 설립자인 살바토르 샌필리포에게는 임기 제한이 없었다. 그의 리더 지위에 제동을 건 사람도 없었고, 그가 레디스의 혁신을 지속하는 데 다른 걸림돌이 있지도 않았다. 그러나 2020년 6월 30일 샌필리포는 레디스 직무의 종료를 발표했다. 이 프로젝트의 최고 관리자 역할을 그만두겠다는 것이다. 

그는 다음과 같이 말했다. “앞날이 어떨지 정말이지 모르겠다. 이렇다 할 일도 없이 그냥 두리번거리기만 하는 것 같다.”
 
10년이 넘는 기간 동안 레디스의 간판 역할을 해온 샌필리포는 한계에 도달했다. 그는 휴식이 필요했다. 샌필리포의 이탈이 초래할 영향은 레디스 커뮤니티에 한정될 것이 유력하지만, 좀더 살펴보면 더 넓은 함의를 갖는다.  

여기서는 오픈소스 관리자에 대해 이야기할 것이다. 그리고 샌필리포의 사례가 기업에게 어떤 교훈을 주는지 살펴본다.
 
ⓒ Image Credit : Getty Images Bank

또 다른 종류의 ‘로우 코드’
오픈소스 커뮤니티가 어떻게 돌아가는지 아는 사람이라면 아마 이 사실을 알고 있을 것이다. 즉, 관리자는 코드를 많이 쓰지 않는다는 사실이다. 기트허브 오픈소스 가이드에서 보듯이 “수많은 사람이 사용하는 오픈소스 프로젝트를 관리한다면 코드를 작성하는 것보다 문제에 대응하는 데 더 많은 일을 한다.” 

코드를 쓰는 대신 기여자가 자신의 코드를 오픈소스 프로젝트에 유용하게 만드는 데 도움을 주거나, 프로세스와 비전을 문서로 정리하거나, 그 밖의 여러 일을 해야 한다. 그리고 코딩을 하는 경우는 그렇게 많지 않다. 

OBS 프로젝트의 설립자 겸 관리자인 짐 베일리는 “프로젝트를 관리할 때 골칫거리 가운데 하나는 유입되는 소프트웨어가 그다지 양호하지 않은 경우가 흔하다는 점이다”라고 말했다. 

그는 “사람들의 코드를 리뷰하는 것은 매우 어려울 수 있다. 프로젝트 내의 모든 것이 일관적이어야 하기 때문이다. 사람들이 기고하는 코드 가운데 수준 미달의 코드가 많다”라고 말했다. 

물론 모든 코드가 수준 미달이라는 것은 아니다. 그러나 코드의 품질 자체를 떠나 협소하고 자기 중심적이라는 이유로 수준에 부합하지 않는 경우가 흔하다. 

베일리는 “사람들은 거의 예외 없이 자신에게 유용한 코드만을 기고한다. 항상 그렇다는 것은 아니지만 모두에게 유익한 코드를 기고하는 경우는 드물다. 거의 80%의 경우 무언가에 대한 풀 리퀘스트(pull request), 코드 병합 요청이 있다면 이는 거의 언제나 협소한 자기 이익 때문이다”라고 설명했다. 

이에 대응하기 위해 관리자는 코드를 교정하기 위해 기고자와 대화하며 수많은 시간을 소비해야 한다. 베일리에 따르면 그는 이 때문에 여러 차례 번아웃 증상을 겪었다. 현재에도 자신이 리뷰해야 할 115개의 풀 리퀘스트가 대기 중이다. 

그러나 그는 코드를 작성하고 싶다고 전했다. 베일리는 “해야 할 일이 수 없이 많고, 한 가지 일에만 집중해야 한다. 코드를 작성할 수 없다. 코딩이 아니라 프로젝트를 관리하는 데 집중해야 한다. 그러다 보면 번아웃이 쉽게 찾아온다”라고 말했다. 

샌필리포의 사례로 돌아가보자. 

“소프트웨어 관리자가 되고 싶었던 적이 한번도 없었다” 
샌필리포가 한 인터뷰에서 말한 것처럼 그는 관계형 데이터베이스의 안락한 세계에 정착할 생각이 없었다. 그는 그저 마이SQL을 이용해 실시간 애널리틱스 엔진을 비용 효율적으로 제작할 수 없었고, 그래서 모든 데이터베이스 규칙을 타파하며 인-메모리 데이터베이스를 완성했다. 이는 세계에서 가장 사랑받고 10번째로 유명한 데이터베이스로 성장했다. 

그리고 이는 문제가 되었다. 샌필리포는 다음과 같이 말했다.  
 
“레디스는 놀랍게도 여러 분야에서 주역이 되었다. 시간이 지나면서 나의 일은 코드를 제작하는 것으로부터 코드가 최대한 유용하고 안정적임을 보장하는 쪽으로 변화했다. 그리고 최근 몇 해 동안 내가 매일 하는 일이 완전히 달라졌다. 다른 개발자가 레디스 코드에 관해, 이를 향상시키는 방법에 관해, 보다 정확하거나 보다 빠르거나 보다 안전하기 위해 필요한 변화에 관해 말한 것을 검토하면서 대부분의 시간을 보냈다. 그렇지만 나는 소프트웨어 관리자가 되기를 원한 적이 전혀 없었다.”

그러나 프로젝트 관리는 오픈소스 소프트웨어 개발의 정점이 아닌가? 그럴 수도 있지만 샌필리노의 경우는 그렇지 않다. 그는 “나 자신을 표현하기 위해 코드를 쓴다. 나의 첫째 목표는 아름다운 무언가를 만드는 것이다. 유능한 프로그래머보다 무능한 예술가로 기억되는 것이 차라리 낫다”라고 말했다. 

갈등이 느껴지는가? 이어서 그는 “현재는 나 자신을 표출하는 것보다 프로젝트를 관리하는 쪽으로 더 많은 요청을 받는다. 그리고 실제로 이게 레디스에게 현재 필요한 것이다. 그러나 이는 내가 하고 싶은 것이 아니다”라고 말했다. 

오픈소스 권위자인 팀 브레이는 오픈소스 소프트웨어 개발과 클라우드 서비스의 교차점에 대해 이야기하면서 “탁월한 소프트웨어를 무로부터 창출하는 재능이 있는 사람이 반드시 운영에서도 뛰어난 것은 아니다”라고 말했다. 

그는 이어 “오픈소스 프로젝트 관리도 예외가 아니다. 유능한 소프트웨어 개발자라고 해서 반드시 우수한 소프트웨어 관리자가 된다는 것은 아니고, 그 반대도 마찬가지이다”라고 말했다. 

샌필리포의 사례는 개발자가 두 가지를 전부 잘할 수 있지만 두 가지 모두에 관심이 있지는 않은 사례로 보는 것이 더 적절하다(어떤 식으로 보든 샌필리포는 유능한 관리자였다. 그러나 스스로가 프로젝트에 걸림돌이 될 수 있다고 말한 드문 사람이기도 하다.) 

샌필리포는 행보는 오픈소스 커뮤니티에게 참고할 만한 선례를 남겼지만, 이는 기업에게도 적용된다. 일부 개발자는 사람 또는 코드에 대한 관리자로 성공할 수 있겠지만, 모두가 그럴 수는 없다. 따라서 기업은 엔지니어에게 관리 작업 이외의 경로를 개발해 제시하는 것이 좋다. 그렇다면 개발자는 좋아하는 코드에 전념하면서 경력을 개척할 수 있을 것이다. 그렇지 않은 경우 불만스러운 개발자의 벗아웃과 이탈 가능성이 있다. 샌필리포 사례에서 알 수 있듯이 얼마든지 더 나은 길이 존재할 수 있다. ciokr@idg.co.kr

X