코딩

설계자가 숙지한 기본단위(primitive) 수준으로 문제가 분해됐을때 설계에서 코딩으로 전환된다. 설계자와 코더(coder)가 동일한 사람이 아니라면, 설계자와 코더의 기본단위가 같지 않을수 있고, 이는 문제를 초래할 수 있다.

출처: 소프트웨어 공학의 사실과 오해

요즘 공정분리에 대한 관심이 높다. 얼핏 설계의 상세성에 대한 논란이 많다. 내가 속한 조직에서는 설계는 무조건 상세 해야 한다는 식의 논리가 힘을 얻고 있는 듯 보인다.  이는 들쭉 날쭉한 코더의 개발 역량, 원격지에서의 커뮤니케이션 오류 등을 모두 염두에 두고 생각하는 듯 하다.

다만 이런 식의 공정분리가 우리에게 주는 것이 무엇일까? 첫번째 경제성에 대해 생각해보다. 얼핏 봐도 설계의 비용이 늘어서 경제적인 이득이 있다는건 아닌 것 같다. 인건비가 싼 중국, 인도에 코딩을 아웃소싱 한다 치더라도 설계의 비용이 늘어난 것에 대한 보전에 지나지 않을 것이다.

두번째, 개발프로세스에 대해 생각해보면.. 요즘 방법론은 Waterfall 방법론의 약점을 보완하기 위하여 점진적인 방법론의 성향을 띈다. 더 나아가 Agile방법론에서는 일주일단위의 iteration을 운영하는 방법을 쓰기도한다. 이런 방법론에 공정분리가 적절한가?  iteration이 잦을 수록 공정분리에 따른 커뮤니케이션 비용, 시간이 증가할 것이다.

세번째, 고객이 공정분리가 가치있는 것이라고 생각하겠느냐? 공정분리를 한다고 고객에게 설득하는 것이 쉽지 않다고 한다. 얼핏 생각해도 설계 이후엔 요구사항의 변경이 힘들것 같다는 생각이 지나간다.고객의 입장에서도 한번 내 뱉은 요구사항을 번복하기가 쉽지 않다는 것을 받아들이기가 어려울것이다.

지금까지 공정분리에 대해 심하게 깐것 같지만 공정분리라는 말이 나온 것은 다른 곳에 있는 것 같다. 설계/코드 를 1인이 하는 경우에 설계의 품질이 엉망이라는 판단에서 일 것이다. 문제는 문제가 있는 곳에서 해결하라는 말을 하고 싶다.
설계의 품질이 엉망이란 것은 아직도 우리가 Waterfall에서 벗어나지 못해서 초기 설계에 대한 수정 없이 그냥 진행해 버리는 것 일수도 있고, 개발자(설계자+코더)들은 자신에게 Burden으로만 느껴지는 무거운 산출물을 본능적으로 무시고 싶을 것 같기도 하다. 그런면에서 Agile 방법론이 빨리 빨리 자라줬으면 한다.