모델러에게 필요한 역량
여기서 이야기하는 모델러는 SI프로젝트에서 활동하는 모델러를 말한다. Process Modeler 일수도 있고 Data Modeler 일수도 있다. Process Modeler와 Data Modeler에 대해서는 별도로 설명하게 될텐데 우선 간단히 보면,
Process Modeler는 프로젝트의 방법론에 맞춰 WBS 공정을 설계하고, 분석/설계 모델 또는 산출물의 표준 정의 및 가이드하고, 검토/피드백한다. 필요한 경우 분석/설계 관련 도구를 비교/검토/도입/표준화/커스터마이징/가이드할 수도 있다.
Data Modeler는 물리적인 DBMS를 관리하는 DBA와 달리 분석단계, 설계단계 특히 분석단계의 Data Modeling Task의 주체로서, Data Modeling 통합관리를 위한 표준/가이드/검토/피드백하고, DBA와 협업하여 DB설계에 대해 논의/정의하고, Data Modeling 도구 및 META 도구를 비교/검토/도입/표준화/커스터마이징/가이드해야 한다.
Process Modeler든 Data Modeler든 모델러라면 반드시 갖춰야할 역량이 있다. 당장 없더라도 여러 현장 경험과 시간을 들여서라도 반드시 확보해야할 능력이다. 아래 설명할 모델러의 역량을 갖추지 못하면 Process Modeler든 Data Modeler든 그 지식과 경험도 모두 소용없는 일이다. 소용없다는 말은 좀 과장되었고 제한적이라는 표현이 더 맞겠다.
그리고 아래 열거하는 역량들에 대해 가르치는 교과서는 없다. 관련 책이 있다하더라도 어느정도 짐작만 될 뿐이지 제대로 배우기는 어렵다. 가능한 여러 프로젝트 현장에서 경험적으로 체득해야한다. 선배 모델러와 함께 투입되어 배울수 있다면 더욱 좋겠지만, 그러한 기회가 흔히 오지 않기 때문에 혼자 맨땅에 헤딩하는 심정으로 배워야한다. 즉, 현장에 모델러든 비슷한 역할이든 나갈수 있는 기회가 있다면 반드시 손들고 나가야만 배울수 있는 역량들이다.
Communication 역량
현재 유명한 어떤 정치인이 정치에 발을 들여놓기 전에 했던 말이다. 사람의 능력은 'Communication'과 'Skill'의 '곱하기'이다. 예를들어 Skill은 '100'인데 Communication이 '0'이면 그 사람의 전체 능력은 몇 점인가? 그렇다 빵점이다. Communication이 '-1'이라면? 오히려 그가 가진 Skill이 더 독이되는 상황, 즉 없는게 나을것 같은 상황일수도 있겠다. 그 만큼 Skill 못지 않게 Communication 중요한 것이다.
모델러는 현장에 나가면 적게는 10명 미만, 많게는 100명 넘는 설계자/개발자를 상대할수도 있다. 뿐만 아니라 수행사의 PM, PL, QA 및 고객사의 의사결정권자까지 모델러가 상대/설득해야할 대상이 많다. 너무 원칙만 고집해도 안되고, 모든 걸 상황에 맞춰 다 허용해도 문제다. 너무 강해도 문제고, 너무 다 받아줘도 문제다. 당연히 받을 그 스트레스를 너무 속으로만 쌓으면 언젠가 터지기 마련이기 때문이다. 유연하게 소통하고 적절히 주고받을 수 있어야 한다. 말이 쉽지 어렵다.
나도 Communication이 좋지 못해 많이 힘들었다. 고집도 피우고 싸움도 많았다. 하지만 지나면 늘 후회였다. 지금도 잘 한다고는 할 수 없다. 그래서 늘 노력하고 있다. Communication에 대해. 그만큼 중요하고 어렵다.
책으로 배울수도 없고 지식만으로도 안된다. 관리자, 자사/협력업체/프리랜서 설계자/개발자, 고객 등과 부딪히면서 반드시 현장에서만 배울수 있는 역량이다. 하지만 반드시 필요한 역량이다. 부족해도 할수는 있지만 힘들다. 그렇다. 일단 마음부터 바꿔먹어야 한다.
Presentation 역량
여러 사람을 대상으로 앞에나와 이야기하는게 발표하는게 두려운가? 노력해도 어려울 것 같은가? 그러면 모델러 하기 어렵다.하더라도 Sub Modeler정도이지 전면에 나서는 Modeler가 되기는 어렵다.
관리자를 대상으로, 고객을 대상으로 설명하고 설득하고, 수십명의 설계자/개발자를 대상으로 가이드 교육하고, 그것도 필요할 때 마다 반복해서 해야하고, 모델링에 관련된 Workshop 등을 할 때 나가서 중재하고 진행도 해야 하는데 사람앞에 서기 힘들다면, 발표하는게 두렵다면, 앞으로도 계속 그럴것 같다면... 그렇다면 모델러는 힘들다고 하는 것이다.
그리고 Presentation 자료도 여러 사람을 대상을 전달하는데 적절하도록 잘 만들 수 있어야 한다. 대상에 맞춰... 폰트를 너무 작게 많은 내용을 담는다거나, 워드 형태를 슬라이드로 띄워두고 그냥 보고 읽기만 한다거나, 본인도 이해하지 못하는 내용을 띄워두고 적당히 넘어간다거나, 듣는 대상을 전혀 생각하지 않고 자기 하고 싶은 말만 한다거나 등등은 하지 말아야한다.
모델러의 Presentation 능력이 왜 필요할지 다시 한번 생각해봐야한다. 프로젝트에 어떤 방법론이 적절하거나, 어떤 도구가 필요하거나 하면 설득해야지 않겠는가? 그리고 분석/설계 등의 표준을 정의했다면 이를 효과적으로 여러 이해관계자들에게 전달해야지 않겠는가?
강의 역량
반드시 필요한 건 아니지만 강의도 할 수 있으면 좋겠다. 과정개발에 참여하여 교재도 만들고 직접 강의까지 할 수 있다면 더욱 좋겠지만, 최소한 강의라도하면 좋겠다. 대부분의 사람들은 강사로 나서기를 꺼린다. 누구를 가르칠 때 더 많이 배운다는 말이 있는 것처럼 교재를 만들면서, 강의를 준비하면서 정말 많이 배울 수 있다.
나도 몇 년 전 우연한 기회에 선배의 권유에 응답하면서 강의를 하게되었다. 처음에는 당연히 떨렸고, 무엇을 이야기해야할지 몰라서 슬라이드와 교재를 맞춰보면서 체크하고 어떤말을 해야할지 교재에 빼곡히 적었다. 내 딴에는 재밌게도 해보려고 농담아닌 농담도 어디서 하면 좋을지 교재에 적어두고 어색하게 했던 기억이 난다. 강의평가도 신경쓰면서 꼼꼼히 읽었다. 강의 준비를 위해 교재 여러번 읽고 관련된 자료도 찾아 참고자료도 만들어서 교재 슬라이드 중간중간에 부연설명도 넣었다. 강의 시간을 넘겨서 준비한 걸 다 못하기도 하고, 너무 빨리 끝나서 민망하기도 했었다.
하지만 몇년에 걸쳐 강의 경험이 쌓이면서 이제는 당황하지 않는다. 강의평가나 설문에 구애 받지 않고 나의 경험과 하고 싶은 이야기를 편하게 한다. 물론 때론 말의 스텝도 꼬이고 흥분도 할때도 있고, 민망할 때도 있지만, 나의 경험을 정리해둔 슬라이드만 가지고 있다면 괜찮다. 낯짝이 많이 두꺼워졌다.
예전 대학 학부 수업때 박사과정의 어떤 선배가 했던 말이 생각난다. Presentation 을 포함한 수업이었는데 나도 그렇고 다들 Presentation이 어렵다고 어떻게 잘 하냐고 질문했더니 이렇게 조언을 해주었다.
"지금 발표하는 이 슬라이는 누가 만들었는가?
네가 만든것 아닌가?
그러면 지금 발표하는 이 슬라이드는 누가 제일 잘 아는가?
네가 고민하고 직접 만든 슬라이드라면 네가 제일 잘 아는것 아닌가?
그런데 왜 두려워하는가?
직접 만든 자료를 발표하는 지금 이순간 만큼은 네가 제일 전문가다.
그러니 자신있게해라."
강의할 기회가 온다면 일단 손 들어라. 어떻게든 시작하는게 중요하다. 만약 없다면 일부러 만들어서라도 한번 해봐라. 처음에는 당연히 떨리고 부끄럽고 부족할수 있지만 하다보면 여러방면으로 성장하는 본인 모습을 보게될 것이다.
도구 개발 역량
'강의' 처럼 이것도 꼭 필요한 역량은 아니지만 도구 개발 또는 Customizing 능력까지 갖추고 있다면 더욱 훌륭한 모델러가 될 것이다.
설계자가 개발, 즉 코딩을 할 줄 모른다면 어떻게될까? 아니, 코딩하는 개발을 할 줄 모른다면 설계를 할 수는 있을까? 한줄한줄 세부적인 코딩까지는 모른다 하더라도 당연히 소스를 보고, 검토하고, 필요한 경우 본인도 간단하게라도 추가/변경할 수 있는 능력이 있어야 또는 과거에 유사한 개발 경험을 가지고 있어야 어떻게 개발할지 가이드하는 '설계'를 할 수 있지 않을까? 그러한 개발경험과 코드를 읽을줄도 모르는 사람이 어떻게 설계를 한단 말인가?
도구 개발도 이와 유사하다. ERD 또는 UML 등 내가 사용하는 모델링 도구에 대한 이해도 없고 Customizing이 가능은 한지, 사용하는데 얼마나 공수가 드는지 등에 대해 모른다면 어떻게 도구 관련해서 제안하고 가이드할 것인가? MDA/MDD Engineer 없는 경우도 많고 있다 하더라도 MDA/MDD Engineer 에만 의존하면 이상하지 않는가?
필요한 도구를 직접 만들거나, 아이디어를 제안하거나, 기존 제품을 직접 Customizing 할 수 있다면 더없이 좋겠다.