천객만래 [千客萬來] (It has an interminable succession of visitors)

[연봉통계] 2007년3월 소프트웨어,솔루션,ASP분야 직급별

jobkorea.co.kr










Posted by SB패밀리

[연봉통계] 2007년3월 소프트웨어,솔루션,ASP분야

출처 : jobkorea.co.kr


경력년차별 연봉차이...








Posted by SB패밀리



'SW 마에스트로' 연수생 구글 본사 방문… 선배들과 간담회

2011년 01월 07일

"좋은 소프트웨어(SW) 개발자의 조건은 명문대 졸업여부가 아니라 창의력과 문제에 접근하고 해결하는 능력이다.", "초가집을 수 백 채 지어봤다고 63빌딩을 건설할 수 없다. SW 개발도 우선 역량을 크게 키워야 한다."

실리콘밸리를 방문한 한국의 SW 꿈나무들에게 미국 구글 본사에서 근무하고 있는 한국인 SW 엔지니어들은 창의력을 바탕으로 더 높은 곳으로 비상해야한다고 조언했다.

5일(현지시간) 지식경제부, 정보통신산업진흥원, 한국정보산업연합회 등이 주관하는 SW 마에스트로 미국 연수의 일환으로 구글을 방문한 학생들은 직원들의 언제든 즐길 수 있는 게임기와 카페테리아 등 자유로운 업무환경을 돌아봤다. 이어진 구글 본사에서 근무하고 있는 한국인 SW엔지니어들과의 간담회에서는 선배들의 조언이 쏟아졌다.

SW엔지니어인 전지운 씨는 "코딩과 프로그래밍 능력은 물론 창의력과 문제에 접근하고 해결하는 능력이 중요하기 때문에 미국에서는 SW 개발자를 뽑는데 창의력과 문제 해결 능력 등에 중점을 두고 평가한다"며 "알고리즘과 자료구조 등이 중요한데 책만 본다고 이런 능력이 생기는 것이 아니므로 프로젝트를 하면서 문제 해결 능력을 배양해야 한다"고 말했다.

김용성씨는 "초가집을 수 백 채 지어봤다고 63빌딩을 지을 수 있는 것이 아닌 것처럼 SW 도 SW를 잘 개발하는 역량이 있는 기업에서 배워야 한다"며 "SW 마에스트로 과정을 통해 큰 프로젝트들을 진행해 보는 것도 도움이 될 것"이라고 조언했다.

SW 마에스트로 연수단 학생들은 구글의 SW 개발 여건에 많은 관심을 나타냈다.

이에 대해 김용성 구글 SW엔지니어는 "미국과 한국의 SW 개발 환경의 차이는 관리 대상이 다르다는 것"이라고 설명하고 "한국에서는 SW를 개발할 때 사람을 대상으로 관리하는데 구글 등 미국에서는 일의 성과를 중심으로 관리한다는 점이 다르다"고 말했다. 또 "구글 등 미국 기업들의 자율적인 SW 개발 환경에 대해 동경하는 이야기가 많은데 실제 일의 강도와 업무는 한국보다 더 높다"며 "이는 업무를 믿고 맡겨서 밀어주는 환경이 업무 집중도를 높여주기 때문"이라고 설명했다.

한국인 구글 SW엔지니어들은 후배 개발자들에게 문제 해결 능력을 배양하는 것이 중요하다고 입을 모아 말하고 시야를 넓게 갖고 큰 꿈을 가지라고 충고했다

출처 : http://www.dt.co.kr/contents.html?article_no=2011010702010660739004




실제로 사회에서 개발자로 직장을 다닌다는건 .. 학생 때와는 다르게 프로다운 마음가짐이 필요합니다.
신입일 때는 내가 못하면 위에서 봐주면서 대신 처리해주지만 갈수록 책임감이 늘어갑니다.
즉, 문제가 주어졌을 때 해결해야한다는 것이죠. 차선책이라도 꼭 만들어야 한다는 겁니다.
가정의 가장일 경우도... 책임감은 날로 늘어가면서 가정을 지키기 위해서는 문제가 있을 때마다 해결해야한다는
압박감이 큽니다. 개발자이건 아니건 문제해결능력이라는건 그사람의 역량과도 직결되는 문제이니 간과해서는 안됩니다.


Posted by SB패밀리

고객의 마음은 갈대와 같다 
2004.06.11 10:44  

류(ryujt)   http://cafe.naver.com/codeway/139 


  소프트웨어 개발에 가장 큰 위험요소는 역시 “변화”이다.  그 동안 소프트웨어 공학은 이 변화의 요소를 최소화하고 억제하는 방법을 연구해왔다.  개발방법론을 내세워서 모든 프로세스가 제대로 통제되고 돌발상황이 발생하지 않기를 애태우며 기대해왔다.  하지만, 그 기대는 처참히 무너져 버렸다.  그 어떠한 개발방법론도 “소프트웨어 판타지”를 완성할 수는 없었다.

  근래에 들어서는 “수용”과 “통제”가 이슈가 되고 있다.  그리고 “요구사항은 반드시 변한다.”라는 대 명제에서부터 출발하고 있다.  보다 적극적으로 고객의 요구사항을 수용하고 서로 승리자가 되는 길을 모색하고 있는 것이다.

  하지만, 여전히 승리의 길은 너무 험난하고도 멀다.  그 이유는 해결책을 찾고 있기 때문이다.  특효약을 찾아 헤매고 있기 때문이다.  나는, 그 무엇보다 지금 우리에게 필요한 것은 언제나 상황을 “냉철하게 판단할 수 있는 여유”라고 믿는다.


1. 갈대의 마음을 사로 잡아라

  “불신지옥 믿음천당”

  아!  이 얼마나 명쾌한 표현인가?  일단 고객과의 관계에서 불신이 싹트는 순간 그 프로젝트는 지옥으로 떨어지고 만다.  갈대의 마음을 사로 잡아야 한다.  하지만, 어떻게?  항상 변하는 갈대의 마음에 화답하기란 그다지 쉽지만은 않다.  아니 어쩌면 처음부터 불가능했을 지도 모른다.

  갈대의 마음을 사로 잡기 위해서 가장 조심해야 할 것은 대책 없는 약속들이다.   고객은 자주 묻는다.

  “이거 이렇게 할 수 있어요?  저건 저렇게 가능한가요?”

  개발자는 쉽게 대답한다.  물론이라고.  하지만, 여기서부터 지독한 오해의 골짜기를 파기 시작하다가, 결국 프로젝트 종반에서 스스로 그 무덤 속에서 헤어나오질 못하게 된다.

  고객이 묻는 것은 여러분들의 실력과 가능성이 아니다.  자신이 그 기능을 가질 수 있는 지에 대한 물음이다.  나는 여러분들의 실력이 그러한 것들을 이루기에 충분하다고 믿어 의심치 않는다.  하지만, 인생은 앞을 알 수 없다고 했다.  프로젝트는 때로 개인의 인생보다 복잡하다.  언제 무엇이 어떻게 벌어질지 아무도 모른다.  여러분들은 이미 경험으로 알고 있을 것이다.  여러분들이 내뱉은 약속은 절반도 지켜지지 않을 것이며, 결국 여러분들의 고객의 마음을 사로잡기는 실패로 끝날 수 밖에 없을 것이다.

  고객은 개발 초기에 상당히 우호적이다.  그리고 시간이 지날수록 원수가 되어 간다.  고객의 마음을 끝까지 사로 잡기 위해서는 초기 고객이 우호적일 때를 이용해야 한다.  개발이란 얼마나 어려운 것인지, 부실공사가 주는 피해가 얼마나 큰 지를 그들에게 알려줄 절호의 찬스인 것이다.

  요구사항을 통제하는 활동들이 고객과 개발자 그렇게 우리 모두를 위한 길이라는 신념을 심어주어야 한다.  여기서 신념은 물론 허울뿐인 신념이 아니다.  고객에게 잘 보이면서 무사히 프로젝트가 끝나길 기도하지 말라.  고객 스스로가 그렇게 해야 할 수 밖에 없다는 것을 깨닫게 하고, 스스로 선택하도록 만드는 것이 바로 여러분들의 몫인 것이다.

  갈대는 신념이 없기에 불안한 것이다.  그래서 흔들릴 수 밖에 없는 것이다.  흔들리는 갈대와 함께 행복한 결말을 기대하려면, 믿음을 심어주는 수 밖에 없는 것이다.  그리고 그 믿음과 신념은, 명확한 비전을 제시할 수 있을 때 비로서 얻을 수 있는 것이다.

  나의 개발일정에는 항상 초기에 “고객에 대한 개발방법론 강의”가 들어있다.  이것이야 말로 고객과 내가 함께 승리할 수 있는 목표를 제시하는 첫걸음이라고 생각한다.


2. 여자는 원하는 것을 말해주지 않지만, 해주지 않으면 화낸다.

  고객은 항상 말한다.  “알아서 해주세요.”  고객은 기술에 있어서 스스로 모르는 분야라고 판단하고 난 후 뒷짐을 지기 시작한다.  또한, 개발자에게 모든 희망과 기대 그리고 책임을 맡겨 버리게 된다.  자신이 어떻게 할 수 있는 일이 아니라는 신념이 있는 한, 어쩔 수 있겠는가?

  문제는 고객은 자신이 진정 원하는 바가 무엇인지 모른다는 사실조차 모른다는 것이다.  고객은 자신이 원하는 시스템을 상당히 단순하게 생각한다.  여러분들은 가끔 여러분들의 심장을 관통하는 구인 글을 많이 보아왔을 것이다.

  “아주 간단한 건데요..”

  이것은 지극히 당연한 결과일 수 밖에 없다.  이러한 것으로 불현듯 폭발하려는 짜증을 느낀다면, 그대는 아직 도(道)를 깨우치지 못한 것이다. ㅡ.ㅡ  고객은 시스템을 깊이 이해할 수 있는 능력이 없다.  당연하지 않는가?  그러니 모든 것이 지극히 단순해 보일 수 밖에 없다.  개발자가 바라 볼 때 빙산의 일각이라고 생각하지만, 고객은 그것이 전부라고 느낄 수 밖에 없는 것이다.

  막연한 기대감.  그것이 고객이 항상 자신이 원하는 바를 알려줄 수 없는 이유가 된다.  막연함 이외에는 고객의 마음 속에 아무것도 없기 때문이다.  그러나 그 막연함의 유연성은 상당히 획기적이다.  어디에 붙여도 잘 들어 맞기 때문에, 코에 걸면 코걸이 귀에 걸면 딱 귀걸이다.

  해결 방법은 지극히 간단하다.  고객은 여자가 아니다.  개발자의 정성만으로 감동 받지 않는다는 것이다.  따라서, 고객이 진정으로 원하는 것을 추측하여 개발을 진행해서는 안 된다.  고객의 앞을 가로 막고 물어봐야 하는 것이다.

  “이 도끼가 니가 원하던 것이냐?  아니면 이 도끼가 니가 원하던 것이냐?”


3. 그리고 이제는 개발방법론이 필요하다

  이제 여러분들은 고객의 믿음을 얻었고, 고객이 원하는 바를 구체적으로 물어보고 확인해야 하는 이유를 알았다.  그러면 이제는 어떻게 해야 할 것인가를 생각할 때이다.  이에 대한 거론은 너무나 어렵고 긴 시간이 필요하기 때문에 여기서 나는 비겁한 결말을 지으려고 한다.

  아래는 본인의 추천서적들이다.  이를 통해서 스스로의 환경에 맞는 자신만의 개발프로세스를 만들어보기 바란다.  본인 또한 언젠가 능력이 향상된다면 보다 구체적인 이야기를 마무리 짓도록 하겠다.  여러분들이 읽어봤으면 하는 순서대로 나열하였다.

  제목 : Professional 소프트웨어 개발
  출판사 : 인사이트

  제목 : 프로젝트 매니지먼트
         (원제 : 10 Minute Guide to Project Management) 
  출판사 : 피어슨에듀케이션코리아

  제목 : 초보자를 위한 eXtreme 프로그래밍
  출판사 : 인포북

  제목 : 소프트웨어 프로젝트 생존 전략 
  출판사 : 인사이트

  제목 :  Rapid Development
  출판사 : 한빛미디어

  제목 : Software Requirements 2nd Ed
  출판사 : 정보문화사

  제목 : CMM
  출판사 : 피어슨에듀케이션코리아

  제목 : 구현사례를 통한 CMM 이해
  출판사 : 피어슨에듀케이션코리아

Posted by SB패밀리
영업하는 직원이 어떤 상품을  팔 건데 이 기능은 되냐? 라고 물으면
개발자가 어떤 대답을 하기를 원할까?

당연히, 영업하느라 수고 많다며 회사가 당신 때문에 돌아가는거 같다며
영업에 필요한 건데 당연히 기한내에 현재의 인력과 비용으로 해 드리겠다고 하면
만족스러운 답이겠지.

하지만, 현실은 그렇지가 않다.
아침에 아내에게서 들은 이야기가...

영업부장님 요청하신 말씀처럼 다 할 수 있는 건 아니다.
우리가 냉장고를 만든다고해서 당장 에어컨의 기능을 발휘할 수 있는 건 아니지 않냐.

그렇다. 영업직원들은 마이더스의 손이라고 생각하는 건지 다 된다고 한다.
그것도 개발직원에게 문의해 보지 않고 말이다.

LCD TV 를 만드는데... 마케팅과 영업정책이 맘에 안든다거나 더 잘 해주려고 엔지니어가 
맘대로 스마트 TV 기능을 추가했다고 하자. 칭찬을 받을까? 
TV를 가볍게 하는 대신에 두께를 2cm에서 2.5cm로 늘렸다고해서 좋아할까?

마케팅과 영업정책이 모조리 바뀌어야 한다.
시장의 네트워크 구축이 어려운 만큼 변화를 두려워하는 영업직원이 신나서 좋아하지는 않을것이다.

이렇듯 내가 잘났다 니가 못났다하는 네가티브한 싸움은 지양하고
영업이나 개발 모두 잘 되어야 지속적으로 성장하고 혜택도 누릴 수 있다고 생각한다.
영업직원이 고객사에 된다고 말해버린 기능이 왜 개발자가 안된다고 하는지 이유를 물어봐야한다.
그리고 그들 입장에서 이해하려고 해야한다. 반대로 개발자는 왜 영업직원이 된다고 말했는지 이해하려고
해야한다. 고객이 사용하기 위한 솔루션을 제시하는게 영업직원과 개발직원 모두의 목적이기 때문이다.

서로간에 문의를 하러 오는 경우에는 친절하게 설명해주고 되면 되는대로 안되면 안되는 대로
이유를 설명해주고 해결방안을 모색해야한다.
그것도 함께... 주도하는 부서가 다를 뿐이지 동반자가 아닌가.

영업이나 개발자가 함께 수년이 지난 후에도 그 때가 일하기 좋았어라는 생각을 할 수 있도록 해야한다.
모두가 다시는 함께 일하고 싶지 않은 자로 또는 최악의 협업자로 선택되고 싶지는 않을 것이기 때문이다.

자, 지금부터라도 나와 일하고 싶은 사람들로 주변을 가득채우고 싶지 않은가? 
Posted by SB패밀리
[작업] Internet Explorer 주소창 검색 기술 개발

얼마전 인터넷 익스플로러어 주소검색창에서 키워드를 입력하면 검색엔진을 이용하여 사용자에게 유익한 검색결과를 보여주는 프로그램을 제작했다.

여기서, 단지 주소창 검색은 쉬워보였었다. 연초에 만들어 보았더니 쉽게 되어서 별거 아니구나 했었는데 이번에 개발하는데 무지어려웠다.

이미 공개된 소스들로는 로직만 사용될 정도였다. 제대로 구현되지 않아서는 세상에 공개할 수 없는 작품이었다.

윈도우즈 7이 나오면서 무지 어려워진것이다.
그리고 IE 버전별로 이렇게 동작과 구성이 다를줄 몰랐다. 결국 win xp와 win 7기반에서 IE버전별로 모조리 분석을 했다.

여러차례의 시행착오를 거쳤다. 그리고 결국 만들어 냈다. 그런데, win 7 ultimate 버전이 말썽이었다. BHO로 동작하면서 win 7의 UAC에 막혀서 고전을 했다.

하지만 이것도 결국 이겨냈다.
그래서 IE 6~9 모든 버전과 win xp, win 7 모두에서 주소창 검색이 동작하는 주소창 검색 솔루션을 만들었다.

추석연휴까지 반납했었는데...
된다고 믿었고 나 하나가 아닌 함께하는 사람들을 떠올리면서 이루어낸 것이라 생각했다.

추석에 못 찾아뵌 가족들은 이후 찾아뵈었다.
이 성과물이 나와 함께하는 분들에게 좋은 결과를 가져다 줄 것이라 믿는다.

많이 도와준 분들도 약간 도와준 분들도 나에게 모두 고마운 분들이다. 고마운 마음으로 계속해 나갈 것이다.
Posted by SB패밀리

두서없이 정리된 용어이다. 기본기가 있어야 더욱 더 커뮤니케이션과 실무가 쉽다.


beta version [베타 버전]
소프트웨어를 정식으로 발표하기 전에 미처 발견하지 못한 오류를 찾아내기 위해, 회사가 특정 사용자들에게 배포하는 시험용 소프트웨어. 베타 버전은 시간이 경과하면 사용하지 못하도록 장치가 되어 있거나 정식 제품이 아님을 표시하는 문구가 표시되어 있는 경우가 많다.

Alpha Version [알파버전]
개발 도중의 하드웨어/소프트웨어에 붙는 제품 버전. 개발 초기 단계에서 개발 기업 내 또는 일부의 사용자에게 배포하여 시험하는 초기 버전으로, 일반적으로 불안정한 상태에서 알파 시험(Alpha Test)을 거쳐 문제점을 보완 한 후 다음 단계인 베타 버전으로 진행한다.

시스템 담당자 구분
H/W담당자 : 네트워크, 컴퓨터 및 coat를 관리
Application 담당자 : 업무지원을 위해서 개발 혹은 도입된 소프트웨어 담당자
운영담당자 : 일반사용자에게 업무를 원활하게 지원할 수 있도로고 각종 주요 데이터를 관리

개발 방법론
패키지 솔루션을 적용하여 고객의 Needs에 맞도록 재구축하는 방법론.
어플리케이션 시스템을 구축하는 방법의 사례에서는 라이프사이클에 따른 업무 수행방법과 산출물을 표시하여 효율적인 개발과 유지보수가 되도록 지원하는 체계

산출물 관리방법
산출물에 대한 형상관리 대상인지 표시

reversion : 변경 전후 내용
final : 최종결과
history : 변경이력

제안서
제품설명과 고객의 현재와 미래를 기술한 문서

제품설명서
패키지 솔루션을 고객이 경영전략과 업무전략 차원에서 설명한 자료와 ITA(ISP)측면에서 설명한 자료

컨설팅
도메인 부분의 지식과 솔루션을 이용 고객의 업무효율을 증진시키는 일

형상관리
시간에 따라 문서나 소프트웨어 하드웨어의 변경을 추적하고 관리할 수 있도록 변경사유와 내용을 지속적으로 관리업무

BPR
Business Process Reengineering, 기업내 비효율적인 요소를 파악하여 업무를 재구성하여 업무효율을 높이는 경영전략

Package
비즈니스 도메인 영역의 내용을 미리 구축하여 적용시간을 단축한 소프트웨어 산출물

PI
Process Innovation, 업무 효율을 높이기 위한 업무의 간소화 재구성 추진 업무

PL
Project Leader, 프로젝트에서 PM의 영역을 지원

PM
Project Manager or Project Management, 프로젝트 관리인력 또는 방법

솔루션
고객의 니즈를 반영해 해결할 수 있는 업무 지원 방법이나 도구.
1)기대하는 기능을 구현할 수 있는 정보와 기술력
2)기대하는 기능을 수행할 수 있는 제품을 가진 경우

staff
프로젝트 지정된 담당자들

stakeholder
프로젝트에 관련된 이해 당사자들, 공급자와 고객에게 프로젝트나 결과에 관계되는 모든 사람으로 시스템 운영자도 포함

 

Posted by SB패밀리