요지는, 조엘이 책에서 주장하는 것 처럼 최고의 개발자에게 최고의 대우를 제공하는 인재에 몰빵식 경영은 회사에 필요 이상의 예산을 소모하게 만드는 고비용 방법론이며, 개발자에게는 헛된 환상을 심어주기 때문에 해로운 책으로 분류하고 싶다는 내용이다.
이 블로그의 글이 흥미로웠던 것은 회사의 경영자 입장과 개발자의 시각차를 볼 수 있었다는 점 때문이었다. 특히 작은 벤쳐회사의 경영자 입장에서는 회사를 존속시키고, 하루하루 회사를 키워 나아가는 것이 그야말로 피말리는 경영이라는 현실이기 때문에 조엘이 주장하는 "최고의 개발자" 들에게 최고의 대우를 해 주는 것은 고비용 저효율 방법론으로 비춰질 수 밖에 없다.
그런데 한가지 생각해 봐야 할 문제는, 최고의 개발자에게 최고의 대우를 해 주는 것이 "고비용" 인 것은 어쩔수 없다고 해도 "저효율" 로 인식되는 점은 우리 IT 업계의 구조적인 모순이 반영되어 있지 않는가 하는 점이다.
벤쳐열풍이 꺼진이후 벤쳐에서 시작해서 주목받는 탄탄한 IT 전문 기업으로 성장해서 돈을 버는 회사가 그리 많지 않은데다, 전형적으로 국내 IT 업계가 SI 위주의 시장이라 개발자들의 몸값은 철저하게 M/M 로 계산되기에 고급개발자라고 해서 그에 걸맞는 대우를 해주기가 어려운 것이 현실이다.
고가의 라이센스 비용을 지불해야 하거나 대량으로 팔리는 국산 솔루션 or 패키지가 많지 않고, IT 사업은 대부분 고객사와 협의한 외주개발비만큼만 지급되는 SI 사업 위주로 편성되어 있기에, 개발사들 입장에서도 초과 수익을 기대하기는 어려운 상황이다.
결국 최고의 개발자들이 만든 최고의 소프트웨어가 잘 팔려서 많은 수익을 올리는 성공스토리가 부족한 국내 IT 업계 현실에서는, 경영자 입장에서도 최고의 개발자를 굳이 찾을 필요를 느끼지 못하는 것이 아닌가 싶다.
사실 "똑똑하고 100배 일 잘하는 개발자" 가 드문 것도 사실이지만, 분명 그런 사람들은 존재하며, 적절한 사업모델과 "똑똑하고 100배 일 잘하는 개발자" 들이 만드는 서비스가 결합할 때 Success Story 가 만들어겠지만, 국내에서 그런 성공사례 자체가 드물기에 조엘이 책에서 시도하는 방법들은 환상적이고 비현실적인 이야기로 밖에 비추어지지 않는 현실이 아닐까 싶다.
PS) 나 자신도 "똑똑하고 100배 일 잘하는 개발자" 의 범주에 속하지 않기에 이런 글을 쓰는 것이 주제넘다는 생각도 들지만, 열악한 국내 IT 현실에서 답답한 마음에 끄적여 본다.
현실이 암울하고 답답하지만, 반드시 헤쳐나가야 할 특별한 이유가 있을 때, 우리가 생각해야 하는 것이 바로 혁신(Innovation)입니다. 북유럽 작은 나라들이 자국시장을 가지고 있지 않으면서도 부유하게 지속적으로 살 수 있는 것들은 혁신을 지속적으로 이뤄내고 있기 때문이구요... 우리나라의 S/W 산업도 '혁신'의 기치를 내걸고 뭔가 돌파구를 찾아야 할 필요가 있습니다. 맨날 형편 타령, 시장 타령, 심지어 '막장'이라는 단어까지 서슴치 않고 내뱉는 자세에서는 혁신이 나올 수가 없겠죠.
그런데 중요한 것은 '혁신'이 어느 한 순간의 산물이 아니라는 것이죠. 지속적으로 발상의 전환을 유도하고, 현실에 적용시켜서 변화를 유도하고 발전시키려는 끈질긴 노력이 혁신을 만들어 냅니다. S/W 업계에 그런 인재가 필요한 상황입니다. 100배 일을 잘하는 사람이라면, 웬만한 도전에는 꿈쩍하지 않고 불굴의 의지로 돌파구를 찾고, 온갖 주변의 냉담과 질시 또는 질타 속에서도 헤쳐나갈 수 있는 그런 사람일 것이라고 생각합니다.
요번 겨울 여행중에 우연히 Newsweek 를 보다가 재미있는 기사를 읽었다. 바로 마이크로 소프트의 핵심 엔지니어였던 찰스 시모니가 우주 여행을 다녀와서 기고한 기사이다. 유명한 책인 Programming Windows 3.1 ~ 시리즈 에서는 찰스 시모니를 "마이크로 소프트의 전설적인 프로그래머" 이자 "헝가리안 표기법(Hungarian Notation)" 를 고안한 사람으로 소개하고 있다.
예전에 빌 게이츠가 쓴 책에서 본 기억으로는 초창기 마이크로 소프트에서는 동구권의 개발자들이 매우 우수하다는 사실을 깨닫고 동구권 개발자들을 적극적으로 채용해서 활용했는데 그 중의 대표주자가 바로 헝가리 출신의 찰스 시모니(Charles Simonyi) 라 할 수 있다. 마이크로 소프트에서 20 여년간 근무하면서 초기에는 엑셀, 워드의 핵심 개발자이자 아키텍트로 활동했고 후기에는 마이크로소프트의 소프트웨어 개발 최고책임자( CSO, Chief Software Architect) 의 역활을 수행했다.
지금은 Intentional Software 라는 회사의 공동대표로 있다고 하는데 아마도 얼굴마담으로 직함만 걸어놓고 여생을 즐기는 것이 아닌가 싶다. 한때 마이크로 소프트 주식의 1%를 스톡옵션으로 가지고 있었다 하니 어마어마한 부자라 할 수 있다. (시모니의 추정재산 : 10억 달러 = 1조원)
뉴스위크에 실린 기사는 시모니가 2007년 3월에 2500 만 달러를 내고 러시아 우주항공국의 우주여행 관광상품을 통해 2 주일간 우주정거장을 체류한, 우주 여행을 하고 온 이야기에 대한 것이다. 생각보다 러시아 항공우주국은 굉장히 개방적이라는 것... ( 돈만 있으면 누구나 우주여행을 갈 수 있다. ) 우주여행을 하기 위해서는 무중력 환경 적응 훈련 및 적절한 체력 조건등을 갖추기 위해 수개월간의 준비 훈련이 필요하다는 것, 환갑이 다된 ( 48년생 ) 나이 때문에 자신이 과연 우주여행이 가능한지 걱정을 많이 했다는 것 ( 약 50 여명의 의사를 만나서 검진을 받고, 조언을 들었다 한다 ), 그리고 우주여행을 다녀온 소감이 간단히 써 있다. "I discover just how beautiful the world truly is"
IT 업계에서 최고의 성공을 거두고, 어린시절 자신의 꿈이던 우주여행까지 다녀온 이 사람의 인생이 참 멋지다는 생각과 함께 ( 시모니는 우주여행을 다녀온 후 소감을 정리한 홈페이지 까지 만들어 놨다 ), 곧 있을 우리나라의 한국 최초의 우주비행사 이벤트도 결국은 국민의 세금을 이용해서 러시아에 2,000만 달러를 지불하고 우주관광상품을 이용하는 것을 정부에서는 한국이 우주비행사를 배출했다고 오바한다는 생각이 들어 한심스러운 마음이 든다.
그나저나 우리나라도 우주여행을 갈만큼 거액을 벌어놓는 시모니와 같은 IT 업계의 스타들이 많이 나와야 할텐데...
11월 2일은 올해의 2007 ACM-ICPC Asia Programming Contest - Seoul 대회가 열린 날이다. 이 대회는 정보통신부가 주최하는 제 7회 대학생 프로그래밍 경시대회와 함께 개최되었다. 2001 년 첫 대회를 시작으로 벌써 7회째를 맞는 대회이다.
나는 직접참관을 고려하다가 이런저런 사정으로 그냥 회사에서 인터넷으로 관람을 했는데 매우 재미있었다. 대회 중계에도 참여해보고.. ㅋㅋ
ACM-ICPC 서울지역대회는 매년 그 규모가 성장하여 작년에 참가팀수가 200 팀을 넘어선데 이어 ( 207팀 ) 올해는 300 팀을 훌쩍 넘겼다. ( 349팀 ) 아시아에서는 중국 다음가는 큰 규모이다.
ACM-ICPC 의 재미있는 점중 하나는 대회 진행도중 문제를 하나 풀때마다 풍선을 하나씩 달아준다는 것이다. 각 풍선의 색깔은 문제번호를 의미하고, 높이 달리는 풍선일수록 난이도가 어렵다는 것을 의미한다. 대회가 진행되다 보면 풍선을 많이 단 팀과 풍선을 적게 단 팀간의 희비가 엇갈린다.
대회는 오전 10시부터 오후 3시까지 5시간동안 치뤄졌고, 총 10문제가 출제되었다.
대회가 시작하자마자 가장 쉬운 A 번부터 많은 팀들이 순식간에 풀기 시작한다. 이 당시는 아직 팀명이 제대로 나오지 않던 상태의 스탠딩이다. team22 = KAIST Farmer John, team4 = 서강대 KURU, team15 = 포항공대 Poscat, team31 = 서울대 We Are But Men, Rock (이하 WABMR), team13 = ICU Strawberry, team14 = ICU Anytime, team33 = 대만국립대 AC 순이다. A 번은 주어진 화학식에 섞여있는 원소기호와 숫자를 파싱해서 원소기호의 무게 * 숫자를 계산하면 되는 쉬운 문제이다.
2 번째 문제를 가장 먼저 푼 팀은 team14 = ICU Strawberry 였고, 그 뒤가 서울대 WABMR 였다. B 번은 주어진 문자열에서 2번 이상 나타나는 가장 긴 Substring 을 찾는 문제였다. suffix tree 를 이용해서 구현하면 된다고 하는데, 입력의 최대길이가 N = 5000 밖에 안되므로 그냥 무식하게 Brute Force 로 돌려도 풀린다. Team42 (중산대학교 ZSU_Dubhe) 팀은 특이하게 B 를 첫번째 문제로 선택해서 가장 먼저 풀었다.
대회 시작 40분이 되면서 서울대의 Mighty Friend 팀이 3번째 문제를 풀면서 잠시 중간순위 1위를 차지하기도 하였으나...
대회시작 50분이 지나면서 중국의 명문, 중산(中山, ZhongShan University) 대학교 가 4문제 (B A D E)를 가장 빨리 풀면서 다시 중간순위 1위로 올라선다. (중산대학교는 2006 년 서울대회에도 참가하여 3위를 기록한바 있다.) 그 뒤로 3문제를 푼 2위 그룹이 형성되어 있는데, 파키스탄에서 온 Punjab Univ. College of Information Technology 가 3문제로 순위권에 포함된 것이 의외였다.
대회 시작후 1시간 30분이 지난 시점. 놀라운 이변이 일어났다. 대회 전까지 누구도 주목하지 않았던 파키스탄의 펀잡 기술대학이 5번째 문제를 풀면서 (A B E C D) 1위로 올라선것. 관람하던 사람들과 중계하던 사람들 모두 웅성거리면서 올해 서울대회에서 한국팀이 우승을 차지하기가 쉽지 않겠다는 의견이 나오기 시작한다.
바로 이 팀이 중반이후 1위로 치고올라선 문제의(?) 펀잡 기술대학이다. 왠지모를 포스가 느껴진다~~
오전 11시 38분. 대회 시작한지 1시간 35분 정도가 지난 시점. 서울대 Incoming 팀도 5문제를 풀어 (A B E D F) 펀잡을 뒤쫒고 있다. 이 시점까지 2 문제 이상을 푼 팀은 총 24팀이고 아직 한문제도 풀지 못한팀도 4 팀이 있었다.
오전 11시 52분, 대회시작 후 110 분이 지난 시점이다. 펀잡은 또다시 6번째 문제 ( A B E C D F ) 를 풀면서 단독 1위를 질주한다. 인하대가 3번째 문제를 풀면서 초반에 선전하고 있다. ( 인하대는 여기에서 더이상 문제를 추가로 풀지는 못한다. )
차츰 대회는 중반을 넘어서 후반으로 가고 있었다. 대회 도중에는 도시락이 지급되어 참가자들은 식사를 하면서 문제풀이 코딩을 한다. ( 일부 열혈 참가자들은 밥을 굶으면서 대회에 매진한다. ^^ ) 파란색 풍선이 가장 많이 보이는 것으로 보아 역시 제일 쉬웠던 A 번이 파란색 풍선을 의미하는 것으로 보이고, B 번이 노란색 풍선인 것 같다.
대회 시작 2시간 10분이 조금지난 12시 15분 경, 온라인 예선에서 1위를 차지했던 WABMR 팀이 6번째 문제를 풀면서 다시 1위 자리를 빼았았다. WABMR 팀은 lewha0, zizavino 님과 같은 TopCoder 의 한국 상위 랭커가 팀을 이룬 강력한 우승호보 팀이다. 한편, 온라인 예선에서 좋은 성적을 거두었던 몇몇 팀들이 상대적으로 부진한 것도 눈에 띈다.
오후 1시 10분, 대회 시작한지도 3시간이 넘어섰다. 펀잡이 1시가 되기 조금전 7번째 문제 (G) 를 먼저 풀고, 10여분 후에 서울대 WABMR 팀도 7번째 문제 (F) 를 풀었다. 한편 외국팀들도 상당히 선전하면서 슬금슬금 순위가 올라오는데, 3 위의 중산대, 7 위의 홍콩과기대, 12 위에 천진 대학이 위치해 있다. 온라인 예선 1-2-3 위를 차지한 서울대는 서울대회 본선에서도 중간순위 2-4-5 를 차지하는 저력을 보여주고 있으며, ACM-ICPC 의 전통의 강호 ICU 와 KAIST 도 10위권 내에 위치하고 있다. 한편 4번째 문제를 푼 서강대 KURU 팀의 선전이 눈에 띈다.
오후 1시 50분. 온라인으로 공개하는 공식 순위 업데이트는 대회가 종료되기 1시간 전부터 중단된다. 이제 공식순위 업데이트가 얼마남지 않은 시점에서 여전히 1,2 위팀은 7문제에 멈춰있다. 서강대 KURU 팀이 5 번째 문제를 풀면서 ( A D E F B ) 10위까지 치고 올라갔고, 경희대 Zraler ( 즈랄러 라고 읽는다 -_-;; ) 팀 역시 4 번째 문제 ( A D C B ) 를 풀면서 입상 안정권에 들어섰다. TopCoder 에서 최근 많은 활동을 보이고있는 서강대와 경희대 두 학교는 모두 작년에 비해 향상된 성적을 거둘 가능성이 높았다.
오후 2시 12분. 순위 업데이트가 끝나고 더이상의 공식적인 순위 정보는 제공되지 않아 이제 현장에 구경간 특파원? 들의 정보에 의존해야 하는 상황이었다. 이 당시 상황으로는 펀잡의 월드파이널 출전과 서울대회 우승이 매우 유력해 보이는 상황이었다. 상대적으로 서울대 WABMR 팀은 패널티에서 밀리고 있어서 우승을 하기 위해서는 8번째 문제를 풀고 펀잡이 7문제로 굳는 것을 바랄 수 밖에 없는 상황이었다.
대회 1시간 남겨놓고 펀잡에 이어 2위에 있던 서울대 WABMR 팀. 괴로워하고 있음 -_-
그런데 대회 종료를 얼마남겨놓지 않은 시점에서 사고?? 가 터졌다
소식을 듣기로는 펀잡의 부정행위가 발각되어 급히 대회 스탭들이 사실 여부를 조사하기 시작한 것이다. 정확한 내용은 알려진 바 없으나 펀잡이 대회장 내에서 해킹을 시도하여 다른팀의 소스코드를 해킹하여 문제를 풀었다 한다.
부정행위로 인해 실격처리 되어 자리에서 Out 된 펀잡... -_-; ;
결국 펀잡의 서울대회 돌풍은 한바탕 해프닝으로 끝나게 되고, 막판에 8 번째 문제를 푼 서울대 WABMR 팀이 우승을 차지했다. ( 중산대도 8 문제를 풀어서 2위, 3위는 ICU. 최종 공식 순위는 아직 홈페이지에 공개되지 않음. )
최종 결과가 나오면 다시 정리하겠지만, 금년 대회도 매우 흥미로웠다. ;) 역시 Competetion 은 당사자에게는 피를 말리지만 보는 사람에게는 재미와 즐거움을 준다 -_-;;
재밌게 잘 봤습니다! 저도 한번 문제를 풀어보았는데요. 죄송한데 제가 푼 답이 맞는지 확인할 수 있는 방법이 있을까요? 생각보다 예외가 많아서 제가 푼 것이 틀린 것 같은데, 정답은 공개가 되지 않더라도 채점기계(?) 같은 것으로 제가 푼 것이 맞는지는 알고 싶습니다. 혹시 아신다면 꼭 좀 알려주세요~
보니까 모든 입출력이 stdin/stdout으로 되기 때문에 자동화된 채점 툴이 있을 것 같은데 말입니다.
작년의 경우 http://tanso.kaist.ac.kr/ 에서 대회 문제를 다시 풀어보는 채점 사이트를 운영하였습니다만... 금년 문제의 채점 사이트도 운영될지는 미지수네요.
algospot.com 을 가보시면 며칠 후에 대회 문제의 해설과 풀이방법이 올라올 것입니다.
그리고 북경대 acm 문제 온라인 심사 사이트(http://acm.pku.edu.cn/JudgeOnline/) 에서 시간이 좀 지난 후에 서울대회의 문제가 등록되어 다시풀어볼 수 있게 제공되기도 하니 기다려 보세요..
공감가는 내용이 많고... 평소에 생각하던 것들과도 연관되는 내용들이 많아서 원문 블로그에 있던 국내 IT 의 문제점인 세 가지 이슈에 대한 내 의견을 적고 싶다.
1. SI 중심의 왜곡된 업계 구조
말이 필요없다... 갑 - 을 - 병 - 정 - 무 - 기 - 경 - 신 - 임 - 계... 로 이어지는 SI 하청구조속에서 개발자들은 짧은 개발기간과 낮은 공수책정으로 인한 착취를 감내해야 한다. (대규모 프로젝트에서는 정무기 까지 내려가는 경우가 흔하다 ) 아는 후배가 술자리에서 "형 저희회사는 경 이예요" 라고 얘기했을때 그때는 웃었지만 마음이 착잡했다. ( 후배 녀석이 불쌍하기도 했고.. )
안철수 씨가 쓴 어느 책을 보면 SI 중심으로 나아가는 국내 IT 업계에 대해 개탄하는 내용이 있는데, 특정 분야의 특정 요구사항만을 충족하기 위해 개발된 SI 솔루션은 그 개발 난이도나 완성도 측면에서 팩키지 소프트웨어와는 넘을 수 없는 차이가 있고, 결국 SI 가 국내 IT 의 주류가 되면 전반적인 IT 시장의 수준도 낮아진다는 이야기였다. 개인적으로 느끼는 SI 의 문제점을 하나만 더 꼽자면, 개발 완료된 시점에서는 그럭저럭 쓸 수 있지만 이 솔루션을 조금 더 개선하고 싶거나, 퍼포먼스를 올리고 싶거나 혹은 기능을 추가하고 싶거나 할때는 완전히 GG 치게 되는 상황이 너무나 자주 발생한다는 것이다. ( 보통 이런 경우 처음에 개발을 맡긴 업체에게 돈을 주고 재개발을 시킨다. )
2. 엉성한 개발자 관리
위와 같은 왜곡된 상황에다가 소프트웨어 개발자의 노동력은 단순 M/M 공수로 계산되고 개발자의 역량이나 특기에 대한 가치평가의 기준은 너무나 원시적이다. 개발자의 숙련도와 경력에 대한 평가는 정보통신부 노임 기준에 따라 개발자를 경력과 학력에 따라 주먹구구식으로 나눈 초/중/고/특 급으로 나눈 임금 기준이 유일한 잣대로 제시된다. 부적절한 관리자들에 의해 개발자들이 고생하는 일이 비일비재 하며 개발자는 하나의 부품처럼 여겨지는 경우가 너무나 많다. 이런 열악한 상황속에서도 아웃풋은 최고를 강요한다... 흑..
3. 개발자들의 스킬 부족
사실은 여기에 대해서 정말 하고 싶은 말이 있어서 이 블로그를 쓰게 되었다. 류한석님의 원 블로그에는 개발자들의 커뮤니케이션 능력과 인성에 대해 지적했지만, 나는 테크니컬 스킬에 대해서 말하고 싶다. 블로그와 덧글들을 읽어보면 국내 IT 시장이 어렵고 열악하다는 것에는 많은 이들이 동의를 하지만, 어떻게 바꿀 지에 대한 의견은 거의 없다. 환경을 바꾸기 어렵다면 자기 자신부터 바뀌어야 하지 않겠는가. 이러한 열악한 IT 환경을 만든 것에는 국내 SW 개발자들도 책임이 있다고 생각한다.
개발자들이 프로젝트를 수행하면서 경험이 쌓이고 어느정도 스킬이 생기게 되면 어느순간인가 매너리즘에 빠지기 쉽다. 더이상 공부를 안하게 되고 자신이 갖고있는 밑천으로 버티거나 copy & paste 신공만 늘어난다. 무언가 개발해야 할 문제가 생기면 어떻게 구현할지 생각하기 보다는 비슷하게 개발된 오픈소스부터 찾는다.
SI 개발자들의 경우를 보자. 온갖 편법을 써서 (예를 들면 본인이 핸들링도 못하는 오픈소스 클래스를 덕지덕지 붙여놓거나, 심각한 오버헤드가 있는 노가다 코드로 구현한 상태) 요구사항만 간신히 만족시켜 놓고서는 개발 완료후에는 나몰라라 하는 경우가 허다하다. 자신이 개발한 결과물에 대해서 너무나 무책임한 사람들도 많이 보았다. 현실이 이러하니 국내 IT 업계가 어려워 진 것을 환경 탓만 할 수는 없다고 생각한다.
약간 주제가 다르긴 하지만 개발자들의 이러한 문제점에 대해서는 겐도우 님의 블로그가 공감대를 많이 가지게 한다.
사실 그리 많지 않은 개발 경험이지만 학교와 멤버쉽, 그리고 회사에서 여러 프로젝트와 외주관리를 진행해보면서 가면갈수록 개발방법론과 소프트웨어 공학에 대해 의구심이 드는 경우가 많았다. 바로 현실과 이상의 괴리라고나 할까. 내가 만나본, 많은 개발경력을 가지고 있고 업체에서 손꼽히는 뛰어난 개발자들 조차도 소프트웨어 개발 방법론을 제대로 내재화하여 실제 프로젝트에 적용하는 사례는 거의 보지를 못했고, 또 매번 프로젝트를 할때마다 그리는 UML 다이어그램들이 실제 프로젝트의 퍼포먼스 향상에 도움을 주는 것을 체감하기 힘들었기에 이러한 이론적인 방법론들이 과연 현업에서 어떻게 적용되야 하고, 또 얼마나 효과가 있을 것인지 의문이 들었던 것이다. (이상의 생각은 사실 작년 11월 경에 가졌던 생각이고, 요즘에 드는 생각은 설계와 좋은 방법론에 따라 표준화 된 소프트웨어 개발은 생산성 향상에 분명 도움이 될 수 있다. 문제는 어떻게 하면 소프트웨어 개발에 있어 좋은 설계를 만들고, 이를 바탕으로 중간에 일어날 수 있는 요구사항의 변경이나 설계시에 발견하지 못했던 많은 오류들을 적절히 컨트롤해 가면서 설계를 개발과 매칭할 수 있는가... 이다. 그리고, 설계를 하는 사람은 반드시 많은 개발경험과 소프트웨어 지식을 갖춘 아키텍쳐가 되어야 한다는 생각에는 변함이 없다.)
나의 질문 : 방법론 세미나를 들을때마다 드는 의문인데, 현업에서는 이러한 방법론을 내재화하여 개발 효율성과 결과물의 성능 향상에 도움을 주도록 적용하는 사례가 거의 없다시피 하며, ( 나와 내 주위의 경험상으로 볼떄. ) 현업에서 적용시키기 어려운 점 이 많습니다. 이러한 부분에 대해서 어떻게 생각하시는 지?
김창준 : ( 대략 3 분정도 침묵이 흐른 후 ) 현업에 적용시키기 어렵고, 노력을 많이 해야 한다. 하지만 이러한 방법론이 실제 개발에 있어서 가장 효율적이고 좋은 방법이라고 생각한다.
사실 이러한 대답에 좀 실망을 많이 했다. agile 방법론이 좋다! 라는 이야기는 이미 수도없이 들어왓기 때문에, 실제 현업에서 성공적으로 적용되는 사례 ( 개발자가 내재화 할 수 있는 ) 에 대해서 자세하게 듣고 싶었는데 그러한 부분에 대해서는 언급이 거의 없었던 것이다.
외부 회의때문에 끝까지 세미나를 듣지 못해서 아쉬웠는데. 어쨌든 나름대로 개발방법론의 적용과 현업 개발자간의 괴리감에 대해서 다시 한번 생각해 볼 수 있는 시간이 되어서 나 자신에게도 의미가 있던 것 같다.
안녕하세요... 글을 남겨주시고... 솔직히 많이 놀랬습니다. ^^
제 개인블로그는 별로 찾아오는 분이 안계셔서요....
창준님 입장에서는 분명 불쾌할수 있는 이야기일텐데... 논리적으로 잘 설명해 주셔서 정말 감사하고 제가 머슥해지네요... ;;
항상 프로젝트를 진행해 보면 최초 설계와 적절한 개발방법론을 적용해서 실제 프로젝트에서 개발자가 얼마나 더 효율적으로 일을하고, 프로젝트의 생산성 향상에 기여할 수 있는지가 늘 의문이었는지라 이런 글을 쓰게 되었습니다. 말씀하신 성공사례에 대해서는 저도 글을 찾아서 읽어보고.. 지금 진행중인 프로젝트에도 어떻게 참고할 수 있을지 더 생각해 봐야 할것 같네요...
글 마지막 부분의 경력에 관한 이야기는 저의 선입견으로 쓴 글이니 웃어 넘겨주셨으면 합니다... ^^ 오해의 소지가 있을만한 글이라서 지웠습니다~
그럼 오늘도 좋은 하루 되세요..
추신 ) 헉... 댓글 지우셨나... ;;
현실이 암울하고 답답하지만, 반드시 헤쳐나가야 할 특별한 이유가 있을 때, 우리가 생각해야 하는 것이 바로 혁신(Innovation)입니다. 북유럽 작은 나라들이 자국시장을 가지고 있지 않으면서도 부유하게 지속적으로 살 수 있는 것들은 혁신을 지속적으로 이뤄내고 있기 때문이구요... 우리나라의 S/W 산업도 '혁신'의 기치를 내걸고 뭔가 돌파구를 찾아야 할 필요가 있습니다. 맨날 형편 타령, 시장 타령, 심지어 '막장'이라는 단어까지 서슴치 않고 내뱉는 자세에서는 혁신이 나올 수가 없겠죠.
그런데 중요한 것은 '혁신'이 어느 한 순간의 산물이 아니라는 것이죠. 지속적으로 발상의 전환을 유도하고, 현실에 적용시켜서 변화를 유도하고 발전시키려는 끈질긴 노력이 혁신을 만들어 냅니다. S/W 업계에 그런 인재가 필요한 상황입니다. 100배 일을 잘하는 사람이라면, 웬만한 도전에는 꿈쩍하지 않고 불굴의 의지로 돌파구를 찾고, 온갖 주변의 냉담과 질시 또는 질타 속에서도 헤쳐나갈 수 있는 그런 사람일 것이라고 생각합니다.
좋은 의견 감사합니다..
똑똑하고 100배 잘하는 개발자에 들어가야지 뭔소리 하고 있는겨....
그정도의 프라이드도 없이 어찌 개발하고 있는겐가...
역시 영업에 슬슬 입질이 오는것이야?? ㅎㅎ
영업에서 입질은 꾸준히 온다고 할수있지... ㅋㅋ
어쨌든 100배는 아니고 10배 잘하는 개발자만 되도 좋겠다..