2020.07.09

“코딩에만 집중하고 싶은데” 오픈소스 관리자와 번아웃

Matt Asay | InfoWorld
레디스(Redis)의 설립자인 살바토레 산필리포는 임기 제한이 없었다. 아무도 프로젝트 리더를 그만두라고 요구하지 않았고, 레디스의 혁신을 멈추라고 요구하지도 않았다. 그러나 2020년 6월 30일 산필리포는 자기 자신을 위해 ‘레디스 모험의 종말’을 발표했다. 발표 즉시 효력이 발생했고 유지 관리자 자리에서 내려왔다. 산필리포는 “앞으로의 미래는 알 수 없지만, 너무 많은 일을 하지 말고 주위를 그냥 둘러보라고 추천하고 싶다”라고 말했다.

10년 넘게 레디스의 간판 위치에 있었음에도(혹은, 오히려 그 때문일 수도 있지만) 산필리포는 할 일을 다했다. 휴식이 필요했다. 산필리포의 이탈이 레디스 공동체에만 영향을 미칠 수도 있겠지만, 이탈한 이유는 훨씬 더 광범위한 함의를 지닌다.
 
ⓒ Getty Images Bank

그렇다면 오픈소스 유지 관리자에 대해, 그리고 산필리포의 사례가 기업 내에서의 모범 사례로 어떻게 전환되는지 이야기해 보도록 하자.
 

다른 종류의 ‘로우 코드(low code)’

오픈소스 커뮤니티가 어떻게 작동하는지 잘 알고 있다면 건너뛰어도 좋다. 아마 이미 알고 있을 가능성이 높기 때문이다. 유지 관리자는 코드를 많이 쓰지 않는다. 깃허브 오픈소스 가이드에 따르면, “많은 사람들이 이용하는 오픈소스 프로젝트를 유지하는 사람이라면, 코딩 시간은 적고 문제 해결 시간이 더 많다는 것을 알아차렸을 것이다”라고 한다. 코드를 작성하는 대신, 유지 관리자는 자신의 코드가 프로젝트에 유용하게 쓰여 기여하려는 사람들과 의사소통을 하거나, 프로세스와 비전, 또는 다른 많은 것들을 문서화한다.

정작 코딩은...? 많이 하지는 않는다.

유명한 OBS 프로젝트의 유지 관리자와 이야기를 나누면서, 설립자(이자 유지 관리자인) 짐 베일리는 내게 프로젝트를 유지하는 데 있어 가장 큰 골칫거리는 새로 들어오는 소프트웨어가 “아주 좋지는 않은” 때가 종종 있다는 점이라고 말했다. 베일리는 “프로젝트의 모든 것이 일관되기를 원하면 여러 명의 코드를 검토하는 것은 매우 어려울 수 있다. 사람들이 기여하려는 코드 중에는 품질이 나쁜 것도 많이 있다”고 설명했다.

물론 모든 코드가 나쁜 것은 아니며, 때로는 다소 편협하고 자기 중심적이기 때문에 ‘나쁜’ 경우도 있다. 베일리는 다음과 같이 말했다. 

“사람들은 자신에게 유용한 것만 기여한다. 거의 대부분 그렇다. 보통 누구에게나 유용한 코드를 제공하지는 않는다. 어떤 것에 대한 전체 요청이나 코드 병합 요청을 받는 경우가 약 80%를 차지하는데 그것은 거의 언제나 개인의 사리사욕이 목적이다.”

즉, 기여자들과 대화를 나누면서 코드를 복구하는 데 많은 시간을 쏟아야 한다는 것이다. 베일리 자신도 여러 차례 이런 이유로 번아웃 되었다고 한다. 검토할 전체 요청 백로그가 115건이나 쌓여 있지만 베일리는 현재 계속 코드 작성에 몰두하고 있다. “할 일이 너무 많다. 그럴 수록 한 가지에만 집중할 필요가 있다. 꼭 코딩일 필요는 없다. 프로젝트를 코딩보다는 프로젝트의 유지 관리에 초점을 맞출 필요가 있다. 번아웃되는 것은 정말 한순간이다.”

다시 산필리포 이야기로 돌아가 보자. 
 

“나는 결코 소프트웨어 유지 관리자가 되고 싶지 않았다”

인터뷰에서 말했듯이, 산필리포는 관계형 데이터베이스의 아늑한 세계를 뒤집기 위해 나선 것이 아니었다. 그는 MySQL을 사용하여 비용 효율적으로 실시간 애널리틱스 엔진을 구축할 수 없어서, 지구상에서 가장 사랑받고 가장 인기 있는 10대 데이터베이스로 성장한 인메모리 데이터베이스를 제공하기 위해 데이터베이스의 모든 규칙을 깬 것이다.

결국에는 그것이 문제였다. 산필리포는 다음과 같이 적었다. 

“레디스는 놀랍게도 정말 많은 것들의 주요 구성 요소다. 그리고 해마다 나의 일은 레디스를 구축하는 것에서 가능한 한 유용하고, 가능한 한 신뢰할 수 있는 것을 확실히 하는 것으로 바뀌었다. 최근 몇 년 동안은 매일 하는 업무가 정말 많이 바뀌었다. 다른 개발자들이 레디스 코드에 대해 말해주는 것, 그것을 개선하는 방법, 그것을 더 정확하거나 더 빠르고 더 안전하게 하기 위해 필요한 변화를 확인하는 것이 대부분이다. 하지만 나는 결코 소프트웨어 유지 관리자가 되고 싶지는 않았다.”

그러나 프로젝트를 유지하는 것이 오픈소스 소프트웨어 개발의 정점이 아닐까? 산필리포에게는 그렇지 않다. “나는 스스로를 표현하기 위해 코드를 쓴다. 첫 번째 목표는 어떤 면에서는 어떤 것을 아름답게 만드는 것이다. 본질적으로 좋은 프로그래머라기보다는 차라리 나쁜 아티스트로 기억되기를 원한다.” 산필리포의 갈등이 이해되는가? 그는 계속 이렇게 말한다. “자신을 표현하기보다 프로젝트 유지에 힘쓰면서 점점 더 많은 질문을 받는다. 그것은 바로 지금 레디스에 필요한 것이다. 하지만 내가 하고 싶은 일은 아니다.”

오픈소스 소프트웨어 개발과 클라우드 서비스의 교차점에 대해서 오픈소스 전문가인 팀 브레이는 “무가치에서 고부가가치 소프트웨어를 잘 만들어내는 자질이 반드시 운영 능력과 직결되지는 않는다”라고 말했다. 오픈소스 프로젝트 유지도 마찬가지라고 할 수 있다. 놀라운 소프트웨어 개발자라고 해서 훌륭한 소프트웨어 유지 관리자인 것은 아니며, 그 반대의 경우도 마찬가지다.

아마도 산필리포의 예에 더 적절한 것은 개발자들이 둘 다 잘할 수 있어도, 둘 다에 관심이 없을 수도 있다는 점이다. (다른 사람에게 의존하기보다는 스스로 많은 일을 하는 것을 좋아하기 때문에 장애물이 될 수 있다고 제일 먼저 말한 사람이지만, 모든 면에서 산필리포는 훌륭한 유지 관리자였다.)

산필리포는 오픈소스 커뮤니티의 프로젝트 내에서 경력을 어떻게 발전시킬지를 생각해야 한다는 점을 보여주는 좋은 사례를 제시했지만, 기업 내에서도 같은 원칙이 적용된다. 일부 개발자는 (사람이나 코드의) 관리자로서 번창하겠지만, 전부가 그런 것은 아니다. 그런 만큼 더 많은 기업이 최고의 엔지니어를 위해 비경영 노선을 개척할 필요가 있으며, 이렇게 함으로써 개발자는 자신이 사랑하는 코드를 떠나지 않고도 경력을 발전시킬 수 있다. 또 다른 대안은 불행한 개발자들이 번아웃된 채로 나가 떨어지는 것이다. 하지만 산필리노가 보여준 것처럼, 더 좋은 방법이 있다. editor@itworld.co.kr 


2020.07.09

“코딩에만 집중하고 싶은데” 오픈소스 관리자와 번아웃

Matt Asay | InfoWorld
레디스(Redis)의 설립자인 살바토레 산필리포는 임기 제한이 없었다. 아무도 프로젝트 리더를 그만두라고 요구하지 않았고, 레디스의 혁신을 멈추라고 요구하지도 않았다. 그러나 2020년 6월 30일 산필리포는 자기 자신을 위해 ‘레디스 모험의 종말’을 발표했다. 발표 즉시 효력이 발생했고 유지 관리자 자리에서 내려왔다. 산필리포는 “앞으로의 미래는 알 수 없지만, 너무 많은 일을 하지 말고 주위를 그냥 둘러보라고 추천하고 싶다”라고 말했다.

10년 넘게 레디스의 간판 위치에 있었음에도(혹은, 오히려 그 때문일 수도 있지만) 산필리포는 할 일을 다했다. 휴식이 필요했다. 산필리포의 이탈이 레디스 공동체에만 영향을 미칠 수도 있겠지만, 이탈한 이유는 훨씬 더 광범위한 함의를 지닌다.
 
ⓒ Getty Images Bank

그렇다면 오픈소스 유지 관리자에 대해, 그리고 산필리포의 사례가 기업 내에서의 모범 사례로 어떻게 전환되는지 이야기해 보도록 하자.
 

다른 종류의 ‘로우 코드(low code)’

오픈소스 커뮤니티가 어떻게 작동하는지 잘 알고 있다면 건너뛰어도 좋다. 아마 이미 알고 있을 가능성이 높기 때문이다. 유지 관리자는 코드를 많이 쓰지 않는다. 깃허브 오픈소스 가이드에 따르면, “많은 사람들이 이용하는 오픈소스 프로젝트를 유지하는 사람이라면, 코딩 시간은 적고 문제 해결 시간이 더 많다는 것을 알아차렸을 것이다”라고 한다. 코드를 작성하는 대신, 유지 관리자는 자신의 코드가 프로젝트에 유용하게 쓰여 기여하려는 사람들과 의사소통을 하거나, 프로세스와 비전, 또는 다른 많은 것들을 문서화한다.

정작 코딩은...? 많이 하지는 않는다.

유명한 OBS 프로젝트의 유지 관리자와 이야기를 나누면서, 설립자(이자 유지 관리자인) 짐 베일리는 내게 프로젝트를 유지하는 데 있어 가장 큰 골칫거리는 새로 들어오는 소프트웨어가 “아주 좋지는 않은” 때가 종종 있다는 점이라고 말했다. 베일리는 “프로젝트의 모든 것이 일관되기를 원하면 여러 명의 코드를 검토하는 것은 매우 어려울 수 있다. 사람들이 기여하려는 코드 중에는 품질이 나쁜 것도 많이 있다”고 설명했다.

물론 모든 코드가 나쁜 것은 아니며, 때로는 다소 편협하고 자기 중심적이기 때문에 ‘나쁜’ 경우도 있다. 베일리는 다음과 같이 말했다. 

“사람들은 자신에게 유용한 것만 기여한다. 거의 대부분 그렇다. 보통 누구에게나 유용한 코드를 제공하지는 않는다. 어떤 것에 대한 전체 요청이나 코드 병합 요청을 받는 경우가 약 80%를 차지하는데 그것은 거의 언제나 개인의 사리사욕이 목적이다.”

즉, 기여자들과 대화를 나누면서 코드를 복구하는 데 많은 시간을 쏟아야 한다는 것이다. 베일리 자신도 여러 차례 이런 이유로 번아웃 되었다고 한다. 검토할 전체 요청 백로그가 115건이나 쌓여 있지만 베일리는 현재 계속 코드 작성에 몰두하고 있다. “할 일이 너무 많다. 그럴 수록 한 가지에만 집중할 필요가 있다. 꼭 코딩일 필요는 없다. 프로젝트를 코딩보다는 프로젝트의 유지 관리에 초점을 맞출 필요가 있다. 번아웃되는 것은 정말 한순간이다.”

다시 산필리포 이야기로 돌아가 보자. 
 

“나는 결코 소프트웨어 유지 관리자가 되고 싶지 않았다”

인터뷰에서 말했듯이, 산필리포는 관계형 데이터베이스의 아늑한 세계를 뒤집기 위해 나선 것이 아니었다. 그는 MySQL을 사용하여 비용 효율적으로 실시간 애널리틱스 엔진을 구축할 수 없어서, 지구상에서 가장 사랑받고 가장 인기 있는 10대 데이터베이스로 성장한 인메모리 데이터베이스를 제공하기 위해 데이터베이스의 모든 규칙을 깬 것이다.

결국에는 그것이 문제였다. 산필리포는 다음과 같이 적었다. 

“레디스는 놀랍게도 정말 많은 것들의 주요 구성 요소다. 그리고 해마다 나의 일은 레디스를 구축하는 것에서 가능한 한 유용하고, 가능한 한 신뢰할 수 있는 것을 확실히 하는 것으로 바뀌었다. 최근 몇 년 동안은 매일 하는 업무가 정말 많이 바뀌었다. 다른 개발자들이 레디스 코드에 대해 말해주는 것, 그것을 개선하는 방법, 그것을 더 정확하거나 더 빠르고 더 안전하게 하기 위해 필요한 변화를 확인하는 것이 대부분이다. 하지만 나는 결코 소프트웨어 유지 관리자가 되고 싶지는 않았다.”

그러나 프로젝트를 유지하는 것이 오픈소스 소프트웨어 개발의 정점이 아닐까? 산필리포에게는 그렇지 않다. “나는 스스로를 표현하기 위해 코드를 쓴다. 첫 번째 목표는 어떤 면에서는 어떤 것을 아름답게 만드는 것이다. 본질적으로 좋은 프로그래머라기보다는 차라리 나쁜 아티스트로 기억되기를 원한다.” 산필리포의 갈등이 이해되는가? 그는 계속 이렇게 말한다. “자신을 표현하기보다 프로젝트 유지에 힘쓰면서 점점 더 많은 질문을 받는다. 그것은 바로 지금 레디스에 필요한 것이다. 하지만 내가 하고 싶은 일은 아니다.”

오픈소스 소프트웨어 개발과 클라우드 서비스의 교차점에 대해서 오픈소스 전문가인 팀 브레이는 “무가치에서 고부가가치 소프트웨어를 잘 만들어내는 자질이 반드시 운영 능력과 직결되지는 않는다”라고 말했다. 오픈소스 프로젝트 유지도 마찬가지라고 할 수 있다. 놀라운 소프트웨어 개발자라고 해서 훌륭한 소프트웨어 유지 관리자인 것은 아니며, 그 반대의 경우도 마찬가지다.

아마도 산필리포의 예에 더 적절한 것은 개발자들이 둘 다 잘할 수 있어도, 둘 다에 관심이 없을 수도 있다는 점이다. (다른 사람에게 의존하기보다는 스스로 많은 일을 하는 것을 좋아하기 때문에 장애물이 될 수 있다고 제일 먼저 말한 사람이지만, 모든 면에서 산필리포는 훌륭한 유지 관리자였다.)

산필리포는 오픈소스 커뮤니티의 프로젝트 내에서 경력을 어떻게 발전시킬지를 생각해야 한다는 점을 보여주는 좋은 사례를 제시했지만, 기업 내에서도 같은 원칙이 적용된다. 일부 개발자는 (사람이나 코드의) 관리자로서 번창하겠지만, 전부가 그런 것은 아니다. 그런 만큼 더 많은 기업이 최고의 엔지니어를 위해 비경영 노선을 개척할 필요가 있으며, 이렇게 함으로써 개발자는 자신이 사랑하는 코드를 떠나지 않고도 경력을 발전시킬 수 있다. 또 다른 대안은 불행한 개발자들이 번아웃된 채로 나가 떨어지는 것이다. 하지만 산필리노가 보여준 것처럼, 더 좋은 방법이 있다. editor@itworld.co.kr 


X