해당 글은 일반적인 리스크 관리의 의미인 RM(Risk Management) 과는 다른 직무상 용어에 대한 설명 입니다.
10 여년 넘게 개발자로 일하다 보면 업무 협의중에 구석에 조용이 않아 있다가 이런 이야기를 툭하고 던지는 사람이 꼭 있었습니다.
"그게 왜 안돼요? 그냥 해줘요. 이거랑 저거랑 엮으면 금방 되는일 아닌가?". 뭐 이런 말들이 사실 개발자를 효과적으로 빡치게 만드는 화법인데 그럴 경우 "아 놔 이 생퀴 그럼 니가 해보시든지" 3, 4년 전만 해도 그랬듯이(아내의 표현대로 AB형 답게 직설적으로) 톡톡 쏘아주고 싶은 말들이 목구멍 바로 밑에까지 올라오지만, 요즘은 숨 한번 꾹 참고 왜 쉽게 될수 없는지 이유를 차분히 설명을 해주려 노력합니다.
뭐 예전에는 기술적이나 상세하게 업무를 파고들며 설명을 해보았지만 그럴 경우에 보통 이런 말 생각없이 던지는 유형들은 대부분 눈이 살짝 풀리며 딴 생각을 하는 경우가 많았습니다. 어느 정도 짠밥 좀 먹은 요즘은 그냥 차분하게 사례를 들어 설명해 줍니다.
출처 : pixbay 무료이미지
"M대리야, 저번에 K사 거래건 가져올거라고 개발 준비해야 한다고 호언장담 하더니 아직도 계약 안됐지?"
"아니 그 얘긴 지금 왜 해요? 거긴 B사와 이미 오래 거래중이라 생각보다 관계가 깊더라구요. 게다가 담당자인 A가 우리회사 안티여서 진행이 잘 안되고요 어쩌구..."
"그게 왜 안돼? 그냥 그 담당자 A랑 술 한번 먹고 협상 좀 하면 금방 계약 따는거 아냐?"
"아니 그게!!! 그렇게 말처럼 쉬운게 아니에요!!!"
"내 말이...."
".........."
아마도 제 친한 지인이 말했듯 반대로 영업 업무를 하는 사람을 가장 빡치게 하는 경우는 되지도 않은 갑질 하는 상대를 만나거나 위에 예시 처럼 이런 말 툭던지는 사람입니다. "영업 그까이거 술 한잔 먹고 노래방 가서 노래좀 부르고 좀 구워 삶으면 되는거 아님?" 사실 이런 편견을 가진 사람들이 제 주변에도 꽤나 있었습니다.
제가 사회에서 겪은 수 많은 사람들 중 대부분이 자기가 하고 있는 일이 가장 힘들고 어렵거나 중요하다고 생각하는 사람은 상당히 많습니다. 물론 저 역시 거기에서 벗어나지 못합니다. 그냥 그게 아마도 자연스러운 사람의 본성인가 봅니다. 내가 다녀온 군대가 대한민국에서 가장 빡센 부대이고 내가 하는 일이 젤 중요하고 어려운 일인 법이니까요. 다만 문제는 내가 하는건 다 중요하고 어려운 일이지만 상대가 하는건 개나 소나 아무나 할 수 있는 땅짚고 헤엄치기로 생각하는 경우가 문제인것 같습니다.
개발자가 무엇인가를 개발 하려는 경우, 보통 개발 요구 사항을 가진 현업 담당자 A와 개발자 B가 있습니다. 개인적인 생각에 A와 B는 같은 공간에 있어도 안드로메다만큼 먼 각자의 정신세계와 같은 한국어라도 실상은 완전히 다른 언어를 구사하는 경우가 많다고 생각합니다. (누가 더 낫다 이런 개념이 아닌 그냥 단순히 직무나 서로의 환경에 따른 차이 입니다.) 그러다 보니 대부분의 경우 A는 자신이 원하는 바를 자신만이 이해하는 언어로 표현하거나, 사실 자신이 원하는 부분이 전산적으로 뭘 해주야 하는지는 정확히 잘 모르는 경우도 많습니다.
B는 또 자신만의 경험에 입각해서 A의 요구를 오인하거나 혹은 자신만의 개발자 언어로 번역해 알아 듣습니다. 그러다 보니 나중에 결과물이 나오면 A는 자신이 원한게 아니라고 투덜거리고 B는 원하는 요건대로 만들어 줬는데 왜 딴소리 하냐며 샐쭉해 집니다. 이런 경우에 A의 말을 이해하고 좀더 깊이 분석해서 A가 원하는 부분을 하려면 요구 사항외에도 추가적으로 고려해야 할 부분을 찾아내거나 A가 표현하지 않은 부분까지도 검토한 뒤, 개발자에게는 개발자의 언어로 이러이러한 개발이 필요하다라고 짚어 주는 사람이 필요합니다.
이렇게 서로 다른 이 둘 사이를 이어 주는 사람이 보통 기획자라 부르는 사람들 입니다. 때로는 RM(Relationship Manager) 이라는 명칭을 가진 관리 업무로 변신중인 시니어 개발자가 그 역할을 겸하는 경우도 많습니다.
사실 국내에서는 기획과 영업의 경계가 상당히 큰 대기업이 큰 조직이 아니면 꽤 모호합니다. 제가 근무했던 금융, 결제와 관련된 회사들의 환경에서는 영업이나 기획팀에 더 가까운 커리어를 가진 경우는 보통 기획으로 불리고, 개발자가 어느 정도 기획의 영역으로 나아가거나, 업무와 인력을 조율하는 업무를 주로 하는 경우에 RM 으로 불리웠습니다.
어느쪽이든 오랜 업무 경험으로 양쪽의 언어를 이해하게된 통역사와 같은 사람이랄까요? 각자 한발씩 더 나아가서 자기 분야 외에도 개발을 좀 더 이해하게 된 사람이거나 개발자지만 영업이나 지원을 좀 더 이해하게 된 사람 입니다. 뭐 사실 근무하는 환경마다 조금씩은 다른 의미로 쓰이거나 완전히 다른뜻으로 지칭되기도 하는것 같습니다.
RM의 역활은 내부에서는 통역사일 뿐만 아니라 대외적으로는 종종 정보를 한곳에 집중시켜 전체적인 부분에 대해 조율하고 판단하는 역활도 합니다. 서로 다른 회사가 공동 작업을 하는 경우 때때로 많은 인원간의 커뮤니케이션이 필요 한데 예를 들면 서로 B2B 제휴를 하려면 RM 역활이 없다면 비즈니스 로직 개발자, 인터페이스 개발자, 네트워크 담당자, 배치 개발자 등 다양한 개발자 들이 상대 회사의 각 담당자와 각개 격파 방식으로 일을 진행시켜야 하는데 인원이 많아질수록 결국 전체적인 일이 산으로 가는 경우가 허다합니다.
이럴 경우 보통 각사의 입장이나 상황을 파악하고 집약시켜 1:1로 정의해서 대화하는 채널이 필요합니다. 예전에는 이런 일을 하는 사람들을 Key Man으로 여기기도 했습니다.
좀더 규모가 큰 프로젝트라면 내부라도 각 분야의 전문가 들로 더 많은 매니저,리더가 구성됩니다.
일반적 업무에서는 개발 리더의 위치가 RM 과 비슷 할 듯 합니다.
이미지 출처 : Flickr 재사용 가능 권한
개인적으로는 위에서 말한 개념으로 비교하자면 과거에는 기획과 일하는것 보다는 RM과 일하는게 훨씬 더 편했습니다. 사실 국내의 기획이란 직무는 오랜 비지니스 경험이 있고 개발자를 상대했던 사람이기 보다는 사원때 부터 기획일만 했던 사람이 다수이고 아무래도 RM은 대개의 경우 개발쪽 커리어를 가졌던 사람이 기획업무로 나아간 경우다 보니 개발 부분에 대한 이해도가 높고 제 자신 부터가 개발자이기 때문에 커뮤니케이션이 편하기 때문일지도 모릅니다.
물론 기획자 중에도 개발에 대한 이해력이 높고 오랜 경험으로 개발자와 대화하는 법을 충분히 익힌 사람들도 많았습니다. 이 기획자 또는 RM(이후 의미에 관계 없이 모두 RM이라 부르겠습니다.)은 Relationship Manager의 약자로 말 그대로 사람간의 관계와 커뮤니케이션을 조율해주는 관리자 입니다. 개인적으로는 이 중간의 RM이 어떤 사람인가에 따라, 엄청난 규모의 개발 건이라도 칼 퇴근하며 여유있게 개발 할수 있는 경우와 소소한 개발건 인데도 매일 같이 야근하며 자잘한 수정을 하며 스트레스를 받은적도 있습니다.
최근에 저는 직접적인 개발 업무를 수행하기 보다는 각종 업무 협의에 참석하고 개발자들에게 개발업무를 지시하고 일정을 조율하거나 진척 사항을 체크하는 비중이 더 많아지고 있습니다. 그렇지만 아직까지는 완전히 RM의 단계까지 나아간것은 아니고 일반적으로 개발 부서의 흔히 시니어 개발자들이 많이 하는 일들이라고 할 수 있습니다.
그런데 앞서 이야기 했듯 이 Relationship Manager라는 역활은 과거와는 달리 점점 더 복잡해지는 IT와 연계된 업무들과 직무의 분화로 매우 중요한 역활이 되어가고 있습니다. 사실 막 시작한 스타트업이라면 항상 곁에서 부대끼는 사람들간이기 때문에 때때로 급하면 영업이 DB서버를 리스타트(응? 했지만 실제로 있었던 일 입니다.) 하기도 하고 개발자가 영업도 하는 등 서로간의 친밀감과 업무 이해도가 꽤나 높아서 따로 RM이 필요가 없을 수도 있겠지만 금융권이나 대기업, 중견기업과 같이 조직이 커지고 분화되는 경우는 그런 접점을 가져가기가 점차 힘들어 집니다.
실제 현업이나 지원을 담당하는 사람들의 경우 IT를 전혀 모르거나 이해하지 못하는 경우도 많아지고 또한 개발자 역시 현업의 현실을 전혀 모르고 사무실에만 있으면서 현장에서는 전혀 원하지도 않는 개발 결과물을 만들고 있는 경우도 종종 발생합니다.
결국 개발을 진행하는 일이란 다른 모든 회사일과 공동작업이 대개 그렇듯 어떤것을 원하는 자와 그 원하는 것을 해결해 주려 하는 사람들간의 협상과 커뮤니케이션의 반복 입니다.
이러한 것을 중간에 선 RM들의 능력이 좋고 예술적인 조율 능력이 있다면 자연스럽게 모든것이 다 만족하고 좋은 상황이 될 것이고 그렇지 않다면 그저 중간에 낀 방해물로 전락 할 수도 있습니다. 국내에서는 안타깝지만 이 RM이 간혹 개발자를 공급하는 하청 업체를 속된 표현으로 잘 갈구고, 조련하는 사람을 지칭하는 경우도 많습니다. 실제로 매니저란 직함으로 불리는 이들을 현장에서 겪어본 경험담은 과거 S모 카드사의 경우 그 회사의 RM들은 상대사의 개발자가 하는 말들을 대부분 이해하고 자사의 개발자, 업무 담당자에게 명확하게 전달되는 경우를 본 적이 있었습니다.
해당 카드사의 승인처리 개발자, 배치 개발자, 인터페이스 개발자, 네트어크 담당자등 여러 개발자와 IT 지원담당과 직접 통화하거나 각각 이야기 할 필요도 없었고 모든것이 일원화된 RM과의 커뮤니케이션으로 수렴되어 정확하게 전달되다 보니 꽤 크고 복잡한 제휴업무 였지만 원할하게 착착 진행되었던 좋은 경험이 있습니다. 반면 통신업을 하는 다른 S모 사의 제휴를 진행했던 경우는 중간의 RM 역활을 수행한 사람이 그다지 권한도 없고 사업 경험도 없는 사람을 얼굴 마담 수준으로 내세운 경우다 보니 IT나 개발 사항 뿐만 아니라 진행해야 할 기본 업무도 다 이해하지 못하다 보니 어느 순간 각자의 말을 중간에서 (그것도 왜곡해서) 중계만 하는 역할만 해서 아까운 시간만 까먹게 만들었습니다.
커뮤니케이션을 하다가 결국은 답답해진 각 사 개발자끼리가 직접 대화를 원하게 된다거나 때로는 서로 다른 이야기가 전달되고 모호한 의사를 전달해서 각자가 좋을대로만 해석하도록 만든것이 가장 큰 문제 였습니다. 그러다 보니 마지막까지 서로 아귀가 맞지 않는 방향으로 개발하고 나중에 조율을 상당히 어렵게 만드는 스트레스를 안겨주었던 경험도 있습니다.
복잡한 현대의 IT 개발 환경에서 개발자도 더 이상 혼자 코딩만 잘하면 되는 시대가 아니게 되었습니다.
커뮤니케이션 능력이 떨어지는 개발자는 오히려 골치덩이가 될수 있습니다. 사실 회사일이란게 대부분 팀워크 입니다.
이미지 출처 : pixbay 무료이미지
오늘은 이처럼 IT 개발직군에서 현업 직무 담당자와 IT를 연결하는 역활을 하는 사람들을 지칭하는 RM(Relationship Manager)라는 직군에 대해서 가볍게 이야기 해 보았습니다. 그러고 보니 꼭 개발 직군은 아니라도 모든 공동 작업이 필요한 일들에 대해서 사람들 간의 일들을 조율하는 매니저가 존재하는것 같습니다.
