간단한 변화가 가져온 복잡성

지금까지 하나의 채널로 하나의 외부 시스템을 제어하는 구조만 만나왔는데 새로운 시스템은 두 개의 채널로 하나의 시스템을 제어하는 특별한 구조를 가지고 있다. 별거 아닌거 같은데 오늘 채널의 메시지 처리 파이프라인을 구성하며 어려움을 겪는다.

간단한 외부 환경 변화 하나로 왜 이렇게 큰 어려움을 겪는걸까? 곰곰이 생각해 보다 모델링의 부재 때문이 아닐까 생각해 보게 된다. 사실 채널이 두 개가 된 것 때문에 큰 어려움을 겪을 거라 예상하지 못했다. 무작정 기존 방식대로 코드를 작성하다 보니 여기저기서 예상치 못한 막히는 것들이 생기기 시작했다.

내가 생각한 의도가 맞는지 세부 코드로 작성해 보고, 틀린걸 인지하고, 돌아가고를 반복하다 보니 코드가 엉망이 되고 부분 부분 완성되어 가지 못하고 점점 완성되지 않은 큰 덩어리가 되어갔다. 모델링으로 내 생각을 검증해 보았다면 어땟을까?

과도한 모델링

한 때 Defence 분야에서 일할 때는 모델링을 정말 과도하게 했다. UML 툴로 거의 코드 수준까지 모델링을 하고 리뷰회의를 통해 검토까지 했었는데 그때는 정말 코드를 작성할 때 거침없이 코드를 작성했던 것 같다. 그때는 이럴 바에는 그냥 코드로 작성하는게 빠른거 아닌가 물음표를 많이 가졌었다. 그때는 확실히 과했었다.

모델링의 부재

다른 분야로 이직해보니 모델링이란 걸 거의 하지 않는다. 모델링이라고 하면 큰 시스템 단위의 아키텍처 다이어그램 정도를 만들어 보는 것이 전부이고 기능을 어떻게 구현할지, 내 생각을 코드로 구현하면 문제가 없는지 미리 확인해 보는 과정을 거의 생략하는 것 같다. 아키텍처 다이어그램도 구현 언어로 구현하기 전에 문제를 미리 모델링해서 찾아보자는 취지가 아니라 대부분 누군가에게 우리 시스템을 설명하기 위해서 작성하는 경우가 많다.

혹시 도움이 되지 않을까?

사실 많은 경우에 모델링 없이 주석 정도로 생각을 정리해 보고 코드를 작성하면 큰 문제를 만나지는 않았던 것 같다. 그러나 오늘 처럼 새로 만나는 문제이거나 많은 구성요소들이 참여하는 약간의 복잡성이 있는 문제는 구현 언어로 구현하기 이전에 모델링 언어로 문제를 풀어 보는게 적은 자원으로 소프트웨어의 복잡성을 제어하는데 도움이 되지 않나 하는 생각이 든다.

물론 정답인지는 모르겠다. 내일은 오늘 무작정 코드로 덤벼보았던 문제를 UML 다이어그램을 사용해 모델링해 보며 큰 그림을 그려보아야 겠다. 시간이 촉박해질수록 당장 코드를 작성하지 않으면 불안한 마음이 드는게 사실이지만 일보후퇴 이보전진이라는 말도 있지 않나? 잠시 뒤로 물러나서 재정비하고 다시 앞으로 나아갈 힘을 얻는게 좋을 것 같다. 물론 새로운 깨달음도 얻게 되지 않을까 기대해 본다.