투명한 개발 문화의 효과

흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자.

투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다.

거의 모든 결정의 과정 및 결과가 공개되고 기록되는 것이다. 이것의 효과는 꽤 대단한다. 이슈관리시스템을 이용하여 모든 정보를 공개하는 것도 좋은 방법이다. 결정해야 할 이슈들을 공개하고 결정 과정이 공개되면 근거가 부족한 일방적인 주장을 하기가 어려워진다.

일방적인 주장이라고 하면 특정부서의 입장만 밀어붙이거나 윗사람이라고 해서 일방적으로 우기는 것을 예로 들 수 있다. 영업의 입장, 회사의 비전, 개발 비용등 여러가지를 고려해야 할 결정에 영업의 입장대로만 주장하여 그렇게 결정되면 장기적으로 회사에 손해가 될 수 있다.

또, 2주는 더 걸릴 일을 추가해 놓고 일정을 전혀 손댈 수 없다고 주장을 한다면 그러한 주장이 공개된다면 상황이 좀 달라질 수도 있다. 무조건 우기기보다는 합리적인 해결책을 찾는 시늉이라도 하게 될 가능성이 높다. 그런 상황에도 독선적인 결정을 하고 그런 과정이 모든 직원들에게 공개가 되고 그런 일이 반복된다면 그런 주장을 하는 사람의 능력을 의심하게 될 것이다.

물론 이런 변화는 하루 아침에 일어나지도 않고 모든 정보가 투명하게 시스템에 기록되는 일이 쉽게 이루어지지는 않는다. 수평적인 구조와 성숙한 개발문화를 가지고 있다면 자연스로운 일이지만 그렇지 않은 조직에서의 변화는 쉽지 않고 오래 걸리는 일이다.

이럴 때는 개발팀이 주도하여 개발과정이 투명하게 공개되도록 유도를 하는 것이 좋다. 개발팀 스스로가 최대한 이슈를 등록하고 사소한 요청이나 결정사항도 이슈관리시스템을 통하고 타부서의 사용률이 저조하면 도와줘서라도 타부서 사람들도 점차 끌어들이는 것이 좋다. 경영진의 후원도 필요하지만 개발팀 스스로도 많은 노력을 해야 한다. 

우리가 흔히 모여서 회의를 통해 논의하고 결정하는 것 중 상당수는 시스템을 통해서 가능하다. 사람들이 물리적으로 모이는 것은 매우 많은 비용을 지불해야 한다. 가능하면 시스템을 이용하는 습관을 들이면 좋다. 또한 모여서 결정한 것도 시스템에 등록을 하면 좋다. 이때 최종 결정 사항외에도 그 과정과 누가 무슨 주장을 했는지 핵심적인 것을 요약해서 기록을 해주면 좋다. 이런 것이 일상화 될 때까지는 신경을 써서 노력해보자.

정보와 지식, 의논 내용 등을 기록으로 남기는 것이 습관이 들지 않으면 상당한 부담인 것이 사실이다. 하지만 모두가 어느정도 몸에 벤다면 오히려 더 시간을 절약해주고 효과적이라는 것을 알게 될 것이다.

내가 오늘 주장하거나 결정한 것이 내일 아침에 신문에 나도 나는 떳떳한가? 대부분의 정보가 공개되면 이와 비슷한 효과가 있어서 일방적인 주장이 좀 줄어 들 수 있다. 또한 한번 기록으로 남은 것은 추후 되돌아 봤을 때 언제 잘못된 결정을 했는지도 잘 알 수 있다. 말로해서 사라지거나 메일에 묻혀서 찾기 어려운 것은 그런 역할을 할 수 없다. 물론 모든 것을 기록으로 남기는 것은 불가능하지만 해보면 어디까지 남겨야 하는지 저절로 알게 된다. 걱정할 필요가 없다.

투명한 개발을 꺼려하는 개발팀도 많은 것을 알고 있다. 스펙의 많은 부분이 개발자들 머리속에 있고 뭘하나 알려고 해도 개발자에게 물어봐야 하고 온갖 정보를 숨겨서 개발자가 쥐고 있으면 그것이 곧 파워라고 생각하는 경우도 있다. 물론 단기적으로 맞는 말일 수 있으나 장기적으로는 개발자에게 오히려 손해인 경우가 많다. 회사 차원에서는 장/단기적으로 모두 손해다.

보통 개발팀은 여러가지 불합리한 것들 때문에 고생을 한다. 일방적인 요구사항 추가/변경이나 그럼에도 불구하고 무리한 일정에 많이 시달리곤 한다. 투명한 개발은 여러가지 효과가 있지만 개발팀이 조금더 합리적으로 일할 수 있게 하는 효과도 있다.

스펙을 작성하고 Wiki를 통해서 정보를 공유하는 것외에 모든 결정과정을 투명하게 공개하는 것을 통해서 좀더 효율적인 개발 문화에 한발짝 다가가보자.