영업맨의 요구에 '노(No)'라고 말하는 개발자_제니퍼소프트

 

프로젝트 입찰에 바쁜 영업맨 A씨가 오후 늦게 회사로 돌아왔습니다. 그리고 이렇게 말합니다.

 "고객이 이런 기능을 넣어달라고 해요. 경쟁사에는 있는 건데, 우리는 없답니다. 이번 프로젝트 따려면 이거 들어가야 합니다. 서둘러 주세요."

개발자 입장에서 두 가지 대답을 할 수 있을 것입니다.

"그렇게 하죠"와 "그건 안되겠는데요"

요즘처럼 하수상한 시절에, 영업맨의 이런 요청에 노(No)라고 말하기가 쉬운 일은 아닙니다. 특히 프로젝트를 따고 못 따고 먹고 사는 문제라도 걸려있다면 '노'라는 대답, 차마 하기 어렵습니다. 그래도 노라고 하는 개발자라면 아마 대단한 강심장의 소유자일 것입니다.

영업맨의 요청에 '노'라고 말하는 개발자. 어떤 생각이 드십니까? 나름 철학이 있어 보이나요, 아니면 앞뒤가 꽝 막힌 융통성 없는 사람이라 생각하는지요?

한 건이 급한 영업맨들이라면.. 자기 요구에 '노'라고 하는 개발자들은 기피대상 1호일 것입니다. 한대 때려 주고픈 생각이 절로 들 겁니다. 회사를 나가줬으면 하는 마음도 들겠죠.  늘 그렇듯 상대방의 입장이 되어보지 않고는 절대 그 상황을 이해할 수 없는 상대적인 괴리감일겁니다. 지인들로부터 종종 이런 얘기를 듣습니다.  개발자랑 대화하기 정말로 힘들다고. 어느 정도는 현실입니다.
 
'화성에서 온 기획자, 금성에서 온 개발자'란 말이 여전히 먹혀 들고 있습니다. 

말 안 듣는 개발자, 얼마나 답답할까요? 입장 바꿔 생각하면 이해되는 측면도 있습니다. 그러나 오랫동안 개발자와 아키텍트로 지내면서 깨달은 것 중 하나가 있습니다. 영업맨들 얘기 다 들어 줬다가는 제품이 누더기가 될 가능성이 매우 높다는 것입니다. 멀쩡하던 제품이 누더기가 되는 장면, 정말이지 여러 번 봤습니다.

물론 영업맨들의 얘기를 다 무시해서는 안되죠. 시장 전반적으로 요구되는 기술이나 기능이라면 당연히 반영해야 합니다. 이것도 무시하는 개발자라면 앞뒤가 꽉 막혔다 소리 들어도 할 말 없습니다. 내보내야겠죠.

그러나 특정 프로젝트 때문에 제품에 손을 대는 것은 아무리 생각해도 아닌 것 같습니다. 한 두 번 들어주다 보면 제품 망가지는 것 금방입니다. 관성의 법칙을 사람 사는 일에 적용하면 '한번 시작한 일은 되돌리 어렵다'는 의미도 있을 것입니다. 때문에 후배들에게도 영 아니다 싶으면 마음 단단히 먹고 영업맨들에게 'No'라고 말하라고 부추깁니다.

 
제 얘기 한번 해보겠습니다. 개발자 입장에서 제품을 만들 때는 우선순위가 있습니다.

얼마 전 발표한 제니퍼4.0도 마찬가지입니다. 제품 개발을 이끌면서 영업사원들이 원하는 스펙을 무조건 맞춰주지는 않았습니다. 경쟁사 스펙이라도 해도 시장이 필요로 하는 것이 아니라면 과감하게 배제했습니다. 

영업맨들이 "이번 프로젝트 따려면 이거 있어야 한다"고 얘기하면 이렇게 말하고 넘어갔습니다. "제대로 영업을 하지 않은 겁니다." 

무지 거만해 보일 수도 있겠네요. 그래도 저는 이게 맞다고 생각합니다. 특정 프로젝트를 위해 제품의 틀을 흔들 수는 없는 겁니다. 

물론 시장이 요구하는 것들은 포함시킵니다. 제니퍼4.0에 추가된 다이내믹 프로파일링 기능은 바로 이렇게 나왔습니다. 다이내믹 프로파일링은 특정 프로젝트를 위한 것이 결코 아닙니다.

대용량을 소화하는 기능도 마찬가지입니다. 

제니퍼는 웹기반입니다. 사실 클라이언트서버(CS) 환경으로 개발하면 솔직히 할게 더 많습니다. 그래도 제니퍼는 웹환경을 선택했습니다. 지금보다는 앞으로를 봤을 때 얻을게 더 많다는 판단에서입니다. 웹이 발전하고 있는 만큼, 제니퍼가 얻을 것들은 점점 더 늘어날 것입니다. 

개발을 하면서 적지 않은 시행착오를 겪게 됩니다. 그러다 보면 의미 있는 깨달음을 얻을 때도 있습니다. 그 중 하나가 제품의 뼈대라는 것은 시간이 지나도 초기 버전에서 크게 변하지 않는다는 겁니다. 제품이 계속 발전하더라도 말이죠.

이런 경우가 있습니다. 

좋은 아이디어로 제품을 개발했고 초반 반응도 괜찮습니다. 그러나 시간이 지나면서 경쟁 제품과 비교 당하기 시작합니다. 내부에서는 '우리도 바뀌어야 한다'는 말이 쏟아집니다. 개발자들도 슬슬 제품을 제대로 한번 뒤집고 싶어집니다. 초심은 이렇게 허무하게 무너집니다. 

결국, 바꿨습니다. 어떻게 됐을까요? 희망대로 최고의 제품이 나왔을까요? 그럴 가능성은 낮다는 것이 제 생각입니다.  

조엘 스폴스키가 쓴 <조엘 온 소프트웨어>란 책이 있습니다. 저자는 넷스케이프가 브라우저 시장에서 망가진 이유를 놓고 무턱대고 새로 개발하려다 헛발질을 했기 때문이란 의견을 책 전반에 걸쳐 피력하고 있습니다.

 저, 사실 그거보고 충격 먹었습니다. 가만히 생각해보니 맞는 말 같더라고요.  앞으로는 저도 절대로 제품을 뒤집지 않겠다는 비장한(?) 결심까지 하게 되었습니다. 제니퍼4.0에 2.5버전에 있던 코드들이 꽤 남아있는 이유입니다.

결국 이런 얘기입니다. 새로 만드는 것보다는 있는 것을 고쳐나가는 것이 낫다는 겁니다. 원판 자체가 영 아니라면 할 말 없습니다. 다시 만들어야죠. 그렇지만 '남의 떡이 더 커 보인다'에 빠져들면 안됩니다. 알고 보면  '남의 떡'이 더 작을 때도 많습니다. 외형은 변할 수 있을 테지만, 그 기본 사상과 근본은 늘 제품 속에 살아있어야 합니다.

다시 한 번 제니퍼에 대한 근본적 관점을 고수해야 한다고 마음먹습니다.

요즘에는 많은 APM 기능들이 인터넷에 올라와 있습니다. 누구든지 마음만 먹으면 만들 수 있을 정도입니다. 중요한 것은 각종 기술들을 어떤 관점을 갖고 조직할 것이냐 하는 것입니다. 철학이라고 말한다면 너무 거룩한 것 같고, 저는 제품 개발에도 관점이 필요하다고 생각합니다. 그래야 롱런 할 수 있다고 믿습니다. 

제품에 대한 관점이란 것이 딱 이거다라고 설명하기는 어렵습니다. 그래도 고객들이 원하는 스펙을 다 넣어주는 것이 능사는 아닌 것 같습니다.

저의 생각이 틀릴 수도 있습니다.  경험을 갖고 말하고 있을 뿐입니다.

요즘 SW들이 점점 더 '그게 그거 같아진다'는 말이 많이 들립니다. 무조건 튀기만 해서는 안되겠지만 시장에서 먹혀들 수 있는 자신만의 독특한 그 무엇, 특정 기능이 아니라 제품의 뼈대 역할을 하는 차별화된 그 무엇을 갖고 있다면 개발자로서 자부심을 느낄 수 있지 않을까요?

저는 이것을 관점이라 부르겠습니다.

 

제니퍼(JENNIFER)에 대한 나만의 특별한 관점(이 원칙만은 절대 바꾸지 않는다..)

1.     APM에 있어 가장 중요한 것은 문제해결이다. 문제를 해결하기 위해서는 문제를 한 눈에 볼 수(모니터링) 있어야 한다. (늘 그렇듯 오류는 문제를 이해하지 못하고 직관적으로 볼 수 없는 것으로부터 출발한다. 제니퍼는 애플리케이션의 문제를 해결하는 제품이나 따라서 애플리이케이션의 문제를 잘 볼 수 있게 하는 것이 제일 먼저다.)

 

2.     문제해결의 기본은 Divide and Conquer 이다 혹은 Top-Down 이다. (가설과 검증을 통해 전체에서부터 부분으로 문제를 접근해 가야 한다.  모니터링도 마찬가지이다. 문제를 빠르고 상세하게 분할해서 접근할 수 있도록 데이터를 보여주는 툴이 좋은 툴이다.  수 만의 경우의 데이터를 나열하고 운영자에게 찾아서 봐라.. 하는 것은 말이 안된다..  그런데 BMT할 때는 꼭 무슨 데이터를 조회할 수 있는지부터 묻는다. 늘 그렇듯 문제에 어떻게 접근하는지 물어보는 RFP는 본적이 없다..

 

3.     APM의 핵심은 문제 해결이며 문제해결은 곧 시간이다. 시스템의 장애는 시간적 여유가 없다. 아침에 문제가 나면 점심시간에 가서 30분만에 설치하고 10분 정도 확인하고 오후에는 모니터링 할 수 있어야 한다. 장애를 위해 트라이얼을 하는데 벤더가 H/W박스를 들고 들어 간다? 어불성설이다. 제니퍼의 생명은 시간이다.

 

4.     APM에게 있어 일관된 모니터링 체계는 매우 중요하다. 이러한 컨셉을 바탕으로 제니퍼는 시스템 용량 산정에 결정적 자료를 제공할 것이며 쓸 수 있는 APM인 포인트 솔루션으로 승부할 것이다. 개발->테스트->운영->다시 개발 등으로 이어지는 과정에서 일관된 용량 산정을 위한 값들을 추적해야 함에도 불구하고 계속해서 모니터링 컨셉이 바뀌면 소용이 없다.  쉽지 않겠지만 제니퍼가 갖고 있는 일관된 모니터링 체계는 변함이 없을 것이다. 모니터링을 위해 긴 개발프로젝트를 한다는 건 매우 소모적인 일이다.

 

문제없는 시스템이 나온다면 제니퍼는 어떠한 역할을 하게 될까라고 스스로 되묻게 된다. 그렇다면 제니퍼를 살 필요도, 제니퍼가 존재 할 이유가 없어지게 될 것이다. 그러나 다행스럽게도(?) 가까운 미래 안에 문제 없는 시스템은 없을 것으로 보인다. 단지 문제가 보이지 않는 시스템이 있을 뿐이겠지만. 제품으로의 제니퍼는 자바와 운명을 같이 하게 될 것이다. 그렇지만 제니퍼가 갖고 있는 모니터링에 대한 컨셉은 자바보다 오래 갈 것이라고 믿는다.