달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2009. 2. 10. 21:06

백발이 성성한 개발자 Computing에 관한 독백2009. 2. 10. 21:06


책 사고 싶단 소리가 아닙니다.
이 책 쓴 분 연배가 어찌 될 듯 합니까?
오늘 이 책 표지 보고 참... 놀랬습니다.

정말 백발이 성성한 개발자가 있구나....
백발이 성성해서도 책까지 쓰는 정력적인 개발자가 있긴 있구나...
도데체 이들 나라는 어떻게 이런 게 가능할까...
왜 우린 이런 사람이 없을까...
이런 사람이 없는 우리 사회가 좋은 사회일까...

백발 성성한 개발자가 우리나라에도 꿈이 아니고 현실인 날이 얼른 왔으면 좋겠습니다.

쩝.
:
Posted by 하얀 말
2008. 9. 25. 04:31

하얀말의 미투데이 - 2008년 9월 25일 篇隣2008. 9. 25. 04:31

이 글은 하얀말님의 2008년 9월 24일의 미투데이 내용입니다.

:
Posted by 하얀 말
  • Google Chrome 설치 문제 경험담이다. beta라도 Game은 이랬다간 회사 게시판에 욕이 한가득인데, 이 글 쓴 분은 비판적이어도 전반적으로는 Chrome에 우호적인 것 같다. 정말 신기하다. Google이 이걸 돈 받고 팔 생각이 없어서 그런가?(Google Chrome BetaTest 역시10원이라도받으면반응이틀려)2008-09-09 09:31:39
  • ㅋㅋㅋ~. 개발자가 CIO를 바보라고 생각하는 이유라~. CIO뿐 아니라 개발자들 데리고 일하시는 분들은 새겨 들을 이야기!(개발자 CIO 개발자가CIO를바보라여기는이유)2008-09-09 11:19:41

이 글은 하얀말님의 2008년 9월 9일의 미투데이 내용입니다.

:
Posted by 하얀 말
전산과를 나와서, 곧 퇴사할 것이긴 하지만, LG CNS를 7년 6개월 정도 다닌 사람 입장에서 SI는 소프트웨어 개발자의 적인가?라는 글을 보았을 때, 참, 공감 가는 이야기다 싶었다(위 글에 나오는 업체 임원이 혹시 LG CNS?). 이 정도 경력이면 개발자가 바라본  SI 업체에 대해 썰 풀 자격 정도는 있다 싶어 이야기를 해보면...

일 단 SI업체는 기술로 돈 벌어먹는 회사가 절대 아니다. 만약 SI업체가 기술로 돈 벌어 먹는 회사면 개발자들은 그들의 핵심 역량이고, 따라서 기술 인력 양성에 심혈을 기울여야 한다. 그러나 징허니 잘 아시겠지만 그들은 개발자를 인력 파견 업체에서 고용한다. 핵심 역량은 절대로 아웃소싱하는 것이 아님은 경영의 기본이다. 그들이 그런 것을 모를 리 없고, 따라서 기술 및 기술 인력은 그들에게 핵심 역량은 절대 아니라는 사실. 그들이 필요로 하는 기술 인력이란, 아웃소싱한 기술자들과 의사 소통을 하고 작업 지시를 하고 일정 대비 진척률을 측정하여  작업이 처지면  독려하고(이 독려 방법이 참.... 휴가 반납, 끝없는 야근이란 것이지만서도), 문제 때문에 끙끙대면 해결사 역할을 할 수 있는, 대단히 프로젝트 관리자적인 사람을 뜻한다. 이런 일을 하기 위해서 기술 이해가 필요하고, 그래서 사원, 신입 때는 기술을 가르치긴 한다만. 그래서 대부분 SI업체에서 짬밥이 차면 점차 프로젝트 관리자 같은 일을 하게 된다.

미리 말한 것 같은데, SI업체는, 건설 분야로 치면 시공사가 아니라 CM을 하는 회사이고, 따라서 프로젝트 파이넌싱, 인력 소싱, 고객의 요구 사항 분석 및 그에 따른 가격 산정, 공정 및 진척률 관리, 프로젝트 비용을 관리하여 이익을 남기는 것이 핵심 역량이다. 따라서 그들에게 있어 기술 인력은 '언제나 조달 가능한 자원' 이상은 아니다. 그러나 실제 product는 그들 손 끝에서 나오고, product를 만드는 자가 있어야 SI의 핵심 역량도 할 일이 있는 것도 사실인데, 그걸 간혹 모르는 것 같단 말이지.

그들에게 있어 소프트웨어 개발은 공학(Engineering)이고 공학은 자연을 가공하여 유용한 것을 얻기 위함이 목적이고, 특히 산업 공학은 이러한 공학을 효율적으로 관리하기 위함이 목적이다. 공학이나 관리를 하려면 측정부터 시작을 해야 하는데, S/W란 것이 정말 무형의 것이다 보니, 이 측정이라는 것이 쉽지 않다. 정성적인 것을 정량적인 것으로 환산하면서 겪은 어려움이 여기서도 나오는데(이를테면 기업의 브랜드 가치를 돈으로 환산해서 마이크로소프트나 나이키의 브랜드 가치는 얼마내 하긴 하지만, 솔직히 그게 정말 현금 세는 것처럼 정확하다고 자신있게 말할 수 있나? 가격은 시장에서 결정나는데 그런 브랜드는 거래하는 것이 아니니 말이다) LOC(Line of Code), COCOMO, 기능 점수(functional point) 등 가지가지가 나오지만 정말 한 방에 사람들을 '아, 이거다~' 싶은 측정 체계(metric)가 없다. S/W 개발이 과연 공학적인 접근이 가능한 일인가 하는 주제는 이 글의 범위를 후딱 넘어버리니 이쯤하고, 문제는 SI업체들이 S/W 공학의 신봉자들인데 그럴 수 밖에 없는 것이, 그들은 개발사가 아니라 관리하는 회사기 때문이다. 그러니 공학적인 접근으로 S/W를 만드는 관리 체계 및 측정 체계를 제공한다는 방법론이나 S/W 공학에 매달릴 수 밖에.(SI project를 하다보면, 그 일하는 체계가 정말 건설/토목사의 그것과 너무도 흡사하다. 심지어는 시공사, 감리사 같이 사업자와 감리사가 있다).

그러다 보니 그들은 S/W Factory라는 말에 솔깃할 수 밖에 없고, model만 그리면 product가 나온다는 MDA에 혹하며, 마치 그것을 S/W 개발의 미래라고 부르짖게 되는 것이나, 실제 개발해 보신 분은 아시겠지만, 그 변덕스러운 고객의 요구 사항을, ERP도 뜯어고치라고 하는 그 변덕을 과연 그런 것으로? 아울러 MDA라는 것도 웃기는 것이, LISP이나 Scheme 같은 함수형 언어는 어떻게 UML로 표현할 것이며, Python이나 Ruby 같은 언어에 대한 UML Profile은 만들 수 있는겨? 동적 type이라는 이들 언어의 특성은 단순한 객체 지향 관점에서만 커버하기는 쉽지 않을 것이다. UML은 product를 만들기에는 그 표현력이 모자라며, 그 간극을 메꾸기 위해 UML에도 무언가가 마구 추가되긴 하는데, 사람 기를 질리게 한단 말이지. MDA의 허구를 논하면 또 글의 주제를 넘어버리니 이만하고, 여하튼 그들은 말도 안되는 것을 바라고 믿는데, 그 이유는 S/W 개발의 자동화를 간절히 바라기 때문이다. 그렇게만 된다면 S/W 생산 line만 관리하면 되고 개발자는 필요 없기 때문이다(그러나 그 행동이 연목구어임을 알기에 절대 쫄지 않는다. 앞으로도 그들은 계속 인력 구하고 다닐 것이다. 대신 지금과 같이 대우는 안하겠지).

말이 상당히 길어졌는데 결론은 다음과 같다.

SI업체, 전산과 나와서 개발자로 크려면 가지 마라!
단,
대기업 가고 싶어 SI 업체 갈 것이면 사원,늦어도 대리까지만 다녀라.


SI업체, 산공과나 경영과(특히 MIS 전공) 나왔다면 괜찮다!
단,
다 임원 되는 것은 아니라는 것을 명심하라!
(이 과 출신들은 자기가 다 임원하는 줄 안다니깐 --)
=================================

이전 블로그에서 2007.5.30에 쓴 글
:
Posted by 하얀 말