씁슬한 한국 개발자들의 자화상
http://zdnet.co.kr에 올라온 글입니다.
필자는 업무상 외국 개발자들과 업무 회의를 하는 경우가 종종 있다. 본업이 소프트웨어 분야이기 때문에, 주제는 운영체제, 소프트웨어 시스템 설계, 기능 정의, 개발 언어 등등이며, 필자가 외국 업체를 방문해서 회의를 하는 경우도 있고 국내에서 하는 경우도 있으며, 가끔 전화로 텔레컨퍼런스를 하기도 한다.본론으로 들어가기 전에, 얼마 전에 있었던 에피소드를 한 가지 소개하겠다. 회의실 예약을 해놓고 30분 정도 미리 약속 장소에 도착했는데, 마침 상대측 개발자도 미리 도착해 있었다. 회의실을 사용하려면 30분 정도 기다려야 했기에 '인사하고, 커피 한잔 하면서 가볍게 날씨 얘기로 분위기를 자연스럽게 만들어볼까'하는 생각에 그 사람과 인사를 하고 커피를 권했다. 물론 고맙다면서 커피를 받아 마시기는 했는데, 갑작스레 그쪽에서 먼저 오늘의 본론을 꺼내는 것이었다. 급한대로 주위에 있는 불편한 간이 의자를 끌어와 앉아서 두손으로 자료를 잡고서 미팅을 시작했다.
혹시 외국 생활을 해본 분들은 알겠지만, 그들은 이렇게 언제 어디서나 회의·토론을 자연스럽게 할 수 있는 문화가 몸에 베어있는 경우가 많다. 처음에는 이런 즉석(?) 회의가 좀 어색했지만, 이러한 일을 여러 번 겪으면서 이런 식으로도 진지한 회의가 진행될 수 있다는 것을 다시 한 번 깨달을 수 있었다.
지금부터 편의상 외국 개발자를 A, 국내 개발자를 B라고 하겠다.
A와 업무 이야기를 할 때마다 매번 느끼는 점이지만, 그들은 정말 철저하게 준비를 하고 업무에 임한다. 약간 과장해서 표현하자면, 항상 준비된 자세로 자신의 일에 임하고 있다. 그리고 자신의 관심 분야와 업무 분야에 대해서는 정말로 전문가다운 지식과 관심을 가지고 있다. 어떻게 보면 이러한 자세가 당연한 필요 요소이기는 하지만, B의 경우에는 이러한 필요조건마저 충족돼 있지 않은 경우가 허다하다.A와 회의를 하면서 마무리되는 전형적인 예는 다음과 같다:
A: 이상으로 논의한 내용에 대해서는 제가 본사로 돌아가서 저희 쪽 엔지니어들과 협의한 후에 결과를 알려드리겠습니다.
B: A나 B나 모두 프로젝트 실무자인데, 일단 이 자리에서 개략적인 일정과 개발 내용을 정하는 것이 좋지 않을까요?
A: 이 프로젝트는 저 혼자 진행하는 것이 아니라서, 팀원들과 정확하게 범위를 확정 한 후에 프로젝트에 대한 내용과 범위를 다시 한 번 논의하도록 하겠습니다. 특히 계약이나 일정, 금액적인 면에서는 마케팅 쪽과 상의해야 합니다.
B: 저희는 일단 시작부터 하고 보완해나갔으면 하는데요...
A: 프로젝트의 범위와 일정을 정하지도 않고 어떻게 일을 시작하나요? 이해가 안 되는데요...
B: 우리나라에서는 대개 일단 프로젝트를 시작하고 나서 진행하는 도중에 마케팅 담당자들끼리 일정과 금액을 논의합니다.
A: 좀 이상하네요...프로젝트 내용과 일정도 정해지지 않은 상태에서 어떻게 일을 진행할 수 있나요?
B: 음...글쎄요...저희는 일단 시작하고 봅니다.우리나라 업체끼리 일을 할 때 위의 A와 같은 태도를 보이면 같이 일할 의사가 없는 것으로 간주되고 B는 또 다른 업체를 알아보게 된다. 즉 A가 너무 튕기고 괘씸하다는 생각을 하게 된다. 그러나 A의 경우에는 이것을 당연한 업무 절차라고 생각한다.
또다른 측면에서 보자면, A는 학교에서 배운 것들에 충실한 것 같다.
우리가 학교에서 배운 각종 이론들, 특히 소프트웨어 공학 측면에서 A는 정말 철저한 모범생들이다. 프로젝트를 시작하기 전에 먼저 업무의 내용과 범위를 확정하고, 이에 따른 비용을 산출한다. 개발 결과물에 있어서도 '테스트'와 '문서'가 반드시 포함된다. 심지어 아직 만들어지지도 않은 문서에 대해서 가칭으로 문서 제목까지 언급하면서 이러이러한 문서가 반드시 제공될 것이라는 것이 프로젝트 내용에 포함된다. 유지 보수 측면에서도 언제 어떠한 내용의 작업이 필요하다는 예측까지도 프로젝트에 포함시키고 있다.그러나 우리는 어떠한가? 학부에서뿐만 아니라 대학원에서도 지속적으로 소프트웨어 공학에 대해서 학습을 하지만, 실무에서 이러한 것들을 따르려면 앞뒤 꽉 막힌 사람이라는 소리를 듣기 십상이다. 일단 만들어진 결과물을 상대방에게 제공한 후에 테스트를 하는 경우가 많으며, 이 경우에도 최소한의 테스트만 하는 경우가 부지기수이다. 문서? 이것은 정말로 찬밥 신세이다. 문서는 시간이 남을 때 약간 긁적거리거나, 심지어 개발자가 문서 작업을 하면 그의 능력을 의심받는 경우도 있다. 더욱 심한 것은 '형상 관리'이다. 소스 코드 관리와 문서 관리 시스템에 대한 얘기가 나오면 '왜 그런 걸 돈 주고 해야 하는데?', '개발자가 조금만 시간내서 신경쓰면 해결되지 않는가?'라는 결론을 얻는 경우가 대부분이다.
물론 대기업이나 중견 기업처럼 시간과 (개발)인력 관리 측면에서 여유가 있는 기업에서는 이와 같은 프로젝트 관리 및 형상 관리가 자리를 잡아가고 있는 것 같다. 그러나 우리나라 IT의 대다수를 차지하고 있는 중소 벤처에서는 이러한 관리를 기대하기가 어려운 것이 현실이다. 시간과 비용 때문이다. 화살을 굳이 돌리자면 '갑'측의 횡포 때문이라고도 할 수 있겠다. 최소한의 개발비만 주고서 최단시간 내에 많은 것을 요구하다보니, '을'에 해당하는 용역 업체에서는 정신없이 시간에 쫓기고 테스트나 문서 작업이 부실해질 수밖에 없다. 더구나 제대로 비용도 받지 못하는 유지 보수는 무료 봉사에 가깝다. 대다수의 SI 관련 업체가 개발자 인력난을 겪는 것도 이러한 맥락으로 볼 수 있겠다. 오죽하면 SI 업계에서 '볼모'라는 단어가 공식 용어처럼 통용되고 있을까.
한 가지 더 언급하자면, 학교에서 아무리 최신식의 훌륭한 IT 교육을 받았다고 하더라도 실무 개발에서 이를 필요로 하지 않는다면, 지금과 같은 인력난이 계속될 수밖에 없을 것이다. 학교에서는 정도(正道)를 가르치지지만, 이렇게 배운 정도를 현실에서 사용할 수 없기 때문이라면 지나친 표현일까? 당장 실무에 투입할 IT 인력이 없다고 쩔쩔 매면서도, 정작 제대로 된 '개발자'를 원하는 것이 아니라 임기응변과 변칙적인 기술에 능통한 '해결사'를 원하기 때문은 아닐까?
종종 한미 합작, 한중 합작을 해봤자 결국 우리나라가 손해를 본다는 소식을 접하곤 한다. 특히 중국 비즈니스와 관련해서는 '당했다'라는 표현을 할 정도로 그들은 철저하게 준비하고 이익을 챙긴다. 덕분에 불쌍한 우리의 개발자들은 실컷 고생한 후에 욕을 먹는다.
미국이나 유럽 등 선진국의 개발자들이 좋은 대접을 받는 이유는 몇 가지가 있겠지만, 필자가 느낀 한 가지는 그들은 정말 자신의 분야에 있어서 전문가이고 자신감이 있다는 것이다. 자신의 분야에 대해서는 누구 못지않은 전문가답게 행동하면서도, 그 분야와 관련된 전반적인 주변 내용들도 광범위하게 설파하고 있다는 것이다. 이유야 어떻든 간에 우리 개발자들은 부족한 면들이 많은 것이 사실이다.
필자는 이 글에서 우리 개발자나 시스템을 탓하려는 것은 아니다. 오히려 이렇게 전락해버리고 대접 못 받는 개발자들이 진심으로 불쌍하다(필자도 이 부류에 포함될 지도 모른다). 그리고 이 글에서는 어떠한 대안을 제시하고 싶지도 않다. 필자가 아무리 부르짖더라도 '갑'이라는 '막강 파워'에 도전할 수 없기 때문이다.
그러나 한 가지 짚고 넘어가야할 것은, 비록 현실이 이렇더라도 옳고 그른 것을 정확히 파악하고 있자는 것이다. 비록 현재는 우리의 개발자들이 불합리하고 어려운 여건에서 일하고 있지만, 생각 있는 개발자들이 점차 늘어나고 고령화됨에 따라서 서서히 변화되기를 바란다. 그리고 반드시 그렇게 되어야 할 것이다.
제목 처럼, 우리의 자화상은 상당히 왜곡되고 안타까운 면들이 많다. 학교에서 배운 것들을 다 잊어버리고 사회 선배나 직장 상사로부터 왜곡된 관행을 답습해왔기 때문일 수도 있다. 아니면 당장 밥 먹고 살기에 급급해서 전후좌우 살피지 않고 무조건 코앞의 땅만 쳐다보고 달려가고 있기 때문일 수도 있다. 흔히 하는 말로, '사회생활이 다 그렇지'라는 말로 치부해버리곤 한다. 하지만 '사회가 다 그런 건 아니다.' 하루하루 고민하면서 힘들게 살아가는 것보다 아무 생각 없이 사는 바보가 더 행복할 수도 있다. 그러나 미래를 꿈꾸고 창조적인 개발을 하고 있다는 자부심과 자신의 분야에서는 최고가 되겠다는 자신감이 있다면, 지금처럼 눈 가리고 아웅 하는 식의 '해결사'가 되기보다 진정한 '개발자'의 길을 포기해서는 안될 것이다.
우리의 선배들이나 선진 외국 개발자가 우리의 자화상을 그려주지는 못한다. 우리의 자화상을 정확하게, 그리고 보다 아름답게 그려나가기 위해서는 우리 스스로 안목과 감각을 키우고 다듬을 수밖에 없을 것이다. @
http://www.zdnet.co.kr/anchordesk/todays/hjung/article.jsp?id=63947
개인적으로 요즘 매우 공감하고 있습니다. 신입으로 뛰어들어 나름대로 소프트웨어 공학을 적용한 프로그램을 만들어보자고 혈기방자하게 나섰다가 퇴짜맞고, 지금은 그냥 "너 이거해" 시키면 남들이 뭘 하던 말던 신경안쓰고 내꺼 막코딩하고 있습니다.
그리곤, 나중에 남들꺼랑 맞춰보면 제대로 되는게 하나도 없고, CVS같은것도 도입하지 않아 6명이 작업하면서 남의 것 덮어쓰기 일쑤지만, 그냥 그렇게 살고 있고..
지금 내가 꿈꾸는 것을 결코 잊지 않고 기억하고 있다가 내가 프로젝트 리더가 되는 그날... 꼭 세상(??)을 바꿔보겠노라고 다짐하며 하루하루를 보냅니다.
단지 "기억하는 것"에서 멈추지 않고 그 분야(SW공학과 내가 일하고 있는 분야)에 대해 나름대로 전문가가 되기 위해 책을 읽는 것도 게을리 하지 않으려 합니다.
언젠가는 우리도 선진국 개발자들처럼 제대로 분석하고 설계하고 구현하게 되는 그날이 오겠지요?
문제는...
개인적인 생각은, 프로그래밍이라는게 협업이기 때문에...
단순히 테크닉과 기술이 뛰어나다고 해서 되는 문제는 아닌 것 같습니다.
프로그래밍도 사람과 사람이 하는 것이므로 서로 의견을 교환하고 절충하고 토론하는 문화가 우선되야 하는데...
우리네 교육과 사회 분위기가 그런 건 쏙~ 빼놓고 단순 기술만 가르치고 또한 '능력있는 사람 = 많이 아는 사람'이라고 생각하기 때문에 발생하는 것 같습니다만.
서로 다들 너무나 잘나서 각자 개발하는게 편하고 익숙해 하지 않나요?
프로그래밍은 코딩 못지 않게 사람과 사람과의 관계를 유지하고 협력하는데에도 많은 비중이 있다고 봅니다.
단순히 기술력이 부족하네 하는 문제만으로는 설명하기 어렵죠.
"나는 CVS를 쓰려고 하는데 다른 사람들은 싫어라 한다~"
"설계를 잘 하고 구현하고 싶은데 회사는 그런거 무시하더라"
라는 말에는 '나는 잘 하는데 여건이 문제다', '나는 자유롭게 프로그래밍만 하고 싶은데 이게 어렵다'라는 변명이 섞여 있지 않나 싶습니다.
물론 저도 현업에 뛰고 있기 때문에 현 상황을 충분히 이해하고 인정하고 있습니다만.
이게 개발에 대한 열정이나 지식으로 무장한 '똑똑한 사람들'은 많지만, 이들이 협력하여 그럴싸한 결과가 나오지 않는 이유 중에 하나가 아닐까요?
-----
우리가 자기자신에게 "나는 그렇게 할 수 있어. 단지 하고 싶지 않을 뿐이야"라고 할 때 이것은 내가 실제로 할 수 없다는 것을 다르게 표현하는 것일 수 있다.
(파인만씨 농담도 잘하시네..)
The difficulty in life is the choice.
Re: 문제는...
사실 무슨 말씀이신지 이해가 잘 안갑니다.
결론은 그냥 시키는 대로 하라는 말씀이신지(즉, 나는 내가 잘났다고 생각하지만, 사실은 그렇지 않다. 걍 윗사람들이 시키는대로 해라) - 그렇다면 지금 그렇게 하고 있구요.. ,
아니면, 윗사람이 안된다고 해도 포기하고서 "세상이 내 실력을 발휘할 기회를 안주네" 그러고 있으면 변명일 뿐이다, 그러니 상대방을 설득하고 뜻을 관철하라 그런 뜻으로 하신말씀인가요? - 나름대로 노력했지만 대화기술 부족인지 실패했습니다.
어쨌든 협업이 안되는 것이 사실이고, 그렇기 때문에 그런 글을 올렸습니다. 올바른 설계와 대화, 그리고 프로그래머들간의 의지를 모아 협업솔루션(뭐가 됐든 대다수의 프로그래머들이 원하는 것으로)을 도입해서 서로간의 충돌을 줄여보자구요.
현재 제가 참여하고 있는 일은 거의 대화 없이, 각자가 만든 모듈을 보면 서로 일치하는게 몇개씩 있지만 그냥 그렇게...
어떤 사람은 개발 서버에서 작업하다 남의 것 날려먹고, 어떤 사람은 로칼에서 작업하다 서버에 올리면서 남의 것 날려먹고..
서로서로 왜 로칼에서는 되는데 개발 서버에만 올리면 안되느냐 아우성치면서 열심히들 일하고 있습니다.
http://kwon37xi.egloos.com
Re: 문제는...
kwon37xi 께 올린 글은 아니구요... ^^
님께서 올리신 주제 - 협업이 잘 안된다 - 에 대해 '왜 안되나?'에 대한 제 생각을 올려 본 것 입니다.
답변을 해야 할 것 같아서 다시 올립니다. 오해하실까봐서...
그러고보니 해결책이 없었네요.
말씀하신데로, 현 상황에서는 노력하는 방법밖에는 없지 싶습니다.
구성원이 보다 개방적이이면 더욱 좋겠지만...
제가 진짜 하려는 말은.
"많은 분들(저를 포함한)이 생각하는 '프로그래밍'에서, 정말 필요한 '커뮤니케이션'부분이 빠져 있는 것 같다. 이 부분의 중요성을 깨닫고 '프로그래밍'을 다시 바라보자"
뭐 그 정도 였던 것 같습니다.
그럼. 좋은 결과 있으시길....
The difficulty in life is the choice.
Re: 문제는...
개인적으로는... 커뮤니케이션의 문제라기 보다는 신뢰도의 문제라고 생각합니다. 우리나라 사회는 낯선 사람에 대한 경계가 지나치게 강한 편입니다. 일제 강점기와 한국 전쟁, 그리고 급격한 산업화의 부작용을 생각해 본다면 당연한 일이겠습니다만.
서양쪽에서 일하는 관습 중에 한국어로 번역하기 힘든 단어 중의 하나가 manual이죠. user's manual.. administrator's manual... 매뉴얼을 따르는 관습을 보면 우리네와 외국의 차이가 확연히 드러납니다. 일례로, 제품 조립 매뉴얼에 이 부분에는 볼트를 10개 조여라는 지시가 되어 있으면 외국 사람들은 아무 생각없이 10개를 조여 버립니다. 그러나 한국의 상황에서는 세개 정도밖에 조이지 않고 남은 나머지 볼트 7개는 하청을 주든가 팔아버리죠.
볼트 세개를 조이는 습관이 나쁘지는 않습니다. 볼트 세개로 충분할지..넷을 써야 할지.. 자칫 둘만 조였다가는 제품이 바로 부서져 버리겠죠. 똑똑하지 않으면 아예 볼트 세 개를 조일 엄두도 내지 못합니다. 그러나, 한번 정도는 그냥 잔머리를 굴리지 않고 볼트 10개를 조이면서 10개를 조여라고 매뉴얼에 지시해 놓은 그 '이름 모를 사람'의 의견을 존중하는 습관을 우선적으로 배워보면 어떨까 라는 생각이 자주 듭니다. 신뢰도가 올라가면 자연히 어느날 매뉴얼을 쓴 사람에게 연락을 해서 필요없이 10개 조이지 말고 3개만 해도 충분하더라.. 이런 얘기를 자연스럽게 할 수 있게 되지 않을까요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
닭이 먼저냐, 달걀이 먼저냐의 문제겠지만..
인식과 비용도 어느정도 한몫 하는것 같습니다.
국내 굴지의 ISP 선임의 말이 생각나네요..
"우리나라에서 소프트웨어는 공짜 아니었나요?"
아주 미팅 장소에서 한방 먹이고 싶더군요.. 쯥.
Fever Pitch!
언제나 회자 되는 문제이군요..저 상황을 어떻게 극복해야 하나 저
언제나 회자 되는 문제이군요..
저 상황을 어떻게 극복해야 하나 저도 생각을 많이 해봅니다만..
생각하면 할수록 화만 나는군요..
여러분들... 좋은 방향으로 나갈수 있도록 우리모두.~ 힘씁니시다..
사회적 풍조 때문이 아닐지..
"아는 것"과 "할수 있다는 것"
이 두가지를 제대로 구분하지 못하는 사람들이 많은 것이
우리나라인것 같습니다.
사실 "어정쩡하게 아는 것" 과 "진짜로 아는것" 으로 말하는 것이 더 적절하겠네요.
그렇기 때문에, 프로젝트를 시작하기 전에 내용, 비용 등등 전체적인 것들을 결정하지 못하는 것입니다.
사실, 어정쩡하게 알면 모른다고 얘기해야 하는데 많은 사람이 안다고 말하는 것도 문제인것 같습니다.
No Pain, No Gain.