삼성이 소프트웨어 분야에서도 최고가 되려면?
잠시 후 Google blogger로 이동됩니다.
2010/01/23 - [소프트웨어이야기] - 삼성이 바다를 출시해서는 안되는 이유
2010/02/08 - [소프트웨어이야기] - 삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유
|
|
잠시 후 Google blogger로 이동됩니다.
잠시 후 Google blogger로 이동됩니다.
포스팅 잘 읽었습니다. CMMI에서도 요구사항에 대해서 요구사항을 먼저 "개발" 하고 그 다음 레벨이 요구사항 "관리"입니다. 지속적으로 요구사항이 바뀌기 때문이지요. 본문의 내용과 비슷한 맥락이라 허접 답변 남기고 갑니다. ^^
어쩌면 가장 중요한 차이점은,
요구사항이 변경되고 나서 재계산되는 시간, 비용의 차이가 아닐까 생각이 됩니다.
한국에서는 변경되도 마감일이나 비용이 변하지 않으니 말이죠..
구차니님 안녕하세요.
요구사항이 변경되면 그에 따른 영향평가가 따라야 하고, 계약이 변경되어야 하는데, 우리나라에서는 스펙따로 계약 따로이기 때문에 요구사항이 2배로 늘어도 계약은 변하지 않는 문제가 있죠.
잠시 후 Google blogger로 이동됩니다.
안녕하세요. 익명님
제가 동안이라... 실제는 그렇게 어리지 않습니다. ^^
오래 살아 남는 것도 중요하기 하죠. 본인의 가치관에 따라 다를 것 같습니다.
현실적으로 진짜 일리 있는 말입니다. 현실적인 지적입니다.
개인적인 관점으로만 보면 서로 자신만 살아 남는 것이 좋겠죠. 여러 회사를 컨설팅하다보면 특히 금융권 등에서 이런 개발자가 많은 것을 알 수 있습니다.
그러다 보니 모두 서로 발목을 잡아서 회사나 각 개발자는 성장이 어려워지고, 본인들도 살아는 남지만 또한 운신의 폭이 작아지는 것을 종종 봐 옵니다.
하지만 현실적으로 이렇게 생존모드 외에 별 방법이 없는 것을 이해는 합니다. 할줄 아는게 생존이라서 자신의 지식을 감추고 자신이 없으면 잘 안돌아가게 하는 수 밖에 없더군요. 이 때 자신만 내놓으면 자신만 손해보는 현상이 발생하죠. 이게 악순환... 우리나라 대부분의 소프트웨어 회사에 존재하는 거죠.
선순환이 그렇게 쉬면 누구나 다 하겠죠. 회사, 개발자 모두 바뀌어야 모두에게 이익인데, 선순환의 시작은 대단히 어렵습니다. 제가 하는 일이 선순환이 시작될 수 있도록 회사를 바꿔주고 개발자를 교육하는 일입니다.
잠시 후 Google blogger로 이동됩니다.
문서가 실용적이어야 한다는 의미는 공감합니다만,
> 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.
이 부분은 일반적인 이야기가 아니지 않나 생각됩니다. 코드는 문서보다 훨씬 빠르게 바뀌기 때문에 문서는 뒤쳐지게 되어있는데, 아마도 말씀하신 의미상으로는 문서를 이런 변화까지 수용하게 적어야 된다는 것이 아닐까 추측되는데, 그건 잘 작성된 기준으로 생각하기에는 적합한 기준이 아니지 않나 생각됩니다. 문서가 바뀌기 때문에 잘 작성하지 않았다는 것은...
또한, 다음 단계(?)의 개발자가 이를 활용할 수 있는 프로젝트가 있는 반면, 그렇지 않은 프로젝트도 많이 있기도 한 것 같습니다.
charlz님 안녕하세요.
좋은 의견 감사합니다. charlz님의 댓글을 보면 "문서"라는 말을 가지고도 서로 다른 이미지를 그리고 있다는 생각이 듭니다.
예를 들어서 스펙서를 기준으로 보면 설계단계나 구현단계에서 스펙서가 바뀌는 것은 스펙이 바뀐 것이고, 그 변경에 대한 비용을 몇곱절로 치뤄야 합니다. 하지만 개발 기간내에 스펙이 전혀 바뀌지 않는 프로젝트는 찾아보기 힘들죠. 하지만 변경을 최소화는 해야 합니다. 설계가 진행되고 코드가 진행됨에 따라서 스펙서를 바꾸지는 않죠.
그리고 설계서의 경우에도 코드가 진행됨에 따라서 아키텍쳐나 인터페이스의 변경이 있기 전에는 설계서가 변경되지 않습니다. 문서와 코드가 같이 발전해 나가는 경우는 분석, 설계, 구현단계가 적당히 밍글된 형태일 수도 있습니다. 사실 크고 작은 많은 프로젝트가 이렇게 진행되고 성공적으로 잘 끝나기도 합니다. 하지만 이런 방법으로 계속 성장하기는 어려움이 있습니다.
사실 문서가 잘 작성되었는지 판단하기는 대단히 어렵습니다. 그래서 그 한방법을 언급해 봤습니다.
제가 항상 주장하는 것은 개발자들이나 개발사들의 현재 상황에 따른 전투적인 대응방법이 아니고 개발자들이 꾸준히 성장하고 실력도 향상되며 현재 프로젝트를 잘 수행해내기 위한 원론적인 방법들이 주류를 이룹니다. 그런 관점으로 읽어주세요.
charlz님의 의견과 같은 여러 관점은 제가 많은 도움이 되네요. 감사합니다.
문서라 지긋지긋하지요.
정말 돈받고 만드는 프로덕트로서의 문서들은 가끔 종이값과 타이핑값을 받기 위해 만드는거 아닐까 하는 생각이 들곤 합니다. 그래서 도큐멘트도 아니고 산출물이라고 하는게 아닐까 생각하죠. ^^
SI성 프로젝트를 많이 하다보니 몇십종의 산출물들이 과연 필요나 할까 싶을떄가 많기도 하고, 왜 보지도 않고 쓸데도 없는 문서를 주구줄창 만들어야 할까 싶습니다.
경험적으로 생각해보면 산출물은 의사전달을 위한 문서, 생각을 정리하기 위한 문서, 점검을 위한 문서 세종류가 있는 것 갑습니다. (그냥 제 기준입니다.)
무엇을 위해서 작성을 하는지가 중요한 것 같은데.. 문서 프레임에 압도당할때가 만은데요. 잘하지는 못하지만 고객이나 내부 팀원이 쓸 수 있을 만한 표현력이 들어가면 문서의 프레임이야 얼마든지 고칠 수 있지 않나 싶네요. ㅎㅎ
뭐 항상 만들고 나면 이것 저것 한방에 보고 싶다는 욕심에 덕지덕지 붙여넣다가
질려서 흐지부지 되는 경향이 있어서.
될 수 있으면 간략한게 좋지 않나 생각이 드네요.
특히나 고객의 요구사항이 수시로 변할떄는 말이죠.
산더미같이 많은 문서를 만드는 프로젝트들은 아주 잘못된 관행입니다. 소프트웨어 개발에 대해서 잘 모르는 고객이 거대한 방법론에 있는 문서를 무작정 다 요구하곤 합니다. 그 방법론에서도 문서를 다 만들라고 하지 않는데도 잘못 적용하는 것이지요.
하지만 개발사 입장에서 고객이 요구하는데 안만들 수는 없는 노릇이지요. 수많은 문서 중에서 실제 개발에 필요한 문서는 소수에 불과합니다. 그런 문서만 제대로 만들고 나머지 프로세스나 관리를 위한 문서들은 최소한의 노력만 들이는 것이 좋습니다.
잠시 후 Google blogger로 이동됩니다.
잠시 후 Google blogger로 이동됩니다.
버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요. |
버그관리시스템 사용 vs. 미사용 비율 |
전체 투표 결과 |
버그관리시스템의 사용 비율 |
결론 |
맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
저희회사도 이제막 도입을 검토중이거든요..
프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^
어떤 시스템을 도입하려하시나요? Mantis? JIRA? 도입과정에서 어려움이 있거나 사용상의 이슈등 궁금하신 것이 있으면 언제든지 문의하세요. 감사합니다.
잠시 후 Google blogger로 이동됩니다.
![]() 컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을 도입한 것이다 ![]() 컴퓨터 시스템의 가격에서 소프트웨어가 차지하는 비율은, 컴퓨터가 생겨난 직후인 1955년경에는 20% 미만이었지만, 그 후에 급격히 높아져 80년대 후반에는 80~90%에 이르렀다. 이것은 요구되는 소프트웨어의 규모가 커짐에 따라 복잡해진 데 기인한다. 또, 요구되는 소프트웨어가 점차 복잡해진 반면, 그것에 대처할 수 있는 소프트웨어 기술(개발기술 및 관리기술)이 뒤따르지 못하기 때문이다. 그 결과, 소프트웨어는 항상 납기(納期)에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성(透明性)이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기(危機)’라고 불리는 징후가 나타나기 시작했다. 그 원인으로서, 모든 공학 분야에서 공통된 기본적인 설계절차를 밟지 않고 있다는 지적이 일기 시작하고, 소프트웨어의 개발에 스트럭처드 프로그래밍(structured programming:구조화 프로그래밍)과 같은 공학적 어프로치(approach)가 도입되기에 이르렀다. 소프트웨어에 소요되는 비용을, 계획에서 보수에 이르는 각 단계가 차지하는 비율로 보면, 요구하는 정의(定義) 및 방법의 기술(記述) 단계에 약 10%, 설계단계에 약 10%, 프로그래밍단계에 약 10%, 테스트 및 디버그 단계에 약 20%, 그리고 보수에 소요되는 비용이 약 50%를 차지한다. 검출되는 에러로는, 설계단계 및 그 이전의 것이 약 60%나 된다. 종래까지는 프로그래밍 단계가 강조되었으나, 소프트웨어의 ‘라이프사이클’을 인식하고 사태를 개선할 필요가 있다. 그러기 위해서는 과학적인 지식을 축적하고, 이를 실제적으로 응용해야 하는데, 이것들을 다루는 분야가 곧 소프트웨어 공학이다. |
팀에서 개발경험없는 소프트웨어 공학을 전공한 석/박사님들과 충돌을 많이했습니다. 학교에서 배우지 못하는 학문이라서 그랬을까요? ^^;
앞으로 올라올 포스팅이 기대되네요... 저도 많은 의견 올리겠습니다. ^,.^;
정의의소님 안녕하세요.
실전을 모르고 대학에서 소프트웨어 공학을 연구하시는 분들이 계십니다. 그런 분들을 헐뜻는 것은 아니지만 그런 분들은 계속 연구쪽으로 하시는 것이 좋겠죠.
실전은 다르니까요. 물론 그런 분중에는 실전 경험도 두루 갖추고 계신 분들이 계시죠.
연구파와 실전파 정도로 나눌 수 있겠죠.
미국에서도 소프트웨어 공학을 가르칠 때 "가르칠 수 없다", "배울 수 없다"라고 하고 가르친다고 합니다.
현실 소프트웨어 개발 현장에서는 탄탄한 이론에 기초를 둔 실전파들이 필요하다고 생각합니다.
그런 경우 그분들이 실전을 잘 몰라서 그런다고 생각하십시오. 소프트웨어 공학이 기계적으로 적용하면 된다고 생각하면 그분들이 잘못 배운 것이거나 경험없이는 안되는 것이 소프트웨어 공학인 것이지요.
제 생각에는 소프트웨어 공학은 실전 경험이 있는 분들에게 가르치는 것이 좋을 것 같습니다. 현재 KAIST에는 경험자를 위한 소프트웨어 공학 코스가 있는 것으로 알고 있습니다. 대부분 10년 이상 경험이 있는 분들이 수강을 하는데, 그정도는 되야 가르치는 것을 이해한다고 하더군요.
제 trackback에 있어서 타고 왔더니 정말 좋은 글이 있군요;ㅁ;
금일 다음 클릭애드클릭스 블로그 선정이 안되어서 우울했는데..
정리의 진수를 보여주시는군요..잘보고 갑니다^0^/
열정태하님 안녕하세요.
소프트웨어공학에 관심이 있으신 것 같아서 트랙백을 남겼습니다. 블로그 가보니 좋기만 하던데 왜 선정이 안되었을까요? 너무 뻑뻑하네요. 힘내세요.
감사합니다.
트랙백 있길래 와봣습니다.
참 좋은 내용은 많네용..
흠..소프트웨어 공학..학교때 배워도.어찌보면...그때는 아하 그랫어도 실상 개발자로 살아가다보면 간과 하게되죵..역으로 다시 서적을 통해 보고 있습니다.
잘 보고 갑니다.
쇼팬하워님 안녕하세요.
그래서, 소프트웨어 공학에는 경험이 정말 중요한 것 같습니다. 우리가 아는 유명한 소프트웨어 공학자들도 대부분 실전파 잖아요.
음...저는 학교에서 배울때 소공의 목적이 요즘은 빨리 만드는것보다는 유지보수가 용이하게 잘 만드는 추세로 간다고 들었던 것 같은데, 뭐가 맞는 걸까요? 연구실파는 아니셨는데요...ㅡ.ㅡ;;
나르사스님 안녕하세요.
의견 감사합니다.
저는 실전파 맞습니다. 그리고 소프트웨어 개발에 소프트웨어 공학을 적용하는 것은 프로젝트 비용 및 기간 단축과 유지보수를 용이하게 만드는 것 모두 해당합니다.
추세를 말씀하셨네요. 갈수록 소프트웨어의 유지보수가 중요해지고 있습니다. 실제로 소프트웨어는 개발보다도 유지보수에 더 많은 비용이 듭니다. 그래서 유지보수의 비용을 줄이는 것도 매우 중요합니다.
주먹구구식으로 개발하는 소프트웨어 프로젝트는 초기에는 빠른 것 같지만, 프로젝트가 막바지로 갈수록 뒤죽박죽이 되어갑니다. 그리고 이렇게 개발한 프로젝트가 더 빨리 끝나는 경우도 가끔 있으나 유지보수에 더 많은 비용이 드는 것이 일반적이지요.
녹차프린스님의 글부터 시작해서 트랙백을 따라서 여기까지 왔습니다.
알찬 글들이 많이 있네요.
잘 읽고 갑니다. 구독링크하고 자주 방문하겠습니다. ^^*
필넷님 안녕하세요.
새해 복 많이 받으세요. 좋은 블로그를 운영중이시더군요. RSS 등록해서 볼려고 합니다. 감사합니다.
잠시 후 Google blogger로 이동됩니다.
자율에 의해 버그가 잘 처리 되고 개발자가 자기 모듈에서 버그가 발생된다면 해당 개발자가 맡아 주는 것이 좋겠죠? 그러나 버그 리포트만 보고 어느 모듈에서 버그가 있는지 알기 어려울때가 있고 또 이전 모듈을 담당한 개발자가 더이상 일하지 않을수도 있고, 우리의 관리자가 개발자의 이름을 다 기억 못할수도 있고 등등등. 이럴때 이전 버그 할당한 히스코리나 버그의 증상을 바탕으로 버그 트래킹 시스템이 자동으로 이 버그를 픽스할만한 후보를 3명 정도 찝어 준다면 어떨까요? 물론 이 3명을 정확하게 찝어줘야 겠지만.
HannaKim님 안녕하세요.
자동으로 후보를 찍어주는 시스템이 효과를 발휘하면 대형 프로젝트에서는 정말 멋진 시스템이 될 것 같은데요. 혹시 그런 시스템을 만드신다면 기대하고 싶네요.
테스트팀이 개발 설계때 부터 투입되고 개발과 테스트관련 작업?이 같이 진행되면 Bug를 발견한 테스터가 직접 개발자를 Assign해도 좋다고 생각합니다. 물론 그 만큼 개발과 테스트가 유기적으로 진행되고 있어야하겠지요. 개발자와 1:1로 개발, 테스트를 진행했었는데 이게 가장 효율적이었습니다.
즉, 현재 조직 상황과 프로세스에 따라 다르게 적용되어야 한다고 생각합니다. 프로세스 성숙도와 규모에 따라 적용하는 것이 달라지겠지요.
Clear Quest를 사용하면서 큰 틀은 함께하면서 팀마다 다른 스키마를 적용했었습니다.
정의의소님 안녕하세요.
각 개발자가 컴포넌트를 완전히 구분해서 개발을 하신 경우겠네요.
테스트팀은 말씀하신 대로 개발 초기부터 투입이 되어야 합니다. V-Model만 보더라도 테스트팀이 요구사항단계부터 투입이 됩니다.
소프트웨어 개발은 원리를 이해하는 것이 정말 중요하다고 생각합니다.
관리자 및 개발자의 성숙한 소프트웨어 개발 프로세스 문화 뿐 아니라 QA팀에서의 Report도 많은 비중을 차지할 것 같습니다.
일단 버그의 담당자를 지정하기 위한 자료는 Issue Report 가 전부이기 때문이죠.
그리고 Stracking System을 Product별로 커스터마이징 해서 킥 오프 단계에서 각 개발 컴포넌트와 그 담당자를 매칭해 주고 자동 Assign 하면서 이 관계를 지속적으로 업데이트하는 방법도 효율적일 것 같습니다.
(가능한 Tracking System 및 양질의 Issue Report, 모든 부서의 원활한 커뮤니케이션이 선행되어야 하는... 어려운(...?!?!?!) 점이 있겠지만요.)
Noel님 안녕하세요.
상당히 Detail하게 적어주셨네요. 말씀하신 모든 부분이 이슈 할당 및 처리에 도움을 주는 방법들이죠.
버그 리포트 주체를 QA팀이 아닌 "누구나"로 확장하면 또 고려해야 할 것들이 있겠죠.
워낙 다양한 경우가 있어서 원리만 잘 이해하고 있으면 응용력이 생기죠.
이런 좋은 경험들이 다양한 경우에 응용력을 키워 줍니다.
잠시 후 Google blogger로 이동됩니다.
이상적인 환경이네요. 아웃소싱, SI 업계에서는 조건부터 잘못되서 적용이 안될거 같고, 금융 또는 IT 대기업 사내 소프트웨어 연구실 정도면 어느정도 현실화 될지도. 아마 괜찮은 회사에서는 벌써 적용될지도 몰르고. 그러나, 99% 개발자에겐 그림의 떡일듯. 불쌍한 우리회사 개발자들..
실력있는 개발자 같으신데 기회가 되면 창업한번 해보세요. 다양한 경험을 통해 좀더 현실적인 답을 찾아내시길~
저희 팀이 보편적인 프로젝트라고 보기는 힘들지만, 분명 SI 업계의 아웃소싱 프로젝트에서 위 내용을 토대로 진행을 해서 야근을 없앴습니다.
팀원 중 2명은 야간 대학원에 다니기 까지 하고 있습니다.
중요한 일이 무엇인지 판단을 하고, 고객이 원하는 것이 무엇인지 정확하게 판단하는 것과 구현을 분리하지 않고 일하는 것, 작업을 잘게 쪼개서 예측가능하게 하려는 노력은 현실적인 답을 만들어냅니다.
영회님 안녕하세요.
역시, 이 댓글 하나만 봐도 영회님과 그 개발팀이 어느정도의 실력과 경험이 있는지 알 수 있겠네요.
말은 쉽지만 실제로 그렇게 실행하고 있다는 것은 이해의 단계를 넘어서 내제화를 이루고 있다고 할 수 있습니다. 감사합니다.
붉은칼님 안녕하세요.
우선 밝혀둘 것이 있습니다. 저는 소프트웨어 개발컨설턴트로서 대한민국의 어떠한 개발자와 비교해도 부족하지 않은 개발 및 컨설팅의 지식과 경험이 있습니다. 수백만명이 쓰는 제품, 전세계인이 쓰는 제품, SI등 다양한 분야의 경험을 풍부하게 다 가지고 있습니다. 제가 쓰는 글들은 모두 경험에서 나온 글들입니다. 또한 저희 펌에서는 한국과 미국에서의 20년이상의 소프트웨어 개발에 대한 다양한 노하우를 가지고 있습니다. 그냥 단순히 보고 들은 내용을 옮기는 것으로 오해하지 마시길 바랍니다.
제가 컨설팅을 하면서 만난 거의 모든 회사는 "우리회사는 다르다"라고 합니다. SI다, 금융이다. 이유는 많지만 사실을 다 똑같습니다. 원리는 같다는 얘기입니다. 99%의 개발자에게 그림의 떡이 아니고 99%의 개발자에게 가능하고 그래야 더 품질이 좋은 제품이 개발되고 회사의 경쟁력이 더 높아집니다.
8시간 근무를 하는 이유도 더 개발을 잘하고 빨리 하기 위해서임을 명심해주시면 좋을 것 같습니다. 잘 이해가 안되면 붉은칼님에게는 정말 좋은 기회인 것 같습니다. 소프트웨어 엔지니어링이 가져올 좋은 개발환경에 대해서 앞으로 제 블로그를 지속적으로 관심을 가지고 봐주세요. 점점 더 구체적인 글들을 작성해 나갈 겁니다.
감사합니다.
저도 동감합니다. 저도 지금까지 거친 회사에서 항상 개발 프로세스를 체계화 해 보려고 노력했지만 (지금도 하고 있습니다) 항상 나오는 말은 "우리는 그런거 적용 못해" 라는 겁니다. 하지만 한가지 짚고 넘어가고 싶은 부분은 Ray 님의 말씀처럼 원리는 다 같다고 할 수 있겠지만 원리와 현실의 차이는 무시할 수 없다고 생각합니다.
따라서 원리나 원칙을 적용하고 그에 따르도록 하는 것 보다는 그 회사의 특수성을 이해하고 받아들여 그에 맞게 차용(adopt)하는 것이 가장 현실적이고 바람직하지 않을까 하는 생각입니다.
아시다시피 미국회사라고 야근 없는 것 아니고 주말에도 일할 때도 많습니다 - 전 미국에 있습니다. 개발자란 직업의 특수성이라고 생각합니다. 제 처제는 게임회사 그래픽 디자이너인데 프로젝트 마감일 다가오면 집에도 못가고 주말에도 밤새서 일합니다. 하지만 릴리즈 후에는 2주 - 3주 정도의 휴가를 받습니다. 고생 후 그만큼의 보상이 따른다는 것이 한국과의 다른점이라고 생각이 됩니다. 이는 IT 업계뿐 아닌 사회 전반적인 문화의 차이가 아닐까 하는 생각이 되네요.
Jake님 안녕하세요.
정확한 말씀입니다. 평소에 제가 하는 말이죠.^^
Jake님은 한번 만나뵈고 싶은 분이네요.
앞으로 좋은 교류 지속되기 기대합니다.
미국의 개발자들은 야근을 안하는가? 하는 오해가 있을 수 있습니다. 미국의 개발자들도 야근을 많이 하기로 유명합니다. 하지만 우리와는 경우가 좀 다릅니다. 대부분 체계적으로 개발을 하는데도 야근을 많이 하는 거죠. 특히 MS는 야근을 많이하고 그만큼 많이 보상해주죠. 많이주고 많이 뽑아먹기로 유명합니다.
HannaKim님 안녕하세요.
소프트웨어 엔지니어링에 관심이 많으신 분을 만나서 반갑습니다. 앞으로 좋은 얘기 많이 주고 받으면 좋겠습니다.
감사합니다.
좋은 말씀 잘 보고 갑니다. 선택할 위치에 있는 분들의 뿌리깊은 잘못된 사고방식이 합리적으로 바뀌었으면 좋겠는데, 개발자 출신의 관리자들도 똑같은 생각은 가지신 분들이 많으니 요원한 일로 보이기도 합니다. 하지만 점점 좋아지겠죠? ^^
cozydev님 안녕하세요.
개발자가 좀더 전문적이어야하지 않을까요? 주먹구구식으로는 경영자를 납득시키기는 어려울 것 같습니다.
뭐 워낙 대단한분들이 모이신거 같은데 읽다가 저도 생각을 한줄 표현할까 해서 올립니다만...
환경이 열악한건 사실이죠..근데 환경이 언젠가는 좋아지겠지라는 생각과 그런날이 올까? 라는 생각이 주를 이루는데요...?너무 환경탓을 하기 보다는 자신에게 주어진 환경을 자기가 만들어 갈수 있다는 생각을 가지는것이 중요하다고 생각합니다. 저도 적지않은SI 경험을 가지고 있지만...SI하면서도 일빨리 끝내고 일찍가는 개발자 많고요... 일잘하면 요새는 관리자도 특별히 근태 터치 안합니다.물론 기본적 근태는 지켜줘야죠 9시 출근 6~7시 퇴근 그러다가 일주일에 한두번정도는 8~9시 퇴근 이정도면 처자식과 가정생활 하면서도 충분히 SI에서도 개발자로 생활 가능하다고 보는데요..
잠시 후 Google blogger로 이동됩니다.
JasonPA님 반갑습니다.
이런 현상을 조삼모사라고 합니다.
당장의 이익을 위해서 미래에 큰 손해를 보는 것이지요. 회사의 비전과 제품의 로드맵에 따라서 이익이 안되는 요구나 고객들은 과감히 포기할 수 있어야 하는데, 우리나라의 많은 소프트웨어 회사들은 비전과 로드맵이 부족하기 때문에 사실 포기할 수 있는 기준도 애매한 경우가 많더군요.
전적으로 동감합니다.
아직까지도, 소프트웨어에 제 값 안주고, 하드웨어의 서비스처럼 생각하는 동네도 있습니다.
슬픈 현실입니다.
어제 밤에 우연히 이곳을 발견했습니다.
도움되는 글이 많아서, 오늘 하루를 몽땅 투자해서 처음부터 읽고 있습니다.
좋은 글 감사합니다.
이건 우리나라의 특수성에서도 기인하는 것 같습니다.
미수다였나? 어디선가 외국인이 우리나라 오면 신기해하는 것중 하나가 "어디를 가도 사람 없는 곳이 없다."라는 것이었습니다.
인구밀도가 워낙 높아서, 아파트를 선호하고, 인구밀도가 높으니 네트워크를 설치할 때도 비용이 상대적으로 저렴하죠. 그러니 초고속 인터넷 보급률도 높았죠. 소프트웨어 산업도 비슷한 맥락이 아닐까 합니다. 인력은 넘쳐나니(업무능력은 논외), 손쉬운 대안이 되는 것이고, 개발자는 개발자 나름대로 자기 노하우를 다 쏟아놓으면 토사구팽될까 두려워하고. 뭐, 이런 것 아닐까요?
nulonge님 안녕하세요.
동감입니다. 그래서 개발자들이 죽어나죠. 고객들은 좋지만 결국 고객도 손해보고 다 같이 손해보는 것인데 말입니다.
최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..
유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..
이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..
소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..
필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..
김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..
우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..
10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..
본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..
우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..
정말 100% 공감하는 글 입니다.
극단적인 표현일지 몰라도 . 많은 프로젝트들이 실패를 해야 한다고 생각이
듭니다.
부정적인 시각이라기 보다 현실적인 시각이죠...
프로젝트가 시작하면 이미 절반이상 실패를 했다고
생각합니다.
근거를 알 수 없는 개발공수, 복불복 개발 방법론(나만 아니면돼),
커뮤니케이션 없는 일방적 진행,무늬만 개발 총괄,
기술보단 정치가 중요한 환경등...
재난이 난 후 피해액보다 예방에 투자한 금액이 훨씬 저렴하고
안정적이란걸 깨달았으면 합니다.
쓰나미가 밀려오는 걸 알면서 피하지 않고 기다린다는게 너무 슬프군요
안녕하세요. Beyond J2EE
또다른 문제는 소프트웨어 분야에서 문제가 많음에도 불구하고 삼성이 잘해왔다는 겁니다. 최근 스마트폰이 대두되면서 문제가 되고 있기는 하지만 지금까지 겉으로 보기에는 잘 해왔습니다.
그래서 더욱 경영층들이 설득이 알될 가능성이 높습니다.
바늘로 찔러 고름을 짜낼것을 미루고 미루다가
10%도 안되는 성공율의 수술을 받아야 하는 상황이 된게 아닐까 싶습니다.
안녕하세요. 구차니님
지금까지 왜 이렇게 되어 왔는지 이해는 되지만 안타깝죠.
시나리오는 영화로 제작하지 않는한 실감하기가 쉽지 않죠.
또한 영화로 제작한다고 시나리오가 현실이 되는것도 아니고요.
삼성의 SW 성공 시나리오는 말그대로 시나리오일 뿐..
현실에서의 실질적인 대책은
역시 어느 누구도 세울 수 없는 상황인 것 같습니다.
안녕하세요. 크레브님
그나마 최선의 방법을 제시한 것이지만 이렇게 되지 않을 확률이 훨씬 높아 보입니다.
그 동네는 해외 유학파 출신 인재들도 많은 걸로 알고 있습니다만, 선진국으로부터 배운 것들은 조직문화에 별 영향을 주지 못하는 것 같습니다. '인천공항의 기적'이라는 말도 있던데.. 주로 대학 쪽에서 쓰이던 말이지만, 업계에서도 그것은 통용되고 있지 않나 싶네요.