(이미지 출처 : http://www.identropy.com/blog/. 사진만 링크걸음)


2010년 하반기, 나는 회사에서 FOSS 거버넌스 정책에 대한 초안을 잡았다. 조직이동을 하면서 아이디어와 개념만 잡는 일만 하고, 거버넌스에 대한 실무는 내가 직접 하지 않았다는 점이 가장 흠이지만. 큰 틀에서는 내가 생각한 큰 틀은 지금도 이어지고 있다. 사실 내가 하고 싶어서 한 것은 아니고, 시간이 약간 널널한 관계로 정리했었던 것 같다.

(내 생각에는 내가 뛰어나서기 보다는 시간이 많아서 된 것 같다. 절대로 내가 특출난 능력이 있어서 한 것은 아니다. 사실 난 많이 부족한 사람이다. )

회사 특성상, 오픈 소스를 많이 활용하고 있다. 웹 서비스 및 솔루션 특성상 많은 오픈 소스 라이브러리를 알고 언제든기 개발할 준비가 되어있어야 한다. 그러나 워낙 많은 오픈 소스들이 범람하고 있고, 잘못하다가는 장애로 이어질 수 있는 수많은 장애가 있기 때문에 반드시 이 부분이 있어야 했다.

단순히 오픈 소스 소프트웨어 는 아무거나 쓰세요 하기에는 중요한 결정을 하는 조직에 있었고, 많은 개발자들이 새로 나온 오픈 소스 소프트웨어 또는 버그가 충만한(?) 오픈 소스 소프트웨어의 특이 버전을 쓰면서 이슈가 될 수 있었다. 오픈 소스 소프트웨어를 쓰면서 문제나 장애가 생기면 누구의 책임인가? 하는 고민들이 생기던 시점이었다. 그리고 회사에 많은 서비스조직이 있다보니 계속 반복된 장애는 계속 다른 부서에서도 나타났다. 마치 메아리처럼 이 산, 저 산 부딪히듯이 계속 발생되는 경우가 있었다.

또한 거버넌스 (Governance)라는 단어는 사람마다 달리 생각할 수 있는 모호한 단어였다. 거버넌스란 무엇인가? 거버넌스의 한계는 어디까지인가? 정부가 통제하듯이 하는 것인가? 가이던스(Guidance) 라는 단어와 많이 비슷한 느낌이면서 먼가 Push하는 느낌 때문에 초안 잡는 부분에 힘이 들었다. 너무 관여하면 자율성에 문제가 일어나고, 너무 멀리 있으면 장애나 서비스개발에 어려운 점들이 많았다.

인터넷을 통해서 다양한 정보를 얻으려 했지만, 결코 정보를 취합하지는 못했다. 거버넌스 하는 회사가 한국 뿐 아니라 외국에도 없는 독특한 사례였다. 단순히 Test 의 개념이나 Regressive Test 개념정도로 거버넌스를 바라보는 자료도 있었다. 좋은 선례가 없어서 결국 우리 회사안에서의 FOSS 거버넌스를 직접 하기로 했다.

나는 여러가지 인문서와 성경을 참조했다.
- 헤겔의 역사철학 강의
- 예링의 권리를 위한 투쟁
- 키케로의 의무론
- 루소의 사회계약론
- 홉스의 리바이던
- 애덤스미스의 국부론
- 토마스 모어의 유토피아
- 로크의 정부론
- 아리스토텔레스의 정치학
- 하이데거의 존재와 시간

우선 거버넌스를 하기전에 많은 것을 알아햐 했다. 사람에 대해서 알아야 했었다. 조직이란, 사람이란 무엇인가? 그리고, 어떻게 해야 유익할 것인가? 선한 게 행동할 것인가? 개발자는 어떤 사람인가? 관리자는 어떤 사람인가? 이 조직의 롤은 무엇이고, 다른 조직의 롤은 무엇인가? 바람직한 거버넌스는 무엇인가? 협업은 어떻게 할 것인가?하는 많은 고민을 하고 또 고민했다. 사람을 이해하고 조직을 이해하는 과정 속에서 다른 사람들은 어떻게 문제를 해결하려고 했을까 하는 수많은 생각들을 접하면서 깊이 고민했다.
(이런 시간들을 통해서 나는 겸손함을 더욱 더 배웠던 시간이었다. 나보다 똑똑하고 훌륭한 사람들이 많았고, 그 분들을 통해서 사회를 볼 수 있었다. 그러나.. 내 안에 아직도 많은 식견이 부족해서 많이 다듬어야 할 것 같다. )

내가 과연 모든 사람이 만족할만한 완전한 거버넌스를 만들어낼 수 있을까? 라는 고민속에 초안을 작성하기 시작했다. 잘못된 방향과 설득으로 인해서 어중간하게 하다가 종료하는 것은 없도록 해야할 것 같았다. 감사하게도 조직장과 좋은 피드백을 통해서 좋은 초안이 만들어지기 시작했다.

오픈 소스 거버넌스의 사용 조건, 오픈 소스 거버넌스 결과에 대한 게시판, 오픈 소스 거버넌스 조직은 모든 오픈소스를 다 할 수 없기 때문에 오픈 소스를 사용하려고 하는 서비스 부서와의 협업 모델을 생각하며 그렸다. 다양한 시나리오를 따라 흘러가는 플로우 차트를 그리며 오픈 소스 거버넌스에 대한 내용을 작성해서 어른 조직장들의 회의를 통과했다.

내가 가장 바탕을 둔 것은 오픈 소스 라이브러리에 대한 '검증'과 서비스 부서와 거버넌스 조직간의 '신뢰'였다. 첫번째 오픈 소스 소프트웨어에 대한 '검증'은 철저히 하려고 했다. 비슷한 종류의 라이브러리를 비교하고 사용성 팩터들을 모두 나열하고 객관적인 검토와 테스트를 통해서 검증할 수 있게 했다. 그리고 승인받은 오픈 소스 라이브러는 버전 통제를 통해서 잘 쓸 수 있는 것과 못쓰는 것, 문제 있는 것을 구분하려고 했다.

두번째, 상호 조직간의 신뢰였다. 거버넌스 자체가 굉장히 딱딱해질 수 밖에 없고, 특히 칼로 자르듯 하는 부분 때문에 감정이 상하거나 신뢰 관계가 손상되지 않게 하려고 했다. 서로가 돕고 지식을 쌓고 신뢰를 증강시키는 부분을 많이 염두하려고 했다. 신뢰 관계가 손상되면 소문이 나게 되고 불신이 전체 조직으로 흘러갈 수 있는 부분을 줄이려 했다. 이 불신에 대한 방법론이 여러가지로 나타나게 하지 않는 것이 최선이라고 생각했다. 


(이미지 출처 : http://opiniontribunal.wordpress.com, 사진만 링크걸음)

초안을 작성하고 나고 공유하면서. 여러 담당자들로부터 들은 얘기는 다들 할 수 없다는 분위기였다. 그리고 코딩과 상관없는 일들을 하는 것에 대해서 많은 부담을 가지고 있었다. '코딩'의 즐거움이 없어서 부담스러웠을지 모르겠다. 하지만, 조직장의 업무 지시로 다들 잘해갔다. 그리고, 관계에 대한 신뢰 부분을 얘기할 때, 여러 개발자들의 설득이 가장 어려웠다. 관계의 중요성을 잘 얘기하려고 했지만, 이 부분은 잘 이해하는 사람은 많지 않았다. 개발자들에게는 관계의 중요성을 얘기하는 것은 가장 어렵다. (협업 잘하는 것과 관계를 잘 이끄는 것은 비슷하지만, 완전 다른 내용이다. 관계를 잘 이끄는 것은 상대에 대한 신뢰와 섬김과 양보가 필요하다. 때로는 적절한 관계를 두고 하는 것도 포함한다. 나중에 일과 관계에 대해서 써봐야겠다는 생각이 든다.)

모든 오픈 소스 라이브러리를 검증할 수 없기 때문에 중요한 것만 검증을 시도했다. 모든 라이브러리를 검증할 필요가 없었다. 중요한 것만, 장애로 검증한 것만 해도 사실은 충분했다.

시스템적으로 다양하게 변화했다. 위키보다는 Cafe 형태로 제공하는 방법으로 말씀드렸고, 그 부분은 잘 진행할 수 있었다. 또한 좀 더 진화해서 서버에 있는 라이브러리를 검증하여 서비스 개발자에게 이메일로 알려주도록 하는 시스템을 추가하였다. 이렇게 하여 안정성을 확보한 솔루션이 만들어졌다.

실제로 업무가 돌아가는 것을 보면서 기분이 좋았고, 사실 초안을 작성한 나도 확신이 없었다. 오픈 소스 라이브러리에 대한 믿음을 가지고 힘을 가지고 능력을 가진 조직장때문에 일이 잘 진행되었다. 다만, 아쉬운 점은 상호간의 협력 대신 점차 그 의미는 시들어지고, 껍데기인 프로세스만 남는다는 사실이 아쉬웠다. 아마도 많은 사람들이 나와 같은 고민을 했을까? 흐훗..


마치며...

오픈 소스 거버넌스에 대해서 간단하게 적은 글이다. 프로세스를 만들기전 어떤 고민을 했는지를 적었다. 거버넌스에 대한 고민에 대해서 누군가가 이런 일을 할 때 좋은 소스가 되지 않을까 해서 작성해본다.
좋은 오픈 소스 거버넌스는 방법론적 접근보다는 검증과 신뢰 관계가 중요하다는 관점에서 시작했고, 좋은 결과를 가질 수 있었던 것 같다.

Posted by '김용환'
,