모델링을 수행하는 주체는?

실무에서 모델링을 수행하는 주체는 누구일까요? 당연한 질문인데 답변하기 망설여지는 게 안타깝습니다.

 

개발 프로젝트에서 데이터 모델링을 개발자가 수행하는 경우가 많습니다. 운영 단계는 제외하고 개발 단계만 따져도 개발자가 모델을 설계하는 경우가 60~70%는 되지 않을까 싶습니다.

 

개발 프로젝트에서 전문 모델러가 모델링을 수행한 지는 얼마 되지 않을 거 같습니다. 아마 15년 전부터 일부 대형 프로젝트에서 전문 모델러가 모델링을 수행하지 않았나 싶습니다.

 

그렇지 않으면 개발자 중에 모델링을 잘 하는 사람이 모델링을 수행하는 경우가 대부분이었습니다. 저도 15년 전에 그렇게 모델링을 했습니다. 개발도 했지만 프로그래밍 언어보다 MS 액세스를 먼저 다루었고, 정규화를 알고 있었기 때문이었죠.

 

하지만 그때도 일반적이지 않았을 뿐이지 전문 모델러는 있었을 것이고, 전문 모델러가 모델링을 수행하고 있었을 것입니다. EA 아키텍처가 활성화돼서 DA를 전문 영역으로 인식하게 됐고, 몇몇 모델링 회사의 노력이 결과로 나타난 것일테지요.

 

그럼에도 아직까지 개발자가 모델링을 수행하는 개발 프로젝트가 많고, 규모가 큰 프로젝트도 그렇게 하는 경우가 많습니다. 개발자가 모델링을 수행하는 경우 그 모델을 검토하는 소수의 모델러가 존재하기도 하는데, 최소한의 안전 장치만 두는 것입니다.

 

사업에 대한 의사결정자가 아닌 입장에서 이유를 정확히 알 수는 없지만, 몇 가지 추측해 볼 수 있습니다. 자주 듣는 얘기지만 모델러는 업무를 모르기 때문에 모델링을 수행할 수 없다는 주장이 이유가 될 듯합니다.

 

이는 지난 글에서 자세히 설명했는데요. 업무 설명을 누구도 해주지 않는다면 모델링을 할 수 없지만 그게 아니라면 기우일 뿐입니다. 전문 모델러는 업무 설명을 듣고, 데이터 종속성을 따져서 설계할 뿐입니다. 통합과 확장 가능성까지 감안해서 설계하기 때문에 모델의 품질이 좋습니다.

 

또 다른 이유로, 전문 모델러가 부족하다는 점이 떠오릅니다. 큰 프로젝트는 6~7명의 전문 모델러가 필요한데, 전문 모델러를 구하기 쉽지 않습니다. 그래도 이 문제 때문에 개발자가 모델링을 수행하도록 하지는 않을 것입니다.

 

비용 문제가 현실적인 문제일 것입니다. 하지만 그 비용이 전체 비용에서 차지하는 부분은 매우 적고, 개발자가 모델링을 수행해도 그 만큼의 추가 비용은 발생합니다. 모델이 변경되거나 잘못 설계됐을 때의 시행착오나 유지보수 비용까지 고려하면 전문 모델러가 수행했을 때의 비용이 오히려 적게 드는 것이라 확신합니다. 시스템의 토대가 되는 데이터 모델은 당장의 조그만 비용 차이보다는 향후의 효율성까지 고려해야 합니다.

 

개발자가 모델링을 수행할 때의 가장 큰 문제점은 ASIS 모델과 유사하다는 것입니다. 확신이 없기 때문에 모델 구조를 변경하기는 힘듭니다. 겁이 날 수밖에 없습니다. 모델 구조를 바꾸는 것은 전문 모델러에게도 힘든 작업이니까요. 개발자가 모델링을 하면 ASIS와 유사해질 수밖에 없습니다.

 

이런 이유로 개발자가 모델링을 하면 통합 모델이 되지 않습니다. 통합 모델은 데이터를 효과적으로 관리하는 것 외에 중복 개발을 방지하기 위한 목적도 있죠. 통합 모델은 전문 모델러도 구축하기 힘든 모델이니 개발자가 구축하기는 매우 힘들 것입니다.

 

결국 개발자가 수행한 모델은 품질이 떨어지는 모델이 될 가능성이 큽니다. 개발자는 해당 업무를 잘 알고 있고, 개발 언어와 개발 방법론을 잘 알고 있는 전문가입니다. 테이블을 사용하는 데는 익숙하지만 테이블을 설계하는 능력은 부족할 수밖에 없습니다. 전문 모델러가 설계한 모델과 품질 차이가 많이 날 수밖에 없습니다.

 

그럼 어떻게 해야 할까요? 당연히 전문 모델러가 모델링을 수행해야 합니다. 그래야 통합 모델이 되고, ASIS 모델에서 정제될 부분이 정제된 모델이 됩니다. 당장의 비용은 조금 더 소비될 수는 있지만, 모델이 잘 설계되면 개발을 빨리 하는 데도 도움이 되며, 개발 중에 모델이 변경되는 것도 최소화되고 오류가 줄 수 있습니다. 유지보수 효율성까지 고려한다면 비용은 오히려 저렴할 것입니다.

 

만약 어쩔 수 없이 개발자가 모델링을 수행한다면, 모델링 가이드와 모델 검토를 할 수 있는 전문 모델러가 반드시 존재해야 합니다. 개발자는 어차피 개발 영역이 좁기 때문에 통합 모델이나 일관된 모델을 설계할 수 없습니다. 전문 모델러가 전사 차원에서 모델의 설계 방향성과 통합 여부 등을 판단해야 합니다.

 

또한 논리 모델의 토대가 되는 개념 모델은 전문 모델러가 수행하는 것이 바람직합니다. 이 개념 모델은 중요 엔터티로 구성된 토대가 되는 모델(ERD)이지 개념도가 아닙니다. 개발자가 논리 모델을 설계할 때 사용되는 실제 모델이어야 합니다. 개념 모델은 논리 모델을 수행할 수 있는 토대가 돼야 의미가 있습니다. 개념 모델이 개념도에 불과해서 논리 모델로 이어지지 않는 모델이라면 개념 모델 단계는 필요 없습니다.

 

그리고 전문 모델러의 권한을 강화해야 합니다. 확실하게 잘못된 부분에 대한 변경이나 다른 영역과의 통합 의견 등이 반영될 수 있어야 합니다. 모델 설계 오너십이 없다고, 모델러의 의견이 무시되는 형식이 되면 안 되는 것이죠. 이를 보완할 수 있는 게, 토대인 개념 모델을 전문 모델러가 설계하고 개발자가 이어서 논리 모델을 설계하는 것입니다.

 

물론 앞서 밝힌 대로 가장 좋은 방법은 전문 모델러에게 물리 모델까지 전적으로 맡기는 것입니다. 당연한 원칙입니다. 처방은 의사가 하고 제조는 약사가 하는 식으로 전문 분야의 일을 전문가가 해야 정상적인 것이죠.

 

저는 직접 모델링한 경험이 대부분인데요. 문제가 없진 않지만 개발자가 모델을 설계하는 것에 비할 바가 아니라고 생각합니다. 통합 모델과 모델 구조 설계, 표준화, 이슈 처리 등 어떤 부분에서도 모델러가 설계한 모델이 월등합니다. 개발자는 개발 전문가이지 모델을 설계하는 기술은 부족할 수밖에 없습니다.

 

간혹 모델러보다 모델 설계를 잘 할 수 있는 개발자를 보기도 합니다. 모델러로의 전향을 권유한 적도 여러 번 있습니다. 이런 개발자는 데이터에 관심을 가지고 오랫동안 공부한 사람이라 모델러라 해도 손색이 없습니다. 하지만 매우 드물고, 경험의 부족은 어쩔 수 없이 티가 납니다.

 

또한 프로젝트에서 이런 모델러 같은 개발자를 선별해서 배치하지는 않습니다. 개발을 잘하는 순수한 전문 개발자를 배치하죠. 역할에 맡게 배치하는 게 아니라는 것입니다. 이 때문에 자신 없는 모델 설게를 개발자에게 맡기는 것은 스트레스를 가중시키는 원인만 됩니다.

 

우선 수행사의 생각이 바뀌었으면 좋겠습니다. 어차피 모델링의 중요성을 피할 수 없다면, 모델 설계를 제대로 하겠다는 결정을 했으면 좋겠습니다. 수행사가 아니라면 고객사라도 그런 결정을 했으면 좋겠습니다.

 

각자의 분야에서 전문가가 제 역할을 해야 부작용이 줄 것입니다. 비전문가에게 전문적인 일을 맡기는 것은 사고로 이어질 확률도 커지며, 그 자체로 바람직하지 않습니다. 현재 우리 사회의 그릇된 모습이기도 합니다. 다음 세대에 물려줄 것은 아닙니다.

 

아마 개발자가 데이터 모델을 설계하지 않고 전문 모델러가 데이터 모델을 설계하는 현상은 가까운 시일 내에 오지 않을 수도 있습니다. 그래도 관련 전문가들이 끊임없이 주장하고, 그런 분위기가 되도록 노력해야 할 것입니다.

 

그리고 그런 시대가 올 것을 준비해야 합니다. DA를 준비하는 사람이 많아져서 때가 왔을 때 제대로 했으면 좋겠습니다. 모델러들도 더욱 노력했으면 좋겠고요. 모델링을 이끌었던 선구자적인 회사들도 초심으로 돌아가서, 힘들어도 다시 노력했으면 좋겠습니다.