반갑습니다. 민원기님
언제든지 토론 주제를 던져주세요.

안녕하세요. 편집장님
"한국인"이라고 표기될 수도 있겠네요. ^^

안녕하세요.
Localization에서 정확한 표기를 하려면 Locale을 사용해야 합니다.
Locale에는 문자체계와 사용하는 지역으로 표기가 됩니다.
즉, 영어_영국, 영어_미국, 한글_대한민국, 한글_북한, 한글_중국(조선족) 이와 같은 식이죠.
따라서 en_UK, en_US, ko_KR, ko_PK, ko_CN 이렇게 표기합니다.
하지만 이렇게 표기하면 일반인들이 알아보기 힘듭니다.
따라서 영국영어, 미국영어, 한국어, 조선어, 중국조선어 등으로 표기할 수 있습니다. 여기에는 딱히 표준이 없는것 같습니다.

하지만 한국어의 주요 소비국은 대한민국이라서 대부분의 외국제품은 대한민국만을 기준으로 Localization을 하고 있습니다.

구차니님 안녕하세요.
ㅎㅎ 그래서 애플이 한글이라고 표기를 했었나보군요.

맞습니다. ^^

안녕하세요. 오산돌구님
컴퓨터 구조나 원리도 개인에게 있어서느 기초체력 중하나에 해당할 수 있겠습니다. 애초에 이런 것을 모르고는 기본에 되어 있지 않은 개발자이기 때문에 다른 것은 말할 필요도 없겠네요.
Pair Programming을 하시고 계시나요?
사실 이부분에 있어서는 논쟁의 여지가 많습니다. 모든 회사가 Pair Programming이 필요하고 효율적인 것은 아닙니다.
어떤 식으로 진행하고 계신지는 모르겠지만 자칫 시행착오가 될 가능성도 있습니다.

변화는 대단히 어려운 것입니다. 조금만 관심을 가지지 않으면 어느새 옛날로 돌아가 있습니다. 그래서 질질 끌지말고 짧은 기간에 강력한 힘으로 밀어붙이는 것이 효과적일때가 많습니다.

밑으로부터 서서히 천천히 일어나는 변화는 대부분 실패할 가능성이 높습니다.

그렇다고 섯부른 Push는 조직원들의 반발을 사기 쉽습니다. 그래서 변화가 어려운 것이지요.

하지만 변화하지 않으면 죽는 것이기 때문에 선택의 여지가 있는 것은 아닙니다. 필수죠.

그럼 제가 할수있는건 우선 저부터 변화하는 방법밖에 없는건가요?

일정에 쫒기는 개발이 아니라, 서로서로 정보공유하고
참여하는 모든 이들에게 이득이 되는 그런 개발을 하고싶습니다.
오늘 책을 다시 봐야겠습니다

사장님, 연구소장님, 팀장님의 생각을 먼저 바꾸는 것이 중요합니다.
본인만 열심히 하면서 이렇게 해야 한다고 주장하고 다니면 자칫 괴짜로 보여질 수도 있습니다.
윗분들의 생각을 바꾸는 것은 저희같은 전문가가 하는 일 중에 하나죠. ^^

안녕하세요. 윤민식님
회사이름을 밝히기는 어렵습니다.
기초가 잘 되어 있다는 것은 이제 출발점입니다.
필요조건을 갖췄다는 의미이고 필요충분조건은 아닙니다.

안녕하세요. 구차니님

시스템을 도입하고 프로세스를 정비하면 당연히 담당자가 필요하게 됩니다.
큰회사는 하나의 팀에서 여러명이 이일을 담당하고 작은 회사는 혼자 또는 1/2명이 이일을 담당합니다. 1/2명은 다른 개발일도 하면서 짬짬히 이일을 하는 거죠.

이렇게 정식으로 dedicate시켜주지 않으면 제대로 돌아가지를 않습니다. 이것도 잘 알려줘야죠.

시스템, 프로세스 관련된 일이 자기일이 되는 것은 나쁜 현상이 아닙니다. 회사에서 충분히 이해하고 시간을 할애해준다면요. 일반 개발자들이 알지 못하는 중요한 경험을 익히게 됩니다.

안녕하세요. 우울한 딱따구리님

Wow! 대단하신데요. 스스로에게 너그럽게 점수를 매기지 않았기를 바랍니다. ^^

QA전담팀은 개발자가 10명 내외의 작은 개발팀에서도 필요합니다. 테스트케이스도 마찬가지입니다. 작은 개발팀도 이렇게 개발하는 것이 더 적은 비용으로 빨리 개발할 수 있는 방법이지만, QA전담 인원을 채용하는 것은 왠지 아까운 생각이 들곤합니다. 개발자를 뽑으면 코딩도 하고 테스트도 다 할 수 있는데 말입니다. 이것이 바로 착각이죠. 개발자는 개발자만이 할 수 있는 본연의 작업에 충실하게 해 주는 것이 돈버는 길이죠. ^^

이외에도 소수의 개발팀이라도 갖춰야 할 것이 수두룩하죠. 그렇게 해 놔야 훨씬 빨리 개발할 수 있죠.

우울한딱따구리님은 이미 거의 잘 하고 계시는 것 같군요. 다음단계로 스펙과 아키텍쳐에 대해서 고민을 하셔야 할 것 같네요.

예 저도 이번에 전직을 하면서 QA팀이 있는 회사는 처음 다녀보는데, 수년간 숙달된 전문 QA들의 버그 잡아내는 솜씨란 개발자에 비할 바가 아니더군요. 게다가 웹의 경우 IE6/7/8, FF까지 cross platform 체크에 regression test까지, 개발과 QA는 비슷해 보이지만 엄연히 다른 분야라는 걸 실감했습니다. 그리고 개발자 못지 않게 유능한 QA 전문가를 채용하는 것 또한 중요하다는 것을요.

안녕하세요.
S그룹 회사마다 팀마다 천차만별이더군요. 상당히 잘되어 있는 팀에서 일하시는 군요.
사실 큰회사에 다니는 개발자들은 다양한 교육의 기회도 많고 회사에서 이것 저것 많이 시도들을 하기 때문에 왠만한 용어는 다 알고 경험들도 있습니다.
하지만 제가 컨설팅했던 큰 회사들을 보면 회사에서 추진하는 개선작업들이 잘못된 방향으로 여러차례 Push 하면서 잘된 것들도 있지만 잘못된 시도들 때문에 부정적인 이미지가 많이 퍼진 것들도 봐왔습니다.
그래서 이론적으로는 어떻게 하는 것이 옳다는 것을 알아도 그렇게 하지 않는 것들을 많이 봤습니다.
운전하면서 양보하는 것이 좋다는 것이 시험에 나오면 정확하게 맞혀도 실제 운전하면서는 양보하지 않는 것과 비슷하죠.
그중에는 정말 열심히 하는 사람들도 있는데 그렇지 않는 사람들도 많더군요.
그래서 이런 큰회사들은 바뀌는 것이 정말로 어렵습니다. 시간도 오래걸리고 경영층의 의지기 특히 중요하죠.

요새 욕 많이 듣는 다고 생각하는 것에 대한 제 생각은 여태 S사가 세계적으로 1등이고 뭐든지 잘하는 줄 알았는데 SW분야에서 그렇지 않고 많이 뒤쳐졌다는 뉴스들이 나오고 몇몇 제품과 비교가 되니까 나오는 실망감이고 넉두리라고 생각합니다. 대부분은 사용자로서 내 밷는 토로이고 저는 좀 생각이 다릅니다. 어떻게 해야 하는지에 대해서 주로 생각하고 말하려고 합니다.

유능한 개발자들이 가장 많이 몰려있는 곳이기도 하기 때문에 경영층이 조금만 더 똑바로 생각한다면 언제든지 SW에서도 1등이 될 수 있다고 생각합니다.

안녕하세요.

몇가지의 질문으로 역량을 다 평가할 수는 없겠지만 간단한 지표는 될 수 있습니다. 그렇다고 수십, 수백개의 질문을 만들면 너무 복잡하죠. 그래서 복잡한 질문은 제 Blog상단에 별도의 서비스로 만들어 놨고, 별도로 의견을 적을 수도 있게 되어 있습니다. 그러면 제가 읽어보고 제 의견을 Email로 별로도 보내드립니다.

역량평가표의 항목들은 소프트웨어 회사라면 갖춰야할 최소의 것들로 이루어져 있기 때문에 이부분들을 무시하고는 소프트웨어를 잘 개발한다고 말하기 어려운 것들입니다. 물론 개인적으로 뛰어난 개발자일 수는 있으나 회사차원에 그렇다는 의미입니다.

국내 대부분의 SW회사가 정말 척박한 환경이고 서로 대동소이하기 때문에 본 설문으로 대부분의 회사의 기본적인 상태는 간단히 평가할 수 있을 것으로 생각합니다.

안녕하세요. 구차니님
소프트웨어 회사는 수백년간 존재했던 수많은 종류의 회사들과는 완전히 다른 종류의 형태입니다.
이를 이해하지 못하고 성공하기는 어렵습니다.

안녕하세요. 곤님
경영층과 관리자들에게 소프트웨어 공학을 이해시키는 것이 제가 하는 일 중의 일부입니다. ^^
회사 내부의 개발자들의 말은 잘 안들어도 외부 전문가의 말은 설득력이 있습니다.
사실 개발자들도 고집이 세고 바뀌지 않으려는 사람도 많습니다. 이들을 바꾸는 것도 저의 일이지요.

안녕하세요. beyond j2ee님
티맥스 사례로 끝나지 않을 것입니다. 앞으로도 제2, 제3의 티맥스가 계속 나오겠죠.
이런 일이 나올 때마다 소프트웨어 산업이 신뢰를 잃고 후퇴하는 것이 문제죠.

한국인의 유전자에 뛰어난 창의성이 있는지는 몰라도 소프트웨어 필드에서는 그렇게 느끼기가 힘든 것 같습니다. 말씀하신 것들이 그 이유중 하나라고 생각합니다.

요즘 만나는 소프트웨어 회사의 경영자들은 소프트웨어 공학에 대해서 어느 정도 이해를 하고 있는 비율이 점점 높아지고 있는 것같이 느껴집니다.
약간 다행스러운 현상이라고 생각됩니다.

감사합니다.

안녕하세요. 고감자님
아직도 많은 사람들이 소프트웨어공학에 대해서 착각을 하는 경우가 많습니다. 소프트웨어공학은 이론이 아닌 실전이죠. 자칫 이론적인 방향으로 빠져드는 것은 경계를 해야 합니다.

안녕하세요. 오산돌구님
책이 모든 것을 해결해주지는 않지만 약간의 생각의 전환에는 도움일 될 겁니다. 디테일은 소통으로 해결하고요. ^^

curnell님 안녕하세요.
책 잘 보세요. 도움이 되기를 기대합니다.

안녕하세요. 현버미님
책 잘보시고 궁금하신 것이 있으면 언제든지 연락주세요.

그동안 우리나라에서 날고 긴다는 개발자들도 코딩능력이 뛰어난 것이지 실제 개발능력이 뛰어난 것은 아닙니다.
즉 소수의 인원 끼리는 제법 잘하지만 체계적으로 개발을 못하기 때문에 10명이 개발하나 100명이 개발하나 별로 나을 것이 없고 100명은 더 문제가 커집니다. 이것이 우리나라 일반 개발자들의 한계입니다.

이렇게 해서는 오래 못가죠.

책을 일고 계신다고 하니 도움이 되기를 바랍니다. 궁금하신 것이 있으면 언제든지 연락주시기 바랍니다.

영회님 반갑습니다.

구차니님 안녕하세요.
SI회사로 대표되는 대기업들의 문제는 또 다뤄볼 문제입니다.

BackToT님 안녕하세요.
병특인가요? ^^

정부의 지원은 필요악이라고 생각합니다.
워낙 환경이 열악하여 필요하기는 하나 별로 도움이 안되고 오히려 방해가 되는 경우가 많죠.

안녕하세요.
저는 티스토리에 제공하는 기본 폰트와 글씩크기를 이용합니다.
하지만 독자에 따라서 웹을 보는 환경이 너무 달라서 어디서 잘보이고 어디서 잘 안보이는지 저는 알 수가 없네요.
저는 IE, 불여우, 오페라, 사파리 두루 테스트를 하지만 그런 문제를 찾지 못했습니다.
웹을 보시는 환경을 정확하게 기술해주시거나, 화면을 캡쳐해서 보내주시면 도움이 될것 같습니다.

화면이 잘 보이지 않는 것은 폰트크기 때문일 수도 있으니 웹의 폰트를 키워보시는 것은 어떨까요?
브라우저마다 다르기는 하지만, Ctrl을 누르고 마우스의 트랙볼을 살살 굴리면 화면이 커졌다 작아졌다 합니다.
저는 글씨가 작아서 잘 안보이는 웹화면은 이렇게 봅니다.

그래도 문제가 해결되지 않으면 연락주세요. 감사합니다.

제 파이어폭스에서 글씨가 흐릿하게 보입니다만, 옵션에서 웹페이지에서 지정한 폰트를 사용치 못하게 하니 선명하게 보입니다.

립서비스로 연명하는 회사. ^^
립서비스 잘하는게 문제는 아니지만, 할줄 아는게 립서비스밖에 없다면 문제겠네요.

"투자는 없이 개발자를 혹사해서 연명하는 회사"는 건실하게 투자도 하고 개발자의 비전을 보여줄 수 있는 그런 중소기업을 덩덜아 망하게 합니다. 항상 저가 수주를 일삼아 정당한 비용을 받으려는 중소기업들을 아사하게 만들죠.

그래서 물귀신이라고 합니다.

Blackstone님 안녕하세요.
어려운 상황에서 개발자나 회사나 모두 솔직하면 좋겠네요. 나중에 상처만 남는 경우가 대부분이죠.

안녕하세요 moova님^^
소스코드를 오픈하는 회사는 특정 산업에 국한된 이야기 아닐까요..저는 반도체MES분야에서 일하고있어서그런지 소스코드를 오픈 한다는것 자체가 불가능하다고 생각되어서요.^^

1/2/3번은 공감할수가 없네요.
소스코드를 오픈하지 않는 회사가 사내에서 오픈하지 않는 것을 말씀하시는 것이라면 수긍하지만(그런 회사가 설마?), 사외에 오픈하지 않는다고 망해야 하는 회사라면, 애플도 망해야 하고, 구글도 망해야 하고, SAP도 망해야 하고, Oracle도 망해야 하고, MS도 망해야 하고... 대부분의 회사가 다 망해야 하네요. GNU를 존중하지만 GNU신도가 되어서는 안되지 않을까요?
2번은 코어 인력 빠져나가면 회사가 휘청하는 구조를 만드는 것보다는, 코어 인력을 안만들고 사내 시스템을 잘 만드는 것이 더 좋은 방법이라고 생각됩니다. 유능한 사원을 뽑는것도 중요하고, 무능한 사람 퇴출하는 것도 중요하죠.
3번은... On-Time이 중요한 요즘같은 상황에서 회사가 살려면 반드시 습득해야 하는 기술 아닐지요.

사내 개발자들에게도 소스코드를 공개하지 않는 회사는 의외로 많습니다. 보안핑계를 대곤 하는데 소프트웨어를 잘 이해 못하는 경영자에게는 이게 먹혀들어 갑니다.

안녕하세요. moova님
1,2,3번에 대해서 저는 처음보고 바로 이해했습니다.
워낙 짧게 쓰셔서 오해할 수 있는 사람도 있을 것이라고 생각은 했지만, 제가 이해한 것과 동일한 맥락으로 쓰셨군요. moova님이 누군지 개인적으로 점점 궁금해지네요. ^^

지연님 안녕하세요.
1:1 분석이므로 공유는 하지 않습니다. 설문에 참여를 하시면 참여하신 회사의 개발역량을 분석하여 문제점과 개선할 점을 알려드립니다.

무혹님 아쉬워 마세요. 남들보다 일찍 책을 보고 공부를 했으니 앞서간다고 생각하세요.
가장 비싼 것은 시간이니까요. ^^

안녕하세요.

삼성이 위치에 걸맞지 않게 소프트웨어는 잘 못하고 개발자들이 힘들게 일하는 것은 사실이지만, 우리나라 전체 소프트웨어 환경을 놓고 보면 삼성을 직장으로 봤을 때 상위권입니다. 상대적으로 높은 임금과 좋은 환경을 가지고 있습니다.

하지만 소프트웨어 개발자로서의 진정한 비전을 가질수 없습니다. 따라서 소속된 개발자라면 본인의 비전과 목표에 따라서 삼성이 좋은 직장이 될수도 있고 오래 있으면 안되는 직장이 될 수도 있습니다.

좋은 개발자가 되는 것을 목표로 삼성을 나와도 우리나라에는 갈만한 좋은 소프트웨어 회사가 별로 없습니다. 그래서 제 주변 사람들은 주로 실리콘밸리로 가더군요. 좋은 마인드를 가지고 그들의 개발문화를 어느정도 이해하고 영어가 어느 정도 된다면 충분히 가능합니다.
쉬운 조건은 아니죠. 이렇게 해서 실패한 사람들도 많습니다. 신중히 결정해야 할 것입니다.

소프트웨어 컨설턴트는 종류가 여러가지가 있습니다.
개별 기술에 대해선 컨설팅이 있고
체계화된 소프트웨어 공학 컨설팅이 있고
저는 실전 소프트웨어 공학 컨설팅입니다.

위에 것들은 어느정도 배우면 되지만 제가 하는 컨설팅은 실제 소프트웨어 개발 경험이 많이 필요합니다. 기간으로 따지만 3년이 걸릴수도 있고 10년이 걸릴 수도 있습니다. 삼성 같은 조직 내부에서는 배우기 어려운 것들입니다.

그래도 시스템은 좋은 것 쓰시나보네요. ^^

역설적으로 이전 개발서버가 출장갈때 썼던 센트리노 1.7Ghz 노트북이었답니다 ㅋ
그러던녀석을 듀얼코어 E5400으로 교체하니 날아 다닐수 밖에요 ㅎ

서버가 노트북이라니...
그럼, 개발/빌드/테스트 장비는 잘 분리되어 있나요?

개발+빌드+테스트 죠 ^^;
임베디드이다 보니 엄밀하게 테스트를 구분하기는 모호한거 같아요.


서버가 노트북이라니.. 라고 생각하시기 보다는
어떤면에서는 중소규모 기업에서는 노트북을 서버로 쓰는게 어떤 면에서는 더 좋은거 같다는 생각이 듭니다.

성능/가격으로 따지면 일반 데스크탑 서버가 좋겠지만
UPS를 감안하면 노트북이 더 나을수도 있으니까요. 그리고 UPS는 끽해야 30분인데 노트북은 2시간은 버티잖아요 ㅎ 아무래도 임베디드 쪽은 실수하면 전기나가는게 다반사라 서버가 정전으로 인해 먹통이 되는것 보다는 안정적인 작동이 가능한 노트북이 UPS없는 서버보다는 낫지 않을까 생각을 한답니다.

보통 임베디드 개발은 빌드 시간이 짧아서 높은 성능의 서버가 필요하 않을 수 있겠네요.
하지만 임베디드라고 하더라도 빌드, 테스트는 구분해야 합니다.
그렇지 않으면 dirty environment가 됩니다.
조직이 구분되어 있지 않으면 대충 섞어 쓰는 경우가 많지만, 이런 경우라도 적절히 구분해야 합니다.

DoubleJ님 안녕하세요.
소프트웨어에 대한 이해와 Long term view가 필요한데 경영자들에게 기대하기 힘든 것들입니다.

안녕하세요. 반디숲지기님
"피플웨어" 좋은 책이죠. 우리 현실에 안맞는 부분이 약간 있지만, 생각할게 많은 책입니다.
경영자들에게 이책은 너무 Gap이 커서 도움이 될지 걱정이기도 합니다. ^^ 경영자들은 대부분 너무 단기적이 이익이 집중하거든요.

창천님 안녕하세요.
사장님께 보고하고 결과 꼭 알려주세요. ^^

용훈님 안녕하세요.
감사합니다.

별군님 안녕하세요.
사실 투자대비 효과가 큰 것들만 적었기 때문에 윗분들이 더 공감해야 하는데 현실은 그렇지 않은 것 같습니다.

BackToT님 안녕하세요.
나중이 이런 CEO가 되시는 것은 어떨까요?

아름드리님 안녕하세요.
제가 회사를 만들면 블로그에 공지를 하도록 하겠습니다. ^^
그때 Apply해보세요. 감사합니다.

라라윈님 안녕하세요.
재미있는 블로그를 가지고 계시네요. 바로 RSS Feed 등록했습니다. ^^

그 의자... 저도 욕심나는데요. ^^
저는 지금 듀오백에서 가장 비싼 의자를 쓰고 있는데, 허리는 보호를 해주긴 하는것 같은데 그렇게 편하지는 않네요.

청하님 안녕하세요.
전 빵이라도 감지덕지네요. ^^
변하는 사람은 좋은 마인드를 가진게 아니고 그런 척한게 아닐까요? 진짜 아는게 아니고 아는척하는 거죠.
위에서도 언급했듯이 적절한 투자라는 것이 회사마다 다르기 때문에 절대 기준은 없습니다.

꼬미님 회사에서 의자 안사주면 개인돈으로도 사세요. - -;

이사님 오랫만입니다.
이글은 말씀하신 주제와는 거리가 있는 글입니다. 투자효율성에 대한 글이죠. 좋은 주제라고 생각합니다. 나중에 꼭 다뤄보죠. 감사합니다.

tack님 안녕하세요.
개발자도 매너리즘에 빠지는 경우가 많죠.

blackstone님은 회사 경영자이신가요? 아님 개발자?

아직도 많은 경영자들이 관성화된 야근의 장기적인 피해를 모르고 있습니다.
하지만 이를 피하려면 먼저 제대로 된 시스템과 프로세스와 개발자들이 역량이 뒷받침되어야 합니다.
닭이 먼저냐 달걀이 먼저냐 하는 이슈죠.

안녕하세요. 피요히코님
RSS feed 등록해놓고 보시면 편리합니다.

안녕하세요. Beyond J2EE
또다른 문제는 소프트웨어 분야에서 문제가 많음에도 불구하고 삼성이 잘해왔다는 겁니다. 최근 스마트폰이 대두되면서 문제가 되고 있기는 하지만 지금까지 겉으로 보기에는 잘 해왔습니다.
그래서 더욱 경영층들이 설득이 알될 가능성이 높습니다.

안녕하세요. 구차니님
지금까지 왜 이렇게 되어 왔는지 이해는 되지만 안타깝죠.

안녕하세요. 크레브님
그나마 최선의 방법을 제시한 것이지만 이렇게 되지 않을 확률이 훨씬 높아 보입니다.

moova님 안녕하세요.
실리콘밸리의 소프트웨어 회사에 가서 "너희 방법론은 뭐냐?"라고 물어보면 대부분 그런거 없고 그냥 개발한다고 합니다. 요즘은 Agile에 관심이 좀 있기는 하더군요. 하지만, 자신의 회사에 맞게 이거 저거 섞어서 사용하기 때문에 특별한 방법론은 없습니다.
그래도 스펙을 가장 중요시하는 것은 여전합니다. 뭐하나 개발을 해도 스펙을 꼭 작성하고 리뷰를 한 후에 개발을 하죠.

정말 획기적이고 기발하고 어렵고 새로운 것은 별로 없습니다. 아이디어는 새로울 수 있으나 소프트웨어를 개발하면서 사용하는 기술들의 99%는 그렇지 않습니다. 새로운 기술이라면 바로 프로젝트에 적용할 수 없죠. 이를 검증하는 프로젝트가 별도로 필요하곤 하죠.

신기술이라면 바로 프로젝트에 적용할 수 없다는 것에 공감합니다. 그것에 더해서, 신기술에 대해 기술적 검증이 필요한 기간은 꼭 필요한 것 같습니다. 신기술이라고 해서 장담할 수 없는 것 중에 하나가, 기존 사례가 미약해서 쉽게 계약이나 결정을 못하는 것은 어떻게 보면 당연한 것 같습니다. 하지만, 사례가 많다면 여러가지 장점을 취할 수도 있겠습니다.

안녕하세요. 구차니님
우리들이 바꿔나가야 하겠죠. 아자.

이슈와는 거리가 먼 답글입니다만..
소프트웨어 개발자로써 종사하는 사람임에도 "무른모"가 무슨 뜻인지 몰라서 사전을 찾아봤습니다.
소프트웨어를 의미하는 말이더군요. 색다른 표현을 알려주신것에 대해 감사드립니다. (__)a

"무른모"란 용어를 안다는 것은 오래된 개발자라는 뜻?
한때 외래어 한글화 일환으로 여러 단어들의 한글화가 시도되었었죠.
누리꾼, 댓글 등 자리잡은 단어들도 많은데 "무른모"는 소리소문없이 사라졌네요.
그런데, 한글화의 문제점이 일반인은 좋지만, 개발자 입장에서 두 단어를 모두 알아야 하는 단점이 있죠. 그래서 그냥 영어를 그대로 쓰는게 개발자에게는 편하긴 합니다.

소프트웨어 산업의 고질적인 문제를 더 언급하셨네요.

저가 수주에 따른 저가 하청 및 재하청
불합리한 갑/을 관계
소프트웨어의 가격을 쳐주지 않는 관행 및 불법복제
정부 지원금 및 이것으로 연명하는 기업들

블로그가 있으면 좀 알려주시지요? 감사합니다.

무른모..라는 말이 먼저 나왔는지 모르겠는데 한참 그말이 널리 쓰이려는 즈음에 "씨앗" 이라는 순수 한글 풀그림 언어도 있었죠. 한때나마 이 척박한 땅에서도 나무를 키워 숲을 이룰수 있다고 생각해본 순진한 시기였습니다만...

안녕하세요. 영회님 오랫만이예요.
요즘도 블로그 잘 보고 있습니다.

안녕하세요. Beyond J2EE님
많은 경영자들이 개발자를 단순히 도구로 생각하고 있습니다. 공장에서 조립라인의 직원 생각하듯히 하는 경우가 많습니다.

안녕하세요. 자바지기님
아직 저변이 부족해서 그런 것 같습니다. 요즘 스마트폰이 관심의 대상이 되면서 삼성전자의 부진이 이슈가 되고 그 원인으로 소프트웨어가 대두되고 있는 상황입니다. 이런 일이 반복되면 소프트웨어에 대한 시각이 바뀌는데 일조하지 않을까 생각합니다.

안녕하세요. BackToT님
"토론문화" 중요하죠. 소프트웨어 개발하는데 있어서 정말 중요한 요소입니다.

청하님 안녕하세요.
소프트웨어 문화 막상 보면 별거 아니고 다 아는 것처럼 보입니다. 하지만 교과서에서 보고 아는 것과 오랫동안 해와서 몸에 익은 것은 하늘과 땅 차입니다.

안녕하세요. Mr봉쿠레님
감사합니다. 사실 별로 부지런하지도 않습니다. - -;