최근 프로젝트 분위기

최근의 프로젝트 분위기를 보면 어느때 보다
최악의 한해를 보내고 있는 것 같습니다.
1월부터 3월까지는 비수기라 치고
4월,5월 까지 프로젝트 물량이 나오지 않는
다는 것은 다소 심각 하다고 볼 수 있습니다.

물론 앞으로 시간이 지나면 풀린다 라고 얘기
할 수도 있지만 현재 분위기는 전혀 장담 할수가
없습니다.
(몇일 전만 해도 코스피 1730 이였는데 이 글을
쓰는 시점은 1630)

현재 진행 하려고 하는 프로젝트들이
갑자기 drop 되거나 holding 되는 경우가 많습니다.

설사 진행이 되더라도 대부분 기간이 3 ~ 4개월
정도이고 중장기 프로젝트는 거의 찾아 볼 수가
없습니다.

그리고 기존 협렵업체나 외부 소싱 인력의 TO를
Big3 업체의 정규직으로 대체하는 경우가
최근들어서 많이 늘었습니다.
아무래도 매출액 때문이겠죠.
(프로젝트 비용이 거의 노마진 수준)

그래서 시장에서 고급인력의 수요는
거의 없으며 프리랜서 같은 경우는
정말 key man 같은 스페셜
리스트가 아닌 경우는 고급으로
들어갈 수가 없습니다.
(예전 처럼 경력이나 등급이 고급이라고
해서 고급단가 그대로 주는 시대는 갔음)

이러다 보니 고급 프리랜서들이 경력을
다운 사이징 하거나 협의를 통해서 중급같은
고급들이 많아지고 있습니다.
단가 또한 공급이 많으니 당연히
내려 가겠죠.

그리고 예전엔 xxx 프로젝트는 안간다.
이렇게 나름 구분해서 골랐다면 지금은
기간이나 모든 것이 예전보다 열악하기 때문에
지금은 어딜가나 고생은 각오 하셔야 할 것
같습니다.
(최근 면접 본데는 2주 설계완료,개발 한달 이였음..)
그냥 일하는 것 자체만으로 행복하다고 생각
하면서 긍정적으로 일하는게 좋을 듯 합니다.

가끔 후배들 중에서 프리를 하고 싶어 하거나
또는 현재 근무환경에 불만을 가지는 분들은
허벅지바늘로 찌르고 참으시라고 말씀 드리고
싶습니다.
어떻게 보면 행복한 고민 입니다.
한번 몇달 쉬어보면 아실 것입니다.
즉 힘드시더라도 일단 어느 정도 경기가
풀린다고 생각 되면 그때 움직이시란 뜻 입니다.

그리고 이렇게 일이 없다보니 면접이 예전보다
많이 까다로와 졌습니다.
예전에는 면접을 하면 바로 언제 출근 가능하냐
하면서 바로 확정을 지었는데 요새는 아무래도
인력이 많다 보니 예전보다는 깐깐하게 면접을
진행 하는 것 같습니다.
(자기 개발만이 살길.... 무늬만 고급은 이제 고급 단가를
받기 어려움)

이런 분위기에서 최신 트렌드 운운하는 것이
업계 모든 분들께 과연 어떻게 다가갈까
하는 생각이 듭니다.
씁쓸하죠.....

일부러 회의적인 글을 쓰려고 한 것은 아니고,
나름 현실에 대한 정보를 제공 하려는 것 뿐입니다.
이럴때 일수록 서로 예민하지 말고 힘내서
극복해 나갔으면 합니다.
분명 언제가 IT 업계 모든분들이 즐거울
날이 오겠죠 모두 화이팅 !!

일정만 기억하는 더러운 세상

프로젝트를 처음 시작할때 PM한테 일정을 물어 봅니다.

ME : "이번 프로젝트 일정이 어떻게 됩니까?"
PM : "분석/설계 2개월,개발 3개월"
ME : "일정에 대한 근거는 모죠?"
"전 이세상에서 그게 제일 궁금해서요"
PM : "대충 프로젝트 scope이 그정도돼"
ME : "대충? 글면 프로젝트 scope 과 일정의 척도는 뭐죠?"
PM : "그래서 경험이 중요한거야"
ME : "네에? "
"일정을 소화할 설계자/개발자와 협의 해야 하는것 아닌가요?"
PM : (슬슬 짜증내면서) 왜그래 프로젝트 처음하는 사람 처럼
ME : ............
"설계가 밀리면 일정도 밀리나요?"
PM : "안돼 무조건 끝내야해."

여러분들도 "프로젝트 일정 산정 법칙"
궁금하시지 않습니까?
만약 프로젝트가 일정내에 완료가 되면 둘중 하나 입니다.
정말 운이 좋았거나 아니면 개발자들이 고생해서 일정을
맞추어 준 것입니다. 오히려 고마워 해야죠.

• 일정을 사람에 맞추자
  

여기서 하나 게임을 해보겠습니다.
"회원정보를 가져오는 로직이 있는 소스가 있습니다. 1분안에 위의 로직이 필요한 30개 함수에 반드시 적용해야 합니다".
준비 시작~~~~~~~~~~
저 일정을 소화 하려면 100%로 Copy&Paste 할 것입니다.
"제임스 고슬링" 아저씨가 오던 "로드존스"형이 와도
아마도 CTRL+C,CTRL+V를 누르면서 소스에
화려하게 수를 놓고 계실 것입니다.
공통 함수 만들 생각조차 못할 것입니다.
다소 극단적인 표현을 이기는 하지만
일정을 사람에 맞추지 않고 사람이 일정을 맞추면
그 고객에게 전달될 제품의 퀄리티는 굳이 얘기 하지
않아도 아실듯 합니다.

• 몸에 맞지 않은 옷
  

최근에 스프링이 대세도 아닌 필수가 되어서 열공하시는
분들이 엄청 많아 졌습니다.
그런데 왜 우리는 Spring을 써야만 할까요?
경력에 도움이 되어서,아니면 쓰라고 하니깐..
가끔 EJB 시절 묻지마 개발을 떠올리면
Spring도 그전철을 밡을수도 있다는 생각을
하면 씁쓸해 집니다.
Spring을 사용하는 이유는 많겠지만
그중에서 제일 중요한 부분은
테스트주도 개발 입니다.
즉 제품의 퀄리티는 높이고
고객의 요구 사항에 빠르게 응대를 함으로서
유지 보수를 극대화 하는 것입니다.
이러한 철학과 사상은 애자일적인 생각이죠,
(로드존슨 형은 애자일 신봉자..)
하지만 실무에서는 이러한 순수성은
없어지고 오직 일정을 지켜기 위해서 라면
오히려 느슨한 연결과 오픈 소스들이 짐이 되는 것 같습니다.
그냥 날 JSP+도메인 대신 Map 으로 개발하는 것이
더 낫다고 생각합니다.
절대로 현재의 개발 인프라와 Only waterfall 방법론은
재앙으로 다가 올것입니다.

• 파일럿을 하자

제 개인적으로 비판만 있고 대안이 없는걸 싫어해서
말씀 드립니다.
우리나라 개발 환경 특성상 100% 애자일 도입은
사실상 힘듭니다. 하지만 부분적으로 적용할
필요는 있습니다. 특히 순환 방법 개발 입니다.
일단 프로젝트가 시작하면 scope을 줄여서
한 사이클을 2~ 3개월단위로 파일럿 플젝을 진행해야 한다고
생각 합니다. 그래야 어떤것이 부족하고 개발 공수에
대한 예측이 가능하니깐요.
불과 몇년전과 지금 환경은 너무나도 다릅니다.
업무도 복잡해지고 기술또한 오픈 소스의
홍수속에서 살고 있습니다.
그 만큼 변수가 몇년전에 비해서 너무 많다는 것입니다.
하지만 대부분 프로젝트가 완료일이 가까이 되어서야
한사이클이 됩니다. (그나마 한사이클 돌면 다행이죠..)
엄청난 요구 사항과 기술적인 설계의 결함등이 쓰나미처럼
밀려오죠. 옛날은 몸빵이라도 했지만 지금은
그냥 프로젝트가 정지가 되어버린 상태로 되죠.

• 품질로 승부하자

제발 프로젝트를 제안 할때 단가 또는 일정으로 후리지
않았으면 좋겠습니다.
고객들에게 다소 단가가 높거나 일정이 길수는 있어도
품질만은 확실하게 보장한다고 제안 해야 합니다.
이제는 품질로 승부해야 한다고 생각 합니다.
실제로 이런 부분을 몸소 체험한 몇몇 회사에서는
많이 개선하려고 노력하고 있습니다.

• 커뮤니케이션을 통해서 시간을 Save 하자

개인적으로 프리랜서 활동을 하고 있어서 가끔 프로젝트
중간에 투입이 될 경우가 있습니다.
그럴때 제가 제일 먼저 체크하는건 프로젝트 인력들과의
릴레이션 쉽입니다. 아무리 설계가 안되고 프레임웍이 꼬여도
프로젝트 팀원간의 유대관계가 좋으면 힘들거나 두렵지
않습니다. 제가 제일 두려운건 설계도 프레임웍도 아닌
프로젝트 인력간의 유대 관계입니다.
사실 유대 관계가 좋으면 상황이 나뻐지지도 않습니다.
개발자들 매우 감성적인 사람들 입니다.
지속적인 커뮤니케이션을 통해서 이해하고 유대감을 형성하면
야근,주말근무 알아서들 나와서 도와 줍니다.
왜냐면 일하는게 즐겁기 때문이죠.
지속적인 커뮤니케이션을 통해서 생산성을 높이고
최적의 방안을 논의 한다면 상당수 시간을 줄일수 있다고
생각 합니다.

김연아 선수와 팀에서 배워야 할 점

요새 김연아 선수때문에 한국이 난리가 났죠 ..
다시 한번 개인적으로 축하를 전하고 싶습니다.
어떻게 이런한 성과를 얻었는지 조직이든 개인이든
벤치 마킹할 필요가 있습니다.
아래는 그와 관련된 블러그 입니다.
꼭 한번 읽어 보세요
김연아 선수와 브라이언 오서 코치의 "행복" 리더십

개발 마인드를 바꾸자!

얼마전 TV를 보니 재미 있는 얘기를 들었습니다.
고대 이집트의 피라미드 와 고대 건축물들을 보면
어떻게 저 시대에 저런 건물을 지을 수 있을지 지금까지도
불가사의로 남아 있습니다.
이런 일을 가능하게 했던건 뛰어난 수학적 사고와 기술이 바탕이
되었기 때문에 가능하리라고 생각이 듭니다.
하지만 오늘날 수학에 대해서 유럽이나 미국이
훨씬더 발달이 되어 있습니다.
여기서 의문에 생겼습니다.
당연히 고대에 범접할 수 없는 수학 지식을
갖춘 이집트가 주도 하지 못하는 것일까요?
이유인즉 이집트 민족들은 어떠한 목표가 달성이
되면 거기에 만족한다고 합니다. 즉 어떻게
하면 피라미드를 쌓을까 하고 고민하고 구현하면
그걸로 끝이난 거죠. 반면 유럽 사람들은 거기서
만족하지 않고, 이번에 이렇게 해봤으니 다음엔
이렇게 해보자 , 실패하든 성공하든 ...
즉 계속해서 도전하고 실험 하면서 좀 더 나은 방법을
위해서 연구한다는 것입니다.
어느 특정 국가나 민족을 칭찬 하거나 비난하려고
말씀 드린것이 아닙니다.
이 내용을 보면서 현재 우리가 처한 개발 환경에 대해서
많은 것을 생각하게 했습니다.
국내 또는 해외에서 "애자일 방법론"을 사용해서 큰 효과를
봤다 하면 개인적으로 "애자일 방법론"을 한번이라도 사용해
봤다니 부럽다 이런 생각 보단. 그러한 멤버들과 같이 일했다는게
더 부럽습니다.
여기서 애자일 방법론을 찬양 하는 것이 아니라. 무언가를 시도할때
팀원들이 새로운 것을 받아 드릴 준비가 되었는지가
정말 중요하다고 생각 합니다.
꼭 방법론 뿐만 아니라 개발에 있어서 변화에 너무나도
두려워 하는 것 같습니다.
특히나 변화를 싫어하는 팀장이나 PL들은 개발 경험을
가지고 방해 하죠."실무에서 그런거 안통해"
이런식의 접근은 공식하나로 모든 걸 푸려는 것이라고
생각 합니다. 곱셈으로 해결해도 될걸 아는게 덧셈 밖에
없어서 우구장창 더하기만 하는...
물론 책임이 크니 그런말을 할 수 있다고 생각 합니다.
하지만 기술적 검토를 위한 스터디만 한다면
그다지 큰 리스크는 없다고 생각 합니다.
주변에서 정말 매니아 처럼 공부 하시고, 우리쪽
관련 기술에 관심이 많고 스킬이 뛰어난 분도
많지만 반면 어느 정도까지는 정말 열심히 하고
그 이후는 그걸로 평생 가려는 분들이 많은 것
같습니다.
생계형 개발자든 매니아 개발자든 학습 과 연구
는 필요하다고 생각이 듭니다.

소프트웨어 개발방법론의 함정 [전규현]을 읽고서..

얼마전 ZDNet에서 "소프트웨어 개발방법론의 함정"
이란 컬럼을 읽었습니다.
(http://www.zdnet.co.kr/ArticleView.asp?artice_id=20091129180815)
꼭 블러그 읽어보시기 바라며 글을 보고 느낀점이 있어서
몇자 적고자 합니다.

• MNH는 프로젝트에서 꼭 사용합시다.

MNH뜻은 (Maven+Nexus+Hudson)를 축약한 제가 만든 용어
입니다. ^^
현재 프로젝트 사이트가 waterfall를 하던 agile을 하던 아니면
대기업에서 전설로 내려오는 일을 위한 일을 하는 방법론을
사용 하던 간에 이제 빌드 자동화에 대한 투자는 제발
좀 합시다.
빌드 자동화를 한다는 것은 사실 쉽지만은 않습니다.
(현재 제가 진행 하고 있는 프로젝트에서도 많은 시행착오를
경험하고 있습니다. ) 하지만 투자할 가치가 충분 합니다.
tomcat에서 개발한 프로그램이 다른 WAS에서도 잘 동작
하기를 바라는 생각을 한다면 큰코 다칩니다.
JAVA는 OS 독립적이지만 WAS에 의존적이란걸
아는 분들은 아실것입니다.
처음 부터 maven,nexus,hudson,track,mylyn..
다 적용하지 말고 step by step으로 하나씩
필드에서 적용 하시기 바랍니다.

• 전문적인 조직을 갖추자

대략 90년말 ~ 2003년까지는 막개발의 전성 시대라고
할 수있습니다. 조직에서 개발경험이 많은 사람이
개발 리딩 + 업무 리딩을 했습니다.
(혼자서 WAS 설치+DBMS 설치+모델링+프레임웍
+공통 모듈 완전 멀티플레이어)
심지어 SVN에 사용을 안해서 소스 엉키는 게
일이 였습니다.정말 한국인의 의지로 버틴 시절 이었습니다.
(그 때 생각하니 눈물이...)
하지만 지금은 그때와는 복잡도나 규모로 봤을때
엄청나게 변했습니다.
이제는 한국인의 의지가지고는 불가능하게 되었습니다.
하지만 아직도 우리나라 개발 회사들은
한국인의 의지를 믿고 있습니다.
그 믿음이 엄청난 손실로 돌아 오는 경우를
많이 경험 했습니다.
예를 들어서 어중간한 개발자 10명 보다 비즈니스 로직 7명+테크니컬 파트3명
구성된 조직이 더 생산성이 뛰어 납니다.
조직을 분업하고 서로 간의 협업을 통해서
프로젝트를 구성해야 한다고 생각합니다.

• 정치는 이제 그만

가끔 프로젝트를 하다보면 어떻게 하면 성공적으로 프로젝트를
완수하려는 것보다 다른 요인들이 더 중요하다고 생각할때가 있습니다.
예를 들어서 산으로 가고 있으면 이슈화해서 다시 방향을 잡아야지
뻔히 다른 방향으로 가고 있으면서도 이런저런 이유로
그냥 go 합니다.
정말 미치게 하는건 절벽으로 떨어질 걸 알고
간다는 거죠. 설마 죽기야 하겠어 하는
정신으로 말이죠.
그리고 어설픈 Lip Service는 제발 Shut Up!
상품 관리 파트 PL이 TA 파트에 와서 프레임웍 구성이
잘못된것 같다. 다른 비지니스로직 파트에 가서
업무 로직은 그렇게 하면 안된다. 참...
업무상 조언정도는 할 수 있지만 각 파트별
담당자 롤을 침범해서는 안된다고 생각 합니다.
대부분 이런 사람들이
"나는 멀티 플레이어야 나 이런 사람이야"
하고 쌩 PR을 하는 사람들이죠.
대부분 담배피면서 들은 얘기나 구글링을 해서
겉핥기만 하죠.
최신 트렌드 기사한줄 읽고 "그거 아세요?"
하면서 기선제압하는 사람들...
제발 우리 프로젝트만 집중 합시다.

내가 강추하는 디스커버리 프로그램

나이가 들어서 그런지 드라마도 재미 없고 ,리얼 버라이어티도
재미가 없네요.
그래서 최근에 제가 꽂힌 채널이 디스커버리 입니다.
예전에도 조금씩 받지만 더더욱 저를 빠지게하는 2개의 프로그램이 있어서
소개하고자 합니다.

• Man VS Wild

디스커비리 관심있는 사람들은 이 프로그램을 당근 알 듯 합니다.
미국에서는 엄청 인기가 많아서 현재 시즌 3을 방송하고 있습니다.
내용은 한 남자가 헬기를 타고 오지(사막,정글,알래스카같은 추운곳 )
한가운데로 떨어 집니다.
그리고 사람들이 사는 곳까지 생존해서 찾아오는 프로그램
입니다. 주인공은 베어 그릴스라고 실제 영국 특수 부대 출신이며
베테랑이죠 . 휴대품은 딸랑 부싯돌 한개, 먹는 거,자는 것은
주변에서 다 알아서 자신이 해야 합니다. 말그래도 생존 프로그램 이죠.
때로는 주변의 물건을 가지고 신기한것도 만들고 합니다.
마치 맥가이버처럼요. ㅋㅋ
제가 이 프로그램을 보는건 무엇보다 우리가 사는 세계와 흡사한
느낌이 들곤 해서 봅니다. 생존에 필요한건 지식과 건강한 육체
그리고 가장중요한건 긍정적 마인드라고 합니다.
보면서 간접적으로 많이 느끼는 프로그램입니다.
아마도 한번 보시면 바로 낚이지 않을까 합니다.

• Doing Davinci

최근에 디스커버리 새로운 시리즈 입니다. 내용은 천재 네오나르도 다빈치가
생전에 설계만 하고 구현이 되지 않았던 무기 또는 건축물을 실제로
구현하는 프로그램 입니다.
구현후 정말 유용한지 테스트도 합니다.
구현을 할때 설계자 2명 과 목수 2명이 한팀을 이루어서 구현하는데
서로 자주 싸웁니다. ㅋㅋ
설계자는 목수들이 대충한다고 모라고 하고 목수는 언제 구현할거냐고
답답해 하고 마치 it 개발 현실과 너무 흡사해서 공감이 많이 됩니다.
다빈치의 설계를 구현하는것도 재미 있고 실제 프로젝트를 진행하면서
간접적으로 많이 느껴서 좋은 것 같습니다. it 아키텍쳐도 사실은
건축에서 나온 아이디어라 볼수 있죠