개발 프로세스에 대한 판단

정형화된 개발 프로세스는 건축과 같이 Waterfall 방식을 일반적으로 택한다. 그래서 소프트웨어 감리도 이 Waterfall 방식에 의거하여 검수하고 확인하게 된다.

개인적인 경험 기반으로 이 Waterfall 방식의 개발에서 가장 큰 문제는 분석/설계 단계에서의 완성도다. 이 분석, 설계 단계에서 만들어진 구조에서 조금이라도 빗겨나가면 개발이 크게 흔들리며, 결과물은 전혀 다른 결과물을 자아낼 수 밖에 없다. 흔들린 결과물을 원상복귀하는데 크나큰 댓가를 치르는 모습을 경험하기도 했고, 지켜바라보기도 했다.

여러가지 방법은 있겠지만, 대개의 경우 상황에 따라 아메바처럼 변하는 애자일 방식으로 진행하는데 그 중 XP 방식을 많이 진행하게 된다. 중구난방으로 마구 쏟아져 백로그에서 개발자들이 모여 틀을 구성하고 구현해보고 조립해본다. 단계 단계 마다 확인하고 연결하면서 구성하게 된다. 즉 Top-Down이 아닌 Down-Top 방식이지 않나 싶다.

일반적으로 작은 프로젝트나 일반 기업을 대상으로 프로젝트를 진행하는 경우 이 감리라는 단계가 생략되거나 축소 혹은 다른 형태로 제공하지만, 각종 공공기관에서는 각 담당자가 현재 공정에 대한 이해가 많이 부족하고, 업무 수행의 공정성을 증명하기 위해 감리라는 절차를 밟게 된다. 문제는 감리하는 프로세스다. 감리라는 조직은 검증하기 위한 조직이다 보니 모든 절차는 정형적일 수 밖에 없기 때문에 정해진 대로 밖에는 할 수 없다. 더욱이 새로운 프로세스라는 건 적용하는게 무리가 생길 수 밖에 없다. 결국 하던 대로 하게 되고, 가장 체크하기 좋은 방법인 이 Waterfall 방식을 고집할 수 밖에 없다.

개발과 감리는 바로 이 점에서부터 상충을 할 수 밖에 없다.
개발에서는 다양한 요구를 적용하기 위해, 알 수 없는 무언가를 개발하기 위해 유연한 진행을 하고자 한다면, 감리는 정확한 검사와 확인을 위해 딱 정해진 포인트를 강조하게 된다. 뻔한 개발이야 개발자들도 어느정도 정형화를 하겠지만, 막연한 요구사항과 그 결과물을 쉽게 예상하지 못한다면 자연스럽게 흩어지는 구성이 되는데, 이걸 리스크로 간주하고 더 철저히 감시하고 확인하는게 감리의 역할이 된다는 것이다.

물론 감리에서도 변경에 대한 유연성을 제시하면서 그에 따른 변경이 존재하면 당연히 허용을 해준다. 다만, 문서로 남겨서 그 근거를 제시하라는 내용에서 부터다.

보통 건축물은 한번 지어지면 정말 수정이라는게 불가능하다. 설계된 내용 그대로 지어져야 되며, 설계가 잘못되면 그 건물은 정말이지 끝이다. 정말 분석, 설계가 중요한 요소가 될 수 밖에 없다.

하지만 소프트웨어는 동적인 변화를 갖는다. 요구사항이 변해도 변할 수 있으며, 기술이 변해도 변할 수 있다. 중심 설계라는 것이 있겠지만, 간혹 그 중심 설계라는게 잘못되어도 수정은 가능하다. 물론 댓가는 크지만. 이 리스크 줄이는 방법은 개발자들은 작은 개발 단위 개발이라는 방식을 택한 것 뿐이지만...

( 출처 :https://www.slideshare.net/deview/1c3 )

만약 이 개발과 감리라는 두 개의 상충점을 조율을 어떻게 하냐에 따라 프로젝트는 윈윈이 되거나, 어느 한 쪽으로 질질 끌려다니거나 실패하거나 4중 하나가 되지 않을까 생각한다. 감리라는게 소프트웨어 개발 쪽에는 그다지 큰 도움이 안되는 것은 맞지만, 무언가 검증하기 위한 고객의 방법이라는 점에서는 쉽게 부인하기 어렵다. 해줄 것은 해줘야 할 것이다. 하지만, 개발자체를 감리에 맞춰서 하라고 한다면 이 부분은 전혀 다른 문제라고 생각한다.

최소한 감리 입맛에 맞는 개발을 하려면, 현재 개발하려는 대상에 대한 이해가 최소 7~80%가 정해지고 잘 알고 있어야 된다. 더욱이 감리에서 제시하는 문서를 작성하기 위한 인원이 규모에 따라 2~3명 정도여야 하며, 각 문서화에 대한 전문적인 지식(UML, 요구사항 분석서, 추적서, 아키텍처 문서 등등)도 상당해야 한다.

그리고 각 내용들의 기본적인 내용은 거의 미리 작성을 하고 각 고객과의 인터뷰를 통해 정형화 하며 정리하고 매 순간 순간 추적표에 하나씩 꼼꼼하게 기록해야 한다. 절대 얼렁 뚱땅하는 순간 무너진다. 이렇게 정해진 내용을 기반으로 설계 문서를 작성한다. 여기서 모든 개발이 이뤄진다는 생각을 갖고 문서를 작성한다. 규모가 있는 프로젝트에서는 이 단계가 1~2개월로 절대 끝나지 않는다. 산출되는 문서의 양도 4~500여 페이지는 훌쩍 넘길 수 밖에 없다. SI 중 대기업이나 이런 프로세스를 제대로 처리할 수 있지 않을까?

개발자에게 위의 일을 하라고 한다면 과연 할 수 있을까? 더욱이 스스로 쓰면서도 스스로 족쇄가 될 거라는 것을 빤히 알게 될 내용을 말이다. 되려 적다가 여지 만들어본다고 혼자 쑈하다가 감리에 지적당하기나 할 것이다.

더욱이 개발하다가 누락이라도 된 부분이 있으면 그 내용을 추가하려다가 근거 찾으러 다녀야 하고, 불필요한 개발이라고 생각되어 생략하고 싶어도 그 내용을 증명해야 한다. 매우 적극적이면 그 증거라는 것을 채워보려 하겠지만, 최소한 내가 경험해본 결과 대개는 그냥 방치하거나 그대로 둔다. 일을 사서 만들 수 있을 정도로 여유로운 개발기간이 아니니까. 그래놓고 왜 그 때 수정하지 않았냐고 닥달하면, 생각해보니 잘못한 것은 맞으니 묵묵히 욕 얻어 먹고, 속으로는 설계가 엉망이지 않았냐는 뒷담화만 잔뜩 늘어놓으면서 결국 야근과 지연을 반복한다.

요즘 내가 처한 처지가 저 상황 속에 있다.

뭘 어떻게 해야할지 이젠 전혀 감 조차도 서지 않는다.

감리를 위한 프로젝트인지, 개발을 위한 프로젝트인지 부터 생각해야 할 것 같은데, 자꾸 주변에서는 정론만을 들이대면서, 방법은 없다. 감리는 지키면서 개발을 위한 프로젝트를 하란다. 저 갭은 별 생각은 없으면서 말이다.