내가 개발자를 먹여 살린다
Posted 2012/02/07 12:46출처: http://i-guacu.com/3012
십여년 가까이 기술 영업직(기술 마케터)을 하다 다른 업종으로 최근 업을 바꾼 사람을 만났다. 자신에게 가장 큰 영향을 준 멘토이자 선배 기술 영업 사원에 대한 이야기를 하며 감명 깊었던 격언을 전했다,
"내가 개발자를 먹여 살린다는 자세로 영업을 해야 한다"
좋은 말이다. 그런데 문제는 그 뒤에 이어진 이야기였다. 고객사를 만나서 열심히 설명하고 회사로 돌아와 개발자에게 개발 사안을 이야기하면서 개발자들과 많이 싸웠고 참 힘들었다는 것이다. 그런 어려운 상황을 극복하며 개발자들의 몰이해에도 불구하고 영업 실적을 쌓아왔고 그것이 자랑스럽다고 말했다. 답답한 개발자들에 대한 이야기와 답답한 상황을 참으며 이해하며 그들을 먹여 살리기 위해 열심히 뛰어 다녔다는 이야기를 듣고 있자니 괜히 화가 났다.
누가 누굴 먹여 살리나?
모든 마케터가 그런 것은 아니지만 꽤 많은 마케터들, 특히 기술 영업을 하는 마케터들이 전가의 보도처럼 사용하는 표현이 있다. '마케터가 개발자를 먹여 살린다'는 것이 대표적이고 이와 비슷한 또 다른 표현도 있다,
"아무리 잘 만들어진 상품도 못 팔면 의미가 없다"
특히 솔루션 영업 혹은 SI 영업을 하는 마케터들은 이런 이야기를 참 쉽게 하는 것 같다. 이런 이야기를 하는 마케터들의 공통점 중 하나는 고객사와 만나면서 자신이 개발자인 것처럼 솔루션의 스펙을 이리저리 뜯어 고치고 심지어 개발 이슈까지 정의해 버린다는 것이다. 예컨데 이메일 솔루션을 판매하러 간 마케터에게 고객사가 이런 질문을 한다,
"페이스북에 있는 것처럼 '좋아요' 버튼을 추가하는 게 가능한가요?"
고객사의 이런 질문에 대해 마케터는 어떤 대답을 할까? 그건 단순한 기능이 아닙니다. 제대로 개발을 하려면 기대하는 것 이상의 큰 비용이 발생합니다... 라고 대답할까? 회사를 먹여 살리는 것이 자신의 가장 중요한 임무라고 믿는 마케터들은 이렇게 대답하곤 한다,
"그 정도는 쉽게 구현 가능합니다. 자 그럼 계약을..."
회사에 돌아온 마케터는 보스에게 진행 상황을 보고 한다. 아마 조만간 계약이 될 것 같다고 보고하자 보스는 흐뭇한 미소를 지으며 회의를 소집한다. 계약 진행 상황이 보고되고 말미에 간단하게 혹은 지나치듯이 고객사가 요구하는 몇 가지 추가 개발 사항에 대해 언급한다. 그러자 개발팀장이 언짢은 표정으로 이의를 제기한다,
"그 버튼을 추가하는 게 쉬운 일이 아닙니다. 고객사의 profile 구조가 어떻게 되어 있는 지 알 수 없고, 새로운 기능과 기존 기능이 어떻게 조합될 지 물어 보셨나요? 현재 진행 중인 프로젝트 일정과 자원이 부족할 수도 있습니다..."
그러나 그런 문제 제기는 그리 중요하지 않은 것으로 치부된다. 고객사가 요구한 것은 그냥 '좋아요' 버튼 정도인데 왜 그렇게 깊이 생각하느냐고 핀잔을 듣는 경우도 있다. 개발팀장은 다시 이의를 제기한다,
"고객사가 분명 '페이스북의 좋아요 버튼'이라고 했다면서요? 엄지 손가락 들고 있는 이미지를 붙여 달라고 요구한 것은 아닐 것 아닙니까. 고객사가 요구하는 구체적인 스펙이 어떻게 되나요?"
이쯤이면 마케터도 열 받는다. 도대체 이 개발자는 돈을 벌자는 소린지 계약을 엎어 버리자는 소리인지 알 수 없다. 회사의 요즘 영업 상황이나 캐시 플로우는 알고 저런 소리를 하는 건가 싶다. 저런 개발자를 믿고 영업을 계속 해야 하는 건지 답답하기만 하다. 마침 보스가 그런 답답한 회의를 빨리 종결시키는 한 마디를 한다,
"일단 계약 협의를 진행하는 과정에서 나온 거니까 너무 신경쓰지 말지 그래?"
순간 개발팀장은 회사의 상황은 고려치 않고 팀의 입장만 내세우는 이기주의자로 취급받는 느낌을 받는다. 뭔가 암울한 느낌이 분명히 있지만 더 이의를 제기하는 것은 상황을 악화시킬 것 같아 입을 다문다. 그리고 천천히 어둠의 포스가 입을 벌리며 다가옴을 느낀다.
배보다 더 큰 배꼽
이런 일은 계약 협의가 진행되는 중 자주 발생하고 마케터와 개발자의 충돌도 자주 발생한다. 마케터는 답답하다. 고객사와 협의하는 과정에서 고객사의 상황을 깊이 이해하게 될수록 고객사가 요구하는 것이 무리한 것도 아닌데 회사로 돌아와 개발자와 이야기를 할 때마다 "그것이 안되는 108가지 이유"를 이야기하니 계약 협의를 진행하기 너무 힘들다. 그러나 개발자도 미칠 지경이다. 기술 영업을 하는 마케터가 솔루션을 팔러 간 것인지 없는 솔루션을 개발하러 간 것인지 이해하기 힘들기 때문이다.
현재 개발된 이메일 솔루션은 그것 자체로 무결성을 갖기 위해 많은 이슈를 해결해 왔고 안정적인 버전이다. 고객사가 요구하는 부가적인 기능은 또 다른 솔루션을 개발해야 하는 것이지 현재 솔루션에 추가될 기능은 아니다. 마케터가 고객사의 요구라고 갖고 오는 개발 이슈를 보면 마치 현재 솔루션을 끼워 파는 것처럼 보인다. 어느 정도 현실적 상황을 이해하고 개발할 수도 있겠지만 정도가 지나치다. 이런 식으로 나가면 기존 솔루션을 판매하는 것보다 새로운 시스템을 구축하는 상황이 된다. 배보다 배꼽이 더 커지는 것이다.
영업 회의는 점차 미궁으로 빠져 든다. 이 즈음에서 보스가 뭔가 조정을 해 줘야 할텐데 그가 지금 당장 신경 쓰는 것은 며칠 뒤로 다가 온 급여일이고 아직 들어오지 않은 계약 잔금과 통장 잔액이다. 마케터가 갖고 오는 새로운 고객과 계약 진행 보고는 신나는 일이지만 현실적인 문제를 제기하는 개발팀의 상황도 이해 못하는 것은 아니다. 둘이 좀 협력하면서 일하면 좋을텐데 중간에 끼어 매우 힘들다. 어쨌든 이 프로젝트는 해야 한다. 바야흐로 프로젝트 지옥문이 열리고 있다.
이상적인 상황
웹기반 소프트웨어 개발사인 <37SIGNALS>가 어떤 식으로 소프트웨어를 개발하고 판매하고 있는 가를 보면 이런 문제에 대한 대답을 찾을 수 있다. 그들은 "우리에게 필요한 소프트웨어를 만들어 판다"고 말하고 있다. 또한 고객사가 원하는 모든 기능을 넣은 소프트웨어는 만들 생각이 없다고 단언하고 있다. 그들은 단순하지만 충분히 훌륭하게 동작하는 소프트웨어를 만들어 고객들을 감동시키고자 한다.
기술 영업을 하는 마케터들은 고객사와 계약을 성공시키지 위해 경쟁사보다 자사의 제품이 훨씬 낫다는 것을 강조한다. 그러나 마케터가 고객을 설득하는 방법으로 제품 기능 리스트를 확대시키는 것을 선택하게 될 때 회사는 개발 지옥의 나락을 빠지게 된다. <37SIGNALS>은 경쟁사에 비해 우리 회사가 더 많은 기능을 제공할 수 있다고 선전하는 게 매우 멍청한 짓이라고 말한다. 그들은 경쟁사들이 더 많은 기능을 넣은 제품으로 서로 경쟁하고 있을 때 가장 기본적인 기능을 충실히 구현했고 오히려 경쟁사들이 상상도 못할 성과를 거두고 있다. <37SIGNALS>은 진흙탕 싸움을 벌이는 곳에 뛰어드는 대신 자신만의 경쟁 방식을 만들어 고객사를 설득했고 성공했다.
물론 <37SIGNALS>과 같은 회사가 일반적인 것은 아니다. 그들과 같은 개발 방식과 운영 시스템을 구현하고 훌륭한 성과로 연결하는 것은 결코 쉽지 않다. 현실의 우리가 처한 상황은 고객사와 만나서 솔루션의 스펙을 재정의하는 마케터와 그런 마케터를 보며 분노하는 개발자들이 있는 회사일 가능성이 높다. 마케터가 "내가 개발자를 (혹은 회사를) 먹여 살린다"고 단언하는 상황이 기분 나쁠 수는 있지만 그런 마케터가 없는 것보다 있는 것이 훨씬 낫다. 그러나 여전히 거부할 수 없는 사실이 있다. 마케터는 개발자가 아니다.
<37SIGNALS> 정도의 멋진 솔루션을 전 세계적으로 팔아대는 회사는 아니지만 그에 버금갈 정도로 조화롭게 운영되는 몇몇 회사를 알고 있다. 한 소프트웨어 개발사를 방문했을 때 일이다. 대표이사를 기다리며 회사 구경을 하고 있는데 DB 다이어그램을 한참 들여다 보고 있는 사람을 발견할 수 있었다. 개발자인가 싶었는데 나중에 마케팅 회의를 할 때 보니 마케팅 팀장이었다. 그는 개발자로 시작해서 몇 년 동안 기술 영업을 하는 마케터였다. 요즘도 프로그래밍을 하느냐고 묻자 그는 이렇게 대답했다,
"기술 영업을 하기 위해 굳이 코드를 볼 필요는 없다. 그러나 팔려는 제품이 어떻게 상태인지, 어떻게 진화할 지 충분히 알고 있어야 한다. 나는 더 이상 프로그래밍을 하지 않지만 프로그래밍을 이해 하지 않아도 된다는 의미는 아니다."
그는 자신이 회사를 먹여 살린다는 말을 하지 않았다. 이런 마케터가 회사를 먹여 살리는 것은 감사할 뿐이다. 이런 마케터가 개발자를 대상화하지 않는 것은 분명하다. 좋은 마케터가 오직 잘 팔아대는 마케터라고 규정하는 회사가 아님도 분명하다. 협업을 위해 개발 환경을 이해 하려고 노력하는 마케터가 있는 회사에서 무턱대고 반대부터 하는 개발자가 존재할 리 없다.
기술 영업을 하는 마케터는 자신이 자동차 영업을 하는 마케터와 어떤 차이가 있는 지 알고 있어야 할 것이다. 파는 것이 최우선 과제라고 생각하는 마케터와 개발자는 늘 충돌할 수 밖에 없다. 저항하는 개발자는 저항할만한 환경에서 발생한다. 내가 누군가를 먹여 살린다고 생각하는 그 순간, 상대방은 더 이상 파트너가 아니다. 그저 눌러서 이겨야 할 존재일 뿐이다.
한 손에 개발 가능 리스트를 들고 가격 흥정을 하는 마케터야말로 개발자를 죽음의 프로젝트로 몰아 넣는 주범이다. 그런 마케터가 개발자를 먹여 살리고 있다고 떠들고 다니면 참 어이없지 않겠는가.
반응형
'경영,리더십, 성과관리' 카테고리의 다른 글
[경영/리더십] 경쟁은 비용이 많이 드는 경영방식 (0) | 2012.02.14 |
---|---|
[경영/리더십] 효과적 업무 지시와 커뮤니케이션 (0) | 2012.02.09 |
[조직/경영] 유형별로 살펴본 나쁜 상사 대처법 (0) | 2012.01.25 |
[경영/리더십] 안철수연구소 인사팀장이 신입사원에게 해준 말 (0) | 2011.12.28 |
[경영/리더십] 직급별 역할모델 (0) | 2011.11.23 |
댓글