오픈소스로 개발하면 좋은점 - 1

오픈소스로 개발하면 좋은 점은 엄청 많은데, 다 적기는 귀찮아서 1이라는 숫자를 붙이고 지금 생각난거 하나만 적어본다.ㅎ

오픈소스는 결과보다 과정을 중요하게 되는 효과가 있다. -맛소금

연남동에서 피맥하기 좋은 요즘

아주 오래전 내가 회사에 입사해서 개발자로서의 삶을 시작할 때, 심각한 시장 문제가 나오면 상무님이 결론 회의실로 담당자들을 집합시켰다. "이 세상에 버그없는 SW는 없다" 는 말로 부드럽게 시작하시지만, 결국은 최종 코드 작성자를 찾아서 아주 개박살을 내고 회의를 마친다. 무엇이 잘 못 되었는지 앞으로의 대책은 무엇인지, 어떻게 고쳐야 할지에 대한 고민은 별도로 진행되지 않는다. 아니 진행은 추후에 따로 진행된다. 개박살 나는 꼴을 보고 사람들은 겁을 먹고, 뭐가 문제였는지 스스로 각자 자신의 코드를 점검하고, 알아서 조심한다.ㅋㅋㅋ

그 때는 철저히 결과 중심이었다. 지금 기준으로 SW품질을 논하자면, 너무 부끄러운 점이 많다. 요구 사항에 맞게 동작하는 코드가 핵심이었고, 그것이 가장 효율적이라고 생각했다.

요즘은 시대가 많이 변했다. 회사에서도 동작하는 코드보다는 좋은 코드, 훌륭한 코드를 추구한다. 오픈소스는 그 과정에서 아주 좋은 역할을 할 수 있다.

우리가 모인 것은 동작하는 코드를 만들기 위함이 아니다. 좋은 코드를 만들기 위해 여기에 모였다. -맛소금

오픈소스로 개발을 하게되면 모든 소스가 공개되고, 보다 공개적으로 코드에 대해서 논하게 된다. 동작, 결과가 아닌 코드, 과정에 집중하게 된다. 누군가 하나의 코드 뭉치를 만들고, 리뷰어는 책임감을 갖고 더 꼼꼼이 확인 한다. 혹여 리뷰어가 확인하지 못한 부분도 다른 사람들이 확인 해 줄 수 있다. 개발자도 코드 한줄 한줄에 보다 더 집중하게 된다. 내 일기장에 끄적이는 것이 아니라 전교생 앞에서 발표를 하는 것에 가깝다. 개발자 본인도 더 책임감을 갖게되고, 부담감은 줄어 든다.

조금 과장해서 말해보자면...예전의 방식에서는 코드가 아무리 지저분하고 더러워도, 심지어 문제가 있어도 결과적으로 문제가 없으면 인정 받을 수 있었다. 반면, 요즘의 방식에서는 결과가 혹여나 결과가 좋지 않아도 코드에 문제가 없다면 책임 소재를 강하게 따지지 않는다.

근데, 과정이 좋으면 보통 결과도 좋다.ㅎ 당연히 코드가 좋으면, 자연스레 결과가 좋게 되어있다. 그래서 오픈소스로 개발하면 품질이 좋아진다. 많은 IT 기업들이 오픈소스로 개발 업무를 진행하고, 자신의 BOK, Body of Knowlege를 아낌 없이 기술 블로그에 오픈하는 이유가 그런 효과를 노리기 위해서 이다. 소속 개발자들의 코드 품질에 대한 자부심과 책임감을 높이고, 내부 경쟁이 아닌 외부 경쟁을 유도하기 위함이라고 생각한다.