본문 바로가기
Homo Coding

기준의 법칙

by javauser 2011. 10. 28.
군대를 다녀온 사람은 익히 잘 알 것이다. 기준의 중요성을. 아니, 군대식으로 통제되던 시절의 중고등학교 시절을 나온 사람들도 충분히 알 수 있을 것이다. 일련의 단체를 일렬로 정렬한다는 자체가 얼마나 어려운 것인지를. 우르르 몰려나온 사람들을 정렬하는 것은 기준을 세우는 것이다. 기준이라는 소리에 모두가 경청하고 오와 열을 맞추고 앞뒤의 간격을 적당하게 유지시키는 노력들을 개인에게 부여한다. 만일 기준의 상체나 하체가 다른 각도로 서있으면 전체의 줄이나 열이 삐딱하게 되는 것을 아침 조례 시간에 경험해본 사람들은 알 것이다.

We brake for nobody!
We brake for nobody! by leg0fenris 저작자 표시비영리변경 금지


SW 개발시에도 기준은 상당히 중요하다. 그것도 제일 처음에 어떠한 형태로 해당 산출물이 만들어졌는지에 따라서 이후의 만들어진 산출물들은 거기에 영향을 상당히 받는다. 어찌 보면 커뮤니케이션이 닫혀진 조직의 속성도 있으며, 무엇인가 고민하면서 왜 그래야 하는지를 반문하면서 새로운 형태로 만들어가려는 노력을 제약받는 환경에서 어쩔 수 없다라는 생각도 들지만, 이러한 현상은 집단 사고에 속하기도 한다.

요즘엔 특정 조직이 템플릿이나 가이드 등을 만들어서 그대로 수행하라는 압박을 주기도 하며, 누군가가 형상관리에 최초에 올려놓은 것을 보고 그대로 좇아서 수행하는 경우도 있다. 그 누구가 되었든 간에 처음 형상관리에 올려놓은 산출물은 바로 기준이 된다. 이 산출물이 예제라고 하더라도 바로 기준이 되어버린다. 소스코드의 주석, 형상관리 항목(소스파일, 디렉토리, 설정파일, 바이너리 파일 등) 이 모든 것들의 최초 산출물은 바로 기준이 된다.

많은 사람들이 동일한 활동을 하는 그룹에서는 최소한 남들만큼만 하기를 원한다. 무엇인가 튀어나오면 감사에 걸리며, 왜 그렇게 되었는지에 대한 심문을 받아야 한다. 하지만, 처음의 기준이 잘못되었다면, 혹은 아무런 의미없이 올려진 산출물이라면 그 이후의 산출물들을 바로 잡기란 여간 난처한게 아니다. 주석이 없는 소스 코드를 보고 이후의 개발자들은 주석이나 형상 변경 정보를 올리지 않는다. 거의 백명에 가까운 개발자가 동시다발적으로 수행하는 프로젝트에서는 이러한 현상을 바로 잡기가 힘들다. 마치 수십년동안 좌측통행에 익숙한 사람들이 어느날 갑자기 우측통행을 하라고 해도 그게 잘 안지켜지는 것처럼.

SW 개발에 참여하는 사람들은 개별 기술에 대해서 깊숙하고 광범위하게 익숙해져야 하고, 언제든지 개발 방식에 대해서 이야기할 수 있어야 한다. 기존의 기준을 세우는 방식은 개발자의 머리를 점점 굳어지게 만든다. 개인이 편한 방식을 아예 처음부터 방지하게 만드는 것이 아니라, 효과적이고 건전한 방식으로 유도해야 한다. 왜 그래야 하는지를 피부로 직접 체험하게 만들어야 한다. 또한, 비관적인(pessimistic) 관리/통제 방식이 아닌 낙관적인(optimistic) 관리/통제 방식으로 개발자의 부담을 덜어주어야 한다. 즉, 무조건 이것은 하고 저것은 하지 말아야 된다는 방식보다 잘못 어긋나는 방식에 대해서 모니터링하고 왜 그러지 말아야 될지에 대해서 기분이 나쁘지 않게 유도해야 한다.

언제까지 기준만을 탓하고 기준을 세우는 작업을 해야하는 것일까. 그러한 통제의 노력은 수많은 비용이 든다. 운동장에 아무렇게나 서있다고 해서 교장 선생님의 훈화를 안듣는 것은 아닐게다. 오와 열을 똑바로 맞추어서 부동자세로 서있다고 하더라도 교장 선생님의 훈화를 전체가 이해하고 듣는다고 생각하는 자세는 이제 시대를 잘못 파악하는 것은 아닐런지. 개발자에게 더 많은 자유와 책임을 부여하고 생산성이 나는 도구를 통해 자기 스스로 기준을 세울 수 있도록 가이드하는 것이 더 중요하다. 물론, 그러한 기준은 특정 방향성에 부합되도록 만들도록 하지만, 접근 방식이 다르다는 것으로 틀리다는 환경을 만들어서는 더더욱 안된다. 오와 열이 정렬된 학생들은 마음속에 서로 다른 생각으로 가득 차 있어서 교장 선생님의 말씀이 결코 귀로 들어가지 않는다.
반응형