최진호 최진호 Geek

순수 개발자가 CIO에게 외면받는 8가지 이유

2008-09-16 » tech

InfoWorld에서는 최근에 기업에서 IT관련 부서내에서 상호간의 오해와 불신에 관련한 시리즈를 내고있다. “애플리케이션 개발자가 그들의 CIO를 외면하는 9가지 이유”라던지 “CIO가 절대로 되지 않으려하는 개발자들의 8가지 이유”, “CIO가 알아야할 애자일 개발 7가지 요소” 등등 개발자 입장에서 속이 후련할 수도 있고 CIO 입장에선 조금 난처한 이야기를 썼는데 이번에CIO입장에서의 개발자에 대한 이야기를 풀어내었다. 내가 CIO입장이 아니다보니 어떤 부분은 수긍이 가는 반면 어떤 부분은 입장이 다른 것도 있다.

1.개발자는 사업상에 실질적으로 필요한 것을 생각하지 않는다: 기술을 뽐내기만 하지 실제적으로 필요한 것을 가장 빠른 시간 내에 할 생각을 하지 않는다.

  1. 개발자는 고객 관점에서 생각하는 습관이 없다

  2. 개발자는 제품에 어떻게든 깜짝 놀란만한 것을 넣어보려고 한다: CIO가 원하는 것은 안정적인, 표준화된 무언가이다. 최신 기술을 좋아하는 개발자는 상황을 언젠가는 불안하게 만든다.

  3. 개발자는 ROI, TCO 혹은 다른 비즈니스 우선순위를 전혀 생각지 않는다.

  4. 개발자는 IT가치 전달에 소극적이다.

  5. 개발자는 조직에 대한 기술이 부족하다.

  6. 개발자는 협업하여 사고하는 능력이 부족하다.

  7. 개발자는 매니저를 이해하지 못한다. : 때로는 조직의 인력감축과 해외 아웃소싱은 불가피한 것이다.

나 역시 개발자출신이고 지금도 반은 엔지니어의 일을 하고 있지만 가끔 현장을 돌아다니거나 주위의 사람들의 이야기를 듣다보면 심하다 싶게 엔지니어주의가 오히려 비즈니스에 역행하는 경우를 접하게 된다.

개발자는 문제를 해결하기 위해 너무나 고상한 길을 가려한다. 사실 고객이 원하는 것은 단순하고 간단한 것인데 개발자는 그것을 위해 자신의 기술을 뽐내기를 주저하지 않는다.

모전자에서 연구원으로 있는 한 친구의 이야기이다. 연구소에서 6개월짜리 프로젝트를 하느라 자바를 잘하는 업체를 외주로 같이 참여하게 되었다. 웹서비스로 여러 서비스를 연결하는 프로젝트였지만 사실 그렇게 난이도가 높거나 복잡한 것은 아니었다. 문제는 이 외주 업체의 개발자들이 멋진 아키텍처의 오픈소스 프레임워크 신봉자였던 것. 어차피 연구소 입장에서는 연구결과 발표하면 끝이고 변화가능성 및 유지보수에 대한 문제에 대해 고민할 필요가 없는 프로젝트인데도 불구하고 외주업체 개발자는 예리한 칼로 레이어를 나눠대기 시작하고 복잡도를 스스로 증가시켜 버렸다.

너무 훌륭한 개발자는 때로는 제품화에 걸림돌이 되는 경우도 있다. 소규모 IT벤처를 이끌고 있는 어느 사장은 그 회사의 제품을 개발해나가는 과정에서 최근 많은 어려움을 겪고 있다. 문제는 어느 훌륭한 개발자 때문이었다. 사장입장에서는 회사에 돈이 매우 부족하기 때문에 제품의 질은 좀 떨어지더라도 빨리 개발에 성공하여 핵심 아이디어로 무장한 제품화를 통해 시장의 반응을 보고 그 반응에 따라 회사 전략을 세우고자한다. 이를테면 펀딩을 받거나 영업을 강화하거나 제품 개발에 더 투자하거나 함으로써 자금 사정이 좋지 않은 현재의 상황을 빨리 반전시키기를 원한다. 그런데 그 훌륭한 개발자는 너무 완벽한 제품을 처음부터 만드려는 통에 다양한 기반 아키텍처를 만들었다가 부수기를 반복하고 정작 중요한 빠른 제품 완성 일자를 요원하게 만들었던 것이다.

훌륭한 개발자일수록 자기만의 고집에 사로잡혀있는 경우가 많다. 몇년 전에 나는 모 은행에서 진행 중인 프로젝트에 잠깐 참여한 적이 있었다. 내가 참여한 이유는 현재 개발중인 사이트에 장애가 발생하고 심각한 성능저하 현상이 있었기 때문이었다. 내가 JVM 상태를 분석해보니 이것은 운영상황을 고려하지 않은 개발자의 소스코드 때문이었다(사실 거의 대부분의 문제는 개발자의 잘못 짠 소스코드인 경우이다). 하지만 수석 개발자는 핏대를 세워가며 절대로 자기의 잘못일 리가 없다며 호응을 하지 않았다. 우여곡절 끝에 문제의 원인을 스스로 인정할 수 밖에 없게 만들었지만 그때를 생각하면 개발자의 고집이란 게 얼마나 무서운가 다시 한번 생각하게 한다. 사실 이러한 훌륭한 개발자의 고집을 접하는 것은 나의 경우 매우 드문 편이다. 개발자가 아무리 훌륭해도 그들이 보지 못하는 이면은 얼마든지 다양하고 귀를 열어둘 필요가 있다.

여기서 언급하고 있는 개발자들은 멍청한 개발자를 말하는 것은 아니다. 나름대로 개발자의 길에 자긍심을 갖고 있으며 장인정신을 가지고 있는 이들을 말하는 것이다. 이러한 훌륭한 개발자가 멍청한 개발자 10명보다 훨씬 기업에 좋은 이득을 주는 것은 부인할 수 없다. 하지만 그럼에도 불구하고 그들이 CIO나 매니저에게 인정받지 못하는 이유는 무엇인지, 그것에 대해 고민해볼 수 있을 것 같다.

너무 개발자 핀잔만 늘어놓은 것 같아서 멍청한 CIO 및 매니저로 인해 고생하는 개발자들을 위한 재밌는 동영상 하나 올린다.

댓글

^^ · 2008/09/16 15:14

그런 CIO는 그런장인정신을 가진 개발자조차 밑에 둘수 없을듯합니다.

개발자에게 모든것을 요구해봐야.. 할수도없을뿐더러 제대로된 제품이 나올리도 만무합니다.

프로세스별 자기역할만 제대로 처리한다면 글쓴분처럼 모든 책임을 개발자에게 묻는 웃기지도 않은 글을 마치 개발자를 저능아로 몰아가는 똘아이도 나오지않겟지요?

Yozz · 2008/09/16 15:30

흐흐

아비숑 · 2008/09/16 15:51

대부분은 공감하고 인정합니다만…

“사장입장에서는 회사에 돈이 매우 부족하기 때문에 제품의 질은 좀 떨어지더라도 빨리 개발에 성공하여 핵심 아이디어로 무장한 제품화를 통해 시장의 반응을 보고 그 반응에 따라 회사 전략을 세우고자한다. 이를테면 펀딩을 받거나 영업을 강화하거나 제품 개발에 더 투자하거나 함으로써 자금 사정이 좋지 않은 현재의 상황을 빨리 반전시키기를 원한다”

라는 부분에 대해서는 좀.. --;; 이건 시작부터가 잘못된 것이 아닌가 싶습니다… 저런 이유로 급조된 S/W의 경우 나중에 유지보수하기도 힘들뿐더러 개중에는 아키텍트 자체의 문제로 처음부터 다시 시작해야 되는 경우가 발생할 소지가 매우 높지 않을까 싶네요… 실례로 그런 일로 매우 고생하고 있기도 하고요.. --;

Yozz · 2008/09/16 16:03

맞습니다. 그런데 경우에 따라서는 회사입장에서는 아키텍처 자체를 나중에 엎어버리는 한이 있더라도 SW를 급조하여 만들어야만 할 경우도 있습니다. 즉 껍데기만 화려한 제품이라도 만들지 않으면 경쟁사에 기회를 뺐겨버리거나 사업을 아예 접어야하는 경우도 있을겁니다. 하지만 이러한 프로젝트에 개발자들이 선뜻 호응하고 회사입장을 이해해주기를 바라기는 매우 어렵습니다.

초승달과밤배 · 2008/09/16 16:24

개발자라면 프로그램을 보다 예쁘게 만들려는게 당연하겠죠. 아키텍쳐도 최대한 유지보수를 최소화 할수 있는 방향으로 만들고 싶어하구요. 그건 개발자 문제가 아니라 소통의 문제라고 생각되네요. 개발자에게 “유지보수는 거의 필요없으니 걍 최대한 빨리 기능만 되게 해주세요” 라고 요청했는지 의문이네요. 그런 요청이라면 개발자가 아키텍쳐를 생각하고 있진 않을듯하네요.

Vampire · 2008/09/16 19:30

유지 보수는 필요 없으니 최대한 빨리 만들어 주세요! 하고 나서는 유지 보수를 시킨다는게 문제죠…

Yozz · 2008/09/16 21:42

To Vampire: 맞습니다. 개념없는 매니저가 문제이긴 하네요.

나는먼지 · 2008/09/17 09:04

개발자의 자존심도 한몫하겠죠? 이렇게 허접하고 간단하게 만들어버리면 개발자라고 할수 있는가? ㅋㅋ 개발자 다운맛은 테크닉에 있지않나? 하는…

Outsider · 2008/09/17 10:06

솔직히 개발자가 옹고집에 기술지향주의인게 사실이긴 하지만요(그렇지 않은 사람이 더 많은것 같긴 하지만요.) 경험상 보면 CIO쪽에서 개념없는게 더 문제라고 느껴지더군요. 제가 개발자라서 그런지 몰라도요… 말씀하신대로 일정 바빠서 완성도를 낮추고 일단 출시정도는 할수 있는데 문제는 위에서는 그렇게 만들어진 것을 완벽한 완성도인 것 마냥 생각하고 내일까지 요거 추가해.. 이런식으로 나올때는 답답하죠.

Yozz · 2008/09/17 11:23

Outsider: 예 사실 강자는 CIO지 개발자가 아니니까요. 아무리봐도 제 글은 개발자에게 별로 도움되는 글이 아니네요.

미루엘 · 2008/09/17 13:22

지나가다 적습니다.

예로 드신 복잡도를 높이거나, 일정을 못 맞추거나, 아키텍처 설계를 확실하게 못해서 만들었다 지웠다 하는 개발자들은 “훌륭한 개발자”가 아닙니다. “훌륭한 개발자”라면, 적절한 복잡도와 유지보수, 일정, 그에 따른 적절한 아키텍처 설계를 하는 미래를 바라보면서도 일정을 칼같이 준수할 수 있는 개발자 겠지요. 정답은 아니겠지만 전 이러려고 노력합니다. 또 그러는게 일하기도 편합니다. 일정에 끌려다니면 인생이 피곤해집니다. 하지만 이상과 현실의 괴리는 있지요..

제 경험상 문제는 아무리 노력한다 하더라도 “최소한의 기간”이라는 것이 존재하지만 그것마저 인정못하는 관리자들이 문제라고 생각합니다. 개발기간 15일 주면서(워킹데이로 따지면 8일이죠) 아무것도 없는데서 서버를 만들어내라고 한다거나. (제가 바로 이전에 한 프로젝트, 결국 한달만에 딜리버리 했지만..) 아키텍쳐고 뭐고 다 필요 없고 대충 그림 한장 그려놓고 코피쏟으며 기어이 해내면 그게 일반적인 개발기간인 줄 알죠. “이것에 회사의 사활이 걸려있다.”, “이것만 해주면 지금 가서 당장 매출 5억 따온다”. … 등등 흔하게 듣는 이야기들이죠..

애초에 이런 억지스럽고 말도 안되는 개발 기간, 조건에 대해서 받아들이지 않게 사내 협상을 통해서 조율하는 것도 “훌륭한 개발자”의 조건이겠습니다만. “협상”은 그들의 전공분야며 “마케팅부서”는 개발부서보다 사장님 가까이에 있다는 것이 슬프답니다.

영회 · 2008/09/18 02:45

어익후… 최과장님 오랜만입니다. 잘 지내시죠. 오랜만에 포스트 글을 보고… 마치 우연히 만난 듯해 반가운 마음에 짧은 덧글 남깁니다.

Yozz · 2008/09/18 12:56

어익후, 안선생님~~~~ 방가워요. 우리 술 언제할 수 있으려나..^^

okgosu · 2008/09/19 00:19

둘이 언제 그리 친해졌나… 오랜만일세…

Yozz · 2008/09/19 00:28

어이쿠 옥선생님~~~ 방가방가 ㅋㅋ

whiterock · 2011/03/11 13:32

개발자라 그런지 뭔가 안맞다는 느낌이 강하게 듭니다. :)

개발자로 인한 문제로 보이지만, 리더가 더 문제인 것으로 생각됩니다.

예로 든 사례들만 보아도, 제 눈에는 그렇게 보이고요. ㅡ,.ㅡ

farmuser · 2011/10/21 10:23

둘다 문제에요. 개발자는 개발 제품이 어느정도 만들어지는지에 대해 충분히 소통을 않했고 CIO나 매니저도 그런 소통을 않하려고 했기 때문입니다. 그리고 그 훌륭한 개발자는 훌륭한 개발자가 아닙니다..ㅋㅋ 훌륭한 개발자라면 CIO나 매니저가 엉뚱한 소리 해대면 아예 못한다고 하거나 일정 변경 개발 퀄리티 변경할 것입니다. 그리고 나중에 딴소리 못하게 녹음까지 하면 금상첨화임..ㅎㅎ